JavaScript laden zonder de browser te blokkeren

Er zijn heel veel factoren die invloed hebben op de snelheid waarmee een webpagina wordt afgebeeld. Zaken zoals het aantal requests per pagina, het wel of niet gebruik maken van een Content Delivery Network, het instellen van gzip voor bepaalde type content en een juiste plaatsing van scripts en stylesheets in de pagina, dragen allemaal bij aan de ervaring die de gebruiker heeft als hij de pagina opvraagt. Als de ontwikkelaar te veel van deze zaken fout aanpakt, dan zal hij de woede van de gebruiker op zijn hals halen en wellicht hevig bloedend ergens in een greppel treurig aan zijn einde komen.

Er zijn twee lekker pragmatische en niet te dikke boeken over deze onderwerpen geschreven die ik even wil aanstippen: “High Performance Web Sites” en “Even Faster Web Sites”, beide van Steve Souders (http://stevesouders.com/hpws/rules.php). Beide boeken zijn binnen ISAAC in ieder geval verplichte kost voor alle web develeopers.

In deze blogpost wil ik een van de technieken uit het tweede boek kort introduceren: “JavaScript laden zonder de browser te blokkeren”. Het probleem dat hier speelt is dat scripts die worden geladen m.b.v. een SCRIPT tag tot gevolg hebben dat de browser helemaal niets anders zal downloaden tijdens het laden en interpreteren van deze code. Dit alles kan resulteren in een significante verlenging van de laadtijd en dus tot een tragere pagina. Zonde, want browsers kunnen in theorie meerdere bestanden parallel downloaden.

De reden dat de browser niets anders downloadt is dat de JavaScript die op dat moment wordt gedownload de rest van de pagina kan wijzigen na executie. Het aantal en de volgorde van de andere resources kan afwijken van wat er in de oorspronkelijke HTML is gespecificeerd (bv met de document.write(…) constructie). Dit wijzigen van de HTML is in het overgrote deel van de gevallen helemaal niet aan de orde en resulteert dus in een onnodig lange laadtijd. Daarnaast is de volgorde waarin externe JavaScript bestanden zijn gedefinieerd in de HTML tevens de volgorde waarin ze moeten worden geëxecuteerd door de browser. Deze executievolgorde is eigenlijk niet van belang voor de volgorde waarin de scripts worden gedownload, iets dat tot nu toe alleen de ontwikkelaars van IE8, Safari 4 en Chrome 2 hebben begrepen: deze browsers ondersteunen het parallel downloaden van scripts wel. Andere resources worden echter wel nog steeds geblokkeerd.

In “Even Faster Web Sites” worden een aantal technieken geïntroduceerd die dit probleem (ten dele) oplossen. Ik zal deze hier kort introduceren. Voor de details verwijs ik echter door naar het boek zelf.

XHR Eval.
In deze techniek worden de scripts met een XMLHttpRequest gedownload en vervolgens met een aanroep van eval() geïnterpreteerd. Dit werkt: de browsers blokkeren het downloaden van de andere resultaten niet. Het grote probleem is echter dat je op deze manier alleen scripts kan laden die van hetzelfde domein komen als de pagina zelf.

XHR Injection
Deze methode lijkt enigszins op de voorgaande: het script wordt geladen mb.v. de XMLHttpRequest functie, maar wordt geëxecuteerd door een SCRIPT tag in de DOM te creëren en de gedownloade code daarin te injecteren. Deze methode is soms iets sneller dan het gebruik van eval(), maar lijdt onder dezelfde beperkingen.

Script in Iframe
Iframes worden parallel geladen met andere componenten op een pagina. Door in iframe’s HTML pagina’s te laden die verwijzen naar de gewenste scripts, worden deze scripts dus parallel gedownload. Ook deze techniek is beperkt tot scripts die op hetzelfde domein staan als de hoofdpagina zelf. Bovendien moet de code worden aangepast om een verbinding tussen de hoofd- en de iframepagina te leggen.

Script DOM Element
Als alternatief voor het initieel opnemen van een SCRIPT tag in de HTML, kan er ook een on-the-fly worden gecreëerd m.b.v. document.createElement(…). Deze tag wordt dan dynamisch voorzien van een src attribuut en vervolgens in de HTML geïnjecteerd. Deze methode is geschikt voor scripts die komen van een andere domein dan het domein van de pagina zelf.

Script defer
IE ondersteunt het DEFER attribuut bij de SCRIPT tag. Defer is een indicatie aan IE dat het gerefereerde script geen DOM wijzigingen zal uitvoeren en dat het niet meteen hoeft te worden gedownload. Dit heeft tot gevolg dat IE andere bestanden parallel met dit script zal downloaden. Het werkt echter alleen in IE en enkele nieuwe browsers.

Document.write Script tag
In deze techniek wordt net als bij de “Script DOM Element” methode een SCRIPT tag dynamisch aan de HTML toegevoegd, dit keer echter met een document.write() constructie. Het verschil is dat deze techniek alleen resulteert in het parallel downloaden van andere scripts, alle andere bestanden worden toch geblokkeerd.

Conclusie
Na het lezen van de technieken lijkt het redelijk simpel: kies altijd voor de “Script DOM Element” methode. De realiteit is echter niet zo eenvoudig. De keuze hangt af van het gewenste gedrag van de “busy indicators” in de browser (de visuele hints die aangeven dat er iets wordt gedownload) en van de wens om de download- en executievolgorde af te dwingen. Voor meer details over wanneer je nou precies wat moet kiezen verwijs ik je graag door naar hoofdstuk 4 van “Even Faster Web Sites”.

Magical Magento

ISAAC en e-commerce is al tijden een succesvolle combinatie. Tot dusver heeft ISAAC altijd maatwerk webwinkels gerealiseerd, met name omdat veel van onze klanten de webwinkel volledig geïntegreerd willen hebben met reeds bestaande back-end en beheer systemen. Maar sinds enige tijd hebben de technische specialisten van ISAAC zich verdiept in open-source e-commerce pakketten die alle broodnodige functionaliteit , voor een succesvolle webwinkel aan boord hebben. Ook de sales afdeling en de internet marketeers hebben de producten eens goed tegen het licht gehouden op basis van de wensen uit de markt en de aanwezige kennis van succesvolle webwinkels.

Nadat de stofwolken geklaard waren en de nodige pakketten getest waren, stond nog maar 1 pakket in de arena overeind: Magento.

Op technisch gebied is Magento een relatief jong open-source product. Dit heeft een aantal voordelen, bijvoorbeeld dat het product moderne en beproefde technieken gebruikt.
Een plugin systeem laat ontwikkelaars modules realiseren met extra, maatwerk, functionaliteit. Het voordeel van deze werkwijze is dat de kern van de applicatie, de webwinkel zelf, altijd stabiel draait zelfs als een module niet correct functioneert. Omdat de applicatie open-source is, is hierdoor ook een enorme bibliotheek ontstaan met reeds gemaakte modules. De webwinkel uitbreiden is dan ook op deze manier doorgaans het spreekwoordelijke “plakje cake”: zoek of iemand reeds een module heeft gemaakt voor het doel wat je wilt bereiken, download en installeer het….tadaaaa.
Naja, uiteraard zal het in boze echte wereld altijd iets anders werken: doorgaans moet je nog configureren, testen eventueel nog wat aanpassen voordat het werkt zoals je wilt. Maar, je hoeft in ieder geval niet altijd het wiel volledig overnieuw uit te vinden.
Op het gebied van aangeboden functionaliteit kun je een e-commerce product beoordelen op 4 primaire pijlers, namelijk “Komen, Kijken, Overtuigen en Kopen”. Ik zal Magento eens afzetten tegen deze 4 pijlers.

Komen

Zoek Machine Optimalisatie is natuurlijk het kernpunt van de pijler “Komen”. Magento is uitstekend doorzoekbaar voor zoek machines en biedt uitgebreide mogelijkheden op het gebied van tags, keywords, URL rewrites et cetera. Dat klinkt als en is een boel terminologie uit de IT, maar het zijn wel de zaken die Google graag ziet en jij dus wilt hebben.

Andere functionaliteiten die Magento ondersteunt is “tell a friend”, waarmee de bezoeker een vriend of vriendin op de hoogte kan stellen van een product op jouw website. Ook kan een bezoeker een verlanglijstje sturen naar zijn vrienden met producten uit de webwinkel.

Kijken

Zodra een bezoeker uiteindelijk in de webwinkel terecht komt, is het uiteraard de bedoeling dat de klant alle informatie snel en eenvoudig kan vinden. Magento biedt alle mogelijkheden hiertoe, zoals een goede zoekfunctie en uitstekende sorteer en filter mogelijkheden.
Zodra een bezoeker een product heeft gekozen, kunnen ook accessoires voor het en soortgelijke producten getoond worden. Het gehele kijk, vind-wat-je-zoekt aspect is keurig geregeld in Magento.

Overtuigen

Uiteindelijk gaat het er natuurlijk om dat een klant overtuigd wordt om een product aan te schaffen. Op internet kun je dan geen dialoog aangaan met je klant om er achter te komen welke beweegredenen belangrijk zijn voor de klant. Je zult dus een heel arsenaal aan overtuigingsmiddelen in moeten zetten, en dan ook nog op dusdanige wijze dat de bezoeker de voor hem relevante middelen snel en eenvoudig kan inzien.
Voorbeelden van overtuigingsmiddelen zijn uitgebreide productomschrijvingen, grote foto’s, vergelijkingsmogelijkheden, duidelijke communicatie omtrent organisatie, contactmogelijkheden, geaccepteerde betaalwijzen, bezorgkosten, aanbiedingen (van….voor….), productreviews, orderstatus, Top 5 best verkocht, actiecodes, tijdelijke aanbiedingen.
Al deze zaken zijn te realiseren in Magento op een gebruiksvriendelijke wijze waardoor u als ondernemer snel en eenvoudig uw acties kunt coördineren.

Kopen

Zodra een bezoeker in uw webwinkel terecht gekomen is, het product wat hij zocht gevonden heeft en er van overtuigd is om het aan te schaffen, is alleen het afreken proces nog een mogelijke drempel. In het kijken en overtuigen aspect zijn al zoveel mogelijk drempels weggehaald door een duidelijke communicatie over totale kosten (inclusief de bezorgkosten), over geaccepteerde betaalwijzen en levertijden. Een heldere en gebruiksvriendelijke afrekenprocedure is belangrijk waarbij een bezoeker er voor kan kiezen om een account aan te maken of om zonder account de bestelling te plaatsen. Een bezoeker kan een ook een ander bezorgadres kiezen of de datum en tijdstip voor aflevering.
Wederom geeft Magento de mogelijkheid om het check-out proces helder en laagdrempelig te houden. Daarnaast biedt het ook de vrijheid aan ontwerpers om het design te optimaliseren voor conversie.

Zoals gezegd is het mogelijk om nog een laatste pijler toe te voegen, namelijk retentie. Ook hiervoor biedt Magento weer mogelijkheden met nieuwsbrieven, actie mogelijkheden voor groepen gebruikers.

Inmiddels zijn de eerste Magento webwinkels door ISAAC gerealiseerd of in ontwikkeling. We kunnen stellen dat de ISAACi enthousiast zijn over de vele standaard mogelijkheden in dit pakket terwijl we toch onze dingen kunnen blijven doen: een unieke oplossing of dienst neerzetten die bijdraagt aan de bedrijfsdoelstelling zonder concessies te doen aan nieuwe of bestaande processen.

Wilt u ook weten wat Magento voor u kan betekenen, neem even contact met mij of mijn collega’s op, we maken graag een afspraak om de mogelijkheden die Magento biedt, te laten zien. Ik ben te bereiken op 040 215 53 52 of Paul.Luedke@isaac.nl.

OWASP

Nee, dit gaat niet over een in cirkeltjes rondzoemende wesp uit Silicon Valley, maar over the Open Web Application Security Project. Met het mission statement van http://www.owasp.org/ schiet je al wat meer op bij het begrijpen van deze obscure afkorting. Daar lezen we in een Wiki-achtige layout namelijk:

“[OWASP] is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks.”

Het meest bekend is OWASP van de “Top 10”, een lijst met de tien belangrijkste kwetsbaarheden in (o.a. Java Enterprise Edition) web-applicaties. Deze lijst is behoorlijk pragmatisch tot stand gekomen, wat een goed gevoel geeft. Het gaat niet om zuiver theoretische chasing-a-once-in-a-million-cases, maar om heel concrete zaken die (te) regelmatig fout gaan bij de beveiliging (en dus ontwerp en ontwikkeling) van een webapplicatie. OWASP maakt elke paar jaar een nieuwe versie van de Top 10, uiteraard steeds pas wanneer de omstandigheden voldoende veranderd zijn. De huidige versie is die van 2007, en ten opzichte van 2004 (de vorige versie) zijn er wat items van de lijst verdwenen (o.a. buffer overflows), en wat andere toegevoegd.

Aandacht voor zaken op de OWASP Top 10 tijdens het hele ontwerp- en ontwikkelproces zorgt voor betere, veiligere, en, uiteindelijk, goedkopere webapplicaties, in elk geval qua total-cost-of-ownership. Soms is een OWASP-check min of meer verplicht, bijvoorbeeld om een PCI-DSS “audit” door te komen. De kans op grootschalig misbruik van je applicatie is dan wellicht niet zo groot (tenzij je Amazon, Ebay, Rabobank of PayPal heet natuurlijk), maar *als* het mis gaat zijn de gevolgen ook voor kleinere sites niet makkelijk te overzien.

De Top 10, versie 2007 (tromgeroffel! Uiteraard schaamteloos onder Creative Commons geript van de Wiki van het nogal trage OWASP.org zelf):

A1 - Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

A2 - Injection Flaws
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

A3 - Malicious File Execution
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

A4 - Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

A5 - Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

A6 - Information Leakage and Improper Error Handling
Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

A7 - Broken Authentication and Session Management
Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

A8 - Insecure Cryptographic Storage
Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

A9 - Insecure Communications
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

A10 - Failure to Restrict URL Access
Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

Genoeg aandachtspunten dus!

Google haalt software uit beta

Het is ongelooflijk, maar Gmail is eindelijk niet meer in beta. Naast Gmail, die vijf jaar in beta heeft gestaan, zijn ook Google Docs (2006), Calendar (2007) en GTalk (2005) uit beta gehaald.

Mobiele variant van de Monitor Applicatie

De afgelopen maanden heeft Roel geploeterd om voor ISAAC een applicatie te maken die de monitor tool van LaSer kan weergeven op een mobiel device, waaronder een blackberry. Dit moest hij voor elkaar krijgen zonder enige voorkennis over Java, JBoss, Eclipse en browsermogelijkheden van mobiele apparaten... een hele opgave dus.

Maar, afgelopen week is hij geslaagd en heeft hij de eerste versie van de 'mini monitor' klaar. Het is een hele basic HTML versie die precies doet wat de gebruiker wil: in één oogopslag zien of er iets mis is, en zo ja wat er mis is en waardoor het komt. Zo kan de gebruiker direct actie ondernemen als hij even zijn blackberry checkt.

Tijdens zijn afstuderen kwamen er wel enkele interessante zaken naar voren, bijvoorbeeld de beperktheid van de browserfunctionaliteit van veel mobiele devices. Ze hebben allemaal vaak andere standaarden en ondersteunen niet allemaal hetzelfde (IE6-7-8, firefox, opera... all over again). Er is dus helaas geen eenvoudige manier om een website mobiel-proof te maken. Daar zullen we nog even mee moeten wachten totdat de mobiele devices de 'standaard browsers' gaan draaien of meer gaan ondersteunen.

Ook bleek dat java niet zo eenvoudig is als het lijkt, in elk geval voor mensen die meer ervaring hebben met script-talen. Dat heeft Roel met de harde hand ondervonden, maar hij is er uiteindelijk toch wel enigszins uitgekomen (met een beetje hulp). En hij was erg enthousiast over de Expression Language, en daarmee scoor je natuurlijk ook punten bij mij ;)

