Jay’s Not Here

I’m getting screen corruption issues on my Macbook Pro; the one I’m using to run the study upon which I’m basing my thesis; the one I’m using to demo my project at next week’s RIA Showcase.

It’s a 3 year old machine with a battery that still lasts at least 4 hours. Unfortunately, it has the failure-prone nVidia 8600M GT soldered to the logic board.

I haven’t confirmed the GPU is the culprit. I’m currently backing up the drive (thank you Apple for Target Disk mode and Firewire 800).

I can’t take it to the Apple Store any time soon. I’m still anxiously waiting for my mom to be discharged from the hospital.

Aaaaaaaaaaargh >_<

Damn you, Murphy’s Law!

It’s been a while since I blogged about my study so here’s a quick update:

• Acquired a current-gen iPod Touch to give away to one randomly-selected participant.
• Signed up 3 people to come into the lab between now and Monday.
• Tentatively signed up 2 more over the next few weeks.
• Started writing tools to automatically collect statistics about previous sessions:
  • One participant saved their work 53 times per hour.
• Learned that a dual-computer setup makes video transcription much much faster. I’ve got one computer playing back the video on a 40″ monitor using MPlayer (awesome keyboard shortcuts for pausing and navigating video); the other one has an Excel spreadsheet with pre-labeled cells for storing the transcribed data. This setup saves me from having to Command-Tab between apps each time I want to type something. Plus, I get to see the video and the transcript at the same time.
• Discovered that using raw sugar instead of granulated increases the likelihood of caramelization during cookie baking.

Today is the last day of Energy Saving Week 2009. It’ll also be the last day I’ll be running my 108-watt-when-idle development server. I decided to replace it with the new Mac Mini Server and see if that really lives up to all the marketing hype. Here’s a quick summary:

Pros:

• Sips a measly 13 watts when idle. That’s a whopping 87% energy savings over my old server.
• Hourly back ups to a dedicated hard drive, out of the box. It’s configured as a twin 500 GB set up; one for the OS and the other for Time Machine.
• It’s great as a collaboration server: VPN, VNC, SSH, CalDAV, http/https, Open Directory, per-user/group wikis and blogs right out of the box—but if your DNS server isn’t configured properly (or you have no authority to make changes on it) you’re hosed. Good luck finding help.
• Open Directory + SVN = pure awesomeness; no more mucking around with htpasswd files—users can change their password themselves using a built in web interface.
• Makes a great media server—plays 1080p video full screen very smoothly; even across a (wired gigabit) network share (hosted by a dedicated hardware RAID5 unit).
• It was a hell of a lot faster to set up all those services compared to my old Linux server (I still have nightmares about IPsec and ypserv configuration); and I didn’t have to download/compile anything either. I only had to edit config files to get Apache/SVN working.

Cons:

• You need to administer your own DNS server for everything to work. DNS is painful and very tricky to get right if you haven’t set it up before. Luckily the Tomato router firmware, which includes dnsmasq, is good enough to get everything working. It doesn’t run on all routers, and the ones that it does support only transmit at 802.11g speeds (i.e. 54 Mbits max).
• Kerberos and iCal Server are a huge pain to set up unless you’ve got a fully functional DNS server with fully-qualified forward and reverse mappings for your machines.
• Prone to stealthy name collision problems: if you’ve got a nasty habit (like I do) of creating a local admin account with the same username as your Open Directory user account, you’re in for a whole lot of set-up pain.
• Server Admin keeps overwriting my Apache settings You can prevent that by putting your stuff in a separate .conf file and Include it from the main config.

The newly released Mac Mini Server caught my eye. It boasts 16 watts of power usage when idle—that’s just 2 watts more than the base Mac Mini. So I busted out my handy Kill-A-Watt meter to see how my existing boxen farm measures up:

Note to self—don’t forget to turn off the TV.

[1] Assuming a constant rate of $0.093 per kWh (which is currently the peak usage rate in Ontario) and 24/7 idle time. Costs will be higher when the devices are under heavier load.

I heard back from the ethics review board today about my study. They weren’t happy about how I used the word “remuneration” so I decided to look it up on Wikipedia.

Apparently, someone was able to sneak this in:

Renumeration can include:
…

• Eating boiled eggs to gain usage of supernatural powers

I had my first participant come into the lab for my first qualitative study. The session went fairly smooth except for a few wrinkles. I’m studying expert software developers—i.e. people who code to put food on the table. I learned quite a lot:

