What's it all about, Alfie?

This morning when I'm trying to get things done, Comcast is at it again! They take down the cable model, maybe reconfigure it, and then it's up for a minute, and then down again. In all, I probably had it less than 5% of the time this morning. Annoying, to say the least.

I know that they are supposed to be coming out with a new 50Mbps service this month to much of ChicagoLand, but from reading the press releases, it sounds like it's not going to get to the western suburbs until 2009 - which is fine. I'm not sure it's worth another $70/month for 50 Mbps/10 Mbps - but it's close.

Anyway, I wish they would not do the maintenance at 3:30 - 4:00 am... that's when I need it.

I've heard it was coming out any day now, but it's great that today is that day. There are the assorted bug fixes and security updates, but 10.5.6 is also probably the last update before we see 10.6 (Snow Leopard) in the beginning of next year. Maybe not, but it's going to have some neat new things, and I'm super excited about updating.

If only Comcast had been up this morning. Grrr... I'll have to wait until later today to update.

[10:44] UPDATE: I finally found the time to update to 10.5.6. Glad I did. Now I just need to get rid of my hiccups and I'll be golden.

This morning I noticed that Perian 1.1.3 is out and available within Perian for update. With this release they have put in a few more decoders added more sanity checks for some of the streams, and even reduced the memory footprint.

This is just a great way to be able to view a lot more diverse content in QuickTime. GOtta love that.

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.

Today I spent several hours trying to figure out why loading a collection of windows was exhibiting different behavior than loading the windows individually. Basically, I use a visualization system that was written and maintained by another company (a vendor) and it's pretty decent - and terribly complex. There is a way to load a window with multiple views, and a way to load a collection of windows.

Unfortunately, the collection of windows wasn't loading properly. I'd get the first window up just fine, and then the second window would appear to start loading but then all the views from the second window would get sent to the first window. Very odd.

Reverse the loading order and things are reversed. Everything seems to want to go into one window - regardless of which one that is - save it's the first one loaded.

So I wrote an email and sent the window definitions to the vendor's support contacts. I'm not sure what's going to come of it, but it's a bug, and recently introduced, as this used to work. We'll see what they come back with.

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.

Last night, I had a mix-up with my daughter's basketball practice schedule - I was sent to the wrong school by my wife. I realized that I needed to put the schedule into iCal, and once there, there should be no reason I couldn't publish it and let her have a look. Even if she didn't, there was value for me in learning how to publish iCal calendars.

I knew the publishing is over WebDAV, and so I started looking for public WebDAV servers that would host this content for me. I have been disappointed that HostMonster doesn't have WebDAV support - but I decided to send them an email this morning just in case they may have recently added it.

[UPDATE: no they do not have any plans to support it.]

I also looked at a site called Box that said it was WebDAV, but I think that's been pulled and it's a less-general web-based file sharing system now. Shucks.

I ended up seeing iCal Exchange a lot, and it turns out that's an incredibly easy way to do it. They have public and private calendars, and it's got adds if you look at the calendars online, but it just works if you don't.

I ended up getting an account, and then publishing the calendar from within iCal to the base URL of: http://icalx.com/public/drbobbeaty/ - this, they tell you right on your account page at iCal Exchange. Very slick.

Once it's published, you can subscribe to the calendars by using the URL: webcal://icalx.com/public/drbobbeaty/nameOfCalendar.ics - it's pretty much idiot-proof. You can even make it a link on a page so that people don't need to know how to type the URL. That's not anything new about URLs, but it's a nice thing about the integration of iCal into Mac OS X.

So I ended up publishing the calendars for our volleyball team, the Rampage and Angelina's basketball team, the Comets. If I update the calendar in my iCal, it pushes these changes to the server, and each subscribed iCal picks it up. Sweet.

This morning I happened to try Transmit to get to a WebDAV server I was looking at, and I noticed that an update was out. This update fixes a few things with improving performance and the ability to deal with large files on Amazon's S3 storage. Also improved performance on a few things. Not bad.

I have to admit, it's not my favorite FTP Client, but it's very good.

I got a call from a recruiter the other day telling me about a position that was open in a smaller prop (proprietary) trading firm here in the city. This place is small. Less than 20 people in all of IT, and less than a third of that developers. That's small.

But it's bigger than Port-to-Port, my old place. Maybe it's time to head back down to the smaller shops? It got me to thinking.

Certainly the big downsides of a smaller shop would be the job security and the pay. Chances are, they are not going to pay as well, and they have a far greater risk of folding than a multi-national bank with 65,000 employees. But there are a lot of upside there too.

If I got along with the folks (a requirement, to be sure), then the place would be far more accommodating about change. Maybe they'd be willing to look at different platforms, or at least more willing to look at different ideas and ways of doing things. I'm no fool... there's politics everywhere, and coming into a small shop means you have to make sure you like the people there, because that's simply all the people there are. No way to walk to another floor and chat with an old friend - the place doesn't take up two floors.

But if you get along with the people, you are more closely tied to the things that happening in the shop. Decisions about platform and process are going to be a lot more out in the open, and because of the small size, there's going to be less tolerance for the "process as a work product" as opposed to just getting things done. Given the last 8 months here, that is a very attractive possibility.

But in the end, I don't have to move. It might be nice, and if something really stupendous comes along, then great. But if not, that's OK too. I'm not in a horrible place, and I believe I'll know if it's the right time and right opportunity to take.

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.