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!
