What's it all about, Alfie?

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.

Today a developer using BKit chatted me asking if it would be possible to add some simple arithmetic operations to the BKTable. Basically, adding, subtracting, multiplying and dividing the values in the table by simple external values without having to pull out the Object, get it's double value, do the math, create a new Double, and place it back in the table.

It seemed like a very reasonable suggestion. After all, because of the JEP parser, we had the ability to add complete tables, it only makes sense that we do the same for the contents of the individual cells in the table. Problem was, I didn't want to reproduce the code for the arithmetic operations themselves as I'd already written that once. I wanted to leverage that without making the code overly complex and include a JEP parser for each operation.

Thankfully, that wasn't necessary. The way JEP is structured, the operations are classes. I have sub-classed their Add, Subtract, Multiply, and Divide classes to make BKAdd, BKSubtract, BKMultiply, and BKDivide already to make the complex operations in the JEP parser work. Again, luck was on my side in that each of these had simple methods to really do the heavy lifing.

BKAdd used add(), BKSubtract used sub(), and so on. This meant that as long as the BKTable had an instance of BKAdd, it could add. So I make transient ivar of a BKAdd, BKSubtract, and so on to the class so they wouldn't be shipped around the universe, and then sent to work making the methods.

It was somewhat tedious work because I wanted to have forms that would take either integer or String indexing into the table - that's standard for the BKTable, and also have a version that took the generic Object, but also one that took a double for those times when it's just a bunch of numbers, and you don't need the added complexity.

Because it's possible to have nulls in the table before the operations happen, I took the logical stance that a null was the same as a zero for these operations. So, adding a number to a null gives you that something. Multiplying something by a null gives you the null - simple, but important, I think, if you're doing this to minimize the hassles of dealing with Objects when you want primitive values.

Took a while, but it was really nice to see it work. The ability to modify the individual cells in a BKTable now is really nice. It is going to make some of the work done with BKTables a lot cleaner.

I've been using VantagePoint for quite a while, and a few weeks ago I sent in a few questions to the technical contact I've been using in the past and got an automated reply that he'd left the company, and all further requests need to go to Gordon, whom I've come to believe is the lead developer on VantagePoint. So I forwarded my questions to Gordon.

A few days later, I got a reply from 'Dawn' saying that we appeared to be in arrears on the maintenance agreement to the tune of some $20k+, and we needed to come current with that, and answer a few questions about our usage of VantagePoint, and then she'd allow the technical support guy (Gordon) to answer my questions.

Well... it took a while because the maintenance bills were sent to the paying agency, which, for a hedge fund, isn't always the same as the hedge fund. So, that's why we haven't been getting them. There were a few harsh words, until 'Dawn' figured out what was happening, and that this was a good way for them to get $9k/yr for doing essentially nothing, and things got back on track.

Gordon has been helping me since things got cleared away, but this morning I was just looking at a recent reply he sent me and I noticed that he cc:'ed a Dawn McKeever - at McKeever Financial. I had to look them up.

I've suspected that there was a management shake-up at Visualize Inc, because of the way they treated us, but I didn't suspect them to get bought out by an accounting company. Holy Cow! The web site for McKeever Financial isn't nearly as professionally done as the one for Visualize Inc. While that doesn't mean they didn't have the money, and that Visualize Inc wasn't in trouble.

It's just that when one of the owners is doing the Accounts Receivable, you know it's a small shop. And when it's an accounting firm, you know their priority is not going to be a high-performance Java graphing/visualization package. So chances are, the company got into trouble, and as an added asset, they included the software and it's users as part of the deal. But the guy had to go back to what he was more "billable" at, and now the support for VantagePoint is part-time on evenings and weekends.

It's just too bad. I really liked the package. It had a lot of promise, and yet I know it's only a matter of time before it's stale and dies of neglect. If they had just given up and given the users the code in escrow, then we'd be able to do something with it. But they didn't. Shucks.

