Sunday, August 14, 2011

Planet Eclipse Is Misrepresenting Me


Unfortunately the wrong feed URL for my Wordpress blog was fed into Planet Eclipse and so the following posts are not mine, even though they seem to have my name on them.
  • Robert Konigsberg: Senior Software Engineer
  • Robert Konigsberg: Cure for the itch
  • Robert Konigsberg: Java Developers (ALL LEVELS) San Antonio TX
  • Robert Konigsberg: 2 Fast thrice Furious
  • Robert Konigsberg: Eclipse CREDENTIAL_ERROR
The Eclipse bug around which all of this has been based has been updated with a request to correct the feed.

Thanks to Lars Vogel for pointing this out.

Saturday, June 25, 2011

WordPress: a three month experiment

I'm starting a three month experiment of using WordPress solely for blogging.

I still like Blogger's platform, but also the few times I've worked with WordPress I've really liked what it had to offer. So now's just as good a time as any to give it a three month trial.

I will not be updating this blog during this time. You can follow me at I've already put up my first post, which talks a little bit about using the things I discovered while getting started.

Thursday, May 26, 2011

Mac Word of the Day

I want to see if using Electric Sheep as my screen saver is the cause of recent OSX workstation lock-ups. So I scanned the available screen savers and settled on Word of the Day screen saver.

The first thing it published was:

polynomial: Mathematics of, relating to, or denoting a polynomial or polynomials. 

Yeah, that was useful. Thanks. I'll stick with dog photos.

Sunday, May 22, 2011

Tales of Pirx The Pilot

I learned about Stanislaw Lem in 1992 when a friend made a gift of The Cyberiad to me. He has become my favorite author ever since. I own all of his books translated to English, and one in Polish.

That isn't to say I've read all those books, save the untranslated one. No, there are several which remained unread or partially read over the last 20 years. Two of these are the series Tales of Pirx the Pilot, and More Tales of Pirx the Pilot. Though years back I read the first story in the series, The Test, a fantastic story that demonstrates a skill Lem excels at but rarely uses, that of slowly-building dramatic tension followed by a shocking and logical twist. Even  while re-reading The Test this past week for the second time in fifteen years, even knowing how the story ended, I couldn't help but forget everything but what was going on at that moment in the story, and still felt a genuine sense of shock by the revelation of the story's unspoken conceit. The only other time I experienced this sense of being drawn in, hooked on every single word, despite knowing how the story ends, is the story-within-a-story in Fiasco.

But now I've moved on to the second story in Tales, titled The Conditioned Reflex and it's delicious in the more standard way for him to write, which is his ability to describe fake science. Here Pirx is borrowing a space suit from the Russia's lunar station.
The Russian suit was unconventional in a number of ways. For one thing it had three, instead of two, visors: one for high Sun, one for low, and one - shaded dark orange - for dust. The air-valve arrangement was different, and it was rigged with inflatable boots that cushioned the impact of rocks and gripped even the slipperiest surface; they called it the "high-mountain model." Even the coloring was different: half in black and half in silver. When you stood with the black side facing the Sun, you broke out in a sweat; with the silver you were braced by a delicious coolness.

Pirx found the idea had one basic flaw in it: a man couldn't always be pointed in the direction of the Sun. So what was he supposed to do? Walk backward?

The others chuckled and called his attention to a color alternator located on his chest. If he adjusted the knob, the colors could be reversed: black in front, silver in back, and vice versa. The mechanics of it were interesting. The suit's outer ply was made of a clear, tear-resistant nylon fabric; between it and his body was a thin air barrier filled with two different kinds of dye, or rather semiliquid substances - one aluminized, the other carbonized...
Lem's view of space travel speaks to me more than the Roddenbery/Star Trek/space fantasy view. Space travel is inconvenient, difficult, a product of good and bad engineering, and can often fail because of small problems compounding on each other. From a favorite story of mine, The Seventh Voyage from The Star Diaries:
It was on a Monday, April second - I was cruising in the vicinity of Betelgeuse - when a meteor no larger than a lima bean pierced the hull, shattered the drive regulator and part of the rudder, as a result of which the rocket lost all maneuverability. I put on my spacesuit, went outside and tried to fix the mechanism, but found I couldn't possibly attach the spare rudder - which I'd had the foresight to bring along - without the help of another man. The constructors had foolishly designed the rocket in such a way, that it took one person to hold the head of the bolt in place with a wrench, and another to tighten the nut.
In the end, Lem's stories human failings and not technical ones, and typically that comes down to hubris - failure of the overconfident, the smart and foolish. A good dose of humility is your best asset in Lem's world, even when you're alone, in a damaged rocket, tearing out of control toward the Moon.


Thursday, April 28, 2011

PSE&G, Your Laziness Is A Liability

Dear PSE&G,

Thank you again for coming out in early November to repair the rotting gas line. To accomplish this you had to dig a deep hole, about three feet deep if I recall correctly. I was told the night of the repairs by your team on-site that someone would come fill that hole within that week. Nobody came. My wife has called you repeatedly. We've been given a variety of responses mostly between "We will dispatch somebody" to "It's not our problem" to "It's not our department". Whatever. It's April, and this is a safety issue. It's been six months. Fill the damn hole.

I'm pleased to show you pictures of your incomplete work.

