// TODO: make sure file exists before opening!
fooBar = [[FooBar alloc] initWithFile:path];

This is a reasonable thing to do, because sometimes you just want to get something working right now and aren’t in the mood to write all the required error checking code. But, you also know that you cannot trust your soft human brain to remember to add the check later, so you write a comment to remind yourself to do it.

Xcode recognizes the TODO: keyword in your comments and helpfully adds items to the function popup menu so that you can quickly navigate to them. In addition to TODO:, Xcode will also recognize FIXME: (when you know the code is broken), ???: (when you don’t know what it does), and !!!: (when you wish you didn’t know).

That’s helpful when you’re editing a file, but what about a TODO tucked away in some dark corner of your source code that you haven’t visited in a while? You’re likely to forget about it, and how can you keep a promise you forgot that you made?

The answer, of course, is to have somebody nag you. Fortunately, there’s a way to have Xcode fill that role. All you have to do is add a simple Run Script Build Phase which turns them into Build Warnings.

Select Project > New Build Phase > New Run Script Build Phase from the menu bar. Then, copy and paste this into the script window:

1
2
3
4

KEYWORDS="TODO:|FIXME:|\?\?\?:|\!\!\!:"
find ${SRCROOT} \( -name "*.h" -or -name "*.m" \) -print0 | \
    xargs -0 egrep --with-filename --line-number --only-matching "($KEYWORDS).*\$" | \
    perl -p -e "s/($KEYWORDS)/ warning: \$1/"

What does it mean?

Line 1 defines the keywords we want to search for. If you want to exclude a keyword or include a different one, edit this line.

Line 2 uses the find command to generate a list of all files in your project directory (SRCROOT) having an .h or .m extension. If you want to search more files, you will need to edit this line.

Line 3 uses xargs to pass those file names along to egrep, which searches inside the files for lines containing one of the keywords. If any are found, it outputs the file name, line number, and the matching part of the line.

Line 4 uses Perl to format the lines as warnings.

The output of the script will look like this:

/Users/benzado/Projects/FooBart/Baz.m:42: warning: TODO: make sure file exists before opening!

Xcode will recognize lines in this format and treat them as first class build warnings. You can see them in the Build Results panel and, just like a warning from the compiler, a double click will open an editor window and take you directly to the offending line.

An Exercise For The Enterprising Reader: modify the script so that no warnings or errors are reported during Debug builds, but TODOs are flagged as errors in Release builds.

But I’m not working with table cells, so even though the standard disclosure indicator is perfect for this situation, if I want one I’ll have to draw it myself.

In this situation I will usually take a screenshot of the real iPhone control, add the image file to my project, and then feel kind of guilty about it. I began to do this, but I realized that the disclosure indicator is really only two gray lines. Two lines! How hard can it be to just draw it in code?

It turns out that it’s not too hard, if you’re willing to spend some time experimenting with different numbers and seeing what looks right. Fortunately for you, I’ve saved you the trouble by posting the answer here:

// Draws a disclosure indicator such that the tip of the arrow is at (x,y)
void BRDrawDisclosureIndicator(CGContextRef ctxt, CGFloat x, CGFloat y) {
    static const CGFloat R = 4.5; // "radius" of the arrow head
    static const CGFloat W = 3; // line width
    CGContextSaveGState(ctxt);
    CGContextMoveToPoint(ctxt, x-R, y-R);
    CGContextAddLineToPoint(ctxt, x, y);
    CGContextAddLineToPoint(ctxt, x-R, y+R);
    CGContextSetLineCap(ctxt, kCGLineCapSquare);
    CGContextSetLineJoin(ctxt, kCGLineJoinMiter);
    CGContextSetLineWidth(ctxt, W);
    CGContextStrokePath(ctxt);
    CGContextRestoreGState(ctxt);
}

Before calling the function, you should set the stroke color to 50% gray if you’re drawing on a white background or white if the control is highlighted and you’re drawing on a blue background. Or, you can use whatever color you like.

To be honest, I only eyeballed the result, so it might not be a pixel-perfect reproduction of the real thing. However, I think my eyeballs are at least as good as most users’ eyeballs, so I will confidently declare this code Good Enough.

