1. Navigate to a .app file in the Finder, e.g. /Applications/Mail.app
2. Control-click the app icon and select “Show Package Contents”
3. Navigate to Contents/Info.plist
4. Open with a plist editor or your favorite text editor.

These files advertise a number of interesting attributes including the application’s official version and copyright strings. They also include important clues to the system about what kinds of files the application knows how to read and write, and what its minimum system requirements are.

Minimum System Requirements

Declaring the right Info.plist values not only allows a developer to control which operating systems a product should run on, but which of the application’s architectures should be considered for a particular operating system. For example, Black Ink uses a number of keyed values describing its requirements:

	<key>LSArchitecturePriority</key>
	<array>
		<string>x86_64</string>
		<string>i386</string>
		<string>ppc</string>
	</array>
	<key>LSMinimumSystemVersion</key>
	<string>10.4.0</string>
	<key>LSMinimumSystemVersionByArchitecture</key>
	<dict>
		<key>i386</key>
		<string>10.4.0</string>
		<key>x86_64</key>
		<string>10.6.0</string>
		<key>ppc</key>
		<string>10.4.0</string>
	</dict>

Notice the fidelity of some of these options. Black Ink is an application that is compiled with binary code for three separate architectures embedded into it: 64-bit Intel, 32-bit Intel, and 32-bit PowerPC. In order to give the user the best possible experience after they double-click the application icon, the system consults the Info.plist values to determine which binary is most appropriate to load on the current system.

The options for Black Ink start by indicating that all things being equal, it prefers to run as 64-bit Intel, but will settle for 32-bit Intel or PowerPC in a pinch. Next, it conveys that it should not be run on any operating system earlier than Mac OS X 10.4. Finally, it adds an additional restriction by architecture, stating that in the case of 64-bit Intel, the system should consider Mac OS X 10.6 the minimum required OS.

Why so picky? For example, Mac OS X 10.5 will run on computers that are new enough to support 64-bit Intel code, but the 10.5 operating environment itself doesn’t contain enough compatible libraries to make it very useful to a full-featured Cocoa application. So we need to convince the 10.5 system to ignore our 64-bit Intel code. And this is how it’s done.

Embedding Info.plist

This is all well and good for applications, but what about other code that may be run on a variety of hardware and operating systems? In particular, command-line tools do not come in the same bundled-folder format that applications do. Fortunately, Apple thought of this when they implemented support in their developer tools for embedding the contents of an Info.plist directly into the binary itself. You just have to pass the Info.plist path to Apple’s linker tool when it’s constructing your binary file. (Thanks to Paul Kim for reminding me of this functionality). What this means in practice is adding arguments like this to your Xcode target’s “Other Linker Flags” build setting:

-sectcreate __TEXT __info_plist $(INFOPLIST_FILE)

This instructs the linker to crete a new text segment named “__info_plist” in the resulting binary, and to fill it with the contents of the referenced Info.plist file. To make sure the INFOPLIST_FILE expands correctly, just make sure you set it in the separate build setting for identifying the Info.plist (the one you’d normally use in an app, and that is just ignored by default for a command-line tool target).

I brushed up on all this information because I wanted to help ensure that some recent work I did to create a standalone MultiMarkdown tool would be backward compatible with older systems. This required adding an embedded plist much as I’m describing here.

(Note: I have gotten some feedback to the effect that the __info_plist segment’s minimum system version requirements may not actually be consulted properly on Mac OS X 10.5. This would be a bummer, and in fact sort of reject the whole point of embedding the Info.plist in this case. I’m going to see if I can confirm whether it doesn’t in fact work.)

You could technically embed all kinds of stuff in the binary, with different section names. But the contract in this case is that when Mac OS X is determining information about an executable, it will consult the bundle’s Info.plist file, if it happens to be an executable in a bundle, or the binary’s __info_plist segment, if it happens to have one.

Another common reason for needing to embed Info.plist information into a standalone binary is if you are using Apple’s code signing mechanism to sign an individual binary tool. Code signing uses information from the Info.plist of a product, and in the case of standalone binaries, the only product-cohesive place to put this is in the binary itself.

Examining Binary Info.plists

After you’ve performed the magic above, you’ll probably be keen to inspect your command-line tool’s Info.plist to see if it worked. To do this, you can use the otool command from the Finder. If you run otool with the “-l” option to show all load commands, it will include the load command that identifies the __info_plist segment. Use grep to narrow it down to the part you’re interested in:

