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. Then, in 2005, I adjusted the code to be more scalable and I showed how the tests that had originally been written helped when code needed to be changed for performance purposes.
This morning a new Ready NAS NV+ unit arrived, so now I have three. I didn’t have a sudden change of heart about buying a development box, the power supply in my office NAS died on Thursday afternoon and buying a new, bare, enclosure was the quickest way to get my existing disks back online.
However, once I get the faulty until returned from repair I’ll have a unit that I could develop on…
As I mentioned a while back I’m using a pair of ReadyNAS NV+ RAID systems as my on-site data store and off-site backup. These are both working well and I’m pleased with the solution. After a few hickups and delays due to the Netgear takeover of Infrant it seems that the firmware is developing nicely again and the latest thing that I’ve discovered is that you can now develop and deploy your own code to the devices (if you’re brave enough!
Whilst I’ve been away I’ve had a bug report for the TDD timer queue code that’s available here. The report is completely correct and could result in a timer being scheduled out of sequence if it’s scheduled around the point when GetTickCount() wraps. I’ve coded up a fix but I need to write it up and post it. It may take me a while to do this as I have a lot going on in my life at present, if you need the fix sooner then drop me a mail.
I’ve been away skiing for a couple of weeks in Davos and St. Anton, the snow was pretty good in both places but Davos won out as a more civilised skiing experience. St. Anton was just too busy for me, I’m getting fussy in my old age ;). The situation in St. Anton wasn’t helped by the fact that when we arrived the off-piste was all a bit crunchy and skied out which meant that most people stayed on piste and then we had a big three day storm that kept the high lifts and links shut and meant that several of the accessible off piste routes were unadvisable due to avalanche risk.
An interesting piece here from Phil Haack about why they decided to use an abstract base class rather than an interface.
Versioning is always a complicated thing for library designers. I know that I’m lucky in that I don’t have a gazillion users of my libraries so I tend to make breaking changes rather than build up technical debt in the name of backwards compatibility but I’ve worked on software where we couldn’t do that and where binary compatibility was important.
For some time I’ve had a class which implements asynchronous file writing. It’s the basis for a logging class that some of my clients use. The class builds on several of the classes in The Server Framework and uses I/O Completion Ports and a thread pool to manage the overlapped I/O. Due to the way that I structure my servers you can often share the I/O pool that you use for your overlapped log writes with the pool that deals with the socket I/O.
The latest release of The Server Framework is now available. This release includes the following changes.
All code now builds with VC6, VS2002, VS2003, VS2005 and VS2008. The VS2005 and VS2008 builds support x86 and x64.
This is the first release built using continuous integration and there have been some project file fixes to fix incorrect output directories, etc so that x64 and x86 builds can be done in complete isolation.
I’m still reading the Richter book, highly recommended even if you’ve read one of the earlier versions. In fact it’s possibly MORE highly recommended IF you’ve read one of the earlier versions… It seems that lots of things have changed a little, and some things have changed a lot. Unfortunately the book doesn’t detail the actual changes. Note to publishers; I’d PAY for a slim book that DOES detail the changes between the APIs that are being discussed…
One of the problems I currently have with CruiseControl.Net is that some of my tests spawn multiple processes; such as server tests which run the development environment, which runs a batch file to start a server (or two) and then run a test harness which generates network traffic and then run a program to ask the server to shutdown cleanly. When these tests timeout in CC.Net they’re forcibly killed. Unfortunately due to how Windows processes work, killing the parent of a tree of processes doesn’t kill the children.