Friday and Saturday, I attended the first Ruby Hoedown at RedHat HQ in Raleigh, NC. The Hoedown was one of many regional Ruby conferences popping up all over the place driven in small part by Ruby Central’s conference grant. Nathaniel and Jeremy did an excellent job putting the conference together. It was flawlessly executed with an exciting program and a good dose of southern charm.
Here’s a braindump:
The conference pre-started with me, Bruce Tate, and Marcel Molina giving a two and a half hour testing workshop for charity. Taking a queue from the Dave and Mike’s Rails Guidebook, participants gave a donation ($50 recommended) to attend the workshop. We ultimately raised roughly $3200 for the Food Bank of Central and Eastern North Carolina. A large portion of the workshop consisted of me and Marcel interactively improvising the development of an application in test-first style while drawing the questions, comments, and criticism of the audience. The format worked well (from our perspective), and we covered a lot of great material. We’re really looking forward to our FULL DAY testing workshop for charity at RailsConf Europe in Berlin next month. (Next month’s workshop goes to support Habitat for Humanity. We’re happily accepting donations regardless of whether you attend.)
The main conference kicked off with a talk from Ezra Zygmuntowicz about Merb. Merb started out as a complement to Rails—-something you whip out when you need multi-threaded request processing, such as big file uploads and long-running application logic. Rails isn’t always well suited to this sort of thing, because Rails is single threaded. To scale, you have to add more processes, which adds a potentially unhealthy amount of memory overhead. Merb is a multithreaded, lighter weight Mongrel-bound (for now) framework.
Now, however, Merb is turning into a full-blown Rails clone (Actionpack clone really). I remain fully skeptical. I understand Ezra’s stated reasons for doing it (along with a few implicit ones I think), but I think we already have a Rails, and incremental improvements are, well, incremental. It would be nice to see someone taking a leap as opposed to a step. Even before Rails came out, I think the industry had seen enough MVC. I am hopeful that some of Ezra’s improvements make it back into Rails. His desire to keep things lean and unmagical is commendable.
Next up was Jay Phillips, whose Adhearsion framework for VOIP applications completely blew me away. Adhearsion is a perfect example of someone taking a powerful domain with a historically ridiculous development model and taking a full evolutionary step forward. Jay’s framework takes developers from what literally looks like the dark ages (have you seen an Asterisk dial plan?) to a beautiful and powerful API with modern automation wrapped around it.
We Rubyists have been looking for another killer app following Rails. Adhearsion might be it. Seeing Jay speak made me realize that we have that same combination of disdain with the current state of affairs, courage to slap the (telecom development) industry in the face, intelligence to innovate a solution which brings programmer joy and the people skills and marketing sensibility to push it over the edge. If you care about Ruby, watch Adhearsion closely.
The day closed with Bruce Tate giving a keynote on the direction of Ruby. He drew some interesting parallels to past technologies and also led us through a series of scenarios about where Ruby and its community might be headed. The most convincing one can be summarized as using Ruby to build elegant APIs on top of existing problems which do for those problems what Rails did for web development. See Adhearsion.
Andrea O. K. Wright from Chariot Solutions gave a surprisingly thorough and engaging talk which ended up being a survey of the various game libraries available for Ruby. I’m an avid gamer and got interested in computer programming because I wanted to be a game developer, so I’ve taken this tour myself a few times. But it’s been a while and I was simply amazed at how far things have come. As Andrea spoke, I downloaded literally every library she was discussing and tried them out. I had some problems with the SDL bindings on my Mac, but I had instant success with both Gosu and Shattered Ruby. I’m not sure if we’re ready for Unreal Tournament-style games in Ruby but simple games are finally, well…simple to create. Definitely check out Gosu if you even have a passing interest. Really fun.
There were a series of quick lightning talks. They were good, but there were too many to enumerate. I’m liking this format more and more every time I experience it.
During lunch Jeff Casimir and I organized a “BoF” (I hate that term) on Ruby for Social Change. Jeff booked the smallest spot, thinking we were going to be a tiny crowd, but we ended up cramming a large group into the room. The discussion was lively and loud and the people were passionate. With only 45 minutes to talk, we came out of the meeting with some ideas about organizing volunteers to give their time to produce real applications for non-profits/charities who could use the projects to make impactful change. More on this soon I hope. We have a RubyForge project set up for the group.
If you’re interested in this topic and interested in helping to shape what we do, please do drop in and sign up for the mailing list once it’s activated. The first order of business (in parallel to doing things like setting up a web site) is to find a project with a real customer to rally around. If you have ideas, we’d love to hear them.
I was skeptical because of the title of this talk, but I trusted that Ken Auer was going to deliver something interesting, and my skepticism turned out to be ill-founded. Ken is an old Smalltalker and one of the leaders in both the patterns and agile movements. His talk was a well-thought-out history of Smalltalk and ultimately a comparison to Ruby’s adoption curve. I won’t do this one justice with a summary, but I recommend watching it when the conference videos go live on the Confreaks web site.
Jared Richardson gave a really engaging and fun talk on extending Ruby with C. It was review for me, but the audience was totally into it, and 2 out of 6 people who Nathaniel asked to tell one thing they were excited about learning at the end of the conferenced cited material from Jared’s talk. It’s easy to forget how elegant and human-friendly Ruby’s C API is. If you’re the kind of person who has a natural aversion to that kind of thing and have been avoiding it, you really should take a Saturday morning to crack open the Pick Axe and go through some of the C extension examples. I think you’ll be pleasantly surprised. Lots of potential gain for not much pain.
I’m not going to say much about this, because I hope to take this topic into a separate post, but Marcel’s ideas from this talk have already changed the way I think about my own code as I write it. Those that know Marcel and have worked with him know that he is obsessed with keeping code beautiful. Whether it’s a shell script, a systems programming task, or a high level API, he creates some of the most consistently beautiful code you’ll see in Ruby-land. In this talk, Marcel decided to take this passion for beauty and try to more clearly define the elements that make code beautiful. The result is a small but useful framework for measuring trade-offs when developing software. I’m looking forward to seeing these ideas develop. The keynote itself was short but the Q&A and discussion about it expanded such that Nathaniel ultimately had to cut it off. Obviously a topic that inspired much passion.
This time literally. We took a group to a nearby hotel and played Werewolf until around midnight. If you don’t know Werewolf, you owe it to yourself to try it. We played 5 nights straight at RailsConf this year, and I feel like some lasting bonds were made with people who I might not have even met otherwise. I think our community is too cliquey and fragmented sometimes, and Werewolf is a powerful tool (yes I’m talking about a game and saying “powerful”) for changing that.
We’ll be trying to put together a game again in a couple of weeks at The Rails Edge in Chicago. If you’re coming to the Rails Edge, read up on the rules before-hand and join in. If you’re not yet signed up it’s not too late.
Thanks to last night’s players and my (some-of-them) new friends Lyle Johnson, Tony Devlin, Jim Meyers, Chris Redinger, Evan Light, Devin Mullins, Carl Youngblood, Coby Randquist, Joe Martinez, Rick DeNatale, Ted Behling, Ryan Daigle, and Marcel. I hope to see you guys around soon.

