malvasia bianca

Phoenix Wright Ace Attorney: Trials and Tribulations is the third game in the Phoenix Wright series. I don’t have a lot to add beyond what I said before: it’s a good series, and if you’ve played the other games, then by all means play this one as well, while if you haven’t, give the first game a try.

The mechanics haven’t changed at all since the second game, which is fine; there’s enough to do, and if they’d added anything more, I suspect it would have felt gimmicky. The game starts off a good deal harder than the earlier games, with very little gentleness towards newcomers; fortunately, it doesn’t get any harder after the second case, and in fact I found the last case slightly easier than some of the earlier ones. (Or maybe my brain was just getting back in the groove.)

Amusing enough new characters, but no spectacular additions. (Though the chef is quite something, for better or for worse.) They continued the story arcs set up in the first two games, bringing it all to a conclusion in the last case of this game; timeless plotting it isn’t, but it did all come together acceptably (if not wonderfully) at the end. As with the earlier games, Liesl played all the way through this one, finishing it before I did. (Partly because I was obsessing over Professor Layton.)

I’m not 100% sure that I’ll play future games in the series, now that this plot arc has come to a conclusion; if Liesl wants to, I will, otherwise who knows. (It may depend as much as anything on how many vacations I take.) But I’m quite glad I played through these three.

I was very sad to learn that Erik Ray died on May 14, after being hit by a car while riding his bicycle. He was more of a friend-of-a-friend than a direct friend, but I certainly enjoyed the time I spent with him when we were both living in the Boston area.

For those of you who come here for video-game-related reasons, he worked on the excellent System Shock in a variety of roles, including doing some of the level design. He also wrote a pleasant introduction to XML.

But the main reason why I miss him is Lambda Expressway. It’s a fabulous quirky audio novella, mixing a sort of adventure story with mentions of the virtues of building your own backhoe, a character with a theme song immortalizing the virtues of buns, and, well, just go listen. (I do every year or so.)

I think I have another tape or two of his around somewhere; I really need to go and get them digitized. I hope they haven’t fallen apart…

Liesl’s car is getting a bit long in the tooth, so a week and a half ago we went and test-drove some cars. And decided on a Prius; one of the surprises was that I actually preferred its interior dimensions to the Camry’s. (I kept bumping my head on the Camry’s ceiling.)

We didn’t like the dealer we test-drove it at enough to want to give them our money (and the only package 2 Prius they had in stock was black, which didn’t sound great for summer driving), so we sent out some inquiries via cars.com. Piercey Toyota in Milpitas got back to us saying that they had a non-black package 2 in stock for $23,909. That sounded fine, so we left them a voice mail.

And didn’t get a response—I guess the person we were dealing with was unavailable on the weekend?—but we heard back from them yesterday, and made an appointment to drop by there this evening.

So we show up; the first words are “I have some good news and some bad news”. It turns out that they don’t have one in stock any more, which was pretty annoying; couldn’t they have e-mailed us to let us know? Still, we wanted a car, so we probably would have been willing to put down a deposit or something and wait for a week for the one they had on order to show up.

But, it turns out, Toyota has raised the MSRP in the interim: not only would we have to wait a week, we’d have to pay a few hundred bucks more. They kept us sitting around for a good twenty minutes or so while thinking about whether or not they really wanted to charge us the MSRP, but ultimately they stayed firm: if we wanted a car, we’d have to pay the higher price, instead of the price they quoted to us.

Which Liesl and I were both furious at, and were completely unwilling to do. The reason why we went through cars.com in the first place is so we wouldn’t have to deal with stupid dealer crap: they’d make us their best offer, we’d take it or leave it, no hard feelings either way. Instead, they told us one thing, gave us no indication that anything had changed, had us drive through rush-hour traffic to get there on an evening when, frankly, we had better things to do, only to tell us then that they wanted to change the price on us.

I’m not particularly mad at them for selling the one they’d mentioned on the e-mail: it’s a hot market, we didn’t jump in our car to drive there and buy it immediately. (Though, you know, it would have been nice if they’d indicated that they wouldn’t hold it for us unless, say, we called them to put down a few hundred bucks as a down payment or something: we got back to them pretty quickly, after all.) But if they are going to sell it and we’ll have to wait for a week or two to get another one, it’s simple basic courtesy to spend a minute and send us an e-mail: that way, we would have known what was going on, and hopefully we could have avoided tonight’s trip entirely, arranging whatever needed to be arranged over the phone.

Even with that, though, we would have been willing to put down a deposit for the next car tonight when we showed up and were told that, in fact, they didn’t have a car for us. But to change the price like that with no advance warning is completely unacceptable. Basically, it turns out that what their original “we have a #2 Prius to sell you for $23,909” e-mail actually meant was “we’re a Toyota dealer, it’s likely the case that we’ll be able to sell you a Prius at some point in the future for some undetermined price.” Which we could have figured out quite nicely on our own without blowing an evening on it, thank you very much.

Liesl will contact the next dealer on our list tomorrow; hopefully they’ll be more honest in their dealings with us.

One thing which I was expecting to find in the GTD book, but didn’t, was some sort of version of Standardized Work. This is an idea that I’ve seen in lean: it says that, if there’s a task that you do repeatedly, you should write down the best way you know of to do that task. From then on, you should either follow your standardized work guidelines when performing that task or be consciously experimenting with a new way to perform that task. (And then, depending on the results of the experiment, either updating your standardized work or going back to the old way.)

