What's it all about, Alfie?

Today is going to be one of those days that I remember for a long time. Probably the rest of my life. I can imagine what my parents must have felt listening to JFK talking about the Peace Corps, and the Space Race, and the Berlin Airlift... I even have to give it to Regan that for those that were interested in his message, he had a way of making a speech.

But Obama is going to change how we feel about America. He's going to change the sense that it's run by people that think they know what's good for us, when all along we fear that they're doing what's good for them. I am excited about what this will bring. The change is due. We need to have a better moral compass than Gitmo and torture - we need to understand that there are costs to living in a free society, and just because some nutcases flew planes into buildings doesn't mean we have to give up any of the liberties this country was founded upon.

I looked at Intrade this morning and at 9:43 am it's got Obama at 92.4. Excellent. I can't wait to leave early and cast my vote. I really can't.

This morning I saw that MacTelnet 4.0 was out, and while I'd never heard of it, I wanted to give it a look-see, to see if there has been anything I've missed. I'm always on the look-out for a Terminal.app replacement. I'd settle for getting rid of the scroll bars, but that's not in the cards - at least not today.

Anyway, the MacTelnet 4.0 screen is pretty standard, but there's a border around the screen that is a little annoying. You can't get rid of the scroll bars, and there's no anti-aliasing of the text or manually setting the horizontal and vertical spacing. All these are in Terminal.app and iTerm. Seems that MacTelnet is going for a different audience.

I will say that I like that it's got TEK 4014 graphics. I spent a while in grad school creating a TEK 4014 terminal emulator only to see that VersaTerm on the Mac was far better, and did everything I needed. Still, there appears to be a different audience for this app than the iTerm/Terminal.app crowd. This seems to be for the larger font size, more GUI-based guys. Full screen seems nicely supported, but I'd never use that. Extensibility with Python is nice, but I'd never use that either.

So I'm interested to see where they are taking this, but for now, Terminal.app is still the winner, and iTerm a close second. We'll have to see what MacTelnet evolves into.

Several weeks ago, a developer asked me if it would be possible to expand the functionality of the secondary Y axis on the BKSimpleLineGraphApplet such that when the secondary Y axis was visible, a new pick-list of columns appeared at the top of the widget. This second pick-list would mimic the original but be tied to the secondary Y axis, such that the user could select whatever they wanted to see on the secondary Y axis. This ended up spawning an entire set of issues with VantagePoint and the problems that it's had with the secondary Y axis in version 4.6.6.

While I'm waiting for Gordon to get back to me on the status of that final fix, I wanted to clean things up and check everything in, given that it appears to be working, and the only test is when we get a fixed version of VantagePoint.

So it's built, checked in and ready to go, and should work fine if it's used against version 4.6.4 (but that would require a recompile as the constants have changed).

UPDATE: I recompiled BKit against VantagePoint 4.6.4 to see how it looked and found that the same error exists there! So it doesn't matter if we use 4.6.4 or 4.6.6 - they both have the 'modulo 2' bug and I need to have a fix from Gordon for that. Good to know, sad to see. So I re-built it against 4.6.6 build 209 and that's what the developers can use until we get a fix.

UPDATE: I got an email response from Gordon saying that the next scheduled release of VantagePoint is 11/11/08 - one week from today. He said that this bug would be corrected in this release, and asked if that was soon enough for me. I told him that was fine, I can wait a week for the fix. It's good to know that it's fixed, and when we'll be getting the update.

This morning I was clearing the decks as it were and trying to see if I could get the feature requested several weeks ago into CVS. The feature really started out as a bug report - the developer said that when the axes on a graph changed, the zoom should reset and show all the data regardless of the zoom that was in effect. I pointed out that many times the axes change is not a contextual change, as he implied, but a drilling for detail where the zoom represented the filtering of the dataset and the change in axes was the drilling for detail.

We agreed that it should be an option.

So I worked on the code and got it working. However, additional other graphing requests came in and they piled on top of the zoom reset code, and then they stalled because of the bugs I've found in the secondary axis for VantagePoint. This morning I decided to unwind these changes and commit the zoom reset and give it to the developer that asked for it.

So now it's done.

The way to activate it is to have a simple applet PARAM tag:

    <param name="zoomoutongraphchange" value="true"> 

and if this is in the applet tag, the graph will reset the zoom on any axes change. If it's 'false' or missing, then the default behavior is to respect the zoom level on the axes change.

