I’ve been noticing that since I started doing the testing thing in anger my objects tend to be smaller and I have more of them. The pressure that testing puts on you to design in such a way that each object can be used as independently as possible so that you can write tests seems to break chunks of functionality far better than other design methods I’ve tried. As I’ve said before, the problem then becomes one of managing the obvious complexity; looking at this kind of code for the first time can be a little daunting.
We’re happy to be helping Commerzbank in London with their FX trading system again.
Due to staff turnover Len’s back, part time, to help mentor the new team members and help with bug fixing and testing.
As I mentioned last week, I’m writing a new component for one of my clients. I also mentioned that ‘beyond the interface, I can do what I like’; that’s actually a surprisingly important part of the specification due to the situation that the client finds itself in…
The client’s current codebase is in a fairly bad way; a mixture of staff turn-over, evolving requirements, tight deadlines, and lack of care and inexperience and lack of strong technical leadership has allowed the code to develop a nice selection of problems.
I didn’t know you could do this; seems like a useful thing to remember. How to erase registry keys using .reg files…
I was reading this the other day and I recognised Past Mozilla Mistakes: two as something that quite a few (if not all) of my clients have made…
If you’re writing in C++ then COM is just an interface layer. It’s great for providing access to an object model to loads of non C++ consumers but, in my opinion, it’s a lousy thing to base your entire system on. COM is a complex thing, considering how much work it does for you, the rules aren’t that onerous, but they tend to corrupt nice, clean C++ code if you let them.
I’m building a new data provider for one of my clients. It breaks a huge chunk of their existing codebase out into a new component that hides behind a simple COM interface and abstracts away lots of nasty stuff so that they don’t need to worry about it. The inflection point is small; a method or two on a single COM interface. This is good as it means we have a single, easy to test, integration point.
Joel has written a nice little piece on the demise of the Win32 API. Some of it I agree with; such as for many developers the fact that .Net is just the latest example of Microsoft indulging in a Fire and Motion exercise, yet for other developers it’s vitally important; the trick, as ever, is working out which camp you fall into… But some of it, I don’t.
I really don’t understand the problem with API complexity (but perhaps that’s because I don’t really understand the problem with API complexity…).
Last week I spent some time back with the guys on the refactoring project. Things are going well for them and, apart from a few minor transgressions, they’re sticking with the process that we put in place when I was with them on a regular basis. The project is currently suffering from a slight lack of technical direction; they have a new guy on the team and he’s enthusiastic to try ’new’ things and nobody is currently restricting the things he is allowed to try…
Sorry for the recent outages. My hosting provider upgraded a server and it took longer than expected to find all the things that were installed on the old server but were not on the new server. It seems that I’m the only one that uses them…
Blog was down for a few hours, comments and trackbacks have been hosed for a day or so. All seems fine now.
20 year’s ago I traveled with my dad and the remaining members of my grandfather’s unit to Normandy for the 40th anniversary celebrations. I was 17, around the same age that some of them were on the day. My grandfather, Frank Holgate (also ‘my F.’), survived the war but died from heart disease when I was far too young.
I’ve found the news reports of the 60th anniversary to be far more moving than I expected; possibly because I spent some time with these amazing people.