[A note for casual readers: These notes are not meant to be objective representations of what different speakers said at Scottish Ruby Conference. They are my interpretations in my context.]

[Update 2010-03-29, morning: added more links. 2010-03-29, evening: re-phrased note on gender distribution and separated it from note on sexism, since I don't think of them as related and don't want others to think so. 2010-04-01: links to other summaries.]

Concurrency and real time are great to have and quite attainable if we step outside the comfort zone that Rails gives us. Thanks to Jim Weirich for the reminders and to Makoto Inoue and Martyn Loughran for valuable tips and tools: js-model, dragban, pusher demo, . Presentation here, and some background. And I really want to do some Erlang.

What we do is an art that is based on science and while the artistery has received a lot of attention lately, we can benefit from revisiting the science. Jim Weirich told us about Structure and Interpretation of Computer Programs. It’s available online and there is a mailing list to discuss the content and/or the exercises. I think Jim would have been able to sell 50 copies of the book on the spot if he had brought any.

Lifecycle management should be done with proper tools, not timestamps with funny names (approved_at, published_at, etc). And lifecycle is more than state machines, it’s also workflow and permissions. David Bock showed off Stonepath and hinted at Stonewall. He uses acts_as_state_machine but says that it should probably be really easy to use state_machine instead. (NB: A new version of state machine was released two weeks ago with a lot of important fixes!)

Ever since I read about ticgit in Scott Chacon’s Git Internals I have wanted to do something with git besides source code control but I always thought I’d need to learn 100 git plumbing commands. Scott demonstrated how to do very useful things with just four or five commands, so that’s something I’ll put in my toolbox.

Gwyn Morfey introduced a very useful image in his talk “Write Bad Code”. We may need to get into technical debt in order to avoid the area of death, just like we may need to get into financial debt in real life to avoid starving or bankruptcy. He also gave a good number of rules for classifying the situations where it is applicable and how to act in those situations.

Lots of people retweeted Tim Bray’s sentiment that “if your webapp doesn’t work on a mobile device nowadays then it doesn’t work”. I definitely think that is true in most cases, but I’m worried that it will be wielded like the Sword Of Truth in the future. It’s not black or white, and while most webapps should be written to work on a mobile device, I think there are loads of valid exceptions.

I read about CRC Cards (Class, Responsibility, Collaboration) many years ago and threw off the idea as a tool for people who needed something to hold in their hands while they learned about object oriented design and analysis. Sam Wessel ran a BoF workshop with Kevin Rutherford where we got to work through a simple analysis exercise. It was a real eye opener and the most valuable session of the conference. I learned two things:

1. it is useful to have a class for the whole of the system and not just the parts, and
2. I should learn about CRC. (I shall try to avoid the temptation to think that I can actually use it on my own just because I’ve sat at the feet of masters.)

I’m not a big friend of mocking and thus went to a BoF where Brian Swan and Kevin Rutherford debated mocks. Interesting debate, but according to show of hands at the end, I was the only person who changed their position to whatever slight extent. Apparently there is now a nicer syntax for setting expectations so that you can do the stubbing in the setup and the expectation checks in the actual it-clauses. And Kevin says that (contrary to Brian’s experience, and mine), he feels that he can refactor quite freely without breaking loads of mocks. I need to learn more about mocks or modelling, or both.

WebMock by Bartosz Blimke does the same thing FakeWeb, but better. It has support for regexp matching of urls, checks for POST data, and nice assertions. Worth checking out.

Redcar by Daniel Lucraft aims to be “a cross-platform programmer’s editor written in Ruby”. I couldn’t install it, probably because I have installed gems and rubies in too many ways on my laptop. Will need to clean up and try again.

Things I should check out: 12 hours to rate a rails application, Story mapper (big picture planning for Pivotal Tracker), Distributed Architectures with Rack (mentioned in Tim Bray’s blog).

Non-coding observations

• When going to a country where it is hideously expensive to use my phone for data, I should bring an old phone that can run my normal sim card and buy a pay-as-you-go card for my iphone at the destination. Doubly so since there is really no reason to believe that anyone can ever create a wireless network that can support 300 developers at the same time, all the time.
• RubyConf India had 28 female attendees out of 400 total; Scottish Ruby Conference had slightly less, I think.  I wonder what we can do as a community to raise that percentage.  I wonder what we can do as a society.  I wonder what I can do.
• I also noted that a few presenters thought it appropriate to portray Ruby developers as geeky manboys and women as some kind of more or less attainable prize or decoration. That is so not cool.
• Quality of presentations vary from marvellous and eyeopening to YOU HAVE ROBBED ME OF 45 MINUTES OF MY LIFE AND MADE ME LOSE FAITH IN HUMANITY. Unless the presenters are well known, I should always find someone who can vouch for the presenter beforehand, or at least talk to the presenter to find out what I can expect. In the choice between an interesting presentation and an interesting presenter, prefer the latter.
• If I don’t manage to do the above, I should make sure to find a seat where I can sneak out of the room without looking rude.
• Considering that the lack of equal opportunities for men and women is a far greater problem than my having 45 minutes ripped from my day, I’m forced to make the observation that I have grown slightly numb to male chauvinism. I don’t like that.

Links to others’ summaries:

• Gautam Rege
• Sebastian Röbke

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%.