7 ms·

Get Your App Ready for Rails 4

75 points by blacktulip 14y ago

j45 14y 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 14y 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.
  - j45 14y 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.
    - venus 14y ago
      Well, if you're managing your rails app like that, you're running against the grain. Most rails apps should and, from what I know, are, being maintained at or near the latest stable version (currently 3.2.9). It's very much against rails best practise not to keep up to date, IMO. Any fast-evolving framework is a bit of a moving target - see android and iOS as well, not to mention HTML5, jquery, apps written in anything fast-moving needs constant minor maintenance to keep up. That said, there's no reason a rails 1 app won't run today just like it always has. One of the reasons rails can move so fast while avoiding bloat is its aggressive cutting of deprecated code. That has always been part of the rails way and I believe most rails devs are strongly in favour of this policy.
- nickbarnwell 14y 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.
  - nirvdrum 14y 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.
    - j45 14y ago
      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 14y ago
        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.
- ollysb 14y 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.
  - j45 14y 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.
holgersindbaek 14y ago
Does this mean that Rails will be released within a week or so?
- joevandyk 14y ago
  No, it's a couple months out probably. There needs to be a couple release candidates first.
kmf 14y 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 14y 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 14y 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'
michaelmartin 14y 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 14y 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.
danso 14y 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-record-rails-4-countdown-to-2013 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 http://edgeguides.rubyonrails.org/4_0_release_notes.html
- mgkimsal 14y ago
  Why are the dynamic finders being deprecated? Is it a speed/parsing thing? Or changing styles?
  - danso 14y 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?
    - mgkimsal 14y ago
      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'.
  - lobster_johnson 14y 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 14y 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 14y ago
  Actually I think the queue system won't be included just yet.
- phsr 14y ago
  Queues were recently pulled from Rails 4: https://github.com/rails/rails/commit/f9da785d0b1b22317cfca25c15fb555e9016accb https://github.com/rails/rails/commit/f9da785d0b1b22317cfca2...
bejar37 14y ago
A
sergiotapia 14y 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?
- nachteilig 14y ago
  Turbolinks still currently breaks a lot of things, including lots of .ready JS stuff.
nachteilig 14y ago
queues is going to be pretty nice.

75 points by blacktulip 14y ago

j45 14y 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 14y 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.
- j45 14y 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.
  - venus 14y ago
    Well, if you're managing your rails app like that, you're running against the grain. Most rails apps should and, from what I know, are, being maintained at or near the latest stable version (currently 3.2.9). It's very much against rails best practise not to keep up to date, IMO. Any fast-evolving framework is a bit of a moving target - see android and iOS as well, not to mention HTML5, jquery, apps written in anything fast-moving needs constant minor maintenance to keep up. That said, there's no reason a rails 1 app won't run today just like it always has. One of the reasons rails can move so fast while avoiding bloat is its aggressive cutting of deprecated code. That has always been part of the rails way and I believe most rails devs are strongly in favour of this policy.
nickbarnwell 14y 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.
- nirvdrum 14y 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.
  - j45 14y ago
    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 14y ago
      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.
ollysb 14y 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.
- j45 14y 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.

holgersindbaek 14y ago

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

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

kmf 14y 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 14y 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 14y 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'

michaelmartin 14y 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 14y 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.

danso 14y 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-record-rails-4-countdown-to-2013 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 http://edgeguides.rubyonrails.org/4_0_release_notes.html

mgkimsal 14y ago
Why are the dynamic finders being deprecated? Is it a speed/parsing thing? Or changing styles?
- danso 14y 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?
  - mgkimsal 14y ago
    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'.
- lobster_johnson 14y 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 14y 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 14y ago
Actually I think the queue system won't be included just yet.
phsr 14y ago
Queues were recently pulled from Rails 4: https://github.com/rails/rails/commit/f9da785d0b1b22317cfca25c15fb555e9016accb https://github.com/rails/rails/commit/f9da785d0b1b22317cfca2...

bejar37 14y ago

sergiotapia 14y 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?

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

nachteilig 14y ago

queues is going to be pretty nice.