On Slashdot I found a link to the following superb rant about perl. For instance [Perl] rewards idiotic behavior in a way that no other language or tool has ever done, and on top of it, it punishes conscientiousness and quality craftsmanship -- put simply: you can commit any dirty hack in a few minutes in perl, but you can't write an elegant, maintainable program . Many a true word. The same thread included these other links What's wrong with Perl and Is Perl Difficult? that are also interesting.

I'm not saying that perl isn't useful but I do have some sympathy with the view that it has a corrupting influence. I know that every programmer thinks that they are above average, and that the code they write is fine whatever the language they use, but we all know that can't be true. Using a language that encourages good habits and rewards thoughtful approaches rather than hacking can be beneficial to even the best programmers, especially the self described best programmers.

pictures of cats. This isn't my cat. It just struck me as an excellent example of the picture of my pet genre. A wet cat.

From TheInquirer a report of a report. Large firms hold off Web services because of security fears Pretty much matches what I've seen, lots of talk and RFQ check boxes but no real action.

I have linux on my machine at work and here at home. When I work from home I have a couple of options. Remote XWindows over ssh, which is pretty slow, or a local copy of the sources to work on. The best way I've found to get a local copy is to use rsync to replicate my source directory from work to home. The alternative is to use CVS to update a home copy of the code. Not only is rsync faster it also lets me work on stuff I haven't checked in yet. Because I'm syncing with my own copy of the sources I don't have to worry about overwriting other people's changes and I can either check in the code by logging in to work with ssh or just wait and do it the next day.

I'm sure I've written this before, and the actual idea is taken from elsewhere as well. However, the current post was inspired by a thread in The Joel on Software Forum about whether Linux would become a mainstream OS. One poster wrote To get Microsoft's security fix information all you have to do is go to micorsoft.com. One stop shopping. comparing this favourably to Linux.

This weeks MS SQL worm/virus gives the lie to that claim. Just having the fix available isn't enough it appears, looks like you also need a good Windows admin to make sure all the security holes are closed. RedHat also an auto install of fixes similar to windows and it works very well in my experience.

What Linux has done at this point is reduce the cost of a decent stable OS to around zero. Any money you're paying to Microsoft must therefore be for something above and beyond a decent stable OS. If you think what you're getting is worth the money then that's fine. Other people are starting to decide that it's not and that's where the problems start of MS. The cat's out of the bag on this one, if windows is worth $100, or whatever, then it must deliver that amount of value in addition to just being an OS.

From The Inquirer comes a link to Personal Computer Milestones

I'd never heard of this law before I saw the link on Haddock.org. The basic statement is Good customers make for good products. When the customer can't distinguish a good, but more expensive product, from a poor but cheaper one the cheaper, but poor quality, products come to dominate the market. A marketplace with more experienced customers with a better understanding of what they want will support better products. I wonder how this applies to the product I work on. We've certainly faced the problem of trying to sell something for which there wasn't a well defined marketplace, perhaps we're going to next have to fight off a bunch of poor quality rebrandings of software originally written for other domains. Anyway, here's Moen's Law of Bicycles.

This tool, Macker, may be useful. I'll have to give it a try sometime. At work we check separation between layers by breaking the source code into different modules and ensuring that only the appropriate modules are included in the classpath at compile time. Each "application" is built by combining a number of different modules.

A little addon I developed for ant. It's an implementation of the org.apache.tools.ant.util.FileNameMapper interface that takes a .java file and returns the name the file should have based on its package statement. I needed it when I was generating code using the ant style task. All of the .xml files were in one single directory but the generated code had to go into multiple different directories depending on the package. After generating to a single output directory an ant move task was used like this example.

<move todir="${basedir}/src">
  <mapper classname="com.zanthan.ant.PackageFileMapper"
    to="" from="${basedir}/generated"/>
  <fileset dir="${basedir}/generated">
    <include name="*AutoGen.java"/>
  </fileset>
</move>

Here's the source code. It's so simple I don't think I need to post the supporting stuff needed to compile it.

At the moment the programmers working on IntelliJ are in the that excellent position of being able to use their product to write their product. I would imagine that IntelliJ is written using IntelliJ, and I think this must account for some of its success. Whatever is an annoyance to IntelliJ's users will be an annoyance to its developers first, whatever makes developing the product hard or slow will make using the product hard or slow, and conversely whatever makes development easier and faster will make use easier and faster. If you can arrange it so that your software developers are also your first software users it can certainly help your product.

It's going to be interesting to see how the EJB support in IntelliJ develops. Obviously IntelliJ does not itself involve any EJBs so using and testing that functionality won't be an intimate and inescapable part of developing it. Will they be able to come up with something as good when they're not working first to please themselves?

A couple of side notes. On my recent trip to Microsoft I noticed that several developers there used emacs instead of VisualStudio.NET to develop in. Clearly this is not a good thing. If you can't convince your own internal developers to use the product it doesn't bode well for outside users. Nathaniel S. Borenstein talks about this issue, getting editor writers to use the editor they're writing, in his great book Programming as if People Mattered. Doing it by fiat doesn't work. He says you need to provide some compelling feature that the current editor doesn't provide, and can't easily be hacked in. For me and IntelliJ that was the refactoring support.