Today I got an email from the Pragmatic Programmers about two books: Core Data and Core Animation, and after thinking about it for a few minutes and looking at excerpts from the books, I decided to get them both. The Core Data is a "beta book" meaning it's not really done, but it will be, and the Core Animation book is finalized and in print.

I really like the books these guys put together - very easy to read as PDFs with Preview on my Mac, and with updates I don't have to worry about errata. Also, there's no way I can carry around the tonnage of books that I have for reference, etc. It's just not possible. But I can carry all that and more on my laptop.

While I haven't started reading these books, the one I read on Git is excellent, and I highly recommend it. I'm not sure exactly what I'm going to do with Core Data or Animation, but I know that the few things I have been thinking about require both: simulations and market tools. So... we'll see how these pan out, but I'm betting on "great".

I've been using the betas and release candidates of JDK 1.6.0 for several months now as it's the only version that allows me to properly run one of my apps in Java WebStart and have the graphing applets I've written work in web pages. It's been a know issue for Sun for a long time, and 1.6.0_10 has been in "beta" and then "release candidate" for a long time - I mean months. So it was nice to see yesterday that they finally released it.

I got the Windows and Linux versions and put them on my machines. It's where I need the WebStart and applet stability that this version gives me. Why they called it '10' when the last one I remember was '7', I don't know. I'm guessing a different group of guys was working on this from the main-line code, and it's taken so long because in addition to their features and fixes, they had to merge back in all the changes to the main JDK branch.

In any case, I'm sure it'll be a while before it shows up on Software Update... Apple is not the early adopter of JDK releases, they go through a lot of work when they get a new one, and that's OK with me. Mac OS X is a great java development platform, and the applet support was (and is) great without the need for JDK 1.6.0_10. But I'll bet that we see it. If not soon, then in Snow Leopard due out in January.

I was just thinking of how nice it'd be to get rid of the scroll bars on my Terminal.app windows, and it got me thinking about iTerm. I wondered if there was an update - so I ran it and sure enough, iTerm 0.9.6.1021 is out, and it fixed quite a few little things:

Version 0.9.6.1021 includes the following changes:

• Fixed a bug that cause crashes when using vim.
• 256 Color palette support (patch provided by Walter Dorwald).
• Improved URL handling for ssh/ftp/telnet.
• iTerm no longer sends a growl alert for a bell event if the winodw is the key window.
• Highlight window when it's in the "send input to all tab" mode.
• Better handling of "fork" errors.
• The anti-idle is no longer sent to all tabs when "send input to all tabs" is on.
• Other minor UI changes and bug fixes.

While I'm not sure it's still the complete replacement for Terminal.app, it's great to see that they haven't given up on it.

I heard back from my tech support contact at Visualize Inc. about an update to VantagePoint to bring it to 4.6.6 build 209 to fix the problem I'd been having displaying a Variable from a TwoDimDataSet on a secondary Y axis. It was a few weeks ago that I first saw this bug - it was brought to my attention by another developer. The bug only appeared in ver. 4.6.6 - as it was working fine in 4.6.4. So I emailed them, and while it took a while for other reasons, Gordon kept me updated on the status of this, and got me something working today.

Unfortunately, it's still got that weird bug where trying to plot Variable(i) ends up plotting Variable(i mod 2) no matter what the value of i. He said that bug would likely still be there, and after my tests, I informed him that, indeed, it was still there. Fair enough, he's going to work on that and get back to me.

For now, I've got one bug down, and another in the wings. As soon as that guy is fixed, I'll be able to give something to the developer that originally pointed out the problem to me.

I noticed this morning that DataGraph had been updated to 1.6.1.1 with several bug fixes regarding the inclusion of multiple y-axes on the same plot. Since I love to play with DataGraph, I decided to get the update for the app and the Framework - who knows, maybe I'll get around to playing more with it today and checking out the differences.