small medium large xlarge

Back to: All Forums  PragPub
Generic-user-small
05 Jun 2013, 15:52
Jon Roberts (6 posts)

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.

http://www.freeagent.com/central/migrating-freeagent-to-rails-3-and-ruby-1.9

‘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.

Samr_small_pragsmall
06 Jun 2013, 14:18
Sam Ruby (634 posts)

I guess it would be helpful if I clarified something. If you built a Rails application for, say, Rails 3.2 and then were to want to upgrade to Rails 4, you can generally do that fairly easily. Particularly if you check your logs for deprecation warnings prior to an upgrade.

An example to illustrate the difference between the problem I am dealing with and the migration problem you describe:

In Rails 3.2 (like versions of Rails before it), generate scaffolding would put function tests for controllers into a directory named tests/functional. Now it places such tests into a directory named tests/controllers.

It can be confusing to somebody attempting to learn a framework when a book suggests that they edit a file by a given name in a certain directory to not find that directory.

But in order to accommodate applications with existing tests, the command rake test will look in both places for tests.

Occasionally, there is a need for a more substantial change. A security bug found in Rails 3.2 caused the Rails team to introduce “protected attributes”. This wasn’t an ideal solution, but gave them time to work on “strong parameters”. Rails 3.2.3 ships the former by default. Rails 4.0.0.rc1 ships the latter by default. But both are available as gems which can be added to your Gemfile allowing you to chose when (and if!) you decide to make the change.

It looks like “Free Agent” was caught by surprise by a change introduced in Ruby 1.9. The changes from Ruby 1.9 to 2.0 are considerably smaller than the changes were from Ruby 1.8 to Ruby 1.9.

You must be logged in to comment