Way of the Retainer

I have a confession to make. I’m a huge data geek. I love data. It’s one of the things that’s kept me in IT. I love games like HeroClix and World of WarCraft because they are delicious soups of raw information, leading in the case of WoW to sites like Thottbot.com. In fact, a lot of the time I like the raw potential of these games more than sinking time into playing them. (time, it must be said, is clearly the most precious resource here)

One of the reasons why I work in integration is that integration is primarily about getting data from A to B. It’s like saying you like water, so yes please, I will wrap my mouth around a fire hose to enjoy the torrent of information ensuing.

Part of being a data geek is also being a huge geek for representation of data. The denser your data, the more of a challenge it is to present that information in a compelling and transparent way. Recently I splashed out on Edward Tufte’s works, which I’m going through presently.

The point of all of this is that Google recently released a charting API. Charting’s always been something you could do manually, or programmatically if you were willing to go through some onerous (for my money) Apache configuration, but now you can do it with a simple URL.

Here’s the Google Chart API documentation, as well. Y’know. Could be handy.

This one popped up courtesy of Lifehacker Australia, which is a really great extension to the Lifehacker family and well worth reading. I’m addicted to productivity porn.

On a side note: Generated charts are limited to 50,000 views per day. I’m pretty confident I’m not in danger here, but to add some value I’ll follow this up soon with a PHP script that caches the result of a generated page (using the URL to determine uniqueness, given that all the information is in there) and serves up the cached image instead.

No Comments »

I recently had need to verify the precision of the Java VM’s timing precision on various platforms. We were doing some rough benchmarking of ALBPM and ALSB, and needed to measure how long individual processing steps were taking. We got some results that seemed flakey from log4j messages, hence arriving at wondering about JVM timing precision.

I found a simple and elegant solution at YIP Chi Lap’s HK University site. One of those solutions you smack yourself in the head (or *facepalm*, if you roll with the IM kids) for not thinking of yourself. The Java application goes into a tight loop, printing the difference between the current time in milliseconds and the starting time that the app gets before going into a tight loop. It’s pretty short, so here’s the code:


public class TimerTest
{
  public static void main(String[] args)
  {
    long base=System.currentTimeMillis();
    for (int r=0; r<1000; ++r)
    {
      System.out.print(System.currentTimeMillis()-base);
      System.out.print(' ');
     }
  }
}


Because no solution is complete without shell scripting, I ran the output through uniq after modifying the .print statement to a .println. That made the output a little clearer.

To make the solution a one stop shop, I’ve created a slightly modified version of the Java class which only outputs unique timing results (essentially doing the job of uniq) It’s a small modification, but it makes the output less chatty and more manageable. Definitely a class that’s going in my tool belt.

No Comments »