[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 (
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:
- it is useful to have a class for the whole of the system and not just the parts, and
- 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.
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.
- 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: