So I’m just now able to take a few minutes to reflect on my experiences at the past weekend’s Ruby Hoedown in Raleigh, NC. Nathaniel Talbott and Jeremy McAnally did an outstanding job putting together the first in what I hope will be a long series of Ruby-focused events in the southeastern United States.

Rather than recap the entire conference (which has been done elsewhere by more prolific writers than yours truly), I would rather focus on four things I picked up over the 2-day conference.

Stubbing out Ruby’s Time class

The pre-conference kicked off with a 2.5 hour workshop run by Bruce Tate, Marcel Molina Jr. and Chad Fowler. Chad, in particular, has been very vocal lately about the importance of developers (and particularly Ruby/Rails developers) giving back to the world. The workshop itself was a fundraising vehicle for the Food Bank of Eastern & Central North Carolina, with 100% of the workshop registration fee being donated. This is an interesting new model, and I’m curious to see where it’s going to lead in the future.

So, one of the things I encounter frequently in my classes is needing to test time-specific behavior. Previously, I had been instantiating a plethora of instance variables to check edge cases for Date and Time processing in my tests. My first “a-ha!” moment of the weekend came during Bruce Tate’s presentation, when he put up the following code snippet:

Time.stubs(now).returns(groundhog_day_at_noon)

This is going to make a world of difference for me, because now I can create insular, repeatable tests regardless of the time of day at which the test is run.

VOIP has become accessible

Jay Phillips became a new hero of mine when he showed off his Ruby-based Dialplan using the Adhearsion library. After showing us a multi-thousand line Dialplan written in an obscure, telecom dialect, he switched back to his slides and showed us the equivalent code, written in near-human readable Ruby. VOIP has been one of those technologies that I wasn’t really paying much attention to, but now my mind is spinning out a whole host of new telephony-enabled website applications faster than I can manage to write them down.

Driving return traffic to a website is a huge deal. Once they sign up for the account, what’s the hook that keeps them coming back over and over again? What if Your Garage Online could CALL you to tell you your car was due for service, instead of simply sending you an email? Powerful stuff.

It’s time to crack open those dusty C books again

Jared Richardson (who shares my agony of constantly being called “Jerry”) gave an energetic talk on using Ruby’s C extensions to speed up application performance. I had heard Jared speak back in January at the Rails Edge conference in Reston, VA, on Rails performance and how the search engine Cha-Cha was using Rails in an optimized fashion. This time, in between launching small boxes of candy at unsuspecting audience members, he gave us a great overview of the various methods to include C code to handle low-level, no-magic-required operations directly with our Ruby code. I actually coded along with his his presentation, and wrote more C code in 45 minutes than I’d written in the past 10 years combined.

In particular, RubyInline looks to be an incredibly useful library to write C code directly inside a Ruby class, and have it generated as needed. One caveat, which is particularly visible in the Rails spectrum, is that RubyInline’s performance gains are only really visible AFTER the class has been run once and the C code compiled and cached. So, for Rails development, classes which use RubyInline should be housed in #{RAILS_ROOT}/lib, rather than directly in a model or controller, to avoid the code being recompiled on EVERY load.

The Germ of an Idea

This isn’t directly something I learned at Ruby Hoedown, but more a general idea that I’d be curious to explore in the future. I’ve recently picked up Joe Armstrong’s Programming Erlang from the Pragmatic Bookshelf. One of the most oft-repeated themes of the conference was concerns about Ruby’s performance. If we eschew the idea that everything related to Ruby has to be written in Ruby (and I can thank Jared Richardson for this new mind-set), what if a version of the Ruby VM could be written in Erlang, to execute high performance Ruby in a multi-core environment?

I was sitting next to Brenton Leanhardt on Saturday, who happens to be another member of ErloungeRDU. We talked the idea over for a few minutes, and concluded that while neither of us had any solid idea how to write a Virtual Machine, the idea itself could be worth exploring. This may be a subject I return to in the future…