On Friday, my ’Net connection started bouncing up and down every minute or so. Obviously this isn’t supposed to happen, and this is the second time now that it has. Unfortunately, working from home, I rely on my ’Net connection working.

To their credit, Plus.net have always answered the phone promptly and have tried to help, as much as they can. I don’t actually think it’s their fault though. Most likely (particularly as it happened on a Friday last time too) it’s one of BT’s engineers doing something on a Friday at our local exchange.

Anyway, I’ve pretty much made up my mind that I need an office. Extra expense, obviously, but at least it means I’m not reliant on my home broadband connection.

(It has got a bit better, in that it’s now up and down every five minutes or so, rather than every minute, but even so it makes things rather awkward…)

Posted by alastair at 9:04 PM Digg It | Permalink | Comments (2) | TrackBacks (0)

It’s sometimes tempting when writing a cell class to override the -objectValue and -setObjectValue: methods of NSCell and let something other than the cell store the value (perhaps you could even generate the value from some other data).

But please don’t.

The problem is that NSCell doesn’t use the -objectValue accessor in some important cases¹, which means that if you override -objectValue, some of the cell’s methods will produce inconsistent results.

The right way to use NSCell is to always let NSCell store the data, which will avoid significant pain if someone is trying to do something fancy in a subclass of your cell.

Posted by alastair at 3:31 PM Digg It | Permalink | Comments (0) | TrackBacks (0)

Readers of Apple’s cocoa-dev mailing list will have seen a number of messages recently attacking the Objective-C feature of making messages to nil do nothing.

One of these posts (whose author shall remain nameless) made the claim that

…it’s disappointing that people still think that it’s quicker to just send the message to nil, than to do “if (target) [target message];” since it doesn’t matter how fast you make that message dispatcher, it can’t possibly be faster than the two instructions that the conditional takes…

These kinds of arguments are a very seductive trap for the unwary programmer; they seem “obvious”, right? Nevertheless, as I’ll show, they aren’t always as clear cut as they first seem.

If you are considering optimizations to your program (and you should), you absolutely must measure to see where you should spend your time. Indeed, if you write programs for Mac OS X, you are spoilt for choice in terms of the tools available to help you do this. (I’m a particular fan of Apple’s Shark tool… it’s a large part of the reason that iDefrag’s main display is so fast.)

Continue reading “Optimization without measurement - a seductive trap” $raquo;

Posted by alastair at 10:48 AM Digg It | Permalink | Comments (3) | TrackBacks (0)

My friend and colleague Chris Suter (who you may know from his regular posts on the cocoa-dev and xcode-users developer mailing lists) thinks I should mention our products more on my blog.

He’s probably right; after all, iPartition and iDefrag are pretty useful programs, and both of them have a number of unique features not found in anything similar on any platform. Mind you, just wait until you see iPartition 2.0 when we release it :-)

I promise, by the way, that this blog isn’t going to turn into a stream of advertising for our software. That’s just not interesting. But perhaps I’ll talk more about new features when we add them.

Posted by alastair at 11:59 AM Digg It | Permalink | Comments (0) | TrackBacks (0)