Three bugs went into a program; a memory leak, a misunderstood interface and a deadlock… The memory leak was easy to track down as it was in the code that was covered by the test harness. So we just instrument the code with Bounds Checker and run the test. A reference counted object was being mishandled and leaking. Easy fix. The interface issue was harder. I was using a std::list<> to manage a list of items and every so often needed to walk the list and remove some entries.

Given that the work I do goes on in my head and can be done anywhere I find that it’s often done everywhere. Anyone got any hints on how to switch off? Skiing and skating are good for me as I can’t think about other things when I’m doing them. Everything else always has the risk of being interrupted by an ‘a-ha!’ moment where a ‘work’ problem is suddenly solved and I need to scurry away to the study to implement the idea… And then you get in the flow and hours go by and you haven’t spent time with people you should.

We tried the new Carluccios on Upper Street on Friday night. Great food and excellent service. Back to watch the final Buffy (season 6) on DVD (so sad); glass or two of Glenfiddich, bug hunting and to bed. Up early to bug hunt and then skating in Kensington Gardens on Saturday morning. Back to get changed and then off to The Blue Elephant in Fulham for Hilary’s birthday do; more great food, left my unbrella at the restaurant :(.

If I don’t write enough blog entries then the way I have my CSS set up means that the front page starts to look ugly as the number of entries on the left side of the page shrinks and the columns on the right go all squigly… Is that why blog people end up writing these inane items that nobody really wants to read?

It’s easy to write untestable code. It’s natural. Most code that we write will be hard to test unless we explicitly think about testing when we write it… This code is really simple, yet it’s untestable. Why? DateChangeManager.h class CDateChangeManager { public : class Listener { public : virtual void OnDateChange( const CTime &oldDate, const CTime &newDate) = 0; protected : ~Listener() {} }; CDateChangeManager(); typedef unsigned long Cookie; Cookie RegisterForNotification( Listener &listener); void UnRegisterForNotification( const Cookie &cookie); void CheckForChange(); CTime GetToday() const; private : CTime m_today; typedef std::map<Cookie, Listener *> Listeners; Listeners m_listeners; CCriticalSection m_criticalSection; // No copies - do not implement CDateChangeManager(const CDateChangeManager &rhs); CDateChangeManager &operator=(const CDateChangeManager &rhs); }; DateChangeManager.

The code generation crowd are at it again. So, “writing code” is stupid is it? Well what will we call writing the requirements in a form that the code generators can understand and why will it be easier to get the requirements right? I like code generators. I couldn’t live without my IDL compiler. Or generators that write the grungy database access code or generators that make it easy for me to make SOAP calls.

A while ago I likened writing articles about code with pickling it to preserve it… It seems the last few days have been spent changing the vinegar… I’m moving most of my source to CVS. This was easy for the code that I had that was current; the Socket Server stuff and all of my latest clients. I’ve been working with all of that code a lot recently and it’s all pretty clean and consistent.

Back in 1999 Darren came up with a cunning plan to make lots of money. The plan was ‘device control over the internet’… In summary, we didn’t. Ideally this plan required an audio/visual link as well as a device control link. I decided that doing the audio and video ourselves was too much work and that we’d be better off using the NetMeeting data channel for our device control. We would get the audio/video stuff for free and wouldn’t have to worry about things like cameras and microphones.

“The most successful method of programming is to begin a program as simply as possible, test it, and then add to the program until it performs the required job.” – The PDP-8/e Small Computer Handbook (DEC, 1972) - Chapter 9, Page 9-64 Just what those agile guys are saying! from Joel.

For those of us still working with VC 6… This page about all the clever things you can do in the debugger watch window is pretty cool. I knew all about s and su and hr but I didn’t know about m, that one’s way cool. Hmm, looks like all of these work in VS.Net 2003 too :)