Morten Grouleff er medlem af Spring User Group Denmark. I år deltog han i SpringOne i Amsterdam. Her får du hans anmeldelse af konferencen.

Jeg havde fornøjelsen af at deltage i SpringOne i Amsterdam d. 27-29 april, dog ikke den sidste dag, hvor jeg var nødt til at tage hjem.

SpringOne i Amsterdam havde belejligt lagt den første præsentation over middag mandag, så det var muligt at komme frem til den uden at skulle afsted søndag. Desværre var der tekniske problemer med flyet, så jeg ankom først lidt inde i Rod Johnson’s velkomst-keynote.

Han brugte Oracle’s køb af Sun som springbræt til at tale om “Fremtiden for Java EE udvikling”. Oracle er gode til at tjene penge, mens det er småt med innovation forlød det, så vi skal næppe vente os større nyheder på Java EE fronten fra den kant. Det, vi som java-udviklere savner, er at kunne udkonkurrere Rails/PHP på produktivitet på JVM-platformen, og SpringSource ser naturligvis Spring som vejen til at kunne opnå det! 
Et særligt problem i forhold til konkurrenterne er det at få et nyt java enterprise-projekt i luften: Hvem har ikke kopieret et tidligere projekt, eller et eksempelprojekt, og så tilpasset det, for at komme i gang? Til det formål og til generelt at øge hastigheden i starten af projektet findes nu “ROO“.

Som demonstration af ROO oprettede Ben Alex helt fra bunden, på scenen, en lille web-applikation til at stemme om hvad “ROO” skal hedde. Den bestod af en administrations-del, hvor man kunne indtaste muligheder at stemme på og en kunde-vendt del, hvor man kunne stemme. Det, ROO bygger, er javakode, samt en del “aspects”, som ligger i filer ved siden af selve den genererede kode. For den del, der blev demonstreret, var der fuld “Round-trip support”, så ROO selv udvidede aspekterne, når koden blev rettet. F.eks. opstod gettere og settere af sig selv, så snart der blev tilføjet felter, og databaseskemaet fulgte også med. Og da der ikke er nogen runtime-dependencies, ud over hele spring-stakken, kan man holde op med att bruge ROO, hvis man bliver træt af det… Det skal vist prøves for rigtig at sætte pris på det. Men det ser ud til at være et rigtig smart værktøj til dels at komme  igang med nye projekter, men også til at udvikle de mindre kunderettede dele af ens web-applikationer.

Men faktisk sagde Rod Johnson at det kun er erfarne java-udviklere, der ikke ønsker at arbejde med et dynamisk sprog, der bør bruge ROO til at blive i java, alle andre bør benytte Groovy+Grails og på den måde udnytte JVM-platformen til hurtigere udvikling. Og alle bør benytte SpringSource Tool Suite (STS) der blev annonceret til at være gratis fra nu af. Der er tale om Eclipse, bundled med en flok plugins til brug for Spring-udvikling, både i Java og Grails. Jeg er selv skiftet til att bruge den og indtil videre ganske godt tilfreds. (Subversion integrationen i Eclipse halter fortsat, men det er helt på linie med den ordinære Eclipse “Ganymede”)

Sidste del var vel nærmest et reklameindslag for SpringSource’s server-produkter, men der er nu noget om det: Den traditionelle applikationsserver, typisk i form af WebSphere, er på vej ud, til fordel for mere letvægts alternativer, typisk i form af Apache Tomcat. Det har været almindeligt at udvikle på Tomcat og så køre produktion på WebSphere eller en af dens konkurrenter, mens det nu bliver mere og mere almindeligt at benytte Tomcat hele vejen. Og så er det jo praktisk at SprintSource har produktet tc Server, der netop er Tomcat i en mere produktionsdriftbar udgave. Jeg har ikke prøvet den, så jeg kan ikke kommentere på dens kvaliteter i forhold til et almindeligt open-source release af tomcat-koden.

Slides fra præsentationen er faktisk læseværdige i sig selv. Og så har de den fordel, at de ikke går en halv time over tiden…

Tirsdagens keynote handlede om tage deployment med i ens “lean” process: Adrian Colyer mener at vide at det er skridtet fra udvikling gennem preproduktion til produktion, der er mest at hente ved at optimere på nu. Han gav demonstrationer af hvor hurtigt det er muligt at lave et nyt Grails webprojekt og få det deployet på Google App Engine, til AmazonEC2, og til en VMWare farm af dmServer instanser. Det ser ud til at SpringSource vil forsøge at udvikle et framework for konfiguration af den slags, så man som udvikler kan specificere at der f. eks. skal findes en database til ens applikation, på en abstrakt form.

De øvrige foredrag jeg gik til synes jeg ikke det giver mening at fortælle om her. Det er langt bedre at læse deres abstracts og se hele programmet og de fleste slides her.

Nå, nu har jeg skrevet mere end nogen orker at læse (åbenbart ikke, hvis du læste helt herned) men jeg vil slutte med at fortælle at der i pauserne og specielt mandag aften var masser af mulighed for at deltage i interessante samtaler. Som en af talerne svarede, da jeg spurgte hvad han gerne ville have ud af at deltage: at have talt med en hel masse af brugerne af spring-komponenterne. Og det må man sige lykkedes.

Hvis jeg får mulighed for at deltage igen, vil jeg bestemt gøre det!