This is, of course, not an idea that is original to lean, and, in fact, I have heard David Allen mention it (either in a podcast or in another book, I can’t remember), under the term “checklist”. But I still think its absence in the book creates a gap; here’s why.

One of his quotes in that book is “There is no reason ever to have the same thought twice, unless you like having that thought.” (p. 22) That’s perhaps a bit of an exaggeration, but it is true that GTD trains you to capture certain kinds of thoughts (worries, ideas, …) as they flit through your mind, and write them down.

So: if the thought is a next action, it goes on your next action list. If it’s related to a project, it goes on your entry for that project. If it’s something you’re thinking about but haven’t yet committed to, it goes on your someday/maybe list.

But what if it relates something that you do repeatedly? You may be able to place that in one of the above categories, but, for me, they’re not a particularly good fit. That may sound a bit abstract (or wrong!), so let me give you an example as an explanation: sometimes, I am hiring. When I hire, I bring candidates in for interviews. And setting up an interview involves several steps: the candidate and I have to agree on the time, I have to reserve a conference room, I have to register the candidate with the visitor system, I have to make an entry in my calendar, I have to e-mail the candidate driving directions. And probably other steps that I can’t think of right now, which is exactly my point: I can try to hope that I’ll remember all of those steps, but they’re exactly the sort of thing that GTD teaches us not to keep in our brains, to keep instead in some trusted location.

But where? If I’m hiring, I’ll have a ‘hiring’ project, so I could keep it there. If I’m not hiring, I guess I could shuffle it over to the someday/maybe list. But that sounds like a lot of busywork for no particular reason; instead, I find it simplest to have a ‘checklist’ folder where I keep stuff like that. (If you’re curious, the GTD directory on my computer contains my tickler file plus four subdirectories: ‘projects’, ‘someday’, ‘reference’, and ‘checklists’.) So, at work, this is more or less my current set of checklists: a couple of hiring-related ones, one for when somebody leaves, one giving the steps of my weekly review, and my favorite ones, the checklists for when I get to work and leave work. (I created the “get to work” checklist the second time that I realized that it was almost lunchtime, that I’d been too busy to eat breakfast at home, and that I’d gotten distracted and hadn’t eaten breakfast at work; so I created a checklist whose fifth item is “have I eaten breakfast?”.)

Incidentally, my GTD system is settling down pretty well. I’ve made peace with the e-mail sorting issues that I mentioned earlier; once I’d added short keystroke commands to file an e-mail as action/waiting/scheduled (along with keystrokes for various reference folders), I found that having separate folders for those categories worked fine. I’ve instituted weekly reviews at both home and work; they haven’t had any big effects yet, but seem to be a positive occurrence as a whole. My personal next action list has been getting out of hand recently, but I made some progress in taming that this weekend, and it’s been a successful feedback mechanism in preventing me from taking on more personal projects that I really don’t have time for; my work next action list has remained pleasantly manageable. In fact, while I plan to continue tweaking the system indefinitely, I’ve declared the “adopt GTD” project at work a success, and I only have a couple of action items left on the home version of that project.

In a bit of a shocker, I not only just put up pictures from 2007, I even got around to putting up the pictures we have so far from 2008. No, I don’t like zoos as much as you might think from these pictures, I just found more stuff that I wanted to take pictures of in zoos than elsewhere.

Resizing that many pictures at once makes me understand why people like batch image-processing software; at least I’ve noted down the keystrokes to do it in GIMP, so that I won’t have to spend a few minutes figuring that out next time.

(Mostly an e-mail to the leandevelopment group, but I figured I might as well stick it here, too.)

I just finished reading The Toyota Way, by Jeffrey Liker. Which I highly recommend: it may actually now be my favorite (non-software-specific) lean book. A clear presentation of a good set of principles; I saw a lot that was new to me, still more that would have been new to me half a year ago (or a year ago or two years ago), I’m sure that I’ll get a lot out of it the next time I read it.

One thing that struck me in the software development context is its principle 13: “Make Decisions Slowly by Consensus, Thoroughly Considering All Options; Implement Rapidly”. It seems to me that there’s a pretty big tension between a naive application of that rule and agile: it sounds to me a lot more like BDUF than traditional agile.

Now, I don’t really believe that that’s true, partly for ideological reasons and partly because I’m sure that most people doing BDUF would do it in a way that is far away from the spirit of that principle. But maybe there’s something to be learned (in both directions?) from Toyota’s slowly building a consensus before deciding as compared to Agile’s quick iterations on development?

Part of the bridge seems to be set-based development. (Which is one concept in the Poppendiecks’ books that I haven’t seen in many (any?) other agile books.) Are there other Toyota techniques in this area that we should take to heart? The chapter talks about A3 reports; I’d been thinking that they might be a good fit to some gaps at work; does anybody have experience using them in software development? (Hmm, the Poppendiecks talk about those, too, don’t they? My copies of their books are at work, so I can’t check.)

One thing about agile that I don’t want to give up is that we’ve got some good techniques for evolving well-designed software. (E.g. Kent Beck’s four rules. Which I wish I could find a good URL for; this is the best I’ve come up with.) Are they in tension with the Toyota principle? Or are they each applicable in different domains?

