Method Resolution Order

When you have an Object that inherits methods from multiple parent Object, there needs to be a definitive way to determine which of the parent Objects implements methods not directly implemented in the child object. Dojo uses the C3 Method Resolution Order and you can read all the details by following that link. However, it gets a little technical, so I’ll try to summarize here.

Normally, it’s pretty easy to figure things out. Consider the following:

It’s easy to figure out which Function object to use for the method call C.method(). If it’s not in C, look in B. If it’s not there, look in A.

Now consider this diagram, which shows the well-known Diamond problem

In this diagram, C inherits from B and D, which both inherit from A. So here’s the question: if C overrides a method from A called foo, and B and D both override that method differently, which Function will be used for the method call C.foo()?

That’s where MRO comes in. MRO is used to determine which order to search for a method in a network of classes. The C3 Method Resolution Order guarantees that this will be predictable.

Figuring out MRO for your classes

Let’s say you’ve declare the following classes:

1
2
3
4
5
6
7

require(['dojo/_base/declare'],function(declare) {
  declare('A',[],{});
  declare('B',[],{});
  declare('C',[],{});
  declare('D',[A,B,C],{});
  declare('E',[C,D],{});
}

If you want to know which order E will use to search for a method, you could hand crunch the MRO yourself. If you don’t want to, then the following function will help you out:

1
2
3
4
5
6
7

define('mro', ['dojo/_base/array'], function(arrayUtils) {
  return function(proto) {
    return arrayUtils.map(proto._meta.bases,function(base) { 
      return base.prototype.declaredClass 
    }).join(" -> ");
  }
});

With this function: mro, you can take the constructor of any Object and determine its MRO, like so:

1
2
3
4
5
6
7
8
9

require(['dojo/_base/declare','mro'],function(declare, mro) {
  declare('A',[],{});
  declare('B',[],{});
  declare('C',[],{});
  declare('D',[A,B,C],{});
  declare('E',[C,D],{});
 
  alert(mro(E)); 
})

This will display E -> D -> C -> B -> A in an alert box. This shows you the order of Objects that will be search in order to resolve a method call.

If you’d like to play with this, you can do so in a Dojo sandbox. And that’s all you need to know. If you’re interested in why I wrote this, you can read on, but that’s all you need in order to starting checking MROs for your Objects.

Why did I need to know about MRO?

If you’ve ever used the Dijit Toolbar, you may know that it captures the left and right arrow keys in order to move focus between buttons. Unfortunately, if you put a text box into your toolbar, you can no longer move the caret, as the arrow keys just shit focus instead of shifting the cursor.

It does this with the _KeyNavContainer mixin:

1
2
3
4
5
6
7
8
9
10
11
12

define([
    "require",
    "dojo/_base/declare", // declare
        ...
    "./_Widget",
    "./_KeyNavContainer",
    "./_TemplatedMixin"
], function(require, declare, ... , _Widget, _KeyNavContainer, _TemplatedMixin){
    ...
    declare("dijit.Toolbar", [_Widget, _TemplatedMixin, _KeyNavContainer], { ... });
    ...
})

In order to override this behaviour, I created my own Toolbar and _KeyNavContainer:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

define(["dojo/_base/declare", // declare
        ...
    "dijit/_KeyNavContainer"
], function(declare, ... ,_KeyNavContainer){
    declare("danrumney._KeyNavContainer", [_KeyNavContainer], { ... });
})
 
...
 
define(["dojo/_base/declare", // declare
        ...
    "dijit/Toolbar",
        "danrumney/_KeyNavContainer"
], function(declare, ... ,_KeyNavContainer){
    declare("danrumney.Toolbar", [Toolbar, _KeyNavContainer], { ... });
})

In order to confirm that my overriding Objects would be the ones to provide Functions for method calls against danrumney.Toolbar, I wrote the MRO code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

define('mro', ['dojo/_base/array'], function(arrayUtils) {
  return function(proto) {
    return arrayUtils.map(proto._meta.bases,function(base) { 
      return base.prototype.declaredClass 
    }).join(" -> ");
  }
});
 
require(['dojo/_base/declare','mro'],function(declare, mro) {
  declare('dijit_Widget',[],{});
  declare('dijit_TemplatedMixin',[],{});
  declare('dijit_KeyNavContainer',[],{});
  declare('dijit_Toolbar',[dijit_Widget, dijit_TemplatedMixin, dijit_KeyNavContainer ],{});
  declare('dcr_KeyNavContainer',[dijit_KeyNavContainer ],{});
  declare('dcr_Toolbar',[dijit_Toolbar,dcr_KeyNavContainer],{});
 
  alert(mro(dcr_Toolbar)); 
})

This gives

dcr_Toolbar -> dcr_KeyNavContainer -> dijit_Toolbar 
            -> dijit_KeyNavContainer -> dijit_TemplatedMixin 
            -> dijit_Widget

which is exactly what I wanted. Hooray for MRO!

Some of you may have stumbled across an issue whereby a Listener has been attached to an Action, but isn’t being called when that Action executes. This article explains what’s going on an how to avoid it.

Throughout this article, you’ll see me using the AMD style of module use. That is, I won’t be referring to dojo.methods. If you’re not familiar with Dojo’s AMD, take a look at this article about the Dojo Loader at some point. Until then, don’t worry: all this affects for this article is what the method calls look like; the internals are the same.

The problem

Take a look at this code and see if you can figure out what the output will be:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

/*jshint dojo:true devel:true strict:false*/
require(['dojo/_base/declare', 'dojo/_base/lang',
         'dojo/_base/connect'], 
    function(declare, lang,
             connect) {
 
        declare("Foo", [], {
        /*global Foo*/
            constructor : function(name) {
                this.name = name || "<undef>";
               console.log("Instantiated a Foo called '"+this.name+"'");
            },
 
            aMethod: function() {
                console.log(this.name+".aMethod called with arguments: %o", arguments);
            },
 
            secondMethod: function() {
                console.log(this.name+".secondMethod called with arguments: %o", arguments);
            }
        });
 
        declare("Bar", [], {
            /*global Bar */
           constructor : function(name) {
               this.name = name || "<undef>";
               console.log("Instantiated a Bar called '"+this.name+"'");
           },
 
           anotherMethod: function() {
                console.log(this.name+".anotherMethod called with arguments: %o", arguments);
           }
        });
 
 
        var foo = new Foo("foo");
        console.info("Calling foo.aMethod");
        foo.aMethod("After init");
 
        var bar = new Bar('bar');
 
        console.info("Calling bar.anotherMethod");
        bar.anotherMethod("After init");
 
        console.info("Getting a reference to bar.anotherMethod called barAM");
        var barAM = lang.hitch(bar, bar.anotherMethod);
 
        console.info("Connecting foo.aMethod to bar.anotherMethod");
        connect.connect(bar,'anotherMethod', foo, foo.aMethod);
 
        console.info("Calling bar.anotherMethod");
        bar.anotherMethod('Direct call');
        console.info("Calling barAM");
        barAM('Via barAM');
 
        console.info("Getting another reference to bar.anotherMethod called barAM2");
        var barAM2 = lang.hitch(bar, bar.anotherMethod);
 
        console.info("Connecting foo.secondMethod to bar.anotherMethod");
        connect.connect(bar,'anotherMethod', foo, foo.secondMethod);
 
        console.info("Calling bar.anotherMethod");
        bar.anotherMethod('Direct call');
        console.info("Calling barAM");
        barAM('Via barAM');
        console.info("Calling barAM2");
        barAM2('Via barAM2');        
    }
);

Here’s what you will see in your console:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

Instantiated a Foo called 'foo'
Calling foo.aMethod
foo.aMethod called with arguments: ["After init"]
 
Instantiated a Bar called 'bar'
Calling bar.anotherMethod
bar.anotherMethod called with arguments: ["After init"]
 
Getting a reference to bar.anotherMethod called barAM
Connecting foo.aMethod to bar.anotherMethod
Calling bar.anotherMethod
bar.anotherMethod called with arguments: ["Direct call"]
foo.aMethod called with arguments: ["Direct call"]
 
Calling barAM
bar.anotherMethod called with arguments: ["Via barAM"]
 
Getting another reference to bar.anotherMethod called barAM2
Connecting foo.secondMethod to bar.anotherMethod
Calling bar.anotherMethod
bar.anotherMethod called with arguments: ["Direct call"]
foo.aMethod called with arguments: ["Direct call"]
foo.secondMethod called with arguments: ["Direct call"]
 
Calling barAM
bar.anotherMethod called with arguments: ["Via barAM"]
 
Calling barAM2
bar.anotherMethod called with arguments: ["Via barAM2"]
foo.aMethod called with arguments: ["Via barAM2"]
foo.secondMethod called with arguments: ["Via barAM2"]

First, we instantiate two objects: foo and bar and we call some methods to demonstrate how those methods behave. Then, we get a reference to the bar.anotherMethod called barAM. We connect foo.aMethod to bar.anotherMethod, so that foo.aMethod is called whenever bar.anotherMethod is called. Next, we call bar.anotherMethod and, as expected, we see that foo.aMethod is called. After that, we call barAM, but we see that foo.aMethod is not called, even though bar.anotherMethod was. OK, so maybe it’s because we created barAM before we connected foo.aMethod. So, we create another reference to bar.anotherMethod and call it barAM2. We also connect another method (foo.secondMethod) to bar.anotherMethod. This time, when we call bar.anotherMethod we see both of our connected methods also being called. Great; this is what we expect. Then, we call barAM and we see that only bar.anotherMethod is called. Not what we want, but what we now expect. Finally, we call barAM2. This time, we see that both foo methods are called, even though we attached secondMethod after we took our reference.

What’s going on?

First, let’s look at the wiring…

The wiring

Prior to Dojo 1.7, this was all handled by the connect module. Since the advent of Dojo 1.7, this functionality has been split out into the [on][] module for event-handling and aspect module for Aspect Oriented Programming (AOP) advice giving. Indeed, the 1.7 version of connect.connect() is essentially a wrapper around calls to on() and aspect.after(). First, let’s look at connect

Dojo connect

If you take a look at the connect API, you’ll see the method signature:

connect.connect(obj, event, context, method, dontFix);

obj

This is the object that fires the Action. It might be a DOM node or just a plain old object. It can be omitted, but we’re not going to worry about that here.

event

This is the Action that was mentioned above. It might be an event; it might be a method name. Either way, it’s just a String that represents the Action that we’re interested in connecting to

context

This is the context in which the method will be called. Basically, the context of a method is the value that is returned if the method refers to this. If no context is given to connect.connect(), then the context will be set to the event’s context.

method

This is the function that will be called after the Action takes place. This can be a Function object (i.e. a reference to a function) or it can be a String. If it is a String, then the function that is called is context[method].

dontFix

Don’t worry about this. It’s not relevant to this discussion.

In Dojo 1.7, connect.connect() follow this recipe:

1. Normalises the input parameters, to handle any that were set to null or left undefined
2. Hitch the method to the context
3. If obj is not a DOM node, then use aspect.after() to attach the Listener to the Action
4. If obj is a DOM node, do some clean up for the event to ensure that cross-browser support works and then use on() to attach the Listener to the Action

If you’ve already moved away from using connect.connect(), you’re probably using lang.hitch() yourself, to ensure that your Listener is called in the context of its providing object. Here’s where you can get into problems. To understand why, though, lets look at how aspect.* works.

Dojo aspect

The Dojo aspect API defines three functions: before, after and around. They have very similar signatures:

aspect.before(target,methodName,advice)
aspect.around(target,methodName,advice)
aspect.after(target,methodName,advice,receiveArguments)

target

This is the object that is being targeted with the advice.

methodName

This is the method of the target that is being targeted with the advice.

advice

This is the function to be called at a time indicated by the aspect.* method. More often than not, this will be a method that has been hitched to another object.

receiveArguments

This just controls whether the after advice receives the arguments that were passed to methodName

The way that Dojo handles this is to create a dispatch Function that creates a linked list of Function objects. The before advice comes first, then the targeted method, then the after advice. A little more work is needed for around advice, but the principle remains the same.

How it all works

In Javascript, an Object is simply an associative array with some special features. The keys of the Object are the field names and method names. The values of the Object are the field values and Function objects. In the image below, you can see a representation of the two objects created in our code sample:

You can see the Function objects represented as rounded rectangles. Plain rectangles represent variable names. Whenever a call is made to bar.anotherMethod, the anotherMethod Function object is called, with bar as the context.

In the next diagram, we create our reference to bar.anotherMethod. When this happens, Javascript looks to see what bar.anotherMethod points to and points barAM to that. The little bar on the arrow tells us that this is a hitch and that the context for this call will be bar. At this point, you can see that a call to bar.anotherMethod and barAM will be identical. They point to the same Function object and will be called with the same context.

Next, we perform our connect, which is just an aspect.after. Here’s where the problem kicks in.

When the aspect.after is performed, Dojo replaces the anotherMethod Function with the DISPATCHER function that handles all of the AOP magic. Now, bar.anotherMethod points to DISPATCHER. DISPATCHER‘s job is to call all of the aspect.before Functions, then the Function that is being advised (in this case anotherMethod) and then the aspect.after functions. (We’re ignoring aspect.around here, just for diagrammatic clarity… it doesn’t alter the explanation). You can see here, that barAM and bar.anotherMethod no longer point to the same thing.

Now, we add our second hitch:

Now, bar.anotherMethod is pointing to the AOP dispatcher, so that’s what barAM2 points to. When we connect our second method:

bar.anotherMethod and barAM2 are still pointing to the same thing. That explains what we saw in our console. Once AOP advice has been attached to a method, any newly created references to this method will see any advice attached after that reference is made

Conclusions

So what conclusions can we draw here?

The crucial one is that any references made to an object method before connections are made or AOP advice is attached will, when called, NOT result in these attachments being called.

Since the very nature of web-apps results is asynchronous, you often cannot guarantee the order of execution of code. In addition, future modifications to your code base, could result in these incompatible hitches and connections being made. This can lead to very tricky bugs.

So how do we avoid this? Luckily, it’s really easy. hitch allows you to provide a method as a String, rather than a Function. When you do this, your reference points to the method in a different way:

Your code would now look like:

46

var barAM = lang.hitch(bar, "anotherMethod");

Any time you make a call to your hitched Function, it has to look up bar["aMethod"]. Therefore, any changes to where this points are picked up by your hitched reference. This does have a minor penalty performance, but it makes your code way more robust, so it’s worth the cost.

So, in summary: whenever you create a hitch, either explicitly, or (as in the case of connect) implicitly, do so with the method as a String, rather than a Function. If you don’t, you may end up observing unexpected behaviour, once AOP comes in to play.

The roar of the wind and surf makes it hard to concentrate. The acrid scent of molecules, once confined to the pages of textbooks, prick my nose and tickle my throat. Turning to face the wind, like a contrarian weather vane, sea-spray and sand scour my face. The salted air mixes with salted water as the onslaught brings tears – tears born, not of emotion, but in an attempt to replenish what the cold rush has wicked away. The world blurs as I am disconnected from all useful stimuli. At that moment, its burdens drop away and for once, I am free.

Frequently, within these dumps, I’m face with a buffer that wraps. That is to say, each entry in the buffer is filled and, once the buffer is full, the next entry to be filled is the first, again (overwriting the old value).

At the point in time that the dump is taken, there is an index value that points to the ‘start’ of this buffer (i.e. the point in the buffer that is the oldest). Unfortunately, when Perl gets hold of the buffer, it represents it as an array, with the first entry in the array being the buffer entry with the lowest memory address.

So… given an array representing a buffer and an index to the logical start of the buffer, what’s the simplest way to rejig it, so that the array represents the logical order of the buffer instead of the physical order?

Voila:

splice @buffer, 0, 0, (splice @buffer, $start_index);

This raises the question, when you decide to move an object to a new position in the sort order, what is the simplest way to update the other objects to ensure that you maintain consecutive sort positions.

Imagine the following SQL table:

CREATE TABLE "projects" (
    "id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
    "name" VARCHAR(255),
    "sort_order" INTEGER UNSIGNED
);

The ’sort_order’ field contains a simple integer that indicates the position that the object should appear in. To get the ‘projects’ in the desired order, you’d execute:

SELECT * FROM projects ORDER BY sort_order DESC

To move an object from one position to another is a fairly simple operation. Each object has a unique (and immutable) “id”.  An appropriate method signature would be something like this:

def change_sort_location(object_id, new_location)

The following steps should be followed:

1. Identify the current location of the objects as old_location
2. If old_location < new_location
   1. Subtract 1 from sort_order for all objects where old_location < sort_order ≤ new_location
3. If new_location < old_location
   1. Add 1 to sort_order for all objects where new_location < sort_order ≤ old_location
4. Set sort_order for the provided id to new_location

The SQL for this is pretty straightforward:

UPDATE projects SET sort_order = sort_order-1
  WHERE sort_order > @old_location AND sort_order <= @new_location

or

UPDATE projects SET sort_order = sort_order+1
  WHERE sort_order > @new_location AND sort_order <= @old_location

followed by

UPDATE projects SET sort_order = @new_location
  WHERE id = @object_id

Clearly, in a full implementation, you’d probably not be using SQL variables, but the point stands.

One complaint might be that the object that is getting moved can get updated twice here, but that’s unlikely to be a major performance impact.

Currently, once object move requires 2 SQL queries. N object moves will require 2N SQL queries. I’m currently trying to figure out a method to reduce the number of SQL queries needed for multiple moves.

Let’s say you have a website hosted somewhere, and you’ve bought the domain name from Go Daddy. How do you make that web address point to your website? Well, it’s pretty straightforward.

First, log on to your account. Once you have, you should see a page similar to this:

Select ‘Domain Manager’ and the next window will open up:

On this page, select the domain name that you’re interested in and then click on the Nameservers. The following window will pop up:

Choose ‘I have specific nameservers for my domain’ and insert the nameservers that your hosting solution provided.

Once you click OK, it may take some minutes for the change to propagate throughout the internet. Technically speaking, it can take many hours to get to every part of the Internet, but most people will see the change within a few minutes.

That’s it… easy, eh?

We all know, by now, that Twitter limits its tweets to 140 characters. We’ve all got pretty good at limiting ourselves to 140 characters, but many overlook a hidden limit. This post outlines what that is and how we can avoid it.

Many users of Twitters are hoping that their followers will retweet (RT) their tweets. Twitter recently made a change to how these work, but in general, the following pattern is followed:

   UserXYZ tweets: Hey... here's something that's fascinating
   UserABC tweets: RT @UserXYZ: Hey... here's something that's fascinating

User XYZ’s tweet was 42 characters. UserABC’s RT was 52 characters, i.e. 10 characters were added in order to RT.

Put another way, if UserXYZ creates a tweet that was longer than 130 characters, nobody would be able to RT it with modifying the original tweet. If you’re trying to get a specific message out to the world, you might not be happy with lots of people fiddling with it.

I’ve created a new Greasemonkey script which will help you with this. I’ve written about Greasemonkey plugins before and this is another Twitter helper. If you install the script, you will see the following change:

You can now see, next to the normal character countdown, a bracketed countdown. This is the number of characters that you have left, before a tweet can no longer be RTed without modification. In this example, you would be able to send the tweet (as you have 6 characters left), but Twitter users would have to remove 8 characters before they could RT your Tweet.

To use this, it’s simple:

1. If you haven’t already, install Greasemonkey
2. Install the ReTweetable Alert script

That’s it! As ever, your questions and comments are most welcome

• Google Analytics will not be able to track these external links (if, for instance, you’re using my Google Analytics for external links)
• Non-visual User Agents will not be able to access these links
• As a subset, Google will not be able to crawl these links and so associate your site with the sites those banners point to.

The way to resolve this is to use the method of graceful degradation or, perhaps more appropriately, progressive enhancement. By this, I mean, the HTML should be written such that the above issues are avoided, and then the JavaScript should be written to provide the Rotating Banners functionality.

Using the Rotating Banners script as a starting point, the obvious approach is to dispense with the JSON representation of our banners and replace it with an HTML representation of our banners. This will be hidden using CSS. Much of the functionality will otherwise remain the same. By representing the links in the HTML document, webcrawlers (such as Google’s indexing service) will be able to parse these links and use them accordingly. In addition, Google Analytics (if installed on your site) can track exits from your site, via these banners.

I have created a new object which extends the original Rotating Banners object, such that it doesn’t cause SEO problems. In order to use this object, you need to include the original object in your HTML, as well as this one.

The new object is shown below:

/**
* SEO Safe Rotating Banner
*
* Specialized version of Rotating Banner
* @author dancrumb
*/
 
/*global rotatingBanner,$ */ 
 
var seoSafeRotatingBanner = function (spec, secrets) {
 
	var prvItems = secrets || {};
 
	var that = rotatingBanner(spec, prvItems);
 
	spec.banners = [];
 
	prvItems.rotate = function () {
		// This should only be executed if initialization is complete
		if (!prvItems.intialized)	{
			return null;
		}
 
		var newBanner = prvItems.nextBanner();
 
		$('#' + spec.divId + ' a').css('display', 'none');
		$('#' + newBanner.id).empty();
		var imgBanner = $(document.createElement('img')).
			attr('src', newBanner.src).
			attr('height', spec.height).
			attr('width', spec.width);
 
		$('#' + newBanner.id).append(imgBanner);
		$('#' + newBanner.id).css('display', 'inline');
 
		prvItems.cacheNextImage();
 
		return newBanner;
	};
 
	prvItems.initialize = function () {
		var bannerDiv;
		bannerDiv = $('#' + spec.divId);
		if (bannerDiv.length === 0)	{
			alert("Please provide the ID of an element on the page");
			return null;
		}
 
		$('div#' + spec.divId + ' a').each(function (i) {
			var aElem = $(this);
			// Ensure that there is an ID defined, for future manipulation
 
			var a_id = aElem.attr('id');
			if (a_id === null) {
				a_id = 'rb_auto_id_' + i;
				aElem.attr('id', a_id);
			}
 
			// Ensure that there is a target defined, and set it to the defaultTarget
			// if not
			var tgt = aElem.attr('target');
			if (!tgt) {
				tgt = spec.defaultTarget;
				aElem.attr('target', tgt);
			}
 
			// Ensure that the banner is hidden
			aElem.css('display', 'none');
 
			// Add the banner to the rotater
			that.addBanner(
				{
					"src": aElem.text(),
					"id": a_id
				}
			);
		});
 
		that.randomizeBanners();
		prvItems.intialized = true;
		prvItems.rotate();
                $('div#' + spec.divId).css('display', '');
	};
 
	return that;
 
};

This file can be downloaded here. All that is necessary is to override the ‘initialize’ and ‘rotate’ methods.

Using this object on your page is just as straightforward as before. As before, you need to include the jQuery library. You also need to include the original rotatingBanners script, as well as this one. The initialization code is slightly different:

var rB = seoSafeRotatingBanner(
  {
    "width":  600,
    "height": 400,
    "interval": 5000,
    "divId": "bannerHere",
    "defaultTarget": "blank"
   }
);
rB.startRotation();

The final ingredient is the list of links itself. This is provided in HTML:

<div id="bannerHere" style="display:none;">
  <a id="banner1" href="link1">/image_location/img_src_1.jpg</a>
  <a id="banner2" href="link1" target="blank">../img_src_2.png</a>
  <a id="banner3" href="link1" target="some_target">img_src3.gif</a></div>

Note that the URLs to the images are just plain text. They are not IMG tags.

You must ensure that the style of the enclosing DIV contains ‘display:none‘ (per line 1) or your list of links will be visible to the user.

At this point, you will have your rotating banners, without sacrificing your SEO performance.

The main problem with the script is that it was too random. It took an array, or list, of banners and, on each rotation, it would select a random position in this list. The problem with this becomes obvious when you look at some examples of random number selections. The output from the following (Perl) script:

my $idx = 20;
while ($idx)
{
print int(rand()*5);
$idx--;
print "," if $idx;
}

is

0,1,2,0,3,0,3,3,3,3,0,3,0,1,1,1,0,4,4,2,4

If each number represents a specific banner, you can see that there is a significant bias toward 3 in this set of 20 rotations. This is not indicating an inherent bias towards 3. Quite the opposite; this is truly random, but human perception detects a bias because our sample is relatively low.

Leaving the statistics behind, it is quite easy to ensure that the order of banner rotation is random, but every banner gets equal time. All you have to do is to randomize the order of your list of banners when the page loads, and then cycle through them. On each page load, the order is random, but once a page is loaded, the order remains static.

With that in mind, I wrote a JavaScript object to provide the necessary function. I’ve been writing JavaScript for some time, but I recently bought ‘JavaScript: The Good Parts’ by Douglas Crockford. Crockford has been writing JavaScript for a long time now and has some strong opinions on the language. I for one applaud this book, although I’m not wholly sold on some of his beliefs. That said, I decided to take a crack at creating an object based on his writings. I’m not overly convinced that the code I’ve written is superior to anything else I would have written, but I’m willing to take the blame for any failings in my code here:

/**
 * @author dancrumb
 */
 
/*global $ */
 
var rotatingBanner = function (spec, secrets)
{
 // Private
 var that = {},
 prvItems = secrets || {};
 
 prvItems.workingList = [];
 prvItems.cached = {};
 prvItems.timeoutId = null;
 prvItems.intialized = false;
 
 prvItems.nextBanner = function () {
 var banner = prvItems.workingList.shift();
 prvItems.workingList.push(banner);
 return banner;
 };
 
 prvItems.rotate = function () {
 // This should only be executed if initialization is complete
 if (!prvItems.intialized) return null;
 
 var newBanner = prvItems.nextBanner();
 
 $('#'+spec.divId+' a img').attr('src',newBanner.src);
 $('#'+spec.divId+' a').attr('href',newBanner.href || '');
 $('#'+spec.divId+' a').attr('target',newBanner.target || spec.defaultTarget || '');
 
 prvItems.cacheNextImage();
 
 return newBanner;
 };
 
 prvItems.initialize = function() {
 var bannerDiv,
 eImg,
 eA;
 bannerDiv = $('#'+spec.divId);
 if(bannerDiv.length == 0)
 {
 alert("Please provide the ID of an element on the page");
 return null;
 }
 
 bannerDiv.empty();
 eImg = $(document.createElement("img")).
 attr('height',spec.height).
 attr('width',spec.width).
 attr('id','bannerImage');
 
 eA = $(document.createElement('a')).
 attr('href','');
 
 eA.append(eImg);
 bannerDiv.append(eA);                
 
 that.randomizeBanners();
 prvItems.intialized = true;
 prvItems.rotate();
 };
 
 /*
 * Place the next Banner Image into the browser cache
 */
 prvItems.cacheNextImage = function () {
 var upcomingBanner = prvItems.workingList[0],
 cacheImage;
 if (!prvItems.cached[upcomingBanner.src])
 {
 cacheImage = new Image();
 cacheImage.src = upcomingBanner.src;
 prvItems.cached[upcomingBanner.src] = true;
 }
 };
 
 /*
 * Ensure we, at least, have an array of banners
 */
 if(!(
 spec.banners &&
 typeof spec.banners === 'object' &&
 typeof spec.banners.length === 'number' &&
 typeof spec.banners.splice === 'function' &&
 !(spec.banners.propertyIsEnumerable('length'))
 ))
 {
 spec.banners = [];
 }
 
 /*
 * Confirm that the interval is sensibly set
 */
 if (!((typeof spec.interval === 'number') &&
 (isFinite(spec.interval)) &&
 (spec.interval >= 500))) {
 spec.interval = 1000;
 }
 
 // Public
 that.randomizeBanners = function () {
 // We shouldn't fiddle with knownBanners directly as this
 // is our master list of banners
 var holdingCopy = spec.banners.slice(0),
 index;
 
 if (prvItems.timeoutId)
 {
 clearTimeout(prvItems.timeoutId);
 }
 prvItems.workingList = [];
 
 // Randomize the order of the holding copy of known banners and put it
 // into the working list
 while (holdingCopy.length > 0)
 {
 index = parseInt((Math.random()*holdingCopy.length),10);
 prvItems.workingList.push(holdingCopy[index]);
 holdingCopy.splice(index,1);
 }        
 
 // If we cancelled the rotation, we restart it here
 if (prvItems.timeoutId)
 {
 that.startRotation();
 }
 };
 
 that.startRotation = function () {
 prvItems.timeoutId = setInterval(function(){
 prvItems.rotate();
 },spec.interval);
 };
 
 that.addBanner = function (banner) {
 spec.banners.push(banner);
 this.randomizeBanners();
 };
 
 that.setInterval = function (interval) {
 if (prvItems.timeoutId)
 {
 clearTimeout(prvItems.timeoutId);
 }
 spec.interval = interval;
 if (prvItems.timeoutId)
 {
 that.startRotation()
 }
 }
 
 $(function(){ prvItems.initialize();});
 return that;
};

You can download this script here

The code above relies on jQuery, so naturally, you would need to include that library first in any HTML page that uses this object.

Invoking this code is straightforward. Your webpage will need a DIV with a defined ID attribute; in this case we use bannerHere.

var rB = rotatingBanner(
 {
 "width":  600,
 "height": 400,
 "banners": [
 {"src":'fake1', "href":'fake1'},
 {"src":'fake2', "href":'fake2'}
 ],
 "interval": 2000,
 "divId": "bannerHere",
 "defaultTarget": "blank"
 }
 );
 rB.startRotation();

width and height are the desired dimensions for the banners interval is the time (in ms) between each rotation defaultTarget is the desired value for the TARGET attribute of the banner link banners is a JavaScript array of JavaScript objects with the following fields:

src is the SRC of the banner image href is the HREF of the banner link target is the optional target for the banner link

The code is based on Crockford’s belief that we should not pretend the JavaScript is a class-based language. It isn’t, it’s a prototype-based language. This means that new objects are created from a ‘template’ object or from a factory method, which generates new object. Again, I’ll repeat that my implementation is quite probably not the best example of this and I’m not sure that I prefer this code to a class-based approach, but it works and it’ll do for now.

There are some SEO concerns with this implementation, but I’m going to save them for an upcoming post. For now, the code about should be enough for you to implement rotating banners on your website

I’ve started learning Ruby on Rails and the Ruby part uses things called ‘Gems’ in a similar way to Perl using Modules. Where you read ‘gem’, thing ‘cpan’.

I wanted to install a new gem on my server to support some Paypal integration, but ‘gem’ kept segfaulting on me.

If you’re like me, you’ll see this behaviour:

root@server [~]# gem install rubygems-update
Bulk updating Gem source index for: http://gems.rubyforge.org
Terminated

It turns out that ‘Bulk updating…’ part gobbles up memory like it’s going spare and leads to a segfault.

The way to avoid this problem is to update RubyGems… but to do that, you need to use ‘gem’… and that leads to a segfault… and around we go again.

To break the cycle, you simply use:

gem update --system --no-update-sources

to prevent the updating of sources.

Once I’d done that, I found that I was still getting segmentation faults. Also, when I ran:

root@server [~]# gem install activemerchant --no-update-sources

I now got

ERROR:  could not find activemerchant locally or in a repository

So the problem still wasn’t resolved!

The only solution was to force my system to the latest version of RubyGems. Unfortunately, this was not in my local repository. However, a manual update was pretty simple:

cd /tmp
wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz
tar -xvzf rubygems-1.3.5.tgz
cd rubygems-1.3
ruby setup.rb

Job done!