I’ve given a few talks so far this year, which I’ve been kinda slack about and haven’t put up any slides for yet. So, if you’re one of the zero people who’ve been eagerly awaiting my incredibly astute and sexy opinions, I guess today’s your lucky day, punk!

Earlier this year, on January 2, 2008, Earth Time, I gave a talk at Kiwi Foo Camp in New Zealand, also known as Baa Camp. (Harhar, foo, baa, get it?) The talk was titled “Towards the Massive Media Matrix”, with the MMM in the title being a pun on the whole WWW three-letter acronym thing. (Credit for the MMM acronym should go to Silvia Pfeiffer and Conrad Parker, who phrased the term about eight years ago :). The talk was about the importance of free and open standards on the Web, what’s wrong with the current status quo about Web video basically being Flash video, and the complications involved in trying to find a solution that satisfies everyone. I’m happy to announce that the slides for the talk are now available for download; you can also grab the details off my talks page.

A bit later this year in March, Manuel Chakravarty and I were invited to the fp-syd functional programming user group in Sydney, to give a talk about… monads! As in, that scary Haskell thing. We understand that writing a monad tutorial seems to be a rite of passage for all Haskell programmers and was thus stereotypical of the “Haskell guys” in the group to give a talk about, but the talk seemed to be well-received.

Manuel gave a general introduction to monads: what they are, how to use them, and why they’re actually a good thing rather than simply another hoop you have to jump through if you just want to do some simple I/O in Haskell. I focused on a practical use case of monads that didn’t involve I/O (OMG!), giving a walkthrough on how to use Haskell’s excellent Parsec library to perform parsing tasks, and why you’d want to use it instead of writing a recursive descent parser yourself, or resort to the insanity of using lex and yacc. I was flattered to find out that after my talk, Ben Leppmeier rewrote the parser for DDC (the Disciplined Disciple Compiler) to use Parsec, rather than his old system of Alex and Happy (Haskell’s equivalents of lex and yacc). So, I guess I managed to make a good impression with at least one of our audience members, which gave me a nice warm fuzzy feeling.

You can find both Manuel’s and my slides online at the Google Groups files page for fp-syd, or you can download the slides directly from my own site. Enjoy.

Finally, during my three-week journey to the USA last month in June, I somehow got roped into giving a talk at Galois Inc. in Portland, about pretty much whatever I wanted. Since the audience was, once again, a Haskell and functional programming crowd, I of course chose to give a talk about an object-oriented language instead: Objective-C, the lingua franca of Mac OS X development.

If you’re a programming language geek and don’t know much about Objective-C, the talk should hopefully interest you. Objective-C is a very practical programming language that has a number of interesting features from a language point of view, such as opt-in garbage collection, and a hybrid of a dynamically typed runtime system with static type checking. If you’re a Mac OS X developer, there’s some stuff there about the internals of the Objective-C object and runtime system, and a few slides about higher-order messaging, which brings much of the expressive power of higher-order functions in other programming languages to Objective-C. Of course, if you’re a Mac OS X developer and a programming language geek, well, this should be right up your alley :). Once again, you can download the slides directly, or off my talks page.

Two years ago, I had a wonderful job working on a truly excellent piece of software named cineSync. It had the somewhat simple but cheery job of playing back movies in sync across different computers, letting people write notes about particular movie frames and scribbling drawings on them. (As you can imagine, many of the drawings that we produced when testing cineSync weren’t really fit for public consumption.) While it sounds like a simple idea, oh boy did it make some people’s lives a lot easier and a lot less stressful. People used to do crazy things like fly from city to city just to be the same room with another guy for 30 minutes to talk about a video that they were producing; sometimes they’d be flying two or three times per week just to do this. Now, they just fire up cineSync instead and get stuff done in 30 minutes, instead of 30 minutes and an extra eight hours of travelling. cineSync made the time, cost and stress savings probably an order of magnitude or two better. As a result, I have immense pride and joy in saying that it’s being used on virtually every single Hollywood movie out there today (yep, even Iron Man). So, hell of a cool project to work on? Tick ✓.

Plus, it was practically a dream coding job when it came to programming languages and technologies. My day job consisted of programming with Mac OS X’s Cocoa, the most elegant framework I’ve ever had the pleasure of using, and working with one of the best C++ cross-platform code bases I’ve seen. I also did extensive hacking in Erlang for the server code, so I got paid to play with one of my favourite functional programming languages, which some people spend their entire life wishing for. And I got schooled in just so much stuff: wielding C++ right, designing network protocols, learning about software process, business practices… so, geek nirvana? Tick ✓.

The ticks go on: great workplace ✓; fantastic people to work with ✓; being privy to the latest movie gossip because we were co-located with one of Australia’s premiere visual effects company ✓; sane working hours ✓; being located in Surry Hills and sampling Crown St for lunch nearly every day ✓; having the luxury of working at home and at cafés far too often ✓. So, since it was all going so well, I had decided that it was obviously time to make a life a lot harder, so I resigned, set up my own little software consulting company, and start working on Mac shareware full-time.

Outside of the day job on cineSync, I was doing some coding on a cute little program to build websites named RapidWeaver. RapidWeaver’s kinda like Dreamweaver, but a lot more simple (and hopefully just as powerful), and it’s not stupidly priced. Or, it’s kinda like iWeb, but a lot more powerful, with hopefully most of the simplicity. I first encountered RapidWeaver as a normal customer and paid my $40 for it since I thought it was a great little program, but after writing a little plugin for it, I took on some coding tasks.

And you know what? The code base sucked. The process sucked. Every task I had to do was a chore. When I started, there wasn’t even a revision control system in place: developers would commit their changes by emailing entire source code files or zip archives to each other. There was no formal bug tracker. Not a day went by when I shook my fist, lo, with great anger, and thunder and lightning appeared. RapidWeaver’s code base had evolved since version 1.0 from nearly a decade before, written by multiple contractors with nobody being an overall custodian of the code, and it showed. I saw methods that were over thousand lines long, multithreaded bugs that would make Baby Jesus cry, method names that were prefixed with with Java-style global package namespacing (yes, we have method names called com_rwrp_currentlySelectedPage), block nesting that got so bad that I once counted thirteen tabs before the actual line of code started, dozens of lines of commented-out code, classes that had more than a hundred and twenty instance variables, etc, etc. Definitely no tick ✗.

