Handy Rails Tips

Don't use SecureRandom for simple Strings in Ruby

Sun, 15 Nov 2020 00:00:00 +0000

SecureRandom is a common solution for generating simple, random strings in Ruby. But is it always the optimal approach?

In this video I demonstrate how SecureRandom can actually be quite a slow and expensive way to generate random strings, and walk through the steps for creating your own PORO that suits your specific domain.

RandomRef class

class RandomRef

  CHARS = *'A'..'Z', *'0'..'9'

  attr_reader :string

  alias to_s string

  def initialize(length: 10)
    @string = CHARS.shuffle.take(length).join
  end

end

Benchmark

Here’s the benchmark setup and results on my machine:

require "benchmark"

require_relative "random_ref"
require "securerandom"

TIMES_RUN = 10_000

Benchmark.bmbm do |test|
  test.report("SecureRandom hex:") { TIMES_RUN.times { SecureRandom.hex(5).upcase } }
  test.report("SecureRandom alpha:") { TIMES_RUN.times { SecureRandom.alphanumeric(10).upcase } }
  test.report("RandomRef:") { TIMES_RUN.times { RandomRef.new.to_s } }
end

Rehearsal -------------------------------------------------------
SecureRandom hex:     0.017828   0.101192   0.119020 (  0.119230)
SecureRandom alpha:   0.063555   0.243703   0.307258 (  0.307377)
RandomRef:            0.013328   0.001197   0.014525 (  0.014526)
---------------------------------------------- total: 0.440803sec

                          user     system      total        real
SecureRandom hex:     0.019170   0.108771   0.127941 (  0.128621)
SecureRandom alpha:   0.064643   0.246745   0.311388 (  0.311942)
RandomRef:            0.013712   0.000642   0.014354 (  0.014404)

Update 16/11/2020

I realised that RandomRef will not return a truly random string, since it won’t have any repeat characters. While this isn’t a major problem, I’ve updated the episode code with a slight refactor that corrects this. Benchmarks for the updated version below:

class RandomRef

  CHARS = *'A'..'Z', *'0'..'9'

  attr_reader :string

  alias to_s string

  def initialize(length: 10)
    @string = length.times.map { CHARS.sample }.join
  end

end

Rehearsal -------------------------------------------------------
SecureRandom hex:     0.022391   0.142847   0.165238 (  0.167282)
SecureRandom alpha:   0.071716   0.281742   0.353458 (  0.354494)
RandomRef:            0.022149   0.001585   0.023734 (  0.024165)
---------------------------------------------- total: 0.542430sec

                          user     system      total        real
SecureRandom hex:     0.018336   0.117855   0.136191 (  0.136656)
SecureRandom alpha:   0.071869   0.282151   0.354020 (  0.356737)
RandomRef:            0.023950   0.000139   0.024089 (  0.024159)

Building a REST API in Ruby on Rails 3

Wed, 12 Aug 2020 00:00:00 +0000

This short screencast is one that I recorded back in 2012 to demonstrate the power of Ruby on Rails to a client.

In this video I set up a basic User resource, and then create controller endpoints to create, read, update, and destroy records via JSON requests.

A naming convention for ActionMailer emails

Fri, 10 Jul 2020 00:00:00 +0000

One of the great things about Ruby on Rails is its philosophy of Convention over Configuration. Simply put, this means that developers are encouraged to name and organise their code in specific ways, and to stick to these naming principles wherever possible. The benefit of CoC is that developers spend less mental energy trying to make decisions about things like “where should I store my database schema?”, so they can spend more mental energy on building a great product.

In Rails apps, emails are typically sent by a library called ActionMailer. While ActionMailer is an excellent tool for the job, there’s no common convention in the Rails community on how to name mailer classes and methods. In this post, I’ll share with you the convention I’ve been using on projects I’ve worked on recently.

The essence of a mailer

To develop a naming convention, we must first reflect on how our code is being used, and look for some common patterns that apply to most use cases. In doing so, I’ve realised that most mailers can all be boiled down to these common features:

