FiveRuns Blog

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Jamie van Dyke is in the house. Jamie recently left Engine Yard and is now CTO at Parfait—“The Ruby Agency”. He’s been a Rails developer since 2005, he’s a Rails Core Contributor, and has developed multiple open source projects.

FiveRuns: Welcome, Jamie! Thanks for taking the time to share your thoughts. Let’s start by talking a bit about Rails 2.1. What about the new release excites you the most – time zones? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Jamie van Dyke: Coming from Engine Yard, I’ve seen some tragedies when it comes to application optimisation, I would have to say that the caching improvements are a welcome addition. The ability to seamlessly cache into a memory store and at any point flip it over to memcached with a simple configuration change, removes any excuse for not using it in your application. Although this answers the question, I’d also like to point out that the threading support and internationalisation is a big bonus too. The spaghetti i18n applications I’ve had to deal with in the past will benefit greatly from the built-in support.

However, it’s hard to pick a clear winner that I’m looking forward to, thread safety is a good step in the right direction, as well the changes to ActiveRecord that ease our every day lives. For example, bundle up named_scope with nesting mass model assignment, and a chunk of my code is cleaner immediately.

What I’m trying to say is, I guess, there’s no clear winner in my eyes. It’s the collected improvements that impress me.

FiveRuns: Spurred on by the recently announced Ruby Hero Awards, who is your own personal Ruby hero, and why?

Jamie van Dyke: Personally my Ruby Hero would be Rick Olson. Although he’s directly involved in Ruby on Rails, I think through the myriad of plugins that he contributed and the style in which he wrote them, he’s given a huge amount of time to the Ruby community through plugins and multiple open source projects, he’s shown how good code should be written. He’s also got a humble personality and plays a mean drum set on Rock Band! It has to be said that Jamis Buck could also be my choice though, as his work has been stellar in easing my day to day work in deploying and server scripting. Nice job, Jamis.

FiveRuns: We’ve blogged a little bit about this recently, but do you have any experience that you can share from playing around with Phusion Passenger?

Jamie van Dyke: I’ve personally been an Nginx and Mongrel deployer since the early days, and being an App Support Manager at Engine Yard for over a year I used the same there. However, since starting Parfait I’ve decided to try out Apache again with Phusion Passenger and I have to say my experience has been a positive one. Deploying with Capistrano was a simple Capistrano change, as you don’t ask Passenger to restart directly you merely place a file on the server in a specific location and Apache knows to give it a kick. It’s quick and simple, no need to worry about the mongrel cluster proxy that I’m used to, so monitoring is easier than the Monit battle that you can get into with mongrel.

As for best practise deployments, it’s got to be Capistrano all the way. Versioning of releases with git scm support for the application, is quick, safe and painless. Migrations are a non-issue if you’re using Capistrano, the long deploy task handles bringing the site down during the migration and bringing it back up afterwards. So altogether it’s been a smooth transition, I’m impressed so far, only time will tell whether I change my mind.

FiveRuns: Beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

Jamie van Dyke: Well, Merb is the real one I’m watching. I haven’t had any experience with any of the alternative frameworks on a work basis, only playing around to see what they’re capable of and the ease of use. They each have a definite place in the marketplace, each focus on different aspects of the web and what is needed.

I particularly like some of the concepts of the Mack Framework, specifically the distributed application idea. Allowing applications to share more than just RESTful resources opens up new possibilities in areas like intranet development, where different departments are responsible for their own functionality but with a shared base layer. I’ll be keeping my eye on that one, for sure. As well as Merb, of course.

FiveRuns: Along those lines, tell us a little more about what you think of Merb – they are all about being agnostic – ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean to you? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails?

Jamie van Dyke: Rails is a very opinionated framework. Opinionated in the sense that it chooses tools for you and expects you to use them. That’s all well and good if you like them, but if you prefer a different method of doing something then it’s a matter of overriding the internals of Rails and creating a fragile work environment. Nobody likes to update Rails and find the plugin they’ve been using and rely on, doesn’t work. Personally I prefer testing using Behavioural Driven Development, specifically with RSpec. For this I have to use plugins in Rails to override the default Test Unit that it assumes I should use. This is exactly what Merb solves. Merb doesn’t assume you want any particular testing framework, it allows me to choose. The same goes for the templating language and javascript etc. It’s nice to have the flexibility to choose what suits me best, rather than the framework developer.

Merb is thread-safe, you say? Indeed it is, and is there promise of it working alongside Rails? Indeed there is. In fact, at Engine Yard we had many customers who used it alongside their Rails application. Most of the time it was to solve the problem of file uploads, which in Rails lock the entire thread. This means that when you have 3 mongrels running Rails and 3 users decide to upload large files at the same time, everyone else visiting the site is put in a queue waiting for the file upload to complete. Merb solves this by doing file uploads in a separate thread, allowing other requests to continue. There are many other uses for thread safety, like long running processes that need to be spawned off by the web interface on demand.

I think there will always be room for Merb alongside Rails, not just for the reasons I’ve mentioned but because of the smaller memory footprint, speed at which it handles requests and more.

Jamie van Dyke is the CTO at Parfait, “The Ruby Agency”. He’s been developing in Ruby on Rails since the beginning of 2005 and web development in general since 1996. He is a Rails Core Contributor and developer of multiple open source projects. After being an Application Support Manager at Engine Yard for over a year, he is now taking that experience into the Ruby training, head hunting and consultancy market.