otool -l ./yourTool | grep info_plist -B1 -A10

Any results at will confirm that there is Info.plist information in the binary, but how does it look? The “-s” option to otool lets you examine the contents of a specific segment in a binary, but it dumps it out as hex code. Fortunately, another system-bundled tool called “xxd” is capable of easily converting between hex-dump and text formats. As it turns out, some of Apple’s bundled developer tools (at least on my Mac) contain these embedded __info_plist sections, so if you don’t have a command line tool of your own to try this on, you can peek at what the “atos” tool has to say for itself:

otool -s __TEXT __info_plist /usr/bin/atos | xxd -r

In Summary

Info.plist values are important for conveying information about your product, from the crudest, most obvious stuff like version number, to the most nuanced details such as which architectures are supported. Knowing how to specify an application or tool’s requirements as precisely as possible will ensure that the product performs optimally on whatever supported system your user happens to be using. I’ve barely scratched the surface here with a few common deployment keys that control execution behavior on Mac OS X. Be sure to skim Apple’s Information Property List Key Reference to see if there are other useful bits of information you can share for your application or for your command-line tool.

Consider the work that went into the first word processors and web browsers, whose work can now be mimicked by a Mac developer who knows how to embed NSTextView or or WebView. Imagine the time that early game developers invested in rudimentary sprite drawing, animation, and collision, which is now achieved easily in iOS games with open source packages such as cocos2d.

Still, building truly great software continues to elude most developers. It’s easy to assume that a large amount of time invested in a project, combined with an impressive outcome, is the key to a successful product. But it’s not so simple.

The ninety-ninety rule is often cited when describing the challenge of finessing a product after most of the hard work has seemingly been done:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” — Tom Cargill

I agree with this perspective, and I cite it often when discussing software with others. The rule as stated is in terms of “code” but is also applicable to all the visual design, user experience, marketing, and positioning of a product. I think the rule is also recursive: whatever is missing can always be split up such that an “easy” 90% of the job can be done, leaving an elusive 10% of finesse work.

Many developers mistakenly assume that after they’ve put a ton of work into a project, and it achieves some impressive feat, that their work is done. When you focus on the enormity of work completed thus far, it’s tempting to pat yourself on the back and call it a day.

But customers don’t care about the hard work that went into the 90%. They only notice the flaws or omissions in the 10%. Imagine if Michelangelo’s statue of David was perfect in every detail, except that where David’s face should be, a clump of ragged, unfinished marble lay crudely in its place. Instead of marveling at the exquisite details of David’s feet, torso, and arms, viewers would reject it as unfinished and clumsy.

An important takeaway for software developers is that the missing 10%, or the missing one-tenth of 10%, may be something that will take a great deal of work to get right, but it may be something you simply overlooked the importance of.

You might build an impressive skyscraper projecting 40 stories into the sky. The architecture, interior design, plumbing, and electrical work may all be superior to that of your peers. But if some blindness in your product vision prevents you from adding windows, the product will never sell. It doesn’t matter how much time or effort went into this masterpiece: nobody will live in a windowless skyscraper.

As a developer, the obvious upside to using Core Data is Apple’s powerful framework manages most of the nitty-gritty details of managing the … well, the data your app uses both in memory and on disk. But giving up precise control over the storage and mangement of this data also becomes maddening when you run into problems: you’re not directly responsible for the management, so you’re less likely to know exactly what is going wrong.

I ran into a problem recently having to do with versioning of core data model schemas, and how good a job the frameworks do or do not do of automatically updating existing data that a customer may have on disk. In recent years Apple has made it increasingly easy to make minor changes to your model schema and having the frameworks handle the migration easily. Apple calls this trivial technique lightweight migration, and when it works well, it works very well. To modify your existing data model, you just add a new “version” of your xcdatamodel file, and add a few options flags when creating your persistent store:

NSDictionary *options =
   [NSDictionary dictionaryWithObjectsAndKeys:
   [NSNumber numberWithBool:YES],
     NSMigratePersistentStoresAutomaticallyOption,
   [NSNumber numberWithBool:YES],
     NSInferMappingModelAutomaticallyOption, nil];

[myPSC addPersistentStoreWithType:NSSQLiteStoreType
   configuration:nil URL:storeUrl
   options:options error:&error];

This actually works quite well for simple addition or removal of entity attributes, but you might be forgiven for assuming its completely freaking broken if you run into a problem I did, having to do with a stale “.mom” file being left in the built application’s bundle in the iOS simulator and on iOS devices.

