Throwing Down the Gauntlet

Right, I know, two posts in two days... kind of different that the usual MO around here. But I felt the need to declare before the world that I have officially HAD IT with Tomcat. I have just spent the last two hours of my life— hours that should have been spent doing something, ANYTHING, other than dealing with Tomcat— screwing around with JNDI contexts, obscure classpaths, xml configuration files, and so on, trying to figure out why an application that had worked perfectly well on one laptop wouldn't work on another. The answer is annoyingly nitpickingly technical, so go ahead and ignore the next paragraph if you want.

It had to do with the fact that the application had been written a laptop which, for all sorts of stupid reasons, still has Tomcat 5.0 on it. My newer laptop is much more up to date, and has a relatively current version of Tomcat 5.5 on it. Even though these are only a few minor versions off, they have wildly different configuration file formats, and this is what finally bit me in the ass. See, in pre-5.5-Tomcat, a JNDI resource declaration consisted of a Resource tag and then a ResourceParam tag containing the configuration parameters for your resource. 5.5 does away with this, and now parameters are declared as attributes for the top-level Resource. This change is definitely for the better, and I can see why they made it— it simplifies a confusing and overly complex configuration process.

The problem is that if you try and use the old behavior, it fails silently, and then causes your code to break in odd ways. Rather than give an error message, or support the old behavior with a deprecation warning, Tomcat just forges boldly on ahead. Anything that was trying to use those parameters now gets null, which causes all sorts of interesting runtime errors. Would it have killed them to put ten lines of code in to check to see if you were still trying to use ResourceParam tags, and then spit out a warning to stderr? Why do they hate their users so much? Why?

This change in configuration file format is, in fact, documented... but it's pretty well hidden, as is so much of what one usually looks for in Tomcat's documentation. Gah.

At any rate, I have now officially Had Enough With Tomcat. No more screwing around with massive XML configuration files— it's over. Oh wow, that felt good to say. Not sure what I'll be using now... I've really been digging Ruby on Rails, and the 1.1 release will finally add polymorphic relationships and easy support for aggregate functions (count(), sum(), etc.) and group-by statements to ActiveRecord. This news makes me happy... perhaps it's time to see if they've made any progress with easing the pain of hosting a RoR app.

Hmmm...

Wow, so, long time no post. This quarter's keeping me too busy- this is *so* the last time I take a 16-credit course load. I've basically been eating & breathing linear regression, which is turning out to be fascinating (in spite of the frightening textbook). I've also been getting far more familiar with linkage analysis than I'd ever really wanted to be. I'm working on some software to take in genotype data from a repository of microsatellite data and output some interesting visualizations based on linkage, and the biggest problem is not turning out to be the algorithms. The problem is being that I (foolishly, I see now) decided to use PML (the Polymorphism Markup Language) as the input file format. "It'll be great! Any other app that outputs PML will be able to use my program! Standards are good! Why roll my own representation of pedigree and genotype and haplotype information when there's already a perfectly good standard out there?" Of course, PML turns out to be enormously complex, and really not all that well documented. The documentation consists of a long OMG specification, some sample files, and a giant XSD file. The XSD file is pretty well-documented, and the OMG document goes into quite a lot of detail... but there's no real high-level look at how to represent various types of data using PML. I've been figuring it out as I go along, but it's being more work than I'd hoped. A lot more work. Grrr. Hence my current procrastinating.

One recent event of note was that I got to play around with a da Vinci Surgical System. This is an incredibly fancy computer-assisted surgical unit. Picture the loaders from Aliens, only instead of magnifying human movement, it reduces it. A lot. A whole lot. The device consists of a control console and a bedside unit. The bedside unit is a large and intimidating cabinet that has up to four manipulator arms coming out of it. One of those is for the stereoscopic camera, the other three are for tools. You stick as many of the arms as you want into your patient, and then fire the thing up.

The surgeon sits at the console a few feet away, sticks his or her head into it, and is immediately presented with a three-dimensional view of whatever the camera is pointing it. From the natural sitting position at the console, the surgeon's hands are perfectly placed to use the manipulator control units. Unlike traditional laparoscopic controls, these are not scissor-grip handles. Rather, they are oddly-shaped and difficult to describe gadgets that your hand fits around perfectly. The thumb and forefinger grasp a small lever, and then you just move your hands as you would if you had them stuck in the patient yourself. Any motion of your hands or fingers is immediately carried out by the tools being wielded by the bedside unit, only with all of your natural hand tremor removed, and with the motion scaled down by a good bit. That is, a one-inch movement by your hand translates to approximately a third of an inch of movement by the tool.

The really amazing thing is that the tools have pretty much the same range of motion as your hands do, so anything that you could do with your hands, you can do with the tools. Other laparoscopic systems I've used require significant mental effort to translate what you want to have happen into what the tools are capable of doing in terms of movement and positioning. Operating this thing was completely natural— it was very easy to forget that I was controlling a machine!

The display adds to the effect. The laparoscopic systems that I've used had no depth of field, making an already demanding eye-hand coordination task all the more difficult. Because of the stereoscopic camera and immersive display, the da Vinci system had superb depth of field, which made everything far easier. I was actually able to tie sutures, something that I've never been able to accomplish with traditional laparoscopic tools. Of course, I'm not a surgeon— so the fact that I was able to sit down at this thing and immediately sew and tie a pretty good (or, at least, not awful) suture is saying something. :-)

The price tag for these babies starts at around 1.5 million dollars, so it's not for the faint of heart. The possibilities, however, are endless— both medically, and from an engineering perspective. These things are true works of scientific art— a beautiful melding of precision hardware engineering with top-notch software engineering. Anybody out there who works at or near a medical facility should try and arrange a demo— it's hours of fun for the whole family... er, hospital.