JavaZone 2010

Da er årets Java Zone over. Etter to dager stappfulle av faglig påfyll og gjennsyn med gamle kjente må man dra seg tilbake til kontoret. Det var morsomt og jeg gleder meg allerede til neste JavaZone i 2011. Det blir 10-årsjubileum så det blir neppe mindre kult av den grunn.

Jeg har som vanlig prøvd å få med meg så mange sesjoner som mulig. I år var det både lyntaler og timesforedrag, og jeg har variert mellom begge. Blant de jeg plukket meg ut så er jeg vel totalt sett mest fornøyd med lynforedragene. Her er de foredragene jeg var på og de momentene jeg husker fra dem (sikkert noe som er galt oppsumert her - så mye på kort tid, med en fest på torsdag gjør vel at man glemmer litt):

Emergent Design - Neil Ford
Dette var et godt foredrag etter deg jeg kan huske. Detaljene har jeg ikke i hodet nå, så jeg må gå tilbake og se på slidene. Jeg mener å minnes at det ble snakket om en del interessante metrics på kodebaser:

- Hvor kompleks er en klasse? en faktor av lengde på metoder og hvor mange alternative kodeflyter som koden gjør.
- Hvor mange benytter en gitt klasse.

HVa gjør en kodebase? Lag tag cloud av koden og se hva den gjør.


Scalability, Availability & Stability Patterns - Jonas Boner
Dette foredrag var et greit foredrag. Det var en teknologioppramsing for hvilke måter man kan skalere ut software på (skalere opp = kraftigere hardware, skalere ut = flere noder). Ingen spesielle øyeåpner her - for det meste sunn fornuft, men et godt foredrag om man lurer på hvilke teknologier man har å velge i for å lage skalerbare løsninger.

Writing SOLID JavaScript code - Andreas Norås
Dette foredrag hadde noen særdeles fine eksempler på hvordan kule ting man kan gjøre i JavaScript. Her ble det vist snutter som demonstrerer hvordan man kan benytte de dynamiske aspektene i Java Script til å støtte ting som språket i utgangsunktet ikke støtter - herav overloading og currying. Spesielt den siste eksemplet er et "You got to see it to believe it".

Her ble det endelig klart hva prototype begrepet i Java Script er for noe. Jeg har lest om det tidligere, men av en eller annen grunn har det unnsluppet meg før nå - prototype setter verdier i definisjonen av objektet slik at det blir gyldig for alle fremtidige og eksisterende instanser. Tilordner man for eksempel et attributt til en ny funksjon så er den funksjonen kun tilgjenglig i det objektet. Gjør man det derimot i prototypen så vil alle objekter ha denne funksjonen. Det betyr at man ved hjelp av prototype kan utvide funksjonen i eksisteerende objekter, for eksempel objekter i DOMen.

Det ble også forklart og vist at JavaScript ikke er objektorientert, men ønsker man å utvikle mer objektorientert i JavaScript så finnes det greie bibliotker som man kan laste ned som gir objhekter som oppfører seg mer som Javaklasser.

HATEOAS - The Confusing Bit from REST - Jim Webber
Jeg har vært på foredrag tidligere som viser at webprotokollen er velegnet til å beskrive tilstandsprosesser. Han viste hvordan en restprotokollen HATEOAS (Hypermedia as the Engine of Application State) benyttes.

Hovedideen er at hver operasjon mot serveren gir et svar om hvilken tilstand man er i og hvilke nye lovlige operasjoner som vil dra prosessen videre. Har man for eksempel lagt inn en ordre vil man få som svar at man kan slette, legge til ordrelinje og for eksempel fullføre ordre. Disse, og kun disse URIene som returneres kan benyttes videre i kommunikasjon i denne sesjonen.

Går noe galt, eller en tilstand ikke er riktig så benyttes https feilkoder for å signalisere dette tilbake til klienten og avhengig av hvilken metode som benyttes POST/GET/PUT/DELETE styrer det hvilke endringer som gjøres på tilstanden på serversiden.

