A new version of 1060 NetKernel was released today, version 3.1. I had a brief play around with the previous release but never really had the time to dig into it too deeply. It always looked pretty neat though, a possible good solution to base adapter (in the TIBCO sense) style components on. One of the advertised features of the new release is a newly written ‘Getting Started Guide’, so this may be a good opportunity to have another look.

For RvSnoop I’m currently working on adding namespaces to all of the files that are used to save the application preferences and also the project files. This is a Good Thing in and of itself, as it allows me to use XML Schema to validate and document the files formats. But, more importantly, it gives me the opportunity to refactor as I go alond, the general plan is to make the projects in the next release be based on directories rather than a single XML file, this will allow me to use a disk based storage mechanism for messages so that they will be persistent across sessions.

Playing Well With Others

At the same time, I’ve taken the opportunity to include some of the Apache Commons libraries in the build. There were (well, still are) a number of small utility classes scattered around which I’m planning on replacing with the versions from Apache.

One side effect of this is that the build is increasing in size, to help control this I’m going to remove the Berkeley DB dependency from the build. I was origiannly planning to use this for the on disk message store but I’ve changed my mind here. My current thinking is to just write the messages out to files but to have a set of indexes (probably built using Lucene) as well for searching and sorting.

There should be another (alpha) release out later this week with the Commons and Berkeley DB changes complete, and a release next week with the new project structure.

There is nothing more annoying than people who insist on standing up and talking loudly on their mobile phones in the middle of an open plan office (just one more reason why open plan offices suck arse). At least in the past it was just a few ignorant tossers who did this, but now with Skype a whole bunch of otherwise considerate people seem to think it’s fine to yammer away at high volume while sat at their PCs.

Bastards.

Although it’s an open source project that anybody can help out with, in practice RvSnoop is developed by me at present. However, a couple of people have asked — - either in the forums or by email — - what the current development status is. Well, in a word, it’s going slower than I had planned!

However, I’ll start posting to this blog a little about what I’m working on and what my current plans are, and also try to start making more frequent releases.

I’ll rearrange the distributables slightly as well, given the speed of most connections these days I no longer see the point of keeping a binary only download so I’m just goint to include the compressed source and API docs will all of the releases, this will be labelled as the RvSnoop Stable release.

I’ll make more frequent releases of the code that I am working on as a RvSnoop Development release. But first, a little explanation of what you can expect from these unstable releases. I’ll post later about my plans for the upcoming releases.

It’s All Greek To Me

Projects use diffferent terminology for there release schedules, here’s how I’m using the terms.

Alpha

If a release is labelled alpha then it means that I am still adding new features and working on major known bugs. Once the release is feature complete and all of the major bugs have been squashed I’ll go through and clean up all of the strings, finally I’ll spend some time cleaning up any glaring UI problems.

Once this is complete I’ll relabel the release beta.

Beta

Moving forward one of the main points about the beta release is that it will be considered to be a string freeze release. I’m aiming for release 1.7 to be fully prepared for internationalization and hopefully some of the people who have been using RvSnoop will help out with translations.

Also at this point the UI will be basically finished, so the beta releases are for testing and minor bug fixing. Also during this phase I will run all of the analysis tasks (currently only PMD, but more are planned) and clean up whatever they reveal.

Why the fuck does this exist exactly? It seems to be like some twisted rite of passage that Java developers need to write their own logging API. I confess that I’ve even suffered from this although, in my defence, I kept mine to a single class and plan to throw it away in the very near future.