Weaponized Fluff

I had fun this year.

I missed David Pogue’s keynote, though I saw a few snippets from the tape and they looked funny. Steve Hayman, from Apple, did the second night’s presentation, and he was hilarious. He was subbing for Jordan Hubbard, who was having his own “personal denial of service attack” (he was sick).

To my surprise, I co-won Best Paper, which means I get to go there next year with no registration fee. I got to go this year the same way by writing the paper in the first place.

The conference had noticeably fewer attendees this year. Per my sources, maybe half the number from last time around. Otherwise, it seemed mostly unchanged.

People still called the hack contest “the hack contest,” even though officially it had a new name – even the conference organizers had to correct each other.

19 hacks this year. In my impression, the hacks didn’t have the same technical wow factor as previously. There was nothing, for example, like Quinn’s FireStarter from 2002.

Still, I had fun, and the organizers called this year a success.

Would I mind seeing the conference do things dramatically different next year? Nope. Shinkage without change isn’t a strategy you can continue indefinitely. New location? Different format? Merge with another conference? Dunno. If I had any big ideas, I suppose I would’ve volunteered to help run things next year. Since I don’t, I will merely wish next year’s organizing committee the best of luck.

I was unable to demonstrate my Xcode projects today at my ADHOC presentation. They produced an obscure error when building.

Why?

Not because I’d moved the project, or renamed the project or its enclosing folder. Xcode can handle that.

It was because I’d renamed the enclosing folder to contain a comma.

I remember when Project Builder location paths couldn’t contain a space.

This is probably a similar issue having to do with the underlying, Unix-based technologies (i.e. gcc).

I wonder if the fix will involve merely putting in a few more quotes around command-line options, or if it would require deeper surgery.

Though the title of this post might sound like a pornographic spam, it actually refers to a hypothetical situation.

I thought of it in response to a comment to my last post; Jon Johnson talks about what would happen with the password-changing utility if someone got a hold of your laptop.

This got me thinking. Mac OS X 10.3 “Panther” provides you with the possibility of encrypting your Home directory. This directory is unencrypted magically for you when you log in, and then encrypted again when you log out. That’s probably a simplification, but it’ll do for now.

The idea behind this feature is that if somebody steals your laptop, and you’ve logged out, they don’t automatically get access to your files, because they’re encrypted on disk. BUT if getting access to those encrypted files is as easy as runnning a startup CD/DVD utility, then the feature doesn’t help very much, does it?

My question is this: if I change the password with the utility, will it decrypt the HD when I log in with the new password, or is the HD still encrypted with the old password?

I am not about to try this at home with my laptop, which is why I called it a “hypothetical” scenario above. I would, however, be interested in the result of someone else trying it.

Any takers?

You know that little aside I made in this post, about how helpful it can be to reset your computer password from your install CD/DVD?

Welllll…that’s not the end of the story.

I found that that same password I couldn’t remember for my computer had been embedded – separately – in my default “login” keychain. I couldn’t add anything to that keychain or change anything about it, including the password, even after I reset my computer password!

The solution was to delete the keychain and all the data associated with it, and then reset my keychains to their default state with the new password. Could have been a real pain, if I’d had a lot of entries for that keychain. I didn’t, so I was lucky.

Just an FYI.

Have you seen the trailer for Jerry Seinfeld’s movie Comedian? It skewers the deep, ominous voiceovers of Hollywood blockbuster trailers by showing what seems like a real movie announcer in his recording booth.

But the person behind the scenes is no laughing matter (sorry!) for the purpose I talked about in my last post: finding a comments format that had a worthwhile translator into documentation.

I was planning on spending some time trying to track down the HeaderDoc implementors, to find out the status of the project and maybe some answers to the puzzles I’ve discovered, but Wolf’s comment about Doxygen got me thinking along different lines.

In general, I think a sense of ownership really matters, and it’s easier for one person, the initial author, to own a project. Doxygen is the project of “one man,” Dimitri van Heesch, and it does seem to have momentum and a much more active mailing list.

I’m still planning on finding out more about HeaderDoc, but I’ll probably try Doxygen first.

Can I just exchange one for another? Is it just an implementation detail? I’ve found that most implementations aren’t interchangeable, and any significant project design does require knowledge of how it’s going to be implemented, even if just the bare outlines, to succeed. This is why I’m chasing after implementation first.

Will it be enough, in a world gone mad, to keep me happy?

I’ll let you know.

Good code comments are an art form.

Even art needs structure, though, and I had hoped that HeaderDoc would provide me a ready-made structure for comments when they’re needed, with the promise of generating useful documentation later.

Testing the second part is what the rest of this post is about.

I downloaded HeaderDoc via its main page on Apple’s Web site, http://developer.apple.com/darwin/projects/headerdoc/, and tried to follow the instructions in the included README file to install it.

Problem: typing in the indicated sudo make realinstall gives me an error. Well, OK, first it doesn’t work because I forgot my computer’s password. Tip: your install CD/DVD can reset your password. Extremely convenient. Second, it gives me an error because I don’t have make installed. So I go to http://connect.apple.com, download Xcode 1.2, and install it. This also installs what I assumed was an older version of HeaderDoc, version 2.1. So the next time you’re trying to download all those segments of an Xcode install, blame a tiny smidgen of the bloat on HeaderDoc.

The real error is that there’s no file xml2man in the folder called xmlman/ inside the install package. There’s a makefile there, though, so I run it, run the command from above again, and it works. A post on the headerdoc-development mailing list describes this exact problem. How could a major release have been made without realizing this was a problem?

The package I downloaded is called, and all the documentation says, 8.0, but version of the headerdoc2html utility installed by “8.0” is 2.1, just like the version I installed with Xcode 1.2. I must admit, version 8.0 of anything seems a bit dodgy these days. Things tend not to get up to that version number before being renamed, re-branded, etc.

There are more things that confuse me. The documentation states that comments can be embedded in “source code and header files.” I also remember reading a message on the headerdoc-development mailing list to the same effect, though I can’t find that message again now.

But the utility only seems to accept *.h files and directories, not *.m files. This certainly implies that comments in *.m files are ignored, and that’s been my impression from the tests I’ve run. This is a bit disappointing, since there are times when you want additional comments in the source code file, and I’d rather they weren’t lost.

Also, the documentation talks about “tagless syntax,” the ability to put a HeaderDoc tag in front of a function or method without needing to include a @function or @method tag in the comment. This would be good: computers don’t mistype, unlike humans. But I didn’t find this to work with comments for Objective-C methods. If I didn’t include the @method tag, then the method didn’t show up in the documentation.

These sorts of issues give me the impression that if I use HeaderDoc syntax in my source code comments, it should be merely because I like the syntax, not because HeaderDoc at this point suits my documentation workflow.

I’d be curious to hear about other people’s experiences.