Arnt Gulbrandsen
About meAbout this blog

A short digression on humane architecture

This stadium was designed by Zaha Hadid and meant to be built in Tokyo:

I don't actually know, but I expect that the committee felt that it might be a landmark like the Sydney Opera House, famous, forever photographed. The committee scrapped it, though, and decided to build this, instead, and it makes me so happy:

Much more humane. By comparison, Zaha Hadid's white wonder looks like a science-fiction paperback cover. It doesn't look bad, at least not to me, better than e.g. what they build in Dubai, but the humane vision is clearly Kengo Kuma's wood structure.

I'm not sure why this is.

Part of it is wood. You can shape concrete freely and at any scale, wood retains some relationship to the size of a tree, even if modern use of glued laminated wood weaken that relationship. Or perhaps someone who starts out planning with wood has already decided on a humane philosophy for the building?

Part of it is structure. Consider the Empire State Building, perhaps the most widely-known tall building except the current record holder, whose name is invariably forgotten as soon as there's a new record holder. Thirty other buildings have been the tallest after the Empire State Building, and twenty-nine have been forgotten. I think the big reason is they lack humane structure. Wikimedia has a revealing photo of the Empire State Building and some neighbours where you can see how it looks like the brownish building in front, not like the glassy cube to the left. It's tall, to be sure, but its appearance is not detached from human scale. There's some very clever design there that stretches humanity up, far up. There are small structural elements, bigger ones, even bigger, and that continuity of structure connects the street with the sky.

Perhaps: A building is humane if it can be seen to be made of human-sized components. A hundred-meter soaring curve of concrete can be a fine thing, but human-sized it's not.

Personally, I think that Zaha Hadid stadium would look awful when seen from much of the area around it, despite its memorable beauty. It would be immeasurably bigger than and completely disconnected from the buildings in front of it. Behold a Dublin street:


A new email address

I think mail to आर्न्ट@यूनिवर्सल.भारत should now land in my inbox... wonder how long it'll take before the first spammer manages to spam that address.


Three programs, one feature

It's not something one does often, but I've implemented the same feature in three different programs. Not very different, all are written in the same programming language for the same platform, and all are servers.

Same platform, same language, same task, same developer... you would think the three patches would end up looking similar? They did not, not at all.

The feature I wrote is is support for using UTF8 on SMTP, which I've implemented for Postfix, Sendmail and Qmail, which all run on linux/posix systems. I tried to follow the code style for each of them, and surprised myself at how different my code looked.

One patch is well-engineered, prim and proper.

The next is for an amorphous blob of software. The patch is itself amorphous, and makes functions even longer that were too long already. Yet it's half as long as the first patch. The two are, in my own judgment, about equally readable. One wins on length, the other on readability, they're roughly tied overall. This surprised me not a little.

The third is a short, readable patch which one might call an inspired hack. It's a much smaller than the others and easily wins on readability too.

It wasn't supposed to be like that, was it? Good engineering shouldn't give the most verbose patch, and the hack shouldn't be the most lucid of the three.

I see two things here:

First: Proper engineering has its value, but perhaps not as much as common wisdom says. Moderately clean code offers almost all of the value of really clean code.

Second: A small program is easy to work with, such as the MVPs that are so fashionable these days. But ease of modification isn't all, the smallest among the three servers has fallen out of use because the world changed and it stopped being viable.

Some random verbiage on each of the three servers and patches: (more…)


Use UTF8 or Punycode for email addresses?

Unicode addresses in email, such as مثال@مثال.السعودية, can be written using either Punycode or UTF8. (Or, if you're feeling inventive, in another manner you invent.) Which is best?

UTF8 looks like this: From: Arabic Example <مثال@مثال.السعودية>, punycode is From: Arabic Example <xn--mgbh0fb@xn--mgbh0fb.xn--mgberp4a5d4ar>.

The answer follows from two of the design goals for the unicode email extensions:

  1. Allow UTF8 everywhere
  2. Extend email, don't restrict it

RFC 821 and its successors do not contain any rules such as you MUST NOT put the letter n next to an x, so Punycode is allowed. EAI allows Punycode by virtue of not forbidding what was previously allowed. But the right way is to use UTF8 everywhere. Use UTF8 in the subject field, in the body text, in the address… everywhere! That's allowed, it's a design goal, and it's better than Punycode for four reasons.

First, it's simpler than using Punycode in addresses, 2047 encoding in the subject text and qp/b64 encoding in the body text.

Second, it's very, very readable. A surprising amount of legacy software does the right thing if you send it UTF8, and that goes for humans who read email source too.

Third, Punycode is specified for the domain part of addresses, but not for the localpart, and if rumour is to be believed, people are using two incompatible encodings for the localpart. (In the example above, the second and third instances of xn-- are specified, but the first is not and one vendor reputedly does it differently.)

Fourth, sending Punycode habituates users to accept random hex blobs in addresses. A phisher's dream.

So use UTF8 everywhere in the message. Mapping to Punycode is necessary when doing the MX lookup in order to transmit the message, but only then.


A list of free email providers

I've updated my list of free email providers and put it on github, removing many domains that no longer offer such services. freemail.txt contains a one-per-line list of domains that offer free email. There are also scripts to create the list.


Code review times two

I like code review but complain about it all the time. Why? The other day I had an eureka moment: There are two quite different kinds, which I will give the misleading names agile review and waterfall review, and I'm annoyed when the reviewers perform one kind of review and I want the other.

Waterfall development is centered around planning, development and deployment in stages: First plan well and get rid of most bugs, then implement what's planned, then review and test to fix the remaining bugs, then deploy. In this model, code review focuses on catching minor bugs, ensuring code style harmony, proper use of internal/thirdparty APIs, etc. Big questions such as is this feature a good idea at all? are out of scope, because that's been settled in the planning phase. (I'm not saying waterfall works in practice, only describing the theory.)

Agile development is different. Instead of planning well, agile development is based around an iterative process: Implement something that seems to be a good idea, consider it, learn something from it, finish it and then deploy, then pick something else to do, something one now knows more about. Code review can be the first part of the consideration and learning process, so it's a good time to discover that although a feature seemed like a good idea, it's going to be a morass and should be dropped at once. (more…)


Arak Al-Bustan

It is the last day of August. Tomorrow I start working, bright and early, but tonight I am still on vacation, if unpacking suitcases counts as vacation, and so I have tasted my latest bottle of arak, a variety called Al-Bustan, formerly perhaps made in Oman? There's a place called Al-Bustan there, I bought the bottle in the Muscat airport, and I haven't seen it on sale anywhere else. Formerly is formerly though, today it's made in Jordan, by the same distillery that also makes my favourite arak, Al-Zumot.

I'm glad I bought it.

Al-Bustan is nice, with a round, food-friendly taste. It's not great in the way Al-Massaya is, it just tastes of a happy occasion with good food. Oddly enough I liked it better pure than with water and ice.


Life goes on

This autumn my work shifts from arthouse pixels to mass-market pixels. An occasion to post this remarkable photo:

It reminds me a little of a more modern descendant of the sparse modernist interiors, but sparser, sparser, and with a giant screen instead of art.

The picture comes from an advertisement. You're assumed to like the interior, and you're meant to buy the TV. Too late, that model is not on sale any more.

My work involves avoiding some things you don't see on the photo: A settop box and a hundred-button remote control. Less frustration, more reliability, better usability.