DeVoxx ’08

The English presentation of this posting can be found at my new weblog.

Afgelopen dagen ben ik naar DeVoxx’08 gegaan, in Antwerpen en ik ben erg enthousiast! Veel goede presentaties gezien.

Van alle presentaties die ik heb gezien, dit is mijn top:

1. From Concurrent to Parallel by Brian Goetz – een steengoede presentatie. De ParallelArray structuur en de Fork-Join – beide in Java 7 – lijken zeer krachtig.
   Het boek van Brian Goetz Java Concurrency in practice heb ik gekocht. Helaas behandeld de nieuwe feature van Java 7 niet, het boek komt uit 2006.
2. The Feel of Scala by Bill Venners – Buitengewoon veelbelovende en goede taal. Vooral de demonstratie hoe Scala ook de mogelijkheden van mogelijkheden heeft voor uitbreiden en aanpassen van bestaande classes zoals in Ruby kan (add methods), maar met static type checking. En hoe in Scala veel refactor-operaties deterministisch  zijn, versus heuristic zoals in dynamische talen. Deterministisch refactoring betekent dat je code gegarandeerd hetzelfde blijft werken na refactoring.
   Het nieuw aangeschafte boek ‘Programming in Scala‘ ligt nu op mijn buro.
3. Be smart! by Ivar Jacobson – Een zeer energieke en inspirende man. Ik ben veel eens met wat hij beweerd eens en vond een een gedeelte al langer zo, maar hij kan het wel veel beter brengen.
   
4. RESTful Design, Patterns and Anti-Patterns by Stefan Tilkov – Door zijn praatje ben ik erg enthousiast geworden over REST. Het was ook erg verhelderend te horen dat SOAP eigenlijk een bloated (hoewel niet zo gezegd) remoting framework is, en niet echt voor open, goed herbruikbare services zorg. Tenminste niet meer dan andere remoting frameworks als RMI.
5. Effective Pairing: The Good, the Bad and the Ugly by Dave Nicolette – Leuk en inspirerend. Voorbeelden hoe pairing wel en niet moet,maar niet zo interessant vermoed ik als je er niet direct bij bent.
6. Implementing agile at enterprise level by Jef Cumps Heel even leek de spreker niet zo over te komen, maar al snel kwam hij los, voor mij tenminste. Zeer interessant hoe Scrum is geïntroduceerd binnen een organisatie als The Belgian Post. Mooi was ook een plaatje van een echt Scrum-bord (met gele en roze post-its) zoals gebruikt is.
   
7. What’s new in Spring Framework 3.0? by Arjen Poutsma and Alef Arendsen – Spring blijft een krachtig framework als je Java gebruikt. Ik vond het interessant te horen welke nieuwe mogelijkheden er zijn, aangezien ik het Spring-framework bijna iedere dag gebruik.
8. Java + XSLT 2.0
   Doug Tidwell – Behoorlijk interessant, en goede spreker. Vooral interessant voor mij, omdat ik pas een stukje over XSLT heb geschreven en het eerder gebruikt heb. XSLT 2.0 lijkt zeer nuttig, vooral de mogelijkheid om aanroepen van Java-code te embedden.
   
9. Patterns in Mule
   by Antoine Borg Redelijk interessant, Mule lijkt een zeer mooi tool. Ik heb organisaties gezien die het messenging, queuing probleem met custom-code of wel niet hebben opgelost, Mule lijkt prima in te passen. Spreker kwam alleen niet zo heel goed over, hij was niet zo interactief en sprak soms wat ‘voorlezend’.
10. How Do We Test This Stuff?
    by Frank Cohen – Uiteraard wil ik goed testen. De spreker kwam goed over, maar inhoudelijk was de presentatie niet zo interessant, ik hoorde niet veel nieuws. Vooral over open-source test tools, PushToTest, Selenium, SoapUI.
11. Preventing bugs with pluggable type-checking for Java
    by Mahmood Ali – Erg veelbelovend en interessant idee en bij behorend framework: een pluggable type-system via annotations. De spreker kwam alleen niet zo goed over. Ik kreeg idee dat hij verkouden was, en wat nerveus.
12. Introduction to NIO.2
    by Jean-Francois Arcand – Deze presentatie viel behoorlijk tegen. De spreker sprak erg warrig, half afgemaakte zinnen, van de hak op de tak en met een zwaar Frans accent. NIO2 en Grizzly-framework lijkt wel zeer krachtig, dat kwam wel over.

Ik ben overtuigd, ook van wat ik van andere heb gehoord op de conferentie, dat er andere erg goede sessies waren. Helaas kan ik niet overal bij zijn, dus ik kijk uit naar wanneer de presentaties online komen op Parleys.

Java Concurrency In Practice
Tim Peierls & Brian Goetz

Effective Java
Joshua Bloch

Generic CRUD component

Belangrijkste  voordeel van een ORM framewok, is het voorkomen van telkens opnieuw code maken om data uit een database te transleren naar een object-type. De belangrijkste opereraties die met zo’n object moeten gebeuren zijn: aanmaken (Create), opvragen (Read), bijwerken (Update) en verwijderen (Delete), ofwel CRUD. Je zou die functies voor ieder type apart kunnen maken, maar via de standaarden JPA en Java 1.5 is het ook goed mogelijk een generiek CRUD-component te maken in Java. Via deze service zijn alle CRUD-operaties beschikbaar voor persistent Java-objecten. Op die manier kun je heel snel b.v. een GebruikersService, AdresService.
Ik was niet de enige met dat idee, na wat snel zoeken vond ik het volgende artikel van Adam Bien: Generic CRUD Components with Java EE 5.  Na een discussie met een collega kwamen we erop dat Generic CRUD component zeer veel weg heeft van het Active Record Pattern van Martin Fowler.
Het Active Record Pattern is uiteraard uitgewerkt in Ruby on Rails. In Java is er sinds kort ook een implementatie, Active Objects. Active Objects wordt uitgelegd in een artikel van Daniel Spiewak op Javalobby.org.
In zekere zin lijkt ActiveRecord erg op een DAO-pattern. ActiveRecord werkt echter goed in dynamische talen als Ruby en Groovy, DAO is beter geschikt voor niet dynamische, static-type talen als Java. Wat ik dus zoek is niet een Generic Crud Service, maar een Generic Dao, gelukkig al beschreven door IBM.
Een afgeronde implementatie van een Generic DAO kon ik helaas nog niet vinden, maar in combinatie met Spring zou zo’n implementatie toch weinig code bevatten. Een goede omschrijving is ondermeer DRY CRUD DAOs with JPA. Op Google Code vond ik het Crank project, die een implementatie van een uitgebreide Generic Dao levert.

Er is niets nieuws onder de zon, zolang je maar de juiste (en dezelfde) woorden gebruikt en kent!

Multi core processors en parallel programming

Een van de belangrijkste revoluties in ICT-land is de stagnatie van die kloksnelheid van chips en de opkomst van multi-core processors in computers. Globaal gezegd: processors van nu kunnen nauwelijks meer achterelkaar, maar kunnen nu steeds meer tegelijk.
Dit biedt een flinke uitdaging voor softwareontwikkelaars (programmeurs, architecten): in plaats van programmacode die achter elkaar wordt uitgevoerd, moet programmacode geschreven worden die tegelijkertijd uitgevoerd kan worden.

Metafoor van werkverdelen
Voor heel veel software is dit buitengewoon moeilijk. Om in metaforen te spreken: heel veel werk, of het nu het verven van een huis is of het ontwikkelen van nieuwe belastingsoftware kan niet door een iemand gedaan worden. Het werk moet met meerdere mensen gebeuren. Om te zorgen dat het werk nog steeds goed gaat, is alleen wel een coördinator of leider nodig, in de vorm van projectleider, hoofdschilder, aannemer, etc. Daarnaast zijn vaak secretaress, boekhouders, etc. nodig ter ondersteuning van de leider. Die leiders en ondersteunend personeel dragen niets direct bij aan het eindproduct: dan doen de schilders, programmeurs, timmermannen. Bij een goed bedrijf zal er ook zo min mogelijk ondersteunend en coordinerend personeel zijn.
Om de metafoor verder te trekken: voor de bovenstaande problemen is geen generieke oplossing. Het aannemersbedrijf, of schildersbedrijf, of softwarehuis dat slecht loopt kan niet al zijn problemen oplossen door een algemeen coordinator in te huren. Als iemand ingehuurd wordt, zal hij zich eerst in de problemen en de bedrijfssituatie moeten verdiepen, voor hij een passende oplossing kan aanbieden of mensen kan gaan aansturen.
Bij een slecht werkend bedrijf zal er heel veel coordinerend en ondersteunend personeeel nodig zijn. Of het gebeurt zeer vaak dat een schilder erachter komt dat alle verf al door iemand anders in gebruikt wordt. Of verwarmingsinstalleur wil de buizen gaan aanleggen terwijl de stuccadoor al alle muren heeft afgewerkt.

Zelfde geldt ook binnen de softwareontwikkeling: generieke oplossingen als een gedistribueerd database, een nieuwe applicatieserver of hercompileren van programmacode zorgt er niet voor dat oude software meteen goed werkt op een multi-coreprocessor.
Evenzo is het zomaar verdelen van werk over meerdere threads of processen meestal niet mogelijk, of levert dit verdelen zoveel overhead dat de prestatiewinst minimaal is.

Parellel programming, Nightmare on core street
Eerder schreef ik al, dat programmeurs en architecten dit probleem negeren of in het gunstige geval schromelijk onderschatten. Desalniettemin waren ten tijde van mijn posting al fraaie artikelen die het probleem van parellel programming goed uitleggen. Op een weblog van Rebel Science News, staat een erg heldere serie van postings die het probleem goed uitleggen: Nightmare on core street. De eerste entry legt al heel helder het probleem van software schrijven voor meerdere cores, en waarom threads niet de beste oplossing zijn.
De stelling van de weblogauteur, dat we (de programmeurs) in de toekomst geen algoritmes meer schrijven vind ik alleen wat kort door de bocht: dat hangt geheel van je interpretatie van algoritme af.

Uitdagingen voor multi-core

Het schrijven van gedistribueerde software of parellele software door een programma op te splitsen in meerdere threads werkt voor simpele taken als sorteren (zie de heldere posting op javaworld: Java Concurrency in Practice), maar naar mate het werk ingewikkeld wordt (volgens de bovenstaande metafoor) wordt de overhead van coordineren van threads èn de kans op fouten exponentieel groter (zie ook een latere artikel op javaworld: Multicore: New chips mean new challenges).
Bedrijven als NVIDIA werken aan ander model van chips: GPU’s: vectorprocessors, terwijl Intel blijft vast houden aan thread-based programming volgens de auteur. Wellicht een antwoord op de auteur van Rebel Science: ik vond een weblog entry waar Intel elk geval onderkent dat programmeren met meerdere threads niet bruikbaar is om parallelle software te schrijven en een andere model nodig is om met de multi-core processors van Intel om te gaan. Desalniettemin geloof ik de auteurs van Rebel Science dat een geheel ander model van chips nodig is: Parallel Computing: Why the Future Is Non-Algorithmic.

Kortom parellel programming wordt komend jaar denk ik een erg hot onderwerp! Zelfs met of zelfs dankzij de kredietcrisis: softwareontwikkel- en -consultancybedrijven zullen moeten zoeken naar oplossing om zo goedkoop mogelijk, zulke goed mogelijke programma’s te schrijven die gebruiken van van multi-core processors. Simpel het budget verhogen om veel meer servers en mankracht in te kopen of te huren leidt niet tot een oplossing.

Rich clients en kringloopwinkels

Zo’n 8 jaar geleden waren kringloopwinkels en en tweedehands spullen bepaald niet populair. Hoogstens voor studenten die op kamers gingen of (andere) armlastige mensen. Sinds enkele jaren is het hebben van tweedehands spullen helemaal hip, en zijn kringloop winkels druk bezocht. Hoe komt dat? Simpel door markplaats (overigens ooit een dochterorganisatie van een kringlooporganisatie Het Goed). Markplaats zorgde ervoor dat kopen van tweedehands goederen veel laagdrempeliger was. Een indirect gevolg van de toename van kopen van tweedehands goederen via internet, was dat kringloopwinkels ook weer populair werden. Voordeel van een kringloopwinkel bovenop Markplaats is ten slotte dat je makkelijke artikelen direct kunt zien voor aankoop, zonder allerlei adressen eerst te hoeven bezoeken.

Ik denk dat de desktop-applicatie, in de vorm van de rich-client een soortgelijke ontwikkeling doormaakt qua populariteit aan het doormaken zijn.

Begin jaren 2000 werd de desktopapplicatie plots een stuk minder populair. Heel veel, vooral administratieve, applicaties werden als webapplicatie gebouwd of omgezet.
Men kwam er snel achter dat de UI van webapplicaties zo zijn beperkingen heeft. Oorspronkelijk is het WWW ontworpen voor online bekijken van artikelen en online formulieren bedoeld voor verzenden van berichten als bestellingen of klachten. Bij een webapplicatie verwacht een gebruiker veel meer dan die beperkte functionaliteit: sneltoetsen, makkelijk kunnen scrollen, makkelijk kunnen doorklikken (dus een snelle interface).

Als oplossing hiervoor kwamen technieken als Javascript, Ajax en slimmere web-browsers als Google Chrome, Firefox3 of IE8 (probeer maar eens een moderne webapplicatie met IE6 te gebruiken). Op die manier kan toch een redelijk soepel voelende en uitgebreide applicatie geschreven worden, die helemaal in een webbrowser werkt.
Los van het probleem dat rich internetapplicaties (RIA) als Google Docs of Zoho nog steeds soms wat traag aanvoelen, ligt het grootste probleem in de ontwikkeling van die applicaties. De ontwikkeling van webapplicaties is een stuk moeilijker en omslachtiger. Aanwijzing hiervoor zijn de vele webframeworks voor webapplicaties zoals voor HTML/Ajax: Wicket, Spring Webflow, JSF, Struts, GWT.  Dat deze applicaties zo snel opkomen en vaak weer in populareit dalen zegt volgens mij wel wat over de kwaliteit.

Er komen inmiddels ook frameworks die niet op html zijn gebaseerd: Flex, Microsoft, Mozilla Xul of Sun’s JavaFx. Als je een webapplicatie in zo’n framework bouwt, bouw je bijna applicatie die bijna hetzelfde werkt als een tradionele desktopapplicatie.
Ofwel, via een omweg wordt de desktopapplicatie weer populair. De voordelen van een webapplicatie: leesbare html, automatisch indexbare tekst bestaat of niet-nodig-zijn van een extra plugin blijken opeens niet zo belangrijk. Kortom, de desktop-applicatie is stiekem weer hot geworden.