Beta testing FishEye

I was going to blog this tomorrow, but tomorrow is April 1, and that just doesn’t seem right.
I’ve been involved in beta testing of FishEye which is a CVS repository browser. I’ve just installed it and got it running, and I have to say that this thing rocks.
What I’m going to say needs to be balanced with this being a 0.1 beta. So, it’s really early on in the cycle. The functionality is rock solid, and I didn’t see any issues with it actually working and providing the reporting functionality. It’s really well finished off in that respects, but I’m also early on in looking at the complete functionality, such as the complex searching and query languages. I also need to look at how the RSS functionality works.
The other thing to mention is that the guys (and gals) at Cortex are super-responsive, and about 10 minutes after my first set of feedback rolled in via email, I had responses from their development team.
A word of warning to those looking at the beta, FishEye creates a bunch of directories and log files, it’s worth starting the application in a separate directory to the install dir. It’s not terribly tragic, but it did surprise me.
The one main feature that I’m waiting for is the remote CVS integration. That’s in the works, it will be neat to see how they implement it.
So, do the team at Cortex a favour and go and buy a copy of Clover their Java test coverage tool. After finding out their an Australian company I feel really bad about recommending jCoverage and providing those patches to make jCoverage more useful. Go and use Clover instead, support Australian businesses.

Why is James Turner such an arrogant prat ?

Now, I’m not the sort of person to resort to ad-hominem attacks, but when I read an article “Why Do Java Developers Like to Make Things So Hard” (no, I’m not linking, find it yourself) and one of the actual attacks is on myself and my co-developers, well, I feel that deserves a response.
This is what I am pissed about;
Immediately, I ran into the thing I hate most about Java developers. They (as a group) are in love with how clever they can be. The Bouncy Castle code was a morass of Factories, multiple different classes that needed to be configured in order to make everything work right, and even at that I couldn’t get it to work after a day of messing around. The mantra in Java seems to be to never hardwire anything, so that in the hypothetical “someday”, you can rip out class X and put in class Y by just adding a Factory. The end result however, is code that’s confusing to use, hard to maintain, and never seems to be very well documented.
First I’ll share a few things. BouncyCastle is a set of Java cryptographic API’s that implement base algorithms (like AES, DES, MD5) and also includes a bunch of extras like S/MIME and PGP. So, there’s a lot of code there. What’s more it’s been implemented in such a way that the majority of the functionality can run on the J2ME platform as well as be conformant to the Java JCE. And it’s all free. Completely free, more free than the GPL free.
Now, to be completely clear. Fuck you James. We aren’t in love with how clever we are. We do something and give it away so other people can benefit. We do what we do because we enjoy the community and the joy of writing code. Much of the code is a “morass of Factories” because that’s what is required. Using the high level abstractions such as the JCE require that. For our provider to be conformant with the JDK JCE it is required. To get the code to work with the variety of implementations (especially things like IE, Mozilla, PGP, GPG) there needs to be higher levels of abstractions. And the PGP implementation is new, and what’s more the PGP specification is broken and confusing and implemented many different ways. Of course, you don’t care about that. You only care if it worked for you. And what’s more you only care if it worked for you in the time you were willing to spend. Clearly your knowledge of security and crypto is very limited which was also inhibiting your ability to solve your problems. But that didn’t stop you flaunting that ignorance and masking that with an attack.
And onto the specifics. James was trying to use the newly created PGP libraries. Now, we’re the first to admit that we’re not perfect, and the PGP libraries are pretty new and there are bugs in the implementation as we find all the corner cases that exist in the PGP world. However James couldn’t get it to work at all. Now, that’s not a crime as some of this stuff is pretty confusing. So, James asked a question on the mailing list. For 2 days there were responses from the BC developers trying to help James sort out his problem. And then, without a word of thank-you, he’s gone. All of this can be seen in the BC mailing list archives. It turns out it was all too hard for James, so he went and found a Perl library.
As to documentation, well, that’s a perennial problem. One that we’re aware of, but it seems that most people can resolve that issue by themselves without having to attack the project in a public forum. There are examples, but they only cover the most basic operations. Most of the issues on the mailing list have pointed to the difficulty in selecting the correct keys from the PGP keyrings (which appeared to be James’ problem). Interestingly in the latest beta the examples are expanded to show better how to select keys, hopefully that will help people better.
Most of the people who have used the libraries have sorted it out with a minimum of fuss, and not felt the need to have a screaming hissy fit in public about how hard it is. I suppose that says more about the ability of James Turner than it does about the complexity of the libraries, and how certain people feel about taking from an open source project rather than being part of the project. For the benefit of the BC mailing list and the majority of the people who’ve used our libraries, I thank you for your patience, kind words and feedback. You are all the ones that make it worthwhile. I hope that James doesn’t need help from too many other open source projects from here on in, because I’m not sure he’s going to be too welcomed.
I’d be interested to hear from other BC users. Do you all feel the same as James Turner ? Are we nothing more than just a group who are in love with how clever we are ? Or is there some value provided by the project that it’s worth spending some time asking questions on the mailing list, getting help ?

