As people spend more time with Ruby 1.9, JRuby, and Rubinius, we are seeing a lot more benchmarks. It has been a while since we published any metrics, so I thought now would be a good time to summarize our recent experience on some real projects. We chose to measure some different things, however:

• DPC. Developer Productivity, as judged by the Client. This is the percentage of iterations where the client felt that the developers were more productive in Ruby than they would have been with their second choice "Platform B."
• DPR. Developer Productivity, as judged by Relevance. Like above, but in Relevance's opinion.
• DP5. Is Developer Productivity in the Top 5 list of things we would like to have more of? In other words, a project with a high DPC and DP5 means that the client is happy with Ruby, but would be even more happy if Ruby was, um, Rubyer.
• CS5. Is Code Speed in the Top 5 list of things we would like to have more of?

Here's the numbers. The trends are not subtle.

            DPC      DPR      DP5      CS5
Project A:  100%     100%     100%     0
Project B:  100%     100%     100%     0
Project C:  100%     100%     100%     0
Project D:  100%     100%     100%     0

At this point, even caring about Ruby's language performance would be a premature optimization at the business process level. Ruby's runtime performance is a non-issue for a broad spectrum of applications. In fact, I believe that all of our customers would be even happier with a language that ran 50% slower than Ruby, if it also made the development team a mere 10% more productive.

After years of quiet research, I am pleased to announce the discovery of a new universal constant. Not quite as important as most of the constants in physics, but nevertheless here it is: S, which measures the suckitude of conference registration web sites. The cool thing about S is, every time you attempt to measure its value, it is larger than you thought possible.

Case in point: I just did the speaker registration for RailsConf. This process collected my address, and took a little over an hour to complete. Here's how it played out.

Phase 1. Optimisim. "Ooh, look, you can use your OpenID." I go and activate an OpenID on one of my free accounts, come back, enter it, and ... Nothing. No warning, no error, just the silent contempt of the machine.

Phase 2. Realism. I create a special O'Reilly password, using 1Password (awesome, btw). I have learned that many web sites install validations to prevent you from using strong passwords (duh!?), so I dumb it down to a twenty character password. The site accepts my account, and sends an email confirmation. I click the email, return to the site, enter my shiny new password, and ... Nothing. No error, no warning. The screen doesn't change at all.

Interlude. Email exchange with nice folks at O'Reilly. "Try a different browser." No Joy.

Phase 3. A sad theory. Maybe my password is still too stong! I reset my password to a simple, easily guessable password, and now I am finally into the site.

Phase 4. Denial. Most of my data is already filled in, but the conference wants to know my physical address. I can tell this by the little red asterisks. Street, city, state, zip, country, whoa, no I don't live in Uganda! Submit the form, and Ha! Some of the other fields (not marked with red asterisks) are required as well. The error message informs me that I must pick a tutorial to attend. (I am giving one of the tutorials, so I think the server side object model is a little weak). Sign up for my own tutorial, submit the form again, and ... wait for it ...

Phase 5. Resignation. "1 ERROR PROHIBITED THIS ATTENDEED FROM BEING SAVED." "Sorry, speaker is already registered." Well, I'm in. Maybe.

In the "yet another anecdote that may not work for you" department, here is my journey from svn to git on a Mac. My objectives were simple:

• Get git working
• Use git atop some existing svn repositories
• Convert some svn repositories entirely to git

My experience with package installs is that if things start to go a little squirrely, give up and build from source. Git was no exception. Build from source didn't quite work either:

MSGFMT    po/de.msg make[1]: *** [po/de.msg] Error 127

This blog post got me past the first hurdle. Git was working, but the svn integration was not, so I followed this advice to reinstall subversion with Perl bindings. (This actually worked without resorting to source.)

Next, I followed these instructions to completely convert a substantial svn repository to git. That almost worked, but since my repositories are authenticated (duh!), I ran into this problem:

Can't locate SVN/Core.pm in @INC  

This is caused by a missing Perl module, as documented here. After a couple of minutes fiddling with the multiple Perl installs on my machine to install to the Perl that git-svn expected, I was ready to go.

And with that I seem to be up and running. Total time: about 2.5 hours.

Jay Fields blogged recently (and not for the first time) about managing gems within Rails projects. This is a problem a lot of people have wrestled with; there are close to a dozen plugins, rake tasks, uncommitted patches, and published hacks that attempt to provide a solution (and those are just the ones I know of).

FrozenGemsGenerator is the solution that we’ve been using on some projects at Relevance, and we’re happy enough with it that we’ll be using it more. It’s a rails generator, packaged as a gem, that gives your Rails app a private gem repository, fully self-contained, and manageable just like your system-wide repository (except using script/gem instead of gem).

$ sudo gem install frozen_gems_generator
$ script/generate frozen_gems
$ script/gem install money

script/gem supports all of the subcommands that the regular gem command does.

I haven’t yet implemented a solution for gems that install binary extensions. I’m very interested in suggestions for how best to solve that problem. Several of the other approaches have at least partial support for architecture-specific gems; the best may be Jeremy Voorhis’ CarryOn plugin, which is also the solution that’s closest in spirit to the FrozenGems approach. If you have ideas or suggestions about how architecture-specific gems should be handled, please add comments here or post them on our Trac instance.