sipXconfig
Saturday, July 16, 2005
 
sipXconfig code implosion
After 1 year and 1 month, sipXconfig developers are almost done rewriting entire application from the ground up(rewrite was not main focus, many features were added in this time). Because all the new code was written parallel to legacy code, there was an implosion last week when all the legacy code was deleted and all that was left was the new code. I had to accumulate some source code metrics to capture this effect.

This shows LOC (Lines Of Code) for sipXconfig Version 2.8 v.s. Upcoming 3.0 Version. This does not include unittest code, I'm hoping to post code coverage metrics if I get some time. We've reduced codebase by 75%. We still have a number of features to re implement, but i do not predict this number changing that dramatically.

Lines Of Source Code
sipxconfig-code-metrics

 
it's the aspect, stupid!
My infatuation with Spring is official. My significant other knows. We have an understanding. (Which is a lot of fun, since it makes my fellow programmers quite jealous.)

It turns out that the way to coder's heart goes through aspect oriented programming. This great technique, let's you solve one problem at a time. And Spring empowers you to use it.

Let's say you have this lengthy operation that should be done asynchronously. In sipXconfig world it usually means replication and until recently no-one dared to speak this term aloud without paying tribute to programming gods. By I digress...

I get to work. I write the tests. I write the code. After couple of iterations things start working. And now for something completely new. I cannot possibly run replication - which involves opening HTTP connection to sipX servers - in the same thread that builds WEB pages. The last thing our users need is extra coffee breaks, while they wait for page refresh. So I dig out my Java and threads books and start worrying... And then it hits me. The fact that my code runs in a different thread in not a property of my code. It's not even the property of the code that calls my code. It's a different ASPECT (and when I say ASPECT you need to visualize it as a fifth spatial dimension in the coding time-space). I repeat this couple of times in my head. Then I repeat this couple of times to lazyboy, who - as usual - looks unfazed. Just in case he might want to say something, I pretend that I am really busy and I run back to my computer.

It turns out Spring lets me to write little pieces of code called interceptors. I can intercept any method call and do something extra. For example spin the thread, or even better tell a thread pool to do something for me.

The callers do not see anything different. They call the functions as they always did. Just by changing Spring beans configuration I can change all my beans to asynchronous. Aspect of replicating data is isolated from aspect of doing things in the background. And you code, test and implement one aspect at a time.

This experience comes handy couple of days later when I integrate Apache XML/RPC client. This is how sipXconfig will communicate with sipX servers in future. But I do not want to expose this fact in every sipXconfig corner. I do not want to write entire isolation layer of code either. Turns out I do not have to. Again thanks to the ASPECT. Just as calling stuff asynchronously, calling stuff through XML/RPC can be handled by Invoker. Good Spring people do not have XML/RPC invoker, but writing one turns out to be trivial.

And again - the code that calls my beans does not even know that implementation of the interface lives on sipX server. Xmlrpc-iness is magically injected in the configuration file.

 
may be it is rocket science after all
It's 2005 and you still cannot spend weekends on the Asteroid Belt. Every geek I know is seriously depressed by that. Instead, bunch of smart people is spending weekend debugging stupid fuel indicator on Discovery.

That made me think about unit testing. Pretty much eveything does these days. Some time ago I have read Columbia Last Flight. By now everyone knows about that fatal piece of foam that smashed into Columbia's wing during lift off. Apparently for a long time, despite of increasing evidence, some NASA engineers could not accept that. They decided to test the "foam did it" hypothesis. They were actually shooting foam pieces into shuttle panels and monitoring the damage. William Langewiesche in his Atlantic Monthly article describes the critical test: The gun fired, and the foam hit the panel at a 25-degree relative angle at about 500 mph. Immediately afterward an audible gasp went through the crowd. The foam had knocked a hole in the RCC large enough to allow people to put their heads through.

I like to think that this is what happens when you type "ant test-all". A gun is fired, big piece of foam hits sipXconfig code, damage is assesed. There are no gasps, just test report. And if there is a hole, no-one's life depends on it. (Well, there is this e-mail from lazyboy with your morning coffee.)

Now the sick part: it almost makes the lack of Asteroid Belt vacation package bearable.


Powered by Blogger