What's it all about, Alfie?

I came in today to see a problem in one of my apps that uses the plist parsing in CKit for preferences - much like the old Mac OS X plist files. I did this because I really liked them, and they afforded me a great deal of flexibility in the setting of the parameters for this application. But there was a problem. I hadn't found it because up to this point I edited the file and then reloaded the file into the app. But if the app wrote out the file and then tried to reload it, there was a problem.

The problem today was that I looked at the plist file and it had clearly been changed. Yet they probably hadn't changed it. What probably happened was that the app itself had written it out and then failed to read it back in properly. There was another interesting complication in the works that lead me to believe that it was the writing part and that was a feature I had put into the code from the beginning.

If I had a section of the plist that looked like this:

    backup = {
        interval_mins = 5;
        filename = "../logs/<hostname>/backup.dat";
    }

then the same could would write out:

    backup = {
        filename = ../logs/<hostname>/backup.dat; interval_mins = 5;
    }

and there's a good reason for it. First, the quotation marks are gone because it's obviously a string and there's nothing that needs escaping in the string. Secondly, for maps with less than three elements, I decided to place them all on a line so that things like points and lines are more easily visualized. What happened then was the bug.

The bug was in the reading of the converted plist. Specifically, it wasn't looking at the semi-colon as the terminator for the value on the first key/value pair. In fact, it was only looking at the line-endings as terminations and that was meaning that the filename had the semi-colon as well as the second key/value pair. That's not going to work.

The solution was simple - recognize that the semi-colon was the terminator and everything worked perfectly. Simple fix, but finding it took longer than I expected.

The guys working on MacVim have released Snapshot 40 with an impressive list of updates:

• Fix problems with Quickstart "leaking" Vim processes
• 'imdisable' now on by default (i.e. IM is disabled by default)
• Clipboard support in non-GUI mode (Kent Sibilev)
• New document icons, more filetype associations (Nico Weber)
• Add support for 'guitabtooltip' (hint: add the line "set gtl=%t gtt=%F" to your .gvimrc to make tabs display the name of the file and have the tooltip display the full path) (Jonathon Mah)
• Look for toolbar icons in runtime path (plugins such as TVO now display toolbar icons properly)
• Show dialog when clicking to close tab with modified buffers
• Update documentation
• Latest Vim source code and runtime files

Still the best cross-platform editor I've ever used.

I was thinking about the current state of web development - where it's used well, where it's not, and what people are trying to force it to do, and it lead me to giggle as I realized that George Santayana could as easily have been talking about computer developers:

Those who don't learn from history are doomed to repeat it.

I guess the extension is more on point:

Those who don't study what was written are doomed to rewrite it.

The Web 2.0 craze is trying to take a great static-content system and make it interactive. Why? Because the client footprint is so small and you can collect hardware in a central location for easier support and maintenance. Again, we have the re-birth of the mainframe/centralized computer resources. Just now they are called clusters and web server as opposed to AS/400 or IBM mainframes.

It's funny, because each time I think about the goal of the Web 2.0 I come to the same place X11 was over a decade ago - a way to have an interactive experience on the client machine while having the processing done on heavy iron at a remote location. Why not drop Web 2.0 and just do X11 again? I'm convinced that it's because the developers doing this never learned what the old X11 was all about and why it was created.

OK, X11 didn't have a lot of pretty graphics by today's standards, but it was designed to be a remote application delivery platform and optimized for that. Give it better graphics like a decent widget set on all machines and all of a sudden you don't need all the interactivity of the Google Docs - you can run it locally and get just the display in the native widget set.

The other extreme is to take the AJAX and build it up to the point that it also includes a widget set on the client end - much like Firefox, et. al. has done with it's markup. It gives you a complete widget set on the client-side (just like X11) and then a way to communicate with the back-end. I'm amazed at the similarities between these two. But one has 20+ years of development and the other is "cool and new".