How do I tell on a software project when we should be spending more time thinking before making a decision and when we should be getting our hands dirty and checking in production code? (With, of course, the expectation that the code will change as our understanding and the requirements change.)

Here’s the book’s description of the principle (emphasis in the original):

The Principle: Thorough Consideration in Decision Making

Many employees outside Japan who have joined Toyota after working for another company have had to face the challenge of learning the Toyota approach to problem solving and decision making. Because Toyota’s process of consensus decision making deviates so dramatically from the way most other firms operate, it is a major reeducation process. New employees wonder how an efficient company like Toyota can use such a detailed, slow, cumbersome, and time-consuming decision-making process. But all the people I have met who have worked for or with Toyota for a few years are believers in the process and have been greatly enriched by it—even in their personal lives.

For Toyota, how you arrive at the decision is just as important as the quality of the decision. Taking the time and effort to do it right is mandatory. In fact, management will forgive a decision that does not work out as expected, if the process used was the right one. A decision that by chance works out well, but was based on a shortcut process, is more likely to lead to a reprimand from the boss. As Warren explained in this chapter’s opening quote, Toyota’s secret to smooth and often flawless implementation of new initiatives is careful, upfront planning. Underlying the entire process of planning, problem solving, and decision making is careful attention to every detail. This behavior is associated with many of the best Japanese firms and Toyota is a master at it. No stone is left unturned. In fact, every stone is inspected under a microscope.

…

Thorough consideration in decision making includes five major elements:

• Finding out what is really going on, including genchi gembutsu.
• Understanding underlying causes that explain surface appearances—asking “Why?” five times.
• Broadly considering alternative solutions and developing a detailed rationale for the preferred solution.
• Building consensus within the team, including Toyota employees and outside partners.
• Using very efficient communication vehicles to do one through four, preferably one side of one sheet of paper.

(Liker, The Toyota Way, pp. 238–9)

As I have, perhaps, alluded to previously, we spent the second half of April in Paris. Notes:

• It’s the most wonderful place in the world, but I’m actually not feeling particularly compelled to visit it again any time soon. Some of this has to do with the fact that I’ve been there eight times; some of this has to do with the fact that I rather enjoyed spending the week between Christmas and New Year’s at home, and am not sure how much I want to do any vacationing for the sake of vacationing. Of course, this is all subject to change at any time, and Liesl and Miranda may have different opinions.
• We’ve had bad hotel luck in the past; based on recommendations from comments on this blog post, we decided to try renting an apartment this time. We went with absoluliving; not as cheap as a cheap hotel, but for the same price as a decent hotel, we could get two bedrooms and a living room, with a clothes washer, a stove (not that we used it), a fridge. Or at least we thought that’s what we were getting; the day before we were supposed to leave, they e-mailed us to tell us, with no explanation whatsoever, that they were changing apartments on us; we ended up in a one-bedroom apartment, which they had the gall to call an upgrade because it was in a trendier neighborhood. To be fair, the apartment wasn’t a complete unknown, since we’d marked it as acceptable from the list of apartments they’d initially proposed to us, but I still didn’t appreciate the bait-and-switch, or whatever it was, at all. (Also, to be fair, I’m happy enough with the area we ended up in, and will consider staying near République in the future, but I didn’t like being in the middle of a very long block on a side street.) The other problem with the apartment was that one window kept squeaking open and closed all night when it got really windy; I’m not really mad at them about this, because I’m not sure how they would have discovered it by inspection, but it does point out a problem with an apartment agency that you don’t have with a hotel, namely that you can’t just complain about a maintenance problem and have them move you, because they might, say, be closed on the weekend. (Fortunately, it happened on a Thursday, and they managed to get somebody in on Friday who eventually stopped the squeaking by duct-taping it shut.) Anyways, one separate bedroom (Miranda was in a sofabed in the living room) is vastly better than everybody sharing a bedroom, so the general idea was a good one.
• Poor Liesl was sick some of the time; fortunately, it wasn’t nearly as bad as when we were in Amsterdam, but she stayed in the apartment for three (two?) of the days because of that. Partly because of that, we didn’t go to as many restaurants as we might, but we still got some good food out of the trip (including one from a restaurant that apparently changed hands about a week after our last trip and was completely, surprisingly different this time); visiting salons de thé in the afternoon may have been my favorite part of the trip. (The pizza at decent Italian restaurants in Paris is quite nice, too.)
• Why had I never heard of Lovis Corinth before? My first reaction is that I’d rather look at his art than, say, that of Van Gogh or Gaugin or Seurat. Looking at labels suggested that part of the reason is that his art is scattered around museums in Germany instead of clustered in museums in Paris; glad I’m aware of him now.
• The baboons at the zoo in the Bois de Vincennes are a hoot.
• Having internet access in your apartment is a good thing. And no, this is not a sign that I need to relax and tear myself away from the internet: this is a sign that I don’t feel compelled to spend every vacationing hour traipsing from site to site and can, instead, spend time in my hotel just enjoying myself without feeling guilty that I should be doing more on vacation.
• Having a washing machine in your apartment is also a good thing. And points out another benefit to the internet: if your washing machine is refusing to wash and just blinking when you hit a number, you can google the model name and get a manual. (Answer: you accidentally hit the child lock button; hold it down for four seconds to unlock, and what you thought was the off button is actually the start button.)
• Miranda’s favorite museum turned out to be the sewer museum.
• Sacré Coeur is distinctive to look at from a distance but boring on the outside. Not so Notre Dame: there’s something to be said for thousands of people working for hundreds of years to produce something glorious.
• I really am not impressed by the current Orangina ad campaign: large-breasted zebras just don’t do it for me. Sex, fine; animals, fine; combining the two, ick.
• We forgot to buy a power converter; fortunately, the basement of BHV had them for sale. (They had one that went both directions, 110-to-220 and 220-110.)
• Traveling with several puzzle books from Nikoli was an excellent idea: not only are the puzzles top-notch, but the narrower-than-US form factor meant that I could slip one into my jeans pocket, which is very useful when walking through museums where I’ve had to check my backpack, finding myself a room or two ahead of Liesl and Miranda because we go through them at a different pace, and needing to amuse myself. I’m getting a bit burned out on Nurikabe (though I still think they’re an excellent puzzle variant), and Number Link isn’t my fave (once the puzzles get out of the easy range, I have a hard time proving my solution is unique, which frustrates me), but I’m still a big fan of Masyu and Slitherlink. I’ll have to try some of their other puzzle types.
• I really can dial down the number of books that I take on a trip these days: I have enough other entertainments that I don’t need to carry nearly as many to avoid running out of them. (And there are always bookstores if I guess wrong.)
• Heavy curtains are great for the first night or two after getting off the plane, but in retrospect I should have stopped closing them completely after that: I never really got my clock adjusted to Paris time. The flip side of which was that lying awake at night gave me lots of practice in going over my Joyo kanji…

