The Rails core team has released version 4 of its extremely popular web application framework on June 25th. Rails 4 contains numerous new features that should be interesting to most developers.
This release of Rails requires at least version 1.9.3 of the Ruby interpreter (or a compatible implementation) and the core team recommends running under 2.0+ for performance improvements. In the release announcement, DHH states that Rails 5.x will require ruby 2.0+, so as he put it, "you might as well get a head start" and upgrade now.
A quick Google search shows multiple articles detailing the new features of Rails 4. Some of the more salient features, in a nutshell...
Rails developers have been pretty used to dealing with MySQL by and large over the years (with an exception for folks using Heroku), but now the times are changing. Rails 4 includes support for multiple PostgreSQL data types. There's hstore, inet, cidr, macaddr and uuid support available in Rails 4. hstore can allow you to store "NoSQL-like" unstructured data in a PostgreSQL database (but don't abuse it as a full/complete NoSQL DB, it's not built for that). The inet, cidr, and macaddr data types also work with Ruby; inet and cidr both come out as instances of the IPAddr class, and MAC addresses are treated as strings in Ruby, but stored as the "macaddr" data type in PostgreSQL.
UUIDs are also easily supported - just remember to use a default scope of order("created_at ASC") with your models not to break Model#first and Model#last.
A JavaScript library designed to speed up end-user experience, TurboLinks is "on" by default in Rails 4. It works by fetching a new page as normal, but instead of reloading the whole thing, it just swaps out the body tag in your current, open and rendered browser view with what would have been in there anyway. This give things the illusion of being faster because the browser doesn't have to re-parse all your JavaScript and CSS. Instead, all necessary objects from the browser's point of view are already instantiated in memory and the only thing it has to do is render the changes in the body tag.
However, some folks have said TurboLinks can be a little problematic. It's possible that it can break some of your existing JavaScript, and that's more likely the more complex your JS is. It's also possible that you may have to change some of your event listeners as well. The good news is that it shouldn't interfere with existing JavaScript frameworks like jQuery.
Turning off TurboLinks is quite easy: just remove the "turbolinks" entry from your Gemfile, remove it from app/assets/javascripts/application.js, and run bundle again and you're done.
I suggest you try TurboLinks at first and only disable it if you suspect it's causing issues with your application.
A new method of protecting from mass assignment attacks, Rails 4's "Strong Parameters" seeks to move mass assignment protection out of the model and into the controller.
In previous versions of Rails, you might have had a model and told it that its parameters would be protected with attr_accessible. This was somewhat annoying for a developer because it prevented us from mass updating attributes too, even in cases when we really needed to for whatever reason.
With Rails 4, this can now be done in the controller. For example:
class PostsController < ApplicationController # ... other stuff ... def create @post = Post.new(post_params) end private def post_params params.require(:post).permit(:title, :body) end end
This is a simplistic example that shows a Post object being instantiated. However, in the past where we may have done something like@post = Post.new(params[:post]), instead we're no longer passing it attributes straight from params. Now we're giving it a private method that will require the params hash to have a post hash, and inside that the only keys it will allow are title and body (in this example). That means that if I somehow push up a request with, say, an author_id in the hash, that will be rejected outright and only the title and body attributes will actually be returned from the post_params method. This sanitizes input and prevents mass assignment attacks on the model.
Rails 4 includes a new cookie store: the encrypted cookie store. The idea is simple: encrypt a cookie before it goes out, decrypt it when it comes back. This prevents user tampering with cookies. However, I still strongly caution against putting sensitive information in cookies - just because it's encrypted (now) does NOT mean it's actually secure.
You can now include any number of default headers with your responses straight from your Rails app. It's not like you couldn't do this before with something like nginx, but for anyone on a multi-tenant host (e.g. AppFog, Heroku), this is a good option.
Aaron Patterson implemented the ability to live stream a response to a browser over a connection that stays open between the server and the client. This implementation very likely needs an application server capable of threading, and will probably work best on a real thread capable Ruby implementation (so JRuby or Rubinius for example), but should provide some interesting capabilities. There is the possibility that this feature will only work in the latest versions of Internet Explorer, however, if it works in IE at all.
Upgrade advice and more info
The Rails project has a good guide on upgrading located at http://guides.rubyonrails.org/upgrading_ruby_on_rails.html and there are several nice changelogs available for your perusal on GitHub:
