The contents of this podcast, expressed or otherwise, including but not limited to hints as to the veracity therein, triple-entendres relating to its verbosity, and also covering private or public scrutiny as to the tenacity of this agreement shall not, under any circumstances be conveyed, portrayed, imbibed, or parlayed to or by Apple Inc, its affiliates, or its aficionados.

(Spread the word! But don’t tell Apple!)

Just posted! Core Intuition 6, in which Manton and I leave a love note to The Talk Show, yack it up about bug tracking systems, and discuss juggling an indie business with new-dad responsibilities.

Thanks for listening!

1. I don’t know what they are.
2. I love them! You should always use them!
3. I hate them! You should never use them!
4. I appreciate them, but I’m lazy and don’t use them that much.

Of these, I have the most respect for the first and fourth. If you don’t know what unit testing is, you can hardly be blamed for failing to employ them. Go learn more about them and maybe you’ll enjoy the rest of this entry a bit more. If you are familiar with them but feel that you don’t use them enough, don’t beat yourself up. You’re probably using them “about the right amount.” That is to say, as much as you need to, in order to alleviate your pains.

Groups 2 and 3 could practically be folded into one, because each is about as useless the other. Some things in life demand a strict behavioral code, but programming is not one of them. Some kinds of code bases and programming tasks are extremely conducive to unit testing, and others are not. Use them wherever they make sense, and where they accelerate your ability to improve upon your existing code base. I won’t go into much more about the whens and ifs, but Wil Shipley and Bill Bumgarner have delved deeper into this question, if you’re interested in reading more.

Laziness Incubators

Let’s assume for the sake of argument that you’ve learned about unit testing, and self-disqualified yourself from either of the extremist groups described above. You probably find yourself in that fuzzy group that I’ve labeled lazy yet appreciative. Laziness on its own is one thing, but it doesn’t help when tedious roadblocks are put in our way to incubate further laziness.

“I should really add a unit test suite for this complicated class.”

…

“But then I’d have to create a new unit test file, and stuff…”

I’m ashamed to admit that this is how many a unit test has been put off. Other laziness incubators include the friction of adding a suitable unit test bundle target to a project, and the difficulty of deciding how to factor your unit tests so that they make sense in the context of your project. Oh, and let’s not overlook the difficulty of having to think up how to write the specific unit tests themselves.

Apple makes some of these roadblocks somewhat easier, with built-in unit testing support for Xcode. Unfortunately, they only go about 80% of the way in many regards, leaving us floundering to figure out how to fill the gaps for the remaining assistance we might need. These gaps where we’re forced to scramble for solutions can be a great deterrent to using unit tests as much as we might like.

Debugging Unit Tests

So you’ve overcome inertia and established unit testing build targets in your projects. You came up with an approach that makes sense for your code, created a new unit test suite source file, and actually written a few tests for your code. But now you’re bound to run into a vexing question: “how the heck do I debug this thing?”. Since unit tests are generally built into a standalone bundle, there’s nothing for Xcode to run. But when you come across a failing unit test and you can’t figure out why, you find yourself wishing you could step through the code just as you might in an application.

The answer to this question, as well as many other “missing pieces” for unit test support in Xcode, comes from Chris Hanson, who shares a great deal of useful information on his blog, including this gem on debugging unit tests. This post also contains a number of useful links if you’re still struggling with the other roadblocks such as adding a target, etc.

What we learn from Chris is essentially that the easiest way to debug unit tests in your project is to set up some executable, any executable, and arrange for your unit test bundle to be “injected” into the executable at runtime. Now, to debug your unit tests, you just ask Xcode to debug the injected executable.

It turns out this isn’t very difficult, but it’s tedious. To set up this custom executable, you need to add a bunch of cryptic command line arguments and environment variables to your project. Yuck! This cumbersome process has caused me on many occasions to “just skip doing unit tests for now.” That’s not really helpful to me or to the health of my code, so I finally got off by butt and wrote a handy AppleScript to do it for me:

Download Add Unit Test Executable. Free AppleScript.

What does this script do? In a nutshell, it asks for the name of your unit test bundle. Provide it, without the “.octest” extention, and the script will add a custom executable to your application, with all the gross arguments and environment variables needed to “make it work” in both Xcode 3 and Xcode 3.1. I added it to my Xcode application-specific scripts folder, and select it (using FastScripts) whenever I find myself in a project that doesn’t already have a suitable custom executable for debugging unit tests.

My script uses TextEdit.app as the test harness application, because it’s on everybody’s Mac, and because it seems like a fairly innocuous host application. Of course, you could use your own application, or another custom host application of your choosing. Just edit the script to suit your needs.

Hope this helps some of you overcome one source of laziness getting in the way of writing excellent unit tests!