But the code—just like PHP—didn’t matter, because the product just plain rocked. (Hey, I did pay $40 for it, which surprised me quite a lot because I moved to the Mac from the Linux world, and sneered off most things at the time that cost more than $0.) Despite being a tangled maze of twisty paths, the code worked. I was determined to make the product rock more. After meeting the RapidWeaver folks at WWDC 2007, I decided to take the plunge and see how it’d go full-time. So, we worked, and we worked hard. RapidWeaver 3.5 was released two years ago, in June 2006, followed by 3.5.1. 3.6 followed in May 2007, followed by a slew of upgrades: 3.6.1, 3.6.2, 3.6.3… all the way up to 3.6.7. Slowly but surely, the product improved. On the 3rd of August 2007, we created the branch for RapidWeaver 3.7, which we didn’t realise yet was going to be such a major release that it eventually became 4.0.

And over time, it slowly dawned on me just how many users we had. A product that I initially thought had a few thousand users was much closer to about 100,000 users. I realised I was working on something that was going to affect a lot of people, so when we decided to call it version 4.0, I was a little nervous. I stared at the code base and it stared back at me; was it really possible ship a major new revision of a product and add features to it, and maintain my sanity?

I decided in my naïvety to refactor a huge bunch of things. I held conference calls with other developers to talk about what needed to change in our plugin API, and how I was going to redo half of the internals so it wouldn’t suck anymore. Heads nodded; I was happy. After about two weeks of being pleased with myself and ripping up many of our central classes, reality set in as I realised that I was very far behind on implementing all the new features, because those two weeks were spent on nothing else but refactoring. After doing time estimation on all the tasks we had planned out for 4.0 and realising that we were about within one day of the target date, I realised we were completely screwed, because nobody sane does time estimation for software without multiplying the total estimate by about 1.5-2x longer. 4.0 was going to take twice as long as we thought it would, and since the feature list was not fixed, it was going to take even longer than that.

So, the refactoring work was dropped, and we concentrated on adding the new required features, and porting the bugfixes from the 3.6 versions to 4.0. So, now we ended up with half-refactored code, which is arguably just as bad as no refactored code. All the best-laid plans that I had to clean up the code base went south, as we soldiered on towards feature completion for 4.0, because we simply didn’t have the time. I ended up working literally up until the last hour to get 4.0 to code completion state, and made some executive decisions to pull some features that were just too unstable in their current state. Quick Look support was pulled an hour and a half before the release as we kept finding and fixing bugs with it that crashed RapidWeaver while saving a document, which was a sure-fire way to lose customers. Ultimately, pulling Quick Look was the correct decision. (Don’t worry guys, it’ll be back in 4.0.1, without any of that crashing-on-save shenanigans.)

So, last Thursday, it became reality: RapidWeaver 4.0 shipped out the door. While I was fighting against the code, Dan, Aron, Nik and Ben were revamping the website, which now absolutely bloody gorgeous, all the while handling the litany of support requests and being their usual easygoing sociable selves on the Realmac forums. I was rather nervous about the release: did we, and our brave beta testers, catch all the show-stopper bugs? The good news is that it seems to be mostly OK so far, although no software is ever perfect, so there’s no doubt we’ll be releasing 4.0.1 soon (if only to re-add Quick Look support).

A day after the release, it slowly dawned on me that the code for 4.0 was basically my baby. Sure, I’d worked on RapidWeaver 3.5 and 3.6 and was the lead coder for that, but the 3.5 and 3.6 goals were much more modest than 4.0. We certainly had other developers work on 4.0 (kudos to Kevin and Josh), but if I had a bad coding day, the code basically didn’t move. So all the blood, sweat and tears that went into making 4.0 was more-or-less my pride and my responsibility. (Code-wise, at least.)

If there’s a point to this story, I guess that’d be it: take pride and responsibility in what you do, and love your work. The 4.0 code base still sucks, sitting there sniggering at me in its half-refactored state, but we’ve finally suffered the consequences of its legacy design for long enough that we have no choice but to give it a makeover with a vengeance for the next major release. Sooner or later, everyone pays the bad code debt.

So, it’s going to be a lot more hard work to 4.1, as 4.1 becomes the release that we all really wanted 4.0 to be. But I wouldn’t trade this job for pretty much anything else in this world right now, because it’s a great product loved by a lot of customers, and making RapidWeaver better isn’t just a job anymore, it’s a need. We love this program, and we wanna make it so good that you’ll just have to buy the thing if you own a Mac. One day, I’m sure I’ll move on from RapidWeaver to other hopefully great things, but right now, I can’t imagine doing anything else. We’ve come a long way from RapidWeaver 3.5 in the past two years, and I look forward to the long road ahead for RapidWeaver 5. Tick ✓.

Two years ago, I had a wonderful job working on a truly excellent piece of software named cineSync. It had the somewhat simple but cheery job of playing back movies in sync across different computers, letting people write notes about particular movie frames and scribbling drawings on them. (As you can imagine, many of the drawings that we produced when testing cineSync weren’t really fit for public consumption.) While it sounds like a simple idea, oh boy did it make some people’s lives a lot easier and a lot less stressful. People used to do crazy things like fly from city to city just to be the same room with another guy for 30 minutes to talk about a video that they were producing; sometimes they’d be flying two or three times per week just to do this. Now, they just fire up cineSync instead and get stuff done in 30 minutes, instead of 30 minutes and an extra eight hours of travelling. cineSync made the time, cost and stress savings probably an order of magnitude or two better. As a result, I have immense pride and joy in saying that it’s being used on virtually every single Hollywood movie out there today (yep, even Iron Man). So, hell of a cool project to work on? Tick ✓.

Plus, it was practically a dream coding job when it came to programming languages and technologies. My day job consisted of programming with Mac OS X’s Cocoa, the most elegant framework I’ve ever had the pleasure of using, and working with one of the best C++ cross-platform code bases I’ve seen. I also did extensive hacking in Erlang for the server code, so I got paid to play with one of my favourite functional programming languages, which some people spend their entire life wishing for. And I got schooled in just so much stuff: wielding C++ right, designing network protocols, learning about software process, business practices… so, geek nirvana? Tick ✓.