Essentially, if you’ve been building your project up to now with a single, unversioned xcdatamodel file, and you convert it to a versioned xcdatamodel file, it will start producing a new “.momd” file in your application bundle, and stop producing the older “.mom”. But because of a bug in the way Xcode installs the application binary in the simulator and devices, it will leave existing files from previous builds where they were in the bundle.

If, like many folks, you use the convenient [NSManagedObjectModel mergedModelFromBundles:nil] method to initialize your managed object model, this will, to use a technical term, bite you in the ass. The problem is Core Data looks at the .mom and the .momd files as equally viable, and attempts to merge them into some cohesive whole. When it discovers they both redundantly describe the same entities, it blows a gasket with a runtime error like “Can’t merge models with two different entities named ‘MyEntity’”

I did some googling around and discovered that the simplest solution is to simply delete the iOS app from the device or simulator, ensuring that the next time you install, you get a pristine, clean copy of the app without the troubling “.mom” file. But there’s a huge problem with that: in deleting the app you also delete its associated data files, and thus are left in a position where you aren’t actually testing the ability of Core Data to effectively migrate from your previously versioned data.

On the simulator, it’s no problem to dive in and trash the problematic, stale file. You can find the application binary somewhere in:

[Home] -> Library -> Application Support -> iTunes Simulator

Once you’ve deleted the “.mom” file you can test with your new model and everything hopefully works great.

On the device, it’s not as easy (I think) to get in there and do pinpoint editing of the application contents, but I still wanted to test my changes against the real data on my device. I was also starting to get paranoid about the possibility of an App Store update at some point also causing a stale “.mom” file to be left in an app bundle, and wreaking havoc. So the 100% safe solution to make sure the one-true “.momd” file is consulted when building the Core Data object model, is to point directly at it:

NSString *momdPath = [[NSBundle mainBundle]
	pathForResource:@"MyModel" ofType:@"momd"];

NSURL *momdURL = [NSURL fileURLWithPath:momdPath];

managedObjectModel = [[NSManagedObjectModel alloc]
	initWithContentsOfURL:momdURL];

Hopefully seeding this solution into my blog will make it available for folks searching on similar failures in their Core Data projects.

LaMarche offers a fairly balanced presentation of the two sides, but in my opinion he gives too much credibility to the argument that nil’ing is a good idea. He essentially embraces the argument that nil’ing the variables in production code is wise, because it might mask crashing bugs that would obviously vex the user:

Generally speaking, this is only going to happen if you’ve got a bug elsewhere in your code, but let’s face it, you may very well. Anyone who codes on the assumption that all of their code is perfect is begging for a smackdown.

And speaking specifically about the approach I prefer, leaving the instance variable alone and not bothering to nil it out:

On the other hand, that approach is really, really bad in a shipping application because you really don’t want to crash on your users if you can avoid it.

I disagree with the assertion that avoiding crashes at all costs in shipping code is the right priority. The biggest disservice you can do to your users is to allow them to run code that has unpredictable behavior. The whole point of programming is to make computers accomplish tasks in predictable ways. Sure, we all make mistakes as programmers, but giving in to the chaos and putting up safety nets “just in case” is not the right approach, especially considering it has unwanted consequences.

Consider that by masking the crash from occurring in the wild, you may be putting off detection of and resolution of the underlying bug indefinitely. But if your application has a crash reporter, or if you take advantage of Apple’s iOS crash reports, you will learn quickly that there are issues needing to be resolved.

It is reasonable to take steps that mask mysterious crashes, but this should only be done after you know there are actually crashes to prevent. Masking the symptoms in a blanket manner is akin to cutting half the phone lines in the neighborhood and celebrating the reduced number of 911 calls.

It’s also worth noting that LaMarche’s defense of nil’ing out instance variables hinges on the presumption that messaging nil is safe. True, messaging nil will not cause a crash. But is that safe? Not if it changes the behavior of your code in unpredictable ways. Consider this incredibly contrived Cocoa-based nuclear arms controller:

if ([mDiplomat didReturnGestureOfPeace] == NO)
{
 	[[NuclearWarehouse nuclearMissile] launch];
}

By LaMarche’s reasoning, it’s a good idea to nil out the mDiplomat variable on release, so that it won’t crash when you message it. But in this case, messaging nil for a BOOL result causes a logical flaw in the program, with obviously dire consequences. If the instance variable were not set to nil, it would probably crash before the launch message could ever be sent.