I'm glad to get this out, and then isolate the changes still awaiting the fixes from VantagePoint.

This morning I read an email from a developer asking me if it would be possible to extend the functionality of the pseudo z-axis on the BKSimpleScatterGraph to allow for the pre-selection of certain values so that if these values were on an applet tag, then only those values would be selected on the initial view of the graph. After that, the graph would function normally, allowing them to show more, or less, as they wished.

The key to this was to be able to easily encode a list (Vector) of objects on a single applet PARAM tag. Since I'd already done something like this for the CKit Variant list, it seemed reasonable to extend it and then make it easy for the user to generate the encoded value and easy for me to decode it.

The format for the encoding of the list is pretty simple:

  ;value_1;value_2;...;value_n;

where each of the value_i is an encoded value itself. This allows for lists of lists and list of tables, etc. For this particular instance, it's going to be z-axis values, specifically, String values, and the encoding for a string is simply: S:value. So the encoded list of some strings looks like:

  ;S:one;S:two;S:three;

would be the Java Vector with string values 'one', 'two', and 'three' in it. Simple.

But I wanted to make it even easier for the developers. So easy that they don't have to know the encoding scheme. That's where the refactoring work on the BKTable comes into play. With this, it's as easy as saying:

  Vector  v = new Vector();
  v.add("one");
  v.add("two");
  v.add("three");
 
  String  encoded = BKTable.generateCodeFromValues(v);

and then put encoded as the VALUE part of the PARAM tag. The NAME is going to be 'zvisible' and we're off to the races! On the applet side of things a simple call:

  Vector  v = BKTable.parseVectorFromCode(code);

gets me the Vector back from the code previously generated. Not bad at all.

When I put all this into the code, there were just a few little loose ends to clean up. Where would this list be read, and how would it default the graph? It took me an hour or so to wire it all up, but the hard part of refactoring the BKTable's encoding and decoding was done and it was pretty fast work after that. In the end, we have a wonderful way to pre-select the z-axis values on a SimpleScatterGraph. Not bad.

Today I spent a few hours refactoring the encoding and decoding on the BKTable because I wanted to achieve two things, neither of which was a pressing need for the BKTable: First, to allow the inclusion of the Vector as an elemental data type in the contents of a table's cell, and two: to expose the encoding and decoding of the Vector (Array) so that the CKit-based tables and Lists will match up nicely. The genesis of this is really to be able to have an applet PARAM tag take a Vector so that it's easy for a person to generate that tag (using the encoding of a Vector), and it's easy for me to decode it.

What this ended up doing was to really overhaul the serialization methods for the BKTable and make them look a lot more like their CKit counterparts. The finding of an appropriate delimiter is important to the table, but it's also important to the list. So the old way of having it embedded into the table's encode was just not the right thing to do. Likewise, the way in which individual values were both encoded and decoded was too restrictive for what I needed.

In the end, it was a few hours that gave me some very interesting code snippets. The most interesting, was the thread-safe, thread-local SimpleDateFormat. The Date, as an element in the table needed to be able to be decoded and encoded. But the SimpleDateFormat is not thread-safe, so what's to be done? The old code had a new one created for each encoding and decoding. The new one uses the code below:

  /**
   * In order to make the formatting of Date values efficient,
   * I want to make a class that's going to handle the formatting
   * in a thread-safe way using thread-local storage. The idea is
   * that each thread will create it's own formatter, and then
   * there won't be need for a bunch of them, and there won't be
   * problems with excessive garbage collection.
   */
  class SafeDateFormatter {
    private static ThreadLocal formatter = new ThreadLocal() {
      protected synchronized Object initialValue() {
        return new SimpleDateFormat("yyyyMMdd.hhmmss");
      }
    };
 
    public static String format(Date arg) {
      return ((SimpleDateFormat) formatter.get()).format(arg);
    }
 
    public static Date parse(String arg) {
      return ((SimpleDateFormat) formatter.get()).parse(arg,
            new ParsePosition(0));
    }
  }

with this little jewel, the incoming thread will create a thread-local copy of the SimpleDateFormatter with the default formatter provided. Then, each call after that will use the one and not create another. This is something I can see that they might not have wanted to do, but I can't imagine how much garbage collection I would have had were I to blindly create one each time one was needed. Yikes.

When I got all this done I created a few more tests, and like a champ, they worked perfectly. I was very happy. But all this did was really set the stage for the changes to the BKSimpleScatterGraphApplet - the ability to pre-select the z-axis values from an applet tag.