malvasia bianca

• As presentations about how the world is changing go, this one is well done.
• An excellent use of Post-It notes.
• An assembly line moving two inches a minute.
• Sprout is a delightful way to spend half an hour or so. You’re a seed that learns to grow up into different plants, which you use as a way to move: coconuts roll, dandelions blow on the wind, etc.
• The Super Mario Bros. theme, played by its creator.
• Lost Garden on waterfall, agile, and “stage gate”. Where the latter looks a lot like some of what’s in lean software development but not traditional agile: see the Poppendieck’s discussion of funding models and of set-based design.

Wii Sports is supposed to be key to the system’s mass appeal. Rather than targeting gamers, it’s designed to appeal to everybody; rather than forcing you to control the game by manipulating two joysticks, a D-pad, six face buttons, and four shoulder buttons, it lets you just swing the controller back and forth. (Side note: one thing that wasn’t clear to me in the early coverage of the system was that the controller contains two unusual motion detection devices: there’s something that can tell where on the screen you’re pointing it (if you’re pointing it at the screen, at least), and there’s an accelerometer, to tell whether/how you’re swinging it around. This game only uses the latter (except for interacting with menus and the like). The nunchuck attachment also has an accelerometer; this game uses that for boxing, so it can tell whether or not each hand is punching.) Designed for easy accessibility, designed for multiplayer, designed to convince people who wouldn’t think of buying an Xbox to buy a Wii, after some friend or relative has forced a controller into their hand and they’ve achieved enlightenment.

Or something like that. I don’t know if I believe all the hype, but the console is continuing to sell, and Wii Sports doubtless has a lot to do with it. While my parents were here over Christmas, I did play it a few times with my dad and with Miranda; my dad wasn’t planning to buy a Wii when he got home or anything, but he did seem to be enjoying himself. Then again, I’m sure he would have enjoyed doing a lot of things with the two of us.

Tennis was our favorite game of the lot. Let me be very clear: this is not at all a sim. It’s doubles tennis (with one player in charge of two miis if you’re playing with less than four people), with the computer controlling movement: your sole responsibility is to swing at a not-too-inappropriate time. And if you swing too early, well, swing again: your mii will franticly double-take, flail, dive for the ball, leap, whatever as is required. Which looks very silly indeed on the screen, especially the dives. I smiled and laughed basically the whole time while playing the game; it really was a lot of fun.

Bowling is much more of a sim. To the extent that, at first, it was a little uncomfortable: I was trying to make natural bowling movements, but without a 15-pound ball at the end of my arm, my elbow started feeling a bit odd. I’m used to that now, though. I think this is Miranda’s favorite of the games; right now, actually, she’s better than I am, though I hope to close the gap now that I’ve given up on trying to put just the right spin on the ball. (I don’t do that in real life; why try in the game?)

She finds golf frustrating, but I think it’s pretty good. It certainly requires the most finesse of any of the games; sometimes, alas, it requires more finesse than the controller is capable of. Putting, in particular, can be a bit much: the controller seems unable to detect very small swings, so tap-ins, rather than being completely routine, turn into an annoying task of making very small swings to try to get the minimum strength that the controller registers, lest you end up several feet away on the other side. There are similar problems with chip shots near the green. Still, I enjoyed it; if I were to play the game more, golf might end up being the mode where I’d spend the most time.

Baseball and boxing, however, seemed more or less pointless. Baseball in particular seemed like a quite bad translation of the game.

Fun stuff; I’m not planning to play any more of it by myself, but I’ll happily pull it out whenever guests come over. After, of course, forcing them to make miis of themselves; I continue to think that miis are a great idea, exactly for games like this.

And no, we didn’t launch any wii remotes into our television screen, or indeed launch them at all. We did whack them a few times on furniture that was nearby, but they turned out to be sturdy enough to survive that. Good thing, too, considering how expensive they are and how hard they were to find…

[ I apologize for all the acronyms in the first paragraph of the post. I will explain what one of them means over the course of this entry, but if you’re here for, say, video game thoughts instead of technical geekery, then you would be correct in interpreting that as a sign that you should hit the ‘next’ button in your blog reader. ]

One of my team’s current projects at work is replacing a CORBA interface for managing video files with an interface involving sending XML over HTTP. We’ve looked at a few examples of XML/HTTP interfaces recently – we considered integrating a few areas of our software with a very simple hand-rolled RPC mechanism last year, and we’re also integrating a different part of our software with a SOAP interface right now. But one of my coworkers said “shouldn’t we look at REST?” in our team meeting on Thursday. And since all the cool bloggers are now spending their time talking about how REST is good and SOAP is bad, I thought that was a great idea: if nothing else, I was already rather embarrassed that I had no idea what REST meant, and it would give me an excuse to learn! So I spent a quite pleasant afternoon yesterday learning about it, and coming up with a RESTful version of the interface in question.