We should aim to comprehend what our software actually does. Deliberately decreasing the symptoms of problematic code won’t lead us any closer to that understanding. Ship the best code you have to your customers, and if it crashes, try to fix the root cause of the crash as quickly as possible. Don’t get in the habit of writing “hope this fixes it” code, and by all means don’t adopt that philosophy as a boilerplate coding habit.

Today I was so supremely frustrated by this that I played around with all manner of double-clicking, alternate modifier keys, etc., until I stumbled on the simple solution. Googling for answers after-the-fact revealed that I’m by no means the first person to discover this, but it’s quite possible I’m the first person who has told you!

To zoom in on an arbitrary point with the iPhone simulator:

1. Hold down the option key to obtain the familiar “simulation fingertips”.
2. Move the mouse until the fingertips are the desired “starting width” for your gesture.
3. Keeping the option key pressed, hold down the shift key to enter “panning” mode.
4. Move the mouse until the fingertips are at the desired starting position.
5. Remove the shift key while continuing to hold the option key.
6. Click and drag to zoom in or out at the selection location.

It’s a little cumbersome, but it’s about 1000% more useful than not being able to do it at all.

This functionality is based largely on the great work of the iMedia project, which was spearheaded by Karelia to replicate Apple’s own ubiquitous media browsing interface, some variant of which is available in Pages, iWeb, Mail, etc.

iMedia has been around for a while, but in the past year or more it has been undergoing a significant overhaul as its primary developers gear up to release the official 2.0 milestone. I have been involved in the 2.0 project for a long time now as an “early adopter,” using MarsEdit as a testing ground during the beta phase, and taking (mostly!) only the refined and polished aspects of the product for the final MarsEdit 3.0 release.

We are still ironing out some of the kinks, especially in parts of the project that were not tested in MarsEdit. One of the cool new features is support for the Flickr photo-sharing service. Like MarsEdit’s own Flickr-browser, it shows thumbnails of images on Flickr, and lets you treat them more-or-less like ordinary image files that you’d find on your computer.

Things get a little bit complicated when a user selects and drags one of these Flickr image thumbnails to another app, such as the Finder, or Photoshop. Since the image lives in the internet, and not on the local hard disk, it is not something that can be popped over to the application in an instant. Instead, a progress dialog comes up while the image is downloaded to the disk, and then the local copy is passed to the receiving application.

I try to contribute back when possible in the form of bug fixes and architectural feedback. Some of the work I did for iMedia 2.0 involved updating its drag-and-drop functionality to take advantage of new features in Mac OS X 10.6. In the process, I became a sort of de facto expert on handling dragging, which is a shame, because we could sure use a real expert, instead!

The other day, an issue came up that relates to the dragging of Flickr files. If the download is taking a while, and the user tries to cancel, mouse clicks are apparently ignored and they are stuck with the progress dialog above. I agreed to look into the issue, but there was just one problem: my network is too fast! Whenever I try to drag a Flickr image to another app, it’s done within a couple seconds, and I don’t have time to play around with clicking the cancel button.

If only I could get a really slow connection to Flickr, then I could easily test this. In the old days of Mac OS 9 or earlier, I may have resorted to plugging in a slow modem to simulate the experience of the less bandwidth-fortunate. In Mac OS X however, I can take advantage of the advanced firewall software that comes bundled with the operating system, and which allows me to configure “traffic shaping” policies on the traffic coming in and out of my computer. I found a great hint from Macworld that got me on the right track.

My goal is to cause Flickr downloads to be artificially slow. In order to achieve this goal I need to find the specific web address that the downloads come from. To do this, I use the standard tcpdump terminal utility, which also comes bundled with Mac OS X:

sudo tcpdump -Atqp -s 0 -ien1

The only part you may want to change is the bit at the end that says “en1″. Depending on the network interface you’re using, you might want en0 or en2 instead. With this running in the terminal, I go back to iMedia and start downloading Flickr files. This lets me see what the addresses of those files look like, and I discover the pertinent host name is “farm5.static.flickr.com”. Using the information I gleaned from the Macworld article, I set up the following firewall traffic shaping rules:

sudo ipfw pipe 1 config bw 15KByte/s
sudo ipfw add 1 pipe 1 src-port 80 src-ip farm5.static.flickr.com

Translation?

1. Create a pipe (you might prefer to call it a “tube”). A pipe is an artificial pass-through which can be configured to slow down, block, or otherwise alter the network traffic that goes through it.
2. Configure the pipe to limit bandwidth to a crawling 15KByte/s.
3. Configure all traffic coming from port 80 (the standard HTTP port), and originating from a specific hostname at Flickr, to pass through that pipe.

