[Direct Link]

Because everything needs an FAQ:

What will you be working on?

I’m not sure that I can say, just yet. But it will involve heavy amounts of coding in Objective-C.

So you’re moving to California?

Nope. I’ll be staying right here in Chicago.

Will you still be writing The Road to Code for MacTech Magazine?

Unfortunately, I will be unable to continue writing The Road to Code for MacTech, and I’ve already submitted my last article. It has been an amazing three years, and I am truly grateful to have worked with MacTech.

What about public speaking?

I will also be unavailable for future speaking engagements. I’ve already had to turn down opportunities to speak at Voices that Matter, the MacTech conference, and SecondConf. I’m sure I will be an attendee at a number of the conferences, though, and I plan to stay active in the community as much as possible.

What does this mean for Bit Maki and Textcast?

This is still preliminary and in progress, but Bit Maki Software, Inc., the joint company between Jonathan Rentzsch and I, is in process of being dissolved. I plan to keep Bit Maki, Inc., my contracting company, alive for now, though I will not be doing any more contracting. Textcast will become free and be available from the Bit Maki website.

What’s the future of MAME OS X?

It has been a few years since I’ve been able to dedicate much time towards MAME OS X, and this is the nail in the coffin. I will not be able to contribute to MAME OS X. If anyone want’s to pick up the effort, please let me know. This also goes for most of my other open source software. Truth be told, with the two recent additions to our family, I’m going to be sufficiently distracted for a while, anyways.

Or, you could avoid floating point altogether. Thus, I wrote trigint, a 100% integer-based trigonometry library. It uses a 16-entry lookup table plus linear interpolation so it’s quite memory efficient, yet still accurate enough for most purposes. Since it’s written in ANSI C99, it can be used on 8-bit microcontrollers, like an Atmel AVR with avr-gcc. Here’s the code and the API documentation.

How fast is it? Take a look at the numbers on a 1st generation iPod Touch. In summary, trigint_sin16() is about 4.4 times faster than sinf() and 6.7 times faster than sin() in Thumb mode. Without Thumb mode, the gap closes a bit to 3.8 times faster and 6.2 times faster, respectively. I haven’t, yet run the benchmark on the iPhone 4 or the iPad, so it may not matter as much on the more modern hardware; however, it’s still useful for the the 8-bit MCUs like the AVR, though.

trigint is essentially a C version of the Scott Dattalo’s sine wave routine for the PIC microcontroller. Credit goes to Scott for coming up with the algorithm. He’s also got a whole write up of sine wave theory. Scott is one of the most brilliant assembly coders I’ve ever run into. He helped me optimize a CRC-16 routine in PIC assembly, years ago.

You can listen to and download the MP3 from its 8bitcollective page. Or download the NSF (what’s an NSF?) and play it in an NSF player, such as my own Chip Player. Or perhaps something a bit more stable like Audio Overload.

Structure Initialization

Structure initialization received a lot of love in C99. In C89, you could initialize a structure variable like this:

NSPoint point = {0, 0};

The caveat here is that the structure elements must be provided in the order that they are listed in the definition. In this case, NSPoint is declared as like:

typedef struct _NSPoint {
    CGFloat x;
    CGFloat y;
} NSPoint;

So, when we initialize a variable, x comes first, followed by y. This can be a drawback because if the order in the definition ever changed, all existing code that depended on the order would break. As of C99, you can initialize a structure by specifying the structure element names:

NSPoint point = { .x = 0, .y = 0};

This not only decouples the order of the definition from the order of the initialization, but it’s more readable. As an added benefit, any structure elements not initialized are set to zero. This means you only need to fill out the portions of the structure that are relevant. And if new elements to the structure are added in later versions, they get initialized to a known value.

The benefit of this becomes even more clear for nested structures like NSRect:

typedef struct _NSRect {
    NSPoint origin;
    NSSize size;
} NSRect;

To initialize an NSRect in straight C89 looked something like this:

NSRect rect = {{0, 0}, {640, 480}};

Because this is kind of awkward, there’s a function to make this a bit easier:

NSRect rect = NSMakeRect(0, 0, 640, 480);

But, honestly, that’s not much of an improvement in readability. NSMakeRect is more useful in structure assignment, but we’ll see an alternate way to do this below. With C99, we can initialize this variable like:

NSRect rect = {
    .origin.x = 0,
    .origin.y = 0,
    .size.width = 640,
    .size.height = 480,
};

Again, we can order the structure elements however we please; we’re not required to list them in the order of the definition. We have some flexibility in how we assign the nested structures, too. This is also legal:

NSRect rect = {
    .origin = {.x = 0, .y = 0},
    .size = {.width = 640, .height = 480},
};

As as this:

NSRect rect = {
    .origin = NSMakePoint(0, 0),
    .size = NSMakeSize(640, 480),
};

And even this:

NSRect rect = {
    .origin = otherRect.origin,
    .size = NSMakeSize(640, 480),
};

So, as you can see, we get a lot more flexibility on how to initialize structures.

Compound Literals for Structure Assignment

This new syntax of initializing structure variables is great, but it doesn’t help us much for assigning to existing structure variables. The example I used in my iPad Dev Camp talk was setting up a AudioStreamBasicDescription structure, colloquially known as ASBD. This structure is used to describe an audio format for Core Audio. In this case, I had an ASBD instance variable. Because it’s an instance variable, you cannot set its value using the initialization syntax above. Thus, the traditional way to initialize one of these it to clear out it to zero with memset, and then set the fields you need, one by one:

