Jfokus firar 10-årsjubileum i år och det märks att de har rutin på det här nu. Väldigt proffsigt organiserat, ett minimum av köande och gott om platser för naturliga mötespunkter. De talare jag lyssnade på höll alla en hög nivå av presentationsteknik och hade mestadels intressant och relevant information.
Det var två oerhört intensiva dagar och jag håller fortfarande på att sortera alla intryck.
Microservices och Java 8 i praktiken tycker jag var de ledande områdena detta år. De nya grejerna i Java 8 börjar landa hos utvecklarna men jag misstänker att appliceringen inte riktigt mognat. Det var två stora (och mycket populära) sessioner om vanliga misstag i användandet av Streams och Lambdas.
Avanza och Spotify berättade om sina erfarenheter kring microservices och IBM höll en dragning om testning av distribuerade system. Det var också flera sessioner om Docker och Kubernetes och det märks att de här teknikerna börjar bli mainstream nu. Mindre fokus ligger på själva tekniken och mer på hur dessa verktyg kan användas i en deployment pipeline samt vad som egentligen utgör en leverabel artefakt.
Min spaning är att som utvecklare i den närstående framtiden behöver man ha koll inte bara på sin kod utan också hur den ska paketeras, hur miljön den ska exekvera i behöver se ut samt till och med hur nätverkskartan ska utformas.
Josh Long från Pivotal höll en underhållande session med live-kodning om Spring Boot. Ni vet väl att det går att byta ut ASCII-grafiken som visas vid uppstart? banner.txt i classpathen bara!
Josh har ett bra repo på GitHub som demonstrerar många av ramverken som ingår i Spring Boot.
Spring Boot är en samling ramverk ihopsatta enligt en best practice som Pivotal bestämt. ”Very opinionated” som Josh säger.
"Spring Boot is very opinionated" – Josh Long
Tanken är att det ska täcka 80% av normalbehovet men att det fortfarande ska vara lätt att gå utanför dessa ramar om man vill (det är ju vanlig Spring i botten).
På tal om opinionated så lyssnade jag på Adam Biens presentation The Java EE-stic Way of Coding. Jag har följt Adam några år nu och hade en lätt känsla av starstruckness (men det får jag ju så lätt) under hans presentation. För er som inte känner till Adam så är han en tysk utvecklare/konsult som specialiserat sig på Java EE. Har har gått all-in på f.d. Glassfish (numera heter den Payara) och använder givetvis uteslutande Netbeans som IDE. Adam menar att Java EE inte alls är bloated och tungrott längre, snarare tvärt om. Hans artefakter är typiskt några KB stora, att jämföra med en Spring Boot-app som lätt blir uppåt 50MB. Detta lyckas han med genom att använda alla tillgängliga features som applikationsservern erbjuder och drar sällan in några andra ramverk. Adam delar upp sin kod på domän istället för per typ. Alltså är det förbjudet att ha paketnamn såsom model, controller, exception etc. Det som hör ihop ska också ligga ihop! Han har skrivit två lättlästa böcker som jag rekommenderar som ni hittar på Adams hemsida.
Gradle var också där och berättade om kommande nyheter. Gradle är en motsvarighet till Maven, det vill säga ett ramverk för kompilering och paketering av projekt. Selling point är att Gradle har smarta mekanismer för att hålla koll på vad som egentligen behöver kompileras om (i flera led) och därmed hela tiden gör minimalt med jobb.
En nyhet är att det går att deklarera en så kallad resolutionStrategy för beroenden till andra moduler. I denna går det att säga till exempel: hämta modulen från (maven)repot men om modulen finns utcheckad är den versionen att föredra.
På detta vis går det alltså att lokalt göra ändringar i en modul och direkt få access till dessa från en tredje modul. Detta har varit krångligt med Maven eftersom beroenden alltid måste hämtas från ett repo (lokalt eller globalt).
Har ni hört talas om AsciiDoctor? Jag blev inspirerad och ska testa detta format för kod och projektdokumentation. Gillar speciellt att den kan generera systemskisser och att det går att referera till källkod som sedan infogas, färgläggs och kan annoteras med index för referens i dokumentationen. En kille jag snackade med på Jfokus om AsciiDoctor fnös dock föraktfullt och sa:
"Vadå, all min kod är ju självdokumenterande" – Föraktfull utvecklare
Det finns pluginer för Maven och Gradle och den kan även generera JavaDoc.
En av de avslutande presentationerna handlade om varför vi tycker att viss kod eller val av arkitektur är dålig och annan är bra. Slutsatsen handlade inte, som man skulle kunna tro, om hur vi kan skriva bättre och mer lättläst kod utan snarare om vikten av att efterlämna sig information som förklarar och motiverar de val man gjort. Nästan vilken kodmassa som helst kan upplevas som riktigt dålig om man inte har bakgrunden till hur och varför den utformats på just detta vis. Kan tyckas självklart men hur ofta händer har det hänt att det finns något att läsa när man kommer som konsult till ett projekt?!
Alla föredrag från JFokus spelas in och blir så småningom tillgängliga här