In the Zone

| 0 Comments

Where did the last three days go?

I've been working on this project for a client since February, on and off. They had some delays which meant that hardware that I needed wasn't ready when expected, so we slipped. Then other commitments got in the way, so we slipped. Then I decided to work around the lack of hardware and make one final push for the finish line...

That was Wednesday. Now it's Friday afternoon and I'm sitting here looking at the finished product, ready to ship. There's a small amount of integration work to do, but that's for another day. The product is a TCP/IP gateway for a legacy system, written using The Server Framework. The legacy app connects to the gateway which does 'Good Stuff' and passes data on to external systems. It also allows external systems to connect to it and passes stuff on to the legacy system. Hardly rocket science, but it's nice to see it working. The last few days have revolved around writing some new system tests which showed up a few 'issues', fixing the issues and adding the server monitoring system.

Wednesday morning I woke up knowing that for the roll-out to go smoothly we'd need more debug tracing than we normally put into these kinds of systems. I generally don't like debug traces as I've said before, but for this system it would be a useful aid to be able to see the data flow per connection in an easy to understand manner. Most of the installation work will be done by the client's personnel and I'll be at the end of a phone if they need me. I don't want them to need me. We've done several products this way for this particular client and it's worked well; thing is, the other products had much tighter specs and we actually got to see the hardware before we shipped the code to them...

So first thing Wednesday I added per connection logging and to simplify the code I used the 'null object pattern' to allow us to turn off the logs without introducing a mass of logic switches in the main-line code. We ran the system stress test and, well, it's all well and good that the system can produce a log file for each connection but when there are 200 connections on the go at one time you need some way to work out which one you want to look at. Made a note to integrate the logging into the status reporting so that you could navigate from the status updates to the logs...

Next was the status reporting; we have a simple web server embedded in the gateway server. If the web server is enabled, you can browse to the appropriate port on the box where the gateway is running and view the server status. Initially this was just a snapshot view of the gateway's performance counters. Then I added the per-connection status monitoring and links to the log files. Ran the stress tests again and locating the log we were looking for was easy. The web server was very limited but it could serve up the 3 or 4 dynamically generated status pages easily enough; they're not pretty, but then I don't do GUI... They do the job. Added the ability to display the logs directly in the browser which was kinda cool and should save the ops guys a bit of time... No, you can't navigate to random places on the server file system; the web server doesn't know about file systems, just about logs and the log manager knows where they live and only lets you say 'stream this log file to here'. One web page shows the real-time status of all 2-300 connections and it's a single click to see the logs if they're turned on.

Thursday morning I woke with 'Monkey app' in my head, not nice, but it meant that I got up nice and early. We have a pretty decent stress test but it's no good for working out why the gateway doesn't talk to the hardware. Spent an hour or so writing a very typical 'Len does MFC' test app (one dialog, big buttons) to allow us to put the gateway through its paces with a human at the wheel. Remember, monkey apps aren't tests even if you put 'test' in the name and pretty isn't the point, remember, I don't do GUI.

Since then it's been code, code, code. Working down the list of things to do, doing the things on the list and adding new things as they cropped up. Interesting how the areas of the code with tests felt more flexible even though it often seemed to take longer than it 'should' to change them as the tests needed to be changed and updated and checked. Interesting how seemingly simple changes could still break tests (mainly because they had seemingly simple bugs in the changes)...

Now it's done. The integration work can be finished next week, 17.30 on the Friday before a Bank Holiday weekend is not the time to start on that... I've spent the past three days knowing what needs to be done three steps ahead of where I currently am; feeling my body is racing to keep up with my mind; seeing the days vanish as I come up for air every 4 hrs or so. Now I'm done and It Is Good. It's times like this that I know why I keep doing this stuff...

Time for a shower; and then beer, and then curry.

Leave a comment