DeveloperDerby 2008

Februari 2008 - 7 februari was het weer zover, Whitehorses organiseerde een nieuwe editie van de DeveloperDerby, een interne ontwikkelwedstrijd. Na een succesvolle editie in 2007 was het animo voor deze DeveloperDerby nog groter, met maar liefst 6 teams die de strijd met elkaar aan gingen. Ook ditmaal was de opdracht voor de teams simpel, bouw in anderhalve dag zoveel mogelijk functionaliteit van een vooraf gedefinieerde case, met een zelf gekozen technologie en een Oracle database op de achtergrond.

In het volgende verslag is te lezen welke technologie deze opdracht het best wist te voltooien.

Commercieel directeur Frank Dorst en organisator Martin Schapendonk.

De case: Whinny

Vanuit Whitehorses medewerkers is er een groeiende behoefte om actuele informatie te hebben over het wel en wee van de collega's. De te bouwen case is een applicatie genaamd Whinny, die inzichtelijk moet krijgen wie de collega’s zijn, wat ze zoal bezighoudt en over welke kennis ze beschikken.

Whinny is alleen voor intern gebruik en moet uiteraard via de browser te benaderen zijn. Na het registratieproces, waarbij een nieuw account geactiveerd moet worden door middel van een URL in een mail, moet ingelogd kunnen worden op "My Whinny". Dit is een dashboard waar de laatst geplaatste berichten en verjaardagen zichtbaar zijn. De belangrijkste functionaliteiten zijn het aanmaken en bijhouden van een profiel, gemakkelijk kunnen zoeken, tags aanmaken bij profielen en berichten plaatsen. Daarnaast zijn er nog additionele functionaliteiten zoals beheer mogelijkheden voor accounts, een tag cloud en als extra een CV database. En bij dit alles mag de veiligheid natuurlijk niet uit het oog verloren worden.

Jurering

Aan elke functionaliteit van de case werd vooraf een aantal punten gekoppeld, dus de teams moesten goed prioriteiten stellen aan de verschillende onderdelen van de case om bij de jury hoge ogen te gooien. Naast de beoordeling van opgeleverde functionaliteit werd dit jaar ook gekeken naar de Whitehorses waarden zoals innovativiteit, betrokkenheid, Agile & Lean development, samenwerking en simplicity.

Geen wedstrijd zonder jurering. De teams werden beoordeeld door een 3-koppige vakjury, die ook tijdens de wedstrijd nauwlettend de vorderingen van de deelnemers in de gaten hield. Middels korte interviews probeerden zij een goed beeld te krijgen van de gekozen oplossingen en de naleving van de Whitehorses waarden.

De vakjury: Marco Heerebout, Arianne van den Berg en Wessel van Norel.

Naast de vakjury is door de organisatie besloten om ook de mening van de deelnemers mee te laten tellen. Door een presentatie en demonstratie van de oplossing konden de teams hun collega’s al dan niet overhalen om extra punten in de wacht te slepen voor de eindoverwinning.

De teams

Sprinter - Team Sprinter maakte zijn debuut met de gekozen technologie : Ruby on Rails. Samen met de Netbeans IDE en de WebRick-webserver bleek het een gouden combinatie. Doordat model, view en controller netjes gescheiden geïmplementeerd kunnen worden, werd een overzichtelijk project opgeleverd, waarbij opviel dat het aangeleverde datamodel niet gebruikt werd. Deze keuze is gemaakt omdat Ruby de betekenis van kolommen, zoals primary keys en relaties, ontleent aan de naamgeving ervan. Het enige noemenswaardige probleem wat Sprinter eventjes heeft tegengehouden was het mailen van de activatielink. Er waren problemen met het ActionMailer framework, maar na lang zoeken bleek een simpele herstart van een webservice voldoende. Ondanks deze problemen heeft het team een schitterende applicatie gebouwd waar ook de jury erg van onder de indruk was.

De Wicketeers - Ook dit team heeft een nieuwe technologie geïntroduceerd voor de DeveloperDerby: Apache Wicket. Met deze technologiekeuze hoopten de Wicketeers de complexiteit van andere frameworks te omzeilen zodat ze zich volledig op de functionele aspecten konden richten. Een snelle start hebben de Wicketeers echter niet gemaakt. Problemen met deployment op een Tomcat j2ee-server heeft het team doen besluiten over te stappen op Jetty. Daarnaast bleken de ontwikkelde securityfeatures enkel op de testomgeving te werken. Uiteindelijk zijn de Wicketeers niet veel verder gekomen dan de registratieprocedure, maar de oplossing werd wel zeer hoog gewaardeerd op architectuur, innovativiteit en leesbaarheid van de programmacode. De rolverdeling binnen het team bleek ook dik in orde doordat een duidelijke scheiding van front- en backend mogelijk was.

de Wicketeers en team Sprinter staan lijnrecht tegenover elkaar.

M&M's - De zege van vorig jaar nog eens dunnetjes overdoen. Dat was het motto van team M&M’s dat met Oracle Apex vol vertrouwen de DeveloperDerby startte. Er waren weinig problemen met het oplossen van de functionaliteit, enkel het bouwen van het inlogscherm waarbij de gebruikersgegevens op een veilige manier opgeslagen en benaderd moest worden kostte relatief het meeste tijd, aldus de teamleden. Wel doken er wat infrastructurele problemen op. Voor het kunnen verzenden van emails met activatiegegevens voor de gebruikersregistratie moesten er nog instellingen gebeuren op de virtual machine met de ontwikkelomgeving die zich bij een teamlid thuis bevond. Vlak voor de eindoplevering sloeg echter het noodlot toe: de applicatie was niet meer te benaderen. De oorzaak was de crash van de virtual machine en tot overmaat van ramp wilde na een reboot de webcache van de applicatieserver niet meer starten. Ondanks de technische problemen leverde het team een goed werkende applicatie op, waarbij de meeste functionele eisen opgeleverd waren.

Spring in ’t veld - Met de combinatie Spring, Hibernate en JSF ging team Spring in ’t veld vol goede moed beginnen aan de case. Het opzetten van het project ging echter niet voorspoedig. De leden hadden verschillende versies van ontwikkeltools en java waardoor kostbare tijd verloren ging. Het genereren van Data Access Objects op basis van het aangeleverde datamodel zorgde voor veel problemen waardoor het team genoodzaakt was deze handmatig te coderen. Om dit alles nog met Maven als build-tool aan de praat te krijgen bleek erg moeilijk te zijn in de korte tijd die beschikbaar was. Uiteindelijk is er wel wat functionaliteit opgeleverd waaronder het inlog- en registratieproces en het bijwerken van gebruikersprofielen. Daarnaast heeft Spring in ’t Veld gebruik gemaakt van UML om processen van de case in kaart te brengen.

Ondanks wat tegenslag zit de sfeer bij Spring in 't veld er goed in.

FlexFuse - Het FlexFuse team probeerde dit jaar de oplevering van de Flexomaniacs van de vorige DeveloperDerby te overtreffen. Door het gebruik van AppFuse dacht het team een "kickstart" te kunnen maken met de voorgelegde case: het genereren van de projectstructuur en algemene oplossingen voor security en databasetoegang hoeven niet meer van begin tot eind opnieuw gebouwd te worden. Het bleek echter dat AppFuse niet goed raad wist met het genereren van javacode voor Flex. Na een mislukte poging om Flex aan te sluiten op een webservicelaag is gekozen om toch maar via POJO’s databasecommunicatie op te zetten. Deze problemen zorgden voor veel tijdsverlies, maar het ontwikkelen van de gebruikersinteractie ging daarna vrij vlot. FlexFuse kon de aanwezigen tijdens de presentatie dan ook verbazen met de mogelijkheden van Flex.

JHeadshots - Een samenstelling van ontwikkelaars met een "traditionele" oracle achtergrond wilde dit jaar een poging wagen met het Oracle ADF framework in combinatie met jHeadstart als generatietool. De Jheadshots kozen voor een duidelijke rolverdeling. Een persoon hield zich bezig met de database: het bouwen van de benodigde tabellen, views en PL/SQL-functies, de andere twee leden hebben gezamenlijk het ADF deel voor hun rekening genomen en daarbij de pair programming-techniek toegepast. Het streven van de jHeadshots naar volledige generatie van de applicatie werd helaas niet gehaald doordat de onderdelen van het dashboard niet allemaal tegelijk op een enkele pagina geplaatst konden worden via jHeadstart. Een ander probleem was de security. Er was bedacht dat een apart registratieformulier zou worden gebouwd, maar deze bleek niet publiek toegankelijk te kunnen worden gemaakt. Om dit probleem op te lossen moest dit formulier verplaatst worden naar de inlogpagina.

de JHeadShots geven een extra dimensie aan pair programming.

De uitslag

Nadat alle teams hun applicaties - voor zover als deze af waren - hadden getoond aan het publiek en de jury, was het tijd voor de eindbeoordeling. Het team M&M's (Apex) en team Sprinter (Ruby on Rails) hadden duidelijk de meeste functionaliteit weten te realiseren en dit was ook terug te vinden in de uitslag. Het publiek had z'n punten gegeven, en de M&M's waren hierbij de winnaar met een paar punten voorsprong op team Sprinter. De overige teams bleven hier op gepaste afstand achter. Het laatste woord was nu aan de jury, die de beslissende punten gaven en zij waren het heel erg eens met het publiek. En dus was de uiteindelijke winnaar, met voor het 3e achtereenvolgende jaar Apex als technologie: team M&M’s!

De gelukkige winnaars mochten als prijs een Nabaztag, het WiFi-konijn, mee naar huis nemen.

De gelukkige winnaars met hun Nabaztag WiFi-konijn.

De conclusie

De DeveloperDerby was ook in 2008 een erg geslaagd evenement. Er is hard gewerkt, maar zeker ook met veel plezier. Alhoewel niet iedereen het resultaat haalde waar vooraf op was gehoopt, heeft elk team veel geleerd over de technologie waar ze deze dagen mee gewerkt hebben. Een conclusie die vorig jaar ook getrokken werd: voorbereiding en testen van de gekozen technology-stack is essentieel om de gedoodverfde winnaars als Apex en Ruby volgend jaar een flinke slag toe te kunnen dienen.