A Trifle Absurd

Dogfoodability

Once upon a time, some overly-clever soul applied the phrase “eating your own dog food” to the practice of using your own product before inflicting it on customers. Then, in the twinkling of an eye, “to dogfood” became a verb. “Sure, I’ll start dogfooding that.” “Is it dogfoodable yet?” (The scary thing is that those sentences now sound completely normal to me.)

Anyway, Trifle has reached dogfoodability (dogfoodableness?). There are no columns or rules yet, just lists—but that’s enough for simple task lists, and that’s what I’m using it for. I ported over my GTD stuff this afternoon.

I won’t be working on Trifle itself for the next couple of weeks, but I’ll be using it. No doubt I’ll accumulate quite a list—in the form of a Trifle document, of course—of things I want to tweak, extend, and fix.

Choosing a File Format

I knew starting out that Trifle’s file format should be textual. Trying to avoid the knee-jerk answer of XML, I looked at alternatives, such as YAML and Turtle. But XML still won out: I can use existing libraries to parse and generate it, and it interoperates with a staggering quantity of tools.

That took the question to another level: what XML format should I use? My instinct was to find and use an existing XML vocabulary, rather than invent my own. Tim Bray reinforced that with Don’t Invent XML Languages.

But none of Tim’s Big Five fit the task. DocBook, ODF, and UBL weren’t even in the neighborhood. Atom could just barely work, but only if I added a bunch of extensions in a separate namespace. An XHTML microformat like XOXO could be made to work by shoehorning everything in, but my goals don’t match those of the microformat folk. (For instance, I don’t want to support presentability—these are data files.)

RDF is a better match for Trifle’s graph semantics, but RDF/XML is a pain to use and process. In fact, using RDF/XML would effectively shut out a lot of XML tools. I checked out Turtle as a non-XML RDF syntax, but almost nobody is using it; again, XML has the advantage of existing libraries and tools.

So my only remaining option was to design my own XML vocabulary. And I don’t think that’s a bad thing in this case. Tim’s arguments mostly involve designing a vocabulary for interchange between independently developed pieces of software. That’s not my situation. Other than current and future versions of Trifle, the only consumers of the format will be purpose-built scripts written by power users.

Besides, Trifle won’t ignore those common formats. I’ll include some form of Atom import and export, and probably HTML too. Maybe I’ll even do it by using XSLT to transform to and from Trifle’s format.

Booklog: December

I’m going to start posting a monthly rundown of the books I’m reading. It won’t be as software-centric as the rest of my blog, but since it’s only once a month, it should be easy to skip if you’re not interested. Here’s what I read in December:

Geekery

Programming Pearls — Jon Bentley

More Programming Pearls — Jon Bentley

A couple of old favorites I hadn’t read in a while—I needed to be reminded of some practical programming wisdom as I turned to the task of building Trifle as a shippable app.

The Pragmatic Programmer — Andrew Hunt and David Thomas

Rereading this along with Bentley’s Pearls, I found a lot of overlap. Further evidence that computers change fast, but good programming practice doesn’t.

Small Pieces Loosely Joined — David Weinberger

Finally got around to reading this. Much of it seems obvious, but it is written for a general audience, so Weinberger can’t assume much from the reader. Also, the obvious bits were probably a good deal less obvious four years ago when it was written. Despite all that, it did make me stop and think.

Cocoa Programming for Mac OS X — Aaron Hillegass

The Mac application programming book. This was my first time with the second edition; Hillegass took an already-good book and improved it. If you want to write applications on the Mac, this is the book you need.

Fiction

Litany of the Long Sun — Gene Wolfe

Epiphany of the Long Sun — Gene Wolfe

The Book of the Long Sun was originally published as four novels; this edition collects them into two volumes, with two novels in each. (I actually read Litany in November—I’m not that fast a reader.) Gene Wolfe continues to amaze and delight. Here he tells the story of a young priest in charge of a small run-down temple who gets commissioned by a mysterious minor god to save that temple. Of course, there’s far more going on than is immediately apparent; Wolfe uncovers it masterfully over the four-book span.

Descent into Hell — Charles Williams

Yes, J.R.R. Tolkien and C.S. Lewis were better writers; still, their pal Charles Williams wrote some fascinating metaphysical fantasies. Descent into Hell isn’t as dark as it sounds—there’s also an ascent into heaven going on. Williams sidesteps tired metaphors by rendering it all as a contemporary fantasy. (Well, contemporary for 1937, anyway.)

Other

Invitation to a Journey — M. Robert Mulholland Jr.

A short introduction to spiritual formation that focuses on mindset and approach. Nicely complements the theological emphasis of The Spirit of the Disciplines and the practical focus of Celebration of Discipline.

