Notes from Rolf Potts’ “Vagabonding: An Uncommon Guide to the Art of Long-Term World Travel”

I’m not inherently a person who likes to travel a lot, although I have been to a few places within the country in recent years because there were specific experiences I’ve never done before and wanted to try, like going on an airplane ride, visiting an interesting museum, or learning how to surf. I enjoyed those experiences, even though those were mostly brief getaways with friends. Rolf Potts, however, in his book titled “Vagabonding: An Uncommon Guide to the Art of Long-Term World Travel“, wants us to consider travelling in the long-term rather than living for hurried weekend trips and why.

Some favorite lines from the book:

  • Travel isn’t just for changing what’s outside, it’s for reinventing what’s inside.
  • For some reason, we see long-term travel to faraway lands as a recurring dream or an exotic temptation, but not something that applies to the here and now. Instead – out of our insane duty to fear, fashion, and monthly payments on things we don’t really need – we quarantine our travels to short, frenzied bursts. In this way, as we throw our wealth at an abstract notion called lifestyle, travel becomes just another accessory – a smooth-edged, encapsulated experience that we purchase the same way we buy clothing and furniture.
  • The more we associate experience with cash value, the more we think that money is what we need to live. And the more we associate money with life, the more we convince ourselves that we’re too poor to buy our freedom.
  • No combination of one-week or ten-day vacations will truly take you away from the life you lead at home. Vagabonding involves taking an extended time-out from your normal life – six weeks, four months, two years – travel the world on your own terms.
  • Wanting to travel reflects a positive attitude. You want to see, to grow in experience, and presumably to become more whole as a human being. Vagabonding takes this a step further: it promotes the chances of sustaining and strengthening this positive attitude. As a vagabond, you begin to face your fears now and then instead of continuously sidestepping them in the name of convenience. You build an attitude that makes life more rewarding, which in turn makes it easier to keep doing it.
  • Vagabonding is not like bulk shopping: the value of your travels does not hinge on how many stamps you have in your passport when you get home – and the slow, nuanced  experience of a single country is always better than the hurried, superficial experience of forty countries.
  • If there’s one key concept to remember amid the excitement of your first days on the road, it’s this: slow down. You must keep in mind that the whole point of long-term travel is having the time to move deliberately through the world. Vagabonding is about not merely re-allotting a portion of your life for travel but rediscovering the entire concept of time. At home, you’re conditioned to get to the point and get things done, to favor goals and efficiency over moment-by-moment distinction. On the road, you learn to improvise your days, take a second look at everything you see, and not obsess over your schedule.
  • When you want to hurry something, that means you no longer care about it and want to get on to other things.
  • Shortly after arriving at your initial destination, find a beachhead (be it an actual beach, an urban travelers’ ghetto, or an out-of-the-way town) and spend a few days relaxing ad acclimating yourself. Don’t strike off to hit all the sights or actualize all your travel fantasies from the get-go. Stay organized and interested, but don’t keep a things to do list. Watch and listen to your environment. Take pleasure in small details and differences. Look more and analyze less; take things as they come. Practice your flexibility and patience – and don’t decide in advance how long you’ll stay in one place or another.
  • Don’t set limits on what you can or can’t do. Don’t set limits on what is or isn’t worthy of your time. Dare yourself to play games with your day: watch, wait, listen; allow things to happen. Wherever you are, be it the Vatican gift shop, a jungle village in Panama, or downtown Ouagadougou – keep aware of the tiniest tics and details that surround you. Anything that is remarked, even little flowers or leaves picked up off the ground and shown to a child, even a shoeshine or gravel pit, anything is potentially an attraction.
  • The greater value is not in what you’ve seen and checked off the list, but in what you’ve learned deeply, the hard way.
  • Once you have learned the basics, it becomes clear that having less work is easy. It’s filling the void with more life that is hard. Finding excitement, as it turns out, takes more thought than simple workaholism. But don’t fret. That’s where all the rewards are.
  • What I find is that you can do almost anything or go almost anywhere, if you’re not in a hurry.

Lessons Learned from Scott Adams’ “How to Fail at Almost Everything and Still Win Big”

Last week I had a lovely time reading “How to Fail at Almost Everything and Still Win Big” by cartoonist Scott Adams. His views on success and happiness, and his formula for increasing the odds of success through failures are intriguing, based on his life experiences. He shares ideas about goals and systems, skills, happiness, priorities, and personal energy, which provides a guide for living well. Some of those ideas are ones I already exercise, while others have provided answers to goals that have failed me in the past as well as reasons to why I’ve acted a certain way before. It’s refreshing to learn something new about existing patterns of behavior.

Here are some favorite quotes from the book:

  • A goal is a specific objective that you either achieve or don’t sometime in the future. A system is something you do on a regular basis that increases your odds of happiness in the long run. If you do something every day, it’s a system. If you’re waiting to achieve it someday in the future, it’s a goal. Goal-oriented people exist in a state of continuous pre-success failure at best, and permanent failure at worst if things never work out. Systems people succeed every time they apply their systems, in the sense that they did what they intended to do. The goals people are fighting the feeling of discouragement at each turn. The systems people are feeling good every time they apply their system. That’s a big difference in terms of maintaining your personal energy. Goals only make sense if you also have a system that moves you in the right direction.
  • One of the most important tricks for maximizing your productivity involves matching your mental state to the task. For example, when I first wake up, my brain is relaxed and creative. The thought of writing a comic is fun, and it’s relatively easy because my brain is in exactly the right mode for that task. I know from experience that trying to be creative in the mid-afternoon is a waste of time. By 2:00 PM all I can do is regurgitate the ideas I’ve seen elsewhere. At 6:00 AM I’m a creator, and by 2:00 PM I’m a copier.
  • The way I approach the problem of multiple priorities is by focusing on just one main metric: my energy. I make choices that maximize my personal energy because that makes it easier to manage all of the other priorities. Maximizing my personal energy means eating right, exercising, avoiding unnecessary stress, getting enough sleep, and all of the obvious steps. But it also means having something in my life that makes me excited to wake up.
  • It’s useful to think of your priorities in terms of concentric circles, like an archery target. In the center is your highest priority: you. If you ruin yourself, you won’t be able to work on any other  priorities. So taking care of your own health is job one. The next ring – and your second-biggest priority is economics. That includes your job, your investments, and even your house. You might wince at the fact that I put economics ahead of your family, your friends, and the rest of the world, but there’s a reason. If you don’t get your personal financial engine working right, you place a burden on everyone from your family to the country. Once you are both healthy and financially sound, it’s time for the third ring: family, friends, and lovers. Good health and sufficient money are necessary for a base level of happiness, but you need to be right with your family, friends, and romantic partners to truly enjoy life.
  • There’s a formula for success. You can manipulate your odds of success by how you choose to fill out the variables in the formula. The formula, roughly speaking, is that every skill you acquire doubles your odds of success. Good + Good > Excellent. If you think extraordinary talent and a maniacal pursuit of excellence are necessary for success, I say that’s just one approach, and probably the hardest. When it comes to skills, quantity often beats quality.
  • I find it helpful to see the world as a slot machine that doesn’t ask you to put money in. All it asks is your time, focus, and energy to pull the handle over and over. A normal slot machine that requires money will bankrupt any player in the long run. But the machine that has rare yet certain payoffs, and asks for no money up front, is a guaranteed winner if you have what it takes yo keep yanking until you get lucky. In that environment, you can fail 99% of the time, while knowing success is guaranteed. All you need to do is stay in the game long enough.
  • The single biggest trick for manipulating your happiness chemistry is being able to do what you want, when you want. I’m contrasting that with the more common situation, in which you might be able to do all the things you want, but you can’t often do them when you want. The timing of things can be more important than the intrinsic value of the things. It’s hard to become rich enough to buy your own private island, but, relatively speaking, it’s easier to find a job with flexible hours. A person with a flexible schedule and average resources will be happier than a rich person who has everything except a flexible schedule. Step one in your search for happiness is to continually work toward having control of your schedule.
  • No one wants to believe that the formula for happiness is as simple as daydreaming, controlling your schedule, napping, eating right, and being active every day. You’d feel like an idiot for suffering so many unhappy days while not knowing the cure was so accessible.
  • The happiness formula:
    • Eat right
    • Exercise
    • Get enough sleep
    • Imagine an incredible future (even if you don’t believe it)
    • Work toward a flexible schedule
    • Do things you can steadily improve at
    • Help others (if you’ve already helped yourself)
    • Reduce daily decisions to routine
  • Always remember that failure is your friend. It is the raw material of success. Invite it in. Learn from it. And don’t let it leave until you pick its pocket.

Takeaways from Rob Lambert’s “How To Thrive As A Web Tester”

Rob Lambert released a new book on testing early this year, with title “How To Thrive as a Web Tester“. Like “Remaining Relevant and Employable in a Changing World” and “The Problems with Software Testing“, the new book only takes a few hours to read through and is focused, this time offering ideas which challenges testers to think more about how they perform their day-to-day work and their skill set. Rob wants us to flourish as testers, and the book provides us with tidbits of actionable items.

