Enabling Cache

We use asset helpers such as javascript_include_tag and stylesheet_link_tag in our layouts to include external Javascript and CSS files. One benefit of using these helpers is the ability to cache these resources. Asset cache is turned on when the perform_caching configuration option is set to true.

Rails applications default to having caching disabled during development, and enabled in production. We can change this in config/environments/development.rb to test out caching during development.

config.action_controller.perform_caching = true

Caching Assets

We enable asset caching in our applications using the :cache option in our helpers. We can cache Javascript files by doing the following:

<%= javascript_include_tag "prototype", "application", "effects",
                           :cache => "cache/all" %>

When caching is disabled, Rails will generate the normal references to these resources.

<script src="/javascripts/prototype.js?1197321216" type="text/javascript"></script>
<script src="/javascripts/application.js?1197321216" type="text/javascript"></script>
<script src="/javascripts/effects.js?1197321216" type="text/javascript"></script>

However when caching is enabled, Rails will generate a single external Javascript file in the location we specified. It will then reference this file instead of the original source files.

<script src="/javascripts/cache/all.js" type="text/javascript"></script>

As you can see in the above example, we’re going to store our asset cache in subdirectories named cache/. This makes it easier to clear out the cache later on. Caching external CSS files works similar to the Javascript example:

<%= stylesheet_link_tag "typography", "layout", "color",
                        :cache => "cache/all" %>

Clearing Cache

Rails comes with some useful built-in tasks for clearing out temporary files under the tmp: rake namespace. Rails does not come with a built-in task for clearing out the asset cache. We’ll add this ourselves by adding a new rake task named rake tmp:assets:clear. Create a new file in your Rails application named at lib/tasks/tmp.rake, and add the following code.

namespace :tmp do
  namespace :assets do 
    desc "Clears javascripts/cache and stylesheets/cache"
    task :clear => :environment do      
      FileUtils.rm(Dir['public/javascripts/cache/[^.]*'])
      FileUtils.rm(Dir['public/stylesheets/cache/[^.]*'])
    end
  end
end

The custom tmp:assets:clear task we added removes all files from both the javascripts/cache/ and stylesheets/cache/ directories. Let’s give it a whirl:

$> rake tmp:assets:clear

Wrap Up

Using asset cache can significantly reduce the number of requests sent to the server for external CSS and Javascript files. Along with a good gzip strategy, this is an essential feature when working with large multi-file Javascript libraries.

For additional performance increases using asset helpers, check out Chad Fowler’s write-up of Distributed Asset Hosts.

We’ll go over the basics needed to test your Rails applications in IE6/IE7 on Parallels in the most convenient way possible.

• Getting Started
• Open Ports on the Network
• Browsing in IE
• Browse By Name with Bonjour

Getting Started

I’ll start out by saying that the first prerequisite for this setup is having an Intel powered Mac. This article is useless without one unless you’re just here to drool over neat tools.

Being able to use Parallels comes at a cost. You’ll need to shell out $79.99 for a copy of Parallels for Mac, and a couple hundred more for a copy of Windows. I believe this is a nominal business cost for what the software offers, and is much cheaper than having to buy and maintain a separate PC to run Windows. Both Parallels and Windows have a trial versions you can use to verify that this setup is worth your money.

Once you download Parallels for Mac, you can unpack and install the software as usual. Parallels has a great guide for getting started with the software. It will take you through Installing Parallels Desktop, Creating new Virtual Machines, and Installing Windows on the machine. I started out by installing a single Windows XP virtual machine and set it up with IE6 and all other default settings I use. I then just copied that setup to create a new VM on which I upgraded to IE7.

Open Ports on the Network

When developing Rails applications on the Mac, the typical setup is to develop everything on localhost, and serve the applications using mongrel.

$ cd maintainable
$ mongrel_rails start -d -p 3000

We can of course access this directly in our native Mac browsers by navigating to http://localhost:3000. To make this application accessible from IE on our Windows VM, we’ll have to accept network traffic through our firewall on port 3000. Open up your Apple System Preferences and go to the sharing window.

Navigate to the Firewall Tab in the Sharing pane, and click on the New button so that we can add an additional port(s).

Here is where we make our Rails ports available on the network. We’re going to open up ports 3000-3099 for any additional Rails applications we choose to bind to a port in that range. Enter

• Port Name: Other
• TCP Port Number(s): 3000-3099
• Description: Rails Applications (30xx)

Browsing in IE

