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.


Comments(0)

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.


Comments(0)

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?


Comments(8)

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?

Nah.


Comments(0)