Here are some alternatives:

To view a man page in Xcode’s documentation window, simply select “Open man Page…” from the Help menu. For some reason, I hadn’t noticed that menu item until I read this hint on accessing it via AppleScript. Nicely formatted and references to other man pages are hyperlinked.

Bwana allows you to read man pages in any web browser, by registering itself as a protocol handler for man: URLs. Once installed, you can type man:perl in your browser’s address bar or open man:perl at a command prompt to read a manual page in your browser. Like Xcode, cross-references become hyperlinks, but it formats text using Courier. Source code is available, so I guess if I care enough I can do something about it.

Finally, a surprisingly short incantation will open any man page as a beautifully formatted document in Preview:

man -t perl | open -f -a /Applications/Preview.app

The -t option tells man to output PostScript, and the -f option tells open to put its input into a temporary file and pass that along to the specified application.

After reading that hint I set about writing a shell function so I could type manp perl to open Perl’s manual page in Preview. However, Preview’s PostScript to PDF conversion is kind of slow, so I wound up writing something slightly more sophisticated:

function manp {
    local M=`man -w $*`               # Get path of page source.
    if [ -z $M ]; then return; fi     # Quit if it doesn't exist.
    local N=`basename $M .gz`         # Extract the name of the file and
    local P=$TMPDIR/man.$N.pdf        # use it to create a PDF file name.
    if [ ! -e $P ]; then              # If the PDF file doesn't exist,
        echo Creating PDF for $N...
        man -t $1 | pstopdf -i -o $P  # generate it.
    fi
    open $P                           # Open the PDF version.
}

Then I went back and read the comments, which contain a dozen or so different versions of the same idea. But mine’s the best! Copy and paste it into the your .profile if you agree.

1. If I print all network traffic all the time, it overwhelms my console, making it useless for any other kind of output. So instead, I’m constantly inserting or removing NSLog() statements as I work. Not to mention having to reproduce a request because the right logging statements weren’t in place the first time around.
2. NSURLConnection returns downloaded information as an NSData object, so simply passing it to NSLog() dumps a lot of useless hexadecimal code to the screen. That means I must first create an NSString from the data, print it, then release it. (I can’t use %s, the data isn’t null terminated.)
3. NSURLConnection does a lot of behind the scenes work, like storing cookies and setting Content-Length headers. That’s nice, but that makes it hard to know exactly what’s being sent on the wire.

And that’s when it occurred to me: why not just watch what’s on the wire? tcpdump is a command line utility which monitors network traffic and prints out packets that you specify.

Here’s the incantation to monitor HTTP traffic to and from a specified host:

sudo tcpdump -l -q -A "host (Specified Host) and tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)"

To explain briefly, sudo runs the command as root, -l enables line buffering, -q hides some of the less interesting protocol information, and -A prints the content of each packet in ASCII. The filtering expression that follows selects packets to or from (Specified Host), to or from port 80, and ignoring SYN, FIN, ACK-only, and other non-data packets. I’ll confess, I don’t understand that last part completely, I copied it from the tcpdump man page.

To make the output a little easier to read, I pipe the output to a Perl script I quickly hacked together which watches for the packet header lines and outputs the ANSI escape codes to render them in bold. But I’ll leave that as an exercise to you, dear reader.

There’s no need to download anything, tcpdump is already installed on your Mac. (I don’t know if it’s part of the standard install or the Developer Tools, but what do you care?)

Now, what would be really sweet is a graphical app to do this. I found Cocoa Packet Analyzer, but it’s a little low-level for me. I don’t care about packet specifics; I’d prefer something that reconstructed the tcp streams in an easy to navigate way.

This is annoying, because that purple monster isn’t even a real event; it’s just a notice that somebody’s film is available for download from Amazon. As much as I encourage everybody to watch that film, I don’t want it eating up my calendar. I am routinely invited to events like this, and they are always announcements, or “I’m looking for a roommate,” or “I was too lazy to create four separate events for the show I’m doing four times this month.” In other words, calendar spam.

