
Rails 2.2 Released - 27 Links and Resources To Get You Going - petercooper
http://www.rubyinside.com/rails-22-released-27-links-and-resources-to-get-you-going-1354.html
======
smoody
The new Rails release appears to have some great stuff in it -- definitely
time-savers for those people already up-to-speed with Rails. At the same time,
the dynamic state of Rails makes it difficult for small dev teams to keep up
with the state-of-the-Rails-art, IMHO. I spent some serious time with Rails
and always wondered if I was writing sub-optimal code. There are so many ways
to approach any programming task with Rails, that I, personally, felt like I
could never definitively prove that my way was the best way. And, every time a
new release came out, I had this feeling that I should go back and change all
of my code to take advantage of all the new features (in addition to making
the changes necessary to make it compatible with new releases), which pretty
much negates many of the productivity benefits afforded by Rails. If, for
example, I had rolled my own i18n solution, would I now go back and rip it out
and replace it with Rails' solution or keep it in place?

In the end, as some people do, I wrote my own framework (in PHP) and couldn't
be happier. Yes, I don't have a lot of the bells and whistles of Rails and
others, but my framework is stable, I know the optimal way to utilize it, and
when I do update it, I do it with knowledge of how the changes impact the code
that is built upon it.

I drifted a bit off topic I guess. My point is that, while I appreciate the 27
links (out of perhaps hundreds of soon-to-be available links on the new
upgrade) that help people navigate the fresh Rails waters, I have to wonder...
is the fact that hundreds of people feel the need to document their
experiences with rails updates, how to utilize the updates, and the gotchas
associated with the updates, an indicator of a hidden cost of using Rails that
negates some of the benefit?

~~~
petercooper
I would upmod you with several points of my own karma for this if I could :)
Yes, you're right. The upgrades come some thick and fast that code soon goes
out of date and can even be viewed by the community as "bad" - yet it was
using standards that were "good" months earlier!

The way I tend to look at it is like a car. If I have an old app, I treat it
like an old car. I'll keep it updated where necessary, but I'll stick to the
style of its times. If lots of new gee-whiz features are needed, I'll start a
new app. This is less than ideal in certain environments, but if you're agile,
working on your own projects, or have the right mindset, it's quite
refreshing.

