geek: 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...
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?
