Rails 4.0: Final version released
weblog.rubyonrails.org
weblog.rubyonrails.org
The latest rewrite of my book for Rails 4 is available at http://leanpub.com/tr4w
Michael Hartl's Rails Tutorial has also been fully updated. See http://news.railstutorial.org/ruby-on-rails-tutorial-rails-4... for all links to relevant material.
Design Patterns in Ruby is just as enjoyable.
I have never heard of POODR before...but given that so many people are listing it in the same "top list" as Eloquent Ruby - I am definitely gonna get it.
Hartl's tutorial was a bit much for me. I don't think when I was just learning Rails, to be thrown into TDD was wayy too much and made it much less enjoyable.
I think if there was a "no-TDD" path, it would have been better....or maybe some way to explain the TDD aspect more clearly.
As it is, while one can of course still use Test::Spec, you're likely to be in a small minority.
Since the Book is not 'the factory default stack of Rails' but rather the Rails "way" we certainly do have an opinion about what is considered the most popular and efficient way of building Rails apps. This does mean we use HAML throughout the book, because honestly, we all think its a better choice. Personally, since we converted to HAML at Astrails several years ago, I cringe every time I have to deal with ERB. Its just too verbose and it doesn't present the structure as obviously as HAML. Same for the rest of the 'opinions' in the book. YMMW
I just purchased R4W, looking forward to brushing up.
http://contributors.rubyonrails.org/releases/4-0-0/contribut...
I mentioned this below, but I'll mention it here, as well: if you have gems that aren't ready yet for Rails 4, please ping me and let me know if I can help get them ready somehow. If you maintain a gem and want help running your tests on Travis against multiple versions of Rails, I can help with that as well.
<3 <3 <3 <3
I wrote up my own personal 'contributing to Rails' guide here: http://blog.steveklabnik.com/posts/2012-07-05-how-can-i-cont...
The official one is here: http://edgeguides.rubyonrails.org/contributing_to_ruby_on_ra...
The easiest way is to write documentation; that's how I got started. It's not for everyone, though. The simplest possible way to get involved with writing code is to pick an open bug on the tracker and fix it.
Like most things, it just gets easier the more you do it. The first one seems hard, everything seems confusing. But by the time you've done two or three, you wonder why you ever thought it was difficult.
Once you get a certain level of familiarity with the way Rails is built, find a small bug and follow the contribution guidelines.
There is no magic :) Take small steps and continue to make any contribution you can. Ask a ton fo questions and work through issues, you'll get there.
Here's a blog post that Steve actually wrote about contributions:
http://blog.steveklabnik.com/posts/2012-07-05-how-can-i-cont...
Congrats as well Steve! You should be really proud of this release with the rest of the core team.
And thank you for contributing in making rails awesome :)
Would love opinions from the HN gallery as to whether a delay now saves time later.
Edit: And thanks to the Rails team for providing me with this conundrum!
Edit2: Thanks for the info and opinions! I'll check back later too.
For larger apps (which I maintain as a freelance) I would wait a bit more though, since some gems will still have little bugfixes related to Rails 4 compatibility, most likely.
I'm in the same boat (having been building on Rails 3 for a good while) and for now I'm going to stay put. People who are more knowledgeable about the specific updates please correct me if my assumptions are off-base.
- the bug fixes will only be included in 4.0.z releases
- the security issues will only be fixed in 4.0.z and 3.2.z
- the severe security issues will only be fixed in 4.0.z, 3.2.z
So you will want at least to upgrade to 3.2.z, or use Rails LTS ([2])
[1] http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-f...
Really, it's not large. The things I'm most worried about are
gem 'carrierwave'
gem 'jquery-fileupload-rails'
gem 'jquery-datatables-rails'
gem 'jquery-ui-rails'
I don't have a good answer: Fine to program with, but certainly took some doing for our particular need. (We had a number of requirements that made the "easy" out-of-the-box jquery-fileupload not suitable.)
Ask me in a couple of months and I'll probably have a lot of opinions to give.
> and when I saw there was some weird iframe thing for IE... I closed the page and walked away.
We are migrating customers from a C++ desktop app to a web interface: So anyone on old IE with problems will be informed that they're not supported on the new system, so keep using the old and let us know after they upgrade. :) (Newer IE is OK.)
Deviously, this also prevents absolutely everyone from ditching the old app and swamping the new system on day 1.
The iframe transport method for uploads is useful for browsers that don't support XHR file uploads (basically IE < 10). You can read more a bit about how it works in: https://github.com/blueimp/jQuery-File-Upload/wiki/Frequentl... or directly in the source: https://github.com/blueimp/jQuery-File-Upload/blob/master/js... (it's pretty small).
You'll have a bit of work to do to migrate to strong parameters, but you can always add the protected_attributes gem back to re-enable support for attr_accessible.
I'd suggest checking out the Rails 4 migration RailsCast.
Definitely not going to be fun!
I have performed two rails 2 upgrades. Both cases they were smallish apps, but they took 3-5 days to feel comfortable with everything that's happened.
If this is an app that is still being actively developed, I highly recommend you fast track it.
[If not, look up the community-managed security back port branch and switch to that asap]
Basically, the problem stems from bit-rot and alas such is the nature of our industry. In a nutshell, the longer you wait the harder it is to find quality docs on what's changed and how to fix it. A lot of links are now gone.
The main challenge comes from: the change in the router, the changes in the view api (everything is escaped by default, and you will find a ton of string concats in your helpers that will now spit out garbage), migrating over to the asset pipeline (which I personally found confounding for a long time until I got the hang of it), migrating over to Arel queries and updating all of your plugins - many of which will stop working in quirky ways. You may also experience pain with updating your test suite.
So, there's a lot of yak shaving but you don't actually have to refactor your app much. Your controllers will remain basically untouched and so will your models modulo named scopes and certain now preferred validation patterns. Most of the pain is view-focussed.
Oh, and the attribute protection but that pain is a good pain, you really need to whitelist your attributes. IF YOU ARE READING THIS MAKE SURE YOUR MODELS HAVE AN `attr_accessible` THAT DOES NOT HAVE ANY ATTRIBUTE THAT ENDS IN `_id`.
There's a phenomenal plugin that will help a lot - https://github.com/rails/rails_upgrade - but it's not going to catch everything.
Suppose you have some kind of permissions model based around the department that a certain employee belongs to. Say, HR people can look at people's salaries.
If you allow mass assignment to department_id, someone can edit the form in the user page and assign themselves to ANY department and boom!, they're in.
You can fix this by having some sort of validation, but I find I prefer to have it in the controller.
Before:
@model.update_attributes(params[:model]) # trololol
dept = params[:model].delete[:department_id]
@model.update_attributes(params[:model])
if current_user.can(:foo)
@model.department = Department.find(dept)
end
You may be interested to know that you can have multiple attr_accessible declarations for different classes of user, and then when you call update_attributes you say which declaration should apply. But perhaps with strong parameters it's not worth going down that road.
We have actually backported sprockets/asset pipeline quite awhile back and have been using it without any major problems.
Definitely aware of the benefits its just very hard to do something at the scale that we're at :). Earlier this year our REE -> 1.9.3 upgrade took about a month and a half. For the past year we've been moving to separate, smaller applications and then breaking those into mountable engines within each application.
Appreciate the feedback though and the links!
If you see any failures in the days after upgrading you have a new variable to consider on the cause.
Look at what the best/worst outcomes are from making the change - does the risk justify the benefit?
Would I do it? yes probably, I can't sleep if I'm on a 3 when I know there is a 4 around.
If you're on 2.3.x upgrade, otherwise wait a bit.
To the OP, I suggest you launch with 3.x and upgrade immediately after to 4 and start taking note of deprecations.
Yeah, but that pain will come regardless. Better I think to wait until the dust settles on turbolinks et al and plugin authors update. You could always update first to 4.0.x (for mild to large values of x) or what have you before jumping over to 4.1.
Point is, if you've got a large app it's not worth pushing back any deadlines. Someone's gotta do it! and much to love to the rails-core team, but being 3 months behind the release schedule still counts as "bleeding edge" in most of the rest of the software world ;).
I think this is the most likely outcome. Thanks again to everyone for the discussion too.
If anyone has gems that don't work with 4 yet, please let me know. Most of them at least have a branch going, but I'm always curious, and am willing to help out to upgrade things.
Full disclosure: I'm friends and work with Andy and he's super smart and I'm not getting a kickback. :)
Nobody wanted a 2 -> 3 transition again.
In the meantime you can watch bug / experience reports and get some info to make an educated decision.
There are so many improvements to this version that are not immediately visible, but which are maturing Rails in tremendous ways. I think it compares with the release of Mac OS X Snow Leopard (10.6). Especially in the perception on different types of users (experts to consumers).
On a different note, moving from 3.2 can best be done one gem at the time. For instance, implement strong parameters and you're one step closer to Rails 4. https://github.com/rails/strong_parameters
I work with rails every day for the last 6+ years and it was a revelation when I started. Now I still think it works decently well for large web-apps, but it's just grown way to big over the years. Basecamp is awesome and a great proving ground, but I'd wager the vast majority of apps written in RoR come no where close to needing most of what's included today.
I'll admit to being on a hard-core minimalist, simplicity, explicit coding kick recently, so I'm already biased against behemoth frameworks. Rails is wonderful if you need that level of complexity/features. I don't think most apps do and we're "forcing" everyone to write basecamp when that is overengineering for most apps.
The beautiful part is that while writing most code in pure Rails you don't need to think about turbolinks at all - it just comes for free.
BTW, turbolinks is a bit improvement over pjax. It is much simpler (since the whole page is loaded), discouraging some of the complexity that you might be tempted to introduce by pjaxing different parts of the page.
Converting an existing app to turbolinks will take some work, especially with how JS is handled. The key is to run your JS on the turbolinks "page:change" callback and then call the same callback on the initial page load:
$ ->
# Simulate turbolinks page change on document ready.
$(document).trigger "page:change"This meant that anything page-specific in your <head> caused Turbolinks to double the work your app had do to, and provided no positive benefit at all.
I'll check and see how it's behaving now.
Edit: Looks like concerned assets are now tagged with a data attribute. Glad that's in there now.
This screws up the normal .ready() stuff, right? Has this bitten anyone yet?
The Turbolinks README has everything you need to do to make your applications ready, if you choose to use it: https://github.com/rails/turbolinks#turbolinks
Using Angular with Rails is definitely a Good Thing(TM), but you really need a large enough project to justify, something both front- and back-end heavy. My current project is large enough to benefit from both, but unfortunately, I chose jQuery and Sinatra. Feeling the pain, for sure.
I don't personally know of anyone using Angular + Turbolinks, so I can't answer that.
By the way, ActiveModel::Serializers is part of the Rails API project[1], and we'd love some thoughts on how to make it work well with Angular.
ActiveSupport.on_load(:active_model_serializers) do
ActiveModel::ArraySerializer.root = false
ActiveModel::Serializer.root = false
endI'm more interested in it as a place to explore best practices and work on useful things around names, than the speed aspects.
On another note, I've been using Rails4 beta and RCs at home for the past couple months and it has been a joy. At work I've also been working on a Rails 3.2 app and incorporating routing_concerns and strong_parameter gems. I think upgrading from Rails 3 to 4 apps won't be as drastic as upgrading from Rails 2.x to 3 apps was (curse you asset pipeline!)
http://pragprog.com/book/jvrails2/crafting-rails-4-applicati...
Now I just need a good book on Rails 4.0 or for Michael Hartl to update the Rails tutorial.
It diffs the initial 'rails new' project between any two versions.
I will caution all to be aware of the turbolinks included by default. I spent a while scratching my head why a setTimeout function worked every so often. I had no prior experience with turbolinks or the discussion thereof, though I believe it's a great feature.
> The beauty of that system is that you just don’t care. Memcached will automatically evict the oldest keys first when it runs out of space
Well, I do care : I use redis as cache backend. I guess it will not be as simple as that.
http://stackoverflow.com/questions/9010789/configuring-redis...
I currently empty redis cache on each deployment, so that's not really a problem, but it will be when I use a less naive cache invalidation on code update (and I'm pretty sure some of you are).
So, we'll probably have to take a look in rails cache internal and force sweeping when computing a new key (this will not be a major problem on redis, since it supports wildcards in key names).
ERROR: While executing gem ... (Gem::RemoteFetcher::UnknownHostError) no such name (https://rubygems.org/gems/actionpack-4.0.0.gem)
Edit: Now it is working :)
Also, this post describes today's book release as the "final" version, but the PragProg changelog calls it Beta 4.0.
I'm curious how does this affect the rails-api project?
I don't know of any type of application that Rails 4 CAN'T do, but it's still Rails and Ruby, so anything computationally intense would probably be better served (ha!) by a Java (or Go, or Scala, or...) framework. The further you get from a CRUD app, the less useful the Rails framework becomes.
Definitely not a good choice for 1st Rails book though.
Another recommendation for it below from jherdman & jazearbrooks.
I've updated the first half of the book, though the forums say there's still a few typos and such that made it through so far. I'm working on the second half now.