memset(&_dataFormat, 0, sizeof(_dataFormat));
_dataFormat.mFormatID = kAudioFormatLinearPCM;
_dataFormat.mSampleRate = SAMPLE_RATE;
_dataFormat.mBitsPerChannel = 16;
// And on and on...

Using new C99 syntax known as a compound literal, you can set an existing structure variable like this:

_dataFormat = (AudioStreamBasicDescription) {
    .mFormatID = kAudioFormatLinearPCM,
    .mSampleRate = SAMPLE_RATE,
    .mBitsPerChannel = 16,
    // And on and on...
};

It looks similar to a cast plus an initialization. And under the hood, the compiler is making a anonymous variable. So you can think of the above as equivalent to:

AudioStreamBasicDescription anon = {
    .mFormatID = kAudioFormatLinearPCM,
    .mSampleRate = SAMPLE_RATE,
    .mBitsPerChannel = 16,
    // And on and on...
};
_dataFormat = anon;

Again, the nice thing here as that unset fields are initialized to zero, so you get the equivalent of the memset. Plus, you don’t have to repeat the variable name over and over again.

Oh, and as a quick shorthand for setting the entire structure to zero, you can do something like this:

_dataFormat = (AudioStreamBasicDescription) {0};

Compound Literals with Primitives

Compound literals can be applied to primitive types, too. Most of the time this is not much use:

int i = (int) {3};

But because these are anonymous variables, you can take the address of them:

int * iPointer = &(int) {3};

This can be useful for some Core Audio APIs, such as AudioUnitSetProperty. Typically you create a variable for the sole purpose of taking the address of it:

UInt32 maxFramesPerSlice = 4096;
AudioUnitSetProperty(converterAudioUnit,
                     kAudioUnitProperty_MaximumFramesPerSlice,
                     kAudioUnitScope_Global,
                     0,
                     &maxFramesPerSlice,
                     sizeof(UInt32));

Using compound literals, we can do this inline without an extra variable:

AudioUnitSetProperty(converterAudioUnit,
                     kAudioUnitProperty_MaximumFramesPerSlice,
                     kAudioUnitScope_Global,
                     0,
                     &(UInt32) {4096},
                     sizeof(UInt32));

Conclusion

While C99 was a relatively minor update to C89, there are quite a few gems buried away to make our code more flexible and readable, as you can see.

• Audio Queue Services
• Audio Unit Graphs

The source code to the two projects I went over are up on BitBucket:

• A440: A Core Audio “Hello World”. Runs on Mac, iPhone, and iPad.
• Chip Player: A chiptune player using the Game Music Emu library. Runs on Mac and iPad and plays popular chiptune file formats, such as NSF and GBS.

Use the ipaddevcamp2010 tag to see what they looked like at the time of the presentations.

I’ve posted the code up on BitBucket if you want to check it out before hand or are unable to attend. I also hope to have a more complex and complete audio playing application ready to release by this weekend, too. Hint, it’ll have something to do with 8-bit chiptunes. So if you’re in Chicago, sign up! It’ll be fun!

After some good suggestions on Twitter, and a bit of casual recreational coding, I’ve come up with a general purpose solution that involves, of course, method swizzling.

Take this code in an application delegate as an example:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [self performSelectorOnMainThread:@selector(echo:) withObject:@"foo" waitUntilDone:NO];
    });

    [self performSelector:@selector(echo:) withObject:@"bar" afterDelay:3.0];
}

- (void)echo:(id)object
{
    NSLog(@"echo: %@", object);
}

If you set a breakpoint in the echo: method, you’ll see a backtrace like:

(gdb) bt
#0  -[PerformDebugAppDelegate echo:] (self=0x10012c480, _cmd=0x100002462, object=0x1000030e8) at /Users/dave/Desktop/PerformDebug/PerformDebugAppDelegate.m:42
#1  0x00007fff83500647 in __NSThreadPerformPerform ()
#2  0x00007fff80477271 in __CFRunLoopDoSources0 ()
#3  0x00007fff80475469 in __CFRunLoopRun ()
#4  0x00007fff80474c2f in CFRunLoopRunSpecific ()
#5  0x00007fff8101ea4e in RunCurrentEventLoopInMode ()
#6  0x00007fff8101e7b1 in ReceiveNextEventCommon ()
#7  0x00007fff8101e70c in BlockUntilNextEventMatchingListInMode ()
#8  0x00007fff870b21f2 in _DPSNextEvent ()
#9  0x00007fff870b1b41 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#10 0x00007fff87077747 in -[NSApplication run] ()
#11 0x00007fff87070468 in NSApplicationMain ()
#12 0x0000000100001a09 in main (argc=1, argv=0x7fff5fbff1f0) at /Users/dave/Desktop/PerformDebug/main.m:29

This really isn’t all that helpful. Yes, echo: was called, but we don’t know who called it. If echo: is a method that tends to get called from a number of places with a performSelector... variant, we don’t know which one it is.

This afternoon, I took the easy way out, and set an auto-continuing breakpoint on -[NSObject performSelector:onThread:withObject:waitUntilDone:modes:] with a bt action. This isn’t ideal, though. First, this method gets called quite a bit, so hitting the breakpoint can slow things down a lot. Plus, it dumps the stack trace for each call, cluttering the gdb console with mostly useless garbage.

