The last few days have been rather hectic as I find myself actually doing work for a change. I finally got around to get to the point of debugging one of my secondary projects -- generating call timing data from the event stream and storing it in the database. Now, one reason why I wasn't doing this was that I didn't want to set up a full installation of our product. Not only has it gotten big, but I've pretty much lost the knowledge to use it.

Since the statistics module is an add on package that doesn't interfere with the MCM (Multi-Channel Manager, the current name for the core product), the easiest thing to do was to just get a trace of the events from a test run. Then I could at my leisure use the trace and feed that to statistics, since the module only looks at the events and needs very little else to run.

I spent two days getting rid of nullPointerExceptions and making sure that the data it's making at least makes some sense based on the event stream. At this point I wasn't using the standard input and ouput parts, but dummies that read from the event log and displayed the output to screen instead of writing to the database.

After I was sort of satisfied with that, we did some unit tests to make sure it worked with the MCM. Nope, the output part was erroring out. The problem with some errors is that they can be kind of cryptic. This one was "String index out of bounds" when executing the SQL statements. I thought it may be bad data, then I thought the JDBC layer was bad, but it worked with a little test program I had so I was really stumped. After a day I finally narrowed it down to the SQL statement itself, which I had forgotten to terminate. That's a problem with JDBC, lots of Strings used so no compile time error checking. Makes debugging longer since you have to compile then actually run the program to see the errors.

So now I had it writing to the database. Back to the test run: three simple calls to see if it could add them up correctly. Nope. Back to getting the trace and poring through the log file. A rather work intensive process where I look at each pertinent event and jot down the timing info, slowly building up the time parts of the call and seeing if they match with what the debug statements are saying.

But this time it was something else. I forgot a little clause in the isDone method of the call. I have to clean up the call objects to reclaim memory, so I know a call is done if the last timestamp is filled in for a standard call, or the hangup time is filled in for an abandoned call. I forgot to make sure that the last timestamp actually has a value, otherwise I'm comparing it's default value of 0 to see if it's less than the current time, which it will always be.

So back to changing the code. Then check in the code into our CVS system. Then compile the code, download it to the test machine. Start the three programs (the MCM itself, an agent simulator, and some sort of call inbound server) then log in the three agents. Then actually do the calls. Wait a minute or two then check to see if the data is correct. If not then I'll have to ftp the event trace and the debug log to my work machine (since it's running an FTP server and I can't seem to get Windows Networking to work), then ftp from my work machine to my PowerBook. A lot of little steps.

We just got an iBook (Tangerine) so we can do certification testing on Apple hardware. There's a bit of a push to certify our various products so that we can say that at least our client stuff works on the Mac. I think in return we got a bunch of iBooks and iMacs from Apple. If they can actually get all the web-based stuff to work that'll be great. Right now it requires JInitiator, which is a Java runner that we wrote for Windows, hence I haven't been able to use it on my Mac. It would just be yet another little thing that I won't need Windows for.