[ Content | Sidebar ]

bush text adventure

January 22nd, 2006

This is really funny.

good journalism

January 22nd, 2006

Despite my complaints a few days ago, I do think that the Mercury News is a decent paper by today’s standards, and this morning they reminded me why. They’ve been reviewing 700 appeals of local criminal cases; the results will appear in a five-part series that began with a special section of today’s paper, the main article of which can be found here. (The link may go stale after a week.)

Good stuff; it’s not serving advertisers or power interests, it’s just reporters putting in the time and effort to dig up facts, construct an intelligent narrative around them, and, with a bit of luck, help make the world a better place.

mindful programming

January 21st, 2006

The last section of The Fifth Book of Peace talks about Thich Nhan Hanh a lot, so I decided to read one of his books next. One of his big themes is “mindful behavior”; as I understand it, this means that, when you do something, you should simply be doing that, not thinking about or working on many things at once. When you’re walking, you should simply be walking; when you’re sitting, you should simply be sitting. I’m quite bad at that: right now, for example, I am not mindfully writing a blog post, but am also looking up periodically at what’s on the TV. (The anglerfish battle on Iron Chef, which is really quite something: maybe I should be mindfully watching it instead of writing.)

Anyways, it seems to me that some of the XP processes could be thought of as enabling mindful programming. Take TDD, for example: rather than trying to simultaneously figure out what your code should do and writing code that implements that as well as possible, you’re instead either writing the next test, getting a test to pass however you can, or tidying up your code. So you’re always focused on one quite narrow task, trying to do it as well as possible. Pair programming helps with this, too: it enables the driver to narrowly focus on implementing what is closest at hand. It’s not clear to me that the navigator is working mindfully, however: the navigator has the jobs of writing down potential future tasks as they come to mind (so the driver doesn’t have to worry about them), doing low-level checking on the driver’s work (e.g. syntax checking), and paying attention to their direction at a high level.

I suspect that the customer/implementor split could be seen that way, too: you’re either picking what’s most important or implementing the chosen stories. (Or estimating stories; I’m not quite sure how to do that mindfully.) And I suspect a mindful attitude would make it easier to accept the pause in your work caused by the integration process, too.

I guess I’m pushing the analogy a bit far by that last paragraph, and I doubt it’s profitable to explain all XP practices in terms of mindfulness. But I’m pretty sure that there’s something to this at the TDD level: it’s much closer to what I would understand mindful programming to mean than almost anything else I can think of.

interactive interaction with a language

January 21st, 2006

It’s fun having an excuse to interact interactively with a language, as I work through the Learning SQL examples and exercises; almost all of my interaction with languages since I was an undergraduate has been mediated through a compiler, and I’d forgotten what I was missing.

Hmm: I suppose I interact with bash all the time, but most of the time the interactions are so simple that it’s not really the same thing. Then again, interacting with SQL is hardly as rich as interacting with Scheme. And, now that I think of it, I do evaluate Emacs-Lisp expressions in the *scratch* buffer not infrequently, or redefine functions in my .emacs file (.xemacs/init.el, actually, but never mind that) and evaluate them without reloading the whole file. So I guess my life isn’t as barren as I thought when I started this post. The point that interactive interaction with a language can be quite pleasant still stands, though.

shifting cards between people

January 20th, 2006

At our weekly meeting today, my team members had some interesting comments on what had gone wrong over the last week. Among other things, we had planned to work on two 2-point cards; we break up cards that are larger than that, and in the past even cards that size have been problematic. In this case, we didn’t finish (or even come particularly close) to finishing one of the cards, while we breezed through the other card.

In the case of the card that proceeded smoothly, we already had a very clear, eight-step list of the tasks involved in carrying out the card. Normally, one person owns a card from start to finish (frequently pairing with others while working on it, to be sure); in this case, however, the card was owned by three separate people, as our schedules changed. But, because of the clear task list, it was very easy to hand the card off: I was the first owner of the card, and my pair partner and I finished off the first task one morning; I was too busy with other work that afternoon to be able to continue working on it, and one of my team members had just finished his card, so I handed my card off to him. (And he later handed it off to somebody else, perhaps because the latter was working alone in the evening.) Also, while I don’t think we ended up working on tasks in parallel (I was out of the office in manager training most of the week), we would have been able to parallelize many (though not all) of them. This would have been really useful if, for example, we hadn’t gotten around to working on the card at all until the latter part of week: by then, we might not have had enough time to finish the card without parallelizing, but the task breakdown would have allowed us to deploy our resources more flexibly.

We made progress on the other card, but not nearly as much or as quickly. (To be sure, it may have actually been more complex than the first card, despite the fact that both were 2-point cards: the points are just estimates, after all.) Again, it would have been nice to have been able to hand off the card: the card’s owner had to work on something else (something came up that only he could do well: a sign that we still need a bit more knowledge transfer, but that’s another story, and one which we understand better), so it would have really helped if somebody else had been able to easily pick up the work. Unfortunately, the lack of a clear roadmap made that difficult to do. It also would have been nice if we’d been able to parallelize the work, as it became clear that it was a bit trickier than expected; again, doing so was impossible.

So we’ve renewed our agreement that, if possible, we should break up each card into tasks during our weekly planning meeting. And, if we don’t quite understand the details well enough to do so then, then the card owner’s first task should be to come up with an implementation plan which takes the form of a task list. I’m pretty sure this will help us going forward. So, even though we’re not shifting roles as frequently the people on the podcast I discussed last weekend, it does seem that behaving as if we wanted the capability to do so would have some real benefits.

functor moustache

January 20th, 2006

I just got a piece of spam whose subject line was “functor moustache”; for some reason, this amuses me.

paper = air?

January 20th, 2006

The chapters of The Fifth Book of Peace are titled Fire, Paper, Water, and Earth. This, of course, sets up an analogy of paper with air. Which I can relate to, but after thinking about it, it’s either a bit too specific or a bit too general for me.

Words = Air: sure, I can get behind that. But the words I’m writing now aren’t on paper: they’re on a computer. And I don’t necessarily mind reading words on a computer, either: I’d just as soon read an article online as on a computer.

If we make the paper more specific rather than less, I also like Books = Air: one of the determining factors of my last two choices of residence was how many blank walls they had, so we could find places for our bookshelves (and places to add more). Now that I think about it, I rather prefer equating air with books over equating it with words, though I’m having a hard time articulating just why. Maybe it’s because I haven’t spent a disproportionate amount of time trying to actively work with words: I did go through a phase around eighth grade when I was trying to become a writer, but I’ve spent as much or more time working with mathematical concepts, programming, playing music, or trying to understand and improve power relations. So words don’t really stand out in my creative activities. But when it comes to consumption, books have played a much larger role in my life.

I, however, am not Maxine Hong Kingston: she does spend time crafting words. And, again unlike me, she spends time actually crafting words on paper; the thought of doing significant amounts of writing on paper makes my hands cramp. (And I have horrible writing, but am a fast typist. Which doesn’t make my hands cramp as long as I don’t overdo it; mouse usage, however, is another story…)

Editing, though, I do like to do on paper. Which sets up a bit of a disconnect, because I’d just as soon avoid having to print out what I’m working on; perhaps not coincidentally, the Tablet PC was the only Microsoft product that I can think of that has particularly excited me. Not that I’ve used one, but I’m sure that there are UI advances to be had there; and my DS experiences have shown me that I was underestimating the new elements that a touch screen can bring to your experience. Maybe when Apple comes out with something like that, and when display technology has taken another few jumps, I’ll get one…

magical mystery tour

January 19th, 2006

I was just listening to Magical Mystery Tour; what a good album that is. I only got it a year or so ago, when I was rounding out my Beatles collection; somehow it had never entered my consciousness as one of the great Beatles albums. But it really is quite fine; I’d heard most of the songs before (more than half of them are on the blue album, which was my introduction to the Beatles, which is doubtless coloring my reactions here), but I’m getting to like the others as well. (“Your Mother Should Know” is charming.)

Maybe the issue here really is that it’s hard to limit yourself when picking “great Beatles albums”. I might have started by saying Seargent Pepper, Rubber Soul, Revolver, and Abbey Road, but for all I know I’m only saying that because those are the albums I’ve had for the longest; what about the white album? Or Help!? I’m not a big fan of most of their earliest stuff, but after that it’s hard to say no.

shadow of the colossus

January 17th, 2006

Today’s game: Shadow of the Colossus. Developed by the same team that did the excellent Ico, and it shows: Liesl immediately commented on the similarity between the two games’ graphical styles, despite being unaware of the connection.