Not Just a Living — Mark Henricks

A book on “creating a business that gives you a life”, intended as an antidote to the idea that entrepreneurship is all about working long hours and giving up your life in the hopes of making a lot of money. Best part: the stories of individual business owners.

Replacing the Daily Log

Over the holidays, I kept thinking it was time to ditch the daily log. I resisted at first, ’cause I really liked the daily log and its effect of keeping me on task. But the thought wouldn’t go away.

So I turned back to The Now Habit, the book I got the daily-log idea from in the first place. Neil Fiore only suggests keeping a log for a week or two, just to see where the time is going and get some idea of why you procrastinate. Later in the book, he presents a time-management system called the Unschedule, which I’d never gotten around to trying (hmm, procrastination perhaps?).

The main idea of the Unschedule is that you schedule your fixed appointments, sleep time, commuting, exercise, meals, and play time; anything left over is potentially time for work, but you don’t schedule work in advance. Then you log any work you do that covers at least a half-hour stretch. Also, you make a point of turning to some fun activity immediately after completing a work session. (There’s a bit more to it than that, of course—see the book for details.)

The Unschedule as presented uses a classic hour-by-hour grid, and I knew from experience that wouldn’t work for me. So I tried to express the same ideas without an explicit schedule, while keeping some of the best parts of the daily log.

Here’s my new setup: I keep track of work I complete in four simple categories, which are Trifle, website, music, and business-of-life (paying bills, cleaning house, etc.). Work has a half-hour minimum, and runs in fifteen-minute increments. I also have a list of post-work-session activities to choose from—everything from lunch to blog-reading. And, of course, I can always take some other kind of break if I need it.

I’m loving it so far, and getting a lot done, but we’ll see what I think in a month or so. After all, any system can run well for a week; the test is whether I keep it up.

Risking Mistakes

I’m cautious by nature. Too cautious, in fact. Many times I’ve thought that I should take more risks, knowing that even if I screwed up more often, it would still be worth it.

Looking back at the past year, I can see a lot of mistakes, wrong turns, and dead ends. That’s discouraging, especially if I start playing the what-if game. How much could I have gotten done if I’d made some better decisions along the way?

But then, the very quantity of mistakes shows that I’m actually taking more risks, and screwing up correspondingly more often. And I sure have learned a lot from those mistakes: not just “don’t do that again”, but bigger lessons about how to make decisions, and how to recognize my own tendencies. Herewith, a few risks and results from my past year of programming:

• Switching to the Mac — a spectacular win that renewed my enthusiasm for programming.
• Starting Overleaf — a mixed bag: it got me learning Cocoa, but took my attention away from Trifle.
• Redoing Overleaf in Scheme, then Haskell, then Python — a long and crooked road that wasted time but finally wound up at the right place: Python was a great fit for Overleaf’s needs.
• Making Trifle a Mac-only desktop app — a great idea that made it possible to consider Trifle as a commercial venture.
• Writing Trifle in Haskell — a dead end, unfortunately.

Hmm. I was expecting just to catalog my mistakes, but by listing risks and results instead I see just how many of them turned out well. That’s tremendously encouraging—it shows that my risks are paying off, not just theoretically but actually. Here’s to taking more risks in 2006!

What Trifle Isn’t

One of the best ways I’ve found to clarify my vision of Trifle is to define what it won’t do. So here are some things that Trifle isn’t:

Trifle isn’t an outliner. Nested structure is avoided, and even what little nesting there is (like grouping by a column value) is programmatic, not arbitrary. It’s not that I think outliners are a bad thing—in fact, I’m a happily registered user of Hog Bay Notebook—but Trifle is trying to cover different ground. Consider Ted Goranson’s outliner use patterns: long document generation, notetaking/journaling, snippet management, and list management. Trifle isn’t intended to handle any of those except list management—and even that is handled differently than outliners do.

Trifle isn’t a notebook. Entries don’t have attached notes, although they can be linked to other documents if you like. That makes a Trifle document more of a nexus, or a jumping-off point, than a self-contained notebook.

Trifle isn’t a database. Well, okay, Trifle is a database, in the general sense. But if you have a complex schema to enforce, or have tens of thousands of entries, you probably need a full-blown SQL-supporting database.

Knowing what Trifle isn’t helps me avoid unnecessary competition. There are a number of really good outliners for the Mac. If I wrote another outliner, I’d be hard-pressed to compete with them. The same holds true for notebooks and databases. But the more I can manage to avoid overlap and distinguish Trifle by its differences, the more likely people are to see it as a complementary tool to the tools they already have. (I hope.)