Website optimalisatie

Moderne websites zitten tjokvol afbeeldingen en "rich" onderdelen (javascript libraries als JQuery of Dojo) en hoewel bijna iedereen tegenwoordig ultrasnelle internet verbindingen heeft is het aan te raden om je website te optimaliseren. Door dit te doen laadt de pagina sneller en is de user-experience dus beter. Een goed begin om iets over website optimalisatie te leren is door het boek "High Performance Websites" te lezen. Hierin staat in detail uitgelegd waar je op moet letten bij het maken van een website. Hieronder vind je een overzicht van de grootste snelheidswinsten die je kunt behalen.

- Het aantal HTTP requests beperken
- Javascript en CSS verkleinen
- De site gzippen
- CSS sprites gebruiken

Hiernaast zijn er nog veel meer mogelijkheden om snelheid te winnen, zoals het plaatsen van css files bovenaan in de webpagina en javascripts juist onderin, het vermijden van CSS expressies en redirects voorkomen. Maar we beperken ons nu tot de bovenstaande technieken omdat deze de grootste winsten boeken.
Het aantal requests beperken kan een behoorlijke winst opleveren. Stel dat je site zes javascript files inlaad. Hiervoor zijn dus ook zes requests nodig. Deze requests zitten op elkaar te wachten en dit kan dus voor een behoorlijke vertraging zorgen. Het aantal request kun je beperken door de zes javascript files te bundelen tot een enkele file. Dit zorgt ervoor dat de scripts niet op elkaar hoeven te wachten en met 1 request ingeladen kunnen worden. Naast de javascript bestanden kun je ook kijken naar de stylesheets die worden ingeladen en afbeeldingen. Afbeeldingen kun je ook bundelen tot een enkele afbeelding met behulp van CSS sprites. Een CSS sprite is eigenlijk een grote afbeelding met alle afbeeldingen op de site naast elkaar. Door in je CSS aan te geven waar je afbeelding begint, kun je de enkele afbeelding voor alle afbeeldingen op de site hergebruiken en hoeft er dus maar 1 afbeelding ingeladen te worden.

