January 2005 – Weaponized Fluff

I Think I Myst Again

What have I been doing with all this free time I accumulate by not writing weblog entries for weeks and weeks?

Playing Myst IV, of course!

I won’t be the first person to talk about its interface flaws, but talk I will:

1. No access to regular application menu. This means going through their clunky custom interface to open and save games and bring up preferences. This has gotten worse since previous Mysts.

2. Purty, but clunky “camera” interface. No Undo/Redo for deleting pictures. Ouch! And who needs full-motion transitions just to look at a damn picture! Why do I have to move the mouse, with difficulty, in a circle to switch pictures? Forward and back arrows, hello?!? I love being able to take pictures, but the interface is horrible.

3. Degraded zip mode. Before, you could hover your arrow on a distant location, and if you could “zip” there, it became a lightning bolt. Now, instead, you have to pick a new location from a tiny tiny strip of limited, obscure location pictures. You have to memorize what miniscule image goes with what location, and click the tiny tiny scroll arrows if the list of such images is over 4 or so. In theory, this could be better than the lightning bolt, because it lets you go anywhere. In practice….

4. No automapping. Why doesn’t any game map for me as I go? I spend hours tracing everything out to make a coherent map, guessing whether a gentle turn means 90 degrees or maybe just 45 degrees, hoping the damn paths all link up in the right places when I’m done. I can’t use my own graphics program to help, because Myst takes up the whole damn screen! Is the exact layout of all the locations a state secret? No? Then why act like it! And annotate the map, too. I don’t want obscure florid icons where I have to make a second map just to describe what the in-game map really means.

Those rants may lead you to believe I hate Myst IV, but in fact I’m enjoying playing it. The continued greater and greater use of motion in each successive Myst is a lot of fun. Not particularly realistic, but fun. And the art and music are always great. The acting somehow never seems to improve, but it’s no worse than your average Sci Fi Channel show.

I’m not done, so no spoilers in the comments!

Not in Session

The reason, in my previous post, that my Audible link wasn’t a direct link to a search on Douglas Adams titles, is because of the downside of sessions.

This post will seem like child’s play for those of you already in the Web site programming business, but here goes:

You know the difference between dynamic and static content, right?

Static content means you receive exactly the Web page that’s on the server’s file system. The Web page never varies regardless of who asks for it.

Dynamic content means some or all of the information you see comes from other sources, usually big ol’ databases, and that information is used to construct the page right when you ask for it.

Examples of dynamic content include: a Yahoo! email account, Amazon.com, a dot-Mac account, etc.

Some of the most interesting kinds of dynamic content require you to have an account with the Web site, where it stores your identity, your preferences, your history, etc. on the server.

The idea of a session has to do with how they know that the you of the account is indeed the you requesting the Web page, from one page to the next. Unaided HTTP is stateless. If you request two pages in a row, the Web server doesn’t have any idea that the same person requested both.

There are at least two ways to make that connection. One involves storing information with the client (i.e. you). This is done with cookies that are sent to your browser and which your browser stores and makes available to the Web server. This way, the Web server doesn’t have remember anything special from page to page – it asks you who you are each time.

But this can lead to problems. What if you don’t have cookies turned on? What if you delete one of them? What if the information is particularly sensitive, like a credit card number, which you would rather not leave unprotected on the user’s computer?

A more robust solution, used by application servers like WebObjects and BroadVision, is to create a collection of information called a session on the server side the very first time a user shows up. The only thing the user has to tell the Web server each time she requests a page is the ID of that session.

That session information takes up space on the server, space that can add up for thousands of users, millions of users over time. Remember: stateless. Being a Web surfer means never having to say goodbye.

Application servers get around this by having sessions expire. If you haven’t asked for a new page within a certain time limit, then that session ID becomes invalid, its information thrown out, and if you ask for a page after that, you get the dreaded “Your session has expired” message.

Recap: (1) Session aren’t eternal. (2) Session IDs are needed to access the dynamic content of sites like Audible and Yahoo!. So I can’t give you a URL for Audible content, because I can’t give you an accompanying session ID that will be guaranteed to be valid by the time you want to use it.

So if you use WebObjects for your Web site, you can never give out static URLs? Well, not quite, but this post is long enough already, so I’ll talk about it next time.

Psst!

I wasn’t supposed to make this public, but…I can’t help myself. It’s just too exciting.

The rumor about a headless iMac are in the right ballpark, but they go in the wrong direction.

Instead of a headless iMac, what Apple will announce at MacWorld San Francisco in a few days is a two-headed iMac.

It will be called the iMac Zaphod Beeblebrox Special Edition, and instead of the normal iMac silver and white colors, it will be black with green trim. It will be bundled with all seven Audible.com Hitchhiker’s Guide to the Galaxy titles, the Hitchhiker’s Guide to the Galaxy text adventure game from Infocom, and two tickets to the Hitchhiker’s Guide to the Galaxy upcoming movie.

Instead of the usual startup sound, whenever you turn on an iMac Zaphod Beeblebrox Special Edition, you will hear a cheery voice say, “Don’t Panic!”

Oh, and they got the price wrong, too.

Instead of retailing for five hundred dollars, this special computer will sell for five thousand dollars. I can’t guarantee I have this completely correct, but from what I hear, they figured that anyone who is excited by the above specifications is probably not from this planet anyway, and would be a bit fuzzy on the earthly exchange rate.

You heard it here first!

Subversion Perversion: Switching from Berkeley DB to FSFS

Warning! Warning!

I’ve spoken to two developers I know about my Subversion repository, and the reaction from both of them was:

You’re using the filesystem version, not the Berkeley DB version, right?

But while the first developer (hi, Wolf!) couldn’t give me a good reason not to use the default Berkeley DB version, which per the manual is better tested, the second developer (hi, Uli!) could.

