Wednesday, April 30, 2008

I happened upon the Official YouTube Gadget for iGoogle the other day and thought it would be a fun project to replicate it using the myriad of Google API's that are now available. From the developer perspective, this mini application is entirely client side JavaScript - as the Google API's take care of any server side processing.

My workings...

That said, I needed to re-engineer the greater part of the widget using the available Google APIs.

Google AJAX Search API approach

I initially thought the widget would be driven primarily by Google AJAX Search API due to their support for YouTube search access (Direct Access to YouTube Channels). This support means that using a GvideoSearch for ytfeed:recently_featured would return a JSON object containing all the detail you need about that feed. However, the support for YouTube feeds is limited to variants of most_viewed, recently_featured and top_rated (and YouTube channels). The major reason that I chose to abandon this avenue was that the search API provides very limited results (GSearchgoogle.search.Search.LARGE_RESULTSET = 8 results!).

The problem with using the YouTube RSS 2.0 feed is that the supplied feed is not valid RSS 2.0. The duration attribute is not a supported part of RSS 2.0. Therefore, when you fetch the feed via the Google AJAX Feed API you get no duration information.

To get the complete behaviour required for the widget (with durations and more than 8 results), I have to use the GData YouTube feed. In the GData feed the duration information is inside a special YouTube namespace. For parsing elements that are within namespace to work across browsers you will need to make use of the Feed API's google.feeds.getElementsByTagNameNS. A slight down side to using the Google AJAX Feed API to fetch the feeds is that each feed is cached for about an hour.

Conclusions

A very enjoyable experience (a couple of days messing about!). I hope this offers some insight into some of the problems you might run into when working with the Google APIs. The final widget comes pretty close to the functionality of the official gadget and I'm sure I could polish this further.

Friday, April 25, 2008

I was browsing the Google AJAX Search API blog recently when I discovered they were using an interesting widget at the bottom of the page, it turned out to be PartnerBar. PartnerBar was created as an example for the Google AJAX Feed API. I have been very busy with family stuff recently so I managed to completely miss this when news of it first broke in December (Ajax Feed Partner Bar and The PartnerBar - Contextual Cross Linking). In my defence this is easy to miss, it is called "PartnerBar", which means nothing to anybody on this side of the pond and the launch article talks about "contextual cross linking" (meaningless technobabble!). Essentially, PartnerBar is a feed aggregating magic javascript widget thingy, if it had been launched as such I would have spotted it sooner.

Anyway I have been playing with it recently and have made some minor tweaks to improve it for my own usage, I'm very happy with the results. I can't decide whether to install the resulting widget permanently on my blog because I think people would find it annoying if I were to place it somewhere prominent.

My tweaks and modifications

Feed titles and links.

Incidentally, notice how it supports tags so that you can use the same array for multiple widgets with distinct content.

My first modification was to tweak the code so that I did not have to supply the feed name and link, this information is stored in the feed (why store it twice?). To achieve this I overrode the loadPartner method - I think the trick with overriding methods in JavaScript is to make sure the method you override is a small one!

Alternating row colours

Secondly, I wanted the feed entries to display in alternating colours. Again, I found a small JavaScript method in PartnerBar (resetClassOnPartnerDom) and overrode it (AFAIK there is no "super" keyword in JavaScript, which is a shame). In order to do this I made use of a getElementsByClassName method that I found on the web.

Friday, April 18, 2008

I have been experimenting with the Google App Engine (GAE) recently which is a Google hosted Python application server. I am not a native Python programmer (I've written about 5 scripts in my life). Even so, GAE is a great toy to play with.

Python on GAE

There are currently some weaknesses in the implementation of Python available in GAE (re: C libraries, XML parsers, XSLT engines) but this is a preview release and all things considered it is a very impressive offering. Why Python? We are told that "Google are huge fans of Python" and it is evidently used extensively inside Google. One of Google's other "hosted" platforms, Google's Mashup Editor, is a JavaScript application server running on top of Java, so Google obviously have experience in the Java application server area. As a Java programmer, I would get more excited if I could upload WAR files to GAE (even if I had to use proprietary Google Java APIs for some things) but you can't win them all. You never know, Java support could be just around the corner.

I'm new to writing Python web applications and so far it reminds me of writing Perl CGI code. This is not the best way to write web applications and I miss JSP at this point. There must be better ways of doing this using wsgiref and the Django framework which come pre-installed in GAE. These may help me get around the "scriptyness" of my python web application programming. My writing simple python web applications experience has surprised me somewhat as I had been drip fed with the idea that Python was a more efficient language (and hence better!) than Java/JSP (but I suspect I'm not doing it right!). So far it seems that you have to write a lot more Python code than the equivalent in JSP e.g. to get a parameter from an URL:

To be absolutely honest, I have never liked the conditional expression tenary operator (e.g '?' above) syntax and in this case I would prefer something more verbose but this illustrates the potential efficiency inherent in contemporary JSP.

Worries about using GAE as a commercial platform?

If I were a business with an interest in using GAE commercially, storing my valuable data in proprietary Google storage would worry me somewhat. There are open source versions of BigTable available (e.g. HBase, HyperTable) and these owe there existence to Google but as there is not yet a standard "GQL" mechanism, data exit strategies seem limited.

I would be greatly concerned that my applications are hosted by Google and that my Python developers were exposed to Google. GAE could be described as a lobster pot. Getting Google to host your business means that Google are in a prime position to absorb successful businesses, steal talented developers, learn more about your business quicker than you can yourself and learn from your mistakes.