Damon Hart-Davis: Code Download Page

I have made some of my code available for download and use; I hope it is of interest. I'd be very pleased to know of how what you find is put to use.

Unless otherwise stated, most code published here is published under a BSD-style licence, and I retain a right to do what I like with the code.

7LEDs

A fun PICAXE (18M2+) project to flash 7 LEDs (six in a circle, one in the centre) with a fair degree of randomness and unpredictability, and that responds to ambient light levels. This even makes some attempt to scoop up a little real entropy from temperature and light inputs.

ThroughputMonitorFilter

The ThroughputMonitorFilter is a Java Servlet filter that can be used to monitor Web server performance from the user point of view, ie how quickly requests are responded to, regardless of CPU (and other resource) availability.

In particular, this may be useful in tackling usability problems arising from lock contention (insufficient concurrency) and internal I/O (eg database) performance issues.

Here is the source, documentation and JAR as a ZIP for V0.3.1 (ZIP for V0.3.0, ZIP for V0.2.2). Still with many rough edges, but has been in daily use for a long, long time! Requires JDK 1.4+ to run.

REUtils

The code behind the live GB nation grid carbon intensity page can be found here.

The Multimedia Gallery

The code and documentation for the DHD Multimedia Gallery can be found linked to from its resources page.

IsDebug Class

It is often desirable to strip out some extra instrumentation and tests in released/optimised code, for reasons of commercial sensitivity and application size and speed. In some cases, such as embedded code, it may be very important to make the released code as small and efficient as possible.

In Sun's JCP (Java Community Process) new support for run-time enabling of extra internal checks (asserts) and testing is covered in JSR-041. When this support becomes available in main-line JDK releases it will be the preferred way to handle such selective checking for normal applications, but the support I have developed is still appropriate for extra code that would be inappropriate to leave in shipped releases for reasons of, for example, privacy or size. My support interacts well with the new Assert support from Sun for such cases.

This support consists of two jar files, each of which contains a definition (the .class file and the source file for reference) for the same class, ORG.hd.d.IsDebug. This class contains a single public static final boolean isDebug. In one jar (IsDebug.true.jar) this value is true, and in the other (IsDebug.false.jar) it is false.

When building code that is to have extra checks, have the IsDebug.true.jar in your CLASSPATH; for release code have IsDebug.false.jar in your CLASSPATH. Then use code such as if(ORG.hd.d.IsDebug.isDebug) { doExtraChecks(); }. This will be entirely eliminated by an optimising compiler when IsDebug.false.jar is in the CLASSPATH (or later by a good JVM or JIT or HotSpot). If you use tools to trim out unused methods and classes before wrapping up your release jar or zip file, they will probably be able to throw away all the support just used for extra checking, just as you would like.

(If you do not build release and non-release code in separate areas you will need to force a full rebuild if you change which jar is in your CLASSPATH between builds, to make sure the effect of the new value of isDebug is applied consistently throughout.)

The two versions of the file:

IsDebug.true.jar (7kB) with the flag true.
IsDebug.false.jar (7kB) with the flag false.

ZapDisc

This is a little Java utility to help you try to ensure that sensitive data is gone from your discs when you have deleted it.

First delete your files in the normal way, but really delete them rather than moving them to a recycle bin or renaming them.

Then run this program (having compiled ZapDisc.java) as "java ZapDisc".

It attempts to gobble up all free space into a file (ZapDisc.TMP) and overwrite it several times with large blocks of random data to actually remove all trace of the underlying data if possible. If you have a per-file length limit, or quotas, etc, you may need to let the program make a pass or two of writes in one file, kill the program leaving the file intact (but rename it so it continues to hold the disc space) and run the program again until there is no free space.

Make sure that you do not leave free space, files in the recycle bin or equivalent, etc, and beware of backups, swap space and hibernation files.

When you have done be sure to zap the generated files to free up the disc space again!

So this isn't perfect, but it may help a little.

ParTasks

Threads can be quite messy and tricky to use raw, a little like pointers. Following a proposal I made to Sun in 1998, I have developed a simple class which illustrates some related ideas and which I use myself in, for example, the Photo Gallery.

This is based on:

Keeping a global track of CPU use and tuning the level of threading to suit.
Allowing for I/O-bound and CPU-bound threads.
Using a Collection to hold a group of data items to have threads applied to them.

Download a zip of V0.1 of the source, javadocs and optimised .jar file or browse the javadocs online or get ParTasks-0.1.0.jar itself.

Because I seemed to be having some problems with the particular 0.1.0 JAR file in J2EE servers (possibly because of the name or (for example) some problem with the manifest, I've built a new version with a less toxic name and compiled with JDK1.3.0's javac, called ParTasks_0_2_1.jar. This should not behave differently to the 0.1.0 version. There's a version with the public inner classes broken out to top-level, called ParTasks_1_0_0.jar.

You can also see a collection of material (including a sample solution) for a simple student exercise with ParTasks in ParTasks-Ex-0.1.0.zip.