Naast het verminderen van het aantal requests die gedaan worden kan ook het verminderen van de hoeveelheid data een snelheidswinst opleveren. De hoeveelheid data die je verzend kun je verminderen door, bijvoorbeeld, javascript en css bestanden te "minify-en". Je haalt dan alle overtollige tekens uit de bestanden (zoals enters, spaties, opmerkingen) waardoor de files stukken kleiner worden. Daarnaast kun je de hoeveelheid data verminderen door de site te g-zippen. gzip is een protocol die door de meeste browsers wordt ondersteund en de hoeveelheid data met 70 tot 80 procent kleiner kan maken.

Frontcontrollers

Tijdens het volgen van een SCWCD (Sun Certified Web Component Developer) training kom je de coolste dingen tegen om een webapplicatie te ontwerpen en implementeren. Er wordt voortdurend op gehamerd dat je elk component in een webapplicatie (POJO, EJB, Servlet, JSP e.d.) moet gebruiken waar het voor dient, en ze niet misbruikt door bijvoorbeeld logica in een JSP te gaan stoppen omdat dat ook wel werkt. Neen! Men doet er verstandig aan de verschillende lagen van een applicatie te scheiden, het voornaamste voorbeeld hiervan is het MVC (Model-View-Controller) model. De details hiervan laat ik even achterwegen (Wikipedia is your friend) maar kort gezegd krijg je door dit model te implementeren een applicatie waarin de bussiness logic, het ophalen van data uit de bussiness logic en het tonen daarvan van elkaar gescheiden zijn.

