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

As an owner of a brand new Palm Pre, I recently got exposed to the vagaries of trying to import my Facebook Calendar into my Pre. It’s not as easy as it should be and the fault lies with Facebook and with Palm. While we’re waiting to sort things out, I’ve written a little application, along with the post, to help myself and others out of this pickle

The start of the problem is with Facebook. When you opt to export your Events, Facebook provides you with a URL pointing to an iCalendar file. This contains all the details of your upcoming events. However, what it does not contain (and this is critical) is any timezone information. When you access Facebook normally, it knows what timezone you are in from you computer’s clock and shows events at the according time. This is known as using a ‘floating’ timezone and makes things a lot easier on the FB backend.

However, when you import this iCalendar file into another calendar application, it has no idea what timezone the file represents. Some applications will assume it is your local timezone. Others (especially web applications) may assume that the timezone is GMT. Unless you live in the UK, or other GMT countries, you’re going to see an offset for all of your events.

How does this play into the Pre? Well, I live in Austin, which is in the Central timezone. When I imported my Facebook events, they were off by two hours. After some investigation, I came across this theory, that I find the most compelling: My Pre is synchronised with my FB events via a server at Palm, in the Pacific timezone. Facebook ‘floats’ my events to match the PST timezone. As a result, when they appear in my Pre, they are off by two hours.

So, I though to myself, why not import my FB Events into my Google calendar and use that as my primary calendar. Well, Google has other ideas. It sees an iCalendar file without a time zone, assumes GMT and so shifts all of my events by 6 hours.

As a result, I’ve made this app. Just provide the URL to your Facebook Events Export, set your timezone and give the new calendar a name. A new URL will be generated, which you can then pass to Google Calendars. Within an hour or so, Google will import your events and keep them updated.

You can then sync your Pre (or other PDAs) with your Google Calendar and, hey presto, there are your events.

This process doesn’t add any functionality to the calendar; it just sets to timezone correctly. Any delays in synching will come from the delay of Google synching with Facebook and your Pre synching with Google. My filter adds no significant time overhead at all.

This functionality is provided to you all free of charge. All I ask is that you add comments and suggestions. I’m happy to tweak this and respond to error reports.

Tracking external links with Google Analytics is a great way to work out and why how people are leaving your site. This post describes a method for automatically tracking external links in a way that degrades gracefully in the absence of Javascript.

Google Analytics works by having you install a small Javascript on each page. This script tracks a number of things, including the referrer. The referrer is the page that the user as just on. If this was an external page, then Google Analytics registers this as a traffic source. If this was an internal page, then Google analytics registers this as well. When you’re analyzing your site statistics, Google Analytics will be able to show which internal links were clicked on any given page.

However, because Google Analytics relies on the page that you’re clicking to, in order to track information, you need to do something extra in order to track clicks on external links. Remember, when you leave your site, Google Analytics isn’t going to be able to track that normally.

The Google Analytics documentation for this explains what you need to do. You need to add an onClick event handler to your external links. The problem is, the method that they recommend doesn’t degrade very nicely if your visitor doesn’t have Javascript running. In addition, it requires yo to add this code to every external link.

I’ve written a script which will set up all of your external links to be tracked with Google Analytics and include it here for your use. I’ve stripped out a lot of the comments from the code below, but the actual file has plenty of comments in it. It can be found here.

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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120

