Ik probeer wat "bij" te komen met de podcasts. Dus ik zit in de flow vanaf nummer 1 nu rond podcast 400. Maar ik begin nu ook met wat recenter materiaal, om mogelijk wat inzichten en tools die "nieuw" zijn in beeld te krijgen.
PC 1961: Event sourcing met Hannes Lowette.
De show begint nog steeds met "better know a framework". Alleen gaat dit niet over het .NET Framework, maar over "computerized" gitaren die gebouwd worden (en die niemand wil kopen). Hierbij verwijst Carl naar dit artikel (uit 2012). Richard leest een e-mail voor, het bedankje is niet de swag zoals ik die ken (de beker), maar de CD "music to code by", gespeeld en geproduceerd door Carl. Je kunt ze hier ook online kopen voor een kleine 50 dollar. Hannes bespreekt in deze uitzending "event sourcing", een heel interessant onderwerp! Want wij zijn allemaal gewend aan onze tabellen, het normaliseren van data. Zaken niet dubbel opslaan. Maar omdat we dat al zo lang doen, zijn we ook een beetje kwijt welke zaken hierdoor wat minder werken. Want zoals Hannes zegt: "daarin staat de werkelijkheid zoals deze nu is". En dat is ook zo. In de database van de krant sta ik met mijn huidige adres. Maar zou je vragen, waar woonde ik 47 jaar geleden, dan is dat niet te achterhalen.
Met event sourcing kan dat wel. Ook heb je hier geen last van interferentie, bij onze relationele structuur heeft het impact als 5 mensen gelijktijdig in de ordertabel hun data bijwerken en/of toevoegen. Hannes legt uit dat je met een soort "beginsituatie werkt" en elke toevoeging, aanpassing als een event wordt toegevoegd. Dat zorgt er ook voor dat je altijd alles "opnieuw kunt opbouwen" door de hele flow uit te laten voeren/door te lopen. Wel worden hier soms gegevens van weggeschreven in een relationele database, omdat je een weergave wilt (bijvoorbeeld voor rapportage). De vraag van Carl of er ook situaties zijn die nadelig zijn of waar je rekening mee moet houden beantwoordt Hannes met het voorbeeld van een item wat miljoenen events heeft gehad. Als er behoorlijk van zulk soort items zijn en die moet je vanaf 0 laten opbouwen, dat is niet te doen. Daar komen snapshots in beeld, waarbij je bepaalde stappen (de 1 miljoenste stap, de 2 miljoenste stap) vastlegt, zodat je uiteindelijk minder stappen en dus minder lang bezig bent om zaken opnieuw op te bouwen. Ook noemt Hannes de GDPR. Klanten hebben in theorie het recht om vergeten te worden. De werking van event sourcing is dat je daar nooit wat in aanpast. Je kunt geen "events verwijderen", want dan heeft dat mogelijk ook invloed op andere afgeleide zaken.
Hannes merkt ook op dat veel mensen denken dat je hiermee ook het auditing-verhaal afgerond hebt. Dat is niet zo, daar moet je nog wel extra stappen voor uitvoeren. Want bij elk event weet je niet "wie" iets gedaan heeft.
Ook doorlopen we de tools. SQL Server voor de opslag van event sourcing is niet optimaal, Hannes is enthousiast over Postgress, die dit vanaf de start al ondersteunt (en ook nog eens gratis is). Met hun BSON (binaire JSON-formaat), maar ook zo "slim" is om te kunnen indexeren op bepaalde eigenschappen in de JSON-boom, hoe diep dat ook is. Bij een eerdere uitzending zijn die tools ook ter sprake gekomen, dus zo horen we ook nog Wolverine genoemd worden, Critter Stack (wat de combinatie van Wolverine en het Marten Framework is), het Saga pattern en het CQRS pattern. Microsoft heeft ook nog een Event Sourcing Pattern.
Deze aanpak kan soms behoorlijk veel schijfruimte vergen, zoals Carl zegt: dat is geen enkel probleem. Nou, niet als je alles in de cloud doet. Maar als je on-premise hosting hebt, zul je waarschijnlijk eerst wel moeten kijken of dit voor jou haalbaar is, of dat je hiervoor wat anders moet inrichten. De terechte opmerking ook tijdens de uitzending, "niet alles is geschikt om via event sourcing te verwerken". Als je dit gaat implementeren, moet je dit goed voorbereiden. Want het heeft ook impact op je ontwikkeling. Als zaken wegschrijft naar een relationele database, maar later wijzigt die structuur van bepaalde tabellen, kun je dan nog steeds je objecten van 0 opbouwen en hergenereren of moet je daar met versies o.i.d. gaan werken?
PC 1962: Improving legacy applications met Billy Hollis.
Bij "better know a framework" gaat het deze keer wel weer over code. Namelijk over Blazor.inputchips, hier te vinden op Github. Deze uitzending gaat (deels) over legacy applicaties en hoe je die weer "bij kunt brengen" naar de huidige tijd. Onder "legacy" schaart Billy de software die 10 jaar of ouder is.
PC 1963: 30 jaar application security met Michael Howard
In deze uitzending gaat het over security. Carl noemt nog even dat hij ook een podcast over security maakt, securitythisweek. Michael Howerd is actief geweest bij meerdere versies van IIS, zoals hij zelf zegt, werd er veel aan security gedaan (met versie 2, 3,4), maar veilig waren ze niet. In versie 6 werd dat beter, in plaats van dat alle opties "actief" waren, moest je nu expliciet zaken aan zetten. Codenaam van IIS 6 was dan ook niet voor niets "kevlar" :) Michael werkt graag met C#, maar als er zaken zijn die bijvoorbeeld niet over de garbage collection van .NET kunnen (dat is niet deterministisch, voor sommige zaken wil je dat wel), dan codeert hij in RUST. Hij is fan van deze programmeertaal, maar geeft ook aan dat het een moeilijke taal is om te leren. Michael maakt deel uit van het Red Team van Microsoft. Dus er worden nog wat meer zaken besproken. Zo komt de Slammer bug van 2001 langs. Dat was een worm die met een UDP payload SQL Server instanties "plat gooide". Daar komt een correctie op, niet SQL Server (want die waren vaak al gepatched), maar de MSDE, de versie die voor desktop-applicaties gebruikt werd. Ook zat er nog een bug in de worm zelf, waardoor geen even of oneven getallen gebruikt konden worden. Daardoor was een "deel van het internet veilig", omdat ze een even of oneven IP-adres hadden. Op Wikipedia lees ik trouwens dat het in 2003 was. Michael is enthousiast over codeQL van Github, waarmee je code op security-issues kunt scannen. De repository kun je hier bekijken. Richard meldt dat hij een tijdje geleden bij RunAs radio Yuri Diogenes te gast heeft gehad, die heeft een boek geschreven over Cybersecurity - Attack and Defense stategies. Michael zegt meteen dat hij dit "een goed boek vindt", dus binnenkort (waarschijnlijk) maar aanschaffen. Carl noemt bij de commercials de ondersteuning van AWS voor dotnet, op deze URL kun je dat zelf verder uitzoeken.
PC 1964: c# met Dustin Campbell
Bij "better know a framework" komt FusionCache ter sprake. Schijnt een goede codebibliotheek te zijn. Microsoft heeft ook zelf nog de HybridCache codebibliotheek. Richard zijn achternaam is ook Campbell, maar Dustin is geen familie. In deze uitzending gaat het over "nieuwe dingen" in C#14. Zo wordt onder andere Extension members genoemd en null-conditional assignment. Nu snapte ik niet helemaal wat daarmee bedoeld wordt, maar op de pagina van de podcast wordt verwezen naar de Microsoft documentatie. Ook komt ter sprake welke IDE je gebruikt, Visual Studio of Visual Studio Code. met De C# Dev Kit kunnen we al heel veel in Visual Studio Code. Ook Razor Pages komen ter sprake. Bij de shownotes wordt nog verwezen naar Razor Pages in ASP.NET Core. Ook omdat Dustin daarmee bezig is en "er dingen aan komen". Carl geeft aan dat hij niet altijd tevreden is hoe zaken werken in Razor pages. Dustin geeft uitgebreide en interessante uitleg over hoe alles werkt en hoe Roslin daarbij gebruikt kan worden. Ook hoe je niet wilt dat zaken wel in code kunnen, maar in Razor niet. Dat deel van de uitzending is zeker de moeite waard om te beluisteren. En Carl noemt dat in Razor je geen Codelens kunt gebruiken.
PC 1965: Design bij Github met Diana Mounter
Bij "better know a framework" noemt Carl "Awesome Claude code". Dit is een repository voor de AI modellen van Claude op Github (check 'm hier). Omdat ik daar ook steeds meer over hoor, misschien toch eens een kijkje nemen! Diana Mounter is de gast. Op haar website wordt de term "code is a material" gedropt. Dit heeft ze van Rune Madsen, Carl en Richard hebben in de shownotes een link naar de Youtube-video toegevoegd. Ze werkt als designer bij Github, maar heeft ook wel met code gewerkt. Haar website is te bekijken op broccolini.net. Carl vraagt hoe ze erbij komt om zichzelf met de naam van een groente online te presenteren. Daar zit een verhaal achter. In een restaurant zag ze "broccolini" op de menukaart en dacht toen "ze willen broccoli wat meer popie-jopie maken" en plakken er dus -ini achter. Later loopt ze met een vriend door de stad, zijn vriendin werkt in een restaurant, daar moeten ze even heen en daar ziet ze het weer op de menukaart staan en moet ze erom lachen. De vriend vraagt waarom ze lacht en zij zegt: "nou, omdat hier broccolini staat!" en de reactie is dan "ja?". Want... broccolini is gewoon een groente. Zoals je op Wikipedia kunt lezen een kruising van broccoli en een soort kool en pas in de jaren 90 ontstaan. En daardoor noemt iedereen Diana die haar naam vergat "die broccolini-dame". Toen Diana bij Github kwam werken, werkte ze aan het design-system, Primer. Ook komt ter sprake dat bij Github gebruik wordt gemaakt van react, en er is wat gecombineerd met v-components uit Ruby on Rails (want daar draaide Github eerst op). Figma wordt als ontwerptool genoemd (maar door allen ook genoemd, dat dit niet responsive is, dus daar zul je eigen ontwerpen voor moeten maken). Hoe een tijd geleden alles "mobile-first" gemaakt werd. En hoe Diana wel benieuwd is wat de huidige AI-tijd qua design gaat opleveren, vast weer nieuwe bevindingen. Carl noemt bootstrap (dat is een beetje old skool geworden), tailwind en Diana is dan nog actief geweest met Functional CSS. Ook komt Jekyll voorbij, daar heb ik ook ooit wat mee gedaan, perfect voor een statische HTML-site. Als je zelf een design system wilt bouwen, is het misschien handig dat je een blik werpt op deze Github-repo, styled-system. Bij de commercials komen regelmatig AWS zaken voorbij. Omdat ik zelf meer op Azure gericht ben, ben ik niet op de hoogte van de mogelijkheden daar. Carl noemt hier AWS beanstalk. Ook dat misschien eens bekijken.
PC 1966: Devops met Michael Levan
Bij "better know a framework" noemt Carl lottiefiles, dat zijn een soort animated GIFs, site is hier te bekijken. Die moet je ook kunnen afspelen, daarvoor had Carl een soort player voor Blazor op Github gevonden. De uitzending gaat niet alleen over devops, maar ook over security en AI. Zo komt hier voorbij dat hij Claude een stuk code had laten maken, maar waarbij hij later dacht "waarom krijg ik overal dezelfde output?". Toen bleek dat Claude (zonder dat er om gevraagd was) overal mock-data had toegevoegd. Het verwijderen van al die data kostte zoveel tijd, dat Michael de code sneller zelf had kunnen opzetten. Veel zaken gaan fout, omdat er bijvoorbeeld met Kubernetes gewerkt wordt en je allemaal netwerkverkeer van pod naar pod hebt. Maar ontvangt een bepaalde pod ook data die niet voor die pod bedoeld is? Tevens is 75% van de fouten gerelateerd aan foutieve configuratie, developers die "denken" dat iets op een bepaalde manier ingesteld moet worden in Azure maar het niet "zeker weten". Vaak is de vraag nu bij een security-issue, welk risico is groter, het veiligheidsissue (nog) niet fixen, of wel meteen fixen, maar wel met een "fix" waarvan niet bekend is of die weer extra problemen veroorzaakt? Juist omdat gaten in code in de huidige tijd supersnel misbruikt kunnen worden, is de noodzaak om snel fixes uit te brengen ook steeds groter geworden. Er worden nog een paar handige tools gedeeld, zoals Microsoft Security (is alleen voor bedrijven, met je persoonlijke account inloggen geeft een foutmelding), de SBOM-tool van Microsoft, Jaeger (voor je micro-services) en de "good old" Wireshark, waarbij je kunt zien wat voor verkeer er allemaal over jouw netwerk heen gaat en Prometheus voor het monitoren van je systemen. Michael geeft aan dat zodra je als bedrijf door ransomware getroffen wordt, je wel een jaar bezig bent om die klap te boven te komen. Richard heeft wel eens ondersteuning moeten bieden in zo'n geval, de decryptor die het bedrijf kreeg om hun bestanden te ontsleutelen werkte namelijk niet als een bestand groter dan 2 GB was...
PC 1967: Visual Studio met Mads Kristensen
Aan het begin van de uitzending hoor ik iets over dat "Windows ook in een Docker container kan". Mads is de man die veel plug-ins voor Visual Studio gemaakt heeft. Dat wist ik wel, maar ik heb er nooit echt actief op gezocht. Naar aanleiding van deze uitzending dat toch maar even gedaan. Er zijn (natuurlijk) ook onzin plug-ins gemaakt zoals de "Farticus" waarbij je het geluid van een scheet hoort als je oplossing niet meer wil builden ;)
Mads is lovend over de Playwright MCP. En er zijn volgens hem veel zaken verbeterd, waarbij bepaalde clicks op een button op de UI-thread uitgevoerd werden (waardoor je een "hang" of "freeze" krijgt), dat zou beter moeten gaan.
Op de 34e minuut is de commercial van AWS over app to container app
PC 1968: Razor tooling in visual studio met David Wengier
David legt hier uit dat Razor nu met "cohosting" werkt, waar dat eerder via LSP ging. Ook omdat er in Razor 5 talen ondersteund moeten worden (C#, VB, css, HTML en javascript?). Bij die LSP methode werden delen van de code heen en weer gestuurd om te valideren/interpreteren, wat voor vertraging kan zorgen. Nu werkt dit via Roslyn. Interessante uitzending.
PC 1969: Visual Studio Code AI met James Montemagno
Bij "better know a framework" noemt Carl de tool "WebGoat". OWASP onderhoudt deze "onveilige web-applicatie", die bedoeld is ter educatie, om te laten zien wat je "niet moet doen". De moeite waard om eens te bekijken! Deze uitzending was wel interessant om te beluisteren omdat James aan "vibe coding" doet, iets waar ik redelijk sceptisch tegenaan kijk. Hij geeft aan dat dit voor hem heel goed werkt en dat hij er veel meer code/software mee kan opleveren dan als hij dat zelf had moeten doen. Ook bij Carl en Richard is AI steeds meer gespreksonderwerp, dus heeft Carl samen met Jeff een site opgezet met filmpjes, "code it with AI". Zelf gebruik ik CoPilot in Visual Studio Code. Om C# te programmeren in Visual Studio Code heb je de C# Dev Kit nodig (link). Vervolgens ga je naar de site van CoPilot (link) om eerst 30 dagen te testen of het je biedt wat je zoekt. In de show-notes zit een verwijzing naar de stappen voor CoPilot zoals James die ingesteld heeft (link). Ik zie daar op het eerste gezicht niet het nut van, maar het zal wel ergens nodig voor zijn. In ieder geval, het zit in de repo van de feedback-app, dat is de app die James ontwikkeld heeft. Zoals je in een project een README.md hebt voor "mensen", zo heb je ook een tekstbestand voor Agents, de AGENTS.md. In de show-notes wordt ook een directe link gedeeld naar de "coding assistant van ChatGPT": link. Microsoft is bezig met het ontwikkelen van een integratie tussen CoPilot en Azure Boards (link). James heeft een website waar hij actief op blogt: link.
PC 1970: Lokale AI modellen met Joe Finney
Bij "better know a framework" komt ter sprake dat er nu ook een MCP server beschikbaar is voor Unity. Carl zou zelf bezig zijn geweest met een MCP server voor PlayWright. Carl en Richard spreken met Joe Finney over "local ai models". De vrouw van Carl heeft net een nieuwe computer gekocht, dat is een CoPilot plus pc. Je krijgt dan meteen een stuk AI bijgeleverd. Er zit een NPU op (Neural Processing Unit) die voor AI instructies kan uitvoeren. Carl heeft hier wel bepaalde zaken meteen op uit gezet. Zo heb je de functie "recall" die continue screenshots neemt, zodat je over 2 weken de vraag kunt stellen: "wanneer was ik ook alweer met mijn belastingaangifte bezig" en krijg je het antwoord op basis van deze gegevens. Als ik me niet vergis staat deze app trouwens standaard "uit", die moet je actief aan zetten als je het wilt gebruiken. Joe is bezig met Text-Grab, met OCR en AI teksten filteren uit afbeeldingen, check hier de Github-repo. Hij maakt gebruik van Windows ML. Carl noemt ook nog Tesseract, een OCR engine die al jaren bestaat, check de Github-repo. Joe noemt nog een paar andere AI zaken. Kaggle, Hugging Face. Die laatste kende ik wel (door Elastic), je kunt hier allemaal modellen downloaden die je zelf kunt gebruiken. Nu is het niet zo simpel om dat te doen. Joe noemt de Microsoft AI Dev Gallery (link) en de AI toolkit voor Visual Studio Code (link). Op de site van Dotnetrocks wordt nog Phi Silica genoemd. En als je een "vet ding" wilt zien, check dan van NVIDIA de RTX PRO 6000 Blackwell GPU.