Sandboxes are fun. A simple box full of sand, a bucket, and a shovel somehow opens the imagination like nothing else. You can build anything you want, keep it around for a while if you like it, add to it, subtract from it, or crush it in Godzilla like fashion if you so choose. You can experiment with your creation in any way imaginable, without consequence. Creating things in such a carefree environment can be refreshing, and rewarding.

I think that it is a great idea for developers to have such an environment for themselves where they can try out new technologies, techniques, or processes. Setting up a sandbox now-a-days is pretty easy. Machines are cheap, or free if you’re not picky and keep your eyes and ears open. That 4 year old PC that your cousin is throwing away because he got a brand new Dell for Christmas will fit the bill just fine. Linux is free, runs great on older computers, and has the power and flexibility to host virtually any application. Sign up for a free DNS service such as DynDNS and poof, you’ve got yourself a little server that you can reach over the Internet. My sandbox is a dusty old dual Pentium III with 512 MB of RAM, which is running Ubuntu Linux. It fits the bill quite nicely if you ask me.

But a sandbox is only half the equation. For developers, we need an application that we can play with in the sandbox. Something we can poke and prod. A sandbox application so to speak. There are several reasons why you many want to create a sandbox application.

Platform for playing with new technologies

Perhaps the biggest reason for creating and maintaining your own sandbox application is that it can serve as a platform for trying out new technologies. Doing this at work can be tough. Your boss or client may not be thrilled to hear that you completely re-wrote part of the application to use the bleeding edge release of some hot new framework because you “thought it was cool”. But, there’s nothing stopping you from doing it with your own application. Even if you rely heavily on your application, there’s no reason why you can’t fork your code, and give the new technology a try on a separate branch. If it works out you can merge the code into the main branch, and if not you can always abandon the changes. Now, this approach will only work if you have your application under source control (which you should). If you don’t mind giving the world access to your code, GitHub will host your code for free. Otherwise, it’s very easy to setup your own source control system in your sandbox.

Material to blog about

Trying out new technologies, techniques, or processes can also give you plenty of material to blog about. If the technology/technique/process you are tinkering with is hot, it is very likely that many people will be interested in reading about your experience. If you blog frequently about topics that people are interested in, you’ll steadily increase readership. This could be very good for your career, as well known programmers generally don’t have a hard time finding work. Work usually finds them.

Create something that you will use

What’s the point in going through all of this trouble to create something if you never use it? I’ve created a few applications that I use on a regular basis. Not only did these applications address some need that I was currently facing, but having a sandbox application that you actually use means that you will be more likely to maintain and enhance it.

Looks great on a resume

Employers love to hire people who show an interest in their field outside of work. I’ve found that people passionate about their field are usually better at their jobs than those who show up at 9, work on the same ol’ stuff for 8 hours, and go home. Having a sandbox application shows people that you love what you do so much that you have dedicated time outside of work to create something that you care about. This especially holds true if you’ve put serious thought into your application, and are excited to show it off to anybody who asks to see it.

Release it, and potentially help others

One of my colleagues once said,

Your parents lied to you. You are not special. There’s millions of people out there just like you.

He wasn’t trying to be mean, this time :) He was simply pointing out that you are not alone. If you are facing a problem, odds are there are hundreds or thousands (or more) of people out there who are facing that same problem. Releasing your application could be helping all of these people. Perhaps it would help them so much that they would be willing to pay for it. Wouldn’t that be nice?

Open source your application

Open sourcing your application can be great for several reasons. Perhaps you’ve just finished migrating your application to the latest version some framework. Not only can you blog about your experience, but you can share the code with others so that they can see exactly how you did it. This could potentially help others looking to migrate their applications to the same framework. You could get feedback from the community about something you could be doing better, and learn something new. People looking at your code could spot a bug, giving you the opportunity to fix it before it affects you (especially if you use your application). Some employers ask to see source code samples as part of the interview process. What sort of reaction do you think you would get if you immediately spit out several repositories that you owned on GitHub for the prospective employer to browse at their leisure? I’m not sure about you, but I’d be pretty impressed.

However, there is a potential drawback in releasing your code to the world. Ironically, it’s the same as one of the benefits. The world can see your code. This can be a bad thing if your code is full of bugs, or sloppy. So if you plan on releasing your code, take the extra care necessary to ensure that the code reflects your best effort. Your code, and you as a developer, will benefit from the extra TLC.

The next big thing