The ticks go on: great workplace ✓; fantastic people to work with ✓; being privy to the latest movie gossip because we were co-located with one of Australia’s premiere visual effects company ✓; sane working hours ✓; being located in Surry Hills and sampling Crown St for lunch nearly every day ✓; having the luxury of working at home and at cafés far too often ✓. So, since it was all going so well, I had decided that it was obviously time to make a life a lot harder, so I resigned, set up my own little software consulting company, and start working on Mac shareware full-time.

Outside of the day job on cineSync, I was doing some coding on a cute little program to build websites named RapidWeaver. RapidWeaver’s kinda like Dreamweaver, but a lot more simple (and hopefully just as powerful), and it’s not stupidly priced. Or, it’s kinda like iWeb, but a lot more powerful, with hopefully most of the simplicity. I first encountered RapidWeaver as a normal customer and paid my $40 for it since I thought it was a great little program, but after writing a little plugin for it, I took on some coding tasks.

And you know what? The code base sucked. The process sucked. Every task I had to do was a chore. When I started, there wasn’t even a revision control system in place: developers would commit their changes by emailing entire source code files or zip archives to each other. There was no formal bug tracker. Not a day went by when I shook my fist, lo, with great anger, and thunder and lightning appeared. RapidWeaver’s code base had evolved since version 1.0 from nearly a decade before, written by multiple contractors with nobody being an overall custodian of the code, and it showed. I saw methods that were over thousand lines long, multithreaded bugs that would make Baby Jesus cry, method names that were prefixed with with Java-style global package namespacing (yes, we have method names called com_rwrp_currentlySelectedPage), block nesting that got so bad that I once counted thirteen tabs before the actual line of code started, dozens of lines of commented-out code, classes that had more than a hundred and twenty instance variables, etc, etc. Definitely no tick ✗.

But the code—just like PHP—didn’t matter, because the product just plain rocked. (Hey, I did pay $40 for it, which surprised me quite a lot because I moved to the Mac from the Linux world, and sneered off most things at the time that cost more than $0.) Despite being a tangled maze of twisty paths, the code worked. I was determined to make the product rock more. After meeting the RapidWeaver folks at WWDC 2007, I decided to take the plunge and see how it’d go full-time. So, we worked, and we worked hard. RapidWeaver 3.5 was released two years ago, in June 2006, followed by 3.5.1. 3.6 followed in May 2007, followed by a slew of upgrades: 3.6.1, 3.6.2, 3.6.3… all the way up to 3.6.7. Slowly but surely, the product improved. On the 3rd of August 2007, we created the branch for RapidWeaver 3.7, which we didn’t realise yet was going to be such a major release that it eventually became 4.0.

And over time, it slowly dawned on me just how many users we had. A product that I initially thought had a few thousand users was much closer to about 100,000 users. I realised I was working on something that was going to affect a lot of people, so when we decided to call it version 4.0, I was a little nervous. I stared at the code base and it stared back at me; was it really possible ship a major new revision of a product and add features to it, and maintain my sanity?

I decided in my naïvety to refactor a huge bunch of things. I held conference calls with other developers to talk about what needed to change in our plugin API, and how I was going to redo half of the internals so it wouldn’t suck anymore. Heads nodded; I was happy. After about two weeks of being pleased with myself and ripping up many of our central classes, reality set in as I realised that I was very far behind on implementing all the new features, because those two weeks were spent on nothing else but refactoring. After doing time estimation on all the tasks we had planned out for 4.0 and realising that we were about within one day of the target date, I realised we were completely screwed, because nobody sane does time estimation for software without multiplying the total estimate by about 1.5-2x longer. 4.0 was going to take twice as long as we thought it would, and since the feature list was not fixed, it was going to take even longer than that.

So, the refactoring work was dropped, and we concentrated on adding the new required features, and porting the bugfixes from the 3.6 versions to 4.0. So, now we ended up with half-refactored code, which is arguably just as bad as no refactored code. All the best-laid plans that I had to clean up the code base went south, as we soldiered on towards feature completion for 4.0, because we simply didn’t have the time. I ended up working literally up until the last hour to get 4.0 to code completion state, and made some executive decisions to pull some features that were just too unstable in their current state. Quick Look support was pulled an hour and a half before the release as we kept finding and fixing bugs with it that crashed RapidWeaver while saving a document, which was a sure-fire way to lose customers. Ultimately, pulling Quick Look was the correct decision. (Don’t worry guys, it’ll be back in 4.0.1, without any of that crashing-on-save shenanigans.)

So, last Thursday, it became reality: RapidWeaver 4.0 shipped out the door. While I was fighting against the code, Dan, Aron, Nik and Ben were revamping the website, which now absolutely bloody gorgeous, all the while handling the litany of support requests and being their usual easygoing sociable selves on the Realmac forums. I was rather nervous about the release: did we, and our brave beta testers, catch all the show-stopper bugs? The good news is that it seems to be mostly OK so far, although no software is ever perfect, so there’s no doubt we’ll be releasing 4.0.1 soon (if only to re-add Quick Look support).

A day after the release, it slowly dawned on me that the code for 4.0 was basically my baby. Sure, I’d worked on RapidWeaver 3.5 and 3.6 and was the lead coder for that, but the 3.5 and 3.6 goals were much more modest than 4.0. We certainly had other developers work on 4.0 (kudos to Kevin and Josh), but if I had a bad coding day, the code basically didn’t move. So all the blood, sweat and tears that went into making 4.0 was more-or-less my pride and my responsibility. (Code-wise, at least.)

If there’s a point to this story, I guess that’d be it: take pride and responsibility in what you do, and love your work. The 4.0 code base still sucks, sitting there sniggering at me in its half-refactored state, but we’ve finally suffered the consequences of its legacy design for long enough that we have no choice but to give it a makeover with a vengeance for the next major release. Sooner or later, everyone pays the bad code debt.

