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.
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
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.
