Op Techorama 2025 werden inzichten gedeeld over actuele thema’s binnen de IT en softwareontwikkeling. Deze blog is
geschreven voor IT professionals. In dit blog bespreken we enkele hoogtepunten.

In deze blog geef ik een samenvatting van de verschillende sessies:

• The Past, Present, and Future of AI for Application Developers — Steve Sanderson
• Agents of Change: Building AI Agents that Work (and Think) for Us – Jeff Prosise
• Understanding Model Context Protocol (MCP) — Roelant Dieben
• VAR, AI Referees, and the Future of Code Reviews – Amber Vanderburg
• The Next Decade of Software Development – Richard Campbell
• Relate. Reflect. Respond. – Alice Meredith
• What’s new in C# 13, 14, and beyond – Bart de Smet
• Practical tips for keeping your C# code base clean – Dennis Doomen
• Debugging Like a Coach: Fixing Team Bugs Before They Crash the Game — Amber Vanderburg
• React: The Most Common State Mistakes in 2025 — Cory House
• Fortifying your Workflows: Battle-Tested Security Strategies for Hardening GitHub Actions – Josh Johanning
• Trusted. Respected. Heard. – Alice Meredith
• Lessons from the Fast Lane – Robert Doornbos

The Past, Present, and Future of AI for Application Developers — Steve Sanderson

Steve Sanderson begon zijn sessie met een simpele constatering: “AI makes work better.” En dat is nauwelijks overdreven. Twee jaar geleden gebruikte nog vrijwel niemand AI tijdens het ontwikkelen, nu ligt dat gebruik al rond de vijftig procent. De vraag is niet langer of we AI gaan gebruiken, maar hoe we ermee beginnen.
Om die vraag te beantwoorden, nam Steve het publiek mee op een reis door de tijd — terug naar het begin van het begrip “kunstmatige intelligentie”.

Van Turing tot Eliza

In 1950 stelde Alan Turing zijn beroemde vraag: “Can machines think?” Hij bedacht de zogenaamde imitation game, later bekend geworden als de Turingtest — een manier om te bepalen of een machine menselijk genoeg kan converseren.
In de jaren zestig ontstonden de eerste chatbots. Steve toonde live een klassieker: Eliza , een programma dat met simpele stringvervanging reageerde op wat je zei. Als je iets intypte, herhaalde Eliza het gewoon in de vorm van een vraag. Het werkte niet echt, maar het was een fascinerende illusie. Steve lachte: “People process it as intelligence — but it’s just string replacement.”

De fundamenten van voorspellende tekst

Daarna ging hij nog verder terug. In 1913 beschreef Andrey Markov de kans dat een volgende letter of woord afhangt van de vorige — de basis voor wat we nu Markov chains noemen.
En in 1948 legde Claude Shannon met zijn informatietheorie de basis voor moderne taalmodellen. Hij liet zien hoe je op basis van letterfrequenties een tekst kunt laten “gokken” wat erna komt.

“Pro tip,” grapte Steve. “Everything is legitimate for AI.”
En inderdaad: zelfs iets eenvoudigs als een letterrooster kan de kiem zijn van een taalmodel.

De doorbraak: Transformers

Pas in 2017 kwam de echte revolutie: de Transformer-architectuur. Die maakte het mogelijk om context op veel grotere schaal te begrijpen. Sindsdien is de groei van AI-modellen explosief.
Steve toonde een overzicht van bekende modellen — van GPT-1 met 117 miljoen parameters tot GPT-4 , waarvan naar schatting 1,7 biljoen parameters onder de motorkap zitten. Daar tegenover staan open modellen als LLaMA en DeepSeek R1 , die ook snel aan terrein winnen.

Hoe een taalmodel leert

Om te laten zien hoe AI leert, trainde Steve live een kleine versie van GPT-2.
Na één iteratie was de output pure chaos.
Na honderd iteraties begon het model taalpatronen te herkennen.
Na vijfhonderd iteraties produceerde het zinnen die grammaticaal klopten.

“It’s just predicting the next token,” zei Steve.
“Chat completion is simply token prediction shaped into something we want to hear.”

Function calling en echte intelligentie

Maar moderne AI gaat verder dan tekstvoorspelling. Met function calling kan een model nu echte methodes aanroepen of data uit de echte wereld ophalen.
Zo ontstaat een brug tussen tekstbegrip en praktische actie.
Hij liet zien hoe dat werkt in toepassingen als:

• Chat-interfaces
• RAG (Retrieval-Augmented Generation)
• Virtuele assistenten

C# in actie

Vervolgens stapte hij over naar de praktijk: AI integreren in .NET.
Met Microsoft.Extensions.AI en IChatClient demonstreerde hij hoe je een AI-model eenvoudig laat samenvatten, vertalen of classificeren.
Een voorbeeld met een vastgoedapplicatie liet zien hoe een AI automatisch eigenschappen uit een beschrijving kon extraheren en in JSON kon teruggeven.

Vision en reasoning

Steve liet ook multimodale toepassingen zien — modellen die niet alleen tekst, maar ook beelden begrijpen.
Met GPT-4o-mini en lokale modellen via Hugging Face (een site waar veel AI modellen op staan) demonstreerde hij beeldclassificatie, zelfs draaiend in WebAssembly.
Daarna ging het over reasoning models: AI die niet alleen voorspelt, maar nadenkt — patronen herkent, context begrijpt en keuzes maakt.
Hij liet praktische voorbeelden zien:

• Formulieren automatisch invullen op basis van clipboarddata
• Slimme autocomplete
• Semantische zoekfuncties
• Spraakinterfaces, zoals in een auto-advertentie met voice-input

Tot slot

Aan het einde van zijn sessie benadrukte Steve dat de toekomst van AI niet alleen draait om grotere modellen, maar om betere modellen — systemen die begrijpen wat ze doen.
AI wordt niet meer alleen een tool die code aanvult of tekst genereert, maar een integraal onderdeel van hoe we software bouwen. De lijn tussen mens en machine vervaagt en voor ontwikkelaars ligt daar niet een bedreiging, maar een kans: om slimmer, sneller en creatiever te bouwen dan ooit tevoren.

Agents of Change: Building AI Agents that Work (and Think) for Us – Jeff Prosise

Jeff Prosise stapte het podium op met een energieke glimlach en de belofte van “lots of demos.” Hij hield woord. Het volgende uur stond in het teken van een nieuwe golf binnen AI: autonome agents — systemen die niet alleen reageren, maar ook samenwerken, plannen en handelen.

“Think of them as microservices for AI,” zei Jeff.
“Each agent does one thing extraordinarily well. Together, they can solve problems far more complex than any single model could.”

Wat zijn AI-agents eigenlijk?

Een AI-agent is in de basis een wrapper rondom een LLM (Large Language Model). Maar in plaats van simpelweg tekst te genereren, krijgt de agent autonomie en tools om specifieke taken uit te voeren: data ophalen, bestanden doorzoeken, berekeningen uitvoeren of zelfs API’s aanroepen.
Jeff legde het uit als een soort bouwteam: jij levert de bouwstenen, AI zorgt voor de workflow en het framework biedt de infrastructuur voor communicatie tussen de agents.

Agentic frameworks: de bouwstenen van deze nieuwe golf

Hij liet vier populaire frameworks zien die deze manier van werken mogelijk maken:

• Agents SDK / AutoGen – Een open-source framework van Microsoft voor het coördineren van meerdere agents. Ondersteunt RAG (Retrieval-Augmented Generation), verschillende conversatiepatronen en werkt met Python en .NET.
• CrewAI – Een Python-framework waarin groepen (“crews”) van agents samenwerken. Rijke ondersteuning voor geheugen en toolgebruik.
• Agno – Een open-source, LLM-agnostisch framework dat toolgebruik, persistentie en RAG ondersteunt, met een ingebouwde playground om workflows te testen.
• OpenAI’s Agents SDK – Een meer Python-first benadering met ondersteuning voor geheugen, audio, tool use en web search.

De praktijk: agents die denken, plannen en samenwerken

Om te laten zien wat dat betekent, bouwde Jeff live een prototype.
Op het scherm verscheen een fictieve vacature voor een CEO. Een agent analyseerde cv’s, beoordeelde kandidaten en gaf scores tussen 1 en 10 — allemaal in natuurlijke taal.

“One agent reads the resumes, another compares them to the job description, a third composes the response,” legde hij uit.
“They pass information dynamically — one by one — like a team.”

De workflow verscheen als een soort chatinterface waarin agents met elkaar communiceerden. Jeff vroeg de AI zelfs om een rejection letter in the style of Dr. Seuss — en het werkte.

Hoe werkt dat technisch?

Achter de schermen gebeurt er veel.
LLM’s zijn stateless, dus een agent-framework moet zelf geheugen bijhouden. Jeff liet zien hoe dat werkt met een eenvoudige in-memory database of met SQLite of MongoDB.
Hij demonstreerde Agno, waarin agents eenvoudig worden gedefinieerd met een paar regels Python-code.
Een agent heeft:

• een instructieprompt,
• een session ID,
• en een streaming-output om tussentijdse resultaten te tonen.

Agno bevat ingebouwde tools voor o.a. samenvatten, rekenen, het ophalen van data (zoals via yfinance) en zelfs het genereren van afbeeldingen. Alles via function calling — waarbij de LLM een JSON-beschrijving van de gewenste functie opstelt, die vervolgens echt wordt uitgevoerd.

MCP – de nieuwe standaard voor agentcommunicatie

Daarna ging het over MCP (Model Context Protocol), een nieuwe standaard die LLM’s in staat stelt om functies en API’s te importeren alsof het lokale tools zijn.
Bedrijven zijn druk bezig hun diensten via MCP beschikbaar te maken — van PayPal tot Salesforce.
De voordelen:

• gestandaardiseerde communicatie tussen agents;
• eenvoudige authenticatie (OAuth, tokens environment variables);
• ondersteuning voor streaming via HTTP.

Agno heeft zijn eigen MCP-server en ondersteunt multi-agent orchestration met vector databases en deelbare context.

Multi-agent samenwerking in actie

Tot slot liet Jeff een indrukwekkende demo zien van meerdere agents die samenwerkten aan een data-analyse.
Een Database Agent haalde gegevens op, een Quant Agent verwerkte ze en een Visualization Agent genereerde de grafiek — alles binnen een teamstructuur, aangestuurd door een Team Lead Agent.
In Python definieerde hij een Team-klasse met een members-property. Door share_member_interactions=True te zetten, konden de agents onderling informatie delen. Het resultaat verscheen als een live gegenereerde plot op het scherm.

De toekomst van agentic AI

Jeff sloot af met een vooruitblik:
AI-agents zullen binnenkort samenwerken zoals menselijke teams dat doen — met rollen, taken en context. De ontwikkelaar definieert het speelveld, maar de agents bepalen de uitvoering.

“We’re entering the era of AI orchestration,” zei hij.
“Where you don’t just build models — you build teams.”

Understanding Model Context Protocol (MCP) — Roelant Dieben

De sessie begon rustig, met een simpele titel op het scherm: “Understanding MCP.” Maar al snel werd duidelijk dat dit niet zomaar een technische uitleg zou worden — dit was een kijkje in wat velen de nieuwe ruggengraat van AI-integratie noemen.

De opkomst van MCP

Roelant trapte af met een glimlach: “MCP is nog geen jaar oud, maar het zorgt nu al voor flink wat buzz.”
Zijn agenda was overzichtelijk:

1. Introductie
2. Wat is MCP en waarom de ophef
3. De fundamenten
4. Zelf een MCP-server bouwen
5. Belangrijkste inzichten

Hij grapte over de USB-analogie — “I hate this analogy, it had nine connectors” — maar gebruikte het toch om te illustreren wat MCP wil zijn: één universele standaard voor hoe taalmodellen met externe systemen praten.

Waarom MCP nodig is

LLM’s, legde Roelant uit, kennen jouw wereld niet. Ze hebben geen toegang tot je documenten, API’s of databases. Ze genereren tekst, maar zonder context weten ze niet wat relevant of actueel is.

“Context is everything to the model,” zei hij.
“Good context makes agents smarter — and safer.”

MCP (Model Context Protocol) is ontworpen om dat probleem op te lossen. Het combineert memory, state en access — zodat een model kan werken met externe informatie op een veilige, gestandaardiseerde manier.

Wat is MCP?

MCP werd geïntroduceerd in november 2024 en is een open-source standaard die sterk doet denken aan bestaande protocollen als REST, LSP (Language Server Protocol) en JSON-RPC. Het is flexibel, webgebaseerd en bedoeld om de interactie tussen LLM’s, applicaties en tools te standaardiseren.

Demo: MCP in actie