The breakpoint actually helped me debug the issue today, but I’ve run into this situation a number of times in the past and never had a good way to debug it. Until now.

Swizzling for Fun and Profit

The key is to swizzle the NSObject implementations of these two methods:

• performSelector:withObject:afterDelay:inModes:
• performSelector:onThread:withObject:waitUntilDone:modes:

In our swizzled implementations, we’d like to capture the backtrace at time they are called. Later, we can dump out the backtrace for debugging, if we want to. To do this, we’ll create an intermediate object to hold the backtrace: DDPerformDebugger. Here are its two most important methods:

- (id)initWithTarget:(id)target selector:(SEL)selector argument:(id)argument;
{
    self = [super init];
    if (self == nil)
        return nil;

    _target = [target retain];
    _selector = selector;
    _argument = [argument retain];
    // Capture a backtrace at the time we're created
    _frames = backtrace(_callstack, sizeof(_callstack)/sizeof(*_callstack));

    return self;
}

- (void)perform;
{
    [_target performSelector:_selector withObject:_argument];
}

In the initializer, we capture the target, selector, and argument. But we also capture a backtrace using the very handy backtrace(3) function.

In our swizzled performSelector..., we create an instance of DDPerformDebugger, but instead of passing the target and selector to the original implementation, we use this instance as the target and perform as the selector. As you can see above, this just forwards it on to the passed in target and selector. However, as I demonstrate below, we’ll have access to the saved backtrace. Here’s what the swizzled method looks like:

- (void)dd_performSelector:(SEL)selector withObject:(id)argument afterDelay:(NSTimeInterval)delay inModes:(NSArray *)modes;
{
    DDPerformDebugger * debugger = [[DDPerformDebugger alloc] initWithTarget:self
                                                                    selector:selector
                                                                    argument:argument];
    [debugger autorelease];

    // This calls the original implementation.  It's not recursing.
    [debugger dd_performSelector:@selector(perform)
                      withObject:nil
                      afterDelay:delay
                         inModes:modes];
}

The swizzled dd_performSelectorOnMainThread:... looks similar. Now, when we stop on our breakpoint in echo:, we get the following backtrace:

(gdb) bt 5
#0  -[PerformDebugAppDelegate echo:] (self=0x10012b170, _cmd=0x100002462, object=0x1000030e8) at /Users/dave/Desktop/PerformDebug/PerformDebugAppDelegate.m:42
#1  0x000000010000207c in -[DDPerformDebugger perform] (self=0x10101ae00, _cmd=0x7fff85a42a1a) at /Users/dave/Desktop/PerformDebug/DDPerformDebugger.m:157
#2  0x00007fff83500647 in __NSThreadPerformPerform ()
#3  0x00007fff80477271 in __CFRunLoopDoSources0 ()
#4  0x00007fff80475469 in __CFRunLoopRun ()
(More stack frames follow...)

This isn’t much help on it’s own. But if we jump to frame 1, where we’re inside the perform method of our intermediate object, we have access to the backtrace of the original calling point. I’ve rigged up the description method to show the backtrace, so it’s easy to get:

(gdb) po self
<DDPerformDebugger 0x10101ae00: target: <PerformDebugAppDelegate 0x10012b170>, selector: <echo:>, argument: <NSCFString 0x1000030e8>
0   PerformDebug                        0x0000000100001f45 -[DDPerformDebugger initWithTarget:selector:argument:] + 268
1   PerformDebug                        0x0000000100001d3c -[NSObject(DDPerformDebugger) dd_performSelector:onThread:withObject:waitUntilDone:modes:] + 99
2   Foundation                          0x00007fff83512d54 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 143
3   PerformDebug                        0x0000000100001b42 __-[PerformDebugAppDelegate applicationDidFinishLaunching:]_block_invoke_1 + 66
4   libSystem.B.dylib                   0x00007fff86eebce8 _dispatch_call_block_and_release + 15
5   libSystem.B.dylib                   0x00007fff86eca279 _dispatch_worker_thread2 + 231
6   libSystem.B.dylib                   0x00007fff86ec9bb8 _pthread_wqthread + 353
7   libSystem.B.dylib                   0x00007fff86ec9a55 start_wqthread + 13

We can see we’re on on a GCD thread inside applicationDidFinishLaunching:. The only downside to the backtrace_symbols(3) function is that it does not utilize debugging information to show line numbers. We just get an offset into the method.

Fortunately, a command line tool called atos(1) can provide us with this information. Given an address, it’ll decode the symbol and line number information. We can even invoke this right from inside gdb:

(gdb) info pid
Inferior has process ID 11017.
(gdb) shell atos -p 11017 0x0000000100001b42
__-[PerformDebugAppDelegate applicationDidFinishLaunching:]_block_invoke_1 (in PerformDebug) (PerformDebugAppDelegate.m:35)

And know we know that performSelectorOnMainThread: was originally called from line 35 of PerformDebugAppDelegate.m. Very helpul!

The full code for DDPerformDebugger is part of my DDFoundation project on BitBucket, but you can grab just the one file on its own and and included it with your project. By default, it does not swizzle anything, so you can compile it in for every build and not worry about taking a performance hit creating those intermediate objects. To enable the swizzling, just set the DDPerformDebug environment variable to YES. Grab a sample project, PerformDebug.tgz, and try it out for yourself.

What I Miss

Before settling in on Objective-C, I was a Java guy for about six years or so. Overall, I much, much prefer coding in Objective-C to Java, and have no intentions of going back to Java. But that doesn’t mean there’s some things I miss. Here’s a quick list, with more detail below:

• A flexible I/O class hierarchy
• Everything in java.util.concurrent
• Exceptions for errors
• Packages, a.k.a namespaces
• One file for interface/implementation
• Type safe enum classes
• Annotations
• Awesome IDEs (IntelliJ)

A Flexible I/O Class Hierarchy

Overall, I feel the java.io package is really well designed. I like the difference between InputStream/OutputStream that are byte-oriented and Reader/Writer that are text-oriented. Also, there’s some cool subclasses such as GZIPInputStream, GZIPOutputStream, and LineNumberReader

Java’s InputStream and OutputStream are easier to subclass than NSInputStream and NSOutputStream since there’s fewer methods to deal with. Plus, there’s a lingering bug in NSInputStream that makes it effectively impossible to subclass in some really handy situations. See this mailing list post from 2007 that mentions rdar://problem/322278.

Everything in java.util.concurrent

Ever since I read Java Concurrency in Practice, I’ve been drooling over a lot of stuff Java programmers have available in their arsenal in java.util.concurrent. The Executor is roughly equivalent to a Grand Central Dispatch queue and theExecutorService is roughly equivalent to an NSOperationQueue, but that’s where the similarities end. Granted, I think the Cocoa and GCD APIs are more palatable, especially since the introduction of blocks, but there’s a bunch of classes we don’t have that would have been really useful at some point or another:

• BlockingQueue and it’s implementations are handy for passing objects between threads. The need for this is partially mitigated by GCD, but it’d still be nice to have these to feed objects from one queue to another.
• ConcurrentHashMapis an awesome, thread safe and scalable map/dictionary.
• CopyOnWriteArrayList and CopyOnWriteArraySet are really nice for mostly read-only data.
• The atomic classes in java.util.concurrent.atomic are nicer than dealing with the OSAtomic functions.
• The Future interface has some very handy uses. Mike Ash just wrote a blog post on futures in Objective-C, but I think I prefer explicit futures to implicit futures.
• The SwingWorker class offers nice integration of asynchronous background tasks with the user interface thread. I’ve used a similar pattern in Objective-C, but I think it’d be nice to have this encapsulated in a reusable object.
• The java.util.concurrent.locks package has some nice specialty locks such as ReentrantReadWriteLock.

Exceptions for Errors

Objective-C may have exceptions, but they are only used for programming errors or essentially fatal runtime errors. Error handling is done with NSError. This is different than Java, which uses exceptions for expected error cases, such as error reading from a file, or failure to execute a database transaction. This isn’t just a Java thing. Most modern languages like Python, Ruby, and C# use exceptions as Java does. Not using exceptions as error handling was one of the harder habits for me to break; however, I’ve come to embrace NSError and eschew exceptions in Objective-C, even if I don’t like it.

I’ve debated this a number of times with people, but having dealt with both exceptions and NSError, I still prefer exceptions. The big argument against exceptions is that they are non-local jumps causing confusing behavior and subtle bugs. I guess I’ve never seen this happen. Plus there’s also the fact that Foundation and AppKit are not exception safe, so throwing exceptions through these frameworks can and will lead to memory leaks and probably unpredictable behavior. Thus, the best course of action to handle an exception is to gracefully terminate the app.

To me, NSError doesn’t result in more robust code than exceptions. 90% of the time, people just pass NULL or log the NSError in place instead of passing it up to where it’s better handled. A big reason for this is that NSError is returned as an output parameter. Thus to pass an NSError up to a higher level requires that an NSError be added to every method up the chain. Not only is this ungainly, but it’s sometimes not possible to add an NSError to an existing API. This is also a problem with checked exceptions Java, which is why most Java people endorse unchecked exceptions these days.

Exceptions really shine when you call multiple methods in a row that can fail. In Objective-C, your best bet is to return early or use a goto. This still litters your code with error handling that drowns out the real code. With exceptions, the error handling code is nicely separated from the “happy” code path. Perhaps exceptions aren’t the be-all end-all of error handling, as I’ve recently been intrigued by the error handling of Haskell. However, this is not something we’ll see in Objective-C any time soon.

Packages, a.k.a Namespaces

Classes in Objective-C live in a big, flat, global namespace. The common workaround is to prefix class names with two or three letters. Thus, I’d name my classes DDObject or some such. The problem with this approach is that two or three letters is just not enough of a namespace. It helps reduce collisions, but it does not eliminate them. Plus, Apple no longer uses only the NS prefix. It uses CA, CI, CV, QC, AB, UI, PS, IO, QL and probably more. A safe prefix today may be a collision tomorrow.

Things get even more dire when it comes to categories. Category smashing happens, and it’s hard to debug. The only way to avoid it is to prefix your category methods with some unique prefix, as well.

Packages or namespace could theoretically solve both of these collisions. This is not an unknown issue. Many radars have been filed, such as rdar://problem/7025435, that are all duped to a very low radar: rdar://problem/2821039. The problem is this isn’t an easy thing to bolt onto an existing language, because, of course, we want it done in a backwards compatible manner that doesn’t impact the performance of objc_msgSend(). So I understand why we don’t have it, but that doesn’t mean I don’t want it.

One File for Interface and Implementation

