Jfokus 2016

Senast jag var på jFokus var 2014, så nu var det åter dags igen. I år hoppade jag över den första dagen av tre.

Tisdag 2016-02-09

Move Deliberately and Don't Break Anything - Brian Goetz, Oracle

Öppningstalet av Brian var mycket bra. Han lyckades på ett pedagogiskt sätt förklara hur arbetet med att utveckla Java går till (idéerna bör gälla även för andra språk). Det är ett väldigt stort arbete som föregår även till synes små förändring av Java. Man måste ta hänsyn till de miljontals utvecklare som finns och de miljarder och åter miljarder rader kod som körs på olika plattformar. Kod som kompilerades för tjugo år sedan måste fortfarande fungera. Utvecklare måste känna igen sig i språket, det ska fortfarande "kännas Java". 

Varje förändring stänger också dörrar till framtida förändringar. Därför måste stor tankemöda och eftertänksamhet föregå varje förändring. Det betyder inte att språket inte utvecklas, bara att det inte är möjligt att införa icke bakåtkompatibla ändringar och att man har ett väldigt stort ansvar gentemot befintliga användare, utvecklare och system. Denna genomgång gav en bättre förståelse för varför det tog flera år innan Oracle släppte sin första Java-version efter övertagandet från Sun. Det ska vi vara glada för, då det gäller att skynda långsamt i dessa sammanhang!

Designing for Performance - Martin Thompson, Real Logic

Detta var första gången jag lyssnade på Martin, vilket är en mycket energisk talare som kan sitt ämne och utstrålar mycket entusiasm. Han gick igenom olika saker att tänka på om man vill få bra prestanda i sina system. Till att börja med kan prestanda betyda olika saker. En aspekt av prestanda är throughput, alltså hur snabbt data kan flöda från A till B (genomströmning). En annan är latency (svarstider). Båda påverkar prestandan. Kunskapen kring vad som ger bra prestanda har funnits länge. Köteori är till exempel något som praktiserats i Erlang. En grundregel är att ha tillräcklig kapacitet så att det inte "stockar igen", vilket kan vara förödande, likt trafikstockning.

Martin återkom ganska ofta till Amdahl's law som är en modell för hur svarstider (latency) påverkar prestanda. En annan sak han tog upp var att synkroniserad loggning påverkade prestandan negativt. Han gillade inte missbruk av abstraktioner. Först när man ser ett tredje exempel av duplicering i sin kod ska man överväga att skapa en abstraktion som angriper dupliceringen. Abstraktioner har sitt pris, precis som duplicerad kod har sitt. Det hela är en avvägning, vilket jag håller med om. Min egen reflektion är att man allt för ofta ser kod där utvecklarna inte gjort denna avvägning. 
Utan att tänka på konsekvenserna, försöker man ta bort all kodduplicering man hittar, för att göra koden så DRY som möjligt. Resultatet är ofta kod som är fullmatad med abstraktioner till höger och vänster, vilket leder till att koden blir svår att följa, förstå och vidareutveckla. Varför inte avsluta detta ämne med Martins egna ord "beware DRY, the evil siren that tricks you into abstraction".

Nästa viktiga sak för att skapa god prestanda är att skriva enkel kod. Ett tips är att tänka efter före innan man sätter sig vid tangentbordet. Dokumentera, diskutera och skriv tester innan, var några av förslagen. Min egen observation är att detta med att tänka efter före verkar vara på utdöende. Man tror att allt går att "fixa till efteråt". Han nämnde ett bra citat av Blaise Pascal, "If I had more time, I would have written a shorter letter".

Nästa tips var att batcha upp saker och det gäller inte bara batch-jobb utan det kan även vara en framkomlig väg för att "samla ihop" arbete i runtime och utföra det från ett ställe på ett kontrollerat sätt. Kötänkandet är en bra metafor enligt min mening och ett sätt att förenkla flöden och minska komplexitet.

Ha många och små loopar istället för en stor, så att antalet instruktioner i loopen ryms i processorns cache. Har man programmerat lågnivåspråk som assembler eller C så är man troligen redan medveten om detta, men det gäller även andra språk som Java, då de ofta i slutändan kompileras till maskinkod. Nästa sak att tänka på är att API-konstruktörer ska lämna kontroll till användarna av API:erna (utvecklarna), vilket går att läsa mer om på hans blogg.

För att inte lägga för mycket tid på prestandaförbättringar ska man sätta upp prestandamål i förväg. När målen väl är uppfyllda, finns det ingen större anledning att fortsätta optimera! Han nämnde även HdrHistogram som kan användas för att skapa histogram. Ett annat tips var Java Microbenchmark Harness (JMH) som är "a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks written in Java and other languages targetting the JVM". 

Slutligen citerade han en flygtillverkares motto "If it looks good - it flies well" - vilket stämmer bra även för kod och system! Det fick mig att tänka på mitt eget motto - Är det fult så är det fel!

ES2015: Using tomorrow's JavaScript today! - Pratik Patel, TripLingo

Denna föreläsning gick ut på att det är en god idé att redan nu använda nästa version av JavaScript (ES2015). Att migrera ES2015 till äldre versioner av JavaScript kan göras med hjälp av Babel.

Patrik gick igenom de viktigaste förbättringarna:

