Google’s “Meaning of Open”

John Gruber:

Basically, he’s spewed 4,000 words to say that “open” is always good and always wins, Google is always open, therefore Google is always good and will always win. And please don’t worry your pretty little minds about things like Google’s search or ad algorithms or the specific details of how its data centers work, all of which things Google could not possibly be more secretive about.

Yup.

LaunchCodes 1.0

LaunchCodes (via Matt Deatherage) is a clever utility that tries to restore the creator code functionality that Apple removed in Snow Leopard. It sort of does for files what Choosy does for URLs, acting as a trampoline to receive opened files and redirect them to the proper application. The basic functionality seems to work, but I ran into a few problems:

1. It doesn’t pass along Apple events. For example, if you find a PDF file using Spotlight or EagleFiler and open it, the query should be passed along to the PDF viewer so that it can search within the file. This stops working when you enable LaunchCodes.
2. Some of my creatorless files now display in the Finder with generic white document icons.
3. Applications can no longer tell which application would be used to open a file. For example, when you select an HTML file in EagleFiler, one of the menu commands will say “Open With Safari” and show the Safari icon, and if you select a PDF file it will say “Open With Preview.” Once you enable LaunchCodes, you’ll see “Open With LaunchCodes” and the LaunchCodes icon, which is not very informative.
4. It doesn’t handle extensionless files. For example, if TextEdit is your default text application and you double-click a Makefile with creator code 'R*ch', it will open in TextEdit rather than BBEdit.

(1) seems like a bug that could be fixed. I’m not sure what’s going on with (2); it may be unavoidable since LaunchCodes doesn’t declare any icons for the file types that it handles. Unfortunately, (3) and (4) are probably not fixable given the way LaunchCodes works.

A Sample Mac Application With Complete Unit Tests

Matt Gallagher demonstrates using OCMock to develop a Cocoa application test-first. I’m skeptical about relying so much on mocks, but it’s good to see a complete example project.

How Success Killed Duke Nukem

Wired tells the story of Duke Nukem Forever:

It’s a dilemma all artists confront, of course. When do you stop creating and send your work out to face the public? Plenty of Hollywood directors have delayed for months, dithering in the editing room. But in videogames, the problem is particularly acute, because the longer you delay, the more genuinely antiquated your product begins to look—and the more likely it is that you’ll need to rip things down and start again. All game designers know this, so they pick a point to stop improving—to “lock the game down”—and then spend a frantic year polishing. But Broussard never seemed willing to do that.

HTML5’s <video> autobuffer Attribute

John Gruber:

A big part of the appeal of the <video> and <audio> elements is that they should be easier to use. As it stands today, though, these elements are unusable in popular contexts without resorting to JavaScript DOM manipulation to effectively turn auto-buffering off.