TECHHEAD Development Blog

Google Voice Click-to-call Widget

2009-04-27T17:34:00.000-07:00

I'll keep this short. I was lucky enough to get in on the Google Voice closed beta (back when it was Grand Central). It offers a free click-to-call widget that you can embed in your web pages. But it didn't offer quite enough "pizzaz" for my taste, so I enhanced it a bit using some Javascript. I'm making the code freely available. (It should be an interesting read.)

It works in IE 6 through 8 as well as Firefox 3 and Safari 3. I didn't test it in anything else. To see it in action, use one of the aforementioned browsers and go to http://techhead.biz.

Feel free to use it, improve it, etc. As always, a little credit here would be appreciated. If you do use it, please leave a comment here and drop a link so I can find you.

DOMContentLoaded and ondocumentready and onreadystatechange! Oh my!

2009-04-23T15:30:00.000-07:00

How do you determine when your document is ready to be manipulated by the javascript in your web application? In the course of a recent project, I discovered that the answer is perhaps not so simple as the question. In fact, the conclusion I've come to is that "it depends".

The most elegant solution I've come across (in my opinion) is the DOMContentLoaded event. This event has been hidden in Mozilla browsers since I don't know when (???) but has now been adopted in recent versions of WebKit and Opera as well. As the name suggests, this event fires when the document tree (DOM) is completely loaded. This may fire before images and other external objects are loaded. The only problem is that IE 6, 7 and 8 don't support it, so there goes the market share. The rest of this article is about various "hacks" which attempt to emulate this behavior in IE.

The current most popular workaround (and newest I believe) is a "hack" discovered by Diego Perini. It is based on the ondocumentready event that is available only to Behaviors in IE. Diego discovered a paragraph in an MSDN document and ran with it.

A few methods, such as doScroll, require the primary document to be completely loaded. If these methods are part of an initialization function, they should be handled when the ondocumentready event fires.

Taking the reverse of this statement, Diego tried polling doScroll until there were no more errors as a means to achieve a "poor man's" ondocumentready. And guess what? It works! ...Sort of. If the loading document's window is not top level (ie. if in an iframe), doScroll never errors and the hack falls apart.

// Should return true only if the document is ready, false otherwise
// Works unless in an IFRAME
function documentready() {
  try {
    window.doScroll('top');
    return true;
  } catch (e) {
    return false;
  }
}

function init() {
}

// Poll until documentready
(function() {
  if (documentready()) return init();
  setTimeout(arguments.callee, 0);
})();

Another popular method of DOMContentLoaded emulation in IE is the deferred SCRIPT method made popular by Dean Edwards.

function firedomload() {
}

// A deferred, external script is executed after the DOM is available in IE.
// I know of no formal specification for this behavior.
// However, it appears consistent across IE 6 through 8.
// MUST use a document.write to emit the SCRIPT (if being placed dynamically)
//   or readyState never reaches 'complete'.
//   (I don't know why, but that's just the way it is.)
document.write('<' + 'SCRIPT src="//:" defer><' + '/SCRIPT>');
var script = document.documentElement.lastChild.lastChild;
script.onreadystatechange = function() {
  if (this.readyState == 'complete') {
    this.onreadystatechange = null;
    this.parentNode.removeChild(this);
    firedomload();
  }
};

The problem with this method is, of course, is that it requires a call to document.write which will obliterate the current document if called too late.

Dean also shows us how to take advantage of the ondocumentready event directly, but this method requires an external HTC Behavior file, making it less friendly for inclusion within libraries.

Lastly is the most obvious option. Place a script after all of the content in the BODY of your document and use it to bootstrap the initialization calls.

<html>
<head>
<script type="text/javascript">
if (typeof ondomload == 'undefined') ondomload = [];
ondomload.push(function() {
  alert('This will execute on DOM load');
});
</script>
</head>
<body>
... some content ...
<script src="firedomload.js"></script>
</body>
</html>

And the firedomload.js script looks like this...

/**
 * This SCRIPT should be placed just before the close of the BODY element
 * in your (X)HTML document. It may be deferred.
 *
 * Scripts that take advantage of 'ondomload' may come before or after
 * this SCRIPT and may be either deferred or not deferred.
 *
 * USAGE:
 * if (typeof ondomload == 'undefined') ondomload = [];
 * ondomload.push(function() {
 *   alert('This will execute on DOM load');
 * });
 */
if (typeof ondomload == 'undefined') {
  ondomload = {};
} else {
  while (ondomload.length)
    setTimeout(ondomload.shift(), 0);
}
ondomload.push = function(cb) { return cb() };

In summary, each method has its pros and cons. Even the library authors can't agree on what is best. At the time of this writing, jQuery uses the doScroll method and Prototype uses the deferred SCRIPT method. I've written a small function using the deferred SCRIPT method. You can find it here. The source code for the tests is also available here. And there is a live test here.

What you use may depend on your needs.

Running IE6, IE7 and IE8 on your Mac (reloaded)

2009-04-13T16:23:00.000-07:00

The original article is here: http://blog.mozmonkey.com/2008/vpc-ie6-ie7-ie8-on-mac-os-x/

I came across the above article a while ago when looking for a good way to test my web sites in Internet Explorer without having to resort to using a PC. Microsoft releases Virtual PC images of Windows containing various versions of the Internet Explorer web browser. These expire and are re-released periodically. At the time of this writing, they are about to expire again. I do hope that Microsoft will continue this valuable service. (It's the least they can do.) You can download the images here: http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF

If you are using Windows, then you may download the free Virtual PC from Microsoft. Otherwise, download the free, open source VirtualBox. At the time of the article noted above, it was necessary to first convert the Virtual PC images before they could be used on VirtualBox. This is no longer the case.

The Virtual PC images available from Microsoft come packed in self-expanding archive files. This is a small problem if on a Mac. You cannot run the self expander, but I find that the free Stuffit Expander works fine to extract the image file.

Once you set up your virtual machine, Windows will boot, show you the EULA and attempt (and fail) to install a bunch of "new hardware". Just skip past all of this and then choose "Devices -> Install Guest Additions..." from the menu bar. This allows better integration with your system. It also makes folder sharing with your Mac possible.

Of all those hardware installation dialogs you clicked past earlier, one of them was to install a network device. Without this, you can't access the internet. At the time of this writing, VirtualBox emulates an AMD PCnet-FAST III NIC by default. You will need to download the driver for it here. Then you'll need to setup a shared folder and put the driver in it so that you may install the driver from Windows.

If you're a more visual person, just watch the video here (or inline below).

Google App Engine is available for Java developers

2009-04-09T14:40:00.000-07:00

I'm sure that you've heard the news by now, but I couldn't let it pass without a comment. Hooray!

I am a Java developer. That is to say, Java is the language I have done most of my development in over the past 10 years. But my interest lately has been less in Java actual and more in the JVM and all the Groovy new languages you can get to run on it.

That's why I'm particularly excited that the App Engine will support such alternate languages. I was lucky enough be get in on the developer preview, so you can expect to see me posting more on this topic in the new few weeks.

Stay tuned.

Prototype-based programming in Javascript (part 2)

2009-04-04T02:06:00.000-07:00

This is part 2 of the subject. For a primer on prototype-based inheritance in Javascript, see the previous article.

Javascript is a prototype-based language, but sometimes it pretends not to be. Constructors, types, the new and instanceof operators -- these are all an additional layer built on top of the core model. And they make it a little difficult to tell what is really going on... So we're going to take them out of the picture. Here's a summary of the last article in SpiderMonkey Javascript.

// Prototype inheritance
A = { foo: true }; // new A
B = {}; // new B
B.__proto__ = A; // If a property is not found in B, look in A
alert(B.foo); // true
B.foo = false;
alert(A.foo); // still true

// the 'new' operator can be reproduced in SpiderMonkey Javascript
function nuevo (constructor) {
  var newObject = {}; // new object with its own properties
  newObject.constructor = constructor; // this is the new object 'type'
  newObject.__proto__ = constructor.prototype; // desired prototype obtained here
  // call the constructor on the newly created object
  constructor.apply(newObject, Array.prototype.slice.call(arguments, 1));
  return newObject;
}

Ok, so now that you know how prototype inheritance works, lets make it a little easier to use. There are already many good libraries that make "classical" or class-based inheritance easier in Javascript. (My favorite is the simple one provided by John Resig on his blog.) But I'm not yet aware (I'm sure you'll help me here) of any that make prototype-based programming simpler. Douglas Crockford, Javascript god, has a simple function posted on his site. We'll start with that.

Object.create = function (o) {
  function F() {}
  F.prototype = o;
  return new F();
};

You should know by now what this is doing. The constructor function F is necessary because there is no universal way to set a prototype chain directly, other than specifying it on a constructor. The type F is a throwaway. You don't need it anymore. You won't be using the new operator, and the instanceof operator makes no sense for pure prototype-based programming anyway. (Instead, you would use the Object.prototype.isPrototypeOf method found on every object.)

Using Crockford's function, our first code example now looks like this.

// Prototype inheritance
A = { foo: true }; // new A
B = Object.create(A); // new B

Pretty simple, and it's almost all you need. But I find that in practice, some additional features are useful. Here's a first iteration of my version.

var Proto = {

  __proto__: Object.prototype,

  clone: function(init) {
    var Clone = function(init) {
      this.__proto__ = Clone.prototype;
      this.constructor = Clone;
      if (init) this.assign(init);
    }
    Clone.prototype = this;
    return new Clone(init);
  },
  
  assign: function(props) {
    for (var key in props) {
      var value = props[key];
      if (this[key] != value)
        this[key] = value;
    }
    return this;
  }
  
}

There's not a whole lot of difference between my own and Crockford's here besides naming, but there are some significant things going on. For one, Crockford attaches his function as a property of the Object constructor. This makes perfect sense, unless you consider that the whole reason he scrapped his first iteration (in which the function was simply named object) was that "globals are clearly problematic". But you actually have all the same problems (namespace issues, etc) here.

On another of his iterations, he attached the method begetObject to the Object.prototype. The problem here is that adding anything to Object.prototype will cause it to be inherited by every single object in the global namespace, whether or not it's actually part of your program. I made a compromise and added my clone method to the prototype of the Proto object. So only objects which inherit from Proto will be affected. Of course, there are still no guarantees that other code in the global namespace will not interact with the name Proto, but you can name this whatever you will (eg. biz$techhead$Proto if you like).

Another thing you'll notice about my "improvements" is that I explicitly set the __proto__ property of the new object. The __proto__ property really only means anything in Mozilla's Javascript, and I simply set it to what it was already. The reason I set it is because it is a useful relationship to preserve, and now I have read access to it even in Internet Explorer. I also set the constructor property for the sake of correctness.

Lastly, you'll notice that I added an optional initializer to assign properties to the newly constructed object. This is merely a shortcut.

But I'm not quite done. For one, it is useful on occasion, even when using prototypes, to be able to call a method on a super prototype. A naive attempt and its correction is shown below.

A a = Proto.clone({
  create: function(name) { return this.clone({ name: name }) }
});

B b = A.clone({
  create: function(name, gender) {
    // this may look right at first glance
    // but will quite often end up in an endless loop
    // see if you can figure out why
    // var o = this.__proto__.create.call(this, name);
    // instead, this is correct
    var o = A.create.call(this, name);
    o.gender = gender;
    return o;
  }
});

But I don't really like having to refer to the super prototype by name. If I decide to change the name from A to something else, I've got to change B also. Not a disaster but it is still annoying. So I provided a way to access the super prototype through a generic name.

A bigger issue I've found is that sometimes a prototype needs to be able to control exactly how it is "copied". Sure, it could override the clone method each time, but that is a lot of extra work for a common task, so I set up an event instead. Behold the next iteration.

var Proto = {

  __proto__: Object.prototype,

  clone: function(init) {
    var Clone = function(init) {
      this.__proto__ = Clone.prototype;
      this.constructor = Clone;
      this.onclone();
      if (init) init.call(this, this.__proto__);
    }
    Clone.prototype = this;
    return new Clone(init);
  },
  
  onclone: function() {}
  
}

Notice that on my last iteration, you could provide an object to the clone method and it would copy its properties onto the new object. In this iteration, you may provide an initialization function (much like a constructor) to set up the new object. This provides a couple of new advantages. See the example below.

Animal = Proto.clone(function() {
  this.eat = function(food) {}
  this.sleep = function() {}
  this.poop = function() {}
  this.breed = function(animal) {}
});

Human = Animal.clone(function(_super) {
  var ate = [];  // now I get a new private scope
  this.eat = function(betterfood) {
    _super.eat.call(this, betterfood); // can use _super instead of Animal
    // do something else
    ate.push(betterfood);
    // sorry about the lame example
  }
});

So, with the latest and greatest iteration, I get access to a _super keyword and the ability to easily add private members to an object. But wait! The private member ate is now shared by all humankind. This is probably not what the programmer had in mind. Instead, this probably was...

Human = Animal.clone(function(_super) {
  var init = function() {
    var ate = [];  // now I get a new private scope
    this.eat = function(betterfood) {
      _super.eat.call(this, betterfood);
      ate.push(betterfood);
    };
  };
  this.onclone = function() {
    _super.onclone.call(this);
    init();
  };
  init();
});

Now each Human keeps his own menu to himself. But that's a lot of extra typing for something that should be simple, so I'll add one last bit of magic...

/**
 * The prototype of all objects in this small
 * prototype framework.
 */
var biz$techhead$Proto = {

  __proto__: Object.prototype,

  /**
   * Clone this object and (optionally) invoke an initializer.
   * Should NOT be overriden.
   * Override 'onclone' instead.
   */
  clone: function(init) {
    var Clone = function(init) {
      this.__proto__ = Clone.prototype;
      this.constructor = Clone;
      this.onclone();
      if (init) {
        if (init instanceof Function)
          this.init(init);
        else
          this.assign(init);
      }
    }
    Clone.prototype = this;
    return new Clone(init);
  },
  
  /**
   * This event fires on the new child of this object
   * whenever 'clone' is called.
   * It is analagous to a constructor.
   */
  onclone: function() {},
  
  /**
   * Invokes an initializer function on this object.
   * It supplies this object's super prototype as the
   * first argument, and provides an optional second
   * argument to those initializers that declare
   * two or more parameters. The second argument is a
   * function that will install the initializer 'onclone'
   * when invoked.
   */
  init: function(init) {
    var _this = this,
        _super = this.__proto__;
    if (init.length > 1) {
      init.call(this, _super,
        function() {
          var hasonclone = _this.hasOwnProperty('onclone'),
              onclone = _this.onclone;
          _this.onclone = function() {
            var _this = this;
            var f = hasonclone ?
              function() { onclone.call(_this) } :
              function() { _super.onclone.call(_this) };
            init.call(this, _super, f);
          };
        });
    } else {
      init.call(this, _super);
    }
  },

  /**
   * Shallow copies the given properties onto this object,
   * excluding those already owned by this object
   * (eg. those inherited through Object.prototype).
   */
  assign: function(props) {
    for (var key in props) {
      var value = props[key];
      if (this[key] != value)
        this[key] = value;
    }
    return this;
  }
  
}

I just added a bit of sugar that allows you to set the 'onclone' event handler to the initializer in one step. Now the following is possible.

Human = Animal.clone(function(_super, install) {

  install(); // This initializer method will run 'onclone' also.
             // install() will automagically be replaced with a call
             // to _super.onclone when called from the 'onclone' event
  var ate = [];
  this.eat = function(betterfood) {
    _super.eat.call(this, betterfood);
    ate.push(betterfood);
  }
});

You can find the "finished" framework here. I hope you enjoyed this journey as much as I did. Please comment, and let me know your thoughts on prototype-based program design.

Prototype-based programming in Javascript

2009-04-03T15:55:00.000-07:00

You may have heard that Javascript is a prototype-based programming language, but chances are that you've never used it that way -- not really. Maybe that's because prototype-based programming is kind of... well... different.

Now, I must admit that I think prototype-based programming makes sense to me, but I haven't ever actually used it in a project. (Until now.) In fact, you might be hard pressed to find any projects in which this programming model is being used, and I am curious to know why. Is it because it is awkward, or is it a hidden gem?

My interest is both academic and practical, in the sense that I love to explore programming language methodologies but I also actually write code. It seems, other than Javascript, the prototype model exists largely in academia. You'll hear a lot about Self, a Smalltalk derivative, but I am unaware of any projects actually written in Self. My favorite example of a prototype-based programming language is Io -- in which I have never written a single line of code. But its documentation helps to illustrate the point. I will translate one such example into how Javascript would look if it were more straightforwardly prototypal (and then we'll work on making it so).