Eclipse M8 is out – Beware there be dragons

For the 3rd or 4th release in a row they’ve changed the way to configure the key bindings, and this is the most sucky version yet. Almost impossible to work out what your keybindings are, and what hierarchy the keybindings follow. What’s a Window ? A Dialog ?
And for the first time since I’ve been downloading the 3.0 milestone builds they’ve completely screwed the emacs key bindings. Normally they’ve been marginally crapulent, and obviously for M6 and M7 they default values were set by somebody who has never used emacs key bindings in their life. M8 however just doesn’t work. No amount of coaxing will allow emacs key bindings to work, presumably short of rebinding the entire default keybinding set to look like the emacs key bindings.
Isn’t there any regression or unit tests for the emacs keybindings ? Sheesh.
Now, on to the next most craptastic part of M8. It completely borks the workspace configuration so that once you’ve upgraded to M8, found that the keybindings are screwed, and you go back to M7, then the workspace defaults are gone. My newly configured JRE (with BouncyCastle included) was gone, my colours and fonts for the Java editor were gone as were a couple of other defaults that I can’t remember off hand. Feh, took me quite a while to get it back. So, remember boys and girls, export all your settings from the preferences dialog before upgrading, or if you want to go back, you are hosed.
So, I give M8 a solid “American Idol’s contribution to world music” on the Sid and Nancy Scale.

Free beer is good, making your own beer is not always better

It seems that every man and his dog have been writing about the virtues of an Open Source Java and how it will solve world hunger, the conflict in the Middle East and the confusion over how Britney Spears has just been announced FHM’s most sexy woman.
It was this blog entry by Eitan Suez that was the straw that broke the camels back.
Now, before I am tarred with the pro-Microsoft brush, I’d like to say that I’d like to see Sun change their licensing policy to allow the Linux distributions to distribute the JRE and the JDK as part of a package. I really don’t see the harm, and I can see that it can only help, mostly to shut up a bunch of whiners who want to jump on bandwagons without the faintest clue. I’m very happy with the way Sun has treated Java, and I don’t see how open sourcing the codebase will help. At all.
To the real point, the pro-open source Java crew seem to be collecting around the simple view that when Java is open sourced, then all the bugs, and issues in the JVM will be magically fixed by all the motivated and freely available Java programmers just rushing to spend time fixing them. And I quote;
“Any features that developers claim are missing would quickly be contributed as patches to the J2SE codebase.”
To this I reply: “Absolute bollocks”.
It is simplistic and naive in the extreme to take this view. And I can only conclude that it comes from people who have never, ever been involved in an open source project of any sort. In all the projects I have been involved in, either as a maintainer, or as a patch provider to an existing project, the successful projects are run by a core group of people who manage the process, accept patches to the codebase and make the necessary releases. The source is available, CVS write is not available to everybody, but there is no hue-and-cry for Apache or Linus to open up write access to each project so that J Random Developer can just dump in their fixes.
How is that different to what Sun does ? For a start, all the source code for the Java releases is available to anybody who wishes to download. They can then find the problem, create a patch and submit it to Sun for inclusion in the next release. How many people have ever done that ?
I’ll admit that I speak from ignorance in that I don’t know how many people have done this and had their patches rejected, only the Sun engineers can really respond to that, but I’ve been working on an open source project for 4 years and the number of patches that comes in is low, very low, compared to the codebase and the number of developers on the mailing list. (To those who have supplied the patches, bug reports for BouncyCastle, I thank you for each and every one, I’m not raining on your generosity, I’m just making a point that in general, developers want to use the software provided free by others, rather than be deeply involved)
Maybe to clarify this point somebody should start a register of all these Java software developers who are just craving to provide fixes to Java over all these years to show Sun (and me) how much support they have. Of course, the developers will actually have to do the work, and that’s the sticking point, I just don’t see it happening. Go ahead, prove me wrong. My guess is that most of the cry for open sourcing Java is over some weak religious ground by feeble minded followers and it’s all being dressed up with this additional resource rhetoric which is completely false.
Focus your efforts on getting Sun to change the licence model if that’s what is really wanted, but I suspect that you’ve well and truly burnt your bridges by now, which is terribly sad because that would have been a cause worth working towards.

Setting up an Eclipse installation for smooth upgrades

I’m going to admit that I like Eclipse. Maybe it’s an quirk of fate because it was the first well-featured modern IDE that I used, or maybe I just think the same way that the Eclipse guys and gals do. Whatever the reason I’ve invested quite a bit of time and effort understanding how Eclipse works and getting the most out of Eclipse. I’ve tried IntelliJ IDEA and I haven’t found it anywhere as nice to use as Eclipse. Most of my cow-orkers give me grief about it, oh well maybe I’ll try version 4.0 to see if CVS integration actually works.
Now, onto the real topic. Eclipse does have some interesting features in the way that the internal structure of the download is set up by default. What this means is that there is a lot of intermingling between the core libraries for Eclipse, the extra plugins that are installed by the developer, the configuration and customisation information and the workspace. So when upgrading Eclipse, you have the choice of trying to find out what bits have been changed, or just dumping the new version on top of the old version. After seeing the pain and suffering of Jason when he was doing this, I decided to find a better way.
To get the most out of Eclipse and the least pain for developers the best way to handle the setup is to partition all those components as best as Eclipse will let you. What follows is a process to follow during initial installation, and then for each upgrade.
Good luck !
This process works for me, it might not work for you.
If you trash your installation, your wife leaves you, your computer explodes or your camel gets fleas then it’s not my problem, don’t complain to me about it. When in doubt, make a backup. And even when you’re not in doubt make a backup. You have been warned.

