For a background on the asset pipeline, please read through the rails guide and these two excellent railscast by Ryan Bates. These got me about 90% of the way there.

One of the main goals of the asset pipeline is to bundle together all of your application’s javascript and stylesheets, condense them, and serve them to the end user with a sophisticated caching approach.  This works very well for many of the applications on the web.  In the case of my application, we had several javascript files that were specific to individual pages, and didn’t play well (for one reason or another) with other areas of the site.  It has long been a requirement that these javascripts are only loaded for these specific pages.  We were accomplishing this by creating a yield section in our application.html.erb like so:
<%= yield :head_includes %>
Then, in the pages were we needed to load a javascript file, we would put the javascript_include_tag inside a content_for block, like so:
<% content_for :head_includes do %>
<%= javascript_include_tag "search.js" %>
<% end %>
This worked quite well for us in rails 3.0.  However, in Rails 3.1 with the asset pipeline enabled, this would throw an error:
search.js isn't precompiled
My first attempt at getting this to work was to run
bundle exec rake assets:precompile

This compiled all of my coffeescript assets, as well as application.js, however the default rails configuration doesn’t precompile files with .js or .css extensions (although .js.coffee or .css.scss would be precompiled).  I could have renamed all of my files to end with .js.coffee, but I wanted to move away from declaring individual files on various views, and I wanted javascript files that are run on similar pages to be bundled together.  The rails guide had this bit of advice:

You should put any JavaScript or CSS unique to a controller inside their respective asset files, as these files can then be loaded just for these controllers with lines such as <%= javascript_include_tag params[:controller] %> or <%= stylesheet_link_tag params[:controller] %>.

This was decent advice, however the assets still weren’t being compiled.  That would take a few more steps.  First, I created a manifest file for any controller that had controller specific javascripts.  For example, if a controller named EventsController had specific javascript files, I would create events.js (if it didn’t already exist).  To that file, I added the following statements:

//= require_tree "./events"

I would also include the following if the file already existed with existing javascript:

//= require_self

I would then dump any controller specific .js files into the folder specified by the require_tree directive.  I also had to add the manifest files to the list of files to precompile by adding the following to config/application.rb (with an entry for each manifest file, comma separated):

config.assets.precompile += ['events.js', 'pages.js']

For the sake of organization, I also moved a lot of javascript files to vendor/assets/javascripts and lib/assets/javascripts, as appropriate.  I then updated application.rb to list all of the files that needed to be included on every page, using require and require_tree directives.  I then was able to replace my various javascript_include_tag lines in my application.html.erb file with the following:

<%= stylesheet_link_tag 'application'%>
<%= stylesheet_link_tag controller.controller_name if individual_css_file_exists?(controller.controller_name) %>
<%= javascript_include_tag 'application' %>
<%= javascript_include_tag controller.controller_name if individual_js_file_exists?(controller.controller_name) %>

Note that controller.controller_name is similar to params[:controller], except where you have namespaced controllers. For example, Admin::EventsController would return “events” for controller.controller_name, and “admin/events” if you use params[:controller].  I chose the former for simplicity’s sake.  I also created the following helpers in application_helper.rb

def individual_css_file_exists?(name)
!GoVoluntr::Application.assets.find_asset("#{name}.css").nil?
end

def individual_js_file_exists?(name)
!GoVoluntr::Application.assets.find_asset("#{name}.js").nil?
end

This helped to avoid the dreaded “controller.js is not precompiled” error when a manifest file didn’t exist for that specific controller.

This may seem like an awful lot of work for the application to essentially work the same as it did before.  The benefit, however, is that I can remove a lot of redundant code from each of my view files, and I get a reasonable tradeoff between combining multiple javascript files and only loading certain code on specific pages.

<%= observe_form 'search-form',
:before => "Element.show('spinner')",
:complete => "Element.hide('spinner')",
:url => {:action => 'search'}
%>

My solution was to hook into the onChange callback of the slider itself (ignoring the hidden fields). I used onChange instead of onSlide because I didn’t want a dozen requests going to the server per slide. I simply added the following javascript.

Element.show('spinner');
new Ajax.Request('/search',{asynchronous:true,
evalScripts:true,
onComplete:function(request){Element.hide('spinner')},
parameters:Form.serialize('search-form')});

A simple note: I suck at javascript. Not that I’m particularly dense, I just haven’t taken the time to learn it. I simply gleaned this little gem by using firebug to see what Rails had generated using the aforementioned observe_form, and simply modified it slightly. Win!

I recently switched my project over from SVN to Github. My reasons were varied, but a large reason was because I needed to create various branches to accomodate my ADD style of development (work on layouts for a bit, then switch to security, then switch to fine tuning my models). I also need to create a branch for productions servers, as well as a branch for my staging server, which is set up at home. The latter was a bit confusing at first, until I found a great tutorial here.

First, a couple of notes about my setup. I am the sole contributor to my (private) repository. Up until now, I have not had a need for this “forking” business that I see from time to time. In configuring up my multistage setup, I ran into an issue when I tried to use set :branch, "2.0" in my staging deploy.rb file. Even though I had created a branch for “2.0″ like so:
git branch 2.0
I was getting the following error:
`query_revision': Unable to resolve revision for 'invalid' on repository 'git@github.com:*****/******.git'. (RuntimeError)
This confused me for quite some time, until I found out that the set :branch isn’t referring to the branches that I had created locally, but to github forks. To create a fork from the branch, I simply had to do the following:
git checkout 2.0
git push origin 2.0

The origin bit is what does the magic. As soon as I refreshed, I was able to see the newly created fork in the github web UI, and my deploy recipe worked like magic. Brilliant!

Note: I still have to find out how this will affect my git workflow, but since the clone URL is still the same, it seems that I should still be able to continue with my current way of doing things.

To give you a little bit of background on my setup, I am using Capistrano to deploy to two servers, both of which are running Phusion Passenger.  One server is on a shared host, along with the SVN repository, and the second server is inside of a private network with a sub-optimal internet connection.  Both servers share a common database.  I ran into an issue running “cap deploy”, because it was trying to copy the entire application over ssh to both servers every time.  This wasn’t a large issue for the shared host, but the server in the private network would keep hanging after it got past a certain point.  This all took me days to figure out, because capistrano give very minimal debugging/logging information, and the error messages changed every time, usually letting me know that the I/O stream had closed.

I first set this scenario up using the Agile Development with RoR book, but since I was using an outdated PDF, turns out I wasn’t using the optimal setup.  Originally, the book called for the following line in my config/deploy.rb file:

set :deploy_via, :export

The idea here is that you want to export the project from the SVN repository,  but leave behind all the unnecessary subversion .svn junk.  Seemed reasonable enough to me.  However, in the updated PDF, they made a subtle, but gamechanging alteration:

set :deploy_via, :remote_cache

What this does, is it actually checks out a version of your project into shared/cached-copy on the target server(s), and going forward only runs an SVN update command, which only updates the files that have been changed.  Capistrano then uses this copy to deploy your code the same as before.

It seems like the obvious choice, and now that I know where to look, there is plenty of information about it.  But if you are stuck waiting for an hour for cap deploy to finish, or are getting random errors, it’s hard to find an answer online.  In my case, I actually manually checked out my code into the shared/cached-copy directory on both servers, as I was tired of capistrano screwing it up.  Once I got the initial code in there, further cap deploy’s take only 1 minute or so, compared to 30+ minutes previously.  Sweet!