Proprietary Software Not Necessarily The Best Software

I’m a big fan of open source software. I use it extensively at home and at work. I’ve also contributed to a few projects here and there. I think that on average, it is usually more secure, more stable, and more extensible than proprietary software. Oh, and it’s usually free too.

I got a little reminder today that proprietary software isn’t necessarily the best software. I recently upgraded to Ubuntu 8.10. The first time booting up into the new version of the OS, a little pop-up notified me that some proprietary drivers were available for my graphics adapter. Sweet, I thought. Maybe now I can finally enable Compiz on my work laptop. The driver installed without a problem, and sure enough, most features of Compiz worked without an issue. However, over time I noticed Compiz was slowing things down a bit (it’s an older laptop, with an older graphics adapter), so I disabled it.

Today, I was scheduled to give a presentation to a small group of peers at work. I arrived on time, hooked up my laptop to the projector like I’ve done a hundred times before, and hit the magical key sequence to change the resolution and output to the projector. Nothing. I tried again and again, even rebooting. Nothing. Fifteen minutes after the presentation should have started, I finally bit the bullet and booted into Windows to give the presentation…something I have only done one other time since putting Ubuntu on my work laptop. Man I was pissed, especially since it took Windows forever to boot…reminding me why I switched to Ubuntu in the first place.

This worked fine in version 8.04. What the heck happened?

When I got back to my desk, I did some searching on the web, and found some forum threads indicating that a proprietary video driver could be the cause of such an issue. Remembering I had enabled the proprietary video driver, I quickly disabled it, hooked up to a projector, and tried again. Bingo! Worked like a charm. As a side benefit, I also got the dual-monitor support that had been advertised in the newest version of Ubuntu. Up until now, I couldn’t get that to work either.

So, the moral of the story is, just because it’s proprietary doesn’t always mean it’s better.

Karate Journal Webapp Has Been Released

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.

The Google Chart API

At work last week, I spent some time helping to write a small tool that would performance and capacity test our applications. We thought it would be great if at the end of the test run, the tool would generate a series of graphs to display the trends of certain key metrics over the course of the test. A quick search of the web for charting tools lead me to the Google Chart API.

The Google Chart API is a very slick tool for generating all sorts of graphs. You build the graphs by specifying all of the data for the graph, the graph type, and the graph metadata in the URL. The URLs get a little nasty, but in all fairness, there is a ton of information being conveyed in the URL. So, it’s going to be nasty no matter what you do.

My only concern was relying on an external web service to generate the graphs. Since this is just a development tool, it wouldn’t be the end of the world if the Google Chart API went away. We would simply adjust the tool to use some other graphing library. And, as for all of the old charts from previous runs…we wouldn’t want all of those graphs simply “disappearing”. So, instead of using the Google Chart API URL directly in the reports, I do a wget on the URL, and store the image on my file system. I then reference that local image in the reports.

All in all, the Google Chart API is a very slick, easy to use tool. I’d recommend checking it out next time you need to quickly throw together some graphs.

Falling in Love with DSLs

We were recently given a free day at work to hack on a project that was outside the realm of our normal responsibilities, yet could still be beneficial to the company. We were encouraged to be creative, explore ideas that interested us, and see if we could come up with something to demo at the end of the day.

Service level testing, or functional testing, has been a hot topic at work recently. It’s no secret that we have a very large SOA at Orbitz, powered by Jini. Services, calling services, calling services…you get the picture. Historically, we have not been the best at automating the testing of these services. That is beginning to change. About two years ago, the team I work on developed a test tool that allows us to interact with our services at a very high level, keeping us out of the nitty-gritty details when invoking a service. It’s a command line based tool with a very simple, intuitive syntax. All of the details are accessible if we need them, but more often than not they just get in the way. In fact, we enjoyed working at this level of abstraction so much, that I wrote a functional test framework (named jwoodunit by my co-workers) that drove service level tests against our services, which were written in this same “language”. It allowed us to pump out service level tests is very short order that were easy to read, and easy to maintain. It has only just occurred to me that what we had created was really a Domain Specific Language (DSL).

We have a fairly large quality assurance team that is made up mostly non-developers. Most of the testing that is done is manual, or driven by an automation tool similar to Selenium. The problem is that the manual testing is slow and not reliable, and tools like Selenium tend to be brittle, since they are based on the layout of the HTML page. It also prevents you from testing any service that is not directly accessible through the web application. So, for my project, I wanted to see if I could take my team’s DSL, clean it up even more (it is still very “programmy”), and give it to our quality assurance team so that they could test our services in a more reliable fashion.

What I ended up with was a very high level, English like DSL that I call Trastel (Travel Service Testing Language). Trastel is implemented in Ruby. In fact, it’s safe to say that Trastel is Ruby. I didn’t implement a new language. I simply took advantage of Ruby’s fantastic meta programming capabilities to extend the language with functionality that is needed by the tests. A example test is worth 1000 words:

search.flights.on("orbitz").where(
   :origin => "ORD",
   :destination => "LAX",
   :departure_date => "2008/12/10",
   :return_date => "2008/12/15"
)

verify_at_least_one_result

foreach_result do
  verify_equal "ORD", origin
end

This does exactly what you’d expect. It searches flights on Orbitz, flying from Chicago’s O’Hare airport to Los Angeles International Airport on 2008/12/10, returning on 2008/12/15. We then verify at least one result came back, and that the origin of each flight is O’Hare. That’s it.

Implementing this test in Ruby was a breeze. Since everything is an object in Ruby, dynamically adding methods to the Object class gives us the ability to create pseudo-keywords, like “search”, and “foreach_result”. Trastel also sets an attribute named @response on the test, so the code that implements the verify methods can just check that, instead of having to specify that your checking the response of the service call. foreach_result will iterate over the @response if it is an array, yielding to the specified code block for each item in that array…giving us an easy way to check each element. The last bit of magic surrounds the “origin” method. “origin” isn’t a method on object. It’s a method on the the type contained in the @response. Thanks to Ruby’s method_missing method, I can forward that method call onto the object in the @response for it to tell me what origin means. Nice and easy.

Another great thing about Trastel is that it sucks in Active Support. Active Support brings with it a wealth of extensions to the core ruby classes, letting us do something like this:

search.flights.on("orbitz").where(
   :origin => "ORD",
   :destination => "LAX",
   :departure_date => 4.weeks.from_now,
   :return_date => 6.weeks.from_now
)

We still do all of the heavy lifting (creation of the service request, execution of the remote service, etc) in Java, using JRuby to get the Ruby code to play nice with the Java code. But, the DSL serves as an excellent means to collect the data needed to drive the test, call the Java code to invoke the service with that data, and verify the data in the response matches what was expected. It successfully keeps the person writing the test from having to know anything about actually invoking the service. Writing tests at this level of abstraction also shields us from the majority of service API changes that may come our way.

With all of the benefits that I can already see with this still very immature DSL, I’m kicking myself for not considering DSLs more seriously in the past. They have been around quite some time, and have had many well know developers singing their praises. I’m looking to see what other problems I’m currently facing that could be solved a little easier by letting me code a little closer to the domain. Had I know that it would be this simple, maybe I would have tried it a long time ago.

Diners Club Webapp Has Been Released

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