The asset pipeline, introduced with Rails 3.1, makes it simple to include versioned external assets as application dependencies. Provided those assets are packaged as Ruby gems, the process is as simple as adding the gem to your Gemfile, running bundle install and, in the case of CSS and JavaScript, adding a require to the proper manifest file.

Many popular CSS frameworks and JavaScript libraries are already available as gems. Search RubyGems to see if the assets you’re interested in are already packaged this way. What if the JavaScript library you use isn’t yet available as a gem? Packaging and publishing asset gems is simple. Here’s your chance.

Most web applications call for at least one level of navigational structure. Many will have two or more levels and require the active node in each level to have distinct styling via an active class. I’ve seen as many navigation solutions as I’ve seen rails projects. Most look similar in that each level of navigation is represented by a partial. Some track the active node via local variables passed with the call to render, but this approach isn’t very DRY. Some track the active node via instance variables on the controller, but this is a painful violation of MVC which gets especially tedious to maintain in multilevel scenarios.

Thankfully, there’s a mature, simple, and actively maintained solution just a gem away. Simple Navigation handles just about whatever you can throw at it. I was surprised, however, by how hard it was to unearth when I was looking for the solution to my navigational troubles. It’s an elegant solution that deserves more attention.

Mac OS X ships with a console version of Vim, but it is outdated and it was not compiled with Ruby or Python support. Command-T, for one, requires vim to be compiled with Ruby support and thus will not work with the version of Vim shipped with the operating system. You may also have configuration settings in your .vimrc that are incompatible with Vim 7.2. Thankfully, there are a few rather simple options for updating Vim.

Bundler has been around for quite some time now, but I continue to see what I consider to be be bad advice with regards to specifying version constraints in your project Gemfile. My position is simple: Do not constrain gem versions in your Gemfile until you have a good reason to do so. I typically encounter two arguments against this position. The first is misinformed, showing a critical lack of understanding of how bundler works. The second is a defensible position, but seems to offer no advantage over my approach.

I’ve been doing a lot of development in MacVim of late, but there are times when I long for the warm embrace of an IDE. For many reasons that I won’t detail here, I find RubyMine to be the best Ruby IDE out there. While its keyboard-based file navigation is functional, I much prefer the interface provided by PeepOpen that I had grown acustomed to when using MacVim and TextMate.

Fortunately, with a little work we can use the External Tools configuration in RubyMine to invoke PeepOpen.