Recipient: The recipient is the entity that will receive the email. This will normally be a person, but it could also be another app or remote service that receives email inputs. Recipients might be your service users, customers, internal admins, or unauthenticated visitors to your website.
Resource: Emails are usually sent out to provide information about a specific resource or domain concept within the system. In other words, emails are usually sent about something relevant to some thing. An article has been published, a subscription has lapsed, a purchase has been completed. These will often be the models that you’ve defined in your code, but they might also be more abstract concepts (like a password reminder).
Change: Transactional emails don’t just spontaneously fire off. They’re usually sent in response to an event or some change that’s happened within the system. An example could be when some resource is created, updated, cancelled, or renewed.
Intention: Services email people for different reasons, which I’ve called the intention. In practice, using this convention, I’ve only ever come across four different intentions when sending emails: notification, confirmation, warning, and provision. You might discover more in your own use-cases, but I haven’t needed more than these in the past few months.

By identifying these common patterns within our mailers, we can now try to establish a naming convention that communicates what an email is being sent for within our code.

What should you name your Mailer class?

Web applications can sometimes become very large, and the number of different emails that are sent out can easily grow into the dozens, and this sometimes means large ActionMailer classes with dozens of methods defined in them. Most sensible developers will avoid having just one mailer class, and try to split the emails up into separate mailer classes for different purposes.

But this raises the question: what should I name my mailer class? Should I name it based on the recipient? Or the subject matter? Or the namespace within my app? A mixture of these?

My preference is to name ActionMailer classes based on the recipient. This should always be the term you use within your business domain. If you call your customers customers, call your mailer CustomerMailer. If you call your customers “guests”, call your mailer GuestMailer. This makes it very clear who is the intended recipient of a given email.

What should you name your Mailer method?

Just like our class name convention makes it easy to see, at a glance, who the recipient of an email is, your mailer method name should make it clear what the email is about, and why it’s being sent. With this in mind, I use the following naming convention for mailer methods names: #<resource>_<change>_<intention>. To get a feel for this convention, let’s look at a couple of examples:

Example 1:

A visitor to your blog receives an email to notify them that their comment has been approved. In this case, the recipient is a visitor (Recipient), and we’re notifying them (Intention) that their comment (Resource) has been approved (Change).

In this case, we’d define VisitorMailer#comment_approved_notification

Example 2:

An admin of your business receives an email to notify them that a customer payment has failed. In this case, the recipient is an admin (Recipient), and we’re notifying them (Intention) that their payment (Resource) has failed (Change).

In this case, we’d define AdminMailer#payment_failed_notification

Example 3:

A member of your organisation requests a link to reset their password. In this case, the recipient is a member (Recipient), and we’re providing them (Intention) with a password (Resource) reset (Change).

In this case, we’d define MemberMailer#password_reset_provision

Conclusion

So there’s my proposed naming convention for ActionMailer methods. I’ve been using this with great success, and it’s one less thing I have to think about when I’m coding apps.

If you have any thoughts, please feel free to share them with me on Twitter (@morricegavin).

Grab data from your production database using ActionMailer

Wed, 27 May 2020 00:00:00 +0000

This is a nasty and naughty hack, and one I’m abashedly apologetic for.

I was doing some work on a personal project recently, and wanted to pull some data out of the live database. I only needed a few columns from a couple of tables, so it didn’t seem to warrant a SQL dump.

I decided to format the records as JSON data, and copy/paste them from the console directly. But it turned out the length of the JSON data was longer than the backtrace in my terminal window, so I wasn’t able to see it all at once to select, copy, and paste.

Instead, I decided to save the data in a temporary file, and then email it to myself—using a temporary, memory-only mailer object.

Since this code was only held in memory during my rails console session, it disappeared as soon as I exited the session.

Here’s the code I used to do that:

array = # ... get all of the data that I need from the DB

# Create the Tempfile object
tempfile = Tempfile.new("my-data")
# Write the data to the tempfile as JSON
tempfile.write(array.to_json)

# Subclass ApplicationMailer in memory
class DynamicMailer < ApplicationMailer

  # Define a mailer method to send myself the file we just created
  def send_attachment(tempfile)
    attachments['attached.json'] = File.read(tempfile.path)
    mail(to: 'me@handyrailstips.com',
         body: "",
         subject: "Incoming...")
  end

end
# Send the email
DynamicMailer.send_attachment(tempfile).deliver_now

# Clean up the Tempfile afterwards
tempfile.close
tempfile.unlink