This would be tolerable, if there were some way to hide individual events, but there isn’t. Facebook includes every event you’ve been invited to, even if you RSVP: Not Attending. You can uninvite yourself using the “Remove from My Events” link, but it’s tedious and doesn’t protect you from being re-invited in the future. It’s also of no use if you’re away from the computer and viewing your calendar on your iPhone.

How to Clean Your Calendar

I solved the problem with a program that acts as a proxy between your calendar app and Facebook, removing events that are longer than 12 hours. It’s on the web, so you can use it, too.

First, find your Facebook Calendar URL by going to Facebook Events and clicking “Export Events” in the top left corner. A box will appear with an address that looks something like this:

http://www.facebook.com/ical/u.php?uid=123456&key=789abcdef

To use the filter, change the first part of the address (everything before the question mark) so that it looks like this:

http://www.benzado.com/bin/icalproxy.php?uid=123456&key=789abcdef

Then you can use the new address to subscribe to your filtered calendar in apps like Apple iCal or Google Calendar.

Note that using my filter means your events pass through my web server, and even though I’m not really interested in looking at them, I could. So if you’re super concerned about your privacy, keep that in mind.

If you’d like to see how the script works or make a copy to run on your own server, you can view the source code. If you extend it in any interesting ways, please let me know.

Your iPhone app includes a Settings bundle, so that you can keep your application simple and leave the settings in the settings app. Specifically, you allow the user to customize the FooColor setting, with a default value of Red.

Initially, the user defaults database doesn’t contain a value for FooColor. Although you defined a default value in the Settings bundle, only the Settings app pays any attention to it.

Take Note: Cocoa uses the term “user defaults” to refer to application settings in general. Don’t confuse that with the notion of a default value, which is the initial value of a setting before it has been changed through user action.

The proper way to load default values at runtime is to use NSUserDefaults’s registerDefaults: method. It takes a single NSDictionary object and merges it into the user defaults registration domain. (The user defaults database is divided into domains, or layers.) Values in the registration domain are only used if they are not defined anywhere else, so you don’t need to worry about overwriting a user’s preference.

You create a property list file named Defaults.plist, define an entry giving “FooColor” the value “Red”, and load it:

NSString *path = [[NSBundle mainBundle] pathForResource:@"Defaults" ofType:@"plist"];
NSDictionary *dict = [NSDictionary dictionaryWithContentsOfFile:path];
[[NSUserDefaults standardUserDefaults] registerDefaults:dict];

The only problem with this set up is that you must keep your Settings bundle and Defaults.plist files in sync. If you change the default FooColor from Red to Blue, you must change both. If you add a new setting, you must add it to both. If you’ve been programming for more than a month, you know that eventually you will make a mistake which will lead to a bug that will take forever to track down and take years off your life.

Therefore, a better solution is to dynamically generate Defaults.plist from the data that is already in the Settings bundle. You can do so with ExtractDefaults.xsl, a simple stylesheet which creates an XML property list from a Settings bundle definition, and xsltproc, which is fortunately already installed on your Mac.

First, if you really did create a Defaults.plist, remove it from your project and delete the file. It’s graduating from a source file to a build product!

Then, select your target in Xcode. Go to the menu bar and select Project | New Build Phase | New Run Script Build Phase. A window appears. In the Script area, enter the following shell script:

SETTINGS_PLIST=$SRCROOT/Settings/Root.plist
XSL=$SRCROOT/ExtractDefaults.xsl
DEFAULTS_PLIST=${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/Defaults.plist
xsltproc -o $DEFAULTS_PLIST $XSL $SETTINGS_PLIST
plutil -convert binary1 $DEFAULTS_PLIST

You may need to edit the first three lines, depending on the path to your Settings page file and where you saved ExtractDefaults.xsl. It’s also recommended that you fill in the Input Files and Output Files lists, so that Xcode can intelligently determine when the script needs to be run (when input files are newer than output files). Following the script above, Input Files should contain:

$(SRCROOT)/Settings/Root.plist
$(SRCROOT)/ExtractDefaults.xsl

Output Files should contain:

$(BUILT_PRODUCTS_DIR)/$(WRAPPER_NAME)/Defaults.plist

Note that Xcode needs round parenthesis around variable names, unlike the shell script, which uses nothing or curly braces. There’s a good reason for this, but I don’t know what it is.

That’s it! Now, when you build your app, the script will generate a Defaults.plist file inside of your app bundle, so it can be loaded by your code. And you won’t have to worry about your app defaults mismatching your Settings bundle defaults, because it is being handled by a machine, and machines never fail!

Mini-FAQ

Where do I get ExtractDefaults.xsl? Click here to download the file. It’s free to use for whatever you want to do with it. If you improve on it in some way, kindly let me know.

What if I have also default values not defined in my Settings bundle? You can manually enter them into another property list file, and load both. It’s totally cool to call registerDefaults: several times with different dictionaries. Totally cool!

What if my Settings bundle contains multiple page files? In that case you could run the script over each one, generating several Defaults.plist files, and load them all at runtime. Or, if you’re really clever, figure out some way to merge them all into a single property list at build time. I can’t do everything for you.

The Intent of Code

When we look at well written C code, we can tell exactly what is going on by glancing at it. That’s the power that C gives us. If I want to take a drink of water while doing a cartwheel, I call the function:

drink(water, TRUE);

We know exactly what that means. There is no room for interpretation. It is pure, simple, and good, just as Jesus intended.

Then comes Objective-C…

Objective-C comes along, sprinkling diabetes-inducing syntactic sugar all over our code. We wind up having to read code like this:

x = [foo value];

What is that? Can anybody interpret that? Of course not! That’s because the compiler could translate it into a call to any one of the functions objc_msgSend, objc_msgSend_fpret, or objc_msgSend_stret. But we have no way of telling which one! It’s impossible! For all we know, the compiler just picks one at random!

It’s incredibly confusing, which is why I recommend that students exclusively call those C functions directly, so there is no doubt about which one is being called. That way the code is readable.

But I’m used to Smalltalk. Bracket notation looks like I’m at home!

You are not at home. You’re in the forest, and wolves are trying to kill you.

Apple uses it in their sample code, though!

That’s right, they do. But should you really be trying to emulate Apple? Have you heard about the App Store review process? They are totally incompetent and can’t do anything!

In the end, there is a wrong way and a right way to write Objective-C code. I will not say that using brackets is wrong, even though I tell my students never ever to use it. Is that confusing? Not as confusing as brackets are.

Many of the mercenary testers I encountered were motivated to scrape the system for bugs, as ridiculous as they may be. They logged them into the bug system and then defended them at all costs, as if their lives depended on it. And it turned out, they did. At least, their paychecks did.

I would not be surprised to learn that App Store reviewers are working under a similar structure. A system that rewards “unique, valid rejections” would certainly explain the behavior we have seen coming to light in the past year.

QA teams, like the ones Daniel writes about, reward “unique, valid bug reports” because all the testers are testing the same piece of software. If a group of testers repeatedly file duplicate bug reports, clearly you have an inefficient team, and can afford to let some of them go. The team has an incentive to reward unique reports.

The App Store review team, on the other hand, has one reviewer per app, and each app is different. Even if the team was perversely trying to justify its existence by beefing up its rejection numbers, there would be no need to come up with “unique, valid rejections.” In that case it would be more efficient for them to reject apps with increasingly vague reasons, or no reason at all.

It is more likely that reviewers are severely punished (i.e., fired) for approving an app that later causes a problem. That’s the kind of situation that leads to overzealous reviewers without assuming that management is dumb.

And there are problems: all the writing on the Ninjawords rejection pits Apple against enlightened liberal people. Not pictured are the parents who have purchased an iPod touch for their young child and want to let them download games from the App Store, but maybe don’t want to let them downloading Motorboat, which is not actually about boats, but involves rubbing your nose on the touchscreen.

When Apple added ratings to the App Store, it did not do so in a vacuum. It has quite a few customers with children, who I suspect express themselves by making phone calls instead of posting on blogs. So while we’ve read a lot about the helpless developers who are being persecuted by puritannical Apple, we haven’t read the testimony of parents who are trying to give their child a little bit of freedom without having to worry that they will get the idea that sticking your nose in a woman’s cleavage is an acceptable thing to talk about during Thanksgiving dinner.

It wasn’t obvious what was causing the crashes, but I found out I could use a Microsoft Debugging utility to read the memory dump files that Windows creates on each crash. I offered to take the computer home with me, so I could plug it into a network and install the utility and finish the job.

Booting into “Safe Mode with Networking” worked, so I was able to download the utility, but I was not able to install it. I was told, “The System Administrator has set policies to prevent this installation.” That was confusing, because I logged in using the fucking system administrator account. Now I am pretty sure that the error message is inaccurate, because some lazy asshole at Microsoft decided to use that very specific text as a generic “operation failed” message.

It turns out that the installer program requires the Installer Service to be running, but the Service cannot be started in Safe Mode. So, if I want to use the debugging tools, I am caught in a catch-22: the computer will crash if I don’t use Safe Mode, but I can’t diagnose the crashes if I do use Safe Mode.

After chasing my own tail for longer than I’d like to admit, I realized I could try finding some other tool to extract the utility from the installer package. I found such a tool, and in the process I learned that MSI archives are apparently unable to store file extensions, so when you unpack them, you have to manually insert the dot in hundreds of file names. I do this for a subset of the files that seem necessary to run the diagnostic program, and finally, I get it to run.

At least, I think I do. It outputs a lot of error messages, but the instructions I am following from some sketchy website say it is normal to see a lot of messages, so I have no clue if it’s working or if I need to add more dots to more filenames. I blindly forge ahead, and finally get it to generate a report from one of the memory dump files.

The goal, in case you’ve forgotten, is to find out what is responsible for crashing the kernel. The report indicates the memory location where the crash occurs: Good. It also contains a list of loaded drivers and what memory locations they occupy: Good. So I scan the list to find the culprit. While every other line has a driver name, this one has the name “00001b6f” or something like that. No name, just a hexadecimal number without context. WTF?

So, I give up.

To be clear, I’m not just giving up on this job, but I’m giving up on ever attempting to “fix” a computer running Microsoft Windows ever again. It’s been so long since I used one regularly that I’m no longer familiar with all the voodoo incantations required to make them work. The only thing my technical knowledge buys me is a misleading sense of being “one step closer” when in fact I am running in circles. It is painful and frustrating and humiliating. I honestly feel like I’m the butt of a joke right now. Like I’ve spent four hours trying to catch a pig on a dare.

By taking this computer home, I thought I was doing a favor for a friend, but now I realize that she has done a favor for me. I’ve learned a lesson. I’m sorry, I can’t fix your computer, I don’t know how.

The impatient can get it here: mkbuild.zip

The basic idea is that you create a build-config.sh file with some instructions on how to build your particular project, place it into a checked-out working copy of your project, and run mkbuild.sh from within the same directory. When you ask it to create a new build (mkbuild.sh new), it will:

1. Tag your repository with a build number (e.g., build-0023).
2. Export that tag to a RAM disk.
3. Compile and package your app as instructed by the configuration file.
4. Destroy the RAM disk.

I like using RAM disks for this sort of thing, since there is no doubt the build is clean.

The build number is always a four digit, monotonically increasing integer. When you make a new build, the script scans your existing tags and automatically determines the next available build number. I briefly experimented with using the repository revision number, but decided it would be better to decouple the build numbering from the revision control system used.

That turned out to be a good move, because although I developed the script to work against a Subversion repository, I made a git version for a different project I worked on. I have since merged the two, so the mkbuild.sh script will talk to either Subversion or git, depending on how you configure it.

Here is a summary of the operations it supports:

• mkbuild.sh new creates a new build
• mkbuild.sh rebuild n recreates build n, in case you deleted it
• mkbuild.sh log n prints changes between build n and build n – 1
• mkbuild.sh log n m prints changes between build n and build m
• mkbuild.sh list lists all builds in the repository
• mkbuild.sh archive n creates a zip file of the source of build n

Everywhere it asks for a build number, you can specify 3 and it will automatically interpret that as 0003.

Although I wrote the script to simplify iPhone project builds, it could be easily adapted to handle any Xcode project.

Please try it out and let me know what you think. This link will always redirect you to the latest version and I’ll make previous versions available here. Since the script will tag your repository, be responsible and make a backup before you start experimenting. The zip file contains a sample configuration file and there is documentation is in the script source itself.