The gameplay of the two games is quite different, however. This game consists almost entirely of a series of sixteen boss fights, with only the smallest amount of exploration and plot development stringing them together. A paean to boss fights, I initially assumed; not something that necessarily excites me, but I trusted the team to not let me down too badly. I’m not completely against the concept of boss fights, after all: there is something satisfying about staying on your toes and figuring out the boss’s vulnerability, and when done well they can provide a satisfying sense of completion to your recent task. But when done badly, they just annoy me; I’m sure that I have ranted here in the past about how I dislike idea that the final boss fight should require you to first defeat the boss, after which the boss reveals his true form, after defeating which the boss then reveals yet another true form, all without any chance to save. Not the way that I want to spend a few hours of my time; gamefaqs make such battles (usually) bearable, but developers should know better.

Back to the game at hand: I’d been assuming it would be a paean to boss fights, but the reality turned out somewhat differently. Right before the first boss is a section of the environment where you have to climb walls, slide along ledges, jump from one ledge to another: a platformer tutorial area. And then I got to the first boss; lo and behold, fighting him was like playing a platformer, with the difference that the environment moves. Some areas of the boss you can’t climb on, but there are bone ridges that serve as ledges, and fur that you can climb on. (You’re supposed to work your way up to the boss to a glowing spot, which you stab repeatedly with your sword, while he tries to shake you off.) It didn’t feel like any boss fight that I’d ever played: a strange platformer variant, which is a pretty neat idea.

So, over the course of the next few bosses, my opinion changed: it’s not a paean to boss fights, it’s a paean to bosses themselves. It continued to have platformer elements that I’ve never seen in a traditional boss fight, and after a while, you start almost rooting for the bosses: they are noble, glorious creatures, and I started to feel like I was committing a crime against god by killing them. And they are gorgeous, gorgeous: no polygon was spared, the textures are lovingly designed. (The environment is quite nice, too, and I can only hope that the next Zelda will have a horse looking half as good as this one.) There have been some nice looking PS2 games recently; early in the system’s life, I would look at games and think “Soul Calibur looked better than this, and that was a Dreamcast launch game”. No more.

After a while, though, the game elements did start to feel more like traditional boss fights. In a traditional boss fight, you have to observe the boss’s movements, figure out the pattern, and chose the right moment (and method) to attack. Here, you can’t just start climbing up the boss: there aren’t holds on the bosses’ feet, so you need to figure out how to trigger an action which will cause a climbable part to appear, which is a similar way of thinking to a traditional fight. It’s normally much easier to dodge the bosses in this game than in a traditional boss fight, which is all to the good, given the number of fights in this game: rather than dying ten times while trying to figure out a fight and execute properly, I’d play for 45 minutes without dying while trying to figure out a fight and execute properly.

I’m glad the game wasn’t any longer than it was, but honestly I enjoyed it until the end; I wouldn’t have felt unfulfilled if the game had been half the length, but there was enough novelty in the fights to keep me going. (And the bosses are beautiful!) One of the defining games of the end of this generation (which is going out nicely; and we still have the new Zelda and, especially, Okami to look forward to!); it makes me happy that game developers are willing to experiment this way.

i want to build jet engines

January 17th, 2006

This is great. Ricardo Semler would approve. (Found via the XP mailing list.)

(My volume of posts that link to something else with minimal comment of my own has increased; I guess I’m turning into a more normal blogger. Which is okay; I try to have at least one more substantial post on any day I blog, posts like that take very little time for me, and they’re easy for you guys to skip.)

newspaper political coverage

January 17th, 2006

The Mercury News had an article this morning headlined “Gore says Bush broke law in use of wiretaps”. (The link may go stale after a week, alas.) Which really annoyed me for two reasons:

  1. Why can’t the newspapers venture an opinion themselves on whether or not the wiretaps are illegal? This isn’t entirely a straightforward factual matter, but as it is, I get the impression that, if Bush walked into a 7-11, pulled out a gun, and killed everybody there, the papers wouldn’t venture an opinion as to whether or not doing so is illegal: maybe that’s legal for the Commander in Chief, too! (Speaking of which, anybody else like watching Boondocks?) If they think that the legality of the acts is seriously in question, then they should interview experts on the subject, not dance around it or post opinions from random people. Which brings us to my second point:
  2. Who cares what Al Gore thinks? In general, why is their political coverage almost all treated as a combination of partisan fights and personality coverage? If I want that sort of reporting, I can read the sports pages or the entertainment pages. Honestly, much of the time I think the quality of analysis is better in those sections than in the front section: it sure seems to me that the Merc’s movie reviewers take their job more seriously than their political analysts.

Despite all of which, I still think the Merc is probably a better than average paper. Sigh. At least it has a good comics section.

kung pao chicken

January 17th, 2006

If I’m going to post random recipes here (not entirely random – they’re all good!), I suppose I might as well try out other recipes in blogs I read. The kung pao chicken recipe from this blog entry is pretty good, it turns out.

go keith knight

January 17th, 2006

An excellent MLK day celebration. (You’ll probably have to watch a free ad first, though. Which might then dump you at Salon’s home page; I’m not sure.)

mealbox

January 16th, 2006

I like the way this looks. Though I’m not sure how comfortable it would be…

sql schema

January 16th, 2006

Despite my earlier planning, I still haven’t done any work towards switching dbcdb to an SQL backend. Part of this is other things intervening in my life, but most of this is the inertia of starting something new, and that I haven’t broken tasks down enough.

Today is a holiday, so I can spend some of the day programming; let’s tackle those head-on. I did install MySQL a couple of months ago, but I’ve never really used it, and there’s a difference between reading about something and actually using it. So I’ll work through some of the exercises in Learning SQL today.

And the other thing that I’ll do is come up with a schema. I’ll do that in this post; doubtless many of you know more about SQL than I do, so hopefully I can get some useful suggestions.

All the pages are reachable via a unique number: it’s not that books and authors have a separate number 1, but rather item 1 is an author, item 2 is a book, etc. Let’s call these IDs; presumably I need a table mapping IDs to the kind of item they represent. (Is saying the word “mapping” bad form when discussing SQL? Should I say “relating” instead?)

That “kind of item” can just be a number: 1 = book, 2 = author, 3 = series, etc. If I wanted, I could create another table documenting that; should I do so? It’s not clear to me what immediate value it would have; I suppose that, in some future world, I could stick enough information in that table to be able to generically generate the index pages for each type, but that seems pretty far-fetched. So it would only serve as documentation. And, while I have nothing against documentation, it’s not obvious to me that it’s appropriate in this case. I guess a raw number is a bit stark, though; some sort of enum might be more appropriate.

I’ll presumably have one table for each kind of page. What will the author table have on it? The first column will be the ID. And then there’s the name; eventually we’ll want to separate out first and last names (and suffixes (Jr., III), and whether or not the author is Asian, non-Asian, or nonhuman, and probably other things I’ve forgotten), but right now I don’t need that extra information, so let’s just include one name field and refactor things later as necessary.

The page for an individual author also has links to the books and series by that author, but that information is best stored in the book / series tables instead of the author table.

What about books written by multiple authors? The only kind of compound author that is currently supported is a book with two authors, but it will probably be just as easy to design the schema so that it supports an arbitrary number of authors. So I guess I have a table whose first column is the compound author’s ID and whose second column is the ID for one of the individual authors making up the compound author. So a single compound author will be represented by multiple rows, all of whose entries in the first column are identical.

But order matters, too: Fred and George is a different author from George and Fred. We could say that, for Fred and George, the row with Fred’s ID in the second column comes before the row with George’s id in the second column. But does SQL have a notion of “before”? I’m not completely sure. And, if for some reason I wanted to edit the Fred and George entry to change it to, say, Fred, Bill, and George (unlikely, but whatever), then depending on the ordering in the database would make that a little more annoying. So maybe I’ll add a third column, which is the order of the individual within that compound author.

Now we have two tables representing authors, which bothers me a little bit. One possibility: I could add all individual authors to the compound author table: they could be a compound author containing only one author! Being a mathematician, I like using boundary cases like that. (Hmm: the zero-author boundary case is impossible to represent. Do I care? Probably not.) But, after thinking about it for a little while, I’m not so sure: it imposes an extra constraint on the data (that every individual author will also have a row as a compound author), and I don’t like that. I could try reinterpreting the data somehow (the individual author table doesn’t really represent authors, it represents people), but that would just be trying to dance around a real issue.

I guess the deciding factor is that, even if I leave out the one-author compound authors, I can still build up that table by doing a union of select id, id, 1 from the single author table with the multiple author table. Great; as long as I can create it as needed, then no need to stick in those extra rows explicitly. Hmm: is it possible to create a sorted list of authors (once I get the first name, last name split in place) that handles compound authors correctly by doing a single SQL query using that extended compound author table? Not obvious to me how to do it, but my SQL skills are nonexistent; it wouldn’t suprise me at all if it were possible.

