Have you ever wanted to check your tomcat instance without going through mod_jk? Would you like to know if a server problem is caused by your servlet engine or your connector? If you answered "whaaa???" to either of those questions, then the answer is no. If you're still reading this post, then we offer this handy troubleshooting device: ajping

ajping relies on Time::HiRes and Socket. It sends "\x12\x34\x00\x01\x0a" to the server and checks for "\0x41\0x42\0x00\0x01\0x09" in response. For an explanation of that exchance, check out the AJP protocol page.

Script: ajping

JoeDog::Stats (tarball - zip) was updated to version 1.15. This version adds support for the geometric mean in arrays and hash tables. 

The Geometric Mean of a set of n positive numbers is the nth root of the product of n numbers. There are two main uses of the Geometric Mean: (1) to average indexes or (2) determine the average percent increase of a series of numbers from one time to another. JoeDog::Stats performs the first function. If you require the latter, let us know.

The Geometric Mean is calculated as follows:

        ________________
GM = \n/ (x1)(x2)...(xn)

To illustrate the geometric mean consider the following example. If Joe's Bar and Whorehouse made annual profits of 3, 2, 4 and 6% over a period of four years, what is the geometric mean profit?

        __________
GM = \4/(3)(2)(4)(6)
        ______
   = \4/ 144

   = 3.46

This is slightly less than the artimetic mean which is 3.75. In the example above, Joe had a disproportionately good fourth year that skews his average. The Geometric Mean, therefore, provides a better description of a typical year's profits. The Geometric mean is not as weighted by extreme measures. Because of this, it provides a better indicator or typical experience. It is a good stat to describe positively skewed data such as network performance measures.

Who's more like Hitler, Bush or Obama? Is Glenn Beck more like a spent condom or Jesus Christ? The Internets love to argue. One of the more contentious debates is Windows vs. Linux. Now, your blogger clearly favors Linux for numerous reasons. First and foremost is stability. "Oh, Windows is just as stable" he's heard Microsoft bigots claim. Really? Well if you're on life support which OS do you want to manage the controls?

"Release early, release often." - Eric Raymond

Most successful open source projects rely on the RERO development model. Frequent releases provide developers with a steady stream of customer feedback which allows them to shape a product to fit the needs of those who use it. Open source projects tend to evolve as a community of customers and developers form around them. 

Eric Raymond proposed this model in 1997 when open source was still playing catch up to commerical software. Does it still make sense? 

Frequent releases seem to improve security as bug fixes and security patches move quickly to end users. In the 1990s, somebody with too much time on their hands discovered you could crash most devices by sending them large ICMP packets, the dreaded ping of death. Within two hours, the Linux kernel team provided a fix. Their commercial counterparts needed days, weeks and, in the case of Microsoft, months to provide users with a fix. The ability to get fixes in the hands of users quickly is without question a Good Thing. But what about RE part of RERO? What about early releases?

I've encountered too many open source projects that were, frankly, a waste of my time. Unless it's designated as a developer's relase, a 1.0 software project should meet a minimum set of standards:

• It should do what you say it will do. If your project is a plug proxy, then release 1.0 should act as a plug proxy. Users understand it might not do IP filtering or load balancing but, dammit!, it ought to serve as a plug proxy. 
  
• It should have a help section. The first thing somebody does when they see a new binary is pass it a -h/--help option to understand its behavior. You can add this option in less than an hour. Users will forgive your 1.0 version for lack of a man page but you better provide a help section.
  
• It should rely on GNU autotools. Yes, autotools sucks but users are conditioned to run ./configure, make and make install. Again, there are plenty of open source projects from which you can steal a configure.in and a Makefile.am. Feel free to steal them from mine.
  
• If it's a daemon, then it should write a PID file to a configurable location. If your project is going to be successful, then you'll need to add this at some point. Why not add it to release 1.0?
• If it's a daemon, then it should reload its configuration with kill -HUP. It's no longer 1997. The internet is filled with open source software. There are plenty of examples of this implementation. Find one and steal the code.