dev derby 2010
This weekend, on September 11, 2010, I took part in the Dev Derby 2010. This was a contest where teams were split up by programming language, and challenged to create as usable and fully functional a program as possible in only six hours. Sadly, some teams, such as Justin Ko’s Team Ruby, were shorthanded. However, the PHP and C# teams put up a good fight.
The challenge was to design a software system that could be used to match non-profit organizations with volunteer groups that offer services that match their needs. There were a number of criteria that we had to meet, such as implementing some external API (most people chose some form of Single Sign On) and implementing all of the required features for the application.
I’m happy to announce that my team, Team Java, won the challenge. More so, our system was the only one that worked end to end.
Some might wonder how we did it: well, I started out doing what I do with everything else - I first identified the best tools for the job. And sometimes those tools aren’t the ones we normally use.
At work, as an enterprise Java developer on Wall Street, I normally use a particular stack of frameworks: Spring, JSF, Hibernate. I think they are the right tools for that job. The usual development cycle involves coding - compiling - deploying the updated code - restarting the server/process/container - relogging in and whatever else to get back to wherever you were - and then, finally, retesting. (Of course, we employ automated test suites as well.)
For the contest, we were building a webapp, and competing against languages like Ruby, Python, and PHP that do not have the compile and deploy stages: it’s simply code - hit refresh and test. Over the long term, for a large project, that’s not a huge advantage, but in a contest that lasts only six hours, that would have killed us.
So our secret weapon was the Play! framework. This is a very easy to use to framework. How easy was it? Well, none of the other six team members had even heard of Play! before the contest. I sent out a document only a week before the challenge describing how to use it and only two people really read it. The rest learned as we coded.
Play! is a very agile framework that is completely stateless and recompiles changes to your codebase transparently - so it erases the advantage that dynamic languages have by not needing a compilation step. In the meantime, we still benefit from the advantages of static typing that Java gives us, protecting us from a large number of time-wasting bugs. Certainly, there are certain types of problem domains that are easier or only possible in dynamic languages (that’s why there are no pure static typed languages: they all offer some way to subvert the type system such as reflection or casting), but for a webapp those problems aren’t applicable.
We were allowed to use libraries that would help us in meeting the coding challenge. Play! has a lot of plugins available for it: we used Search to implement full text search in our filters, and Scaffold to rapidly generate prototype screens.
While not a Play! plugin, we also used the java-facebook-api which was incredibly easy to use when adding Facebook Connect access to the system.
I’m very pleased with how well our use of the Play! framework turned out (even if I’m not entirely pleased with how our CODE turned out: hey, in only six hours, you have to make a few allowances… :) ). It was a fun challenge, and I hope to try again next year. Hopefully the Ruby team will have better luck assembling their team so I can show all the cool kids how you should truly achieve web scale webapps. At least the Zend-spinning PHP geeks got the message. (Luckily for C#, Microsoft was on hand with paid counselors to help them cope with the loss with promises of improvements in Visual Studio 2011 that would make them more competitive… well, not really, but they should have been!)