Hopefully the annotations in the code example make sense.

I pulled the data that I wanted from the database in an Array of Hashes
I created a Tempfile to store the data in
I wrote the data to the Tempfile in the JSON format
I created a new Mailer class in memory with one method for sending attached files
I sent myself the Tempfile full of JSON
I cleaned up the Tempfile afterwards.

I don’t advise that you ever use this horrible little hack for anything, on any project, ever.

DRYer, neater filters with class-based filters

Tue, 18 May 2010 00:00:00 +0000

Recently I was working on a project which required various permissions for each controller. A user could have permission to access one feature of the site but not another.

Here’s a great tip for keeping your rails controllers simple and DRY when working with multiple before filter conditions.

The before_filter method takes not only a method name as an argument, it can also take custom class objects as an argument. Here’s an example:

class OrdersController

  # run this before filter on :index, :show and :destroy actions
  before_filter PermissionCheck.new( :orders, :only => [:index, :show, :destroy] )

end

When requests are made to those actions that require this before filter, Rails will create a new instance of PermissionCheck and call it’s before() method (you have to define this method yourself). Here’s an example of the PermissionCheck class and how it works:

# lib/permission_check.rb
# Here we create a new subclass of Struct, an easy way to create a class with an attribute.
class PermissionCheck < Struct.new( :permission_name )

  # NOTE  - here it is assumed that you have
  # a) A method to find the current_user from the controller: ApplicationController#current_user
  # b) A method to check if the current_user has a specific permission: User#has_permission?
  # c) A method to redirect and notify the user if they do not have adequate permissions: ApplicationController#unauthorized_action
  # this is called from the controller automatically when we use before_filter
  def before( controller )
    # unless the current_user has permission...
    unless controller.current_user.has_permission?( permission_name )
    # redirect and notify user
      controller.unauthorized_action
    end
  end


  # after_filters can be defined in the same way
  def after( controller )

  end

end

To make things neater still, we can create a class method for this in ApplicationController:

class ApplicationController < ActionController::Base

  # Helper method to add this before filter to the controller
  def self.check_permission( permission, options = {} )
    before_filter PermissionCheck.new( permission ), options
  end

end

And our controllers now look like:

class OrdersController < ApplicationController

  check_permission :orders, :only => [:index, :show, :destroy]

  # etc...

end

class CustomersController < ApplicationController

  check_permission :customers, :only => [:index, :destroy]

  # etc...
end

Defining classes for before filters and after filters offers far more flexibility than simply using methods. So, if your before filters are starting to mount up and they contain a lot of similar code, then defining a class may be a better solution for you.

Improve Performance With Record/Resource Caching

Thu, 25 Feb 2010 00:00:00 +0000

For my personal homepage I wanted to load the latest tips from Handy Rails Tips as well as my most recent Tweets on twitter. As these resources are stored on different sites from my homepage, there was a little lag when loading the landing page.

I don’t tweet or post tips every day so it seemed a little unnecessary to have these loaded fresh with every hit to my site. Instead, updating them once a day seemed fine.

Here’s a quick tip for caching ActiveResource resources or any other data that doesn’t necessarily need to be ‘hot off the press’.

Below is the Tip model for my homepage:

class Tip < ActiveResource::Base
  self.site = "http://handyrailstips.com/"

  def self.cached
    return @@cached if @@last_cached == Date.today
    @@last_cached = Date.today
    @@cached      = self.all
  end

end

I wont cover the ins and outs of ActiveResource here, but let’s have a look at the cached method:

the first line will return the value of the class variable @@cached only if the @@last_cached date is today. If not, we update @@last_cached to equal today’s date and then re-set @@cached to equal all tips (only 5 are returned from Handy Rails Tips). All subsequent calls to the cached method on this date will return the contents of @@cached.

Then, in the controller all I had to add was:

class HomepagesController < ApplicationController::Base

  # GET /
  def index
    @tips = Tip.cached
  end

end

Simple!

For the tweets I took pretty much the same approach but did not use ActiveResource.

