A few days ago Zattoo updated their client, and guess what, it didn’t work on Linux anymore. Using the error messages I was able to guess which libraries were missing: I had to install the xulrunner (it looks like they use the Mozilla API to display the channel browser).
But when trying to run the client I got still more errors, the problem is that Zattoo uses some strange library name convention, so we have to create the links to the actual libraries, so we have to run the following as root:
I still get some errors about the missing flash-plugin, but that’s just an annoying dialog box that can be closed by clicking ok. From thereon it should work like a charm
JSONP feeds are great! They allow you to access information in a secure way across domains, build slim mashups and keep the load off your own servers. Sadly though they aren’t as widespread as many of us would like them to be, still RSS Feeds and Atom Feeds have the majority. But now Google comes into play: the new Service from the GoogleAjax API’s team Google AJAX Feed not only translates RSS and Atom Feeds into JSONP Feeds, but also caches them for you, speeding up the loading, and keeping the load off the publishers side (a feature Digg & Co. will be grateful for).
And so with only a few lines of code
<html>
<head>
<script type="text/javascript" src="http://www.google.com/jsapi?key=YOUR_KEY_HERE"></script>
<script type="text/javascript">
google.load("feeds", "1");
function initialize(){var feed = newgoogle.feeds.Feed("http://www.digg.com/rss/index.xml");
feed.load(function(result){if(!result.error){var container = document.getElementById("feed");
for(var i = 0; i < result.feed.entries.length; i++){var entry = result.feed.entries[i];
var div = document.createElement("div");
div.appendChild(document.createTextNode(entry.title));
container.appendChild(div);
}}});
}google.setOnLoadCallback(initialize);
</script>
</script></head>
<body>
<div id="feed"></div>
</body>
</html>
Some weeks ago
Google has added a nice new feature to their GData libraries: JSON data retrieval. This means
that we now can retrieve data from some services of Google (Base, Blogger and Calendar for
now) without having to proxy it through our servers (if you still don’t know, after thousands
of posts about Cross-Domain issues, why you need to do this, just look
here).
Why can we do this? Because we can just create a <script>-Element, points the src to the
feed URL and tell the GData API what function to call upon load.
var headTag = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = feedurl;
headTag.appendChild(script);
I was a bit sorry to see that Google doesn’t
provide an API for Client side JavaScript. So once again, in one of those “don’t complain,
do it better“-moments I figured it would be nice to write it myself for the Calendar.
Off course some stuff can’t be done with JavaScript, we can only retrieve data, not submit new
data to Google, so we can’t add new entries directly, but hey it’s a start
The library
We start off by modelling the Entry class, as you might easily figure out by the following code
we rely on the Prototype library.
Notice the first line of the loadFeed? Yep, it’s a workaround, and an ugly one too. The problem
is that we want to have access to the Calendar-object once we have the feed data. So we add it
to the window-object. Anyway, this is the reason why you can load only one calendar at once.
And what would we be without some really ugly utility objects? So here you go, a pretty useless
date converter class:
/**
* Singleton object used to convert Dates from one format to another.
*/var DateConverter = {
rfc3339toDate: function(t){
t = t.substr(0,19).replace(/-/g,"/").replace("T"," ");
var dt = new Date();
dt.setTime(Date.parse(t));
return dt;
}};
So after all this code that you don't have to write (because you can
download it all here) now
some code you have to write.
How to use it
I tried to keep it as simple as possible, if there are enough requests I may well extend it
further, but for now it works nicely as it is. First you have to find out the feed identifier.
Take the Feed URL as can be found in Google Calendar in the Calendar details and it will look
something like this:
And that's it
Now let's see what we can do with it, and the reason I started fiddling with the Calendar in
the first place. My custom frontend to one of my calendars can be seen
here.
The people that are currently working on OpenID have come up with a new problem with the protocol: bots. You know those annoying programs that create hundreds of accounts and just spread spam and hatred all over the net? Well the usual way to keep clear of bots is adding a CAPTCHA to the site, but that would be a step backwards for OpenID. You see OpenID is all about Single Sign-On, easy registration and just plain easiness, while Captchas add a stop in the word flow, an undesirable interruption. Why require users to enter them over and over and over again? That’s exactly where BotBouncer comes into play:
I’m excited to announce BotBouncer.com which is a free service that we’re releasing today. BotBouncer allows sites to verify that an OpenID has successfully entered a CAPTCHA. BotBouncer works as web service that sites can subscribe to with a unique API key. As users login to an OpenID enabled site that site can query BotBouncer to see if that OpenID has entered a CAPTCHA. If they have, it quietly logs in the user via the existing OpenID process. If it doesn’t, the user is sent to a page where they must enter a CAPTCHA. Once they have successfully entered the CAPTCHA, they are redirected back to the page from where they came from.
I personally like BotBouncer, it adds an extra Karma Point to my account, now I can prove that I’m human once and never bother again. I wouldn’t rely only on BotBouncer though, because it requires you to trust BotBouncer, no big deal there, but most importantly you’d close out everybody that hasn’t registered with it. Just add a Captcha for users that haven’t yet registered with BotBouncer.
[via Kveton.com]
John Ferguson Smart has written a great tutorial about how to integrate the Google Maps API with Java Servlets. He starts off with the usual introduction to Ajax, but soon goes on to more interesting topics, and after just a few lines he already has a fully functional Map in his application.
function load(){if(GBrowserIsCompatible()){var map = new GMap2(document.getElementById("map"));
map.setCenter(new GLatLng(-41.5, -187.5), 5);
map.addControl(new GSmallMapControl());
map.addControl(new GOverviewMapControl());
}}
Details are then added a few at a time, and what he ends up with is a fully fledged Maps Application, with asynchronous fetching of data and detail Overlays.
function processSiteData(xmlDoc){// obtain the array of markers and loop through it
siteMarkers = xmlDoc.documentElement.getElementsByTagName("marker");
displaySitesMarkers();
}function displaySitesMarkers(){
map.clearOverlays();
for(var i = 0; i < siteMarkers.length; i++){// obtain the attributes of each markervar lat = parseFloat(siteMarkers[i].getElementsByTagName("latitude")[0].firstChild.nodeValue);
var lng = parseFloat(siteMarkers[i].getElementsByTagName("longitude")[0].firstChild.nodeValue);
var id = siteMarkers[i].getElementsByTagName("id")[0].firstChild.nodeValue;
var label = siteMarkers[i].getElementsByTagName("name")[0].firstChild.nodeValue;
createSiteMarker(new GLatLng(lat,lng),label,id);
}}
All is explained step by step and is really easy to follow, if only all tutorials were this easy
P.S.: I like people that aren’t too shy to add some humour to their posts:
Of course, the advantage of storing geographical site coordinates in a database is that they can be updated as necessary; for example, in the case of a major earthquake or land slide, or continental drift, or to keep track of the famous migrating mud-transporting camel caravans of the central Elbonian steppes.