Now we should be able to browse to this from IE in our Parallels machine by pointing to our internal IP Address. We can find out this internal address by taking a look at the Services tab on our Sharing pane. Near the bottom it will say something like “Other Macintosh Users can access your computer at afp://192.168.1.100″.

This is the number we’re looking for, and we can alternately find it using this command from the terminal.

$ ifconfig | grep 192 | awk '{print $2}'

Once we have our internal IP, let’s fire up our IE browser and check out our site. In IE, navigate to http://192.168.1.100:3000.

Browse By Name with Bonjour

The problem with browsing by internal IP address is that it’s likely to change from day to day. A better approach is to install Bonjour for Windows so that we can simply refer to our computer by name instead of number.

We’ll first go back into our Services tab on the Sharing pane in Apple System Preferences. Here we’re going to shorten our name to be something easy to remember and type into the browser. Click on the Edit Button near the top.

I’m going to simply rename this to derek.local. Feel free to be more creative with your own.

To seamlessly network with our Windows VM without the hassle of dealing with network settings manually, we’re going to install Bonjour for Windows. Download BonjourSetup.exe, and choose the default settings for the installation. With Bonjour installed, we can now browse to our application at http://derek.local:3000.

This number can be cut down a little bit with Douglas Crockford’s JSMin filter. This filter creates a smaller version of your Javascript source by stripping out extraneous code like whitespace and comments. The minified versions of Prototype is 52K, and Effects is 28K. This saves us around 25K off the bat.

Since we like to keep as much of our code as possible in the Ruby family, we use the Ruby version of the minifier. Copy The jsmin.rb file to script/javscript/jsmin.rb in your Rails application.

Now let’s add a handy Rake task to minify your javascript code using this script. The following task will combine prototype.js, effects.js, and application.js. This will create our final minified file as all_min.js. You can add additional javascript files to the libs array as needed, or adjust what you want the final file to be named. Then copy the code into a file named lib/tasks/js.rake.

namespace :js do
  desc "Minify javascript src for production environment"
  task :min => :environment do
    # list of files to minify
    libs = ['public/javascripts/prototype.js', 
            'public/javascripts/effects.js', 
            'public/javascripts/application.js']
 
    # paths to jsmin script and final minified file
    jsmin = 'script/javascript/jsmin.rb'
    final = 'public/javascripts/all_min.js'
 
    # create single tmp js file
    tmp = Tempfile.open('all')
    libs.each {|lib| open(lib) {|f| tmp.write(f.read) } }
    tmp.rewind
 
    # minify file
    %x[ruby #{jsmin} < #{tmp.path} > #{final}]
    puts "\n#{final}"
  end
end

Before we run the task, there is a single point in Prototype version 1.5 stable that breaks the jsmin filter. There is a patch for this in the Rails trac, but we will need to manually add the single missing semi-colon until it is applied. You may want to also run your application code through JSLint Verifier and clean up any issues that may jam the jsmin filter.

Now we can minify our javascript by running this new task. It will create a new javascript file with the combined source. From the root of your rails application run:

$ rake js:min
(in /Users/derek/work/sportspyder/trunk)
 
created public/javascripts/all_min.js
<pre>
 
In our development environment we don't want to have to re-minify our javascript after every change. We'll still use our separate and easy to read source files. We can do this by putting a conditional in our layout to include the minified version in production mode, and the separate files during development.
 
 
<pre lang="ruby">
<% if RAILS_ENV == 'production' %&gt;
<%= javascript_include_tag "all_min" %&gt;
<% else %&gt;
<%= javascript_include_tag "prototype", "effects",
                           "application" %&gt;
<% end %>

One of the added benefits of this approach is that you have a single Javascript source file for the client to download instead of multiple resources for the browser to pull.

You’ll have to make sure to run this rake task before you deploy, and may want to add it directly to your deployment script.

While minification provides a nice break in file size, it is secondary to sending your javascript compressed. Compression can cut your Javascript to nearly 1/4 of the original size, and is most commonly done using using Apache’s mod_deflate module. There is more information on Apache settings on the Mongrel website.

Update - 03/01/2007

Prototype doesn’t actively support a specific packing strategy for various reasons, and patches submitted for making the code pass something like JSLint are likely to be ignored. Reasons for this, and some other strategies on reducing filesize of the library are discussed in Packing Prototype.

Update - 12/14/2007

Rails 2.0 includes a feature that makes much of what is described here obsolete. Check out our write-up of Rails Asset Cache.