There’s a lot of talk about how unit tests shouldn’t touch the network or the file system or databases whilst they’re running. Michael Feathers even has a set of unit test “rules” (A Set of Unit Testing Rules) which go so far as to suggest that: “A test is not a unit test if: It talks to the database It communicates across the network It touches the file system It can’t run at the same time as any of your other unit tests

Jacob Nielsen has a list of Top Ten Blog Design Mistakes. Number 5 is “Classic hits are buried” where he suggests that it is useful for readers if you list your most ‘important’ entries prominently as well as regularly back linking to earlier posts. This sounds like sensible stuff; until you have to work out what your classic entries are from the other 486 not so classic postings… Anyway, I’ve had a go at starting a list of some entries that are either a) very popular or b) clearly define my views on software development.

I’ve just finished posting several OLE DB provider articles from back in 1999 and 2000 when the favourite method of data access that Microsoft recommended was OLE DB. This was relatively easy to use as a data consumer, especially from VB. Writing a data provider was another matter entirely. The OLE DB documentation was mostly written in a style that assumed that you were only using it for reference, this made it hard to get to grips with when you first started working with it.

This made me smile. From “Irregular Web Comic”, via Raincannon.

There’s a nice story over on “Bug Babble” about debugging a problem with a robot by using various sounds coming out of a speaker to determine where in the code the problem occurred: “Now the robot sounded like a modem trying to connect. We would repro the hang and based on the pitch at ‘flatline’ we knew the point of the last successful call to the sound driver.” Via Google Translate and Radium Software, which also suggests using the CapsLock key, or changing display colours to debug gnarly problems in a printf style when you don’t have a console to use for output.

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.

Jeremy D. Miller writes about The Dependency Injection Pattern; or what I’ve tended to call “Parameterise from above”. He covers the various ways you can inject a dependency into a class rather than having the knowledge of the dependency hard wired into the class itself. I tend to favour the constructor injection pattern myself; it’s all about breaking concrete coupling with interfaces and then allowing the creator of the object to specify the concrete type used by the object.

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.

“Desire to know why, and how, curiosity; such as is in no living creature but man: so that man is distinguished, not only by his reason, but also by this singular passion from other animals; in whom the appetite of food, and other pleasures of sense, by predominance, take away the care of knowing causes; which is a lust of the mind, that by a perseverance of delight in the continual and indefatigable generation of knowledge, exceedeth the short vehemence of any carnal pleasure.

Richard Hale Shaw writes on and his conclusion is “it’s too confusing” and “I’d suggest not even using using statements”. I think that position is a little harsh, but I think that the main problem is that using tries to provide support for “scoped locals” and it doesn’t do it well enough. Richard refers to this C# idiom for deterministic resource release. using(MyObj obj = new MyObj()) { obj.DoStuff(); } The point being that although the memory that MyObj uses will not be reclaimed until the garbage collector runs other resources that MyObj uses could be released at a precisely defined point via an implementation of IDisposable.