At work I keep my work-log and my work plan in one big XML document (actually one per client, for the sake of limiting the enormity of the files). This single document is then sliced and diced through various XSL transforms to create different views: for example, when you look at the entry for one task, you see all the notes describing that task and the work I did on it, and when you look at the log for a particular day, you see the notes for that day regardless of which task they belong to.
I kept all this organized using 
Apache Cocoon, a web-application
framework from the Apache project. This was really overkill -- I used
the simplest kind of pipeline, sucking in XML files at one end and
choosing a particular XSLT to render it based on parts of the URL. Installing it was a bit of an
adventure (installing a new version of Java on to my old Windows 2000
machine, copying JAR files around,and so on), but
it worked well enough (except for running our of memory when I tried to
render pages as PDF using FOP).
On Thursday, I made a foolish mistake: I decided to upgrade 
Apache
Jakarta Tomcat, the web server that hosts Cocoon. The original
impetus was that I wanted to install VeryQuickWiki, and that was
because I am not content with having specifications passed around as long and unweildy Microsoft Word
documents. VeryQuickWiki is very quick to install, assuming that your
JSP compilations do not fail with a 200-line error message, which is
what happened to me. Google's wisdom suggested reinstalling Tomcat in a
directory whose name does not contain spaces (amateurs!!), and I thought I might as
well switch from version 4.1 to 5.0 while I was at it.
Needless to say the usual shennanigans of installing Java software
ensued. On 
Debian GNU/Linux, I have been spoiled by APT, where the
most difficult part is often guessing the name of the package; after
that, you type apt-get install xalan and lo! Xalan-C++ and other
packages it depends on are downloaded, installed, and configured.
Installing on
Microsoft Windows systems is not this slick at the best of times
(you have to do your own downloading, step through interminable wizards,
and so on), and Java adds a whole new level of not-quite-workingness.
(The server is at work and so is running Microsoft Windows.)
Apache tends to assume that people installing Tomcat are Java
enthusiasts with infinite knowlege and patience regarding Java's special
conventions; all I want is software that will make Cocoon and
VeryQuickWiki work.
So what went wrong? My first attempts at visiting the Tomcat front page
just got 'connection refused' (which translates as, 'the server has
failed to open the listener socket'). Rebooting the server fixed this. I ended up
doing the usual random rearrangements of JAR files (Tomcat has three
places to store JARs, and a lot of places that seem plausible at first),
rebooting the server each time because merely restarting the service did
not work). Eventually I got it to display the Tomcat documentation and
example JSPs. Fine. But when I dropped the Cocoon or VeryQuickWiki WAR files in to its
webapps directory, the files were unpacked but something prevented
them from working -- all I got was a strangely terse message saying the
URL was 'unavailable'. I say strangely terse, because I am used to the
more usual Java error messages including a 200-line stack dump. After
wasting a couple more hours fruitlessly tring to work out where in the
configuration files I might be expected to fix this, I gave up.
I gave up not because I don't think the problem was solveable, and not
because I don't think that eventually I could have worked it out or got
advice from some Cocoon mailing list. I gave up because I decided that
it would take me less time to write my own web server from scratch
than to fix my Tomcat/Cocoon problem. That may seem a
bold claim, but remember two things:
-
I was really using Cocoon to do no more than parse the URI, choose one of the XSLT scripts, set some parameters, and set it running (all the 'smarts' of the server are in the XML and XSLT), and
I already know how to throw together a web server in Python using BaseHTTPServer: I've
used it as one of the implementations of the Picky Picky Game (the deployed version
uses CGI instead). The main trick was running the XSLT transforms (something that should
have been absorbed in to the standard Python library long ago). Google found me a Python
wrapper for the 
Apache Xalan-C++ library, called Pyana for some reason.
On Windows, the Pyana installer comes with the required libraries: you just run the
installer and it works. By the end of the afternoon I had sorted out a working
replacement work-log server (with a bug in the formatting of dates, which I will fix
later). The most time-consuming part was rearranging the directory structure of the
source files, since they no longer lived in Cocoon's directory tree (this boiled down to
judiciously adding ../ to various relative URLs).
What are the lessons here (apart from 'Don't write your own work-log web server in the first place')? First, XSLT makes your formatting more mobile between platforms: switching from Java to Python would have been tough had the HTML layouts been mixed in with Java code (or ASP or PHP for that matter). Second, Java Sucks for Sysadmins. Third, Python excels at providing simple interfaces to complex libraries, which makes it possible to write sophisticated applications in a hurry.