Before you spend time to write something that you think is clearly so unique that it's never been done before, stop and think. Ask. I'm willing to bet that a lot of the ideas that are so "new" are really just re-inventions.

Learn from the past.

I put a few finishing touches on the multi-scatter graph today. It was pretty much done, but I wanted to give it the ability to read the initial selections for the x-axis column as well as any y-axis columns from the applet PARAM tags. With that, the developers that asked for this can pretty much put together everything they need.

The new applet PARAM tags are pretty simple:

• defaultXAxis - this is the name of the column that is the initial selection for the x-axis.
• defaultYAxis - this is the encoded string of a Vector of Strings that are the column names to be placed on the y-axis initially.

where the encoded string is the output of the call:

  Vector    v = new Vector();
  ...
  String    str = BKTable.generateCodeFromValues(v);

where the Vector v is populated with the names of the columns to place on the graph.

I have to say it looks good and works well. I've handed it off to the developers that want to use it and supplied them with an example HTML file where it's used.

Probably the nicest graphing package for Mac OS X - DataGraph, was updated to v1.6.2 today. He added a lot of nice features - templates, assistants for the date/time formats, pop-up widgets for the selection of values like line width, etc. It's a nice little update. I still like the fact that if you register for $30 (or something like that) you can incorporate his graphing frameworks into your own apps. My idea was to use this as the basis of a lot of simulation graphing. I haven't gotten around to it yet - as much by the time as for the fact that he still doesn't support the types of graphs I need - 3D mapped to 2D. Contour, heat, those kids of graphs.

Still doesn't make this any less nice of a package. Excellent.

Amazingly, BBEdit 9.1 had just the feature I was hoping it'd add - stripping white space at the end of lines. I do that a lot - even have a macro for it, but now I don't have to. Just set it up in the Text Files preferences pane and every time you save, it's going to strip those nasty trailing whitespace characters.

The release notes have a lot more - like a new font: Consolas Regular. It's remarkably like my current favorite: Panic Sans from the guys at Panic who distributed it with Coda, their all-in-one web development app. It's clean, clear, and the only difference I can see is that the point sizes are a little different. Consolas 10pt is Panis Sans 9pt. That's it.

Yet there's even more. BBEdit 9.1 has a much improved FTP/SFTP interface that is supposed to be much faster than the previous version. Excellent. RCS keywords are handled better - it's amazing, really. The list goes on and on. It's still my favorite editor on the Mac.

UPDATE: I've been looking at the new Consolas font and how it differs from Panic Sans... it's got more white space above and below the line. More even, than the same point size in Panic Sans. Meaning that if Consolas 10pt is the same horizontal size as Panic Sans 9pt it's got more vertical room than Panis Sans 10pt. That's very interesting. More whitespace in between the lines may make this more readable while making the horizonal compression able to get more columns in the same real-estate. Interesting.

Well, I heard in this article that in JDK/JRE 1.6.0_12 and beyond, Sun is going to be delivering a 64-bit Java plugin. Finally. I've been waiting for a long time for this, and while I have to say it's not going to impact me that much as I don't do a lot of web/applet-based development any more, it's nice to know it's there should I ever get back to it.

Now all we need to see is a pre-packaged Firefox for Linux that's 64-bit.

A few days ago (late last week) a couple of developers stopped by my cube to ask me if the BKit graphs had anything like a multi-select scatter graph where the data points were grouped into data sets and then they could be overlaid on top of one another to build up a more complex graph.

Well... the answer was clearly "No", and they didn't think so, but we got to thinking about how you could do it with the existing tools, and I got to thinking how to do it with the TwoDimCrossScatterViewer. So, I started work on the new graph as they started working on the different data structures to make it work with the existing scatter graph and the pseudo z-axis capabilities.

The first thing I knew I needed was to get the TwoDimCrossScatterViewer working without the lines. That was simple enough. But then it was on to the coloring of the data points and labels. This was a very tricky thing.