As soon as these commands are executed, the pipe is in place, and Flickr download speeds are brought to screeching halt. I can now debug the issue with the download dialog and the cancel button patiently and curiously, instead of racing to try clicking the button while I still have the chance.

When I’m done debugging, I definitely want to delete the pipe, so that download speeds go back to normal:

sudo ipfw delete 1

Mucking around with the built-in firewall on Mac OS X is not for the extremely faint-of-heart. This is why all the commands listed in this entry require “sudo” superuser privileges. Yes, you could seriously screw up your computer’s network connection if you do something wrong. But if you are the type of person whose work requires you to test and debug network related tasks, this traffic shaping functionality can be a real asset when it comes to mimicking the network environments of other people.

Addendum: I should have known I might be doing it the hard way, as usual. Clint Ecker reported on Twitter, and several folks in the comments below, that speedlimit, a Mac OS X preference pane, gets the job done in a much friendlier manner.

Unfortunately, this seemingly minor update presented a major failure in my debug builds, which I’m adventurously compiling using the LLVM clang compiler. They built fine with Xcode 3.2.2, but starting in 3.2.3, I got a linkage failure, tracing back to the popular open source RegExKitLite:

Undefined symbols:
  "___gxx_personality_v0", referenced from:
      _rkl_debugCacheSpinLock in RegexKitLite.o
      ...
  "__ZSt9terminatev", referenced from:
      +[NSString(RegexKitLiteAdditions) clearStringCache]
      in RegexKitLite.o

What? Those symbols smack of C++, but there isn’t any C++ code in my project. At least, I don’t think there is. RegExKitLite is so famously advanced in its designed, I couldn’t easily tell you whether there was stuff in there intended as C++ or not. On a whim, I tried to switch the file type to C++ to see if that made clang any happier. No, it screamed bloody murder. It agrees with me, RegExKitLite is not C++ code.

So why the link errors? I examined the compile line carefully for RegExKitLite and confirmed that it’s using clang in a manner that should only be generating plain C linkage:

/Developer/usr/bin/clang -x objective-c -arch x86_64 ...

But when I look at the resulting RegExKitLite.o with the “nm” command-line tool, it shows the culprits symbols have been listed as references in the binary object file:

% nm RegexKitLite.o | grep -e terminate\\\|personality
                 U __ZSt9terminatev
                 U ___gxx_personality_v0

Normally when I’m getting some kind of issue like this, I just type in the problematic symbols in to Google and usually find somebody else has found and solved the problem. No such luck this time. There are lots of false positives for the typical reason somebody runs into this link error: they are compiling legitimate C++ code but neglecting to link with the stdc++ library. But in our case, we are not compiling C++ code, but we’re ending up with C++ dependencies nonetheless.

I hopped on to the #clang IRC channel on irc.oftc.net, where a couple extremely helpful clang engineers (thanks to dgregor and rjmccall) helped talk me through the problem, and determine that it does seem to be a clang 1.5 bug. They confirmed that with their latest and greatest clang the bug seems to be fixed, but I was curious to confirm it myself, so I checked out and built the latest clang, too. Sure enough, all is well for future generations!

But what do we do now, stuck with the clang 1.5 that ships with Xcode? There is a crude workaround: simply link to stdc++. But yuck! All that C++ linkage dirtying up my pristine Objective-C project? Since I only use clang (for now) to build debug builds, I don’t have too much of a problem doing this. But if I was shipping these binaries I would be very hesitant to make that concession.

Radar #8230225: clang 1.5 forces linkage to C++ for non-C++ source file
(Open Radar Link)

The best we can do is report the issue to Apple and let them decide whether it’s worth their time to backport whatever fix in later clang is missing from clang 1.5. If you have other suggestions for how to work around the problem in the mean time, please do chime in with a comment below.

Update: The author of RegExKitLite kindly chimed in below with a pointer to the revision in the clang source repository that that fixes the issue. He also suggests a simple, and seemingly safe workaround, involving a slight tweak to the RegExKitLite source code.

“Every time I press cmd-N to create a new document and start typing, instead of accepting the text, it just beeps at me.”

This seems impossible to me. Creating a new document and typing into it is fundamental to my product. Surely if it was broken I would know from my own daily testing of the application. I try diligently to reproduce it, but of course, I can’t. Create a new document. Start typing. Everything works, everybody’s happy. Except the person who reported the bug.

