malvasia bianca

We got back the results of Yosha’s blood work; it would seem that his kidneys aren’t functioning at full capacity. Which might even explain the vision problems: kidney problems can lead to high blood pressure can lead to vision problems. We’ll see; we’ve gotten bags of special “easy on the kidneys” dog food, and hopefully various matters will improve.

Certainly he peed a lot less today than he had been doing in previous days. A good sign, though it’s rather too early to declare victory: there was poop all over the carpets, so probably not enough stuff was making it into his blood in the first place to really tax his kidneys. I’m not particularly worried about the poop; this sort of thing happens when changing from one kind of dog food to another. That should settle down in a few days, after which we’ll have a better idea of the new food’s affects.

Apparently there was only one AIDS death in Santa Clara county in 2004. A ways to go still, but that’s real progress.

We just finished watching the version of Angels in America that HBO did a couple of years ago; fabulous.

I wasn’t expecting to like How Buildings Learn nearly as much as I did. I learned about it from the XP book‘s bibliography, and certainly you wouldn’t have to look very far in the book to find inspiration for your programming. But I was surprised at how interested I was in the actual topic of the book. (Not too strange in restrospect – being a homeowner does change one’s views on such matters.)

Lots of groups of pictures of one house over the years: additions to the house, changes in the styling of the house, the occasional removal of a previous addition. We don’t have have any plans to add onto our house: we don’t have any plans even to remodel, though I can conceive of how we could, say, improve the kitchen. But looking around the house with addition eyes, I can imagine how we could this house could grow over time: enlarge the den by going out into the back yard, then add a similar addition to the guest room above it, then move out the kitchen next to it, and so forth. Though, to be sure, we couldn’t actually do that: we live in a townhouse complex, and there are rules against that sort of thing.

Even if there weren’t rules, we probably wouldn’t want to expand – there’s only so much space in our backyard, after all, and neighboring buildings are uncomfortably close. But a lot of standalone buildings these days are in developments with CCR’s of their own; I can’t see how that’s a good thing. I wouldn’t necessarily support giving up all housing-related rules, or even all non-safety-related rules, but enforcing a sterile uniformity for the putative reason of improving your neighbors’ property values seems pretty crazy to me. Much better to adapt your house to changing events, instead of being forced to change houses entirely.

There were also good thoughts on the idea that there shouldn’t be this sudden changeover when a building is finished: you only know how it will actually work when people are living in there, so the conversation with the architect/builder/whatever should continue at that point instead of end there. Some random tidbits from the book: drawings from a book on Malaysian house-building, showing various traditional expansion sequences for Malaysian dwellings. Discussion of some Japanese building firms that take responsibility for all of the design and construction, engaging with the resident throughout the whole process, continuing that engagement after the resident moves in. It’s hard to say what the future will bring, and I don’t particularly foresee ever having a house custom-built for us, but if we were to do so, that sounds like a good way to go.

And discussions of older architecture versus newer architecture. In lots of areas, I tend to reflexively support the new against the defenders of the old, but reading this book and Christopher Alexander have rather turned me the other way when it comes to architecture. A lot of screwed up ideas on that score in the last century. (Hmm, maybe my opinions shouldn’t surprise me so much: I’d already been convinced of that when it comes to urban planning.)

Among other things, modern houses apparently aren’t built to last so long. And one symptom of the lack of an ongoing conversation between builders and dwellers is the general lack of ongoing maintenance. Certainly I wish that I knew somebody whom I trusted whom I could talk to about the state of our house, what should be done about it in what order, and who could help arrange for stuff to get done. We’re managing to chip away at this somewhat (and actually the HOA / management company can be very helpful in this regard, for stuff that’s their responsibility to pay for / arrange), but not as quickly as I’d like, and there are definitely some areas where I could use some good, informed, unbiased advice. (E.g. about our floor.)

Of course, part of the issue there is scheduling – it’s the whole “important but not urgent” problem, made worse by the fact that I don’t in fact really know how important and/or urgent it is.

