Get Your App Ready for Rails 4

http://rubysource.com/get-your-app-ready-for-rails-4/

by blacktulip • 14 years ago

75 31 14 years ago

rubysource.com

holgersindbaek• 14 years ago

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

joevandyk• 14 years ago

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

kmf• 14 years ago

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.

rustc• 14 years ago

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

Excellent post BTW.

kawsper• 14 years ago

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'

j454• 14 years ago

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.

irahul• 14 years ago

As bad as breaking changes sound, keeping historical baggage isn't ideal as well. I don't know about your friends, but if this is all that has changed, it would be a simple migration provided you already are on 3.2.

j454• 14 years ago

I'm referring to Rails apps that are being maintained in their current states in v1, 2, 3 and now beyond. The ability to maintain them in their current version (or upgrade) depending on what an updated gem does, or does not fix can be quite a challenge.

nickbarnwell• 14 years ago

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.

nirvdrum3• 14 years ago

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.

ollysb• 14 years ago

This is a question of taste really. Do you favour continuous improvement or stability? Personally I prefer the continuous refinement approach that rails takes. It's definitely not for everyone though.

j454• 14 years ago

I've seen that you can reasonably have both.

With a mindset of today's leading edge "way" being tomorrow's legacy.. one is creating technical debt that will be abandoned on older versions without extensive updates.

A black and white view on a framework being opinionated definitely costs more developer hours in some ways (which it could save up front).

I want to be extremely careful to not go near any religious debates about frameworks, or as you put it very well, preferences.

There is no perfect or ideal tool. Having open enough conversations about the tools we use and the reality we sometimes face without trying to be apologists or explain it away is essential.

I do wonder if many people have yet to have a relationship with a codebase they started as the leading edge, which stays stuck on an old release that becomes more and more expensive to upgrade. Does one really end up ahead in that case having to repay technical debt caused by the philosophy of a framework?

Maybe there's a finer line that can be drawn between the fantastic benefits of a framework that are not likely to change, and a way to work in approaches that may come and go?

Like any framework, it will have mature whether it likes it or not, I just hope it's for the better like everyone.

michaelmartin• 14 years ago

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.

hayksaakian• 14 years ago

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.

danso2• 14 years ago

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

The official edgenotes has sections for all the Active components:

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

mgkimsal2• 14 years ago

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

danso2• 14 years ago

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

lobster_johnson2• 14 years ago

Changing styles is my guess; less a reliance on auto-generated magic. There is nothing wrong with this:

    find_all_by_user_id_and_conversation_id(params[:user_id], @conversation.id)

But this is equally (actually more) concise:

    where(user_id: params[:user_id], conversation_id: @conversation.id)

...and it builds on the composable scope system (derived from ARel).

ejpastorino• 14 years ago

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.

viseztrance• 14 years ago

Actually I think the queue system won't be included just yet.

phsr• 14 years ago

Queues were recently pulled from Rails 4: https://github.com/rails/rails/commit/f9da785d0b1b22317cfca2...

bejar37• 14 years ago

sergiotapia• 14 years ago

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?

nachteilig2• 14 years ago

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

nachteilig2• 14 years ago

queues is going to be pretty nice.

Get Your App Ready for Rails 4

Related Stories