There are some good things about the separate of the interface in the .h file and the implementation in the .m file. However, I really despise having to keep these two up-to-date. Many accumulated hours have been lost to compile warnings and errors due to updating one without the other. The repeated method definitions are very un-DRY.

Others suggested that they like this separation of interface from implementation details, only exposing what’s necessary to users of the class, and conceptually I agree. In practice, I find it a chore. Perhaps the repeated code could be mitigated with some Xcode assistance. For example, add a method in the .m and it offers to add it to the .h for you. I think I could deal with this.

However, some of the private details are still exposed in the headers, namely the instance variables. The modern Objective-C runtime, available in 64-bit on Mac OS X and the native iPhone environments, allow synthesized ivars, meaning you can declare properties, and the ivars will automatically be created. But you can’t really use this until you drop 32-bit Mac OS X and/or the simulator supports the modern runtime.

And even so, I’m not sold on synthesized ivars, as it requires using properties where I previously used ivars. To me, a property is conceptually different than an ivar, even if it’s non-public. Properties can be overridden, can have side effects, are available via key-value coding, and also have more overhead. Most of the time, I don’t want these things, and prefer direct ivar access. I much prefer explicit ivars. Perhaps way to solve the exposed privates issue would be to declare them in the .m in say a class extension, instead of the .h. The runtime supports adding ivars at runtime, so this sounds technically possible.

Type Safe Enum Classes

Enums in Objective-C are inherited from C. Thus we get all the weaknesses of C enums for free. C enums are not much more than syntactic sugar for integer constants. There’s no way to get type safety, to introspect them, print them, loop over them, or do anything remotely fancy. The one benefit over a #define used to be that the debugger could decode the integer value into a readable name. But these days, all enums in Cocoa are anonymous, defined as such for 64-bit compatibility:

enum {
    // Pass in one of the "By" options:
    NSStringEnumerationByLines = 0,
    // ...
};
typedef NSUInteger NSStringEnumerationOptions;

Thus most types that are enums are actually typedef’d to NSUInteger. While this is necessary, it means we no longer get debugger integration with enum constants.

Annotations

Annotations in Java are bits of metadata that can be added to classes and methods. Some of this metadata is used at compile time, but it is also available at runtime. The runtime uses are intriguing, but one of the compile time annotations that I like is the @override annotation. This allows you to detect some subtle, yet easy-to-make mistakes when overriding methods in subclasses or a protocol:

• Accidentally overriding a superclass’ method.
• Misspelling a superclass’ method, thus not actually overriding it.
• Misspelling an optional protocol method, thus not actually implementing it.

I’ve requested similar functionality for Objective-C in rdar://problem/7215146.

Awesome IDEs (IntelliJ)

This one has really nothing to do with the language. Xcode has really improved over the years. And while it is generally a very good text editor with project management, I’m afraid it still doesn’t compare to IntelliJ. I don’t know how other Java IDEs stack up (I was never very impressed with Eclipse), but IntelliJ was the first IDE that sold me on the concept of IDEs (I used Emacs prior to it).

Honestly, this probably deserves a whole post in and of itself, but for starters, Xcode could really use intention actions, see rdar://problem/7215136, and much better unit testing integration. IntelliJ has a bunch of other small niceties that all add up to a more pleasant development experience. Unfortunately, it’s been years since I used IntelliJ, so I don’t remember all of the details. Some I can remember are: real-time syntax checking, automatic import statement management, and customizable code reformatting (yes, I need to file bugs on these, too).

All I do remember as that it was the first and only development environment that really took much of the grunt work out of editing code. It not only got out of my way, it actually made me more productive. I dropped the $500 on it out of my own pocket, and it easily paid for itself (in real consulting dollars) in a matter of weeks.

These are all code smells that something isn’t right. Remember, TDD is about tests driving development; however you must remember to listen to the tests when they are crying out in pain. I’m going to take Matt’s Mac and iPhone projects with unit tests and re-work them so that they are much more manageable and cleaner.

Duplicated Code

This first smell I want to address is in the duplicated code between the Mac and iPhone applications. Both apps have a CLLoationManager delegate that listens for updates and formats the location into HTML for the web view, strings labels for the buttons, and a Google Maps URL. The code between these two apps is identical and is a good example of a violation of the Don’t Repeat Yourself, or DRY, Principle.

So how do we remove this duplicated code? Part of what makes this difficult is that it is highly coupled to the UI. In the Mac app, this code lives in an NSWindowController subclass, and in the iPhone app it lives in a UIViewController subclass. Thus we can’t just share an existing class as-is between projects because you can’t use an NSWindowController in an iPhone app and you can’t use a UIViewController in a Mac app. The answer is to extract this code into a new class that can be used from both applications.

Because the primary function of this new class is to take core location updates and format them to various strings, I’m calling the class MyCoreLocationFormatter. There may be a better name, since using the word formatter may imply an NSFormatter subclass, but let’s stick with it for now.

The sticking point is that we somehow need this new class to update the UI, irrespective of Cocoa vs. Cocoa Touch. We need to break the direct dependency on Cocoa and Cocoa Touch, and I’ve chosen to use a delegate with a single method as a bit of dependency inversion:

@protocol MyCoreLocationFormatterDelegate <NSObject>

- (void)locationFormatter:(MyCoreLocationFormatter *)formatter
 didUpdateFormattedString:(NSString *)formattedString
            locationLabel:(NSString *)locationLabel
           accuractyLabel:(NSString *)accuracyLabel;