Bovenstaande kan gerealiseerd worden door in bijvoorbeeld een servlet de bussiness logic (via EJB o.i.d.) aan te spreken en het resultaat te delegeren naar JSP's die gevuld worden met deze data. Echter is dit model op deze manier ook niet perfect. In een website met omvangrijke grootte kan het schrijven van dergelijke code redundant en onoverzichtelijk worden. Je voelt het misschien al aankomen, maar inderdaad, ze hebben ook hier iets op gevonden. Een techniek (eigenlijk een design-pattern) met een vrij algemene naam "frontcontroller". Frontcontrollers zijn kleine frameworkjes die je kunt gebruiken om de code die je in je controllerlaag gebruikt om de bussiness logic aan te spreken evenals de code die je gebruikt om de view-laag aan te spreken in herbruikbare objecten te stoppen. Op die manier hoef je code om requests af te handelen niet steeds opnieuw te schrijven voor elke servlet die je in je applicatie gebruikt. Dit leidt al gauw tot meer overzicht in de code die makkelijker onderhoudbaar is. Een belangrijke kenmerk van een frontcontroller is dat het een centraal punt vormt in een applicatie voor het ontvangen van requests en het delegeren daarvan.

Een keerpunt van een dergelijke techniek is dat je al je logica zult moeten implementeren in de frontcontroller, wat tot heel wat configuratie en omslachtigheid kan leiden. Bijvoorbeeld het delegeren van een bepaald request naar een bepaalde servlet kun je dan niet even snel met een RequestDispatcher doen, maar je zult een object moeten schrijven dat de configuratie en logica voor die delegatie bevat. Op die manier is het gebruik van een frontcontroller aan de ene kant een zegen en aan de andere kant een vloek. Zoals een bekende voetballer ooit zei (ja, Kruijff): elk noadeel heb een foordeel!