A problem I’ve been dealing with at work recently, too. I think we’re making some progress – my team in particular has been very helpful in informing me that, no, we shouldn’t put off fixing certain bugs, they’re causing problems now. XP and lean seem to have a good approach here: they have useful concrete criteria for telling whether or not something is important, and once they’ve decided it is important, they immediately elevate its urgency. (A defective part just went by – stop the whole assembly line until we can figure out what went wrong!) Not clear how to apply that to home maintenance, though, or even whether it’s a good idea to apply that to home maintenance. I guess there’s probably another way in which lean deals with important-but-not-urgent events – there must be periodic checkup sessions, which then lead to recommendations of fixes that are more urgent to implement. So the analogy here is to periodically give the house a check-up, and then to immediately fix the problems that you find. Assuming that I’m not just making up that last sentence about lean! Even if I am, the application to houses sounds like a good idea.

I’ve just upgraded from WordPress 2.0.2 to WordPress 2.0.3. Let me know if you see any problems.

God of War is a quite well done beat-em-up. Basically, you wander through a mostly linear, pseudo-ancient-Greek world, beating the crap out of tons of monsters that appear in your past, occasionally taking a break to either solve a bit of a puzzle or fight a boss monster.

I’m not sure that there are any stunning advances here, and I don’t understand the “game of the year” support that it’s gotten, but I had fun playing it. The difficulty level is well-balanced – I basically never got frustrated, and they’ve learned the recent lesson that, if a player is having trouble at a spot, maybe they should offer to make the game a bit easier for you instead of having you give up on the game. (Which I was happy to take advantage of in the final boss fight, or rather trio of fights – while I enjoyed the game, I didn’t feel like putting in hours to finish the very last part.) Good level design, nice texturing to the challenges, boss fights that I didn’t mind and even rather enjoyed at times.

The plot could have been decent (for the genre – this isn’t an RPG, after all) were it not for its blatant disregard of any actual Greek mythology. You play as a Spartan warrior who has been chosen by Ares but who has subsequently turned against him. So you end up trekking through a desert to find a Titan wandering around with a labyrinth chained on his back, hidden in the middle of which is Pandora’s box, which will give you superhuman powers. Sigh. If they’re going to do that, why not give up on the Greek theme entirely, and just invent a fictional ancient world to set it in?

Quite violent – you even have special finishing QTE-ish sequences to add to the gore of killing monsters. (And to provide an extra gameplay mechanic in boss fights.) Also, it’s the first video game that I can recall playing with bare breasts. I wonder why that is? I guess video game publishers are afraid that parents will freak out if their kids are playing games where you can see breasts, but in this game they figure the parents will freak out at the violence anyways, so they might as well go full-out for the slightly older male audience. The nudity disappears after the first third of the game or so, though; it was never very well-integrated into the plot, anyways. (Or maybe it’s that the plot attenuates after the first third or so, too.)

A slightly interesting leveling-up system: vaguely hidden (not really, any more than blocks in a Super Mario game are hidden) chests lying around. Many of these contain some amount of red orbs, which you can use to power up your spells and weapons. But some contain “Gorgon’s eyes” and “Phoenix feathers” to increase your health bar or magic bar. (I forget which does which.) Both of the latter max out after a certain point, however. And either I’m a stunningly good chest-finder or they’ve over-provisioned the eyes/feathers in chests, so if you find a chest that would have an eye or a feather after you’re already maxed out those bars, you get a lot of red orbs instead.

The result is that, if you’re at all inquisitive, you’ll have maxed out your bars by the end of the game. And the result of being extra inquisitive is that you’ll have maxed out every spell instead of most of them. It’s not at all important to max out every spell, while maxing out the bars is quite useful; the result is a system that gives you a linear world (so you can’t go back to earlier regions to search), and rewards you for doing extra searching, while not actually diminishing the gameplay for people who aren’t obsessive searchers (or who aren’t following a guide showing the location of every chest). A nice compromise.

Next in the “violent game” series: Halo. Which may or may not be too violent for Miranda to watch; I have no idea. I’m not sure, and it happens to be next on my list of games to play. One advantage – probably the only advantage, actually – of summer game doldrums is that it gives me time to play important games that I never got around to playing when they first came out. Speaking of which, if anybody has recommendations, I’m all ears – I don’t quite know what I’ll play after I’ve finished Halo or Guitar Hero.

