How to check versions of gems in Heroku

Recently I got stuck trying to fix a problem in Heroku, a slick cloud-based Ruby hosting service. The problem involved gems that I had added to my app’s private gem repository. I had to check the versions of the gems in the repository, but Heroku’s documentation on gem management didn’t provide any suggestions.

Turns out, the trick is to use Heroku’s console command, and then use the Ruby Gem command. To open a new console session, fire up a terminal and enter:

heroku console

Then list the versions of the gems in your private repo, by enclosing the gem list command in backticks. (On Macs, the backtick key is in the upper left corner of the keyboard. I know, it took me a few seconds to find it as well.)

`gem list`

Since Heroku has many built-in gems, you’ll probably want to pipe through grep to find what you want:

`gem list | grep foo`

And you’re off to the races!

Observations from this month’s Silicon Valley Ruby on Rails meetup

Here are a couple of interesting things I learned at this month’s Silicon Valley Ruby on Rails meetup, specifically the first presentation by Michael Hartl of InsoshI.

The first is how GitHub leverages the power of decentralization. Let me explain how I understand this work: GitHub encourages people to fork off of existing projects. So, if someone wants to add a fix to an open source project, they make their own, add the fix, and publish it on GitHub. Eventually they ping a core contributor to have their changes added back into the main branch. GitHub’s very good at merging changes back into a branch, so this is fairly painless.

Here’s why this is so significant. Traditionally, it’s taken a long time for fixes to get much distribution. This is because there was only one central repository for any open source project. Before any fix could be checked into the main branch, it would have to get reviewed and approved. This would take time. What GitHub does is remove this bottleneck. So more fixes get published more quickly.

You’d think forking would be a bad thing — a proliferation of nonstandard branches. But it isn’t. GitHub’s merge capabilities mean that these fixes find their way into the main branch.

Seeing this presentation makes me wonder why any open source project would NOT be on GitHub.

—

The second thing I learned was from watching how Michael does test-driven development. It’s all testing, all the time. I believe the tools being used were Rake, Growl, and Textmate. Tests are automatically run every minute or so in the background. Test results summaries are displayed in Growl alerts: a green box displaying how many tests passed, a yellow one with how many tests are undefined, and red with how many failed. The alerts fade from the screen after a few seconds.

It’s not a big production, moonshot-style, let’s-run-the-nightly-test-suite kind of thing. Rather, it’s simple, continual testing that provides a steady drumbeat of feedback to the developer. Ambient is the best word that comes to mind.

Words like these don’t really do it justice — you have to see it for yourself to fully appreciate what’s going on. It’s a subtle change, but one that I think will make a big change over time in terms of the quality and velocity of software development.