function EnableGA(tracker,mappings,trackUnknownLinks,testing)
{
	this.tracker = tracker;
	this.mappings = mappings;
	this.trackUnknown = (typeof(trackUnknownLinks) != "undefined")?trackUnknownLinks:false;
	this.testing = (typeof(testing) != "undefined")?testing:false;
 
	this.parseOptions = {
		key: ["source","protocol","authority","userInfo","user","password","host","port","relative","path","directory","file","query","anchor"],
		q:   {
			name:   "queryKey",
			parser: /(?:^|&)([^&=]*)=?([^&]*)/g
		},
		parser: /^(?:([^:\/?#]+):)?(?:\/\/((?:(([^:@]*):?([^:@]*))?@)?([^:\/?#]*)(?::(\d*))?))?((((?:[^?#\/]*\/)*)([^?#]*))(?:\?([^#]*))?(?:#(.*))?)/
	};
 
	var oThis = this;
    $(document).ready(function(){oThis.enable()});
}
 
/*
 * enable
 *
 * Enables GA tracking of external links
 */
EnableGA.prototype.enable = function()
{
	if(this.tracker || this.testing)
	{
		var oThis = this;
		$("a").each(function()
		{
			var target = $(this).attr("href");
			if((target != null) && (target != ""))
			{
				var URL = oThis.parseUri(target);
				if ((URL.host == "") || (URL.host.search(window.location.hostname)>=0))
				{
					// Do nothing. Google Analytics already tracks local files
				}
				else
				{
					var pseudoLoc = oThis.getPseudoLoc(URL);
					if(pseudoLoc)
					{
						$(this).bind('click',function(evt)
						{
							if(oThis.testing)
							{
								if((typeof(console) != 'undefined') && (typeof(console.log) != 'undefined'))
								{
									console.log(pseudoLoc)
								}
								else
								{
									alert(pseudoLoc);
								}
								evt.preventDefault();
							}
							else
							{
								pageTracker._trackPageview(pseudoLoc);
							}
						});
					}
				}
			}
		});
	}
};
 
/*
 * getPseudoLoc
 *
 * Gets a pseudo-location for the purposes of GA tracking for the provided
 * URL of an external link
 */
EnableGA.prototype.getPseudoLoc = function(url)
{
	var response = this.trackUnknown?"/UNK/"+[url.host,url.directory,url.file].join(''):null;
 
	jQuery.each(this.mappings, function(plDir,regExp)
			{
				if(regExp.test(url.host))
				{
					if(((url.path == "") || (url.path == "/")) && (url.file == ""))
					{
						response = "/"+plDir+"/root";
					}
					else
					{
						response = "/"+plDir+"/"+[url.directory,url.file].join('/');
					}
				}
			});
 
	return response;
};
 
/*
 * parseURI
 *
 * Takes a URI and splits it into its constituent parts
 */
EnableGA.prototype.parseUri = function(str)
{
	var	o   = this.parseOptions,
		m   = o.parser.exec(str),
		uri = {},
		i   = 14;
 
	while (i--) uri[o.key[i]] = m[i] || "";
 
	uri[o.q.name] = {};
	uri[o.key[12]].replace(o.q.parser, function ($0, $1, $2) {
		if ($1) uri[o.q.name][$1] = $2;
	});
 
	return uri;
};

In order to demonstrate how this works, I’ve created a very bare bones demonstration. This will show you how the script is used and how it bahaves in ‘testing’ mode.

If you have any questions or comments, feel free to leave a comment below and I’ll address them as soon as I can

Twitter recently changed the ids and classes that they use for the DIVs their pages, so I had to make an update to the Twitter WhoAmi script.

Still find it useful as I now have at least 4 Twitter identities (one personal and three project IDs).

The other day, the preDevCamp team published our ‘PreView’ map at http://predevcamp.org/preView.html. In this post, I’ll talk about how it was put together.

PreView is a combination of the Google Maps API and the Twitter API. Without wanting to shatter the mystique, I’m going to outline how I set about creating PreView.

First, take a look at the HTML in preView.html. When you strip out the preDevCamp menu and Twitter Bird, you’re left with:

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

<html>
<head>
<title>preView - Global Twitter interest in preDevCamp, Palm Pre and webOS</title>
<link rel="stylesheet" type="text/css" href="/css/preView.css" >
<script src="http://maps.google.com/maps?file=api&amp;v=2.x&amp;key=xxxxxxxx" type="text/javascript"></script>
<script src="http://gmaps-utility-library.googlecode.com/svn/trunk/markermanager/release/src/markermanager_packed.js" type="text/javascript"></script>
<script type="text/javascript" src="/js/jQuery.js"></script>
<script src="/js/tweetList.js" type="text/javascript"></script>
<script type="text/javascript" src="/js/preView.js"></script>
</head>
<body>
<div id="tweetAPI">Checking Twitter API</div>
<div id="preViewMap">Loading Google Map</div>
</body>
</html>

As you can see, the BODY of the page is exceptionally simple; just two DIVs with ids set and some basic content. All the hard work is done by the Javascript in the HEAD of the page. So how does it all work? The ‘preView.js’ script creates an object called PreView which pulls together jQuery, Google Maps and Twitter.

jQuery

jQuery is a library that extends the Javascript language and makes it easier to perform Web 2.0 functionality in a way that works independent of your users’ browsers. You can find good tutorials on jQuery all over the Internet and the docs are pretty good too, with lots of examples. One thing that I discovered the hard way is that your CSS links must appear before loading jQuery or else you can find you have problems when you try to access CSS properties in later code. For the life of me, I can’t figure out why this is so, but that’s how it works.

Other people might say Prototype or YUI. I haven’t used either of those, so I can’t comment, but I will be learning Prototype soon, since it underpins a lot of the webOS language.

Google Maps

The next step is to create your map. I used the Google Maps API for this. To access the API, you need to get a key from Google. This allows them to track how people are using their API and who is making requests. Your API key is associated with a specific domain, so for preDevCamp, we need 3 keys; one for ‘.com’, one for ‘.org’ and one for ‘.net’.

In addition to pulling in the Google Maps API, we used the Marker Manager for handling all of those little Palm Pres dotted over the map. The Marker Manager improves performance of map panning by only drawing the Pres that are currently visible. As preDevCamp grows, we’re going to have more and more Pres on the map, so this will get more an more important.

Once the API is loaded, you have access to all of the Google Maps commands. The API documentation is the best place to go to understand what each object does, but here’s a breakdown of what PreView does:

1. Locate the destination DIV for the Google Map
2. Create the GMap2 object and associate it with this DIV
3. Add a small Zoom control
4. Centre the map on 50n,0E. This is in the English channel, directly south of London. There’s no great geographical significance of this point, but it makes for a map that feels reasonably centered, with regard to land masses.
5. Set the map to a Physical map instead of a Satellite Image map
6. Create a new Marker Manager and associate it with the map
7. Make a JSONP call to the preDevCamp website requesting the location of all the preDevCamps. This returns an array of JS objects, each containing the Name, Longitude and Latitude of each preDevCamp city (see geocoding below)

That’s it for creating the map!

Geocoding

Geocoding is the transformation of an address of some sort into a latitude and longitude. Google Maps provides a geocoding interface and you can translate addresses on the fly if you need to. However, the geocoding service is rate limited and if you request too many, too quickly, your requests will get rejected. In addition to this, it takes a certain amount of time to send the request and get a response. As a result, the geocoding results have been cached on the preDevCamp server and are taken from there. This also allows us to handle ambiguous locations, such as “Washington” or “Charleston”, which could refer to a number of locations. Since we know which city each preDevCamp is in, we can add special handling for cities such as these.

That said, the geocoding service is used to find the Latitude and Longitude of Twitter users, based on their reported location.

Twitter API

Once the map is created, all that remains is to query Twitter for relevant Tweets. Like the Google Maps API, the Twitter API is really well documented. They actually have 2 APIs. One is for searching the Twitter public time line, the other is for interacting more explicitly with Twitter. One thing to note is that the Twitter API is also rate limited. You’re restricted to 100 API requests per hour, unless you get a special dispensation from Twitter.

So, the first step PreView takes is to find out how many API requests are available. It also checks to see when this limit will be reset and will use that later on, if the limit is exceeded

PreView continues by sending out searches for ‘predevcamp’, ‘webos’ and ‘palm pre’. Each of these requests generates a list of Tweet objects which are put onto a central list which sorts by each Tweet’s ID. The ID is globally unique. At this point, PreView does not filter duplicated Tweets, but a future version will.

The next step is to go through the list one at a time and display the Tweet on the map. In order to do this, we take the location property of the Tweet and send it to the Google Geocoding Service. Although this Service is rate limited, we only show Tweets once every 8 seconds or so, so we’re not going to hit the rate limit that Google sets. However, asking Twitter where a user is located, does count against our Twitter API usage, so we make sure to cache users’ locations to prevent the limit from being gobbled up.

If the user’s location does not translate, we put the Tweet somewhere in the middle of the Pacific Ocean. There may be a better way to indicate that Tweet cannot be located but, again, that is deferred to version 2.0.

Once all of the Tweets in the list have been shown, we send a second request to the Twitter Search API. Twitter has a neat trick to help us here. When we send a search request , Twitter gives us a list of Tweets as well as a URL that we can use later which essentially says: “Show us the Search Results starting from where we left off in the last search”. This means we don’t need to filter for Tweets that we’ve already seen.

Summary

Hopefully, that’s given you an overview of what I sought to achieve with the preView map. By looking through the source code and reading this post, you should be able to see what it takes to make something like this. The astute of you will also see areas where preView could be improved and, when I have time, I’ll be taking a second run at it. However, for now, I hope that it proves to be an instructive read!

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.

Lot’s of people have been writing about Bespin, including Whurley, and I’ve got to say, I’m not sharing the general enthusiasm for the release.

Don’t get me wrong, I think the idea of a code editor which is inherently connected to the web is a great idea, but let’s not get over-excited about what was presented and what has been promised.

First, what was actually released last week? It was a text editor with syntax highlighting for 3 languages. It provides line numbering. It dos not allow you to paste from your clipboard, as I discovered to my dismay. It does not allow you to create new files. It does not allow you rename files… in fact it basically allows you to do nothing but alter the contents of 3 files that are pre-generated for you. I’ve been using code editors that blow this functionality out of the water for years.

I watched the demo video and was stunned that a reasonable amount of time was spent extolling the virtues of the scroll-bars. Now don’t get me wrong; these guys have done some neat coding to work with the <canvas> element and to get this working, but the net achievement was to implement scroll-bars… hardly an innovation. While this may be no mean feat, I’m not going to switch to a new editor because it has… tada!… scroll-bars.

I think the release of Bespin in its current form was a mistake. The demo showed no innovation in terms of functionality or usability. In fact, right now, it’s a retrograde step. It provides no means for coders to extend it, by adding their own commands or syntax highlighting files or other such modifications.

Now, let me comment on the future of coding in the cloud. There already exist a wide variety of frameworks that allow multiple coders from disparate locations to work on the same code base. I’m not saying they’re perfect, but the idea of remote collaboration is not a new one. For coding in the cloud to really be effective, it needs to bring something radically different. It also needs to bring something that couldn’t be achieved with an Eclipse plugin or the suitable modification to your IDE of choice. The big promise of code computing is that it could allow peer programming with remote peers. Imagine a code editor with built-in webcam support so that you and a peer can work on the same piece of code (updated real-time on both screens), while being able to talk ‘face to face’. Now that I could get excited about!

Let me finish by saying that I don’t wish to denigrate the efforts of these guys; I think the goal is commendable and could bring exciting things to the act of coding. However, what I saw this Friday was technology for it’s own sake… and poorly presented at that. I want to see Mozilla provide us with a demo that does something new and invites users to actually try it out for real and start to add their own tweaks and flair. You never know, they might come up with the next great feature!

Like a fair number of people, I have a number of Twitter identities. I have my personal identity (@dancrumb) as well as a number of shared identities that represent events or organizations in which I’m involved.

I use a number of clients to send out tweets, but all of these clients limit you to a single identity. If you want to user twitter.com to send out messages, you need to log in with the appropriate identity before you perform any Twitter functions.

Herein lies the problem. When you’re logged in to Twitter and you navigate to somebody’s Twitter page, there is no indication as to who you’re logged in as. The risk is that you could elect to follow or message someone, thinking you’re logged in as one identity, only to find that you’re logged in as another identity. I did precisely this, yesterday. As luck would have it, the person was my sister and I quickly spotted my mistake, but if  you’re using Twitter as a major communication channel, you need to be very aware of which identity you’re tweeting with.

In order to address this, I’ve written a small Greasemonkey script. You can access it here. You’ll need to have the Greasemonkey plugin installed, of course.

Once the script is installed, you will be able to see who you’re logged on as, in the Twitter navigation bar at the top right-hand corner of the screen, at all times.

I hope you find it useful; I know from experience that I will…