Tag Archives: javascript

Takeaways from Derek Sivers’s “Anything You Want”

Derek Sivers, in his book titled “Anything You Want“, shares tales and lessons he’s learned when he started, built, and sold CD Baby, a global music distribution platform, for $22M (which will return to musicians after he dies). He’s an entrepreneur, but a divergent kind of entrepreneur from the ones I’m accustomed to, and I’ve grown fond of his philosophies in both business and in life. Perhaps it’s because of Seth Godin‘s influence, perhaps it’s because he’s a very slow thinker, perhaps it’s because the things he says just sounds about right.

Some favorite lines from the book:

  • Most people don’t know why they’re doing what they’re doing. They imitate others, go with the flow, and follow paths without making their own. They spend decades in pursuit of something that someone convinced them they should want, without realizing that it won’t make them happy. Don’t be on your deathbed someday, having squandered your one chance at life, full of regret because you pursued little distractions instead of big dreams. You need to know your personal philosophy of what makes you happy and what’s worth doing.
  • The key point is that I wasn’t trying to make a big business. I was just daydreaming about how one little thing would look in a perfect world. When you make a business, you get to make a little universe where you control all the laws. This is your utopia. When you make it a dream come true for yourself, it’ll be a dream come true for someone else, too.
  • Success comes from persistently improving and inventing, not from persistently doing what’s not working. We all have lots of ideas, creations, and projects. When you present one to the world and it’s not a hit, don’t keep pushing it as is. Instead, get back to improving and inventing. Present each new idea or improvement to the world. If multiple people are saying, “Wow! Yes! I need this! I’d be happy to pay you to do this!” then you should probably do it. But if the response is anything less, don’t pursue it.
  • If you’re not saying “Hell yeah!” about something, say no. When deciding whether to do something, if you feel anything less than “Wow! That would be amazing! Absolutely! Hell yeah!” then say no. When you say no to most things, you leave room in your life to throw yourself completely into that rare thing that makes you say, “Hell yeah!” We’re all busy. We’ve all taken on too much. Saying yes to less is the way out.
  • Never forget that absolutely everything you do is for your customers. Make every decision – even decisions about whether to expand the business, raise money, or promote someone – according to what’s best for your customers. If you’re ever unsure what to prioritize, just ask your customers the open-ended question, “How can I best help you now?” Then focus on  satisfying those requests. None of your customers will ask you to turn your attention to expanding. They want you to keep your attention focused on them. It’s counter-intuitive, but the way to grow your business is to focus entirely on your existing customers. Just thrill them, and they’ll tell everyone.
  • Watch out when anyone (including you) says he wants to do something big, but can’t until he raises money. It usually means the person is more in love with the idea of being big-big-big than with actually doing something useful. For an idea to get big-big-big, it has to be useful. And being useful doesn’t need funding. If you want to be useful, you can always start now, with only 1 percent of what you have in your grand vision. It’ll be a humble prototype version of your grand vision, but you’ll be in the game. You’ll be ahead of the rest, because you actually started, while others are waiting for the finish line to magically appear at the starting line.
  • Never forget why you’re really doing what you’re doing. Are you helping people? Are they happy? Are you happy? Are you profitable? Isn’t that enough?
  • We all grade ourselves by different measures:
    • For some people, it’s as simple as how much money they make. When their net worth is going up, they know they’re doing well.
    • For others, it’s how much money they give.
    • For some, it’s how many people’s lives they can influence for the better.
    • For others, it’s how deeply they can influence just a few people’s lives.
    • For me, it’s how many useful things I create, whether songs, companies, articles, websites, or anything else. If I create something that is not useful to others, it doesn’t count. But I’m also not interested in doing something useful unless it needs my creative input.
  • When you want to learn how to do something yourself, most people won’t understand. They’ll assume the only reason we do anything is to get it done, and doing it yourself is not the most efficient way. But that’s forgetting about the joy of learning and doing. Yes, it may take longer. Yes, it may be inefficient. Yes, it may even cost you millions of dollars in lost opportunities because your business is growing slower because you’re insisting on doing something yourself. But the whole point of doing anything is because it makes you happy! That’s it! You might get bigger faster and make millions if you outsource everything to the experts. But what’s the point of getting bigger and making millions? To be happy, right? In the end, it’s about what you want to be, not what you want to have. To have something (a finished recording, a business, or millions of dollars) is the means, not the end. To be something (a good singer, a skilled entrepreneur, or just plain happy) is the real point. When you sign up to run a marathon, you don’t want a taxi to take you to the finish line.

