Recently in Tech Category

On Monday, I had a series of tweets ([1], [2], [3]) about what I like about Java that I miss in Objective-C/Cocoa that were probably better off in a blog post. I blame Jeff LaMarche for baiting me into the tweet rant, so here’s the the same thing, in blog post format with more detail and other points I forgot to mention.

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)

This is a follow-up to my post on why you should unit test Cocoa and iPhone applications. One reason I think Matt is against unit tests, at least given his particular examples, is that the tests themselves are quite large and confusing. They also use category smashing to override methods and inject mock objects and use runtime trickery to gain access to private instance variables.

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.

Matt Gallagher, on his absolutely fantastic Cocoa with Love blog, recently wrote a series of posts about test driven development (TDD) and unit testing Mac and iPhone applications:

• 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.

By and large, sudo on Mac OS X comes setup with some sane defaults. But here’s two lines I add to my /etc/sudoers file on a fresh install:

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

One of my gifts to my wife, Nancy, for her birthday this year was the Happy Birthday song, chiptune style. It’s an actual NES program, hand-coded in 6502 assembly. This is the first original NES program I’ve written, and could be considered my first homebrew or even demo. While you can download the ROM and run it yourself, here’s a video of it running in Nestopia, an NES emulator [YouTube link]:

Some interesting stats about this program:

Authenticated Mercurial repositories are generally handled in one of two ways: HTTP authentication or SSH. Prior to Mercurial version 1.3, the best way to handle authenticated repositories so that you didn’t have to enter your password on every transaction was to use SSH with ssh-agent, or, if you were running Mac OS X, use Jonathan Wight’s hgkeychain extension, which stored HTTP passwords in the Mac OS X keychain. As of Mercurial 1.3, there’s a new way to handle authenticated HTTP repositories that I’ve just started using.

For those that missed the announcement, NSConference 2010 is now open for registration. NSConference is a 2-day conference for Mac and iPhone developers, plus some optional workshops. If you missed WWDC or C4, or just can’t get enough good technical information related to all things Mac and iPhone, check out NSConference. There’s one in Europe and the US, so there’s no excuse for not going! Yours truly will be giving a talk on writing clean code.

Bottom bars have been an important user interface element for a while now on Mac OS X. They’re that gray status bar you see at the bottom of many of Apple’s applications including iTunes, Finder, iChat, iCal, Address Book, and iPhoto. The Human Interface Guidelines even has a whole section on bottom bars describing what they are and when to use them. In case you’re not familiar with what they look like, here’s a fresh window with a bottom bar:

In Mac OS X 10.5, Apple added a new API to NSWindow to add bottom bars, somewhat cryptically named setContentBorderThickness:forEdge:. There was no support for bottom bars in Interface Builder 3.0 and 3.1, though, so you had to call this method in awakeFromNib:

[window setContentBorderThickness:22 forEdge:NSMinYEdge];

In Snow Leopard, we finally get Interface Builder support for bottom bars. I somehow missed this in the new IB until just this week, and it’s easy to use.

This blog currently runs on Movable Type, and has since I started it back in 2003 on version 2.65 (dang, my first post is quite a snoozer). I even wrote some plugins for version 2 and 3 to cope with some of the limitations of its permalinks.

However, I recently learned that version 5 will only supports MySQL. This is a huge disappointment as SQLite is one of the major reasons I chose Movable Type (see my comments about upgrading to MT 4). I don’t know what’s motivating this decision, but it really makes no sense. Is it really that hard to write database neutral SQL? Surely this is a solved problem by now.

This is so bad that it’s deal killer for me, and I’m starting to investigate my options going forward.

Last week, Mike Ash wrote a post describing the different install name keywords recognized by the Mac OS X dynamic linker: @executable_path, @loader_path, and @rpath. I wanted to chime in with a bit of advice: if at all possible use @rpath.

This gist is, if you’re targeting 10.5 or later, use @rpath. There’s no reason I can think of to still use @loader_path. If you’re still on 10.4, use @loader_path. And let’s hope that you’re still not targeting 10.3 and earlier, so forget that @executable_path ever existed. There’s really never a good reason to use @executable_path on 10.4 and later.