Bygg applikasjonen din testbar - Janniche Haugen
Dette foredraget var en tabbe at jeg ramlet inn på… Jeg trodde jeg gikk inn i rommet til lyntalene, men det var det ikke. Gikk da glipp av en del lyntaler jeg ville høre, men på den lyse siden så var det mitt andrevalg. Foredraget var kanskje litt for basic for min smak, men det ene gode nye poenget som jeg tar med meg er at man bør vurdere å ha factory metode for oppretting av tidspunktet "nå". Gjør man det er det betraktelig enklere å enhetsteste kode som omhandler tidsoperasjoner som er relativ til tidspunktet nå.

Personlig har jeg ofte gjort det slik at jeg endrer data som det spørres på for å styre programflyten i koden slik at jeg får testet den delen som jeg ønsker. Det er da altså hvilke data jeg skal teste mot "nå" som da ofte hentes ut som løser samme greia. Uansett et godt tips og neste gang jeg skriver kode som tester mot "nå" så skal jeg absolutt vurdere å benytte det.

How to debug threads in your production VM - Henning Spjelkavik
Dette foredraget ga meg ikke noen nytt

Min drømmeapplikasjon - Bjørn Nordlund
Bjørn hadde laget en maven archtype som setter opp et enkelt skall for å ha en applikasjon som både kan startes fra kommandolinje samt deployes som en war fil. I tillegg har den enkel persistense satt opp og konfigurasjon for å styre mellom miljøer test/prod osv. Fin om man ønsker en quick start guide.

Spring Roo - a tiny tour de force of sensibile - Håkon Arneng Holmstedt
Demonstrasjon av Roo. Presentasjonen ble rimelig slick da Spring Roo er et veldig godt demoverktøy. Roo er et kommandobasert spring rammeverk ala Rails for Java. På 10 minutter ble det satt opp applikasjon med domeneobjekter, relasjoner mellom objektene med crud rammeverk med tilhørende UI. Imponerende greier. Absolutt verdt å se på om man skal komme opp med noe raskt. Om dette er noe man kan bruke i praksis senere er en annen greie… Å ha det som første prototype, og eller et copy & paste prosjekt, det er helt klart interessant. Gitt at man vil ta inn Spring stacken i applikasjonen sin.

The value of a Steaming Pile of Crap - Greg Young
Dette foredrag var veldig bra. Profft gjennomført uten slides - en ren monolog. Budskapet var at når man skal utvikle software så må man alltid tenke på "Hvor lenge skal denne leve og hvilken verdi kan den gi". Teknisk gjeld er ikke nødvendigvis en uting, så lenge man er den bevisst. Skal programmet ha veldig kort levetid er ikke teknisk gjeld noe man bør bry seg om.

Time-travel and logging - Andreas Jacobsen
Et utrolig kult konsept med Log4j. Ideen er i hovedsak at man har en logger som cacher alle logginnslag opp til et visst threashold. Dersom man får en error log så dumpes alt av cachet data (inklusive debug meldinger) ned i loggen. På det viset så slipper man at logfilene fylles opp med "søppel", men dersom ting har gått at skogen så får man med seg alt av meldinger fram til det tidspunktet.

Dette høres ut som en genial greie å ta med seg i enterprise prosjekter, da man da nødvendigvis ikke bekymrer seg for å ha for eksempel 10 mb med cachet log til enhver tid.

Top 5 plugins for Hudson and Chuck Norris
Ingen store nyheter her - kan være greit å finne slidene og installere plugins.

97 things every programmer should know
5 lyntaler som omtaler et par elementer fra boken med samme tittel. Jeg har kjøpt den boken og tenker nok at den skal jeg kværne gjennom i løpet av høsten. Jeg er ingen storleser, men siden hver enkel ting er på 2 sider (lengre enn en oppsumering, mindre enn en total beskrivelse) så er det nok enkelt å komme gjennom den. Krever ikke stor innsats for hver gang man har litt tid til å bla i en bok.

Blant de punktene som jeg synes er viktig er "know your next commit". Tanken er at når man begynner en oppgave så skal man ha et mål om hva man skal oppnå i løpet av de neste par timene. Når man så har nådd det målet så skal man commite og fortsette på neste oppgave som får en nærmere kompletering av oppgaven. Et eksempel kan for eksempel være at man gjør en refactoring for å klargjøre koden for neste oppgave som man skal gjøre. Når den er gjort så bør man committe.

Det som kanskje var det mest interessante påstanden var at dersom man ikke har klart å løse greia man har satt seg som mål innenfor den oppmålte tiden så bør man rulle tilbake og begynne på nytt. Personlig så er dette rimelig likt slik jeg helst jobber.

Har jeg kontroll på alle punkter slik at jeg kan fullføre oppgaven uten at jeg går i feil så er dette en vanlig måte å jobbe på. Og det er veldig behagelig å kunne rulle tilbake det man har gjort si en halv time eller time dersom man ser at stien man er på vei ned ikke vil føre fram. Da er det i noen tilfeller greiere å angre de endringer man har gjort i stedet for å hacke ting til å virke. Argumentasjonen her går at man ved neste forsøk på koden så har man en dypere forståelse for den koden man skal endre på og bedre forståelse for problemet.

En fornuftig branching-strategi i Git - Trond Marius Øvstetun
Jeg har ikke benyttet GIT mye, men det jeg har benyttet av GIT har jeg likt. Brancher i GIT er veldig enkelt å få til og det er ikke uvanlig å brache for å lage en feature. Skal man benytte GIT er det kanskje greit å ta en titt på denne lyntalen for å få en ide om en mulig branchstrategi.

Is the grass greener for wiki users? - Svein Magnus Sørensen
Dette var et lite spennende foredrag. Involver brukerne dine og du får en løsning som kan virke. En wiki kan også lagre strukturerte data. Ikke den store revolusjonen…

Live Coding Session: Addding on obtrusive and search engine friendly JavaScript navigation - Andreas Øverland
Unngå javascript i linker. Her bør man nok lete opp foilene for "the JavaScript goodness".

10 steg til robuste batchsystemer - Bjørn Nordlund
Et godt foredrag om hvordan lage batchbaserte prosjekter. Benyttet Apache Camel for integrasjonsdelene. Det virker rimelig fornuftig ut. Gode tips er:
- Bruk poll
- La batchen være en egen monolittisk enhet.
- Den må ha overvåkningskonsoll.
- Lag tjenestene dine idempotent.
- Benytte atomiske operasjoner for å se at ting er startet.¨
- La overvåkningssystemet kalle deg - ikke send meldinger til overvåkningssystemet. Dersom ting går midlertidig feil så er det greit å se at systemet kommer seg igjen før man skriker om feil.

+ en del andre ting som ikke festet seg som enten ikke er så viktig eller at man bør lese foileneHappy

Basic Memory Troubleshooting - Inga Kristine Holen
Et bra lynforedrag om verktøy som kan hjelpe deg. Har man minneproblemer som "out of memory error" så finn frem dette foredraget og dra frem verktøyene som er nevnt. Her er både tips for hvordan man kan benytte jmx og få ut dumper fra produksjonssystemer (hvordan instruere til å få dem) dersom ting går galt og da kan man ta disse dumpene hjem og studere dem.

Enhance your Maven plugins with Groovy - Harald Søvik
Groovy virker som et veldig godt alternativ til å skrive maven plugins i. Mindre støy og det er jo virkelig ikke del av produksjonssettingen. Skal jeg skrive en maven plugin så vil jeg dra den frem.

Er det mulig å gjøre Oslo til verdens IT-hovedstad - Tobias Torrisen
Tobias drar frem hvor aktivt miljøet i Oslo er. Han estimerte det til å være lagt ned 270000 timer med fagarbeid i Oslo i året. (Om jeg husker tallet riktig). Så det er et veldig sterkt fagmiljø her, men ingen vet om det Happy Vi må bli flinkere til å dra inn forretningssiden slik at Oslo plasseres på kartet. Andre ting vi kan gjøre er å holde foredrag i utlandet.

Java, HotSpot og concurrency kan bite hardt i leggen - Øyvind Bø Syrstad
Interessant problemstilling om hvordan pipelining gjør at kode nødvendigvis ikke gjennomføres i den rekkefølgen man tror…

Securing web services with OpenSSO - Mario Aparicio
Open SSO virker som en interessant variant for å sikre webservices og lignende og det ser ut til å kunne gjøres ved konfigurasjon og ikke koding. Ikke et veldig godt foredrag, men ideen om at dette kan settes opp rimelig greit og etter at det er oppe så er det mulig å konfigurere seg dit man vil ble demonstrert.

Are you ready for change? - Anders Sveen
Kjedelig

Hjelp jeg har tatt over en legacy applikasjon - Vegard Hartmann
Et par strategier for hvordan jobbe med en legacy applikasjon:
- Ikke rør den
- Gjør kun noen endringer av og til. (dyrt)
- Konstant jobbe med å forbedre den. Lag tester.


Parprogrammering i praksis - Morten Berg
Det er vanskeligere å opprettholde parprogrammering enn det er å starte med det. Ofte blir oppgaver regnet for trivielle og da er det ofte enkelt å ramle ned på "dette gjør man alene".

Smdiig åpenhet : Fra skyldfordeling til samarbeid - Tore Vestues
Et interessant angrepsvinkel om hvordan åpenhet i smidige prosjekter avslører svakheter i prosjektgjennomførelsen. Åpenheten gjør at når man ikke klarer å gjennomføre oppgavene sine på tid så kan det føre til at folk føler seg dumme og vil da skjerme seg for å komme i mål med oppgavene sine. Det gjør at folk blir egoistiske og teamet vil ikke klare å yte sitt beste, og et velfungerende team som jobber mot et felles mål er viktig for at smidige metoder skal virke. Av andre poenger var det at sjefen ikke har noe på daglige standups. Det er viktig at teamet skjermes og får den arbeidsro det trenger for å få ting gjennom.

The Product Backlog Hinders Value Creation - Trond Wingård
Product backloggen mangler hvorfor man øsnker å gjennomføre en oppgave. Hva er verdien som man ønsker å oppnå? Dette gjør det vanskelig å prioritere inn oppgaver og man løser nødvendigvis ikke de ting som gir mest verdi for kunden.

The Java EE Spike Kata - Anders Karlsen, Johannes Broadwal
På en time så lagde disse to luringene en test først basert web applikasjon med persistens til databasen. Dette var primært en oppvisning i hvordan man kan parprogrammere og hvordan man benytter utviklingsverktøyet. Underholdene og som alltid er det spennende å se hvordan andre tenker når de utvikler. Av nye ting som jeg merker meg er måten å lage en @Test tilfelle ved å skrive Test og ctrl space. I tillegg var det en del flotte teknikker på hvordan man kan lage tester som benytter minnedatabaser sammen med hibernate for å se at ting blir utført. De vil jeg nok hente ned og bruke neste gang jeg skriver unittester som også tester databaselaget.

Utstillerne og området
Utstillerne i år er i følgende kategorier:
- Konsulenthus som vil ansette deg.
- De som vil selge deg bøker
- De som vil selge deg kurs
- Nescafe som vil selge kaffemaskinene sine.

Standene var som vanlig alt fra spennende til veldig kjedelig. Mange konkurranser - en del veldig vanskelige og en del helt greie. Jeg var med på noen små, men som vanlig så vinner jeg neppe Happy En del "swag" var det å finne - jeg fikk med meg en lekeand og noe annet smårusk. Og et par is og litt snop på området ble også fortært….

Oslo Spectrum som arena for Java Zone er veldig bra. Det er trangt, men ikke så ille at man ikke kommer inn der man vil. Jeg så to foredrag i "overflow" området. Det er en stor sal med 6 skjermer hvor man via et trådløst headset kan velge hvilke foredrag man skal være med på. Det blir litt som å sitte hjemme forran PCen å se foredraget, men tross alt bedre enn å ikke bruke tiden sin. Det største problemet med slikt er jo å faktisk sette av tid til det. Samt at hjemme mangler man det sosiale aspektet som er interessant - alltid noen å ta en spennende prat med over lunsjen eller middagen.

Matserveringen gikk forøvrig på skinner og var god. Det er en prestasjon i seg selv i og med at rundt 2000 personer skal ha mat….

Festen på torsdags kveld
Gratis øl er hyggelig det. Og IT folk er tydeligvis tørste, for alt av øl gikk ut i løpet av de 2 første timene Happy Igjen, mange hyggelige kjenninger ute på utestedene på Grønnland og som vanlig ble det flere gode nerdesamtaler Happy

Til slutt - Java Zone in a nutshell:
En klar sekser på terningen fra meg - dette bør man gjøre oftere Happy
|