Hey, Jonathan’s blogging about Thumper. Neat.

I am still looking for music recommendations. Several of the bloggers that I read occasionally recommend either individual artists or podcasts; since I seem to agree with said bloggers’ tastes in other matters, I usually give them a try. Alas, all such experiments have proved unsatisfactory. Fortunately, the artists that they recommend have sample songs available on their web pages, so I can discover that they are not to my taste before spending money on them. Progress, I suppose.

I’m somewhat embarrassed (or at least surprised) to find out that basically the only music podcast that I continue to listen to is Next Big Hit, which I found through the top 100 list on iTunes rather than more informal methods. A grab bag of pop, not particularly the sort of thing that I’m looking for, but I usually don’t mind most of it, and every week or two there’s a song that I rather like. And it’s in an AAC feed with chapter markings, so if there’s a song I particularly dislike, I can just hit the ‘next’ button.

Not a crisis, I suppose – I have enough music lying around the house that I don’t mind going through my CDs over and over again. (I’m just finishing a Mahler symphony run right now. Somewhat to my surprise, I’m finding that, though I basically like all of them, the first and second continue to stick in my head to a much greater extent than the others. Is that because of the symphonies themselves, or because I listened to those two over and over again before I bought recordings of the other ones? Maybe I should try, say, listening to just the sixth several times in a row.) And I have enough to listen to on my iPod; when I run low on my regular podcasts, I can always learn Japanese. Hmm – maybe I’m making a strategic error by looking for pop podcasts, and should try looking for classical music podcasts instead – judging from my non-podcast musical experiences, I’m probably more likely to find matches that way. Or if I’m going to branch out more, maybe jazz is a better place to go than pop. I shall experiment.

I was just looking at the front material of a book and saw that its “SBN” was 671-21320-2. I didn’t know that there was a pre-international version of the ISBN.

And here’s some information if you’re curious about the 13-digit ISBNs that have been appearing recently.

I think I made the right decision to give up playing go: I just don’t want to spend one evening a week doing that. But I was just looking at a picture of a game in Hikaru No Go (nine moves into the Ota vs. Akira game), and memories came back. It can be a remarkably rich experience.

The next time I’m looking for a job, I should keep my eye out for one where I’ll be able to play go over lunch.

• Translators, beware.
• Banana phone!
• Just in time for the primaries.
• No, we don’t need webcasting rights.
• Fun with flash.
• Um. Well.

Our beloved Alyosha is fourteen years old. He’s been showing his age for a little while now – aside from slowing down in general, he started getting excessively grumpy three or four years ago. At a vet visit not too soon after that happened, the doctor said his thyroid levels were low; he went on thyroid meds, and his mood improved enormously.

He’s also started peeing a lot. Which may or may not be a side effect of the meds; we should get an answer to that soon. Recently, though, a couple of things have gotten worse. For a while, he’d had a hard time seeing the steps up into bed right after we turned off the light – it took his night vision a while to adjust. Recently, however, he’s been unable to get up into bed at all in the middle of the night – he seems to have very little night vision at all these days. Also, while it’s been a while since he wanted to take long walks, these days he’s loath to venture even as far as the end of the townhouse complex. I’m not entirely sure what’s going on there – he’s happy to shadow me when I walk around the house, including going up and down stairs, so I don’t think his legs can be aching too much. Hard to say. He’s gotten rather heavier, too, which may be a result of the decreased exercise.

Anyways, the other night we heard him falling down the stairs. I do hope that hadn’t been a regular feature of his nights; if so, it might be an explanation of why he doesn’t want to go on much of a walk in the morning, since he may be a bit bruised. So real night vision problems, and he hasn’t figured out quite where the stairs are. Once we realized he was doing that, we started leaving the stair lights on at night. Unfortunately, the stairs are near our bedroom, but we found that, if we unscrewed the light bulb at the top of the stairs, then we could still get to sleep just fine, and I think the light at the bottom is enough for him to see. Liesl was also talking about installing a dimmer switch; we might give that a try if the current solution doesn’t work.