So, it’s going to be a lot more hard work to 4.1, as 4.1 becomes the release that we all really wanted 4.0 to be. But I wouldn’t trade this job for pretty much anything else in this world right now, because it’s a great product loved by a lot of customers, and making RapidWeaver better isn’t just a job anymore, it’s a need. We love this program, and we wanna make it so good that you’ll just have to buy the thing if you own a Mac. One day, I’m sure I’ll move on from RapidWeaver to other hopefully great things, but right now, I can’t imagine doing anything else. We’ve come a long way from RapidWeaver 3.5 in the past two years, and I look forward to the long road ahead for RapidWeaver 5. Tick ✓.

It seems that my exercise to keep track of every single movie I watched last year actually worked. Here’s how 2007 turned out for me:

• 5th of January: Blood Diamond (Hoyts Broadway, 8/10)
• 1st of February: Perfume (Hoyts Cinema Paris, 7/10)
• 4th of February: The Fountain (Hoyts George St City, 8/10)
• 10th of February: Fight Club (DVD, repeat viewing, 8/10)
• 11th of February: Pan’s Labyrinth (Hoyts George St City, 7/10)
• 10th of March: Quand j’étais chanteur, a.k.a The Singer (Palace Academy Paddington, 6.5/10)
• 18th of March: Hors de Prix, a.k.a. Priceless (Palace Academy Leichardt, 7/10)
• 24th of March: The Illusionist (Greater Union Tuggerah, 7/10)
• 3rd of April: Hot Fuzz (Hoyts Fox Studios, 8.5/10).
• 10th of April: 300 (Hoyts Westfield Chatswood, 7.5/10).
• 7th of May: La Science des rêves, a.k.a. The Science of Sleep (Hayden Orpheum, 7/10).
• 12th of May: Spider-man 3 (Hoyts Westfield Chatswood, 7.5/10)
• 22nd of May: Shooter (Greater Union Macquarie, 7/10).
• 27th of May: Tales from Earthsea (Dendy Newtown, 6.5/10).
• 30th of May: Pirates of the Caribbean: At World’s End (Hayden Orpheum, 7/10).
• 27th of June: Knocked Up (AMC Pacific Theatres, The Grove, Los Angeles, 8/10).
• 29th of June: Blades of Glory (Air New Zealand LAX to SYD, 8/10).
• 1st of July: Transformers (Hoyts Broadway, 8/10)
• 8th of July: Ocean’s Thirteen (Greater Union Bondi Junction, 7/10).
• 17th of July: Harry Potter and the Order Of the Phoenix (special groovy RSP screening at Hoyts, Fox Studios, 7/10).
• 2nd of August: Notes on a Scandal (DVD, 7/10).
• 5th of August: Fabuleux destin d’Amélie Poulain, Le, a.k.a. Amélie (DVD, 8.5/10)
• 7th of August: The Simpsons Movie (Hoyts Fox Studios, 7.5/10).
• 17th of August: Die Hard 4.0 (Hoyts Broadway, 7.5/10).
• 14th of September: The Bourne Ultimatum (Greater Union Bondi Junction, 6.5/10)
• 22nd of September: Ratatouille (Hoyts Broadway, 8.5/10)
• 23rd of September: An Inconvenient Truth (DVD, 8.5/10).
• 30th of September: The Holiday (DVD, 7/10)
• 5th of October: Shaun of the Dead (DVD, 7.5/10).
• 6th of October: Rush Hour 3 (Hoyts Chatswood Westfield, 6.5/10).
• 13th of October: Resident Evil: Extinction (Shaw Cinemas, Isetan Singapore, 6.5/10).
• 4th of November: A Chinese Odyssey (DVD, 6.5/10).
• 18th of November: Elizabeth: The Golden Age (Reading Cinemas at Rhodes, 7/10).
• 2nd of December: Stranger Than Fiction (DVD, 8/10).
• 9th of December: Ghost in the Shell S.A.C.: Solid State Society (DVD, 9/10)
• 16th of December: The Prestige (DVD, 8.5/10).
• 24th of December: National Treasure: Book of Secrets (Hoyts Chatswood Westfield, 7.5/10)
• 28th of December: Aliens vs. Predator: Requiem (Hoyts Chatswood Mandarin, 7.5/10)

All in all, a pretty good movie year, with Solid State Society topping the list, and The Prestige, Stranger than Fiction, An Inconvenient Truth, Ratatouille, Amélie, Transformers, Blades of Glory, Knocked Up, Hot Fuzz, The Fountain, and Blood Diamond as my personal A-graders. Reflecting back, about the only two ratings I disagree with are Pan’s Labyrinth (should’ve been way higher, probably 8 or 8.5) and An Inconvenient Truth (which I don’t think quite deserved an 8.5).

I await the arrival of Wall•E this year. The trailer looks like, well, it was done by Pixar. Great humour, fantastic graphics (thank you 1080p), kid-friendly, and with the director and writer of Finding Nemo, Monsters Inc, and Toy Story 2. I’m actually beginning to believe that Pixar have actually built a self-reinforcing system of awesome that is going to be impossible to knock down for at least the next fifty years. It’s pretty incredible that most of their blockbuster movies have been directed and produced by completely different people.

To all my friends working at Pixar, I love you. Please continue doing what you do best.

It seems that my exercise to keep track of every single movie I watched last year actually worked. Here’s how 2007 turned out for me:

• 5th of January: Blood Diamond (Hoyts Broadway, 8/10)
• 1st of February: Perfume (Hoyts Cinema Paris, 7/10)
• 4th of February: The Fountain (Hoyts George St City, 8/10)
• 10th of February: Fight Club (DVD, repeat viewing, 8/10)
• 11th of February: Pan’s Labyrinth (Hoyts George St City, 7/10)
• 10th of March: Quand j’étais chanteur, a.k.a The Singer (Palace Academy Paddington, 6.5/10)
• 18th of March: Hors de Prix, a.k.a. Priceless (Palace Academy Leichardt, 7/10)
• 24th of March: The Illusionist (Greater Union Tuggerah, 7/10)
• 3rd of April: Hot Fuzz (Hoyts Fox Studios, 8.5/10).
• 10th of April: 300 (Hoyts Westfield Chatswood, 7.5/10).
• 7th of May: La Science des rêves, a.k.a. The Science of Sleep (Hayden Orpheum, 7/10).
• 12th of May: Spider-man 3 (Hoyts Westfield Chatswood, 7.5/10)
• 22nd of May: Shooter (Greater Union Macquarie, 7/10).
• 27th of May: Tales from Earthsea (Dendy Newtown, 6.5/10).
• 30th of May: Pirates of the Caribbean: At World’s End (Hayden Orpheum, 7/10).
• 27th of June: Knocked Up (AMC Pacific Theatres, The Grove, Los Angeles, 8/10).
• 29th of June: Blades of Glory (Air New Zealand LAX to SYD, 8/10).
• 1st of July: Transformers (Hoyts Broadway, 8/10)
• 8th of July: Ocean’s Thirteen (Greater Union Bondi Junction, 7/10).
• 17th of July: Harry Potter and the Order Of the Phoenix (special groovy RSP screening at Hoyts, Fox Studios, 7/10).
• 2nd of August: Notes on a Scandal (DVD, 7/10).
• 5th of August: Fabuleux destin d’Amélie Poulain, Le, a.k.a. Amélie (DVD, 8.5/10)
• 7th of August: The Simpsons Movie (Hoyts Fox Studios, 7.5/10).
• 17th of August: Die Hard 4.0 (Hoyts Broadway, 7.5/10).
• 14th of September: The Bourne Ultimatum (Greater Union Bondi Junction, 6.5/10)
• 22nd of September: Ratatouille (Hoyts Broadway, 8.5/10)
• 23rd of September: An Inconvenient Truth (DVD, 8.5/10).
• 30th of September: The Holiday (DVD, 7/10)
• 5th of October: Shaun of the Dead (DVD, 7.5/10).
• 6th of October: Rush Hour 3 (Hoyts Chatswood Westfield, 6.5/10).
• 13th of October: Resident Evil: Extinction (Shaw Cinemas, Isetan Singapore, 6.5/10).
• 4th of November: A Chinese Odyssey (DVD, 6.5/10).
• 18th of November: Elizabeth: The Golden Age (Reading Cinemas at Rhodes, 7/10).
• 2nd of December: Stranger Than Fiction (DVD, 8/10).
• 9th of December: Ghost in the Shell S.A.C.: Solid State Society (DVD, 9/10)
• 16th of December: The Prestige (DVD, 8.5/10).
• 24th of December: National Treasure: Book of Secrets (Hoyts Chatswood Westfield, 7.5/10)
• 28th of December: Aliens vs. Predator: Requiem (Hoyts Chatswood Mandarin, 7.5/10)

All in all, a pretty good movie year, with Solid State Society topping the list, and The Prestige, Stranger than Fiction, An Inconvenient Truth, Ratatouille, Amélie, Transformers, Blades of Glory, Knocked Up, Hot Fuzz, The Fountain, and Blood Diamond as my personal A-graders. Reflecting back, about the only two ratings I disagree with are Pan’s Labyrinth (should’ve been way higher, probably 8 or 8.5) and An Inconvenient Truth (which I don’t think quite deserved an 8.5).

I await the arrival of Wall•E this year. The trailer looks like, well, it was done by Pixar. Great humour, fantastic graphics (thank you 1080p), kid-friendly, and with the director and writer of Finding Nemo, Monsters Inc, and Toy Story 2. I’m actually beginning to believe that Pixar have actually built a self-reinforcing system of awesome that is going to be impossible to knock down for at least the next fifty years. It’s pretty incredible that most of their blockbuster movies have been directed and produced by completely different people.

To all my friends working at Pixar, I love you. Please continue doing what you do best.

A small tip for l’iPhone digerati (aw haw haw haw!): if you, like me, like to look up currency rates, forget about all this Web browser and Web application malarkey. Use the Stocks application instead:

1. go to the Stocks application,
2. add a new stock,
3. use a stock name of AUDUSD=X for the Australian to US dollar, USDGBP=X for USD to the British Pound, etc. (Use the Yahoo! finance page if you don’t know the three-letter currency codes.)

Since a picture is worth a thousand words, here you go:

Pretty!

A small tip for l’iPhone digerati (aw haw haw haw!): if you, like me, like to look up currency rates, forget about all this Web browser and Web application malarkey. Use the Stocks application instead:

1. go to the Stocks application,
2. add a new stock,
3. use a stock name of AUDUSD=X for the Australian to US dollar, USDGBP=X for USD to the British Pound, etc. (Use the Yahoo! finance page if you don’t know the three-letter currency codes.)

Since a picture is worth a thousand words, here you go:

Pretty!

For all the oldskool Amiga demoscene folks out there, I’ve weirdly had a bit of nostalgia for the classic Jesus on E’s demo from 1992. It was was understandably not featured on Mindcandy Volume 2, although there are videos of it on the Web floating around. It’s somewhat amusing that the MPEG-4 video is around 120MB when the original version fit on two 880k disks.

So, I chopped up the MPEG-4 videos I found floating around on the Web, and exported the soundtrack to MPEG-4 audio files so I could throw them onto my iPod. The tracks are available at:

• http://www.algorithm.com.au/downloads/music/Jesus_on_Es-MP4.zip

If you’re into oldskool techno and rave tracks from the ~1992 era, you can’t beat this stuff. (And if you don’t like oldskool techno and rave tracks, the soundtrack will probably send you completely insane). Have the appropriate amount of fun!

For all the oldskool Amiga demoscene folks out there, I’ve weirdly had a bit of nostalgia for the classic Jesus on E’s demo from 1992. It was was understandably not featured on Mindcandy Volume 2, although there are videos of it on the Web floating around. It’s somewhat amusing that the MPEG-4 video is around 120MB when the original version fit on two 880k disks.

So, I chopped up the MPEG-4 videos I found floating around on the Web, and exported the soundtrack to MPEG-4 audio files so I could throw them onto my iPod. The tracks are available at:

• http://www.algorithm.com.au/downloads/music/Jesus_on_Es-MP4.zip

If you’re into oldskool techno and rave tracks from the ~1992 era, you can’t beat this stuff. (And if you don’t like oldskool techno and rave tracks, the soundtrack will probably send you completely insane). Have the appropriate amount of fun!