@end

Thus, when the location changes, it formats the new location into appropriate strings and sends this message to its delegate. Both WhereIsMyMacWindowController and WhereIsMyPhoneViewController implement this protocol, and when they receive the message, the update their UI accordingly.

There are other ways to achieve similar decoupling. We could use an NSNotification to send out the update with the strings in the user info dictionary. Or we could have properties for the three strings and allow interested parties to monitor their updates using key-value observing. On the Mac side, this enables you to use Cocoa bindings to wire up the UI. Or we could return a dictionary with the three strings. Or we could create a new value object and return that. Any of these alternatives are viable, however I think using a delegate makes the coupling a bit more explicit and easier to follow. What’s important is that the direct dependency to the UI layer is broken.

Here’s the full interface of MyCoreLocationFormatter:

@interface MyCoreLocationFormatter : NSObject <CLLocationManagerDelegate>
{
    id<MyCoreLocationFormatterDelegate> _delegate;
    NSString * _formatString;
}

@property (nonatomic, assign, readwrite) id<MyCoreLocationFormatterDelegate> delegate;
@property (nonatomic, copy, readonly) NSString * formatString;

- (id)initWithDelegate:(id<MyCoreLocationFormatterDelegate>)delegate
          formatString:(NSString *)htmlFormatString;

- (NSURL *)googleMapsUrlForLocation:(CLLocation *)currentLocation;

- (void)locationManager:(CLLocationManager *)manager
    didUpdateToLocation:(CLLocation *)newLocation
           fromLocation:(CLLocation *)oldLocation;

- (void)locationManager:(CLLocationManager *)manager
       didFailWithError:(NSError *)error;

@end

Ignoring the CLLocationManager delegate methods, there are only two methods. The format string is used as the HTML template that gets loaded from the application’s bundle. The -googleMapsUrlForLocation: method is used to open the location up in a browser.

To test this class, we use a mock object to ensure the delegate is being called properly. We use instance variables and our fixture methods to setup an instance of MyCoreLocationFormatter and the mock delegate:

- (void)setUp
{
    // Setup
    _mockDelegate = [OCMockObject mockForProtocol:@protocol(MyCoreLocationFormatterDelegate)];
    _formatter = [[MyCoreLocationFormatter alloc] initWithDelegate:_mockDelegate
                                                    formatString:@"ll=%f,%f spn=%f,%f"];
}

- (void)tearDown
{
    // Verify
    [_mockDelegate verify];

    // Teardown
    [_formatter release]; _formatter = nil;
}

With these fixtures in place, writing our tests are fairly straight forward:

- (void)testUpdateToNewLocationSendsUpdateToDelegate
{
    // Setup
    CLLocation * location = [self makeLocationWithLatitude:-37.80996889 longitude:144.96326388];
    [[_mockDelegate expect] locationFormatter:_formatter
                     didUpdateFormattedString:@"ll=-37.809969,144.963264 spn=-0.000018,-0.000014"
                                locationLabel:@"-37.809969, 144.963264"
                               accuractyLabel:[NSString stringWithFormat:@"%f", kCLLocationAccuracyBest]];

    // Execute
    [_formatter locationManager:nil didUpdateToLocation:location fromLocation:nil];
}

- (void)testUpdateToSameLocationDoesNotSendUpdateToDelegate
{
    // Setup
    CLLocation * location = [self makeLocationWithLatitude:-37.80996889 longitude:144.96326388];

    // Execute
    [_formatter locationManager:nil didUpdateToLocation:location fromLocation:location];
}

- (void)testFailedUpdateSendsUpdateToDelegate
{
    // Setup
    NSError * error = [self makeFakeErrorWithDescription:@"Some error description"];
    [[_mockDelegate expect] locationFormatter:_formatter
                     didUpdateFormattedString:@"Location manager failed with error: Some error description"
                                locationLabel:@""
                               accuractyLabel:@""];


    // Execute
    [_formatter locationManager:nil didFailWithError:error];
}

In order to keep the tests short and concise, I’ve moved the lengthy code to create a CLLocation and an NSError out of the tests and into helper methods. Remember, you’ve got to keep test code clean and maintainable, too. All three of these tests are only about 35 lines of code.

In contrast, Matt’s two original test methods were over 200 lines of code. The problem is that Matt’s code is testing the string formatting by asserting the web view’s HTML and text field’s strings. Separating the responsibility of formatting the strings from updating the UI not only improves the design, but makes testing much simpler.

So we’ve got on almost order of magnitude less code in our test methods that’s cleaner with the same code coverage. As a bonus, this class can be used in both the Mac and iPhone applications, so we can re-use the core logic. From an MVC perspective, the new MyCoreLocationFormatter class would be considered the model that is used with different views. Pushing logic out of the controller layer and into a model pays homage to the skinny controller, fat model design guideline.

Removing Testing Hacks

With this class complete, we can now move on to testing the WhereIsMyMacWindowController class. Matt’s test code uses a couple of hacks in order to enable testing that I consider code smells.

First, it uses runtime trickery, namely object_getInstanceVariable and object_setInstanceVariable, to gain access to the outlet instance variables. I think this is bad form and prefer to add public accessors for the outlets using properties:

@property (assign) IBOutlet WebView *webView;
@property (assign) IBOutlet NSTextField *locationLabel;
@property (assign) IBOutlet NSTextField *accuracyLabel;
@property (assign) IBOutlet NSButton *openInBrowserButton;

