Holy Chao

Rivaling the amazing transitive powers of Nightcrawler, Jon Distad and I decided to tackle the problem of parsing CSV rapidly under Ruby 1.9. "Aha!" you might be saying, "FasterCSV was already rolled into the stdlib in Ruby 1.9! Why would I need a gem to handle it?" Well you have a very good point there, FasterCSV was a good response to the performance of the old 1.8 stdlib CSV parser. However there are still cases where it doesn't quite go fast enough.

I've been running into some complications trying to get ruby 1.9.2 installed by RVM on OS X 10.6.3. This is likely not an original problem, but I got it to work. My environment is pretty crufty, I have an oldish Macbook Pro that came installed with 10.4, and has had an upgrade path including 10.5. Macports, and it's ruby interpreter were on my system, as well as the default Mac ruby, and a ruby source tarball installation.

I had since uninstalled all rubies except for the 1.9.2 source tarball, and uninstalled Macports in favor of migrating to Homebrew.

My specific problem is working on a project in which the .rvmrc specified ruby-1.9.2-p0, and rvm install ruby-1.9.2-p0 did not act as expected. I received the error

readline.c:1292: error: 'username_completion_function' undeclared (first use in this function)

Starting with brew and rvm installed I then needed to do some more:

Install readline:

brew install readline

Cleanup to only one version of readline:

brew cleanup readline

Link the brew install to /usr/local:

brew link readline

Install with rvm passing args to autoconf:

rvm install 1.9.2-p0 -C --enable-shared,--with-readline-dir=/usr/local

No compile errors, and proper readline support! Yay. My thanks to George at Plataforma Tecnologia for this solution.

Looking at this past article is a good start as most of the problems to be solved are similar or the same.

Or how I learned to stop worrying and love SVN, Cerberus, and RCov

I recently was given carte blanche to enact some authoritarian controls on our source code at work, and ran with it. My general feeling is not to limit what people can do with our repository, just to audit that they have done it, and when it is problematic, make their work widely known rapidly. Thus, my intent was not to lockout checkins which would cause rake to fail, just to report on the checkins when they happened.

We had at a prior point in time incorporate the Cerberus system with a cron job on our source control server, every 10 minutes it would checkout the revision and then bitch about whoever had the last checkin if the build was broken to a mailing list all developers were signed up to. This was okay except:

• If two people comitted in that 10 minute period, the last got the blame.
• If you made huge structural changes to the project, it would cause the build to fail.

So our cerberus system got switched off and we quickly stopped having a reliable rake build. People broke things and didn't know they broke them, and we were slowly marching down the path of madness.

I decided that I wanted us to have a different system, one that:

1. Would run the build process on every checkin.

2. Could cope with large structural changes to the source tree.
3. Would not violate our prior decision not to have config files checked into the source tree.
4. Would generate code coverage reports.

It was more work than I anticipated!