This Week in Edge Rails

April 4 – April 17, 2009

Just in case you missed the news: edge Rails is waking up, with Rails 3 changes starting to show up in the master branch at Github. So there’s a lot to discuss this week. If you want some more of the technical story on the Rails 3 rearchitecting to date, check out the detailed blog postings from Yehuda Katz.

Which Branch Should I Use?

The Rails 3.0 work is being done on the master branch in the Rails repository on Github. If you want to keep up with all the latest changes, this is the branch to track – with the caveat that this is currently alpha code. It’s entirely possible to build a working Rails application using the master branch. The Rails core team is committed to keeping the master branch passing all tests, and in fact improving our test coverage and continuous integration policies are both on tap as Rails 3 improvements. But it’s important to realize that the changes to Rails will result in many plugins needing a rewrite before they will work with Rails 3 (of course, some plugins will need more updating than others). This will make Rails 3 difficult to use for full-scale production deployments for some time to come.

For existing production applications, you should be tracking the changes on the 2-3-stable branch at Github. This branch contains bug fixes and improvements to the 2.3 release code, and should continue to remain compatible with the plugins and code that you’re already using.

Should I be Submitting Patches to Rails?

Absolutely! Rails has always been a community effort and that’s not changing for Rails 3. We welcome patches for either Rails 2.3 or Rails 3.0 – please use the appropriate tag (2-3-stable or 3.0) in your Lighthouse tickets to make it easy to tell which branch you’ve tested and based your patch on. The Contributing to Rails Guide will help you through the mechanics of submitting a patch to Rails.

David outlined the overall vision for Rails 3 back in December, and that’s still the basic plan. If there’s some piece that you’d especially like to get involved with, the Ruby on Rails: Core mailing list will help you get in touch with the developers to coordinate plans – and possibly save some headaches. Most of the major pieces of work are already underway, but we know that community ideas and contributions are essential to the success of Rails 3.

Rails 2.3.x Changes

Speaking of Rails 2.3, the last couple of weeks have seen some bug fixes deployed, and one interesting piece of new functionality: ActiveRecord::Base#touch. The idea is that you get a shortcut to push the current time into the updated_at or updated_on timestamp field in a record:


What makes this more than a savings of a few keystrokes is that it’s also implemented as an option for belongs_to associations:

class Order < ActiveRecord::Base
	belongs_to :customer, :touch => :last_order_update

With this declaration in place, saving or destroying an order object will touch the corresponding parent customer object. This can come in very handy when you’re trying to invalidate a cached copy of the parent in that situation.

commit commit

Rails 3.0 Changes

ActiveRecord::Base#touch was also added to Rails 3.0 at the same time that it went into the 2.3 branch. In general, this should be the case: new functionality from Rails 2.3 will carry over into Rails 3. The core team is working hard to ensure easy upgrades and compatibility when the time comes to make the version change. But there were a lot of other changes this week that only apply to Rails 3: that’s what the rest of this posting is about.

Module Organization

There are spots in the Rails code where there are multiple levels of inclusion and inheritance and setup. As part of making it easier to follow what’s going on, Rails 3 is introducing new depends_on, use, and setup abstractions. These can make the intent of code more obvious on reading:

module AbstractController
  module Helpers
    depends_on Renderer
    setup do

module ActionController
  class Base2 < AbstractBase
    use AbstractController::Callbacks
    use AbstractController::Helpers

commit More information


Probably the biggest architectural change so far in Rails 3 is the introduction of the AbstractController base class. This is a new implementation of the commonalities between ActionController::Base and ActionMailer::Base, and will eventually serve as a base class for the Rails analog of Merb’s parts. The intent is not to provide code that plugins or applications will use directly, but the build a solid low-level API that other things can depend on. For example, a consumer of AbstractController will be able to implement its own path-finding logic for templates, or add additional options to the basic render method.

commit commit More information


Another internal architectural change is the introduction of ActionDispatch. A new member of the Action Pack family, ActionDispatch exists as a home for all of the various HTTP libraries and middleware that were previously stuffed into ActionController, including such things as request handling, parameter parsing, status codes, and our bundled copy of Rack. commit

Defining the Surface Area

One of the goals of the Rails 3 work is to cleanly distinguish between public API methods that plugins and application code can rely on, and Rails internals that are subject to change. For an example of this, you can look at some of the refactoring that’s been done to ActionView::Template. Here, the change is to identify the methods that aren’t used by other classes, and to make them private. This immediately makes the intended API of the class more graspable, and in the long run will help give us a contract with plugins as to how they should interact with core code. After the current surface area has been formally identified, it’s likely that it will be reduced to result in a cleaner external API. commit

AJAX and authenticity tokens

If you’ve been writing much javascript by hand, you’ve discovered the nuisance of needing to include the Rails authenticity token in your requests. A closer analysis of the issues shows that there’s no need for these tokens in AJAX requests, because the same origin policy protects them. So, Rails 3 no longer checks for those tokens on AJAX requests, and that’s one less ugly bit of javascript for you to write. commit

Test Improvements

Another area of focus in Rails 3 is to bring the internal tests up to current best practices. There are a number of spots in the existing code where the tests are less systematic than they could be – changes have been checked in with test coverage, but no one has gone through and tried to ensure full test coverage of all normal “happy” code paths. For a glimpse of what’s happening in this area, check out some of the test files in actionpack/test/new_base (the new_base code is a rewrite-in-progress of ActionController::Base). There’s also active work going on to improve our continuous integration story, and the get together some basic high-level integration tests that can exercise Rails as a whole.

Loose Ends

There are some Rails 2.3 features that are currently not implemented in master. Some changes could not be merged cleanly with the new architecture, others are being reimplemented in different ways. You’ll find some specifics in this commit message, but the missing pieces include the performance boost for development mode rendering, template recompiling in production, and some template-picking logic. The developers working on Rails 3 have indicated that they intend to get back to feature parity as quickly as possible. In fact, a first pass over the rails-dev-boost changes has already been committed.

Removed: CGI Support

Rails 3 will not support direct CGI dispatching. This was deprecated in Rails 2.3, so it should be no surprise to anyone that it’s being removed entirely. If you need to use CGI for some reason, though, remember that it’s still supported through Rack. commit

Phusion Announces Passenger for Nginx

In the relatively short time since its release, Phusion Passenger has become part of the preferred deployment strategy for many Rails applications. But because it’s targeted at Apache, some sites have been unable to use Passenger. Apache is a great full-featured web server, but for highly traffic nginx seems to consistently deliver better throughput at lower memory use.

As of today, though, the Rails server landscape is changing for the better once again with the announcement of Phusion Passenger for Nginx. This new version takes the Passenger technology, including the use of Ruby Enterprise Edition, and integrates it tightly with nginx. How tightly? Well, you just install the Passenger 2.2.0 gem and run the included nginx installer, and you get a custom-built version of nginx along with instructions on how to configure it to server your Rails site. In addition to combining the benefits of nginx and Passenger, this has the side effect of greatly simplifying the nginx setup.

For more details, including a screencast, hop on over to Phusion’s blog

One Giant Leap Forward

As of a few minutes ago, the first big bunch of Rails 3 changes were merged back to Rails master branch in github. This represents a good deal of work by Yehuda Katz, Carl Lerche, and others. I’ll have more to say on the changes later on this week, but for now, just a quick caution: if you’re in the habit of using Edge Rails, you should likely switch to the 2-3-stable branch for the time being. The master branch of Rails will likely take a little while to settle back into something that can be used for anything other than getting a preview of the Rails 3 excitement.

Rails IDEs March On

Many Rails developers are perfectly happy working on their code in a text editor – and there are certainly plenty of excellent text editors out there. But others, particularly those who have come to Rails from another platform, find themselves wanting a full integrated development environment. For the latter group of developers, there’s good news: two major cross-platform Rails IDEs have releases available now.

