While doing some spring cleaning around my hard disk, I found a little Haskell program I wrote several years ago in an attempt to learn the basics of music theory. Now, I’m not a pro at writing Haskell, and I know even less about music theory, but I’m hoping that what I wrote down back then is a bit accurate. The program seems to summarize the basics quite consisely: by just having a glance at the program, I’m rediscovering some things I totally forgot about scales and chords.

Google recently published a C++ style guide, containing all the rules that Google code adheres to. Many of the style tips are quite sensible, and well accepted by many developers out there. However, I was surprised to find the following rule:

This year, we held the first ever International Psi Conference in the San Francisco Bay Area. The event  was spread out over 2 days, with different venues to keep things interesting. The conference was a big success, with attendees from different countries (including the Netherlands, Belgium, and the U.S.), and the presence of several big companies.

The day before yesterday, Peter Saint-Andre sent out a couple of Jaiku invites to all Jabber Google Summer of Code students and their mentors, including me. Never having looked at microblogging before, I toyed around with it a bit, and it quickly reminded me that I still had something on my Psi wish-list for a while now: a flat, live log of all Jabber events in your network. Since I had a long weekend, I quickly coded up a prototype, and hooked it into Psi.

For a while now, Psi users have been requesting several changes and additions to the roster (or ‘contact list’). These requests include grouping contacts into meta-contacts, nested roster groups, and displaying user avatars in the roster. We have been postponing all these changes to the roster as much as possible, because none of us wanted to touch the roster code, for reasons I’ll explain below. This year, Psi is fortunate enough to have Adam Czachorowski (aka Gislan), a student from the Google Summer of Code, to work on roster improvements.

It probably happened to most of us developers before: while refactoring, you change the name of a virtual method, but forget to change the name of the overriding method in one of your derived classes. Compilation works fine, all unit tests pass, but your program doesn’t work: the overriding method is never called. Java (and C#) programmers can avoid this problem by putting @Override (and override) in front of their methods, which causes the compiler to print out an error message if the method is not overriding anything. However, most other languages leave you hanging with this problem. Luckily, with statically typed languages like C++, you can avoid these bugs by slightly adapting your unit tests.

At the occasion of Read an eBook week, I thought I’ld do something you can’t actually do with real books: buy (and read) a version of a book before it is released. Andy Hunt, author of the excellent book The Pragmatic Programmer (a must read for every developer!), recently announced the availability of a beta version of his new book, Refactor your wetware. This beta version is an early electronic version of the book, which gives the reader the opportunity to get a sneak peek at the book, and give feedback for the final version (which, as a beta book owner, you can also download when it is released). So, I went over to the Pragmatic Bookshelf store, ordered my copy, and got an e-mail with my personalized copy only a few seconds later.

I created a Fink package for MP4Box, the multimedia packager from the GPAC project. MP4Box can be used for manipulating (e.g. muxing, demuxing) multimedia files such as MP4, 3GP, AVI, MPG, TS, …

User interfaces: every piece of software needs one, but no programmer likes to write one. According to Joel Spolsky (host of the popular Joel on Software), the root cause of the problem is the (unnecessary) fear of being incapable of designing user interfaces. He claims that UI design actually is fun, challenging, and doesn’t require any artistic talent whatsoever (as opposed to what many programmers think). Since I have to write quite some UI code myself, and always thought it was the most boring and frustrating aspect of software development, I thought I’ld pick up Spolsky’s book ‘User Interface Design for Programmers’, and let him try to convince me otherwise.