• An interruption-free environment lets a coder focus on their task so much they can lose track of time and let 3 hours pass. (Ahh, memories of undergrad assignments…)
• My idea of easy can be very, very different from someone else’s.
• Coders don’t like think-aloud experiments. They just want to do things their way.
• I need to make the task even shorter.
• Even though your screen recording software has a crash recovery feature, DO NOT TRUST IT!^[1]
• The last GO Bus going home leaves Union Station at 0040h. Not a good idea to miss that one, lest I want to spend the night downtown…

Now it’s time to go over all the data. Luckily I have all 3 hours worth of source code deltas, browser history, and IDE metadata, despite losing 2 hours worth of video. Some data is better than no data.

^[1]
I made the awful mistake of thinking my data was safe after recording the session. The program was in the middle of transcoding the capture data to a standard movie file and I stupidly decided to close the lid of my laptop to put it to sleep. Of course, when it woke up, the screen recorder crashed, but I knew it had a crash recovery feature that allows transcoding to resume. Well, it did continue, but the last 2h10 of the recording was all green screen. It only salvaged the first 50 minutes.

I’ve seen a lot of mail fly by lately on the Python edu-sig mailing list about clean code snippets that are easy for students to digest. That made me wonder whether it’s appropriate to shelter students from the complexity of code in the wild throughout most of their university career.

Teaching people how to dissect a huge, largely undocumented code base into more manageable bits was (and still is) the most time-consuming task for me as a professional programmer. That certainly wasn’t taught at any school I’ve attended; I’d be curious if any universities do.

Here’s my take on how such a course could be structured; abstract and link to outline below. I’d be grateful for feedback.

Budding scientists study the well-established experimental techniques of their predecessors. English majors study the works of great writers like Shakespeare. Following this tradition of analyzing the approaches and designs of significant historical figures in the field, this course focuses on the art history of software.

The open source movement has made it possible for anyone to study large, industrial-strength software. Mature code bases have a rich history full of design decisions and trade offs. This course covers why modern software is built the way it is, as well as the design patterns that emerged, while drawing upon the code bases of many open source projects.

Here’s a preliminary outline of the topics I’d want covered. I’m still 5 lectures short by UofT standards—then again, I’m not sure if I’m alloting enough time for the material I’ve already listed.

Last week was extremely productive on many fronts. The hobbyist in me is all smiles:

• Finished acceptance test suite for my study.
• Fixed a major concurrency bug involving modal dialogs in one of my Java projects.
• Wrote a little PHP script that feeds a Flash/AS2 gallery with pictures from my Flickr account.
• Put in an order for The Pragmatic Programmer and Software Craftsmanship.
• Climbed a bunch of 5.9 walls at the gym. 5.8s are now my cooldown climbs.
• Climbed about 80% through a V1 bouldering route—it’s hard to get over the lip after ten or so 30-50′ climbs.
• Learned how to jack up and chock a car, remove the front bumper, air box and resonator, swap in a cold air intake and put it all back together again. Once the parts come in, I’ll get to apply this theoretical stuff. In the meantime, I’ve learned how to take public transit to get all the way to school—you know, just in case.
• Found a 25% off deal on a 200W bass amp head and 4×10″ cabinet. My 30W combo unit just isn’t doing it for me anymore—actually, it never did.
• Started packing my stuff for the move in February.
• Booked cottage for autumn getaway.
• Caught up on sleep.

Someone asked me how to convert a string to a date. This was my answer:

"Your place or mine?"

It works over email, IM, Facebook, SMS and even blog comments! Of course, it’s most effective AFK.

Now that I’m back in Toronto (though not quite on EST), I’ve had a bit of time to think over my research. Emerson was kind enough to review my study design and share his literature. Thanks very much for that!

One issue that arose from our discussion is my usage of the term “expert”. In research literature, expert programmers are generally those in industry who are paid to program. In all the software firms I’ve worked for, I’ve observed huge differences among these “experts” to the extent that I don’t feel right calling them all “experts”. I can’t call these “lesser experts” novices because that term refers to inexperienced programmers, such as most CS undergrads.

I ended up choosing a term used by Sonnentag’s study of software design expertise[1]: high and low performers. So now I can talk about high- and low-performing novices, as well as high- and low-performing experts.

My new problem is how to operationalize “performance”.

[1] S. Sonnentag. Expertise in professional software design: a process study. The Journal of applied psychology, 83(5):703–715, October 1998.