Aptana’s RadRails (a plugin for their Aptana Studio IDE) has just released version 1.2. This Eclipse-based environment will seem instantly familiar to many users, and version 1.2 has a couple of major advances to boast about. First, it includes a wizard that will aid new users in setting up Ruby, Gems, and Rails; this is likely to be especially useful to those coming to Rails on Windows. Second, it has built-in deployment to Aptana’s Cloud Connect scalable deployment service, giving a pain-free way to get your Rails applications up and running.

Also worth a look is JetBrains’ RubyMine, currently in late beta prior to its commercial release. A purpose-built Rails IDE, it offers a variety of features including rake support, a model diagrammer, built-in web previews, and code quality tools. RubyMine isn’t finished yet, but the current beta version is showing good promise.

Both RadRails and RubyMine have the features you’d expect from an IDE, including flexible code editors, refactoring support, built-in hooks for test running, integrated debugging, and source code integration. RadRails comes in both community and $99 Pro editions, while RubyMine is scheduled to be released at $99. Whether you prefer to work in a text editor or an IDE, the appearance of these applications is yet another sign of the continuing popularity and growth of the Rails ecosystem.

This Week in Edge Rails

March 28, 2009 – April 3, 2009

Things are still fairly quiet out on the edge: 5 commits this week. The work for Rails 3.0 hasn’t been merged back to the master branch yet, so if you need any of the post-2.3 patches you can still just update to edge without worrying about major upheaval.


  • When are 24 hours not 24 hours? When you add them across a DST boundary in Rails – at least, until one of this week’s commits. You can read more details of what was going on over at the Lighthouse ticket.
  • Looked at your development mode /rails/info/properties view lately? Look again after this commit and it will show all of the installed Rack middleware pieces in your application.

RailsConf interviews, presenter posts, and keynotes

RailsConf 2009 is drawing ever closer and it’s going to be one hell of a show worthy of Vegas glitz and glamour. To let you all get more familiar with who’s going to be talking and what they’ll be talking about, Chad Fowler has been doing a series of presenter interviews:

In addition, Nicke Plante is talking about his Rumble Panel and Marty Andrews about his automated code quality check talk.

We’ve also announced some of the keynoters. In addition to yours truly, we’ll have Bob Martin of ObjectMentor, Chris Wanstrath of Github, and Timothy Ferris of 4-hour work week and lifestyle designs rock it out. We’re also going to have a Rails Core panel of some sort.

It’s going to be a great time. You can follow along with even more announcements from the conference on Twitter by subscribing to @railsconf. See you in Vegas? Of course I will!

This Week in Edge Rails

March 21, 2009 – March 27, 2009

It’s been a quiet week for Rails on the surface: just half a dozen commits over the course of the week. Behind the scenes, though, the work is going on to merge initial Rails 3.0 work into the master branch of the git repository. We’ll have more news on that as it happens.


Meanwhile, a few small issues in the 2.3 release have been cleared up in edge:

  • Tests with multiple POST requests in the same test block now properly handle parameters. commit
  • render :file with absolute paths now works on Windows systems. commit
  • Template extension parsing is now more robust (if you’ve been having problems with files like show.erb.orig, this one is for you). commit

Just a reminder, if you’re having any issues with Rails 2.3, we’d love to know about them – and we’d love it even more if you’d supply a failing test or a patch. Check out the details in the Contributing to Rails guide.

This Week in Edge Rails

March 14, 2009 – March 20, 2009

The big news in Rails this week, of course, was the release of Rails 2.3. But that certainly doesn’t mean the Rails edge story is over! To the contrary, we’re embarking on one of the more ambitious and exciting Rails projects of all: the creation of Rails 3.0. Read on to see where things stand.

Final 2.3 Changes

A few things went in to Rails 2.3 in the days leading up to release. These include:

  • DDL transactions for SQLite databases commit
  • Compatibility between render :file and Pathname commit
  • ActionController class naming conventions for Metal commit


