Main

May 4, 2006

Two Examples

I'm sure this has been articulated elsewhere in the past, but just wanted to scribble it down while it was in my head:

All expositions of new or complex technologies should be accompanied by at least two examples from disjoint domains.

Technologies are not ends in and of themselves; they are tools which we use to solve domain-specific problems. But when an explanation of a previously-unfamiliar technology focuses on a single example, it's way too likely that the reader will forever associate the technology with the domain of the example. This hinders a full grasp of the extent and benefits of the technology, and can prevent new adopters from seeing creative and innovative uses of the technology outside of the domain.

We often learn best by example, but it's important not to let a single example typecast a technology within a particular domain. Two (or more) equally developed examples helps ameliorate this danger and showcases the technology itself rather than the example's domain.

Posted by Lee Feigenbaum at 11:41 AM |

April 17, 2006

AJAX callback function signatures in prototype

In the wake of using the Yahoo! User Interface Library to wrap AJAX1 requests for the SPARQL calendar demo, I decided to try out the Prototype JavaScript framework for my latest round of (unrelated) web hacking.

Very early on, I was struck by an incongruency between the callback signatures of the onSuccess, onFailure, and on### events and those of the onLoading, onLoaded, onComplete, etc. events. Event handlers for the former collection of events—which only occur after a request is completed—receive two arguments: the XMLHttpRequest object itself, and, if applicable, a JavaScript object formed by parsing the JSON serialized value of any X-JSON response header.

On the other hand, event handlers for the latter set of events (events that correspond to ready-state changes), receive the above two arguments and in addition receive the Ajax.Request wrapper object that was used in the creation of the AJAX request. In turn, this object gives access to the options dictionary, which can contain arbitrary bits of state useful in routing callbacks to their eventual final destination(s).

Why don't the other callbacks contain the Ajax.Request objects? Got me. Maybe for compatibility with some other (unknown) API? In any case, I hacked around this in my application by duplicating the functionality from prototype.js that translates generic onComplete events into specific onSuccess and onFailure events: 

  ...
  onComplete: function(request, xhr, xjson) {
    if (request.responseIsSuccess())
      this._onSuccess(request, xhr, xjson);
    else
      this._onFailure(request, xhr, xjson);
  },
  ...
_onSuccess and _onFailure act just as regular ol' onSuccess and onFailure would, except that they now have access to the original Ajax.Request object. Good enough for me, but curious nonetheless.

1 AJAX sure has used its snazzy-name status to propel a not-so-novel idea to stratospheric levels of buzzwordiness. The lack of a consistent capitalization for it (AJAX vs. Ajax) bugs the heck out of me though. Of course, it really should be AJaX, but I doubt that will ever catch on. Alas.

Posted by Lee Feigenbaum at 12:39 AM |

January 1, 2006

Happy New Year, the *nix Way

They just think of everything, don't they?

hcs:~ 21>factors 2006

CORRECT>factor 2006 (y|n|e|a)? yes
2006: 2 17 59
hcs:~ 22>uname
Linux
hcs:~ 23>

But not always consistently:

bantha:~ 55>factor 2006

CORRECT>gfactor 2006 (y|n|e|a)? yes
2006: 2 17 59
bantha:~ 56>uname
NetBSD
bantha:~ 57>

Posted by Lee Feigenbaum at 5:39 PM |