Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Pivots Talking Tuesday: Hacking with Gems

Do you ever stop and wonder if the library you’re about to “gem install” is safe? Have you thought about what’s the worst that could happen by using a gem? Today, I (yes, yours truly) explore those questions in a talk I gave a RuLu this summer.

Read more »

Automating Bundler In Your Deploy

If you are using Bundler to lock and package your gem dependencies in your app (which you should), here's some tips on making everything automatic in your Capistrano deploy.

Refer to the Bundler Documentation for instructions on how to use Bundler to properly package your gems and check everything in.

Once this is done, however, you still must ensure that two things are done on every machine to which you will deploy:

  1. Bundler is installed
  2. You run 'bundle install' on every deploy to install the packaged gems on the local machine (and compile any gems with native dependencies)

Here's the Capistrano magic to accomplish these two tasks automatically on every deploy:

before "deploy:bundle_install", "deploy:install_bundler"
after "deploy:update_code", "deploy:bundle_install"

namespace :deploy do
  desc "installs Bundler if it is not already installed"
  task :install_bundler, :roles => :app do
    sudo "sh -c 'if [ -z `which bundle` ]; then echo Installing Bundler; sudo gem install bundler; fi'"

  desc "run 'bundle install' to install Bundler's packaged gems for the current deploy"
  task :bundle_install, :roles => :app do
    run "cd #{release_path} && bundle install"

Oh, and for you GemInstaller users out there - here's an easy way to generate a Bundler Gemfile from your geminstaller.yml config:

geminstaller --bundler-export > Gemfile

You'll probably still need some tweaks, but this will get you started. Just make sure you upgrade to GemInstaller 0.5.5 first (0.5.4 forgot to put the 'source' line in the Gemfile).

Happy Bundling! -- Chad

P.S. There is a similar article here, which includes tasks to symlink your .bundle dir into the Capistrano shared directory, but my deploy was pretty fast anyway, so I didn't worry about it. YMMV.

[ANN] GemInstaller 0.5.3 Released

This fixes several bugs that people have complained about for quite a while. Please let me know if anything is broken.

GemInstaller 0.5.3 has been released!



  • 0.5.3 / 2009-08-25
  • Many long overdue bugfixes and patches, see for details.
  • Thanks to Greg Fitzgerald, Britt Crawford, John Trupiano, Gabriel Gironda, and Eric Hodel for patches and assistance.
  • Issues with case statement under Ruby 1.9
  • GemInstaller cannot distinguish between gems that have the ame name but capitalized differently.
  • add ./ci as default location for config file
  • Disable GemInstaller install in default rails preinitializer.rb, but fork if it is used
  • autogem() fails when run for newly-installed gem
  • Sometimes installing fails due to RubyGems cache not being cleared between multiple API calls


Automated Gem installation, activation, and much more!


GemInstaller provides automated installation, loading and activation of RubyGems. It uses a simple YAML config file to:

  • Automatically install the correct versions of all required gems wherever your app runs.
  • Automatically ensure installed gems and versions are consistent across multiple applications, machines, platforms, and environments
  • Automatically activate correct versions of gems on the ruby load path when your app runs ('require_gem'/'gem')
  • Automatically reinstall missing dependency gems (built in to RubyGems > 1.0)
  • Automatically detect correct platform to install for multi-platform gems (built in to RubyGems > 1.0)
  • Print YAML for "rogue gems" which are not specified in the current config, to easily bootstrap your config file, or find gems that were manually installed without GemInstaller.
  • Allow for common configs to be reused across projects or environments by supporting multiple config files, including common config file snippets, and defaults with overrides.
  • Allow for dynamic selection of gems, versions, and platforms to be used based on environment vars or any other logic.
  • Avoid the "works on demo, breaks on production" syndrome
  • Find lost socks.

Quick Start



  • [sudo] gem install geminstaller

Standup 08/07/2009: Rubygems 1.3.5 fail?

Interesting Things

  • One project had trouble installing the Rails 2.3.3 with the most recent version of Rubygems (1.3.5) on a Gentoo box (EY Solo instance). Installing the gem on an OSX box worked fine with the same versions. No obvious solution presented itself, other than to roll back to Rubygems version 1.3.1.

  • If you do update your Rubygems version to 1.3.5 and you use Geminstaller you must update your Geminstaller gem to 0.5.2; Rubygems made some changes that break Geminstaller's implementation. If you use an older version of Rubygems then keep using Geminstaller 0.5.1.

  • One project wanted to find all places where they needed to escape user input on their site, so they injected <script>alert('foo');</script> into every text field in the database, ran through their site, and looked for every place that a pop up box appeared.

Take a Looksee at how a Ruby Object got its Methods

One property of the Ruby object model and object oriented programming in general is that a subclass of an object automatically inherits all of the methods of its superclass. Classes can further expand the number of methods available by mixing in a Module, or several.

Because of mixins and subclassing even a class that has declared just a few methods can actually have hundreds of methods on it. In Ruby, all classes subclass Object by default which declares a hefty 45 methods, guaranteeing you to have at least that many. Out of the box in 1.8.7, a Ruby String object has 176 instance methods. If you are programming on top of the Rails framework, ActiveSupport adds 98 methods bringing the total to 274!

On numerous occasions I have needed to see what methods are available on an object I am working with I will type the following in irb.

myobject.methods - Object.instance_methods