At some point in my tinkering I stumble upon the bug. Beep. I can’t type. There it is! What a drag. This application sucks!

Now that I’ve seen and heard the bug with my own eyes, I’m more committed than ever to fixing it. But how on earth did I do it? I try several more times and am unable to reproduce the problem.

I have only spotted the issue once in my dozens of trials, yet the customer claims it affects him every single time. What explains this? Maybe it simply doesn’t happen as often on my Mac as it does on his. My thoughts turn to the brute force of AppleScript. If this happens only once in a blue moon on my Mac, surely I can reproduce it by running a script that iterates the test conditions hundreds or thousands of times. I open AppleScript Editor and enter the following:

tell application "System Events"
	repeat 100 times
		keystroke "n" using command down
		keystroke "Testing typing"
	end repeat
end tell

Nothing! Even after running it 1000 times, nothing. How can this be? How could something so common for the customer, something that I saw myself once, be so difficult to reproduce on my Mac?

After playing around a bit more, I started to reproduce it more readily. What was happening? I couldn’t figure it out, but something “felt” a little different when I reproduced it. I thought carefully about the parameters of the bug, as exemplified (I thought) by my script:

1. The command key is pressed.
2. The N key is pressed.
3. The N key is released.
4. The command key is released.
5. Typing into the new document is attempted.

I looked again at the script. Perhaps this “keystroke” command is not literal enough. For all I know it’s circumventing the normal key events that get generated when you type on the keyboard. On a lark, I modified the script to be more explicit:

tell application "System Events"
	repeat 100 times
		key down {command}
		key down  "n"
		key up "n"
		key up {command}
		key down "x"
		key up "x"
	end repeat
end tell

Here we have a more literal match with my analysis of what happens. Hold down the command key, press the N key, release, then type something. In this case I just type an x character because I figure any typing is enough to trigger the bug.

I ran this 100 times as well and no luck. The bug is simply not reproducible through scripting. I guess I’ll have to figure out what conditions are making it more likely for the customer to run into the bug. Maybe he has some 3rd party software that is interfering. Or … wait a minute.

tell application "System Events"
	repeat 100 times
		key down {command}
		key down  "n"
		key up {command}
		key up "n"
		key down "x"
		key up "x"
	end repeat
end tell

I ran the modified script and the bug immediately exhibited itself. So what changed? Look carefully and you’ll see that my previous script assumed that when a keyboard shortcut is pressed, there is a sort of nested symmetry to the order of pressing and releasing the keys. When I press keyboard shortcuts, I hold the modifier keys down throughout the stroke, and release only after the letter key has been released. But this customer has muscle memory that inclines him to instead release the keys in the order they were pressed. When he releases the N key, the command key has “long” since been released.

This subtle difference turns out to trigger a bug in my event monitoring code that, to make a long story short, robs first responder status from the default view in the document. So when he creates a new document, there is no first responder, and his typing just causes a bunch of beeps. When I create a new document, there’s always a first responder, so I don’t see the bug.

As difficult as this bug was to track down, it would have been near impossible without the theory testing, disproving, and ultimately proving tool of using AppleScript and System Events to zero on in the behavior. Sometimes when the steps a customer provides to reproduce a bug seem exactly the same as what you’re doing, you’re just not trying hard enough to find the difference.

I am always feeling overwhelmed and helpless when it comes to localization. The tools at our disposal don’t make it easy enough to “do it perfectly,” so I end up (for the most part) not offering localizations at all.

Maybe I should give in and adopt Wil’s strategy of essentially providing a UI that fits all languages. Unwanted white space be damned!

“Classic computer programming has largely failed, because it failed to copy nature. Nothing in nature works 100% of the time, but it sure works well MOST of the time – and when it fails, well, you die and get replaced. A human being, for instance, is an absolutely amazing machine, and is provably NOT provably correct.”

I particularly like the example in the second half, having to do with smartly interpreting a typed ISBN numbers for product search. How do you strip the meaningless dashes from a search term, except when they’re utterly meaningful? This kind of thinking is important to fine-tuning an application. Nobody will appreciate the hours you spent laboring over the question, but for some reason they’ll just think your product is particularly awesome.

It’s interesting that the pursuit of perfection in an application has to involve the pursuit of compromise. By solving a problem in a way that degrades gracefully to unsolvable, you offer a happy, possibly even surprise solution to many people who would not otherwise expect one.