Once again I have a list of items flagged for comment in Bloglines but at least this time I have an excuse: “We were on a break!”.
First is a link from Brad Wilson to where Bruce Eckel writes about how the “Hyper enthusiasts” of the Java world have moved on to Ruby. Bruce makes some good points. Personally I’d be pretty happy if all persuasuion of “hyper enthusiast” were to vanish overnight, IMHO they just get in the way, distort the picture and encourage bad decisions…
Noel Llopis, over at Games From Within, has written a nice piece about a typical workday at his work place, High Moon Studios.
It certainly sounds like a nice way of working. Unfortunately I haven’t been involved in quite that agile a team yet.
I’ve been skiing for the last couple of weeks and now I’m back in London; normal service will resume soon.
It seems that the leak that I found isn’t likely to be the one that my new user of the code is having problems with. They’ve built the code with Visual Studio 2005, made a few (correct) changes to the code to get it to build with the stricter compiler and they find that several of the servers leak; at first it looked like it was just the more complex servers but I’ve just tested the simplest echo server and that leaks in just the same way.
Well, the leak in my legacy code wasn’t too hard to find. There was one potential leak and one screamingly obvious leak. I’ll post the fixed code tomorrow.
I’m currently investigating a memory leak in a complicated piece of multi-threaded code. Unfortunately the code doesn’t have any unit tests and the leak only shows up reliably in the release build. Worse, I wrote the code and nobody has fiddled with it since, so it’s my leak and my code and I have nobody to complain about and no excuses. I miss the unit tests and loose coupling that would be present if I hadn’t written this particular piece of code quite so long ago.
Paul Graham writes about “How to do what you love”… It’s quite a good piece but the best bit is hidden down near the end. He suggests that a good way to “stay honest with yourself” about dreams to do something other than your “day job” is to Always Produce; that is, don’t just talk about it or think about it, produce physical artefacts.
This is excellent advice and it can be applied to pretty much everything you do.
Charles Petzold confesses his love for books.
I must admit this bit really hit home for me: “I love how my books remind me of passages in my life. I love the shelves of authors I’ve been obsessed with, and the books that knocked me over. I love knowing that I still own virtually every book I’ve read.”
I have shelves and shelves of technical books as I’ve always been quite happy to buy a book on the chance that I might learn one thing from it.
I finally got around to upgrading my mobile phone from an aging Sony Ericsson T68i to a more current (though still hardly bleeding edge) Motorola Razr V3. I’m not interested in the downloadable java games but the fact that you can get a J2ME SDK for it and that the docs seem to imply that you can access the GPRS network using SSL and that you can also access the serial port makes it interesting… Now I just need a hack to be able to somehow connect the Garmin GPS to the V3 and some code to grab the location from the GPS and send it off to a web service somewhere and some duct tape to make it one device…
The size of the “units” that I test with my unit tests varies quite considerably. Usually I tend to work at the single class level; the test will provide mocks for the services that the class requires and the tests will ensure that the class behaves correctly and interacts as expected with the its service providers. Sometimes though the units consist of a whole subsystem, still often a single class, but one which wires up and collects many other classes into a single component; again the service providers that it uses may be mocked but they’re often only right on the edge of the functionality that is being tested.
