This is probably going to go down in history as my least profound post ever, and I apologize in advance, but I found this signage bizarre and somewhat amusing.
It reminds me of that “Fawlty Towers” episode where Basil is staging a fire drill, and he argues with his hotel guests over which alarm is actually the fire alarm (“it’s at least a semitone higher!”).
Anyway, now back to the regularly scheduled program of non-stop profundity…
I always know something is creating a sensation in movie geekdom when not one, but both of my movie geek friends forward me the same article (thanks Josh and Michael!). In the case of their most recent messages, though, I can certainly understand what all the hubub is about. It seems Darren Aranofsky, the man behind one of my favorite movies, Requiem for a Dream, has been tapped to direct the long-awaited film adaptation of Alan Moore’s seminal graphic novel, Watchmen!
The more I think about this choice, the more I think it makes sense. Aranofsky’s dark style (see Pi, for example) makes him the perfect man to bring Rorschach to the screen, and his track record of brilliant filmmaking alleviates the fears of Hollywood ham-handedness I expressed the last time I wrote about Watchmen. Here’s hoping that Aranofsky can save Watchmen from League of Extraordinary Gentlemen’s fate!
Reading through the previous week’s accumulated email this morning, I came across a message from my friend Josh bringing tidings of a Watchmen movie in the works. If this is true, and the filmmakers don’t utterly screw it up, this is exciting news indeed!
In my opinion, anyone who thinks the medium of comics is fundamentally immature or incapable of rising to the level of “literature” should give Watchmen, or, for that matter, a whole lot of other stuff by its author—British comics genius Alan Moore—a read.
Moore, whose gifts are so great that DC Comics editors reportedly “scoured” his office for scraps of paper containing his ideas after he split from the company in 1989, was among the first to really push the boundaries of genre comics. Watchmen, which is widely considered his magnum opus (except by me—I would give that honor to From Hell) is a groundbreaking deconstruction of the superhero genre and, by way of a clever story-within-a-story, the comics medium itself. It’s one of those thrilling pieces of art that make you giddy just to contemplate the profusion of ideas that seem to be flowing effortlessly from the author’s mind.
So far the movies based on Moore’s books have been a mixed bag. From Hell departed fairly significantly from its source—although, to be fair, it would have had to due to the book’s length, and I think the filmmakers still captured the essential spirit of the original. League of Extraordinary Gentlemen, on the other hand, absolutely bears the indignity of having been “messed with” by Hollywood. I still haven’t gotten around to seeing it, admittedly, but the casting of Sean Connery (who is not nearly haggard enough to play Moore’s Allan Quartermain), the addition of an American-pandering Tom Sawyer character, the Vin Diesel-esque “LXG” acronym used in advertising, and a round of terrible reviews were enough to render it DOA for me.
Hopefully the people in charge of making Watchmen will take their cues from Peter Jackson and approach the material very carefully and respectfully (I can already think of certain aspects of the story—such as the Tales of the Black Freighter comic-within-a-comic—that will be difficult to adapt to screen). Moore fans can forgive the mangling of “LXG,” which is still a relatively minor work in the Moore canon, but marring the legacy of Watchmen with a botched movie would be a real tragedy.
I don’t normally comment too much about non-Cocoa-yet-Apple-related things here, for reasons I’ve outlined before, but a recent post of John Gruber’s pointed me to Jeffrey Zeldman’s story about his disastrous upgrade to Panther, and I find it very difficult not to comment on it. Before I do, though, I have to issue a common sense disclaimer: these opinions are mine and mine alone.
Now, I sympathize with Zeldman. I’m always crushed to hear about someone having a bad experience with OS X, and I more or less agree with his “modest suggestions.” What I want to discuss, though, is what makes his case so exceptional.
To the casual reader, Zeldman’s narrative makes OS X sound like a ticking time bomb, a precarious piece of work ready to come completely unhinged because of a mere software update. His problems—non-launching apps, kernel panics, and other assorted mayhem—would seem to be too obvious for Apple not to catch. As Zeldman says:
A simple OS upgrade should not fail, should not induce panic, and should not waste three days of a user’s life.
So how is it that such anarchy could have been loosed upon the world?
The answer has a lot to do with the actual cause of most of Zeldman’s problems (the more subtle 10.3.3 printer issues that Gruber mentions being an exception), to which he alludes only briefly when he mentions that he was running several third party “system add-ons,” or what are more colloquialy known as “haxies.”
Haxies are fun because they do the seemingly impossible: they magically modify “closed source” software to do things it was never intended to do. Don’t like a standard OS X dialog? Change it! Prefer pink vinyl Finder windows to metal? A little hacking, and your dream can be a reality!
Unfortunately, there’s a reason these nifty OS modifications are called haxies: because they’re hacks. Unlike normal software, which uses the system in publicly documented ways that Apple guarantees to work from release to release, haxies often go rooting around under the hood, rewiring things and generally operating at a level that could best be described as “daring.”
The problem comes when things under the hood change in ways that the haxie author might not have anticipated (say, because of a major OS update), but the haxie goes on trying to rewire things the way it always has. If things go sufficiently wrong, this can result in any application that depends on that “wiring” crashing. Since modern operating systems are built with layers of reusable code, a haxie that causes such problems at a low enough level can make its ill effects felt across the entire system. This is why Zeldman experienced not one, but a plethora of crashing apps.
My point in explaining this is not necessarily to dissuade people from using OS mods, or to dissuade developers from creating them. I appreciate good hacks as much as the next guy, and I have respect for the clever people who pull them off. However, I would argue that becoming the kind of person who “mods” his OS is a lot like becoming the kind of person who “mods” his car: it demands more of an awareness about what you’re doing to the machine, a more active involvement in its maintenance, a certain tolerance for potential downtime, and an understanding that Honda (or Apple, as it were) is not necessarily to be blamed if something goes wrong.
This is not to say that all of the responsibility should be laid at the user’s feet, though. In fact, in my opinion, haxie authors have a much greater obligation to ensure their users’ well-being than developers of conventional software. I think a great example of a developer who understands this and practices “responsible hacking” is Panic, with their CandyBar app. Rather than allowing CandyBar to blindly assume it will function properly in future OS versions, Panic restricts each version of CandyBar such that it will only work on OS versions up to the latest one at the time of release. Meanwhile, Panic tracks upcoming OS X releases through developer seeds, and only releases an update once it has been adequately tested with the new OS update.
So, then, I guess an additional lesson of Zeldman’s Good Friday disaster, from my perspective, might be this: let the user beware, and let the hax0r be responsible!
If you write software for Mac OS X, and you’ve ever needed to do interapplication communication, chances are you’ve waded at least a little bit into the murky waters of AppleEvents. If your task involved getting another application to do anything remotely complicated, however, you probably decided fairly quickly that constructing whole hierarchies of raw AppleEvent descriptors is for the birds, and that there is a much nicer, high level interface to the AppleEvents infrastructure: AppleScript.
Cocoa has had simple support for programmatically executing AppleScripts since Jaguar, in the form of NSAppleScript. Unfortunately, though, NSAppleScript’s usefulness in the scenario I’ve described is somewhat limited, since it only provides support for executing an entire AppleScript from start to finish, without any way of passing arguments.
A preferable solution would allow the Cocoa programmer to call a specific handler within the AppleScript, almost as if it was a normal function call. This would allow essentially all of the interapplication communication code to be implemented in AppleScript and encapsulated within the handler, and the data being sent to the other application provided through the handler’s parameters.
Fortunately, while Cocoa may not provide this facility directly, it does at least provide the raw tools to make it happen. After a lot of trial and error, I managed to distill the necessary magic into a relatively straightforward NSAppleScript category with a single method:
- (NSAppleEventDescriptor *) callHandler: (NSString *) handler withArguments: (NSAppleEventDescriptor *) arguments errorInfo: (NSDictionary **) errorInfo;
The first parameter is simply the name of the handler to be called. The second is an AppleEvent descriptor containing the arguments. The third is an NSDictionary reference that will point to error information in the event that something goes wrong. The method returns an AppleEvent descriptor containing the handler’s return value.
The high level outline for how to use this category in your own code is as follows:
All of this is illustrated and explained in more detail in an Xcode project I have posted (disclaimer: the code is provided under a Creative Commons License, and represents my own late night hacking—not some sort of officially endorsed code sample from my employer or anything like that :-)):
- ASHandlerTest.dmg (27k)
Enjoy, and let me know if anyone has any interesting feedback (it’s amazing how much I end up learning from other people when I post code on this site!).
(Update: The ever vigilant Michael Tsai pointed out that I had a misplaced “release” in the earlier version of this code (I copied the category code from a larger, non-category method I originally wrote and forgot to get rid of the “release” of an object that is now passed in as an argument). The code is fixed now.
Some time ago, I mentioned my little brother, Bobby, and his icon design work. Well, thanks to that post and its readers, Bobby has had a small but steady stream of icon commissions coming in from various Mac and web developers for awhile now (massive thanks to everyone who has expressed interest or referred him to others, by the way). What’s more, he recently managed a very respectable showing in the IconFactory’s Pixelpalooza “People’s Choice” voting with his Bathroom Items set (seventh out of approximately 60 entries). Not bad for a high school student!
Now Bobby’s hoping to take things up a notch by setting up a website to showcase his growing portfolio and (probably more interestingly to the average reader of this weblog) get into the business of selling stock toolbar icons. The latter can be purchased either as a full set (for $99) or individually (for the low, low price of $3). I imagine that the individual option might appeal particularly to a lot of smaller shareware or freeware developers who find themselves in perpetual need of toolbar icons but lacking the funds to commission them. If you fit that description (or even if you don’t), be sure to give Bobby’s stuff a look.
I spent Easter back home in Denver (yes, I still do—and probably always will—think of Denver as home). Regrettably, I failed to take any photos (despite the onset of a fairly impressive spring snowstorm on Sunday night) but I am nonetheless sufficiently moved by the experience to put down a few random weblog notes on the flight home.
Anyone interested in attending the weblogger meetup I’m organizing for WWDC should take note of the event’s new web page. It currently contains a list of people who’ve expressed interest in attending (with URLs), a map to the restaurant, and links to possible related activities.
Some additional administrivia:
It looks like the consensus is more or less for having the event at The Thirsty Bear. The only problem is that, at this point, we’ve got kind of an awkward number of people: potentially 15+. This seems like too many for “normal” seating, but unfortunately banquets get rather expensive. I guess I’ll have to call to see what our options are.
As the web page suggests, we still need to set a date and time. Unfortunately, Apple hasn’t announced much about the schedule for WWDC 2004, so it’s hard to know if we would be conflicting with something. If we go by last year’s schedule, though, the biggest lulls seem to be on Wednesday and Friday (Monday had an ADC reception, Tuesday had the Apple Design Awards, Thursday had the Campus Bash). On the other hand, I do agree with the people who suggested it might be better to meet up earlier in the week, so people know each other during the rest of the conference, so maybe it would be better to try for Monday, Tuesday, or even the Sunday evening everyone will likely be arriving?
I’m definitely open to suggestions on this, so let me know what would work best for everyone.
Though we have more or less decided against the Giants/A’s game as our venue for a variety of reasons, that certainly doesn’t mean people can’t get together and go. If you’re interested in attending, Justin Williams is organizing a trip, so be sure to let him know.
Michael McCracken has some other suggestions for other interesting activities people might want to participate in at WWDC.
Since the response to my last desktop photo post was very positive, I’ve decided to follow it up with a view of Edinburgh from the castle, looking over Princes Street toward the Firth of Forth. I took this photo during my New Years trip to Scotland, and it has been a favorite in my desktop rotation ever since.
Like the last one, I am providing this one in standard 1280×1024, 15” PowerBook-style 1280×854, and 17” PowerBook-style 1440×900. A Creative Commons license applies.
The response to my proposal for a WWDC weblogger meetup has been good: so far we have ten intrepid souls in. The actual activities remains a bit uncertain at this point, but Michael McCracken made an interesting suggestion I hadn’t thought of: we could attend the San Francisco vs. Oakland game at SBC Park on July 2 (which, as it turns out, is fireworks night at the park).
This idea brings up an important question, though: how long does everyone plan to stick around? I agree that July 2 would be a good date since it wouldn’t conflict with any of Apple’s offical events, but I know a lot of people don’t plan to stay that long.
The idea of leaving the immediate vicinity of the Moscone Center (whether for a ball game, barbecue, or whatever) also introduces some transportation issues, but I agree with Michael that either we locals or public transportation could probably solve our problem there.
So, then, what does everyone think? Dinner and baseball? Just dinner? Just baseball? Or should we pursue the picnic/barbecue format (perhaps somewhere like Baker Beach, with its excellent Golden Gate Bridge vantage and picnic facilities)?
(Update: I just discussed this with one prospective attendee who made some excellent points about the merits of keeping this informal, flexible and close to Moscone. As this person pointed out, peoples’ schedules can change a lot over time, and it would probably be best, in terms of ensuring that everyone who wants to can particpate, to make sure this event is one where people can easily come and go as they want or need to.
This being the case, I have to say that the Thirsty Bear, an excellent restaurant right next to Moscone, is once again sounding like a solid choice.)
