It's a mute point anyhow
File this under "things that make me want to quit the computer industry and become a florist":
"Loose"? Come on, people. Let's show a little hustle with the grammar, huh?
File this under "things that make me want to quit the computer industry and become a florist":
"Loose"? Come on, people. Let's show a little hustle with the grammar, huh?
If you're using malloc to instantiate a C++ class, I'd like to throw you in a sack and toss the sack in a river and hurl the river into space1.
Not knowing what an assertion is shouldn't dissuade you from being a developer, but not caring what an assertion is should.
Casting everything to Object is not the right way to fix compiler type warnings.
Comments can be used for purposes other than skipping over code that won't compile.
1 with apologies to Futurama 2ACV12, The Deep South.
Security is hard.
When people talk about security, they usually mean that they want to prevent some action from being take against some object: “I want to prevent the money from being stolen.” “I want to only teachers to be able to change the grade records.” “I want to keep attackers from gaining entry to the computer system.”
Security is really about economics, weighing costs against benefits. The goal of security is to make the cost of taking some unwanted action against an object greater than the benefit of securing it plus the value of the object itself. If you say “I want to prevent the money from being stolen,” you really mean “I want it to be more expensive to steal the money than the total value of the money plus the cost to protect it.” That’s why we feel secure in keeping 50 dollars in our wallet, but we hire armored trucks and guards with shotguns to feel secure in dealing with 500,000 dollars.
Sometimes the simple and obvious security solution—guards with shotguns—is the right solution. With security, however, the devil is in the details.
Consider: “I want to make sure that the yogurt I buy isn’t spoiled.”
Continue reading "Yogurt and security: a tale of two things" »
Visual Studio 2005 was the last product I worked on before I left Microsoft, and I'm very glad to see that it's been released and is available to the public now. It's especially nice to see that Microsoft decided to make the Express versions of all the VS products available for free download (at least for the next year). That means that if you want to try out one of all of the Express versions of the VS2k5 product, you can get them here:
Congratulations to my former teammates on shipping; I think it's a fine product. [via]
A new version of Ook, v2.2, is out. Some things that changed:
Enjoy.
Since I posted my entry on Outlook's annoying IMAP behavior, I've gotten a few requests for copies of the program I wrote to automatically dismiss the bothersome error dialogs.
I was a little surprised that there were other people who find this behavior as frustrating as I do, but I suppose that's just more evidence as to the disservice Microsoft does to their customers by not fixing these obvious kinds of bugs. (I only wonder how many people have simply switched to another better IMAP client simply because of this issue.)
Anyhow, you wanted it, you got it. Introducing Ook: the Outlook dialOg Killer. It's a little .NET app that just sits around waiting for a dialog it likes and then gives it the ol' WM_CLOSE treatment. I spent some time cleaning up the app and the source code, and I decided to release both under the BSD license. I even put together some rudimentary documentation. Ook isn't the prettiest app or the best code I've ever written, but it gets the job done--for me, at least.
I hope some other people find it useful. I welcome any feedback you might have about it.
I've been reading "flow | state", a fascinating UI design weblog by ex-microsoftie Jan Miksovsky. His recent entry, "Situation normal, all fouled up" had me laughing, particularly because of this part:
People who use Outlook outside of an enterprise struggle along with support for POP mail that hasn't improved appreciably in years. While POP isn’t great, at least Outlook's POP driver is reasonably solid. Outlook's IMAP driver, on the other hand, appears to have been left for dead in the jungle, where it was raised by apes.
I (grudgingly) use Outlook's IMAP support for basically all of my email needs, and the lack of fit-and-finish there is terrible, bordering on the ridiculous. For example, as Jan notes:
Among its many deficiencies, the driver can’t properly cope if you use two different machines (say, at home and at the office) to check your email. This scenario is one of the reasons for IMAP’s existence, and most IMAP clients handle this situation gracefully: if they see another client is checking the mailbox, they wait for a while then try again. If you try to use Outlook this way, however, the IMAP driver throws up the following error:
Your IMAP server has closed the connection. This may occur if you have left the connection idle for too long.
This is such an incredibly stupid behavior that I have actually written a program that does nothing but wait for this dialog to appear and then dismisses it. (It works for Outlook 2003, and if anyone would like a copy just let me know.)
And to add insult to injury, the IMAP support in Windows CE has the exact same behavior! I have my smartphone setup to check my IMAP email as well, although at much less frequent intervals than Outlook. If the two devices (my phone and my desktop) happen to check for mail at the same time, the smartphone displays an error as well!
My friend Melinda is a tester in the Office organization, and I told her that if there was a position open for someone to test (or heck, to develop) the IMAP driver in Outlook, I might just consider applying for it. I was only half joking.
[Update:] I've made my Outlook dialog-killing app available for download.
My friend Nate asked me via email:
You said: "I tend to get nervous when the answer to 'How often will the user exercise this code path' is 'all the time.' If nothing else, changing an often-used code path increases the risk of causing a regression. As much as I hate shipping software with a bug, I hate shipping software with a regression even more." What is a regression?
A "regression" (really, a "regression bug") is the recurrence of a bug that was previously fixed.
Consider a product in which Bug A was fixed weeks ago. Then, in the course of fixing another Bug B (which may be completely unrelated to Bug A), the fix causes Bug A (or a very similar bug) to re-appear in the product. The recurrence of the previous bug is a regression. And we would say "fixing Bug B caused a regression of Bug A."
Sadly, these bugs (i.e., regressions) are more common than you'd think, especially as the complexity of software grows, and more especially as the dependencies between different independent software teams become more numerous. (This is somewhat analogous to the increase in communications required as you add more people to a software project, as set forth in Brooks’ Law.)
I suppose that the saying "the Internet never forgets" has some truth to it. (Maybe a more accurate version would be "Google never forgets" but I suppose the nice folks at MSN Search wouldn't like that one as much.)
As I posted a while back, I made the decision to remove all of my old entries when I gave this site its most recent makeover. This wasn't an attempt at hiding or erasing anything I had written, it was just a personal decision. Anyhow, Google (or more appropriately, Google's cache) never forgets. I still see a bunch of 404s in my logs from people following old broken links (Mark Pilgrim would not approve, but that's just tough).
Much to my surprise, I've actually gotten an emailed request asking about one entry I wrote in particular, called "The anatomy of a bug".
Someone was nice nice enough to ask for it, so I've re-instated the entry: The anatomy of a bug
I've never been one to ignore the (reasonable) demands of my readership, so there you go. Enjoy.