This prints out a large array of instance methods with the methods inherited from Object removed from the list. This is useful but what if the object I am working with mixed in several modules and I am left with a list of over a hundred methods? It would be great to view which Class or Module each method came from. Well, actually there's a gem for that.™


Looksee is a new gem by George Ogata that examines the method lookup path of any object. To use it add require 'looksee/shortcuts' to your ~/.irbrc. This will add a lp ("lookup path") method to your irb environment. When passed an object lp prints out a colored display showing where each of an object's methods lives.

Introducing ActiveApi – A sane way to translate your data to xml

ActiveApi allows you to define a schema in Ruby, and use that schema to convert ruby objects to xml. An example looks like this:

Schema.version(:v1) do |schema|
  schema.define :article do |t|
    t.attribute :id
    t.string :title :published_on
    t.has_many :comments

"open_gem" Gem Plugin

From the Too Useful Not to Blog Department:

open_gem from Adam Sanderson is a new RubyGems Plugin to automatically open a gem's source in your favorite $EDITOR.

gem update --system
sudo gem install open_gem
export EDITOR=mate
gem open rails

NOTE: If you have RubyGems 1.1 or 1.2, 'gem update --system' may not work. See the RubyGems Release Notes for more info.

Introducing AutoTagger – easy multi-stage deployment tagging with git

AutoTagger is a gem that helps you automatically create a date-stamped tag for each stage of your deployment, and deploy from the last tag from the previous environment.

Let's say you have the following workflow:

  • Run all test on a Continuous Integration (CI) server
  • Deploy to a staging server
  • Deploy to a production server

You can use the autotag command to tag releases on your CI box, then use the capistrano tasks to auto-tag each release.

New York Standup 10/7/2008

Interesting Things

When you specify a gem from a custom source, and it has dependencies on a separate source, you need to list both sources in geminstaller.yml.

This comes up when you are installing a gem from github and that gem depends on other gems from rubyforge. You can specify multiple sources by adding more --source attributes.

Removing Old Ruby Source Installation After a Leopard Upgrade

Removing Ruby

I just upgraded to Leopard on my Mac. Previously, on Tiger, I had installed Ruby from source, in the default /usr/local/lib prefix. After reading the discussion on the Apple-provided Ruby installation, I decided to try it - mainly to ensure that my apps, such as GemInstaller, play well with it (on Pivotal's Mac pair workstations, we still install Ruby from source, so everything matches our demo/production environments as closely as possible, and things are in consistent locations).

So, I wanted to uninstall the old Ruby source installation, and only have the Apple-provided Ruby on disk. Googling for a few minutes did not provide exact instructions for this, so I'm writing up what I did, in hopes that it will help you!

I didn't use the "--prefix" option when I originally installed Ruby from source, so it was in the default location of /usr/local/lib/ruby, with binaries in /usr/local/bin.

WARNING: Use 'rm -rf' at your own risk - a sleep-deprived encounter with 'rm -rf' and a stray file named '~' is what "motivated" my Leopard upgrade in the first place...

First, I deleted the old ruby libraries/gems, which was easy enough, because they all lived under /usr/local/bin/ruby:

sudo rm -rf /usr/local/lib/ruby

However, this left all the old ruby/gems executables in /usr/local/bin. This resulted in errors when trying to run executable gems that I had not yet installed under the Apple Ruby installation:

$ cheat
/usr/local/bin/cheat:9:in `require': no such file to load -- rubygems (LoadError)
from /usr/local/bin/cheat:9

Instead of a cryptic rubygems error, I should get a 'file not found error':

$ sudo rm /usr/local/bin/cheat
$ cheat
-bash: /usr/local/bin/cheat: No such file or directory

So, I want to purge everything ruby-releated from my /usr/local/bin folder. I whipped up a quick ruby one-liner which just prints out (almost) all ruby-related files in /usr/local/bin:

ruby -e "old_ruby_execs = `egrep 'rubygems|bin/ruby|env ruby' /usr/local/bin/*`; require 'pp'; pp old_ruby_execs.split("n").collect{|line| line.split(':').first}.uniq"

Yeah, I know, ugly and obtuse, but one-liners are kind of fun, and help me remember that Ruby is great tool for sysadmin scripts. Feel free to put it in a class and test it if you are so inclined.

Even though I tried to make a fairly specific regexp for egrep, when inspecting that list, I did find a 'jgem' file, which was part of JRuby. I'm planning on reinstalling JRuby anyway, so I didn't care if that got deleted along with the other ruby stuff.

Anyway, if the output of that looks like everything you want to delete, then run this one-liner to do the actual deed (the 'sudo echo' is to 'prime' the sudo auth, so you don't get a noninteractive password prompt):

sudo echo; ruby -e "old_ruby_execs = `egrep 'rubygems|bin/ruby|env ruby' /usr/local/bin/*`; old_ruby_execs.split("n").collect{|line| line.split(':').first}.uniq.each { |exec| p 'removing ' + exec; `sudo rm #{exec}`}"

After that, the only thing that I saw left was the 'ruby' executable itself, which I whacked as well:

$ sudo rm /usr/local/bin/ruby

That seems to be about it, as least good enough to get all the old invalid executables off my path. I'm sure this could have been done cleaner if I had taken more care with the original source install. However, a good brute-force approach never hurt anyone. Much. Feel free to post links to relevant and helpful stuff.