PC 1971: Valuable Testing met Egil Hansen
Bij "better know a framework" noemt Carl de repository voor "het sterker maken van je Windows beveiliging": Github-repo. Daar worden allemaal zaken gedeeld die Microsoft ook zelf gedeeld heeft, maar niet altijd in Windows geactiveerd heeft. Vaak omdat Windows "bruikbaar" moet zijn. Als een 80-jarige een volledig dichtgetimmerde pc met Windows koopt, is de kans groot dat hij/zij er niets mee kan. Maar met de huidige bedreigingen van phishing, ransomware is het eigenlijk het beste om die acties uit te voeren. Ik ga er zeker mee aan de slag! De term "waardevolle testen" geeft de indruk dat er ook "minder waardevolle testen" zijn en dat is natuurlijk ook zo. In deze uitzending komen zaken voorbij die als tester wel bekend zijn, namelijk of je zaken wilt "mokken" (met b.v. Moq) of dat je wel gebruikt wilt maken van de echte objecten. Egil is de auteur van bUnit, een testing-framework voor Blazor-applicaties. Zijn Github-repo is hier te vinden. Er worden wat resources in deze uitzending gedeeld die interessant zijn. Zo noemt hij Stryker. Dat is een soort test-framework wat bepaalde bitjes in je code "omzet". Daarna zouden jouw unit-testen moeten falen. Dus als ze nog steeds goed gaan, kan dat een indicatie zijn dat je testen niet goed zijn, of dat je testen onvolledig zijn en je (dus) extra testen moet toevoegen. Dan is er een blogpost van Mark Seemann over hoe je jouw testen moet noemen, hier na te lezen. Zo moet je testen niet het resultaat laten bevatten, maar de intentie van de test. Dat lijkt me vergelijkbaar dat je een stukje code ziet met een comment erachter en denkt: dit klopt niet. Voorbeeld:
Thread.Sleep(3000); // wacht 5 seconden
Mark Seemann heeft ook nog een boek geschreven: Code that fits in your head, het boek maakt deel uit van de Robert C. Martin series (Uncle Bob), dus dat lijkt een aanrader.
Carl noemt volgens mij nog Anglesharp, een .NET bibliotheek voor HTML die state-of-the-art is, ook daar ga ik naar kijken.
Natuurlijk komt ook AI nog even in deze uitzending voorbij. Egil geeft aan dat hij wel eens code heeft laten maken door AI en ook de testen, maar daar uiteindelijk niet een goed gevoel over had / niet voldoende vertrouwde. Want als je zelf de testen maakt, dan maak je bepaalde beslissingen, loop je tegen zaken aan en denk je "oh ja, dit moet ook afgevangen worden", dat mist hij in het AI verhaal. Hij heeft wel een LLM als een soort "reviewer" gebruikt en daar heeft hij wel goede ervaringen mee. Hij had bestaande tests, paste code aan en liet de LLM suggesties doen voor aanpassingen/uitbreidingen op de tests.
Ook noemt Egil het boek Unit testing principles practises and patterns van Vladimir Khorikov, waarin onder andere de 4 pilaren van testen genoemd worden.
Deze uitzending is de moeite waard!
PC 1972: Dieper duiken in .NET Aspire met Chris Klug
Bij "better know a framework" noemt Carl de tool "Excelsior". Een codebibliotheek, waarmee je Excel-sheets kunt genereren. Aan het begin van de aflevering leest Carl altijd even de bio voor van de persoon die te gast is. Chris laat weten dat het deel "developer" nog wel klopt, maar dat DevOps en Cloud momenteel niet echt van toepassing zijn, omdat hij bij een bank is gaan werken. En daar wordt alles "in-house" gedaan. In het begin komen Aspire en DAPR voorbij en wordt een soort vergelijking gemaakt. Chris geeft aan dat het 2 verschillende dingen zijn, maar dat ze beide goed met elkaar kunnen werken. Als je wilt starten met Aspire, kun je het beste naar deze pagina gaan. Chris heeft een eigen blog, die lijkt actief bijgehouden te worden. Als ik het goed begrijp probeert hij daar ook zaken te delen die niet bij iedereen bekend zijn, zoals het feit dat je het dashboard van Aspire naar eigen wens kunt aanpassen. Zo kun je daar dus een link naar het restoren van de database toevoegen en hoeft een nieuwe developer dus niet allemaal handmatige acties te doen om dat voor elkaar te krijgen. Carl vraagt of hij het dashboard ook op productie gebruikt, Chris geeft aan dat hij dat niet doet. Vaak wordt dat geïntegreerd met de dashboards in Azure of met andere Telemetry-frameworks, zoals Honeycomb. Chris geeft aan dat bepaalde zaken in Aspire in ontwikkeling zijn, dat hij snapt dat het team graag zaken snel "live" wil zetten, maar het voor developers moeilijk is om te bepalen of iets wat nu op een bepaalde manier werkt later ook nog zo werkt. Zo noemt hij het onderdeel "publisher", dat is nog experimenteel en bevat geen documentatie. Dat is voor deployment van code en kan best interessant zijn. Bij de bank waar hij werkt wordt "nog" met Jenkins code gereleased. Pulumi wordt nog even genoemd, dat is voor infrastructure-as-code. Op de vraag van Carl wat hij op zijn TODO-list heeft staan, antwoordt Chris dat hij bezig is om een 2-daagse workshop op te zetten, waarin het onderwerp ASP.NET Core webdevelopment is, MVC, minimal API's, gRPC, Yarp, project Orleans, Identity-Server.
PC 1973: CSLA met Rocky Lhotka
Bij "better know a framework" noemt Carl Playnite. Dit is een video game library manager. Ook console emulators worden ondersteund. Mocht je games spelen via Steam e.d., dan is dit misschien interessant voor jou. Dan de gast van de uitzending. Als je eerder podcasts van .NET Rocks beluisterd hebt (of mijn blogs hier gelezen hebt), ben je Rocky hier vaker met CSLA tegen gekomen. Dus als je er nog niets mee doet (zoals ik), misschien wordt het wel eens tijd om het wel te doen... In deze uitzending wordt versie 9 besproken, begin 2025 uitgebracht is. Versie 9.1 is in juni uitgebracht. Omdat .NET 10 uitgebracht is, zal CSLA over niet al te lange tijd ook als versie 10 uitgebracht worden, hou hiervoor de site van CSLA in de gaten. Het is Richard opgevallen dat er veel meer features in deze release zitten, meestal waren dat er 8 of 9, dit keer waren dat er 60. En ook in 9.1 waren er meer features. Dat was voor Rocky ook (deels) een verrassing, een bedrijf wat CSLA voor hun product gebruikt, wilde Rocky geen geld geven, maar wel iets voor het product doen. Toen hebben ze een soort online inschrijving geactiveerd, developers die bijdragen deden aan de CSLA-repo konden daarvoor een vergoeding krijgen. Dat heeft flink wat respons opgeleverd. Die betaal-actie was tijdelijk, maar er zijn toch een paar developers "blijven hangen", die het nu niet voor het geld, maar voor het product doen. Rocky laat weten dat in deze release heel veel zaken gericht zijn op Blazor. WPF (en Windows applicaties) worden nog wel ondersteund. Recent heeft Rocky gekeken of hij een WPF project ook met dependency injection kon laten werken. Dat kon, code ziet er dan wel heel anders uit. Op basis van die ervaring is hij het met Carl eens dat minder behoefte hebt aan Model-View-View-Model classes, dat geldt ook voor Blazor. Aan het einde van de uitzending laat Rocky weten dat hij ook een MCP-server gemaakt heeft voor CSLA. De "moeilijke manier" vond hij te moeilijk, dus hij heeft de nuget gebruikt en daar zelf een endpoint "search" aan toegevoegd. Daar doet hij een full-text search op, hij geeft daar mark-up aan terug. Carl zag dat Rocky met gRPC aan de slag ging, hij noemt nog even SignalR. Hoe dat bij cursussen die hij geeft altijd de enthousiaste reactie oplevert "wat cool!" en hij dat altijd moet temperen: als er niemand naar de berichten "luistert", komen ze ook niet aan.
PC 1974: Github Spec Kit met Den Delimarsky
Bij "better know a framework" noemt Carl "Bitwarden". Bitwarden is een password-manager. Hij zag dat Bitwarden server op Github zit, dus je kunt er zelf mee aan de slag gaan. Cool! En ook leuk om te zien dat dit in C# gemaakt is. In deze uitzending is Den te gast die het met Carl en Richard gaat hebben over ... AI. Hiervoor heeft Github het project spec-kit gemaakt, wat dus ook op Github te vinden is. Een interessante uitzending! Want er worden wat zaken besproken waar je als developer tegen aan kunt lopen. Het gaat over het specificeren van software, Richard heeft teruggezocht dat in aflevering 9xx het onderwerp Cucumber was, ook een soort framework om dat voor elkaar te krijgen. Het idee is dus zeker niet nieuw. Maar met AI zijn er inmiddels veel meer mogelijkheden.
Zo is Den wel eens met Claude een project gaan bouwen, heeft Claude ook de testen gebouwd en was de feedback van Den dat hij moest zorgen dat alle testen groen licht gaven. Dat gaven ze ook... totdat Den zag dat de code aangepast was en een simpele TRUE terug gegeven werd. Dat is natuurlijk niet de bedoeling! Ook dat bijvoorbeeld bepaalde mappen worden gekopieerd, waarbij "het wel werkt", maar het gevolg is dat zaken minder goed (of niet) onderhoudbaar zijn. Carl noemt het voorbeeld van een project waar hij mee bezig was en duidelijk had aangegeven dat het op .NET 9 moest draaien. Had Claude het toch weer teruggezet naar .NET 8... Dit is volgens Den een goed voorbeeld van waar Github Spec voor ingezet kan worden. Zo geef je in de specs aan dat altijd .NET 9 gebruikt moet worden. Maar vervolgens laat je niet alleen AI de code bouwen en "hoop" je dat de AI zich aan de regels gehouden heeft, maar geef je ook aan, als je "klaar" bent valideer of jouw code voldoet aan de specs. Als dat niet het geval is, ben je nog niet klaar en moet je doorwerken.
Ook komt voorbij dat je "context" mee geeft, maar dat dit tokens kost en na verloop van tijd de agent de originele context kwijt (of deels kwijt) kan raken. Den noemt het inzetten van taken. Een agent kan sub-agents aansturen om taken uit te voeren (die soms ook parallel uitgevoerd kunnen worden) en zorgt dat ieder van die taken hun eigen relevante context krijgen. Als een taak het stylen van de applicatie is, heeft die taak niet alle informatie over de back-end API met alle endpoints nodig. Ook komt het punt van "verschillende scenario's" voorbij. Soms heb je werkende code, maar een volgende wens of requirement wordt uitgewerkt en vervolgens werkt je code niet meer. Dan kun je "terug" naar het checkpoint en het opnieuw proberen. Dat kun je met GIT doen, waarbij de agent verschillende branches kan aanmaken en ook verschillende scenario's kan uitwerken. Aan het einde van de uitzending komt voorbij dat je vaak begint met een document met de specificaties, daar worden vergaderingen over gehouden, daarna gaan developers "bouwen", komen er nieuwe wensen, wijzigingen, bug-fixes, maar niemand die het specificatie-document bijwerkt. Den heeft positieve ervaringen met Project DeepWiki dat op basis van de code goede documentatie kan genereren. Ook kan deze bestaande documentatie bijwerken naar de huidige status. En omdat developers vaak met "brownfield-projects" bezig zijn, dus de applicatie bestaat al een aantal jaren, de originele developers werken er niet meer en er moeten zaken aangepast worden, dan kan deze tool zorgen voor goede documentatie. Carl noemt ook nog de mogelijkheid om PlayWright te gebruiken, aangezien die nu een MCP server bevat, Carl heeft dit bij zijn AI podcast gebruikt om documentatie te maken en daar dan goede screenshots van de applicatie bij te krijgen.
Uit deze podcast blijkt wel dat "het vak software-developer blijft bestaan", want er zijn mensen nodig die snappen wat de code doet, die zaken kunnen aanpassen en ook corrigeren bij onjuistheden.
Den zijn eigen website is hier te bekijken, zo te zien is hij een actieve blogger. En ik zie daar ook terug dat hij een aantal boeken bij de bibliotheek geleend heeft en hij die aanraadt op zijn blog, misschien wel inspiratie om ook die boeken te lezen!
PC 1975: Cake.SDK met Mattias Karlsson
Bij "better know a framework" noemt Carl dat in eerdere uitzending al eens ter sprake gekomen is, "hoe kun je zorgen dat open-source (dus openbare software waar je niet voor betaalt) onderhouden wordt"? Carl/Richard hebben toen ooit gezegd, misschien moet je een soort "doneer-knop" ergens toevoegen, zodat gebruikers die de open-source software gebruiken en er dus belang bij hebben dat het ondersteund wordt (alle software veroudert, dus je moet het onderhouden) een donatie kunnen doen. Op dit moment is dat toegevoegd bij Nuget-packages. Hier kun je er een artikel over lezen.
Te gast is Mattias die het over "Cake" heeft. Dat is een pakket wat al sinds 2014 (volgens mij?) bestaat. Hiermee kun je in C# je deployments programmeren en hoef je geen YAML te leren. Ook is dus multi-platform, multi-besturingssysteem. Dus als je het nu voor Azure Devops gebruikt, je kunt je code ook gebruiken voor als je zou overstappen naar Github en daar gebruik maakt van Github Actions. Het nieuws van Cake is dat het nu een SDK heeft, waarmee je ook bepaalde rechten die nodig waren om te deployen weer wat strakker ingericht kunnen worden. Cake kun je hier vinden, de Cake SDK kun je hier vinden.
Omdat ik tijdens het luisteren naar deze podcast aan het sneeuwscheppen was en aangesproken werd door iemand die bij de bushalte stond te wachten, heb ik een gedeelte gemist. Bij het artikel over de podcast staan een paar linkjes die ik niet kan terugkoppelen aan deze podcast. Maar omdat ze wel handig zijn, deel ik ze hier. Namelijk de SBOM-tool van Microsoft en Verify Snapshot Testing.
PC 1976: Oude ontwikkelaars gebruiken nieuwe tools met Brady Gaster
Bij "better know a framework" noemt Carl Python.NET, waarmee je in .NET Python kunt gebruiken en .NET in Python. Github-pagina is hier te vinden. Bij de ingekomen e-mails noemt Richard volgens mij een inzending van Eduard Keilholz (van 4dotnet?), over dat de Azure Developer CLI "handig" is, maar je wel ervaring moet hebben hoe je zaken configureert, omdat anders zaken "te" veel open kunnen blijven staan. Je krijgt daar niet het advies om zaken in een VNet te zetten, er een firewall bij te doen e.d. Brady is met allemaal tools bezig, onder andere met het omzetten van .NET Framework-applicaties naar .NET Core (Microsoft pagina). Hij was bij een vriend en zag een mooie UI, en opperde dat hij dit graag als een back-end-omgeving wilde gebruiken. "Momentje" zei zijn vriend en die had het in "no time" voor elkaar. Brady was daar erg van onder de indruk, daarom wilde hij React Flow met ons delen. AI komt ook voorbij. Zo is er volgens Carl een "prompt repository van Microsoft op Github", die heeft hij gedeeld: link. Ook werkt Brady aan Aspire. Wil je daar ook mee starten, begin dan hier. De link naar de Community Toolkit bij de podcast van .NET Rocks werkt niet meer, daarom maar de rechtstreekse link naar de Github-repo.
Ook nog een "leuk verhaaltje tussendoor". Zo werd het logo van Rust getoond, dat is een programmeertaal. Maar er was per ongeluk het logo gebruikt van het spel Rust... zoals je hier ook op Reddit kunt lezen. Brady heeft er vervolgens maar een eigen implementatie voor gemaakt, de Facepunch.Rust game-server. Als je op zoek bent naar het "Rust" spel, klik dan hier.
Github Copilot voor Azure, daarover kun je hier informatie vinden. De huidige toekomst lijkt MCP-servers, de combinatie van AI en OpenAI. De specificatie daarvan kun je hier vinden.
Carl spreekt zijn angst uit dat door zaken te combineren, stem, beeld, je het voor elkaar kunt krijgen om iemand een bekentenis te laten doen, die hij/zij nooit gedaan heeft. En dat niet te achterhalen is dat het "nep" is. Er zou een soort tool moeten zijn die dat wel kan onderscheiden. Zoals in je foto's EXIF-data zit die aan kan geven met welk type toestel de foto gemaakt is, op welke GPS-coördinaten e.d. En we sluiten af met de Github spec-kit, al eerder genoemd in aflevering 1974, maar omdat Brady daar ook enthousiast over is, nogmaals.
PC 1977: De rol van LLM's in Visual Studio productiviteit met Leslie Richardson
Bij "better know a framework" noemt Carl een setting in Visual Studio Code... die je beter niet kunt gebruiken. Als je naar Settings gaat ( CTRL + , ) en in het zoekveld YOLO invoert dan zie je dat deze optie aangevinkt kan worden. Daarmee geef je een agent "alle rechten". En daarom wordt het ook expliciet afgeraden om dit te doen. You Only Live Once... en vooral als een agent je volledige infrastructuur verwijdert ;) Maar goed, mocht je binnen een afgeschermde omgeving iets dergelijks toch nodig hebben, dan weet je nu dat de mogelijkheid er is. Richard heeft bij de show-notes nog even een linkje toegevoegd, dat alleen te lezen is als je ingelogd bent in Github. Leslie is een product-manager in het .NET team en daar bezig met debuggen, MCP-servers. Tijdens deze uitzending komen een aantal zaken daarvan voorbij. Bijvoorbeeld het debuggen van een lijst met objecten. Als je ergens een breakpoint hebt, en je inspecteert een variabele die een lijst is met bijvoorbeeld 500 items, als je daar "even" de 350e wilt controleren, daar moet je moeite voor doen. In de debugger heb je nu een IEnumerable visualizer, wat het een stuk beter maakt: link. Een andere mogelijkheid (die al een tijd bestaat) is dat je via een attribuut aangeeft hoe een bepaalde variabele getoond moet worden met DebuggerDisplay. Alleen betekent dit dat je code aan moet passen, dat is dus "meer werk". Je kunt ook in "de cloud" ontwikkelen, dat deed je met Dev-Box. Daar kun je je nu niet meer voor aanmelden, want het pakket wijzigt, als je dit wilt ga je voor Windows 365. In dit artikel kun je er meer over lezen.
Leslie komt het de Github-repo "Awesome Copilot". Waarom zou je een prompt bedenken en schrijven, als iemand anders dat al gedaan heeft? Hier staan allemaal prompts die je kunt "kopiëren en plakken".
Leslie vind het vervelend dat Copilot vaak de editorconfig negeert, dat is een configuratie die bijvoorbeeld aangeeft dat alle namen van interfaces met een hoofdletter I moeten beginnen (link). Carl kende editorconfig volgens mij niet, maar noemt iets wat in het verleden gebruikt werd, FxCop. Die werd in het verleden ook bij TRES gebruikt.
De MCP-servers komen aan bod, zo heeft Github ook een MCP-server waar Leslie vaak gebruik van maakt. En natuurlijk heeft ook Azure een MCP-server.
En nog een hele mooie, Leslie kwam met de "beast mode" voor je AI Agent. Hier is de link naar de Github-repo. Hiermee instrueer je de agent dat ie niet zegt "het is klaar" en dat je vervolgens met een stuk code zit wat "helemaal niet klaar is". Carl vraagt of er ook ergens een soort mode is dat je de "te kont-kusserige responses" van de agent uit kunt zetten "oh ja, je hebt helemaal gelijk", "wat een goede vraag stel je nu...". Die mode is er volgens mij niet. In ieder geval, met beast mode dwing je de agent online bronnen te raadplegen en zaken te valideren. Lijkt me de moeite waard om eens te proberen!
In deze uitzending komen ook "kusto query's" voorbij. Op deze pagina van Microsoft kun je er meer informatie over vinden. Richard noemt nog even dat hij bij een podcast van Runas Radio Mark Morowczynski te gast heeft gehad die hier een boek over ging schrijven. Dat boek is al een tijdje "klaar" en heeft de titel Business Skills-The Definitive Guide to KQL.
PC 1978: Meer sustainable software met Tom Kerkhove
Bij "better know a framework" noemt Carl een tool die gemaakt is door Simon Cropp, die zo te horen wel vaker in Dotnetrocks genoemd is. Het project, ProjectFiles, kun je hier op Github vinden. Hiermee kun je "dingen doen" met bestanden die in .csproj-bestanden als "copy to output" gemarkeerd zijn. Carl zegt: "je eerste ingeving is -waarom?". Maar na verloop van tijd denk je, dit is inderdaad handig. Want je kunt nu "in code" zaken benaderen en controles uitvoeren. In de Github-repo staan wat voorbeelden, ik kan mij voorstellen dat je in de pipeline bepaalde zaken wilt testen. Voorkomen dat bepaalde dingen die "niet ingecheckt hadden mogen worden" er toch in staan en bij een deployment ervoor kunnen zorgen dat zaken overschreven worden, zo'n test kun je laten falen. Checken dus, lijkt cool. De gast van deze uitzending is Tom Kerkhove. Tom geeft aan dat hij een half jaar geleden een ongeluk heeft gehad, waardoor hij zijn ene hand niet kan gebruiken. Hij gebruikte eerst "speech-recognition" voor zijn e-mails en zag toen dat er bijna geen fouten meer werden gemaakt. CoPilot ondersteunde eerst geen gesproken tekst in Visual Studio, wel in Visual Studio Code en daar heeft hij ook uitgebreid gebruik van gemaakt. Richard merkt op dat hij nu vast een "accessibility fan" geworden is, dat klopt. Op het moment dat je alles kon en daarna met moeite, doet je beseffen dat er ook andere mensen op deze planeet rondlopen die moeite hebben om met bepaalde tools te kunnen werken. Tom werkt al sinds jaar-en-dag bij Microsoft en is de "API-man". Zo wordt Azure API-Management besproken. Veel mensen denken het niet nodig te hebben, maar komen er later achter dat ze het wel nodig hebben. Implementatie is niet al te moeilijk, maar zorgt wel voor breaking changes bij klanten als je de DNS niet op orde hebt. Bij sustainability worden een paar voorbeelden genoemd. Bijvoorbeeld dat tijdens de corona-pandemie bleek dat zodra iemand begon te typen, iedereen daar feedback van kreeg (zichtbaar in Teams als "Dirk is typing..."). Onnodig extra dataverbruik, wat pas opviel toen iedereen thuis ging werken en deze activiteit dus veel vaker voorkwam. Hoe er gekeken wordt naar: bij dit data-center is het nu avond, dus energie die verbruikt wordt is "niet schone energie". Kunnen we bepaalde loads laten uitvoeren door een data-center die wel "clean energy" gebruikt? Microsoft deelt er deze pagina over, over "carbon optimization". Tom noemt ook het voorbeeld van pipelines die gebuild worden, maar waar niemand naar kijkt. Ook hier kun je gaan kijken naar wat er gebuild wordt, welke wél gevalideerd worden en welke "overbodige runs" je er dus uit zou kunnen halen. Bij Azure API-Management heb je nu ook de AI gateway, om het verbruik van tokens te monitoren. Maar ook andere zaken, zoals DDOS en andere limieten. Tom noemt het voorbeeld waarbij bepaalde limieten geraakt worden en je via policies hebt ingesteld dat bepaalde "redundante acties" op een lager pitje gezet worden. Mogelijk log je alle inkomende requests, maar doe je dat nu (even) niet bij requests waarbij de hoeveelheid data een bepaalde limiet overschrijdt. En je hebt Autoscale, als je bepaalde resources niet gebruikt, zet ze uit.
Richard noemt nog een ander punt, de Azure SRE Agent (staat nog in de kinderschoenen). Agents die kunnen "zien" dat er problemen optreden, onderzoek plegen waar de oorzaak ligt en mogelijke oplossingen kunnen voorstellen. Gaat een uitzending van RunAs-radio over. Meer doen met agents? Check de Microsoft Foundry.
Tom zijn blog is hier te bekijken (laatste artikel is van 2023).
PC 1979: Een AI app bouwen met Calum Simpson
Bij "better know a framework" noemt Carl Technitium DNS Server, een open-source DNS server. De Github-repo staat hier. Deze ga ik binnenkort toch eens testen, eens zien of ik hiermee binnen mijn eigen netwerk mijn netwerk kan filteren. Ook hier komt het grapje, "It can't be DNS.... it is DNS!" voorbij. Tijdens deze uitzending is Richard in Australië, hij is een tijd bij familie in Nieuw-Zeeland geweest. Calum werkt met zijn bedrijf aan de tool Yakshaver. Je wil met een project beginnen, maar voordat je daarmee kunt beginnen ben je 2 weken bezig met allemaal ondersteunende/voorbereidende taken, waarvan je vaak denkt: is dit nu nodig? Met een soort pipelines, het insturen van een video, daarbij audio van degene die bijvoorbeeld een probleem meldt, kan een ticket aangemaakt worden, die bij de juiste afdeling ingeschoten wordt. Niet meer navragen "hoe heb je in die situatie kunnen komen", of "kun je een screenshot sturen", die data krijg je allemaal al. Er wordt een transacription van de audio gemaakt. Er worden thumbnails van de video van bepaalde punten gemaakt. Dit was een commercieel product, gestart in de tijd dat er nog geen MCP-servers waren. Calum meldt dat ze bezig zijn met versie 2 die op basis van MCP-servers werkt, waarbij het dan ook een open-source project wordt, omdat de tool straks op de desktop van klanten gaat draaien.
MCP begint inmiddels een bekende term te worden, zoals MVC, REST API en andere zaken. In de show-notes hebben Carl en Richard nog even een linkje toegevoegd naar de officiële site waar je kunt lezen "wat MCP nou eigenlijk is".
"Shaving the yak" is een term die ik wel eerder bij .NET Rocks gehoord heb, in de show-notes wordt verwezen naar dit artikel op techtarget.com, volgens Calum komt het ergens uit een Ren en Stimpy filmpje. Even gezocht, daarbij heb ik dit filmpje op YouTube gevonden.
PC 1980: Package management met Gary Ewan Park
Bij "better know a framework" noemt Carl UniGetUI (voormalig WingetUI). Dit programma is een grafische interface voor package-managers, zoals Winget, Scoop, Chocolatey, Pip, NPM, .NET Tool en de PowerShell Gallery. De site kun je hier bekijken, de code kun je (natuurlijk) ook op Github vinden.
Bij deze tools wordt Chocolatey al genoemd, het toeval wil dat de gast in de uitzending, Gary, werkt voor Chocolatey. Zie het als een soort package-manager voor Windows. Voor het opbouwen van je systeem, of een VPS in de cloud waar je direct "al je tools op geïnstalleerd wilt hebben", dan is Chocolatey daar een kandidaat voor. Via parameters zijn veel programma's te installeren, daar werkt dit pakket het beste mee. Carl vraagt hoe het zit met programma's die dat niet hebben en waarbij je echt "door de installatieschermen heen moet klikken". Dan wordt de AutoHotkey-tool gedownload die dat voor je uitvoert. Gary raadt aan om zelf een soort repository te hebben waar je de tools in zet, die je dan weer verder kunt verspreiden, ook om invloed te houden op welke tools gebruikers installeren.
Want hij zegt ook, omdat veel software met admin-rechten "pas" geïnstalleerd kan worden (het moet in Program Files, er moeten zaken naar het Windows-register geschreven worden), draait Chcolatey altijd in admin-mode. En daar zitten natuurlijk ook bepaalde risico's aan gekoppeld. Richard komt met het voorbeeld het opensource-project XZ, wat bij heel veel software voor compressie gebruikt is. Een developer die al jaren goed werk leverde, zijn eigen PR's mocht goedkeuren, had in de code gezorgd dat bepaalde data naar servers in China gestuurd werd. Een Microsoft medewerker is daar achter gekomen, dat publiek gemaakt en gezorgd dat de wereld weer een beetje veiliger geworden is. Maar het is absurd hoe dat tot stand is gekomen. Deze medewerker was namelijk een "hardcore debugger". Hij testte zaken en zag dat ten opzichte van de vorige release het programma 500 milliseconden trager was. Dat is een halve seconde. "Wij" als web-developers zouden mogelijk onze schouders ophalen en zeggen, beetje vertraging op de lijn en doorgaan met ons werk. Maar hij duikt erin en ziet dus dat deze "interne hack" gedaan is. Lees het verhaal op dit blog.