A Trifle Absurd

NaNoWriMo: Done!

Fifty thousand words (50,085, in fact) in thirty days, and National Novel Writing Month is over. Wow. I have no idea what to think, or even what to feel–maybe it just hasn’t sunk in yet. I do know this has gone far beyond anything I would have imagined, and turned up a lot of surprises along the way.

The biggest surprise is that despite all the fun I’ve had doing this, and the wild success of writing so much in so short a time, I’m now more certain than ever that writing fiction isn’t really my thing, after all. It seems kind of contradictory to experience that success and at the same time be completely ready to lay it aside, but that’s what I’m feeling.

My wife Elizabeth pointed out the upside, though: it’s better to make the decision not to write fiction from a position of success than from a position of failure. If I had only experienced frustration and difficulty in my attempts at writing, and then decided not to keep writing, there would always be that doubt hanging around in the back of my mind: what if I had just persevered longer? Instead, I’ve had this fun and instructive experience; I can both appreciate it for what it is, and lay it aside without regret.

Back to Linux Again

Nearly two months ago I installed Ubuntu Linux, and mentioned that it was tempting me to switch (back) to Linux. Since then I’ve been using it only occasionally, keeping up with updates and trying out Linux-only apps I hadn’t been able to try before.

Now, though, as NaNoWriMo winds down (more on that tomorrow), my thoughts turn back to coding, and to using Linux as my primary OS for the first time since college. So I’ve spent some time today installing the missing pieces: Thunderbird, Flash, Java (thanks to davyd), and Eclipse. (Yes, Eclipse: I’m using it as a Scheme editor, thanks to Dominique Boucher’s handy SchemeScript plugin.)

If all goes well, I’ll port my files and settings over and make the switch this week. It looks like Ubuntu has lured me back into the Linux fold…

RESTful Continuations?

A follow-up to my recent post on REST versus continuations: Anton van Straaten is giving a presentation at the upcoming LL4 conference about this very topic. His abstract says that “despite initial appearances to the contrary, first-class continuations are in fact compatible” with REST. I’m mightily intrigued–with any luck, LL4 will be webcast again this year, and I’ll get to see Anton’s presentation.

Laszlo

A year or so ago I ran across Laszlo, a UI framework for rich Internet applications that compiles into Flash. At the time, it looked promising, but had three big negatives: it was proprietary, it required a J2EE server, and the demos ran slowly. Now, though, the Laszlo platform has been open-sourced, a standalone “serverless” compiler is in the works, and performance is improving.

Nevertheless, I still find Laszlo less than compelling when compared to DHTML, at least for Trifle’s needs. Laszlo has a few advantages: you don’t have to write your own widget library, and you can animate everything (and I do mean everything–see the demos). But it doesn’t have an HTML-editor widget, and handling the back-button-and-bookmarks problem is a challenge.

Laszlo may be a good solution for Web applications that focus on images and audio, but DHTML looks like a better fit for a document-oriented system like Trifle. But who’s to say it’s an either-or choice? Trifle will begin life with a DHTML front end, but more front ends could be added later.

NaNoWriMo Week Three

I’ve just crossed the 35,000-word mark on my NaNoWriMo novel, which puts me back on pace for 50,000 words by the end of the month. Talk about unprecedented–all the fiction I’ve written in my life before this would add up to less than 7,000 words. This has been a wild, weird, and wonderful experience–I can’t wait to see what the next nine days bring.

Despite all that, I have a growing conviction that fiction writing isn’t the path for me. When NaNoWriMo wraps up, I’ll probably revise my novel a bit, pass it around to a few people to read, and then leave it at that. Hopefully, though, I’ll be able to use that experience as a springboard into nonfiction writing: blog entries, articles, and maybe even books…

Keeping It Simple, Again

Adam Bosworth waxes eloquent on the virtues of keeping it simple. His argument is reminiscent of Worse Is Better, but he casts it in a different light: keeping it “simple and sloppy” is good because of human fallibility. Rigid systems designed to expect perfection end up breaking because of an imperfect component: us, either as users or as programmers.

An important point that Bosworth implies but doesn’t explicitly state is that “simple” means simple for a human, not simple for a computer. In fact, those two simplicities diverge: GUIs are more complicated for computers (than the command-line), but simpler for humans. Scripting languages are more complicated for computers (than compiled C), but simpler for humans. Every advance in computing derives from making the computer do more work so that humans can do less.

From Categories to Tags

I’ve been vexed by the album problem and other issues with item-category databases, and so I’ve decided to change Trifle’s data model from item-category to item-tag. This isn’t a huge change (as I once mentioned), but it works out better conceptually.

The idea is this: instead of marking an item as belonging to certain (hierarchically nested) categories, you mark an item with some number of tags. Tags can be simple labels, as in GMail, but they can also be multi-part values (i.e. lists). Significantly, a tag can include an item identifier (item-id), and can then represent containment or any other kind of link. Queries are performed using pattern-matching on tags.

This solves a number of problems: First off, it frees you from the constraints of a category hierarchy: a query can match any or all of a tag, and any tag containing an item-id is effectively a link. Second, it solves the album problem: an album is just an item like anything else, and it’s tagged with the item-ids of the tracks it contains. Finally, it provides an easier-to-picture user model: just think of an item with a bunch of tags attached to it, rather than an item that’s in several places at once.

NaNoWriMo Week Two

I wrote 11,938 words last week for NaNoWriMo, just ahead of the 11,667-words-a-week pace, for a total of 20,274 words. The lag from the first week means I’m still 3,060 words behind pace, but if I write 2,100 words a day, I’ll be caught up by the end of Week Three.

I’ve had a harder time getting motivated to write these last few days — it seems, at times, to be a lot of work for no real reward. I think that’s just the slogging-in-the-trenches view, though. In the grand scheme of things, I know I’ll be glad to have done this, even if fiction writing isn’t ultimately a big part of my life.

REST vs. Continuations

A great post by Dave Roberts on REST and how continuations enter the picture has helped me clarify my thinking on Web architecture. The debate is about state, specifically server-side state. In a RESTful system, client-server interactions are stateless, but in a continuation-based system, server-side code saves continuations to capture its intermediate state.

REST is often more scalable than stateful approaches, but what I really like about it is that it preserves a sane user experience. You can freely use the back and forward buttons, have multiple tabs open, and bookmark pages, and everything continues to work. By contrast, a stateful application usually breaks most or all of those actions. (Continuation-based frameworks can often preserve back/forward behavior, but bookmarks break, because at some point the server has to clean up old continuations.)

My take is that it’s a lot like functional versus imperative programming, i.e. stateless vs. stateful programming. Statelessness is a really healthy default, but in certain situations, it’s much simpler and/or cleaner to add state. So when programming, I start as functionally as I can, and add state where necessary; and when designing a web system, I start as RESTfully as I can, and add state if I need to.

The Album Problem

In an item-category database of MP3s, should an album be a category or an item?

It seems natural for it to be a category containing items which are the individual tracks. You could even use subcategories to store track numbers (e.g. “/Album/[name]/[track#]/”). But what if you want to store metadata about the album itself, such as release date? There’s nowhere for it to go.

If an album is an item, you can just put it in the appropriate category, such as “/ReleaseDate/1967/6/1″. But now there’s nowhere to put the tracks themselves…

…unless a category is itself an item. But then we’ve exposed ourselves to all kinds of meta-level funkiness. You could have categories of categories, and categories of categories of categories, etc. And just what is the difference between a category that contains a category as an item, and a category that contains a category as a subcategory? The computer can keep it straight, but can the user? I doubt it.

We could try to unify subcategories and member categories to simplify things–that is, allow a single category to be attached at multiple places in the tree, just like an item. So the album is attached to both “/Album/[name]” and “/ReleaseDate/1967/6/1/[name]”, and the tracks in the album show up as category members in both places. This is sensible enough in the example, but does it make sense in general? I’m skeptical.