Footprints in the Sand

Footprints in the Sand

About Programming, the World at Large and the Meaning of Life.

Or, to be more specific: About whatever I feel like. Don't say you weren't warned.

Code on CodePlex

Programming Posted by Petter Hesselberg Tue, September 02, 2008 07:26
The TextEdit program, from my book Programming Industrial Strength Windows, now has a home on CodePlex. For documentation, the entire book is now online.


Der Lattenzaun

Writing Posted by Petter Hesselberg Mon, January 28, 2008 21:46

While Christian Morgenstern is best known for his poetry, particularly the Galgenlieder, he also translated Norwegian authors (including Ibsen and Hamsun) to German. Why not return the favor?

Here is Morgenstern's original:

Der Lattenzaun

Es war einmal ein Lattenzaun,
mit Zwischenraum, hindurchzuschaun.

Ein Architekt, der dieses sah,
stand eines Abends plötzlich da —

Und nahm den Zwischenraum heraus
und baute draus ein großes Haus.

Der Zaun indessen stand ganz dumm,
mit Latten ohne was herum.

Ein Anblick gräßlich und gemein.
Drum zog ihn der Senat auch ein.

Der Architekt jedoch entfloh
nach Afri- od- Ameriko.

My Norwegian rendition:


Det var en gang et fint stakitt,
med mellomrom som smilte blidt.

En arkitekt fra NTH
en vakker dag stakittet så —

Han stjal hvert mellomrom, på trass,
og bygde seg et stort palass.

Stakittet ble en tragisk ting,
tenk, sprinkler uten no’ omkring!

Et syn så tragisk, leit og trist
at staten rev det ned til sist,

mens arkitekten skyndsomt dro
til Afri- el- Ameriko.

Here is a prettier rendition.


Map Iteration in Java

Programming Posted by Petter Hesselberg Sun, October 28, 2007 12:59

Here's one common idiom for iterating over the values in a map:

private Map<String, String> strings = new ArrayList<String>();

