Travel to Live Blog

Stories of our adventures and updates about the site.

Month: December 2016

Planning my trip on Travel to Live

As I look back on the month and 2016, I wanted to take some time to talk about planning my trip on Travel to Live. When we were making our plans for our Vienna trip, my wife and I needed a place to share our ideas with each other: Travel to Live is such a great tool to do that. In the past, we used Google Docs because the most important thing for group travel or couple travel is that you have one place that you can all see. Improving on that experience was a guiding factor when building the site.

Getting Started

Everybody plans differently but, often, you don’t know exactly what you want to do. You have some ideas for some places you definitely want to go. There are some things you want to do. You know what area you’re going to stay in. Don’t you just want to start pinning them on a map, so you can get some idea of what you’re looking at?

Planning my trip on Travel to Live

All our ideas, unsorted

This isn’t quite what we had in the beginning. Originally, there were few connections between the points, with even more points than what you see now. It looks quite daunting, doesn’t it? Well, it has definitely given support to our future plans for sorting and tagging options. But, for now, you can already sort your plans into different Locations and Days. Sometimes you don’t know where or when you’re going, so you just want to list all the ideas. You can do that too.

Save your ideas on Travel to Live

This was actually the main section we used in the beginning. We just kept adding and adding to this list. Then, when we wanted to plan a specific day, we would look into this list or check their locations on the map to figure out what we wanted to do that day. The list can grow to be quite unwieldy but, as I mentioned, we are looking into tagging and sorting options, which will improve the experience.

Sorting your trip

Pin your ideas on Travel to Live

Day 3 of our Vienna trip

We actually kept planning the trip each night, while we were on the trip. Each night, we would sit down on the computer and think about what we wanted to do the next day. We’d drag the ideas into the next day or some future day and come out with something like the above. Sometimes we changed the plan retroactively, so we could share our true journey later. I think you’ll agree the above picture is much easier to read and understand. This picture is focused only on Day 3 and gives a clear overview.

Planning my trip provided many insights

As I mentioned in Eating your own dog food, it’s important that you use your own product. Testing is one thing but really using the product is something else entirely. I quickly found a variety of issues with the site, both in terms of usability and outright bugs. With our week-long trip to Vienna, it wasn’t long before we became overwhelmed by all our ideas. It wasn’t a problem because I know my way around the site and how to use the existing sorting options. Are new users able to use the site in the same way? Do they understand the sorting options? Do they even come to the point where they have so many ideas? These are all important questions that we need to monitor and address.

The site is already very easy to use and straightforward for planning my trip but there will always be improvements that can be made. If you haven’t already, try planning your trip now on Travel to Live. Give us some feedback on what features you’d like to see. Coming soon: the ability to collaborate on one trip with your friends!

Eating your own dog food

No, this post isn’t about man’s best friend or his favourite dishes. Eating your own dog food refers to a company using its own products. Believed to have originated at Microsoft in the 1980s, it’s a colloquialism I’ve always believed in at every place I’ve worked for. It’s not always easily achievable but you need to find a way to use your own product, if you truly want to understand it as consumers do.

It’s easy to get into a bubble and focus only on what you think your product is or what you hope your product will do. Sometimes programmers are assigned a task and they view it purely as a task to be accomplished. I worked at a company previously who was making a Facebook version of their popular web game. Some fellow coders told me how they had never tried the game yet because they didn’t use Facebook. That’s great but we’re making a Facebook game, so you better start using Facebook now. Often I hear arguments about how a feature ought to work, from people who have never themselves used the product and don’t realize that it doesn’t work as they planned it to. That’s why you’ve got to use your own product; you’ve got to be eating your own dog food.

Thus, I came to the conclusion that the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual. The separation of any of these four components would have hurt TeX significantly. If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important. – Donald E. Knuth, The Errors Of TeX”

Making a product you believe in

Perhaps we’re very fortunate at Travel to Live because we’re making a product we really believe in. We hatched the whole idea when we were flying back from one of our many travels. This is a product that, by definition, is one we want to and do use. That’s why when I started planning my Vienna trip, I started planning it on Travel to Live.

You can gain a lot of insight by eating your own dog food. Regular bug testing won’t catch everything because you won’t think of every use case. By using the product naturally, you find those corner cases or you find the places your app breaks down and stops being fun. You think of new ideas for the future. Soon, your bug list has exploded, your wish list has created work for the next ten years, and your understanding of the product has deepened immensely.

Staying focused

It sounds like all upsides but it isn’t. It’s easy to become distracted or to lose focus. Every software developer knows that you can’t implement every dream feature or fix every bug. The first thing I learned when I started working at Electronic Arts is that the typical game ships with hundreds or thousands of bugs. Most of these errors are simple: the user will never see them. But it’s a reality every project manager needs to consider when prioritizing tasks and assigning work.