My bookshelves have been getting tight, so I just wandered through the house, and found about a hundred books to give away. Given the frequency with which I’m using the library these days, that should give me a good couple of years more space on the shelves, I hope.

I would seem to be ready to give up on much of the random fiction that I acquired during grad school. I’m still hanging on to more of my academic books than I should, though: I didn’t select any math books to discard, or any Sanskrit/Pali/Indian studies books. (I’m certainly not about to give away my 45-volume edition of the Pali canon, what with the stylish elephants on the spine! But other stuff I could probably stand to give away.) Also, I somewhat surprised myself by giving away some books by some authors while keeping other books by those same authors: in the past, I’ve been more of a select-by-author person.

Incidentally, for what it’s worth, this is the sort of blog post that I’m not sure I would have made in my pre-twitter days. But giving away books seemed to meet the twitter-worthy threshold; and when I thought about it a bit more, I decided I had more than 140 characters that I felt like saying on the subject. A good thing, I guess?

N+ is the first XBLA game that I’ve bought. It’s a platformer in its purest form: your only controls are a joystick for movement and a jump button. Each level is a single screen: you start at one point on the screen, there’s an exit somewhere else, and a button that opens up the exit in a third place. The levels are much less left-to-right and involve much more vertical movement than, say, a classic Super Mario Bros. level: they don’t typically have a ground at the bottom as an important component, and you have a wall jump to help you reach higher areas. There are some enemies: the most important are stationary bombs, but there are also moving bombs, and missiles that track you. (You can also die if you fall far enough, though if you’re next to a wall then you can use it to brake.)

The levels are pleasantly challenging while, generally, fair; I had to play many of them over and over again, but I usually felt that dying was my fault rather than the level designers’ fault: if I could just get my movements executed properly, I’d be able to finish the level, and the levels are short enough that you don’t have to retrace your steps much at all.

The graphics style is very bare-bones, which worked just fine: you’re a stick figure (albeit one with amusing death animations: exploding stick-figure limbs setting off a further chain of bomb explosions can be quite charming), there are no textures to speak of, the enemies are the most basic of sprites. All of which just serves to emphasize the pure platformer nature of the game: it’s all about making your jumps, everything else is secondary.

I’m quite happy with it as my first XBLA experience. I didn’t finish the game, and in fact I only made it through about a third of the levels. But that third of the levels was a good 75 levels, and it was a lot cheaper than a retail game; I got my money’s worth, and if they’ll stick in more levels for people who are more obsessed with that sort of gameplay than I am, more power to them! There’s a free version, too (which came out before the XBLA version); I haven’t tried it out myself, but I’m sure the game play is extremely similar, if you’re curious about it.

Another thing that I’d forgotten since the first time I read the GTD book: not everything that advances a project is a Next Action. Some actions are for the future (and hence belong on your calendar or tickler file); some actions need to be carried out by other people.

One concrete effect of this realization is that it gave me a way to flag the current status of all of my projects. I have a list of projects; each project has to have to have at least one item associated to it with the label NEXT, WAITING, or SCHEDULED. I may have multiple such actions, if I’m proceeding along multiple fronts; I may also have items on the project that don’t have any of those labels. (Those items might be ideas for future actions or reference materials.) But I have to have at least one item that’s flagged with one of those labels: if I don’t, that’s either a sign that it’s really a someday/maybe item, not a project, or that I need to sit down and come up with a next action on the project.

