This Week in Rails

Welcome to the first post in a new series which focuses on Ruby and more specifically, Ruby on Rails. My goal is to provide links and a little bit of commentary on interesting blog posts and discussions from the previous week. I have my rss reader pointed to a bunch of Ruby focused blogs, but I'm sure there are things of interest that will slip past me. If you notice something that you think is worth sharing or a blog I seem to be ignoring, please don't hesitate to contact me directly or post in the previous week's discussion.

There are a number of ways I can go with the week in review. I could provide links to a bunch of stuff in the blogosphere or provide just a few links with my own thoughts. Right now I'm leaning towards around five links per week. I could certainly provide more, but I'm worried about inundating people with too much material (a problem I have with my own growing list of rss subscriptions).

While I won't be doing it this week, I would also like to talk about anything I think is noteworthy from the Rails Google Group and possibly write about any interesting commits from the Rails core team. As always, feedback is greatly appreciated.

Without further delay, here's a little roundup of Ruby and Rails related posts from the last seven days.

I couldn't talk about the last week in Rails without mentioning the continuing back and forth blogging of Joel and DHH about Ruby, Rails, performance, and scalability. Joel's latest post about Ruby performance mentions duck typing as a possible source for Ruby's slow speed. I'm not qualified to talk about language implementation reducing the speed of Ruby since that kind of hard core language stuff is still a little beyond me (I'll get to the Dragon book eventually). I can say that I agree with DHH's follow-up post about outsourcing performance intensive functions. He writes about a few specific cases of optimization. The first is from Basecamp, which has Ruby call out to the shell to resize a thumbnail. The second is from Campfire (a web based chat system for teams) in which they rewrote the client polling handler in C.

For me the whole argument dumbs down to a few things. First, I love to program in Ruby. It's fun, it's quick and it helps me just get things done. Second, is that selecting a specific language because you're worried about performance before you even get to coding seems a little like premature optimization. I'd rather get something up and running as quickly as possible and worry about performance on an as needed basis. I think the way of the quick prototype is one of the hallmarks of the Ruby and Rails community. Of course I also buy into the "right tool for the job" argument, but at this point I wouldn't want to write a web application in anything but Rails.

I'm also concerned about Ruby's performance, but with help from the community I think that it's something that can and will be improved over the years to come. If Joel had chosen Ruby as his primary language, perhaps he could have helped the entire Ruby community with improvements to it instead of writing a proprietary compiler for Fogbugz named Wasabi.

Some other interesting things going on include:

On the whole Joel fight -- I

On the whole Joel fight -- I read a great blog post on the difference between efficiency (aka performance) and scalability.