Konstantin I. Boudnik's Blog: December 2005 Archive

Posted by cos on December 23, 2005 at 05:55 PM | Permalink | Comments (4)

Hi there again.

Getting back to my favorite topic about quality of life... I meant that pseudo-life, we all are trying to make. And if there's Something, what had once created all of us and everything else around - it did a way better job :-( But, I think, we have deserved a credit too: we don't have all the time in the eternity to finish our job by trial and errors approach. An average man leaves about 70 years; say 30 years of which she spent in diapers, at school or on medications in front of TV, purchased on retirement money. Which left us with roughly a 40 years term, split between personal and professional life (change the order if you want to :-)

All my professional life is literally coupled with computers (I have six of them at home, including an old Sun's SparcClassic LX and not including my Palm Pilot). And as more and more software is coming into our lives, I'm wondering if I can rely on it and where are the limits of this trust. Also, as a participant of Java software development cycle I want to do better job myself and help my colleagues to do same: namely spend less time to develop more robust software.

This brought me to the point of quality indicators definition. What will be the right criteria to determine if a piece of software will break or not in customers hands. And again, where is the right target to aim our testing efforts and wether or not they are efficient?

After some consideration we humbly came up with the following list:

code complexity? Yes, this is the beast. If you have methods as long as 3+ screens it's bad. If you class hierarchy contains 5+ levels – it's not good either. Does it smell right, if you have 300+ lines of code/class?
a frequent code changes? Or even changes per feature or bug? Yeah, perhaps. If you do have about 5 commits per bugfix it doesn't sound right at all. However, I can imagine some other considerations.
poor code coverage? Yes, one of the kind. But even coverage numbers can't save you from troubles. It isn't a panacea.
design and coding styles? Well, may be. Stylish code is easier to read, understand, but not necessarily to maintain. And if coding styles are easy to check, design style's flaws might not be that easy to find and eliminate. Patterns are helping here in particular, but you have to know where is the fine line between good design solution and simple yet sufficient implementation
code duplication? Not in a sense of reuse, but in a way of overuse of copy-n-paste "technique". Yes, ugly enough. As one of my readers had appointed - if one had introduced a bug in a code, which was copied a few time later then one will end up with a multiple copies of the same bug hidden all over the place :-( There's a number of automated ways to find and fix these rotten spots. One of them named PMD was mentioned by another reader of the article and can be found here
Thanks to all of you sending comments or expressing interest otherwise. If you can imagine or know more of these from your practice – please send them in and I'll gladly add here any reasonable ones.

Well, assuming that now you got a data for all from above and then some. What and how you'll deduce from here?

Let's talk about this after I get back from that nice winter break. How about open sourcing some ideas? Ok, I'll share (swear!) the principles of the technology we're working on for last few months.

Best of everything to all of you and Happy New Year to everybody. Also, Merry Christmas to those who believe in Santa Clause or whatever you can call that dude, who knew something about quality in a long term!

Cheers!
Cos

Preparing your tests

Posted by cos on December 19, 2005 at 12:54 AM | Permalink | Comments (0)

Hmm, I just realized, that it's been a while since my last posting here. So, hi there! And for a difference, this time it isn't about java quality :-)

Last month I was pretty much busy with our testbase build automation. It's not a secret though, that our server VM testbase has a lot of native test code. As David had mentioned recently we have quite a handful of platforms to take care of and it's getting even more troublesome when you need to carefully lay out a lot of native bits.

So, here some insider's information, and please don't tell any one where you got it: we need to build the native pieces for as much as eight platforms (I might've missed a one or two), including Solaris/Linux/Windows on AMD64, of course. Most of native build's pieces are getting built on a separate machines, e.g. you can't build Solaris for Sparc and Solaris for x86 on the same box, can ya? Well, technically speaking, you can do cross compilation in most of cases, but we aren't that limited with hardware resources. Any way, doing this kind of drill manually might be a boring, not cost-effective effort and one can definitely spend all this time for something more interesting

So, we decided to automate out build process. The whole thing was divided into two pretty isolated pieces: writing Ant managed build mechanism and setting up a tiny run-n-watch framework to control as many as 6-8 remote processes, spawned in a certain order. The Ant part has been taken care off by our genius engineers (sic! I mean it) in Saint-Petersburg office and I handled relatively simple execution part.

We do use two different distributed execution systems in our daily business: DTF and Grid engine. Latter takes care about Unix's and former handles Windows, because it's pure Java and doesn't care on what hardware it's running. As the result, I had to create two different sets of starters and watch-dogs to manage our build processes in a slightly different manner.

And I was kind of surprised, that I can write distributed watch dogs, using nothing but Bourn shell (yes, the matter of fact, you can actually program on it and create clear and maintainable code. Wow!). Of course, there's no inter-processes communication or multi-threading. I didn't use anything else more fancy than file-locking (I know, I know – I hate this myself). But it was sort of fun to do this. Overall, the watch dogs' system is quite simple:

- there's a single driver script, which knows everything about build logic and sequences; takes care about any clinches or time out issues
- it sends a set of smaller platform specific scripts to Grid'ed and DTF'ed machines
- sets a number of watch-dog monitors to trace build progress on every platform
- platform specific build drivers do an actually Ant build and are sending notification to the central Tinderbox-like monitor. This helps to ease visualized human control over the process.
- top level script is rolling in a big loop until for all process to finish
- upon the build is successfully completed, the main driver does all necessary adjustments for the fresh bits and run baseline testing against this new testbase. Voilà!

That was my pretty much first real experience of using Grid and it unveils some pit falls, perhaps (or it may be me knowing just too less about this system). For instance, you can't rely on relative paths in your application, because Grid copies a submitted shell script somewhere and executes it from there. Eventually, what was `dirname $0`/../logs/mylog when you were developing your script, will lead to nowhere.
Two other things: setting an 32- and 64-bits environment on Windows platform from a shell script. It took me a while to carefully write a shell equivalent of SetEnv.Cmd batch file, which a Visual Studio supplies.
And I had to find a way around the fact that Linux's automounter sometimes has troubles mounting NFS' auto-maps.

However, on a pleasant note: I had spent a good chunk of my professional time between 2001 and 2004 developing DTF and now it's paying back :-) by nicely doing some leg work for me.

So, yesterday I was able to build new Server VM testbase out of the box without much of my involvement (still had to get done a couple of quick fixes, simply because I was lazy enough no to do any dry-runs beforehand). Hopefully, next time it will cost me as much as a single keystroke to start that main driver script.

What will be a conclusion, you might ask? Hmm, I don't know – I just liked the stuff and the way of getting complex things done with a set simple techniques and tricks :-)

Hope to see yall soon again,
Cos

Offline Java Coding Contest (round 2)

Posted by cos on December 09, 2005 at 01:53 PM | Permalink | Comments (3)

Hey there.

As you might know, my colleagues and I had tried to perform a round of offline Java programming contest back in November (you can read more about this here). Due to a number of reasons, we had no winners that time, however, all participants got some encouraging gifts :-) We had decided to go with another round of the contest. It should start any day now. Please keep watching announcements at http://www.sun.ru/

Yours, Cos

Powered by
Movable Type 3.01D

java.net RSS Feeds