Here are a few gems from the book:

  • Understand who your customer is.
  • Your job is to keep up to date with what’s happening, ask how it might affect your job or how you approach testing. Your job is to get involved with new ideas, movements and embrace the technology that floats your boat.
  • Pick something and learn it. It will likely be out-of-date soon, or surpassed by something else. Don’t let that stop you though – just pick something and learn it. What never goes out-of-date is a Tester’s ability to find problems, ask tough questions and work well with others. Focus on developing those skills and you’ll make a great Tester whatever the tech stack you’re working on.
  • The tech moves on, the way we deliver it has moved on, the pace of delivery may change but the same problems exist; how to get people to work well together, how to understand customer’s needs, how to scale, how to make profit, how to dominate a market, how to learn, how to build an effective and efficient businesses, how to stop bugs affecting customers. Same problems, different tech.
  • Your job is to ship software. Sure, if there are problems that will affect the customer or company, you’ll stop the release, but you’ll also work tirelessly to see how you can improve to allow safer releases, better monitoring, better rollbacks, better roll forwards and a more seamless release mechanism.
  • You need to remain relevant, employable and effective to a wider business community. You cannot rely on your employers for your career development and security – that is your own responsibility.
  • Let go of your job role, or what your job description says, and take ownership of the actual work and any problems that surround it. Take on problems others aren’t owning. Or offer to help those struggling with fixing tricky problems at work. There are always problems, and most problems exist between job roles.
  • Testing is the art of asking questions and seeking answers. Never stop asking questions. Study how to ask good questions. Study how to listen for answers. They can come from anywhere, at any time. Good Testers know when to ask questions. They build the muscle memory needed to match patterns, to know when and where to ask, to know what to ask, to know who to ask, and to follow instincts.
  • Good Testers solve problems. Even problems that are outside of the responsibility of Testers.
  • If you aren’t as good as you can be, it’s because you haven’t yet decided to be the best version of yourself yet. It’s as simple as that.
  • We are all, thankfully, different. There is no single model we should all fit. The world would be a pretty dull place if that were the case.

Notes from David Bryant Copeland’s “Build Awesome Command-Line Applications in Ruby 2”

The experience of writing and running automated checks, as well as building some personal apps that run on the terminal, in recent years, has given me a keen sense of appreciation on how effective command-line applications can be as tools. I’ve grown fond of quick programming experiments (scraping data, playing with Excel files, among others), which are relatively easy to write, powerful, dependable, and maintainable. Tons of libraries online help interface well with the myriad of programs in our desktop or out in the web.

Choosing to read “Build Awesome Command-Line Applications in Ruby 2” is choosing to go on an adventure about writing better CLI apps, finding out how options are designed and built, understanding how they are configured and distributed, and learning how to actually test them.

Some notes from the book:

  • Graphical user interfaces (GUIs) are great for a lot of things; they are typically much kinder to newcomers than the stark glow of a cold, blinking cursor. This comes at a price: you can get only so proficient at a GUI before you have to learn its esoteric keyboard shortcuts. Even then, you will hit the limits of productivity and efficiency. GUIs are notoriously hard to script and automate, and when you can, your script tends not to be very portable.
  • An awesome command-line app has the following characteristics:
    • Easy to use. The command-line can be an unforgiving place to be, so the easier an app is to use, the better.
    • Helpful. Being easy to use isn’t enough; the user will need clear direction on how to use an app and how to fix things they might’ve done wrong.
    • Plays well with others. The more an app can interoperate with other apps and systems, the more useful it will be, and the fewer special customizations that will be needed.
    • Has sensible defaults but is configurable. Users appreciate apps that have a clear goal and opinion on how to do something. Apps that try to be all things to all people are confusing and difficult to master. Awesome apps, however, allow advanced users to tinker under the hood and use the app in ways not imagined by the author. Striking this balance is important.
    • Installs painlessly. Apps that can be installed with one command, on any environment, are more likely to be used.
    • Fails gracefully. Users will misuse apps, trying to make them do things they weren’t designed to do, in environments where they were never designed to run. Awesome apps take this in stride and give useful error messages without being destructive. This is because they’re developed with a comprehensive test suite.
    • Gets new features and bug fixes easily. Awesome command-line apps aren’t awesome just to use; they are awesome to hack on. An awesome app’s internal structure is geared around quickly fixing bugs and easily adding new features.
    • Delights users. Not all command-line apps have to output monochrome text. Color, formatting, and interactive input all have their place and can greatly contribute to the user experience of an awesome command-line app.
  • Three guiding principles for designing command-line applications:
    • Make common tasks easy to accomplish
    • Make uncommon tasks possible (but not easy)
    • Make default behavior nondestructive
  • Options come in two-forms: short and long. Short-form options allow frequent users who use the app on the command line to quickly specify things without a lot of typing. Long-form options allow maintainers of systems that use our app to easily understand what the options do without having to go to the documentation. The existence of a short-form option signals to the user that that option is common and encouraged. The absence of a short-form option signals the opposite— that using it is unusual and possibly dangerous. You might think that unusual or dangerous options should simply be omitted, but we want our application to be as flexible as is reasonable. We want to guide our users to do things safely and correctly, but we also want to respect that they know what they’re doing if they want to do something unusual or dangerous.
  • Thinking about which behavior of an app is destructive is a great way to differentiate the common things from the uncommon things and thus drive some of your design decisions. Any feature that does something destructive shouldn’t be a feature we make easy to use, but we should make it possible.
  • The future of development won’t just be manipulating buttons and toolbars and dragging and dropping icons to create code; the efficiency and productivity inherent to a command-line interface will always have a place in a good developer’s tool chest.

