1 2 3 next »

1. New in Rails 3.1
2. Reversible Migrations
3. has_secure_password

New features of Rails 3.1

by J. Austin Hughey

In this, the second of two articles marking the release of Rails 3.1, web applications engineer J. Austin Hughey discusses the new features and improvements in version 3.1.

New in Rails 3.1

Version 3.1 of the Rails framework has just been released and contains a wide range of new features. From changes designed to better organise and deliver assets such as images, CSS and JavaScript, to modifications to speed database performance, along with many other improvements, the latest version of Rails is going to be impressing developers around the world.

Asset Pipelining – Better Organisation of Images, JavaScript and CSS

As David Heinemeier Hansson (@DHH) pointed out in his RailsConf 2011 keynote, images, JavaScript and CSS have been considered "second class citizens" with respect to organisation in Rails projects for quite a while. They usually end up being thrown together haphazardly in the same directory. The Asset Pipeline, powered by Sprockets 2.0, is an attempt to more cleanly approach the situation by moving assets out of the public/ directory and into app/assets, lib/assets, or vendor/assets.

The idea is to keep assets developed by you for your application in app/assets, and third-party code or images that your application makes use of in vendor/assets. This properly "scopes" the assets so they remain better organised.

On the "front-end", however, Sprockets aggregates all of the asset files in all asset directories (which can be added to by appending a new path to config.assets.paths in config/application.rb), and compiles them into a single JavaScript or CSS file. In production, this file is generated in minified form once, and then re-served without being re-compiled for subsequent requests. In development mode, the file is re-generated on each request and is not minified.

In addition to asset organisation, Rails 3.1 now enables the use of Coffeescript and SASS for the development of JavaScript and CSS respectively. All that is required to develop JavaScript or CSS with Coffeescript or SASS is simply to modify the extension of a file in app/assets/javascripts or app/assets/stylesheets and write the appropriate code. For example, application.css.scss will be parsed as SASS, and application.js.coffee will be parsed as Coffeescript.

Example of new asset directory structure.

HTTP Streaming – faster delivery of JavaScript and CSS assets

Another great feature in Rails 3.1 is the introduction of HTTP streaming. By using streaming, a Rails application can begin returning a layout before the view for the specific controller and action has finished loading. This can help speed up the user's browsing experience: by allowing the browser to see the first portion of a response, it can begin fetching other assets – images, JavaScript and CSS – while waiting on the rest of the response (specific view for the controller and action) to be sent.

Using HTTP streaming is, for the most part, fairly easy. You can stream a specific render call, or everything in an entire controller:

class UsersController < ApplicationController
  def index
    @users = User.active # assume a named scope here
    render :stream => true
  end
end

This example would render the default view (app/views/users/index.html.erb) with streaming enabled.

Enabling streaming through all actions in a controller is even easier:

class UsersController < ApplicationController
  stream # enables streaming controller-wide

  def index
    # ...
  end

  def show
    # ...
  end

  # ... and so on ...
end

In the first example above, User.active – a supposed named scope, for illustrative purposes – is called for a reason. In order to use streaming properly, you need to make sure that your model queries are done using a method that will support lazy loading. Model#all does not support lazy loading, but #where, which powers named scopes (now done through the simple "scope" keyword), does. If you don't use lazy-loaded query methods, the streamed response will wait until the database query is complete. In simple and fast queries, this is generally hardly noticeable, but in queries that are more complex, with larger data sets to search, this issue becomes much more noticeable. With lazy-loaded queries, streaming can continue as one would expect, without waiting for the query to finish before streaming other portions of the response.

Next: Reversible Migrations

1 2 3 next »