On Mac OS X 10.3 Panther, Berkeley DB has a known corruption bug.

Good enough for me.

The manual actually does a really good job of explaining the steps needed to export your repository and then import it again in another format. Here are the steps I used:

svnadmin dump /My/Repository/ > dumpfile // Move old repository somewhere else svnadmin create --fs-type fsfs /My/Repository/ svnadmin load /My/Repository/ < dumpfile

I just rebuilt my entire project and ran it, and it looks great.

At least one of my commenters has mentioned various Subversion GUI-based clients. For now, I’m just using Xcode 1.5’s Subversion plugin. For the most part I like it, but there are two issues:

Xcode expects the Subversion utilities in yet another location, /usr/local/subversion/bin/. So I made that work.
Xcode’s Subversion plugin doesn’t handle bundles like nib files correctly. Known problem. So I have to check in nib files from the command line.

Another commenter asks, why Subversion?

I’ve heard both good and bad things about Subversion. The good: it discards a lot of the cruft of CVS, and it has some new features, esp. atomic multiple commits. The bad: I vaguely remember reading someone’s opinion that as far as going in a new direction, Subversion gets it all wrong. Was that in a weblog somewhere?

I guess my main reason for trying it was that it looked like it would be easier than CVS.

That’s it.

Oh, and if I did run into problems, the Subversion partisans I know might be more enthusiast about helping me because it promotes a product they like.

Nobody likes CVS.

The Unix Complacency

I understand the benefits, mentioned by the commenters to my last post, of the “Unix Bargain” that Apple struck when it bought NeXT.

I’m very happy about what it’s done for the platform:

The vastly improved underpinnings (fewer crashes, etc.) have prevented a complete exodus to Windows.

The ports of Unix-based developer infrastructure have allowed Macintosh developers to be more productive.

But my unease remains, so here’s my second attempt to explain why.

The way I see it, the reason the Mac received a Unix graft isn’t because it’s somehow the best of all possible worlds to piggyback on another platform, a platform with wildly different assumptions about its user base. It is because the Mac doesn’t have the marketshare to pay for or attract these benefits otherwise.

The tendency to think of the current situation as nirvana, rather than a compromise, blinds people to the costs of the compromise.

A parting thought I’ll come back to later: the Macintosh is not Unix with a pretty GUI on top. The more developers think like that, the more chance there is that OS X becomes just another Linux variant that happens to costs $129.

1/6: Edited for clarity

The Unix Ghetto

There are several very helpful comments to my last post filling me in on the Unix justification for the use of the /usr/local/bin location for Subversion’s utilities, and why that location isn’t part of the default PATH environmental variable.

All helpful, all logical. All, as one commenter put it, “Mac OS X’s BSD heritage shining through.”

Still, it makes me feel uneasy, and what follows is a first attempt to describe why.

Don’t get me wrong. I was being paid to program on Unix long before I was paid to program on the Mac. Emacs before CodeWarrior, CGI before Toolbox. Unix has an elegance and a rich history that’s hard to match.

But I don’t want Unix to replace the Mac.

For end users, the debate has pretty much ended. Apple’s APIs are the expected way to interact with them. Anyone who seriously suggests that X11 or a command-line interface is an acceptable way to package consumer applications is, well, not taken seriously.

But as a developer, I’m frustrated by how all that is thrown away when discussion turns to the tools I use on a day-to-day basis. Here, Unix is expected. To use Subversion, I need to know the command line and, as the commenters pointed out, the Unix filesystem hierarchy and its history. I need to know Unix, even if what I’m trying to build is a straight Cocoa application with no Unix API or convention dependencies. I’m expected to know Unix.

I don’t want a ghetto to arise where end users get helpful, easy-to-use applications and tools, but the infrastructure for making and selling similar GUI-based tools to developers withers away because, well, everything’s Unix. Just compile it yourself and go.

What happens when developers all live on the command line, but they’re the ones in charge of writing the elegant, GUI-based applications for the rest of us?

Subversion Excursion: Details of Getting Started on OS X

I’ve set up my first personal Subversion repository.

By all accounts, Subversion is much easier than CVS. But setting up a personal repository on Mac OS X involves little steps that nobody seems to have written down anywhere yet.

First of all, don’t bother with all the packages listed in the MacDevCenter.com article “Making the Jump to Subversion”. For 10.3 “Panther,” all you need is one of these two packages:

Martin Ott’s packages containing statically linked binaries for Mac OS X 10.3 Panther
http://www.codingmonkeys.de/mbo/
Metissian’s Mac OS X Subversion Packages
http://metissian.com/projects/macosx/subversion/

Alas, neither works out of the box without further fiddling. What I discovered from Metissian’s README file is that it doesn’t install its utilities under any of the standard 10.3 PATH environment variable locations. Type echo $PATH in a Terminal window to see these locations for yourself. Instead, without any explanation (though I’m sure some Unix expert could give me theories), it puts them in /usr/local/bin. Under a standard 10.3 configuration, such utilities are not conveniently accessible.

There are perhaps half a dozen ways to add to your PATH environmental variable. Ask the above-mentioned Unix experts about their various merits if you want to while away an hour or two. The one I use is a .profile file in my home directory. See this sample profile.txt file. (Update: I accidently deleted the sample file. See the comments for other options.)

Now you can use Subversion utilities like svn from a Terminal window. Have a look at the Subversion book to see the steps needed from there to set up and access a same-machine Subversion repository.

I’ve heard rumors you need a ~/.subversion/config file to prevent a Subversion import from sucking in .DS_Store files, but my admittedly simple tests tonight show that this fear is unfounded.

I’m sure I’ll have more to say about Subversion, esp. about sample config files, but for now, that’s it!