6 Curious New Tools to Try for Writing Automated Checks for Browser Apps

While I don’t find myself writing a lot of browser-based automated checks these days, I still am on the look out for interesting new tools in that space. The reason: the new tool solves an existing problem I have with setting up such a testing suite from scratch or provides a solution for certain curious use cases I’ve never experienced before. While using Ruby and Watir together in writing tests running through the browser for me is sufficient for common tasks, such a new tool could be a better fit for another project.

Here’s a list of such tools that popped up in my feed in recent months:

  • Cypress. What I like about Cypress, aside from the standalone package installation option and the built-in pretty test report page, is that the pre-defined browser tests that the actual team runs on its own site is included out-of-the-box. This way they made it easy for me to write custom tests; I just had to search for an example of what I wanted to do, copy-pasted it to my own test, and updated the parts that needed changing. Tests are written in Javascript. I have yet to try running the tests via the terminal though, which is important when running tests on a CI server. Using their test runner is free for all projects, however there is a pricing plan for using their dashboard service which helps keep test recordings private.
  • Katalon Studio. This is a full-blown automation solution that is completely free. There’s a pricing plan for business support services. The record-and-playback feature built-in to the tool failed to impress me when I ran it through our legacy apps, but perhaps writing the actual test code through their GUI fares better (using which there will be a high learning curve for people like me who like to use the CLI and personally-configured IDEs).
  • Puppeteer. Build to control Google’s headless Chrome or Chromium browser, running over the DevTools protocol. Tests are written in Javascript. Easy to try and get into using their web playground. Alister Scott has tried it running with Mocha and Circle CI on a demo project.
  • Chromeless. Similar to Puppeteer, but built to automate an army of Chrome browsers running in parallel. It gives us the option to run tests on AWS Lamba too. Again, tests are written in Javascript, which we can try on their demo playground.
  • Laravel Dusk. This gives PHP developers familiar with Laravel the ability to write and run their own browser app tests, using a programming language they’re much accustomed to.
  • Appraise. Similar to BackstopJS, a tool for visually validating browsers apps. Tests are written in Markdown.

Lessons Learned From Gergely Revay’s “Web Hacking: Become a Pentester” Online Course

The realm of security testing is something I have not explored yet in deep detail not because it’s not an interesting field but because I have always found it to be intimidating, stuffed with jargons and specialized tools to learn. But the curiosity is there, and I’ve decided late last year that I want to get better at it. For that reason I’m glad that Gergely Revay has opened an online course on becoming a web pentester this year. Great timing! And very practical too because I was able to directly apply what I learned on the course at work. 🙂

As with any skill, we master it through practice. But here are some notes about the key ideas I learned from the course:

  • Security testing requires exploratory testing. A tester can only find out where the security vulnerabilities are when such person has good understanding of what risks are present in the application, and one can only know about what the risks are when one has vastly explored application behavior in various scenarios as well as the technology stack where it runs.
  • Using JavaScript to create stored cross-site scripts and running them on a vulnerable app is an easy way to annoy users who frequent a page.
  • We can download or view application data (and more) through a system’s insecure file upload feature. Secret configuration files may not be as safe as we think they are.
  • Kali Linux provides us common word lists that we can use to brute-force attack logins. An account is only as safe as the complexity of its matching password.
  • Getting legitimate users to run a malicious script for an attacker relies on how good the attacker is in manipulating the target person to visit some desired page.
  • It is possible to run operating system or database commands on the server where an application is running.
  • Even if an SQL injection does not provide us details of the query results, as long as the injection works we may still get interesting data from the app through succeeding creative attacks.
  • Applications, as innocent as they may seem, can help an attacker find vulnerabilities through the user experience. Be careful about the hints you provide to users when they fail to authenticate their account, among other possible
  • Because security testing relies so much on a tester’s knowledge of the app under test, security testing is difficult. The deeper the tester know about which features are available and how they work, both in the user interface level and in the background, the better the chances of the tester finding security vulnerabilities.