Using IBOutlet on a property means the NIB loading code will go through this public interface as well. Since these properties are already settable by the NIB loading code, I don’t see a big downside to making them public.

Second, the tests use category smashing to inject mock objects of CLLocationManager and NSWorkspace for testing. Again, I think this is bad form and prefer explicit dependency injection as a cleaner way to do this. I’m going to use constructor injection by adding these two initializers to WhereIsMyMacWindowController:

- (id)init;

// Designated Initializer
- (id)initWithLocationManager:(CLLocationManager *)locationManager
            locationFormatter:(MyCoreLocationFormatter *)locationFormatter
                    workspace:(NSWorkspace *)workspace;

The no-argument initializer calls the designated initializer with a new location manager, new location formatter, and the shared workspace. This allows production code to use the no-argument initializer and allows test code to use the designated initializer in order to inject test doubles, such as mock objects.

Some may find it odd to pass in an instance of NSWorkspace. I agree, it is a bit odd, but it’s necessary because it’s a singleton and hard to stub out for testing. There are other ways to achieve this, such as the category smashing Matt uses, or using a custom factory class that can be overridden by unit tests. However, eliminating the use of a singleton in the logic and using dependency injection is far more flexible. What if, for example, we wanted to run tests concurrently, like GHUnit allows? Now we’ve got to deal with thread safety issues when overriding the shared global instance. Remember, a singleton is a global in sheep’s clothing.

With these two hacks addressed, our tests in WhereIsMyMacWindowControllerTests become simpler. Again, I update the fixture to create mock objects for the various dependencies:

- (void)setUp
{
    // Setup
    _mockLocationManager = [OCMockObject mockForClass:[CLLocationManager class]];
    _mockLocationFormatter = [OCMockObject mockForClass:[MyCoreLocationFormatter class]];
    _mockWorkspace = [OCMockObject mockForClass:[NSWorkspace class]];
    _windowController = [[WhereIsMyMacWindowController alloc]
                         initWithLocationManager:_mockLocationManager
                         locationFormatter:_mockLocationFormatter
                         workspace:_mockWorkspace];
}

- (void)tearDown
{
    // Verify
    [_mockLocationManager verify];
    [_mockLocationFormatter verify];
    [_mockWorkspace verify];

    // Teardown
    [_windowController release]; _windowController = nil;
}

Here’s a few of the tests to show what a big difference these changes make:

- (void)testWindowDidLoadStartsLocationManager
{
    // Setup
    [[_mockLocationManager expect] setDelegate:_mockLocationFormatter];
    [[_mockLocationManager expect] startUpdatingLocation];

    // Execute
    [_windowController windowDidLoad];
}

- (void)testOpenInDefaultBrowserActionOpensGoogleMapsUrlInWorkspace
{
    // Setup
    [[[_mockLocationManager stub] andReturn:nil] location];
    NSURL * dummyUrl = [NSURL URLWithString:@"http://example.com/"];
    [[[_mockLocationFormatter stub] andReturn:dummyUrl] googleMapsUrlForLocation:nil];
    [[_mockWorkspace expect] openURL:dummyUrl];

    // Execute
    [_windowController openInDefaultBrowser:nil];
}

- (void)testCloseStopsLocationManager
{
    // Setup
    [[_mockLocationManager expect] stopUpdatingLocation];

    // Execute
    [_windowController close];
}

Note that I also moved the call to -stopUpdatingLocation from -dealloc to -close. I try to use -dealloc only for cleaning up memory related resources, which is especially important in a garbage collected environment. This also means we don’t have to stub out the call to -stopUpdatingLocation everywhere, making our tests simpler, too.

The test to ensure that the location formatter delegate updates the web view and test fields is still a bit lengthy:

- (void)testLocationFormatterDelegateUpdatesUI
{
    // Setup
    id mockWebView = [OCMockObject mockForClass:[WebView class]];
    id mockWebFrame = [OCMockObject mockForClass:[WebFrame class]];
    id mockLocationLabel = [OCMockObject mockForClass:[NSTextField class]];
    id mockAccuracyLabel = [OCMockObject mockForClass:[NSTextField class]];

    _windowController.webView = mockWebView;
    _windowController.locationLabel = mockLocationLabel;
    _windowController.accuracyLabel = mockAccuracyLabel;

    [[[mockWebView stub] andReturn:mockWebFrame] mainFrame];
    [[mockWebFrame expect] loadHTMLString:@"html string" baseURL:nil];
    [[mockLocationLabel expect] setStringValue:@"location"];
    [[mockAccuracyLabel expect] setStringValue:@"accuracy"];

    // Execute
    [_windowController locationFormatter:_mockLocationFormatter
                didUpdateFormattedString:@"html string"
                           locationLabel:@"location"
                           accuracyLabel:@"accuracy"];

    // Verify
    [mockWebFrame verify];
    [mockLocationLabel verify];
    [mockAccuracyLabel verify];
}

Personally, I’m not a big fan of these kinds tests, as well as tests that ensure outlets are setup properly after the NIB loads. If you stick with the skinny controller, fat model principle, the controllers become so simple they’re almost not worth testing. Just as you don’t test simple accessors because there’s little benefit to doing so, I don’t know that it’s necessarily worth it to get 100% code coverage on your controller classes. You still get a big benefit if the bulk of your code is in testable model classes, so this isn’t much of a loss.