Update: It just occurred to me that this script could probably be made even smarter by assuming that the selected target in the active project is in fact the test bundle we want to debug. That would eliminate the clumsy need to ask the user for the name of the test bundle.

In the podcast I mentioned a funny picture I had seen of many copies of Sudoku installed on the same iPhone. I mistakenly (tentatively, though!) credited Glenn Fleishman as the source of the picture, but in fact it was Dan Frakes, whose article on the subject just appeared in Macworld: Best Sudoku Apps for iPhone and iPod Touch. Here’s the original image he posted to Twitter.

Update: Here’s a later picture from Dan, where he’s truly taken Sudoku to the max!

Hope you enjoy the show! As always, your feedback is welcomed.

Nice work, Shimone! It’s great to see examples like this. As I said, I think it’s nice the way MarsEdit hides much of its functionality away, but the flip side of that is of course that it can be difficult to realize its full potential. Blog posts such as Shimone’s do a good job of showing off its hidden strengths.

Today Joel shared a very short and dangerous pronouncement on the use of hidden and disabled menu items:

A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used.

Don’t do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.

Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.

He’s absolutely right about hidden menu items, but on the subject he emphasizes, disabled menu items, he’s absolutely wrong.

Joel argues that instead of disabling a menu item, applications should leave them enabled, and instead display an informative message when the user tries to use them. This solves one problem: that of the user who is perplexed as to why a menu item is disabled. I recognize and applaud the desire to fix this issue. But enabling every menu item creates more usability problems than it solves.

Disabled menu items convey valuable information. Users who are skimming menus in order to figure out what to do are trained by years of experience to skim past disabled items and look for enabled ones instead. The more complex the application is, the more valuable this dichotomy becomes. In essence, disabling menu items gives application designers a means of “funneling” user attention to the actions in an application that will actually work at this moment in time.

Sure, it’s frustrating when you can’t figure out why a menu item is disabled. But what would be unbelievably frustrating is drowning in a sea of enabled menu items, for which the application offers no immediate usability guidance. Instead of skimming past disabled items, a user could be forced to select several, each time receiving a valuable instruction (punishment) as to why it was a worthless move. In time the user would learn to avoid these irritatingly enabled menu items, but they would be offered no future assistance in actually avoiding them.

Joel is right that it’s a bad idea to outright hide menu items. Users become comfortable with an application by learning its topography: where each menu item is in relation to its menu and the other items in that menu. When you go about willy-nilly removing and adding items, it can cause confusion. If you’ve ever visited an old home town after years away, you know this problem. You’re sure your favorite restaurant is around here somewhere, but so many of the shops and landmarks have changed, it’s hard to find it as quickly as you once could.

Joel’s suggestion may increase the learnability of an application in one very specific way, but at the expense of long-term usability. Although it can be argued that an application needs to be learnable in order to attract long-term users, I think user loyalty will be greater when the usability of the application is maximized.

What would be a better solution? The idea is to answer the naive user’s question: why is the menu item disabled? For this purpose I can think of many solutions. The application might show tool tips as the mouse hovers over the disabled menu item. Or if the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration. The point is to build a framework for application learnability that does not seriously affect the usability of the application for experienced users.

It’s not often I get to say it, but hear me loud and clear today: don’t listen to what Joel says about menu items!

Thus, code signing is a technology which is rather useless in itself, but which can be utilized by other services to achieve specific goals. Starting with Mac OS X 10.5, Apple built some features into the operating system which take advantage of code signing, including some features which make accessing secure items from the keychain less of a nuisance.

In particular, consider the scenario in which an application asks permission from the user to access items in the keychain. Once the user gives permission to “always allow,” the application can thereafter obtain a secret value from the keychain without user intervention. This is very handy for internet passwords, etc. But once the application changes, e.g. a new version comes out, the user must be asked again to permit the access. This is to ensure that malicious code hasn’t been snuck into the application.

But with code signing, the users permission can be expanded to cover any release of the application that was signed by the same certificate. The idea is that if users approve one version of an application, then they’ll likely approve the next version, as long as they are guaranteed it came from the same developer.

I have so far not signed any of my publicly released applications. I may do so soon, because these conveniences would remove one more tedious task for users who are updating to the newest versions of my applications.

But the user who has it worst of all is me myself, as I’m constantly revising the application, leading the system to request new approvals every time my changed application accesses the keychain. To get around these constant requests, I finally decided to at take advantage of code signing during the development phase. What does that mean? It means I’m committing to signing my own code for my own internal purposes, but not yet committing to signing publicly shipped products.

From Zero To Code Signed In 300 Seconds

With Xcode 3.0, code signing is easy, but takes a little work to set up. Since I just went through the somewhat tedious task myself, I thought I’d share with you how it’s done easily and predictably:

1. Establish a self-signing certificate. Apple offers simple instructions for how to do this with the Apple-provided Keychain Access utility. When you create the certificate, you’ll be asked to give it a name. Name it whatever you like, for instance “My Cert”. The certificate is stored in your keychain, where it can be easily referenced by name.
2. Add a custom build phase to Xcode. Xcode will not automatically sign your code, but it’s easy enough to add a build phase that does. Select your target in Xcode and choose “Project -> New Build Phase -> New Run Script Build Phase” from the main menu. Paste in the following script:

   if [[ ${CONFIGURATION} == "Debug" ]]
   then
   	# -f means force to re-sign even if already signed
   	codesign -f -s "My Cert" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/"
   fi
   

   Observe that the “My Cert” text can obviously be changed to whatever you ended up naming your certificate. Also notice that because of my hesitation to ship a code signed application yet, I am restricting the action to only the Debug build configuration. If you’re ready to go public, just remove the test and the code signing will happen for all build configurations.

3. There’s no step 3! Enjoy.

Constantly approving those keychain approval dialogs is one of the things that I just fell into the habit of tediously doing. Thanks to Apple’s code signing efforts in 10.5, there’s no longer any reason for me to do that. Hopefully if you use the keychain in your own development products, you’ll find this productivity upgrade useful as well.

I spoke to them about their solution at the time, and was impressed by it. It certainly seemed like a good way to avoid turning those thousands of plastic discs into guaranteed landfill fodder. But what’s even cooler is that they’ve now decided to share the technology so that other companies who are interested can pull of the same feat with a minimum of work:

Announcing LiveDiscKit

It’s also worth reading to near the end of the article, where they confess that even with the clever technology in place, the discs did not turn out to be all that effective as marketing tools:

Of the 5,000 discs we gave out, 5.8% were ever used. That may seem a bit low, but it gets quite depressing when converted to an absolute count: 288. Out of 5000 CDs given out, no more than 300 were used - perhaps giving away CDs isn’t the best idea after all

Well, you can’t win them all! On the bright side, I don’t think they would have been able to gather this information without putting in the effort to make the discs smart enough to “check for updates.” It was a valiant effort, and a very cool idea that other companies might still find useful.

There are good arguments for this, at least on the face of things. They can be packed into a nutshell: it may reduce the security risks of having these access points opened by default.

But in my opinion, there are also good arguments to be made for rejecting the change as a damaging and misguided solution.

First, and obviously near to my heart, is the fact that this marginalizes remote clients. For users who would find value in a remote client, this decision will put one more roadblock in their way. Historically, the remote editor interface is already compromised such that remote editors do not have access to all the same functionality as the web interface. With this change in place, things get even worse. While a screen-scraping application will easily log in and authenticate a fragile WordPress session via the web interface, the well-behaved API clients will be refused access by default. All in the name of improving security.

Second, and probably most important, is that this is not a fundamental security improvement. Consider a bank with two sets of automated cash machines: one for drive-through cars, and one for walk-up pedestrians. Two vastly different sets of customers are being served securely by different interfaces, yet the transactions are secure because they ultimately travel through the same bottlenecked safeguard. A fundamental design consideration on the part of the bank is that these two classes of customer are equally important, and each deserves unfettered access.

WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.

Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!

A Real Solution

If I’m so smart, what should WordPress be doing instead? A real security improvement would be bottlenecking all access to the blog’s vital authorized content, and making sure that the remote APIs and the web interface all go through the same interface.

In my opinion, an entire class of problems with WordPress (and other blogging systems) stems from this interface bifurcation. Establishing a single interface to WordPress would be comparable to the “pin code + card” interface at your bank. You pass through it by car, on foot, and even at the counter when they ask you to swipe before doing any transaction.

If you’ve only got one “real API” that touches the critically important data, then you’ve only got one door to secure. Furthermore, when all views into the blog are required to share the same API, suddenly none of them is deprived of functionality that the other has.

Imagine if the API that the web interface uses to access all features of a blog could be just as easily employed by MarsEdit or any other application you authorized. The end result would be lots less work “playing catch up” for the XMLRPC and Atom developers, and more time focusing on innovative and cool features for all blog users.

If this sounds like a pipe dream, it’s worth pointing out that one very popular web service is already employing this strategy, and it works brilliantly. Flickr, Yahoo’s incredibly popular photo sharing site, is built on the very same APIs it makes available to clients. This results in some truly incredible Flickr-enabled applications and web services. And you don’t see any sign of Flickr disabling access to their API, because there’s too much at stake.

If your web service only provides one, first-class API through which all access flows, then you’ve only got one point to secure, you’re likely to have feature parity across interfaces, and the risk of marginalizing one interface is dramatically decreased.

We’re proud to announce the immediate availability of episode 3, where we talk about WWDC, MobileMe, iPhone 3G, and a bunch of relatively unrelated stuff.

Check us out!