Just read ‘Keeping Rails on the Rails’ by Sam Ruby in the free magazine. He explains how example code in ‘Agile Web Development with Rails’ was regularly breaking because of changes to the underlying Rails code.
The solution is interesting, but it’s a chore, and would have to be repeated for other projects. This repetition and expense is caused by the volatility of Rails code. He has solved the problem for that particular book, but the same issue is faced by all other serious Rails apps.
I have posted up in a few forums over the years making the point that Rails would be more widely adopted if it would slow down a bit, stop changing things that already work pretty well.
This is an unpopular view !
I’ve been coding in C, Java and more lately ruby for 25 years. Most of my work has been in real life revenue earning projects. I was attracted to Rails because of its productivity, but have found that there are some very unproductive aspects that are rarely spoken of by the Rails community. Elephants in the room.
i) The amount of time we have to spend learning the newest way of doing something. A typical response is ‘you are too lazy/stupid to keep up, hard luck’, to which my response is ‘I have a life outside work, I would rather spend time with my kids than learning the 4th incarnation of Rails Routing’.
ii) The speed at which code is conceived, becomes part of Rails and is then abandoned. Causing application code in the layer above (eg code examples in the book) to be rewritten and sometimes new test code to be required.
I think the cause is cultural, the Rails community values innovation above all else. Even if the problem has already been solved before. And if the change will disrupt existing software that already relies on Rails, then hard luck, it will need changing. (I think the reason I had to stop using Mongrel was that something in Rails changed, and Mongrel was pretty widely used at that time, it almost seemed deliberate - can’t remember).
The programming values I hold in highest esteem are ‘Can I use that framework to productively make something, sell it, and still have it working in five years’.
There is an interesting case study from ‘Free Agent’, a brilliant example of Software As a Service for small business accounts written in RoR. The upgrade to Rails 3 and Ruby 1.9 was virtually a rewrite for them, and sounds horribly expensive.
‘The nature of the changes in Rails 3 and Ruby 1.9 meant that to migrate FreeAgent over has taken 974 separate commits and changing over 1,500 files. That’s a lot of changes to review and QA, which is why it’s taken time.’
I am in the middle ground, I love the productive aspects of Rails, but wish the community would be more open about the real world cost of the churn of core code.