Ultimately, though, we should take him to a doctor fairly soon. My tentative hypothesis is that he has cataracts: his eyes have been somewhat milky for years, so I hadn’t been worrying about that too much, but if it’s causing problems, we should do something about it. And googling suggests that cataracts can lead to poor night vision. Liesl’s parents had a dog who responded well to cataract surgery; maybe Yosha will get to go through that, too.

Or maybe it’s something else. Fortunately, the house is small and we have no plans to move any time soon (or any time not soon!), so if they can’t fix his vision, I’m sure he’ll adapt. But he is a sweet darling wonderful dog, so we’d like to make his remaining years as pleasant as possible.

I can now handle books with more than two authors. Yay. Nice to be able to spend ten or fifteen minutes making a change that actually affects what books I can handle instead of spending months making a change whose effects nobody else can see.

Not that I’m done with the behind-the-scenes changes yet – I still have some amount of cleanup to do, getting rid of no-longer-necessary code, so I’m trying to combine each new feature with a bit of cleanup. And there was one unpleasant surprise when doing that: I was shuffling responsibilities between acceptance tests, when all of a sudden one of them stopped working. And stopped working in a quite strange way – it was updating a row in a database, and some of the columns got the new value while others had their old values. I don’t quite see how this could be any sort of obvious bug in my code – tests are pinning down the behavior pretty tightly, and if anything goes wrong an exception should be thrown that would make it up to the top. And my code should be pretty deterministic, yet the problem in question magically cured itself a few minutes later.

So I’m pretty disturbed. I have no idea if it’s related to my other current mystery, the random hangs I mentioned earlier. Just to be on the safe side, I read through the JDBC Javadoc a bit more, to look for places where I’m not releasing resources; I’m now calling close() on my java.lang.sql.Connection objects, just in case. (I was already calling it on my ResultSet objects, though that is one place where I could imagine there being gaps in my unit test coverage.) But this latest problem doesn’t feel like a resource leak to me…

Much of the future cleanups are pretty obvious, but there is one place where I have a question. Right now, I have an abstract interface Collection with two implementations, MemoryCollection and SqlCollection. The former is the original implementation, from the days when the list of books was represented by Java code; the latter is the implementation I’m using now. So I could delete the former, were it not for the fact that it’s being used in unit tests in a fair number of places.

So: do I keep it around, or do I retrofit the unit tests? It’s not clear to me that keeping it around is going to pose that much of a burden; and if it becomes a burden at some point, I can always retrofit the tests then. (Which will, admittedly, take a while, which is one reason to think about starting on it now.) So if keeping it around is the easiest way to write unit tests, then that’s what I’ll do.

One aspect of keeping it around is this: to create, say, a new Book object using MemoryCollection, I call a factory function, passing it the title and author, and then call various write accessor to update other attributes that I feel like setting. (E.g. the ISBN, or when I read it.) Which is an okay way to do things; it’s certainly better than creating an SQL row by hand. But now that I have this CLI tool to create and edit entities, I could use its interface instead, which is pretty easy to use: something like

add book author Fred title “This Book” isbn 1-234-56789-x

is easy enough to write, probably even easier than calling various write accessors.

There are a couple of issues with that. For one thing, I can’t just pass in a single string, I have to pass in an array of Strings, and it’s a little more verbose than I’d like to create that on the fly in Java. Maybe I could work around that by writing a little function to split the single string into an array, though – that would be easy enough to do, and might save me a fair amount of test-writing time. The other issue is that the above isn’t actually the syntax that I use for the current SQL interface – instead of passing in the name of the author, I have to pass in the entity ID of the author, something like “author 3” instead of “author Fred”. So there’s some fiddly counting to do, and I lose type safety, neither of which thrills me. (It’s a problem with the CLI tool as well.)

Another possible issue is that I was worrying about the tests being too incestuous, not being tied to the external realities of the database format enough. But, thinking about it more, I’m not worried about that any more: my tests for the Editor object (which writes out the SQL database) really do test the SQL that is generated. So it’s fine for me if my tests for Book, for example, whose main job is to generate HTML, aren’t so closely tied to the details of the SQL: as long as they accept whatever Editor outputs, it should be fine. In fact, it’s arguably superior to have that linkage be enforced in the unit tests. (This is all being enforced in the acceptance tests, too.)

