The school's weather station webpage seems to have stuffed it sometime around Thanksgiving. Today somebody finally noticed and alerted the support staff.

My boss asks "where's the documentation?".

Right.  There is none. This system has been in place for ten years or more and fails occasionally.  When that happens we go in and fix it.

Start with the webpage that actually displays the data. It's pulling the data from a file that is supposed to be automagically updated. Except we don't believe in magic. The file didn't get updated. Now to find out why.

Since this is a scheduled event, cron has to be involved. Let's have a look at the crontab file. Hmmm. It's pulling the changes from another file that is supposed to be automagically updated. That one hasn't been changing either. What changes that file? It isn't cron. Or is it? That file is symlinked to a file on another computer. Let's go have a look at the other computer. Ah, I see. There's a crontab running there which generates the contents of the update file from a data file via a collection of python scripts. Let's have a look at those. 

As I suspected, they are pulling data from yet another file that is automagically updated. Right. It hasn't changed since November either. What changes this file? Time to scan the logs. Nothing.

OK, it's time to start from the other direction. The weather station is connected to a PC in the corner of a lab. Let's have a look there. It's hung and totally unresponsive. OK, maybe that's the problem. I reboot it. Then go back to the webpage. Nope. Nothing has changed.

OK, somehow the data has to get from the weather station computer to the other computer where the python scripts can munge it. Let's have a look at the logs.

The logs say everything is fine, but it isn't fine. Nothing. It's not happening. Well this is interesting. I check connectivity and network connections. They're OK. We've got an IP addess and pings work just fine. A closer look reveals that there's a Windows task scheduler which occasionally FTP's the weather files across the net to the second Unix box. The logs don't show any errors. Hmmm. The files aren't being FTP'd though. They aren't making it. Then I see a notice at the bottom of the screen. Updates were applied some time since the computer was last powered on - six months ago. OK, what updates? Windows firewall. Right. So I have a look, and sure enough the computer's FTP connection has been firewalled because of an automatic update. The FTP's are silently failing - and indicating success. This is pure evil. After several minutes I'm able to get in with an administrator account that can fix the firewall and do so. 

Then have another look. Still nothing happening. What could be the problem now? Ah, on reboot FTP is automatically disabled on the weather station software - again without any warnings. The logs again say everything is working and files are being transferred. More evil. What's the use of having log files if they lie to you? I turn on the FTP. Bingo - now the files get through. Now back to the second computer to manually process the files and dump them into the directory where the third computer can pick them up. Then back to the third computer to manually update the processed files.

Yay! It works.

Back to the documentation. How would somebody document stuff like this? There's just too much that can go wrong. I could use up a tree or two writing it all down. This is why we've got systems folks. 

Unless you've been watching closely, this announcement was easy to miss. Sun Microsystems is acquiring MySQL. This has ramifications both good and bad.

This will likely affect a huge number of people who are currently using open source web applications; a majority of which are being stored on MySQL databases. Their future viability is now questionable. It all depends on the license and revenue models Sun chooses to adopt.

I would also try to steer clear of the pending 6.0 release as it is likely to involve significant re-structuring of the code to suit Sun's business requirements. It may be a year or three before it stabilises again. Sun is legendary for introducing layers of bureaucracy into development projects.  

While Sun may make public announcements of their intent to continue to provide the product for free [and it should be noted that there was no such announcement in the press release], it is difficult to imagine the corporate bean counters not making a recommendation to derive as much revenue stream as possible from the acquisition.

You can read the announcement here. 

Also of potential interest is this (dated) history of MySQL 

Just turned on my 'Related Articles' plugin. I've been having some fun with it. Click on 'Random Article' or view any individual article (not a page full) to seed the process. Then down on the left hand side of the page (way down) is the list of related articles. I noticed lots of interesting brain warps and rants over the years that actually do follow some strange twist or turn of logic. 

Looks like I got sidetracked from my original mission to use this website as an xml playground to explore and develop new communications technologies, and instead wrote a social portal that hardly anybody cares about. That was a few years ago now. Well, I haven't given up. It just took a while to reach the state where I can get beyond the user-interface plumbing and get back to the machine interfaces which is where the fun is.  

