Best of this Week Summary 23 June - 28 June 2008

• This post summarizes the key parts of the LinkedIn architecture (40M pageviews/day). Full presentations also available. Lots of Java. Below an architecture overview diagram from one of the presentations:
  
  
• Overview of the plans of the BBC for their application/website infrastructure: moving it from mainly Perl and static files to SOA, Single SignOn, REST, Java and PHP.
  


• Orbitz (the online travel booking agency yes) is open sourcing their Extremely Reusable Monitoring API (ERMA) and Graphite this coming Monday. Here's why they're open sourcing their ERMA and Graphite, which are "part of a Complex Event Processing system designed to monitor large distributed applications, analyze the data that is gathered and display that data in real-time graphs."
  


• All of Google's Data APIs now support oAuth. So no need anymore to store a username and password in web applications that use one of Google's Data APIs. Recently also PhotoBucket and SmugMug announced oAuth support.
  

Best of this Week Summary 16 June - 22 June 2008

• Nice (basic) overview on the architectural challenges Twitter has regarding updating thousands of followers when a user posts a message.
  


• Ten good tips to improve your XML effectiveness and efficiency.
  


• References to good articles on scaling and performance tuning monitoring of MySQL.
  


• This article examines Firebug and YSlow as tools for analyzing and improving performance of Ajax applications.
  


• What are some of the the architectural challenges for mobile applications in the web 2.0 era?
  


• Examples of some major enterprises where Adobe AIR ("the cross-OS runtime that lets you run rich internet applications on your desktop") is already being used. They include Nasdaq, Deutsche Bank.
  

How to sign a Firefox 3 addon

Of course you've noticed that Firefox 3 has been released (and that it didn't go that smoothly, trying to break the world record).


One of the major changes in the new FF3 release is that add-ons (plugins, extensions, whatever you wanna call it :-) need to either use an HTTPs updateLink, or if it is an HTTP updateLink, you need to sign the .xpi. The exact info on how to do this is quite scattered, so here I summarize it all in one place, in three steps! :-)

Below I'll focus on Step 2 mentioned in the high level migration steps: providing secure updates.

Step 1
Add the updateKey tag to install.rdf inside the em:updateKey tag. For details see here. Follow the mentioned McCoy link. In short: create a key with the tool, rightclick on the key you created, select Copy and put that inside em:updateKey tags within install.rdf, below em:updateURL.

Step 2
Create the .xpi and add its sha1 hash (right click on the .xpi + select properties in Windows.) to update.rdf as mentioned here. Note that you should put the em:updateHash below each em:updateLink you have in your update.rdf. Also don't forget the sha1: prefix.

Step 3
Add the signature to update.rdf. See here for an example signature. Select the key you used in Step1 in the McCoy tool. Click Sign in the menu. You'll be prompted to select your update.rdf. It will then generate (and overwrite!) your update.rdf, with the em:signature in it. I guess you can reuse this generated update.rdf for next updates (you'll need to re-hash and re-sign it when you update it), but to be save I also made a backup copy of my original update.rdf).

All in all not too complex, but the information was scattered. Useful in getting my mind around it and how it all relates was this thread.

Best of this Week Summary 31 May - 08 June April 2008

• Interesting article on how to do estimates with Use Cases.
  


• The Google Ajax APIs will be available via cached versions for faster load times, stored at Google's servers. Hmmm, doubt that you want to depend on that...
  


• An insight in Google's datacenters. Definitely worth reading. Google's core software consists of: GFS, BigTable and MapReduce.
  


• The OpenAjax Alliance has created a set of papers "as a guide to help Web developers and IT managers understand and evaluate Ajax, define a successful Ajax strategy, and become familiar the important role OpenAjax plays in the development of the Ajax market". This one is an interesting one as it describes Ajax for mobile devides. On the other hand, browsers like Opera can already handle (some form) of regular Ajax, so is it worth making the distinction?
  

Google Friend Connect vs MySpace Data Availability vs Facebook Connect

More and more users are not spending time on one website anymore. And users are getting "tired" of entering their contacts ("social network") every time again and again. The big social websites are realizing that and have created their own solutions to that. Well, potentially not their own solutions, but more their own branded solutions for what's defined by the Dataportability group.

The three announcements were:

Google's FriendConnect. It should give users a shortcut to social connections they have built on different social networks. The user can login with their Facebook, Plaxo etc accounts, allow the FriendConnect enabled site to retrieve the friends on that site, and if they're online, the user can interact with them. FriendConnect will use open standards like OpenID and oAuth. Biggest disadvantage is that an iFrame will be provided as the solution, so no API will be made available. Note that this makes Google the big switch between all these social networks! Since they don't really have a (big) social network site, this is their way of getting a piece of the cake: sitting right between all the social network sites! Some other concerns can be found here.
MySpace Data Availability. A bunch of launch partners will be able to access MySpace user data and be able to present it outside the regular MySpace widgets. MySpace users should be able to revoke the rights of the third party anytime. The third party is not allowed to store the retrieved user data. The good thing here also is that it will be made available via a REST API.


Facebook Connect. In short, the new API will give third parties' users the ability to transport the relationships from their Facebook accounts to the third parties' website. Compare it with what's now already available for Facebook applications (running on the Facebook platform) being made available for third parties. Immediately a big "chick fight" broke out, because apperently Google's Friend Connect is not respecting Facebook's user privacy control, as Facebook blocked FriendConnect! But it might just be Facebook protecting it's own turf :-)


Relationship with Dataportability.org
"The DataPortability Workgroup is actively working to create the ‘DataPortability Reference Design’ to document the best practices for integrating existing open standards and protocols for maximum interoperability (and here’s the key area) to allow users to access their friends and media across all the applications, social networking sites and widgets that implement the design into their systems."
So, let's hope the above initiatives will comply with the standards defined by the DataPortability Workgroup.


Relationship with OpenSocial
Both Google and MySpace are in the OpenSocial Foundation ("a common API for social applications across multiple websites. Built from standard JavaScript and HTML"). For MySpace their Data Availability project is outside the OpenSocial framework, but will stay involved in it too and incorporate when available.


The current status
All three are announcements are kind of the "branded" version of DataPortability implementations within the respective organisation. The furthest seems to be MySpace:
Facebook: no technical specifications released
MySpace: rolling out with only a few launch-partners
Google: not ready to launch yet.