One more serious point that arises from my trying to make a distinction between an author and a person: given that I don’t have any authors without any books listed, there’s another way to get the list of all authors from the database, namely by searching the book table and the series table for their author columns. (I’ll talk more about the book and series tables in a bit.) Hmm: maybe I should think of the author table as, in fact, a creator table: an author is somebody in the creator table who happens to have written a book. This isn’t a serious issue now, but it will become so at some point: when I add movies to the table and have my entire book and movie collections indexed, then I’ll want a single page for Hayao Miyazaki that refers to both his movies and the Nausicaa mangas.

If I really believed in that whole-heartedly, then I would probably also include video game developers in the creator table. And I will, again, have to deal with this eventually: I have both the game Katamari Damacy and its soundtrack CD, and I might want to list Namco as a creator for both of them. For now, though, I’ll stick video game developers in a separate table, and refactor as necessary when it comes to that.

Enough about authors; let’s move on to books. Books can have a title, an author, a last read date, a rating, an ISBN, and whether or not I own them. So we’ll have a table whose first column is the ID of the book. The second and third columns will be the title of the book, the third column being either the, a, an, or NULL. (That will help me generate the sorted list of books.) The fourth column will be the author’s ID. The other columns are pretty obvious.

Series will be similar, but will only go as far as title/author.

Ah, but what about volumes? Do I create a separate table for volumes, or do I add a series ID and volume number to the book table? If they’re in separate tables, then the tables will look awfully similar. And I never want to search only for, say, books that aren’t part of any series. And I should be able to go in either direction: if I have a combined table, then I can generate the volume and non-volume tables by searching for entries whose series ID isn’t or is NULL. While I can go in the other direction by sticking a couple of extra columns onto the non-volume table (for series and volume number), sticking an extra column on the volume table (author ID, which is always derived from the series), and doing a union.

I think I’m leaning towards having just one table. But the latter construction does point out one way in which there is unnecessarily duplicated information: if the series ID is non-NULL then the volumes’ author ID should match the series’ author ID. I can live with that; actually, probably what I would do is that, if the series ID is non-NULL, then you’re allowed to have a NULL author ID. (Which will, admittedly, make the mapping of book/volume to author a bit more complicated than it would otherwise be.) Also, it would open up the door to series where different volumes have different authors; doubtless there are examples of that on my bookshelf somewhere. Or maybe not; I’ve never been that into shared-world series, which is the obvious example. (There are certainly non-fiction examples where my current notion of series will have to be rethought, e.g. Springer GTM’s.)

Looking at all that info, I could still go either way. What do other people think, and why? This is clearly a situation where I could use help from people with more database design expertise.

Once I’ve got those in place (either as one or two tables; I can break them up or put them together if necessary anyways), can I generate a sorted list of books? That shouldn’t be too bad; I can create a four-column table with ID, name body, name prefix, volume suffix, and sort it using the last three columns.

Series should be pretty similar to books. And I don’t think video game systems, video game developers, and video games add much in the way of additional complication. (Other than the aforementioned issue of whether developers and authors should be lumped together as creators.)

I guess one further issue would be whether I should try to extract out the common fields in books and video games to a separate table. (Last read/played date, rating, whether or not I own it, ISBN/ASIN.) This is represented by a common class in the Java code; should the database match the code in that respect? I can’t think of any obvious reason to do so; for example, I can’t think of any situation when I would want to search that joint table. (I don’t, for example, want to produce a “media recently consumed” table. Though, now that I think about it, doing so could be sort of interesting. Hmm.) I guess I’ll just have similar fields in the book table and the video game table, then.

And how long should my strings be? When programming, I don’t like having arbitrary size limits in my code. But that’s not an option in SQL: I have to decide if I want the length of my strings to be 8 bits, 16 bits, 24 bits, 32 bits, or what. (64 bits!) 16 bits is certaintly enough, but I can’t think of any books I own with more than 255 characters in their name. So maybe I’ll go with 8 bits, and feel a little dirty.

Phew; that was a lot of typing. Congratulations to anybody who has read this far, and please give me any suggestions you might have. No wonder I ran into programmer’s block, if just doing a rough draft of the database schema took this much time. And I still have book exercises to work through; I’m not sure if I’ll finish all of those today (I don’t plan to spend all day typing, after all), but I should at least get started. I should also add investigating JDBC to the list somewhere.

