Sam Ruby: Keeping Up With Rails | Hacker News Reader

Sam Ruby: Keeping Up With Rails

intertwingly.net

15 pointsdavidw9 comments

I also agree with this - I find it particularly difficult to maintain apps that I wrote for an earlier version of Rails, and which I had to lock to that version to avoid the app breaking in hard to diagnose ways; I sometimes don't touch these apps for a year or two, and working on them again means remembering the idiosyncrasies of that particular version of Rails, which are different from the idiosyncrasies of the version of Rails I'm using for another more recent app I'll be working on.

In fact, it's bad enough that I've been looking for alternatives to Rails for each new project I've started in the past year or so, but always give up because I think it'll be quicker to use what I know (and then usually end up regretting it later.)

Well, thankfully one of the top priorities of the upcoming release is a stable API.

A little late for that, but here's hoping.

Stability in a number of Ruby projects is a real problem: Rails, rspec, numerous plugins and gems. I wouldn't care so much if everyone used a versioning system that clearly communicated when things would break, but that's not happening.

Maybe having stable APIs and proper versioning is too "professional" for Rails.

"It is this type of change that has lead me to automate my regression testing"

Maybe I am wrong, but I think this post from Sam is about making sure you automate your test environment, so you can keep up with changes. Not complaining about how fast Rails changes.

The quote at the top of the page says: "the greatest difficultly of Rails development is that 'best practices' have a shelf life of < 12 months"

Sam is quoting this (as opposed to making the statement himself), but putting it at the top of the page seems to indicate that he agrees with it.

My understanding of the post is that Sam also deplores the rapid pace of change, and has automated his test environments as a workaround.

Yeah.. keeping up with rails is kinda hard. The hardest part is APIs which disappear for one revision and then come back later.

In this respect django seems to be much better.

I love Rails, but this is a valid point.

It's good to have tests, but shouldn't framework level libraries follow some kind of Design by Contract methodologies so that you never break compatibility?

Do other frameworks have this problem, and to the same degree as rails?

Reply on news.ycombinator.com