open source suckfest...and some bad coffee

maybe it's me ... maybe i'm just having a bad week ... i've been staring at terminal windows for the last couple of days working with some of the premier products of the open source world: apache and tomcat. First, I couldn't find either an RPM or a Linux binary archive for the latest version of Apache: 2.0.43. Not finding an RPM is understandable, but then the absence of a binary for Linux (arguably the most popular platform for Apache) is suspect. Of course, I could get the source archive and compile it and install it. Sure, but I'm not enjoying a day at the beach... I have deadlines here. Software exploration is not something you do on work time. And I can't bear to sit up late staring at a display and going into trance mode over scrolling lines dumped by the build process.

I finally find some binary RPMs (yay Google...<censored> to Apache). But the installation paths are completely different and the RPM extraction to a temporary folder does not work. Clearly, you see, it is not my day. Finally, I decide to venture into building my own binary RPM starting with the .spec file based on the source RPM (consoling myself that there was always the possibility of self-improvement). Now RPM is a widely used package management system that came out of RedHat. Of course, as one may expect, some of the subtleties are not obvious (duh! that's why they're subtle..yes, yes) {like the "remember that your java source file should have the same name as the class it contains" ... double duh!}. Things like these seem obvious to those in the know but are quite frustrating to débutante practitioners of the art of modular coffee.

So I finally manage to construct the RPM. Of course, I've already installed Apache the hard way. Next up, Tomcat. There's an RPM (hurrah!) and the default installation works. Except for the documentation, which refers to non-existent scripts and versions older than the one I have. Bah! Then the big step, getting the two to work together (for those who are interested in the technical details: get Tomcat to serve JSPs and servlets and leave Apache to manage all static HTML). This has surely been attempted by several people out there, yet documentation is sparse, varied, and laden with conflict. As the sun sets, my enthusiasm for this new exciting[sic] technology has hit new lows. With everything going XML, our friends in the Apache forge have decided to hop onto the wagon. This is scary, at best, and horrifying at worst. Remember how Apache got its name? Well, (officially) out of respect for the Apache tribe. The popular story involves "A PAtCHy server" based on existing code and some 'patch' files. Clearly the foundation is one of cure and fixes and not of prevention. I'm sure the innards of the new XML-ized modular avatars of software emanating from the foundation are still as patchy as they used to be. The modular front is just that -- a front. To be fair, some of the software is really cool (like ant, which is an XML camp dude's simplified version of a Makefile -- with semantic tagging and all that sugary stuff that gets people all up these days). But there's too much of pushing XML where complexity can escalade.I finally abandoned my attempts at getting the [step]children of the Apache Foundation to talk to each other and decided to go ahead with just the feline teenager.

Next up, deploying a J2EE web archive (known in the Java-intoxicated community as a WAR -- Web ARchive -- get it?. This again (sigh!) was easier said than done. All the documentation told me I was doing the right thing, but the software refused. And after all, the software is always right, not the documentation {I'm patenting this line ... no takers please!}. So I go about the old low-level way of moving files over and on to my next task: getting the stuff to work. Yes, I am now doing my best impression of Sisyphus. So the documentation on the "official" sites didn't help much. If the provided sample application flunks, what more can a poor guy like me do? Finally, a friendly tip and a pointer to a book helped! The wonders of indirection.

I'm probably being over-critical about Java -- but it's the hype that gets my goat (bleat bleat!). For all its claims at solving problems in software development and allowing developers and corporates to focus on business logic instead of code. Well, Java brought in added baggage: a new way of coding and thinking. And a lot (and I stress that: a lot) of Java programmers have a background like mine: imperative programming (C) and hacky modular coding (C++). Few among the crowd would invest time in "unlearning" their ways or adapting an alternative route to understand Java better and use it appropriately and to their advantage. The result: a storm of buzz words and code that's worse than the C/C++ code slew that Java aims to quell. There's a lot of cool stuff happening in the OO world and a lot of it is in Java. But it's happening too fast. The "smart" suits are extracting new lingo and the "smart" technical jeans are getting some more meat in their sandwich, but learning never got onto the boat. Sayonara education. Lay out the red carpet for some coffee: it's strong and we're out of milk and sugar.