[Sorry if you get this post twice—let’s say that our internal builds of RapidWeaver 4.0 are still a little buggy, and I needed to re-post this ;)]

Xcode, Apple’s IDE for Mac OS X, has this neat ability to perform distributed compilations across multiple computers. The goal, of course, is to cut down on the build time. If you’re sitting at a desktop on a local network and have a Mac or two to spare, distributed builds obviously make a lot of sense: there’s a lot of untapped power that could be harnessed to speed up your build. However, there’s another scenario where distributed builds can help, and that’s if you work mainly off a laptop and occasionally join a network that has a few other Macs around. When your laptop’s offline, you can perform a distributed build with just your laptop; when your laptop’s connected to a few other Macs, they can join in the build and speed it up.

There’s one problem with idea, though, which is that distributed builds add overhead. I had a strong suspicion that a distributed build with only the local machine was a significant amount slower than a simple individual build. Since it’s all talk unless you have benchmarks, lo and behold, a few benchmarks later, I proved my suspicion right.

• Individual build: 4:50.6 (first run), 4:51.7 (second run)
• Shared network build with local machine only: 6:16.3 (first run), 6:16.3 (second run)

This was a realistic benchmark: it was a full build of RapidWeaver including all its sub-project dependencies and core plugins. The host machine is a 2GHz MacBook with 2GB of RAM. The build process includes a typical number of non-compilation phases, such running a shell script or two (which takes a few seconds), copying files to the final application bundle, etc. So, for a typical Mac desktop application project like RapidWeaver, turning on shared network builds without any extra hosts evokes a pretty hefty speed penalty: ~30% in my case. Ouch. You don’t want to leave shared network builds on when your laptop disconnects from the network. To add to the punishment, Xcode will recompile everything from scratch if you switch from individual builds to distributed builds (and vice versa), so flipping the switch when you disconnect from a network or reconnect to it is going to require a full rebuild.

Of course, there’s no point to using distributed builds if there’s only one machine participating. So, what happens when we add a 2.4GHz 20” Aluminium Intel iMac with 2GB of RAM, via Gigabit Ethernet? Unfortunately, not much:

• Individual build: 4:50.6 (first run), 4:51.7 (second run)
• Shared network build with local machine + 2.4GHz iMac: 4:46.6 (first run), 4:46.6 (second run)

You shave an entire four seconds off the build time by getting a 2.4GHz iMac to help out a 2GHz MacBook. A 1% speed increase isn’t very close to the 40% build time reduction that you’re probably hoping for. Sure, a 2.4GHz iMac is not exactly a build farm, but you’d hope for something a little better than a 1% speed improvement by doubling the horsepower, no? Gustafson’s Law strikes again: parallelism is hard, news at 11.

I also timed Xcode’s dedicated network builds (which are a little different from its shared network builds), but buggered if I know where I put the results for that. I vaguely remember that dedicated network builds was very similar to shared network builds with my two hosts, but my memory’s hazy.

So, lesson #1: there’s no point using distributed builds unless there’s usually at least one machine available to help out, otherwise your builds are just going to slow down. Lesson #2: you need to add a significant amount more CPUs to save a significant amount of time with distributed builds. A single 2.4GHz iMac doesn’t appear to help much. I’m guessing that adding a quad-core or eight-core Mac Pro to the build will help. Maybe 10 × 2GHz Intel Mac minis will help, but I’d run some benchmarks on that setup before buying a cute Mac mini build farm — perhaps the overhead of distributing the build to ten other machines is going to nullify any timing advantage you’d get from throwing another 20GHz of processors into the mix.

[Sorry if you get this post twice—let’s say that our internal builds of RapidWeaver 4.0 are still a little buggy, and I needed to re-post this ;)]

Xcode, Apple’s IDE for Mac OS X, has this neat ability to perform distributed compilations across multiple computers. The goal, of course, is to cut down on the build time. If you’re sitting at a desktop on a local network and have a Mac or two to spare, distributed builds obviously make a lot of sense: there’s a lot of untapped power that could be harnessed to speed up your build. However, there’s another scenario where distributed builds can help, and that’s if you work mainly off a laptop and occasionally join a network that has a few other Macs around. When your laptop’s offline, you can perform a distributed build with just your laptop; when your laptop’s connected to a few other Macs, they can join in the build and speed it up.

There’s one problem with idea, though, which is that distributed builds add overhead. I had a strong suspicion that a distributed build with only the local machine was a significant amount slower than a simple individual build. Since it’s all talk unless you have benchmarks, lo and behold, a few benchmarks later, I proved my suspicion right.

• Individual build: 4:50.6 (first run), 4:51.7 (second run)
• Shared network build with local machine only: 6:16.3 (first run), 6:16.3 (second run)

This was a realistic benchmark: it was a full build of RapidWeaver including all its sub-project dependencies and core plugins. The host machine is a 2GHz MacBook with 2GB of RAM. The build process includes a typical number of non-compilation phases, such running a shell script or two (which takes a few seconds), copying files to the final application bundle, etc. So, for a typical Mac desktop application project like RapidWeaver, turning on shared network builds without any extra hosts evokes a pretty hefty speed penalty: ~30% in my case. Ouch. You don’t want to leave shared network builds on when your laptop disconnects from the network. To add to the punishment, Xcode will recompile everything from scratch if you switch from individual builds to distributed builds (and vice versa), so flipping the switch when you disconnect from a network or reconnect to it is going to require a full rebuild.

Of course, there’s no point to using distributed builds if there’s only one machine participating. So, what happens when we add a 2.4GHz 20” Aluminium Intel iMac with 2GB of RAM, via Gigabit Ethernet? Unfortunately, not much:

• Individual build: 4:50.6 (first run), 4:51.7 (second run)
• Shared network build with local machine + 2.4GHz iMac: 4:46.6 (first run), 4:46.6 (second run)

You shave an entire four seconds off the build time by getting a 2.4GHz iMac to help out a 2GHz MacBook. A 1% speed increase isn’t very close to the 40% build time reduction that you’re probably hoping for. Sure, a 2.4GHz iMac is not exactly a build farm, but you’d hope for something a little better than a 1% speed improvement by doubling the horsepower, no? Gustafson’s Law strikes again: parallelism is hard, news at 11.

