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://github.com/rubys/awdwr.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:
By automating the tests I hope to be able to help reduce the number of unintentional changes to Rails. Adding New Templating Systems (Section 23.11 of the book) worked on Rails 2.1.2, didn’t work at all on Rails 2.2.2, works with a different API on Rails 2.3.2, and either is broken or appears to have yet another API on Rails HEAD at the moment.
I also hope to be able to help to get the word out for intentional changes. My experience is that the release notes are a good overview, but could benefit by being augmented with lists like this one.
While there are no firm plans for a fourth edition, I’ve begun to think about ways of making the book appeal to a broader audience, and for the content of the book to be more durable.
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.
Regarding making your book more durable... I’ve accepted that the printed book (or PDF) is a good starting point, and I have to use more dynamic (but less comprehensive) sources for deltas. Please don’t compromise on the value of the book as a starting point in the name of durability.
I have been told that my lack of documentation and clean packaging of things could be holding me back. Well, that and “horrible graphic design”. I think, as with most things, this situation is never as simple as people think. For instance, take Ruby...
I’d say there are other greater difficulties but this is in the top 3. I’d say >50% of the coding time (and >90% of the headaches) of Erector ([link]) have come from figuring out how to work within Rails... and then doing it again on every minor dot release.
registering TemplateHandlers continues to work in config/initializer but no longer works in application_controller.rb. Weird, but I will simply recommend initializers going forward.
As I get this test closer to the point where it repeatably passes, by keeping on top of Rails edge, I should be able to use tools like git bisect to identify exactly where any regression is introduced.
Yehuda Katz: ... I’ve been running automated tests on Rails, focusing on edge, for nearly a month now. Four problems were found during the process: ticket 2779 was probably found before I could even report it, in any case it...
[more]
One of the things that has both pleasantly surprised and frustrated me over the past six months is the state of Rails’ internal tests. While the tests can sometimes cover the most obscure, important bugs, they can sometimes be heavily mock-based or...
One of the things that has both pleasantly surprised and frustrated me over the past six months is the state of Rails’ internal tests. While the tests can sometimes cover the most obscure, important bugs, they can sometimes be heavily mock-based or...
I like to be extremely judicious with use of routes. Fewer routes means less memory consumption and fewer confusing magical methods. I always delete the default route map.connect ‘:controller/:action/:id’ (you should too, otherwise all your pretty...
Since December, Rails has undergone a fairly significant internal refactoring in quite a number of areas. While it was quite tricky at first, we’ve started to hone a process for diving into a new area of the codebase and emerging some time later...
I like to be extremely judicious with use of routes. Fewer routes means less memory consumption and fewer confusing magical methods. I always delete the default route map.connect ‘:controller/:action/:id’ (you should too, otherwise all your pretty...
6 Passos para Refatorar Rails (Para meros mortais)
Esse artigo é uma tradução do Post original do Yehuda Katz Desde dezembro, Rails sofreu uma importante refatoração interna em uma série de áreas, enquanto isso tava delicado no início, Nós meros mortais começamos a afiar o processo de mergulho numa...