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!

Unit testing is a good idea. Ask any random developer what they think about unit testing and you’re likely to get one of four responses:

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!

I’m pleased to announce the immediate availability of MarsEdit 2.2, a free update to MarsEdit 2.

Generic AtomPub Support

AtomPub is a new specification for communication between a blog and a remote editor such as MarsEdit. To use MarsEdit with your AtomPub-compatible blog, select “Other AtomPub Compatible” from the configuration popup in your weblog settings, and enter the service document URL in the RPC URL field.

Please consider the AtomPub support somewhat “introductory.” It seems to work fine in my testing, but it hasn’t seen a whole lot of real-world use yet. I’m sure that development will be refined as I get feedback from users about security schemes you want to see supported, etc.

Customizable Image Markup

Now you can use MarsEdit’s powerful markup macros in the media window. In addition to the built-in macros for image alignment, you can add your own
to finely tune the markup that is used when inserting images or other files. Just select “Edit…” from the bottom of the popup menu that, by default, only contains alignment tags.

Performance Boost

Significant speed improvements to launch time and sorting the table of weblog entries.

And More…

• Support for removing unwanted items from the media catalog.
• New post table columns for viewing Tags or Post ID.
• A date editor pull down for easily selecting today’s date.
• Improved MIME type generation for uploaded files.
• Blosxom now uses the “Slug” field to specify the file name.

Hope you enjoy the update! Download it and let me know what you think.

Since Apple opened the floodgates to the AppStore for iPhone and iPod touch, the amount of anticipatory feedback I am getting from customers has exploded. Not a day goes by without messages from hopeful customers asking if and when my applications will be available for the iPhone. In particular, Black Ink and MarsEdit.

Will I release versions of these applications for the iPhone? Most certainly. Without a doubt. When? That’s a bit tougher to answer. I want to release these applications as soon as I possibly can, but no sooner. That is, I don’t think it would be fair to the public or good for my reputation to release premature applications, so I’m taking “my sweet time” to be sure I’m at least satisfied that they are good, reliable 1.0 releases before I go public with them. Stay tuned!

In The Mean Time

So what is an anxious customer to do in the mean time? I appreciate that iPhone users find it extremely frustrating to imagine what powerful aides their devices could be to them, if only they had the right software. While I do expect that, in time, there will be no better way to blog or solves crossword puzzles on this device than with my software, there is other software that is worth mentioning.

Waiting For MarsEdit

In the blogging department, WordPress users at least should have something to tide them over soon. Matt Mullenweg has announced a native WordPress client, which is apparently complete and submitted to Apple. They’re just waiting for it to go live on the store. Since we can’t try it out yet, I can’t exactly vouch for it, but I hope it will be a step up from navigating the web interface from the phone!

The folks over at Six Apart have also released a native iPhone blogging client, but unfortunately it only works with their paid TypePad service, so it won’t be of much help unless you happen to subscribe to that service.

Waiting For Black Ink

The allure of crosswords on the iPhone must be pretty obvious, because there are already two applications available for downloading and solving puzzles, and they’re pretty good! I have enjoyed buying these applications and seeing how other developers have tackled the problem of displaying a crossword puzzle while also leaving enough room for the user to type in the answers.

The first, simply called “Crosswords,” was developed by my friend Ben Gottlieb, of Standalone, Inc.

Notice how they’ve developed a completely custom keyboard, which aside form sporting a monochromatic look, is also significantly smaller than the default keyboard. This leaves more room to show the puzzle content. The high quality of the custom artwork makes the application shine, although it’s clear the puzzle rendering itself could be a bit cleaner.

The other application, called “2 Across,” comes to us from developer Eliza Block.

Notice that she uses the default keyboard, but provides an extremely zoomable puzzle display that exudes quality. The rendering is extremely sharp and the touch responsiveness is immediate. I also like how she animates the puzzle when you select a square, so that the word is as visible as possible within the confines of the display.

Back To Work

It would have been a great joy to have my applications in the App Store on day one, but looking on the bright side, it will be somewhat easier to finish developing them and to release them in a known context. It’s becoming clearer by the day what people are looking for in the store, and the wealth of applications makes it easier to experience what works and what doesn’t work on this new platform.