I also timed Xcode’s dedicated network builds (which are a little different from its shared network builds), but buggered if I know where I put the results for that. I vaguely remember that dedicated network builds was very similar to shared network builds with my two hosts, but my memory’s hazy.

So, lesson #1: there’s no point using distributed builds unless there’s usually at least one machine available to help out, otherwise your builds are just going to slow down. Lesson #2: you need to add a significant amount more CPUs to save a significant amount of time with distributed builds. A single 2.4GHz iMac doesn’t appear to help much. I’m guessing that adding a quad-core or eight-core Mac Pro to the build will help. Maybe 10 × 2GHz Intel Mac minis will help, but I’d run some benchmarks on that setup before buying a cute Mac mini build farm — perhaps the overhead of distributing the build to ten other machines is going to nullify any timing advantage you’d get from throwing another 20GHz of processors into the mix.

If you love programming, and especially if you love programming languages, there’s an episode of the Software Engineering Radio podcast that has a fantastic interview with Dick Gabriel, titled “Dick Gabriel on Lisp”. If you don’t know who Gabriel is, he’s arguably one of the more important programming language people around, is one of the founding fathers of XEmacs (neé Lucid Emacs), wrote the famous Worse is Better essay (along with a pretty cool book that I’ll personally recommend), and also gave one of the most surreal and brilliant keynotes that I’ve ever heard that received a standing ovation at HoPL III and OOPSLA.

The episode’s about fifty minutes long, and Gabriel talks about a lot more than just Lisp in the interview: among other things, he gives some major insight into the essence of object-oriented message-passing, how functions are objects and objects are functions, what continuations are, metacircularity, and the relationship between XML and S-expressions (and why XML is just a glorified half-assed version of Lisp). There’s also some great stories in the interview for computing historians: how the Common Lisp Object System was initially inspired by Scheme and the original Actor language (yep, “actors” as in “Erlang processes”), what AI research was like in the 1960s and ’70s, and the story of how John McCarthy and his students implemented the first Lisp interpreter in one night.

A wonderful interview, and well worth listening to if programming languages is your shindig.

If you love programming, and especially if you love programming languages, there’s an episode of the Software Engineering Radio podcast that has a fantastic interview with Dick Gabriel, titled “Dick Gabriel on Lisp”. If you don’t know who Gabriel is, he’s arguably one of the more important programming language people around, is one of the founding fathers of XEmacs (neé Lucid Emacs), wrote the famous Worse is Better essay (along with a pretty cool book that I’ll personally recommend), and also gave one of the most surreal and brilliant keynotes that I’ve ever heard that received a standing ovation at HoPL III and OOPSLA.

The episode’s about fifty minutes long, and Gabriel talks about a lot more than just Lisp in the interview: among other things, he gives some major insight into the essence of object-oriented message-passing, how functions are objects and objects are functions, what continuations are, metacircularity, and the relationship between XML and S-expressions (and why XML is just a glorified half-assed version of Lisp). There’s also some great stories in the interview for computing historians: how the Common Lisp Object System was initially inspired by Scheme and the original Actor language (yep, “actors” as in “Erlang processes”), what AI research was like in the 1960s and ’70s, and the story of how John McCarthy and his students implemented the first Lisp interpreter in one night.

A wonderful interview, and well worth listening to if programming languages is your shindig.

I found this short article about law and code on builderAU rather interesting. The money quotes are the first and last paragraphs:

Technology has outpaced the legal system’s ability to regulate its use in matters of privacy and fair use rights, said Kirby… “We are moving to a point in the world where more and more law will be expressed in its effective way, not in terms of statutes solidly enacted by the parliament… but in the technology itself—code,” said Kirby.

I think that’s a great quote, and it shows that Justice Kirby has a pretty solid understanding of what code is, how it interacts with law, and that the USA’s Digital Millennium Copyright Act (DMCA)—and Australia’s Digital Agenda Act—are dangerous things. (I do think that the builderAU article emphasis on Google and Yahoo being the two culprits seem odd, although it’s hard to say this without listening to Kirby’s original speech.) I’ve always been a fan of Justice Kirby, and it’s nice to know that somebody-on-high understands that code-as-law is a problem, and it’s a complex one.

I found this short article about law and code on builderAU rather interesting. The money quotes are the first and last paragraphs:

Technology has outpaced the legal system’s ability to regulate its use in matters of privacy and fair use rights, said Kirby… “We are moving to a point in the world where more and more law will be expressed in its effective way, not in terms of statutes solidly enacted by the parliament… but in the technology itself—code,” said Kirby.

I think that’s a great quote, and it shows that Justice Kirby has a pretty solid understanding of what code is, how it interacts with law, and that the USA’s Digital Millennium Copyright Act (DMCA)—and Australia’s Digital Agenda Act—are dangerous things. (I do think that the builderAU article emphasis on Google and Yahoo being the two culprits seem odd, although it’s hard to say this without listening to Kirby’s original speech.) I’ve always been a fan of Justice Kirby, and it’s nice to know that somebody-on-high understands that code-as-law is a problem, and it’s a complex one.

The Foundations of Open Media Software (FOMS) workshop took place last month, from the 24th to 25th of January. FOMS is a rare opportunity for open-source multimedia developers and industry folks to get together all in one place, and the result is two days of intense discussion about issues such as encapsulation formats, codecs, video and audio output APIs, media commons, and metadata—not to mention sharing a common hatred of Flash. The first FOMS was held last year in 2007, and was a great melting pot for people from very different open-source multimedia projects, such as xine, xiph.org, GStreamer and Nokia, to get together. This year’s FOMS proved to be just as successful; this time with folks from Sun, Opera and the BBC joining the fray.

One wonderful thing about this FOMS was that a large number of the xiph.org folks (Monty, Derf, Rillian, Jean-Marc and MikeS) were all there. xiph.org are one of the main providers of freely available multimedia standards, and it’s rare that their members have an opportunity to meet in person. It’s a little strange that they met in Melbourne rather than in the USA where the majority of their members are, but hey, I’m sure they won’t complaining about that!