Een bekende Java implementatie van een frontcontroller is Jakarta Struts, wat niet bij iedereen geliefd is. Dit geldt echter ook voor Spring, wat minder bekend is maar ook gebruikt wordt in de webwereld om je controller en view netjes neer te zetten. Spring heeft echter ook roots in de modellaag, eigenlijk een frontcontroller++ :P. Beide technieken implementeren het frontcontroller pattern op hun eigen manier, en je wilt ermee werken of niet. Mij persoonlijk lijkt het gebruik van Struts wel interessant, en misschien zelfs wel nuttig. Echter denk ik niet dat je het moet gebruiken in websites van kleine omvang omdat je dan waarschijnlijk niet het potentieel eruit haalt.

Open Source

Open source wordt vaak gezien als iets dat te maken heeft met software. Zo kennen we veel handige open source tools in het land van Java. Voorbeelden hiervan zijn onder andere Hibernate als ORM laag tussen databases en de eigen Java applicatie en Wicket een web framework voor java.

Maar er zijn ook nog andere vormen van open source. Zo is er bijvoorbeeld de "open game license", ontworpen voor role playing games. Deze licentie is in 2000 ontworpen door Wizards of the Coast voor het 'd20 systeem'. Helaas is er ook kritiek op de licentie, onder andere door de controle die Wizards of the Coast er over heeft, aangezien deze een aantal uitgevers de kop gekost heeft.

