Dean Wampler's Blog

I attended the first annual Ruby on Rails RailsConf in Chicago last weekend and I've finally found the time to blog about it ;)

About 500-550 people attended, from novices to Rails experts, including 8 out of 11 of the Rails "core" team. The atmosphere was collegial and somewhat cozy. Everyone realized that future Rails conferences will be a lot bigger and probably more commercial too, given the growing interest in Rails.

Dave Thomas' Keynote

Dave's was the first keynote of the conference. He described the top-3 unsolved problems on his list of TODO'S for Rails. The list contains somewhat conventional items that you might expect, but what was interesting about the keynote was how the list anticipated some spirited philosophical discussions throughout the weekend.

Data Integration Improvements

Dave would like ActiveRecord to extract more information from the schema into the models, such as constraints and associations. He would like better foreign key and compound key support. He would like non-database back-ends supported, like JMS/MQ systems and he would like support for distributed transactions with two-phased commits, etc.

These are all reasonable requests from someone familiar with the typical challenges of "enterprise" (more on that word below...) applications, especially legacy systems. However, this surfaced an on-going debate between the two Daves; Dave Thomas and David Heinemeier Hansson (DHH). DHH has made clear his preference for keeping all domain logic in the application and using the database as a relatively simple-minded storage vehicle.

As subsequent presentations and discussions indicated, the Rails "core" will get smaller in the future and plugins will provide added support for things not considered "core". No doubt people will implement plugins for all the things Dave (Thomas) wants, but they won't be part of the Rails core. But this is okay, as it will satisfy various needs, yet keep Rails lean, mean, and architecturally clean (you can quote me...;) ).

CRUD and Scaffolding

Who could argue with that? Well, some people feel that scaffolding is too much of a crutch that discourages neophytes from understanding Rails and adapting it to their needs. Others feel that the scaffolding command-line tools are too primitive and should be more sophisticated. For a promising example of the latter, see the forth-coming Streamlined.

Perhaps most interesting was DHH's own keynote, where he discussed his thoughts on more fully realizing the "vision" of CRUD in rails, but more on that later.

Deployment

Deployment was a popular topic at the conference, with several sessions devoted to Capistrano, server topology considerations, etc.

David Heinemeier Hansson's Keynote

Jumping ahead to DHH's keynote on Saturday, he replied to some of Dave Thomas' comments by reaffirming his opinions on topics such as the roll of the database and how far ActiveRecord should go in supporting various database features. For example, he was emphatic that composite keys are a known evil in the database world and ActiveRecord should not support them, at least not as a core feature. Perhaps someone will write a separate plugin, but DHH believes that if you do bad stuff, it should be painful, not easy.

For most of hist talk, however, DHH focused on more fully realizing the "vision" of CRUD in Rails. Create, Read, Update, and Delete are the standard operations in database-backed applications. In forthcoming versions of Rails, DHH wants to make this model more consistently applied throughout Rails.

For example, HTTP actually defines four methods, GET and POST, which we all know an love, but also PUT and DELETE. Roughly, these correspond the Read, Create, Update, and Delete operations in CRUD.

Our current way of organizing models, controls, and the behavior they offer is reflected in URLs of the form

.../model/action/id

Instead, we should be writing more "CRUD'y" URLs of the form

.../model/id

Unfortunately, browsers don't usually support PUT and DELETE, so Rails is adopting a convention that hacks around this limitation. For example, the URL for the update case will look something like

.../model/id;update

But there are more ways to "embrace the CRUD." Consider a typical example with a Person model and a Group model, where one or more Persons can be a member of one or more Groups. Typically this is handled thusly:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

  class Person << ActiveRecord::Base
    belongs_to :group
    ...
    def remove_from_group ...
    def add_to_group ...
    ...
  end
  
  class Group << ActiveRecord::Base
    has_many :people
    ...
    def remove_person ...
    def add_person ...
  end

Where should those add and remove methods really go? DHH pointed out that if we reify (not his term) the relationship between Person and Group, that is, treat it as an model object in its own right, then we can use CRUD conventions to manage the relationship itself. In this example, a class Membership could encapsulate membership of people in groups. The CRUD creation operation would add a Person to a Group, deletion of memberships would remove the relationship, etc.

Perhaps the most interesting thing about his keynote was how it demonstrated his thorough commitment to pushing design principles to their logically limit in Rails. Where most of us would have been satisfied with the current design, DHH sees that it can be made even more consistent to the CRUD vision, and thereby further increase the use of common (and automated) conventions. No wonder Rails is so good!

Rails Application Optimization Techniques and Tools

Stefan has done an extensive analysis of Rails performance issues. His detailed talk listed some of his findings. He is working on a book that is due next year, published by Wiley, that promises to be valuable for developers concerned about optimizing performance.

In a nutshell, he listed the following as the top performance problems:

• slow helper methods,
• complicated routes,
• associations, especially when loading one object retrieves all associated objects automatically,
• retrieving too much data from the database (related to the previous point), and
• slow storage of session information.

For more details about his findings and recommendation, see Stefan's blog and his recent InfoQ article.

MetaRails

Stuart discussed some interesting uses of metaprogramming within the Rails core that make Rails the amazing environment that it is. Rails is a treasure trove of patterns and idioms that are well worth learning. As neither Stuart nor Justin are members of the core team, they provided an outsider's perspective.

Stuart mostly praised the quality of the Rails code, but he pointed out one area where he felt it isn't DRY enough, the way many ActiveRecord methods are aliased and then replaced with methods that add support for transactions, etc. There are apparently several different areas where the same methods are aliased this way, where each alias provides a different "enhancement." As these alias statements are not co-located, it would be easy for one such modification to stomp on another. Also, how do you ensure that one alias takes "precedence" (i.e., gets applied first) over another? For example, you might always want authentication and authorization to happen first. (Note that Stuart's follow-up blog mentions that the DRY problem has been partially solved since he started his analysis.)

In fact, he described a classic case that motivates Aspect-Oriented Programming. Even in dynamic languages like Ruby, where metaprogramming facilities are easy to use, AOP provides a conceptual framework for thinking about certain design issues, like adding transactional behavior to persistent objects or invocation of authentication and authorization challenges before executing otherwise normal-looking methods. Yes, Ruby metaprogramming facilities allow you to implement AOP-like behavior, but you have to "switch paradigms" to do so. I don't know how Ruby implements Object-Oriented behavior, but you could image that similar metaprogramming approaches are used or could be used if no OO support were provided. So, yes, you could do OOP, in this case, but isn't it nicer to think in objects when you are writing OO code, rather than have to switch gears mentally and think in meta-object protocols? The same argument can be made about providing AOP facilities in a language, even if those facilities are relatively small additions. For example, AspectR, an AspectJ-like Ruby clone, is only about 200 lines of Ruby code.

I'm going to blog about the role of AOP in dynamic languages like Ruby in the next few days, so please check back. Also, I'll be doing a talk on AOP in Ruby and Python at the Dr. Dobbs Architecture and Design World in Chicago, July 17-20. I hope to see you there!

RailsConf 2007