I’ve got enough other cleanups to do that I don’t have to decide this one way or another for a few more weeks. I’m leaning towards getting rid of MemoryCollection and using SqlCollection exclusively, but I could still change my mind.

I’m trying to fill an opening in my group. If you know any good programmers who live in the S.F. Bay Area, who are looking for jobs, and who think that it’s a good thing for code to come with tests, please point them at that link or send them my way.

Up until a few months ago, the way I would, say, add a new book to the list of books I’d read was to edit a file (WriteDbc.java), compile it, and run its main, which would write out HTML pages directly from the Java data structures that it built up.

Then, a few months ago, I stuck in an SQL database as an intermediary: the main routine would write out the data structures into an SQL database (first wiping out the previous contents of the database!), and a separate program would go from the SQL to HTML. Which is ridiculous in the long term – the point of a database is to store data, not be a transient repository – but a useful step nonetheless.

But now I’ve finished a CLI tool to let me edit and add to the SQL database directly. So yesterday, I did svn rm WriteDbc.java after writing the data out one last time, and today I used the CLI tool for the first time in earnest (to reflect the fact that I just finished this excellent book and am about to start this one). And it works just fine.

Things that I learned while writing the CLI tool:

• I might have fantasized that I had a traditional layered architecture for this, with at least hints of a persistence layer, an abstraction layer, a presentation layer. Well, I don’t. One manifestation of this is that the CLI tool and the SQL-to-HTML tool share essentially no code – my wrapper over java.lang.sql, a couple of simple data types (a date wrapper and a book title wrapper), and that’s it.

  The CLI tool is driven by a table mapping entity types (book, author, etc.) to SQL tables and, for each entity type, another table mapping keywords to columns; that’s it. Really simple to use, really simple to modify: after the first three entity types, adding each new one took less than five minutes. (With one special case exception.) And going from a CLI tool that could add a new entity (a book that I’d just bought, for example) to a CLI tool that could edit an existing entity (reflecting the fact that I’d finished the book, for example) took maybe 30 lines of code. It’s just not complicated enough to justify more architecture than that.

  One benefit of this is that, if I want to dabble in another language, I’ll be able to easily rewrite one part without having to touch the other. So if I want to, say, rewrite the CLI tool in Ruby, nothing’s stopping me (other than the fact that I don’t know Ruby yet) – I even have acceptance tests in place to back me up. Yay.

• The one acceptance test surprise was that the acceptance tests went from taking a minute to taking two minutes; what’s worse, they would hang occasionally. The reason for the time increase was that, if an acceptance test wanted to test a scenario with 15 entities, it would have to run the CLI tool 15 times, starting up the JVM and connecting to the database 15 times. And, it turns out, doing so can turn a 3-second test into a 15-second test. So I modified the CLI tool to accept multiple commands in a single invocation; now the acceptance tests only take about 45 seconds.

  The sporadic hanging still bothers me. I can’t see how it could be some sort of infinite loop in my code, though I’ve been wrong before. I could imagine that I’m not freeing SQL resources appropriately – I have tests verifying that I’m releasing them in many circumstances, but it could well be that there’s some place where I don’t know that I’m supposed to release resources. (I would have naively assumed that resources would be freed when the process exits, so bugs like this wouldn’t matter, but maybe not.) Or maybe there’s a problem somewhere else.

I am glad that this is over with (there are a few loose ends to tidy up, but nothing major or urgent): it will be very nice to shift back to taking an hour to implement a feature that will make an actual visible change on the output, instead of taking rather longer than that to change the guts in a non-user-visible fashion. Especially since I have some features that really need to get implemented: I can’t add one of the books that I’m currently reading to the database, for example! Next weekend I will be able to, though, unless I’m too busy to be able to program at all.

Driven by my recent mania for all thing lean, I just finished Lean Software Development, by Mary and Tom Poppendieck; I wish I’d read it a few years ago. I’d been aware of it for some time, but I passed it over when doing my initial tour of the agile literature. I had assumed that the book was proposing a methodology; back then (and to a fairly large extent, even now) I had no desire to learn about more methodologies. Learning about one or two can be useful, to see concrete examples of how people but the basic ideas into practice, but beyond that, I didn’t see the point. (Especially since I have yet to hear about anybody other than their founders using any agile methodology other than XP or Scrum.)

It is, however, not a methodology: it’s instead a book with a range of suggestions for what software development might learn from lean manufacturing. (Both authors have quite a bit of software development experience; the first author also has quite a bit of lean manufacturing experience, from her time with 3M.) As they say right at the start, software development is not manufacturing: manufacturing is about producing identical (or similar) objects as quickly and reliably as possible over and over again, while software development is about producing a single or a few related evolving products. The authors’ take on this is that software development is more like product development than like manufacturing, so they use lean product development as their inspiration. (It turns out that lean manufacturing companies do product development differently from other companies: Toyota has been better at bringing new models quickly to market than US car companies, for example, and 3M has effective product development strategies as well.)

So, while some of their recommendations were very familiar to me from the little reading I’ve done in lean manufacturing (e.g. the first chapter is “Eliminate Waste”), others weren’t. “Set-Based Development” is a good example: they recommend that, when developing a product, you explore the solution space for your various constraints by constructing a large number of alternatives meeting each constraint, and then see if you can use those alternatives to come up with a design that meets all your constraints. This is in contrast to “point-based development”: there, you start with one target solution, and repeatedly alter it based on feedback until everybody is satisfied. The authors claim that this takes a lot longer to reach a solution than the set-based approach, despite the fact that many fewer options overall are considered.

There are some useful counterpoints (and, at times, counterweights) to XP. I should spend some time thinking about the relation, if any, between the set-based approach and XP spikes, for example. And XP depends on a (to me) almost mystical notion of a Customer making a certain class of decisions; this book spends more time looking at what goes into decision making. The “Empower the Team” section also provides a nice collection of tools (“Self-Determination”, “Motivation”, “Leadership”, and “Expertise”) which acknowledges certain dynamics more explicitly than XP does. Given the lean focus on quality, I was somewhat surprised that there wasn’t more of a focus on testing – I’m used to that being focused on (productively, I should add) to an almost obsessive extent in agile books. And this book spends much more of its time further away from the software developers than many agile books do, e.g. in the discussion of contracts. Or maybe that’s my selection bias coming into play – I have more software development context and responsibilities, so I focus my readings there.

I’m not sure what concrete effects it will have on my work in the short-term; for now, I’m going to continue reading about lean, waiting for concepts to sink in and crystallize. I imagine that I’ll return to this book in a couple of years and find specific inspirations in it, and indeed that it will have subconsciously inspired me in the interim.

This will not, I think, be the most useful discussion of Knights of the Old Republic, simply because I can’t help but viewing the game through the lens of Bioware’s latest, which had the benefit of a couple more years of experience. With that warning in place:

Fun game. I kind of nibbled at the first planet, which had the result that it took me a while to get past it. I took a peek at a guide, and realized that I should either give up on the game right there or pick up the pace; I decided that I liked the game enough to want to keep going, and finished about a planet a week after that. (Admittedly, the first planet was longer than the others.) And I’m glad I did; it’s possible that the level design got better after the first planet, but I don’t think so: I think the plot just worked better when I was constantly making progress. (Obligatory Jade Empire comparison: that game, on the other hand, I was addicted to right from the start. But its later areas were notably weaker than its earlier ones, while KOTOR maintained its quality throughout.) Though it is also true that the plot got more richly woven as the game progressed, and the Major Plot Twist worked well for me. (For what it’s worth, the fact that it’s a Star Wars game didn’t matter much to me one way or another; maybe that gave me a negative bias, but only a very small one.)

The combat system is based on an underlying turn-based system, but you can just sit and let all your characters move and attack according to their defaults. This loses the richness of a real turn-based system, but is a lot less tedious; I probably would have been impressed if I’d played it before Jade Empire. I didn’t, however: I significantly prefer the latter’s complete abandonment of turn-based RPG combat.

Leveling up was pleasant enough; not too much in the way of micromanagement. Ditto for character classes. Party management was handled quite well: at (almost) any given time, you can pick two of your (up to) nine companions to use, but experience points accrue to the party as a whole, so you don’t have to worry about keeping all your characters leveled up. (Again, though, Jade Empire shows that we can do better by going even further in these directions. Yes, I realize this means that I’m not a traditional RPG fan.)

Good difficulty level. Even the final boss fight wasn’t too tedious.

Like several recent games (including Jade Empire), you can play it taking a good path or an evil path. Unlike all the other such games, I was tempted by the evil path, and if I were to replay the game (highly unlikely, if for no other reason than that I basically never replay games), I might well give that a try. I think being set in the Star Wars universe helped here: the evil side is relatively well fleshed out.

Almost 40 hours long; longer than I like these days, but that’s more because of my time constraints than anything else.

Today’s book: The Rise of the Creative Class, by Richard Florida. Or rather, the book of a couple of months ago; I really need to start blogging right after I finish something.

The book claims that something called the creative class has become hugely important over the last few decades, now outstripping the working class as a proportion of the working population, and threatening the service class, which has also had huge growth. (30% creative, 25% working, 45% service; agricultural is almost zero.) That’s just in terms of the numbers of people working in those fields; in terms of, say, financial impact, the creative class is quite a bit more important.

Which means that the creative class is starting to reshape its environment (working and otherwise); how it does that turns out to be quite interesting. For example, while the creative class isn’t necessarily particularly diverse (e.g. I work in the tech industry, which has quite a large number of white males in it), creative class members prefer to live in ethnically diverse areas, areas with a large number of gay people, etc. Creative class people like to be around an active artistic scene, but generally more at a small-scale level (lots of bands playing in various small locations) instead of a larger-scale level (stadium concerts, big orchestras). They like athleticism, but at a personal level (running, mountain biking, going out and doing something) instead of, say, going to a stadium to watch a big sports team. They don’t have much truck with, say, dress codes at work. They don’t work 9-5 hours (and frequently end up working rather more than 40 hours a week); they change jobs pretty frequently.

Most of which sounds pretty familiar to me, and most of which sounds like a good thing to me. And it gives me hope in the ongoing culture wars: the Christian conservatives scare me, but my side is growing, both numerically and economically. But, as the book also points out, we could be doing better in that regard. Creative class members turn out to be relatively apolitical, and I would be the first to admit that my political zeal has dwindled notably over the last several years. Maybe we’re too busy either working or exercising? Or hanging out at ethnic restaurants or nightclubs?

Speaking of which, I don’t quite understand the zeal for long work hours, either. Admittedly, creative class jobs are likely to be more interesting and more financially rewarding than other sorts of jobs; those would push us towards spending time at work. On the other hand, if we like living in richly textured environments, you’d think that we’d also like to spend as much time as possible out in those environments. I think there’s some sort of weird American dysfunction going on there.

The constant changing jobs seems a bit funny to me, too. People in my experience don’t change jobs as frequently as the book discusses – they talk about people routinely changing jobs more frequently than once a year, which sounds awfully fast to me. (On the other hand, there are a lot of independent consultants out there.) Now, I’m not a big one for company loyalty these days, and I can certainly sympathize with having your top priority being working with interesting people, on interesting projects. But it’s not at all clear to me why changing jobs should be a particularly good way to optimize that. I certainly don’t see why, in general, you would expect your new coworkers to be more interesting than your old ones. And while there’s something seductive about working on new projects, the flip side is that you don’t get to grapple with the challenges of long-lasting optimizations that span multiple projects (or even optimizations that last beyond, say, the launch of a new project).

I saw a lot of Jane Jacobs resonances in the book: the intermingling street life from The Death and Life of Great American Cities, the moral wars of Systems of Survival. I’ll have to think for a while about how (if?) to integrate this with the import replacement theory of The Economy of Cities, though.

One other thing the book has pointed out to me: a lot of the political writing I’m reading these days seems to take as a given (or at least imply) that it’s bad for manufacturing to be separated from design: blue collar people lose jobs, bosses get rich, inequality increases. Now, I’m all for employement and for reducing inequality. But separating manufacturing from design can have real benefits. The first is that it makes it possible for small companies to spring up and bring new products to market. It’s not just an issue of existing large companies shedding workers: it’s an issue of new companies coming into being that couldn’t have existed before. The other is that, just because manufacturing and design are in different companies doesn’t mean that jobs are being shed. In fact, the quality of jobs on both sides could improve: maybe a company that focuses on manufacturing could involve its workers more thoroughly (more creatively) in doing the manufacturing as well as possible than a less focused company that tried to do everything.