This also applies to e-mails. Some e-mails, even e-mails that I have flagged as active instead of archived, aren’t associated to a project; I stick these in a folder called ‘conversations’. But lots of my active e-mails are associated to a project. So I have folders ‘actions’, ‘waiting’, and ‘scheduled’, corresponding to the labels above. (As well as another folder, ‘projects’, for reference material that I don’t want to archive just yet.) (Actually, not every e-mail in actions/waiting/scheduled is associated to a project in my formal project list: some of them are single-action projects that I don’t feel compelled to capture elsewhere. Though some may be few-action projects that really should be captured elsewhere? I don’t think it’s hurting me yet, though.)

The problem is that this requires too much work for some common operations. Say that an e-mail comes in that I’m waiting for. Then it’s a response to something that’s currently in my ‘waiting’ folder; to avoid forgetting that I’ve gotten the response, I typically move the response to ‘waiting’ as well, then (once I’ve finished clearing out my inbox), go to ‘waiting’, look for e-mails that have gotten responses, and characterize them accordingly. Another difficult issue is when an e-mail requires some amount of context to respond to entirely: do I just have a single message in my actions folder, or the whole thread?

I’m starting to think that gmail has gotten it right by replacing folders with (per-thread) tags. But I’m not willing to move even my personal e-mail usage to gmail’s web interface, and I certainly can’t move my work e-mail there. Does Thunderbird use tags, and make it easy to restrict your view to only messages with a certain tag? (Looking at the web page, I think so, but I’m not completely sure.)

For the time being, I am one of the eccentrics who reads e-mail using Gnus. I assume I’ll move off of it one of these years, but that time hasn’t yet come, and (despite Gnus’s folder-centric nature) I don’t think this will push me off of Gnus, either. I spent a few hours digging through the source code and asking questions of the newsgroup; Gnus doesn’t have tagging support, but it looks like it should be workable to add an extra header to saved e-mails and tell Gnus to limit its view to headers matching a certain value on that header. (A nice benefit of having a mail reader written in a scripting language.) I haven’t yet found the time to implement this, so there might be something that I’m missing, but I’m optimistic.

Once I’ve done that, I can get rid of the separate action/waiting/scheduled folders: those messages can all be in my projects folder, and I can add keystrokes to narrow my view to messages with a certain tag. Of course, this doesn’t solve the ‘response to waiting’ problem listed above; I may actually have my inbox be the same as my project folder. (I’m not sure what the effects of that will be.)

Even the current system is a big improvement over what my inbox used to look like. My actions folder never gets very big; when I got back from vacation, I had 50 e-mails in there when I was done with my inbox scanning, but that was an exception, and having those e-mails all in one place was very useful. (In particular, it allowed me to get it down to the normal 5-or-so level by the next day.) And the waiting and scheduled folders are useful views for periodic reviews. But it’s clearly an area where improvement is possible.

Jim pointed me to this article a few weeks ago, and I’m annoyed to say that I can’t get it out of my head. It’s about a guy who claims to have an algorithm (implemented by a computer program) to help you remember a lot more stuff a lot more solidly than you can with other methods, and it strikes just the right balance of potential importance and buy-in required to get me thinking about it more than I’d like.

The basic idea is this: if you want to remember something, you have to practice remembering it periodically. So it’s not enough to cram facts for an exam and then pretend that you know something: a few months later, you won’t consciously remember most of it. (Which is one reason why I question significant parts of our educational structure, but that’s a separate rant.) Instead, you have to periodically refresh your memory of the facts; fortunately, you can refresh less and less frequently over time and still remember those facts. Basically, the optimal time to refresh each fact is right before you’re about to forget it; this guy claims that he has a computer program that will serve up facts to you at the appropriate time for optimal practice.

This would be very useful to me (and, for that matter, to Miranda) right now: while he will happily apply it to anything, it’s clearly extremely applicable to learning foreign-language vocabulary. (And grammar!) And the theory is also obviously quite plausible (and apparently supported by the empirical psychological literature): I’ve spent a lot of time memorizing facts over the years (and in particular over the last year), and I can testify that this phenomenon of memorizing a word, and then not quite having it at the tip of your memory (or barely still having it at the tip of your memory) some time later is quite correct, and I’m quite willing to believe that there’s some optimal decay pattern for the refreshes.

But I also have a system for memorizing vocabulary that works moderately well right now: not perfectly, by a long shot, but I’ve gotten a lot of use out of it. In particular, right now I have 1200 or so vocabulary cards written down; I’m not about to sit down and digitize them all (which isn’t really necessary), but I’m also nervous about switching to another system which may or may not work, and (if I decide to switch back) to then deal with having some of my vocabulary on a computer and some on physical cards.

Also, to make matters worse, the software is basically Windows-only. So using it isn’t a realistic possibility for me. (It does seem like the sort of software that would strike a chord among Mac geeks, but who knows…)

But then I was idly thinking about it some more over the last day or two. Just how hard could it be to whip together a version of the software myself? The basic infrastructure is pretty straightforward: I need a way to save questions and answers, I need it to display questions to me, and I need to tell it whether or not I’ve answered the questions correctly. Then the software could save my history of when I’ve answered each question successfully (or unsuccessfully), and, based on his magic curves, figure out when it should next offer that question up to me. I’d never written a Rails app (a deficiency that I’d like to remedy), but all the data entry/display sounded like it should be very easy to whip up using Rails; I didn’t know what the magic sauce was, but it’s probably some sort of exponential decay curve, so I should be able to just look up his algorithm and implement it, right?

So I spent some more time at his web site, looking up his algorithm. And, at first, I was pretty disappointed. The most obvious place to start was with the paper version, but it had a few glaring deficiencies. The main one is that it had you work on groups of items all at once, treating each group as equally difficult (i.e. with the same decay curve). (Both the grouping and the equal difficulty seemed wrong to me.) Also (and this is, of course, just a minor annoyance, easily tweaked around), having the first review come four days after you’ve written down a group seemed way too long to me.

Reading that, I was pretty let down. After more poking around, though, it turns out that the algorithm has changed a fair amount over the years; I believe this is the most recent version of the algorithm listed on the website, and that page gives links to earlier historical versions. I haven’t tried to fully understand the most recent version (and, as far as I can tell, there’s not enough information there to reconstruct it, some of the constants there apparently need to be determined empirically), but there are enough ideas to try to remedy the above flaws. It seems like the current version doesn’t always use exponential decay, but I believe earlier intermediate versions did (version 4 seems a particularly useful touchstone), so I could easily start with that; there is a per-item difficulty factor, and there’s some idea that you can calculate the difficulty factor by counting the number of times you’ve gotten the item wrong.

Based on that, it sounds plausible that I could hallucinate an algorithm that probably wouldn’t do any worse than my current method for learning vocabulary. (My current method wastes too much time up-front in going over words that I would ideally review in intervals longer than a day, while at the same time not doing enough review of old words.) And I don’t think it would be too much work to whip up a program to implement it, and I’d get some practice with Rails to boot.

So: would doing that be a good idea? I’m still not sure: if I ultimately decide that I don’t like the results (whether because I don’t think it works well or because I don’t want to be tied to a computer when doing vocab review or because of some other reason), then there would be a real cost in switching back. And it may turn out that this is all really a side-issue: maybe it would be more effective than my current system, even significantly so, if I wanted to memorize a dictionary. But I don’t want to memorize a dictionary, I want to be able to, say, read Japanese, and doing so would probably give me frequent enough review of the words I was actually using to make a program like this superfluous.

Not sure where I’ll go with this yet; for now, I’m too busy, so it’s on the someday/maybe stack. But it’s surprisingly close to the top of that stack; we’ll see where I am in a couple of weeks.

Time for another tour through my saved items queue in Google Reader. No new categories since last time; the numbers of items in those categories, with the difference from last time, are:

• blog: 7 (+5)
• book: 32 (+7)
• commented: 0 (-2)
• flash-game: 10 (+2)
• long: 28 (+14)
• music: 13 (+6)
• podcast: 28 (+8)
• recommendation: 17 (+6)
• short: 0 (0)
• think: 12 (+3)

For a total of 147 items, an increase of 49 over last time. Which is 49 off of my prediction.

Hmm, not sure I’m learning anything any more from these posts. Note that all the categories except for blog, commented, and short are part of my someday/maybe list; the three short-term categories aren’t growing (the 7 items in “blog” just means it’s been a little while since a “random links” post), but the someday/maybe categories are. Which is fine; I still get occasional use out of the collection of saved items, and the fact that those categories are growing just says that I have other priorities in my spare time right now.

I’m sticking with Twitter, at least for the time being: twittering turns out to be reasonably fun, and my earlier blog post plus a mailing list query turned up enough names to make a critical mass of both people I’m interested in following and people interested in following me. Including a couple of other people who were apparently prompted to join because of my messages, which suggests that I’m not the only person I know who was thinking of joining.

I guess the next steps are to find a Linux client (shouldn’t be hard, I guess I can just do it via IM?) and add a few more people to follow. So far I’ve been following a few people I know and a few of the bloggers I read whose tweets are relatively interesting. Which certainly isn’t the case for all bloggers I read; come to think of it, the sort of tweets I prefer from people I know personally are rather different from the sorts I prefer from people I don’t know. I still need more people to follow, because my stream is thinner than I’d like and too heavily dominated by the relatively few frequent posters, but it’s a good start.

I went back and reread the GTD book to see what I’d forgotten from my first read-through a year or two ago. Quite a lot, it turns out (in fact, almost everything except for the definition of a next action), about which more later, but one of the concepts that struck me the most was the notion of a “someday/maybe” list.

This is a list of things that you’re thinking of doing but don’t currently have in progress. As with most GTD concepts, much of its power comes from allowing you to create clear boundaries: the relevant boundary here is that something you’re thinking of doing is either in progress (in which case it’s on your projects list) or is something you’ve consciously decided to defer (in which case it’s on the someday/maybe list). This forces you to think for a few seconds: do I want to work on this now or postpone it? If I want to work on this now, what’s the next action? But once you’ve done that, you can stop worrying about it. (Or at least that’s how the theory goes, and it matches my experience well enough.)

So, basically, the someday/maybe list is a repository for all those pipe dreams and worries that you’ve had that you’re not dealing with right now. Much of its value is simply as a place to write things down: part of the GTD idea is that, when a thought flits through your mind, you probably want to write it down somewhere unless you particularly want that thought to continue flitting through your mind. And many such thoughts translate into either new items for the someday/maybe list or comments on existing items for that list.

Of course, just making a list won’t do you any good if it turns into sweeping unpleasant thoughts under the carpet: that will translate into some combination of not getting things done that should get done and of worrying that you won’t get things done. So you’re supposed to look at your somebody/maybe list once a week, to ask yourself if any items there should be promoted to active projects.

