• 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 been coding in Perl for years and, generally, I think I’m a pretty competent coder. However, every now and again, I fall into a hole that takes me a loooong time to get out of. Invariably, these problems boil down to upload issues, not code issues. As an aide-mémoire for myself and, hopefully, to you, I thought I’d jot down a few problems that I’ve seen and what the solution was.

Incorrect shebang

The ‘shebang’ is the first line of code in a Perl script. It consists of a hash character ‘#’, followed by an exclamation mark ‘!’, also know as a ‘bang’ (hence the name). Then, the full directory of the Perl binary should be given. As often as not, this will be:

#!/usr/bin/perl

or

#!/usr/local/bin/perl

This is actually a generic line and is not unique to Perl. It’s a Unix device that tells the operating system that the program that is capable of interpreting the following script can be found here.

Now… if you get this wrong, it won’t work. The problem is, if you’re developing on one box with Perl in one location and you upload your scripts to another box, where Perl is located elsewhere, you’ll have the phenomenon of your script working perfectly on your development box, but won’t work on your production box. In addition, if you try to execute the script from the command line of your production box by invoking Perl directly and then provide the script name, that will also work, because the shebang is ignored in this case. It’s not until you try to execute your script via an HTTP request that it all falls apart. You will see the following in your error log:

[Fri Jul 03 16:57:14 2009] [error] [client xxx.xxx.xxx.xxx] suexec failure: could not open log file
[Fri Jul 03 16:57:14 2009] [error] [client xxx.xxx.xxx.xxx] fopen: Permission denied
[Fri Jul 03 16:57:14 2009] [error] [client xxx.xxx.xxx.xxx] Premature end of script headers: script.pl

This should be your indicator to check the shebang in the scripts on your production server and ensure that the point to the correct location for the Perl binary.

Incorrect file formats

Sometimes, your Perl script works fine on your Windows development box, but when you transfer it to your Unix production box, it stops working. As above, it works fine when you run it directly from the command line and you invoke ‘perl’ directly, but an HTTP request results in a 404 error, even though the file is actually in place.

The problem here is that DOS and Unix use different characters to indicate the end of a line and, if you have DOS endings in a Unix environment, the O/S is not able to parse the shebang correctly and so cannot locate the Perl binary. The way to fix this is to use the ‘dos2unix’ command. This will convery a DOS encoded file into a Unix encoded file and everything will be peachy.

This normally occurs if you’re using an FTP client that is uploading Perl files in BINary mode instead of ASCII mode. It also occurs if you are transferring files via SCP, since SCP does not convert files as it copies them.

O’reilly release the first chapter of their new webOS book in the past few days and it has been a welcome island in a sea of tedious rumours. While others may wildly speculate on when the Pre will appear, at least we now have some idea of what it will be running.

So what does this chapter tell us about webOS? Well, a lot of the chapter is spent with the usual overview. I tend to skip these chapters in technical books, but webOS is brand new to me, so I gave it the time. Here’s what I learned:

• webOS is expressly intended to support multiple hardware environments with all sorts over screen sizes, resolutions and orientations – This tells me that a good webOS App will not restrict itself to functioning on a Pre form factor
• webOS will use HTML 5 tags to provide storage functions and some graphic functions (using the canvas) – This tells me that I need to get up to speed on HTML 5 and start playing with it in Firefox
• webOS will give you access to Calendar and Contact data, Location Services, Accelerometer data and XMPP messaging  – This tells me that the apps we can make are going to be awwwwesome!
• Mojo will come bundled with the Prototype framework – Since I’m a jQuery fan, this means that I have to learn another JS framework, if I’m going to be able to fully exploit the Pre
• The Core OS will support fat32 for media file partitions (with a mention of mounting via USB) – This suggests that it may be possible to plug a USB drive into the Pre for extra storage and ease of file transfer!

There are some  nice pieces about design philosophy and UI considerations in the first chapter and some high level introduction to concepts such as stages and scenes.

All in all, and interesting read; certainly enough to whet my appetite for the Pre. Here’s what I’m going to be doing in preparation:

1. Learn HTML 5
2. Learn Prototype

I think focusing on those two, for now, will put me in good stead. I recommend the same to you.

I saw @mhat‘s tweet today about ‘What language should I learn‘  and it got me thinking about the times I’ve asked that question and how I might answer it. So, @mhat, I’m taking your tweet to be a challenge to write an unbiased and ‘unwrong’ post. To do this, I’m going to give you a history of the languages I have learned.

The early years

As I wrote in my first post, I started at a tender age, on a ZX Spectrum. The Spectrum came with a dialect of BASIC, called ‘Sinclair Basic’. Like all BASIC derivatives, it’s a high level language, however unlike modern flavours of BASIC, it was untyped and unstructured. Lines of code were entered with the line number provided explicitly. There was no variable scoping and subroutines were implemented as a special ‘GOTO’ called ‘GOSUB’ which allowed you to ‘RETURN’ to the next line. However, since there was no variable scoping, recursion was impossible.

That said, I was 5 at the time, I wasn’t too worried about recursion at the time. My programming was limited to copying code out of books containing page after page of ZX Spectrum programs. My brother and I would diligently type these out, then play the game for a while and then start playing with the code to see what changes we could make. This process was about as successful as genetic mutation. More often than not, our change would kill the program, but sometimes it would lead to great stuff.

As we got older, our 48K Spectrum was replaced with a 128K Spectrum. Along with the extra memory, came an update to BASIC to include keywords that allowed direct access to the MIDI chip. I continued to mess around with BASIC, making programs that would play both hands of a piano score, as well as simple games.

The IBM PC arrives

My first experience with an IBM PC was the 286. I migrated from Sinclair BASIC to GW-BASIC. At this point, I was writing programs from scratch, including a text adventure called ‘Loup-Garou Chateau’. Tragically, this game has been lost from prosperity, but it was my first foray into actually designing a program before coding it. I chose GW-BASIC, simply because I was very familiar with BASIC and it made for the simplest transition.

As the years passed, I would inherit my dad’s old computers, moving up through the 386 to the 486. At this point, I got my hands on Visual Basic. Again, this transition was driven by the ease of transition from what I knew to something new. This was my first experience with a proper development IDE, as well as my first experience with creating GUIs. Beyond that, it wasn’t a great step forward to me… that would come during university.

Coding gets hardcore

I never studied computing at university; I was a physics student. However, the course I took, included some small computing components. For one lab rotation, we learned how to use computers for physical analysis. This was back in 2000 and they had us coding with Pascal. At the same time, I was playing with C at the suggestion of my dad. For the first time, I was learning about functions and variable typing. In addition, I was programming with the intention to solve problems that were being presented to me, instead of just ‘playing’ with a language and seeing what it could do. When you have an externally provided problem to solve, you’re forced to learn how to use new facets of the language. If you’re just playing around, you can be limited to seeing what you can do with the parts of the language you understand.

While at university, I also participated in an Electronics lab which involved learning about the 8086 processor. We had an experimental board which allowed us to commit opcodes to a region of memory and then execute them. As part of the practical, we actually had to wire up the SUB instruction, by running the clock signal through the appropriate logic gates and to the appropriate ALU pins. This was my first experience with the lowest level of programming.

In the summer between my second and third years, I spent four weeks working for Milford Instruments. While there, I developed a DMX-512 Transceiver Controller. I was working with the SX-Chip from Parallax and learned how to write assembler, how to work with interrupt handlers and how to get microcontrollers to talk to other microchips. For 4 weeks, I worked on the firmware and the hardware and really learned what programming was all about…

Coding starts to bring in money

My month at Milford Instruments made me realise what I wanted to do with my time; I wanted to get into development professionally. It was an obvious choice to apply to IBM and I started working at their Hursley Development Lab, one weeks after school ended. They had me working on a protocol converter, (this time, a SCSI-SSA converter) and, as before, it was coded in assembler.

After a couple of years working on this, I moved to work on one of their Storage RAID controllers. This time I was coding in C, the first time I had done so, professionally. However, alongside all this production code, I was steadily learning how to write Perl and Korn Shell scripts for developing test rigs. I was also teaching myself how to code for the web. I’d done some basic page development while at university, but I was beginning to learn about dynamic pages and DOM manipulation.

My next move got me into support and I started writing a web-based support tool. It uses Perl and MySQL in the back-end and HTML and Javascript in the front-end.

The main thing I got from the IBM Development Lab was the chance to be surrounded by people writing a wide variety of code to solve a wide variety of problems and be exposed to what other people were doing with languages that I both knew and that I had never heard of. I learned that there is really no such thing as the one perfect language, rather the best language for the job in hand.

What’s the point of all this?

So, what’s the point of this post? Is it possible to write a post about “Which language should I use” that is not biased and has some value? I hope so. Here’s what I feel I’ve learned over the years.

People write code for a wide variety of reasons. The language that they code in is also determined by a multitude of factors. More often than not, we don’t have a truly free hand when it comes to choosing the language we’re coding in. However, looking back, I believe I see some benefits in the track I took.

• Learning C allows you to truly understand what higher level languages such as Perl or Java are doing with objects and references. Although people get scared off by pointers, if you don’t understand the concept, then you’re going to struggle with the idea of references. Since all languages have variables, if you can get those nailed and totally understood, you’re going to be in good stead when you move to a language which brings new data types
• Learning Assembler allows you to truly understand what C is doing with pointers. Assembler has a tiny command set and you have to tell it to do every last thing. It’s a struggle, but once you’ve got assembler in your tool belt you’re in good shape. You may never go back to it, but the lessons you learn from it can be applied all the way up the language stack
• Learning a wide variety of languages allows you to truly understand the patterns of development that are language-independent and stops you falling into the trap of becoming a language bigot. There’s nothing wrong with having a favourite language, but saying that one language is categorically better than another because of the presence of a specific feature is like praising Inuit for its wide variety of words for snow. That’s fine if you’re describing snow, but not much use if you want to discuss the surfing conditions in Hawaii.
• Learning a language is a lot easier if you’re trying to solve a specific problem that has come from an external source. This is why it’s such a good idea to do the exercises if you’re learning from a textbook. There’s nothing wrong with playing with a feature for its own sake, but unless you have some factor that is external to the language driving you, it’s going to be tough to learn all that the language can do.

Did I just cop out?

So, did I just cop out of the question? If someone asked me what language they should learn, how would I answer? That depends on the person. If they were just starting out, I would say Perl or Python. These languages have a huge development community and millions of pages dedicated to coding in them. They are in common usage and show no signs of disappearing in the near future. They are neither arcane nor limited in their range and they allow for procedural and object oriented style programming, meaning that the developer can transition to OO without having to change languages.

If I was being asked by someone with a reasonable amount of development, I would strongly suggest Javascript. As the powerhouse behind Web 2.0 and the basis for coding on the Palm Pre, it’s critical to know this language. However, testing and debugging Javascript is not a trivial task and requires a developer who is comfortable writing code that has ‘a good chance’ of working so that troubleshooting is limited to ironing out wrinkle. Also, the problems of cross-browser support are bewildering enough for experienced coders; exposing a brand new coder to Javascript would probably be the end of their efforts in the field.

If someone wanted to spread their wings a little, I’d strongly suggest taking a look at Assembler or some other microprocessor based language. It’s still coding, but you’re forced to truly understand your code’s interaction with external factors that don’t care about your nice neat program. Spending time debugging microprocessor code; especially code that interacts with an external piece of hardware, gives you a true understanding of the many ways that code can fail to work.