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.