But before I explain what REST means, some Kealia history. The software-side founder of Kealia insisted that we follow a programming discipline he (I believe) invented called “attribute-oriented programming”. The idea here is that your object interfaces shouldn’t have any verbs: the interface should consist entirely of attribute getters and setters. So whenever you have a verb that you want to add to your interface, you have to think of a way to express this as changing the value of an attribute. Frequently, this isn’t too hard (though it’s still often distasteful): you might replace a schedule() function with a nextTime() setter. Other times, it’s much more of a stretch: sort() is an example.

There are a few special exceptions allowed. The one that’s relevant to this discussion is that, if you want to add or remove something to/from a collection, then you should call a function named newXXX() or deleteXXX(). (And there are also some extra restrictions layered on top of this, but I won’t go into them here.)

Attribute-oriented programming turns out not to work very well. We still follow the rules, despite the departure of their proponent from active work on the project, because of a general feeling that we’d rather consistently follow a bad standard than mostly follow a bad standard but occasionally do whatever we feel like. (Though I personally would support a thoughtful effort to relax the rules in appropriate circumstances; it’s hard to make a good case for spending time on that, but every new hire is a reason to ask that question again.)

Despite my dislike for the attribute-oriented philosophy, there are some good things that go with it. We have a custom network layer for internal use: it’s specialized for sending out high-performance attribute updates. (Basically, Observer across the network; there are some other things grafted onto it, but I won’t go there.) Not great for a general purpose RPC system, but most of the time in this project, we don’t need a general purpose RPC system: instead, there are several crucial places in our code where we want to spit out lots of little state changes very quickly over the network, where this works quite well. It still takes a while for new hires to come up to speed, but this is one area where I think we made a good choice. (It’s not perfect – some of the details are pretty weird – but, well, if you’re waiting for perfection, you’ll have to wait a while.)

Which brings us to REST. REST (short for REpresentational State Transfer) is a philosophy that says that, if you’re trying to do RPCs over HTTP, you should work with the idioms of HTTP, instead of using it to tunnel general RPC ideas. To begin with, HTTP says that objects should be identified by URIs. (As opposed to, say, sticking an object identifier in the body of the message somewhere, or in some CGI parameter.) And HTTP provides you with four verbs: GET is the most common (your browser uses it every time it fetches a web page), POST is not infrequent (you use it when filling out forms), but there are also PUT and DELETE.

This turns out to map extremely well with attribute-oriented programming: GET and PUT are attribute readers and writers, POST and DELETE are the newXXX and deleteXXX on collections. (It seems that REST proponents are willing to use POST in a somewhat more flexible fashion than that, actually, but I won’t go into that now; certainly the sweet spot for POST seems to be the same.) It also maps extremely well to concepts in other areas: those of you who aren’t my coworkers have, I assume, never heard of attribute-oriented programming, but you’ve all heard of databases. And database people talk about Create, Read, Update, Delete (CRUD), which are POST, GET, PUT, and DELETE.

I don’t want to go into the details of the arguments, but the REST proponents sound reasonable to me: if you want to provide a programmatic interface for a service over the internet, you’ll have an easier time doing it if you can learn from the single most phenomenally successful example of such a beast. (Especially if you’re using that example’s underlying protocol to do your communication!) Network programming is different from and harder than writing a standalone program; learn from the lessons of the past, work with successful idioms, and you’ll avoid many mistakes and find it easier to grow an ecosystem around your service.

And certainly the interface that I’m thinking about at work fits fine within this framework. Let’s say that we have a URL http://foo.com/video/ that represents all the video stored on the server. Then, to upload some new video, do a POST to http://foo.com/video/. This will return a URL representing the new file, say, http://foo.com/video/my-movie. If someone else wants to learn something about the movie, that person (or program!) can do a GET to that URL or to some URL lying off of it: if you want to find its duration, for example, maybe GET from http://foo.com/video/my-movie/duration, or maybe just GET from http://foo.com/video/my-movie itself (which could return an XML object containing the duration as an attribute or an element).

(Incidentally, the details of that last example are what is currently giving me the most trouble. Which URL is the right one to use? If we go with the shorter one, is an attribute or an element more appropriate? For now, I’m leaning to initially using the shorter URL, and using an attribute, but I don’t see much different either way. I’m not immersed enough in XML to know when attributes are idiomatic and when elements are idiomatic in cases like this, alas…)

So that’s two of the verbs. If you then want to remove a video, just send a DELETE request to its URL. And if you want to change some attribute, do a PUT: if you made a typo in the director’s name in your initial POST, for example, you could PUT the new value to http://foo.com/video/my-movie/director.

Fun stuff, this. I didn’t have to think much at all when designing the RESTful version of this interface: many of the decisions were already made for me, and I never had to fight REST, so I can be reasonably confident that other people will find the interface useable. Certainly the result is very simple; much more so than the SOAP example I was looking at. (Even at the surface level, though admittedly we’re solving a simpler problem; the actual underlying XML in that example made me rather nauseous.) The other model we’d been looking at (hand-rolled XML over HTTP, always using POST) was nice and simple, but the REST example is a little more coherent, and required us to make fewer decisions. (And I expect other people will find it a little easier to work with, at least if they’re not too RPC-immersed.)

