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!