Transcriptie: Dennis Doomen over Fluent Assertions & CQRS/Event Sourcing

Welkom bij de tweede aflevering van CodeKlets. Ik ben Saber Karmous. En ik ben Kishen Simbhoedatpanday. Ja, dit is de tweede aflevering. Het was wel, de eerste was best, vond ik best spannend. Was ook heel gaaf, was met Pauline. Nee, maar dat was echt wel gaaf. Dit heeft me best wel verrast, want je weet natuurlijk nooit wat voor persoon je aan tafel hebt. En dit was leuk. Ja, het was heel gezellig. Een hele leuke, spontane meid ook. Veel gelachen. Veel ook inhoudelijke, facking-inhoudelijke dingen ook met haar gesproken. Ja, het was echt goed. Ja, dat vond ik ook. Maar goed, ik zat daarna. Ik wilde nog één opnemen. En ja, dan zit je te wachten, te wachten en dan hopen dat je weer een gast kunt vinden. Gelukkig hebben we best wel een lijst met hele interessante gasten die we binnenkort hopelijk kunnen op gaan nemen. Dus daar kan ik niet op wachten. Die gast van vandaag, Klapper Zoel, die is ook heel erg gaaf. Maar het viel mij op dat ik echt wel zin had om weer een nieuwe op te nemen. Dus ik vind het echt wel gaaf om te doen. Elke week gaan we gewoon tijd maken. Ja, precies. Oké, maar deze keer hebben we een gast die voor mij heel bekend is. Dat is een collega van mij. Die werkt ook bij Alviva Solutions en dat is Dennis Domen. We zijn heel blij dat hij aanschuift bij ons. Dennis werkt dus bij Alviva Solutions. Zit al ruim twee decennia in het vak. Ik weet niet hoe je dit doet, man. Na tien jaar was ik afgeraakt. Hoe hou je je in het volk? 23 jaar. 23 ook. Hij heeft zich inmiddels gespecialiseerd in het verbeteren van het hele software ontwikkeltrekken bij organisaties die software bouwen op basis van .NET technologie. Dan doe je gewoon alleen maar .NET. Ik kan mezelf fullstack noemen, maar dat is een beetje een hype term. Natuurlijk kan ik JavaScript en TypeScript, maar mijn hart ligt nog steeds bij .NET. Heb je ook een tattoo ergens met .NET? Nee, dat doe ik niet aan. Nou, dat is maar goed, want dat vind ik altijd een beetje vreemd. Ik ben er ook de scheidrecht voor. Ja, precies. Maar goed, het gaat over allerlei facetten. Dus architectuur, teams, mensen, infrastructuur, tools en de processen die daar allemaal mee te maken hebben. Dat is een redelijk breed inzet bij die jongen. Dat is wel handig. Hij heeft twee kinderen en nog een vrouw. En hij heeft ook handbaltraining. Dat is wel een verrassing voor mij. Dat wist ik dus niet. Ja, voor mij ook wel. En ook voor mijn familie. Maar mijn vrouw is een handbalfanaat. En mijn kinderen zijn op handbal gegaan. En in een gegeven moment word je een soort van vrijwilliger. En ja, waarom niet? Het is leuk. Je staat buiten. Frisse lucht. Hij schrijft verder ook nog blogs. Nou, ik weet niet, waar had hij de tijd vandaan? Internationale conferenties. En hij onderhoudt meerdere open source projecten. Dat komen we later denk ik nog wel op terug. En hij schijnt ook nog iets met C-Shop te doen. Dat is eigenlijk wel best wel logisch, maar ook wel handig. Het zou wel een beetje lullig zijn als je .net deed en alleen maar Javascript kon. Dat is niet zo handig, denk ik. Maar goed. Dit komt meteen bij het eerste onderwerp, zodat we meteen met de deur in huis vallen. Dat is een project waar hij denk ik best wel trots op is. Nou, we gaan niet alleen over dat project hebben, maar ook een aantal verwante zaken. Dat is Fluid Assertions. Dat is een library om assertions mee te schrijven. Dat is bij unit testen, dus TDD of BDD. Als ik het goed heb. En dat doet hij al een tijdje. Hoe lang eigenlijk? Tien jaar. Tien jaar. Toen vallen zag ik het vandaag. Ik zat te kijken naar de aantekeningen voor een komende presentatie. Toen zag ik dat ik het samen met collega Martin Opdam, ook bij Aviva werkend, in 2009 het idee al zijn we eigenlijk mee gestart. En volgens mij pas in 2010 kwam het op CodeKlets. Maar goed, in 2009 zijn we er al mee begonnen. Toen heette het nog Custom Assertions ofzo. Het was meer een hobbyprojectje. Niet echt serieus bedoeld. Die Fluid Assertions is wel een betere naam. Moet ik eerlijk zeggen. Ja, dat loopt wat lekkerder. Wat vloeiender. Dit is echt een nerd-talk dit. Ja, precies. Ik hoop dat mensen daar mogen luisteren. Maar hoe ben je eigenlijk geïnspireerd? Hoe oud ben je Fluid Assertions gaan doen? Is dat toevallig omdat je dacht. Nou ja, dit probleem lopen we nu samen met Martin, zei je. Ja. We lopen iedere keer een beetje tegen dezelfde problemen aan. Ja, dat is zeker zo. Ik ben niet iemand die gewoon puur uit een hobby sfeer iets gaat bedenken, iets gaat bouwen. Ik ben niet iemand die bijvoorbeeld, weet ik veel, als er iets nieuws uitkomt. Een nieuwe .netversie of een nieuw framework ofzo. Dat ik dan in de avonduren gewoon eens iets in elkaar ga zetten. Pure voor de lol. Het zit niet in me. Ik moet echt een probleem willen oplossen. En volgens mij hadden we toen het probleem. Ik ben ook weer iemand die houdt van leesbare code. Ik wil graag dat mijn code zelfbeschrijvend is. Dat is misschien een beetje een ideologische insteek. Maar ik vind het belangrijk dat het duidelijk is. Dat het de intentie laat zien. En ik kan me nog wel vaak herinneren dat we toen met bestaande toolingen daar niet echt uit de voeten kwamen. En dat we gegeven met zijn experimenteren. En voor mij had het ook ergens gezien. Een soort gelijk project in een andere platform. En dat is eigenlijk zo gegroeid. En we hadden ook nooit bedacht dat het zo groot zou zijn. Ik zag vanmiddag dat we volgens mij richting de 28 miljoen downloads gaan. Nou, ik wou dat ik daar een cent per download van kreeg. Of bitcoins. Ja, precies. Maar dat is eigenlijk zo gegroeid op een of andere manier. En wat was de onderscheidende factor volgens jou? Wat je beschrijft dat je ergens een soort gelijk framework had gevonden. Ja, dat is een hele goede vraag. En eerlijk gezegd weet ik het antwoord daar niet op. Want er zijn een soortgelijke frameworks. Maar die zijn op een of andere manier nooit zo populair geworden. Waar denk je dan als je zelf zou mogen? Misschien de presentatie die ik erover gedaan heb. Misschien de blogs die ik erover geschreven heb. Het laten zien aan andere mensen. Het is gebaseerd op een fluent API. En dat betekent het leest lekker makkelijk. Je hebt een variabele. Je gaat in je whatever IDA je wil gebruiken. Visual Studio Rider. Je doet een dot. En je ziet shoot staan. En je doet nog een keer een dot. En je ziet precies alle opties die je hebt. En het leest ook heel erg duidelijk. En een van de dingen waarvan ik zelf denk dat het wel vrij uniek is opzich van andere frameworks. Als een unit test faalt. Dan vind ik het heel belangrijk dat het heel duidelijk is waarom die faalt. Ik heb dus een hekel aan van expected, false en found true. Dat zegt helemaal niks. Dus ik heb het altijd een onderdeel gemaakt om het proberen heel explic te maken. Dat je meteen ziet zonder dat je een code krijgt van oh dat is de reden waarom het faalt. Ja, je probeert ontwikkelaars net zoals je zelf zegt mooie code. Het is duidelijke code te schrijven. Het moet lezen als een boek. Ja, absoluut. Absoluut. Oké. Ja, dat is wel. Kijk, want het grappige is. Ik heb het best vaak. Trouwens eigenlijk altijd als ik unit test schrijf dan gebruik ik het voortaan. Het lijkt wel een reclameblok. Maar dat is ook feitelijk echt zo. Nogmaals, ik verdien er niks mee. Nee, nee, nee. Maar goed. Maar het grappige is als je het leest. Je denkt, ja, het zijn een search. Je denkt, ja, een big deal zeg maar. Hoe kan dit nou zo veel impact hebben? Maar het grappige is als je het niet gebruikt. Dan denk je, shit, ik mis het. Dus het is al heel snel dat ik dan via de Visual Studio Package Manager, als ik het niet heb, dat ik het meteen installeer. Dus als het in de package niet gebruikt wordt, dan sneak ik altijd die package erbij in. Maar het is steeds vaker zo dat als ik ergens kom en ze hebben unit test geschreven, dat het in de search gebruikt wordt. Dus dat is wel echt opvallend. Ja. Dus dat is al wel een... En dat is ook echt kick om te zien hoor. Want ik zeg al, ik had het zelf niet verwacht dat het zo ver zou gaan. Maar op een gegeven moment ontdek je je eerste blogpost. Dat iemand een blogpost schrijft over je open source library. En vorig jaar zag ik voor het eerst een Pluralsight Training. En toen denk je wel van, wow, dat is toch wel kicken. Dat vind ik eigenlijk wel bijzonder, ja. Dat iemand alles dan een cursus verzint met spullen die jij verzond hebt. Dan heb je wel, ja, dan ben jij gewoon klaar. Dat denk ik wel. Ik zag een open source vereniging van een collega. Ik zag ook voor het eerst een blogpost over voorbij komen van iemand anders die het gewoon gebruikt. Ik denk dat je dan een punt hebt bereikt dat je dat dan gaat spelen. Als andere mensen gaan praten, gaan schrijven over iets wat je gemaakt hebt. Dan heb je denk ik, misschien is dat wel een beetje dat kantelpunt voor een library. Ja, ja, ja. Ja, het lijkt me wel heel erg gaaf. Ik heb het helaas niet mogen meemaken, maar goed, dat is wel heel gaaf. En zijn er ook negatieve zaken geweest waarvan je dacht van nou, want het is een open source project. Heb jij bad stories? Oh, joh. Ja, weet je, het is net een echt software project. Je hebt te maken met mensen die bepaalde wensen hebben, dingen die niet passen, die niet in de filosofie passen. Je hebt mensen die kritiek leveren, dat ze bijvoorbeeld een bepaalde featje niet mooi vinden. Je hebt zelfs mensen die hele vloeiend APIs afsweren. Waarschijnlijk zijn dat de mensen die misschien een keer een slecht ervaring hebben gehad. Die zitten de verkeerde kant van de hype cycle. Maar in het algemeen, ja, weet je, het is software. Dus je moet gaan nadenken over breaking changes. In tien jaar tijd is er heel veel veranderd in de .NET wereld. Allerlei frameworks zijn bedacht en constructies om meerdere platformen of meerdere verschillende frameworks te ondersteunen. We moesten met Mono ondersteunen, Xamarin. We hebben .NET Core, veranderen ook weer van alles. Dus je bent continu bezig geweest om het weer compatible te maken, nieuwe features te ondersteunen en, net als een echt software project, je maakt ook keuzes, keuzes waar je later spijt van hebt. Je hebt een bepaalde constructie bedacht, een bepaalde API en later ontdek je van ja, dat zit niet helemaal lekker in elkaar. Mensen snappen het niet, dat is niet intuïtief genoeg. Maar je kunt het niet zomaar aanpassen, want je wilt geen breaking changes centraliseren. En dat is nog steeds zo, zeker met het aantal downloads, zie je ook dat mensen dingen gaan gebruiken op een manier die je niet verwacht had. Of dat ze een bepaalde functie tijd willen toevoegen die gewoon niet past in het idee. Je wilt dingen recht trekken. Een heel mooi voorbeeld is, iemand voegt een nieuwe functie toe. Ik wil een regular expression match methode hebben. Als je dat wilt toevoegen, bijvoorbeeld voor strings, misschien wil je die ook wel hebben voor collecties of zo. Maar wat de contributors vaak doen, is alleen maar die ene feature toevoegen. En als je als feedback geeft, ja, het is niet helemaal consistent, zou je diezelfde methode ook op die andere klas kunnen zetten, dan hebben ze er vaak geen zin meer in. Dat is een lastige. En ook kwaliteit van de code. Ik wil ook, Flunt is voor mij niet alleen een library, maar het is ook een soort van, hoe zou je het zeggen, een voorbeeld van hoe ik vind hoe je code moet schrijven. Ik heb daar een vrij sterke mening over. En als iemand eens iets aanlevert, wat hij in ieder geval doet, ja, wat doe je dan? Ga je dan een review geven van, ja, ik wil geen far gebruiken, of er moet betere documentatie op, of zeg je van, ja, die persoon heeft wel zijn best gedaan, laat ik het maar gewoon het werk voor hem doen of voor haar doen. Ja, ja, dat kan ik me wel eens bevoorstellen, want het is natuurlijk, ja, het is open source, het is gratis, maar goed, iemand steekt daar gewoon heel veel tijd en effort in. Andere zijn er tegelijkertijd ook afhankelijk van. Dus ik snap ook wel dat je bijvoorbeeld, als je vrijdagmiddag moet je nog even snel een test goed aan de praat krijgen, dan blijkt er een issue te zijn. Of is het niet helemaal duidelijk, zeg maar, hoe een bepaald iets werkt met de Flute Assertions? Dat kan ik me voorstellen. Ik denk, nou, ik moet nu deze bug, die moet voor mij nu opgelost worden. Maar ja, dat kun je niet verwachten van iemand. Aan de andere kant van jou bijvoorbeeld, van, ja, je gaat niet stil op sprong denken van nou, ik ga nu voor hem en voor iedereen die dat op vrijdagmiddag doet, dat probleem oplossen. Dus dat, dus je van de gebruikers is te begrijpen, maar van de maintainer of de eigenaar, of de oprichter van het project. Ja, kun je niet verwachten dat hij ook alles voor je doet. Dus dat is wel, ja, wel. Dat is een lastige balans soms. Ja, ja, ja. Je hoort echt best wel mensen die gewoon best wel populaire open source project hebben, die gewoon echt denken van nou, ik stop je gewoon mee, want ik krijg zoveel, ja, hoe zeg je dat? Negatieve feedback is vooral op github dan, dat er echt een complete rant in zo'n github issue plaatsvindt. Kijk, het voordeel van dit is een library. Het is een library die je alleen maar in unit tests gebruikt. Het wordt bijvoorbeeld een ander verhaal als jij een framework bouwt. In .NET space heb je best wel frameworks om bijvoorbeeld beeld scripts te maken, cake, sake, nuke. En daar zie je dat er vaak wat mensen achter zitten die vrij specifieke mening hebben. En dat betekent ook, als het niet voldoet aan hun mening, dat het ook heel lastig is om te overtuigen dat wat ze hebben gebouwd bijvoorbeeld niet goed te gebruiken is in een groot complex systeem. Misschien omdat ze het zelf dat die ervaring niet hebben of dat ze toch een bepaalde filosofie hebben. En dat is ook heel lastig om het gewoon in tekst, weet je wel, in een discussie op github, op Slack, wat dan ook, uit te vechten om het zo maar even te zeggen. Ja, ja, precies. Het is eigenlijk ook een beetje zoals, ja, als je boos bent dat je eigenlijk niet verstandig is om dan een mail te sturen naar iemand. Het is eigenlijk een beetje hetzelfde medium, zeg maar. En ja, er zijn eerlijk is eerlijk, zeg maar, onder software ontwikkelaars zijn er wel een aantal mensen die zijn redelijk, ja, direct of ja, noem het misschien lomp, zeg maar. Takloos. Ja, precies. Dus dat is nu eenmaal zo. En die willen ja gewoon heel specifiek, altijd op een heel specifieke vraag, terwijl er best wel wat context bij komt kijken. Ja, dat klopt. Dus dat is wel een ding. Ja, achteraf gezien zijn er echt zaken die jij misschien in het begin anders had willen doen. Ja, achteraf is altijd een beetje... Ja, natuurlijk. Ja, daarom is het een beetje een lastige vraag. Of een beetje koffiedik kijken, maar nee, ik ben eigenlijk wel tevreden Weet je, het is... Je hebt keuzes gemaakt, maar het is... Weet je, de keuzes die je maakt zijn ook weer niet zo kritisch voor wie dan ook. Nieuw releases maak je dingen weer wat netter. Ja, je krijgt nu wel een beetje een soort van feature bloot. Er zitten nu zoveel dingen in. Ja, is het eigenlijk niet gewoon complete? Maar goed, ik krijg nog steeds verzoek om dingen toe te voegen. Nee, ik heb dat zeker niet. Het is gewoon zo gebouwd. Zou ik het anders doen? Nee. Het is ook geen architectuur die je neerzet. Kijk, bij architectuur en complexe systemen, daar heb je veel eerder de neiging om van, ja, ships. Ik heb een bepaalde keuze gemaakt. Achteraf was dat misschien een beetje naïef. Maar ja, met een library zoals dit heb je daar helemaal geen last van. Het is geen framework. Dat scheelt al. Heb je ook voor de luisteraars thuis een gouden tip voor het opzetten van zo'n project? Poeh. Dat is wel een lastige. Als ik daarover na had kunnen denken. Nee. Een open source project populair maken. Ja, weet je, het is gewoon... Ook al heb je een mooie oplossing voor een probleem, dan is nog de vraag hoe uniek is dit? En vinden mensen het? Ja, ik denk uiteindelijk Twitter en een blog en dat soort zaken, dat helpt heel erg. Maar uiteindelijk is het ook maar gewoon gelukt dat iemand het ziet. Weet je? Het is in het algemeen wel mond-to-mond reclame. Dat denk ik wel, grotendeels. Dat zie je ook wel. Heb je dat veel gedaan? Nou ja, goed. Kijk, ik kom af en toe wel eens op conferenties en ik help best wel wat klanten natuurlijk. Dus ik kom weleens hier en daar wat. En je laat het gewoon zien, weet je. In dit geval is het een heel laagdrempelige library. Dus je voegt het toe en je kunt er aan het slag mee. Je hebt geen learning curve, weet je. Je hebt geen documenten die je moet lezen. Dat helpt natuurlijk allemaal. Maar het is meestal als mensen het dan zien. Oh ja, dat helpt wel inderdaad. En het is ook geen investment die je doet. Het is niet van ja, maar nu gaan we een framework adopteren. Ja, wat betekent dat voor ons? Weet je, wat voor impact heeft dat op de lange termijn? Dat is helemaal niet van belang. Ja, je kunt het ook een doer, zeg maar. Dat is een stap terug. Dat is zonder dat in één keer alles instopt. Dus dat is op zich het risico is redelijk klein om dit te gaan gebruiken. Als je in de JavaScript wereld zit en je moet in één keer een keuze gaan maken tussen we gaan Angular doen, we gaan React doen, we gaan Vue.js doen. Ja, dat is een hele andere keuze. Dat is een veel fundamentalere keuze. Architectuur gaat over de keuzes die je maakt en naar hoeverre die keuzes teruggedraaid kunnen worden. Bij dit soort dingen is het natuurlijk gewoon een no-deal. Ja, precies. Een non-issue. Non-issue, ja, precies. Een no-deal, het zal wel... Nee. Oh ja, jij zet er ook andere kanten aan. Dat is op zich gewoon een bijzonder verhaal, als ik dat zo kan zeggen. Kijk, het project bestaat tien jaar. Dat betekent dat je over die tien jaar hier en daar toch wel periodes had dat je dezelfde mensen die jou hielpen, contributors, die jou hielpen om het project verder te brengen. En ik heb nu een gozer uit Zweden, Jonas Nierup, die heel erg actief erin is. Maar die gozer, die is 3,24. Dus toen ik begon met het project, zat hij nog waarschijnlijk nog niet eens... was hij nog niet eens aan het studeren. Maar er is ook een jongen geweest uit de Verenigde Staten die jaren geholpen heeft. Die is gegeven moment ook in het Vreemde Legion gegaan. Omdat in een bepaalde fase van zijn leven heb ik zelfs nog een referentie geschreven. En vorig jaar kreeg ik een keer een reactie op een pull request in GitHub van zijn vader. Oh, wauw. Ja, echt. Van dit is de vader van die en die. En ik ben zijn accountant sluiten, want mijn zoon is overleden. Oh. Ja. Oh, en hij was... Natuurlijk, omdat hij in het Vreemde Legion is gegaan. Of daar niet mee te maken? Nee. Oh, oké. Nee, hij was depressief en heeft bepaalde keuzes gemaakt. Ja, moet ik toegeven. Ik ken hem nooit. Ik heb hem nooit persoonlijk gezien. Ik heb hem nooit gesproken. Ik heb hem nooit op video gehad. Maar ik heb wel jaren met hem toen nog op Flowdoc discussies gehad. Ja, dat is toch wel even dat je denkt van even slikken. Ja, dat hakte wel even in. Dat lijkt me wel, ja. En zijn naam is gewoon... Ja, die is gewoon tot het einde den dagen onderdeel van mijn code base geworden. Die zie je gewoon terug in commits en pull requests en issues. Ja, precies. Dan denk je toch eventjes van wauw. Sjongejonge. Ja, dat is wel waar. Ja, want het hoort altijd wel... Het komt wel wat dichterbij, zeg maar, als dit soort dingen gebeuren. Maar goed, het heeft natuurlijk ook wel met leven te maken. Dus ja, dat gebeurt dus wel. Ja. Ik vond het toch wel even de moeite waard om dat te doen. Ja, ja. Nee, dat is het zeker zo. Ja, ik bedoelde dat mensen die staan niet stil bij dit soort dingen. Had ik ook niet kunnen voorspellen, zeg maar. En er zijn altijd mensen die hebben natuurlijk altijd wat vraagtekens over TDD of BDD. Ja, dat moet je helemaal niet doen, want ja, stom. En mijn code, die werkt toch wel. Dat is wel een veel minder discussie dan voorheen. Maar je merkt af en toe komt er weer zo'n golf. Van ah, hoeft niet, weet je wel. Nee, dat is allemaal niet zo heel belangrijk. Ik weet niet hoe jij erin staat, zeg maar. Nou ja, ik kijk. Unit testen, TDD, ik doe dat nu denk ik bijna 15 jaar. En eigenlijk, het is jammer dat we geen visueel aspect hebben in deze podcast. Maar je hebt gewoon de hype cycle en daar heb je gewoon mee te maken. Je ziet gewoon dat, en daar ben ik zelf ook onderdeel van geweest, eigenlijk elke principe, elk concept waar we het over hebben, daar zie je gewoon een facering. Je ziet dat iemand het eens een keer hoort op een conferentie of een collega die erover vertelt. En dan zie je in het algemeen dat mensen zoiets hebben van, nou, weet je, daar moet ik hier mee, allemaal extra werk, weet je wel, dat hebben we niet nodig, ik ben goed genoeg erin. En dan worden ze enthousiast, dit vertel ik ook al eens op mijn presentaties, worden ze enthousiast, gaan ze toepassen, worden ze heel erg enthousiast, enthousiast, gaan ze helemaal los, gaan ze er misschien wel presentaties over geven, gaan ze blogs over schrijven. En dan ontdekken ze op een gegeven moment de keerzijde van zoiets. Want geen enkele tool is, ja, ik geloof niet een silver bullet. Dus wat je in dat gegeven moment ziet ontstaan, is dat mensen eigenlijk een beetje last van de keuze die ze krijgen. En daar een soort van mentaal een ombeslager gaan maken, waarin ze zeggen van, ja, nee, maar TDD, dat is gewoon, ik weet niet of je het mag zeggen, maar kut. Ja, dat was waarschijnlijk, ja. Ja, de vorige aflevering was ook redelijk... Ja, dat was redelijk direct, ja. Ja. Het is helemaal shit en het leidt naar koppeling en het zorgt ervoor dat je niks meer kan refactoreren en dat soort argumenten. En dan wordt het aan de kant geschoven. Dat zie je eigenlijk met heel veel technieken. Dat zie je met dependency injection containers, dat zie je met event sourcing als een architectuurstijl, coding standard, hetzelfde verhaal. En wat je dan eigenlijk ziet, is dat je heel veel van die senior developers hebben, die dat dan hebben afgesworen, want zij hebben namelijk gezien dat het niet werkt. Ik ben zelf heel erg bewust van die hype cycle. Ik heb zelf het idee dat ik wel redelijk ontdekt heb van wanneer dingen niet werken, wanneer ze wel werken, dat gaat alles. En TDD is precies zo'n voorbeeld. Ik ben ervan overtuigd dat het echt goed werkt, maar je moet het goed toepassen. Dat is nogal lastig. Je moet een goede testscope hebben en je moet het begrijpen wanneer je het wel of niet toepast. Je moet niet gewoon alles op die manier doen. Software ontwikkeling is gewoon best wel een creatief proces. En soms moet je gewoon een stukje code gewoon eventjes schrijven zonder te veel na te denken over testen. En als het werkt, als je een beetje de structure intact hebt, dan kun je alsnog de switch maken naar TDD. Ja, precies. Dus dat is eigenlijk gewoon een redelijk pragmatisch aanpak. Eigenlijk wel. Ja, dat is vaak wel de goede aanpak. Maar ja, je hebt natuurlijk altijd te maken met iemand die bijvoorbeeld dan net de boek opengeslagen heeft en die denkt, oh, ik heb een hammer en overal liggen spijkers. En dan slaat hij helemaal door. Dus het is die discussies, zeg maar, die zijn soms wel eens lastig. Ik vind het, ik vind ook, er is gewoon echt, of niet, ik vind zeker dat je wel TDD in je rugzak moet hebben. En ja, je moet het gewoon soms gewoon inzetten. Het helpt echt om de kwaliteit, nou ja, niet alleen de kwaliteit van de code, maar ook gewoon je design, zeg maar, of je structure. En ook, het is ook een beetje documentatie, dat werd weleens gezegd in het boek. Ik heb dat echt gewoon gezien. Weet je, als ik, een heel mooi voorbeeld, Fluent Assertions. Als ik wil weten hoe een bepaalde API hoort te werken, dan ga ik 9 van 10 keer gewoon naar de unit test. Want daar zie ik precies het specifiek scenario op een functionele manier beschreven, van dit is het gedrag wat dit stuk moet doen. En zeker als je wat complexere systemen bouwt, waarin je interne soort van architectuur boundaries hebt, die dan ook test, waar je test schrijft, die de hele boundary testen. Dus niet alleen maar één class, maar het hele ding. Dan geeft dat een heel mooi beeld over wat is nou het gedrag wat de code zou moeten laten zien. En dat is ook natuurlijk een van de belangrijkste dingen die je moet leren denk ik in TDD en BDD land. Zodra je dat niet onder de knie hebt en ook niet begrijpt, dan is alles inderdaad gewoon een spiker. En dan wordt het een soort van mechaniekje van ja, ik schrijf een test eerst en de rest geloof ik al. Maar het gaat echt over het hele ontwerpproces. Weet je, het is geen testtechniek. Het is echt een design techniek. Het dwingt je na te denken over de seams in je architectuur. Het dwingt je na te denken over wat zijn mijn interne boundaries. Hoe zeg je dat? Stukken van de architectuur die je los kan zien en los kan testen. Het dwingt je om na te denken over alle edge cases en de functionaliteiten van een stuk van je systeem. Het is echt gewoon een design techniek. En dat wordt al jaren geroepen natuurlijk. Maar goed, je moet dat zelf een keer ervaren hebben. Ja, precies. Het boek zelf, dat is het één, maar het is heel vaak met programma's. Je moet gewoon het doen, zeg maar. En je stoot een keer je hoofd en je maakt een fout. En daar krijg je natuurlijk die ervaring mee. Dat is natuurlijk een inkoppen, maar dat is niet voor iedereen per se heel logisch. Dus ja, wat voor vragen hebben we nog meer over vloer? Je ging er een presentatie over het runnen van een open source project. Ja, eigenlijk gaat het over alle aspecten die ermee te maken hebben. Het gaat over hoe ga je daar met documentatie om? Hoe doe je een stukje marketing? Hoe ga je er geld mee verdienen? Nou, dat stukje, daar ben ik nog niet helemaal uit. Nee, lijkt maar. Dat is niet gelukt. Ik heb natuurlijk een landing page gemaakt met behulp van Jackal en Githubpages. Dat is op zich wel een mooie stap geweest die we ooit gemaakt hebben. En daar zitten wat Google Ads op. Nou ja, dat is net genoeg om de DNS'en de domeinnaam te kunnen betalen. Maar het gaat inderdaad over het verhaal dat ik net ook vertelde over de ene jongen. Over hoe ga je nou om met contributions. De verschillende, ook heel specifiek. Ik doe dat dan op een .NET-conferentie. De stappen die we gemaakt over de jaren van de verschillende .NET-versies en het supporten ervan. En hoe ga je nou iets bouwen wat meerdere .NET-versies ondersteunt. Dat gaat dan een beetje ver. Maar Portable Class Libraries en .NET Standard en dat soort aspecten. Dat is best wel breed eigenlijk. Het is gewoon echt een softwareproject dat lang loopt. Alles wat daarbij komt kijken. Ja, interessant ja. Maar goed, je bent zelf eigenlijk de... Ja, ben je dan ook... Ja, in skrum term. Ben je dan eigenlijk de product owner ook? Of ja, goed, het is wel jouw ding, zeg maar. Dus dat is natuurlijk al best wel anders aan een open source project. Ja, ik ben de architect. Ik ben de product owner. Ja, precies. Ik ben misschien wel de QA-engineer. Dokvoeden doe ik natuurlijk ook gewoon zelf. Hoewel dat wat makkelijker is. Ja, en het is ook wel een soort hobby of een experimenteerdingetje. Als je... Kijk bijvoorbeeld in de .NET space is er nu een transitie ontstaan waarbij we onze beeldscripts in C-Sharp schrijven. Nou, Keek was daar de eerste versie van. Nu gaan we naar Nuke. Maar ook een oplossingsdingetje. Is dat geschikt voor een enterprise oplossing? Weet ik niet, maar we laten gewoon eens beginnen met het projectje om te zetten. Straks C-Sharp 8. Ik zie al mensen naar nullable types gaan kijken. Hoe kunnen we dat nou op zo'n project toepassen? Dus het is ook een beetje een proeftuin. Ja, precies. Maar wel gecontroleerd. Ja, ja, tuurlijk. Ja, goed. Dat is wel... Ook bij een assertion library is wel handig. Dat kwaliteit en testen, zeg maar, dat ook gebeurt. Dus dat lijkt me wel toepassing. En dat doe ik echt tegen de delen. Dat hele project is helemaal tegen de delen gebouwd. Absoluut. Zonder twijfel. Oké. Ja, we hebben... Ja, we proberen altijd een beetje zo ongeveer drie onderwerpen te doen. En dus we wissen van floor to assertion dat en de presentatie en het runnen van open source project, dat vinden we interessant. Dat vind ik zeker interessant. Dat ik denk, nou ja, misschien een idee om er altijd een keer met meerdere projectjes te bespreken. Ja, in een soort van panel. Maar goed, dat is echt, ja, toekomstmuziek. Dan moet je kijken hoe dat gaat. Dat is een ander onderwerp. Daar weet ik van. Ja, daar heb je wel wat verstand van. Denk ik. En ik noem dat wel eens developers porn. Omdat het eigenlijk heel... Ik vind het gaaf om te doen. Maar ja, mijn ervaring is, maar goed, daar moeten we het over hebben. Dat projecten kunnen best wel complex worden daardoor. Maar op een of andere manier geeft het best wel een kick. Je maakt het wel heel spannend. Ja, precies. Een intro die mensen prikkelt. Nou goed, het gaat eigenlijk over secretes en event sourcing. Nou ga ik dus niet meteen zeggen, ja, wat nou wat is en zo. Dus laten we daar gewoon eens even over hebben. En dat vooral de luisteraar een beetje een beeld krijgt. En ik begrijp dat je daar iets mee hebt. Nou ja, goed, kijk. Ik heb de fase dat ik het supergaaf en enthousiast was, heb ik inmiddels gehad. Ik heb ook de fase gehad dat, het gaat hier over architectuurpatronen, of een aantal architectuurpatronen, dat het ook minder goed kan werken. Dus ook hier heb ik inmiddels zelf het idee dat ik wel een beetje de balans heb gevonden. Maar ja, dit zijn twee eigenlijk architectuurstijlen, zou je ze kunnen noemen. CQS, Command Query Responsibility Segregation, is eigenlijk een soort van oplossing voor het feit dat in complex systemen er soms een soort vrijfing ontstaat tussen de verantwoordelijkheden van een domein, waar het over bedrijfsregels gaat en het bewaken van die bedrijfsregels, en het heel efficiënt data uit een database te krijgen. Als hier echt een DBA in tafel zou zitten, die zou meteen zeggen dat het laatste is geen probleem. Een database die snel kan alle problemen aan, is oneindig schaalbaar. Als je een beetje ervaren bent, dan weet je dat het zeker niet zo is. En een paar jaar geleden, misschien wel tien jaar geleden, was het heel populair om bijvoorbeeld je domein in een objector-orienteerde taal te bouwen, zoals .net, C-Sharp of Java of iets dergelijks, en dan gebruikte een object-relational mapper om dat dan in een database op te slaan. Die object-relational mapper zegt dan een beetje, probeert een beetje discrepantie op de vrijving op te lossen tussen een objector-orienteerde taal en de onderliggende relationele database model. En dat werkte goed voor een tijdje, maar wat je toch al in het algemeen zag, is dat je soms queries wilde uitvoeren die niet performden, omdat de datamodel niet geoptimiseerd is voor queries. Dan kon je oplossingen verzinnen als views en dergelijke. Ja, klopt. Daar heb ik nu de laatste tijd een beetje visie mee. Maar goed, ja, goed. Ja, maar dat is een probleem wat al heel lang bestond. Wat CQRS eigenlijk zegt, is van we accepteren dat dat toch wel een beetje twee verschillende problemen zijn, twee verschillende belangen. En dat gaan we omarmen door te zeggen van we hebben één kant van het systeem, en dat is een architectuuraspect, van die echt gaat over het domein en het bewaken van de business rules. En dat wordt vaak commands genoemd, business commands. En een andere kant gaat over geoptimiseerd om data zo snel mogelijk aan het systeem te krijgen. Geoptimiseerd voor het querien. Het is in feite het CQS-pattern, wat eigenlijk in Petra Maya komt. Ja, heel oud. Heel, heel, heel oud. Maar dan op architectuurniveau, om die verschillen te onderkennen. Ja, dat is eigenlijk een heel los pattern. Dat kun je ook toepassen met een relationeer model. Je kunt misschien views bouwen, materialized views, achteren constructies. En dat is een vrij gebruikelijke architectuuroplossing. Ik gebruik dat nu al best wel, ik denk zeker twaalf jaar. Nou, dan heb je daarnaast nog een ander patroon. En dat gaat meer over van, hoe sla ik nou eigenlijk de data die in het domein staat op een efficiënte manier op? Kijk, wat je met een ORM doet is, je legt een mapping tussen een object. Bijvoorbeeld een product of een order of iets dergelijks. En die sla je gewoon rechtstreeks in een tabel op. Waarin bijvoorbeeld producten staan of orders of iets dergelijks. Maar wat je ook kunt doen, is event sourcing toepassen. Event sourcing, het zit al een beetje in de naam. Source, de bron van je data, zijn de events. De events zijn eigenlijk, het zijn de dingen die gebeuren in het domein. En dat zijn niet zomaar events, dat zijn ook echt het werkelijk business acties of gebeurtenissen vanuit het domein. Ook benoemd, vaak wordt ook die taal gebruikt, die je opslaat in je database. Dus in plaats van dat je een product opslaat in een tabel met genaamd producten, sla je eigenlijk alleen maar een soort van historie op. Wat is er met het product gebeurd? Het product is in de katalige scherm traduceerd. De productprijs is aangepast, de productleverancier is aangepast. Dat soort informatie kun je gewoon terugvinden. Het gave ervan is dat je eigenlijk toch al een soort van, ja, je hebt eigenlijk een compleet audit log. Je kunt compleet terugzien vanaf dag 1 wat er in je systeem gebeurt. Ik krijg eigenlijk gratis, zeg maar. Bijna voor niets. Is ook fantastisch voor socks compliance en dat soort soort systemen. Wat je dan doet met die event, kijk, uiteindelijk wat je dan ziet is dat je een hele platte tabel hebt. Je kunt er ook eigenlijk niet meer op queryen. Het enige wat je kunt doen is van voor dit specifieke product, product X, Y, Z, wat is er gebeurd? Maar je kunt niet zeggen geef mij alle producten waarvan de prijs hoger is dan duizend euro of zoiets dergelijks. Dat gaat niet meer. Die informatie is er niet. Het voordeel ervan is dat je database heel simpel kan zijn. Je hebt geen relationele database meer. Een NoSQL oplossing of misschien voor de Azure fanaten onder ons en Azure, table storage ofzo kun je daarvoor gebruiken. Want je hebt helemaal geen eisen meer aan een relationeel model. Maar je hebt toch iets nodig om te kunnen queryen. Dat is het leuke ervan. Omdat je precies weet wat er gebeurd is in je domein, welke veranderingen zijn doorgevoerd. Want je hebt eigenlijk gewoon een stroom van events waarin het precies staat dit zijn de gebeurtenissen geweest. Kun je die data gebruiken om eigenlijk een querybaar model te bouwen? En de meest voor de handliggende oplossing is je bouwt gewoon eigenlijk een soort van relationeel model op basis van die events. Die je zo kunt construeren dat je heel snel op kunt queryen. Je kunt bijvoorbeeld bij wijze van spreken al een lijst bijhouden waar alleen maar de producten in zitten die meer dan duizend euro waard zijn. En alle producten die minder zijn die sla je niet eens op. Want dat heb je die informatie. En dat is een hele kleine tabel. Dat noemen we ook wel projecteren. Event storage komt met allerlei nadelen trouwens. Maar dit is wel een van de grote voordelen. Want die tabellen zijn allemaal onafhankelijk. Je kunt je hele database structuur bijna oneindig schalen. Er zitten geen relaties meer tussen de tabellen. Je bouwt gewoon... Je kunt zelfs, en dat is ook wel cool, je zou zelfs al een HTML pagina kunnen produceren. Ja, precies. Dus eigenlijk je genereert iets wat geoptimaliseerd is voor een specifiek doel. Ja, precies. En dat hoeft allemaal niet sigoon te gebeuren. Dat kan ook acingoon gebeuren. Maar het maakt het dus gewoon mogelijk om de querykant bijna onbeperkte schalen. En dat is een hele krachtige techniek. En wanneer zou je het niet willen gebruiken? Absoluut niet. Ja, dat is een lastige. Want weet je wat het is? Op het moment dat je ergens... Als je heel behendig wordt om iets te gebruiken, dan gaat het heel erg voor de hand leegend om het by default te gebruiken. Dat is wel gevaarlijk, hoor, trouwens. Ik heb wel geleerd dat event sourcing en Greg Jong, die dat een beetje bedacht heeft en dat ook populair heeft gemaakt tien jaar geleden, zegt ook... Het is eigenlijk geen, wat ze noemen, top-level architectuur. Het is geen architectuur die je gewoon by default op je hele systeem moet leer neerleggen. Het is eigenlijk een stijl die van toepassing is op een stuk van je systeem. Ze zeggen ook het algemeen, event sourcing is heel erg nuttig op het moment dat je of wel een heel erg high-performance systeem moet bouwen of als bijvoorbeeld heel veel gebruikers dezelfde data moeten bewerken. Dus als er heel veel... Hoe zeg je dat? Nederlands en Engels is contention. Normaal gesproken, als jij een document bewerkt, dan ben je negen van tien keer de enige persoon die je bewerkt. Maar op het moment dat je documenten bij heel veel mensen tegelijkertijd aan gaan werken, dan wordt het heel erg interessant. Want dan kun je die events, die kun je namelijk ook merger. Ja, precies. Je kunt zien dat iemand aanpassingen heeft gedaan in een bepaald tijdsbestek. Iemand anders heeft ook aanpassingen gedaan. En dan kun je heel erg functioneel met de business owner bepalen van, hey, als twee personen allebei de titel van het document hebben aangepast in hetzelfde tijdsplaatje, wie gaat er dan voor? Ja, precies. En dan zegt de product owner, ja, misschien die laatste die gewonnen heeft. Maar als de ene persoon de titel van het document aanpast en de andere persoon de beschrijving aanpast, is dat in het traditionele systeem, is dat vaak een probleem. Dan krijg je een soort optimistic concurrency fault. Maar hier kun je wel zeggen, ja, het zijn twee verschillende aspecten van het document. We accepteren ze allebei. Ja, precies. Dat kan niet met een traditioneel CRUD of ORM gebaseerd systeem. Ja, want in principe zit dat in het CRUD systeem. Ja, dat hoeft niet. Normaal sproken zit dat heel erg impliciet in het model van laserschrijven en tegelijk een concurrency. Dus dat nemen we dan maar voor lief. En dan als iemand dan, toen is het mijne van, als mensen horen over CRUD, dan denken ze, ja, maar waarom moet het allemaal zo expliciet en zo. Maar ja, dat zit eigenlijk ook. Dat is zo ingewikkeld ook vaak. Ja, precies. Maar hoe moet het zo ingewikkeld? Ja, en het is ook best wel een pittig patroon, zeg maar. Maar het is wel heel gaaf om te doen. Dat is mijn. Ja, het is nog niet mainstream genoeg. Zou het ook niet moeten zijn eigenlijk, want als het mainstream is, dat slaat natuurlijk nergens op. Ieder architectuurprobleem is uniek en je moet gewoon de beste oplossing ervoor gebruiken. Het voordeel van CRUD en ORM oplossingen is dat er al zoveel tooling voor beschikbaar is en zoveel documentatie. Maar ik moet zeggen, ik volg ook op Twitter elke dag alles wat met event sourcing te maken heeft. En je ziet echt wel de laatste twee jaar dat er enorme spurt is doorgemaakt. Dat het populairder is geworden? Populairder. Ja, ja, oké. Zeker ook buiten. Ik weet nog een paar jaar geleden dat ik op Qcon in San Francisco was. Toen hoorde ik voor het eerst het woord event sourcing vallen. En het was dan toevallig ook echt schaap. Dus weer tot net. Maar nu is het zo gebruikelijk. Je ziet het op elk platform en wordt het gewoon toegepast. Ja, ja, precies. Maar het is zelf volgens mij ook een noodje eerst. Ja, dat is overal. Ik bedoel, je zou een JavaScript of maakt niet uit. Zeker. Ik zie het wel eens langskomen en dan denk ik, oh ja, that makes sense. Sterker nog, volgens mij is het, als ik het goed heb, Pauline had via Twitter als ze een vraag gesteld over event sourcing, dacht ik. Dus van, ja, je kan niemand mij daarmee helpen ofzo. Nou, verder heb ik de inhoudelijk weet ik niet eens. Heb ik ook niet gevraagd de vorige keer. Maar dat was wel toevallig. En zij doet PHP. Dus dat wil niet zeggen dat het niet kan, maar dat is ook, bij PHP komt het wel eens voor, zeg maar. Nou ja, kan je zeggen dat de Domain Driven Design, wat ook al gerelateerd erin is, erg populair in de PHP wereld is. De organisator van de DDD Europe Conferentie, de grootste DDD Conferentie in Europa, is een PHP ontwikkeler. Ja, ja. Dat zegt al wat. Was ik ook echt verbaasd over trouwens, hoor. Ja, nee, we hebben volgens mij, volgens mij, en dat ging over hexagonal architectuur of opzet, ja. En ja, goed, hij maakt er zelf wel grap over. Ja, ja, PHP en zo. En die maakt er best wel lucht in. En op zich zijn sommige dingen makkelijker, zeg maar, in PHP te doen dan in .NET. Dus dat viel me dan ook wel weer op. Dat is voor mij dan, ja, was wel een eye-opener op dat moment. Dus ja, je neerkijken op PHP is een beetje, ja, als je er geen ervaring mee hebt, is dat een beetje, ja, flauw. Maar goed, aan de andere kant, ja, mensen hebben gewoon een mening over PHP. Dat is al misschien een kern van waar het is. Maar ja, er zijn natuurlijk ook mensen die heel slecht JavaScript schrijven. Je kunt ook heel goede JavaScript schrijven. Dat is ook wel... Ja, je kunt heel slecht JavaScript schrijven. Ja, heel snel en heel makkelijk. Dat is me ook opgevallen. Ja. Je kan ook heel slecht .NET-code schrijven. Ja, ja, dat ben ik gewend. Dat is gewoon mijn norm. En dat had ik af en toe. Ik denk, ik denk dat dat soort talen, ja, weet je, ik associëer het gewoon met mijn history. Ik gebruikte het gewoon als hobby-taaltje, weet je wel. Gewoon de eerste keer. Oh, ik kan nu een code uitvoeren, weet je wel. Of PHP bedoel je? Ja, PHP of JavaScript in een browser, weet je wel. Oh, wauw. Ik kan koden. Ik kan iets in de browser dynamisch laten werken. Precies. Het was gewoon een beetje een hobby-tooltje. Sommige mensen maken daar een werk van en krijgen ervoor betaald. Ja, ja, precies. En op een gegeven moment kom je dan bij wat enterprise-achtige bedrijven te werken. Ja, en dan leer je echte programmeertalen zoals Java of Totnet. Nou ja, ik moet wel zeggen dat die wereld wel aan het veranderen is. Kijk maar hoeveel JavaScript op de backend tegenwoordig geschreven wordt met Node.js. Dat is ook weer zo, ja. Dat zijn hele stromingen. Ja, we hadden het de vorige keer ook over Go, Rust en een aantal andere talen. Kotlin. Ja, Kotlin. Ja, Kotlin. Daar hebben we ook wel heel goede dingen over. Dat is wel de Java-platform toch ook? Volgens mij is dat op de Java runtime. Ja, op de runtime, ja. Ja, dat Java runtime, dat heeft wel een soort van katalysator geweest voor allerlei talen die ontstaan zijn daarna. Ja, dat viel me wel op. Ja, in principe is dat ook best wel logisch. Ja, er is iets en dat was een tijdje geleden. Nou ja, een tijdje geleden. Volgens mij is de AVG, vorig jaar of zo, twee jaar geleden. Ik weet niet eens wanneer dat ingegaan is. Ja, ja. En dat kan wel impact hebben op een event sourcing project, toch? Ja, dat klopt. Maar dat is wel een opgelost probleem. Er zijn al verschillende artikelen over hoe je dat zou kunnen oplossen. Maar stel dat ik dus nu, stel dat we als bedrijf zijn dat je een, nou ja, je doet een event sourcing. Je bent de laatste, weet ik veel, vijf, zes jaar heb je een mooie event stream opgeslagen. Ja. En nou, dat zijn allemaal, nou noem maar eens iets, klantgegevens. Ja, dat is denk ik het meest relevante. En ja, dan komt er een jaantje die denkt, nee, leuk. Nou, ik wil vergeten worden. Ja. En wat dan? Ja, ik weet niet of je show notes hebt of iets dergelijks. Ja, die kunnen we sowieso maken. Een van die oplossingen die ik een keer heb voorbij zien komen, wat op zich wel leuker is, is dat je al je events encrypt met een public-private key. Dat je die keys associeert met intervallere personen in je systeem, dus gebruikers. Ja, ja. En op het moment dat die persoon vergeten worden, gooi je ook de key weg, waardoor je die events nooit meer kunt encrypten. Oh ja, dat is slim. Dan heb je eigenlijk, kijk, dan kun je natuurlijk ook fysiek de data gewoon weggooien. Ja, ja, ja. Dat is natuurlijk ook gewoon, ja. Maar je moet, maar moet je niet alles dan compleet opnieuw afspelen, of is dat? Ja, dat ligt een beetje aan hoe je het gebouwd hebt. Kijk, je hebt natuurlijk het probleem is dat je dan een stukje van je waarheid ongedaagd gaat maken. Ja, ja. En dat ligt ook een beetje aan hoe kritisch het systeem is en hoe dogmatisch je dat wilt toepassen. Ja. Als je dat, als je het intact wilt laten, als je in ieder geval intact wilt laten dat er iets geweest is. Ja. Ja, dan zou je dat trucje kunnen uithalen door gewoon alles te encrypten en dan die key weg te gooien. Dan is dat event er nog wel. Ja. En je kunt ook zien wanneer het event gecreëerd is en dergelijke. Maar de inhoud ervan is gewoon weg. Ja, precies. Daar kun je niks mee. Nou goed, maar kun je dat achteraf doen? Is dat, is dat bedoeld? Ja, dat kun je achteraf doen. Oh ja, oké. Kun je zeker. Ja, dat lost wel op. Of dat is wel praktisch. Als je, als je accepteert dat je achteraf jouw event store gaat bewerken. Dat is wel waar. Je zou ook een nieuwe event store op kunnen bouwen opnieuw ernaast. Die origineel laten staan. Maar goed, dat is met AVG natuurlijk juist. Dat stukje data moet gewoon weg. Ze willen gewoon zien dat het weg is. Ja, precies. Dus dat is daar natuurlijk niet. Dus er zijn meerdere oplossingen voor. Je moet het gewoon weg gooien. Maar dan moet je wel een mechanisme hebben om te zeggen van, kijk, je hebt dat CQS aspect bij event sourcing. Die event store ga je events weg gooien. Maar je hebt nog wel wat we dan projecties noemen. Dus tabellen die daar op gebaseerd zijn. En je moet er dan wel weten dat de data is weggegooid. En vaak wat je dan doet, is daar weer een apart event voor introduceren. Waarin je zegt van, hey, we hebben iemand uit het systeem verwijderd, vanwege AVG bijvoorbeeld. En dat zelfde event wordt dan gebruikt om al die projectie tabellen op te schoenen. Ja, precies. Dat kun je op die manier oplossen. En dat maakt het ook heel zichtbaar. Dan kun je ook achteraf zien van, hey, er is iemand uit het systeem verwijderd vanwege een AVG-verzoek. Ja, precies. Ja, oké. En dat maakt het weer voor al dat ding heel erg nuttig. Ja, want er wordt altijd een relationeel data. Ja, dat is heel makkelijk. Dan ga ik kijken. Doe ik even een selectje, een awaretje. Hoe vaak gaat dat goed? Ja, nee, precies. Dan weet je misschien niet helemaal wat de implicatie is. En je weet ook niet waarom die data uitvalt. Die context heb je in principe niet normaal gesproken in een relationeel database. Je hebt alleen maar de huidige state. Ja, precies. Je weet niet waarom, tot hoe je door tot die informatie bent gekomen. Dat is zo nuttig. Ik heb zo'n voorbeeld gezien dat een collega van mij een productieprobleem had, waarin een aantal objecten in het systeem in een bepaalde state terecht kwamen, waardoor het systeem vast zat. Het document kon niet meer gesloten worden of iets dergelijks. Het was daar heel domeinspecifiek. Het coole eraan is, hij kon dus aan die eventstop precies zien wie wat had gedaan in de weken daarvoor, hoe die daar gekomen was. En op basis van die informatie, kon hij uiteindelijk een hypothese opstellen van hoe die bug ontstaan was. Oh ja. Anders had hij dat nooit van zijn leven boven water gekregen. Nooit kunnen achterhalen. Maar goed, ja, ik heb daar heel veel over geblogd. Er zijn ook heel veel nadelen, net zoals elke oplossing. Dat kun je daar allemaal vinden. Ja, het is ook best wel een pattern, zeker in... Ja, wat nu steeds meer is, zeker als je cloud oplossingen hebt, dan moet je al wat meer over gedistribueerde systemen nadenken. Ja, dat wil niet per se zeggen dat CQS daarbij helpt, maar nou, dat kan het helpen. Dat is misschien wel een vraag. Ja, ja. Kijk, wat je ook doet, als je database met groot genoeg wordt, zit daar een schaalbaarheidslimiet. Want je applicatieservice kun je er gewoon bij schrijven. En zeker met moderne spa, single-page applications, react en dergelijke. Wat allemaal stateless is, kun je natuurlijk je applicatieserver heel erg uitschalen. In AWS, Amazons platform kun je gewoon een autoscalinggroep opzetten en dan zet je die op zes en dan worden er gewoon zes applicatieservice gestart. Maar je database blijft uiteindelijk in beperking, hoe groot die ook is. En helemaal als je ook nog eens een keertje regionaal of hoe noem je dat, geografisch gedistribueerd wil zijn, ja, vaak zit er dan een soort transactie omheen. Op het moment dat je event sourcing met CQS toepast, dan is het veel makkelijker om data te partitioneren, omdat er geen directe relatie meer is tussen al die tabellen. Dus je kunt dat veel verder uitschalen, op een hele makkelijke manier. Er zitten heel veel mogelijkheden achter. Ik kan me voorstellen dat je ook makkelijk je hoofd stoot. Oh, heel erg makkelijk. Ik heb wel als een presentatie van jou meegemaakt, online zie je dat, en dan merk je wel dat het wordt, ik weet niet of het nu volwassen zijn, maar je merkt altijd wel een soort van volwassenheid. Dus hoe CQS en event sourcing misschien tien jaar geleden gedaan werd, of de presentatie die ik hoorde, dat is misschien wel anders dan nu. Mensen zullen nu wat pragmatisch zijn, ze hebben wat meer ervaring opgedaan. Er is ook heel veel materiaal nu. Vond Fernon heeft al inmiddels al twee boeken geschreven over het toepas van event sourcing. Greg Young heeft net een boek afgeschreven over de fascineringsaspecten die te maken hebben. Maar hij ziet ook weer een hele nieuwe stroom van mensen, die nu ook eens in een keer voor het eerst event sourcing horen, en daar weer over bloggen zijn. Dus het wordt nu zo mainstream dat er heel veel mensen er nu over gaan praten, in allerlei verschillende platformen en, hoe zeg je dat, vakgebieden, die waarschijnlijk weer tegen dezelfde problemen aan gaan lopen. Dus ik ben ook elke dag bijna weer een tweet aan het plaatsen van, je moet even mijn blogpost lezen, want al je problemen die je tegenaan gaat lopen, die heb ik al eens een keertje beschreven. Ik ben ook altijd benieuwd hoe event sourcing met integratietesten, hoe je dat nou echt doet op een goede manier. Op dezelfde manier als met alles. Net als elke functionele requirement. Het leuke van CQS is dat je eigenlijk al onderkent dat er twee werelden zijn. Je domein en de query kant. En omdat dat eigenlijk ook twee werelden zijn die onafhankelijk van elkaar evalueren. Er zijn, als er een nieuwe functionele requirement zijn over business rules, dan verander je je domein kant. Als je informatie op een andere manier wil presenteren, dat is puur een query kant. Dat zijn ook vaak onafhankelijke requirements die je op een ander tempo ontwikkelen. Als je dat nou onderkent, dan weet je al dat je eigenlijk nooit testen zou moeten schrijven, die end-to-end zijn. Althans, je moet ook testen schrijven die end-to-end zijn, maar niet alleen maar dat. De boundary, de scope van je test, zou eigenlijk in principe voor unit test zeker niet meer moeten zijn dan ik voer een commando uit of ik voer een actie uit op mijn domein en ik verifieer dat er een event is uitgekomen. En een van de textbook examples die ik ooit van Greg Jong heb gehad in 2009 of 2008 zelfs, toen ik met training voor het eerst hoorde bijwoner, is dat heel veel mensen testen nooit of het uitvoeren van een actie op het domein een side effect veroorzaakt. Een andere woord, op het moment dat ik een actie uitvoer op mijn domein, een product bijvoorbeeld aan een order toevoeg, dan kijken we wel vaak van, is dat dan op een goede manier gelukt? Maar we kijken nooit of er andere dingen gebeurd zijn. Ja, want dat is meestal, vind ik altijd, heel fijn aan quality engineers in teams. Die gaan altijd vanuit het negatieve iets aanvallen. Een ontwikkelaar is vaak niet. Ja, die bedenkt, als ik ze zou vragen van, en bedoel ik een ontwikkelaar dus, als ik zou vragen van, joh, werkt dit? Ja, want het komt erin en het komt eruit. Oké, maar wat als? Ja, precies. En die wat als, dat wordt wel... Nou ja, dat gaat hand in hand met TDD natuurlijk. Als je dat op die manier insteekt, dan ga je ook nadenken over die edge cases. Maar event sourcing maakt het ook vrij makkelijk, want ja, als het moment dat er een actie uitkomt, dan moet er één event uitkomen. Er zou niks anders uit kunnen komen. Ja, dat is waar. En dat karandeer je eigenlijk daarmee. Ja. Dat is een voordeel hoor. Het is niet zo'n heel sterk voordeel, maar het werkt wel op die manier. En op dezelfde manier kun je ook testen schrijven, die bijvoorbeeld zeggen van nou, vanuit gaan dat er een aantal events zijn gebeurd. Hoe zou mijn HTTP API moeten, wat voor informatie zou je moeten teruggeven? Dus je kunt dat ook als een scope zien. Testen die eigenlijk de kwere kant verreveren. Nee, nee. Het is inderdaad duidelijk. Dus ja, wat dat betreft geen andere strategie wat dat betreft. Het is nog steeds een requirement die je zou moeten valideren. Maar ook om hem te falsifyen. Dus ook falsifying test zou je daarin ook moeten opnemen. Ja, zeker. En dit is natuurlijk, we hebben nu eigenlijk twee hele technische patterns genoemd. Domain driven design zie je eigenlijk ook hand in hand gaan. Omdat, en dat zeggen ze ook, events zijn niet zomaar technische dingen die gebeuren in je domein. Die moeten ook echt representeren wat er functioneel gebeurd is. Dus negen van tien keer wordt er ook gezegd, en eigenlijk zou je dat ook moeten volgen, wordt de term, misschien heb je het wel eens gehoord, de ubiquitous language gebruikt. De taal van de business. Dus die events zijn ook eigenlijk altijd beschreven in de taal van de business. Want dan kun je ook het onderscheid maken van, is het adres van een persona veranderd omdat er een foutje in zat? Of is het adres veranderd omdat die verhuisd is? Ja, precies. Dus tegen verschillen kun je een relationeel model eigenlijk niet vangen. Nee. Maar in een event store, of een event source, een gebaseerde systeem, zeker als je ook het hele domain driven design aspect meeneemt, kun je dat best wel goed meenemen in het systeem. Kun je dat vastleggen en terughalen? Ja, precies. Want het is ook een beetje een voorbeeld, want ik was tegen klanten en dan probeer je een taakgedreven UI, zeg maar, zodat je echt weet van, kijk, de oude wedstrijdschermen waren heel erg, bijna één op één geënd op de database tabellen, zeg maar. Dus je had gewoon alle velden die in de database stonden, en dan had je een save-knop en een cancel-knop, en dat was het. En je sloeg gewoon data op en dan wist je, je had geen context, zeg maar. Je wist dus niet van, oh, hij heeft nu zijn adres gebeurd, want hij is verhuisd. Dat weet je niet. De intentie was je... Exact, precies. En dat vind ik dan heel gaaf. Dus als je dus wel die taak of de intentie van de actie die je doet, dus je wijzigt een adres of je zegt van, kijk, ik wil nu een verhuizing doen, geef nu het nieuwe adres, dat wordt doorgegeven naar de backend en dan wordt een command en dan komen je fans uit, dan weet je ook waarom dat gebeurd is. Dus dan is het niet zo'n droge data-verhaal, zeg maar. En dat vind ik ook heel erg gaaf, alleen dat kost best wel wat effort om dat bij mensen, zeg maar, tussen de oren te krijgen, omdat best heel veel mensen, en ook zelfs opdrachtgevers, productoners, eindgebruikers, die denken, die zijn gewoon geconditioneerd en dat is er gewend geraakt om in data te denken, oké, dat staat nu in de database, dus dat is één op één en die vracht er gewoon een safe-knop, heel veel mensen zijn dat gewoon gewend. En wat wij vanuit software ontwikkeling kunnen doen, is constant vragen, ja, welk doel wil je hiermee bereiken? En dan kom je ineens op een veel flexibere, of misschien wel een makkelijkere oplossing. Betrokkenheid van je product owner of business analyst, wat dan ook, wordt heel erg belangrijk om dit te doen, anders gaat het gewoon niet werken. Maar goed, ik heb ook ervaren, software ontwikkelaars gesproken die zoiets hebben van, ja, allemaal complexiteit, en dit kan ik ook gewoon met een relationele tabel doen, een DBA'er of een database georienteerde ontwikkelaar, zal zeggen, ja, ik zet gewoon change tracking op die tabel, dan heb ik hetzelfde effect. Meestal geef ik het allemaal gelijk op, dan zit je toch op een andere golflengte te praten. Kijk, dat is ook met software ontwikkeling. Je kunt in principe alles doen. Je kunt ook met iemand, een ontwikkelaar, kan heel makkelijk het tegendeel bewijzen. Als iemand zegt, ik kan met change tracking, dan kan ik blijven programmeren, en ik ga bewijzen dat ik het op die manier ook goed kan doen. Ik kan ook business rules bouwen, en het stort precies. Ja, precies. Het gebeurde vaak. Sterker nog, het gebeurt nog steeds. Dat voel ik wel een beetje zorgelijk altijd. Hele conferenties heb ik bij gewoond waarin dat gebeurde. Je ziet geluk niet meer zo veel gebeuren. Of programmeren in Excel. Je moet ergens beginnen. Ja, dat is waar. Het is wel een lage drempel, toch? Ik kan een grapje vertellen, maar mijn eerste programma ooit was eigenlijk op mijn komende 64. Zo oud ben ik. Volgens mij enig wat ik deed, is een programma schrijven van twee regels. De eerste regel was 10, en dan stond er gewoon een stukje tekst. En wat ik dan kon doen is list, en dan zag ik output. En toen dacht ik dat ik het programmeerde. Echt list, liet me de code zien, en dat dacht ik dat was. Totdat je het boek gaat lezen, en dan ontdek je ervan dat je zegt 10, print, hallo, 20, code 10. Ja, dat herinner ik. Ik heb ook geprogrammeerd op komende 64, ik heb er nooit één gehad. We hadden ergens heel lang geleden in Tilburg, want daar kom ik vandaan. Dat was niet te horen? Nee hoor. Alles bij de barts vanmiddag, 2 komendoor staan, een Vic 20, zeg je ook wel iets, en een 64. En dan stonden er 2. De donkerbruine was de 64, en licht cremeachtig. Ja, precies. Net geen gebroken, whatever. En dan was het altijd een strijd, als ik diegene niet als eerste was, die had natuurlijk de komende 64, want je had meer geheugen, niet dat ik dat nodig had met mijn programma. Het is niet alsof ik die 64 kilobyte nodig had, want ik schreef dus echt 10, print dat, 20, code 10. En soms had je een programma met je snake, het was niet de echte snake, maar als je bleef printen, dat is het scrollen natuurlijk, en dan kon je een slang maken, dus dat hoefde je alleen maar van links naar rechts. Dat was heel makkelijk te programmeren. Je dacht echt dat je de koning was, dat was allemaal bij de bar smitten, dat had ik echt, ik wil een computer, nou, het is een beetje duur, zeg maar. Dus dat duurde even voordat ik thuis een homecomputer had. Maar ja, die komende 64, volgens mij is dat echt voor mij in ieder geval de eerste computer waar ik een soort van had programmeren. Dus misschien is dat een... Ik kan me nog heel goed erin dat ik me ontdekte dat er ook een soort van demos waren met muziek, muziek in beelden, en dat vond ik zo machtig, weet je, dan had je Axel F, dat oude nummer, weet je, van Beverly Hillscope, Axel Foley, en Axel Foley, dat kwam gewoon uit een computertje, weet je wel, het was een sitproces, ik heb niet eens meer waar het voor stond, waarschijnlijk iets van sound, Ja, want je had die, hoe noemen ze die dingen? Chiptunes volgens mij. Zo klopt dat, maar het was machtig dat je gewoon muziek eruit kwam in die tijd, en op een gegeven moment had je ook samples erbij, nou ja, weet je, de huidige generatie weet, ja, fasttracken, dat kwam daarna nog, dat is veel later nog, moet je nagaan, ik heb het hier echt over, ik heb mijn eigen fasttracker, soundtracker nog gebouwd ooit. Nou, ik heb, na de eerste keer dat ik ben begonnen met programmeren was op een, met een dos batch script, want ik had toen op een gegeven moment het commando beep ontdekt, en die kon je dus helemaal instellen, weet je wel, in allerlei noten, hoe lang en dat soort dingen, dus ik had echt een liedje uiteindelijk, had ik daarin geprogrammeerd. Dat is wel grappig, want er is nu een ding waarmee je dat gewoon, waar je echt muziek mee maakt, dat heet Sonic Pi, en dat is helemaal gebaseerd op de principe. Er is een Engelse gozer, Sam Aaron heet hij volgens mij, die heb ik zien optreden op een conferentie recentelijk, die heeft gewoon, volgens mij een Pearl ofzo gebouwd, of PHP, het is PHP gebaseerd, waarin je gewoon met biepjes en dergelijke en loopjes, gewoon complete muziek bouwt. Het is zo geoffenseerd, daar gebruik je ook om leerlingen te leren programmeren, daar doet hij gewoon echt concerten mee, optredens, echt ongelofelijk. Nog steeds hetzelfde principe. Ja, dat is wel cool. Op naar het volgende onderwerp? Ja, genoeg over, ik heb verder geen vragen, het volgende onderwerp, niet echt een onderwerp, zeggen we iedere keer, want we hebben er niet goed over nagedacht. Nee, doen we nooit. Dus we doen maar wat, en dan vullen we de laatste, ja, ik weet niet hoeveel minuten, vullen we nog even met links en rechts wat dingetjes. Het grappige is, je had het een paar keer over de hype cycle, dus die hebben we hier in de voorbereiding, de voorbereidingsnotes hebben we ook staan. Daar op voorbedurend, zeg maar op die hype cycle, nou, we zijn volgens mij al best wel een poosje, je hebt door de Commodore 64 gehad, dus je bent niet pas vijf jaar software ontwikkelaar, dus je hebt denk ik in je carrière, want het is ook wel serieus wel een carrière die je achter de rug hebt en die nog doorloopt, dus even Benny Pangja, precies, die best wel wat nieuwe technologie gezien en golfbewegingen, et cetera. Is er nu technologie, zeg maar, waar jij nu echt super enthousiast over wordt, dus die echt gewoon op de peak of inflated expectations zit. Dat mag van alles zijn, het hoeft niet per se tot net te zijn, het maakt me niet uit, het is gewoon best wel een brede vraag, dus vul hem in zoals je wilt. Dat is wel een moeilijke vraag, want ik heb dat algemeen sowieso niet zo snel. Nee, maar ik bedoel, tot net was wel gaaf, vooral toen het nieuw was. We zijn nu inmiddels bijna 20 jaar verder volgens mij. Eind 2000 is de Nederland geïntroduceerd, het is nu 2019, dat heeft zich wel bewezen. De hele JavaScript wereld, had ik dat verwacht? Nee, niet. HTML, dat is al heel lang succes. Ik ben daar niet zo goed in het algemeen. Op dat vak volg ik een beetje de mensen. Ik zit niet in een beetje erachter. Als ik iemand wat dingen erover hoorde, ga ik er wel naar kijken of het iets mee kan. Maar ik kijk ook altijd naar vanuit een pragmatische insticht. Kan ik er echt iets mee? Ik vind bijvoorbeeld Git, daar heb je al een hele sessie over gehad, vind ik echt wel een disruptive technology. Dat verandert, het is niet alleen maar een source control systeem, het verandert gewoon de manier hoe je software bouwt. Zeker in combinatie met GitHub, het verandert echt hoe je je architectuur neerzet. Het wordt veel makkelijk om dingen op te splitsen, hoe je teams dan er abstract aan sluit. Conway's Law gaat daar ook wel een beetje over, maar dat is wel een dingetje wat ik vrij speciaal vond en in het .NET space hebben we Owen. Het feit dat je je HTTP APIs op zo'n manier kunt bouwen, dat je componenten kan bouwen, die eigenlijk agnostisch zijn, die niet weten hoe ze gehost worden. Ik weet eigenlijk niet zo goed, ik heb daar nog niet echt een alternatief van gezien in andere platformen, maar dat vond ik echt wel een technologie die componenten gebaseerd ontwikkelen, wat natuurlijk 30 jaar geleden ook een ding was, wel heeft geholpen, maar voor de rest ja, het komt en gaat. Ik heb weinig met AI, ik heb weinig met augmented reality en dat soort aspecten. Heb ik te weinig toegevoegd, zie ik te weinig pragmatiek in, kan ik niks mee overdag? Nee, dat snap ik wel. Nee, er is niet echt iets waar je op dit moment warm vallen. Ja, precies. Ik zit heel vaak, zeg maar, dat ik heel enthousiast ergens over word, maar ik herken wel wat jij zegt, dat je niet per se, hoe zeg je dat, heel erg gehyped wordt door een technologie, want je denkt nou, laat me eerst even kijken als we over dat piekmoment zijn, wat gaat het nu doen? En dan hou ik het wel in de gaten, want ik wil er wel heel graag even van proeven, dat ik een beetje een mening heb, maar dan is het niet meteen voor mij dat alles op die manier, dat had ik bijvoorbeeld, nou die had Dokken bijvoorbeeld, Dokken containers, was ik heel enthousiast over, want ik had niet meteen zoiets van nou, we gaan alles met Dokken containers doen, maar ik denk, dat is wel iets waar heel veel potentie in zit. Nou, het blijkt nu ook wel dat het echt wel heel populair is, dat betekent niet dat ik een soort van gelijk heb gehad, maar ja, nu merk je wel dat dat wel, echt wel alle platformen doen het, zeg maar. Maar het is nooit een silver bullet. Het werkt net vaak niet lekker genoeg, want je introduceert weer nieuwe problemen, het is met alles, weet je wel, een paar jaar geleden, ik weet nog exact van voor mij was het in 2012, dat ze op Qcon, dat voor het eerst over microservices werd gesproken, dat was me toch een partij, een hype. Ja, maar daar was ook wel heel veel backlash, zeg maar van, want wie heeft die term, Martin Fowler heeft hem toch? Nou, dat weet ik niet, volgens mij was dat een andere collega van ThoughtWorks. Die heeft het een beetje gecoind en die zegt ook, die heb ik gesproken vorig jaar of dit jaar zelfs, op een conferentie, die zei ook van het is compleet overhyped, weet je, dit had ik niet bedoeld. Het is ook weer gewoon een patron en het lost een specifiek probleem op en je moet beseffen dat het ook weer nadelen heeft. Toen al op die conferentie, toen dat geïntroduceerd werd, had iedereen het al over ja, maar ja, probeer maar eens een monolithe. Het beheren van een monolithe is vaak al voor veel bedrijven een probleem. Deployen van een monolithe op een goede manier is vaak al een probleem, het beheren ervan, ga je nou je complexe monolithe opsplitsen in 100 verschillende services, dan ben je eigenlijk 100 kleine monolithes aan het beheren. Dat kan toch helemaal niet? Als je dat eerst al niet van elkaar krijgt, je probeert één kind op te voeden, als dat niet lukt, dan kun je wel vier kinderen nemen, dus verder geen sneer naar... Maar je moet eerst het probleem onder de knie hebben voordat je verder gaat ermee. Dat vind ik wel een goed punt. Het is nu ook inmiddels zo, dat was echt, ik weet niet wanneer ongeveer microservices best wel heel populair begonnen, misschien drie, vier jaar geleden, dat het een enorme hype was. Alles moet een microservice worden, en het was echt vies als iemand zei, we gaan gewoon alles in één systeem stoppen, en dat kunnen we, en dan zijn we meteen projectief en dan gaat het gewoon werken. En hoe ga je dat dan in de cloud doen, en als we willen schalen, blablabla, terwijl sommige projecten hebben misschien helemaal geen schalingsprobleem, want dat is afdoen om alles in één systeem te stoppen, één database, en voortal niet zo spannend te zijn. Dus het is, ja, het is altijd it depends, de architect zal altijd zeggen it depends, en dat is ook echt zo, maar ja, ik vind het ook wel leuk om een beetje die stammerstrijd, of een beetje mij is beter dan jou, dat vind ik wel leuk, maar het moet wel een doel dienen, zeg maar. Als je bij een opdrachtgever bent, of je moet een project doen, dan moet je niet die stammerstrijd gaan, nou dan moet je gewoon echt kijken welke oplossing het beste past bij dat vraagstof. Zijn er nou ook veel developers die echt alleen maar in projecten die microservices hebben zouden willen zitten, die dan ook echt nee zeggen tegen, weet je wel, hele ingewikkelde problemen? Ja, dat geloof ik zeker wel. Als ik zie bij de projecten waar ik met event sourcing bezig geweest ben, dan werd event sourcing echt een magneet. Er zijn best wat mensen die op die projecten gekomen zijn die echt afkomen over het feit dat we event sourcing gebruiken, en dat zal met microservices precies zo zijn. Dat is eigenlijk met elke technologie wel. Je hebt nu mensen van engelen project, ik ga geen engelen mee doen hoor, het is react, weet je wel, of volgende generatie is van react, nee joh, ik ga Vue.js doen, dan blijf je toch houden. Maar dat zijn wel de mensen die misschien, die willen gewoon iets nieuws doen, iets sketchy, maar wat ik wel merk, is zeker als ik kijk naar mezelf, dat je daar toch wat meer immuun voor wordt. Je zou kunnen zeggen dat je misschien wat minder flexibel bent, zou je ook kunnen zien, maar ik heb al heel vaak zo de neiging van ja, het zal wel die nieuwe technologie, er zitten gewoon haken en ogen aan, dat kan niet anders. Het gevaar ervan is dat je misschien die innovatieve krachten kwijtraakt. Ik ben geen strategisch architect. Ik ben niet van, oh, we gaan op de lange termijn dit doen. Ik ben meer van, oké, welk probleem hebben we nu? Wat zijn de mogelijkheden, de oplossingsrichtingen die we op dit moment hebben? Oké, laten we de volgende stap nemen. Ja, precies. Dat kan namelijk een beperking hebben. Het kan zijn dat je daardoor minder risico wilt nemen, waardoor je dus een keuze iets heel innovatiefs niet voor openstaat, omdat je iets hebt van ja, het is te veel risico, geen inzichten, terwijl je misschien af en toe wel eens een keertje heel erg out of the box moet denken. En dan heb je die jonge honden misschien wel nodig, af en toe eens iets heel... Ja, dat is zeker zo. Je herkent best wel dingen, zeg maar, als er een jonge ontwikkelaar in, die is heel fris, of die doet waarom niet, en die gaat je challengeen. Dat vind ik op zich wel gaaf. Dat houd je wel scherp, zeg maar, want anders word je echt een beetje een Norse ouwe man. En ik vind alles stom. Als ze uiteindelijk maar doen wat ik zeg. Ja, maar dat is sowieso wel een ding. Ik bedoel, thuis werkt dat niet. Nee. Dus op m'n werk doe je gewoon nu dat. Ik heb maar één baas, die zit thuis. Ja, precies. Nou ja, dat en dan nog de kinderen. Oh ja. En dan heb ik nog twee katten, dus ik heb gewoon echt niks, jongen. Niks te zeggen. Dus echt niks. En op het werk heeft hij ook al geen drol te zeggen, dus... Nee joh, dat is echt gewoon zo frustrerend, dus ik denk nou, weet je wat? Maar dit is wel een herkenbaar dingetje, want als je event source noemt en je praat met iemand die al 40 jaar aan het vak zit, zeg je, ah, dat is gewoon event-gedreven architecturen, what's new in the game. Weet je, als je over objectorienteerd programmeren, over microservices, dan komt er iemand die zegt van, ja, maar in Erlang of, weet je wel, Smalltalk. Je ziet heel veel conferenties, dan komt er een of ander professor die in Smalltalk en die gaat dan dingen vertellen en dan denk je, frek, dat zijn de dingen die we nu aan het oplossen zijn, die hebben ze Erlang een keer opgelost. History repeats itself. Dat is wat mij ook inderdaad opvalt met elke ontwikkeld taal die nieuw kon. Dan beginnen ze weer met de beginners mistakes en dan, voordat je het weet, zitten we in de shit en dan denken we aan, oh ja, weet je nog, Smalltalk, die had dat toen opgelost. Nou ja, dat zie je met JavaScript. Iedereen is enthousiast over JavaScript. JavaScript, want je kunt makkelijk en snel code aanpassen, maar als je een beetje een groot systeem mee bouwt, dan krijg je precies dezelfde uitdagingen. En daarom hebben we nu TypeScript, dan weet ik van allemaal, om toch wel meer controle te krijgen over de kwaliteit van de code. Maar ik denk wel dat we dat nodig hebben, anders blijven we niet innoveren. Tuurlijk. Dus ja, ik vind het een beetje, wat is het? Peak of inflated expectations, is dat wat het is? Ja, dat hoort er wel een beetje bij, natuurlijk. Dus het begint ineens een hype te worden en op een gegeven moment gaan we allemaal problemen ontdekken en dan wordt het niet meer populair. En dan op een gegeven moment, oh ja, shit, we hebben toch die legacy gebouwd. We moeten er toch wel wat mee. En dan wordt het weer stabiel, als het ware. En dan word je weer oud. Dan zijn wij de oude, grijze, Javana of dotnetters. Daar zijn we al hoor. Ja, daarom. En dan, ja, dan zitten we huilend op de bank en dan zien we al die jonkies sneller gaan dan ons. Dus ja, het is inderdaad wat je zegt, history repeats. Absoluut. Ja, dat klopt wel. Ja, dat is wel herkenbaar. Maar goed, ja, dat is ervaring. Je wordt met een oude rond en dan... Ik had een, ik denk, een interessant ding, zeg maar. Stel dat je nu stopt bij je huidige opdracht of whatever en je zou nu een nieuw project mogen maken. Maakt het wel uit. Gaan we nu weer die KFC erbij halen? Nee. Een webshop voor KFC en we gaan dus weer kip verkopen, want dat is altijd herkenbaar voor ons. Maakt me niet uit. Cloud of on-premise, verzinbaar. Maar zou je dan naar een andere platform, en het mag dus niet... Welk platform zou je kiezen? Het mag dus niet .net C-sharp zijn. Waar zou je dan naar kijken? Ja, dat is even... Oh, wow. Anders zou het te makkelijk zijn, want ja, dan doe ik F-sharp of... Zo. Ja, lastig, hè? Als het echt niet in .net mag, dan zal ik het misschien dan een JavaScript, of een TypeScript met Node.js doen. Oh ja, oké. Dus een backend Node.js en dan front-end ja, whatever. TypeScript. Ja. Ja, oké. Dat is eigenlijk een soort van ja, blijf dicht bij je huis, want ja, TypeScript is... Dan lijkt het heel weer op C-sharp. Ah, je speelt een beetje vals. Ja, dat is wel... Dat denk ik wel. Om eerlijk te zijn kijk ik eigenlijk niet naar andere talen, simpelweg omdat mijn vakgebied al zo omvangrijk is geworden over de jaren dat ik mijn handen vol heb om dat bij te houden. Ja, ik denk dat ik toch wel een beetje in die hoek blijf. Java, ja. Java staat ook wel een beetje stil. Dus dan toch liever ECMAScript slash TypeScript of iets dergelijks. Ja, cool. Of Pearl. Ja, dat zou... Dat is wel een goeie... Ik vraag me af hoeveel mensen er nu, zeg maar, nu projecten zouden doen met Pearl, want volgens mij is dat echt wel een beetje echt weg, zeg maar. Ja, dat denk ik het ook wel. PowerShell kan dat ook. Nee, PowerShell. Ja, trouwens, ik ben geen vriend met PowerShell. Als je wil kan het. Ja, maar dat is het. Als je wil kan alles. Ja, dat zie je. Mensen schrijven in de meest rare talen dingetjes. Maar ja, ik persoonlijk, ik vind het... Ik wil heel graag ieder jaar. Dat is zo'n ideaal dat je denkt van, oké, ik ga ieder jaar probeer ik een nieuwe taal te leren. Nou ja, dat heb ik losgelaten. Dat zei ik. Programmer aanpakken. Ja, maar dat lukt me gewoon niet, want vorige keer zei ik ook al van ja, heb ik hier dat niet rust, maar het go-book, zeg maar, opengeslagen en na vijf paren is het boek weer dichtgeslagen. Dus ik had echt het werkt niet meer. Voorheen, ja, toen ik wat jonger was, toen dacht ik, nou leuk, pak ik weer een ander taaltje op, even kijken hoe dat werkt. Nou, er zitten best wel leuke aspecten in. Dan blijf je wel bij C-Sharp. Maar je hebt weleens iets van, oh ja, er zijn een aantal concepten die in die andere talen zitten, die best wel interessant kunnen zijn voor C-Sharp of voor anderen. Dus om een beetje bij de buren te kijken en te zien of daar gewoon nuttige zaken in zijn. Dat vind ik op zich wel tof. Maar dat wil niet zeggen dat ik nou fullblown een andere platform zou kiezen. Hoewel ik go spreek me het best nog steeds wel aan. Elixer, maar dat is echt maar zo'n soort van Erlang-achtige, of gebaseerd op Erlang-taaltje leek me ook wel gaaf. Daar heb ik ook heel veel leuke dingen van gezien. Maar ja, ik heb gewoon geen tijd meer om alles te doen. Ik denk dat als ik niet die vier kinderen zou hebben, niet getrouwd en lekker gewoon de lange nachten doorzak proberen, dan zou ik het zeker wel in mijn eigen tijd nog wat andere dingetjes doen. Maar dat is voor mij niet meer echt. Weet je, het is welk probleem los je dan op? Weet je, het is een mooi constraint, mag geen .NET C-Sharp zijn, maar welk probleem los je op als je een ander platform kiest? Nee, dat is ook niet eens. Nee, in principe, ik denk dat je, dat zei je vroeger, was er altijd een beetje zo'n battle tussen Java en .NET. Wie is nou beter? Ik zei, ik denk dat alle beide kanten, dat 95% van je projecten kun je met allebei oplossen. En dan zullen 5% van de use-case die zullen in Java echt veel beter werken, want er is iets beschikbaar in Java dat niet in .NET zit. En in .NET kan zit er ook iets wat, zeg maar, niet met Java kan. Dus in die zin had ik altijd zoiets van ja, flip over coin. Goed, ik ben geen Java-man, zeg maar. Dus het is een beetje een strijd, ik ben voor Feyenoord, iemand is voor Ajax. En dat is het een beetje. Is dat helemaal op ratio gebaseerd? Nee. Maar je kiest voor iets en daar ga je voor vechten, zeg maar. Weet je, dat is ook het punt. Het is niet, de platform aan zich is niet het belangrijkste. Kijk, op het moment dat je als bedrijf kiest voor een bepaalde technologie of een platform stack, dan speel je het ook mee van, wat voor mensen kun je daarvoor krijgen? Wat voor mensen heb je al aan boord? Hoeveel kennis is er beschikbaar? Kijk, toen Java in de beginfase was Java best wel groot, ook in de open source wereld. Heel veel van de open source libraries die in .net nu populair zijn, die komen oorspronkelijk uit de Java wereld. En unit was oorspronkelijk JUnit. En hibernate was hibernate. Dat waren toen toch wel best wel significante dingen. Inmiddels is .net denk ik al wat breder geworden. En zeker nu met dat ze helemaal open standaarden zijn. Dat ze over alle platformen heen met .net core. Het is nu zo mainstream. En de taal anzicht heeft zich zo geontwikkeld. Met AC gewoon programmeren. Lambda's en dat soort aspecten die in Java jaren later pas kwamen. En ja, ik heb niet zoveel met Oracle. Ik heb het idee dat alles wat Oracle bouwt uiteindelijk een beetje een rommeltje wordt. En dat zie je met Java nu ook wel een beetje gebeuren. Ja. Ja, ik heb te weinig nog met Java, dus ik kan er wel iets van vinden. Ik kan er eigenlijk niks van vinden, want ik weet niet precies wat de ontwikkelingen zijn in Java land. Dus dat is gewoon voor mij, ja, iets uit of mij is koop, zeg maar, of We kunnen hem een keer een leuke gast voor uitnodigen. Ja, dat is sowieso wel het idee. En die hebben volgens mij wel een paar. Ja, dat is een Nederlander die best wel veel doet in de Java community. Ja, dat is een aantal tips in moet. Nou, goed. Draag maar aan, dan gaan we die uitnodigen. En sowieso Android is natuurlijk ook Java ontwikkeling. Dus dat zijn echt wel veel Java ontwikkelaars. Dus dat is ook verder niet meer van oh, nou, de Java ontwikkelaars zijn stom of dat is het achterhaal. Nee, qua OO-principes is het hetzelfde. Ja. En Microsoft is vooral, kijk, doordat Oracle Java heeft gekocht, is dat misschien wat Oracle vind ik nog steeds een beetje een evil company. Maar ja, goed, dat is mening. Ja, even kijken. Heb ik hier nog. Dat heb je zelfs mij wel goed behandeld. Ja, toch? Volgens mij hebben we een keer een beetje aan het script gehouden. Het is pas de tweede keer, toch? Ja, we worden steeds beter in. Ja, we zijn echt goed. Dit loopt gesmeerd. We vergeten ook geen microfoon standaard ofzo. Nee. Nee, het gebeurt niet. Nou, dit keer werken de koptelefoons. Dat is in ieder geval een positief iets. Dus de vorige keer, de vorige keer vergeet ik waarschijnlijk de recorder. Oké. Nou, wat ons betreft was hem dat? Yes. Doen we nog even een leuke outro. Dus Dennis, bedankt voor deze keer. Ja, het was een eer. Ik vond het erg leuk. Je bent ook een van de eerste. Het idee was in eerste instantie dat je de eerste zou zijn. Nou, dat was even niet helemaal zo gegaan vanwege de agenda's. Oh, vergeten wij niet iets. De vraag van de vorige. Ja, dat is een hele lastige. Want dan moet ik eigenlijk een beetje naar Pauline kijken. Dit is live. Ik kan nu live op m'n telefoon kijken. Ja, dat weet ik niet. Ik heb het er nog gevraagd. Ze was heel druk aan het werk. Ze zei, wie is die Dennis? Hoe kan ik nou een vraag voor ze hebben? Hoe kan dat nou? Ik heb nog geen vragen. Normaal gesproken wat we proberen te doen iedere keer is dat een gast een vraag stelt voor de volgende gast. Dat heb jij eigenlijk de vorige keer gedaan. Dat was een beetje raar, want jij bent de gast die na Pauline kwam. Die vragen hebben we de vorige keer besproken. Dat waren ook heel leuke antwoorden trouwens. Die hebben we ook gepost via ons Twitteraccount. Die moet je sowieso in de gaten houden. Had je wat aan de vragen? Of de antwoorden moet ik zeggen. Heb je ze gehoord? Nee. Je moet ons Twitteraccount in de gaten houden. Ja, dat heb ik. Ik volg jullie Twitteraccount. Dat was het ook alweer. CodeKlets. Op z'n Nederlands. CodeChat zou een beetje gek zijn. Misschien is dat voor als we ooit een keer een idee hebben om internationaal te gaan. En nu gaat iemand ons idee stelen. Dus dat is te laat. Die antwoorden waren heel leuk. Helaas had zij dit keer geen vragen. We hebben volgens mij heel veel behandeld. Dus ik denk dat we best wel heel breed en heel interessante zaken besproken zijn. Misschien als je de volgende keer te gast komt, dan gaat het ook nog een keer gebeuren. Dat we dan wel echt vragen hebben van een... Echt diepgaande vragen. Heel moeilijke vragen. Zin van het leven. Weet je wel waarom zit je nog in je vakgebied? En hoe komt het zover dat je überhaupt in het vak terechtgekomen bent? Waarom deed je dit? En is je vrouw nog steeds blij met je? Ik heb op zich nog wel een belangrijke vraag. Waar kunnen we je allemaal vinden online? Online? Uiteraard een Twitter account at daydomen. Ik heb een blog. Die heet The Continuous Improver. Gaan we de show notes opnemen? Ja, top. Dat gaat een beetje over het idee dat ik toch altijd op zoek ben naar dingen die wat ook al gezegd werd in het bio. Betere technieken, betere methodieken, betere architectuurprincipes, betere tools. Eigenlijk alles waardoor ik mijn werk elke dag weer een beetje beter kan doen. Ik heb een github profiel natuurlijk, Dennis Domen. Daar vind je ook allemaal open source projecten. Florida Surgeons, Liquid Projections, projectielibrary voor eventsourcing.net. The C-Sharp Coding Guidelines. Als je dan gewoon op Google, dan kom je er vanzelf uit. Die schrijf ik eigenlijk al sinds 2000. Ooit een keer gestart bij Philips. Hier in Eindhoven bij Best zijn we daarmee begonnen. En die beheer ik nog steeds. Volgens mij staan er een paar YouTube-thingen, maar daar zou ik zelf ook niet naar kijken. Van de conferences hier en daar. Ja, precies. Maar goed, we zetten zo in de show notes en dan kunnen mensen die sowieso vinden. Nou goed, zoals Saber zei Dennis, hartstikke bedankt voor je komst. Onze volgende gast die moeten we nog bepalen. We hebben wel een aantal leuke gasten op de backlog staan. Dus ik zou sowieso even abonneren op onze podcast. Maar dat zal je waarschijnlijk al gedaan hebben. Vertel het vooral door aan je collega's, vrienden, familie. Zelfs je buurman mag het weten wat mij u treft. Of buurvrouw. Ja, als je zelf ook een leuke gast weet of vind je het leuk om een keer iemand op onze show te horen. Laat het even weten via Slack of Twitter. We zijn als altijd op zoek naar leuke gasten of dames. Dat zijn natuurlijk die interessante dingen doen in software ontwikkeland. Hou ons gewoon in de gaten op kodeklets Twitter account. En we hebben ook een Instagram account waar je behind the scene foto's kan bekijken. Alle info is dus te vinden op kodeklets.nl. Dus alle verplichte linkjes om alle Apple podcast, Google whatever, Pocketcast, Spotify, ook Spotify? Te abonneren op de podcast kan je daar vinden. Nou, dit was het weer. Tot de volgende keer zou ik maar zeggen. Later!