The Desktop Fishbowl
tail -f /dev/mind > blog

Tuesday, 24 September 2002

How about this for the worst product name in the Java space? Javaanal: Java documentation analysis utility![rebelutionary] <rant>It does quite suit the application, though. It's for examining Javadoc coverage, but it's written in Visual Basic, and hence single-platform. It works by looking at the generated HTML instead of the source, so if you've got a non-standard doclet, it'll fall over and die. It presumes to recommend word counts for Javadoc—from 200 words per interface definition to 10 words for each instance variable. This just reinforces my belief that Javadoc coverage tools don't encourage better documentation, they just encourage more documentation. From the disclaimer: “HCi Consulting Pty Ltd would like to warn potential users that this product may provide misleading, dangerous, and just plain silly results if not used by our staff experts.” In other words, “If you're stupid enough to use this tool, you'll probably want to pay us for consulting, too.”</rant> Edit: Ah. They're an ISO9000 consultancy, suddenly everything is clear. When I lived in Perth, I worked for an ISP. The owner ran an ISO9000 consultancy out of the same office. Whenever you added a new user, they had to be entered in four different places: the Unix passwd file, the contacts database, the accounting software and a paper file. This procedure led to the four sources of data never agreeing with each other, and obviously much hilarity ensuing therein. The thing about ISO9000, though, is that any procedure is a good procedure, so long as it's documented. You could say “all new customers must be entered into the database using only your left hand, while standing on your head in a vat of cow dung”, and so long as that was written down on a sheet of paper and photocopied a thousand times, you'd still qualify for “Quality Management” If you've got a nice cover-sheet where you tick the boxes for each place you have to enter the information, the inconsistency becomes the fault of the employee, not of the overly complex steps he has to take. Bleah. I mentioned the bad state of affairs to my boss when I started, told him it'd probably take six months to write a replacement system (since I'd basically have to have done most of it myself), and that he'd better start now because the more the company grew, the harder it'd be to replace the broken system and transition to the new. Needless to say, twelve months passed, the user-base grew by about a third and the number of different services being offered doubled. Then I was told to drop everything and start on the replacement system. Number one priority. I was also asked if I could have it done by the end of the month. Oh, and I couldn't really drop everything because I was also having to spend the next few weeks filling in for the system administrator who was on holiday, so I'd just have to do overtime to get it done. It's about then that I started applying for jobs elsewhere. 6:00:25 PM

Mike: Why don't people understand that opening windows for me is a bad idea? It's one of the original usability sins. Erik: I spawn new windows, and I like it. So stop your whining. Charles: I'm on Mike's side. Spawning new windows is annoying. I use tabbed browsing. If you're spawning new windows, you're breaking out of my carefully organised tabs. Spawning new windows is bad accessability Spawning new windows is presumptive. It's saying that your style of browsing is better suited to my needs than my own. Spawning new windows is arrogant. It's saying “I know my site is more important than the site I'm linking to, so I'm making sure you have to come back!” Rubbish. That's my decision, not yours. I generally browse by opening up three quarters of links in new tabs, but even then that's my decision. I certainly wouldn't presume to force it on anyone else. 11:35:07 AM

Name: Error Codes Context: You need to provide a stable platform for clients to interpret errors occurring in a networked application (for example a web service) Forces: You want to make it as easy as possible for a client writer to inform the user of abnormal conditions. The easier it is to write a client, the more likely your service will be quickly adopted. You want to make it possible to write an advanced client that intercepts errors and handles them internally. For example, the client may wish to present messages in another language, or perform some action other than reporting the error to the user. Clients should not break if a service's human-readable error codes are changed. Therefore: Present error messages both as an easily machine-parsed code, and as a textual description. Client writers may choose to pass the description straight to the user, to interpret the code and take some other action, or some combination of both. Examples of use: SMTP, NNTP, FTP, HTTP, etc... Notably absent from: Pretty much every web-service designed by amateurs. 8:36:51 AM

Cory Doctorow has made one or two posts about warchalking recently. In one of the comments on his site, he makes the claim that “...the default assumption of the Internet is that open services can be connected to. That's as true of httpds on port 80 as it is of WiFi.” I'm sorry, but this is simply not true. It is like saying that because you can assume it is legal to walk into a shop with an unlocked door, all unlocked doors are fair game. WiFi is not WWW, and a WiFi network is just as likely to be private as it is public even if it's not properly secured. If someone forgets to lock their door, that still isn't legally an invitation to wander through their house, even if someone's graffiti'd “Come Inside!” on the steps. firewall-wizards moderator, Paul Robertson, put it like this: While I realize that there are people who advertise their own networks, I think that the potential for damage for folks with large networks and angry people who've “moved on to persue other opportunities” makes the whole idea bad. Couple that with people who deploy networks and don't understand the technology and it gets worse. IMO, the folks wishing to provide open access should have chosen a common SSID and perhaps even a common WEP key. People who conciously choose to make their nets open shouldn't have a problem doing that- taking the insecure default, or worse-yet having to manage keychanges and SSID changes over a large enterprise because the intern in the mail room is pissed at his boss and things it'd be cool to publish your WEP keys and SSIDs in midtown Manhattan is a bad thing. Someone's pissed off kid chalking the home “behind the VPN” access point is a bad thing. The default of attackable and exploitable until made otherwise is a bad thing, some people will take advantage of this and worse-yet will encourage others to (perhaps inadvertantly) trespass on networks that don't belong to them. The last thing we need is some poor innocent being prosecuted for hacking because they saw a chalk with the WEP key and SSID and thought it was made by the network operator, but it was really put there by the receptionist's ex-husband. The best thing the warchalking community can do right now is to follow Robertson's advice. Pick a standard naming scheme for open networks, and publicise it as widely as warchalking. Otherwise, it'll all end in tears, and protestations that you thought you weren't doing anything wrong are going to be soundly, and deservedly ignored. 12:44:55 AM