UNDERDOG of PERFECTION

The new WordPress 2.1-based version of room34.com is here! I’ve been tinkering with this for about a month now so I’m very excited to finally have it online. And I think WordPress has really taken a major leap forward with version 2. (My loyal reader may recall that I had previously moved to an earlier version of WordPress, only to abandon it a short time later. Frankly, looking back I’m just amazed that I actually used it for 8 months; it seems like it was much less than that, but maybe that’s just because I’m thinking about how I only had Drupal running for about three days.)

There are still a few things left to do: some pages have missing content or broken links; I’m still working on a top navigation bar with dropdown menus (for now the navigation is buried below the fold in the right sidebar… look for Points of Interest and the various links that follow); and there are a plethora of WordPress plug-ins I’m eager to implement.

I’m also moving the photo albums of the kids over into Gallery 2. There’s a lot of work left to do on that, so I apologize to family and friends who are looking for photos. They’ll be back online soon, I promise! (I mean, “I hope!”)

And finally… in the time that I’ve been working on this, I’ve written a few other new blog entries (six, to be precise), which I never bothered to post on the old site. But they’re here, below, so read on!

According to this article, the first security exploit has been found in Windows Vista.

While that’s not entirely surprising in itself (after all, the OS has been commercially available for over 3 full days now), the nature of the flaw is both amusing and somewhat shocking.

Vista adds new speech recognition features, allowing the user to issue commands to the computer by speaking. At least, I’m assuming this is new. Mac OS has had speech recognition for at least a decade, but it used to require extensively “training” the computer to recognize your voice. I’m guessing that the new speech recognition software doesn’t require that kind of training, sort of like how pizza places now have speech recognition software that answers the phone and takes your order.

So, on to the exploit: if speech recognition is on, and the computer’s speakers and microphone are both on, it would then be possible to visit a website that autoplays an MP3 of a voice issuing commands to make the computer do all sorts of nasty things (like erasing files off the hard drive)!

This is an old story, but a coworker and I were just discussing “The Monty Hall Problem,” which comes down to the common scenario from the old game show “Let’s Make a Deal”: If you have three doors, with a car behind one of them, and dud prizes behind the other two, once you’ve made your selection and the host reveals a dud prize behind one of the other doors, does it make sense for you to switch doors or stick with the one you’ve picked?

The simple intuitive answer is that it makes no difference, now that there’s a 50/50 shot at opening the right door. But it seems that 2/3 of the time it’s better to switch! We pondered this for a while and I guessed that it may have something to do with the fact that the host knows which door the car is really behind.

Apparently that’s correct. (Since this link points to an ancient [in Internet time] web page that may or may not endure, although it’s made it this long, I’ll provide a summary here.)

This roulette wheel is the key. The inner circle is the door the car is behind, the middle circle is the door the contestant picks, and the outer circle is the door(s) Monty Hall can open after the contestant picks. The red spaces indicate that the contestant should switch, and the blue that they should not. 2/3 of the time it’s better to switch, because Monty Hall has basically been forced to reveal that the car is behind the door the contestant did not pick.

In other words, the contestant picks the right door the first time 1/3 of the time. This is pretty straightforward. That means that 2/3 of the time they did not pick the right door the first time, also straightforward. Therefore, since 2/3 of the time the car is not behind the door they picked, and Monty Hall will never open the door the car is behind, then 2/3 of the time the car is behind the door that neither the contestant nor Monty Hall picked, so the contestant doubles their chance of winning by switching.

I found this Dilbert cartoon mildly amusing, but I found it even more amusing when I discovered its real-life context!

I will admit, sometimes the problems I encounter in Internet Explorer are simply due to slight differences in browsers’ implementation of HTML or CSS or whatever, and I’m just not properly accounting for the way IE does certain things. Other times, it’s true, they’re due to a flat-out bug in my code that Safari and/or Firefox (usually “and”) will just graciously accept, whereas IE will not. (The cases where IE catches errors that Safari and Firefox permit, however, are rare compared to the vast, cluttered landscape of bad code that IE welcomes with open arms but that Safari and Firefox rightly reject.)

And then there are the cases such as the one I encountered today. There’s no way around it. I can’t find a nicer way to put it, IE is just plain fucked up.

Yesterday I was going along innocently enough, demonstrating to a coworker the site I had been working on for him. As usual I had worked with Safari and Firefox as my test browsers, firing up IE through a remote connection to my PC as needed to make sure things weren’t completely off track. (In a perfect world, I would never have to do this, of course. But, well…) And then, wham! Of course this kind of problem only rears its head when you’re showing your work to someone who has the authority to reject it. I was convinced it was a fluke on his computer, but sure enough when I went back to my desk, I observed the same thing happening in IE on my own PC. Time to hit the brakes once again and go into IE debugging mode.

I tested all of the obvious things. No luck. So I dug a little deeper and started testing the more obscure, but at least logical things. Still nothing. And like so many times before, I was reduced to just randomly trying anything to see if I could get a different result, no matter how seemingly absurd.

Fortunately it only took about an hour to track down the problem this time. But as usual there was no satisfying resolution, no “Aha!” moment as I suddenly recognized a stupid mistake I had made. Oh no. The problem was that the CSS definition for the <div> tag containing the entire body of the page specified a background color. Of course! (No, not of course, as this should not have any impact whatsoever!)

*SIGH* Seeing as how that background color specification wasn’t technically necessary, I removed it. Problem solved. Frustration with Microsoft, higher than ever.