mult.ifario.us

Tim Bray on ALT-TAB:

[...] It’s only taken me a day or two to decide that the Windows/Gnome view that a window is a window is a window, and alt-tab works at a window at a time, and you don’t have to bear in mind the difference between an app an a window, is right, and OS X is wrong about this. [...]

Funny. As I've been bouncing between Linuxes, Windows, and Mac OS X, I've come to the opposite conclusion because, e.g., I can't tell from the ALT-TAB display which terminal window I'll get, and if I then get it wrong, I have to go through the stack of windows again and make another guess.

Fragile casts are a pet peeve of mine. A cast is fragile if it would be unexpected by the user, e.g., they pass in a class that implements an interface but the method casts it to a specific implementation class. For example:

public void method(Iface x) {
  some(code);
  ((IfaceImpl)x).foo(); // Doh!
  more(code);
}

A more egregious version:

public void setFoo(Iface x) {
  this.foo = x;
}

public void method() {
  some(code);
  ((IfaceImpl)foo).func(); // Doh!!
  more(code);
}

The user's experience of the fragile cast is like stepping on a rake in tall grass and getting hit in the nose with the handle: a sudden and unexpected ClassCastException hidden away in some code that they didn't write. Of course, ClassCastException doesn't tell you what cast failed, so if the method is buried deep within a closed-source API, it may take the user a long time to figure out what's wrong. (Or they might just get annoyed enough to run it all through Jad and see what's what.)

The prescription is simple: Don't do that! If the user is only supposed to use subclasses of some class, then give them a base class instead of an interface. Or, as another alternative, alter your design so that functionality in the base class is externalized and the method can rely only on the interface.

As a consumer/producer of open source, it was interesting to see Google Code hosting launch today. It also explains why people from Google were trolling with questions about how Google could help open source... (I should have asked for a search appliance for the Haus now that I'm thinking about it.) It's pleasantly minimal in that it fits cleanly into the spectrum of available infrastructure below the level of a SourceForge, RubyForge, or Java.net: no mailing lists, no forums, no releases, and no project entry criteria — just fill-in a form to get 100Mb of subversion space and an ultralight bugtracker.

From a producer perspective, no strings attached, free subversion hosting is a great offering, although I'd be more likely to use something private and something cooler than subversion — like darcs or Bazaar or another system that supports both push and pull branching semantics — until and even after a project is ready for public consumption. (Subversion+svk would count.) As a consumer, my question is how I'm going to filter out the crap. Nothing is worse than seeing a promising-sounding project and then finding out that there's nothing of value there. On SourceForge, there's plenty of deadwood, but I can look for releases, at activity levels on mailing lists, or at project statistics. On Java.net, I can look at releases, mailing lists, or at rankings. A good start on a crap filter would be a simple voting model for projects, e.g., allow a user to leave a star on a project that they found actually useful. (Of course, something like the Google Finance plotting widget applied to subversion activity and branches/tags wouldn't hurt, either.)

My answer to the “How could Google help open source?” at the time was straightforward: contribute effort and even sponsorship to the projects that Google developers find useful. This is what everyone does (or at least what everyone is supposed to do). Barriers to entry have never been an issue for open source projects, but drawing together a community and channeling combined energy into defining and creating good software have always been and remains a challenge.

An integration environment for a complex system is challenging to maintain, and even a relatively small number of active development teams (e.g., two) can generate a good number of concurrent updates to the target system. Here are some thoughts about how to stop worrying and love a little chaos.

My perspective on software testing is that it is intended to verify a set of assertions about a piece of software in a given environment. Engineering process ensures that the artifacts placed in a given environment have a tight relationship with the source code and configuration for the software, and this is an absolute. It is tempting to strive for a similar level of control over the environments for different stages of testing, but this sort of perfection can actually be the enemy of building good software. (“Good software” is software that does the work it is supposed to do, ideally making money for a business.)

For the sake of argument, suppose that the system under development, SystemX, has a dependency on SystemY. If SystemY is down or degraded in the integration environment, two things should happen. First, SystemX should quickly detect the issue and exhibit an expected, graceful degradation of functionality because that's what it's supposed to do in production under the same circumstances. Second, SystemX should be notifying the SystemY team that the system is degraded. Ideally this is an automated thing, but at a bare minimum it is the lead for SystemX getting in synchronous communication with the lead for SystemY and finding out what's up. Third, the SystemX team needs to sit down and exercise some judgement about how SystemX would behave if SystemY were operating normally. That judgement can be based solely on the knowledge of how SystemX has changed with respect to the last integration release where SystemY was operating normally, but careful and detailed management of changes is critically important. (What revision was known to be working correctly with SystemY? What changes have been made since then?) Note that none of this requires any action on the part of the SystemY team. (It's neither the business nor the responsibility of the SystemX team how SystemY operates and vice versa.)

As bullets:

• Test what you can test.
• Own your outcomes.
• Ensure that your own house is in order and reason from what you know.

This one is only of moderate difficulty, but it's still worth a mention (since I stumbled across it today debugging someone else's code). What could go wrong with the following Java code?

try {
  [code]
} catch (Exception  e) {
  throw new RuntimeException(e);
} finally {
  [code]
}

Not like the Paul Simon song. Like Mr. Truism. As Bob blogged, I've thrown my hat in the ring to help raise some funding for the newly formed Codehaus non-profit foundation. The Codehaus itself has been around in various forms since 2003.

The Haus hosts a bunch of recognizable projects. Some of the ones I've found personally useful are Jaxen, XFire, Woodstox, Stomp (:ttmp), and Jetty6. There were issues with the Haus's hardware back in May, and Bob, Ben, and others put in a Herculean effort to get things back to a reasonable state of sanity. (New hosting and bandwidth provided by Contegix are a step in the right direction.)

The goal for the funding is simple — Ensure that the Codehaus continues to be a great place to make software. Less process than Apache, more infrastructure than Sourceforge, and a vibrant community. There are always plenty of people out on the stoop.

OK, Yahoo!, you got my $1.99, but not because I'm a fan of Jessica Simpson's music. Like the vote I cast for John Kerry (i.e., against George Jr.), I'll vote for Jessica Simpson if it's a vote against DRM. So, what's next?