September 2006 Archives
Something I've come to realise after only a decade in the cold and clammy world of the computers: errors are not the only fruit. After my initial noob habit of ignoring errors out of "boredom" (for boredom, read "not good enough to get the simple, ideal scenario bit done without immitating Shakespeare's monkey for hours) I got into the habit of flagging up errors. Then using strict. Then writing unit test (sometimes).
But all this emphasis on errors means that I'm likely to know when something has run but hasn't completed the intended task. No error reports means no errors, right? Naw, it means no error reports. An absence of evidence is not necessarily evidence of absence.
Without success reports, you'll never know if something succeeded. (Rumsfeld, this known unknown is for you) You'll just know that you don't know that it failed. So make sure you have success reports too.
The best example for this has to be nightly routines, such as backups. Let's say, for instance, you make a database backup overnight. A simple script invokes a mysqldump (say) which you promptly archive away. But what happens if your password for the database changes and you don't update your backup script? Does the script send an error report, or does it die before it can get that far? A well written script will send the error report. It'll be robust enough to cope with such a simple mistake. But who doesn't hack together scripts (sometimes) and cut corners (sometimes)? Who can guarantee their code is always 100% tolerant of all possible failures? To be safe, I want to see something that tells me what I expected to happen, happened. Simply squirting out a success email at the end of a good run does that for me. I delete them every morning. But one morning they won't all be there. And then I'll visit my hacked up scripts and make them robust, tolerant, failsafe. And even after I've done that, a hard disk will go *pop* or a network connection will take a night off. And I won't get my success alert. And then I'll just panic.
But it'll be a pre-emptive panic. A panic that's slightly less panicky than an error report. My known unknowns will have shrunk just a wee bit. My hairline, receded just a little less. And my main disk might just not be completely filled with corrupt file fragments and broken promises of backups before I know something is wrong...
But all this emphasis on errors means that I'm likely to know when something has run but hasn't completed the intended task. No error reports means no errors, right? Naw, it means no error reports. An absence of evidence is not necessarily evidence of absence.
Without success reports, you'll never know if something succeeded. (Rumsfeld, this known unknown is for you) You'll just know that you don't know that it failed. So make sure you have success reports too.
The best example for this has to be nightly routines, such as backups. Let's say, for instance, you make a database backup overnight. A simple script invokes a mysqldump (say) which you promptly archive away. But what happens if your password for the database changes and you don't update your backup script? Does the script send an error report, or does it die before it can get that far? A well written script will send the error report. It'll be robust enough to cope with such a simple mistake. But who doesn't hack together scripts (sometimes) and cut corners (sometimes)? Who can guarantee their code is always 100% tolerant of all possible failures? To be safe, I want to see something that tells me what I expected to happen, happened. Simply squirting out a success email at the end of a good run does that for me. I delete them every morning. But one morning they won't all be there. And then I'll visit my hacked up scripts and make them robust, tolerant, failsafe. And even after I've done that, a hard disk will go *pop* or a network connection will take a night off. And I won't get my success alert. And then I'll just panic.
But it'll be a pre-emptive panic. A panic that's slightly less panicky than an error report. My known unknowns will have shrunk just a wee bit. My hairline, receded just a little less. And my main disk might just not be completely filled with corrupt file fragments and broken promises of backups before I know something is wrong...
If you use Activestate's port of Perl on Windows and you've installed a few CPAN modules using PPM, chances are you'll have started getting annoyong Parser error messages. Have a read of this by Tom "hitman" Hukins on how to hack those useless errors out of your life:
Here's the scenario: I wanted to be able to produce tumbnail images on the fly so that a user could upload their photos to a site and then in their page templates use a cgi call as the img src, passing the desired width and height as arguments to the script. For example:
Anyway, the problem appears to be that the FCGI module ties STDOUT to itself, whilst Image::Magick appears to want to do the same. Conflict ensues and when you call the Image::Magick Write method, your image is written to your Apache error log. Bugger. The solution then would appear to be to untie STDOUT from FCGI and tie it to Image::Magick. So that's what I'm going to do, soon. Watch this space...
Update: see my more recent post on this subject with a happy solution
<img src="/cgi-bin/image.fcgi?name=photo1.jpg&width=100&height=150"; alt="" />Not rocket science, is it, and it works fine as a normal CGI, but I wanted to run it under FastCGI for obvious reasons: It's a low volume site, so I can afford the overhead of generating thumbnails on the fly, but the speed savings from using FastCGI would be appreciated.
Anyway, the problem appears to be that the FCGI module ties STDOUT to itself, whilst Image::Magick appears to want to do the same. Conflict ensues and when you call the Image::Magick Write method, your image is written to your Apache error log. Bugger. The solution then would appear to be to untie STDOUT from FCGI and tie it to Image::Magick. So that's what I'm going to do, soon. Watch this space...
Update: see my more recent post on this subject with a happy solution
I've been using Live Mail in place of Hotmail for a couple of months now, but there's one really annoying bug that's made me go back to good ol' Hotmail: Try to reply all and invariably Live Mail will send it to the first and last person on the recipient list only.
Looks to me like something pretty basic such as parsing the semi-colons from the To field has been broken at some point. So I tried to find a way to report this bug. Filled in the feedback form and heard nothing back from MSN. Shame, since Live Mail is an interesting attempt at making the most of RPC and DHTML (oops, AJAX and Web 2.0) and is well thought out, but when basic functions of a mail service - such as delivering to the intended address - is messed up and feedback goes unanswered you have a Beta that fails user testing.
I wonder when they'll get it working properly?
Looks to me like something pretty basic such as parsing the semi-colons from the To field has been broken at some point. So I tried to find a way to report this bug. Filled in the feedback form and heard nothing back from MSN. Shame, since Live Mail is an interesting attempt at making the most of RPC and DHTML (oops, AJAX and Web 2.0) and is well thought out, but when basic functions of a mail service - such as delivering to the intended address - is messed up and feedback goes unanswered you have a Beta that fails user testing.
I wonder when they'll get it working properly?