The reason why this struck me so much is that it gave another way to look at my preferred way of dealing with books, namely to have a very short stack (ideally of length at most 1) of books that I’ve bought but haven’t yet read, while keeping a much longer list of books that have caught my eye for some reason. I got this revelation from lean (inventory is waste), and it’s served me very well over the last couple of years, but I had a hard time explaining just why it is that having a big stack of books that I really want to read but haven’t gotten around to reading is bad while having a long list of books that I really want to read but haven’t bought or gotten around to reading is good. (The third option would be to not have a list or a stack; for me, that would translate into an unreliable mental list, which is worse than a physical list.)

If you think about it in GTD terms, though, what’s going on is this: you see a book, and the thought flits through your mind that you should read it. Being a trained devotee, you know that you need to write this down somewhere: so is reading that book a current project, or a someday/maybe item?

If it’s a current project, then the logical next action is to buy it, so by all means do so at once. If you don’t have definite plans to read it soon, though, then it should go on the someday/maybe list, in which case buying it now isn’t appropriate. If you want to get a bit subtler, you can say that you have a current project of “always have a book to read”, in which case buying the book is appropriate if you’re close to finishing your current book and you want to read that book next, but isn’t appropriate otherwise.

Basically, there are (in my experience) a few reasons why I’m tempted to buy the book on the spot. One is because I like to fantasize how exciting it will be to read the book. That’s very pleasant, but buying the book isn’t a good response to fantasies like that: I should only buy the book if I’m actually going to read it, not just because I want to bask in the thought of reading it and can hallucinate that buying the book right now is a constructive step towards that end. Another reason is because I’m afraid that I’ll forget about the book if I don’t buy a copy right new, and I really would like to read it at some point in the future; fair enough, but making an entry on a list (possibly with some notes about what attracted me to the book) is a better response than buying it. A third is because I feel guilty walking into a bookstore, browsing their books, taking notes about what books to buy, and then walking out without giving them money; I still think that’s actually a pretty good reason to buy a book, but what I’ve found is that, if I have a low (frequently zero) unread book inventory, then I can assuage my guilt by buying one book and reading it next (or possibly after I’ve finished my other book in inventory). And if I’m not sure that I want to read the book next, then maybe that’s a sign that I shouldn’t buy it right now: I have lots of experience with the strategy of buying books because I feel that I should read them, and the results aren’t generally particularly positive.

The upshot is that I’ve moved my books-to-read (games-to-play, music-to-listen-to) lists to a ‘someday’ subdirectory of my GTD directory, and added a generic someday list there. And the results have been generally pleasant: it’s nice to have a place to write down ideas about things that I’m thinking of doing in the future. Equally importantly, it let me stop worrying about certain things that I knew I should get around to doing but just didn’t have enough spare cycles at the moment to work on; enough items have graduated from the someday list to full-fledged projects that it’s not just a sham.

I just signed up for Twitter. (Should I capitalize the T or not? Hmm, looks like I should.) I mostly did that not because I want to start using it now but rather because I can imagine wanting to use it in the future, and, if I do so, I’d prefer to have a relatively readable URI. But some experiences recently in the red-bean IRC room got me thinking that I like getting little status updates from my friends; that IRC room is far too high a volume (at times) for subscribing to it to be a good idea for me, but Twitter could be a good alternative.

So I’m open to the idea of using it. Which means that I need two things:

• Friends who use it, so I have somebody to follow.
• Good clients for both Linux and Mac.

Presumably I can figure out the latter easily enough myself (though I’m open to suggestions, especially on the Linux front); can my blog readers provide me with a critical mass of the former?

Professor Layton and the Curious Village is a puzzle-based adventure game. Actually, that probably gives the wrong impression, making you think that the game is about figuring out how to use these items to get access to a key that you can use to open a door over there; I should say instead that it’s a puzzle-obsessed adventure game, in the sense that, whenever you strike up a conversation with a random NPC, he or she may or may not have anything to say about whatever is on your mind, but will definitely show you a picture drawn with matchsticks and ask you to, say, turn it from four cubes to three cubes by only moving one matchstick. Or might tell you of a farmer trying to convey wolves and chickens across the river using a boat that only carries two animals, where three chickens can successfully defend themselves against two wolves but one chicken can’t. Or he’ll ask you how he can possibly measure five cups of milk, given that he’s somehow lost his five-cup measure but has a helpful set of ten-cup, seven-cup, and three-cup measures.

I might as well stop here; most people will either run screaming from the game or fall in love with it, and the above paragraph should give you enough information to determine which bucket you fall into. If you want puzzles, this is the place to go: there are 130 or so of them, I enjoyed them all, there are ample hints should you need them. On a non-puzzle-related note, the art style is totally charming, in a sort of Triplets of Belleville way.

And there’s already a sequel out in Japan, with a third game in the series promised; yay!

In honor of the release of the Wii version of Okami, I urge all of you who own a Wii (or a PS2) and who haven’t played the game yet to go out and buy a copy. More here, but the short version is: it’s an adventure game based on Japanese mythology with a beautiful art style based on Japanese brush-work, where you level up by (among other things) growing plants and feeding animals, all on a solid core of Zelda-style gameplay. I haven’t played the Wii version, but I can’t imagine adding Wii controls to the brush commands would lower the quality any…

