Git bisect is the hero of the week! It turned out that some time between now and three weeks ago, the login functionality broke in the Rails app we’re developing. It didn’t break completely, of course, just in certain environments. And looking at the logs, I had no idea what the error could be, so I just had to work it out from the diff between the last working commit and next. Well, between three developers, there can be quite a few commits during three weeks and with a lesser version control system I would have had to

1. checkout the previous revision,
2. restart the server (because plugins, gems and even Rails can change between versions),
3. try to log in,
4. see if works and stop if it does,
5. repeat from 1.

With git, I can ask git itself to perform a binary search among all the revisions between now and three weeks ago. It would go like this:

1. git bisect start HEAD 57c3aaa,
2. restart the server,
3. try to log in,
4. see it fail or succeed,
5. say git bisect bad or git bisect good to make Git checkout the next node in the binary search tree
6. repeat from 1 until Git says that it found the culprit.

It doesn’t look a lot better, but it is if you have 300 commits. Of course there is nothing to stop you from doing a manual binary search with Subversion, or even to step back one day at a time to narrow it down, and we didn’t actually have 300 commits. But where Git really shines is in the fact that if I can write a program that can tell if a version is good or bad, all I have to do is

1. git bisect start HEAD 57c3aaa,
2. git run ../my-test-probe.rb

and sit back and wait. Provided of course that the program also knew how to start and stop the server. Well, here is that program, for your debugging pleasure, and mine:

PeepCode publishes wonderful screencasts and pdf books on subjects that should be of interest to any Rails developer. The pdfs seem to be adapted for screen reading – they are in landscape mode, not in standard paper sizes (as far as I can tell) and they have big print. So far so good, but I spend enough time in front of computer screens and like reading paper. I have tried various pdf rendering options combined with cropping, but the solution that worked best for printing Scott Chacon’s Git Internals PDF on A4 paper was as simple as printing it 2up at 118%.

FS-data was the first web hotel in Sweden to support Ruby on Rails (in August 2006, I think) and I’m glad they did. Unfortunately they haven’t touched their setup since, so patrons are still limited to (a) apps in subdirectories only and (b) FastCGI (FCGI). I have seen many complaints about FCGI, but I have only one: it’s really hard to know if it’s running my latest release. FS-data have added a control panel of sorts, but it’s pretty unreliable. Thus, I have to resort to killing. But what to kill?

$ ps -fe | grep rails
UID        PID  PPID  C STIME TTY          TIME CMD
wcj      27292  3558 27 13:41 ?        00:00:02 RAILS: /home/w/wcj/rails/sis/public/dispatch.fcgi
wcj      27365  3558 40 13:41 ?        00:00:02 RAILS: /home/w/wcj/rails/sis/public/dispatch.fcgi
...

With more than two processes I refuse to kill by PID – FCGI is just too quick to spawn new processes, and I’m not sure if they will run the right version of my app either. So it’s killall. But what to killall?

$ killall -9 'RAILS: /home/w/wcj/rails/sis/public/dispatch.fcgi'

does not work. So it’s ps to the rescue:

$ ps -eo pid,comm:30
  PID COMMAND
27365 rails_dispatche
27292 rails_dispatche

rails_dispatche, really? No final ‘r’? Whatever:

killall -9 rails_dispatche

It works and I’m happy again.