class Tweet

  require "net/http"

  # a Net::HTTP object to be used for each request
  HTTP_OBJ = Net::HTTP.new("twitter.com")

  def self.cached
    # return the cached tweets if they were cached today
    return @cached_tweets if @last_cached == Date.today

    # else, find the latest tweets and changed the cached date to today
    @last_cached      = Date.today    
    @cached_tweets = find_latest
  end

  def self.find_latest(no = 5)
    response, xml = HTTP_OBJ.request_get "/statuses/user_timeline/gavin_morrice.xml?callback=twitterCallback2&count=#{no}"
    # returns an array of new Tweets with the content of each <text> tag
    Nokogiri( xml ).css("status").map { |status| new status.css("text").text }
  end

  attr_reader :text

  def initialize( text )
    @text = text
  end

end

The twitter API returns quite a lot of XML so I used Nokogiri to pick out what I need, the status tags. Each of these are then parsed and their content loaded into a new Tweet object. Calling @tweet.text returns the text content from this tweet.

Remember – by default, classes are not cached from one request to another in the development or test environments so to check this is working properly you’ll have to set cache_classes to true in development.rb.

# In the development environment your application's code is reloaded on
# every request.  This slows down response time but is perfect for development
# since you don't have to restart the webserver when you make code changes.
config.cache_classes = true

Faster Tests With factory_grabber

Wed, 09 Sep 2009 00:00:00 +0000

I use factories instead of fixtures when testing. If you haven’t already discovered factories, check out this Railscast: Factories not Fixtures.

Now that you’re up to speed: I often find when writing tests that I simply want any record. Here’s a quick example scenario from a controller spec:

describe CommentsController do

  describe "POST /posts/1/comments" do

    before do
      @post = Factory :post
      @comment_attributes = Factory.attributes_for(:comment, :post => @post)
    end

    def do_post
      post :create, :comment => @comment_attributes, :post_id => @post.id
    end

    it "should create a new comment for @post " do
      lambda { do_post }.should change {@post.comments.count}.by(1)
    end

    it "should redirect to @post" do
      do_post
      response.should redirect_to(post_path(@post))
    end

  end

end

In this example, we’re creating a new post record even although there may already be several posts in the database. Since this test is only asserting that a new comment has been created for @post it doesn’t really matter what the post’s specific attributes are. All we care about is that it’s a valid post we can create comments for.

Inserting new records to the database is usually slower than simply retrieving an existing record. As a result, constantly creating factories when we already have appropriate records means our tests are slower and more inefficient than they should be.

Factory Grabber

I recently published a gem which addresses this issue. To check it out, simply run:

sudo gem install git://github.com/bodacious/factory_grabber.git

Factory Grabber is intended to be used with Factory Girl by ThoughtBot.

To use factory grabber in your tests/specs simply call the number of records and the model name as a method on Grab like so:

# return 47 individual comment records
@comments = Grab.forty_seven_comments
# will return 9 user records each with last_name "Smith"
@smiths = Grab.nine_users(:last_name => "Smith")
# return one record
@user = Grab.a_user
@article = Grab.an_article
@post = Grab.one_post

If there are appropriate records already in the database, Grab finds them. If there are not appropriate records, Grab will create them using the factories you’ve already defined.

For a practical example:

describe "GET /posts/1" do
  integrate_views

  before do
    @post = Grab.one_post :title => "This is the post title", :body => "This is the post's body"
  end

  def do_get
    get :show, :id => @post
  end

  it "should show the post title" do
    do_get
    response.should include_text(/This is the post title/)
  end

  it "should show the post body" do
    do_get
    response.should include_text(/This the post's body/)
  end

end

# test pagination
describe "GET /posts?page=1" do
  integrate_views

  before do
    # ensures there are at least eleven Post records
    # if there are less than eleven, new posts are created
    # if there are eleven or more no posts are created
    Grab.eleven_posts
  end

  def do_get
    get :index, :page => 1
  end

  it “should find the latest 10 posts” do
    do_get
    assigns[:posts].should == Post.find(:all, :order => “created_at DESC”, :limit => 10)
  end

end

Here’s example of the performance boots you can achieve:

                                 user     system      total        real(secs)
Create 50 new factories      0.100000   0.200000   0.300000 (  6.354282)
Grab 50 separate factories   0.300000   0.000000   0.300000 (  0.310373)
Grab 50 factories at once    0.020000   0.000000   0.020000 (  0.011400)

In this case, grabbing 50 existing records is almost 20 times faster than creating 50 new factories!

Just make sure you turn off transactional fixtures in your test_helper.rb or spec_helper.rb files:

Spec::Runner.configure do |config|
  config.use_transactional_fixtures = false
  config.use_instantiated_fixtures  = false
  config.fixture_path = RAILS_ROOT + '/spec/fixtures/'
end

This gem is still in it’s infancy, I’d welcome any feedback/suggestions.

Make Your Life Easier—Write Less CSS

Mon, 07 Sep 2009 00:00:00 +0000

As far as programming languages go, CSS is the least fun to write. Without variables, mixins or mathematical operations, it can be very time-consuming to write CSS and a nightmare to make changes.

Introducing… Less: Leaner CSS.

Less is a gem that helps alleviate the pain of writing CSS by making it DRYer and far more intuitive.

To install the gem, simply run:

sudo gem install less

You’ll also want to use the less-for-rails plugin by August Lilleaas:

script/plugin install git://github.com/augustl/less-for-rails.git

Usage

To create a stylesheet using Less, simply add a new file to your /stylesheets directory with the format “.less”. Eg, application.less. Write your CSS in this file instead of application.css – the less-for-rails plugin will ensure application.css is updated as you make changes.

Previously, a snippet of CSS may have looked something like this:

div#content{
  width: 80%;
  margin: 0 auto;
}

div.comment{
  border: thin solid silver;
  border-bottom: thick solid #BEBEBE;
  background: #E5E5E5;
  width: 80%;
  margin: 0 auto;
  height: 100px;
}    

.comment p{
  margin-top: 5px;
  font-family: sans-serif;
}

.comment p a{text-decoration: none;}

form#new_comment{
  border: thin solid silver;
  border-bottom: thick solid #BEBEBE;
  background: #E5E5E5;
  width: 80%;
  margin: 0 auto;
}

With Less, this can be simplified to:

@comment_height: 100px;
@inner_width: 80%;
.centered{
  width: @inner_width;
  margin: 0 auto;
}

.comment_borders{
  @comment_background: #E5E5E5;
  border: thin solid silver;
  border-bottom: thick solid (@comment_background/1.2);
  background: @comment_background;
  .centered;
}

div#content{.centered;}

div.comment{
  .comment_borders;
  height: @comment_height;
  p {
    margin-top: @comment_height/20;
    font-family: sans-serif;
    a {text-decoration: none;}
  }
}
form#new_comment{.comment_borders;}

In this example, the variable @comment_height is set to 100px and the margin-top value for p tags within a .comment div is set to @comment_height/20. If we change the height of .comment this margin will also change so that it’s always a 5% of the total height.

Another really cool feature is the ability to apply mathematical operations to colour values. So if we have a div with background-color #7f7f7f, we can multiply this value by two for the text-color property, meaning the text will always be twice as bright as the background-color (up to the #FFFFFF limit).

The class .comment_borders is a mixin. Mixins allow you to store commonly shared values in one place. These can then be included into any other css instruction by simply writing the class name followed by a semicolon.

For more information, check out the Less homepage.

DRYing Up Your Code With A Little Metaprogramming

Sat, 01 Aug 2009 00:00:00 +0000

Metaprogramming in a nutshell is writing code that writes code. Here’s a really simple example:

<% 100.times do |number| %>
  <%= content_tag :strong, "hello" %><br />
<% end %>

Will output:

<strong>hello</strong>

a hundred times.

This really simple example illustrates the power of metaprogramming; in theory, infinite lines of code can be written by just a few lines of your code.

The Rails source code is full of examples of metaprogramming, ever wondered how Active Record is able to provide methods like find_by_username()?

Here are a couple of examples of how you can clean up your code using metaprogramming techniques.

Some metaprogramming tips

Suppose you have an model, say Comment, that can exist in several states: “unflagged”, “flagged”, “approved” and “removed”. The comments table has an integer column called “state” that represents each of these states:

class Comment < ActiveRecord::Base
  # comment state is 1 by default and then changes as it is flagged, approved etc.
  STATES = {
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }
end

You want methods to check if the Comment is or isn’t in one of these states so you add the following:

class Comment < ActiveRecord::Base

  # comment state is 1 by default and then changes as it is flagged, approved etc.
  STATES = {
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }

  def unflagged?
    state == 1
  end

  def flagged?
    state == 2
  end

  def approved?
    state == 3
  end

  def removed?
    state == 4
  end
end

Great! Now you can call @comment.flagged? or @comment.approved? etc.
This is not ideal though, those four methods are really similar!

Defining methods on the fly.

By using define_method we can achieve the exact same thing as we have above but with much less fuss! Check this out:

class Comment < ActiveRecord::Base

  STATES = {
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }

  STATES.each_pair do |key, value|
    define_method "#{key}?" do
      state == value
    end

  end
end

For each key in the hash (the names of our states) a new method is created that checks if the object’s state is equal to value. Twelve lines of code condensed into 4 – Magic!

Lets also add methods to change the state of each comment:

class Comment < ActiveRecord::Base

  STATES = {
    :unflagged => 1,
    :flagged   => 2,
    :approved  => 3,
    :removed   => 4
  }.each_pair do |key, value|
    define_method "#{key}?" do
      state == value
    end

    define_method "to_#{key}" do
      # no point in troubling the database if the state is already == value
      update_attribute :state, value unless state == value
    end

  end
end

When we create a new hash, the hash itself is returned so we can call each_pair directly on the hash making this code even neater. We now also have methods that will change the state: to_unflagged, to_flagged, to_approved, to_removed.

If you have models in your applications that exist in one of several states then this technique could really come in handy to clean up your code. You may also be interested in the enum-colum plugin. Enum columns are like string columns but can only have limited amount of permitted values. This is a lot easier to keep track of than using integers like I have in this example.

Dynamic Page Caching With Prototype

Fri, 24 Jul 2009 00:00:00 +0000

Ryan Bates recently released a Railscast on Dynamic Page Caching. This technique caches each page and then updates the page’s dynamic content using Javascript.

Although I like this technique, it requires the jQuery javascript library whereas Rails ships with the Prototype library and so there’s a high chance your application already relies on Prototype.

Here is a variation on Ryan Bate’s technique you can implement with Prototype:

Assuming you already have a controller named UsersController and a show action, add the following view to views/users/show.js.erb:

document.observe("dom:loaded", function () {
  <% if logged_in? %>
    $$('.login_required').invoke('show');  //reveals all of the hidden links
  <% end %>
  $('content_div').insert('<%= escape_javascript render(:partial => "layouts/flash_notices") %>');  // inserts the flash partial
});

and then this line in the head of your layouts:

<%= javascript_include_tag "prototype", "/users/show/current" %>

I’ve made a few assumptions here but you can change the javascript to suit your needs. The first line here ensures that the javascript is run once the page has loaded.

The second line assumes you have a helper method called logged_in?. The code within this block will only be run if there is a logged in user.

Line three uses the prototype $$ function to find all tags with class name “login_required” and sets the CSS display value to “show”. This is the part that actually displays or hides the dynamic content depending on whether there’s a logged in user.

Finally, line five assumes you have a div on page with id “content_div” and inserts the partial “layouts/flash_notices” inside it. Without this, the flash messages will not be displayed when loading cached pages. Using the insert() function you can insert html content into various objects within the DOM. This method also includes a second argument to specify whether the content should be added as the first or last child. Read the Prototype API for more info.

“flash_notices” is a partial in the views/layouts folder that looks something like this. Next, add this helper method to ApplicationHelper:

module ApplicationHelper
  def admin_links( id = nil, &block )
    concat "<div class='login_required' style='display:none;' #{ "id='#{id}'" if id }>"
    yield
    concat "</div>"
    nil
  end
end

Now, if you want to hide links from non-authorised users you simply have to stick it inside an admin_link block like so:

# content here will be visible to everyone
<% admin_link do %>
  # content here won't be visible to non-authorised users
<% end %>
# content here will be visible to everyone

This will output:

# content here will be visible to everyone
<div class='login_required' style='display:none;'>
  # content here won't be visible to non-authorised users
</div>
# content here will be visible to everyone

You can also specify an id for the div by passing this as an argument to admin_links:

# content here will be visible to everyone
<% admin_link "id_for_my_div" do %>
  # content here won't be visible to non-authorised users
<% end %>
# content here will be visible to everyone

Just make sure you have set perform_caching to true in config/environments/development.rb.