I think my current plan of being self-employed is arguably working out pretty well. I get to work on RapidWeaver and LittleSnapper, two kick-ass products with a ton of users who love it. I’m friends with the lovely baristas and staff at my local café, where I normally work during the day. However, nothing beats taking a weekday off to chill out at my favourite café in Sydney, perhaps catching some waves at Bondi Beach and then playing some tennis afterwards, only to put my head down and code at night when the distractions are minimal. Life, as they say, is pretty peachy.

So, just before my 30th birthday, it was with both great apprehension and excitement that I made the decision to give up my current lifestyle and my current job. In five days, I move from the comfort of Sydney to magnificent San Francisco, to start work for a company that I’ve loved so much ever since I was a kid: Pixar.

To say that this was not where I expected to be in my life is quite an understatement. I was always the guy who thought that things would fall into place if he found the right girl, and that career would work itself out later. I fell in love hard when I was 21, was about this close to deciding to get married when I was 26, and when things went south, it took countless numbers of D&M talks with my close friends (thank you thank you thank you), another wonderful relationship with one of the most amazing people I know, and over three years to truly recover. I spent weeks in self-reflection pondering what life was about, what the day-to-day drudgery meant, and what I had accomplished during my second decade on Earth while so many of my friends were growing by leaps and bounds in their own relationships.

Meanwhile, my career was working out just fine. I worked on one project that will hopefully have the success it deserves with the release of Firefox 3.1 and perhaps take the lead in the important area of open-standards video on the Web. I’ve worked on other projects that are all tremendous successes in their respective markets, and along the way, I made a ton of genuine friends in the demoscene, Haskell, Linux and Mac OS X communities. Nonetheless, I still felt that I failed to meet my own expectations, since I’d never considered my career to be a measure of success. Despite the fantastic lifestyle that working remotely for Realmac afforded me, I was still restless, and still felt incomplete in my personal life.

Last year, I travelled a lot, not as a means of escapism, but because I had a ton of conferences to hit, and also wanted to visit some of my best friends who were now overseas. As I hopped from the UK to the USA to Singapore, I spent a lot of time alone, as travel does to you, and reflected on life. One day, I spent eight hours by myself in my favourite tea lounge in San Francisco, mixing feelings about the past decade and all its ups and downs: perhaps my expectations were too high, or perhaps I concentrated too much on things that would simply work themselves out. By the time I returned to Australia’s beautiful shores in December, I was exhausted from too much reflection, too much living out of a duffel bag on the road for months, and too much melancholy from thinking about the past and too much searching without answers.

However, something else happened in those months of travel: all of those worries slowly felt more and more like experience. I figured that, hey, my third decade was looming; either I start my thirties by continuing to be subtly haunted by those worries of the past decade, or I could treat those worries as learning experiences and forge a new outlook that relished any challenges the future could bring. As Steve Jobs says, “sometimes life hits you in the head with a brick. Don’t lose faith.” And so, just as I started to feel happy when I finally returned home, Pixar came knocking. I flew to San Francisco just a few days after arriving back in Sydney from months of travel; it would be my last trip for 2008. I did the interview thing, and a week later when I was back again in Sydney to wind down for Christmas, I got The Phone Call. When would I be able to move to San Francisco to start work there?

I thought hard about my current lifestyle of cafés and working remotely, and how I loved working at a small company like Realmac where I was directly responsible for the welfare of a much-loved application. I anguished over all the friends I had made in Australia and how much I’d miss them, and how much I’d miss my family. I thought about how I made my life here: how I went to school here, University here, met all my lovers here, and how this was, well, home. In the end, though, how could I turn down the opportunity of a lifetime, working at a company that married art and science so perfectly, and inspires so much love & passion in everyone? (Also, I hear there’s a lot of hot Asian-American girls in San Francisco.)

There’s no moral to this story: it just is, and I thought it needed telling while I still had the guts to tell it. So, as of next Wednesday, I leave my wonderful memories here to explore life in a new city. I’ve traditionally used this blog to communicate my thoughts on computing and technology, but I’ve always admired and enjoyed reading other people’s blogs that were much more personal (without being totally emo). Hopefully I’ll transform this blog a little to have a far more personal feel, so I can keep in touch with all the people I know & love around the world; thank you all for being a part of my life and enriching and defining me. See you on the other side of the Pacific!

Quite often, you may have simple setter methods that need to do a just a tiny bit of work before or after setting an instance variable. For example, maybe you need to redraw something after setting the property of an object. So, instead of writing this:

[self setBackgroundColor:[NSColor blueColor]]; [view setBackgroundColor:[NSColor blueColor]];

You’d probably want to move the relevant code to your -setBackgroundColor: accessor instead:

- (void)setBackgroundColor:(NSColor*)color { // Assuming that _backgroundColor is the ivar you want to set if(_backgroundColor != color) { [_backgroundColor release]; _backgroundColor = [color retain]; // Update the view's background color to reflect the change [view setBackgroundColor:_backgroundColor]; } }

Then you can simply call -setBackgroundColor: and expect it all to work nicely:

// -setBackgroundColor: updates the view's background color // automatically now [self setBackgroundColor:[NSColor blueColor]];

(You could use Key-Value Observing to do this, but I generally avoid KVO for simple intra-class property dependencies like this. I don’t think the overhead of maintaining all the KVC dependencies and KVO-related methods is worth the cost.)

Of course, the above method requires that you write all that stupid boilerplate memory management code in the accessor. Instead of doing that, I tend to declare a private _backgroundColor property in the class, @synthesize a method for the private property, and then use the private property’s generated accessors instead:

@interface MyClass () // Declare a _private_ _backgroundColor property (thus the underscore // in front, and why it's declared in a class continuation rather than // in the public header) @property (copy, setter=_setBackgroundColor:) NSColor* _backgroundColor; @end // @implementation MyClass @synthesize _backgroundColor; - (NSColor*)backgroundColor { return [self _backgroundColor]; } - (void)setBackgroundColor:(NSColor*)color { // Use the private property to set the background colour, so it // handles the memory management bollocks [self _setBackgroundColor:color]; [view setBackgroundColor:[self _backgroundColor]]; } ... @end

With that technique, it’s possible to completely directly setting ivars, and thus avoid -retain and -release altogether. (You’ll still need to use -autorelease at various times, of course, but that’s reasonably rare.) We have some source code files that are well over 2000 lines of code without a single explicit [_ivar retain]; or [_ivar release]; call thanks to this technique. (Yeah, 2000 lines is also large and the class needs refactoring, but that’s another story.)

Of course, you could just use garbage collection which avoids 99% of the need for this bollocks:

- (void)setBackgroundColor:(NSColor*)color { // Yay GC! self->_backgroundColor = color; [view setBackgroundColor:self->_backgroundColor]; }

But plenty of us don’t have that luxury yet. (iPhone, ahem.)

Quite often, you may have simple setter methods that need to do a just a tiny bit of work before or after setting an instance variable. For example, maybe you need to redraw something after setting the property of an object. So, instead of writing this:

[self setBackgroundColor:[NSColor blueColor]]; [view setBackgroundColor:[NSColor blueColor]];

You’d probably want to move the relevant code to your -setBackgroundColor: accessor instead:

- (void)setBackgroundColor:(NSColor*)color { // Assuming that _backgroundColor is the ivar you want to set if(_backgroundColor != color) { [_backgroundColor release]; _backgroundColor = [color retain]; // Update the view's background color to reflect the change [view setBackgroundColor:_backgroundColor]; } }

Then you can simply call -setBackgroundColor: and expect it all to work nicely:

// -setBackgroundColor: updates the view's background color // automatically now [self setBackgroundColor:[NSColor blueColor]];

(You could use Key-Value Observing to do this, but I generally avoid KVO for simple intra-class property dependencies like this. I don’t think the overhead of maintaining all the KVC dependencies and KVO-related methods is worth the cost.)

Of course, the above method requires that you write all that stupid boilerplate memory management code in the accessor. Instead of doing that, I tend to declare a private _backgroundColor property in the class, @synthesize a method for the private property, and then use the private property’s generated accessors instead:

[@interface](https://micro.blog/interface) MyClass () // Declare a _private_ _backgroundColor property (thus the underscore // in front, and why it's declared in a class continuation rather than // in the public header) [@property](https://micro.blog/property) (copy, setter=_setBackgroundColor:) NSColor* _backgroundColor; @end // @implementation MyClass @synthesize _backgroundColor; - (NSColor*)backgroundColor { return [self _backgroundColor]; } - (void)setBackgroundColor:(NSColor*)color { // Use the private property to set the background colour, so it // handles the memory management bollocks [self _setBackgroundColor:color]; [view setBackgroundColor:[self _backgroundColor]]; } ... @end

With that technique, it’s possible to completely directly setting ivars, and thus avoid -retain and -release altogether. (You’ll still need to use -autorelease at various times, of course, but that’s reasonably rare.) We have some source code files that are well over 2000 lines of code without a single explicit [_ivar retain]; or [_ivar release]; call thanks to this technique. (Yeah, 2000 lines is also large and the class needs refactoring, but that’s another story.)

Of course, you could just use garbage collection which avoids 99% of the need for this bollocks:

- (void)setBackgroundColor:(NSColor*)color { // Yay GC! self->_backgroundColor = color; [view setBackgroundColor:self->_backgroundColor]; }

But plenty of us don’t have that luxury yet. (iPhone, ahem.)

For the UNIX users out there who use the git revision control system with the oldskool less pager, try adding the following to your ~/.gitconfig file:

[core]
    # search for core.pager in
    # <http://www.kernel.org/pub/software/scm/git/docs/git-config.html>
    # to see why we use this convoluted syntax
    pager = less -$LESS -SFRX -SR +'/^---'

That’ll launch less with three options set:

• -S: chops long lines rather than folding them (personal preference),
• -R: permits ANSI colour escape sequences so that git’s diff colouring still works, and
• +'/^---': sets the default search regex to ^--- (find --- at the beginning of the line), so that you can easily skip to the next file in your pager with the n key.

The last one’s the handy tip. I browse commits using git diff before committing them, and like being able to jump quickly back and forth between files. Alas, since less is a dumb pager and doesn’t understand the semantics of diff patches, we simply set the find regex to ^---, which does what we want.

Of course, feel free to change the options to your heart’s content. See the less(1) manpage for the gory details.

As the comment in the configuration file says, you’ll need to use the convoluted less -$LESS -SFRX prefix due to interesting git behaviour with the LESS environment variable:

Note that git sets the LESS environment variable to FRSX if it is unset when it runs the pager. One can change these settings by setting the LESS variable to some other value. Alternately, these settings can be overridden on a project or global basis by setting the core.pager option. Setting core.pager has no affect on the LESS environment variable behaviour above, so if you want to override git’s default settings this way, you need to be explicit. For example, to disable the S option in a backward compatible manner, set core.pager to "less -+$LESS -FRX". This will be passed to the shell by git, which will translate the final command to "LESS=FRSX less -+FRSX -FRX".

(And sure, I could switch to using a different pager, but I’ve been using less for more than a decade. Yep, I know all about Emacs & Vim’s diff-mode and Changes.app. It’s hard to break old habits.)

For the UNIX users out there who use the git revision control system with the oldskool less pager, try adding the following to your ~/.gitconfig file:

[core]
    # search for core.pager in
    # <http://www.kernel.org/pub/software/scm/git/docs/git-config.html>
    # to see why we use this convoluted syntax
    pager = less -$LESS -SFRX -SR +'/^---'

That’ll launch less with three options set:

• -S: chops long lines rather than folding them (personal preference),
• -R: permits ANSI colour escape sequences so that git’s diff colouring still works, and
• +'/^---': sets the default search regex to ^--- (find --- at the beginning of the line), so that you can easily skip to the next file in your pager with the n key.

The last one’s the handy tip. I browse commits using git diff before committing them, and like being able to jump quickly back and forth between files. Alas, since less is a dumb pager and doesn’t understand the semantics of diff patches, we simply set the find regex to ^---, which does what we want.

Of course, feel free to change the options to your heart’s content. See the less(1) manpage for the gory details.

As the comment in the configuration file says, you’ll need to use the convoluted less -$LESS -SFRX prefix due to interesting git behaviour with the LESS environment variable:

Note that git sets the LESS environment variable to FRSX if it is unset when it runs the pager. One can change these settings by setting the LESS variable to some other value. Alternately, these settings can be overridden on a project or global basis by setting the core.pager option. Setting core.pager has no affect on the LESS environment variable behaviour above, so if you want to override git’s default settings this way, you need to be explicit. For example, to disable the S option in a backward compatible manner, set core.pager to "less -+$LESS -FRX". This will be passed to the shell by git, which will translate the final command to "LESS=FRSX less -+FRSX -FRX".

(And sure, I could switch to using a different pager, but I’ve been using less for more than a decade. Yep, I know all about Emacs & Vim’s diff-mode and Changes.app. It’s hard to break old habits.)

Four little announcements, all of them Mac-related:

First, myself and my comrades at Realmac Software are very proud to announce the release of LittleSnapper 1.0, our swiss-army-knife picture, screenshot and website organisation utility thingamijiggo. We’ve all worked hard on this for the past few months and sweated over a ton of details to try to make it a polished user experience and be a joy to use; we hope you agree. (You would not believe how long we spent figuring out how the blur and highlighting tools should work before they became their final incarnations, or how much pain was involved when we decided to add FTP and SFTP¹ support late in the development cycle.) If you’re a Mac user, give it a whirl; it’s a hard program to describe because it has a lot of different workflows, but between the quick annotation tools, easy Web sharing with QuickSnapper/Flickr/SFTP¹, website DOM snapping, and the iPhoto-like forget-about-what-folder-you-need-to-put-your-picture-in snapshot management, I’m sure you’ll find something useful for you in there. Hopefully our hard work can make life just a little easier for you!

¹ FTP must die.

I blogged earlier that I was speaking at MacDev 2009 in April, but didn’t mention exactly what I was talking about. Well, the talk abstract’s up now:

One reason for Mac OS X’s success is Objective-C, combining the dynamism of a scripting language with the performance of a compiled language. However, how does Objective-C work its magic and what principles is it based upon? In this session, we explore the inner workings of the Objective-C runtime, and see how a little knowledge about programming language foundations—such as lambda calculus and type theory—can go a long way to tackling difficult topics in Cocoa such as error handling and concurrency. We’ll cover a broad range of areas such as garbage collection, blocks, and data structure design, with a focus on practical tips and techniques that can immediately improve your own code’s quality and maintainability.

So, two sections: first, low-level hackery of the Objective-C runtime. Second, a different kind of low-level hackery, and one that’s arguably far more important: understanding the essence of computation and programming languages, and why I fell in love with both Haskell & Objective-C, two languages at completely opposite ends of the planet.

I’d like to point out that while the MacDev registration fee seems fairly expensive at £399, keep in mind that covers your accommodation and also meals, which easily covers £100-£150. Scotty’s done a lot of organising so that you don’t have to. There’s also a Christmas special on at the moment where a few applications are included in the registration price; check the MacDev 2009 website for details.

If you’re an imsoniac and are having trouble sleeping, you’ll hopefully enjoy a recent Late Night Cocoa episode where I talk to Scotty about Garbage Collection. (Actually, you probably won’t enjoy it so much after you find out exactly how -retain & -release are implemented under-the-hood. The words CFBag and “lock” should hopefully scare you enough.) It’s a bit of a long episode at over an hour and a quarter long, but next time I’ll say “um” a bit less which should shorten it to about half an hour. Have fun. And use GC! (LittleSnapper and RapidWeaver both aren’t GC yet, but you bet your ass they will be for the next major versions.)

I’ve had a pretty long exodus away from the fp-syd user group since I was off getting drunk overseas for about four months. That, of course, meant that somehow my brain was rather misplaced when I arrived back in Sydney, so I decided to give a talk at fp-syd upon my return… on the same day that LittleSnapper 1.0 was due to be released, leaving pretty much no margin for error. Oops. I’ll glad to say that the gusto prevailed, and that both the talk seemed to go OK (well, I wasn’t booed off the stage anyway), and LittleSnapper was released on time. (Just; thanks Alan and Danny!) My talk there was similar to the one I gave at Galois in Portland earlier this year: a whirlwind tour of the Objective-C programming language and Mac OS X technologies for a functional programming audience. In particular:

• basics of the runtime system,
• higher-order messaging and its analogy to higher-order functions in functional languages,
• some details on the engineering marvel that is the Objective-C garbage collector, and
• (updated!) information on Blocks, LLVM and Clang, and a wee tiny bit of info on Grand Central Dispatch and OpenCL.

I’ve updated the talk with a few extra slides, since Apple have made a little more information to the public now. (In particular, brief information on Blocks, Grand Central Dispatch and OpenCL.) Enjoy all!

Four little announcements, all of them Mac-related:

First, myself and my comrades at Realmac Software are very proud to announce the release of LittleSnapper 1.0, our swiss-army-knife picture, screenshot and website organisation utility thingamijiggo. We’ve all worked hard on this for the past few months and sweated over a ton of details to try to make it a polished user experience and be a joy to use; we hope you agree. (You would not believe how long we spent figuring out how the blur and highlighting tools should work before they became their final incarnations, or how much pain was involved when we decided to add FTP and SFTP¹ support late in the development cycle.) If you’re a Mac user, give it a whirl; it’s a hard program to describe because it has a lot of different workflows, but between the quick annotation tools, easy Web sharing with QuickSnapper/Flickr/SFTP¹, website DOM snapping, and the iPhoto-like forget-about-what-folder-you-need-to-put-your-picture-in snapshot management, I’m sure you’ll find something useful for you in there. Hopefully our hard work can make life just a little easier for you!

¹ FTP must die.

I blogged earlier that I was speaking at MacDev 2009 in April, but didn’t mention exactly what I was talking about. Well, the talk abstract’s up now:

One reason for Mac OS X’s success is Objective-C, combining the dynamism of a scripting language with the performance of a compiled language. However, how does Objective-C work its magic and what principles is it based upon? In this session, we explore the inner workings of the Objective-C runtime, and see how a little knowledge about programming language foundations—such as lambda calculus and type theory—can go a long way to tackling difficult topics in Cocoa such as error handling and concurrency. We’ll cover a broad range of areas such as garbage collection, blocks, and data structure design, with a focus on practical tips and techniques that can immediately improve your own code’s quality and maintainability.

So, two sections: first, low-level hackery of the Objective-C runtime. Second, a different kind of low-level hackery, and one that’s arguably far more important: understanding the essence of computation and programming languages, and why I fell in love with both Haskell & Objective-C, two languages at completely opposite ends of the planet.

I’d like to point out that while the MacDev registration fee seems fairly expensive at £399, keep in mind that covers your accommodation and also meals, which easily covers £100-£150. Scotty’s done a lot of organising so that you don’t have to. There’s also a Christmas special on at the moment where a few applications are included in the registration price; check the MacDev 2009 website for details.

If you’re an imsoniac and are having trouble sleeping, you’ll hopefully enjoy a recent Late Night Cocoa episode where I talk to Scotty about Garbage Collection. (Actually, you probably won’t enjoy it so much after you find out exactly how -retain & -release are implemented under-the-hood. The words CFBag and “lock” should hopefully scare you enough.) It’s a bit of a long episode at over an hour and a quarter long, but next time I’ll say “um” a bit less which should shorten it to about half an hour. Have fun. And use GC! (LittleSnapper and RapidWeaver both aren’t GC yet, but you bet your ass they will be for the next major versions.)

I’ve had a pretty long exodus away from the fp-syd user group since I was off getting drunk overseas for about four months. That, of course, meant that somehow my brain was rather misplaced when I arrived back in Sydney, so I decided to give a talk at fp-syd upon my return… on the same day that LittleSnapper 1.0 was due to be released, leaving pretty much no margin for error. Oops. I’ll glad to say that the gusto prevailed, and that both the talk seemed to go OK (well, I wasn’t booed off the stage anyway), and LittleSnapper was released on time. (Just; thanks Alan and Danny!) My talk there was similar to the one I gave at Galois in Portland earlier this year: a whirlwind tour of the Objective-C programming language and Mac OS X technologies for a functional programming audience. In particular:

• basics of the runtime system,
• higher-order messaging and its analogy to higher-order functions in functional languages,
• some details on the engineering marvel that is the Objective-C garbage collector, and
• (updated!) information on Blocks, LLVM and Clang, and a wee tiny bit of info on Grand Central Dispatch and OpenCL.

I’ve updated the talk with a few extra slides, since Apple have made a little more information to the public now. (In particular, brief information on Blocks, Grand Central Dispatch and OpenCL.) Enjoy all!

A website named Neat Little Mac Apps is not the kind of place you’d expect to find an interview with a operating systems and filesystems hacker. Nevertheless, one of their podcasts was just that: an interview with UNIX and BSD legend Marshall Kirk McKusick. (He has his own Wikipedia page; he must be famous!)

There’s some great stuff in there, including the origin of the BSD daemon (Pixar, would you believe? Or, well, Lucasarts at the time…), and a great story about how a bug was introduced into the 4.2 BSD version of the pervasive UNIX diff utility. Marshall’s full of energy, and it’s a great interview; it’s a little amusing to see the stark contrast between the interviewer and McKusick, both of whom have rather different definitions of what constitutes an operating system.

A website named Neat Little Mac Apps is not the kind of place you’d expect to find an interview with a operating systems and filesystems hacker. Nevertheless, one of their podcasts was just that: an interview with UNIX and BSD legend Marshall Kirk McKusick. (He has his own Wikipedia page; he must be famous!)

There’s some great stuff in there, including the origin of the BSD daemon (Pixar, would you believe? Or, well, Lucasarts at the time…), and a great story about how a bug was introduced into the 4.2 BSD version of the pervasive UNIX diff utility. Marshall’s full of energy, and it’s a great interview; it’s a little amusing to see the stark contrast between the interviewer and McKusick, both of whom have rather different definitions of what constitutes an operating system.

Charles Petzold, one of the most famous authors of Windows programming books out there, wrote a great entry on his blog over a year ago that I’ve been meaning to comment on:

Once you’ve restricted yourself to information that turns up in Google searches, you begin having a very distorted view of the world.

On the Internet, everything is in tiny pieces. The typical online article or blog entry is 500, 1000, maybe 1500 words long. Sometimes somebody will write an extended “tutorial” on a topic, possibly 3,000 words in length, maybe even 5,000.

It’s easy to convince oneself that these bite-sized chunks of prose represent the optimum level of information granularity. It is part of the utopian vision of the web that this plethora of loosely-linked pages synergistically becomes all the information we need.

This illusion is affecting the way we learn, and I fear that we’re not getting the broader, more comprehensive overview that only a book can provide. A good author will encounter an unwieldy jungle of information and cut a coherent path through it, primarily by imposing a kind of narrative over the material. This is certainly true of works of history, biography, science, mathematics, philosophy, and so forth, and it is true of programming tutorials as well.

Sometimes you see somebody attempting to construct a tutorial narrative by providing a series a successive links to different web pages, but it never really works well because it lacks an author who has spent many months (or a year or more) primarily structuring the material into a narrative form.

For example, suppose you wanted to learn about the American Civil War. You certainly have plenty of online access to Wikipedia articles, blog entries, even scholarly articles. But I suggest that assembling all the pieces into a coherent whole is something best handled by a trained professional, and that’s why reading a book such as James McPherson’s Battle Cry of Freedom will give you a much better grasp of the American Civil War than hundreds of disparate articles.

If I sound elitist, it’s only because the time and difficulty required for wrapping a complex topic into a coherent narrative is often underestimated by those who have never done it. A book is not 150 successive blog entries, just like a novel isn’t 150 character sketches, descriptions, and scraps of dialog.

A related point I’d like to make is that people tend to read things that reinforce their viewpoints, and avoid things that go against their beliefs. If you’re a left-wing commie pinko in Sydney, you’re probably more likely to read the Sydney Morning Herald as your newspaper; if you’re a right-wing peacenik, you’ll probably prefer The Australian instead. If you’re a functional programming maven who sneers at C, you probably hang around Haskell or O’Caml or Erlang or Scheme geeks. If you’re a Mac programmer, you talk all day about how beautiful and glorious the Cocoa frameworks are, and probably have a firm hatred of C++ (even though there’s a decent chance you’ve never even used the language).

Hang around with other cultures sometimes. Like travelling, it’s good for you; it broadens your perspective, and gives you a better understanding of your own culture. The human nature of seeking confirmation of your own viewpoints, combined with Petzold’s astute observations about learning in bite-sized chunks, means that it’s incredibly easy to find information on the Internet that only explains one side of the story. How many people on your frequented mailing lists, IRC channels, Web forums or Twitter friends have similar opinions to you, and how many people in those communities truly understand other systems and have been shot down whenever they’ve tried to justify something valid that’s contrary to the community’s popular opinion? I’m not saying that hanging around like-minded communities is a bad idea; I’m simply saying to be aware of groupthink and self-reinforcing systems, and break out of your comfort zone sometimes to learn something totally different and contrary to what you’re used to. Make the effort to find out the whole picture; don’t settle for some random snippets of short tidbits that you read somewhere on the Web. Probably the best article I’ve ever read on advocacy is Mark-Jason Dominus’s Why I Hate Advocacy piece, written eight years ago in 2000. It still holds true today.

Charles Petzold, one of the most famous authors of Windows programming books out there, wrote a great entry on his blog over a year ago that I’ve been meaning to comment on:

Once you’ve restricted yourself to information that turns up in Google searches, you begin having a very distorted view of the world.

On the Internet, everything is in tiny pieces. The typical online article or blog entry is 500, 1000, maybe 1500 words long. Sometimes somebody will write an extended “tutorial” on a topic, possibly 3,000 words in length, maybe even 5,000.

It’s easy to convince oneself that these bite-sized chunks of prose represent the optimum level of information granularity. It is part of the utopian vision of the web that this plethora of loosely-linked pages synergistically becomes all the information we need.

This illusion is affecting the way we learn, and I fear that we’re not getting the broader, more comprehensive overview that only a book can provide. A good author will encounter an unwieldy jungle of information and cut a coherent path through it, primarily by imposing a kind of narrative over the material. This is certainly true of works of history, biography, science, mathematics, philosophy, and so forth, and it is true of programming tutorials as well.

Sometimes you see somebody attempting to construct a tutorial narrative by providing a series a successive links to different web pages, but it never really works well because it lacks an author who has spent many months (or a year or more) primarily structuring the material into a narrative form.

For example, suppose you wanted to learn about the American Civil War. You certainly have plenty of online access to Wikipedia articles, blog entries, even scholarly articles. But I suggest that assembling all the pieces into a coherent whole is something best handled by a trained professional, and that’s why reading a book such as James McPherson’s Battle Cry of Freedom will give you a much better grasp of the American Civil War than hundreds of disparate articles.

If I sound elitist, it’s only because the time and difficulty required for wrapping a complex topic into a coherent narrative is often underestimated by those who have never done it. A book is not 150 successive blog entries, just like a novel isn’t 150 character sketches, descriptions, and scraps of dialog.

A related point I’d like to make is that people tend to read things that reinforce their viewpoints, and avoid things that go against their beliefs. If you’re a left-wing commie pinko in Sydney, you’re probably more likely to read the Sydney Morning Herald as your newspaper; if you’re a right-wing peacenik, you’ll probably prefer The Australian instead. If you’re a functional programming maven who sneers at C, you probably hang around Haskell or O’Caml or Erlang or Scheme geeks. If you’re a Mac programmer, you talk all day about how beautiful and glorious the Cocoa frameworks are, and probably have a firm hatred of C++ (even though there’s a decent chance you’ve never even used the language).

Hang around with other cultures sometimes. Like travelling, it’s good for you; it broadens your perspective, and gives you a better understanding of your own culture. The human nature of seeking confirmation of your own viewpoints, combined with Petzold’s astute observations about learning in bite-sized chunks, means that it’s incredibly easy to find information on the Internet that only explains one side of the story. How many people on your frequented mailing lists, IRC channels, Web forums or Twitter friends have similar opinions to you, and how many people in those communities truly understand other systems and have been shot down whenever they’ve tried to justify something valid that’s contrary to the community’s popular opinion? I’m not saying that hanging around like-minded communities is a bad idea; I’m simply saying to be aware of groupthink and self-reinforcing systems, and break out of your comfort zone sometimes to learn something totally different and contrary to what you’re used to. Make the effort to find out the whole picture; don’t settle for some random snippets of short tidbits that you read somewhere on the Web. Probably the best article I’ve ever read on advocacy is Mark-Jason Dominus’s Why I Hate Advocacy piece, written eight years ago in 2000. It still holds true today.

I’ve written before about git-svn and why I use it, but a major stumbling block with git-svn has been been a lack of support for svn:externals. If your project’s small and you have full control over the repository, you may be fortunate enough to not have any svn:externals definitions, or perhaps you can restructure your repository so you don’t need them anymore and live in git and Subversion interoperability bliss.

However, many projects absolutely require svn:externals, and once you start having common libraries and frameworks that are shared amongst multiple projects, it becomes very difficult to avoid svn:externals. What to do for the git-svn user?

If you Google around, it’s easy enough to find solutions out there, such as git-me-up, step-by-step tutorials, explanations about using git submodules, and an overview of all the different ways you can integrate the two things nicely. However, I didn’t like any of those solutions: either they required too much effort, were too fragile and could break easily if you did something wrong with your git configuration, or were simply too complex for such a seemingly simple problem. (Ah, I do like dismissing entire classes of solutions by wand-having them as over-engineering.)

So, in the great spirit of scratching your own itch, here’s my own damn solution:

git-svn-clone-externals

This is a very simple shell script to make git-svn clone your svn:externals definitions. Place the script in a directory where you have one or more svn:externals definitions, run it, and it will:

• git svn clone each external into a .git_externals/ directory.
• symlink the cloned repository in .git_externals/ to the proper directory name.
• add the symlink and .git_externals/ to the .git/info/excludes/ file, so that you’re not pestered about it when performing a git status.

That’s pretty much about it. Low-tech and cheap and cheery, but I couldn’t find anything else like it after extensive Googling, so hopefully some other people out there with low-tech minds like mine will find this useful.

You could certainly make the script a lot more complex and do things such as share svn:externals repositories between different git repositories, traverse through the entire git repository to detect svn:externals definitions instead of having to place the script in the correct directory, etc… but this works, it’s simple, and it does just the one thing, unlike a lot of other git/svn integration scripts that I’ve found. I absolutely do welcome those features, but I figured I’d push this out since it works for me and is probably useful for others.

The source is on github.com at http://github.com/andrep/git-svn-clone-externals/tree/master. Have fun subverting your Subversion overlords!

I’ve written before about git-svn and why I use it, but a major stumbling block with git-svn has been been a lack of support for svn:externals. If your project’s small and you have full control over the repository, you may be fortunate enough to not have any svn:externals definitions, or perhaps you can restructure your repository so you don’t need them anymore and live in git and Subversion interoperability bliss.

However, many projects absolutely require svn:externals, and once you start having common libraries and frameworks that are shared amongst multiple projects, it becomes very difficult to avoid svn:externals. What to do for the git-svn user?

If you Google around, it’s easy enough to find solutions out there, such as git-me-up, step-by-step tutorials, explanations about using git submodules, and an overview of all the different ways you can integrate the two things nicely. However, I didn’t like any of those solutions: either they required too much effort, were too fragile and could break easily if you did something wrong with your git configuration, or were simply too complex for such a seemingly simple problem. (Ah, I do like dismissing entire classes of solutions by wand-having them as over-engineering.)

So, in the great spirit of scratching your own itch, here’s my own damn solution:

git-svn-clone-externals

This is a very simple shell script to make git-svn clone your svn:externals definitions. Place the script in a directory where you have one or more svn:externals definitions, run it, and it will:

• git svn clone each external into a .git_externals/ directory.
• symlink the cloned repository in .git_externals/ to the proper directory name.
• add the symlink and .git_externals/ to the .git/info/excludes/ file, so that you’re not pestered about it when performing a git status.

That’s pretty much about it. Low-tech and cheap and cheery, but I couldn’t find anything else like it after extensive Googling, so hopefully some other people out there with low-tech minds like mine will find this useful.

You could certainly make the script a lot more complex and do things such as share svn:externals repositories between different git repositories, traverse through the entire git repository to detect svn:externals definitions instead of having to place the script in the correct directory, etc… but this works, it’s simple, and it does just the one thing, unlike a lot of other git/svn integration scripts that I’ve found. I absolutely do welcome those features, but I figured I’d push this out since it works for me and is probably useful for others.

The source is on github.com at http://github.com/andrep/git-svn-clone-externals/tree/master. Have fun subverting your Subversion overlords!

I have the small honour of being a speaker at the maiden conference of MacDev 2009, a grass-roots, independently run, Mac developer conference in the UK that’s being held in April next year. MacDev looks like it’ll be the European equivalent of C4, which was absolutely the best Mac developer conference I’ve ever been to; I’d say it’s the Mac equivalent of Linux.conf.au. If you’re a Mac developer at all, come along, it should be great fun, and give your liver a nice workout. Plus, how can you ignore such a sexy list of speakers?

Update: My talk abstract is now available…

One reason for Mac OS X’s success is Objective-C, combining the dynamism of a scripting language with the performance of a compiled language. However, how does Objective-C work its magic and what principles is it based upon? In this session, we explore the inner workings of the Objective-C runtime, and see how a little knowledge about programming language foundations—such as lambda calculus and type theory—can go a long way to tackling difficult topics in Cocoa such as error handling and concurrency. We’ll cover a broad range of areas such as garbage collection, blocks, and data structure design, with a focus on practical tips and techniques that can immediately improve your own code’s quality and maintainability.

I am a great believer in getting the foundations right. Similarly to how bad code design or architecture often leads to a ton of bugs that simply wouldn’t exist in well-designed code, building a complex system on unsteady foundations can produce a lot of unnecessary pain. What are the foundations of your favourite programming language?

It’s 2008 and we’re still seeing buffer overflows in C.

I have the small honour of being a speaker at the maiden conference of MacDev 2009, a grass-roots, independently run, Mac developer conference in the UK that’s being held in April next year. MacDev looks like it’ll be the European equivalent of C4, which was absolutely the best Mac developer conference I’ve ever been to; I’d say it’s the Mac equivalent of Linux.conf.au. If you’re a Mac developer at all, come along, it should be great fun, and give your liver a nice workout. Plus, how can you ignore such a sexy list of speakers?

Update: My talk abstract is now available…

One reason for Mac OS X’s success is Objective-C, combining the dynamism of a scripting language with the performance of a compiled language. However, how does Objective-C work its magic and what principles is it based upon? In this session, we explore the inner workings of the Objective-C runtime, and see how a little knowledge about programming language foundations—such as lambda calculus and type theory—can go a long way to tackling difficult topics in Cocoa such as error handling and concurrency. We’ll cover a broad range of areas such as garbage collection, blocks, and data structure design, with a focus on practical tips and techniques that can immediately improve your own code’s quality and maintainability.

I am a great believer in getting the foundations right. Similarly to how bad code design or architecture often leads to a ton of bugs that simply wouldn’t exist in well-designed code, building a complex system on unsteady foundations can produce a lot of unnecessary pain. What are the foundations of your favourite programming language?

It’s 2008 and we’re still seeing buffer overflows in C.

After one of the longest road-trips of my life, I gave a presentation at DevWorld 08 in Melbourne, Australia, titled “The Business of Development”:

Coding is just one part of what makes a great product, but there’s always so much else to do and learn. So, what can you do to help ship a great product—besides coding—if you’re primarily a developer? In this talk, learn about important commercial and business issues that you, as a coder, can help to define and shape in your company, such as licensing and registration keys, adopting new technologies, software updates, handling support, your website, and crash reports.

The talk has a definite Mac focus and is geared towards people who are writing commercial software, but it arguably applies to all software on any platform, whether you’re a professional programmer or a hobbyist, working on open-source or not. The slides are now online; you can find it on my talks page or download them directly (40MB PDF).

After one of the longest road-trips of my life, I gave a presentation at DevWorld 08 in Melbourne, Australia, titled “The Business of Development”:

Coding is just one part of what makes a great product, but there’s always so much else to do and learn. So, what can you do to help ship a great product—besides coding—if you’re primarily a developer? In this talk, learn about important commercial and business issues that you, as a coder, can help to define and shape in your company, such as licensing and registration keys, adopting new technologies, software updates, handling support, your website, and crash reports.

The talk has a definite Mac focus and is geared towards people who are writing commercial software, but it arguably applies to all software on any platform, whether you’re a professional programmer or a hobbyist, working on open-source or not. The slides are now online; you can find it on my talks page or download them directly (40MB PDF).

R. A. Salvatore, Road of the Patriarch, p. 280:

The point of self-reflection is, foremost, to clarify and to find honesty. Self-reflection is the way to throw self-lies out and face the truth—however painful it might be to admit that you were wrong. We seek consistency in ourselves, and so when we are faced with inconsistency, we struggle to deny.

Denial has no place in self-reflection, and so it is incumbent upon a person to admit his errors, to embrace them and to move along in a more positive direction.

We can fool ourselves for all sorts of reasons. Mostly for the sake of our ego, of course, but sometimes, I now understand, because we are afraid.

For sometimes we are afraid to hope, because hope breeds expectation, and expectation can lead to disappointment.

… Reality is a curious thing. Truth is not as solid and universal as any of us would like it to be; selfishness guides perception, and perception invites justification. The physical image in the mirror, if not pleasing, can be altered by the mere brush of fingers through hair.

And so it is true that we can manipulate our own reality. We can persuade, even deceive. We can make others view us in dishonest ways. We can hide selfishness with charity, make a craving for acceptance into magnanimity, and amplify our smile to coerce a hesitant lover.

… a more difficult alteration than the physical is the image that appears in the glass of introspection, the pureness or rot of the heart and the soul.

For many, sadly, this is not an issue, for the illusion of their lives becomes self-delusion, a masquerade that revels in the applause and sees in a pittance to charity a stain remover for the soul.

… There are those who cannot see the stains on their souls. Some lack the capacity to look in the glass of introspection, perhaps, and others alter reality without and within.

It is, then, the outward misery of Artemis Entreri that has long offered me hope. He doesn’t lack passion; he hides from it. He becomes an instrument, a weapon, because otherwise he must be human. He knows the glass all too well, I see clearly now, and he cannot talk himself around the obvious stain. His justifications for his actions ring hollow—to him most of all.

Only there, in that place, is the road of redemption, for any of us. Only in facing honestly that image in the glass can we change the reality of who we are. Only in seeing the scars and the stains and the rot can we begin to heal.

For Rebecca, who holds that glass of introspection higher than anyone else I’ve ever known. Thank you for everything.

R. A. Salvatore, Road of the Patriarch, p. 280:

The point of self-reflection is, foremost, to clarify and to find honesty. Self-reflection is the way to throw self-lies out and face the truth—however painful it might be to admit that you were wrong. We seek consistency in ourselves, and so when we are faced with inconsistency, we struggle to deny.

Denial has no place in self-reflection, and so it is incumbent upon a person to admit his errors, to embrace them and to move along in a more positive direction.

We can fool ourselves for all sorts of reasons. Mostly for the sake of our ego, of course, but sometimes, I now understand, because we are afraid.

For sometimes we are afraid to hope, because hope breeds expectation, and expectation can lead to disappointment.

… Reality is a curious thing. Truth is not as solid and universal as any of us would like it to be; selfishness guides perception, and perception invites justification. The physical image in the mirror, if not pleasing, can be altered by the mere brush of fingers through hair.

And so it is true that we can manipulate our own reality. We can persuade, even deceive. We can make others view us in dishonest ways. We can hide selfishness with charity, make a craving for acceptance into magnanimity, and amplify our smile to coerce a hesitant lover.

… a more difficult alteration than the physical is the image that appears in the glass of introspection, the pureness or rot of the heart and the soul.

For many, sadly, this is not an issue, for the illusion of their lives becomes self-delusion, a masquerade that revels in the applause and sees in a pittance to charity a stain remover for the soul.

… There are those who cannot see the stains on their souls. Some lack the capacity to look in the glass of introspection, perhaps, and others alter reality without and within.

It is, then, the outward misery of Artemis Entreri that has long offered me hope. He doesn’t lack passion; he hides from it. He becomes an instrument, a weapon, because otherwise he must be human. He knows the glass all too well, I see clearly now, and he cannot talk himself around the obvious stain. His justifications for his actions ring hollow—to him most of all.

Only there, in that place, is the road of redemption, for any of us. Only in facing honestly that image in the glass can we change the reality of who we are. Only in seeing the scars and the stains and the rot can we begin to heal.

For Rebecca, who holds that glass of introspection higher than anyone else I’ve ever known. Thank you for everything.

We use Subversion for our revision control system, and it’s great. It’s certainly not the most advanced thing out there, but it has perhaps the best client support on every platform out there, and when you need to work with non-coders on Windows, Linux and Mac OS X, there’s a lot of better things to do than explain how to use the command-line to people who’ve never heard of it before.

However, I also really need to work offline. My usual modus operandi is working at a café without Internet access (thanks for still being in the stone-age when it comes to data access, Australia), which pretty rules out using Subversion, because I can’t do commits when I do the majority of my work. So, I used svk for quite a long time, and everything was good.

Then, about a month ago, I got annoyed with svk screwing up relatively simple pushes and pulls for the last time. svk seems to work fine if you only track one branch and all you ever do is use its capabilities to commit offline, but the moment you start doing anything vaguely complicated like merges, or track both the trunk and a branch or two, it’ll explode. Workmates generally don’t like it when they see 20 commits arrive the next morning that totally FUBAR your repository.

So, I started using git-svn instead. People who know me will understand that I have a hatred of crap user interfaces, and I have a special hatred of UIs that are different “just because”, which applies to git rather well. I absolutely refused to use tla for that reason—which thankfully never seems to be mentioned in distributed revision control circles anymore—and I stayed away from git for a long time because of its refusal to use conventional revision control terminology. git-svn in particular suffered more much from (ab)using different terminology than git, because you were intermixing Subversion jargon with git jargon. Sorry, you use checkout to revert a commit? And checkout also switches between branches? revert is like a merge? WTF? The five or ten tutorials that I found on the ‘net helped quite a lot, but since a lot of them told me to do things in different ways and I didn’t know what the subtle differences between the commands were, I went back to tolerating svk until it screwed up a commit for the very last time. I also tried really hard to use bzr-svn since I really like Bazaar (and the guys behind Bazaar), but it was clear that git-svn was stable and ready to use right now, whereas bzr-svn still had some very rough edges around it and isn’t quite ready for production yet.

However, now that I’ve got my head wrapped around git’s jargon, I’m very happy to say that it was well worth the time for my brain to learn it. Linus elevated himself from “bloody good” to “true genius” in my eyes for writing that thing in a week, and I now have a very happy workflow using git to integrate with svn.

So, just to pollute the Intertubes more, here’s my own git-svn cheatsheet. I don’t know if this is the most correct way to do things (is there any “correct” way to do things in git?), but it certainly works for me:

* initial repository import (svk sync):
git-svn init https://foo.com/svn -T trunk -b branches -t tags
git checkout -b work trunk

* pulling from upstream (svk pull):
git-svn rebase

* pulling from upstream when there's new branches/tags/etc added:
git-svn fetch

* switching between branches:
git checkout branchname

* svk/svn diff -c NNNN:
git diff NNNN^!

* commiting a change:
git add
git commit

* reverting a change:
git checkout path

* pushing changes upstream (svk push):
git-svn dcommit

* importing svn:ignore:
(echo; git-svn show-ignore) >> .git/info/exclude

* uncommit:
git reset <SHA1 to reset to>

Drop me an email if you have suggestions to improve those. About the only thing that I miss from svk was the great feature of being able to delete a filename from the commit message, which would unstage it from the commit. That was tremendously useful; it meant that you could git commit -a all your changes except one little file, which was simply deleting one line. It’s much easier than tediously trying to git add thirteen files in different directories just you can omit one file.

One tip for git: if your repository has top-level trunk/branches/tags directories, like this:

trunk/
  foo/
  bar/
branches/
  foo-experimental/
  bar-experimental/
tags/
  foo-1.0/
  bar-0.5/

That layout makes switching between the trunk and a branch of a project quite annoying, because while you can “switch” to (checkout) branches/foo-experimental/, git won’t let you checkout trunk/foo; it’ll only let you checkout trunk. This isn’t a big problem, but it does mean that your overall directory structure keeps changing because switching to trunk means that you have foo/ and bar/ directories, while switching to a foo-experimental or bar-experimental omits those directories. This ruins your git excludes and tends to cause general confusion with old files being left behind when switching branches.

Since many of us will only want to track one particular project in a Subversion repository rather than an entire tree (i.e. switch between trunk/foo and branches/foo-experimental), change your .git/config file from this:

[svn-remote "svn"]
    url = https://mysillyserver.com/svn
    fetch = trunk:refs/remotes/trunk
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*

to this:

[svn-remote "svn"]
    url = https://mysillyserver.com/svn
    fetch = trunk/foo:refs/remotes/trunk
     ; ^ change "trunk" to "trunk/foo" as the first part of the fetch
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*

Doing that will make git’s “trunk” branch track trunk/foo/ on your server rather than just trunk/, which is probably what you want. If you want to track other projects in the tree, it’s probably better to git-svn init another directory. Update: Oops, I forgot to thank Mark Rowe for help with this. Thanks Mark!

As an aside, while I believe that distributed version control systems look like a great future for open-source projects, it’s interesting that DVCS clients are now starting to support Subversion, which now forms some form of lowest common denominator. (I’d call it the FAT32 of revision control systems, but that’d be a bit unkind… worse-is-better, perhaps?) Apart from the more “official” clients such as command-line svn and TortoiseSVN, it’s also supported by svk, Git, Bazaar, Mercurial, and some great other GUI clients on Mac OS X and Windows. Perhaps Subversion will become a de-facto repository format that everyone else can push and pull between, since it has the widest range of client choice.