I’m on day 4 of my trip and I’ve already thought of months worth of work, all of which would derail us from our current plans. Right now, we want to focus on user acquisition and the early experience. As a power user of this site, the things that matter to me aren’t the things that matter to our target users. You can’t lose sight of that. You can’t allow bias to cloud your judgement and change your plans. I would absolutely love to implement a tagging feature right now, to make sorting my Ideas much easier, but it’s not a top priority. It’s going to have to wait a little longer.

The most important thing to do is fill out the bug reports and write down the new user stories. Don’t lose all this valuable data. Issues can be closed and rejected or simply scheduled for the future. You lose nothing by recording these valuable insights.

Eating your own dog food is important at all levels of the company

The most difficult thing is keeping all employees engaged. In a small startup, it’s not so difficult, because the company is made up of a tight group of passionate people. They wouldn’t be working on the project if they weren’t interested. It’s a different story in a larger company, meaning startups need to keep their culture as they grow. As companies grow, they hire people to do a task, not always because they are passionate about the product. It’s important to keep a culture of eating your own dog food in the company because employees may not do it without prompting.

Like many millennials, I believe everybody has something to contribute, at all levels. I believe everybody should feel included. You want the people at the lowest level of the company to be able to raise issues that might be important, issues which the highest levels might find important. If everybody is using the product, you maximize the number of different internal viewpoints on the product, which can only be a good thing. You don’t need to implement everything Joe in QA wants; however, he just might be using the product in a way you never imagined.

Time to eat more

I’ve been writing this article from Cafe Tirolerhof in Vienna, Austria. I’m on vacation but an entrepreneur is never truly on vacation. After all, I’m eating my own dog food every day I’m here. Follow my adventures on my personal blog or view my Vienna trip on Travel to Live! Coming soon: blog integration with your personal profile! Stay tuned for more details.

PHPUnit Visual Studio Code Extension

Run PHPUnit tests from VSCode

 Visual studio marketplace version badge Visual studio marketplace installs badge Visual studio marketplace rating badge

At Travel to Live, we love the open source community and we have a bunch of it in our daily arsenal. So, we thought, time to give something back, even if just a small piece! I’m sure anyone reading this is familiar with the famous text editors Sublime text, notepad++ and Atom. But have you tried the new (out of beta under a year ago) Visual Studio Code? Yes, I know what you’re thinking. Visual Studio? Microsoft? Are they making an open source text editor? The answer is yes! And it even runs on Linux and Mac! Yea you heard that correctly. Microsoft is stepping up their open source presence a great deal. Now, what better way to give back to the community than creating a PHPUnit extension in the text editor I use daily, yea you guessed it, Visual Studio Code.

Make everyday work easier

Our back-end is built with PHP, and we do our testing with PHPUnit. However running tests from the command line is no exciting task. You have to start up the command prompt and type the right commands and filter so that it only tests the function you want and you have to do it over again when you want to test another function. But what if you want to test a whole class, what’s the command for that again? As coders, we are lazy and just want to be able to do the thing we want by some command and only solve the problem once. And this is where I saw a chance to fill a pot hole.

The PHPUnit Extension

The extension provides a simple way to run single or multiple PHPUnit tests with minimal effort. Just like Sublime and Atom, VSCode has a command palette where you can execute commands. And one command can be used in different ways depending on the context. So, for example, if your cursor is currently on a function and you run the command, it will test that function. But if you put the cursor on the class, it will run all tests in that class instead. Dead simple. Have a look at the GIFs below.

My Visual Studio Code extension for PHPUnit runs any test function quickly and easily!

Testing a function

My Visual Studio Code extension for PHPUnit tests a whole class quickly and easily!

Testing a class

VSCode also provides a really simple way to pass configurations to your extension, so all the user has to do is open his settings and enter the path to PHPUnit and a string with additional arguments (that can be anything PHPUnit accepts). Settings in VSCode are all in JSON, no tucked away settings in some sub-menu somewhere; it’s all there, searchable in a JSON file.

    "phpunit.execPath": "path/to/phpunit",
    "phpunit.args": [
        "--configuration", "./phpunit.xml.dist"

My experience writing the extension

Extensions are written in TypeScript, which is basically ES6 with types, so no need to learn any complicated things there. VSCode also provides autocomplete into its API, which makes it really easy to find the functionality you’re looking for. Getting started couldn’t be easier. Their documentation explains everything step by step so you can have a “Hello World” extension up and running in no time. All and all, it took me about a weekend to go from not knowing anything about how to make extensions in VSCode to having published it. Writing the actual code was really quick: not a lot of code was required for this extension. If you’re interested in making an extension yourself, know that with VSCode it’s quite simple! Now, if you’re already using VSCode and PHPUnit go ahead and check out my extension!

© 2017 Travel to Live Blog

Theme by Anders NorenUp ↑