Here's the strong piece of wood covering the hole. Look at those fun toys that kids can play with near by.

Look at that -- the whole pit is filled with water! Perfect for getting a quick jump on mosquito season.

Tuesday, April 26, 2011

Dygraphs Bugs and the Start of Automated Javascript Testing

Short version:

Someone contributed wrote a bunch of code to Dygraphs. It broke an existing behavior, but also inadvertently (or advertently)   fixed another one that was broken before his patch was submitted. The new broken behavior was more of a problem than the old broken behavior, so Nealie provided a fix which restored the old broken behavior. And then I went ahead and did a bunch of tests. And as always, patches are welcome!

Long version:

Nealie submitted a rather comprehensive patch to Dygraphs that changed the way zooming events behaved. Here's the use case that he inadvertently broke:
  • Open
  • Use the mouse to zoom in on a graph along both the X and Y axes.
  • Perform an unzoom by clicking the “Unzoom” button. This effectively calls g.updateOptions({dateRange: null, valueWindow: null})
  • Expected behavior: both the original x and y ranges are restored.
  • Actual behavior: Only the x-axis range is restored.
Now, here’s the use case that was broken before his patch, and subsequently fixed:
  • Open
  • Use the mouse to zoom in on a graph along both the X and Y axes.
  • Make the following call from a javascript console: g.updateOptions({})
  • Expected behavior: this should effectively be a no-op.
  • Actual behavior: The y-axis restores to the original range.
In other words, Nealie’s patch made g.updateOptions({}) work just fine, while breaking g.updateOptions({dateRange: null, valueWindow: null});

I figured this out by basically looking at a series of commits and checkout then out at different times along the main code path. You can see my work here. If you read that document, you’ll notice that when performing the same zoom operations via g.updateOptions({…}), neither bug appears. It’s only when a zoom is performed via mouse operations.

Much of this could have been avoided if we had automated tests. Fortunately, I’m working on that, and in fact an initial attempt at them is now in a pull request. It uses the js-test-driver framework. If we had these automated tests in place beforehand, then it might be safe to say that neither bug would have made it in to the main branch.

For instance, here’s a simple test that verifies that verifies calls to updateOptions should do what I expect:

RangeTestCase.prototype.testRangeSetOperations = function() {
  var graph = document.getElementById("graph");
  var g = new Dygraph(graph, ZERO_TO_FIFTY, { });
  assertEquals([10, 20], g.xAxisRange());
  assertEquals([0, 55], g.yAxisRange(0));

  g.updateOptions({ dateWindow : [ 12, 18 ] });
  assertEquals([12, 18], g.xAxisRange());
  assertEquals([0, 55], g.yAxisRange(0));

  g.updateOptions({ valueRange : [ 10, 40 ] });
  assertEquals([12, 18], g.xAxisRange());
  assertEquals([10, 40], g.yAxisRange(0));

  g.updateOptions({  });
  assertEquals([12, 18], g.xAxisRange());
  assertEquals([10, 40], g.yAxisRange(0));

  g.updateOptions({ dateWindow : null, valueRange : null });
  assertEquals([10, 20], g.xAxisRange());
  assertEquals([0, 55], g.yAxisRange(0));

To be fair, that test doesn’t really test the use cases above, where the mouse operations are the cause of broken behavior. I haven’t written those tests yet, but here’s one I did write, which verifies the behavior of a mouse double-click:

RangeTestCase.prototype.testDoubleClick = function() {
  var graph = document.getElementById("graph");
  var g = new Dygraph(graph, ZERO_TO_FIFTY, { });

  assertEquals([10, 20], g.xAxisRange());
  assertEquals([0, 55], g.yAxisRange(0));

  g.updateOptions({ dateWindow : [ 12, 18 ] });
  g.updateOptions({ valueRange : [ 10, 40 ] });
  assertEquals([12, 18], g.xAxisRange());
  assertEquals([10, 40], g.yAxisRange(0));

  var evt = document.createEvent('MouseEvents');
     'dblclick', true, true, document.defaultView,
     2, 0, 0, 0, 0
     0, false, false, false, false, 0, null);
  assertEquals([10, 20], g.xAxisRange());
  assertEquals([0, 55], g.yAxisRange(0));

You get the idea.

If you read those tests carefully, you would probably have four criticisms:
  1. Accessing to the private attribute canvas_ should be discouraged.
  2. All those magic numbers used for initializing the event.
  3. Having to actually dispatch the event via the DOM.
  4. Questioning browser compatibility - what browsers would that work on?
Here are my answers:
  1. Yes, you’re right. That should be fixed.
  2. Yes, you’re right. That should read like DygraphTestUtils.dispatchDoubleClick(g);
  3. You’re right about that one also. Right now the API doesn’t quite make that possible, but it could be worked on if necessary. (Psst … patches welcome!)
  4. Yeah, I have no idea if that would work on anything other than Chrome. One thing at a time.
Finally, just what will we do about this behavior? Here's what I think:

First, I think we should accept Nealie's bug fix. Second, figure out why and how the both cases can be fixed. Third, get some comprehensive automated tests in place, make the tests easy to write and the framework easy to run. Fourth, and probably most important, change the submission guidelines to require a) automated tests to be run as part of the patch submission process and b) require new tests to be part of patches of a certain level of complexity.