For me, there was a bit of an ominous atmosphere leading up to FOMS due to the recent outbreaks of “discussion” in December 2007 about the HTML5 recommended video codec. (I use the one “discussion” lightly here, since it was a lot more like hearing one’s angry neighbour trying to break down a brick wall with their head, for about a week.) It seemed obvious that the HTML5 video codec problem would be discussed at length at FOMS, but I hoped that it wouldn’t dominate discussion, since there were a lot better things to do with the combined intellectual might of all the attendees than talk about issues that were mostly political and arguably largely out of their hands to solve.

I’m glad to say that the HTML5 video codec problem was definitely discussed, but with a great focus on finding a solution rather than wailing on about the problem. Ogg Theora and Dirac, represented by xiph.org and the BBC at FOMS, are two of the contenders for the HTML5 baseline video codec recommendation, and it was excellent to see that people were discussing technical aspects that may be hindering their adoption by the W3C, always keeping the bigger picture in mind.

There were also breakout groups that threw down some short-term and long-term goals for the FOMS attendees: I personally took part in a discussion about metadata, text markup of video (subtitling, closed captions, and transcriptions), and video composition and aggregation (“video mashups”). Shane Stephens would present a great talk at Linux.conf.au a few days later about Web 2.0-style community-based video remixing; if you’re interested at all in video mashups and video mixups, be sure to check out his talk!

If you’re interested at all in the open-standards multimedia space, the proceedings of FOMS are available online thanks to the FOMS A/V team, with a big thanks to Michael Dale for bringing his incredible metavid video content management system to the humble FOMS site. (You may also be interested in the W3C Video on the Web Workshop Report that was very recently released.) In an area that’s as complicated as multimedia, FOMS is tremendously valuable as a place for open-source developers to meet. It was a great complement to Linux.conf.au, and here’s hoping it’ll be on again next year!

The Foundations of Open Media Software (FOMS) workshop took place last month, from the 24th to 25th of January. FOMS is a rare opportunity for open-source multimedia developers and industry folks to get together all in one place, and the result is two days of intense discussion about issues such as encapsulation formats, codecs, video and audio output APIs, media commons, and metadata—not to mention sharing a common hatred of Flash. The first FOMS was held last year in 2007, and was a great melting pot for people from very different open-source multimedia projects, such as xine, xiph.org, GStreamer and Nokia, to get together. This year’s FOMS proved to be just as successful; this time with folks from Sun, Opera and the BBC joining the fray.

One wonderful thing about this FOMS was that a large number of the xiph.org folks (Monty, Derf, Rillian, Jean-Marc and MikeS) were all there. xiph.org are one of the main providers of freely available multimedia standards, and it’s rare that their members have an opportunity to meet in person. It’s a little strange that they met in Melbourne rather than in the USA where the majority of their members are, but hey, I’m sure they won’t complaining about that!

For me, there was a bit of an ominous atmosphere leading up to FOMS due to the recent outbreaks of “discussion” in December 2007 about the HTML5 recommended video codec. (I use the one “discussion” lightly here, since it was a lot more like hearing one’s angry neighbour trying to break down a brick wall with their head, for about a week.) It seemed obvious that the HTML5 video codec problem would be discussed at length at FOMS, but I hoped that it wouldn’t dominate discussion, since there were a lot better things to do with the combined intellectual might of all the attendees than talk about issues that were mostly political and arguably largely out of their hands to solve.

I’m glad to say that the HTML5 video codec problem was definitely discussed, but with a great focus on finding a solution rather than wailing on about the problem. Ogg Theora and Dirac, represented by xiph.org and the BBC at FOMS, are two of the contenders for the HTML5 baseline video codec recommendation, and it was excellent to see that people were discussing technical aspects that may be hindering their adoption by the W3C, always keeping the bigger picture in mind.

There were also breakout groups that threw down some short-term and long-term goals for the FOMS attendees: I personally took part in a discussion about metadata, text markup of video (subtitling, closed captions, and transcriptions), and video composition and aggregation (“video mashups”). Shane Stephens would present a great talk at Linux.conf.au a few days later about Web 2.0-style community-based video remixing; if you’re interested at all in video mashups and video mixups, be sure to check out his talk!

If you’re interested at all in the open-standards multimedia space, the proceedings of FOMS are available online thanks to the FOMS A/V team, with a big thanks to Michael Dale for bringing his incredible metavid video content management system to the humble FOMS site. (You may also be interested in the W3C Video on the Web Workshop Report that was very recently released.) In an area that’s as complicated as multimedia, FOMS is tremendously valuable as a place for open-source developers to meet. It was a great complement to Linux.conf.au, and here’s hoping it’ll be on again next year!

I’ve finally updated my Mac OS X software list to be Leopard-aware, for those of you new to Apple’s shiny little operating system. Spotting the changes between the older version and newer one is left as an exercise for the reader :-). (Boy I’m glad to have TextExtras working with garbage-collected applications on Leopard!)

I’ve finally updated my Mac OS X software list to be Leopard-aware, for those of you new to Apple’s shiny little operating system. Spotting the changes between the older version and newer one is left as an exercise for the reader :-). (Boy I’m glad to have TextExtras working with garbage-collected applications on Leopard!)

Perhaps the most annoying feature of the iPhone is its recessed headphones jack:

This miserable little design decision has spawned an entire bloody industry of headphones adapters just so that you can use your own preferred set of headphones with the thing (though admittedly some headphones adapters are way cooler than others). Me, I preferred a slightly cheaper hack. And by hack, I mean hacksaw.

Process:

1. G’day, where’s the cheese?Get a kitchen knife.
2. Use kitchen knife obtained from step 1 to cut off the end of the rubber sheath at the end of your headphones plug.

Et voilà! Headphones that fit in rather nicely to that stupid jack. It also seems that a few other people have done this as well, but they applied slightly more rigourous methods than me (i.e. they used one of those “proper knives” rather than, say, a kitchen knife).

It's entirely stupid that we have to do this in the first place, but on the bright side, it does solve one of the only major annoyances I've had with the thing, which elevates the iPhone from being "pretty damn good" to "near perfect" in my eyes. One hopes that Apple won't be repeating this particular design decision for their next iPhone revision.