Following this trend, one of the main differentiators between URL shortening services is the reporting that they offer back to you. URL shortening services have been around for several years but were made hugely popular with the arrival of Twitter. With a 140 character limit on posts, you don't want URL's taking up over half of your allocation! It's also not surprising that in backing http://bit.ly that Twitter have pushed that service to prominence ahead of all the others. There are plenty of alternatives out there including one of the earliest players, http://tinyurl.com, and http://tr.im. As well as appearing in Tweets, they are commonly used in print publications, partly to give readers a shorter URL to type in, but also so that editors can track reader response.

If you want to choose between URL shortening services, there are several things to consider:-

• The overall length of the URL: the difference between 'tinyurl.com' and 'j.mp' might make all the difference to you!
• The reliability of the service: the service has to be running for anyone to follow your links
• The reporting metrics behind the service: what statistical breakdown do you get and how reliable are the stats?
• The viability of the service: in August 2009 http://tr.im announced that they were closing; they reversed their decision days later but neither their, or any other operator's, long term assurance can be guaranteed

Here's another issue to consider...who can view your metrics? Stats made available by http://bit.ly and sister service http://j.mp are available to everyone! To view stats on any of their URL's, just add a '+' onto the URL and see just how many followers there have been. This may not bother you, but there are plenty of instances where you may not want your information available to the world! It does make interesting data though. Legendary Tweeter Stephen Fry currently has well over 1 million followers, and links in his posts and direct messages attract somewhere between 12,000 and 30,000 clicks...many advertisers would be pleased with a response rate of 2%!

Oh dear.

Like the cancellation of Concorde, who thought it was a good idea to reduce the number of thumbnails on the startup screen from 9 to 8?

If anything we need the option to increase the number (12 or even 16 would be cool on my screen) and reducing the number actually negates one of the reasons I use chrome in preference to other browsers.

So come on google ... give us our thumbnails back!

www.mindsizzlers.com/presentations/amazon_simpledb/

The site works like this.

Ever hour, Google trends publish data about the hot search terms as determined by analysis of their US based users.

We then run a search against each of the top 100 search terms to find the top sites that web users will be visiting as a result.

We show you this information, together with a thumbnail of the website (made by another mindsizzling service we will soon be launching to the public) which makes it very quick and easy to see if the site is something you are interested in.

If you find it useful, do let us know ...

I've been using XML::XPath to extract the data from the xml, so I can write this sort of thing;

my $xp = XML::XPath->new( xml => $xml );
foreach my $walk ($xp->findnodes('/walks/walk'))
{
my $walkid = $walk->findvalue('./@itemname');
etc ...
}


It's easy to write, easy to read and works well. However recently I've begun noticing that the project has become a bit, well, sluggish. I was kind of hoping that XPath would be using the C (and hence very fast) LibXML under the hood since I had recently installed that parser on the system, however the lack of speed led me to think this might not be the case.

Reading around, I discovered that there already is XPath support built in to LibXML and so I was able to rewrite my code as follows;
my $parser = XML::LibXML->new();
my $doc = $parser->parse_string($xml);
my $xp = XML::LibXML::XPathContext->new($doc->documentElement());

foreach my $walk ($xp->findnodes('/walks/walk'))
{
my $walkid = $walk->findvalue('./@itemname');
etc ...
}


Note how it is just the setup that has changed, the actual data processing stays the same (in most cases).

This makes things *MUCH* speedier as you would expect. My perception is perhaps as much as 10 times faster for large XML files, but I haven't done any quantitative analysis.

BEWARE though, it's not a completely transparent drop-in as the parser in LibXML has some quirks. For example if there is a namespace declared in the xml file, then you will get no data returned unless you correctly attach this to the context.

For example, when writing an Atom parser, note the registerNs line

$PARSER = XML::LibXML->new();
$DOC = $PARSER->parse_string($xml);
$XP = XML::LibXML::XPathContext->new($DOC->documentElement());
$XP->registerNs( xatom => "http://www.w3.org/2005/Atom" );

foreach my $data ($XP->findnodes('//xatom:entry/xatom:content[@type="text/xml"]'))


This despite the fact that inside the atom feed, NO namespace is explicitly used in elements. The atom file contains <entry> and NOT <xatom:entry> but you MUST attach a namespace to be able to read the data. You could choose any namespace, I picked xatom but it could just as well have been fred. Go figure ...

Google seem to have acknowledged this is an issue, but they acknowledged it 2 years ago and have done nothing since - presumably for their own good reason - however for someone developing tools against the API, it can be a real headache.

Enter the open source community and a great product by Lance Dyas called GeoXML which is a new parser you can use for KML files (and much more) within the Google Maps API. And the BEST feature ... well for us, it DOES allow you to open links in placemark info windows in the SAME browser window. Great!

Beware that sadly the project lacks any real documentation and getting started can be rather hard. The documentation for another project EGeoXML is a useful starting point.

I was a bit surprised that this hadn't been addressed by the Amazon community at large so I took a few days (well, a week) out of my schedule to pull together www.backupsdb.com - the world's first online backup solution for Amazon SimpleDB.

We launched it last week and you can read more over at the backupsdb blog

The author of the tool has gone on to pastures new and seems hard to track down, so it was down to us to come up with a solution if we wanted to keep our project on track.

Detailed analysis of the google maps groups led Roger to discover that only this week, google had deprecated use of any api version prior to 2.140 and it transpired that quikmaps was developed with version 2.(0)50 although we had it running with 2.(0)85. This was a clue, and reading through the change logs for each api version gave a further clue with the discovery that the markerinfowindow code had been taken out of the main google maps api and modularised so it would load on demand ... in theory!

The way that quikmaps manipulates the DOM with prototype meant that the google api wasn't realising that the markerinfowindow module was in fact being demanded and so the solution turns out to be to force the map to pull in the infowindow module by simply adding in editor.map.getInfoWindow().show() after the map is instantiated in the browser.

Full details here;

http://groups.google.com/group/Google-Maps-API/browse_thread/thread/77feb23b5f004dac#