Setting up your development environment is always a tedious task. My own environment has changed many times over the years. I've recently gotten my Ruby-related setup to the point I'm finally really happy with it.

This is by no means a complete in-depth step-by-step guide of how to setup your environment like mine though. Instead it's meant as a quick reference of the tools I use, and how I use them. If you were looking for a magical silver bullet, this article is not it. If you're looking for an exciting adventure and treasure hunt, this article is hopefully it.

Ruby

I install and manage multiple Ruby versions with rbenv and ruby-build. They are not as established as RVM which has been around a lot longer, but I prefer rbenv for it's bare-bones simplicity. If you're coming from RVM, the main thing that you'll miss is it's gemset feature, which won't be an issue if you use Bundler properly. There is however a gemset plugin available for rbenv.

To install rbenv, check the ReadMe on the project page. I prefer the Git checkout method. ruby-build has installation info on the project page too, but on OS X I prefer installing it with Homebrew.

Once both are installed, you can install your Ruby version of choice, for example:

$ rbenv install 1.9.3-p0

Then set your global Ruby version:

$ rbenv global 1.9.3-p0

I tend to install a very basic set of gems, as all project-specific gems will be managed by Bundler. So obviously bundler needs to be installed:

$ gem install bundler

With rbenv this does not create the bundle executable however, so the next step is to run:

$ rbenv rehash

This creates the bundle executable in ~/.rbenv/shims, and also any missing executables for other gems you have installed.

Gem Management with Bundler

Bundler is fantastic, but if you just run bundle install as default, I would argue you're not actually using Bundler correctly as it installs the gems into your Ruby verion's gem path. One of Bundler's great features is that you can keep gems completely self-contained within a project. For that reason I use the --path option, to install gems into vendor/bundle relative to the Gemfile.

And because I'm lazy, I have a handy bash alias for my bundle install command.

alias bi="bundle install --path vendor/bundle --binstubs=vendor/bundle/bin"

The --binstubs option there leads me into how I avoid typing bundle exec before every command. It tells Bundler to package binaries from all the installed gems into vendor/bundle/bin directory within the project. Simply add the following at the very end of your ~/.profile or ~/.bash_profile:

export PATH="./vendor/bundle/bin:$PATH"

This enables you to call all of the project's gem binaries like normal, but they're Bundler aware, as if they'd been called with bundle exec.

I also have a few bash aliases for bundle exec ... which I find useful:

alias ru="bundle exec ruby"
alias ra="bundle exec rake"
alias rs="bundle exec rspec"
alias ca="bundle exec cap"
alias cu="bundle exec cucumber"

Update: Instead of using an alias to set Bundler options, you can set default Bundler config options in ~/.bundle/config. Mine looke liks this:

---
BUNDLE_PATH: vendor/bundle
BUNDLE_BIN: vendor/bundle/bin

Run bundle help config for more information.

Running Ruby Apps

For running web-based apps I use Pow and/or Foreman. Pow is my favorite of the two, but for certain projects Foreman is the better match.

I tend to go on a case-by-case basis. For example, some projects might need a few background workers, I tend to start all of them with Foreman, while I might run the web-based frontend with Pow.

MySQL, Redis, and More...

Because I run Mac OS X, I use Homebrew to install things liky MySQL, Redis, Memcache, and others. If you're not on OS X, you'll have to find your own preferred way to install these kinds of tools. But I'd imagine your operating system has some form of package management system you can use.