It feels as though, over the past couple of years, the pace at which I have been learning has slowed. This troubles me. One of the reasons I love the software industry is that there is always something new to learn. I love learning about new ways to solve problems with technology. And, learning is what you must continue to do if you are to stay relevant as a software engineer.

Now, this doesn’t mean that I haven’t learned anything over the past couple of years. Quite the contrary actually. I’ve really been enjoying the boom our industry is seeing in non relational data storage systems. We’ve been utilizing many of these newer technologies at Signal with great success. I’ve been an active member of the ChicagoDB users group, attended a few conferences on this topic, and even gave a few talks…a first for me. I’ve also been learning first hand how to scale a system as we’ve taken the Signal application from one capable of sending thousands of messages per “blast” to one that regularly sends millions of messages per “blast”.

However, something is missing. I used to read more. I used to blog more. I used make a sincere effort to learn a new programming language every year. I used to constantly download and tinker with new tools. These things have fallen to the wayside. And, I really miss them.

Instead, over the past couple of years, I have been spending the majority of my time creating. When creating a new project, there is usually something new to learn. That’s what drives me to create the project in the first place. But as time goes on, the cost of the time I spend working on the project starts to outweigh the benefit. I reach a point where I am no longer learning anything while working on the project. If I’m not benefiting from working on the project in any way (now that the learning part has mostly dried up), there is little motivation for me to keep working on it.

Part of me feels obligated to keep these projects going, and to get them to a point that I would consider “done”. I’ve never been a quitter, and stopping work on these projects sounds like quitting to me. However, it makes little sense to continue working on something that gives me nothing in return. I will still fix bugs that are reported, but any new development on most of my active projects is likely going to cease. Time is precious, and I need to make the most of it.

So as of right now, I’m making an adjustment in priorities. I’m using my free time to invest in myself. To read more. To blog more. To get back to learning a new programming language a year (Clojure is on tap for 2012…I’ve been wanting to learn it for 3 years now). To resume downloading and tinkering with tools that spark my curiosity. I want to start practicing how to write code, like I learned at the code retreat I attended over the summer.

I’ll still be creating, as I’m someone who learns by doing, but I have a feeling from now on my projects will be much, much smaller.

It is impossible to “find” time to do something. You have to make time.

One Monday morning about a month ago, I was browsing through open issues in our bug tracker looking for something to work on. It was my week on “technical support”. At Signal, the engineer on technical support spends a week working on non customer facing issues with our infrastructure, process, etc, that are too large to simply knock out as you encounter them.

An issue entitled “Add monitoring to detect jobs that do not start” caught my attention. We already had monitoring in place to alert us when a job fails. However, we had nothing to alert us if that job never starts in the first place. We have many scheduled jobs that run in the background, some pretty important, and have been bitten on more than one occasion by reoccurring jobs that had not run for quite some time.

I bounced some ideas off the team, and we all agreed that that it made sense to create a new application to monitor our scheduled tasks. The app would know what is supposed to run, and when. We would change all of our jobs to “ping” the app when they start and finish. If the app detects that something did not run when it was supposed to, or did not finish when it was supposed to, it could alert the team.

And just like that, Proby was born.

“What’s with the name?”, you ask? I likened the application to a probation officer, keeping an eye on wayward tasks.

Since going live, Proby has caught several issues with our scheduled jobs that would have gone unnoticed…many more than I would have anticipated. It has also evolved into a fairly complete application. It is easy to setup new tasks. It holds onto the execution history of each task, allowing you to see a trend of the run time for each task, and which runs resulted in an alarm. It supports alarms via email or SMS, using Signal’s SMS messaging API. It has several settings that allow you to tweak exactly when an alarm is sent, cutting down on the number of false alarms. And, thanks to designer extraordinaire Drew Myler, it looks amazing!

Shortly after creating Proby, we realized that there is no way we are the only ones who have had scheduled tasks go days without running, unnoticed. So today, we are making Proby available to the general public. It is currently in closed beta, and we are letting people in slowly to flush out any bugs or other issues. Use of Proby is also FREE while it is in beta.

Interested? Head on over to http://probyapp.com/signup and signup to participate in the closed beta! And, don’t forget to follow @probyapp on Twitter for updates!

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.

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!

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 :)

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.

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!

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!