For whatever reason, XEmacs decided tonight to crash on me when I fire up Gnus. Not good – I like to be able to read my e-mail. Fortunately, there’s a workaround – it doesn’t happen if I touch my .newsrc first – but otherwise the crash is quite reproducible.

Sigh. I’d seen XEmacs crash once or twice since I bought the new computer – I guess it’s not rock-solid in 64-bit mode. But this is the first time it’s been a real problem.

I would say that this is what happens when I use an unusual mail client (Gnus) on an unusual editor (XEmacs) in an unusual operating system (64-bit Linux). But, on reflection, I’m not sure that’s fair – XEmacs is doubtless not the only mail client out there whose 64-bit version has bugs, and it’s certainly not Gnus’s fault that XEmacs is crashing. And at least I feel that, with XEmacs, I have a slight chance at being able to figure out what’s going on: if nothing else, I’ve built it from source many times before, so with luck I’ll be able to reproduce the crash under GDB with full debug info. Whereas I’d feel a good deal more helpless if this happened under, say, Thunderbird or Mail.app. (The latter of which was doing remarkable things to my boss’s mail headers earlier this week.)

And, if worse comes to worst, all the mail data is sitting there in flat text files, so nothing’s would be irretrievably lost if this whole setup stops working. Indeed, I could try just running Gnus in Emacs instead of XEmacs – the bug might well not be present there. I’d rather not, though…

It would seem to be E3 time again; hmm. I suppose the world does not need another blogger talking about it, but I have nothing better to do. Besides, I never got around to talking about the name “Wii”.

Which is a stupid name. I know they’re trying a blue ocean strategy, I think that’s a good idea, I think that not using the name Revolution will help in that regard. But Wii reeks of bad consultants, and it doesn’t strike me as the sort of name that will appeal to the older nontraditional gamer. Still, I can’t see it making or breaking the console.

Actually, they could probably do a better job with their blue ocean strategy: there was a lot of traditional gameplay in their press conference. Then again, they probably are going to weight that sort of thing a bit more heavily at E3 than in their eventual lineup: I don’t recall them demoing Brain Age before its launch in Japan, for example. (I will give that game a try when we’re on vacation this summer; also, this game seems worth importing, for though I’m sick of sudoku by now, I still like number puzzles, and the DS seems like a good platform for that.)

I am getting quite curious about the gameplay now that first-hand reports are trickling in. Even traditional games will feel quite different, but I don’t have a feel for exactly how this will work. I had missed the fact (or forgotten) that the controller has an accelerometer built in, so it can tell how fast you’re moving it, not just where you’re pointing it; the fishing minigame in the new Zelda will certainly be an experience. Speaking of which, it’s too bad that it looks like there will be separate disks for the Gamecube and Wii versions of the game: it would be nice to play the same segment on both consoles to see how it will feel. (The again, I’ve played enough Zelda on recent consoles to have a pretty good idea how the Gamecube version will feel.) And, honestly, I’m still worried that there will be aspects of the Wii Zelda controls that I won’t like – will using the controller to slash with the sword be a distraction from the adventuring? (Will you even use the controller to slash with the sword? Maybe not.)

Pretty muted press conferences, given that one console just launched and two are about to. I would have thought they’d have more to say, somehow. Maybe it’s just my world-weary point of view now, though: new consoles don’t inherently excite me, and we’re in the end-of-generation lull of games, while the good games of the next generation aren’t far enough along to have much meat on them.

And where’s the Wii Smash Brothers? That’s a great series. Not that I have any friends to play video games with these days…

I looked into using delicious for this, but its automatic blog posting doesn’t quite do what I want. So I guess I should cook up some way of transforming its RSS feeds, or something. (An excuse to learn about XSLT!) In the mean time:

• This seems to be sticking with me.
• Glad I didn’t buy another Dell.
• Lots of words.
• I love the Pseudonymous Kid story at the end.
• Men, women, poses.