Nog een interessant open source product is de openmoko. Dit is een open source smartphone waar alle aspecten van de telefoon open zijn gehouden (met uitzondering van een aantal chips, voor zover ik weet), dus niet alleen de software. Je kunt de schemas van de electronica en de CAD files gewoon downloaden op de website. Wel moet er gezegd worden dat het nog een "work in progress" is. De software om alle hardware aan te sturen is nog niet af. Zelfs de hardware heeft nog bugs, maar dat is op te lossen voor mensen die niet al te bang zijn en durven te solderen in hun telefoon. Gelukkig is de tweede versie van de telefoon (GTA02 Freerunner) al een stuk beter als de eerste. De volgende blog post zal de openmoko verder uitdiepen.

Meer Taart voor ISAAC

Een van de ISAAC teams werd vandaag blij verrast met taart. Laser Nederland, Een van ISAACs partners, heeft vandaag taart laten bezorgen als dank voor de extra inzet rondom nieuwe release.

Wij zijn natuurlijk erg blij dat onze inzet wordt gewaardeerd. Dus Laser Nederland bedankt!

Van ontwikkelomgeving naar test- en productieomgeving

Een van de dingen waar een applicatieontwikkelaar mee te maken krijgt, is het configureren van de software voor verschillende omgevingen. De applicatie wordt ontwikkeld op een ontwikkelomgeving, gaat daarna in het algemeen naar een omgeving waar de klant een en ander kan bekijken en testen, en wordt vervolgens op een productieomgeving geplaatst, al dan niet na een aantal aanpassingen. Deze omgevingen hebben hun eigen instellingen nodig. Bij het uitrollen van een nieuwe versie van de applicatie naar een omgeving moet de omgeving de juiste instellingen krijgen en/of houden. Er zijn veel manieren om dit mogelijk te maken, een van de eenvoudigste is via files in verschillende bestandsformaten. Er worden dan verschillende files gemaakt met per omgeving de specifieke configuratie. Vaak is er een file met standaard instellingen, die overschreven kan worden om specifieke eigenschappen aan te passen. Deze files moeten op een goede manier worden beheerd en uitgerold. Er zijn veel verschillende frameworks en tools om dit te realiseren. Een ervan is de Commons Configuration van het Apache Commons project, te vinden op de Apache website. Hiermee kan configuratie worden ingelezen vanuit bijvoorbeeld properties files, XML files, Windows INI files, System properties, etc. Eigenschappen kunnen meerdere waardes hebben indien gewenst, en zijn bovendien van een bepaald type. De toegang tot de eigenschappen verloopt via de generieke Configuration interface.
ISAAC heeft inmiddels in verschillende projecten naar tevredenheid gebruik gemaakt van de XMLConfiguration van Apache Commons. Handmatige aanpassingen na het uitrollen van een applicatie zijn voor deze projecten niet meer nodig.