There’s more changes I’ve made to the Mac application, and I’ve given the same treatment to the iPhone application, but I don’t want to make this post any longer than it already is. View the code I put up on Bitbucket, or download a tarball, to see the final result.

• A sample Mac application with complete unit tests
• A sample iPhone application with complete unit tests
• Quality control in application development without unit testing

However, I heartily disagree with a major point in the conclusion of his final post:

Unit testing an application is filled with difficulties and problems. In my development style, I consider the time cost of unit testing an application outweighs its benefits — especially since a unit tested application still requires system tests like user-interface and regression tests for proper validation.

Before I talk about why I disagree, I want to say that I do agree with the next part of the conclusion:

Regardless of whether you use unit tests, formalized system testing — either automated or manual and methodical — is required to fully validate an application and ensure the lowest possible low bug rates.

Unit testing, while practicing TDD, is not about testing, in the traditional sense. Unit testing does not tell you that your final application is actually easy to use by the end user. Unit testing does not tell you that you actually built an application that solves the problems you intended to address. Unit testing does not tell you if all your units work together once wired up. That’s what higher level acceptance and system tests are for. Acceptance and system tests are required to ensure the overall quality of your application.

However, this doesn’t make unit testing worthless. Applications have two kinds of quality: external and internal. External quality is how the end users perceive the quality of the application: does it crash, is it easy to use, etc. Acceptance and system tests keep the external quality high. Internal quality is how the developers perceive the quality of the code: is easy to understand and maintain, etc. TDD and unit tests are about keeping the internal quality of the application high. High internal quality makes bugs easier to find and features easier to implement. Unit tests provide an essential safety net to be able to refactor your code, improve the design, and avoid code rot. Ultimately this makes software cheaper (and more fun!) to write and easier to stay on schedule.

Thus any real world application should have both unit tests and acceptance tests. They are not mutually exclusive and they do not serve the same purpose. I honestly believe that if writing unit tests for TDD is slowing you down, then you are not properly practicing TDD. Remember TDD is a learned skill, and like any learned skill, it’s not something you pick up overnight. It takes practice. Is TDD a panacea? No, it’s not going to cure cancer and bring world peace, but I think it is the best tool we currently have in our arsenal to keep code clean, flexible, and maintainable.

Defaults        passprompt="%u@%h's password: "
Defaults        timestamp_timeout=15

The first line changes the password from something generic:

% sudo whoami
Password:
root

To something a lot more useful:

% sudo whoami
dave@fuji's password: 
root

The second line changes the time between needing to re-enter your password from 5 minutes to 15 minutes. This is handy if you’re confident you’re in a fairly secure physical environment, like an iMac at home, and you find sudo asking for your password too frequently. If you work in a more paranoid physical environment, you may want to keep the timeout at 5 minutes.

Remember to edit the file with visudo(8). Don’t edit it directly.

% sudo EDITOR=emacs visudo

Some interesting stats about this program:

• The song data is 485 bytes for 42 seconds of music.
• The assembled code is 575 bytes.
• It uses 32 bytes of RAM at runtime, not including stack.
• It uses probably 10 bytes of stack.
• The graphics are 8 kilobytes.
• The ROM file is 24 kilobytes (mostly zeroes, though).
• The video file I uploaded to YouTube was 784 kilobytes.

Much thanks to BunnyBoy and MetalSlime for their “Nerdy Nights” NES coding tutorials on Nintedo Age. The NES sound engine is all MetalSlime’s genius. I just plugged in the notes. The music itself was adapted from some sheet music I found. The lame “graphics” are all mine. I don’t know how to do much other than scroll the background and change the color palette, at the moment.

Also, the NesDev archive and wiki were invaluable as a technical references. For the toolchain, I used cc65, which includes a very nice assembler and linker for 6502. It would be nice to run this on actual hardware at some point using flash cartridge like the PowerPak.

I started learning NES programming only a few months ago. It’s just one of those useless skills I’ve wanted to learn for a while now. I probably had a bit of head start since I learned 6502 assembly back in the day on an Apple ][. Granted, that was a long time ago, but it’s a very simple CPU architecture so it comes back pretty fast.

Mercurial 1.3 added official support was for storing HTTP authentication information in .hg/hgrc. The official documentation for this is in the hgrc.5 man page, but there’s also a good article on hgtip.com on how to set it up. The gist of it is you put something like this in your .hg/hgrc:

[auth]
bb.prefix = https://bitbucket.org
bb.username = {username}
bb.password = {password}

The problem with this solution is that your password is stored as plaintext. Enter mercurial_keyring, also known as the keyring extension. If you leave the password out of your hgrc, the keyring extension will prompt you for the password and store it in a system specific password database, such as the OS X keychain, Gnome Keyring, or KDE KWallet.

Earlier versions had one drawback: it stored passwords indexed on the repository’s URL. For example, if you had two repositories on BitBucket, you’d have to enter your password twice, once for each repository. This wasn’t ideal, especially when you have many repositories on BitBucket. Once I entered my BitBucket password, I shouldn’t have to enter it again.

So I forked the project and and modified it so that saved passwords are indexed on the URL prefix you setup in hgrc. Thus, all authenticated BitBucket repositories will share the same password. My patches were accepted and included in version 0.4.0 of mercurial_keychain. I’ve only been using it for a day now, but it’s been working out well so far.