- Stöd för scope (lokala deklarationer av variabler och konstanter)

- Variabler får lokalt scope i t.ex. for-loopar och let-satser

- Template literals, t ex. `Hello ${name}`

- Object.assign(....) - gör en "shallow merge" (kopiering av objekt, men ej deep copy)

- Stöd för desctructuring (lånat från Clojure)

- Modules (paket/namespace)

- Default-parametrar (likt C++)

- Nya datastrukturer, Set och Map

- Promises (likt Scala eller Clojure)

Något att tänka på var att om samma import görs från flera ställen så kommer man att referera till en och samma instans!

Java Streams: Beyond The Basics - Simon Ritter, Azul Systems

Simon kommer från det imperativa hållet, vilket han var helt öppen med (där kom han visst ut ur garderoben!). Alla har inte hunnit bli fena på funktionell programmering än, men Simon verkar vara på god väg.

De nya stödet för Lambda-uttryck och strömmar (streams) i Java 8 gicks igenom:

- logger.finest(tungOperation()) tvingar loggern att exekvera funktionen (i det här fallet en tung sådan, tungOperation). Gör man om det till ett Lambda-uttryck så exekveras funktionen endast ifall loggnivån säger så: logger.finest(() -> tungOperation()).

- Har man en lång "pipe" med funktioner i en ström, kan man använda peek() för att göra en "pass through" (in-datat skickas vidare opåverkat) vilket gör att man t.ex. kan printa saker till konsollen.

I JDK 9 kommer ett antal förbättringar:

- Optional har en stream()-metod som returnerar en ström med ett eller inga element, vilket förenklar koden och minskar den cyklomatiska komplexiteten (min observation).
- Collectors.flatMapping() är ett standardsätt i funktionella språk för att platta ut datastrukturer.
- Files.lines() - tillåter parallell läsning av filer
- takeWhile() - plockar från strömmen så länge villkoret är sant
- dropWhile - ignorerar element från strömmen så länge villkoret är sant

Ett tips vara att försöka undvika forEach till förmån för reduktion.

Vid något tillfälle sade han att state is good vilket jag inte håller med om. State is evil ligger närmare sanningen. Läs gärna den mycket underhållande första halvan av Out of the Tar Pit så för att förstå vad jag talar om!

Avslutningsvis rekommenderade han en titt på Zulu som är a tested and certified build of OpenJDK.

The Tech Coach strikes back - Tobias Modig, Citerus

Tobias spaning var att man öser tid och pengar på agila satsningar som sällan når utvecklarna, trots att det definitivt är kärnverksamhet (ingen kod, inga system!). Devisen var Developers need to strike back! "we earn our cut from the coaching cake". Tyvärr förde jag inga anteckningar. Då Tobias var mycket väl förberedd och lyckades leverera femton informationstäta minuter, rekommenderar jag istället den nyfikne att invänta släppet av videon.

Speed, scale, query: can NoSQL give us all three? - Arun Gupta, Couchbase and Matthew Revell, Couchbase

Här får jag erkänna att jag var lite trött och att jag inte orkade föra anteckningar i någon större utsträckning, men att ämnet trots det intresserar mig. NoSQL står för Non-relational och sammanfattar alla databaser som inte är relationsdatabaser, vilket innefattar bland annat kolumnorienterade, graf- och key/value-store.

Något att tänka på var att replikering kan fungera dåligt för grafdatabaser i kluster, i fallet att data som hänger ihop och som man vill läsa råkar hamna på olika fysiska maskiner. Jag får hänvisa till videon!

JavaScript Gotchas - Shay Friedman, CodeValue

Det här var en riktigt underhållande föreläsning av Shay. Jag fick vatten på min kvarn vad gäller mina fördomar om JavaScript som ett leksaksspråk! Han gick igenom språket och visade den ena tokigheten värre än den andra. Tydligen kokades språket ihop på några dagar, troligen kan de inte ha varit helt nyktra heller, skrockade Shay :-) Här är några exempel som får en att fundera "hur tänkte dom?":

- Deklarerar man en variable i en funktion med var x = 5, blir den lokal, däremot blir x = 5 global.

- När man skriver var x = 5 inne i en if-sats (eller liknande kodblock), så blir den ändå global!

- Använd inte ==, använd ===. Den förstnämnda kan man inte lita på, till exempel är '1' == 1 true, medan [] == false. === kan man däremot lita på, då den gör en "normal" equals-jämförelse.

- Använd funktionen isNaN(x) för att testa om något är ett riktigt värde.

- För att snabba upp for-loopar, kan man tilldela längden på t.ex. en lista till en variabel (som man ska iterera), annars vill språket fråga listan varje varv i loopen efter dess längd, vilket i värsta fall kan fördubbla exekveringstiden.

- Lägger man ihop två strängarna med plus-operatorn, får man en ny sträng (så som det brukar fungera i andra språk): '3' + '1' = "31", medan subtraktion av strängar gör något helt annat: '3' - '1' = 2.

- Match.pow(2,53) = 9007199254740992 är det högsta talet som JavaScript hanterar. Adderas något till detta höga tal så klagar inte språket (kastar exception eller liknande), det händer ingenting och talet är oförändrat efter operationen.

- JavaSkript-kod försöker förkompilera koden, men om det finns ett try-catch-block så kompileras inte koden. Funktioner som är mer än 600 tecken kompileras inte heller.

- [5] * [5] = 25

- [5] + [5] = "55"

- typeof(x) funkar bara på primitiver, allt annat ses som "object" (arrayer, objekt mm). Använd istället instanceof(x).

- new Boolean(false) är true!

Ett tips var att alltid använda use strict, vilket tvingar dig att deklarera variabler med var.

Pub

Kvällen avslutades med gratis öl, vin, mat och mingel, med möjlighet att spela biljard, fotbollsspel (foosball) och gamla hederliga arkadspel (2D-bilspel). Det var kul, trots att biljardbordet lutade betänkligt (70% av bollarna hamnade på ena halvan efter sprängning!) Jag hann med några fotbollsmatcher också, men tyvärr torskade jag och min medspelare då motståndet var bästa möjliga (proffs från okänt öststatsland, de verkar inte göra annat där)!

Onsdag 2016-02-10

Git From the Bits Up - Tim Berglund, DataStax

Jag var imponerad av det sätt som Tim lade upp denna föreläsning. Genom att manuellt skapa ett lokalt repository med dess kataloger och filer, lyckades han ta udden av en del av den förvirring och respekt man som nykomling till Git kan känna. Han började med att skapa katalogen .git, och fortsatte med att lägga till olika kataloger och filer. Till exempel skapade han textfilen .git/HEAD med innehållet ref: refs/head/master, vilket illustrerade att HEAD bara är en "pekare" mot aktuell branch, vilket ganska ofta är master men kan vara vilken annan branch som helst. 

Han avrådde från att använda kommandot rebase. Det är något som vissa gillar att använda när de ska "städa upp" och organisera bland sina "små-committer" och göra om dem till större och mer sammanhängande dito, till exempel en hel story.

Om jag förstod det hela rätt så fanns det bara två sätt att förstöra information "för evigt" och det var genom rebase och git reset --hard <commit>. Git har annars den goda vanan att låta all information leva kvar (vilket gör det till immutable data). När du tror dig ha förlorat information så ska du ta dig en titt under .git/refs/branch där branch till exempel kan vara master. Genom att lista vad som finns där, kan man enkelt återställa sitt lokala repository till en tidigare tidpunkt, t.ex. git reset --hard d600160 (notera att icke commitade ändringar går förlorade).

När videon släpps, ska jag definitivt titta på denna en gång till!

Frege: purely functional programming for the JVM - Dierk König, Canoo Engineering AG

Dierk var rolig att lyssna på, framförallt på grund av hans hängivenhet till den matematiska enkelhet och skönhet som finns i detta språk Frege, som är en Haskell för JVM:en. Jag har tyvärr själv aldrig programmerat i Haskell, men vet att det är ett rent funktionellt språk som separerar sidoeffektfri kod, från kod med sidoeffekter (mutering av objekt, skrivning till filsystem, databaser och liknande). Det fina med det är att den sidoeffektfria koden plötsligt går att resonera kring, då definitionen är att den varken påverkar annan kod, eller blir påverkad av andra. 

Gottlob Frege har var en tysk matematiker, logiker och filosof som lade grunden till den moderna predikatlogiken och som alltså fått ge namn åt detta språk. 

Dierk börjar med ett exempel på imperativ kod som muterar variabler och som ganska snart visar sig swappa två variabler så att a blir b och b blir a genom temporärvariabeln c. För att förstå koden måste man "exekvera" koden i huvudet och hålla reda på vilka värden de olika variablerna har. Det funktionella sättet är att anropa funktionen swap(a,b) som gör om (a,b) till (b,a) utan att påverka varken a eller b. Funktionen är som att sätta på sig ett par glasögon som utför själva platsbytet.

Sedan fortsätter Dierk med att gå igenom hur funktioner definieras rent logiskt i Frege och hur komposition av funktioner till mer komplexa sådana fungerar. Isolering av kod som innehåller sidoeffekter görs med hjälp av monader. 

Jag tror många Java-utvecklare skulle må bra av att köra lite Frege ett tag! Om man vill testa Frege, kan det göras här direkt i webbläsaren.

Healthcare for the elderly using the IoT - Gerrit Grunwald

I ärlighetens namn funderade jag på vad jag gjorde på denna föreläsning de första minutrarna. Men det tog sig efter hand och när det hela var över hade jag lärt mig både en del om äldre människor på landsbygden och om hur man kan bygga system som övervakar dess hälsa.

När yngre människor flyttar från glesbygden lämnar de en åldrande befolkning efter sig. Det innebär också att antalet läkare per vårdbehövande minskar, att avståndet till närmaste vårdgivare och specialistvård ökar. Gamla människor flyttar ogärna, med risken att de insjuknar eller ramlar utan att någon upptäcker det i tid och då kan det vara för sent.

Gerrit visade hur man kan upptäcka försämringar i gamla människors hälsotillstånd genom övervakning. Det gjordes på ett antal sätt, t.ex. genom att hålla koll på hur de rörde sig från rum till rum, eller hur de rörde sig i sin omgivning (Geo fencing). Uppgifter om hur många steg de gick per dag, hur länge de tittat på TV, var andra indikatorer.

Denna data samlades in och analyserades. Det mest framgångsrika sättet att samla information på var mobiltelefonen och/eller smart klocka. Fallolyckor kunde registreras med 85% säkerhet genom en app som använde mobilens gyro och som skickade larm per automatik till en kontaktperson när en olycka inträffade.

Förutom mobiltelefon och klocka kunde flic-knappar programmeras och användas för att larma på ett enkelt sätt.

Det var inte helt problemfritt att analysera all den data som kom in. Till exempel behövde man förstå om GPS-data innehöll avbrott i täckningen. Tekniken att sätta en mottagare i varje rum för att se hur en person rörde sig, förde svårigheten med sig att personen på vissa ställen uppfattades befinna sig i flera rum samtidigt.

Spark användes för att analyzera och sammanställa allt data. 

Förutom det tråkiga i att övervaka människor, tror jag det kan vara ett värt att överväga om man vill göra äldre människors liv lite tryggare och de anhöriga lite lugnare!

From JavaScript to ES6 - how ChakraCore changes the game - Christian Heilmann, Microsoft

Detta var det andra föredraget om JavaScript för min del denna konferens. Det mesta var redan sagt av Shay Friedman i JavaScript Gotchas, så som att själva språket skapades på kort tid med många brister och att det är ett problem att man inte alltid vet i vilken runtime (webbläsare) som ens program körs i.

Många utvecklare tar sig inte tiden att lära sig språket ordentligt, utan nöjer sig med att leta lösning i form av kodsnuttar ut på nätet. Vidare så rekommenderade han Microsoft webbläsare Edge. 

Avslutningsvis hade han ett bra citat "if you start teaching you end up learing"!

React - Say "No" to Complexity - Mark Volkmann, Object Computing, Inc.

Mark hade jobbat med AngularJS1 och även undervisat i det. När tvåan kom, som innehöll omfattande förändringar, såg han sin chans att testa React. AngularJS är ett mer omfattande och komplett ramverk än React, men trots det så föredrog han det senare. Slides:en var alldeles för packade med information för att fungera bra i ett föredrag. Bortser man från det tror jag att den inbitne webbutvecklaren (jag räknar mig inte till dem) fick en rätt hygglig genomgång av ramverket. 

React skiljer sig från andra ramverk genom att den har en idé om att koden bara ska känna till en datamodell och att grafiska komponenter uppdateras "per automatik" när förändringar i denna "virtuella DOM" sker. Den stora fördelen är att koden blir enklare. Ett intressant alternativ för de som gilla funktionella alternativ är Om som är en wrapper runt React för ClojureScript (egen reflektion).

Jag hänvisar den intresserade till videon.

Maven - Taming the Beast - Roberto Cortez, Tomitribe

Jag kom tyvärr något sent till denna föreläsning. Det enda jag lyckades anteckna var att om en jar "försvann" kunde man köra mvn dependency:list. Resten får jag hänvisa till videon.

Coding Culture - Sven Peters, Atlassian

Avslutningen av Sven var stabil, dock inte så mycket nyheter för min egen del. Han använde "sitt eget" företag till att belysa hur det går att skapa en god företagskultur. Jag gjorde inga anteckningar här heller. 

En kul grej de gjorde på Atlassian var att de använde sig av personas, vilket är fejkade personer som får representera olika användartyper, så som "Gösta 45, lastbilsschaffis" och "Linda 23, student". Dessa var uppsatta överallt på företaget, till och med på toaletten! Detta för att de skulle nötas in och användas för att fånga användarkrav och att ha något konkret att bolla lösningarna mot.

Tävlingen

I Microsofts bås hade de en tävling som gick ut på att väga en dator med bara händerna och att fylla en låda med olika stora stenar så att man hamnade så nära datorns vikt som möjligt. Jag lyckades hamna närmast och fick därför stoltsera med mitt namn överst på listan redan när jag kom på tisdag morgon. 15.15 nästa dag skulle vinnaren utannonseras och en språjlans ny smartphone skulle delas ut till den lycklige vinnaren. Sista föredraget innan prisutdelningen låg jag fortfarande etta, endast två gram ifrån och där tvåan var fyra gram ifrån. Så allt såg bäddat ut för en succé. När jag kom tillbaka för att inkassera mitt förstapris visade det sig att en viss Johan Karlström hade snuvat mig på förstapriset och kommit närmare än mina två gram. Jag fick nöja mig med en sådan där laddare som man kan ladda enheter med utan att vara inkopplad i eluttaget!

För att trösta mig gick jag upp till Mejslas monter där jag fick en helt förträfflig massage av Anna på Energimassage. Tack för den!

Vissa år har man traskat ut från föreläsningar som varit sisådär samtidigt som andra fått sig en halleluja moment i salen bredvid. I år lyckades jag dock bra med att pricka in intressanta föreläsningar.

Det skulle inte förvåna mig om jag dyker upp redan nästa år på denna eminenta konferens!

Jfokus 2012

Jfokus var även i år förlagt till Stockholm Waterfront Congress Centre och varade i två eller tre dagar beroende på om man valt att vara med på tutorialdagen. I år skötte sig dessutom SJ och såg till att jag kom fram i tid!

Mån 13/2 - Tutorial

Continuous Delivery
Neal Ford, ThoughtWorks, Inc

Neal Ford var väldigt bra på Jfokus 2011 och förväntningarna var därför ganska högt ställda. Begreppet Continuous Integration (CI) lär vid det här laget vara ett bekant begrepp för de flesta som jobbar med systemutveckling. Neal pratade om att det egentligen handlar om tre typer:

Continuous integration
 - integrera tidigt och ofta
 - snabbare att integrera många små ändringar ofta än en stor

Continuous deployment
 - mjukvara ska alltid vara deploybar, men inte nödvändigtvis färdig att produktionssättas. Det är QA och "integration" som bestämmer när det är dags att ta in en ny version till testmiljön.

Continuous delivery
 - låt verksamheten (business) bestämma när något ska produktionssättas.

Det betonades hur viktigt det är med den feedback-loop som uppstår när man levererar ofta. Om man levererar sällan, t ex två gånger per år, finns det en risk att användarna beställer mer funktionalitet än de behöver "för säkerhets skull". Systemet har också större möjlighet att utvecklas i rätt riktning då det snabbare kan reagera på användarnas behov. Ett exempel var Flickr som från början var en spelserver där användarna kunde ladda upp sina avatarer. När man upptäckte att användare även laddade upp andra privata bilder utvecklades Flickr till vad det är idag.

En annan fördel att leverera ofta är att mängden förändringar i systemet minskar vilket gör att det inte blir en "en stor grej" för användarna vid nya releaser. Strategin med att leverera ofta gör att man kan minska risken, då en liten förändring av naturen är enklare att införa. Samma princip gäller även vid incheckning av kod och merge:ning (egen observation), d.v.s: gör det ofta, eller som Neal uttryckte det if it hurts, do it more often.

Bland det viktigaste han tog upp var vikten av att versionshantera i princip allt vilket ger spårbarhet och möjlighet att återskapa miljöer i önskat tillstånd, eller som han uttryckte det keep everything you need to build, deploy, test & release in version control!

Brian Maricks kvadrant med de fyra grupperingarna av tester gicks igenom.

Vad gäller branchning var hans råd att bara göra release-brancher. Behöver man jobba med en funktion som inte ska levereras så kan det vara bättre att använda "feature toggles", d.v.s. att under en tid kunna slå av de delar som inte är klara. När dessa är klara att levereas så tas toggle-koden bort. Build-time switchar kan användas men har nackdelen att man kan tvingas ha dubbla uppsättningar tester.

En annan sak som Neal tog upp var att det är bra att rotera in utvecklare så att de får jobba med drift. De får på så sätt en bättre förståelse för systemet, t ex att det är viktigt att ha bra loggningsmeddelanden! Det minskar även friktionen avdelningar emellan. Enligt Neal så spenderas 80% av budgeten på drift. Anledningen är att utveckling "throws crappy code over the wall" som leder till att drift får ägna en stor del av sin tid åt brandsläckning.

Han tog upp något han kallade information radiation som går ut på att sprida information på ett sätt som inte är påträngande, t ex genom att sätta upp informationsblad vid kaffemaskinen eller låta varje utvecklare ha sin egen favoritsång som spelas varje gång dennes incheckning passerar en längre byggsvit, eller spela "Ooops I did it again" när det smäller!

Detta följdes sedan av en rätt lång dragning kring komponentbaserad design som inte innehäll några nyheter för egen del och jag tänker därför inte ta upp det här. Därefter tog han upp nödvändigheter av att versionshantera databasen. Det verktyg han rekommenderade var Liquibase som verkade rätt hyfsat men har nackdelen att allt konfigureras i XML.
 
Sammanfattningsvis var det en bra genomgång som ville belysa att ansvaret att leverera kvalitet inte tar slut i och med att byggservern lyser grönt och man har levererat till testmiljön!

CQRS & Event Sourcing, a crash course
Greg Young

Greg började med att gå igenom grunderna i Domändriven design (DDD) så att alla kunde hänga med. Han började med att slå ett slag för Bounded Context som är ett begrepp inom DDD som förenklat går ut på att man kan ha fler än en modell vilket gör respektive modell mer ändamålsenlig.

Han använde en jämförelse för att förklara varför olika delar av en organisation med tiden kan få svårt att förstå varandra. Exemplifieringen var hur människor som har lite kontakt med varandra till slut utvecklar olika dialekter och språk. Lösningen är mer kommunikation vilket leder till ett mer homogent språk och bättre förståelse vilket är bra när man ska hjälpas åt att bygga system avdelningar emellan. Inom DDD kallas detta ubiquitous language.

Vad gäller uppskattning av ungefärlig storlek på arbetsuppgifter, t ex i story planning 1 i Scrum, föredrog han uppdelningen i Small (S), Medium (M) och Large (L) framför fibonacci-serien. Anledningen ligger i hur människor fungerar och där kan jag tala av egen erfarenhet. När vi i ett tidigare Scrum-team insåg att vi brukade göra ungefär tio story point per tvåveckors-sprint var det inte svårt att översätta detta till en poäng per dag vilket ledde till att vi i praktiken estimerade dagar och vi förlorade på det sättet grundidén att göra relativa och ungefärliga bedömningar av storlek varpå också velocityn låg ganska jämt oavsett hur snabbt eller långsamt vi jobbade.

En vettig fördelning är att ca 20% estimeras till Small, 20% till Large och resten som Medium.

Dags att skriva lite om själva ämnet CQRS som står för Command Query Responsiblility Segregation. Greg förklarade att CQRS inte ska användas på alla delar av systemet utan bara på de delar som både är viktiga och har en hög grad av komplexitet, eller L + L om man skulle göra en relativ storleksestimering av viktighet och komplexitet. Han tryckte på att business components, vilket ofta är service:ar, ska placeras inom ett specifikt bounded context och att de inte får delas mellan olika kontext.

Han gillade inte OR-mappers och en av anledningarna var att de genererade dubbelriktade beroenden mellan klasser, något som man vanligtvis vill undvika. En annan invändning var att det gärna blir CRUD-operationer och att man lätt tappar fokus på syftet med ändringarna. Som exempel tog han att det är skillnad på en rättning av en adress och en adressändring. Tänker man CRUD-operationer skulle båda dessa troligen landa i att man gjorde set-metoder som förändrade state.

CQRS är en vidareutveckling av CQS som står för Command Query Separation, där C:et får mutera state men inte Q och S. I CQRS separerar man läsning och skrivning. En god sak med det är att den halva som utför skrivning inte behöver implementera några getters, det tar halvan för läsning hand om. Greg tog det lite längre och föreslog att man skulle prova sluta använda getters över huvud taget, vilket jag personligen tycker är en bra målsättning!

En annan fördel kan vara att läs- och skrivmodellen kan se helt olika ut. Det finns även prestandavister att göra då de två kan ligga i olika databaser och att läsmodellen kan optimeras för läsning genom att platta ut datastrukturerna på liknande sätt man brukar göra med matrialiserade vyer. En tumregel för huruvida du kan använda CQRS är huruvida du kan använda optimistisk låsning är applicerbart eller ej. Om det går så kan man även använda CQRS-mönstret.

Han tog upp ett viktigt mönster Tell Don't Ask som om man följer länken har en bra summering under Very very short summary och som beskriver de problem som är förknippade med att upprätthålla detta mönster i objektorienterade språk. Personligen ser jag mönstret DCI som ett elegant sätt att tackla detta problem.

Greg rekommenderade användning av aggregat som uppmuntrar till att fokusera på beteende istället för struktur. En aggregatrot är en samling av klasser med ett tydligt och avgränsat ansvar som är grupperade i en genensam klass med ett enhetligt API mot omvärlden.

En kul grej var att Greg ägnade en hel del tid åt att skriva exempelkod som inte använder sig av dependency injection. Detta sätt att skriva kod var från början en work-around då de hade haft problem med DI-containern, men har sedan blivit något han hållit fast vid. Han såg ett problem i det faktum att det är lätt att lägga till beroenden när man använder DI som har beroenden som har beroenden o.s.v och ville istället synliggöra detta genom att tvingas handjaga kod så att: you feel the pain! Han var ganska tydlig med att han inte gillar ramverk!

CQRS använder sig av event sourcing som i korthet går ut på att kunna återskapa aktuellt eller tidigare tillstånd (state) genom att "summera" de tillstånd som har skickats sedan startpunkten. Detta går bra eftersom alla event som påverkar tillståndet lagras. En teknik är att ta snapshots på databasen så att man slipper spela upp alla händelser från tidernas begynnelse.

Han försökte visa hur man kan betrakta objekt som mottagare av händelser och där API.et speglar det beteende man vill åstadkomma snarare än förändring av tillstånd. Det senare ska ses som en intern angelägenhet. Ibland kan det vara en hårfin skillnad. Jag lyckades inte skriva ned hans exempel, men kan ta ett annat. Antag att en person avlider. Då kan man skicka händelsen "avliden" till person-objektet i stället för att anropa metoden setDeceased(true). Metoden som muterar state görs till en privat metod medan metoden som representerar beteende görs publik.

Tis 14/2 - Konferensdag 1

Dagen började med keynote av Juergen Hoeller från SpringSource. Tyvärr gjorde jag inga anteckningar, men jag minns att det var bra!

Play Framework 2.0
Peter Hilton, Lunatech Research

Play-ramverket har funnits ett par år men börjar slå igenom på allvar kanske också beroende på att den släppts i version 2.0 som är helt omskriven i Scala. Det framhålls att ramverket är skrivet av webbutvecklare för webbutvecklare till skillnad från den uppsjö MVC-ramverk som finns i Javavärlden som har till syfte att abstrahera bort underliggande tekniker som HTML och Java Script. Play vill istället ge webbutvecklaren så mycket kontroll som möjligt.

I Play kan du trycka reload i webbläsaren för att testa dina kodändringar vilket ger snabb återkoppling till dig som utvecklaren. En annan bra sak var att allt från Java Script till de mallar som används för att bygga GU kompilerades. Istället för långa stack-trace:ar får man fina felmeddelanden med exakt rad för felet vilket såg mycket lovande ut! Tekniken bygger på REST som går ut på att inte hålla tillstånd (state) på servern utan låta det hanteras av klienten.

Tekniker som används i Play var {less} som är en templatemotor för CSS, CoffeeScript är något som kompileras till JavaScript och ska vara en förbättring av JavaScript. Under ytan används Closure Compiler från Google för att optimera JavaScript-koden.

Programmeringsmodellen är asynkron vilket är bra om man t ex behöver streama mycket data till "molnet".

Han rekommenderade ett par böcker som beräknas komma i slutet av detta år:
  Play 2 with Scala in Action, Peter Hilton, Erik Bakker, Francisco Canedo
  Play 2 with Java in Action, Nicolas Leroux, Sietse de Kaper

Sammanfattningsvis tror jag att i projekt där man låter icke webbutvecklare göra GUI så har MVC-ramverk som JSF fortfarande sin plats. Vill man däremot utnyttja kraften i den underliggande tekniken och korta ned feedbackloopen vid utveckling är Play ett bättre alternativet. Dock ställer Play högre krav på utvecklarna. Vilket val man gör beror på situationen.

Peter Hilton var en kul killa att lyssna på och gav en bra introduktion till Play. Något han ofta återkom till var exempel på att det ena eller det andra var fult och därmed också dåligt. Då kom jag givetvis att tänka på min devis: År det fult så är det fel!

Maven vs Gradle, On your marks, get set, go!
Hardy Ferentschik (Red Hat)

Hardy började med att visa några bra kommandon i Maven:
  mvn dependency:tree
  mvn dependency:build-classpath
  mvn help:describe -plugin=compiler
  mvn help:Ddetail
  mvn help:effective-pom

Därefter visade han ett omtalat blogginlägg av Kent Spillner som lyder: Maven builds are an infinite cycle of despair that will slowly drag you into the deepest, darkest pits of hell (where Maven itself was forged).

Han menade på att Maven fått ett oförskämt dåligt rykte och att Maven faktiskt gör ett bra jobb i att lösa beroenden. Han poängterade att det visst går att sköta en del av beroendena manuellt så att inte "halva internet" tankas ned via en explosion av beroenden. Däremot gillade han inte assembly-pluginen som konstaterade "var trasig".

Matchen mellan Maven och Gradle slutade med siffrorna 3-4 till Gradles favör. Maven vann ronderna distribution, lurning curve och IDE support medan Gradle vann customizable, documentation, speed och resource consuption.

JDK 7 Updates & JDK 8

Denna föreläsning skulle ha hållits av Ben Evans men ersattes av Dalibor Topic, också från Oracle.

Denna lilla dragning utvecklades tyvärr till ett långt sömnpiller. Det var slide efter slide med korta sammanfattningar av kommande funktioner dock utan exempel. Det var lite synd för det märktes att mannen visste vad han pratade om.

Han presenterade följande två länkar för den intresserade:
 Mark Reinhold's blogg
 JDK Enhancement Proposals.

Vad Clojure lärt mig om objektorientering (som jag inte lärt mig av Java)
Ville Svärd, Agical AB

Clojure är ett mycket intressant språk på Java-plattformen och en dialekt av Lisp. Han gick igenom den viktigaste principen inom objektorientering, nämligen inkapsling och konstaterade att den tjänar två syften, att skydda och att abstrahera. Då allt i Clojure är immutable finns heller inga setters utan representeras istället av funktioner.

Han drog en anekdot. Om man får tro Allen Holub så ska skaparen av språket Java, James Gosling, ha svarat följande på frågan "vad skulle du ha gjort annorlunda med Java idag": I'd leave out classes!

Hela dragningen var en resa fram till slutsatsen att varken arv eller klasser är en förutsättning för objektorientering.

The Curious Clojureist
Neal Ford, ThoughtWorks, Inc

Neal är lättsam att lyssna på, så även denna gång. Han började med att beskriva Clujure som:
- Kan prata med Java
- Dialekt av Lisp
- Funktionellt
- Inbyggd hantering av tillstånd och samtidighet (concurrency)
- Består av listor av datastrukturer
- Homoiconic

Han tog ett par kodexempel från Apache-projektet skrivna i Java och gjorde om dessa till Clojure i ett antal steg för att påvisa att det blev mindre och mer uttycksfull kod. Det är uppenbart att funktionella språk för många uppgifter är att föredra framför imperativa språk som Java då de är mer uttrycksfulla och ger färre rader kod.

Efteråt lyssnade jag när en av åhörarna diskuterade med Neal varför man aldrig får se jämförelser av kod som t ex service:ar, d.v.s en typ av kod som är mycket vanligt förekommande i enterprise-system. Hans svar var att denna typ av kod blir ungefär lika lång i alla språk och därför inte lika intressant då det kommer till att belysa skillnaderna språk emellan. Dock hade han själv noterat detta och planerar att göra även sådana jämförelser framöver.

Här är lite ramverk som han nämde:
Leiningen (byggverktyg skrivet i Clojure)
compojure (webbramverk)
clj-record (active records)
ClojureQL (SQL)

Till sist rekommenderar jag alla som inte redan lyssnat på Rick Hickey brandtal Simple Made Easy att göra det, då det är en väl investerad timme!

The road to REST
Rickard Öberg, Neo Technology

Denna dragning kom att handla om REST. Han beskrev acronymen HATEOAS som står för Hypermedia As The Engine Of Application State.

Den stora behållningen av denna dragning var att API:er bör exponera Use Cases snarare än domänmodellen. Är det administration av ett visst användningsfall som bara administratörer har behörighet att utföra kan man låta URL:en börja på /administrator, medan om det är användaren själv som använder funktionen kan den t ex få börja på /account. Det intressanta med HATEOAS är att clienterna guidas att göra rätt då responsen från servern endast innehåller de länkar som är relevanta. Man kan likna en klient med en vanlig webbläsare.

Intressant föreläsning för mig som inte jobbat med REST.

Ons 15/2 - Konferensdag 2

Functional Thinking
Neal Ford, ThoughtWorks, Inc

Det är lätt att lära sig nya språk (syntax) men svårt att lära sig nya paradigm, t ex funktionell programmering då funktionell programmering är mer av ett nytt sätt att tänka. Han drog ett citat av Michael Feathers: "oo makes code understandable by encapsulating moving parts", "fp makes code understandable by minimizing moving parts".

Ford gick igenom fördelarna med att tänka funktionellt och summeringen blev Declarative over Imerative och rekommenderade följande läsning: Thinking functionally.

HTML5 with Play Scala, CoffeeScript and Jade
Matt Raible, Raible Designs

Anorm (SQL data access)

Matt var rätt underhållande att lyssna på. Den röda tråden i Matts presentation var hur efter många mödor och bloggande om detta lyckades bygga en webbaserad lösing med Play på sin Android-telefon som kunde tracka en resväg. När han till slut lyckades få igång sin videopresentation hade han dragit över tio minuter! Dragningen finns att läsa på hans blogg.

Up and out: Scaling software with Actors
Viktor Klang, Typesafe

Jag har varit på ett par dragningar om Akka tidigare. Viktor är core-utvecklare av Akka och är både kunnig och lättsam att lyssna på. Han drog det vanliga kring Akka så som att det skalar bra både vad gäller många CPU:er på en maskin (scaling up) och att det går att köra på många maskiner (scaling out). Han tog även upp exempel på fault tolerance.

Jag planerar att ladda ned och lattja med Actors i Akka så fort jag får tid då det ser kul ut och löser viktiga problem.

It Is Possible to Do Object-Oriented Programming in Java
Kevlin Henney, Curbralan

Kevlins talade om att vi borde fokusera på beteende snarare än tillstånd vilket jag håller med om. Han började att basera sitt resonemang på Liskov substitution principle. Han försökte få fram sitt budskap genom att visa hur man borde implementera metoden equals. Om man som Kevlin hårdrar resonemanget blir det meningslöst att kolla instanceof i equals-metoden då detta inte har något med beteendet att göra.

Om man följer hans råd att bara införa nya klasser om det har ett nytt beteende så borde det leda till att en jämförelse med instanceof implicit skulle testa skillnader i beteende, men det är min slutsats!

Han började med att visa hur man för en klass X imlementerade equals(X x) och då tänkte jag "vad smart" för då borde man slippa implementera equals(Object o) med check på instanceof. Det var inte det han försökte belysa dock, och jag tyckte inte exemplet med equals var så lyckat på det hela taget!

Han rekommenderade följande läsning från 1979: The paradigms of programming.

Ämnet var intressant och jag hoppas han kan ta upp det igen men slipa lite på argumenten!

An introduction to NFC, smartphones and you
Lars Westergren, Mejsla

NFC står för Near Field Communications och är i det här fallet den typ av elektronik som finns i smarta kort och en del mobiltelefoner (t ex Galaxy Nexus). Det ryktas om att iPhone 5 kommer ha detta inbyggt. NFC är i praktiken en liten dator som kan kommunicera på ett avstånd av högst 4 cm, vilket gör att man måste hålla sitt smarta kort eller mobil nära mottagaren, vilket gör den säkrare, och som kan vara allt från lösningar för biljettköp, identifikation, information och reklam.

För de mobiltelefoner som inte har denna lösning inbyggd har företaget Inside Secure löst detta genom att bygga in det i SIM-kortet. Det finns gratis API:er att använda på Android-platformen för den som vill testa själv.

Android Beam är en App som utnyttjar tekniken och gör att man kan överföra information mellan två mobiltelefoner på ett enkelt sätt. NFC är en intressant teknik som verkar vara på frammarsch och absolut något som kan vara intressant som utvecklare att börja titta närmare på.

Det här var en mycket bra dragning av Lars som kunde sitt ämne och gjorde det på ett pedagogiskt sätt.

Lightning intro to CloudFoundry
Josh Long, SpringSource, a division of VMware

Det var intressant att lyssna på vad SpringSource hade på gång "i molnet". Efter att ha lyssnat på Josh var det ingen tvekan om att ambitionen är hög vad gäller satsningen på molnet och med VMware i ryggen kan det nog gå bra.

Han rekommenderade utvecklingsverktyget Sptring Roo som ska vara a next-generation rapid application development tool for Java developers.

Det här blev den sista sessionen för min del i år då jag missade keynoten Cool Code av Kevlin Henney då jag hade en tid att passa. Jfokus utvecklas för varje år och detta blev mitt femte Jfokus sedan 2008. De hade även i år lyckas locka intressanta talare med intressanta ämnen och det är min gissning att jag även dyker upp nästa år!

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!