Op 9 april 2026 was ik weer aanwezig bij DEVCAMPNOORD, georganiseerd door dotNetNoord in de Kinepolis bioscoop in Groningen. Vorig jaar ben ik hier voor het eerst geweest, het waren toen boeiende presentaties, dus redelijk vroeg een (gratis) kaartje gekocht voor deze editie.
Ook dit jaar rijdt het verkeer prima door, om 8.30 uur vertrokken, om 9.15 uur staat mijn auto in de parkeergarage. De inloop is tussen 9.00 en 10.00 uur, mooi op tijd dus. Binnengekomen kun je je jas ophangen, krijg je jouw badge met je naam en een goodie-bag. Ook dat is altijd goed geregeld. Hierna naar de eerste verdieping, tijd voor koffie! Hier staan stands van de sponsors, dus als je een praatje wilt maken (of bijvoorbeeld in de race-simulator een rondje op Zandvoort wilt rijden), dat kan. Iets voor 10.00 uur loop ik naar zaal 7, hier wordt de keynote gehouden, deze is voor alle aanwezigen.
We horen hier dat de boel "uitverkocht" is, geweldig. Want dat betekent ook dat alle tijd en moeite die de organisatie in dit evenement investeert niet voor niets is. Mijn enige aantekening hierbij is dat de bezoekers voor het grootste deel 30+ zijn. Het zou mooi zijn dat er ook een wat jonger publiek naar dit evenement komt. De "startende generatie", die misschien nog aan het studeren is en zo in contact kan komen met verschillende organisaties waar ze kunnen stagelopen, afstuderen of aan het werk kunnen gaan. Uit ervaring met de drumband weet ik: als er geen jeugd meer is, dan stopt de club. Hier moeten we misschien nog wel eens wat mee doen. Ik zal erover nadenken of ik hier ook een bijdrage aan kan leveren.
Rethinking the Possible - Breaking Free with AI door Marcel de Vries
De keynote, met een volle zaal. Waarbij ik ook nog mijn oud-klasgenoot Remco Wolters tegenkom. Deze presentatie wordt gegeven door Marcel de Vries, zijn eigen site kun je bekijken op fluentbytes.com. Marcel is Managing Director en CTO van Xebia. Hij komt voor zijn werk veel in het Midden-Oosten en ziet dat ze daar "veel meer" voorop lopen met AI. Marcel laat ons de voorbeelden uit het verleden zien. Hoe een team ontwikkelaars op het trage internet laat zien hoe een webshop eruit kan zien en de directie van Sears (een soort Wehkamp) zegt: 'dat online kopen/verkopen wordt helemaal niets'. Amazon begint wel met de online verkoop. Amazon is een miljardenbedrijf, Sears is al een aantal jaren failliet. Netflix verkocht DVD's via het internet, zagen het potentieel van online streaming en is nu één van de leidende partijen. Marcel raadt aan om eens de film Blackberry te bekijken. Nadat de iPhone op de markt kwam, was het einde van de blackberry nabij...
Dat "nieuwe techniek" vaak door directie, mensen die de beslissingen nemen afgeserveerd worden komt vaak door "bias", een bepaalde voor ingenomenheid. We zien een overzicht met cartoons van verschillende types zoals loss aversion - bang om zaken te verliezen - dus blijven hangen in het oude.
Dankzij ChatGPT is de ontwikkeling van AI in een stroomversnelling gekomen. Opus Claude 4.6 is inmiddels zo sterk, waar bij een bedrijf 25 PR's aangemaakt werden, zijn dat er inmiddels 250.
Volgens Marcel is een succesvol bedrijf een bedrijf waar developers met coding agents hun werk doen, waar je eerst een team van 10 developers hebt, kun je nu 5 teams met 2 developers en agents opzetten. Marcel laat ook de tool met de meest coole naam ever zien: Get Shit Done. Dit is een CLI voor Claude. Ook heb je OpenClaw, dat was iets wat ik vroeger in gedachten had, een soort "online butler die taken voor je doet". Maar zoals met alles: ben je bereid om je creditcard aan een stuk AI te geven en daar acties mee uit te laten voeren? Met het risico dat je niet 10 rollen toiletpapier bestelt, maar 10 pallets en er de volgende dag dus een vrachtwagen voor je voordeur staat?
Na de pauze gaat mijn collega Jeroen naar de sessie over "OAuth". Ik had het idee dat daar wat algemene zaken besproken zouden worden (blijkt later ook zo te zijn), dus ik heb voor een andere sessie gekozen.
Building a solid foundation on Azure: Landing Zones best-practises, door Erwin Staal
Redelijk recent is mijn andere Jeroen-collega bij een sessie geweest waar gesproken werd over Landing Zones, dat is ook de reden dat ik voor deze sessie gekozen heb: misschien levert het nog wat meer inzichten op.
Je hebt verschillende landingzones. Zo heb je een platform landingzone, waar je gedeelde services plaatst. De "applicaties" zijn de application landingzones. Er wordt soms ook wel over hubs en spokes gesproken, de hub is dan de platform landingzone, de spoke is de application landingzone. Je kunt de landingzones op meerdere plaatsen instellen, de voorkeur gaat uit om dit op subscription-niveau te doen en niet op resourcegroup-niveau. Je zit daar namelijk met bepaalde beperkingen/limieten, je hebt een beter schaalbaar model. Ook voor de facturering maak je het jezelf makkelijker. Het idee hierachter is het Microsoft Cloud Adoption Framework for Azure. De definitie die Erwin aan een landingzone geeft is dat het "een omgeving voor het hosten van workloads is, in de Microsoft Azure cloud, welke geprovisioned wordt door code".
Landingzones gebruik je om zaken duidelijk van elkaar te kunnen scheiden. Om snel nieuwe omgevingen op te spinnen, zodat het development-team bijna instant een omgeving heeft waarop gewerkt kan worden. Omdat je inzicht hebt in de kosten en de CO2 impact van elke workload. Je consistent je security-policies toepast en bijwerkt. Een standaard platform landingzone bestaat vaak uit een 3-tal management-groepen, de Connectivity Management Group (je application gateway, je WAF, VPN, DNS VNet), de Identity Management Group (je domaincontroller(s)), de Management Management Group (nee, geen copy-paste foutje, je Azure Keyvault, Log Analytics Workspace, Sentinel). Ik meende dat Erwin noemde dat er ook nog wel eens een 4e management-groep is, dat was volgens mij de "de-commisioned management group". Zaken die je opzegt blijven nog 90 dagen beschikbaar. Maar die zou je eigenlijk niet meer moeten gebruiken. Door ze in een eigen managementgroup te zetten, weet je wat je daarmee moet doen.
Bij de application zone heb je een management group per subscription (bijvoorbeeld Production en NON-Production). Zo'n management group bestaat uit 2 resource groepen, waarin de ene de Key Vault, Vnet en Log Analytics Workspace. In de andere RG zitten de VM, App Service, SQL Database en Storage.
We zien hoe je met Role Based Access Control via code aan kunt geven waar iemand wel (of niet) rechten op heeft. met actions '*' en een node notActions die bijvoorbeeld dit bevat: Microsoft.Authorization/*/write, Microsoft.Network/publicIPAddresses/write, Microsoft.network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action.
Hierna nog een overzicht van de verschillende netwerken, de centrale hub met de gekoppelde spokes, een mesh-netwerk (waar alles met elkaar verbonden is), en een hub met spokes opzet, waarbij spokes ook rechtstreeks met elkaar kunnen communiceren.
Hierna volgt de lunch. Aansluiten in de rij, veel keuze qua lekkere broodjes! Ik ga voor het broodje tonijnsalade en het broodje kroket.
Building your own MCP server, Stuart van der Lee
In de sessie van Marcel de Vries had Marcel volgens mij al gezegd "dat je MCP niet moet bouwen als een Swagger API". Dus Stuart verontschuldigt zich voor deze presentatie, want daar wordt het eigenlijk wel op deze manier gedaan. Wat hij laat zien is dus ook meer om te laten zien "wat er mogelijk is", maar niet "hoe je het zou moeten doen". Wat op zich wel jammer is, want na de presentatie heb je eigenlijk de vraag "en hoe moet het dan wel?". Ook in deze presentatie komt die uitspraak van Microsoft Build nog voorbij "Your API is not an MCP", hier het YouTube-fragment.
De indruk die je van deze presentatie krijg is eigenlijk dat het opbouwen van een eigen MCP server "een fluitje van een cent is". MCP is uitgebracht in november 2024, in december 2025 is het aangesloten bij de Linux Foundation. Als je wilt starten, een kwestie van naar modelcontextprotocol.io surfen.
De componenten van MCP:
- Tools (kunnen data naar database wegschrijven, externe API's aanroepen, bestanden aanpassen), een voorbeeld is de vraag "plan deze afspraak in, zoek naar vluchten naar Barcelona". Het model controleert deze actie.
- Resources (passieve documenten, API documentatie, read-only toegang toe bepaalde zaken), een voorbeeld is dat de knowledge base geraadpleegd wordt, kalenders uitgelezen worden. De applicatie controleert deze actie.
- Prompts (de instructies om duidelijk te maken welke tools en resources gebruikt kunnen/mogen worden). Voorbeelden zijn "maak een samenvatting van mijn vergaderingen". De gebruiker controleert deze acties.
We zien de code waarbij in de Program.cs je een builder.Services.AddMcpServer() aangeroepen wordt, vervolgens ook nog een .WithStdioServerTransport(), .WithToolsFromAssembly(), .WithPromptsFromAssembly(), .WithResourcesFromAssembly().
Met attributen in je code bij een class aangeven wat het type is. Zo zien we [McpServerToolType] en in een functie GetEmployees() heb je het attribuut [McpServerTool(Name="GetEmployees")] en [Description("Gets a list of employees. Optionally takes a limit of the number of employees to return")].
We zien in de .vscode map een bestand mcp.json waarin staat dat met dotnet de server opgestart wordt.
Ook laat Stuart zien dat hij in zijn user-settings nog een algemene mcp.json heeft. Daar neem ik nog even een paar mogelijk interessante MCP-servers van over: Github Copilot, Microsoft Learn, Jurrassic Park.
Gluing .NET Aspire Services with Container Apps and DAPR, Eduard Keilholz
Eduard heeft een soort "conferentie-app" gemaakt waarbij je net als bij Tinder kunt swipen, naar die presentatie ga ik wel, naar die niet. In de presentatie op het scherm zien we zijn Aspire set-up, deze slides zijn nog van een chat-app die hij gemaakt heeft. Die kun je hier op Github vinden, binnenkort uitchecken, opstarten en kijken hoe het werkt.
In Visual Studio kun je volgens mij redelijk snel Aspire installeren (vandaag, 12 april, een uitzending van .NET Rocks beluisterd waar ik hoorde dat je dit ook met een CLI kunt doen). Eduard toont ons dat je met winget install Dapr.CLI en dapr init je (dus) Dapr aan je project kunt toevoegen. Bij eerdere conferenties had ik al verhalen over Dapr gehoord, maar ik heb er zelf nog niets mee gedaan. En dat is zonde. Want met Dapr heb je een bepaalde abstractie waardoor je lokaal "service A" kunt gebruiken en als je app in de cloud draait, dan gebruikt ie "service B". Spreaview (een QR-code die getoond wordt om sprekers een rating te geven voor hun presentatie) is ook een project wat door Eduard opgezet is.
Hierna weer een pauze, even bijkomen van al dat zitten. Hoewel je goede stoelen in de bioscoop hebt, begin ik inmiddels een houten kont te krijgen, dus nog maar even een bakje koffie doen dan!
Should you start using spec-driven development?, Maarten van Diemen
Als IT-er zit ik nog wel eens in code "van iemand anders". Om soms te begrijpen wat er gebeurt, wat de laatste wijzigingen geweest zijn, waarom dat gedaan is, dat is niet altijd zo simpel. Als je zelf wel eens door een lijst met commit-messages gebladerd hebt, heb je waarschijnlijk datzelfde gevoel. Dat er "ergens" specificaties zijn met uitleg wat er moet gebeuren, waarom dat moet gebeuren en wat er gedaan is, dat zou een mooie feature zijn. Dus "spec-driven" klonk mij wel goed in de oren. Het gaat het in deze sessie over SpecKit. Deze specificatie is voor een goede interactie tussen developer en AI. We beginnen met een voorbeeld waarbij er een schatting gedaan wordt hoe lang iets duurt om te bouwen, in het ene geval zonder AI, in het andere geval met AI. Uiteindelijk wordt gekeken wat het resultaat is. De tijd om te bouwen zonder AI is redelijk correct ingeschat. Maar het bouwen met AI blijkt hier langer te duren (bron van dit onderzoek).
Dan volgt een item van Martin Fowler (uncle Bob). Op deze pagina heeft hij linkjes naar verschillende zaken over LLM's/AI. We zien het schema van de verschillende spec-driven types. Spec first: specificaties worden uitgewerkt door developer en AI, gebouwd en daarna wordt de spec weggegooid. Spec-anchored: na oplevering blijft de spec behouden. En de spec-as-a-source, geen menselijke interactie, de specificatie is "de bron" om te bouwen.
Maarten liep tegen wat zaken aan. Zo is Scalar de opvolger van Swagger (hier waren wat conflicten in code?). Je voert het commando "clarify" uit. Maar moet dan opvolgend "please do" of iets dergelijks invoeren om te zorgen dat het ook uitgevoerd wordt. Via het tasks-commando kun je grote taken verkleinen. Je hebt een plan-mode, maar andere developers zeggen "die heeft Claude zelf al". Het is "follow the flow", je moet alle stappen volgen. Voor dit alles verbruik je (veel) meer tokens, bijvoorbeeld omdat je de Ralph-loop volgt, dus er moet ook (extra) betaald worden. Als je iets opgeleverd hebt, maar de klant zegt "oké, maar dan wil ik nu dit of dat..", oftewel, steeds wijzigingen/aanvullingen doet, dan is dit niet de manier om te werken. Met extensies moet je taken valideren (om de zogenaamde phantom completion cases te fixen). AI zegt: ik ben klaar, maar je programma wil niet meer compileren...
Claude komt nog even voorbij, waaronder de bouwer daarvan, Tariq. Het onderdeel askuserquestiontool is het deel wat vraagt om zaken te verduidelijken. Speckit gaat zich richten op custom workflows.
Mocht je niet met Speckit willen werken, dan zijn er alternatieven. Een wiki, Openspec, AgentOS, AutoSpec, SpecKitty (toen het project een tijd stil lag, heeft iemand een fork van Speckit gemaakt en dat SpecKitty genoemd).
De eindconclusie van Maarten is dat "specs niet altijd de oplossing zijn".
Deze presentatie vond ik uiteindelijk niet zo interessant, had ik misschien toch beter die van Jan de Vries over het migreren van je oplossingen naar moderne standaarden kunnen volgen.
De laatste sessie is weer een collectieve sessie: For shits and giggles: building a compiler, Henry Been
Als je de dag mag afsluiten, dan heb je vaak een zaal vol met publiek dat er redelijk doorheen zit. Al die presentaties volgen, je kunt erbij zitten, maar toch is het vermoeiend.
Henry heeft het voor elkaar gekregen om een presentatie te geven die iedereen goed kon volgen. Want "het maken van een compiler", ik weet niet of het nu nog gedaan wordt, maar het maakte onderdeel uit van de opleiding Hogere Informatica waar ik van 1997 tot en met 2001 gestudeerd heb. Het boek staat nog op mijn boekenplank, Modern Compiler Implementation in Java. Een Lexer, een Parser en een Emitter. Uitleg over de "stack machine". En je hebt natuurlijk een "runtime" nodig, een platform wat jouw code kan draaien. Dat was "toen" voornamelijk de Java Virtual Machine (JVM), maar je kunt het nu dus ook met de .NET Runtime doen (wat Henry hier ook doet).
Wat je met je code bouwt is een "abstract syntax tree", een AST. Henry kies voor een LL(1) parser, dus in een "boom" kies je eerst voor links en je kijkt steeds 1 karakter vooruit. Het uitvoeren van die code in die boom (de AST) doe je met het Visitor-pattern (ook die ken ik nog uit mijn studietijd). Henry gebruikt de tool ANTLR. Er zijn tig manieren om ANTLR4 te installeren, maar al die manieren mislukten bij Henry. Dus zijn tip voor ons (mocht je er zelf mee aan de slag willen gaan), installeer python, doe daarna een py -m ensurepip -upgrade en vervolgens een pip install antlr4-tools
Hoewel dit project een "fun-project" is, is er ook een serieuze component. Want je kunt hier best wel veel dingen mee doen. Henry noemt dat je met statische analyse een AST kunt doorlopen en daar ook kunt kijken "op welke plaatsen data van een externe bron wordt gelezen". En ook waar data opgeschoond wordt (sanitized). Hiermee kun je bepalen op welke plaatsen data (dus) niet opgeschoond wordt en waar dat (mogelijk) een probleem zou kunnen veroorzaken. SQL injection, upload van .php bestanden en wat al niet meer.
Kudo's voor Henry, een leuke presentatie! Het inspireert om ook zelf zoiets te gaan doen. Want als "developers" zijn we vaak bezig met ons (betaalde) werk, in mijn geval het doorlezen van Microsoft Learn pagina's voor Fundamentals-certificeringen en zoals nu, het samenvatten van presentaties. Maar "eigenlijk" zou je gewoon met een leuk hobbyproject aan de slag willen gaan, zoiets als je eigen compiler bouwen.
Hierna gaan we naar de begane grond, we nemen een biertje (een mooie Grolsch-beugel!) en krijgen we nog wat versnaperingen, waaronder kaas-bitterballen.
Had ik al gezegd dat devNetNoord hun zaakjes uitstekend geregeld heeft? Complimenten voor deze dag, ik (en ik denk ook de rest van de bezoekers) vond het een zeer geslaagde dag!
Oh ja, 26 november is de volgende editie (ik vermoed weer in het gebouw van de Gasunie?). Zet 'm in je agenda en zorg dat je erbij bent!
One more thing, tijdens de presentaties maak ik foto's, aanvullend op het bovenstaande verslag heb je er misschien wat aan. Klik hier om de slides te bekijken!