Tijdens de demo opende hij Visual Studio Code en liet hij zien hoe GitHub Copilot, via MCP, kon communiceren met externe services.
Hij vroeg: “Are there new papers on Hugging Face?” Copilot stuurde de vraag via een MCP server , die op zijn beurt de informatie ophaalde. Geen custom plugin meer nodig, geen API-sleutels overal verstopt — gewoon één gestandaardiseerde interface.

“Every LLM used to need its own interface,” zei Roelant. “MCP replaces all of that.”

Hij toonde een GitHub MCP registry , waar al honderden servers beschikbaar zijn — van Playwright tot Hugging Face.

Hoe MCP werkt

MCP draait om drie kerncomponenten:

• Tools – functies of API-calls die een model kan gebruiken.
• Resources – leesbare datasets, bestanden of endpoints.
• Prompts – vooraf gedefinieerde templates voor AI-interacties.

Een MCP client roept tools aan of vult prompts in, terwijl een MCP server die tools en bronnen beschikbaar stelt.
De communicatie verloopt via JSON-RPC , met endpoints zoals /tools/list en /tools/invoke.
Roelant liet met de MCP Explorer zien hoe je de beschikbare tools kunt inspecteren, tokens kunt toevoegen en direct met servers kunt praten.

Lokale vs. externe MCP communicatie

Hij onderscheidde twee typen verbindingen:

• STDIO – lokaal, bidirectioneel en met lage latency (bijvoorbeeld binnen je eigen machine of editor).
• Streamable HTTP – voor externe, netwerkgebaseerde communicatie met authenticatie en streaming-ondersteuning.

STDIO is snel en betrouwbaar voor lokale agents; HTTP is ideaal voor cloudgebaseerde of remote toepassingen.

Pokémon: een verrassende analogie

De eerste slide was al in Pokemon stijl.

“It will make sense later,” had hij aan het begin gezegd — en dat deed het.

Hij legde de analogie uit:

• Pokédex → MCP Registry
• Pokémon → MCP Servers
• Pokémon Skills → Tools
• Pokémon Cards → Resources
• Pokéball → Client
• Trainer → Host
• Battle → Task

Een speelse, maar effectieve manier om te laten zien hoe MCP een ecosysteem vormt waarin clients, servers en tools samenwerken.

Beveiliging en authenticatie

Omdat MCP toegang kan krijgen tot gevoelige data, is veiligheid cruciaal.
Het protocol gebruikt OAuth 2.1 en OpenID Connect , met nadruk op “least privilege” en tokenvalidatie.
Roelant legde uit dat OAuth 2.1 inmiddels veiliger en consistenter is dan zijn voorganger en dat Microsoft werkt aan Entra Agent ID als mogelijke uitbreiding voor agentic identity management.

“MCP is only as secure as you make it,” zei hij. “Keep it updated, and follow best practices.”

Zelf een MCP-server bouwen

Tot slot liet hij zien hoe eenvoudig het is om een eigen MCP-server te bouwen.
In Visual Studio voegde hij via NuGet het ModelContextProtocol-pakket toe.
Met slechts zes regels code registreerde hij een HTTP-client naar de PokéAPI — en maakte zo een simpele, werkende MCP-server met een eigen tool.

“Just HTTP,” benadrukte hij. “No magic.”

Key takeaways

• MCP maakt AI écht contextbewust.
• Het standaardiseert de manier waarop LLM’s tools, data en geheugen gebruiken.
• Het is open, uitbreidbaar en al breed geadopteerd.
• Beveiliging is geïntegreerd, maar blijft je eigen verantwoordelijkheid.
• Context engineering — het bewust ontwerpen van de informatie die je AI krijgt — wordt een nieuw specialisme.

VAR, AI Referees, and the Future of Code Reviews – Amber Vanderburg

Amber opent met een voetbalclip — een bal die nét over de doellijn gaat. De zaal reageert meteen: herkenning, frustratie, discussie. Ze glimlacht: “Outrage in football. What do we do in situations like this?”

Amber is voormalig sportcoach en nu actief in tech leadership. Ze neemt het publiek mee door de geschiedenis van technologie in de sport — en wat we daarvan kunnen leren als softwareontwikkelaars.

In 1731 verscheen de eerste stopwatch. Daarna kwam de elektronische klok, de ‘photo finish’ en automatische scorebepaling bij bowlen. In 1995 deed video-refereeing zijn intrede en in 2001 kwam AI de sport binnen via cricket — het beroemde Hawk-Eye systeem dat met zes tot tien camera’s de balbeweging volgt.

De technologie verbeterde de kijkervaring , maar bracht ook vragen over eerlijkheid en vertrouwen. Tennis volgde in 2006 met real call video assistance. In 2010 zagen we het bekende WK-moment tussen Engeland en Duitsland: een doelpunt dat niet werd toegekend. Twee jaar later voerde de FIFA doeltechnologie in en in 2018 werden videoreferees officieel gebruikt tijdens het WK. Volgens FIFA lag de nauwkeurigheid toen op 99,3%.

In 2022 kwam daar semi-automatische buitenspeltechnologie bij: twaalf camera’s, twintig datapunten per speler. Amber stelt de vraag: “Do we even need human referees anymore?”

Maar: zonder context is er geen vertrouwen. Het publiek accepteert een menselijke fout nog eerder dan een kil technisch besluit van een systeem.
Daarna maakt Amber de overstap naar software: de toekomst van code reviews.

Ze laat een reeks beelden zien van gebeurtenissen waar technologie “technisch correct” handelde, maar menselijk gezien faalde — van persoonlijke tragedies tot Dieselgate bij Volkswagen. Een “defeat device” liet auto’s anders presteren tijdens tests, waardoor ze voldeden aan regels, maar de werkelijkheid maskeerden.
De les: context en intentie doen ertoe.

Amber benadrukt dat goede code reviews — net als goede arbitrage — niet alleen gaan over correctheid , maar over kritisch denken , empathie en communicatie.
Ze zegt: “The questions you ask reveal your values.”

Ze illustreert dit met voorbeelden uit het onderwijs en uit het dagelijks leven.

Wie bij een auto-ongeluk eerst vraagt “hoe erg is de schade?” in plaats van “ben je oké?”, laat zien welke waarde prioriteit krijgt.
Hetzelfde geldt bij code reviews: de vragen die we stellen sturen het gedrag van een team.

Amber vertelt over haar ervaring in India, waar ze een voetbalacademie leidde. De spelers waren taakgericht: ze wachtten op instructies en feedback, zonder het grotere spel te zien. Ze leerden een vaardigheid, maar misten context en creativiteit.
Na jaren training begreep ze dat haar taak niet was om hen nóg beter te laten uitvoeren, maar om hen te leren denken in systemen — de bigger picture te zien.
Tot slot maakt ze de sprong naar AI in coaching en code reviews.

AI kan ons helpen, maar zonder context mist het systeem menselijkheid. Ze toont beelden van vertrouwen en samenwerking en stelt de vraag:
“How are you building trust — with your team, your tools, your AI?”
Vertrouwen, zegt ze, bestaat uit competence, character en communication.
Je kunt iemand vertrouwen met een geheim, maar niet met je auto — omdat vertrouwen domeinspecifiek is.

Goede code reviews, net als goede scheidsrechters, vragen om datzelfde evenwicht tussen correctheid en context.
Het is niet genoeg dat iets werkt — het moet kloppen binnen de waarden van het team en de gebruikers.

Amber eindigt met een persoonlijke anekdote: een jonge speler die “pass!” riep, maar niet wist waarom. Pas toen ze samen de bedoeling achter de actie begrepen, ontstond er echt spelinzicht.
“Reviewing code,” zegt ze, “isn’t about shouting instructions — it’s about helping others see the field.”

The Next Decade of Software Development – Richard Campbell

Richard Campbell, bekend van DotNetRocks en RunAs Radio (samen goed voor bijna tweeduizend afleveringen), nam het publiek mee op een reis door de tijd — van de begindagen van de cloud tot aan de toekomst van softwareontwikkeling in het komend decennium.

Het einde van Moore’s Law

Richard dook vervolgens de geschiedenis van hardware in: van Fairchild Semiconductor in 1960 tot Intel’s vroege RAM-chips. Moore’s Law — de observatie dat het aantal transistors op een chip ongeveer elke twee jaar verdubbelt — heeft decennialang onze vooruitgang gedragen. Maar, zei hij: “We’re at the end of that curve.”
De afstanden tussen transistors worden nu gemeten in nanometers en zelfs picometers. Chips worden 3D en fabrikanten als Intel en TSMC werken aan 2nm-processors. Ondertussen komen ARM-processors op in de cloud, terwijl Apple’s M5-chips met 16 cores en neurale netwerken krachtige lokale AI-taken draaien.
Zijn punt: hardwareontwikkeling verandert niet alleen in tempo, maar ook in karakter.
De toekomst ligt in specialisatie — quantum, neuromorfisch, edge — in plaats van simpelweg sneller en kleiner.

De evolutie van software

Richard liet een lijst van talen en tools zien die developers de afgelopen decennia hebben gebruikt: Python, Java, C#, JavaScript, Swift, Go, Kotlin, Rust, TypeScript.
“None of them are perfect,” zei hij. “They’re just the current answers.”
Hij besprak de verschuiving van client naar cloud, van Windows naar Linux en van traditionele apps naar browsers en PWAs.
“.NET is 20 years old,” herinnerde hij het publiek, “and .NET 10 is around the corner.”
Er volgde een snelle tour door de wereld van low-code tools — Power BI, Power Apps, Power Automate, Power Virtual Agents — en de manier waarop ze traditionele ontwikkelcycli versnellen. Toch, benadrukte hij, blijft de kern hetzelfde: “Good software is still about solving real problems.”

AI: het slechtste goed bedachte woord

Richard noemde “AI” het slechtste marketingwoord ooit.
Hij lachte: “If it doesn’t work, we call it AI. Once it works, we rename it.”
Hij verwees naar HAL 9000 uit 2001: A Space Odyssey, naar de angst voor machines die ons vervangen — en naar de ironie dat moderne AI vooral ons werk makkelijker maakt.
Hij beschreef de opkomst van OpenAI, Google Brain, de ruzies over financiering en de samenwerking tussen Microsoft en OpenAI die leidde tot ChatGPT en GitHub Copilot.
Toch waarschuwde hij: “Copilot is your copilot — but if the plane crashes, it’s still your fault.”
AI kan code genereren, workflows versnellen en documentatie doorspitten, maar het neemt geen verantwoordelijkheid over.

Technologiehypes en wat blijft

Op het scherm verscheen de Gartner Hype Cycle. Richard vergeleek de huidige AI-golf met de dotcom-bubbel van de jaren negentig.
Toen ook kwam er een stortvloed aan investeringen en hoewel veel bedrijven verdwenen, bleef de infrastructuur: de netwerken, servers, browsers en standaarden waarop het internet vandaag nog steeds draait.
“Bubbles come and go,” zei hij, “but the foundations remain.”
Hij noemde zeven grote bedrijven die nu de wereld van AI en cloud domineren en sprak over de groeiende energiebehoefte van datacenters, de verschuiving van banen en het ontstaan van nieuwe rollen rondom AI-veiligheid, ethiek en auditing.

Verder dan generatieve AI

Richard ging daarna dieper in op generatieve AI buiten tekst en code. Hij noemde AlphaFold 3 — dat eiwitstructuren voorspelt — als voorbeeld van AI die wetenschappelijke vooruitgang versnelt.
Hij sprak over batterijen waarvan we nog niet precies begrijpen waarom ze werken, over landbouw waar sensoren en drones bemesting optimaliseren en over de manier waarop machine learning ons helpt zulke complexe systemen te modelleren.
Hij benadrukte dat innovatie niet altijd zichtbaar is. “Phones haven’t changed much,” zei hij, “but what happens behind the glass is revolutionary.”
Hij noemde Apple Vision Pro en Meta’s nieuwe brillen als stappen in de richting van “see-through computing” — maar gaf toe dat we de echte killer use-case voor kenniswerkers nog moeten vinden.

Quantum en de grenzen van kennis

Tot slot nam Richard het publiek mee naar de wereld van quantum computing.
Hij sprak over IBM’s Quantum Eagle, Microsoft’s Majorana-processor en de bizarre omstandigheden waarin deze machines functioneren — gekoeld met helium, zwevend in vacuüm, trillingsvrij tot op atomaire schaal.
Hij vergeleek de huidige fase van quantum computing met de begindagen van de transistor.
“Back then,” zei hij, “we didn’t even know what digital meant yet. Now we’re staring at the next revolution — and just like then, the unreliable will eventually make the reliable.”
Hij eindigde met een optimistische blik:

“We’re in the big time now. We get to make the future.”

Relate. Reflect. Respond. – Alice Meredith

Alice Meredith, met dertig jaar ervaring in leiderschap en verandermanagement, bracht in haar sessie een frisse, menselijke kijk op werk, communicatie en verandering. Haar carrière begon ooit bij Blockbuster Video , daarna werkte ze in HR-leiderschap bij Best Buy en ging daarna trainingen geven bij Pluralsight, waar ze inmiddels meer dan dertig leiderschapscursussen ontwikkelde. Haar missie: mensen helpen de menselijke kant van werk te beheersen — om niet alleen functioneel aanwezig te zijn, maar ook echt verbinding te maken, te reflecteren en bewust te reageren.

“Soft skills aren’t soft,” zei ze. “They’re the hard stuff that makes the hard skills matter.”

De menselijke kant van werk

Om effectiever te zijn in ons werk, moeten we eerst begrijpen hoe we zelf ‘geprogrammeerd’ zijn — ons menselijk besturingssysteem , zoals zij het noemde: een verzameling van levenservaringen, overtuigingen en automatische patronen die we soms zelf hebben gekozen, maar vaak gewoon hebben overgenomen.
We draaien allemaal met een eigen set ‘apps’: persoonlijkheidstypologieën zoals DISC, MBTI, Big Five enneagram en Gallup Strengths. Geen enkele is perfect, maar samen geven ze inzicht in onze kern.
Volgens Alice bestaat die kern uit vier fundamentele drijfveren:

• Macht (Power) – Ze hebben de wens om dingen te laten gebeuren.
• Loyaliteit (Loyalty) – Gedreven door loyaliteit, relaties en waarden.
• Plezier (Fun) Gedreven door plezier. Hebben veel energie.
• Vrede (Peace) – Creëren rust, stabiliteit en veiligheid.

Ze vergeleek onze sterke kanten met een huis met een balkon en een kelder:

“Op het balkon schitteren je kwaliteiten; in de kelder schieten ze door en worden ze je valkuil.”

Het doel is om jezelf in realtime te herkennen en terug naar het balkon te bewegen — naar balans.

Relate: de kracht van echt zien

In het deel Relate vertelde ze een verhaal over een 14-jarige jongen die ze ooit ontmoette aan het strand van Venice Beach. Hij deed stunts op zijn skateboard, terwijl dat daar eigenlijk niet mocht. Toen ze hem aankeek en simpelweg zei: “I see you”, veranderde zijn houding compleet.

“Being seen makes people feel they matter.”

In organisaties werkt het net zo. Mensen willen zich gezien en gehoord voelen. Kleine gebaren kunnen daar groot verschil in maken.
Ze gaf een voorbeeld van haar tijd bij Best Buy, waar ze een interne HR-e-mail herschreef die aanvankelijk formeel en afstandelijk was. In twintig seconden maakte ze de boodschap warmer, persoonlijker, menselijker — “You matter” in plaats van “You must.”

Reflect: het bouwen van verbindingen

Alice moedigde leiders aan om “connection bombs” te planten — spontane, menselijke interacties op de werkvloer die relaties versterken. Ze vertelde hoe ze ooit, tijdens een lunchwandeling, een toevallige ontmoeting had over een Journey-concert. Dat leidde tot een halfuur gesprek, nieuwe inzichten en een langdurige samenwerking.

“Every small conversation expands your network and builds trust.”

Verbinding ontstaat niet in vergaderingen of KPI’s, maar in de tussenruimte — de momenten waarin mensen zichzelf mogen zijn.

Respond: omgaan met conflicten en verandering

Het derde onderdeel draaide om responsiviteit — hoe we reageren in situaties van spanning of feedback.
Alice haalde het Thomas-Kilmann-conflictmodel aan, met vijf stijlen:

• Competing (win-verlies)
• Avoiding (verlies-verlies)
• Accommodating (verlies-winst)
• Compromising (klein win-klein verlies)
• Collaborating (win-win)

Ze benadrukte dat conflictstijlen niet statisch zijn: we kunnen leren om flexibel te schakelen, afhankelijk van de context.

Rommelig einde

Zo eindigde de sessie zonder duidelijke conclusie met veel persoonlijke anektotes.

What’s new in C# 13, 14, and beyond – Bart de Smet

Bart de Smet, Principal Software Engineer bij Microsoft en bekend gezichten binnen de .NET-community, nam het publiek mee in een snelle maar diepgaande tour door de nieuwste features van C# 13 , de aankomende verbeteringen in C# 14 en zelfs een voorproefje van wat daarna nog in de pijplijn zit.
Zoals altijd deed hij dat met zijn kenmerkende combinatie van precisie, snelheid en diepgang.

Params reimagined

C# 13 breidt de bekende params-functionaliteit eindelijk uit. Waar params sinds de begintijd alleen arrays accepteerde, kunnen ze nu ook werken met andere collection types — denk aan IEnumerable<T>, IList<T>, ImmutableArray<T>, of zelfs custom types die IEnumerable implementeren.

Locking: eenvoudiger en veiliger

Een van de meest zichtbare verbeteringen is de nieuwe lock syntax. In plaats van expliciet te werken met Monitor.Enter en Monitor.Exit, introduceert C# 13 een veiligere, moderne variant

Escape sequences: een kleine maar fijne update

Console-API’s ondersteunen nu de Unicode escape \e (in plaats van het oude \x1B), wat code leesbaarder maakt bij het werken met ANSI-color output of terminal-besturing.

Kleine verbeteringen, groot gemak — “less hexadecimal guessing,” aldus Bart.

Ref en unsafe in iterators

Een meer geavanceerde toevoeging: iterators (yield return) kunnen nu werken met ref en unsafe contexten , zonder onnodige heap-allocaties.
Hierdoor worden iterators efficiënter bij performancekritische code, bijvoorbeeld bij Span<T>-operaties.
ref struct types blijven wel beperkt tot de stack — ze kunnen dus niet naar de heap of interfaces worden gecast — maar dankzij nieuwe compilerondersteuning kun je ze nu combineren met IDisposable via het allow ref structs-attribuut.

Partial members en de field keyword

C# 13 breidt partial classes verder uit met partial members — niet alleen methodes, maar ook indexers, properties en constructors kunnen nu als partial worden gedefinieerd. De nieuwe field keyword maakt het bovendien eenvoudiger om in properties expliciet naar het backing field te verwijzen: Een elegante oplossing voor wie vaak boilerplate in properties moest schrijven.

Overload resolution attributes

Een subtiele maar belangrijke verandering: C# 13 introduceert een nieuw [OverloadResolutionPriority] attribuut, waarmee library-ontwikkelaars de prioriteit van overloads kunnen sturen — zonder binary-breaking changes. Vooral nuttig bij API’s die ReadOnlySpan<T> ondersteunen.

C# 14 – de volgende stap

Extension members

De grootste verandering die eraan komt, zijn extension members — niet alleen methodes, maar ook properties, indexers en zelfs operators kunnen worden uitgebreid.
Dat betekent dat je bijvoorbeeld dit kunt doen:

extension StringExtensions on string
{
    int WordCount => this.Split(' ').Length;
}

De feature wordt nog verder uitgewerkt, maar de potentie is groot — zeker voor domeinspecifieke API’s.

User-defined compound assignment

C# 14 introduceert ook custom compound assignments zoals += of ++ in structs. Zo kun je zelf bepalen hoe samengestelde bewerkingen zich gedragen — een krachtig hulpmiddel voor bijvoorbeeld numerieke types of matrixklassen.

Null-conditional assignment

De welbekende ?. operator krijgt een zusje: de null-conditional assignment.
Waar je vroeger alleen kon lezen met ?., kun je nu ook veilig toewijzen:

person?.Address ??= new Address();

Beyond: de horizon van C

Tot slot gaf Bart een vooruitblik op toekomstige concepten — zoals unbound generic names, lambda-parameters met modifiers en verdere uitbreiding van partial members.
De focus blijft volgens hem op type safety, performance en expressiviteit — drie pijlers waar C# al twintig jaar om bekendstaat.

“We’re not done evolving,” sloot Bart af. “C# keeps growing with the developers who use it.”

Practical tips for keeping your C# code base clean – Dennis Doomen

Dennis Doomen — bekend van zijn Fluent Assertions-library en zijn expertise in clean architecture — deelde in deze sessie zijn meest beproefde adviezen voor het onderhouden van een gezonde, schaalbare en begrijpelijke C#-codebase.
Zijn boodschap was duidelijk: “Clean code isn’t about writing less code — it’s about writing code that everyone wants to work with.”

Keep it simple: fight unnecessary complexity

Hij begon met een observatie over hoe veel teams onnodig complexe architecturen creëren. Niet elke toepassing heeft microservices nodig, benadrukte hij:

“If you don’t need independent scaling, merge those microservices back into a modular monolith.”

Het is volgens hem beter om eerst te kijken waar je daadwerkelijk moet schalen — en pas daarna de architectuur daarop aan te passen. Microservices zijn een middel, geen doel.
De Gartner Hype Cycle kwam voorbij: technologieën worden vaak te vroeg geadopteerd. Dennis moedigde aan om pragmatisch te blijven — eenvoud boven hype.

Organiseer de codebase logisch

Een terugkerend thema: structuur.
De mapstructuur van je project moet de architectuur weerspiegelen, niet de technologie. Geen “Controllers”-, “Services”- en “Repositories”-mappen, maar verticale slices zoals Orders, Payments, Users.

“The folder structure should explain your architecture at a glance.”

Daarnaast: hou concrete implementaties intern (internal) en exposeer alleen interfaces waar nodig. Door conventie en tooling kun je afdwingen dat interne onderdelen niet per ongeluk publiek worden.

Gebruik tooling om consistent te blijven

Automatisering is essentieel om kwaliteit te bewaken. Dennis liet zien hoe EditorConfig , Prettier en .NET analyzers kunnen helpen bij consistente formatting en statische code-analyse.
Ook JetBrains Inspect, SonarQube en Roslyn analyzers noemde hij als hulpmiddelen om vroegtijdig problemen te detecteren.

“Let tools do the boring work so you can focus on design.”

Zelfs AI kan hierbij helpen — hij noemde Copilot en Sonnet als voorbeelden van assistenten die mee kunnen denken bij refactoring, zolang je hun output nog steeds als je eigen code beschouwt.

Document the why, not the how

Veel documentatie schiet tekort omdat ze uitlegt wat de code doet, niet waarom ze zo is opgebouwd.
Dennis pleitte voor korte, doelgerichte commentaren die context toevoegen:

“Explain the purpose, not the procedure.”

Gebruik beschrijvende titels en laat de code zelf het werk doen. Tools zoals GhostDoc kunnen helpen bij basisdocumentatie, maar het echte werk zit in de intentie.

Slimme commit- en branchstrategieën

Versiebeheer is volgens hem een onderschat onderdeel van clean code.
Kies één bekende branchstrategie — zoals GitHub Flow of GitFlow — en houd je eraan.
Belangrijker nog:

• Splits refactoring commits van functionele wijzigingen.
• Houd PR’s klein en gericht.
• Gebruik fix-up commits en interactive rebases om je geschiedenis schoon te houden.

“A clean commit history is a clean story of your code.”

Hij toonde voorbeelden in GitKraken hoe kleine, goed getitelde commits het reviewproces aanzienlijk verbeteren.

Reduce dependencies and coupling

Een schoon systeem is een los systeem.
Gebruik Central Package Management om versies te beheren en afhankelijkheden te minimaliseren.
Wanneer code herbruikbaar moet zijn, publiceer het als een NuGet-pakket in plaats van losse binaries.
Verder:

• Vermijd mocks of mocks door interfaces bewust te ontwerpen.
• Gebruik adapters om afhankelijkheden te isoleren.
• Overweeg een omgekeerde afhankelijkheidsrichting wanneer een module te veel weet van een ander.

“Every dependency is a liability — treat it like one.”

Dupliceer liever dan te vroeg te abstraheren

Een opvallend advies dat vaak tot discussie leidt:

“Duplicate before you abstract.”

Dennis legde uit dat je pas moet abstraheren wanneer je dezelfde code minstens drie keer nodig hebt.
Te vroege generieke oplossingen leiden tot onnodige complexiteit en onbegrijpelijke code.

“If it’s too complicated to reuse, maybe it’s not worth reusing.”

Hij verwees naar het principe van de “Rule of Three” en de YAGNI-filosofie (You Ain’t Gonna Need It).

Refactoring and scouting rule

Refactoring hoort een natuurlijke gewoonte te zijn, geen project op zich.
Kleine verbeteringen mogen continu gebeuren, mits goed afgescheiden in commits.
Dennis sloot af met het “Scouting Rule”-principe:

“Always leave the code cleaner than you found it.”

Samenvattend

De sessie was een praktische gids vol nuchtere adviezen:

• Gebruik minder patronen en meer gezond verstand.
• Automatiseer consistentie.
• Schoon commitgedrag is net zo belangrijk als schone code.
• En abstraheer pas als het écht nodig is.

Of zoals Dennis het zelf zei:

“Clean code isn’t a style — it’s a culture. Build it, live it, and your future self will thank you.”

Building the Ultimate Safety Net with Integration Tests — Jimmy Bogard

Het was best druk toen Jimmy Bogard begon aan zijn talk. Z'n presentatie was: demo-heavy, geen theoretisch verhaal. Hij startte met een herkenbaar beeld — een project zonder tests, tot de eerste bug opdook. En dan de pijnlijke realiteit: hoe later je een bug ontdekt, hoe duurder het wordt. Toch blijven veel teams hangen bij unit tests of, erger nog, helemaal geen automatische tests.
Bogard haalde de testing pyramid erbij om dat punt te illustreren. Unit tests zijn snel en goedkoop, maar vaak te ver verwijderd van het echte proces. UI-tests zijn daarentegen traag en breekbaar. Integration tests — die het geheel samenbrengen — zijn trager dan unit tests, maar leveren wél de meeste waarde op, juist omdat ze de echte componenten gebruiken.
Hij liet een eenvoudig voorbeeld zien met een applicatie die queries uitvoert, business-logica afhandelt en data opslaat. In de praktijk zijn de meeste systemen complexer: veel interacties met de database, mocks die verouderen en test suites die vooral vertrouwen vernietigen in plaats van opbouwen. Zijn boodschap was duidelijk: “Mocks can lie. Integration tests don’t.”
Unit tests kunnen je een vals gevoel van veiligheid geven. Ze zijn vaak te sterk gekoppeld aan implementatiedetails, breken bij refactoring en vangen zelden echte regressies. Bogard pleitte ervoor om minder te “mocken” en meer te testen met echte afhankelijkheden — zonder externe tools, tenzij het echt niet anders kan.
Daarna kwam de live demo. Hij gebruikte een Microsoft.AspNetCore.Mvc.Testing library en WebApplicationFactory met xUnit. Een simpele HTTP-client maakte in-process calls naar de applicatie, controleerde responses en voerde assertions uit. De test draaide in slechts 282 ms — volledig end-to-end, zonder mocks.
De volgende stap: integratie met een echte database. Met FastEndpoints en Testcontainers liet hij zien hoe je PostgreSQL in Docker kunt starten voor elke test, onafhankelijk en schoon. Database-seeding, migraties en configuratie gebeurden automatisch. Door in-memory configuraties te gebruiken in plaats van appsettings.json, bleven de tests licht en flexibel.
Hij liet zien hoe belangrijk het is om logs direct in de testoutput te tonen, zodat fouten beter traceerbaar zijn. Daarna ging hij verder met meer geavanceerde scenario’s: authenticatie en externe API-calls. In plaats van auth uit te schakelen, introduceerde hij een TestJWT provider voor gecontroleerde tokens. Voor externe API’s gebruikte hij fakes — eenvoudige singleton-klassen die de complexiteit laag houden maar de logica realistisch nabootsen.
Zelfs Razor Pages kwamen voorbij: een test die de HTML-output controleert om te verifiëren dat de juiste data wordt weergegeven. De kern van zijn verhaal bleef overeind: test het systeem zoals het echt draait.
Aan het einde sloot hij af met een duidelijke boodschap:

“Stop aiming for the testing diamond — embrace integration tests. They’re slower, yes, but they give you confidence that your system actually works.”

Debugging Like a Coach: Fixing Team Bugs Before They Crash the Game — Amber Vanderburg

Amber Vanderburg opende haar sessie niet met code, maar met mensen. Haar stelling: de moeilijkste bugs in een organisatie zitten niet in de software — ze zitten in de teams. En zoals elke goede coach weet, los je die niet op met een snelle fix, maar met dialoog, reflectie en vertrouwen.
Ze gebruikte het beeld van debugging teams like code: analyseren, begrijpen, verbeteren. Haar structuur was eenvoudig maar krachtig: Fix. Improve. New. Niet alles hoeft direct opgelost, maar elk gesprek kan leiden tot verbetering.
De kern van haar verhaal kwam voort uit The Five Dysfunctions of a Team van Patrick Lencioni — met vertrouwen als absolute basis. Zonder vertrouwen beweegt niets. Ze gaf een grappig voorbeeld: “If I say I trust Amber to be late, that’s not trust — that’s experience.” Vertrouwen gaat over voorspelbaarheid, openheid en het nakomen van beloften.
In internationale of silo-gedreven teams is dat vaak een uitdaging. Eén persoon met vertrouwenissues kan al frictie veroorzaken. Amber liet zien hoe je dat kunt “mappen”: wie vertrouwt wie en waar stokt de samenwerking? Ze verwees naar het boek The Speed of Trust — hoe meer vertrouwen, hoe sneller teams leren en presteren.
Daarna introduceerde ze het What–Why–Alternative–Follow-up-model voor gesprekken. Richt je niet op wat iemand fout deed, maar waarom dat gedrag ontstaat, wat het effect is en welke alternatieven beter werken. Cruciaal: plan altijd een follow-up. Zonder consistentie vervliegt verandering.
Wanneer iets niet werkt, zei ze, flip the script. Stel andere vragen. Vraag niet: “Waarom ben je niet meer als Henry?”, maar: “Help me begrijpen waarom je deze keuze maakt.” Goede vragen nodigen uit tot reflectie — slechte vragen sluiten de deur.
Amber benadrukte ook de fear of conflict — een klassieke valkuil. Teams die conflicten vermijden, verliezen innovatie. Ze benoemde verschillende reacties: ontkennen, klagen, of de schuld bij een ander leggen. Maar echte groei vraagt candor — openheid met empathie. “Speak with courage, but also with care.”
Ze liet zien hoe je gesprekken kunt “debuggen”: kijk naar je sociale scripts. Als iemand zegt: “I’m fine,” vraag door. Misschien betekent dat eigenlijk: “I don’t feel supported.” Combineer de persoonlijke behoefte met de praktische noodzaak.
Een belangrijk punt ging over de kracht van pauze. “Don’t erase the empathy statement. Wait for it.” Een korte stilte van twee seconden na “I understand you” maakt ruimte voor echtheid. Ze noemde dit de power in pause.
In het tweede deel ging ze dieper in op leiderschap. “What would a good developer do? What would a good leader do?” — dat zijn de vragen die teams zichzelf dagelijks moeten stellen. Vermijd generieke vragen; luister om te begrijpen, niet om te antwoorden.
Ze sprak ook over process trust: het verschil tussen frustratie en overweldiging. Teams die vier processen gebruiken voor één verandering verliezen vertrouwen. Combineer feiten met gevoelens, want beide sturen gedrag.
Tenslotte: flipping the script op teamniveau. Mensen met sterke meningen die niet durven spreken, teams die politiek zijn geworden — je kunt ze helpen door ruimte te maken, bijvoorbeeld via anonieme feedback of timeboxed discussies.
Amber sloot af met een persoonlijk inzicht: grote teams werken alleen als mensen zichzelf overstijgen. “The greatest teams are made of people who build something bigger than themselves.”

React: The Most Common State Mistakes in 2025 — Cory House

Cory House begon zijn sessie met een quote van schrijver William Gibson: “The future is already here — it’s just not evenly distributed.” Dat gold volgens hem ook voor React. Terwijl sommige teams al met React 19, Server Components en lokale databases werken, worstelen anderen nog met dezelfde stateproblemen als in 2015.
Zijn talk was een reis door tien jaar React-state management — van de eerste componentDidMount() tot de nieuwste server features — met één duidelijke boodschap: de meeste fouten komen niet door de tools, maar door verkeerde keuzes in waar je state beheert.

Van componentDidMount tot React Query

Cory liet zien hoe data fetching in React zich heeft ontwikkeld.

• 2014: Alles gebeurde in componentDidMount().
• 2019: Met hooks verplaatsten we logica naar useEffect(), maar daarmee kwamen ook veel nieuwe problemen: over-fetching, dubbele requests en te veel boilerplate.
• 2020: Custom hooks brachten herbruikbaarheid — useFetch, useUser enz. — maar nog steeds was er veel code nodig.
• 2021: Enter React Query (nu TanStack Query). Een derde van de projecten gebruikt het inmiddels. Het introduceerde query keys, caching en mutations — allemaal gericht op minder boilerplate en betere performance.

Hij legde het principe stale-while-revalidate uit: data wordt eerst uit cache getoond en daarna ververst — een balans tussen snelheid en actualiteit.

React verandert de regels

Vanaf React 18 en 19 werd de manier waarop we state en data beheren opnieuw uitgevonden:

• 2022: useErrorBoundary — fouten worden automatisch afgehandeld.
• 2023: useSuspense voor data fetching — minder handmatige loading– en errorstates nodig.
• 2024: React Server Components — server-side rendering zonder extra fetch-calls aan de clientkant. Data wordt gestreamd als HTML en libraries als Moment.js blijven op de server.

Cory’s advies: “Try it when you can — it’s not the future, it’s already usable.”

2025 en verder: Local-first apps

De nieuwste trend volgens hem is local-first computing. Met tools als TanStack DB draait je database deels in de browser, in een aparte thread. Daardoor blijft je app bruikbaar bij trage of wegvallende verbindingen.
“Every app is a conflict resolution problem,” zei Cory — en lokale databases lossen dat op door synchronisatie en caching slim te combineren.

De 30 manieren om state te beheren

Cory toonde een dia met de titel: “There are 30 ways to handle state in React.”
Dat klinkt als een grap, maar het punt was serieus: er zijn véél lagen van state en de meeste fouten ontstaan doordat ze door elkaar worden gehaald.
Hij onderscheidde onder andere:

• URL state: zoals filters of sortering — deelbaar via link.
• Web storage: localStorage, sessionStorage, of IndexedDB.
• Local state: enkel binnen een component.
• Lifted state: gedeeld tussen componenten via een common parent.
• Derived state: berekende waarden, zoals fullName uit firstName + lastName.
• Refs: handig voor undo-functionaliteit of imperatieve logica.
• Context: voor globale settings zoals taal of dark mode.
• Remote state: data van een server, vaak met React Query of SWR.

Zijn advies: “Pick the lowest level that works. Don’t lift state unless you have to.”

Veelgemaakte fouten

Een paar veelvoorkomende problemen die hij noemde:

• Prop drilling: data die te diep doorgegeven wordt.
• Derived state in useState: dubbele bronnen van waarheid.
• Niet valideren van API-data: gebruik tools als Zod voor runtime-validatie.
• Overmatig global state management: niet alles hoort in Redux, Context of Zustand.

React 19 en de toekomst

Tot slot gaf Cory een vooruitblik op React 19 en wat hij “the good enough mindset” noemde:
gebruik de nieuwste tools waar ze waarde toevoegen, maar vermijd shiny-object-syndroom.
React 19 introduceert o.a. Action State voor formulieren — een manier om pending states, optimistic UI’s en fouten af te handelen zonder extra libraries.
Zijn voorbeeld: bij het verzenden van een formulier kun je direct een optimistic update tonen — alsof de actie geslaagd is — en pas terugrollen als er een fout optreedt. “Great UX assumes success, but gracefully handles failure.”

Conclusie

Cory sloot af met de boodschap dat state management in React minder gaat om syntax en meer om mentaal model.
Begrijp wáár je state hoort, hoe je het deelt en hoe je het valideert — dan maakt het niet uit of je Redux, React Query of een simpele hook gebruikt.
Of zoals hij het samenvatte:

“Managing state is like managing people — if you keep it local when you can, everything runs smoother.”

Fortifying your Workflows: Battle-Tested Security Strategies for Hardening GitHub Actions – Josh Johanning

Josh opende met een simpele maar ontnuchterende constatering: CI/CD workflows zijn nu een van de favoriete aanvalsvectors van kwaadwillenden — en GitHub Actions staat middenin het strijdtoneel. Zijn sessie was praktisch, direct en zat vol voorbeelden uit echte incidenten en best practices die je morgen kunt invoeren.

Waarom GitHub Actions hardenen / versterken?

Met meer dan 29.000 open-source Actions in de marketplace en workflows die arbitrary code uitvoeren, ontstaan er veel risico’s: onbedoelde privilege-escalatie, gelekte secrets, of build-servers die als springplank gebruikt worden voor grotere aanvallen. Josh verwees naar bekende supply-chain incidents, waaronder:

• tj-actions/changed-files (2025) – gehackte Action via malicious commit en re-tagging, die secrets stal via pull_request_target.
• Nx “s1ngularity” Attack (2025) – npm-token lek leidde tot besmette packages die crypto-wallets stalen.
• Shai-Hulud Worm (2025) – zelfreplicerend npm-worm die GitHub en npm tokens misbruikte.
• SolarWinds (2020) – buildserver-compromis met gesigneerde malware.

De zwakste schakel is niet je code, maar je supply chain. Vertrouwen en automatisering verhogen risico’s — en met AI-promptinjection komen daar nieuwe dreigingen bij.

Begin met minimale rechten: permissions & tokens

Vanaf februari 2023 heeft GitHub de default repository-permissies verlaagd naar read-only voor nieuwe orgs en enterprises, maar oudere repos behouden nog steeds read/write!
Josh benadrukte dat je permissies per job moet specificeren, niet op workflow-niveau, zodat alleen noodzakelijke stappen schrijfrechten krijgen.

Secrets en authenticatie

Er zijn drie strategieën:

1. GitHub secrets store – makkelijk, maar minder schaalbaar.
2. Extern (Azure Key Vault / HashiCorp Vault) – veiliger en beter auditbaar via OIDC (OpenID Connect).
3. Hybride aanpak – centrale Vault als bron, met geautomatiseerde sync naar repo-secrets.

Belangrijke tips:

• Gebruik geen gestructureerde data (zoals JSON) als secret.
• Mask dynamisch aangemaakte secrets in logs.
• Automatiseer rotatie en gebruik least-privilege credentials.

OIDC in plaats van long-lived tokens

Met OIDC kan je cloudtoegang regelen zonder tokens op te slaan of te roteren — authenticatie wordt door het externe platform afgehandeld.
Josh demonstreerde dit met Azure AD federated credentials en liet zien hoe je zelfs kunt afdwingen dat alleen goedgekeurde reusable workflows toegang krijgen tot productieomgevingen.
Ook npm schakelt over: klassieke long-lived tokens zijn uitgefaseerd, standaard expiratietijd is teruggebracht naar 7 dagen.
Gebruik OIDC + 2FA voor npm-publicaties om supply-chain risico’s te verkleinen.

Bouwketen integriteit: tags, SHAs en signing

GitHub Actions worden meestal gepubliceerd via Git-tags — en tags zijn mutable. Daardoor kon de tj-actions/changed-files hack duizenden repositories treffen.
Josh benadrukte:

• Pin altijd op commit SHA.
• Gebruik dependabot.yml om automatisch updates te blijven ontvangen.

Sinds augustus 2025 kun je zelfs SHA-pinning afdwingen als enterprise policy.

Immutable releases

In private preview (aug 2025) introduceerde GitHub Immutable Releases, waarmee assets, tags en attestaties cryptografisch worden vastgezet.

• Immutable assets kunnen niet meer aangepast of verwijderd worden.
• Tags zijn beschermd tegen force pushes.
• Releases worden automatisch ondertekend (attestation signing).

Josh toonde live dat force pushing of tag deletion wordt geblokkeerd zodra immutable releases aanstaan.

Script injection & OSS-beveiliging

Net als bij SQL-injectie geldt: gebruikersinput is onbetrouwbaar. Issue-titels, branch-namen of comments kunnen misbruikt worden in inline scripts.
Mitigaties:

• Gebruik Actions met input-parameters in plaats van inline run: scripts.
• Zet userinput eerst in environment-variabelen (env:).
• Beperk token-permissies strikt.

Algemene aanbevelingen

• Gebruik CODEOWNERS of rulesets voor workflowwijzigingen.
• Zet OpenSSF Scorecard Action in om supply-chain hygiene te meten.
• Vermijd pull_request_target — vooral in publieke repos.
• Stel een allow-list in van goedgekeurde Actions (liefst “as code” met automatische validatie).
• Gebruik aparte workflows voor PR-validatie versus productie-CD.

Scan vroeg, scan vaak: CodeQL, Dependabot, Secret scanning

Josh liet zien hoe CodeQL + Copilot Autofix kwetsbaarheden automatisch detecteren én suggesties geven, zoals:

• Ontbrekende permissions-blokken.
• Ongepinde tags.
• Kwetsbare versies van Actions.
• Script injection via gebruikersinput.

CodeQL is gratis voor openbare repos en je kunt security findings organiseren via security campaigns — waarbij Copilot Autofix automatisch patches voorstelt.
Dependabot Security Alerts is ook gratis en detecteert kwetsbare Actions via de GitHub Advisory Database.

Attestations: bewijs van herkomst

Attestations zijn het moderne alternatief voor traditionele code signing.
Ze registreren cryptografisch waar en door wie een artefact is gebouwd en worden automatisch vastgelegd in GitHub Actions via OIDC-signing.
Zo kan downstream-softwareverificatie plaatsvinden zonder extra tooling.

Beheer zelf-gehoste runners verstandig

Josh benadrukte opnieuw het SolarWinds-voorbeeld: treat build servers as production.
Gebruik GitHub-hosted runners als veilige default — die zijn:

• Ephemeral (nieuw image per job)
• Network-isolated
• Volledig vernietigd na afloop van de job

Voor self-hosted runners:

• Gebruik Actions Runner Controller (ARC) of Terraform-templates om ephemeral gedrag na te bootsen.
• Scheid build- en release-runners.
• Geef nooit productie-netwerktoegang.
• Disable repo-level runners om exfiltratie te voorkomen.
• Cache enkel tools, geen gevoelige data.

Praktische checklist

• Zet default repository permissions op minimaal (read-only).
• Pin alle 3rd-party Actions op commit SHA.
• Gebruik OIDC in plaats van long-lived secrets.
• Forceer commit signing en gebruik immutable releases.
• Automatiseer scans (CodeQL, Dependabot, secret scanning).
• Houd een Actions allow-list bij.
• Scheid workflows voor PR’s en releases.
• Beperk en isoleer self-hosted runners.
• Automatiseer tokenrotatie.

Tot slot

Josh sloot af met een realistische maar optimistische boodschap:

“De dreiging is reëel, maar de meeste mitigaties zijn laagdrempelig. Met een paar aanpassingen aan permissies, secrets en scans kun je je CI/CD-pijplijn aanzienlijk weerbaarder maken.”

Trusted. Respected. Heard. – Alice Meredith

Alice begon haar sessie met een glimlach en een waarschuwing: “Invloed begint niet bij je functietitel, maar bij je gedrag.” Ze maakt Pluralsight traningen en reist de wereld rond met haar Human Firewall Tour — waarin ze mensen leert om sterk, eerlijk en empathisch te communiceren binnen organisaties.

De essentie: invloed is gedrag, niet positie

Alice stelde een simpele vraag:

“Wie heeft hier invloed?”
Iedereen keek naar de leidinggevenden — maar volgens haar hebben ook juniors, stagiairs en specialisten invloed. Niet omdat ze macht hebben, maar omdat ze vertrouwen, respect en geloofwaardigheid opbouwen door hun gedrag.

Ze gebruikte het model A-B-C+:

• Authority – formele macht,
• Behaviour – hoe je handelt,
• Consequences – de resultaten die je gedrag oplevert,

Invloed is dus geen status, maar een reeks keuzes die je dagelijks maakt.

Word een persoon van eer (honor)

Echte invloed begint bij integriteit.

“Eén oneervolle actie kan jaren van vertrouwen vernietigen.”

Alice deelde haar persoonlijke “Honor Code” — vijf gedragingen die het fundament vormen voor geloofwaardigheid:

1. Speak the truth , zelfs als het ongemakkelijk is.
2. Act with follow-through – laat je daden overeenkomen met je woorden.
3. Avoid gossip , want roddel ondermijnt vertrouwen.
4. Give credit , want het verheffen van anderen vergroot je eigen invloed.
5. Stand firm , blijf trouw aan je waarden, ook onder druk.

Ze vertelde over teams die uit elkaar vielen door kleine, herhaalde overtredingen van deze ongeschreven regels — en over hoe herstel begint bij eerlijkheid.

Bouw diep vertrouwen – ga van “shallow” naar “deep water”

De meeste werkrelaties blijven aan de oppervlakte: vriendelijk, maar oppervlakkig.

“Shallow water feels safe. Deep water feels risky. But that’s where real connection lives.”

Echte invloed vraagt om kwetsbaarheid. Alice moedigde het publiek aan om de eerste stap te zetten:
– deel je fouten,
– vraag actief naar ervaringen van anderen,
– en wees nieuwsgierig in plaats van oordeelend.
Ze gebruikte de metafoor van het private pool vs open ocean:

• In je private pool voel je je comfortabel met bekenden.
• In de open oceaan ontmoet je nieuwe mensen, ideeën, perspectieven — daar groeit invloed.

Tijdens rondetafels en meetings, zei ze, moeten we bewust “deep water” betreden:
anderen uitnodigen die anders denken, niet alleen wie we al vertrouwen.

Emotionele intelligentie is belangrijker dan cv’s

Alice verwees naar onderzoek bij CEO’s: bij sollicitaties draait het zelden om technische skills, maar om emotionele intelligentie.
Wie zichzelf én anderen begrijpt, beïnvloedt effectiever.
Ze onderscheidde:

• Private awareness – weten wat er in jou omgaat.
• Public awareness – bewust zijn van wat anderen zien en voelen.

Wanneer die twee in balans zijn, word je betrouwbaar én menselijk.
Een voorbeeld: iemand die na een stressvol gesprek zegt “Geef me even tijd om te ontladen” toont bewustzijn — en voorkomt dat emoties onbedoeld richting anderen overslaan.

Inclusie als moreel kompas

“Be the one.”
De ene persoon die groet in de lift.
Die zegt: “Hé Tom, ik heb je al een tijdje niet gehoord.”
Die een stil persoon uitnodigt om iets te delen.

In een drukke corporate wereld waarin mensen vaak “te druk” zijn voor echte verbinding, is bewust inclusief gedrag revolutionair.
Alice noemde inclusie “the reset button for humanity”.
Ze moedigde aan om actief uit je bubbel te stappen: praat met mensen die anders denken, andere rollen of achtergronden hebben.

Feedback en herframing

Het laatste stuk ging het over feedbackcultuur. Negatieve feedback roept vaak defensie op — maar door reframing kun je dezelfde boodschap constructiever brengen.
In plaats van: “Je luistert nooit”, zeg:

“Ik merk dat ik moeite heb om mijn punt te maken. Kunnen we even stilstaan bij hoe we dit gesprek voeren?”

Ze noemde dit “Flipping the script” — de vaardigheid om feedback te geven met empathie, waardoor de ander open blijft.

Kernboodschap

Echte invloed begint niet bij positie , maar bij eer, vertrouwen, authenticiteit en inclusie.

“You don’t need a title to lead.
You just need the courage to be trusted, respected, and heard.”

Lessons from the Fast Lane – Robert Doornbos

De closing keynote van de conferentie werd gegeven door niemand minder dan Robert Doornbos , oud-Formule 1-coureur en tegenwoordig analist en ondernemer. Zijn verhaal was niet zomaar een verzameling anekdotes uit de racewereld — het was een kijkje achter de schermen van een hypercompetitieve sport waarin samenwerking, data en innovatie het verschil maken tussen winnen en uitvallen.

F1 is de ultieme teamsport

Hoewel veel mensen Formule 1 zien als een individuele sport, benadrukte Doornbos dat een F1-team draait op teamwork.
Een modern Red Bull-team bestaat uit ruim 600 mensen , waarvan 120 meereizen naar de 24 races per jaar — verspreid over de hele wereld, goed voor meer dan 1500 reiskilometers per seizoen.

“Een coureur staat op het podium, maar zonder het team is hij nergens.”

Van de monteurs tot de data-analisten, iedereen werkt synchroon samen om één doel te bereiken: de snelste zijn. Elke fractie van een seconde telt.

Innovatie en data: het hart van de snelheid

Formule 1 is net zo goed technologie als sport. Elke auto is uitgerust met meer dan 300 sensoren die continu data verzamelen: temperatuur, bandenslijtage, brandstofverbruik, aerodynamica enzovoort.
Die data stroomt naar gigantische IT-hubs op het circuit én naar het hoofdkwartier van het team. De communicatie moet realtime zijn, want elke vertraging in dataverkeer kan miljoenen kosten.

“Het is een partnerschap van data. Zonder meten geen winnen.”

Simulaties en windtunnels

Hij vertelde hoe belangrijk simulaties tegenwoordig zijn in F1. Coureurs rijden duizenden virtuele kilometers per week in een simulator van 12 miljoen euro — maar, voegde hij met een glimlach toe, “je kunt het gevoel van G-krachten nooit simuleren.”
Ook windtunnels spelen nog steeds een sleutelrol.
Al sinds de jaren dertig wordt aerodynamica getest in windtunnels — eerst voor vliegtuigen, later voor racewagens.

“Waar vliegtuigen lift creëren, creëren wij downforce — genoeg om een auto ondersteboven tegen het plafond te laten rijden.”

De kunst van de pitstop

Doornbos noemde de pitstop het perfecte voorbeeld van menselijke efficiëntie onder extreme druk.
Een compleet bandenwissel — door een team van twintig mensen — gebeurt in gemiddeld 1,8 seconden.

“Dat is pure choreografie. Elk teamlid weet exact wat zijn taak is, geen twijfel, geen ego, alleen perfectie.”

Hij gebruikte het als metafoor voor organisaties:

“In een goed team weet iedereen zijn rol en vertrouwt men elkaar blind. Dat is hoe je onder druk presteert.”

De toekomst: elektrificatie en veiligheid

Formule 1 is constant in beweging. Waar vroeger de V10- en V8-motoren domineerden, zijn moderne wagens hybride power units: een samenspel van verbrandingsmotor en elektrische systemen.
Ook veiligheid is enorm verbeterd — dankzij jarenlange innovaties die later hun weg vinden naar gewone wegauto’s.

“Alles wat we in F1 leren over veiligheid, vindt uiteindelijk z’n weg naar de straat.”

Lessen uit de racebaan

Doornbos sloot af met een krachtige boodschap die net zo goed geldt voor technologie, business en persoonlijke groei:

“Als alles onder controle lijkt, ga je niet snel genoeg.”

Hij bedoelde daarmee dat echte vooruitgang ontstaat aan de rand van comfort — waar risico, lef en teamwork samenkomen.
Fouten horen erbij, maar zonder ambitie, experiment en durf komt niemand op pole position.

Takeaways uit de Fast Lane

1. Data is pas waardevol als je er actie op onderneemt.
2. Snelheid komt van vertrouwen, niet van chaos.
3. Simuleren is goed, maar echte ervaring blijft onmisbaar.
4. Perfectie is teamwork – niet ego.
5. Durf gas te geven, ook als je het nog niet volledig onder controle hebt.

Conclusie — Techorama 2025

Techorama 2025 bewees opnieuw waarom het een van de meest toonaangevende techconferenties van de Benelux is.
Drie dagen lang stond innovatie centraal: van diepgaande sessies over AI-integratie en cloud-native architecturen tot inspirerende keynotes over leiderschap, creativiteit en de toekomst van softwareontwikkeling.

Wat vooral opviel, was de balans tussen technologie en menselijkheid. Sprekers benadrukten niet alleen de kracht van nieuwe tools en frameworks, maar ook het belang van samenwerking, ethiek en een gezonde techcultuur. De rode draad? Technologie ontwikkelt zich razendsnel, maar de kern blijft: mensen die met passie bouwen, leren en delen.

Of je nu kwam voor de nieuwste inzichten in .NET, DevOps, data, of design systems — Techorama 2025 bood iets voor iedereen. En terwijl we naar huis gingen met volle notitieboeken en nog vollere hoofden, bleef één gedachte hangen: de toekomst van technologie is niet iets dat ons overkomt, maar iets wat we samen vormgeven.

Tot volgend jaar — waar we elkaar opnieuw uitdagen, inspireren en verbinden.

Op Techorama 2024 werden inzichten gedeeld over actuele thema’s binnen de IT en softwareontwikkeling. Deze blog is
geschreven voor IT professionals. In dit blog bespreken we enkele hoogtepunten, waaronder Michaël Hompus’
performance-optimalisaties in C#, Steve Smith’s toepassing van Domain-Driven Design (DDD) om complexiteit te
verminderen, en Michael Kaufmann’s uitleg over cybersecurity en Zero Trust voor ontwikkelaars. Daarnaast belichtte Amber
Vanderburg het belang van teamdynamiek en besluitvorming. Van ethisch hacken tot geautomatiseerd testen, deze sessies
bieden waardevolle kennis voor softwareontwikkelaars die veilige, efficiënte en schaalbare systemen willen bouwen.

In deze blog geef ik een samenvatting van de verschillende sessies:

“Learn to Say ‘No!’ Without Being a Jerk” door Christina Aldan:

Deze sessie richt zich op het belang van het stellen van grenzen zonder onbeleefd over te komen. Het behandelt waarom
mensen moeite hebben om “nee” te zeggen, vaak door angsten zoals het missen van kansen (FOMO), oordeel van anderen,
of niet goed genoeg zijn.

Belangrijke punten:

• Grenzen stellen: Definieer tijd, fysieke, mentale en materiële grenzen om je eigen welzijn te waarborgen en
  overbelasting te voorkomen.
• Non-negotiable waarden: Leer wat je kernwaarden zijn en gebruik deze als basis om grenzen te stellen.
• Overcommitment vermijden: Zeg niet automatisch “ja” tegen alles, omdat dit kan leiden tot stress, burn-out, en
  verminderde productiviteit.
• Communicatie van grenzen: Er zijn manieren om vriendelijk en respectvol “nee” te zeggen, zoals het voorstellen
  van alternatieven of het aangeven dat het niet in je agenda past.

Strategieën:

• Blokkeer tijd: Hou je aan je planning, inclusief pauzes.
• Onderzoek verplichtingsgevoelens: Vraag jezelf af of je “ja” zegt uit verplichting of omdat het echt nodig is.
• Maak van “ja” een weloverwogen keuze: Denk na over wat er nodig is om er volmondig “ja” op te zeggen.
• Oefen in het zeggen van nee: Door regelmatig te oefenen, wordt het makkelijker om grenzen te stellen.
• Beslis en wees duidelijk: Sta achter je besluit en blijf bij je nee.

Praktische tips: Gebruik specifieke zinnen om je grenzen duidelijk te maken zonder bot over te komen, zoals “Dit past
helaas niet in mijn agenda” of “Ik kan het nu niet, maar wellicht in de toekomst.”

“SIMD, Vectorization – What It Means and How to Do It in .NET” door Jiří Činčura:

Deze sessie bespreekt SIMD (Single Instruction Multiple Data) en vectorisatie in de context van .NET, waarbij de
focus ligt op prestatie-optimalisatie van CPU-gebaseerde verwerking. SIMD maakt het mogelijk om met één instructie
meerdere datapunten tegelijk te verwerken, wat vooral nuttig is voor wiskundige en wetenschappelijke toepassingen
die veel rekenkracht vereisen.

Belangrijke punten:

• SIMD en prestatieverbeteringen: SIMD kan worden gebruikt om CPU-prestaties te verbeteren door meerdere
  datapunten tegelijkertijd te verwerken.
• Vectorisatie: Moderne CPU’s hebben vector-units waarmee ze grotere hoeveelheden gegevens tegelijk kunnen
  verwerken.
• Simulatie en overhead: Hoewel SIMD snelheidswinst kan opleveren, introduceert het ook overhead, vooral bij
  kleine datasets.
• Visual Studio en benchmarking: Tools zoals Visual Studio helpen bij het meten en optimaliseren van
  SIMD-implementaties.

Praktische toepassingen:

• SIMD is krachtig voor wetenschappelijke simulaties, fysische modellen, en geavanceerde wiskundige berekeningen.

Limitaties:

• SIMD werkt goed in sommige scenario’s, zoals CPU’s in Azure VM’s, maar biedt niet altijd voordelen in elke
  omgeving.
• Het stroomverbruik kan stijgen door intensieve vectorisatie, wat de CPU-prestaties beïnvloedt.

“EQ in Tech” door Amber Vanderburg

Deze sessie draait om het ontwikkelen van emotionele intelligentie (EQ) in de technologiesector en hoe dit invloed
heeft op samenwerking, leiderschap en persoonlijke groei.

Belangrijke punten:

• EQ als spier: Emotionele intelligentie is een vaardigheid die je kunt ontwikkelen, net zoals een spier.
• Waarden en zelfbewustzijn: Het begrijpen van je kernwaarden is cruciaal voor het reguleren van emoties.
• Zelfreflectie en zelfpraat: Positieve zelfpraat helpt bij het herstructureren van negatieve ervaringen en
  emoties.
• Empathisch luisteren: Actief luisteren met aandacht voor intentie en emotie is essentieel.
• Pauzeren voor inzicht: Pauzes tijdens gesprekken zijn krachtig en verminderen misverstanden.

Praktische strategieën:

• Zelfbewustzijn ontwikkelen: Herken je triggers en leer hoe je erop reageert.
• Grenzen stellen: Het is belangrijk om gezonde grenzen te stellen in relaties.
• Modelleer positieve EQ: Inspireer anderen door zelf een voorbeeld te zijn van goede EQ.

De sessie benadrukt dat het ontwikkelen van emotionele intelligentie niet alleen je werkprestaties verbetert, maar ook
een positieve invloed heeft op de samenwerking en de algehele sfeer binnen teams.

“Multitenancy in ASP.NET Core: Challenges and Approaches” door Marco De Sanctis

Deze sessie richt zich op de uitdagingen en benaderingen van het implementeren van multitenancy in ASP.NET Core, met
een focus op SaaS-platforms en het beheren van verschillende huurders.

Belangrijke uitdagingen:

• Data-isolatie: Het scheiden van gegevens tussen verschillende huurders is cruciaal.
• Kosten en complexiteit: Het beheren van meerdere databases of schema’s voor verschillende huurders kan
  operationeel complex en kostbaar zijn.
• Custom domains: Bedrijven kunnen hun eigen domeinen gebruiken voor toegang tot het platform.
• SSO (Single Sign-On): Bedrijven willen hun bestaande identiteitsproviders gebruiken om SSO te implementeren.

Oplossingen:

1. Data-isolatiestrategieën:
• Gescheiden databases: Elke tenant heeft zijn eigen database, wat volledige isolatie biedt maar operationele
  overhead veroorzaakt.
• Gescheiden schema’s: Een enkele database met verschillende schema’s voor elke tenant, wat minder overhead
  heeft dan aparte databases, maar nog steeds isolatie biedt.
• Discriminatiekolommen: Een enkele database met een “company ID” om gegevens van verschillende huurders te
  filteren. Dit kan worden gecombineerd met SQL Server’s Row-Level Security om toegang per tenant te regelen.
2. Enterprise SSO: Gebruik van identiteitsproviders zoals Azure AD B2C of Auth0 om SSO mogelijk te maken, waarbij
   elke tenant zijn eigen login-stroom kan hebben. Configuraties zoals client ID, client secret, en metadata URL’s
   worden beheerd voor elke tenant.
3. Domeinbeheer: Door DNS-zones en aangepaste domeinen in Azure App Services op te zetten, kan elk bedrijf een
   eigen domein hebben waarmee het toegang krijgt tot het platform.
4. Toegang en beveiliging: Het gebruik van token-gebaseerde beveiliging (bijv. JWT-tokens verrijkt met claims)
   zorgt ervoor dat de toegang goed wordt beheerd en kan worden aangepast voor specifieke tenants.

Deze sessie geeft inzicht in verschillende multitenancy-strategieën en hoe je ervoor kunt zorgen dat SaaS-platforms
schaalbaar en veilig blijven, terwijl ze voldoen aan de behoeften van verschillende bedrijven (tenants).

“Making the Web More Accessible for Everyone” door Jarne Van Aerde:

Jarne begon de sessie met een voorbeeld van zijn oma die moeite had met het lezen van kleinere tekst op websites, wat
het belang van toegankelijke webontwerpen benadrukte. Kleine verbeteringen kunnen een groot verschil maken voor
gebruikers met beperkingen.
Kernpunten van toegankelijkheid (A11y):

• Toegankelijkheid is nuttig voor iedereen, maar essentieel voor sommigen: Slechte toegang kan variëren van
  tijdelijke situaties (zoals fel zonlicht op een scherm) tot permanente beperkingen (bijv. slechtziendheid).

• Microsoft’s inclusieve ontwerpbenadering: Dit betekent dat ontwerp moet voorzien in een breed scala aan
  gebruikersbehoeften, van visuele, auditieve, motorische en cognitieve beperkingen.

Regels en richtlijnen:

• WCAG 2.0 (Web Content Accessibility Guidelines): Deze richtlijnen helpen ontwikkelaars websites toegankelijker
  te maken. Ze bestaan uit drie niveaus van naleving: A (essentieel), AA (gewenst) en AAA (optioneel).
• Semantiek en ARIA (Accessible Rich Internet Applications): Semantisch correcte HTML-tags en ARIA-labels zijn
  essentieel om extra context aan schermlezers te geven. Het gebruik van correcte elementen, zoals een
  <button> in plaats van een <div>, kan de toegankelijkheid verbeteren.

Demo’s en implementatie:

• Voorbeelden van slechte semantiek: Het gebruik van onjuiste HTML-tags zoals een <div> voor een knop of
  link kan navigatie en gebruik met schermlezers bemoeilijken.
• ARIA-labels en -rollen: Deze helpen schermlezers om te begrijpen wat een element doet en geven extra context.
  Bijvoorbeeld, een “volgende maand” knop in een datumkiezer kan aria-live-attributen gebruiken om veranderingen
  aan te kondigen.

User Experience (UX):

• UX moet toegankelijk zijn voor iedereen: Visuele indicatoren zoals een focusstaat op interactieve elementen,
  voldoende contrast, en het gebruik van de escape-toets om modals te sluiten zijn essentieel.
• Visuele en toetsenbordnavigatie: Het is belangrijk om interactieve elementen goed zichtbaar te maken voor
  mensen die alleen een toetsenbord gebruiken.

Testen en toekomst:

• Testen van toegankelijkheid: Handmatige tests met schermlezers (zoals JAWS, NVDA en VoiceOver) zijn belangrijk,
  maar er zijn ook automatische tools zoals Lighthouse en Accessibility Insights die basisfouten opsporen.
• Toekomst van toegankelijkheid: Hoewel AI kan helpen bij sommige taken zoals het genereren van
  audio-beschrijvingen, kunnen complexe toegankelijkheidsproblemen nog niet volledig worden opgelost door AI.

Conclusie: Toegankelijkheid begint met kleine stappen, zoals semantiek verbeteren en contrast verhogen. Het vraagt om
voortdurende inspanning en testing om websites voor iedereen bruikbaar te maken.

“C# Language Internals – 25th Anniversary” door Bart De Smet:

Deze sessie besprak de interne ontwikkelingen en evoluties van de C#-taal gedurende de afgelopen 25 jaar. Bart De Smet
belichtte verschillende versies van C# en de nieuwe functies die elk heeft geïntroduceerd, evenals de uitdagingen en
oplossingen die deze verbeteringen met zich meebrachten.

Kernpunten van de sessie:

1. Async Streams en State Machines:
• De sessie begon met een bespreking van async streams en asynchrone enumeratie, waarbij state machines een
  cruciale rol spelen bij het verwerken van asynchrone methoden.
• De rol van custom task builders en hoe deze helpen bij het efficiënt beheren van async workflows kwam ook
  aan bod. Het concept van boxing (het omzetten van een value type naar een object) werd besproken, wat
  prestaties kan beïnvloeden.
2. C# 9 en 10 Functies:
• C# 9:
• Covariant return types: Dit maakt het mogelijk om in een afgeleide klasse een sterkere return type te
  gebruiken dan in de basis klasse, wat handig is voor complexere overerving.
• Record types: Deze bieden een elegante manier om immutable types te creëren zonder veel boilerplate
  code. Functies zoals automatische constructors, ToString, en Equals worden hierbij gratis meegeleverd.
• C# 10:
• Async method builders en het gebruik van custom task builders werden verder toegelicht.
3. C# 11 en 12 Functies:
• C# 11: Introduceerde het concept van required members, waarbij bepaalde eigenschappen verplicht moeten
  worden ingesteld, wat nuttig kan zijn bij het afdwingen van consistentie in object-initialisatie.
• C# 12: Besprak verbeteringen aan lambda-expressies, zoals het omkeren van return types en het ondersteunen
  van meer flexibele aanroepen, die het werken met delegate types eenvoudiger maken.

De sessie gaf een goed overzicht van hoe de C#-taal zich heeft ontwikkeld, met focus op efficiëntie, flexibiliteit, en
leesbaarheid van code.

“A Season for Speed: Turning Puzzles into C# Performance Wins” door Michaël Hompus

In deze sessie bespreekt Michaël Hompus hoe je de prestaties van C#-code kunt verbeteren door het oplossen van
puzzels, gebaseerd op zijn ervaring met de Advent of Code-uitdaging. Deze puzzels bieden een platform om te
experimenteren met optimalisaties en verschillende technieken in C# voor betere performance.

Belangrijkste punten:

1. Advent of Code:
   • Een jaarlijks programmeerevenement gedurende 25 dagen voor Kerstmis. Elke dag komt een nieuwe puzzel met
     unieke input en twee delen die de deelnemers proberen op te lossen.
   • Michaël gebruikte C# om deze puzzels op te lossen en verbeterde de prestaties van zijn oplossingen door
     benchmarks te gebruiken.
2. Performance meten:
   • Stopwatch bleek niet nauwkeurig genoeg om op microsecondenniveau te meten. Daarom werd BenchmarkDotNet
     gebruikt voor gedetailleerdere prestatiemetingen.
   • Het optimaliseren van code kan eenvoudig starten met het vervangen van LINQ met andere methoden zoals
     for-loops, omdat LINQ soms trager is door het gebruik van abstracties.
3. Optimalisatietechnieken:
   • Michaël toonde aan hoe simd en vector optimalisaties prestaties tot 25% kunnen verbeteren.
   • Door gebruik te maken van while-loops in plaats van for-loops werd nog meer snelheid gewonnen, met name
     voor CPU-intensieve taken.
   • Goto-statements kunnen soms nuttig zijn om snel uit een lus te springen, maar moeten voorzichtig worden
     gebruikt.
4. Geavanceerde optimalisaties:
   • Pointer-gebaseerde oplossingen en het gebruik van Unsafe code kunnen soms prestaties verbeteren, hoewel
     ze riskant zijn door hun complexiteit en potentieel gevaarlijke gevolgen.
   • Bit-array optimalisatie: Door geheugen op een efficiëntere manier te gebruiken met bitarrays, kan je
     grote prestatieverbeteringen realiseren, vooral bij herhalende bewerkingen.
5. Praktische voorbeelden:
   • Gebruik van Span<T> voor beter geheugenbeheer.
   • Het vermijden van overbodige initialisaties en optimaliseren van char-verwerking.
   • Geoptimaliseerde algoritmes zoals Dijkstra’s algoritme kunnen significant sneller zijn, vooral bij
     specifieke input.

Conclusie: Het is cruciaal om altijd je code te meten om de impact van je optimalisaties te bepalen. Soms kunnen
kleine aanpassingen grote prestatieverbeteringen opleveren, maar te veel optimaliseren kan ook leiden tot
complexiteit zonder veel extra winst.

“DDD’s Application Building Blocks” door Steve Smith

In deze sessie legt Steve Smith de basisprincipes van Domain-Driven Design (DDD) uit, geïnspireerd door Eric Evans’
werk, en hoe het helpt bij het aanpakken van complexiteit in softwareontwikkeling. De focus ligt op het organiseren
van code in blokken die overeenkomen met domeinen en contexten binnen een applicatie om complexiteit beheersbaar te
houden.

Belangrijkste concepten:

1. Complexiteit verminderen:
   • Softwareontwikkelaars kunnen maar een beperkt aantal dingen tegelijk in hun hoofd houden (5-7 items),
     waardoor het essentieel is om problemen in kleinere stukjes te verdelen.
   • DDD biedt bouwblokken die helpen om dit te organiseren door het domein en de oplossingsruimte op te
     splitsen in verschillende contexten.
2. Domeinen en Bounded Contexts:
   • Het domein is de probleemruimte; het bevat de kernactiviteiten en subdomeinen van een organisatie.
   • Bounded Context is de oplossingsruimte; het is een afgebakende scope waarin bepaalde domeinconcepten
     gelden. Binnen deze context worden concepten en modellen expliciet gedefinieerd en geïsoleerd om
     conflicten te vermijden.
   • Overlapping van contexten moet worden voorkomen omdat dit tot complexiteit en miscommunicatie kan
     leiden.
3. Encapsulatie en grenzen:
   • Encapsulatie binnen bounded contexts zorgt ervoor dat de interne implementatie privé blijft, en dat
     alleen een publieke interface beschikbaar is voor interactie.
   • API’s en contracten (zoals DTO’s) fungeren als publieke interfaces voor communicatie tussen
     verschillende contexten.
4. Aggregaten en entiteiten:
   • Aggregates zijn objecten die samenhangen en die een consistente reeks regels of invarianties afdwingen.
     Ze voorkomen dat geldige staten van het systeem worden geschonden, zoals het maximum aantal lijnitems in
     een order.
   • Entities zijn objecten met een unieke identiteit binnen de bounded context. Ze encapsuleren regels en
     logica en zorgen ervoor dat bepaalde voorwaarden worden afgedwongen, zoals positieve hoeveelheden voor
     orderlijnen.
5. Value Objects:
   • Value Objects zijn objecten die geen identiteit hebben en alleen worden vergeleken op basis van hun
     waarden. Ze zijn immutabel en worden vaak gebruikt om complexe types op een duidelijke en veilige manier
     te modelleren.
   • Ze voorkomen het bestaan van ongeldige staten in het systeem, doordat ze vanaf het moment van creatie
     correct zijn gedefinieerd en niet gewijzigd kunnen worden.
6. Primitive Obsession en validatie:
   • Primitive Obsession is een code-smell waarbij basistypes zoals int of string te veel worden gebruikt
     zonder dat er specifieke domeinregels worden afgedwongen. DDD raadt aan om aangepaste types te gebruiken
     die domeinspecifieke validatie en logica encapsuleren.
7. Modules en microservices:
   • Bounded Contexts kunnen worden gemoduleerd in microservices of in een modulaire monoliet, afhankelijk
     van de behoeften. Microservices kunnen echter leiden tot complexiteit en moeten zorgvuldig worden
     gebruikt.
   • Anti-corruptielagen worden gebruikt om contexten te beschermen tegen ongewenste invloeden van buitenaf
     door het vertalen van externe gegevens naar het interne model.

Conclusie: DDD biedt een reeks patronen en bouwblokken om software op een gestructureerde manier te ontwerpen,
waardoor complexiteit beheersbaar wordt. Door gebruik te maken van bounded contexts, aggregaten, entiteiten en value
objects, kunnen ontwikkelaars hun systemen robuuster en onderhoudsvriendelijker maken.

Security 101: A Beginner’s Guide to Cybersecurity and Zero Trust for Developers

In deze sessie gaf Michael Kaufmann een uitgebreide inleiding in cybersecurity en het concept van Zero Trust,
speciaal gericht op ontwikkelaars. Hij behandelde de basisprincipes van beveiliging, de meest voorkomende
bedreigingen, en belangrijke best practices voor het beveiligen van applicaties en infrastructuren.

Kernpunten van de sessie:

1. Cybersecurity Basics:
   • Cyberaanvallen veroorzaken jaarlijks aanzienlijke financiële schade.
   • Het CIA-model (Confidentiality, Integrity, Availability) vormt de kern van beveiliging, met als doel
     ongeautoriseerde toegang te voorkomen en de vertrouwelijkheid, integriteit en beschikbaarheid van
     systemen te waarborgen.
   • Hackers gebruiken technieken zoals phishing, malware (ransomware, virussen, worms), DoS/DDOS-aanvallen,
     en SQL-injecties om systemen binnen te dringen.
2. Phishing en Social Engineering:
   • Phishing is een veelvoorkomende aanvalsvector waarbij kwaadwillenden zich voordoen als betrouwbare
     partijen om informatie te stelen. Dit gebeurt vaak via e-mails en websites.
   • Social engineering speelt in op menselijke zwakheden, waarbij aanvallers bijvoorbeeld informatie
     ontfutselen via misleidende telefoontjes of social media.
3. Zero Trust Architecture:
   • Bij Zero Trust wordt er vanuit gegaan dat elk systeem of elke gebruiker een potentiële dreiging kan
     zijn. Alles moet dus worden geverifieerd, ongeacht of het zich binnen of buiten het netwerk bevindt.
   • Kernprincipes zijn: Identity Verification, Least Privilege Access, en Continuous Monitoring. Het doel is
     om segmentatie te creëren en alleen de nodige toegang te verlenen.
4. IAM en MFA:
   • Identity and Access Management (IAM) beheert gebruikersidentiteiten en toegang tot systemen, gebaseerd
     op rollen en privileges (Role-Based Access Control – RBAC).
   • Multi-Factor Authentication (MFA) biedt een extra beveiligingslaag door het gebruik van meerdere
     verificatiemethoden, zoals wachtwoorden en biometrie.
5. Encryptie en netwerken:
   • Beveiliging op netwerklaag omvat technieken zoals firewalls, VPN’s, DDoS-bescherming, en encryptie
     (symmetrisch en asymmetrisch).
   • Encryptie beschermt gegevens door ze onleesbaar te maken voor onbevoegden.
6. Security Operations en Incident Management:
   • Security Information and Event Management (SIEM) en Security Operations Centers (SOC) spelen een
     cruciale rol in het monitoren en reageren op beveiligingsincidenten.
   • Teams zoals Red Team en Blue Team worden ingezet om aanvallen te simuleren en verdedigingen te
     versterken.
7. Application Security en SDLC:
   • Ontwikkelaars moeten secure by design denken, waarbij beveiliging in elke stap van de
     software-ontwikkelingslevenscyclus (SDLC) is ingebouwd.
   • Het is essentieel om te werken met inputvalidatie, output encoding, sessiebeheer, en
     afhankelijkheidsbeveiliging.
8. Testing Tools en Beveiliging van de Software Supply Chain:
   • Tools zoals SonarQube, OWASP ZAP, Burp Suite, en Checkmarx helpen bij het identificeren van
     kwetsbaarheden tijdens het ontwikkelen van software (SAST/DAST).
   • Dependabot en Anchore helpen bij het beheren van afhankelijkheden en het beveiligen van de supply chain
     door automatische updates en scans.
9. DevSecOps en Shift Left:
   • Shift Left beveelt aan om beveiliging vroeg in de ontwikkelcyclus op te nemen, zodat
     beveiligingsproblemen sneller worden ontdekt en verholpen.
   • Automatisering in de pipeline is cruciaal voor een veilige DevOps-aanpak.

Conclusie:

Beveiliging is een continu proces, en Zero Trust en IAM zijn fundamenteel voor een robuuste beveiliging.
Ontwikkelaars moeten hun applicaties vanaf het begin beveiligen, gebruik maken van geautomatiseerde tools, en op de
hoogte blijven van de nieuwste bedreigingen en technieken.

Conclusie: Cybersecurity is essentieel voor alle ontwikkelaars, ongeacht hun ervaring. Het implementeren van Zero
Trust, en het toepassen van basisprincipes zoals het CIA-model en least privilege, helpen bij het beveiligen van
moderne applicaties en systemen tegen aanvallen.

Strategies for Influencing your Team/Organization door Amber Vanderburg

Amber begon met een oefening om een bloem in de kamer te vinden, wat diende als metafoor voor het herkennen van
invloed en relaties in ons dagelijks werk en persoonlijke leven. Ze benadrukte dat relaties en invloed belangrijk
zijn om te begrijpen, omdat we vaak mogelijkheden missen door niet actief te beïnvloeden of te investeren in
relaties.

Kernpunten:

1. Systeem 1- en Systeem 2-denken (Kahneman):
   • Systeem 1 is snel, intuïtief en foutgevoelig. Dit type denken wordt gebruikt voor snelle beslissingen,
     zoals kleine wijzigingen in UI/UX of bugfixes.
   • Systeem 2 is langzamer en bewuster, gebruikt voor complexe beslissingen en grondige analyses, zoals het
     aanpakken van complexe problemen in een project.
2. Invloed uitoefenen:
   • Invloed is niet alleen gebaseerd op expertise, maar ook op relaties en vertrouwen. Bouw sterke relaties
     door eerlijk te zijn, respect te tonen en consistent te handelen.
   • Identificeer wie je moet beïnvloeden (bijvoorbeeld een product owner of belangrijke stakeholders), en
     bedenk wat voor hen belangrijk is.
   • Gebruik mentale shortcuts (heuristieken) om snel invloed te krijgen, zoals door vertrouwen op te bouwen
     en sterke eerste indrukken te maken.
3. Systeem 1-acties voor snelle invloed:
   • Kleine, snel uitvoerbare acties, zoals bugfixes of het veranderen van een kleurschema, kunnen snel
     invloed hebben.
   • Focus op eenvoudige ideeën en presenteer ze op een manier die cognitief gemakkelijk te verwerken is.
4. Systeem 2-acties voor langdurige invloed:
   • Voor complexe beslissingen is een meer doordachte, op data gebaseerde aanpak nodig. Hier is het
     belangrijk om risico’s in kaart te brengen, opties af te wegen, en feedback te verzamelen.
   • Het is cruciaal om fouten te erkennen en te leren van feedback.
5. Framing en communicatie:
   • Gebruik positieve framing om je ideeën te presenteren. Begin met “Waarom”, dan “Hoe”, en eindig met
     “Wat” (Golden Circle van Simon Sinek).
   • Benadruk voordelen en resultaten in plaats van alleen functies, zodat je verhaal relevant en overtuigend
     is.
6. Building Trust:
   • Vertrouwen is essentieel voor invloed. Dit kan worden bereikt door consistent eerlijk te zijn, respect
     te tonen en verantwoording af te leggen. Laat zien dat je de belangen van je collega’s en stakeholders
     serieus neemt.
7. Heuristieken en cognitieve biases:
   • Maak gebruik van beschikbaarheidsbias (recente gebeurtenissen worden zwaarder gewogen) en andere
     cognitieve biases om je argumenten effectiever te maken. Verbind complexe concepten aan concrete,
     herkenbare voorbeelden.
8. Invloed vergroten met storytelling:
   • Verhalen zijn krachtige tools om invloed te vergroten, vooral wanneer je complexe of technische ideeën
     moet overbrengen naar een niet-technisch publiek. Gebruik relatable analogieën en voorbeelden.
9. Stap-voor-stap aanpak:
   • Breek grote doelen op in kleinere, haalbare stappen. Dit maakt het gemakkelijker voor anderen om in te
     stemmen met jouw plannen en voorkomt dat ze zich overweldigd voelen.
10. Cultureel bewustzijn en reflectie:
    • Wees je bewust van culturele verschillen binnen teams en bedrijven, en pas je communicatie en
      beïnvloedingsstrategieën hierop aan. Ruimte geven voor reflectie en dialoog kan helpen om een meer
      inclusieve besluitvorming te stimuleren.

Amber sloot af met het belang van zowel groot durven dromen als samenwerken om die dromen te verwezenlijken. Door
invloed stap voor stap te bouwen en relaties te versterken, kun je zowel in systeem 1 als systeem 2 een effectieve
leider zijn.

Belangrijke boodschap:

Begin klein, bouw vertrouwen, en gebruik invloed om je team en stakeholders mee te krijgen in jouw visie.

Getting started with Ethical Hacking door Christian Peeters

Deze sessie, gericht op ontwikkelaars die training geven, behandelt verschillende aspecten van hacking en
beveiliging, met een nadruk op kwetsbaarheden, sociale engineering en best practices om systemen te beveiligen.

Kernpunten:

1. Hacking en kwetsbaarheden:
   • Hacking omvat het exploiteren van kwetsbaarheden in systemen om toegang te krijgen en deze toegang te
     behouden. Hackers gebruiken technieken zoals het scannen van netwerken en het identificeren van open
     poorten om binnen te dringen.
   • Een typisch hackproces bestaat uit vijf stappen: toegang krijgen, toegang behouden, sporen wissen, en
     het verbergen van de aanwezigheid binnen een systeem.
2. Sociale engineering:
   • Sociale engineering is een belangrijke methode die hackers gebruiken om informatie van mensen te
     verkrijgen. Dit kan variëren van phishing-e-mails tot het bellen van medewerkers en zich voordoen als
     een leidinggevende.
   • Voorbeelden werden gegeven van phishing-aanvallen waarbij een hacker zich voordoet als een CEO, wat
     resulteerde in aanzienlijke financiële verliezen voor bedrijven.
3. WiFi-veiligheid:
   • Onbeveiligde netwerken (zoals open WiFi-netwerken) zijn een gemakkelijke toegangspoort voor hackers.
     Encryptiemethoden zoals WEP en WPA moeten zorgvuldig worden gebruikt.
   • Hackers kunnen technieken gebruiken zoals Wireshark om netwerkverkeer te monitoren of
     Pineapple-apparaten om onveilige netwerken te creëren en gegevens te onderscheppen.
4. Kwetsbaarheden in software:
   • De presentatie verwijst naar de OWASP Top 10, die veelvoorkomende kwetsbaarheden in webapplicaties
     identificeert, zoals:
     • Broken access controls
     • Onveilige configuraties
     • SQL-injecties (bijv. 1=1)
     • Cross-Site Scripting (XSS)
   • Het belang van het bijhouden van updates voor softwarepakketten en libraries (zoals npm en NuGet) werd
     benadrukt, evenals het gebruik van CVE-lijsten (Common Vulnerabilities and Exposures).
5. Beveiligingstools:
   • Er werd een overzicht gegeven van verschillende beveiligingstools, waaronder:
     • Burp Suite en OWASP ZAP voor webapplicatietests
     • Metasploit voor penetratietests
     • Hydra voor brute-force-aanvallen
     • DVWA (Damn Vulnerable Web Application) en WebGoat voor training in beveiligingskwetsbaarheden
6. Best practices voor beveiliging:
   • Het belang van “patchen” (het regelmatig bijwerken van software om kwetsbaarheden te verhelpen) en het
     verkrijgen van schriftelijke toestemming voor penetratietests werd benadrukt.
   • Gebruik maken van beveiligingsprotocollen en -standaarden om systemen te beschermen tegen aanvallen.
7. Vertrouwen en kwetsbaarheid:
   • De spreker benadrukte dat je niemand moet vertrouwen, en dat het cruciaal is om voorzichtig om te gaan
     met gevoelige informatie, zowel in softwareontwikkeling als in persoonlijke interacties.
   • Een sterk beveiligingsbeleid en een cultuur van waakzaamheid zijn essentieel om aanvallen te voorkomen.

Belangrijke boodschap:

De sessie benadrukte dat het van vitaal belang is voor ontwikkelaars om niet alleen bewust te zijn van de
technologische aspecten van beveiliging, maar ook van de menselijke factor. Training en bewustwording van sociale
engineeringtechnieken zijn cruciaal om te voorkomen dat individuen en organisaties slachtoffer worden van aanvallen.

Cypress, Playwright or Selenium: choosing the right testing tool

Deze sessie richtte zich op verschillende soorten testen in softwareontwikkeling, met een specifieke focus op
end-to-end (E2E) testing en de tools die beschikbaar zijn voor geautomatiseerd testen.

Kernpunten:

1. Houding ten opzichte van testen:
   • De spreker gaf aan dat ze niet van testen houden, mogelijk door eerdere negatieve ervaringen of
     trauma’s.
   • Ondanks deze gevoelens is het belangrijk om verschillende soorten testen te verkennen om de kwaliteit
     van de software te waarborgen.
2. Soorten testen:
   • Functionele en prestatie testen: Essentieel om ervoor te zorgen dat de software correct functioneert en
     voldoet aan de prestatienormen.
   • Automated UI Testing: Dit omvat het testen van de gebruikersinterface om ervoor te zorgen dat deze
     functioneel is na wijzigingen in de code (regressietests).
   • End-to-End Testing: Dit type testen simuleert echte gebruikersinteracties met de applicatie en
     controleert of alle componenten goed samenwerken.
3. Testtools:
   • Selenium: Geïntroduceerd in 2004 door Jason Huggins, het is een van de meest populaire open-source
     testtools. Selenium WebDriver kan verschillende browsers aansturen en ondersteunt meerdere
     programmeertalen. Het heeft een grote community, maar heeft enkele nadelen zoals trage uitvoering, flaky
     tests, en complexe configuratie.
   • Cypress: Gelanceerd in 2014, is Cypress een moderne testtool die speciaal is ontworpen voor
     JavaScript-ontwikkelaars. Het biedt een uitstekende gebruikerservaring door automatisch te wachten op
     elementen en duidelijke foutmeldingen te geven. Nadelen zijn onder andere de noodzaak van extra plug-ins
     voor sommige functionaliteiten en beperkte browserondersteuning.
   • Playwright: Geïntroduceerd in 2019, is Playwright ontwikkeld door de makers van Puppeteer en ondersteunt
     meerdere browsers, inclusief headless browsers en mobiele applicaties. Het heeft een groeiende
     populariteit, maar wordt soms als complexer en minder intuïtief ervaren, met een kleinere community.
4. Vergelijking van tools:
   • Cypress vs. Selenium: Cypress biedt een betere ontwikkelaarservaring, maar is beperkt tot JavaScript,
     terwijl Selenium veelzijdiger is maar een complexere setup vereist.
   • Playwright vs. Cypress: Playwright biedt ondersteuning voor meer browsers en heeft mogelijkheden voor
     mobile testing, maar de API is complexer en minder gebruiksvriendelijk.
5. Conclusie:
   • Cypress en Playwright zijn beide populaire keuzes voor E2E testing, met een groeiende acceptatie in de
     softwaregemeenschap. Hun gebruik zal waarschijnlijk toenemen naarmate de vraag naar geautomatiseerd
     testen blijft stijgen.

Belangrijke boodschap:

Het is cruciaal voor ontwikkelaars om de juiste testtools te kiezen die aansluiten bij hun specifieke behoeften en de
technologieën die ze gebruiken. Het gebruik van de juiste tools kan de kwaliteit van de software aanzienlijk
verbeteren en bijdragen aan een betere gebruikerservaring.

Conclusie van deze blog

Deze blog biedt een overzicht van diverse sessies die elk belangrijke inzichten delen over onderwerpen variërend van
ethisch hacken en multitenancy tot emotionele intelligentie en prestatieoptimalisatie in C#. De rode draad door alle
sessies is het belang van bewustwording en strategie, zowel op technisch vlak als in persoonlijke groei en samenwerking.