Shortly after the release of Rails 2.3, which was version 2.3.2, it became necessary to make a Rails tag. This is because the tagged 2.3.2 version in the Rails repository is actually missing an important fix (the installable gem version of Rails has the fix). The net result is that rake rails:freeze:edge RELEASE=2.3.2 would freeze a bad version of Rails into your application.

To fix this, the Rails team has re-tagged the master tree at a safer spot, after the critical fix. This new tag is for release So if you’re freezing Rails 2.3 into your applications (as opposed to running it from gems) be sure to use rake rails:freeze:edge RELEASE= That .1 makes all the difference.

The Road to Rails 3.0

Now that 2.3 is out, what’s next? Rails 3.0, which has been a distant speck on the horizon for a while, is rapidly getting closer. The Rails core team is discussing exactly how to proceed, but the bottom line is that you are shortly going to see a lot of changes on edge Rails, as work that’s been going on in various forks gets merged back into the master branch. You’ll want to be cautious about using edge on existing applications. In particular, changes to the Rails internals may result in many plugins needing to be rewritten. Rails edge will continue to be the cutting-edge solution, but you’ll need to keep up with the changes and be prepared to work with them if you choose to run on edge.

But this doesn’t mean that Rails 2 is frozen in time either. There’s a new 2-3-stable branch in the Rails repository which will host any maintenance releases to the current release version. There will continue to be some work on making sure the 2.x releases of Rails work well, though the center of gravity of Rails framework development will shift quickly to Rails 3.0.

So stay tuned. We’ll continue to keep you posted with Rails 3.0 developments as they happen: the process will continue, as always, to be transparent and to welcome ideas and feedback.

Get Paid to Work on Rails

Last year, as you may recall, Rails got thread safety and a new core committer thanks to our participation in the Google Summer of Code program under the auspices of Ruby Central. This year, we’re pleased to announce, Ruby on Rails has been accepted into Google Summer of Code as a sponsoring organization in its own right.

What does this mean to you? Potentially, if you’re the right person, you can get paid to work on the Rails core code this summer!

The “right person” in this case is one who is at least 18 years old (sorry, Google’s rule, not ours!), a full- or part-time college student, and passionate about improving Rails. We’re building a potential list of project ideas on the Rails wiki, but we welcome other interesting proposals. We’re especially interested in work that meshes well with the plans for Rails 3.0, which will be in full swing by the time GSoC launches. If your proposal gets accepted, Google will pay you $4500 over the course of three months to work on the code.

If you’re interested, head over to the GSoC site and start reading about the process. Student applications can be submitted starting March 23.

What if you’re not a student? You can still help out by brainstorming ideas on the Rails wiki. Or if you’re a Rails guru and ready to make a strong commitment to help out the next generation of developers, you can apply to be a mentor.

We’re looking forward to working with this year’s students, and expecting some outstanding contributions to Rails as a result!

Rails 2.3: Templates, Engines, Rack, Metal, much more!

Rails 2.3 is finally done and out the door. This is one of the most substantial upgrades to Rails in a very long time. A brief rundown of the top hitters:

  • Templates: Allows your new skeleton Rails application to be built your way with your default stack of gems, configs, and more.
  • Engines: Share reusable application pieces complete with routes that Just Work, models, view paths, and the works.
  • Rack: Rails now runs on Rack which gives you access to all the middleware goodness.
  • Metal: Write super fast pieces of optimized logic that routes around Action Controller.
  • Nested forms: Deal with complex forms so much easier.

And that’s just the tip of the iceberg. We’ve put together a complete guide for the Rails 2.3 release notes with much more information. Be sure to checkout the section on what was deprecated when you’re ready to upgrade your application.

You install 2.3 with (the final version is marked 2.3.2):

gem install rails

If you’re running on Passenger, be sure to upgrade to 2.1.2 as well. Rails 2.3 doesn’t run on older versions of Passenger!

We hope you’ll love it.