I have just started at the DaVinci Coders “Building the tool-belt of a junior Ruby on Rails Developer” program. An eleven week immersion course designed to take someone with good computer skills and minimal or dated programming experience into the fast moving world of web-development.

Part of our first assignment was to generate this blog, and then to write about our experiences, and the technical and other things that we stumble upon.

Here is my first observation: There is danger in having choices.

This is particularly true in choices for web development environments. It is even more perilous when you are a student in a web development course.

In my case, for various reasons, I had spent the prior two months teaching myself as much as possible about Ruby and Rails so that I would not feel out of my depth in the level II class I was assessed into at DaVinci Coders.

Like most folks, I took the standard path to a working Ruby install, and for a while I used RVM like everybody else. However, for various philosophical, and other reasons I decided to start using rbenv instead.

(For insight into this, see my earlier post. I was an Atari man, after all…)

rbenv takes a more lightweight approach to managing Ruby installs, holding to the Unix tenet of “do one thing well.” Unlike RVM it does not have a concept of gemsets. Instead it relies heavily on another standard of Ruby development: Bundler.

The bundler gem is pure genius, in that it manages gem install and dependencies almost by magic. Bundler takes it cue from the Gemfile that should be configured in each project directory.

So what’s the problem? Isolation, and then duplication of effort.

RVM does an excellent job, via gemsets, of isolating a development environment from other versions of Ruby and associated gems from other projects. Like Bundler, RVM manages various paths to executable gems by some serious techno-magic.

To make sure that project specific gems are run in the context of their gemset or gemfile, you typically need to call a command like this:

1
2

$ bundle exec rake db:migrate, # or
$ bundle exec rspec spec/ 

Even with RVM installed you need to pay the “bundle exec” keystroke tax, just to be sure you are running your code in the right environment.

There are ways to avoid this, you can install bin stubs for your gems and other executables or you can do some clever $PATH editing on a per project basis.

Seems to me like RVM and Bundler are sort of doing some of the same work, which certainly seems to violate the DRY coding principle, “Don’t Repeat Yourself.”

What’s the solution? Blindingly simple: make an alias in your login profile. Oh, and stop using gemsets, since you don’t really need them.

In either .bashrc or .bash_profile simply add the following:

1
2

# an alias to run 'bundle exec'
alias bex='bundle exec'

Now you can type the keystroke efficient bex before any command and be sure it is running in the proper context of your application directory. It rapidly becomes second nature.

I have to give a nod to Michael Hartl and his Ruby on Rails Tutorial, since he proposes this exact solution. However I had seen it before in several other contexts but did not know how or why to take advantage of it.

Additionally, you now know how to create an alias for other often used commands, or for applications with awkward names. For instance subl for the Sublime Text 2 editor:

1
2

# subl runs Sublime Text
alias subl='/Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl'

Lastly, I have to add that in exploring how RVM, rbenv, and Bundler function I also learnt an incredible amount about how things work “behind the curtain.”

I believe this is essential to problem solving. It is not enough to know that things work, you have to understand the how and the why.

For even more on Bundler and gemsets, check out this Ruby Rogues Podcast.

Thanx for reading. Stay tuned for more from the front lines…