JFokus 2020

Het JFokus 2020 congres in Stockholm was fantastisch. Het was een evenement van drie dagen, maar omdat er voldoende te zien en beleven is in Stockholm en de locatie - het Waterfront Conference Center - pal in het centrum ligt, had ik reden genoeg om een dagje eerder te komen en een dagje later te vertrekken. Ik had een ticket inclusief de maandag, waarop alvast wat deepdive sessies van ieder een halve dag werden gegeven. De garderobe was ruim bemand en shirts en goodybags waren ook ruim op voorraad. De stands waren 's ochtendsvroeg reeds opgebouwd en koffie, thee en ontbijt lagen al klaar toen ik om 08:00 op kwam dagen. Het Zweeds fatsoen voel je in de details op dit congres: toegankelijkheid van de locatie, behulpzaamheid van medewerkers en de ingrediëntenlijsten bij iedere snack en maaltijd waren opvallend goed geregeld. De snacks waren gezond en lekker, en met name de maandag kende een lunch van een voor mij ongekende kwaliteit voor een development congres. Ik ging sowieso iedere dag goed gevuld weg. Er was ook goed bier, wat toch netjes is in een land waar je normaal de hoofdprijs betaalt voor alcoholhoudende drank. Er waren ook chill out zones, liften en roltrappen en overal was goede WiFi. Voor stopcontacten moest je wel een beetje zoeken, maar in de grote conferentiezaal waren er plenty stekkerdozen. Op de maandag viel de drukte wel mee, maar op dinsdag en woensdag was het op momenten erg dringen om van de ene naar de andere sessie te komen.

Er waren aardig wat stands. Een aantal Zweedse bedrijven was daar puur gericht op het Zweedse publiek, maar het gros was internationaal: IBM, RedHat, King (van het spelletje), JetBrains, Microsoft, Oracle, Azul, en Hazelcast, om er een aantal te noemen. Er waren de bekende raffles waar ik deze keer achter het net viste, maar er was voldoende swag om in mijn carry-on luggage te proppen, dus niet geklaagd.

De sessies op JFokus waren van goede kwaliteit. Sommige bekende gezichten die een beetje een congresganger in Nederland al wel genoeg heeft gezien, maar ook voldoende nieuwe mensen om nieuwe dingen van te leren. Een lijst van alle praatjes is te vinden op https://www.jfokus.se/talks ; sommige voorzien van slidedecks. Mocht je dit verslag lezen wanneer het programma voor 2021 al online staat: in de footer staat een link naar het archief. Overkoepelend had het hele evenement een Star Wars thema, met als Jedi Knight verklede organisatoren, de bekende scrollende opening credits in gele letters, de hulpoproep van Leia aan Obi Wan Kenobi en een heuse cosplay party op de dinsdagavond. Ik had geen outfit bij me, dus ik drukte mijn snor achter één van de aanwezige pinball machines.

Hieronder volgt een korte impressie van een aantal noemenswaardige sessies die ik heb bijgewoond.

Sessies

Maarten Mulders: Building web applications with React (https://www.jfokus.se/talks/504)

In deze hands-on sessie praatte Maarten ons door de beginselen, best practices en sensible defaults heen van het bouwen van een React applicatie. Ik heb al wat meer ervaring met Angular en moet zeggen dat React een stuk eenvoudiger aanvoelt, doordat het gewoon een flink aantal dingen niet doet - dat kun je een kracht of een tekortkoming vinden, maar feit is dat de frontend wereld voldoende middelen biedt om in te vullen wat React openlaat, zoals routing, cookies, storage, etc. We leerden JSX kennen, waar ik niet zo van gecharmeerd was (XML rechtstreeks in je JavaScript), ondanks dat Maarten ons op het hart drukte dat je hieraan went als React developer. We maakten kennis met hoe React slim omgaat met een virtual DOM en zo alleen die zaken opnieuw rendert in de browser die echt gewijzigd zijn in je frontend applicatie, en dat was aardig indrukwekkend. De opdracht van Maarten begon met het opknippen van een UI in een hiërarchie van componenten, wat een erg goede leidraad bleek voor het verder modelleren en implementeren.

Danielle Banks: Keynote: Connecting Developers and Digital Media (https://www.jfokus.se/talks/521 )

Danielle is een ervaren spreker van The Weather Company (weather.com), wat opvallend genoeg een bedrijf van IBM is. Alles aan haar presentatie voelde wat gemaakt, maar ze had een boodschap die de moeite waard was: Met iets dat zoveel impact kan hebben als het weer, wordt het steeds duidelijker dat developers een belangrijke rol spelen in levensbedreigende of -reddende situaties. Ze haalde als voorbeeld de ClusterDuck aan van Project OWL, wat een laagdrempelige en betrouwbare manier biedt aan mensen in rampsituaties om bereikbaar te zijn wanneer de reguliere communicatie infrastructuur het begeeft. https://www.project-owl.com/ . Een ander voorbeeld van haar boodschap werd gevormd door de afsluitende keynote over de Boeing 737 Max, waarover hieronder meer.

Emil Eifrem: Graphs from Malmö to Panama and beyond. (https://www.jfokus.se/talks/512 )

Het was een thuiswedstrijd voor Emil, de oprichter en CEO van Neo4J. In plaats van over Neo4J te praten, praatte hij over het praktische belang van contextuele grafen om verbanden binnen een grote hoop ruwe data te vinden. Hij begon met een voorbeeld, hoe zoekmachine Altavista het moest afleggen tegen Google: Niet doordat je in Google meer zoekresultaten kon vinden op je opdracht, maar doordat Google een filter bubble kon opbouwen, waardoor er via contexturele metadata meer relevante antwoorden werden gevonden dan de pagina's aan rommel die je op den duur in Altavista vond. Dit trok Emil door naar de Panama Papers: Toen de anonieme klokkenluider hiermee naar journalisten stapte, riepen die de hulp in van concullega's aangesloten bij het International Consortium of Investigative Journalists (icij.org). De Panama Papers bevatten dusdanig veel data (2,6TB aan documenten, e-mails, csv files, etc) dat ongeacht de waarde van die data, en zonder de technologie die Neo4J bood, het onmogelijk zou zijn geweest relevante verbanden boven water te krijgen. Met Neo4J lukte het slechts 3 developers en 3 data journalisten om voldoende te ontdekken om aan 370 journalisten in 80 landen te sturen.

Een opvallende bevinding die Emil live demonstreerde (op http://neo4j.com/sandbox is de methode na te bootsen) was hoe de premier van IJsland zijn aandelen aan Wintris verkocht voordat hij in zijn functie trad, maar zijn vrouw op hetzelfde adres diezelfde dag voor 1 dollar die aandelen weer kocht. Wintris was geen zuivere koffie, en de openbaring van de stiekeme manier waarop de premier hiermee verbonden bleek, was reden voor hem om af te treden.

Matt Raible: Frontend development for backend developers (https://www.jfokus.se/talks/451 )

Het lijkt erop dat Matt Raible de strijd aangaat met Josh Long voor het record aan woorden per seconde. Toch heb ik hem twee keer opgezocht: één reguliere sessie en één sessie tijdens een meetup in de avond die op de locatie van het congres plaatsvond.

In zijn eerste sessie helpt Matt het publiek met fullstack en frontend ambities aan een flinke lading sensible defaults qua tools. Een samenvatting van deze sessie is dan ook niet veel meer dan een opsomming van tools:

• Node verliest het van Java & Spring Boot voor het bouwen van backends en wordt tegenwoordig vooral voor bijv. het transpilen van TypeScript naar JavaScript gebruikt.
• Buildtools: Mensen zijn van Gulp naar SystemJS en Webpack aan het bewegen. Webpack (http://webpack.academy ) kan dependency graphs bouwen en assets bundelen (wat wellicht niet meer is wat je wil; zie onder), maar is traag om te compileren..
• Dependency management: Mensen zijn Bower aan het verlaten en gebruiken nu vooral npm of yarn
• App generation: Grunt ligt an een tijdje achter ons. Matt adviseert Yeoman.
• Local development: BrowserSync (browsersync.io) is handig om in je browser direct je pagina te herladen als je een file aanpast. Matt waarschuwt dat dit gebruik er toe kan leiden dat men vergeet tests te schrijven.
• Top JS frameworks zijn Angular (newline.co/ng-book/2), React (https://vimeo.com/213710634 ) and Vue. De strijd tussen en buiten deze frameworks lijkt wel gestreden, al noemt Matt nog Svelte (https://svelte.dev/ ) in de marge.
• Mobile development: Gebruik ionic, wat een dunne laag over eerdergenoemde 3 JS frameworks is.
• Serverside support: React op de server, Angular Universal (https://angular.io/guide/universal ), Nuxt.js.
• CSS: De meeste mensen gebruiken SASS (http://sass-lang.com ), maar CSS zelf wordt ook steeds moderner. Matt noemt nog een behoorlijk aantal CSS frameworks: Skeleton, PureCSS, Bootstrap, Foundation, Material Design, TailwindCSS.

Er is een aantal manieren om je frontend te optimaliseren. Matt noemt een lijst:

• Verminder de hoeveelheid HTTP requests.
• Gzip je assets.
• Gebruik far future expires headers
• Minify je code
• Optimize je images
• Let op dat HTTP/2 & server push e.e.a. veranderen aan best practices: doordat individuele file wijzigingen gedetecteerd kunnen worden, kan het juist efficiënter uitpakken om je assets niet te bundelen.
• Voor nog veel meer informatie verwijst Matt naar Vitaly Friedman's Frontend performance checklists (https://www.smashingmagazine.com/2020/01/front-end... ).
• Web components is een manier om HTML templates en custom components te introduceren, met shadow DOM and HTML imports. Zie http://webcomponents.org . Een paar jaar geleden was Polymer nog een veelbelovende stip aan de horizon, met StencilJS als alternatief, maar het lijkt erop dat het niet heeft aangeslagen bij het grote publiek.
• Backend developers zijn al een tijdje overtuigd van het nut van microservices, maar de frontend wereld heeft een tijdlang het idee omarmd van monolitische frontends. Steeds meer frontenders bewegen hier nu vandaan (zoals ondergetekende). Martin Fowler heeft het e.e.a. te melden over micro frontends: http://single-spa.js.org

Matt haalt vervolgens een quote aan van Alex Russell: "We've failed on mobile". Daarmee doelt hij op het feit dat mobile devices niet per se de compute power hebben waar developers op rekenen bij het bouwen van frontend applicaties. Op https://infrequently.org/2018/09/the-developer-exp... wordt hier uitgebreid op ingegaan. Progressive Webapps is een idee wat nu weer hot wordt. Ik denk meewarig terug aan een jaar of 5 geleden, toen menig frontender waarschuwde dat SPA's geen rekening houden met progressive enhancement.

Tenslotte verwijst Matt naar fullstack framework JHipster, dat veel van deze best practices en tools in zich verenigt en combineert met Spring Boot, met inmiddels meer keuze dan in de initiële release. Tijdens de meetup in de avond laat hij zien hoe hij makkelijk een applicatie opzet en aanpast om authenticatie via Okta te introduceren. Het ziet er leuk uit en JHipster voelt niet zo beperkt meer als een paar jaar terug toen ik er voor het eerst naar keek. Er is gratis meer over te lezen op https://www.infoq.com/minibooks/jhipster-mini-book... .

Tim Berglund: Events, Dear Boy, Events (https://www.jfokus.se/talks/415 )

Door wat technische problemen, die verder overigens zeldzaam zijn op JFokus, besluit Tim Berglund wat te improviseren en moppen te tappen. Alhoewel hij voor Confluent werkt, weigert hij in te gaan op vragen die dreigen er een commercieel praatje van te maken, wat hem siert.

Eenmaal goed van start, vertelt Tim over een aantal filosofen en wat zelfs de denkbeelden van Socrates en Plato ons nu nog kunnen leren over het onderscheiden van dingen, eigenschappen en events. Ook de inzichten uit deze sessie blijken waardevol om de closing keynote over de Boeing 737 Max beter te kunnen waarderen (welke eigenschappen kunnen veranderen voordat een type vliegtuig een nieuw type vliegtuig mag of moet worden genoemd?)

(noot: Tim Berglund verontschuldigde zich voor de zeer gecomprimeerde versie van de denkbeelden van deze filosofen)

1. Heraclitus was geïnteresseerd in verandering: "Niemand stapt tweemaal in dezelfde rivier", omdat noch jij noch de rivier hetzelfde zijn in alle aspecten. Daarom bestaan dingen niet echt; alleen veranderingen.
2. Aristoteles, student van Plato, was geïnteresseerd in eigenschappen genaamd 'universals' en zei dat die alleen kunnen bestaan als ze zich gecombineerd manifesteren in dingen. Dit idee wordt wel realisme genoemd.
3. Bill Ockham, bekend van Ockham's Razor, ook wel bekend als de "Law of Parsimony", geloofde het tegenovergestelde. Volgens hem bestonden universals niet, en hij gaf niet om eigenschappen. Hij geloofde alleen in individuele dingen, wat ook wel het idee van nominalisme heet. De Law of Parsimony zegt dat je niet meer dingen moet introduceren dan je nodig hebt voor een verklaring.
4. Quine is een latere filosoof en komt uit de analytische traditie. Hij is een extreme nominalist, en is bekend om de stelling "your universe seems overpopulated". Quine ging verder dan Ockham en wilde niet eens toegeven dat er überhaupt dingen bestaan, of een wereld; het enige dat hij wist, was dat hij zich bewust was van events, die hij categoriseerde. Zijn radicale nominalisme ontkende dus niet alleen eigenschappen, maar ook dingen. Hiermee is de cirkel naar Heraclitus weer rond: Quine gaf alleen om veranderingen; om events.

Met deze zienswijzen in het achterhoofd, kunnen we naar software development kijken en zien dat er een spanning is tussen dingen (entities in een entity store), types van dingen(schema's in een schema registry) en veranderingen in dingen (events in een event store). En deze spanning bestaat, omdat zelfs als je alleen geïnteresseerd bent in veranderingen, je nog steeds in staat moet zijn om die veranderingen in relatie tot dingen te benoemen. Concreet: je kunt niet praten over het aankomen van schepen of het plaatsen van een bestelling zonder vast te leggen wat een schip of een bestelling is.

Jonas Bonér: CloudState - Toward stateful services (https://www.jfokus.se/talks/127 )

Ik heb Jonas, de man achter Akka en Lightbend, jaren geleden gezien op Devvox waar hij me bekend maakte met het Reactive Manifesto. Sindsdien ben ik een fan van zijn zowel praktische als theoretische visie op communicerende systemen.

In deze sessie nam hij ons mee in de opzet van CloudState, wat is gebouwd om het concept van stateful serverless te implementeren. Hij daagde het concept uit dat we bij microservices vaak geëxternaliseerde persistence hebben. Een microservice is typisch de baas over zijn eigen data, maar omdat een microservice kan falen, wordt die data elders opgeslagen. De daaruit voortkomende eventual consistency en het gebrek aan mechanical sympathy is waar CloudState een alternatief voor biedt.

Wat Jonas verstaat onder mechanical sympathy, is de colocation van compute & storage. Bij CloudState betekent dit: Een Knative function wordt vergezeld met een Akka client als sidecar. Maar CloudState gaat verder: de functions zouden pure functions moeten zijn: ook storage is een onwenselijk side-effect. In plaats daarvan moet behalve een trigger ook een state worden ingestuurd aan een function. De totale state wordt dan via het Akka Cluster bijgehouden. Dat kan doordat de Akka clients zich in een Akka Cluster met elkaar bevinden en via een gossip protocol praten om 'near-consistency' te bereiken.

Andrew Harmel-Law: Organisation refactoring and culture hacking - lessons from software (https://www.jfokus.se/talks/163 )

De ThoughtWorks consultant poneert een aantal stellingen om als developer over na te denken:

1. Organisaties zijn altijd in een staat van verandering.
2. Wij als developers zijn dichter bij waar de problemen zich manifesteren.
3. Wij als developers beschikken over de beste vaardigheden om development problemen aan te pakken.

Met dit in het achterhoofd dachten we mee met Andrew: Je hoeft niet 'post-tech' te zijn om de problemen het hoofd te bieden waar een veranderende organisatie mee worstelt. Hoe kan een developer zijn vaardigheden aanwenden om veranderingen te faciliteren?

1. Breng de menselijke architectuur in kaart. Teken het met verantwoordelijkheden en afhankelijkheden. Neem het Holacracy model (https://nl.wikipedia.org/wiki/Holacratie ) in tegenstelling tot een top-down hiërarchie; elke actor in de organisatie heeft enige autoriteit nodig, en de organisatie als geheel heeft een dynamische, transparante structuur nodig om te kunnen reageren op veranderende omstandigheden.
2. Leer de factoren kennen die de organisatie beroeren.
3. Maak elk besluit met de overweging dat het de gehele situatie beter moet maken; doe het niet alleen om iets voor jou persoonlijk comfortabeler te maken. Automatiseer de dingen die duidelijke requirements hebben, en richt je aandacht op de dingen waar menselijk oordeelsvermogen voor nodig is. Gun het wat tijd om de beoogde wijzigingen zich te laten manifesteren en wees alert op feedback vanuit het gehele systeem.
4. Vermijd te veel consensus. Verspil je tijd niet aan meetings waarin je probeert iedereen het met elkaar eens te laten zijn voordat je iets verandert. Volg het advies proces: Iedereen kan een besluit nemen, na advies ingewonnen te hebben van iedereen die betekenisvol geraakt wordt door je besluit, en van iedereen met vereiste expertise. Het voordeel van deze benadering is dat 1 persoon een besluit maakte en daarmee ook de verantwoordelijkheid draagt. Een ander voordeel is dat het snel en transparant is.
5. Ga verder dan delegeren.

- Edward Schein zegt: "Cultuur is het patroon van aannames dat een groep mensen heeft om met z'n problemen om te gaan."

- Als je wilt dat mensen problemen oplossen, zul je moeten zorgen dat ze over relevante informatie kunnen beschikken om hun aannames te toetsen en bijstellen, en dat ze het vertrouwen hebben om daarmee de juiste beslissingen

- Devolutie is beter dan delegatie: Je kunt een probleem niet aan een ander geven zonder de macht die nodig is om het op te lossen.

- Zorg voor een rolmodel voor het volgen van het advies proces. Een rolmodel kan als mentor fungeren voor hoe iemand macht kan gebruiken en met zelfvertrouwen beslissingen kan nemen.

Tobias Modig: Get old, go slow, write code! (https://www.jfokus.se/talks/165 )

In deze interactieve sessie wordt aan developers regelmatig gevraagd om via een app op te geven hoe zij denken over zaken, wat de energie er goed in houdt. Een bevinding die Tobias doet, gesterkt door eerdere sessies, is dat vergeleken met andere beroepen de gemiddelde leeftijd van een developer (28) erg laag ligt. De gemiddelde developer blijft 8 jaar in zijn beroep, voordat hij om één van drie redenen iets anders gaat doen:

1. Ze vinden coden niet meer leuk.
2. Ze worden gepromoveerd naar een management functie.
3. Ze kunnen de technologische ontwikkelingen niet bijbenen en gaan wat anders doen.

Over punt 2 haalt Tobias het Peter Principle (https://en.wikipedia.org/wiki/Peter_principle ) aan: Developers worden gepromoveerd naar 'hogere' functies waar hun hands-on skills minder relevant worden en andere skills meer. Dit gaat door totdat ze in een functie terecht zijn gekomen waar ze dusdanig vaardig zijn, dat ze geen promotie meer verdienen. Het resultaat is dat de mensen 'hoger in de boom' incompetent zijn en competente developers uitstromen.

Tobias breekt een lans voor developers die in hun professie blijven naarmate ze ouder worden, en roept bedrijven op om in functiehuis en beloning hier rekening mee te houden. Net als Andrew Harmel-Law benadrukt Tobias dat developers over diverse vaardigheden beschikken om problemen in hun domein op te lossen, met de aanvulling dat deze vaardigheden met leeftijd veranderen. De belangrijkste is volgens hem geduld, in een professie waar druk en haast veel voorkomen:

• Het geduld om te oefenen en te verbeteren.
• Het geduld om processen te evalueren en verbeteren.
• Het geduld om de tijd te nemen om vooruit te plannen
• Het geduld om te refactoren.

De ervaring leert inderdaad dat een minder ervaren team makkelijker geforceerd kan worden om schattingen af te geven en daarna geforceerd kan worden om de daarop gebaseerde deadlines te halen.

Dit druist enigszins in tegen een aantal moderne opvattingen:

• De Lean Startup beweging heeft het veel over 'eliminate waste', wat hoekjes afsnijden in de hand werkt. Robert C. Martin brengt daar tegenin: "The only way to go fast is to go well."
• Scrum heeft het over sprints, maar een lange afstandsrenner sprint niet; die doet wat het Agile Manifesto voorschrijft: "Sustainable development" en "constant indefinite pace".

Tobias sluit af met een quote van Martin Fowler: "Internal quality lowers the cost of future change." Deze toekomst kan er al over een paar weken zijn.

Ken Sipe: Lessons learned from the 737 Max (https://www.jfokus.se/talks/406 )

De afsluitende keynote was indrukwekkend en bracht m.i. een aantal inzichten uit eerdere sessies samen. Het onderwerp was de ongelukken met de recente Boeing 737 Max vliegtuigen. Ken Sipe is een developer met een vliegbrevet. Maar een vliegbrevet betekent niet dat je overal in mag vliegen; je haalt zo'n brevet voor een specifiek type vliegtuig. Met andere woorden: heeft een vliegtuig eigenschappen die niet bij dat type horen, dan mag je er als piloot niet zomaar in vliegen. Je moet weten wat het vliegtuig kan en hoe het zich gedraagt in de lucht. Ken loodste het publiek door een afschrift van de communicatie tussen de Captain, de Flight Officer en de verkeersleiding. Wat evident werd, was dat iedere seconde telt, en dat iedere onduidelijkheid een mentale belasting is die uiteindelijk leidt tot rare besluiten en fouten. Dit is hoe mensen werken.

Het probleem met de Boeing 737 Max was politiek van aard, in de zin dat Boeing er belang bij had om een vliegtuig af te leveren dat van hetzelfde type was als een eerder model: laag en smal. Maar om een groter bereik te hebben, moesten de motoren sterker worden. Dat leidde tot het probleem dat ze dan groter zouden worden, en dus moesten ze elders op de vleugels. Een tweede probleem was dat die motoren dusdanig veel stuwkracht zouden hebben, dat ze het vliegtuig te snel omhoog zouden duwen, waardoor het zou stilvallen. Om dat tegen te gaan, was er in de staart een systeem genaamd MCAS toegevoegd, wat als het ware zou tegensturen - het was bedoeld om de neus naar beneden te duwen.

Wat ging hier mis?

• Denk terug aan de eerder door Tim Berglund genoemde filosofen: Je kunt je afvragen of, gegeven de wijziging in eigenschappen, hier nog sprake is van hetzelfde type vliegtuig. Maar omdat dat het uitgangspunt was, hoefden piloten niet bij te trainen - wat duur zou zijn -. Maar hierdoor was er ook geen handleiding waar het nieuwe MCAS instond. Met andere woorden: de piloten merkten dat de neus van het vliegtuig naar beneden werd geduwd, en ze wisten niet dat dat een feature van het vliegtuig was.
• Development was uitbesteed aan derden, waardoor er weinig 'skin in the game' was: Een development team dat op de hoogte was van het feit dat een piloot niet getraind zou worden in het nieuwe vliegtuig, zou wellicht andere beslissingen hebben gemaakt. De developers lieten het MCAS systeem maar naar 1 van de Angle of Approach systemen luisteren, dat in tweevoud is uitgevoerd. Dit was wellicht goed volgens de opdracht. Maar de hele reden dat het in tweevoud is uitgevoerd, is juist zodat piloten kunnen controleren dat ze echt goed zitten. Bij het noodlottige vliegtuig was onlangs één van deze twee systemen vervangen (en dit was niet doorgegeven aan de piloten), en ze gaven twee verschillende lezingen. Alhoewel de piloten hierdoor konden begrijpen dat er iets mis was in de data die ze uit het systeem kregen, konden ze niet begrijpen dat MCAS het systeem naar beneden bleef duwen: Ze wisten niet dat MCAS bestond, en MCAS wist niet dat er een foutscenario was waar het mee om moest kunnen gaan - want daar hadden de developers niet aan gedacht. Zoals Danielle Banks aangaf: developers spelen een steeds crucialere rol in de veiligheid van mensen.

Jasper