Best practices for mashups

This is a first attempt to identify the do's and don'ts - Best Practices - concerning Mashup development. Googling for "mashup best practices" does yield a few usefull results, like for example:

The blog post "Towards best practices for mashups" by Mark Baker
The blog post "Mashups: Business Models and Trends" by Richard McManus on ZDNet

But because of the "newness" of mashups, we haven't collected much practical wisdom about them yet (or I have just not been looking hard enough). Therefore, I decided to approach these best practices from different directions by looking for best practices for aspects of mashups. Mash these together and you get (tada): best practices for mashups.

So far I have (just briefly) explored these mashup aspects:

• Web API dependancy
• Security & safety
  
• Usability
• Maintainability
• Browser compatibility

There's a convention too: identified Best Practices are indicated in blue with BPx, with x being the identified BPs index (for convenient cross referencing).

Web API dependancy:
Mashups combine functionality from several different Web APIs. This makes a mashup dependant on the availability and stability of those WebAPIs. As a consequence, a Mashup's "use-by date" is limited to the earliest use-by date of the Web API's it depends on. Web API providers periodically introduce new versions of the APIs, and usually keep old and new versions alive for some time. But at some point, the old versions will be shut down. By that time, all mashups still depending on the old version will become invalid.

BP1: Keep Web API interfaces stable. It is safe to add new functionality. But it is unsafe to modify the signatures of existing API interface methods. Ensure downward compatibility

BP2: Make Web API functions robust and flexible in the data it accepts (e.g. date formates, zip code formats, et cetera).

Security & Safety:
A mashup basically is a web application. All kinds of dangers (cross scripting, javascript injection, et cetera) are lurking in the dark, looking for weak spots in your application to target their attack at. Fortunately, there are a lot of best practices for web application security, thanks to the Open Web Application Security Project (OWASP)

One important thing OWASP advises is to always assume the worst about data posted to a web service. Validate, validate, validate.

BP3: Validate all data that a web service receives (with respect to for example Javascript Injection)

Usability:
A Mashup is doomed if its user interface does not meet the user's objectives and expectations. Know the user, know what his/her objectives are. Design a user interface that helps the user to meet these objectives efficiently and effectively.

BP4: Make interaction designs, build UI prototypes and do usability tests.

Maintainability:
Mashups are very often built using Ajax. Roughly said, Ajax = Javascript + DocumentObjectModel? (DOM) + XmlHttpRequest?. Javascript is a nightmare for systems administrators. Building clean and maintainable code in javascript is no sinicure. It takes immense discipline. Furthermore, Ajax development and debugging tools are still in their infancy. However, some Ajax frameworks do a very neat job in keeping manual javascript coding to an absolute minimum by providing rich, out-of-the box UI widgets and allow developers to construct the application's views in a declaritive way.

BP5: Use a professional, proven Ajax framework (which one? GWT? Tibco General Interface? Backbase?)

Browser compatibility:
Javascript behaves differently in different browsers. This puts the stability and availability of an Ajax application directly in the hands of the browser vendors. Professional Ajax frameworks do a fairly good job in hiding these browser differences from the developer.

BP6: Either decide to support only one browser (which is perfectly okay for intranet/extranet applications) or avoid manual Javascript coding alltogether (in which case you should really consider BP5).

I am convinced that I could find much more best practices using this approach. But for now, I'll leave it at this.

RUPje nooit genoeg (dutch)

Zoals zovelen heb ik ook te maken met het Rational Unified Process (RUP). Ik heb intussen een aardige stapel boeken erover gelezen en grapte tegen mijn vrouw dat ik bijna zelf wel een boekje zou kunnen schrijven en dat ik het dan de titel "RUPje nooit genoeg" zou geven, naar het beroemde kinderboek van Eric Carl over een hongerige rups die uiteindelijk een prachtige vlinder wordt.

Dat boekje schrijf ik vast nooit, maar ik vond het wel eens geinig om te zien wat ik met het idee kon. Zie het als een poging van een vader om aan zijn zoontje van 4 uit te leggen wat papa toch allemaal doet op zijn werk:

In het maanlicht lag een eitje op een blad.

Toen op een mooie zondagochtend de zon opkwam, kroop uit dat eitje...KRRRRAK!...een ijverige RUP en ging op weg naar de klant om een systeem te ontwikkelen.

Op maandag schreef het RUPje 1 verhaaltje waarin alle problemen stonden die met het nieuwe systeem opgelost moesten worden.

Op dinsdag maakte het RUPje een 2 hele mooie tekeningen met heel veel poppetjes en ovaaltjes. Nu wist het RUPje precies voor wie het systeem belangrijk is en wat ze met het systeem willen bereiken.

