
Get Your App Ready for Rails 4 - blacktulip
http://rubysource.com/get-your-app-ready-for-rails-4/
======
danso
FYI, here's what's new specifically for ActiveRecord 4, relevant for those of
us who are using other frameworks (Sinatra, Padrino) that leverage Rails
components:

[http://blog.remarkablelabs.com/2012/12/what-s-new-in-
active-...](http://blog.remarkablelabs.com/2012/12/what-s-new-in-active-
record-rails-4-countdown-to-2013)

The official edgenotes has sections for all the Active components:

<http://edgeguides.rubyonrails.org/4_0_release_notes.html>

~~~
mgkimsal
Why are the dynamic finders being deprecated? Is it a speed/parsing thing? Or
changing styles?

~~~
danso
I had that question too...I was thinking that it must have some effect on
performance but I thought it would be pretty minuscule?

~~~
mgkimsal
OT performance rumination: I've not run tests on Rails' performance in this
capacity, but I've _always_ thought that the runtime gymnastics to pluralize
model names would be a big drag on Rails performance. I'm guessing something's
cached, but I've _never_ understood the 'opinion' that a class should be
'Person' and the table name should be 'people'.

------
j45
This is a really nice and handy guide, thanks! On a side note, having coded in
many languages, I'm still a little at a loss for words that code breaking with
new versions is tolerated.

Several of my talented friends spend too much time precariously managing their
old Ruby codebases. I hope it keeps improving to make life easier.

~~~
nickbarnwell
Code breaking for patches and security enhancements is widely viewed as
unacceptable, but this is the first occasion I've seen someone accept to
breaking changes in a major release. Neither Rails 2 nor Rails 3 were
fundamentally broken, and there's nothing stopping you from keeping an
application on those releases.

~~~
nirvdrum
In theory, there's nothing preventing you, but in reality it's just way too
difficult. I put off upgrading to Rails 3 for a long time because of the rspec
2 fiasco and because Rails 2.3 was much faster. But, the problem is the rest
of the ecosystem.

Most gems simply don't provide changelogs. Virtually none will maintain
compatibility with more than one version of Rails, despite how easy monkey-
patching makes this. So, if you care about fixing security releases in your
app, you need to maintain not just Rails, but also the code for every plugin
you use.

In one case I was told if I wanted the latest toys, I should upgrade to Rails
3, even when I offered to provide the Rails 2.3 compatibility branch. It's not
a technical problem, it's a cultural one (and to be fair, those with opposing
viewpoints don't view it as a problem). But, at the end of the day it's just
not worth the headache.

You need to ruthlessly cut your dependency graph or accept the potentially
destabilizing upgrade.

~~~
j45
I think what you said about theory vs reality is the gap of technical debt
that gets created. It's a real and growing issue in any framework that is
maturing.

If what is today's leading edge will be legacy in the next 8-12 months, can a
codebase get established and create value?

~~~
nirvdrum
It's hard to say. Other communities do this much better. Java is obviously the
poster child for backwards compatibility, but Python is much better too. Ruby
makes supporting multiple versions very simple in most cases, but there's no
will to do so.

For my part, I avoid anything that's a Rails plugin now. Time after time, I've
found them to be a problem. Even if you decide you're going to upgrade to
Rails 4, you need to update your entire dependency graph in one pass. Plugins
targeting Rails 4 almost certainly won't target 3.x and not all plugins are
going to be 4 ready on release day, so upgrading piecemeal is impossible.

------
michaelmartin
Great summary here, love the 3.2/4.0 side by side examples. I wondered why it
hadn't mentioned the new background queue API though, only to find that's been
pushed back out of 4.0 now. Just wanted to mention here incase anyone else
hadn't seen that that has been taken out.

------
ejpastorino
Hi, Thanks all for the comments!

I didn't include queues, live streaming, and other features because
unfortunately they are not available as a separate gems.

I tried to cover all the things that are possible now (via gems or simple code
change). Maybe in a future post I'll cover all the new things in Rails 4. But
as it's still on development I prefer to wait until a beta or release
candidate.

~~~
phsr
Queues were recently pulled from Rails 4:
[https://github.com/rails/rails/commit/f9da785d0b1b22317cfca2...](https://github.com/rails/rails/commit/f9da785d0b1b22317cfca25c15fb555e9016accb)

------
holgersindbaek
Does this mean that Rails will be released within a week or so?

~~~
joevandyk
No, it's a couple months out probably. There needs to be a couple release
candidates first.

------
rustc
Are there any instructions to try out Rails 4 right now? And any major gotchas
still left to be fixed?

Excellent post BTW.

~~~
kawsper
Test with edge Rails by uncommenting out your normal Rails-line in your
Gemfile, and add this:

# Bundle edge Rails instead:

gem 'rails', :git => 'git://github.com/rails/rails.git'

------
sergiotapia
Turbolinks seems really, really nifty! It may have been released a long time
ago but it's the first time I see a technique like this.

Does anybody know how this technique affects SEO?

~~~
nachteilig
Turbolinks still currently breaks a lot of things, including lots of .ready JS
stuff.

------
kmf
Awesome! I've seen a lot of little coverage on some of these topics but this
is about as comprehensive as I think we'll find without any sort of release
notes.

------
hayksaakian
I saw no mention of live streaming.

The removal of 'match' in routes is a little saddening....

I'm not sure how I feel about the concerns abstraction.

------
nachteilig
queues is going to be pretty nice.

------
bejar37
A

