Errors are not the only fruit

Posted by robbiebow on 18 September, 2006 under geek | Be the First to Comment

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…

Annoying PPM error warnings be gone!

Posted by robbiebow on under perl | Be the First to Comment

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:

http://use.perl.org/~tomhukins/journal/29857

Image::Magick and FCGI not the best of bed partners

Posted by robbiebow on 17 September, 2006 under perl | Be the First to Comment

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:

<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