It’s just data

Keeping Up With Rails

J Aaron Farr: the greatest difficultly of Rails development is that “best practices” have a shelf life of < 12 months

In an example in Agile Web Development with Rails, 2nd Edition, there is a test with a setup method that includes a few routes.  This example propagated forward to the third edition essentially unchanged.  This code worked in Rails v1.  It worked up to Rails v 2.2.2.

It fails in Rails 2.3.2.  After debugging, it appears that the culprit is that config/routes.rb is processed before setup is called, and that file provides some default routes which are intended to be the lowest priority, but as they are processed first, they end up overriding.

With 2.3.2 there is a new API (which I can’t find, and doesn’t seem to have much in the way of documentation) that allows you to add routes after startup.  Depending on the precedence order of these additions, this could be useful.

It is this type of change that has lead me to automate my regression testing of the scripts in the book against versions of Rails.  If you are on OSX or Linux, and have Rails 2.2.2 or Rails 2.3.2, you can see it in action in under a minute:

git clone git://
cd awdwr
ruby makedepot.rb 6.1-6.5 save

If all went well, what should have happened is that the entire 6th chapter of AWDwR was executed, the results were verified, and a snapshot of the entire application (code+database) was saved.  If you would like to see the actual output, it is captured in makedepot.html.  You can also continue on with the 7th chapter using ruby makedepot.rb restore 7.1-7.4.

My goals are threefold:

At the present time, there are four failures when running this test against HEAD.  Two that I mentioned previously, and two more that I have recently discovered.  The first is truly trivial: timestamps now have a precision of microseconds, which doesn’t match the regular expression I had set up for this in my tests.  The second is the change in Templating Systems API that I haven’t yet debugged.