At one point that just meant OmniOutliner for my lists and iCal for my calendar. But now that I work outside the house, it’s much more convenient to have all that data in Web apps so I can edit it from anywhere. So I moved my lists to Gmail and my calendar to Google Calendar.

Gmail isn’t an ideal list manager, but I’ve come up with a decent workflow. For each GTD list, I set up a label and a filter that redirects mail sent to “myusername+label@gmail.com”. Then, for convenience, I add that email address to my contacts, and give it a short name of just “label”. That puts address autocompletion on my side. Now I can just email that address to add something to the list, and reply to an existing list item to update it or add information.

This would be overkill for a frequently updated list such as next actions, but I keep that on paper. The only lists in Gmail are current-projects, someday-maybe, and waiting-for. So far, those seem to have the right granularity to make this setup work.

And that’s my current GTD system. No doubt it will be different again in six months, but I’m fine with that. Changing things up helps keep it interesting, as long as I don’t focus on the system at the expense of the stuff. I just need to remember that the point is not to get things organized, but to get things done.

I keep my inbox and next actions on paper, specifically a long narrow piece of Rhodia 7.4×21cm graph paper. My next actions cover one side, and there’s plenty of inbox room on the other side. Add a Zebra F-301 Compact pen, and I have a simple, pocketable solution.

Ah, but what about other information I might need to take with me, such as a calendar? That’s what the iPod is for. An iPod nano can sync my calendar and whatever other notes I need, then slip into my pocket alongside pen and paper. Sure, it’s read-only, but I can easily note down changes (like new calendar appointments) and put them in when I’m back at the computer.

I keep several lists on the iPod, such as bus times, (used) books to buy, and library books. The library list is actually two lists: books I have checked out, and books I have on hold. At a glance I can see what books I need to return or pick up. The best part is that I can generate these lists automatically, thanks to the Seattle Public Library’s RSS feeds. (That was the minor XML-munging I referred to in my Ruby post.)

Okay, that covers everything but the stuff still on the computer. Next time…

When I first got into GTD, I kept all my lists in text files on my home computer. At the time I was working at home, so everything was always handy. If I needed to go out and run errands, it was easy to just quickly jot down a list to take with me.

But I got a little bogged down and wondered if just getting it all out on paper would help. I switched to a vanilla Hipster PDA, and that worked well for a while. I liked the portability, but got tired of having to recopy lists to get rid of old items and reorder things.

So I went from the Hipster PDA to an actual PDA, a Palm Z22. That was great fun, but it got old too: in particular, text entry was always a pain, even with help like MessagEase. And the Z22 just wasn’t small enough to be truly pocketable.

Now I’ve switched to a hybrid system, with some things on the computer and others on paper. But this entry is long enough already, so I’ll save that for next time.

Make a copy of Camino.app, and rename it Gmail.app. Change the icon to something appropriate. Open up the application package, and drill down into Contents. In the MacOS folder, rename Camino to Gmail.

Then open up Info.plist. Change CFBundleExecutable, CFBundleName, and mozProfileDirName to “Gmail”. Change CFBundleIdentifier to something different (but in the same reverse-domain-name format). Save and close.

And that’s it. You now have a separate application you can use just for Gmail. Hide the bookmark bar and collapse the toolbar and you have a simple, clean window.

Well, almost. The status bar is still there, and Camino doesn’t provide a way to hide it. But you can get rid of it: open the Gmail.app package again and go to Contents/Resources/English.lproj. Load up BrowserWindow.nib in Interface Builder and simply delete the status bar controls.

Of course, there’s nothing particular to Gmail about all this — you could use the same technique to make a specialized browser app for anything.

(So, for the record, now that I have an employer: This is my personal blog. The views expressed on this blog are mine alone and not those of Google.)

I’m really excited to be working at Google, and I’ll be working on a great project… which I can’t talk about. But I should have enough non-Google material to start posting here regularly again.

I had some minor XML-munging to do, so I started writing a Python script. But none of Python’s plethora of XML-parsing possibilities was simple or convenient, even though what I wanted to do was extremely simple. Grumbling in frustration, I decided to give Ruby a try.

Scant minutes later, I had a working script, despite never having programmed in Ruby before. The code was simple and clear, and easily extended to cover a parallel XML-processing task. That’s the kind of initial experience that will bring me back for more.

I like working as part of a team, and I missed that as an indie developer. So I’m going to get a programming job.

I like balancing programming with other creative work, and I missed that in my former days at Microsoft. So I’m going to make time for writing and music around whatever job I get.

That’s the news in brief; now back to some ordinary, minimally-introspective blogging.

Why not? I realized that I wasn’t enjoying the development process, and recognized the feeling from when I burnt out at Microsoft years ago. This gives rise to two theories: (1) Programming just isn’t for me and this second burnout shows that I should find a completely different line of work. (2) Programming itself isn’t the problem, it’s the surrounding circumstances: at Microsoft the problem was that I had no life to balance my work; now (perhaps) the problem is that I’m working alone, and I’d rather be part of a team. I haven’t decided which theory I think is right.

What now? Good question. I’ll probably wind up with a day job of some kind while I try to sort out longer-term plans. I hope to finally attend a workshop or two at Centerpoint, which I’ve wanted to do for years.

What about this blog? I enjoy blogging and I plan to resume posting on a regular basis in September. With my move away from indie development, the focus will naturally shift, so if you’ve been reading this for the programming-geek content, you may be disappointed. I can’t say much about what will replace it ’cause I don’t know myself yet.

I hope to get back into the swing of geeky things soon and have something real to post. At the very least, I’ll write up my booklog for April.

So it’s about time we figured out how to do concurrent programming. OS-process parallelism can spread the load over a few cores; OS-thread parallelism can do a bit more; but how is your app going to handle a couple dozen cores a few years hence? Shared-state concurrency as practiced these days isn’t going to cut it. (But you’ve heard this already…)

We’re starting to see programming languages that take that challenge seriously. Erlang is the best-known example, though there are others: Haskell (with STM) and Oz come to mind.

In a few spare moments (my nearest equivalent to “spare time”), I’ve been hatching up ideas for a little highly-concurrent language of my own. I doubt anything will come of it before I ship Trifle, but then, who knows? I might add something to the towering babble of computer languages.