Latest Knoppix

Note to self, latest version of Knoppix is 3.8.1. If I have time, project this (long) weekend, is to install Knoppix on our old home PC. I have the version that comes with Knoppix Hacks but might want to upgrade.

Places I’ve visited

There’s some weird and wonderful stuff out there. Here’s a map I created at this site of the places I’ve visited in the world so far.

It’s actually a little misleading because I’ve only been to Georgia, Florida, Arizona and California in the States and New South Wales (well actually only Sydney) in Australia. Still it’s a bit of a giggle.

A Weekend’s Work at the Open Source Coalface

I got my hands dirty trying to fix a bug in Megg last week. My main motivation, for what turned out to be a long weekend’s work, was a desire to use Mike Clark’s pragmatic automation template announced back in July last year.

  • It wouldn’t load from the URL.
  • It wouldn’t load when I downloaded the zip file and copied it into ./templates/pragouto-template.
  • It wouldn’t load from ./pragauto-template.
  • In fact, it would only work when I added it to the templates collection in the project directory and added it to megg.jar using the “ant dist” target.

Intrigued, I uploaded the latest HEAD version from the CVS repository at sourceforge. The problem became even more intriging when I ran “ant test” on my new sandbox copy and it failed!

I dug deeper and found that the test failed because megg was looking for the provided java templates directory at./templates/java but failing to load ./java/megg.xml (not ./templates/java/megg.xml!) when later attempting to parse the megg properties.

When attempting to load a directory in the local folder ./java, megg would fail wto find template files in ./templates/java.

Templates would be loaded fine from the templates collection distributed in the Jar file (or added by me), which is why I assume the problem has not been noticed before.

I have attempted a fix to local file handling whereby megg now tries ./java then ./templates/java then $HOME/.megg/java and finally $HOME/.megg/templates/java before resorting to the jar file. If fact, my added code can actually find files at any path prefix, although I haven’t yet added that feature to the CLI (e.g. as an option -t <em>templates_dir</em>).

I made my changes by creating a new class to represent the TemplatesDirectory which also allows the code for handling local file templates to be somewhat simpler. I also took the opportunity to use commons-io to make file copy a bit more transparent and the commons-io groups’ best practices advice on using object rather than strings to manipulate file names.

I haven’t yet tested the option to download from a URL (which didn’t work when I tried it before my changes). It’s next on my to-do list. However, I have invited Megg’s developer (Jeremy Rayner) to have a look and possibly merge my changes into a test branch for review. Just need to find out how to generate a patch file from CVS manual!

It was nice to be busy!

Ain’t it cool!

Just watched this Screencast from Jon Udell on the power of client-side scripting and web services. It it Jon demonstrates a little bookmarklet that takes an ISBN from a page (demo works with Amazon) and looks the book up in a library. Jon’s blog has a page where you can create your own bookmarklet for various library catalogue systems so I created one for Swansea University. Here’s it is:




To use this, copy it into notepad and remove the newlines, then just drag the bookmarklet to the browser toolbar. Now when you visit Amazon and see a book you’d like, click on the bookmark and a pop-up window will show you if it’s in the library. Cool!


p>Jon takes this further further by using a Firefox plugin called Greasemonkey which allows its user to add bits of DHTML (“user scripts”) to any webpage to change its behavior. Jon’s greasemonkey script allows the Amazon web page to be changed on the fly to show if the book is in the library and if it’s out, when it’s due back! Now that’s cool!