The Rails Rumble is an annual programming competition where teams of up to four people will have 48 hours to build an innovative web application in Ruby on Rails. Once the build portion of the competition is over, a two-phase judging process selects the winning entries in several categories. In the first judging phase, a selected panel of experts reviews all qualifying applications to determine the top tier. Once they're finished and the top applications identified, the public judging period begins. The categories of winners include: Grand Prize, Second Prize, Third Prize, Solo, Appearance and User Interface, Originality and Innovation, Usefulness, and Completeness. Thanks to Nick Plante, Darcy Laycock, Erin Shine, and Jeff Rafter who organized this year's event.
The 2009 Rails Rumble Completeness Prize goes to the Hurl application, developed by Chris Wanstrath and Leah Culver.
Chris, what does the Hurl application actually do?
Hurl makes HTTP requests. It's like a Web-based version of Curl. The cool part is you can share requests with other people -- it's a great way to, say, document an API and give people examples to play with.
What tools did you use to build it?
I use Emacs and Safari while Leah uses Coda and Firefox. The app itself is built in Ruby using Sinatra for the web part and Redis for the data storage.
Yes, we didn't use Rails. But the rules say any Rack-based framework is allowed so we chose the best tool for the job.
Other than that we used simplejson to format the json, xmllint to format the xml, Pygments to do the syntax highlighting, and Curb to make the requests.
What was the hard part in building Hurl?
The UI. We knew what we wanted the app to do but not how we wanted it to do it. We spent a lot of time fiddling with the UI and various workflows.
Making a screencast helped a lot because we were able to add in things we thought were missing as we tried to explain the application to someone. It helped us fill in some missing pieces.
What would you have done different?
Redis is an amazing piece of technology, but it's not great for running popular sites on VPSes with a tiny amount of RAM. We need to (sadly) move the backend to something that is disk bound rather than memory bound -- we have much more disk than memory on our Linode slice.
Where do you go with Hurl from here?
We need to rewrite the data storage but other than that we're going to keep it as-is. We plan to open source the app in the near future so anyone can run their own version of Hurl.
For More Rails Rumble 2009