And God Bless us, every one...
Last night was the traditional gymkhana. Nothing was calm, but it was pretty bright. Actually, that might be because I think the kids were trying to signal the mothership out in space with the amount of lights they inflicted on that poor little tree. The boys finally started snoring at 3:30 or so. I did actually get everything done and sat down with a cup of tea around 6am or so. The kids showed up at 8am precisely, and entirely too chipper about the whole thing. I got the fire started with our Yule-log from last year, and the semi-controlled frenzy ensued.
Barney is a dinosaur from our refridgerator... The velociraptor-sized bird the boys picked out is in the oven, and will be for the rest of the day. The girls chose asparagus for the veggie so that's all trimmed and ready. I'm making picture slideshow CDs for all the grandmas and picking tinsel out of my hair yet again (I am NEVER buying that stuff again).
The consoles have been rearranged and the kids are running around with several of their friends who came over to compare loot. Lord love her, but my Mom got each of the kids their own digital camera. I'm going to have to get a MUCH bigger hard drive. I never thought I'd ever pine for the days of those loud popping-noise Fisher Price things. The boys are running a head-to-head comparison between Project Gotham 2 and Tokyo Extreme Racing 3 on the big TV by switching between controllers and flipping the inputs back and forth really fast. My living room looks like a power sub-station now with all the cables and blinking lights. The girls are closeted in their bathroom with two of their little buddies tangling their hair and applying substances and giggling (which in the case of one of their friends is so high-pitched it could bend metal).
It is a Happy Holiday.
So many words, so little time....
Monday, December 22, 2003
Nothing says "Hollidays"...
....like a glowing deer with an extension cord in his backside. ;)
This year it seems like there's been an invasion of lighted deer all over the place. Who comes up with these things?
We saw a bunch of them tonight while out getting our tree. I decided that if I ever have a rock band, I'm going to call them "Electric Venison".
....like a glowing deer with an extension cord in his backside. ;)
This year it seems like there's been an invasion of lighted deer all over the place. Who comes up with these things?
We saw a bunch of them tonight while out getting our tree. I decided that if I ever have a rock band, I'm going to call them "Electric Venison".
Sunday, December 14, 2003
HeisenBugs....
This is an abridgement of a bunch of material I found on WardsWiki. I'm adding links to these pages in our testing definitions, both as a light-hearted joke but also as a more precise nomenclature for identifying problems that arise.
Bohr Bug
It's broke, but I know how to fix it.
A BohrBug is just your average, straight-forward bug. Simple like the Bohr model of the atom: A small sphere. You push it, it moves. BohrBugs are reproducible, and hence are easily fixed once discovered. Testers pray for these.
Heisen Bug
A HeisenBug is a bug whose presence is affected by act of observing it.
This is a bug who appears and disappears for what appears to be no reason. Sometimes called "intermittent". They play peekaboo through the lines of code. These are most annoying when coupled with the Programmer Proximity Detector (see below) where not only does the tester affect the bug by hunting it, but once they think they've found it and try to show the programmer, the programmer is faced with a program that seems to function perfectly (unlike the tester).
This has been known to make grown testers cry.
Mandel Bug
A bug that has a single simple cause, but which causes the system to exhibit wildly chaotic and unpredictable behaviour.
In multi-tier applications, particularly web applications this is pretty much a given. Something breaks, and since the whole thing is a house of cards you can get errors in what appears to be competely unrelated code.
Schroedin Bug
A defect that exists neither working nor not working until you look at it, and suddenly it collapses into a state, usually 'that could never have worked'.
This occurs frequently while editing other people's code. Since code is often a reflection of the mental workings of the programmer, you are often faced with code that looks like it could have been scrawled on butcher paper with crayons
for all you know. While working with the code you are likely to introduce values and variables that cause other parts of the code that seem to work fine to cease working because they have related return or attibute data that you were unaware of. Or they were just idiots.
Programmer Proximity Detector
This isn't strictly a bug. It more behaves like a feature that is apparently spontaneously evolving in programs. It allows the program to act differently in the presence of its author.
Typically this involves a user who claims that the program has a bug, but after calling the programmer over to the test facility (usually across the compound, requiring exiting the building and crossing a windswept parking lot in the rain, or taking an elevator 26 stories down to the subbasement), the bug does not manifest - the program works perfectly. The user often serves as the proximity detector. Because the user is carefully showing the programmer how he (is supposed to) use the program, the user may use the program more slowly (thus hiding race condition bugs) or exactly the way the programmer told him to use the program (thus hiding bugs due to slightly different inputs or orders of operations).
This is an abridgement of a bunch of material I found on WardsWiki. I'm adding links to these pages in our testing definitions, both as a light-hearted joke but also as a more precise nomenclature for identifying problems that arise.
Bohr Bug
It's broke, but I know how to fix it.
A BohrBug is just your average, straight-forward bug. Simple like the Bohr model of the atom: A small sphere. You push it, it moves. BohrBugs are reproducible, and hence are easily fixed once discovered. Testers pray for these.
Heisen Bug
A HeisenBug is a bug whose presence is affected by act of observing it.
This is a bug who appears and disappears for what appears to be no reason. Sometimes called "intermittent". They play peekaboo through the lines of code. These are most annoying when coupled with the Programmer Proximity Detector (see below) where not only does the tester affect the bug by hunting it, but once they think they've found it and try to show the programmer, the programmer is faced with a program that seems to function perfectly (unlike the tester).
This has been known to make grown testers cry.
Mandel Bug
A bug that has a single simple cause, but which causes the system to exhibit wildly chaotic and unpredictable behaviour.
In multi-tier applications, particularly web applications this is pretty much a given. Something breaks, and since the whole thing is a house of cards you can get errors in what appears to be competely unrelated code.
Schroedin Bug
A defect that exists neither working nor not working until you look at it, and suddenly it collapses into a state, usually 'that could never have worked'.
This occurs frequently while editing other people's code. Since code is often a reflection of the mental workings of the programmer, you are often faced with code that looks like it could have been scrawled on butcher paper with crayons
for all you know. While working with the code you are likely to introduce values and variables that cause other parts of the code that seem to work fine to cease working because they have related return or attibute data that you were unaware of. Or they were just idiots.
Programmer Proximity Detector
This isn't strictly a bug. It more behaves like a feature that is apparently spontaneously evolving in programs. It allows the program to act differently in the presence of its author.
Typically this involves a user who claims that the program has a bug, but after calling the programmer over to the test facility (usually across the compound, requiring exiting the building and crossing a windswept parking lot in the rain, or taking an elevator 26 stories down to the subbasement), the bug does not manifest - the program works perfectly. The user often serves as the proximity detector. Because the user is carefully showing the programmer how he (is supposed to) use the program, the user may use the program more slowly (thus hiding race condition bugs) or exactly the way the programmer told him to use the program (thus hiding bugs due to slightly different inputs or orders of operations).
They're back....
The gang is back from Snow Camp. They had way too much fun in the snow and now we are cleaning up the damp bags of clothes and they are ALL hitting the shower. The hope is for a quiet and early evening as they have school tomorrow.
As for me, I had a night to myself. I met a friend I had known online for a long time and we went to see Master and Commander (way cool flick - Gamerdad's going to have my review of it). It was nice to get out and talk to someone who speaks the entire English language, who uses consonants in all the words that are supposed to have them, and who thinks "hella" is someplace in Greece. He was a good conversationalist and had some great stories to share. That and it was so good to be able to put a face with a screen name. We're looking at trying to do ROTK next weekend or the weekend after.
It's always a challenge to pick the baggage up again when it's been off. Just as you start to decompress it gets dumped on you again, and you stagger under the load. I have been careful this time to plan ahead for that and to be mindful of the phenomenon so that I don't get frustrated and angry about it.
The gang is back from Snow Camp. They had way too much fun in the snow and now we are cleaning up the damp bags of clothes and they are ALL hitting the shower. The hope is for a quiet and early evening as they have school tomorrow.
As for me, I had a night to myself. I met a friend I had known online for a long time and we went to see Master and Commander (way cool flick - Gamerdad's going to have my review of it). It was nice to get out and talk to someone who speaks the entire English language, who uses consonants in all the words that are supposed to have them, and who thinks "hella" is someplace in Greece. He was a good conversationalist and had some great stories to share. That and it was so good to be able to put a face with a screen name. We're looking at trying to do ROTK next weekend or the weekend after.
It's always a challenge to pick the baggage up again when it's been off. Just as you start to decompress it gets dumped on you again, and you stagger under the load. I have been careful this time to plan ahead for that and to be mindful of the phenomenon so that I don't get frustrated and angry about it.
Wednesday, December 10, 2003
Tuesday, December 02, 2003
It couldn't have happened to a nicer geek....
Wil Wheaton, child-star turned geek and author, has inked a deal with O'Reilly Publishing to carry his currently published book Dancing Barefoot, his in-progress Just a Geek, and a third book not yet announced. They are so amped about Dancing Barefoot they are preparing a printing that will be available before Christmas (see their site here to order).
Last year I found his blog, and was delighted to follow his doings as a grown-up, family man, and nascent geek trying to figure out what to do with his life.
w00t for you, Wil!
Wil Wheaton, child-star turned geek and author, has inked a deal with O'Reilly Publishing to carry his currently published book Dancing Barefoot, his in-progress Just a Geek, and a third book not yet announced. They are so amped about Dancing Barefoot they are preparing a printing that will be available before Christmas (see their site here to order).
Last year I found his blog, and was delighted to follow his doings as a grown-up, family man, and nascent geek trying to figure out what to do with his life.
w00t for you, Wil!