If you’re in the South, I highly recommend watching for an announce of the second Ruby Hoedown. Until then, keep your eyes glued to RubyConf.
Sorry, comments are closed for this article.
August 13th, 2007 at 05:11 PM
I had a good time at the conference, and I agree it was well organized and run.
I hope you don’t mind me offering a suggestion about improving the testing workshop. Although it can be fun to have a format where you’re literally thinking of the content as you go, I think the audience may be served better by having the presenters pre-think a bit more.
The pace suffered at times, and there was more repetition than necessary. I think we may have covered more if it wasn’t so “live” and still had time for questions and exploring alternatives.
Having said that, it was of course awesome that we raised $3,200 for the food bank, and it was encouraging to see the interest in such an event both by the presenters and the attendees, so thanks for that.
August 13th, 2007 at 10:24 PM
Brian, of course we don’t mind suggestions. We went back and forth between doing canned content and live coding and ultimately (obviously) settled on live coding. I think what we’re going to do for next time is to come up with a script but still keep ourselves in the editor. I’m still convinced that walking through the process live is the right way to uncover the motivations behind various aspects of TDD, but I agree that a bit more structure can improve the flow and help us cover more ground. We’re going to do the workshop again in Europe but this time for a whole day. We’re going to keep refining it.
That being said, I think it worked pretty well for a large portion of people as well. Different people enjoy different styles and paces, naturally.
August 15th, 2007 at 06:11 PM
Nerd alert! Nerd Alert! Just kidding. I’ve been DMing an D&D game for the last 2 years, so I can’t talk. I’ve never played Werewolf before. I looked it up and it sounds like fun.
August 16th, 2007 at 02:44 AM
I’ll put in a vote for the live coding approach. It felt more engaging and caused me to consider decisions that were being made and whether or not I agreed with them … which made the whole thing stick for me far more than a canned presentation would have.
Must have worked; I spent my spare time over the next two days (okay, not all of it as the above picture proves, though I was sorely tempted to pop open the laptop after my various gory deaths ;) spec’g and writing tests for a new app I’d been noodling. Just finished the model on it today and got the immense satisfaction of:
128 tests, 614 assertions, 0 failures, 0 errors
I haven’t achieved Chad’s goal of 99.3% coverage yet, though. I’m working on it. ;]
August 29th, 2007 at 08:23 AM
Just finished watching the webcast of Marcel’s “What Makes Code Beautiful” session and he mentioned that you’d written a Facebook library. Any plans on releasing it? I rolled my own brief library (http://pushrod.wordpress.com/2007/08/15/the-how-and-why-of-my-streamlined-rails-facebook-library/) because I had problems with the main existing library (not least, no tests).
I’m relatively happy with it, and its working in production, but would love to see your library if you’re OK about showing it off—I’m sure there’s much for me to learn there
September 1st, 2007 at 02:34 PM
Hi Chris T. Please do check out Facebooker (http://facebooker.rubyforge.org). We haven’t done a full release yet, but the code is pretty much feature-complete and is very well tested. I’d love your feedback!
September 3rd, 2007 at 08:07 AM
Wow, that’s quite some library. I’ve not had time to fully go through it (just had a quick read of the tests, and a skim of the main classes), but I’m interested that you took the concrete classes approach rather than just wrapping the Facebook API (I did it using method_missing).
I wonder if there’s perhaps a danger there, both from changes in the Facebook API (I suspect they won’t give the notice that, say, Amazon will of API version deprecation), and from the fact that users need to understand a slightly different API from Facebook (and therefore will need to rely upon the community using this library rather than the wider Facebook community).
Like I said, I haven’t had chance to properly look through it, and I may change my mind, and it certainly looks pretty solid, not least because of the weight (and the nature) of the tests.