As Gavin pointed out in a comment yesterday, if you type “cure for rsi” into Google right now my hair-brained babblings about how drinking lots of water helps is top of the pile… If only I could do that with technical posts that would bring in work ;)

Today I’m doing some work for a client that involves writing some blocking sockets code to talk to one of our servers. Blocking mode fits well with the architecture of the client application they use; we’re moving the app from blocking reads on a serial port to blocking reads on a socket and jiggling the protocol it uses a bit. Testing blocking calls is actually a bit harder than testing non blocking calls because hand cranking the mock objects so that your object under test works correctly is harder to do when your test harness is blocked in a call to read() and wont come back to you until the call times out (and the operation that you’re trying to test fails) or the read completes…

A while back I finally started on the async version of the POP3 client. It ended up as a state machine and seemed to work well. The next step was to write an async version of the mail collector that I used to pull all mail from a mailbox on a server and optionally delete it. The synchronous version of the mail collector is a fairly simple thing. You pass it the mailbox and server details and it decides how to log in; it uses APOP if the server supports it and USER/PASS if it doesn’t.

I agree 100% with this piece from Jimmy Nilsson’s blog.

“I’ll bet you that from ten feet away I can tell if a program is bad. I might not guarantee that it is good, but if it looks bad from ten feet, I can guarantee you that it wasn’t written with care. And if it wasn’t written with care, it’s probably not beautiful in the logical sense.” Charles Simonyi The quote is from an interview with Charles Simonyi; via Joel’s discussion forum.

Those of you who are interested in the Warren Smith Saas Fee ski training sessions you might like to take a look at Warren’s latest DVD, Warren Smith Ski Academy Lesson 2. The first two sections, carving and steeps, were filmed during our course in September 2003. As you can see, the snow was pretty good and, as I said at the time, he had us doing some pretty interesting stuff.

I’m reviewing a large body of code for a client at present. It’s a general review of the design, coding style, code correctness and testability of a project. I started off by making notes on some of the general design changes that I’d recommend and eventually got down to a detailed review of the code. There’s a lot to say about the code and, as with all code, sometimes it’s hard to figure out the reason behind the use of a particular construct.

Interesting thread over on Joel today about using const, or not. The original poster asked how many people bothered to mark function parameters that they don’t modify as const and whether there was any performance or readability advantages in doing so. Ignore any performance issues, making your code const correct has massive readability and comprehension advantages. I’d go so far as to say it’s one of the most important coding standard issues there is…

The test certificates that shipped along with the OpenSSL server demo that I posted here have expired. I’ll post some new ones shortly.

I’ve seen a lot of blog postings recently that pour scorn on the ideas behind TDD. Ah well, if you don’t like it, don’t do it. I’m more than happy if our competitors decide that TDD isn’t for them. In fact, testing is bad, don’t do it, move along now, don’t read any of the testing articles here… The jarring of the “real world” work we’re doing is made worse by work we’re doing for another client at the moment.