intertwingly

Sometimes the answer to information overload is to seek more information.

I’ve been trying to track the changes to both Rails 3.0 and Ruby 1.9.2 which affect Edition 3 of Agile Web Development with Rails, as well as track both with my work on Edition 4.  Depot Dashboard is a static snapshot of the result, updated frequently throughout the day.

At a glance, you can see that all of the tests are passing on 2.3.5 (which actually tracks 2-3-stable, or more precisely 2.3.6-pre at this moment in time).  I can actually tell you that there is at least one fix that will be going into 2.3.6 that will be needed to run on 1.9.2, that was identified as a result of my testing.

You can also see that all of my edition 4 tests are passing, though there is less of them at this time.  If you click through, you can see my thoughts on how the scenarios will unfold: examples of significant changes from edition 3: session data will now exclusively be stored in cookies, Carts and Line Items will be true REST based models, seed data will be used instead of a data-only migration, etc.  This is all still in flux: for example, I’m currently thinking of combining and splitting Iteration D and Iteration E to produce three smaller iterations.

At the present time, all of the 3.0 tests fail.  This is a recent thing, and they all contain the same failure, so that rules out changes in Ruby as a cause.  In fact, the error is simple, and I suspect rather easy to correct: the name of the path for the edit route for a nested resource is generated as (for example) article_edit_comment, whereas compatibility with 2.3.5 would indicate that edit_article_comment is the correct name.  That’s ticket 3561.

The current run for rails3.0 also shows another anomaly that pops up from time to time in runs I make: log data in what appears to be base64.  Search for “tail -25 log” in section 3.8 to see what I mean.

I’ve been generating tickets not just for outright bugs, but also for improvements to Rails which would not only make it easier for people coming to Rails, but also make Rails easier to document :-)

What you see on the public dashboard is only a snapshot of what the full script will do: namely allow me to start and monitor jobs and dynamically update the status based on results of previous runs.  Not shown is the code that sends private IMs to me and status updates to the Rails developers using Tinder.

I’ve submitted a proposal to RailsConf 2010 to discuss my experiences, and to explore collaborating with others with similar needs.