There’s a nice post by Miško Hevery over on the Google Testing Blog about Writing Testable Code. It pretty much sums up my views on testable code. Go read it!

There’s an interesting article over on Dr. Dobb’s about why writing lock free code is so hard. Herb Sutter takes some code from an article that Dr. Dobb’s published a couple of months ago and pulls it apart and points out the problems.

I realised this morning that part of my “The life of a stream socket connection” document about the safe use of server callbacks in my server framework was wrong. I said this: At any time after a connection is established, including before you’ve had a chance to handle the connection establishment event, you might get a connection termination event. and this: Note that it IS possible that you could receive error, client disconnect, connection reset or connection closed events before or during the processing of the connection established callback.

The code in the last two articles in the “Practical Testing” series have contained a considerable amount of duplication. This came about for a couple of reasons. Firstly part 17 was a bit rushed and secondly it was useful to compare the CCallbackTimerQueue implementation with the CCallbackTimerQueueEx implementation. I’m also a firm believer that in this kind of situation it’s better to get both sets of code working independently and then refactor to remove any duplication rather than attempting to design a duplicate-free solution from the start.

As I mentioned here I’ve recently adjusted how socket callbacks are dispatched in The Server Framework. Once you’ve written a TCP server or client you will find that you spend a lot of time dealing with the lifecycle of the connections that are created. You get to deal with a number of events which take place during a connections lifetime and, due to the way that the framework works, you can select just the events that interest you and ignore the rest.

The latest release of The Server Framework is now available. This release includes the following changes. The following changes were made to the libraries. Some whitespace changes to remove incorrect tabs. Admin Library - 5.2.3 Added a check for _WIN32_WINNT >= 0x0600 and JETBYTE_PLATFORM_SDK_VERSION < 0x060A as targetting Vista or later means we enable stuff that’s only available in the v6.0a Platform SDK. Added The \ref AdminFAQ “Frequently asked project related questions” page.

Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since then there have been various changes and fixes and redesigns all of which were made considerably easier due to the original tests.

We’re working with VEXIS Systems Inc. to build a high performance TCP/IP server system using The Server Framework. The server provides a vendor neutral, scalable, high performance client/server framework for event monitoring, data aggregation, and backend system integration for the telephony industry. The server provides a pluggable framework allowing each “plugin” DLL to manage its own resources with respect to various backend systems and call centre equipment.

I started to document part of The Server Framework’s behaviour as I expect that a client will be asking questions about it in the near future. Whilst writing the documents I found myself writing this: “It’s pretty easy to deadlock The Server Framework in complex servers if you don’t abide by the rules. Unfortunately, the rules weren’t documented until now and, although I knew them, it’s probably more accurate to say “I knew of them”.

I stumbled on Gustavo Duarte’s blog this week via this post about how lucky we are to be programmers. The post that led me to his blog is good stuff and has had lots of linkage this week. The rest of the blog is also good stuff; I especially like the “Reality Driven Development” post which fits nicely with my “thin thread of functionality” way of designing software. I’ve always tended to design from the bottom up and my testing addiction has fuelled that somewhat; but I do still like to pop up to the surface on regular intervals and then drill down with a ‘spike’ of throw away code to make sure that the stuff that I’m building properly is actually what we need to build.