Account = Object.clone();
Account.balance = 0;
Account.deposit = function(amount) {
  this.balance += amount;
}

account = Account.clone();
account.deposit(10.00);
alert(account.balance);

In the above example, notice that there are no classes nor constructors. Account is an object. It has a balance. You can even call the deposit method to change that balance. But the Account object was not likely created to be used directly. Instead it is intended to be more of a rubber stamp, a model which can be cloned.

And under the hood, Javascript works this way too. The confusion comes largely from the adhoc type system that is built on top of the prototype model. Take away the new and instanceof operators and using prototype inheritance in Javascript might be more straightforward. (I am not suggesting this, however. I love the flexibility that Javascript provides.)

The previous Javascript example does not work, of course. There is no Object.clone() method. But that is essentially what the new operator does. (More on that later.) In SpiderMonkey Javascript (Mozilla's implementation), the above code could be rewritten as:

Account = {
  balance: 0,
  deposit: function(amount) {
    this.balance += amount;
  }
}
Account.__proto__ = Object.prototype; // Object itself is a constructor,
                                      // not an 'instance'

account = {};
account.__proto__ = Account;
account.deposit(10.00);
alert(account.balance);

And this more clearly shows what is actually going on and the relationship between objects in prototype-based models. Account defines two properties, balance and deposit, but it also declares that it inherits properties from Object.prototype by setting Account.__proto__ = Object.prototype. Thus if you attempt to access a property that does not exist for Account, Object.prototype will also be searched. However, it is important to remember that each object has its own properties (or slots). In the above example, setting account.balance = 1000 does not change Account.balance. This is a good thing.

It is worth mentioning also that in some major Javascript implementations (most notably IE), you cannot set an object's prototype chain directly as we did in the prior example. It must be set on object "construction".

Constructors are the adhoc type system of which I spoke earlier. They are nothing more than simple initializer functions, but they also are responsible for setting the prototype chain by way of their prototype property. As always, code speaks louder than words. Below is what the new operator might look like in SpiderMonkey.

function neww (constructor) {
  var newObject = {}; // new object with its own properties
  newObject.constructor = constructor; // this is the new object 'type'
  newObject.__proto__ = constructor.prototype; // desired prototype obtained here
  // call the constructor on the newly created object
  constructor.apply(newObject, Array.prototype.slice.call(arguments, 1));
  return newObject;
}

function FauxAccountClass() {
}
FauxAccountClass.prototype = Account;

account = neww(FauxAccountClass);
// or, same thing...
account = new FauxAccountClass();

alert(account instanceof FauxAccountClass); // will alert 'true'

Please let me know if something is not clear. To summarize, a constructor is simply a function. The prototype property of that function (eg. FauxAccountClass.prototype) decides what the "parent" object of the new object will be. Constructors are the basis of the Javascript type system. However, if you "forget" about constructors and the operators designed to work with them, you still have Javascript ...and an entirely different way of using it. That's where I'm going to take you next. But this article is already quite long, so I'll continue in a follow-up post.

The follow up is now online here: http://devblog.techhead.biz/2009/04/prototype-based-programming-in_04.html

Dynamically load external Javascript in a cross-browser way

2009-04-02T23:05:00.000-07:00

If you've done any significant Javascript development, I'm sure that you've run into the need to dynamically include an external javascript library. There are many existing libraries that will do this for you quite easily. But what if you are not able to take advantage of such a library? What if that library is precisely the javascript you wish to dynamically load?

Hmm. In that case you can use the following code snippet to bootstrap the process.

function loadScript(src, callback) {
  var head = document.getElementsByTagName('head')[0];
  var script = document.createElement('script');
  var loaded = false;
  script.setAttribute('src', src);
  script.onload = script.onreadystatechange = function() {
    if (!loaded && (!this.readyState || this.readyState == 'complete'
                                     || this.readyState == 'loaded') ) {
      loaded = true;
      callback();
      script.onload = script.onreadystatechange = null;
      head.removeChild(script);
    }
  }
  head.appendChild(script);
}

For example, here's how I used it to bootstrap jQuery in a bookmarklet I wrote.

(function() {

function loadScript(src, callback) {
  var head = document.getElementsByTagName('head')[0];
  var script = document.createElement('script');
  var loaded = false;
  script.setAttribute('src', src);
  script.onload = script.onreadystatechange = function() {
    if (!loaded && (!this.readyState || this.readyState == 'complete'
                                     || this.readyState == 'loaded') ) {
      loaded = true;
      callback();
      script.onload = script.onreadystatechange = null;
      head.removeChild(script);
    }
  }
  head.appendChild(script);
}

function withJQuery(cb) {
  loadScript('http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js',
    function() {
      cb(jQuery.noConflict(true));
    }
  );
}

withJQuery(function($) {
  // do something with jQuery
});

})();

Notice that the above code adds nothing to the global namespace. The code is localized within an anonymous function and jQuery.noConflict(true) is called so that jQuery cleans up after itself and resets the $ and jQuery globals to whatever they were prior to the script being loaded. Nice, but admittedly a lot of bootstrap code.

I've been thinking a lot lately about how a robust javascript packaging system would look. But even then, a nice library wouldn't help a lot here. It would have to be part of the language, and I am not anxious for any additions to the language that have not been very well vetted.

Welcome to the shiny new TECHHEAD Development Blog

2009-04-02T22:24:00.000-07:00

The other TECHHEAD blog has existed (and been largely neglected) for some time now. However, its core audience has always been the technologically challenged, which made my occasional programming or web-development-related article all the more absurd.

But I've needed an outlet. Programming (and web development in particular) is my passion. It is my intention to share that with you here. But be forwarned; I am not a natural blogger. The necessary regularity and dedication has not yet been developed. I'd rather write code than English. So we'll see what happens. Be sure to subscribe to the feed before you go.

Simple bookmarklet for creating Amazon Affiliate links

2009-01-06T15:17:00.001-08:00

For those who don't know, a bookmarklet is just a "fancy" link that you install in your web-browser toolbar, usually by dragging it there. (In IE you must right click it, select "Add to Favorites" and then save it in the "Links" folder.) When clicked, bookmarklets do something with the currently viewed document.

Got it? Good. Moving on...

I am an Amazon Affiliate, and I wanted a simple way to create affiliate links to Amazon products. I found a very straightforward tutorial over at crazybob.org. But I'm still too lazy. I want to be able to browse Amazon.com and when I find what I am looking for, I want to be able to simply click a button to generate the appropriate HTML.

So I made the following bookmarklet:

Amazon Affiliate Link

Install it, and head over to Amazon.com to try it out. Of course, you'll want to make sure that the affiliate links it creates refer to your Amazon Associate ID and not mine.

To create your own customized bookmarklet, use this tool here.

Happy linking! And remember, tipping is easy with Tipjoy.

jQuery vs Dojo Toolkit vs Prototype vs MooTools

2008-12-31T13:15:00.000-08:00

This is a very quick, unthorough rundown of the most popular Javascript frameworks at the time, and why I currently favor jQuery.

I did not make a significant time investment in my investigation, but there were a couple of factors I was interested in:

I wanted a framework that did not include a faux class-based object framework. Javascript is prototype based and very powerful that way. (I'll write my Javascript in Javascript, thank you.)
I wanted a framework that imposed minimal littering of the current window's global namespace.
I wanted a framework that was simple to learn and easy to use.

jQuery best fit the bill. There are no false classes in jQuery; it leaves coding style up to you (not so in Prototype or MooTools). In jQuery, there is minimal littering of the global namespace -- the only exported symbols are jQuery and the optional $. (Again, this is not the case with Prototype and MooTools.) Lastly, jQuery wins hands down on ease of use. You could pick it up in five minutes if you are a seasoned web developer. The Dojo Toolkit looks promising -- I especially like its module packaging framework -- but it will require a more significant time investment than the elegant jQuery.

Here's a closing thought: I would like to see an entirely independent module packaging framework for Javascript. Anyone know of one?

I'm sure that this post will be controversial to some of you MooTools and Prototype zealots. Tell me why I'm wrong! I'd love to hear your take.

Tipjoy post-icon widget for Blogger

2008-12-27T13:38:00.001-08:00

After my last post about micropayments (and Tipjoy in particular), I had several inquiries as to how I added the "Tip 25 cents" icon below each blog entry.

It's pretty simple really. First go to http://tipjoy.com/banners/custom/ to create your custom Tipjoy button. You can then place it anywhere you want on your site and even style it with custom CSS... Or you can forget the default button and CSS and just make your own (like on flyingpizzakitty.com and this website).

My button code looks like this.

<script language="javascript" src="http://tipjoy.com/socnet/widget?username=techhead&url=blog.techhead.biz&message=Thank's%20for%20your%20support!&amount=0.25">script>

And I didn't bother copying the CSS portion because I didn't really want to show the default button. So to avoid showing the button, I wrapped the button code in...

<div style="display:none">...</div>

To add a Tipjoy icon to the bottom of each entry, I wrote a short jQuery script, so you'll need to make sure that jQuery gets loaded sometime prior to the script being executed.

Your blog may be loading jQuery already. If not, add the following to the section of your template or just directly above the icon script:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>

Once you have jQuery available, you can add a "tip reminder" icon to each blog entry by copying the below script either directly into your blog template or by adding an HTML/Javascript Page Element to your Layout.

<script type="text/javascript">
(function($) {
  $(function() {
    $('.hentry').each(function() { // for each blog entry
      var icon = $('<span><a href="javascript:tipjoyOpenLightbox()">Tip 25&#162;</a></span>');
        $('a', icon).css({
          'padding':'1px 5px 5px 22px',
          'background':'url(http://techhead.biz/tipjoy/tipjoystar.gif) no-repeat scroll 0 0'});
      $(this).find('.post-icons').append(icon); // add the Tipjoy icon
    });
  });
})(jQuery);
</script>

And that should do the trick! Of course, you may want to change the figure from "25 cents" to something else. If you do, just remember to change it in both the Tipjoy button script and in the icon script.

If you would like to place an additional tip reminder in the text of your blog post itself, here is another little formula.

<a href="http://tipjoy.com/u/myusername" onclick="if (window.tipjoyOpenLightbox) {tipjoyOpenLightbox();return false} else return true">TEXT OR IMAGE HERE</a>

Speaking of which, if you found this article helpful, please help keep the monkey playing.

Place a context-sensitive search on your website or blog

2008-07-16T20:05:00.000-07:00

Google is making it too easy for the modern web developer. I remember writing a brute-force search engine in Perl for a small web site about 11 years ago. It was slow, resource intensive, and would not scale well with a site of any size.

Skip forward a bit. Google now provides the ability to add a custom search to your site at no cost. Unless yours is for a non-profit organization, displaying ads is mandatory, but you do have the option to share in the profit (or pay to have the ads removed).

Google Custom Search is really quite flexible. You can tell it what sites to include or exclude. You can have it boost the ranking of a given number or sites or simply filter out all the sites that don't meet your criteria. Custom Search even gives you the ability to generate these rules on the fly so that results can be tailored to a particular user or a particular page of the site.

This article is not intended to be an in-depth tutorial on Custom Search. For documentation, see here: http://www.google.com/coop/docs/cse/

The definition of your search engine can either be Google hosted or you can host it yourself (This is termed a Linked CSE). For context-sensitive search, yours must be a Linked CSE.

Custom Search Engines (CSEs) are defined by a simple XML specification. This specification may be generated dynamically for interesting results. Below is a very simple example of a dynamically generated CSE which parses all of the links out of the referring page in order to include only those sites within the search results. The code snippet is written in PHP.

<?php
  header('Content-type: text/xml');
  $url = $_SERVER['QUERY_STRING'];
  if (!$url) $url = $_SERVER['HTTP_REFERER'];
  echo <<<CSE
<?xml version="1.0" encoding="UTF-8"?>
<GoogleCustomizations>
<CustomSearchEngine keywords="" language="en">
  <Title>TECHHEAD</Title>
  <Description>The search for All Things Tech</Description>
  <Context>
    <BackgroundLabels>
      <Label name="techhead_site" mode="FILTER"/>
    </BackgroundLabels>
  </Context>
</CustomSearchEngine>
CSE;
  if ($url) {
    $url = urlencode(urldecode($url));
    echo <<<CSE
<Include type="Annotations"
href="http://www.google.com/cse/tools/makeannotations?url=$url&label=techhead_site"/>
CSE;
  }
  echo <<<CSE
<Annotations>
  <Annotation about="*.techhead.biz/*">
    <Label name="techhead_site"/>
  </Annotation>
</Annotations>
</GoogleCustomizations>
CSE;
?>

Notice how certain annotations are included dynamically based on $url (which is simply the HTTP referer of the script). Annotations are for matching URL patterns with labels. The CSE is set to FILTER out any site that isn't part of "techhead_site". So the annotations define what is to be considered for inclusion in the search results.

Now we have a dynamic CSE definition. To use it, paste the appropriate HTML code snippets (http://www.google.com/coop/docs/cse/cref.html) into your web page or blog template. You will need to substitute the value of the hidden form parameter "cref" for whatever the URL to your PHP program is. For a more concrete example, simply look at the page source of this blog at http://blog.techhead.biz

For a much better Google Custom Search tutorial, see here: http://www.free-your-mind.info/ Then come back to fill in the blanks and make your search engine context-sensitive.

Building a true object-oriented system for Common Lisp

2008-07-15T15:13:00.000-07:00

While the title of this post may be seen as inflammatory, allow me to elaborate before dashing off to the comment link and turning your flamethrower loose.

As you have probably been taught, Dr. Alan Kay coined the term "object oriented" (OO). His term, his rules (Which can be found here: http://www.purl.org/stefan_ram/pub/doc_kay_oop_en). The Common Lisp Object System (CLOS) does not fit the bill to be called object oriented, although it still arrives at many of the benefits of object-oriented principle (and perhaps more -- I will expound on this later). But as Dr. Kay mentions in the above link, OO can be done in Lisp.

I have been exploring programming languages a great deal as of late. One language in particular, Erlang, has caught my attention because of its much hyped nothing-is-shared model of concurrency. Erlang accomplishes scalability by breaking tasks into many lightweight processes that communicate with each other in the form of messages. (Hmm. Where have I seen that before?) There was something very OO looking about some of the code samples I saw. Only instead of method names being "invoked" on an object, a process listens for messages of different types and those message types are represented by "atoms", which are essentially strings that contain some meaning to the program. Communication between processes in Erlang fits with Dr. Kay's requirements for an OO language (messaging, late binding, etc). It also fits the Actor model.

It can be quite confusing to distinguish between the Actor model and that of OO programming. The reason? (And this will likely be a point of some dispute.) There isn't really any difference. The term "Actor model", I believe, just had to be invented because the term "object oriented" had come to represent something other than the original meaning. OO programming has now become synonymous with stack-based models where messages are passed up and down the stack and "messages" are really just function calls conceptualized as messages. Actors on the other hand are discrete (messages and responses don't traverse a call stack) and are therefore inherently concurrent. Erlang processes and web services are good examples of the Actor model.

Now back to CL. CLOS uses multi-methods instead of message passing, so it is not strictly OO. However, as promised earlier, I'm going to stroke the CL users a little bit here and propose that perhaps the CLOS model is more appropriate to be called "object oriented" than Dr. Kay's model. Why? Because OO programming is (supposed to be) all about the encapsulation of behaviors, and objects don't do anything. But functions do.

What do you mean, "An object can't do anything"? Well, in real life, an object (I think of a rock or a piece of wood) does not do anything. A rock cannot skip itself, change its location, size, or color, or tell you any of these things about itself if you send it a message. A rock is simply a rock. If you think in procedural terms, it would be a data structure.

A data structure? Wha? I thought that "everything is an object?" OO languages assign a sort of anthropomorphic view to objects (Objects are people too) which makes perfect sense if you look at the design principles behind Smalltalk (the language Dr. Kay invented to go along with the term). One of the major design goals was to create a human interface with the machine, to allow the programmer to think in an (arguably) more human way.

Along those lines (thinking like a human), I like the term Actor better than Object because it can be explained in a way that makes sense. A rock cannot tell you anything about itself. However, an actor portraying a rock can. (I'm not a rock. I just play one on TV.) This way, everything can be an actor and the model stays coherent. There is no data, only actors that portray it. (Again, refer to Dr. Kay's letter above and where he talks about dataless programming.)

This makes sense to me as I often equate programming language models to models of the universe. But the question remains how to best model the universe. What is the essential building block of the universe? Is there one?

So what is the building block of a program? An object? And what about not only modeling what an object can do but what can be done to it? What rules? What forces apply?

Enter functions. In CLOS, a function (or group of functions called multi-methods) defines a behavior for an object. And these behaviors govern object interactions. Just as a rock has no knowledge of everything that can be done to it, the behaviors do not belong explicitly to the rock, but rather to the context in which the rock is to be used.

And this model is more coherent for "objects" (as I described them earlier). But for our anthropomorphic figures, objects that DO, it makes more sense to just ask them (as in the messaging model).

Most modern programming languages have lost coherency in their model. So when I ask what the building block of a program is, it's not simply rhetoric. The answer will, of course, vary by model, but then is it even possible to introduce a model where there is a single coherent answer? Well, of course it is possible. But perhaps a better question should be, is it practical? Is it a viable way to model our universe?

The question came to me when I realized that an object could be implemented as a function and vise versa, so it's sort of a chicken-and-egg problem.

In some languages (one of them is CL), a function may be curried with a particular parameter or live within an enclosing scope. These functions are essentially just objects as we know them. Here's a short example:

(let* ((privateVar 2)
       (methodDictionary
         `((set . ,(lambda (x) (setf privateVar x)))
           (+   . ,(lambda (x) (+ x privateVar)))
           (-   . ,(lambda (x) (- x privateVar))))))
  (defun simple-object (methodName &rest args)
    (apply (cdr (assoc methodName methodDictionary)) args)))

(simple-object '+ 2) ; equals 4
(simple-object 'set 40)
(simple-object '+ 2) ; equals 42

A whole object system can be created using such closures. In fact, that's exactly what I've done. It may not have been the most practical exercise. (I'm certainly not advocating using it over CLOS.) But for someone interested in language design, as I am, you may find it enlightening. It is prototype based, and state is kept private. You can find it here or on Wikipedia as YACLOS, so feel free to improve on the code if you are so inclined.

Beust Coding Challenge

2008-07-12T12:28:00.000-07:00

Once again I am late to the party. Cedric posted a coding challenge on his blog. It looks like Crazy Bob took the prize for most creative (and fastest) implementation. I would like to think that I could have come up with a similar solution, but then again, I also like to think that I could look like Schwarzenegger if I ever started working out.

However, Cedric posted a follow up, “Port Bob's code to your language.” Bob’s code was in Java. However, I am a Java programmer, so that sort of rules out a port. But I was able to make a few performance enhancements. Instead of a doubly linked list, I used a singly linked list and thus was able to prevent a few unnecessary assignments and eliminate a few checks. In addition, once the max has been found, I use a Throwable to unwind the stack. On my Intel MacBook, I see performance enhancements of 10-20%. The code can be found here: ModifiedBeustSequence. Or for the comparison, see here: CompareBeustSequence.

But sticking to the assignment, I did do a straight port of my modified version into Common Lisp, which I have been toying with lately (The port can be found here: beust.lisp). I’m sure that any respectable Lisp programmer could come up with a much more Lisp-like solution. If you go to the trouble, I would love to see it.

The Groovy Programming Language

2008-07-09T09:28:00.000-07:00

Long before Guice, there was PicoContainer. I used to lurk the mailing lists of PicoContainer and the Avalon Framework project back in the day when Inversion of Control (IoC) was a relatively hot topic. (In fact, if you Google “Jonathan Hawkes” at this time, one of the very few mentions of me is one of my very few posts on the Avalon list.) However, this article is not intended to be an introduction to IoC.

PicoContainer is how I discovered Groovy.

Ant was at its hayday. XML was still somewhat of a buzzword (if it is not now). The folks at the NanoContainer project (PicoContainer’s big brother) made the (gasp) startling realization that all of the configuration files required by Avalon and the Spring framework were actually code. XML configuration files can be large and unwieldy. Learning all of the correct tags and attributes can be a more daunting task for a programmer than simply learning a new API. So why not just write configuration code in… well… code?

One reason is that it’s nice to be able to change configuration on the fly, or at least without a recompile. This is where Groovy comes in.

Groovy is a language for the Java VM. To call it a scripting language would be somewhat of a misnomer. Groovy produces Java bytecodes. It can call Java classes and be called by Java classes. However, like a scripting language, you can change it. You don't have to build it. (Unless you want your vanilla Java code to call it in a typesafe manner.)

Groovy essentially extends the syntax of Java. In most cases, valid Java code will be valid Groovy code. However, like a scripting language, Groovy does not force you to know the type of an object at “compile time”. It supports closures and lots of other little goodies.

Go check it out. If you are a Java programmer, you owe it to yourself.

http://groovy.codehaus.org

What is a TECHHEAD?

2008-07-09T00:01:00.000-07:00

“When I was a child, I was quite adept at taking things apart. Putting them back together on the other hand...”

This is a story I casually tell clients as I have their notebook computer splayed out all over the room. They think that I am teasing them, and I am in part, but as with most jesting, there lies a kernel of truth. And the truth is, in my life I have taken apart many more things than I have put back together, caused myself more problems than I have fixed, and started more projects than I have finished. I find that learning is bold, messy, and full of unforeseen consequences. Mine is a tale of learning.

My name is Jonathan Hawkes, and I am a TECHHEAD.

I began my odyssey into computer programming when I was seven years old. I started out by writing simple games in BASIC on my friend’s Commodore 64. We would spend the better hours of the day punching away at the integrated keyboard, testing, modifying and testing again. We would draw out sprites onto graph paper, convert our makeshift bitmap into hexadecimal, input the figures into our program and enjoy the fruits of our hard-earned artistic labor. Then long after sundown, we would give a simple salute, power down the machine, and say a solemn goodbye to our wasted day’s effort. (At that time, my friend had no floppy drive.)

The subsequent years passed in similar fashion. Games, robots, lasers, etc. — Some were built; all were taken apart; few survived. BBSs were the primary mode of communication. L.O.R.D. and TradeWars rocked. Apogee was the coolest company ever.

Then Al Gore said, “Let there be internet.” And there was internet. The local college had a dial-up gateway that would allow terminal-based access to Gopher, Usenet and the WWW (through the Lynx browser). Way cool. I would page through binary Usenet groups while capturing output to a text file within HyperTerminal. I wrote a UUEncoder/Decoder in C and had instant access to a far larger range of games and other content than any BBS to which I had been a member.

More years passed. My family subscribed to a “real” dial-up account. It came with a finite amount of hosted web space and CGI access. Bingo. I soon discovered that Perl was more suited to the challenge of building web applications than C, and my first Perl project was a sort of simple wiki (circa 1995) called the ScrawlWall (which was just a text box that anyone could modify and save to leave a short note or ASCII art). That same year, I also developed an AJAX precursor, the JavaScript ScrawlWall, which could be saved and loaded without ever leaving the page. Before shutting the project down in 1998, I hosted over 8,000 ScrawlWalls.

After that began my career. As an independent contractor, I developed numerous web sites as well as a (then impressive) cross-browser DHTML library called Pane DOM. This was back when Netscape Navigator only allowed manipulation of content through “layers” and Internet Explorer had much of the same limited capabilities that it does now. Being as impressive of a (still) teenager as I was, I was offered a full-time job by one of my clients. I was newly married (Yikes! Kids these days), so I jumped at the opportunity. This was near the time the first dot com bubble burst. My company proceeded to sink over 3 million dollars into advertising and not a tenth of that into development. Though we had an economic development grant of over a half a million, the plug was pulled on our project before we ever had a finished product (or spent the money). Brilliant!

However my boss, who was one of those really great guys you work for once in a lifetime, managed to keep the team working for a while on various other projects (with remarkably similar outcomes). In the end, we did manage a Cobol-to-Java rewrite of a popular online commodity futures and options trading platform. And I led the development and maintenance for a number of years.

Salute. Power down. Say goodbye.

The problem with having a job that requires your mind is that when you lose your mind, your job will soon follow. So once my project no longer required my guardianship, and I could no longer stand the sight of it, I did what any reasonable person would do. I quit my well-paying job and became a professional ski patroller.

For any other kind of person, this may have been the end of the story. But for a select few there will always be a draw, an inexplicable force that compels one to the soft glow of a computer display and the distinctly stale aroma of the great indoors. So a number of years later, I traded in my ski boots for house shoes and returned to the home office. Thus TECHHEAD was (re)born.

Are you seeing a pattern here? I am a firm believer in reincarnation. I just believe that we have one lifetime in which to accomplish it. So now I am back where I started. But I am learning. I am building. And starting with this, my first blog post, I am sharing. Today I hope to build something truly great, scrap it, and start again tomorrow with the same enthusiasm and perhaps just a little bit wiser.