The upshot is that I can follow certain discussions more intelligently than I could before, I have a good candidate for our new interface, and I have some new insights into the strengths and weaknesses of the way I’ve had to program for the last four years. (Speaking of which, yesterday was the three year anniversity of Kealia’s acquisition by Sun; I am amazed at how quickly the time has gone by.)

I leave you with a quote by Roy Fielding, the originator of REST, on SOAP (and other related protocols):

SOAP … deliberately attempts to suck.

I was pretty nonplussed when I first started playing Elebits. It’s sort of a weird mix of Katamari with a first-person shooter: on the one hand, you have a gun that you use to “capture” these elebit creatures that are hiding and running around, but on the other hand you can also use the gun to pick up various pieces of your environment and in general cause mayhem and wreak havoc.

The problem is, I don’t particularly like first-person shooters. And, at first, it really did feel like an FPS to me: maybe you’re capturing the elebits instead of killing them, but I sure can’t tell the difference. Playing around with the environment was sort of fun, but not all that great: it’s nice to be able to wander around a few rooms in a house grabbing items off of cupboards, and then, as you power up, throw the cupboard itself around, but I wasn’t really getting into it.

After a few levels, though, I realized that I was being unfair as labelling it as an FPS. After all, one key feature of an FPS is that the people you are shooting are shooting you back; that’s not the case in this game. Ironically, though, as I was realizing this, I came across a level where there were a few toy tanks that really were shooting at you; to make things worse, I couldn’t kill (sorry, “capture”) them! I may not always be thrilled with shooting people who are shooting back, but I like being shot at and not being able to shoot back even less. A few levels later, I figured out that, if you turned them on their side, they would stop shooting me, but it took me a while.

Admittedly, there weren’t enough guns for that to be a serious annoyance, and the guns didn’t show up on every level. Unfortunately, that annoyance was followed by levels with different annoyances: in some levels, you can only break so many objects, in others you can only make so much noise. Given that (the good aspect of) this game is about wreaking havoc on your environment, that was just frustrating: I’m all for judicious imposition of limitations in games, but those impositions shouldn’t be directly at odds with what makes the game fun!

At this point, my gentle readers may wonder why I continued playing the game. (And my less gentle readers are writing me off as a wuss, I suppose.) Around level 7 or 8, a few things happened to change my opinion of the game. The most important thing was that I managed to get out of the house, to the back yard. Inside the house, there was only so much scope to wreak havoc: you could work your way up to cabinets, but that was about it. Outside the house, though, you got to where you could toss around shrubbery with abandon fairly quickly, and start to see the possibility of throwing around cars and the like. And soon after that, you got to wander around the neighborhood; cars, light posts, you name it were fair game, and you started to look at houses in a new light.

The second thing is that I upped the sensitivity in the controls to the max. You use the wiimote to both aim and turn, but you only turn if the cursor is near the edge of the screen. (And you use the joystick on the nunchuck to move; it’s a Wii translation of mouse and keyboard FPS controls.) This worked okay, but it wasn’t as fluid as I would have liked. When you up the sensitity, however, the area where you aim but don’t turn got a lot smaller, and the controls started to feel very nice. I may be ambivalent about FPSes, but I appreciate good controls when I see them: I suspect that, as developers get used to the Wii, it will have the best FPS control scheme of any console.

After that, I was happy to play through the rest of the game. And, even setting aside the pleasant environmental mayhem, the game is based on a single, solid mechanism. You use your capture gun to manipulate the environment and to capture elebits; as you capture elebits, you turn on interactive aspects of your environments (usually meaning no more than buttons you can press to turn on machinery). When you activate that machinery, special elebits come out that let you power up your capture gun, allowing you to lift heavier things. And that, in turn, lets you find more elebits, leading to another cycle of turning on machines, etc. A nice, simple reinforcing cycle, and they did a good job of balancing the need to search through the environment carefully to find elebits without requiring you to be insanely thorough about that.

All in all, a pleasant game, with some good aspects, some interesting aspects. So I’m happy to have played it, but also happy that it didn’t last longer than it did. There were some dubious design choices, but ultimately nothing that was really bad; there was a touch of the Katamari genius, but not quite enough to grab me. (One aspect of the Katamari genius was completely lacking, though: the music sucked.) And it was a welcome sign that the Wii controls may end up working very well for some traditional game genres, not just for new ones.