Running Application Audits with Lighthouse

It was only recently that I was made aware of Lighthouse, a relatively new tool for running notable audits for web apps. It’s an open-source tool from Google, and can be found inside Chrome’s DevTools under the Audits tab.

Here’s what it looked like when our team tried it on a recent project (click GIF for a full view on another tab):

Running Audits with Lighthouse

The results:

Accessibility, Best Practices, and SEO Audits

Apparently we did good on accessibility, SEO, and best practices. We don’t usually test for these things, but it’s nice to know that we do enough on them. The application running on localhost wasn’t configured to run on HTTPS yet so it’s about right that we failed that audit for best practice. It’s also true that our app was designed to have small font sizes.

Performance Audit

What’s interesting to see was the dreadfully poor app performance. Throttling our page on a mobile device with 3G connection, it took at least 20 seconds before anything appeared on the page. That’s not good.

And some culprits:

Performance Audit: Opportunities for Improvement

It seems we can do better with our images and style sheets. And it also looks like our JS takes too long to boot-up. We don’t exactly do high-detail performance testing at work so it is awesome to have such a quick audit report from within the browser that notify us about such issues early. At least we’ll know the areas where there’s room for improvement right away.

There’s no excuse to not testing performance (as well as SEO, accessibility, and best practices) on a web app anymore, as far as tools are concerned.

Five People and Their Thoughts (Part 6)

Some engaging articles I’d like to share today:

  • The Failures of ‘Intro to TDD’ (by Justin Searls, about classic test-driven development, code katas, what TDD’s primary benefit actually is, mocks, and discovery testing)
  • Branching is Easy. So? Git-flow Is Not Agile (by Camille Fournier, on Git, tooling, teams, developing software with agility, how easy it is to create feature branches with Git, and some reasons why you don’t need it)
  • What’s Wrong With Estimates? (by Yorgos Saslis, about estimates, why we are being asked to provide estimates, and the pitfalls of the ways we are using them)
  • A New Social Contract for Open Source (by Eran Hammer, on open-source, free code but paid time, sponsorship, making clear rules and specifying benefits, and sustainability)
  • Introducing Example Mapping (by Matt Wynne, about conversations to clarify and confirm acceptance criteria, feedback, colored index cards, and the benefits of writing examples when exploring a problem domain)

Exposing Local Apps Publicly with Ngrok

Here’s a screenshot of something we’ve currently been working on:

It’s not available publicly yet, because it’s still in the early stages of development. The app, hosted locally on, will redirect to a 404 page unless you have the app installed in your machine. As a programmer, the changes I’m making on the app is only accessible on my local computer. Other programmers will only be able to view the changes I’ve made if I push said changes and they download those updates on their machines.

Similarly, I’ll be redirected to an error page if I view the said app on my phone:

What if a tester or a product owner requests an impromptu demo of the app? What if they want to test it as is? Early constructive feedback is always nice. We can set up the app on their machine, but what if they’re working remotely? I’m pretty sure it would be a pain for them to install the development environment on their own. And what if they want to test it on their mobile phone? Having the environment installed on their computer doesn’t mean they can test the app on an actual phone.

Apparently there’s Ngrok. It’s a quick solution to publicly sharing local apps over the internet.

Here’s a screenshot of me trying out the free version:

And now I can test the app on my phone!

No installations needed on the tester / product owner / client side, just a single bash command from the programmer instead. So cool!