Random question: do people say “database schemas” or “database schemata” more frequently? Google suggests the former. Is there any distinction between people who say one and people who say the other? I guess I don’t have to decide which camp I’m in until I’ve written two of the beasts…

fair use report

January 14th, 2006

I finally got around to reading this report on fair use from the Brennan Center. (Which I heard about here.) Quite good.

two recent books on writing

January 14th, 2006

Two authors I respect, Gerald Weinberg and Samuel R. Delany, have both recently published books on writing. I haven’t read either of them yet (other than the lengthy introduction to the latter in a recent New York Review of Science Fiction), but I bet they’re both well worth reading. Johanna Rothman recommends the former.

hiring-related take on alito hearings

January 14th, 2006

I didn’t actually watch or listen to the Alito hearings, but I liked Johanna Rothman’s take on the subject. Compare it to her other post her hiring blog that day.

task ownership

January 14th, 2006

One of the most interesting entries for me on the Agile Toolkit podcast is the one on promiscuous pairing and the least qualified implementor. What the interviewee proposes is that, when starting on a card, the person who knows the least about it should work on the card, pairing with somebody who knows more about the topic at hand. The group should change pairs every two hours; each time, the expert works on a different card, while the former novice takes up the expert role (since he now knows more about the task at hand), and pairs with the person in the group who now knows the least about the task. So there’s no one owner for the card: instead, different people in the group work on it for four hours, in the novice role for two hours and in the expert role for two hours.

He has data to back this up, too. His team has measured its velocity using different pairing strategies and lengths, and, for example, has a significantly higher velocity when rotating pairs every two hours than when using a longer pairing duration. Hearing about these was a warning sign for me: until a few months ago, points in our group corresponded to actual time spent rather than a given story difficulty, which meant that it was impossible to measure velocity improvements (since actual time spent didn’t change). To be honest, right now it’s not clear to me how stable our point estimates are, but at least it’s conceivable that we could measure velocity differences, which makes the scientist in me happy.

Anyways, I mentioned it to my team, but got a lukewarm response; their attitude was that if I felt strongly about this, then we could give it a try, but they didn’t seem too excited. And I didn’t feel too strongly about it, so we let it slide. It did leave one idea, though: before, at each weekly planning session, we’d divided up the cards so every card had an owner. But this podcast suggested that doing so wasn’t essential. What we ended up trying was having each person pick one card that they owned, but leaving the extra cards unowned; then, when somebody finished a card, they could pick a card from the unowned stack. (Or just pair with somebody else for a while, of course.) Cards can also change owners; that’s somewhat rare, but I did hand my card off to another team member yesterday, since I was busy yesterday afternoon (and will be in manager training next week; we’ll see what I learn there!) and he had just finished his card.

The first few weeks were a little chaotic, but our velocity has actually been rising since we made that change. To be sure, I have no reason to believe that this change was the trigger for the velocity improvement: we might have been in a period of abnormally low velocity before the change. That was a month where we were working on several new areas of the code, and we had underestimated the learning curve necessary; we made this change at around the time that we started to get a handle on the new areas. Still, at least it’s evidence that not dividing up all the cards at the start doesn’t hurt our velocity! And I personally prefer the new way of working: focus on a card, get it done, and take stock of the whole team’s status once you’re done with that card, to see how your efforts could best be directed at that point. This ‘limiting your focus’ idea shows up all over the place in agile work, to good effect.

address book

January 12th, 2006

So I was just ordering a book for my dad’s birthday. (Cartographica Extraordinaire; I haven’t looked at it, but it’s recommended here.) Amazon was incorrectly claming that it hadn’t been published, and the publisher’s web site was a little strange, so I didn’t feel like ordering from either of them.

After a few days of checking on Amazon, I remembered that other online bookstores exist, so I went to order through Barnes and Noble. It claimed that they could ship it within 24 hours, so I went ahead with ordering it there. After a bit, I got to the place where I had to enter my Dad’s current mailing address; I was pretty sure I knew it, but I wanted to double-check.

So I was about to go and get my address book out of my backback, when I realized there was a faster way: I went over to Amazon’s web site and got it off of my list of shipping addresses there. Yay.

This probably says something (about me, about the web), but I’m not sure quite what. Among other things, it says that I use computers, but am not in the habit of storing certain kinds of information on them that many other people are; call me Mr. Backwards. But I happily give all my information away to Amazon. Or not so happily in some cases, which is one of the motivators for my dbcdb project, but in this particular instance it was useful.