The breakthrough was finding the Status producer in the docs. The default way of associating a Status object with the data is row-dominant - meaning that a complete row has a single Status object for rendering. I needed to change that to column-based, and this little code did exactly what I needed:

    /**
     * We need to create (and use) a StatusProducer that looks at
     * the columns of the graph for a Status. If we didn't do this,
     * we'd be looking at a row at a time and that's not what
     * we're after.
     */
    AbstractStatusProducer statusProd = new DimensionalStatusProducer(DataSet.diCol);
    _graph.getData().setStatusProducer(statusProd);

with this, I could then set the Status flags for a column. Well, that's good, but all the code I have in place now assumed it's row-based. Well... time for a significant expansion of the code to allow for the testing of the kind of graph we're working with and then to switch to either "by row" or "by column" way of looking at things.

With all that, we have a pretty decent first-cut at the multi-scatter graph:

There are still things I need to do tomorrow - like a lot of testing to make sure that my changes haven't messed up another graph. But I think I'm pretty close to what the guys were looking for.

This afternoon a couple of developers stopped by trying to do something in the graphs I've built on VantagePoint, and I'll admit - it wasn't going to be easy. Basically, they wanted a multi-variable scatter graph - just like the TwoDimCrossScatterViewer, but with all the GUI widgets to make it easy to use by the target audience.

The first step was to be able to easily control the visibility of the lines on the x-y graph, because if I could do that, then I could easily build on that and just use it in the "no lines" mode and be ready to go. But in order to do that, I needed to have a clean way to turn on and off the lines in all pairs, and a pair at a time.

What I came up with was the simple applet PARAM tag showxylines. If that guy is true, then the graph will show the lines, if it's false, then it won't. If it's missing, then they will be shown, by default. The neat addition to that was to add the PARAM tag showxylines:columnName and if that's true, the lines with that column in their definition will be shown, and not otherwise. This makes it very easy to turn all lines off and then some select few on, or vice versa.

This doesn't mean I'm done, but it's a great stepping-stone. From here, I need to add in the GUI widgets to control the graph, make sure the lines are "off", and then put it all together. Not trivial, but I've done this several times and it's not as hard as all that.

The BKBaseGraphApplet can read the data it uses to put on the graphs from the applet PARAM tags a row at a time... or a complete table... or even as a part of the supportData table. This guy was meant for data that didn't make sense to put into the main data table, but was needed to support the proper graphing of the data.

Think colors of scatter points... mouse-over labels... that kind of stuff. More "style data" and not as much "numeric data". But today I realized that the parsing of the supportData and the augmenting of it to the primary data was not working properly.

I had made changes to allow the parsing of a complete table of data, in addition to the row-at-a-time method. But when I did that, I didn't follow-through with all the implications. For instance, the way the code was originally written, it was possible to leave out the primary data table completely, and then pull in parts of the supportData table as the "plotting" (aka primary) data.

In fact, it was possible to augment that as well. Very flexible, and nice, but by putting in the table parsing of the primary source, I broke it. (Well, to be brutally honest, another developer had a crack at it and I just cleaned up what he had written) So... I needed to go back in and clean it all up. Restore all the functionality I had intended to put in there.

The first step was to realize that the easiest way to resolve this was not to have the semi-merge code in the applet... Nope, that's a waste. I have the BKTable's merge() method, all I really needed to do was to put a filter on the supportData table - letting through only the columns the user wanted to merge into the primary data table, and then do the merge(). It was far simpler, and removed a ton of code from the BKBaseGraphApplet's class that was strikingly similar to the BKTable's code, and it was implemented better in the table's class.

Then I had to make sure that all different possibilities worked. No table, some table, etc. This way I could be sure that it was going to work.

In the end, it worked like a charm. The mouse-over is coming from the supportData table, and it's merging in the data exactly as it should. Perfect.