Feeds have improved a lot. I'm using Atom paging now. Still holding off on atom-thread for comments since I can do it so much easier embedding into the articles - though I note that the latest Firefox parses atom-thread just fine. No use forcing it on the public until a few more feedreaders have jumped on board. The code has been working for a year or two, but I'm just waiting for the rest of the world to catch up before I turn it back on.

I've been playing with a weblog export tool that's basically an Atom feed, but replaces images and attachments with inline data: URL's. Have had a few glitches - including a PHP bug in the regular expression library that I need to report. But this in theory can let you take an entire weblog and move it elsewhere as one gigantic XML file. Everything. Images, attachments, comments, categories, the whole nine yards. 

I've also got Atom Publishing Protocol support in a very primitive state (but not yet ready for prime time). This is a big effort and I don't expect to be finished for a few months. I've got a suitable framework, but this site works a bit differently than the model used by the atom publishing spec. It will take a while to resolve all the differences so it plays nicely. This would for instance allow you to import your entire weblog from elsewhere in the world - especially one that used data: URLs to bring in images and attachments. Otherwise if I use the default model, I've got to package everything into a workspace for export, and this takes more than one file to represent all the structures completely. But that's the big picture - on a smaller scale, you should soon be able to publish weblog posts from your cell phone, or sync new articles with another weblog you may have. I 'm also not bothering with the xml-rpc remote mechanisms for publishing. They're primitive now, the api's too fragmented, and pretty much dead.

Oh yeah, and we've got trackbacks now - for any weblog that allows non-member comments. This is a flavor of xml-rpc. It isn't a big deal, but a few folks have requested it. You can find the trackback URL in the 'more actions' menu of articles - that is for any member weblogs that allow them. Mine does.  

Oh, and photo albums can now be exported as zip files. That has nothing to do with XML...

I've been working with some dynamic text/font resizing tools recently. Some visitors over the last few days may have seen some of these efforts in progress, but I've just turned them off again until I get it all sorted.

In order to change the text size on a page after it's loaded, and without re-loading, one has to walk the DOM tree and re-calculate every font size on the page. There are actually a few open-source packages which will do the dirty work, but there are still a lot of issues. Almost all of these center around MSIE (why am I not surprised?). Additionally, it takes some work to get them to play nicely with sifr - the modern day equivalent of webfonts; which was abandoned around the turn of the millennium as being too infected with DRM controls to ever mass deploy.

Anyway, if you're interested in doing dynamic font scaling, I'd like to point you to JS magnifier, which is a pretty cool little app for walking the DOM and changing all the sizes. I had a bit of trouble with it on web forms, because it listens for key events, and if you type -,+,<,or > anywhere it changes the page size - even if you were typing these into a text field. Rather than modify the event listener to determine if it was a form and check the current focus, I just commented out the event listener and used JS links to activate the functions. 

But then on IE, everything was screwed up. First of all, even with a setting of '0' (no change), the page always goes through a resize cycle after you load it, and a lot of inherited sizes got messed up and set to something obscenely small. You can fix these by declaring them '!important', but you'll likely end up with over half your size tags set to !important in order to render your original page anywhere close to what it was designed to look like. 

The real trouble began however doing the DOM walk. IE does some real funny stuff to their DOM (this shouldn't be a surprise to anybody either). If you've got an embedded video, and there are any troubles loading the video, the entire DOM tree from that point forward seems to get rebuilt (resulting in the font size reverting for part of the page). The same thing happens if you've got AJAX-updated content on the page - every time there's an update, everything from that div to the end of the page reverts.

Looks like I'm back to square one. Think I'll go back to my original plan which I never quite finished implementing, but basically use proportional (em) fonts everywhere [this I do already], and then dynamically change the main body font declaration on the fly as the CSS page goes down the wire. This is hardly dynamic - it results in the need for a page reload to render everything correctly. At least it's portable and doesn't require javascript or depend on anybody's screwy DOM implementation. Oh well, live and learn I guess.