NB: This process is for Windows, and it has worked under Windows 2k and XP. Anybody using a Unix variant should be smart enough to convert it to their needs. If you’re not, then re-install Windows.

Installation

To separate the directories that are used by Eclipse, create the following directories.
Step 1: Create the directories
c:\eclipse (unpack Eclipse zip file to here)
c:\eclipse_local (this will hold “local” plugins)
c:\eclipse_work (this holds the metadata directory)
Step 2: Create the link to the local plugins
To get Eclipse to notice the eclipse_local directory, create a file (and the associated subdirectory shown below). You’ll need to create this directory (or copy it from an old version) each time you upgrade as the Eclipse root directory is freshly created
c:\eclipse\links\.link containing the following single line: path=c:\\eclipse_local
Now, create the directories:
c:\eclipse_local\eclipse\features (this will hold local features)
c:\eclipse_local\eclipse\plugins (this will hold local plugins)
This is where to put the “non-core” Eclipse plugins (and features). These are the plugins that are added to your environment for development that are supplementary to what Eclipse provides. Currently I have things like checkstyle, profiler, dbedit and simian in my local plugins and nothing in my local features.
Step 3: Create the runtime shortcut
The final step is to create a shortcut for Eclipse to use the c:\eclipse_work directory. This is very important, or you will lose all your key shortcuts, and any other customisation that you make when you upgrade.
The shortcut information should have in the “Target:” field the following C:\eclipse\eclipse.exe -data c:\eclipse_work Pay attention to the “-data” option in the target. Now run Eclipse using this shortcut.
These three steps only need to be done once. It’s a bit of setup, but well worth it in the end.

Upgrading

This is where all the separation of directories pays off. I have been upgrading Eclipse from a nasty 2.1 installation to the current 3.0 M7 with minimal hassles. The sorts of things that have caused grief has been the changes in plugin compatibility (which means just upgrading the local plugins) and compatibility with the keybindings which seemed to change every second Milestone build. Yes, it was a hassle redoing my Emacs keybindings every 2 versions, but hopefully that will be fixed soon. I noticed that later releases allow the export and import of keybindings which will help.
Step 1: Rename the old version
This is fairly easy. Just rename c:\eclipse to c:\eclipse_{$version} (such as c:\eclipse_m2). This saves the old version should anything bad happen, or the version is just too buggy to use and you want to easily go back to a previous version.
Step 2: Unpack the new version
Unpack the new version to c:\eclipse. This will create a new directory structure where the old version was located. This is important because we are using basically a fresh install each time.
Step 3:Recreate the Links directory
Either create the links directory as shown in step 2 of the installation instructions, or just copy the links directory from the old version. I’ve been copying the directory from previous versions without any hassles.
Step 4. Run Eclipse using the shortcut.
This will still display the “running post-install” text that occurs when you install Eclipse for the first time. I’ve had Eclipse complain about workspace/perspective corruption when I run it for this time.
I’ve just shut down Eclipse and restarted with no other changes and it works perfectly.

On the road to recovery

I’ve had my first visit to the surgeon after leaving hospital, and he removed the bandages and this is the results.
This image shows the compass hinge from the front. This allows me to flex and extend my elbow and start my physio early. This image shows the incision from the surgery and the pin sites from behind.
I can now shower without having to put a plastic bag on my arm, and I’ve got a daily regime to keep the pins (or as I like to call them “extreme body piercing”) clean and free from germs.
I’ve also got a ratchet device which fits into the holes in the outer rim of the compass hinge. This device comes with a handle which allows me to turn the ratchet past the current flex and extend points of my muscles. So, basically it’s a version of the medieval rack for specific locations. I expect that I’ll be having not a lot of fun and a lot of pain from that device over the next couple of weeks.

Pairing in a hospital

I’ve had the unfortunate situation where I broke my elbow and shoulder and ended up in hospital.
Due to the nature of the injuries, I was given fairly significant doses of morphine and pethadine (both pain killers). What I was really interested to observe was that nurses all work in pairs. When giving drugs to patients, one of the nurses takes the role of the driver and checks the name tag on my wrist (and asks me my name if I’m awake), looks up the UR number (presumably a patient number) and the other nurse will compare that number and name to the information that they have on a worksheet for the time, type and amount of drugs that I could have.
Now, maybe the hospital that I was at (Epworth) was a better hospital than many, but it was certainly interesting to watch them do exactly the same sorts of things that I do when pair coding.