I needed to implement the same interface twice in one object today. It took me a while to remember how I do this kind of thing so I thought it was worth a blog posting so that a) I can find it at a later date, b) other people can tell me of better ways to do this, and, c) other people can use the technique if they want to…

There seems to be a wierd bug with .Net 1.1 and sockets… In essence, this code: using System; using System.Net.Sockets; namespace ConsoleClient; { class Class1 { [STAThread] static void Main(string[] args) { TcpClient _socket = new TcpClient(); } } } works with .Net 1.0 and fails with .Net 1.1. The error message on 1.1 is this; “Additional information: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full”, which is the long version of WSAENOBUFS.

I like nested classes in C++. They allow a nicely fine grained approach to naming. Where a class may need to be called CRegistryKeyIterator if declared at namespace level it can be called Iterator if nested inside the CRegistryKey class. The problem is I think I tend to overuse the feature… I’m restructuring some code at present. This involves decoupling the IO Completion Port code for async IO from the socket server code in The Server Framework so that it can be used for file IO as well as network IO.

Looking back on my blog entries for 2003 it’s reasonably obvious that the big thing for me in 2003 was testing. TDD seems to work well for me and my clients. It’s not a silver bullet but it is a useful tool and I find that when you’re operating in TDD mode that nice code just unrolls in a nice, stress-free manner. What’s more, the code usually seems to turn out better than that produced without using TDD.

A combination of events in the run up to my Christmas break meant that I have ended up spending almost 2 weeks without feeling the urge to write any code. I’ve just chilled out and relaxed, watched some DVDs, saw LOTR ROTK, played some SSX3 and ate and drank too much. At the weekend I started to get my head back into coding thoughts by restructuring a couple of libraries that make up The Server Framework.

A long time ago, in a galaxy far, far away… I made a contraption to enable me to strap a camcorder to my head whilst I skiied. As you can see, it wasn’t the most subtle of devices. Well, times change. I upgraded my camcorder this year because I wanted a device with DV in for archive purposes. The new camera also has AV in and for Christmas Michelle bought me a weatherproof bullet camera which can plug into the AV in on the camcorder.

I have only ever made one prayer to God, a very short one: “O Lord, make my enemies ridiculous.” And God granted it. Voltaire From a comment in ESR’s blog. Given our current dealings with our building’s mismanaging agents this seems particularly appropriate right now.

Wayne Allen asks why so much code is so bad? Why the majority of code, even new code, that he sees as a consultant is terrible. Meanwhile, Rory Blyth is complaining about “Paper bag” code. I think Wayne hits the nail on the head with his comment about much of the problem being down to the individuals involved willingness to learn and change. But there’s more. Doing a good job requires lots of thinking, lots of self-discipline and lots of courage.

Today’s job is putting up the Christmas tree. That involves climbing around in our storage space “loft”. We didn’t use the tree last year, so it’s now got 2 year’s worth of stuff in front of it. I feel like I’m digging back through my past to get to it. I’ve just pulled out my previous pair of skis. 2m+ Salomon Superforce 2S. Straight as a very straight thing. Towering a good 8 inches above me (I know… but I was young, and keen, and they were wonderful at the time).

My time working on the refactoring project has come to an end; at least for a while. Here’s a little look back over what we achieved. I’ve been working on the “Refactoring Project” for around 9 months now. I’ve worked alongside the team responsible for the project several days a week for most weeks of that period. In that time we’ve tried to take a project that had become a big ball of mud, whose original developer had left, and make it more maintainable and testable and correct.