At work we don't currently use our product to develop our product but that's certainly one of our longer term goals. Certainly whenever one of the developers has to spend any time working with the product they come back with ideas they immediately want to implement to make things easier. Our JMS based debugger for debugging processes executing on the server from an authoring environment running on a client machine was the outcome of one of these ideas. The more of the tool that is build from the tool using the tool the better it will be for us and our customers.

Obviously we also need to keep in mind the main purpose of our product but the more contact the developers have with product use the better. This is the idea behind some company's system of rotating developers throught consulting/professional services from time to time, to keep them in touch with what the thing they are developing is actually being used for.

In respose to a comment by gavin about my Editing with IntelliJ experience. I'm using my own set of keybindings. I've not made many changes yet though. When I was using the emacs bindings supplied I had the problem he mentions, useful IntelliJ functions were moved to weird places. What I did was copy the default keybindings set and mody them. Initially I just put the cursor control functions on Ctrl-f, -b, -a, and -e. Any IntelliJ ones in conflict I moved to Alt-. So find declaration went to Alt-b. After using emacs a lot Atl-b is no more weird than Ctrl-b. I'll probably make some more changes in the future as I use IntelliJ more and find things my fingers stumble over. It may be that Ctrl-i for tab, and Ctrl-j for enter are going to be the next ones. The way that IntelliJ handles sets of keybindings makes it easy to switch between them, and you can't change the supplied sets, so at least you can't screw things up too badly.

I spent some time over the weekend trying out IntelliJ for editing Java and I'm very impressed, which is surprising as I'm a real Emacs bigot. Once I got used to the keyboard shortcuts I'm found it a productive environment. The remaining thing I have remember is to let the IDE do the typing. With autocompletion, automatic management of imports, and a lot of refactoring support it's faster to type Ctrl+space and select the correct option than to type the text in yourself, provided you remember to do it! As for moving files between packages, it's the only way to go.

Anyway, my point here is a quick shell script I use to set up the external JjavaDoc support so that IntelliJ opens external JavaDoc files in a running Mozilla instance under Linux.

#!/bin/sh

if `mozilla -remote 'ping()' &> /dev/null`
    then
    mozilla -remote "openURL($1)"
else
    mozilla $1
fi

exit

In the IDE Setting - General set the Web Browser path to point to this script. In Project Properties - Paths - JavaDoc Paths add the paths to where the JavaDocs are stored. You need to set the path so that translating the package name into a file name, prepending this path, and appending .html will locate the correct JavaDoc file.

I've just finished reading an interesting book I thought I'd recommend. Called Craze: Gin and Debauchery in an Age of Reason, by Jessica Warner, the subtitle, in a mock 18th C style is Consisting of a Tragicomedy in three acts in which High and Low are brought together much to their Mutual Discomfort. Complete with Stories, some witty and some not, conducive to medidation on Recent Events. It's a look at the Gin Craze of the first half of the 18th Century, the first modern "drug epidemic", and the reactions of the ruling classes to it. You've probably seen Hogarth's famous propaganda prints Gin Lane and Beer Street, produced as the craze was coming to an end. At the end of the book Ms. Warner relates the reactions to gin consumption by the lower orders in the 1700s to the reactions to current drug epidemics, such as crack, a great read.

A little bit of a rant. I think that many of the comments to this article, as usual, show a mistaken view of XML. XML and verbosity. You'd think that now that XML's been around for a while what it's good for and what it's not would have sunk in more. Too many people seem to disucss use of XML thinking only of single user desktop applications, they assume that they control all of the uses of the data, or that they will be the only people writing or parsing it.

In my opinion the greatest reason for using XML is that there are more interesting and useful things to be programming than a parser for yet another data format. If you use a standard parser then that's one less thing to worry about and maintain, and it's one less thing to have to teach users or developers of your software about.

Some good advice to those in the UK who are unused to snow. A user's guide to snow. I do remember when I lived in London that one year there were snow falls heavy enough to cut off some parts of the south of England. Here in Austin though the slightest fall brings the city to a complete halt. Snow's not unknown though, it just never stays on the ground very long, probably a couple of hours max.

Look here for the latest developments and releases of SEQUENCE.

Bob Lee has produced a fantastic application by combining the SEQUENCE tool I wrote with his own jAdvise (a much more sophisticated piece of code). It produces sequence diagrams from executing code and is the sort of thing the inspires, and embarrasses, me into picking up SEQUENCE again and making some improvements.

Article from Joshua Mica Marshall about Dick Cheney and his impact on policy in Washington.

From The Register comes Microsoft's masterplan to screw phone partner - full details. This is an interesting case, especially, as the writer of article says, if the discovery phase of the trial plays the way it might. Whether or not to partner with Microsoft must be an interesting decision these days, it looks like you'd have to be pretty desperate to risk it.

Mainstream coverage of the Lindows Microsoft spat. What Marx can tell us about Bill Gates

Another interesting Gamasutra postmorten, this time on a game called Dungeon Siege. I've found these things interesting in the past. The What Went Right sections are generally good but the What Went Wrong lessons are always great. You can have fun matching both sides up against the classic development mistakes. The examples of how these errors played out, or were avoided, in real projects are very helpful in fixing the ideas in your head.