At Linden Lab, we took a brief look at Ruby in 2006. Some Rails code had snuck into deployment and as we were digging into refactoring back end communications, Ruby and Rails came up as an option. At the time, I remember thinking that Ruby had a comfortable syntax and was as easy as Perl for whipping out quick-and-dirty tasks. Early performance testing was not encouraging and that first production piece of Rails code had issues, however, so Ruby and Rails got lumped together in the collective Linden hive mind as Bad Technology™.
Thus, when Peter decided we were going to build on Ruby and Rails, it gave me pause. Of course, since Peter was going to run engineering, it was his call. Plus, James Currier and his team at Ooga Labs were happy building on it.
So, Ruby it was.
The last six months at EMI have been a blur of learning the music business, adapting to working within a large company, and building a technology team. In making initial hires, I realized that my lack of Ruby expertise was hurting my ability to interview candidates. I had been through the pickaxe book, and various bits of data analysis code had moved from Perl to Ruby, but I hadn’t built anything of substance. So, over the holidays I took on a chunkier side project. Details to come in a later post, but in building it a bunch of useful Ruby lessons emerged.
First, if you know other programming languages and want to bump your brain into Ruby context, read Design Patterns in Ruby
Second, embrace behavior driven development, rspec, and rcov. BDD takes things a step up from unit testing. If you’re an old time C coder, you probably are used to whipping your design out in broad comments and then coding the elements in. BDD changes this from writing comments to writing user stories and then your unit tests as you go. Hard to describe how addictive this style of coding is until you’ve done it, but it explains the evangelical nature of its adopters because it’s fun! At a mental impasse? Write a few more stories. Haven’t had your first cup of coffee yet? Sketch in the class structure to pass early tests and add a few more stories. A few minutes before the end of the day? Bump your code coverage to 100% on a file that currently is at 70%. Note that none of this applies universally to Ruby, nor did Ruby invent any of this. What Ruby does give you is a fairly easy to install and use framework of tools.
Third, if you’re on a Mac, use Growl and ZenTest and then configure reporting. What this does is to automatically rerun your tests every time you change a file and then report the results via growl. You can even have the Doom marine tell you how you’re doing! It’s all about reducing the development process to small, bite-sized chunks, with the added hook of continuous feedback.
Fourth, I’ve already talked about git and github for source code control. Having lived in the CVS/Subversion world for so long, git continues to impress. Super fast, flexible, and integrates well with TextMate.
Finally, we’ve started having movie time at lunch and watching the Pragmatic Programmers series on Metaprogramming. Very useful, without the “look how clever my code is” aspect that seems to permeate a lot of the online discussions.