Op woensdag tekende het RUPje wel 3 tekeningen vol met mooie blokken, ruiten en pijlen. Hij was er erg trots op. Voor 3 van de ovaaltjes wist het RUPje nu wat de poppetjes die deze ovaaltjes vast hielden precies zouden gaan doen en wat het systeem ze moest laten zien.

Op donderdag maakte het RUPje nog eens 4 tekeningen met blokken, ruiten en pijlen. De klant was erg blij met de mooie tekeningen, want hij zag dat het RUPje goed naar hem had geluisterd.

Op vrijdag maakte het RUPje wel 5 vellen vol met blokken en ruiten en pijlen. Nu had het RUPje eindelijk alle ovaaltjes gehad.

Op zaterdag had het RUPje het heel erg druk. Hij:

• maakte een tekening van een lasagna die wel 5 lagen had,
• schreef een griezelverhaal over dingen die wel eens mis zouden kunnen gaan, maar ook wat het RUPje ging doen om ervoor te zorgen dat die enge dingen niet konden gebeuren.
• knutselde en sleutelde het RUPje een eerste voorbeeld van het systeem in elkaar. De klant vond het al heel mooi en zei dat het RUPje op de goede weg was, maar dat sommige dingen niet goed waren.
• maakte wat nieuwe blok-ruit-en-pijl-tekeningen
• knutselde verder aan het voorbeeldsysteem. Nu was het wel goed
• schreef een boekje over apies
• schreef een boekje voor beheersbeestjes
• knutselde en timmerde en puzzelde net zo lang tot het hele systeem helemaal klaar was
• at een enorme pizza en een hele fles cola
• probeerde het systeem stuk te maken door op alle knopjes in te drukken en ook nog eens allemaal tegelijk, maar het systeem ging niet stuk
• pakte het systeem mooi in, samen met alle tekeningen en boekjes die het had gemaakt
• en hielp de klant met uitpakken en het in gebruik nemen van het systeem

.....toen had RUPje pijn in zijn portemonnee.

De volgende dag was weer een zondag. Het RUPje nam nu een vers blaadje en schreef daarop een verhaaltje over wat hij allemaal goed had gedaan en wat hij allemaal fout had gedaan. Het RUPje voelde zich nu al veel beter.

Het RUPje was ook niet meer klein. Het was een grote dikke RUP geworden. Deze grote dikke RUP bouwde een huisje voor zich zelf dat "archief" genoemd wordt. In dit archief bleef hij bijna 2 weken zitten. Toen ging het archief open en kwamen er allemaal prachtige lessen en cijfertjes uit. Lessen die nieuwe RUPjes leren dat ze niet dezelfde fouten mogen maken als vorige RUPjes. En met de cijfertjes kunnen nieuwe RUPjes voorspellen hoe veel pijn zij in hun portemonnee gaan voelen.

Einde

Natuurlijk schetst dit verhaaltje wel een heel voorspoedig verlopen project en zou het RUPje nog veel meer gedaan kunnen hebben. De strekking is eigenlijk voornamelijk dat nieuwe projecten bij zaken als planning, kostenschatting en oplossingen kijken naar eerdere projecten. Meten en vastleggen van dit soort kennis is dan erg belangrijk. Als organisatie wil je bereiken dat de kwaliteit van projectresultaten steeds beter wordt. Maak processen op zijn minst reproduceerbaar (ontwikkel standaarden) en doe steeds je best om kwaliteit van processen te verbeteren.

Mijn eerste mashup (dutch)

Nog maar eens een Web 2.0 definitie: Web 2.0 biedt een globaal en universeel platform voor de ontwikkeling en verspreiding van interactieve web toepassingen. Zo'n toepassing combineert doorgaans functionaliteit van diverse Web Services en maakt gebruik van RIA (Rich Internet Application) principes voor de realisatie van de user interface. De populaire naam hiervoor is "Mashup". Voor deze mashups wordt doorgaans een zeer lichte vorm van service orientatie toegepast dat Web-oriented Archtecture (WOA) wordt genoemd.

Een google search op mashup levert veel resultaten, waarvan de opvallendste de mashup matrix van programmableweb.com is. Op programmableweb.com worden alle Web APIs verzameld en kunnen kruisingen tussen Web APIs worden gevonden. Een hele gave website!

Onderstaand plaatje toont de populairste Web APIs (van de afgelopen 14 dagen)

Er is ook een Mashup Howto op deze website te vinden. Met deze howto ben ik dan maar eens aan de slag gegaan.

Ik wilde beginnen met iets eenvoudigs. Uiteraard iets met Google Maps (vrij letterlijk "hello world" dus). Na wat grasduinen in de diverse APIs viel mijn oog op de Web API van Geonames.org. Met deze API kun je o.a. postcodes, plaatsnamen en weersgegevens vinden bij geografische coördinaten.