public Iterable<String> strings() {
_ _ List<String> ret = new ArrayList<String>();
_ _ for (String key : strings.keySet()) {
_ _ _ _ String value = strings.get(key);
_ _ _ _ ret.add(value);
_ _ }
_ _ return ret;

Although this works correctly, it's woefully inefficient. Use keySet() if you only want the keys; use values() if you only want the values:

public Iterable<String> strings() {
_ _ List<String> ret = new ArrayList<String>();
_ _ for (String value : strings.values()) {
_ _ _ _ ret.add(value);
_ _ }
_ _ return ret;

When you want both key and value, use entrySet instead:

public Iterable<String> strings() {
_ _ List<String> ret = new ArrayList<String>();
_ _ for (Entry<String, String> entry : strings.entrySet()) {
_ _ _ _ System.out.println("Adding value for key " + entry.getKey());
_ _ _ _ ret.add(entry.getValue());
_ _ }
_ _ return ret;

My apologies for the underlines; indentation's a bit of a challenge in these here parts of the web.


Stopping the Proceedings with Idiocy

Usability Posted by Petter Hesselberg Sat, May 12, 2007 21:24

An excise task, according to Alan Cooper, is extra work that satisfies the needs of your tools rather than move you towards your objectives. This example goes beyond the simple dreariness of excise to end up deep in the land of surrealistic idiocy:

Blog Image

Available what? Updates where? What's to cancel?

Adobe puzzles me. It really does, as Holden Cauldfield might have put it. On the one hand, the company is clearly capable of constructing high-quality software. On the other hand, their user interaction designers apparently imagine users at their happiest spending their days coddling to the needs of Adobe's software. "How do you like your new install directory, Acrobat? Should I move you someplace warmer? Tuck you in, perhaps, and give you a good-night kiss?"

I want to do as little as possible to keep my system working. I certainly don't want to be bothered by dialog boxes that have the same relationship to meaning that George Bush has to statesmanship.

Alan Cooper on excise again: "Don't stop the proceedings with idiocy." Cooper specifically took Adobe to task for this back in 1995. Unfortunately, the weight of the evidence suggests that Adobe paid him no attention. This morning, Adobe gave me this. Before coffee, even:

Blog Image

What the hell is a reasonable response here? Which file are we talking about? What location? What are the consequenses of a wrong response? And, if Adobe itself doesn't know whether one of its files ought to be replaced, why am I qualified to make an informed decision?

It's possible that a click on "Change Destination" would have been illuminating. But, being in a lack-of-caffeine-induced macho mood, I hit "Replace" instead, vaguely hoping that Acrobat Reader might commit digital hara kiri and cease bothering me.

No such luck; "Replace" was clearly not a wrong choice.

Almost certainly, it was a choice the installation software could've made on its own.


Next-day update:

Blog Image



In Joyous Celebration of Excessive Wordiness and Pleonastic Obscurantism

Writing Posted by Petter Hesselberg Thu, May 10, 2007 09:26

Here is an example of what passes for communication these days (slightly modified to protect the guilty), written in fluent consultantese and totaling 39 words:

For the Attention of all Business Partner's and Manager's:

The purpose of this memorandum is to inform all Business Partner's and Managers that a series of Vendor Product training courses have been organized as part of the EWPO Program.

This is about par for the course. So what’s the problem? Or rather, what are the problems?

To begin with, the writer is ignorant of the difference between the plural and the possessive: “Business Partners” and “Managers” (possessive) should be “Business Partners” and “Managers” (plural). To add insult to injury, the writer even lacks the street smarts to err consistently; the body of the email has “Business Partners” (incorrect), but “Managers” (correct).

One might also, on a churlish day, question the Capitalization in the Message Body. But I’m feeling mellow today; I’ll refrain.

Instead, let’s talk about useless filler words. This writer’s sin deserves a significant share of the blame for rain forest decimation; it causes the human race to use twice as much paper as necessary.

“The purpose of this memorandum is…”

It has a purpose? Who’d have guessed!

Finally, compare the underlined parts:

For the Attention of all Business Partner's and Manager's:

The purpose of this memorandum is to inform all Business Partner's and Managers that a series of Vendor Product training courses have been organized as part of the EWPO Program.

Redundancy, anyone? The target audience was mentioned in the heading; no need to repeat this in the body. And to write “the purpose […] is to inform” is akin to saying “this memorandum is interesting”. Don't declare something to be interesting; make it so! Don’t talk about informing; do it!

If the memorandum had not been written to inform, this curious fact might’ve been worthy of mention.

So, since I'm such a smart-aleck: how should this memorandum read?

Here is one version, totaling 22 words:

To all Business Partners and Managers:

A series of Vendor Product training courses have been organized as part of the EWPO Program.

It’s still in the passive voice, which is acceptable if we really and truly do want “training courses” as the subject of the sentence. If not, we can rephrase in the active voice, trimming the memorandum to 18 words (for a total savings of 54%, or roughly half a rain forest):

To all Business Partners and Managers:

The EWPO Program has organized a series of Vendor Product training courses.

Just in case you’re wondering: EWPO is indeed an acronym for Excessive Wordiness and Pleonastic Obscurantism. Most organizations appear to have such a program. And whatever else gets the axe, this program is always funded to the hilt.


Blog Software Wish List

Programming Posted by Petter Hesselberg Wed, May 09, 2007 12:10

I've been trying out this blog software for a couple of days. So far, so good; I've had no problems to speak of. But I do have feature requests. Lots and lots, as it were, but I'll be practical about it and keep the list down to what I hope is a manageable size.

Here, then, are my wishes, in order of priority. Feel free to imagine the bullet points intented in whichever fashion your typographical heart finds most pleasing:

1. Once posts start falling off the front page, I'd like a link to "previous posts". And once I'm on a page with previous posts, I'll no doubt want to go back. So: Next and Previous, pretty please.

2. When I look at an individual post, I'd also appreciate Next and Previous links, though they should be named after the posts they refer to. Hell, you've seen how most blog software does this; you know what I mean:

Yesterday's | Main | Tomorrow's

3. Comments: My personal preference would be for comments to appear in chronological order (rather than the current inverse ditto), and to have the "New Post" form at the bottom. I guess this, too, should be configurable.

4. HTML limitations: I'd like to lobby for the inclusion of one additional tag (in posts and in comments): <blockquote>. There are others, but this is the most useful. Bullets would've been nice too, of course, as witness this list.

5. The front page appears limited to three posts. That's a bit measly, in my view; I'd like to see this as a property, configurable up to, say ten or fifteen posts.

6. All links out of the blog go to target="_blank", thus opening a new browser window (or tab, as the case may be). Now, opening a new browser window without a really excellent reason is a nasty trick to pull on poor, unsuspecting users. I don't want to do that. The very least you should do is to give me control over how my links work.

And that's that -- for now. Truth be told, I want a lot of things, but this will do for a start -- they're all relatively simple things; they'd all help me.

No doubt the blog software developers have their own list(s), which may well include some or all of my points. Consider this my input to prioritization.

(Shuffles off, muttering, to experiment with CSS customization. Links should be visible, darn it!)

Update: A blog developer responds in the comments. "Don't know where, don't know when," to quote Vera Lynn, but new features will be forthcoming.

And CSS customization works as advertised.

Further wishes added as comments. Did I mention the pony?


Revival of the Fattest

Programming Posted by Petter Hesselberg Wed, May 09, 2007 10:29

In search of the Unholy Grail or Why Web Applications are Evil

Java Web Start, from Sun, is an application deployment technology that lets you download and install Java applications without the traditional installation and upgrading hassles and without compromising security. In a similar vein, Windows Installer combined with .NET assemblies allows on-demand installation and upgrading as well as a secure execution environment (sandbox).

Real applications (fat clients) have many benefits over web applications (thin clients). They have much richer and more responsive user interfaces (including, but not limited to, drag-and-drop, and integration with the desktop and with other applications), they can run even if the browser does not, they are less dependent on connection speed, and they let you work offline.

In 1997, around the time NCs failed to save the world, the applet-based Corel Office for Java was a miserable failure. How usable would Microsoft Office be as a suite of web applications? I’m writing this in Microsoft Word; if I had to do it in a web-form text field I would go mad.

In an interview with InfoWorld last year, Alan Cooper said:

“The browser is a red herring; it’s a dead end. The idea of having batched processing inside a very stupid program that’s controlled remotely is a software architecture that was invented about 25 years ago by IBM, and was abandoned about 20 years ago because it’s a bad architecture. We’ve gone tremendously retrograde by bringing in web browsers. We have stepped backward in terms of user interface, capability, and the breadth of our thinking about what we could do as a civilization. The browser is a very weak and stupid program because it was written as essentially a master’s thesis inside a university and as an experiment.”

Whatever the color of the fish, it is certain that the browser was designed to disseminate hypertext, not to serve as an application platform. Over the years, an amazing plethora of duct tape, chewing gum, and paper clips has been invented to rectify this, starting with the original CGI specification. Later came more efficient ways to extend the web server — first ISAPI and NSAPI, then seriously clever stuff like ASP and JSP, which mixes HTML with VB or Java, the HTML itself mixed with various incompatible client-side scripting languages operating on various incompatible DOMs. The browser expanded its understanding beyond scripting languages and DOMs to include embedded objects (Java applets, ActiveX controls), and client-side cookies help manage a sort of “meta-session” on top of an inherently sessionless protocol.

Rube Goldberg would’ve been proud.

Mixing presentation and content is inherently evil; it gets in the way of effective maintenance. And, just like the Pleistocene 3270 terminal, the browser application reloads the entire screen on each push of a Submit button — an extraordinary wastefulness of bandwidth.

The entire hypertext navigation paradigm of the browser is hostile to applications. By a formula I just derived, 82.5 percent of all web application development is spent fighting the confusion of the back button, the difficulties of multiple browser windows, and the evil of HTML frames. And double-clicks! We’ll never know how many bills have been paid twice because of an inadvertent double-click.

Now fat clients are making a comeback, and it’s time again to start thinking about “what we could do as a civilization.” (Cooper is always modest in his phrasing.)

Then we can go back to using the browser for its intended purpose

This was written in 2002; the original is here. And in spite of new advances in duct tape technologies, chewing gum methodologies and paper clip mythologies, the basic paradigm mismatch remains and shows no obvious signs of imminent departure.

Back then, a reader pointed out that the term "rich client" is preferable to "fat client". I completely agree. But it would sure screw up the title of the piece: Survival of the richest?



The Case for Testing Trivial Functionality

Testing Posted by Petter Hesselberg Tue, May 08, 2007 09:29

Is any code so trivial that testing it is a waste of time?

In theory, possibly. In real life, no code is ever that trivial -- Real Life has this distressing tendency to turn around and bite your ass when you're not watching.

The article needs formatting not available on this blog; you'll find it here: