Every now and then I come across a situation where encapsulation has been taken slightly too far. Usually, or at least most recently, these over encapsulated designs have had problems because they’ve blocked access to an event handle. It’s great to wrap up a bunch of Win32 primitives into a nice coherent class but if you expose a method that allows the user of the class to wait for something to happen then it’s probably also a good idea to expose a handle they can wait on as well.
Alan Green doesn’t like the word “manager” used as a class name suffix. His point seems to be that “manager” is imprecise and instead he suggests a list of alternative suffixes with more precise meaning; though they seem to be rather contrived and smack of using new words just for the sake of it to me. For example using “Herder” rather than the more usual “Collection” (PolicyHerder, hmm…) and using “Bucket” as a pretty non standard replacement for “Pool”.
Jochen Kalmbach has discovered a problem with dynamically linked applications built with VC2005 running (or not running!) on NT 4. I guess this isn’t going to bite that many people… Read about it here.
This CodeProject entry is SO full of errors and poor practice that I must find the time to leave a comment on it…
[Updated: 29th October] Done. Comment is here.
I’m upgrading one of my build machines to use the April 2005 edition of the Platform SDK to investigate the implications of this posting over at eggheadcafe.com which states that since Visual Studio 6 ceased to be supported as of the end of September 2005 the last version of the Platform SDK that will work with Visual Studio 6 was the February 2003 version.
There has been quite a lot of discussion in the comments of my Bluetooth code sample about the ‘broken’ uuid.
This may also be your kinda thing.
Ellen Ullman’s 1998 two part series “The Dumbing-Down of Programming” from Salon archives.
Rebelling against Microsoft, “My Computer” and easy-to-use Wizards, an engineer rediscovers the joys of difficult computing.
Returning to the Source. Once knowledge disappears into code, how do we retrieve it?
Via Joey deVilla over at The Farm.
I’d forgotten how readable Ellen Ullman was (especially for techies of “a certain age”).
I’m in the process of preparing a release for a client. I’ve done the work, the tests pass, the stress test runs with flying colours and so I’ve tagged the source and I’m in the middle of the final build and test cycle. It’s a nice feeling.
One of the last things I do when shipping code is to turn off the default STLPort support that I use when I’m developing.
Charles Petzold recently delivered a talk at the NYC .Net Developer’s Group and he’s made it available online here “Does Visual Studio Rot The Mind?”.
It’s an interesting read, especially if you actually remember writing early Windows GUI applications and building your dialogs in your resource files by hand. I agree with his view that many of the features of Visual Studio are there simply to help us write code faster and that this doesn’t, necessarily, result in us writing code better or in code that is clear of fluff and easy to maintain.
It seems to be stack walking week; what with Ned’s posting earlier about walking an unmanaged stack and now this excellent piece by David Broman on doing the same in with managed code.
The discussion on Assert goes on, this time in Japanese… Google’s language tools lead me to believe that they’re disagreeing with me. They seem to be pretty shocked that I’d take this stance and appear happier when Noel puts me in my place and returns order to the world. ;) If anyone can come up with a better translation, leave it as a comment please.
