DDD-kurs på Citerus

Jag har gått fyradagarskursen Domain-Driven Desing: Domänmodeller i arbete och tänkte försöka sammanfatta mina intryck.

 

Dag 1

Kursen var fullbokad med tio deltagare vilket tydligen var ovanligt bra då det t ex bara var jag och en till som ville gå kursen i september. En grupp kom från Umeå universitet, resten var spridda skurar från olika kunsultbolag från både Uppsala och Stockholm. Vi håller till på Lundqvist & Lindqvist vid Klarabergsviadukten 90. Det är fräscha lokaler med hembonad känsla och generöst med framställt fika på morgonen och på fikarasterna.

Det är Patrik Fredriksson från Citerus som håller kursen. Han har tidigare kört kursen tillsammans med "grundaren" av DDD, Eric Evans, och är väl insatt i ämnet. På morgonen får alla presentera sig och beskriva förväntningarna på kursen. Alla förväntas ha med sig en egen dator med en fungerande Eclipse-installation. Vi importerar de projekt vi ska jobba med under de fyra dagarna från en USB-sticka vilket går smidigt. Patrik går igenom grunderna och syftet med domändriven design, därefter paras vi ihop två och två och får börja titta på en klass som består av två metoder, den ena ca tjugo rader som på ett ställe anropar en lite mindre metod.

Övningen gick ut på att förstå vad klassen gör. Koden såg ut som riktigt dålig kod ibland kan göra vilket resulterar i att det tar ganska lång tid innan vi förstår vad koden är tänkt att göra. Därefter delas vi upp i två grupper, varvid jag hamnar i gruppen med sex personer. Uppgiften nu är att leta fram preconditions och postconditions och även att hitta bra begrepp som kan ingå i våran modell. Preconditions är de krav som behöver vara uppfyllda för att koden ska fungera, postconditions är i praktiken saker man kan testa mot om man skulle skriva ett enhetstest, d.v.s förväntat resutat. Med lite hjälp av Patrik lyckas vi sätta de flesta av kraven som behöver vara uppfyllda före och efter det att metoden anropas.

I nästa övning snyggar vi till API:et till vår metod något. Vi kör TDD och ändrar därför våra tester att fungera mot den nya metodsignaturen, varpå våra tester först blir röda, därefter implementerar vi varpå de blir gröna! Nästa övning går ut på att få oss att förstå att koden ser grisig ut på grund av att det saknas abstraktioner och begrepp för att beskriva vårat problem. Genom att införa nya begrepp så som som itinerary (resplan) kan vi till slut banta ned vår huvudmetod till hälften och på köpet öka dess läsbarhet. Genom detta sätt att jobba uppfyller vi ett par av de viktigaste tumreglerna inom programmering nämligen att hitta lagom stora byggstenar med ett tydligt ansvar (de nya klasserna i det här fallet) och dels att ha bra namn på saker! Det DDD trycker extra på är att de gemensamma begreppen ska användas både av verksamheten och även återspeglas i koden.

Dag 2

På förmiddagen fortsatte vi att jobba med våra testprojekt. Varje projekt speglar ett litet steg mot en bättre och förfinad modell där domänen är den samma som i Eric Evans bok, frakt av containrar. Varje steg följer samma mönster, praktik i form av kodning (TDD) som varvas med modellering i grupper med en fejkad domänexpert (Patrik). Det avslutas med en genomgång där Patrik presenterar "facit". Det är en bra blandning av diskussioner och praktiskt kodande. Övningsuppgifterna är väl definierade och syftar till att träna en viss del t ex huruvida testerna uttrycker mening och använder sig av ubiquitous language - det gemensamma språket. Precis som dag ett serveras det förutom lunch även rikligt med bakverk och dryck på rasterna och jag siktar på att gå upp ett halvt kilo!

Koncept så som domänevent (som tillkommit efter att Erics bok släpptes), aggregat och bounded context introduceras och diskuteras en hel del. Det trycktes en del på att aggregat används allt för sällan. Personligen tycker jag att aggregat är en bra konstruktion som omfamnar idén om inkapsling och hjälper till att reducera komplexitet när man bygger system. Därefter pratade vi om värdeobjekt som är en trevlig byggsten som dessutom är immutable! Vi anpassar vår kod att använda värdeobjekt, anpassar tester följt av genomgång med diskussioner. En rolig övning som genererade mycket diskussioner i vår grupp infann sig när systemet skulle stödja frågor om var containern befann sig. Det blev långa diskussioner där vi t ex hade tio förslag på vad en metod skulle heta; det är viktigt med namnsättning! Dagen avslutades med ett antal filmsnuttar som visade när en utvecklare försökte ta fram en domänmodell tillsammans med en domänexpert. Det gick väl si så där för honom men fick oss i alla fall att tänka till kring vad man bör tänka på i en sådan situation och att inte falla i samma gropar som han!

Dag 3

Denna dag ägnas åt genomgång av koncept på lite högre nivå så som strategisk design och annat. Det är rätt högt tempo där vi dels får göra en liten teaterövning där vi spelar olika roller för att simulera interaktionen mellan olika utvecklingsteam och externa parter som alla ingår i ett större system. Det blir en ganska kul övning som i slutändan går ut på att definiera de olika teamens relation till varandra. Ett exempel på en typ av relation är upstream-downstream där upstream inte tar hänsyn till downstream och där den senare kan drabbas av vad den förse hittar på.

Ett annat koncept som gicks igenom och övades på var distillation som går ut på att förstå och fokusera på de viktigaste delarna i systemet, det som i DDD kallas core. En av övningarna fick oss att förstå att core kan variera över tiden, där t ex en del kan gå från att vara core till att bli supporting d.v.s inte längre lika central. Ännu en bra dag fylld av diskussioner, om dag ett och två var innehöll mycket kodexempel så var de denna dag utbytta mot boxar och cirklar!

 

Dag 4

Dagen börjar med repetition av gårdagens övningar i kontextmappning och destilering av domänmodellen. Det följdes upp med en övning i att försöka bryta loss begrepp från våran RoutingService. När vi lyckats med det gick det lättare att resonera kring vad servicen gjorde då vårat domänspråk och implementation förfinats. Därefter tittar vi på koden i den DDD exempelapplikation som Citerus tagit fram. Den är visserligen nu två år gammal men fungerar bra som diskussionsunderlag. Någon noterade att applikationen använde sig av DTO:er vilket ses som ett anti-pattern. Jag tror vi kom fram till att man under vissa omständigheter borde kunna skicka rikare objekt än dumma databärare! DTO:erna hade hur som helst lagts till för att simulera kommuniikation med ett externt system.

På kursdeltagarnas begäran körde Patrik en liten genomgång av CQRS som också denna gång ledde till bra diskussioner. En kul grej var att en av deltagarna som kom från Ongame/Bwin hade praktiserat detta mönster i skarp drift för att lösa problematik kring många samtidiga användare.

En annan deltagare jobbade med ett system som bestod av en miljon kodrader och 800 databastabeller. Han tog upp problematik kring kodduplicering, där vi tillsammans spånade kring möjliga lösningar. De hade aggregat som behövde jobba mot samma tabeller men i olika kontext. Dessa aggregat var idag väldigt stora och mitt förslag var att ha ett aggregat skulle ha olika "skepnader" för respektive kontext, men att behålla den underliggande representationen genom att använda mönstret Context Switcher! Dagen avslutades med en halvtimme introduktion till Clojure ur ett DDD-perspektiv, vilket var en kul och intressant avslutning!

Om man som jag tycker att Eric Evans bok Domain Driven Design: Tackling Complexity in the Heart of Software är svårsmält föreslår jag följande preparering: läs Domain-Driven Design Quickly på strax över 100 sidorna som är en komprimerad version av boken och gratis, gå därefter denna fyradagarskurs och först därefter är du redo att ta dig an boken! Patrik Fredriksson föreslog fem genomläsningar och jag lutar åt att han menar allvar!

Sammantaget var detta en mycket bra kurs som jag rekommenderar till var och en som är nyfiken på DDD!

Jfokus 2011

Jfokus har i år utökats från två till tre dagar och flyttat till Stockholm Waterfront Congress Centre. Lokalerna är rymliga och fräscha och ligger centralt nära tågstationen. Läsare av detta första inlägg får ursäkta att det blev något i längsta laget!

Mån 14/2 - Tutorial

Registreringen var mellan 8 och 9 på morgonen och då tåget från Uppsala kom in drygt en timme senare än beräknat blev jag därför 45 minuter försenad och fick då heller ingen frukostmacka :-(.

The Productive Programmer
Neal Ford, ThoughtWorks

Första föreläsningen hölls på förmiddagen av Neal Ford från ThoughtWorks. De första 45 minutrarna (de jag missade) hade han pratat lite kring hur man kunde bli effektiv genom att använda snabbtangenter och kortkommandon. Sammanfattningsvis bjöd hans dragning på en hel del godbitar och höll ett högt men bra tempo. Följande är vär att nämna:

• Han rekomenderar användning av flera skrivbord. Detta för att kunna skräddarsy vart och ett till en egen arbetsuppgift så att man slipper ha allt på ett och samma ställe. Fördelen är också att man kan låta saker ligga på fasta positioner vilket är bra ur användbarhetssynpunkt. Han själv använde elva skrivbord och funderade på att lägga upp ett tolfte! Han rekomenderade VirtuaWin för Windows men avrådde från Windows egna skrivbordshanterare.
• Han hade jobbat i ett projekt som satt utspritt i tre länder. De hade först börjat med att låta varje utvecklare dokumentera vad de hade gjort innan de gick hem för dagen för att de andra skulle hållas uppdaterade. Detta gjordes sedan om så att man fick ett RSS-flöde över alla ändringar och då slapp man försöka underhålla detta manuellt. De gjorde en egen lösning på detta men nu finns det en plugin till Subversion som gör just detta. De använde dessutom denna information till att dokumentera systemet.
• Schemaspy är ett verktyg som kan producera diagram över databaser.
• Han pratade en hel del om DRY (Don't Repeat Yourself). Han hade ett par exempel. I det ena fallet hade de använt iBatis (numera flyttat till MyBatis) för att sköta persistering till databasen. De behövde hålla klasser i Java och konfigureringsfil för iBatis i synk med databasen vilket till en början gjordes manuellt. Detta trots att de bara var olika representationer av samma sak (vilket bryter mot DRY-principen). De införde då kodgenerering som läste upp hur databasen såg ut (från systemtabellerna) och generarade sedan konfigureringsfiler, Java-entiteter och dokumentation. Detta är ett mycket trevligt sätt att använda kodgenerering på vilket höjer kvaliten, tar bort manuell hantering och gör koden DRY. Har själv mycket possitiva erfarenheter av detta arbetssätt då jag skrev en kodgenerator som kunde automatgenerera ett persistenslager i Java plus dokumentation i ett projekt åt Ericsson år 2000! Tag gärna även en titt på mitt projekt Laja som är en kombinerad kodgenerator och parsergenerator där kodgeneratorn har inbyggt stöd för att läsa metadata från en databas (via integration med Groovy) och kan användas för just detta.
• Om du utvecklar webbapplikationer och behöver verifiera att det du gjort fungerar kan man ibland behöva tröska igenom ett antal sidor innan man kommer till den sida man vill testa. Då kan det vara bra att använda en Selenium-plugin till Firefox där du kan spela in det du gör i GUIt fram till den sida där du vill börja jobba manuellt.
• FindBugs är ett verktyg som kan upptäcka buggar i din Java-kod och är öppen källkod.
• PMD är ytterligare ett verktyg som används för att upptäcka olika problem med din kod.
• CPD Copy Paste Detector, kan upptäcka duplicerad kod.
• Han drog en kul anekdot som han nästan kunde verifiera att vara sann, The angry monkeys, och som gick ut på att man stängde in fem apor i ett rum där det fanns en trappa där det hängde bananer ovanför. För att nå bananerna var man tvungen att gå upp för trappan. När någon apa gick upp på trappan sprutade man kallt vatten på alla fem aporna. Efter ett tag lärde sig alla apor att man inte skulle gå upp på trappan, bröt någon mot regeln fick den stryk! Sedan bytte man ut en apa mot en som aldrig hade varit i rummet. Han fick förstås stryk vid minsta försök att gå upp på trappan. Sedan upprepade man det hela tills man hade fem apor som alla jobbade hårt på att upprätthålla regeln att aldrig beträda trappan, trots att ingen av de fem någonsin hade fått kallt vatten sprutat på sig! Paralellen till Java-comunityt är att det finns regler som alla kämpar hårt för att upprätthålla även om de nu har blivit inaktuella bara för att någon för länge sedan bestämt att det ska vara så. Som exempel hade han att det är en bra idé att ha underscore i metodnamn för testmetoder, som ofta blir långa, i stället för CamelCase för att öka läsbarheten. Detta är dock "förbjudet" och om man gör det så får man tillsägelser att "så får man inte göra"!
• En annan sak som också anspelar på The angry monkeys är något som kallas Fluent Interfaces. När man behöver sätta upp en instans som har en massa attribut skapar man ibland en tom instans och kör en hel drös med setters på denna. Den koden blir inte så läsbar. Ett alternativ är att skriva t ex: Car.describedAs().box().length(12).name("Nisse"). Man använder då method chaining på sina setters och använder inte set i sina "setters" och använder dessutom en statisk metod i stället för konstruktor när man skapar instansen, allt för att öka läsbarheten. Allt som allt bryter man mot hur reglerna för en JavaBean ska se ut, men får i stället något som servar behoven bättre! Denna lösning använder vi i det projekt jag sitter i nu för att bygga upp modeller som underlag för generering av testdata till automatiserade acceptanstester, vilket fungerar utmärkt!
• Han ägnade en del tid åt att prata om saker som är bra men som inte är helt intuitivt varför de är bra. Parprogrammering var ett exempel där det för en utomstående kan verka obegripligt att det skulle kunna vara en god idé att låta två personer göra en mans jobb! Det finns dock studier som visar att två personer är endast 15% långsammare än om de hade jobbat var och en för sig, men att antalet fel minskar med 15%! Ju tidigare fel upptäcks desto bättre, vilket spar tid. Ett annat exempel är TDD. Där finns det studier som visar att arbetssättet dels genererar färre fel och dels att man kan producera kod i en jämnare takt till skillnad när man inte kör TDD som i stället tenderar att gå långsammare allt eftersom kodmassan ökar.
• Han hade ett klokt svar på frågan när man bör bygga ramverk. Svaret på den frågan är att ramverk bygger man inte från noll, utan de ska växa fram naturligt som fungerande lösningar i den befintliga kodbasen. Därefter när man ser att man skapat något som skulle fungera bra som ett mer generellt ramverk kan man extrahera ut det och paketera!
• Han pratade om begreppet "Single level of abstraction" som går ut på att en metod bara ska inehålla kod och för samma abstraktionsnivå hela metoden igenom. Man ska t ex inte blanda kod för transaktionshantering med affärslogik, vilket nog alla håller med om men som sällan efterlevs!
• The Free Lunch Is Over går ut på att man nu ökar prestanda genom att utöka antalet CPU:er istället för att öka klockfrekvensen och vilka följdverkningar det har på mjukvaruindustrin.
• Plolyglot är ett begrepp där huvudidén är att det inte längre räcker med att kunna ett språk för att lösa alla problem. Man kan t ex mixa dynamiskt typade språk med statiskt typade för att uppnå en optimal lösning. Det ryktades också om att man i Java 9 (när nu den kommer) ska kunna integrera olika språk som kör på JVM:en på en snyggt sätt. På frågan om det inte var jobigt att skifta mellan olika IDE:er då de fungerar lite olika vad gäller kortkommandon mm var hans svar att han kör Emacs!
• På en fråga från publiken om vad han tyckte om Pomodoro svarade han att han brukade använda det men att då i stället jobba 2 timmar i stället för 30 minuterspass.

Domain-Driven Design: Putting the Model to Work
Eric Evans, Domain Language
Patrik Fredriksson, Citerus

På eftermiddagen körde Eric Evans tillsammans med Patrik Fredriksson en dragning om domändriven design. Det var kul att lyssna till författaren till en av de viktigaste böckerna inom vår bransch idag. De hade delat upp det så att Patrik körde första halvan och Eric resten. Tyvärr gick första passet alldeles för långsamt och var allt för grundläggande för min smak. Han uppehöll sig för länge vid enkla koncept som t ex att en karta kunde ha två olika representationer (modeller), där inget var mer rätt eller fel än det andra då de bara tjänade olika syften. Sedan var det Erics tur.

Det är första gången jag lyssnar till Eric Evans och han gav ett lugnt och samlat intryck. Han sammanfattade domändriven design med att domändriven design är en samling principer med fokus på kärndomänen. Han pratade om hur viktigt det är med kommunikationen mellan utvecklingsteamet och de personer som har domänkunskap vid framtagningen av ett gemensamt (ubiquitous) språk. Han hade en röd tråd genom hela dragningen som till slut landade i att man inte ska skriva om hela legacy-system från scratch utan i stället rikta in sig på att stabilisera befintlig legacy-kod och att sedan bygga ett skikt "Anti Corruption Layer" mellan Legacy-koden och en ny ren domänmodell.
En sak han menade att man inte skulle ägna sig åt var att rädda slarviga personers incheckningar genom att gå in och rätta dessa "i smyg" för att man då bröt "feedback loopen" till verksamheten då denna kod senare troligen skulle orsakar problem.

Man ska prioritera den delen av systemet som är Core Domain (ge fokus och omsorg) och sätta sina bästa utvecklare (vilket enligt han är hjältarna) på denna delen och inte låta dem jobba med t.ex infrastrukturen! Core Domain ska inte heller outsourcas.


Tis 15/2 - Konferensdag 1

What a crazy year it has been
Henrik Ståhl, Oracle

Henrik Ståhl öppnade dag ett av konferensdagarna. Han är en duktig talare och gick igenom hur Oracle såg på uppköpet av Sun och saker som hänt under det gångna året. Man kan sammanfatta med att Oracle försöker inta en rätt ödmjuk hållning vad gäller fusionen med Sun och övertagandet av varumärket Java mm. Oracle verkar nu ha en ambition att gå från The bad guys till The good guys, återstår att se om de lyckas. De kommer att satsa mycket på Java framöver så framtiden för Java och JVM:en ser just nu ljus ut.

Visualization for Code Metrics
Neal Ford, ThoughtWorks

Neal Ford höll här ännu en bra föreläsning kring hur man kan mäta olika aspekter av koden för att kunna vidta nödvändiga åtgärder (läs refaktorering) då man ska hitta var i systemet där insatser gör mest nytta. Bara genom att börja mäta t ex produktivitet så ökar produktiviteten i utvecklingteamet, vilket han drog ett verkligt exempel kring. När man väl fått fram sina mätvärden, ska man fortsätta mäta regelbundet och den statistik som produceras ska visa förändringen av t ex komplexiteten så man kan följa om komplexiteten ökar eller minskar i de olika delarna av koden.

• SourceMonitor är ett verktyg för Windows som mäter komplexitet i koden.
• KiviatGraphs är ett sätt att grafiskt visa om mätvärden ligger inom önskat område.
• Panopticode är ett förkonfigurerat Ant-projekt som kör massa metrics på kodbasen genom att använda andra redan existerande projekt.
• GraphViz är ett verktyg som kan visa diagram utifrån en xml-fil, likt yEd.
• JarAnalyzer kollar vilka jar-filer som används (för att kunna ta bort ej använda).
• Vizant Ant-task som kan ta en Ant byggfil och generera ett diagram (som ser bra ut!. Hittade själv även andra verktyg för detta t ex Grand.
• Gapminder är ett verktyg som kan visa förändring över tid i form av en animation. Här finns bra presentationer av Rosling på TED.com som han varmt rekommenderade.
• Sonar är ett verktyg som mäter teknisk skuld.
• X-ray är en plugin till Eclipse som mäter komplexiteten i koden.
• CodeCity kan visa hur din kodbas är organiserad i form av en 3D-vy.

Han tyckte att man skulle lägga in tröskelvärden som gör att byggservern failar om t ex komplexiteten ökar på samma sätt som man brukar göra om testtäckningen understiger önskad lägsta nivå.

Overview of NOSQL
Emil Eifrem, Neo Technology

Emil höll ett bra föredrag om Not Only SQL databaser. Först pratade han om varför de slår igenom just nu trots att de funnits ute ett tag. Huvudanledningarna var dels att databehoven ökar exponentiellt (typ dubblas varje år) och dels alla nya tjänster på internet som t ex Facebook och Twitter som utöver att de producerar stora datamängder så är dess data kopplat kors och tvärs i stora nätverk sådant som traditionella relationsdatabaser är dåliga på. En annan benämning på webben är Giant Global Graph (GGG).

Han gick igenom de fyra olika typerna av NOSQL-databaser:

Key-Value
Denna typ är den simplaste och är egentligen bara en enda stor hash map. Här rekomenderade han Dynamo. Egenskaper:

• + enkelt
• + bra skalning
• - för enkel datamodell
• - dålig för komplex data

Column Family (BigTable) stores
I denna typ kan varje kolumn innehålla ett eget schema. Exempel på databaser:

• HBase 
• HyperTable 
• Cassandra - mest populär

Dokumentdatabaser
Denna typ gör vad det låter som, nämligen lagrar dokument. Exempel:

• CouchDB
• MongoDB - mest populär "CouchDB without the crazy"
• Terrastore - skrivet i Java

Grafiska databaser
Den typ som Emil Eifrem själv gillade bäst vilket kan bero på att han är jobbar med Neo4J. Exempel:

• Sones GraphDB
• InfiniteGraph
• Neo4J

När han kom in på Neo4J ville han framhålla att det fanns en till stor fördel förutom ökad prestanda och det hänger ihop med hur man modellerar dessa databaser. Han visade ett exempel på en whiteboard-skiss framtagen genom diskussion tillsammans med verksamhetskunniga och som senare kunde implementeras näst intill rakt av. Databasscheman brukar annars sällan vara till så mycket nytta när man pratar med verksamheten! Han uttryckte det också som att dessa databaser skala komplexitet på ett bättre sätt. En nackdel än så länge är att mognaden på verktyg inte på långt när kan mäta sig med verktyg för relationsdatabaser.

Slutsatsen var att NOSQL-databaser inte kommer att ersätta vanliga SQL-databaser utan snarare är ett komplement till dessa. I Spring finns projektet Spring Data som just stödjer användandet av båda dessa typer av databaser.

The Java EE 6 Programming Model Explained
Alexis Moussine-Pouchkine, Oracle

Alexis drog man igenom de förbättringar som gjorts till version 6 av Java Enterprise Edition. Det var en bra dragning och när allt var över kunde man dra slutsatsen att denna version kommer kunna ersätta Spring i många lägen:

• Servlet 3.0 - web.xml är nu valfri!
• JSF 2.0 - Nu lättare att skriva komponenter. Nu vill man på allvar ersätta JSP!
• Bean Validation
• Delar av web.xml kan packas med en jar-fil för enklare konfigurering
• Allt kan nu packas i en war-fil i stället som förut i jar + war + ear.
• Uppmuntrar att börja smått med ManagedBeans och sedan utöka till SessionBeans på ett som det verkade problemfritt sätt!
• JNDI - mer standardiserat sätt att referera bönor i andra projekt.

Introduction to Mirah
Lars Westergren, Mejsla

Mirah är ett två år gammalt språk som tidigare hette Duby. Lars gick igenom på ett pedagogiskt sätt nyttan med språket varvat med kodexempel. Egenskaper hos detta språk som gör att du kan tänkas vilja använda det är att det använder Ruby-syntax så långt det är möjligt. Anledningen till att det inte kan följa Ruby-syntaxen rakt av är att detta språk är statiskt typat till skillnad från Ruby. När du kompilerar Mirah kan du välja om du vill generera Java källkod eller kompilera direkt till Java bytekod. Bytekoden blir mycket likt vad som skulle producerats av Java-kod och en annan fördel är att du inte behöver distribuera en runtime-jar vilket gör den lämpad för t ex utveckling på mobila enheter då man slipper långa uppstartstider.

The Secrets of Concurrency
Heinz Kabutz, JavaSpecialists.EU

Heinz Kabutz driver Java Specialits' Newsletter, Här delade han med sig av sina erfarenheter kring concurrency. Precis som alla andra pratade han om hur viktigt det är att bara använda immutable data när man jobbar med kod som löper risken att exekveras samtidigt av fler än en tråd. Andra saker han nämde var:

• Köra fler än 2500 trådar kan det ge OutOfMemoryError.
• Trådar får hålla lokala kopior av sitt data vilket kan orsaka problem då det inte är säkert att sättning av data "biter" (tråden behåller sin lokala kopia i stället).
• Ett känt problem som han tog upp är att concurrency-problem kan försvinna om man t ex debuggar koden i stället för att köra den vanligt, eller om man förändrar koden t ex genom att lägga in en loggutskrift. Problem kan också uppstå eller försvinna om man byter hårdvara.
• För att lösa låsning av en metod i en klass förespråkade han att man skapar en final instans i klassen som man låser på inne i metoden i stället för att sätta hela metoden som synchronized.

Han summerade upp med att det är svårt att hantera concurrency med hjälp av låsning (lock) då för mycket synkronisering kan ge upphov till starvation och för lite kan orsaka felaktigt data. Som exempel på det senare nämnde han att om två trådar samtidigt skriver värden till en 64-bitars long kunder resultatet bli att de 32 övre bitarna sätts av den ena tråden och de 32 lägsta av den andra, inte så lyckat!

Java EE 6 Toolshow
Arun Gupta, Oracle

Vid det här laget måste jag erkänna att jag var lite trött, därav de få anteckningarna om detta ämne! Han nämnde i alla fall att GlassFish och NetBeans integrerar bra och stödjer kontinuerlig integration inne från IDE:n. Han visade ett exempel där han ändrade en fil vilket automatiskt deployade till GlassFish på 748 ms.

Domain Driven Design BOF
Dan Bergh Johnsson

När livebandet med jazzmusik började spela på hög volym anslöt jag något försenad till denna grupp (observera, har inget emot jazz!) som hade diskussioner kring ett skarpt projekt där de försöker tillämpa DDD. De hade använt mönstret Anti Corruption Layer med en domänmodell ovanpå. Samma lösning som Eric Evans hade pratade om två dagar tidigare. Dan Bergh-Johnsson närvarade inte men Eric Evans dök upp efter ett tag. Det var intressanta diskussioner att lyssna på men jag gick efter knappt en timme för att hinna med åttatåget hem mot Uppsala.

Ons 16/2 - Konferensdag 2

Sista dagen.

Emergent Desing
Neal Ford, ThoughtWorks

Neal Ford hade en bra definition på vad arkitektur är som han lånat från Martin Fowler och tål att repeteras: arkitektur är allt som är svårt att ändra senare

Han pratade om skillnaden mellan "inherent complexity" och "accidental complexity" varav den första är nödvändig komplexitet som man inte kommer undan med och det senare är onödig komplexitet som t ex ett extra lager av arv "för att det kan vara bra att ha". Ett annat resonemang var att teknisk skuld är ofrånkomligt, det gäller bara att hålla den i schack på de viktigaste delarna i kodbasen. Velocityn ökar när man jobbar med refaktorering och omvänt minskar vid ökad teknisk skuld.

HTML5 APIs - The New Frontier
Robert Nyman, Valtech AB

Det var förmodligen inget fel med denna dragning men efter tio minuter, gick jag vidare till Scala-spåret. Det jag hann anteckna var att VideoJS är en videospelare med en fallback till Flash. Vidly var en annan spelare eller tjänst lät det mer som, som han rekomenderade.

Scala, from newbie to ninja in less than one hour
Nina Heitmann, Basefarm
Karianne Berg, Miles

Jag har börjat titta på Scala sedan ett par månader tillbaka och det var lite småsaker som jag inte hade snappat upp som jag fick förklarat i denna dragning. Upplägget var att de två tjejerna spelade att den ene var expert och den andre helt okunnig och det funkade rätt bra och var stundtals ganska kul. En sak jag inte hade förstått var hur for satser var lösta i Scala då de inte ingår i kärnan av språket. Delar av mysteriet fick i alla fall sin lösning. I satsen for (i <- 1 to x) är to en metod som körs på siffran 1 som är en Integer och som använder implicit conversion via klassen RichInteger för att tillhandahålla metoden to till klassen Integer. Enkelt ;-)

Akka: Simpler Scalability, Fault-Tollerance, Concurrency & Remoting through Actors & STM
Jonas Bonér, Scalable Solutions

Då jag i ett par månader håller på att försöka lära mig Scala var Jonas föredrag ett av de jag såg mest fram emot. Han förklarade att man kan se Akka som en verktygslåda snarare än ett ramverk och det var precis det intrycket jag fick. Han började med att förklara vad en Actor var för något. En Actor är ett objekt som har en meddelandekö dit man kan skicka meddelanden. På det viset ligger den närmare den ursprungliga tanken om hur objektorientering bör implementeras än vad t ex "vanliga objekt" gör.

En Actor får bara exekvera ett meddelande i taget vilket gör att man slipper concurrency-problem. Det går att starta upp flera miljoner Actors på en vanlig bärbar dator. Då JVM:en bara kan köra några tusen trådar finns det en mekanism som fördelar arbetet dem emellan. Arbetet kan även fördelas på flera fysiska maskiner. En actor kan starta upp andra actors och även få meddelanden om när de går ned varpå de kan startas om och man får på det sättet ett väldigt stabilt system. Allt som allt var det en bra dragning om Akka och man blir sugen att börja jobba med denna verktygslåda!

Future-proofing collections: from mutable to persistent to parallel
Martin Odersky, Scala Solutions

Martin var intressant att lyssna till. Det pratas mycket om att språket Scala är komplext. Scala har haft en designidé att hålla själva språket så litet som möjligt och i stället utöka det med klassbibliotek. Scala är lite unikt på det viset men gör det väldigt kraftfullt. Mycket av de syntaktiska byggstenarna i Scala upplevs som en integrerad del av språket trots att de bara är delar av klassbibliotek. Detta ger möjlighet att "utöka språket" trots att man bara lägger till nya klassbibliotek. Tanken är att man som användare av dessa klassbibliotek, d.v.s "den vanliga utvecklaren" inte ska behöva förstå all komplexitet bakom. Komplext blir det dock om man vill bygga upp fina och flexibla klassbibliotek och vill att de ska kännas som en del av språket, lite som två sidor av samma mynt.

Han visade hur man med ett par enkla ändringar i en listning kunde förvandla den till att exekveras parallellt genom att endast byta ut listtypen och lägga till ändelsen .par på kodraden som skulle exekveras, mycket imponerande! Detta tror jag kommer i version 2.9 (osäker) som troligen lanseras någon gång de närmaste två veckorna enligt Martins gissning.

Han hade en berättelse som jag tror skulle belysa vikten av kraftfulla klassbibliotek. En undersökning där studenter skulle utföra en programmeringsuppgift i olika språk resulterade i att de som hade jobbat med dynamiska språk i genomsnitt hade bättre prestanda än versionerna i de statiska språken t ex C++. Detta var för tio år sedan och hans tolkning av resultatet var att de dynamiska språken hade snabba kompilerade klassbibliotek som de lutade sig mot men att C++ utvecklarna på den tiden skapade egna bibliotek för t ex listor vilket i vissa fall hade mycket dålig prestanda. Den snabbaste lösningen var dock i C++!

Give Scala a try? Test your Java code with Scala
Andreas Kaltenbach, Stendahls.net

Denna dragning var tyvärr lite av en besvikelse. Andreas Kaltenbach uppehöll sig lite för länge när han beskrev sitt företag Stendahls innan han gick vidare och pratade om testning av Java-kod med hjälp av ScalaTest. Han nämnde att det finns ett till testramverk ScalaCheck som är en port från Haskell. Han kände inte till att det går att få ut förväntat värde när ett test failar. Det går dock genom att ärva från JUnitSuite och mixa in ShouldMatchersForJUnit och skriva test i stil med: value should be (5). Mitt projekt för att lära mig Scala heter TetrisAi och använder tester som följer detta mönster. Jag skriver även om framstegen här En Javaprogrammerares väg mot Scala (börja med äldsta inlägget).

Programming in pain
Enno Runne, Transmode

Enno Runne körde en 15 minuters dragning om den frustration man kan känna när man suttit med Scalas rika abstraktioner och rena syntax och sedan återgår till att utveckla i Java. Han gick igenom ett antal exempel där han jämförde hur man gör i Scala och hur motsvarande görs i Java. Det var mycket pedagogiskt och belyste väl centrala skillnader mellan de två språken. En slutsats är att man blir en bättre Java-utvecklare av att jobba med Scala!

Abstraction Distraction
Neal Ford, Thoughworks

Neal Ford fick äran att avsluta Jfokus vilket jag tycker var ett bra val då hans dragningar i mitt tycke varit mycket bra rakt igenom. Här gjorde jag inga anteckningar och då dragningen var fullspäckad och höll högt tempo tänker jag inte skriva så mycket om denna avslutande dragning. Hans presentation kommer att läggas upp antingen på hans egen sida eller på Jfokus sida. Dragningen i stort gick ut på att man kan styrs av (distraction) de föreställningar (abstractions) man skapat om sin omvärld. Han hade ett antal exempel och det hela kändes både roande och tänkvärt, en bra avslutning på tre dagars konferens helt enkelt!

Om jag förstod rätt så filmades endast föreläsningarna i konferenssalarna A1, A2 och A4. I år var det så späckat med bra föredrag att man missade några stycken. Dessa ska jag försöka kolla igenom:

• Git from the Ground Up, Matthew McCullough - var tydligen en mycket bra talare, osäker om denna kommer att läggas upp då den visades i rum 24/25
• Cloud Computing with Scala, Nikita Ivanov - alla jag pratade med var mäkta imponerade!
• Scrum & XP - beyond the trenches, Henrik Kniberg
• Folding Together DDD and Agile, Eric Evans
• Ubiquitous Language, Dan Bergh Johnsson

Sammanfattningsvis var Jfokus en kanonkonferens i år!

Scalaträff med Martin Odersky

Denna träff anordnades av Scala User Group i Omegapoints lokaler direkt efter konferensens slut. Gästerna var Martin Odersky och ytterligare en (som jag tyvärr inte minns namnet på) av totalt fyra (Martin inräknad) core developers av Scala-kompilatorn. Totalt var det drygt fyrtio fritt inbjudna som var där för att ställa frågor till skaparen av språket Scala. Innan allt drog igång bjöds det på wrapps och det hela var mycket trevligt och bra ordnat! Det blev mycket frågor på en ibland ganska djup teknisk nivå. Martin och hans bisittare hade förstås stenkoll på ämnet och svarade pedagogiskt på alla frågor. Det händer mycket spännande saker med Scala de närmaste åren. Bl.a. jobbas det med ett projekt som är sponsrat av EU och som går ut på att kunna bädda in DSLer i själva språket Scala. Det pratades om plugginer till själva kompilatorn men är osäker på om det är den tekniken som var tänkt för de inbyggda DSLerna. De inbyggda DSLerna ska kunna kompilera till annat än Java bytekod, t ex direkt till speciell hårdvara (grafikkort mm) för beräkningsintensiva uppgifter. På frågan vilket språk han skulle välja om han inte fick välja Scala var svaret F# (fsharp)!