Three Recommended Paid Software Testing Online Courses

Free online courses are nice, but some paid ones are just better at delivering value especially when instructors take a lot of care about building the best possible content they can provide to their audience. Free is always an option, but the problem with free is that we don’t necessarily have to give anything back in return for a service. We can do nothing and that’s okay. With paid courses however I find myself to be more motivated to take in everything I can. I focus more and I believe that helps me learn better.

Here are three recommended paid software testing courses I’ve taken recently, from which I’ve learned a great deal:

About Selenium Conference 2016

I had time over the holidays to binge watch last years Selenium Conference talks, which was as awesome, if not more so, as the talks during the 2015 conference. Automation in testing has really come a long way, alongside the advancements in technology and software development, and this brings forth new challenges for all of us who test software. It’s not just about Selenium anymore. Mobile automation still proves to be challenging, and soon we’ll have to build repeatable test scenarios for the internet of things – homes, vehicles, stores, among others. Software testing can only get more interesting by the year.

Here are my picks for the best talks from the conference, if you’re curious:

Slowly Trying To Learn How To Write Automated Checks With Javascript

If I were to treat the experience like a game, the difficulty level I felt when learning how to write automated checks with Java is normal. At the time, the choice of programming language was obvious – I still remembered how to write C++ functions and if-else conditions and loops from back in college so I thought that maybe I could ease through the course materials that I took. By then I also had practical knowledge about Selenium using the Firefox record-and-play extension, or at least I understood how valid page element locators and Selenese commands are composed. What I focused more then was understanding how I could customize, update, and maintain checks in code rather than by updating all Selenium IDE tests via the browser extension, since the latter was a huge pain. Along the way the way I learned other stuff – object-oriented programming, version control, virtual machines, Selenium Grid, and parallel testing.

Then a year later I decided to rewrite the existing test code to a Ruby implementation, coupled with gem libraries like watir and page-object. There were no actual massive reason as to why I decided to try another programming language, except that I was curious. Ruby sounded cool, there were many who thought of the language as programmer-friendly, and when I found out about Jeff Morgan‘s Cucumber and Cheese book online I finally gave in and studied. And I realized, after writing test code in Ruby for a few months, that the difficulty level was easy. Perhaps because I’ve already absorbed a lot from programming in Java, or perhaps because I’ve found out (and was amazed) that Ruby code in general is more readable. The learning process was tons of fun – aside from spotting mistakes in my earlier style of writing code with Java and became more informed about refactoring, I also got knowledgeable about writing API tests, even HTTP requests, and understood that there are ways of testing web applications without directly interacting with the user interface.

Now I’m reading Enrique Amodeo’s Learning Behavior-Driven Development with Javascript book and studying how to write automated checks using Javascript. The difficulty level is hard, even with all the experience I’ve gained with previous programming languages, and I say that it’s all because of the language syntax. If I didn’t know any other programming language, I would probably come out and say that the difficulty level is insane. From what I’ve experienced so far, the abundance of braces, nested functions, callbacks, and promises makes it difficult for me to read and debug, and I feel that there’s a lot of room for making mistakes. Writing test code in Javascript is a bit overwhelming. So learning is slow, and a lot of the time I have to back-read and study how the code was written some more before going forward to the next lesson. But it’s all good practice for mastering the language and it’s quirks, which may prove useful someday.

Five People and Their Thoughts (Part 3)

There’s always something new to learn, and these days watching webinars and recorded conference videos are good ways of finding and sharing interesting content about what practices do other people think is important in software testing. Lately I am finding myself getting more curious about performance and security testing, as well as the idea of software (including test code) as specification.

Some engaging thoughts about those topics, if you’re interested: