Build Stuff 2022: Samenvattingen

De conferentie zelf

Ik kwam de dag voor de conferentie aan in Vilnius. Deels omdat het wat tijd kostte om erheen te vliegen en ook vanwege een .NET user group die een meetup in het hotel organiseerde. De groep gebruikte deze gelegenheid om de internationale sprekers die al op de conferentie waren uit te nodigen om een presentatie te geven op hun meetup.

De locatie was in het Radisson Blu-hotel in Vilnius. Het was fijn om uit bed te rollen, te ontbijten en de eerste talk te kunnen bijwonen. Zo laat in het jaar was het weer minder mooi en met de wintertijd was het buiten al donker om 16:30.

Naast alle talks waren er veel stands voor sponsors, competities, eten en kunstenaars die karikaturen van je tekenden. Bewijs dat ik er was:

Na de tweede dag was er een afterparty op een andere locatie. Er was een DJ die muziek maakte via code, een band die volledig uit developers bestond uit Litouwen en “Dylan Beattie and the line breakers”

Hier afgebeeld terwijl ze hun nummer We’re going to build a Framework uitvoeren

Al met al was het een geweldige conferentie en ik hoop dat ik hem in 2023 ook kan bezoeken.

In de 3 dagen ging ik naar ongeveer 20 talks en maakte ik bij de meeste aantekeningen. Hier zijn mijn samenvattingen van de talks die ik het belangrijkst vond en waarvan ik nog de beste aantekeningen heb.

Intentional code - David Whitney

Voeg intentionaliteit toe aan je code

Code organiseren op architecturale functie is een slechte manier om je project te structureren en leidt tot een rommelige structuur. Het is als een verzameling auto’s organiseren op de losse onderdelen.

Design patterns zijn oorspronkelijk bedacht door een echte bouwarchitect. De Gang of Four schreef in 1999 een boek; die patterns werden gebruikt om problemen uit die tijd op te lossen. Het waren templates voor veelvoorkomende situaties in code. Daarna kwam Donald Knuth met Literate programming. Het combineren van een code- en een documentatietaal.

Software is een beperkte vorm van literatuur. Het communiceert oplossingen van programmeur naar programmeur in code die door een computer uitvoerbaar is.

Computercode is intentionele communicatie.

Elk teken dat je typt doet ertoe.

Code die met aandacht en intentie is geschreven, is goede code.

Intentional > Clean

Extreme Programming Explained > Clean Code. Ketterij!

Intent

Macro - Organisatorische patterns

Micro - Vorm, flow en cohesie

Gebruik witruimte om code over één onderwerp samen te voegen, net als een alinea.

De complexiteit van een applicatie zou hooguit zo complex moeten zijn als het probleemgebied waarin het zich bevindt, en niet groter.

Het niet naleven van Macro- en Micro-design kan leiden tot over-designen

Design is tijdgebonden, alleen geldig in de huidige context. Voorbeelden waren telefoons en walkmans. Het design was revolutionair maar is nu heel oud

Structureel design is vaak te groot en te ingewikkeld.

Microservices = Distributed Monoliths

Design en patterns overweldigen het probleemgebied

Voer oorlog tegen complexiteit.

Vraag je af: waarom ziet deze code er zo uit en wat doet het? Je wilt dat dingen die iets anders doen er ook anders uitzien

Code die je niet eenvoudig kunt debuggen is slechte code.

Intentionaliteit is geven om de kosten van abstractie.

file.open() is een voorbeeld van goede abstractie, omdat het het verschil tussen HDD’s en SSD’s afhandelt.

Tip

Neem meer tijd om na te denken over wat je doet in plaats van het gewoon te doen.

Actors in messaging system - Ted Neward

De talk was gebaseerd op Microsoft Orleans, een .NET-framework voor Actors.

Hoe actors gedistribueerde systemen veranderen; we willen dat programma’s met elkaar praten.

Manieren om berichten af te leveren in gedistribueerde systemen:

• Once and only once
• At most once
• At least once

RPC

Complexiteit verborgen achter een façade voor developers. Doet alsof het lokaal werkt als een local procedure call, maar dan in een gedistribueerde omgeving

RPC-tekortkomingen

• Een enorme verkeerspiek leidt tot het slashdot-effect of de reddit hug of death
• Wat als het netwerk wegvalt of ernstig vertraagt? Het zal errors gooien
• Wat als we het programma laten evolueren? Daar hebben we niet aan gedacht toen we de spec/protobuf schreven

RPC is nog steeds request/response

Streamingdiensten zoals Netflix moeten andere protocollen gebruiken omdat ze connecties niet eindeloos open kunnen houden.

Actors

Lichtgewicht entiteiten

Actors in plaats van objecten

Kunnen stateful of stateless zijn

Hebben een identificeerbaar adres

Reageert op een bericht door:

• Berichten te sturen naar andere actors
• Nieuwe actors aan te maken
• State bij te werken
• Het berichtformaat bij te werken om naar anderen te sturen

Analogie voor Actors aan de hand van spreker en publiek

Actors delen geen state

Een bericht is niet hetzelfde als een method call

Een bericht hoeft geen response terug te geven, maar kan wel iets in een andere Actor in gang zetten.

Agility != Speed - Kevlin Henney

Deze talk werd zonder slides gegeven omdat er problemen waren met het verbinden met de schermen.

Agility is de manier waarop we uiteindelijk gemeten werden. Het Agile-manifest startte de agile-methodiek.

Wanneer een bedrijf zegt “Wij doen aan Agile”, weet je dat ze het concept niet begrijpen.

Agile is een overkoepelende term, geen enkel proces dat je kunt doen.

Agile is een bijvoeglijk naamwoord, het is een observatie die je kunt maken. Team A is agiler dan Team B.

Je kunt Scrum of Kanban doen, maar niet Agile

Het Agile-manifest stelt dat het geen proces is, het is een houding. Agile is een continu proces.

Agile waardeert interacties en individuen boven processen en tools. Agile betekent “Responsiveness, klaar voor verandering”.

Herbruikbaarheid verhoogt agility

Geen testen in Continuous Deployment = Continuous Disaster

Wanneer we teams meten, gebruiken we woorden als “Productiviteit”. Productiviteit komt uit fabrieken. Als je zegt “Ik ben productiever”, zeg je eigenlijk “Ik ben meer als een fabriek”.

We kunnen de fysieke wereld eenvoudig inschatten, maar niet de abstracte wereld van software. Je kunt inschatten wanneer een auto aankomt bij een bepaalde snelheid, maar niet wanneer die feature af is.

Lines of Code is een slechte maatstaf. Het enige wat Lines of Code je vertelt, is de regels code; het is waardeloos zonder context. Het kan alleen laten zien welke cognitieve belasting developers moeten verwerken. In verhouding tussen 100k LoC en 1 miljoen LoC.

Developers zijn probleemoplossers en ze zijn creatief. Als je ze meet op LoC, geven ze je meer code maar niet meer waarde.

Story points

Wat is een story point?

Een willekeurige maateenheid om ons af te leiden van de deadline.

“Hoelang gaat dit duren?” Dat kunnen we niet neutraal beantwoorden als er al een deadline is gesteld.

Schatting ≠ commitment.

Schattingen kunnen wel in productie (manufacturing). De 1001e widget duurt even lang als de 1000e. In software hebben we het manufacturing-probleem al opgelost, dat heet de compiler. Als je exact hetzelfde wilt, heb je alleen dezelfde input nodig.

Software gaat over het design-probleem. Software produceert verschillende dingen, anders zou je het gewoon opnieuw kunnen kopiëren.

Gradaties bestaan niet

• Bekend. Je hebt de technologie gezien of er iets mee geprobeerd.
• Nieuwe technologie. Je hebt het nog nooit gebruikt of ervan gehoord

We weten niet hoe we moeten inschatten omdat het voor ons een nieuwe technologie is.

Story points worden een valuta. Hoeveel tijd kost x en hoeveel story points is dat? Dus x / story points = 1 story point.

Wanneer het een valuta wordt, komt het onder druk te staan. Je eindigt met een omrekening van story points naar tijd. Als je dan story points over tijd zou bijhouden, zou je zeggen “Team A doet x hoeveelheid in x hoeveelheid tijd”. Tijd over tijd wordt een gradiënt; je meet ofwel hun bezigheid ofwel hoe goed je schattingen zijn.

Teams kunnen dezelfde story points hebben maar een andere valuta gebruiken. Teams kunnen niet alleen op story points gemeten worden.

Hoe kunnen we dan meten?

Features over tijd. Waarbij feature gedefinieerd is als opgeleverde functionaliteit.

Maar dat is nog steeds als zeggen “Ik neem nog een drankje. Hoe groot is het drankje? Geen idee”

Een andere maatstaf is velocity. Teams gaan velocity vergelijken op story points, die verschillende valuta gebruiken. Ze raken dan geobsedeerd door een getal.

Als je te veel druk op een getal zet, vecht het terug.

“When a measure becomes a target, it ceases to be a good measure” - Goodhart’s Law

En coverage (in tests)?

Coverage is geen goede maatstaf. Het meet niet hoe goed je tests zijn, het meet alleen dat code door een test gedekt is. Het houdt geen rekening met assertions in tests.

Wat is een betere maatstaf? Velocity

Velocity is niet alleen hoe snel je gaat

Je bent onderweg om een vriend te bezoeken en hij belt je. “Waar ben je?” Ik rijd 100 km per uur. “Maar welke richting?” Noord “Maar je moet naar het Zuiden!”

Velocity = Een afstand + een richting

1 meter per uur in de juiste richting is beter dan 100 km per uur in de verkeerde richting.

Bouwen we het juiste ding? “Nee, maar we bouwen het snel”

Agility = Als we de agility van een team meten, meten we hun vermogen om van richting te veranderen. Om het proces te vertragen en opnieuw te beoordelen of ze op het juiste pad zitten.

Fixing Distributed system fails - Jimmy Bogard

Deze talk was gebaseerd op 6 regels code die elk verschillende third parties aanriepen zonder enige error handling. Jimmy demonstreerde wat er mis kon gaan en wat je daartegen kon doen.

6 regels code in een toernooi-bestelsysteem vormden de aanleiding voor deze talk.

Het was code die een bestelling plaatste, geld van de klant afschreef en een e-mail verstuurde.

Opdeling van de code

1. Find customer in DB
   • Bij falen kan de transactie terugrollen. De klant wordt niet belast
2. Create order from Cart
   • Bij falen kan de transactie terugrollen. De klant wordt niet belast
3. Post payment to Stripe
   • Stripe faalt, de klant wordt niet belast en de transactie wordt teruggerold
4. Send email via SendGrid
   • E-mail faalt, de klant krijgt nooit een e-mail maar wordt wel belast. Transactie teruggerold
5. Create order Transaction in DB
   • Queue faalt, klant belast en gemaild maar geen order omdat de transactie is teruggerold
6. Redirect to success page

Alles verpakt in één enkele Transaction

Het zijn allemaal externe systemen. Bij aanroepen naar externe systemen is falen ALTIJD een optie

Niet wat er gebeurt ALS een aanroep faalt, maar WANNEER

Je kunt niet alle aanroepen in de transactie verpakken en hopen het op te vangen. Plan voor het ergste

“Je koffiezaak gebruikt geen two-phase commit”

Opties om fouten af te handelen

• Ignore
  • Wil je je systeem stilleggen om deze fout? Logging kan falen, moet dat alles stoppen? Nee
• Retry
  • Probeer de aanroep opnieuw. Maar wat als die faalt? Of wat als de retry faalt?
• Undo
  • Rol de actie terug. Geef de gebruiker een refund in het geval van Stripe
• Coordinate
  • Zet een broker in om beide partijen af te handelen. Voorbeeld: een makelaar

Kies voor elke externe bron de beste optie op basis van de business requirements

Patterns

Saga pattern - Een reeks atomaire transacties met undo en rollback. Voorbeeld: een vakantie boeken met hotel, vlucht en autohuur. Wanneer de vakantie wordt geannuleerd, kan elke stap ook geannuleerd worden.

Process manager pattern - Orchestration (commands) vs choreography (events). Kan een mix zijn in een systeem

Deze patterns worden genoemd in het boek “Enterprise integration patterns”

Refactoring, not just clickbait - Kevlin Henney

Refactoring is niet alleen de kunst van het hernoemen van dingen, en het is ook geen maandenlange reengineering. Refactoring is een design-praktijk.

“Developers are drawn to complexity like moths to a flame, often with the same outcome.” - Neil Ford

“Ik kan dat probleem oplossen, maar ik kan het ook interessanter maken”. Wij (SWE’s) kunnen altijd iets complexers vinden.

Technical debt

Technical debt op zich is geen probleem, net zoals schuld niet altijd een probleem is.

Als de (technische) schuld beheerd en gestructureerd is, een aflossingsplan en -periode heeft, kan het gebruikt worden om dingen sneller te maken.

Als je dat niet op orde hebt, heb je geen technical debt maar technical neglect.

Refactoring

Softwareontwikkeling is een proces van kennisverwerving.

Verderop in een project kun je de kennis verwerven die je een paar weken eerder nodig had. Dat is het moment waarop je iets zou refactoren.

Refactoring = een wijziging aan software om het makkelijker te begrijpen te maken zonder het waarneembare gedrag te veranderen.

Refactoring Driven Development.

Refactor = Software herstructureren door een reeks refactorings toe te passen

95% van de refactoring-uitdagingen is opgelost door tools; de overgebleven 5% wordt veroorzaakt door de developers. Refactoring kan grotendeels geautomatiseerd worden met IDE-functies zoals “Extract method”

“How we spend our days is of course how we spend our lives” - Annie Dillard

Muphry’s law → “If you write anything criticizing editing or proofreading, there will be a fault of some kind in what you have written.”

Atomic habits for developers - Natan Silinsky

De talk is gebaseerd op het boek Atomic Habits van James Clear

Vooruitgang = Het opstapelen van kleine prestaties

Als je naar deze talk ging, wil je een betere developer worden

Een doel bereiken is slechts momentaan geluk

Vermijd doelen - Plan voor gewoontes

Gewoontes volgen deze cyclus

• Cue → Maak het duidelijk
  • Wat, wanneer en waar doe ik de gewoonte?
  • Koppel het aan een context. Je zou leren aan je bureau en niet in je woonkamer.
• Crave → Maak het aantrekkelijk
  • Habit stacking: na [gewoonte die ik nodig heb], doe ik [gewoonte die ik wil]
• Response → Maak het makkelijk
  • Blijf onder het punt waarop het als werk voelt om te beginnen
  • Minimaliseer de acties die je nodig hebt om te starten
  • Richt je omgeving zo in dat het makkelijk te doen is
• Reward → Maak het bevredigend
  • Gamification

Voorbeeld

Gewoonte: Nieuwe tech-skills leren

Cue: Leren tijdens het woon-werkverkeer

Crave: Leren met een collega, sluit je aan bij een cultuur die leren stimuleert

Response/Makkelijk: Luister telkens 1 hoofdstuk van een audioboek. Doe 1 coding kata.

Bevredigend: Deel interessante punten met collega’s, start een discussie over het onderwerp.

Een slechte gewoonte doorbreken

Het is het omgekeerde van het creëren van een goede gewoonte

• Maak het onzichtbaar
  • Blokkeer notificaties om niet afgeleid te worden
  • Verminder de blootstelling
• Maak het onaantrekkelijk
  • Negatieve visualisatie. Denk na over het doel dat je wilt bereiken en wat er gebeurt als je in deze slechte gewoonte blijft hangen
• Maak het moeilijk
  • Blokkeer apps en websites die je tijdens werkuren afleiden
  • Gebruik een commitment device
• Onbevredigend
  • Deel een terugval met een accountability partner
  • Recap je dag met een accountability partner

Architecting in the Cloud for sustainability - Sohan Maheshwa

De presentator werkt bij AWS en daarom was de presentatie gebaseerd op AWS, maar de principes zijn in elke Cloud te gebruiken

Hoe je in de cloud architecteert voor duurzaamheid

Wat je in de cloud bouwt en gebruikt heeft een carbon footprint.

Duurzaamheid stuwt bedrijfsgroei.

GHG-protocol - Green house gas

Scope 1: Alle brandstof die bij de bron verbruikt wordt. Een auto die olie en gas verbrandt.

Scope 2: Energie die ergens anders gebruikt wordt. Voorbeeld: een windmolen

Scope 3: Al het andere. Energie die je consumenten en leveranciers gebruiken.

AWS rapporteert een reductie van 80% CO2 bij de overstap van een traditioneel datacenter naar de cloud.

Dit verschilt per regio; de EU en Azië zijn 5x efficiënter, terwijl de VS 3,6x efficiënter is.

Shared Sustainability Responsibility

Cloud providers zijn verantwoordelijk voor de duurzaamheid VAN de Cloud

De klant is verantwoordelijk voor duurzaamheid IN de cloud. Draai niet de grootste machine voor de kleinste workload.

Duurzaamheid is een continue, gerichte inspanning om energie te verminderen.

ASDI - Gratis energiedata over AWS-duurzaamheid.

User Behavior patterns

Voorbeeldcasus: 2 zones met machines op 50% capaciteit zodat er failover-capaciteit overblijft.

Beter zou zijn om 3 zones op 75% te draaien zodat 2 andere zones het werk van een falende zone kunnen overnemen. Dit leidt tot een betere benutting van resources. De eerste heeft 50% idle, terwijl de tweede 25% idle heeft.

Onderhandel impact-vriendelijke SLA’s. Neem in je SLA’s op om de zones met de laagste impact te gebruiken.

Software patterns

Architecteren voor piekgebruik is duur. Beter om de pieken te verlagen en daarmee de rekenbehoefte te verlagen.

Async, queues, buffers en geplande jobs verlagen pieken. Maar iedereen draait zijn cronjobs om middernacht, wat een piek voor de Cloud creëert.

Hardware patterns

• Gebruik het minimum dat je nodig hebt
• Gebruik managed services
• Gebruik het juiste instance type. CPU- of GPU-gericht.

Data patterns

Denk na over het benaderen en opslaan van data. Cold storage is goedkoper en duurzamer dan alles in hot storage houden. Gebruik hiervoor lifecycle policies.

Gebruik geoptimaliseerde dataformaten zoals AVRO om data op te slaan in plaats van CSV of JSON.

Comprimeer data waar mogelijk.

AWS verminderde hun opslag met 1 Exabyte door over te stappen op een ander compressie-algoritme.

Development en deployment

Verklein de build-artifactgrootte. Dit versnelt je builds en pipelines en verlaagt ook de carbon footprint.

Maak duurzaamheid onderdeel van je hele proces. Rapporteer over metrics tijdens deployments.

Elimineer idle processen

Rapporteer carbon-data aan leiders en klanten zodat zij er iets mee kunnen doen.

Gebruik de AWS well architected service om de carbon footprint te verlagen.