• Housing prices as shown on a roller coaster. I had no idea that the ups and downs had been so small until recently.
• An Agile Toolkit interview about movie making. (This one had some interesting non-programming analogies, too.
• Go Steve!
• Different ways of looking at the world.

Phoenix Wright: Ace Attorney is an old-style courtroom-based adventure game for the DS. It’s set in the near future, and apparently legal norms have changed somewhat: as far as I can tell, rather than people being innocent until proven guilty, they’re guilty unless you can prove during the (at most three-day trial) that some specific other person committed the crime.

This would seem to be a bit of a tall order. Fortunately, it also turns out that the real guilty parties love to appear as witnesses in court cases, so you have a chance at catching them in some sort of contradiction, after which everything starts to unravel. At least if you don’t try the judge’s patience too much.

The mechanics of the game alternate between evidence gathering and courtroom scenes. In the former, you wander around various areas (the scene of the crime, related locations, police offices, etc.) gathering evidence (i.e. touching various parts of the environment) and talking to people; in the latter, you cross-examine witnesses, pressing them on various points, whipping out evidence that contradicts them, and the like.

And it’s fabulous. It’s witty: the characters are funny, the situations are pleasantly outlandish, but with enough internal consistency to have it cohere nicely. I inadvertently laughed out loud once during the game (at the end of the third case, for those of you who have played it), and was quietly amused many more times. There’s a plot connecting the various cases, with enough surprises to keep me interested. I liked how they (completely inappropriately) reused character sprites from the evidence gathering phase in the courtroom phase (e.g. the hotel bellboy carrying a tray with a tea set on it); I liked the over-the-top reactions to courtroom triumphs and setbacks, coupled with animations that would be in place in a 2D fighter.

The gameplay mechanics were also solid. Liesl and I managed to finish it without having to resort to gamefaqs, which is quite an accomplishment for a traditional adventure game. There were, admittedly, situations where we mostly had to guess at which piece of evidence to present – various pieces seemed relevant, and we couldn’t quite figure out which one the game was expecting at a given juncture – but there weren’t so many of those as to be really oppresive, and, in retrospect, I often felt that I could have figured it out on my own. (Fortunately, you can basically save at any time, so if you get really stuck, you can just do an exhaustive search without worrying about the judge punishing you.) There were a couple of times when cases went a bit far outside the game’s internal logic – in particular, I was a bit nonplussed by the time when the judge went as far as declaring your client guilty before a deus ex machina dropped in – but it didn’t abuse that sort of thing too often.

I don’t quite understand why it didn’t have multiple save slots – save data must take up all of 100 bytes or so. As it was, one person had to finish a given episode before the next person could try it. Fortunately, in our case, the first person trying each episode managed to finish it without needing outside help, so that wasn’t a huge barrier.

It’s now my favorite DS game. (Though I’m not sure I’d feel that way if the DS Animal Crossing had been my introduction to that series.) Which, admittedly, says as much about the DS as it does about this game: while I’m glad I got the console (I need a portable console, and the DS is clearly a better choice for me than the PSP), there just haven’t been that many traditional great games on it. Of course, games on portable consoles are by nature less ambitious than their tv console brethren, but that’s not entirely an inherit limitation: in particular, the two Golden Sun games are some of my favorite games ever.

Having said that, this game is exactly what is so wonderful about the DS, and what more publishers should take as a lesson. It’s a traditional adventure game, with a simple engine, simple artwork, and a fair number of words. A very small team should be able to pull this out: I could imagine a single programmer, a single artist, a single writer (plus help with music, playtesting, etc. as needed) pulling this off in half a year. You’d want that artist and writer to be quite talented, because they make or break a game like this, but the overall development costs for this game must have been a hundredth the costs of a top-flight Xbox 360 game, say. At that price, you don’t need to appeal to everybody: if you have a vision that’s well-executed that will appeal to a niche market, that’s enough to make a successful product. Which is apparently the case here – the series is on its fourth iteration in Japan, I believe, two of which have come out so far in the US, and other publishers have noticed and started to put out their own entries in the genre.

Those of you who think the industry is forgetting its past, or those of you who like to read, take heart. And, as I have said before: go Capcom.

I turned on Akismet a little more than a month ago; since then, it’s caught just shy of 20,000 spam comments for me, or just under 600 a day, allowing less than five a day to make it through. I haven’t noticed any false positives yet (though admittedly I get a low enough rate of comments that that doesn’t mean as much as it might); all in all, I’m extremely pleased.

The volume of spam is high enough that I frequently am unable to thoroughly examine the spam queue before clearing it out. So if you submit a comment and it hasn’t been approved by the next time I post, please let me know. As is, though, I’m almost inclined to stop examining the spam queue at all and just trust Akismet to not screw up. I would definitely be willing to pay money for this.

I was kind of looking forward to the Xbox 360 Elite announcement. I’m almost positive I’ll buy a 360 at some point this year: I doubt the Wii and DS will be enough to keep me happy this year, and it even seems likely that the 360 willl have more games I’m really interested in this year than any other console. In fact, it looks like the first must-have 360 game for me will show up next month (Mass Effect, by the makers of the excellent Jade Empire), and while the first half of this year is looking abnormally strong game-wise, so I might not need to rush out immediately to buy it, I’ll probably be bored if I don’t buy it at some point over the summer.

But I’d rather not pay $400 for a console, and by all accounts a shockingly high proportion of the consoles break. Surely a redesign is a sign that they’ll drop prices, and maybe give us a signal that their manufacturing has improved somehow?

No, it turns out: they’re keeping the prices of existing models the same, just adding a new model on top. With a strange price point and set of features: I for one don’t care in the slightest about HDMI outputs, and while there are people out there who do, it seems like those people would look at an 360 for $480 and a PS3 for $500/600, and shell out the extra money to get a Blu-ray player. The business logic behind making your console look more like your surprisingly unsuccessful competitor, and doing so in a way as to maximize the likelihood of negative comparisons, escapes me. But what do I know?

No matter the price, I clearly wasn’t getting the Elite, but I could have done with a price drop. As far as quality goes, the initial comment from Microsoft along the lines of “our other models have crap quality but the new one will be better” didn’t impress me too much. A day or two ago, though, they announced that they were improving the warranty terms: now, if it breaks within the first year, they’ll repair it at no cost (including free shipping) and have it back within 5 days.

I suppose I’ll grudgingly shell out 400 bucks for one at some point this summer. Which would seem to be evidence that their strategy of not lowering the price is paying off, at least in this case. I would say that I’m not sure I’m representative, but maybe I am: if other people agree that the 360 is coming into its own this year, then Microsoft probably should hold off on price drops. I guess their feeling is that they aren’t likely to win over many Wii buyers, that they still have compelling advantages over Sony, and that they like actually not losing money on consoles, so no sense dropping their price until Sony does. Not sure they’re making the right choice, but in the grand scheme of things it’s really not my problem.

There had been rumors at the end of last year that, some time this year, EMI would allow non-DRM versions of its music to be sold online, so I wasn’t completely shocked by the recent announcement. But I was still surprised, and surprised it happened so early. Nice to see one record company behaving sanely. (Or at least behaving in the way I’d like them to; the jury is certainly still out on whether or not it will help their business goals.)

The details are a little interesting: bundling no DRM with a higher quality and a higher price point. The higher price point is obvious enough, and I’m glad it’s only for singles instead of albums; I’m curious how the higher quality came to be, though. Was Apple arguing for a single price point, EMI wanted a higher one, and Apple relented if they’d raise the quality? Does somebody have an interest in muddying the experiment, to make it harder to tell the effects of no DRM alone? Had Apple been wanting to raise prices all along, and this was a way they could do it without losing face? Could it be some strange way to make it easier to track illegal copies of the non-DRM music purchased in this manner? (That would really be stretching it.) Did somebody just decide that higher bit rates are good, and this is where they’d introduce it? I’m betting that this linkage is a face-saving gesture somehow, I just can’t figure out the details.

I would say that this makes me want to go out and buy more EMI music, but it really doesn’t. For one thing, I buy music based on what I want to listen to rather than the publisher, and for another thing, my preferred medium of purchase remains CDs. This will have an effect on my purchasing habits if/when indy publishers are allowed to sell non-DRM music through iTunes, however: it occasionally happens that I learn about a band through Next Big Hit and am unable to purchase their music on a CD. Until now, that’s meant that I won’t purchase their music at all (though I might give in and sign up for one of these MP3 subscription services at some point), but I would be willing to purchase their music on iTunes under the new rules. Who knows, maybe at some point I’ll give up on my “only buy albums” philosophy, and start buying individual tracks as well.

Since I finished rereading the Earthsea books more than a month ago, I suppose it’s time for me to say something about them. To be honest, I’m feeling a little intimidated by what I wrote last time; I should have done a better job of taking notes right after finishing the books. Ah well.

I don’t think I have anything to add about the first four books. A Wizard of Earthsea is still my favorite of the series; I imagine it will be comfort reading for me until the day I die. And Tehanu is still my next favorite, and I like The Tombs of Atuan and The Farthest Shore more than I did when I was a kid.

And the question remains: after Tehanu, what next? I’m happy to accept the notion that the sayings “weak as woman’s magic” and “wicked as women’s magic” are signs of sexism instead of accurate representations of how magic works in the world: that’s the way these things normally work in real life, after all. But how do we make an interesting story starting from that? What else about our understanding of the world might need to change? And what do we do with the human/dragon story from Tehanu?

The obvious thing to do (at least about the notion that women are as talented in magic as men) would be to write a story about a girl going to school at Roke, being confronted with prejudice, and valiantly overcoming it. Which is all well and good, but I’m glad Le Guin didn’t go that route; it would be rather too straightforward. Alternatively, I’m sure there could be interesting stories written that take their example from, say, battles in the US over the last century or two over this issue, but that really doesn’t excite me too much, either.

Which means, I guess, that we’re left with picking at that and other loose ends, enlarging the scope of the differences, and seeing what happens. Tales from Earthsea is a transition book in this regard. Three of the stories are really quite charming, without any obvious grand ambitions (though gender issues certainly play a role in them). One (re?)writes the early history of Earthsea and Roke, in ways that I find unsatisfactory (if only because it’s supposed to take place a mere three centuries earlier). And one looks like a straightforward “girl overcoming prejudice” story, and then pulls out another dragon at the end.

Which brings us to The Other Wind. Did I really write my previous notes before reading that book? If so, I’m impressed: the Kargad problem is, indeed front and center. (Quite possibly I wrote some of the notes after reading that book, though, and just ran out of steam before talking about it explicitly.) In particular, harmonizing the Kargad belief in reincarnation with others’ belief (and, in fact, direct experience of) a (rather depressing) afterlife is, well, important but a bit difficult, no?

And Le Guin obviously felt the difficulty. One thing that occurs somewhere in the last two books: magicians are talking about what happens if you start to cast a spell and then have second thoughts. You can’t just stop and pretend that you didn’t say anything: instead, you have to explicitly undo the partial spell that you’ve spoken. Which is what Le Guin is doing here: the afterlife that played such a large role in the first and third books turns out to be a mistake, an artificial construct that has to be undone.

Which she does. And she does it well, unweaving the various plot strands that were out of place, reweaving them into a newly coherent whole. I enjoyed the book much more than most books I read, and more than its predecessor.

But there’s a real cost, too: the strands she unwove were quite deeply embedded into the fabric of the story. So even though I’m willing to accept that those strands were out of place, she’s had to reweave vast amounts of a fabric that I (and others) have known and loved for decades. That is a loss by itself; I don’t have enough experience with the new fabric to have any confidence that it’s an improvement.

I hope that, the next time I reread these, I actually remember what goes on in the fifth and sixth books, so I’ll be able to reread them with a more critical eye. Maybe I’ll like them more next time (it happened before with Tehanu); I suspect, however, that I’ll continue to be uneasy with them.

(Are more Earthsea books coming? Hard to see what she would do next; I’m not sure the world could survive another earthquake like this.)

For the non-EU flights in Schiphol (at least where we were), they place a metal detector at each gate, instead of having a central bank of metal detectors that everybody goes through. And I can’t figure out why. This seems like the worst possible solution from a queuing theory point of view: you get your best utilization when you spread out the arrival of people into queues, but what they do instead is to artificially delay people from entering the queue and then process everybody all at once. Which means that it takes ages to actually get onto the plane once they start calling rows.

So what’s going on here? Imagine if they took those metal detectors and put them all in a big, shared bank: you’d show up, there would be a hundred or so metal detectors that you’d go through, and you’d never have to wait in line for more than a minute or two, I’d imagine. So what benefit do they get out of their current arrangement? Does it somehow use staff more efficiently? If there is any gain there, I don’t think it’s a huge one, and I’m sure they could improve both time and staffing with a smaller number of shared metal detectors. Is there some benefit in having most of the airport before the metal detectors instead of after metal detectors? Yes, I suppose, since you can actually see your friends and family off at the gate; I’ve gotten so used to not being able to do that that it hardly registered, but I guess that’s a good idea. Is there something about the construction of the airport that makes a shared bank (or multiple shared banks) of metal detectors impractical? Not clear to me one way or another. Something else I’m missing? Or is it just a mistake?

I now have braces. Or a brace, perhaps I should say: it’s only on my lower jaw. Not for cosmetic reasons: though I am, of course, shockingly vain, my teeth are really pretty straight. But I’ve had annoying amounts of buildup behind my lower front teeth for years now, and even going to the dentist three times a year hasn’t been good enough. (As measured by the discomfort I feel during cleanings.) They suggested braces, and the teeth in question are a bit crowded together and don’t line up as straight as they could; in the past the dentists in my current office haven’t seemed to be excessively inclined to fleecing me (certainly loads better than my previous dentist), so I thought I’d give it a chance. Still, I don’t know if I’m being stupid here or not. Or maybe it will work but I’m getting most of the benefits just out of the slight shaving of the sides of the teeth that they just did – it’s much easier to floss already.

I decided to go with Invisalign – like I said, I’m shockingly vain. It popped right on; I pop it off for eating, but other than that I’m supposed to wear it all the time. Which seems okay – actually, the most annoying affect is that, because I’m brushing my teeth right after eating all of a sudden, it means that most of the day my mouth tastes like toothpaste. And I miss snacking. But I can deal, and it should only last about five months: I’ll have ten sets of molds for my teeth, changing them every two weeks, getting progressively straighter and straighter. Nice technology.

What a glorious day yesterday was: the seventh Hikaru No Go DVD came out, and the ninth book. And now I have to wait another two months for the next DVD, another four months for the next book. Aargh!

We finished the DVD today, after which Miranda asked me if we could play through the ear-reddening game. So we did. Funny what she remembers me telling her about; it’s not like we’ve actually played go since I first taught her several months ago. She’s asked twice if we can play again this weekend, though.

The CD database that Max uses lists the artist for Deep Voices as “Various Whales”. Yay.

Last week, I went to a talk by Mike Cohn on “Agile Estimating and Planning”. Good timing: I’d been thinking that I should get around to reading his book on the subject. Which I won a copy of at the drawing after the talk; apparently my recent remarkable good luck has (correctly) decided that I have enough iPods and should start winning other things instead.

I’d gotten my previous take on the subject from others’ books and from a presentation by Ron Jeffries; back when (a previous incarnation of) my team used to estimate regularly, we followed Ron’s 1-point, 2-point, 3-point idea. (Well, we did until we dropped 3 and added 1/2, but the result is almost the same thing.) Mike Cohn, however, uses much larger numbers: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100.

That’s for story points; he recommends estimating tasks within stories in terms of hours. (I can’t remember if Ron talked about estimating tasks at all.) And he made a good point about why you should use artificial points instead of real time units for your story estimations: if you use real time for both, you’ll be tempted to expect, say, the time estimated for the tasks making up a story to add up to the time for the entire story. Which makes sense, except that you estimate a story before you’ve broken it up into tasks (you don’t do the latter until somebody has decided that you’ll work on it), so when you do the task estimation, you’ll have thought much more about what’s involved in implementing the story. And you can’t convert between “hours that you’ve thought a lot about” and “hours that you haven’t thought much about”, which you’d be sorely tempted to do if you use hours in both situations.

Mike came about his expertise on the subject honestly, by the way: he was VP of engineering at a company that had adopted Scrum, and that had a fair number of teams working on not-very-long-lived projects. So teams had to estimate stuff, and he imposed the rule that, each project, you had to do something different when you estimated. There was enough discussion going around that people had an idea of what teams with accurate estimates had done in the past, but the rule meant that they couldn’t just stop and declare victory, they had to keep on trying to find ways to improve. A nice example of evolutionary process improvement.

Anyways, after the talk, I asked him about his versus Ron’s recommended range of estimation values. Part of his answer was that maybe the right thing for somebody working in the trenches is different for the right thing for a VP of engineering. More generally, people are going to ask the team how long it takes to implement a feature that’s larger than a simple story; they need a way to answer that. Which is a good point – I don’t have that clear a view on how Ron recommends estimating features larger than a single story. (I should ask, shouldn’t I?)

There’s still a tension there that I’m not entirely comfortable with. Unless you go with long iterations (and Mike prefers two-week iterations, which already doesn’t seem long enough), I don’t see how you can fit stories that vary anywhere near a hundredfold in length into a single iteration. Now, stories at the extremes (especially the large end) are bad, but still, a 1- to 13-point range (or whatever) seems too wide to me to fit within an iteration. But a story that can’t be done within a single iteration isn’t really a story, is it?

So maybe there are there levels needed: features, stories, tasks. Each with their own (non-convertible, as above) estimations. But that’s too much estimation. Given that, I’d actually be tempted to drop the task estimation instead of the feature estimation: isn’t it kind of pointless to spend time how many hours a task will take? Just implement the damn thing! In the previous incarnation of my team, we did break down stories into tasks (we should get back to doing that, it was useful), but we didn’t estimate individual tasks, and I never felt the lack. Maybe I was missing something, but it still seems funny to me.

Actually, though, it’s entirely possible that we were subtly shifting things by a level (and making them too long, to boot.) Because the truth is that a lot of our stories were technical: we weren’t clever enough (and weren’t working with a Customer representative to give us a nudge) to break work up into small, customer-visible units. So maybe what we called stories were really tasks? I don’t think that’s quite accurate, but there’s enough truth to that to make me nervous; something to think about more.

Since Stuart brought it up (see his blog post on the talk if you want another take), I might as well talk about another question I had. Mike presented some very interesting examples (you can see his slides, by the way) of studies that showed that, when people were given extra, irrelevant information, their estimates for tasks increased. (My favorite example was when group A and group B were given exactly the same text, but in one case on a single piece of paper while in another case spread over seven pieces of paper.) To which I asked: that’s neat, but which estimate is more accurate?

I freely admit that I asked this solely out of methodological purity: even though the studies didn’t give any evidence about the relative accuracy, I know which way I’d bet. (Well, one of the studies sort of did give evidence: they gave three teams the same tasks, but told team A nothing about expectations, team B that the customer hoped it could be done in 500 hours and team C that the customer hoped it could be done in 50 hours. All teams insisted that the hopes had nothing to do with their estimates, but team A ended up with an estimate of 456 hours, team B with 555 hours, and team C with 99 hours! Scary, that: a trap that I fall into all too often myself.)

But, the more I think about it, the less sure I am which team’s estimate is the most accurate. Take, for example, the study where team A was told to estimate requirements 1-4, team B was told to estimate requirements 1-5, and team C was told to estimate requirements 1-4 but were also given the future requirement 5 for purely informational purposes. In this case, A and B both estimated 4 hours (even though B was told to estimate strictly more work than A) while C estimated 8 hours (even though they were told to estimate the same work as A)! Looking at that, I don’t see at all why I should believe that A is the most accurate – they give the same answer as B, which is within the margin of error but clearly odd. What seems more likely to me is that A and B are estimating in terms of “hours we haven’t thought much about” while C is estimating in terms of “hours we’ve thought more about”, which we learned earlier can’t be converted to each other!

Anyways: good talk, a good reminder that we should get back to estimating once matters get a bit more under control, and I ended up with a book and enough sets of his planning poker cards that we can use them in our future team meetings. If you have a chance to hear him, I definitely recommend it.

Liesl is playing through Bust-A-Move ’99. And there’s this one song that’s the most insanely perky, catchy song ever. Dah da. Da da da dah da. Da da da da da da da dah dah dadadadah…

Wii version next month!

Elite Beat Agents is a music game for the DS. It takes its mechanics and much of its style from a Japanese game called Osu! Tatakae! Ouendan; apparently, however, Nintendo of America thought that my country’s youth would prefer secret agents to male cheerleaders dressed in black, and American pop to J-pop. (Imagine that.)

The cool video game bloggers all disagree with NoA on that score, and I suspected that I’d prefer the original, too, but I didn’t feel like ordering it from an import store. And the US version has gotten reasonably good reviews – clearly its sense of style hadn’t entirely vanished in translation.

I was a bit dubious about the idea of a rhythm game on the DS, but the mechanics turn out to work rather well. Numbered buttons appear on the screen, with shrinking circles surrounding them; you’re supposed to tap the buttons when the circles shrink to the size of the button. There are also some paths which you have to move your stylus along as the speed of a ball. Pretty basic stuff, kind of artificial, but I’m not sure it’s any more so than any other rhythm game out there. (It just doesn’t have an alternate controller hiding the artificial nature.)

It begins with two difficulty levels opened up; I tried the harder one. And I was glad I did: the first few songs were quite easy. Fun, though – I didn’t mind the music, and the illustrations that went along with them were pretty funny. (My favorite one is when you play Leonardo da Vinci trying to woo Mona Lisa with your fabulous drawings and inventions.) Five or six songs in, though, it starts getting harder: I was working just to survive the songs, let alone to get a good rating on them. (Depending on how you’re doing during the story interludes in the song, you’ll get a good result or a bad result in the interludes: Mona Lisa may like you or spurn you, etc.) The last three, plus the one where you’re a car company heir dressed as a ninja sneaking into your competitor’s factory to retrieve some plans, are all really tough.

After which I unlocked the third difficulty level, and had to start all over again. Again, the earlier songs were really easy, but the later levels were quite tough. This time, though, when I got frustrated with the later levels, I went back and replayed them on the second difficulty level; they’d magically gotten quite easy in the interim. Which is a good sign on the gameplay mechanics: there is a real learning curve, you do get better as you go along, and getting through the tough ones is more of a matter of skill than luck.

And by the last level on the fourth and hardest difficulty setting, I needed all the skill I could muster. I think it took me something like three hours to make it through that level, and the part of my finger where the stylus rests was starting to get sore. But I never (well, almost never) felt that it was being unfair: I just had to do a better job of memorizing the tricky bits, and not losing my concentration over the course of the four or five minutes that it took to get through the song.

Liesl likes it, too: she’s banging her head against the third difficulty level now. (Or maybe she’s just finished that, I can’t quite remember.) When I finished it, I thought I’d go out and get the Japanese version, but I’m holding off for now; I’m in the mood for more J-pop (my entire collection of which consists of the two Katamari soundtracks, plus a greatest hists collection by Tsuji Ayano containing the excellent theme song from The Cat Returns – any other recommendations?), but the one video I’ve watched of a level on the Japanese version didn’t immediately grab me. And I have enough other games on my maybe-play list that I should give other genres a try.

Recommended; not as wide a range of songs as DDR, I suppose I like the controls in Guitar Hero a bit more, but worth playing.

I’ve finally finished backing up all my CDs which are filed under the letter B. Of which there turn out to be 176, approximately a third of the collection. The distribution:

panini$ ls | cut -f1 -d- | uniq -c | sort -rn
     62 bach
     29 beethoven
     24 britten
     14 beatles
     10 brubeck
     10 berio
      6 bartok
      5 bruckner
      4 brahms
      2 bobs
      2 biber
      2 bernstein
      2 berg
      1 bush
      1 blue
      1 blades
      1 ben

Most of which are obvious, but some notes: “bach” includes two by P.D.Q. Bach; “bush” is Kate Bush, “blue” is Blue Scholars, “blades” is Ruben Blades, “ben” is Jorge Ben. (The latter two being Liesl’s, actually, so I’m less familiar with them.)

I wonder if Bach by himself will beat out all other letters of the alphabet? My guess is that S will edge him out; we shall see.

A random factoid from Cheaper by the Dozen:

Also of exceptional general interest was a series of tricks whereby Dad could multiply large numbers in his head, without using pencil and paper. The explanation of how the tricks are worked is too complicated to explain in detail here, and two fairly elementary examples should suffice.

1. To multiply forty-six times forty-six, you figure how much greater forty-six is than twenty-five. The answer is twenty-one. Then you figure how much less forty-six is than fifty. The answer is four. You can square the four and get sixteen. You put the twenty-one and the sixteen together, and the answer is twenty-one sixteen, or 2,116.

2. To multiply forty-four times forty-four, you figure how much greater forty-four is than twenty-five. The answer is nineteen. Then you figure how much less forty-four is than fifty. The answer is six. You square the six and get thirty-six. You put the nineteen and the thirty-six together, and the answer is nineteen thirty-six, or 1,936.

On Mary Poppendieck‘s recommendation, I’m reading Cheaper by the Dozen. Two paragraphs into it and I’m already a fan!