FiveRuns Blog

Welcome to this week’s edition of Rails TakeFive, our ongoing interview series of insight and commentary from notable members of the Ruby and Rails community. This week, we’re happy to welcome Jacques Crocker, a Rails developer from Palo Alto and the man behind RailsJedi.com.

FiveRuns: Welcome Jacques, and thanks for joining us! Let’s kick it off by talking a bit about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Jacques Crocker: Rails 2.1 was an amazing point release. One of my biggest pain points for a long time has been gem dependencies. 99% of all my Capistrano deployment failures up until recently were because one gem or another was installed on my local machine but not on the server. In fact, I was halfway done writing my own little gem dependency management plugin that was in use on several of my sites before I saw the edge Rails announcement and subsequently ripped out all traces of my version of the code.

Also, named_scope was a very nice addition to the core. I was already using the excellent scope_out plugin on all my projects, however it had some quirks that have all been smoothed out after switching over to named_scope.

The most immediate need I see for the next release of Rails is to be able to split up large rails projects into separate projects that can easily share code. As soon as any Rails project gets up to 25-30 controllers, it starts to lose a lot of the fun it had when it was 5-6 controllers. But if your Rails project was instead maybe 4 independent but related applications, each with 5-6 controllers then I think development would be a lot more enjoyable for large projects. The trick is allowing these projects to reuse common functionality without becoming too interconnected so they can be swapped out and shared easily. Rails Core needs to address this if they want to take on the real scalability problem, that is scaling a large code-base.

I’d also love for them to ditch migrations altogether and integrate PJ’s auto_migrations plugin.

FiveRuns: You’ve recently written about Phusion Passenger. Tell us a little about your experiences with it so far.

Jacques Crocker: Yep, I’ve been using mod_rails extensively since RailsConf. Given the meager amounts of memory most virtual servers provide, I see Phusion Passenger as a massive benefit since you no longer have to worry about running X numbers of mongrels, and can rely on Passenger to scale up and down as needed. In addition, the use of Enterprise Ruby has decreased memory usage on my servers fairly dramatically (20-30%).

Deployments with Passenger have been a big improvement over the old mongrel/nginx process. It cut my Capistrano config in half, as I used to have all the nginx load balancing config, and mongrel setup as part of my deploy.rb. Now it’s just a simple git update, gem install, migration, and server restart. I’m even exploring the possibility of running any pending migrations automatically as part of the application initializer.

I’m also really excited about the Rack support, giving us an easy way to deploy other Ruby frameworks (like Merb). Rails 2.2 should bring Rack compatibility as well. That should enable a consistent deployment platform for all Ruby web frameworks.

FiveRuns: On that note, let’s talk about Merb – they are all about being agnostic—ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails, say, for processing?

Jacques Crocker: I think Merb is a natural response to some of the wrong choices the Ruby on Rails team made in picking libraries to promote. While Rails initially got me into Prototype and Scriptaculous, I quickly grew frustrated with the framework and made the switch to JQuery. In fact, every time I fork my base Rails project, by default it has JQuery for Javascript, HAML for views, and Sass for stylesheets. I have a suspicion that within a year, it might also include DataMapper as a replacement for ActiveRecord.

I was extremely happy to see that Merb decided to implement “slices”, which is similar to Rails Engines, a hugely mistreated Rails plugin. Engines could have been revolutionary had it been encouraged and integrated by the Rails Core. I’m hoping that merb-slices will demonstrate to the Rails Core team that pluggable, self-contained apps are really the only way we’ll be able to manage our applications’ rapidly growing complexity.

The whole “thread-safe” concern, for me, has been rendered mostly irrelevent. With Mongrel clusters (and now Passenger), the core threading issues have been fairly easy to work around. As for mixing Merb and Rails on the same application, it’s probably a bad idea. If you need an alternative for some fast processing alongside Rails, Sinatra would be an even lighter, faster alternative.

FiveRuns: Beyond Merb, you mentioned Sinatra, but there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Ramaze, Camping, ... What have you seen so far that you really like? Dislike?

Jacques Crocker: After Erik Kastner’s excellent session at RailsConf this year, I starting using Sinatra on some toy projects and have been impressed with it.

Just being able to create all your controller actions in one file is great for small projects, as you don’t have to explore your project directories whenever you need to find something. Plus I love the fact that I can still use HAML and Sass, which drastically reduces the size of the HTML and CSS needed in the view.

The major downside of course is the lack of Rails plugins, which can save a lot of time implementing complex features like tagging and S3 file uploads and can be extremely time saving for even really small projects. However I think the Sinatra community is growing fast and will eventually have stable ports of all the most popular Rails plugins.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. Obie has written about ultra-productivity, but we have to ask – what are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Jacques Crocker: Obie has been a huge inspiration for me. I’ve been involved in rapid startup bootstrapping for a few years now, and it was great to see Hashrocket succeed in delivering rapid development projects as a packaged service.

I took part in last year’s Rails Rumble (building PubBud) and I think the capability is there for anyone to be able to build a significant web application in a few days time, given the right vision and tools. This year there are going to be way more teams, and a lot of excitement as people have been getting much better at building Rails apps fast. I’m looking forward to competing again.

The single best tip I can offer for “ultra-productivity” is to create and continuously improve upon your own Rails new project skeleton. In that skeleton app, collect all the most useful rails plugins, stabilize them, and make them your own. Add in base stylesheets and ui components (I use blueprint) so the views don’t slow you down. Also add in common helper methods that you frequently use.

They key is to use this skeleton often, that is use it to create a new web app. I try to start a new Rails project from my base project at least once a week. Most of the time I leave it after hacking for 3-4 hours, but each time I end up improving on the base project and extracting pieces of functionality into my asset library.

This was one of the ways I was able to implement OpenSourceRails in a single weekend. All the major features – file uploads, tagging, bookmarking, ratings – were stuff I’ve implemented before and were part of my library. Having a collection of tried and true pieces of functionality along with a well structured and familiar base project will be a big time saver on any new project.

Jacques Crocker is a Rails developer from Palo Alto and blogs at RailsJedi.com. He also runs OpenSourceRails.com, a gallery for open source ruby on rails web apps.