Wow, I haven’t been blogging much recently, have I? Sorry about that; I do most of my blogging on weekends, and the last few weekends have been pretty busy. (And much of my weekday free time in the evenings has been spent watching Twelve Kingdoms.)

Fortunately, I have not been slacking off on all of my side activities: I’m finally caught up with all the back episodes of JapanesePod101! I even managed to catch up a couple of months earlier than I predicted, largely due to the fact that, for a while, they were only doing two episodes a week that were at about the right level for me instead of three episodes a week. (I listen to all the episodes, I just pay more attention to some than others.)

Actually, learning Japanese has been going well for the last two or three months. I was unhappy with how long it took me to go through the first ten chapters of the textbook I’m using; since then, I’ve done six more chapters, and only one of them took more than two weeks, so my pace has increased noticeably. (And that one only took three weeks.) And I’m up to 301 characters in my march through the Joyo Kanji; I still have years to go on that journey, but at least it isn’t showing any signs of stalling.

Happy signs everywhere.

I’m not convinced I like the comment management UI in WordPress 2.5: I accidentally marked several previously-approved comments as spam and then deleted them. Fortunately, I noticed my mistake within a couple of hours, quickly enough that the most recent nightly backup was still around, but it was still an easier mistake to make than I would have liked.

Lessons:

• Other WordPress users, beware.
• If you’re saving something you care about, practice restoring from the backup! (Some googling showed me how to restore from a mysqlhotcopy backup, but I still had one heartstopping moment where the initial restore didn’t work because of a file ownership/permissions problem.)
• If you’re saving something you care about, keep multiple nights’ worth of backups.

So what’s the best way to address that last issue? We have enough disk space lying around that I could just keep around tens of nightly snapshots. But snapshots from night to night are, in general, not very different, and the process (other than transient spam comments) is largely additive; I don’t see why a complete revision history should take up that much more space than two full backups. (Hmm, maybe that’s a bit optimistic, because of all those spam comments.) But tools like that that I’m aware of are all line-based, and I don’t know offhand of a good way to do a mysql database backup that puts different rows in different lines. So I might have to use a binary diff program, which I’m not that familiar with; maybe bsdiff?

Maybe I’m going at this in the wrong direction – maybe I should approach the problem at a different level, backing it up using some sort of xml format that WordPress can handle through its management interface? If I did that, I’d have more confidence that I’d be able to manipulate the resulting backup files in a non-harmful fashion that’s more amenable to line manipulation.

For now, though, I think I’ll just throw disk space at the problem…

Since I felt compelled to type out a long quote for use on a mailing list, I might as well stick it up here, too. This is from Deming’s Out of the Crisis, pp. 128–129, in its chapter on “Diseases and Obstacles”; the blockquote sections are indented in the original.

Search for Examples. Improvement of quality is a method, transferable to different problems and circumstances. It does not consist of cookbook procedures on file ready for specific application to this or that kind of product.

It is not unusual for a consultant to receive an enquiry for examples of success in a similar product line. One man enquired if the methods of this book had ever been used in the manufacture of wheelchairs. Another enquired about compressors for air conditioners: did I know of any application? Another man enquired about the management of a hospital: would the 14 points apply? Another wondered about application in a large accounting firm. Another man wondered if the principles taught in this book had ever been used in the manufacture of automobiles, as if he had never heard of Japan’s automobiles. A banker wondered about application in banks.

A man just called on the telephone from Johannesburg with the proposal that he come to this country and visit with me six companies that are doing well. He needed examples, he said.

My answer to such enquiries is that no number of examples of success or of failure in the improvement of quality and productivity would indicate to the enquirer what success his company would have. His success would depend totally on his knowledge of the 14 points and of the diseases and obstacles, and the efforts that he himself puts forth.

Too often this is the story. The management of a company, seized with a desire to improve quality and productivity, knowing not how to go about it, having not guidance from principles, seeking enlightenment, embark on excursions to other companies that are ostensibly doing well. They are received with open arms, and the exchange of ideas commences. They (visitors) learn what the host is doing, some of which may by accident be in accordance with the 14 points. Devoid of guiding principles, they are both adrift. Neither company knows whether or why any procedure is right, nor whether or why another is wrong. The question is not whether a business is successful, but why? and why it was not more successful? One can only hope that the visitors enjoy the ride. They are more to be pitied than censured.

It is a hazard to copy. It is necessary to understand the theory of what one wishes to do or to make. Americans are great copiers (QC-Circles, Kanban or just in time, for example). The fact is that the Japanese learn the theory of what they wish to make, then improve on it.

QC-Circles contribute vitally to industry in Japan. American management, without understanding management’s role in a QC-Circle, try to copy QC-Circles, only to find some time later that they have a dud. QC-Circles that enjoy cooperation and action by management will do well anywhere.

It was related to me during a seminar (source unfortunately unrecorded) that the management of a company that makes furniture, doing well, took it into their heads to expand their line into pianos. Why not make pianos? They bought a Steinway piano, took it apart, made or bought parts, and put a piano together exactly like the Steinway, only to discover that they could only get thuds out of their product. So they put the Steinway piano back together with the intention to get their money back on it, only to discover that it too would now only make thuds.