I attended the Rails Underground conference in London at the weekend (July 24-25, 2009). As always seems to be the case at these events, I got the most value out of the more theoretical and opinion-based talks rather than 'how-to' style presentations. Having said that, Pat Allan and George Palmer gave great talks on their respective thinking_sphinx and couch_foo plugins.

I'm going to concentrate on the keynotes from the two days, which give quite differing perspectives.

Fred George - Rails is a hammer. Not everything is a nail.

In the keynote (video link) for the first day, former Thoughtworker, Fred George warned us against using Rails for the wrong kinds of projects.  He started off by discussing how frameworks like Rails let you get started quickly but become harder to manage as the complexity of your problem increases.

The rest of the talk consisted of Fred explaining the architecture of a project for which he decided to roll his own framework with only the parts he needed.  Fred explained that he wasn't a fan of using SQL-based traditional relational databases, as it can force your object model into an unnatural form that might not suit your problem domain. Fred's project consisted of a HAML/SASS front-end with Sinatra and pure-Ruby models persisting data to YAML files.  The problem I have with this kind of approach is that by relying on a disparate set of technologies you run the risk of one or more component becoming obsolete over time.

As a couple of people in the audience mentioned afterwards, Fred didn't really give an exhaustive comparison of Rails versus the alternatives, as he was basically just describing one particular application that he'd written. The basic message that I got from the talk was that if your domain model fits well with a relational database structure, then traditional MVC with Rails is a good fit (e.g. administering users).  However, a service that just exposes the DB structure and its contents isn't adding much value (i.e. REST/CRUD on a set of tables).  To add value you need to design the models intelligently.

Yehuda Katz - the future is granular

Yehuda Katz gave the keynote (video link) for day two, about how Rails is evolving.  Yehuda explained how the Merb and Rails core teams have come together to work on Rails 3.0 - a fusion of the best parts of each framework, but with re-imagined internals.  Rails 3.0 isn't going to remove any of what makes Rails great, but it will hopefully be better for 'power users'.  i.e. those developers who care about how the internals work, and take advantage of the concepts therein.

A large portion of the keynote involved an explanation of why interfaces are a good abstraction.  (Not the Java kind of interface, but the hypothetical kind - i.e. contracts between components). Interfaces give you a calling-convention, allowing you to change internal implementations without affecting the calling code.  Classes and modules take this to the next level: mixing in modules is more powerful than inheritance as it allows your classes to learn new things. As Yehuda put it, "Your parents didn't define all that you can do when you were born. You can learn new things."  With Ruby modules you can swap out small sections of implementations as and when you need them at runtime.

This concept is used to allow the different components of Rails 3.0 to be separated up.  For example, you will no longer be forced to use ActionView - you'll just need something that is "ActionView compliant".  The same applies to ActiveRecord - your models will just need to comply with the ActionModel contract.

Despite what you might think, the contracts for ActionView and ActionModel compliance are actually really simple, and just need a few methods.  If you just want the default behaviour, all you'll need to do is just include an existing module.  By implementing these interfaces you will end up with something that 'just works' with ActionPack, providing you with all the usual form and error helpers.  Furthermore, ActionController::Base will essentially just be ActionController::Metal with a bunch of extra modules included... but you can still use a stripped down version of metal if you don't need all that extra functionality.

So, all of this will result in a much more granular Rails which will allow you to opt in or out of each part if that's what you want.  By just pulling in the parts of Rails you need, you can reduce memory usage and complexity in your apps.  This goes some way to answering Fred George's criticisms of Rails, regarding not being able to just select the parts you need for the job. And maybe it will unite the Ruby community by allowing people to focus on just one de-facto implementation of each component.

Links to slides and videos for each presentation made at the conference can be found on the schedule page of the Rails Underground site.

Also.. Jumpstart Lab is offering workshops teaching Ruby for beginning female programmers (Ruby Jumpstart) on August 1st and 2nd, then beginning Rails (Rails Jumpstart) for everyone on August 15 & 16. Save 10% with code "rubyinside"!