Ik besloot daarom een online postcodezoeker (postal code mapper) te maken. De postcodezoeker maakt het mogelijk om de gebruiker door aanwijzen van een plek op een geografische kaart postcodes in de omgeving van ze plek te vinden. De postcodezoeker probeert verder op basis van het IP-adres van de gebruiker te bepalen in welk land de gebruiker zich bevindt en zal bij het laden de kaart van dat land tonen.

De GoogleMaps API komt in de vorm van een Javascript class library. Het is zeer goed gedocumenteerd en erg eenvoudig in gebruik. In minder dan 10 minuten heb je een web-pagina met een interactieve wereldkaart erop. je hebt er een (gratis) key voor nodig die gebonden is aan het webdomein van jouw applicatie.

Geonames.org biedt diverse web services rond geografische data zoals postcodes en plaatsnamen, maar ook meer informatieve data zoals recente aardbevingen, actuele weergegevens en wikipedia artikelen gekoppeld aan geografische coordinaten.

Alle Geonames services zijn gebaseerd op REST en de meeste hebben zowel een XML als een JSON interface.

De Geonames Web API is eenvoudig van opzet en redelijk goed gedocumenteerd. Door de mogelijkheid JSON te gebruiken is de aanroep van deze services vanuit Javascript erg eenvoudig. Jammer is de inconsequente naamgeving van data attributen tussen de diverse service outputs en zelfs tussen de XML en JSON variant van dezelfde service.

Het is heel eenvoudig om met deze twee APIs snel iets werkends te krijgen. Door de toepassing van JSONRequest kun je zonder dat je daarvoor op een eigen server een gateway hoeft in te richten, web services aanroepen uit verschillende web domeinen. Met de XMLHttpRequest kan dit niet zondermeer vanwege de same origin policy.

Ik heb ervoor gekozen om geen gebruik te maken van een Ajax toolkit omdat ik geen gebruik maak van geavanceerde UI widgets. Ik maak voor het updaten van de user interface gebruik van eenvoudige DOM-manipulatie. Een absolute aanrader en musthave bookmark voor Ajax doe-het-zelvers is overigens Quirksmode.

Mijn knutselwerkje kun je hier bekijken. Best een leuk resultaat, al zeg ik het zelf.

Startblok (dutch)

Daar zit ik dan. Mark's blog account is een feit en ik zit in de startblokken om mijn hoofd helemaal leeg te bloggen.

Even een kleine profielschets van mezelf: Ik ben een doorgewinterde IT-er. Een soort senior Dilbert maar dan zonder stropdas. Daar laat ik het maar even bij.

Ik ben momenteel helemaal in de ban van het fenomeen Web 2.0. Aanvankelijk was ik er sceptisch over. Maar toen ik me er wat meer in verdiepte sloeg mijn scepsis snel om in enthousiastme. Laat je niet misleiden door zijn trendy naam. Het is nou eenmaal de naam die is blijven hangen. Het schijnt nu zelfs een beschermde naam te zijn. Je mag kennelijk niet zonder toestemming van Tim O'Reilly de naam Web 2.0 gebruiken voor je conferentie. Digg that!

Ik ben al een tijdje bezig om een beeld te vormen van Web 2.0. Wat is Web 2.0 nou eigenlijk? Waarom houden zoveel mensen zich ermee bezig? What's all the fuss?

Mijn huidige beeld van Web 2.0 is die van een dubbelloops WWW: iedereen is zowel auteur als lezer, zowel producent als gebruiker, zowel recensent als vergelijker, enz. De meest succesvolle internetbedrijven verdienen dankzij dit principe daadwerkelijk geld met internet (eBay, Google, Amazon, MySpace). Dat vind ik nogal wat.

Vanuit Dilbert's perspectief zie ik natuurlijk een soort lasagna. Er zitten vertrouwde lagen in. De onderste laag is een dikke, vette supergeschaalde, gedistribueerde data laag. De kwaliteit en beschikbaarheid van die data is van levensbelang.

Op de bovenste laag overheerst Ajax. Daar vlak onder zitten webservices. Web 2.0 applicaties ondergaan meerdere releases per dag, soms per uur! Tja, wat wil je ook als de web services waarvan gebruik wordt gemaakt kunnen bederven. Interfaces staan niet vast. Er wordt van de afnemers verwacht dat ze de houdbaarheidsdatum van de services goed controleren. Dat is toch om gek van te worden? En toch werkt het. En hoe!

Dit is mijn eerste concrete bijdrage aan het Web 2.0. Waar stijgen dan nu de banksaldo's als gevolg daarvan?