You never know which crazy, off the wall idea will turn into the next big thing. Who would of thought that there was a real need for an application that lets you tell the world what you’re doing right now. If your idea for a sandbox application turns into something with real business value, then you never know where it will end up. Large companies will often spend big bucks to buy great ideas. I’d imagine it would be pretty cool to be on the receiving end of one of those deals.

Summary

Creating a sandbox, and a sandbox application is something that every serious developer should do. If nothing more, it will give you a place to tinker with new technologies and grow as a developer. There is little to no cost to set it up, and your imagination is the only limit.

career development, continued education, personal projects

I’ve spent some time over the past couple of months cleaning up the Rails apps I’ve written with the goal of making them available for download on this site. I wrapped that up last week with the release of Addressbook. However, I soon realized that making the code available on this site was not ideal, and it would be much better if I made the code available via some code hosting site, like Sourceforge or GitHub. This gives the projects a little more visibility, allows for easier contributions to the projects, and simply provides a better home for the code. So, I spent the past few days making Diners Club, Addressbook, and Karate Journal available on GitHub. Please check the project pages on this site for links to the GitHub repositories.

Choosing GitHub was fairly easy. I’ve been wanting to learn Git for a while now, GitHub has all of the features I needed (plus some nice-to-haves), and it seemed pretty straight forward to use. So far so good!

I did however have to do some additional cleanup before the move to GitHub. Previously, I had a bash script that I ran that would export the code from my local Subversion repository, and wipe out any user names, passwords, or other configuration that I didn’t want to publish with the code. The script would then tar and zip up the code, and push it to the site. This wouldn’t fly with GitHub, since everybody would be able to see the code in the repository. So, some work was needed to provide template config files (database.yml.template for example) for people to specify their own configuration, and I removed the original files from source control.

All things considered, I’m very happy with the move, and wish I’d done it sooner. I think from now on, I’ll be using GitHub from the start with new projects.

Merry Christmas everybody!

git, GitHub, personal projects

Yay for me! I set a personal goal to have the code for all of my Rails apps on this site by the end of the year. Tonight, I can check that one off the list. The code for the Addressbook webapp is now available for download. Addressbook was not only my first Rails app, but also my first experience with Ajax. And trust me, it shows. I learned a lot from this project, especially what not to do. However, I must also say that I use Addressbook more than any other personal project I have ever completed. So, it can’t be that bad :) I love the fact that I can access my contact information from anywhere, and that I can manage groups of addresses and print mailing labels with the click of a button. Sure, the UI can be a bit unintuitive, but it’s not that big of an issue for me. There are a few more things I’d like to do with this project. We’ll see where it goes from here.

personal projects, rails, ruby

I finished cleaning up the Karate Journal code, and it is now available here. Two down, one to go. I hope to have the Addressbook webapp code on the site by the end of the year.

personal projects, rails

I finally got around to cleaning up and publishing the code for the Diners Club web application. Like everything else I release, I’m not sure who will actually use it. But, I find that the whole exercise of releasing your code is beneficial to you and your code. So, it’s worth the effort. It’s available via the MIT license, so have at it.

Kind of a funny side note about this project. I recently found out that a couple of co-workers of mine spend some of their spare time working on Planypus, which is a site for making plans with your friends. Sounds familiar! I was talking to them, and it turns out that Planypus started the exact same way that the Diners Club webapp started, as just a way to organize dinner outings with friends. They however took it to the next level and threw a business plan around it. I’m just not that business savvy I guess :)

personal projects, rails, ruby, Software

I’ve just completed the initial release of my second Gnome Do plugin. It’s called TravelAgent. TravelAgent allows you to kick off searches for flights, rental cars, and hotel rooms on select travel agency websites right from Do. To use TravelAgent, you tell Do what you want to search for (flights, cars, or hotels), provide Do a simple search query string (see the plugin’s wiki page for details), and specify which of the supported travel agencies you’d like to use to conduct the search. Do will then open up a web browser, bringing you to the search results page on the travel agency’s website.

Let me just state this right from the start. I have no idea who will use this plugin, or who, if anybody, will find it useful. This is just something I wanted to do. If others find it useful, then that’s great. But, that was not my main motivation. Searching for travel can be complicated, as there are many options to consider. Take flights for example. The number of passengers you’re looking to book a flight for, and the “types” of those passengers (adults, children, seniors, etc) can vary from search to search. The departure time, arrival time, and flight time is often very important to people. Some people only fly certain airlines or certain cabin classes (coach, first class, etc). Trying to sum all of this up into a Do plugin is difficult. Do’s interface is simple…it needs to be. That’s one of the reasons why Do rocks so much. So, using the plugin had to be just as simple. To do that, many assumptions were made about the search being conducted, greatly reducing the flexibility of the search as compared to doing the search right on the travel agency’s website.

