Na een lange periode van radiostilte is de Nederlandse Java User Group NL-JUG weer tot leven gebracht. Sinds vorig jaar vindt er in de lente en de herfst een event van een gehele dag plaats, genaamd JSpring en JFall. Om de events bij te wonen, moet je lid zijn, maar dat moet geen probleem zijn want de contributie bedraagt EUR. 25,- per jaar en dan zijn de events gratis.
Oktober de twaalfde vond de JFall van 2004 plaats in de Reehorst in Ede. In de centrale ruimte was ruimte gemaakt voor stands van de sponsors, waaronder Quest en Sun. In de aangrenzende ruimten vonden een aantal parallelsessies plaats. Hieronder worden drie presentaties samengevat.
De eerste presentatie van de dag werd gegeven door Simon Phipps. Een interessante presentatie om bij wakker te worden, zoals Klaas Tukker (voorzitter van de NL-JUG) het uitdrukte. Hij vertoonde op zijn Apple Powerbook een grappig filmpje waarin drie kamergenoten met elkaar communiceren via instant messaging en mobiele telefoon terwijl ze alledrie aan de ontbijttafel zitten. Dezelfde ontbijttafel, wel te verstaan. De centrale boodschap was: we leven in een wereld waarin iedereen met iedereen is verbonden, "Massively Connected". Hierdoor zijn een aantal zaken verandert.
Phipps zag bijvoorbeeld een terugkeer naar het gilden-systeem. Deze organisaties van vaklieden waren honderden jaren lang de manier waarop professionals zich organiseerden, maar uiteindelijk verloren ze de strijd van de industrialisatie. Phipps trok parallellen tussen de gilden van weleer en de open source manier van ontwikkelen. Het verschil is echter, zo zei hij, dat gilden hun kennis binnenshuis hielden terwijl men nu juist geld verdient door die kennis te etaleren als open source en vervolgens te verkopen door middel van consulting.
Maar dat naar zijn mening was niet het belangrijkste kenmerk van open source. Hij sprak ook over het woord "free", dat in het Engels feitelijk twee betekenissen heeft: gratis en vrij. Open source is namelijk niet slechts gratis oftewel, kosteloos; het geeft ook een stukje vrijheid. De vrijheid om een andere leverancier te kiezen, of om de software zelf aan te passen. Verder brengt die vrijheid een hogere kwaliteit en veiligheid met zich mee.
Het publiek vroeg zich al af waar dit heen ging. De laatste tijd is Sun namelijk in het nieuws geweest omdat ze claimden dat ze de broncode van Java en zelfs hun eigen besturingssysteem Solaris gingen opensourcen. De controversie was de licentie: de broncode van Java is altijd beschikbaar geweest, maar mocht niet verder gedistribueerd worden. De community had gehoopt dat de bekende GPL of BSD licenties zouden gebruikt worden zodat Java met een Linux-distributie (zoals RedHat) meegeleverd kon worden. Maar dat was niet het geval: er kwam een nieuwe Sun-specifieke licentie die niet compatibel was. Echter, zo zei Phipps, dat maakte geen enkel verschil want er zijn meerdere soorten vrijheden. De GPL en BSD licenties geven de vrijheid om de code te distribueren. Daarentegen brengt de Sun-specifieke licentie compatibiliteit met zich mee! Hij gaf hiermee een interessante draai aan de discussie.
Naast design patterns zijn er nu ook project patterns. De heer Hoogendoorn hield de aandacht van zijn publiek stevig vast door de zaak om te draaien: als er project patterns zijn, dan volgt automatisch daaruit dat er ook project anti-patterns zijn. Dus: hoe kun je een project op een uitstekende manier laten mislukken, saboteren, de grond in drijven, et cetera.
Eerst gaf hij enkele statistieken. Volgens de Standish Group sterft 32% van alle projecten een vroege dood, 53% gaat 190% over budget en dan houden we 16% over die slagen.
Hij toonde vervolgens slides met elk een anti-pattern; de eerste was getiteld "Titanic Projects". Zeer grote projecten waar diverse afdelingen betrokken zijn, complex probleemdomeinen en developers zonder ervaring. Zulk soort projecten waren net als de Titanic gedoemd om halverwege de reis ten onder te gaan. Ideaal! aldus Hoogendoorn, want we zoeken in deze presentatie projecten die mislukken.
Daarna werd elke rol in een project onder de loep genomen. Als je klant bent en je wilt dat je project faalt, zorg dan voor torenhoge ambities en zoveel mogelijk buzzwords. Als je accountmanager bent en je staan op de golfbaan met je prospect, kweek dan onrealistische verwachtingen, "fake it until you make it".
Ook projectmanagers kwamen aan de orde. Als je projectmanager bent, dan ben je in een bijzondere positie om het project te laten falen. Voor die manager is de heer Winston Royce een ongekende held, want hij is de uitvinder van de waterfall methodiek. Het mooie van deze methode is dat er voor elke stap een terugkoppeling zat naar de voorgaande stap; echter dit is in een standaardisatie-slag door het Amerikaanse Department of Defense weggelaten! De ambtenaar die dit op zijn geweten heeft, is inmiddels kluizenaar en woonzaam in de bossen van Wisconsin. Na deze simplificatie zijn de verantwoordelijkheden keurig gescheiden. Project- en accountmanagers kunnen dus de analisten bij een andere klant zetten, wanneer de ontwikkelaars binnenkomen.
Naast waterfall is een ander aardig anti-pattern "death by planning", wat volgens Hoogendoorn ook wel "management by Excel" wordt genoemd. De projectmanager maakt tot ver in het jaar een gedetailleerde planning en is vervolgens elke week een dag kwijt aan het bijwerken van die planning. Dan blijven er uiteraard vier dagen over om naar andere klanten te gaan! Ook, zo zei Hoogendoorn, kun je als projectmanager inkorten op testen en aan het eind van het project nog ontwikkelaars toevoegen om de deadline te halen. Na deze uitspraak toonde de volgende slide Charlie Chaplin als The Great Dictator, voorstellend: de projectmanager als dictator. Deze manager geeft niemand verantwoordelijkheid, laat iedereen overwerken, maar acht zich bijzonder sympathiek door drie maanden achter elkaar elke avond pizza te halen (want die zit op de hoek naast de klant). De volgende rol was de architect. Wat zo mooi is aan een architectenrol, is dat in Word en Powerpoint altijd alles werkt: het hoeft niet te compileren. Zo kun je onmogelijk complexe ontwerpen toch er goed laten uitzien. De architect doet er goed aan, om nooit en te nimmer een ontwikkelomgeving te installeren want technische details zijn triviaal.
De laatste rol was die van de developer. Op de slide werd Bob de Bouwer getoond. Bob heeft een aantal pratende machines die altijd 'ja' zeggen als Bob vraagt of ze iets kunnen bouwen. Dit pattern doet zich voor wanneer er developers op het project zijn die onnodige features voorstellen aan de klant, vervolgens nachten door moeten werken om het te realiseren en in de tussentijd de hele codebase overhoop gooien. Een goede zaak, aldus Hoogendoorn, want we willen tenslotte het project doen mislukken. Dit verhoogt ook de zogenaamde Truck Factor: de kans dat het project tot stilstand komt, als een bepaalde developer onder een pick-up truck terecht komt.
Over de rol van tester had Hoogendoorn in deze presentatie weinig te melden, behalve dan dat hij maar zo laat mogelijk op het project moest komen. Ook moest er vooral gewoon worden doorgeprogrammeerd terwijl de tester zijn werk doet.
In de laatste slides werden aanwijzigen gegeven hoe het wel moet. Projecten moeten bij voorkeur klein en overzichtelijk zijn, developers dienen ook de rol van architect op zich te nemen, betrek de klant, een planning is flexibel, enzovoort. Kortom, werk meer volgens de agile methoden (XP, Scrub, etc.) en je zult tijd en budget overhouden. Door de insteek was het een grappige en onderhoudende presentatie, maar jammer was wel dat er geen tijd was voor nadelen met betrekking tot agile methoden. In een schriftelijke reactie gaf Sander Hoogendoorn aan dat het doel van de presentatie was om om mensen na te laten denken over nieuwe manieren van ontwikkelen. Hij heeft een boek in de pijpleiding dat dieper ingaat op de voor- en nadelen hiervan. Zijn website is zeer interessant: www.sanderhoogendoorn.com/.
Deze presentatie was zeer praktisch ingericht. Er werd uitgelegd wat aspect oriented programming (AOP) is en hoe het werd toegepast op een project dat Sogeti deed bij een klant.
AOP is een aanvulling op object georienteerd programmeren (OOP). Vrijwel elke mainstream taal is tegenwoordig in mindere of meerdere mate objectgeorienteerd. Alhoewel een object een goede abstractie is voor zaken in de wereld om ons heen, is hij niet perfect. Allerlei infrastructurele zaken zoals logging, authentication, performance testing, bepaalde vormen van input validatie enzovoort raken vaak een groot aantal klassen die niets met elkaar te maken hebben. Het is dan lastig om dit objectgeorienteerd te modelleren.
De kern van aspect oriented programming is, zeer verrassend, het aspect. Dit is een apart stukje code waarvan je kan specificeren dat het op een bepaalde plaats in een method wordt aangeroepen. Het standaard AOP voorbeeld is logging. Het zou aardig zijn als elke method automatisch begon met
logger.fine("begin raiseSalary");en eindigde met
logger.fine("end raiseSalary");Dit is te realiseren met AOP. Er zijn meerdere implementaties: JBoss AOP, Nanning, Aspectwerkz en in mindere mate het Spring framework. In deze presentatie werd echter gebruik gemaakt van de oudste en meest uitgebreide implementatie AspectJ. Om met AspectJ het bovenstaande voorbeeld te realiseren, compileer je je project op de gebruikelijke manier. Vervolgens maak je je aspect met de volgende file:
public aspect LoggingAspect {
pointcut tracePoints() : execution(* *.* (..))
&& !within(LoggingAspect);
before() : tracePoints() {
System.out.println("Before: " + thisJoinPoint);
}
after() : tracePoints() {
System.out.println("After: + thisJoinPoint);
}
}
Zoals je ziet, heeft de code een Java syntax met wat extra keywords. Als bovenstaande file is gemaakt, run je de AspectJ compiler. Die past de .class files aan van je project in een proces dat 'weaving' wordt genoemd. De bytecode wordt aangepast en vervolgens kun je die code deployen.
Natuurlijk kun je nog veel verder gaan met AOP dan wat logging toevoegen, maar daar was binnen de presentatie geen ruimte voor. Het boek wat de heer Steeghs aanraadde, was AspectJ In Action van Ramnivas Laddad (ISBN 1-930110-93-6 (alternate, search)).