Troubles pushing code to Heroku

After a little sleuthing, I found one post that seemed to be the very same problem that I was having.  In normal(?) environments, Bundler will accept conditionals in determining whether to install a gem or not.

E.g.,

gem 'rb-fsevent', :require => false if RUBY_PLATFORM =~ /darwin/i # so that Guard can detect file changes on OS X (Mac)

Apparently, as FreeAssoc states in his post, Heroku doesn't handle the conditionals well, even when those conditionals show up in a non-production block in the Gemfile.

Sure enough, as soon as I commented out the conditional, I was back in business.

gem 'rb-fsevent' #, :require => false if RUBY_PLATFORM =~ /darwin/i # so that Guard can detect file changes on OS X (Mac)

Finally getting to know the asset pipeline

For the last year I have accepted the asset pipeline as Ruby 'magic' that just works. I decided it was time to take my head out of the sand and actually understand a little of how it works and, more importantly, how I can leverage it. I would start with these two references; they were key in bubbling up the important concepts.

• http://coderberry.me/blog/2012/04/24/asset-pipeline-for-dummies/
• http://railscasts.com/episodes/279-understanding-the-asset-pipeline

Then, while I was in the area, I also got a brief overview of Coffee Script and Sass.

• http://railscasts.com/episodes/267-coffeescript-basics
• http://railscasts.com/episodes/268-sass-basics

Of course, there's nothing like going to the source to get the raw information. The above resources are great at quickly providing an overview from which it may be easier to take advantage of the reference material below.

• Rails guide for the Asset Pipeline
• Sprockets documentation; learn more about available directives
• Coffee Script documentation
• Sass documentation
• Sass functions

Here are some of the jewels I gleaned from my experience.

• files under the app/assets directory consist of manifests (with directive configuration), JavaScript, CSS, image and other resources. The manifests are responsible for grouping sets of assets. It just so happens that out of the box, the application.js and application.css files include everything -- hence why many feel the asset pipeline is just more Ruby 'magic'.
• Each layout template usually has '<%= javascript_include_tag :application %>'; this truly means that only 'application.js' or 'application.js.erb' will be pulled in. The directives at the top of 'application.js' determine what other js resources will be compiled into 'public/assets/application.js' at deployment. If you require a different set of JavaScript files for a different layout, set up directives for a new *.js file to pull in the desired resources and point to the desired JavaScript 'custom_manifest' in the call to '<%= javascript_include_tag :custom_manifest %>'
• With the CSS assets, to provide a certain set of styles to an isolated controller and its associated views, namespace the targeted css attributes by setting the id for the tag and including that namespace in the appropriate *.css file. Or better yet, group the css attributes in a *.scss file.

I'm looking forward to now leveraging the true power of the asset pipeline.