So, what is it useful for then? Well, it’s a quick an easy way to do a price check. And if you’re interested in purchasing some travel, then you can always tweak the search right from the search results page, to get it just the way you want it, before continuing down the purchase path.

As for the list of agencies supported, they are all Orbitz Worldwide agencies. All of the agencies are also running our global travel platform, which means I can interact with all of them the same way. The plugin currently works by building a URL, which contains all of the necessary search criteria, and feeding that URL to the web browser. It was the simplest way to get up and running. So, where is Orbitz you ask? Well, Orbitz is still running the classic platform. It does not have pretty URLs, or any other type of publicly available web services that I could use to conduct a search. I could write a screen scraper to get the job done, but that was beyond the scope of this initial 0.1 release. Cheaptickets suffers from the same issue. Soon, we will be rolling some of the other Ebookers agencies onto the new platform. When those sites go on, I will add support for them in the plugin. Orbitz and Cheaptickets are still a ways out, so I may look into scraping those sites for the time being.

So, what’s next for the plugin? Here’s a short list of stuff I’d like to do:

• Add support for additional OWW agencies
• Add support for searching packages (flight + car rental, flight + hotel, flight + car rental + hotel)
• Change the plugin to display the search results in Do, instead of on the agency’s search results page (but still giving the user the option to see the full search results page)
• Add support for pre-configured search options, like cabin class, preferred airline, etc. This would give the user more control over the search, while keeping the search query string simple.

I’m sure more features will come up as time goes on. We’ll see where this heads. If you have any ideas for what you’d like this plugin to be able to do, I’m all ears.

Gnome Do, personal projects, TravelAgent

I just pushed the code for my first Gnome Do plugin. It is a plugin for Confluence, a popular wiki package, and allows you to search your wiki from within Gnome Do. Do will present you with the results, and selecting one of the results will open that page in a web browser.

I want to give a shout out to the Do developers. Because of their very powerful and flexible plugin architecture, writing the plugin was a snap. Very little code was required. I probably spent no more than 10 hours total on this plugin, and the majority of that time was spent learning the plugin architecture, and learning how to install and test my plugin.

The code is currently on its own branch, waiting to be merged with the Gnome Do community plugins branch. If interested, you can currently find the code at https://code.launchpad.net/~john-p-wood/do-plugins/confluence. Eventually, it will be merged to https://code.launchpad.net/~do-plugins/do-plugins/community.

Next up, I’m working on a Do plugin that will interact with the many Orbitz Worldwide travel websites. Stay tuned!

Gnome Do, personal projects

You know that piece of code that you wrote a while back? That webapp that you wrote to help organize some aspect of your life? That library you wrote to abstract away some details of a specific task? Release it! That’s right. Set it free!

One of the reasons I set up this website was to give me a way to “showcase” and release some of the code I had written over the last couple of years. I guess some part of me thought it would be as simple as tarring up the code and throwing it on the site. Well, it turns out it’s not that simple (at least for me), and that’s a good thing.

I’ve found that releasing code forces you to make it better! Over the last couple of days, I’ve found myself adding more test cases, fixing bugs, removing assumptions, bulking up the documentation, and cleaning up the code. In general, now that the code will be out there in the public eye, I want to make sure it represents my best effort. When I write code for my own use, I generally focus on keeping it clean, and making it work. I don’t usually write doc outside of the code. I sometimes make assumptions in the code based on the box that I know will be running the code. I put up with small bugs that don’t really cause that big of a problem. But at the same time, when I use somebody else’s code, I expect more. I expect good doc. I expect that the code doesn’t assume to be running in any specific environment or on any specific setup. I expect those small bugs to be fixed. So, I’ve found myself cleaning up the code to meet my own standards. And, this is great for the code.

Releasing code also engages the community. You never know who may be out there looking for something like what you have created. You could be helping your fellow man by providing a solution to a problem they could be experiencing, perhaps the same problem that prompted you to write the code in the first place. Engaging the community has several other benefits. In true open source fashion, if users feel that your code is missing something, they will often add it. If there are bugs in the code that you missed, sometimes they will get fixed. An increased user base will sometimes serve as a source of innovation. All of these end up making your code better.

So, in short, I’ve found that releasing your code makes it better! So, release that code!

career development, personal projects