{
"$type": "site.standard.document",
"content": {
"$type": "pub.leaflet.content",
"pages": [
{
"$type": "pub.leaflet.pages.linearDocument",
"blocks": [
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"description": "S1 · Afl. 16 · 1 u 18 min · 4 maart 2021",
"previewImage": {
"$type": "blob",
"ref": {
"$link": "bafkreicsf5futjpz3qbrkbee3zsqweuj3rknrs6dqfwalj5r23jdrl7xnm"
},
"mimeType": "image/jpeg",
"size": 59484
},
"src": "https://codeklets.nl/episodes/396",
"title": "▶ Beluister deze aflevering"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [],
"plaintext": "Deze keer is Raymond Roestenburg te gast. Ray Roestenburg werkt bij Lightbend als Tech Lead in het Akka Platform team met Cloud-native initiatieven met een focus op Akka en Kubernetes. Daarnaast werkt hij ook aan Cloudflow. Hij is de auteur van 'Akka in Action' voor Manning publications. Aan het coden sinds de Commodore 64 in de 80's.."
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#didMention",
"did": "did:plc:n5zdxzzelmg7g22ebweczura"
}
],
"index": {
"byteEnd": 58,
"byteStart": 45
}
},
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://kishenpanday.medium.com"
}
],
"index": {
"byteEnd": 83,
"byteStart": 60
}
}
],
"plaintext": "Te gast: Raymond Roestenburg · Presentatie: Saber Karmous, Kishen Simbhoedatpanday"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Hoofdstukken"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.unorderedList",
"children": [
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396?t=4"
}
],
"index": {
"byteEnd": 11,
"byteStart": 0
}
}
],
"plaintext": "0:04 Intro"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396?t=600"
}
],
"index": {
"byteEnd": 35,
"byteStart": 0
}
}
],
"plaintext": "10:00 Oldschool games programmeren"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396?t=2220"
}
],
"index": {
"byteEnd": 17,
"byteStart": 0
}
}
],
"plaintext": "37:00 Lightblend"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396?t=3560"
}
],
"index": {
"byteEnd": 26,
"byteStart": 0
}
}
],
"plaintext": "59:20 Akka in Action boek"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396?t=4080"
}
],
"index": {
"byteEnd": 21,
"byteStart": 0
}
}
],
"plaintext": "1:08:00 Twitter rant"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396?t=4320"
}
],
"index": {
"byteEnd": 13,
"byteStart": 0
}
}
],
"plaintext": "1:12:00 Tips"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396?t=4595"
}
],
"index": {
"byteEnd": 14,
"byteStart": 0
}
}
],
"plaintext": "1:16:35 Outro"
}
}
]
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Shownotes"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://www.lightbend.com/"
}
],
"index": {
"byteEnd": 127,
"byteStart": 117
}
}
],
"plaintext": "Raymond Roestenburg neemt ons mee in de wereld van Akka en hoe hij begonnen is als Software Developer. Hij werkt bij Lightblend. We hebben het o.a. over Scala en wat belangrijk is als software ontwikkelaar."
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Links"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://www.lightbend.com/",
"title": "Lightbend"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://www.manning.com/books/akka-in-action",
"title": "Akka in Action"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://cloudflow.io/",
"title": "Cloudflow"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://www.youtube.com/watch?v=LriUAmAkuD8",
"title": "Retro gaming with Docker"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://www.lightbend.com/akka-serverless",
"title": "Lightbend akka serverless"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://github1s.com/akka/akka",
"title": "Github vscode"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://github.com/features/codespaces",
"title": "Github codespaces"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://doc.rust-lang.org/rust-by-example/",
"title": "Rust by example"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.horizontalRule"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/396"
}
],
"index": {
"byteEnd": 72,
"byteStart": 60
}
}
],
"plaintext": "Beluister de aflevering en lees het volledige transcript op codeklets.nl."
}
}
],
"id": "aa2f89d4-7819-49db-a473-9c5db8e11555"
}
]
},
"contributors": [
{
"did": "did:plc:n5zdxzzelmg7g22ebweczura",
"displayName": "Saber Karmous",
"role": "host"
}
],
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreicsf5futjpz3qbrkbee3zsqweuj3rknrs6dqfwalj5r23jdrl7xnm"
},
"mimeType": "image/jpeg",
"size": 59484
},
"description": "Deze keer is Raymond Roestenburg te gast. Ray Roestenburg werkt bij Lightbend als Tech Lead in het Akka Platform team met Cloud-native initiatieven met een focus op Akka en Kubernetes. Daarnaast werkt hij ook aan Cloudflow. Hij is de auteur van 'Akka in Action' voor Manning publications. Aan het coden sinds de Commodore 64 in de 80's..",
"path": "/episodes/396",
"publishedAt": "2021-03-04T08:58:26.000Z",
"site": "at://did:plc:flhrheaiuteqoy65yixudwsv/site.standard.publication/self",
"tags": [
"Akka",
"Microservice",
"Scala"
],
"textContent": "Welkom bij aflevering 16 van CodeKlets. Vandaag zijn we weer de host Kishen en ik, zoals verhoudt. Dat is alweer een postje gelegen dat wij met z'n tweeën deden. Yes, sir. Ja, zeker. En we hebben vandaag weer een hele leuke en interessante gast. En dat is Raymond Roestenburg. Ja, welkom Raymond. Dankjewel. Oh, sorry. Nu zeg ik Raymond en niet Raymond. Maakt dat nog uit? Nee, dat maakt mij niet uit. Raymond, Raymond, dat maakt niet uit. Misschien moet ik gewoon Ray zeggen, dat is het makkelijkste. Maar goed, Ray Roestenburg werkt bij Lightband als tech lead in het Akka platform team. Ray werkt tegenwoordig aan cloud native initiatieven van Lightband met een focus op Akka en Kubernetes. Daarnaast werkt hij ook aan Cloudflow, een open source project voor distributed streaming applications op Kubernetes. Hij is de auteur van Akka in Action, daar komen we strakken natuurlijk ook op terug, voor Manning Publications. Manning is best populair, daar hebben we steeds gast van. Ja, zeker. De tweede, vorige was Meint. Ja, dat klopt. En hij is aan het coden sinds de Commodore 64 in de jaren tachtig. Kijk, dat is al een poos gedeen. Welkom, welkom Ray. Cool. Dank je wel. Ja, waar zou ons gaan beginnen? Want je zegt net, of jij zegt niet, in je bio staat mooi dat je bent begonnen met programmeren met de Commodore 64. Is dat ook echt de eerste programmerervaring of was er nog iets geks daarvoor? Nee, dat was wel de eerste programmerervaring. Ja, dat was echt, begon natuurlijk heel simpel zoals iedereen met je eigen naam op het beeld zetten. En dat soort dingen, weet je, loopjes maken en dat ging verder naar spelletjes aanpassen en wat met sprites sloten en dat soort dingen. Dat was wel heel leuk. Ja, dat klopt. Ja, dat klopt ja. En welke game heb je, kan je dat nog herinneren, welke games je hebt aangepast? Nou, die games aanpassen was pas later op de MSX. Ik had later een MSX, een andere homecomputer, als je het wilt kennen, denk ik. Nou, nu zijn we weer vrienden. Ja. Want je begon met de Commodore en dan denk je, ja, wacht eens even. Nee, nee, oké, cool. Ja, Commodore 64 was de eerste en toen vriendje van mij had een MSX en dat kwam op bepaalde spelletjes heel erg leuk. Dus toen MSX 2 uiteindelijk. En daar had je een aantal games die, ja, dat kon je redelijk eenvoudig, kon je teksten in aanpassen of je kon verschillende dingen uitproberen met peaks en pokes. En ik weet de helft wel niet meer van, maar dat was wel heel leuk om te doen. En ja, een spelletje heet The Feedback, maar ja, het lijkt een beetje op een spel van Sega, waar ik ook wel de naam meer van weet. Maar het is al een tijd geleden. Maar genoeg spelletjes die je het simpelweg aan kon passen in die tijd, omdat de code natuurlijk eenvoudiger was op dat moment. En kan je nog herinneren in wat voor programmeertal het was? Dat was in Basic. Ja, dat was voornamelijk in Basic. En er waren ook wel wat spelletjes die waren waarschijnlijk in december gemaakt. Maar daar kon je dus, daar verander je niet zozeer de source code, maar gewoon de, ja, ik neem aan dat het binary code was. Ik weet al helemaal niet meer hoe dat deden, maar je had ook bepaalde hex editors voor. Dan kon je hex editors, dan kon je gewoon dingen aanpassen. En dan veranderde er wat in het spel en dat vonden we wel heel gaaf om te doen. Als je jongen kiest van een jaar of 11, 12, zeg maar. Dus je moet er niet altijd veel bij voorstellen. Maar het was wel heel erg leuk. En ja, met de Commodore een aantal sprites gemaakt en te kijken van wanneer is het botsen, zeg maar, wat je dan moet doen. Dus dat was al heel snel, voor mij was het van, oh, dat lijkt me heel erg gaaf om een eigen spelletje te maken. Dat soort dingen. Daar was er nooit echt helemaal van gekomen. Ik heb wel wat gehobbyd met een aantal shoot-'em-ups van die ouderwetse shoot-'em-ups gebouwd. Game level designers gemaakt, dat soort dingen met DirectX en zo. Dat was al weer een tijdje verder natuurlijk in de tijd. Maar dat was meer zo van, oh, hoe zou het eigenlijk moeten? Wat heb je er eigenlijk allemaal voor nodig? En als het op een moment erachter kwam van, oh ja, dit werd ongeveer zo, dan hield het er vaak mee op. Dus ik heb een aantal halve games gemaakt, zeg maar, als hobby ooit. Gaaf, man. Leuk tijd ook, denk ik. Ja, het was super. Ik weet ook nog dat je een spelletje van de radio op kon nemen, weet je wel? Ja, dat is gewoon heel apart. Op de trost zat dat toch? Ik weet niet hoe het programma heet. Ja, dat klopt, ja. Dat is echt bijzonder, toch? Dat je een radio programma neem je op en dan kun je dat afspelen en dan laat je dat programma heen. Ja, dat was een hele interessante tijd inderdaad. Het was allemaal gewoon helemaal nieuw. En ja, je ging gewoon naar vrienden of naar andere mensen die je dan tegenkwam van, oh, weet je hoe dat moet? En had iemand weer een tooltje om wat te kopiëren of wat dan ook? En zo ging het verder. Ja, dat was nog echt innovatie. Ja. Ja, precies. Voor ons was, voor mij, ik zat ook een beetje in die tijd, want Conde64 was ook een beetje mijn... Die heb ik nooit gehad, maar daar ben ik wel door mee in aanraking gekomen met programmeren. En later ook de MSX 2 jaar. En alles was gewoon, dat hebben we eerder ook wel eens besproken, maar alles, je had geen internet. Dus je moest gewoon boeken en via andere mensen moest je aan informatie komen of zelf uitvinden. Precies. Ja, dat is wel bijzonder. Kun je je eigenlijk niet meer voorstellen dat je dat nu... Iedere drie regelscoden die ik schrijf hebben Google nodig. Dus dat is echt... Ja, ja, ja. Ja, ik weet ook nog, met mijn studie moesten we een soort van animatieprogramma maken. Dat was op de HTS. En dan moest je een paar momenten bitmaps inladen. Ik had een boek van Charles Petzold en dan ging ik echt gewoon pagina voor pagina overtypen, weet je wel. Die had gewoon niks. Nee, klopt, ja. Ja. Ja, en ik kan me ook nog herinneren op school over HTS gesproken. Dat ik ook een keer zo'n gameontwikkelvak had, een module of zoiets had gekozen. Dan was het inderdaad echt zo'n heel dik boek. Waar al die sprites ook in uitgelegd werd en zo. En dan was het inderdaad letterlijk gewoon... Het was volgens mij heel veel in C, dacht ik. Ja, ja. En ja, dat was inderdaad gewoon overtypen, weet je wel. En dan hopen dat het weer ging werken. Dus ja, dat was geen internet. Ik las trouwens ook een heel interessant artikel van Container Solutions. Een tijdje terug. Die ken je wel, hè. Dat is best wel een gaaf bedrijf ook. Wat heel erg gericht is op Container Solutions. En die vertelden dat er iemand was die allemaal Sega games, ook in docke containers... Ja, ik zal hem straks... Ik zal hem ook even in de notes delen. Ik vond dat ook wel bijzonder. Om het in een container te doen, ja. Ja joh, bizar, ja. En daarna ben je zeg maar... Nou goed, je zei net dat je op de ATS gezeten hebt, software ontwikkeling gedaan, bla bla. Ja, ja. En wat ben je daarna gaan doen? Ben je meteen... Whatever. Ik weet niet welk jaar hebben we het eigenlijk over. Ik ben begonnen met zijn werk in 97. En toen heb ik een tijdje Oracle gedaan, Oracle Development gedaan. Dat was op een bepaalde moment toch een beetje saai. Toen ben ik toch weer op meer Java gaan doen, want ik was op het ATS op het einde ook op het Java bezig. En een tijdje bij de telegraaf gezeten, bij de financiële telegraaf. Wel wat leuke dingen gedaan. En zo was het eigenlijk gewoon consultancy zeg maar. Java consultancy is dan voornamelijk het werk geweest voor best wel wat jaartjes eigenlijk. Even kijken hoor. Toen ben ik zo rond 2003 naar Zuid-Afrika verhuisd. Mijn vrouw komt daar vandaan. Dus ben ik daarheen gegaan om daar te gaan wonen. Toen heb ik daar vier jaar gewoond. Toen heb ik ook daar eerst wat Java gedaan. En toen .NET, het bedrijf switchte over van Java naar .NET. Dat heb ik een paar jaar gedaan. Toen heb ik naar Nederland gekomen met situaties. En toen heb ik daar ook weer .NET gedaan voor zo'n twee, drie jaar denk ik. En toen weer een opdracht gedaan in Java. En dat was een message broker voor wegverkeer in Nederland. En toen kwam ik erachter van, oké, dit is toch wel vervelend af en toe, de concurrency problemen. Het was best wel pittig. En toen had ik mijn eigen soort van herbruikbare dingen gebouwd. Maar ja, goed, natuurlijk niet helemaal volledig. Het moest ook wel in dienst zijn van het project. En toen kwam ik op een bepaald moment Akka tegen. Volg op dat moment Dean Wampler. Hij heeft ook wel het boek over scalen geschreven en dat soort dingen. En die heb ik later nog mee gewerkt bij LiveBait. En die zei ze van, oh, je moet Akka 0.7 uitproberen via Twitter. Ik denk, wat is dat nou, Akka? Weet je wel. Dus ik ben gaan kijken en dat ik, oh, dit is precies wat ik moet hebben. Het is gewoon helemaal, wat ik ook eerder eigenlijk zelf, maar ja, in een veel minimaalere zin natuurlijk, gemaakt heb met threads en mailbox en queues. Het handelen van exceptions. En toen heb ik dat gebruikt in een project bij bedrijf Wijktoenwerk de CSC. Voor de Konker commercial C. Dat is een systeem om bij de grens allerlei activiteiten in de gaten te houden via camera's en radars, maar ook via patrouille auto's die rondrijden. En dat was dus een gedistribueerd systeem met allerlei sensorlocaties. En ik zag daar al aankomen, al die verschillende sensoren, verschillende systemen, zowel in auto's gebouwd als boven de weg. Om al die informatie terug te brengen. Dat dat een hele uitdagende case zou zijn met de traditionele concurrency en distribution tools. En toen kwam ik Akka tegen. En toen zag ik al heel snel, het zag er vroeger anders uit die website, maar daar hadden ze een klein stukje code over, over wat een actor is, zeg maar. En dat sprak me meteen aan. En na even in de code te kijken en wie eraan gewerkt had, et cetera, was al weleens nou duidelijk van dit is niet zomaar een framework dat iemand eventjes open source heeft gezet. Het zijn gewoon een aantal vooraanstaande mensen die aan de internals van de JVM bij J-Rocket volgens mij hebben gewerkt. Dus ja, dat was ik wel meteen geïnteresseerd. En zo ben je daar terecht gekomen bij die Akka technologie, zeg maar. Ja, oké. Dus dat is wel grappig, want dat je dan eigenlijk, ten eerste de ideeën die je zelf ook al had, dat je die dan ergens anders, ja, op een grotere schaal misschien, dat je die dan weer terug ziet. Dat is wel een soort van bevestiging van, ik zie je wel, ik zat goed. Ja, het is heel lastig met threads. Als je, oké, ik wil iets concurrent doen, oké, dan start ik een thread. Oké, hoe communiceer ik nou met dat ding wat in die thread draait, in die run method, wat ga ik doen? En dan kom je de primitieve tegen, dan kom je de verschillende queues tegen. Oké, ik kan iets op een queue gooien en dan kan ik het daar weer afhalen. Nou, dan gebruik je de verkeerde queue een keer en dan loopt het helemaal mis, zeg maar. En daarnaast, er kunnen exceptions gegooid worden in die thread. Ja, wat doe je daar dan precies mee? Hoe communiceer je die? Nou, dan moet je eigenlijk weer een soort van queue voor hebben of iets anders, of een mechanisme dat je kan zeggen van, hey, dit ding is kapot, hij moet opnieuw beginnen. En daar had ik een hele gelimiteerde, of tenminste, ik had het, zeg maar, het probleem door mij en had ik gelimiteerd gezien in mijn applicatie. En dat ging toch ook niet altijd helemaal goed, zoals bij iedereen. En ja, dat was af en toe best wel pittig met de low-level primitives, zeg maar, van Java concurrency. Ja, dat is in Java toen, ja. Want ik, het enige wat ik, goed, Kishen zei toen van oké, we kunnen iemand uitnodigen die iets met Akko heeft gedaan. Toen dacht ik, ik ben een .NET ontwikkelaar, dus ik dacht, oh ja, dat is een .NET. En je weet gewoon, dat is bij heel veel van die projecten, zeg maar, opstorspecten, waar .NET achter staat, dan weet je, waarschijnlijk is er een project, zeg maar, wat eigenlijk van Java afkomt. En daar hebben ze een .NET variant van gemaakt. Ja. En dan komt Microsoft en die zegt van, hey, die open source shit moet je niet doen, joh, we gaan het voor je doen. En dan is de open source u weg. Ja, dat is wel waar, maar dat is me eerder als gelukkig, maar dat zul je misschien zelf ook wel een beetje mee hebben gekregen, dus de laatste vier, vijf jaar is dat wel heel erg omgeslagen, gelukkig, want Microsoft is gewoon open source all the way tegenwoordig. Ja, precies. Dat is wel veranderd, maar dat is wel zeker zo, zeker, onder Steve Ballmer was het wel een beetje evil, of ten eerste not done om iets over open source te roepen. Dus aka.net, ja, dat kende ik zeg maar. En ja, dat was een beetje het uitzoeken van hoe het nou zat. Ik heb eerlijk gezegd nog nooit met het, en dat is trouwens wel een vraag ook, het actor model heb ik niks mee gedaan, want ik heb wel iets in productie gezet met event sourcing en CKRS. En gedistribueerde systemen, dat is ook wat we voor de opname ook al een beetje zei, van ja, het is een beetje, hoe zeg je dat? Systemen worden steeds, ja, complexer misschien wel. Het is helemaal heel gangbaar. Nou ja, misschien worden bijna alle, nee, niet bijna alle systemen, maar heel veel systemen worden in de cloud geontwikkeld. En dan is het gewoon belangrijk om na te gaan denken over ja, hoe werken nou gedistribueerde systemen? Hoe zet je die goed op en hoe moet je met performance omgaan? Wat voor architectuur ga je gebruiken? Ga je een monolith gebruiken of neerzetten? Of wil je microservices gebruiken? En daar komen best wel allerlei vraagstukken naar boven. Want het is, ja, iemand die enorm veel ervaring heeft, zal nooit zeggen dat het ingewikkeld is of moeilijk, maar het is wel een complex verhaal. Je moet aan best veel dingen denken. Dus binnen die gedistribueerde systemen, zeg maar, is ACCA een van de manieren om, zeg maar, zoiets op te lossen? Zie je dat anders of kun je dat toelichten? Ja, ACCA is begonnen als een soort van toolkit, waarin je een aantal tools hebt, die voor dit soort situaties handig zijn. En daar is het mee begonnen. Dus initieel was het een actor-based library, zeg maar, en daar werd steeds meer bovenop gebouwd. Het was altijd wel vanuit het begin al bedoeld als actors zijn zowel lokaal als distributed. Dat was altijd de idee. En daar zijn over de jaren heen verschillende modellen voor gebruikt om dat te uiten, zeg maar. Dus initieel kon je twee actors met elkaar praten over een remote connection. En nu is dat uiteindelijk terechtgekomen in een cluster-technologie. Dus je kan actors in een cluster hebben. Maar dat is niet het totale beeld, want je kan alle dingen in de toolkit gebruiken of een klein gedeelte ervan. Dus daar zit best wel veel ruimte in. Je kan zeggen, die dingen wel, die dingen niet. Er zit bijvoorbeeld ook CRDT-support in voor de Conflict-replicator-data-types, om bijvoorbeeld zoiets als docs.google.com te maken, dat je tegelijkertijd schrijft in documents maar dat het wel uiteindelijk eventually klopt, wat je opgeschreven hebt. Maar er zitten dus ook bijvoorbeeld persistent actors in. En die kan je weer gebruiken voor een situatie waar je je systeem partitioneert of shard in verschillende entities, waarbij je heel erg hoog kan schalen in de zin van in-memory stateful processen. Dus het extra model bestaat eigenlijk uit een aantal onderdeeltjes of het bestaat uit een... of nee, dat is misschien niet de makkste manier om het uit te leggen. Wat het lastig maakt, zoals ik al eerder ook al zei met die threads, is dat het lastig is om te communiceren tussen threads of om ervoor te zorgen dat je niet enige andere fout maakt in concurrency, waardoor je race condition krijgt en al dat soort dingen. Dus het actor model is een ander soort model waarin je praat in vorm van actors. Een actor is een soort van object waar je berichten naar kan sturen. En je actor kan dan weer reageren met berichten. Dus het is heel erg berichtgedreven, als je dat zo kan nog kunnen zeggen. En een aantal garanties worden daarbij gesteld. En dat is dat als jij een actor schrijft en je krijgt een berichtje binnen, of je krijgt berichten binnen, dan krijg je die berichten altijd één voor één binnen. Dus je kan een soort van, ja, wat heet het, een receive kan je schrijven waarin verschillende soorten berichten binnen kunnen komen. Dus bijvoorbeeld een bericht heet ping en dan stuur jij een bericht terug pong. Dan maakt het niet uit van wie die berichten komen of hoe concurrent ze aankomen. Als actor zijn, dan kan je ze één voor één verwerken. Het sturen van de berichten en het ontvangen van de berichten is allemaal asyngroon. Dus je wacht eigenlijk nooit. Je bent nooit aan het blokken op iets. Dus je bent geen fret aan het vasthouden of wat dan ook. En alleen dat al, alleen dat principe al, zeg maar, dat je heel eenvoudig één voor één berichten kan afwerken, dat is een heel groot voordeel. Een actor kan ook andere actors maken. Dus je kan een soort van hiërarchie maken van parents and children, om het zo maar even te zeggen. En wat daar ook heel interessant aan maakt, is dat als een actor, als er wat fout gaat in een actor, dan is het standaardbordeel om er eigenlijk niet veel aan te doen en gewoon om die actor te laten crashen. Wat er dan gebeurt, is dat de parent van die actor doorheeft van oh, er is iets verkeerd gegaan en die kan dan bepalen wat er moet gebeuren. Dus in plaats van dat je alle problemen op moet lossen op het laagste niveau van je applicatie kan je zeggen, ik hou er gewoon mee op, ik geef het door naar boven. En dan kan op het hogere niveau, misschien ook wel op basis van meer informatie, want er kunnen meerdere actors zijn, kan dan een beslissing genomen worden. Dus dat is in zekere zin, als ik het zo heel snel uit probeert te leggen, je ontvangt berichten, je verstuurt berichten en alles wat je doet is eigenlijk in zekere zin single-threaded. In de zin van je elke keer heb je een berichtje. En wat nog belangrijker is, die actors daar kan je er miljoenen van hebben. Een thread is heel erg zwaar. Misschien heb je max 400 threads of 1000 threads, maar bij de actors kan je naar de miljoenen actors gaan als je dat wilt. Dus ze hebben sowieso veel minder geheugen nodig. En eigenlijk wat ze doen onder water, delen actors een threadpool. Dus al die actors die draaien op een threadpool, dat heet een dispatcher, en al die berichten die gaan op een soort van queue, elke actor heeft een mailbox. En die mailbox die wordt door de dispatcher heen geduwd naar de actors die die berichten kunnen verwerken. Dus daar zit een samenspel. Maar door die opzet kan je dus ook kiezen voor een andere dispatcher voor jouw toepassing. Als je zegt, ik wil gewoon een fixed thread dispatcher, ik wil gewoon 4 threads hebben, en daar ga ik al mijn actors op draaien. En dan gaan die actors die draaien dan boven op die 4 threads en die gaan dan automatisch, zeg maar, krijgen ze een bericht om het zo maar even te zeggen. Ja precies, dus je kunt aangeven van hoeveel resources mag dit systeem als het ware dus het volledige gebruiken door een restrictie uit te geven. Oké, ja. Nou hoor ik in ACCA dat de actor model een rol speelt. Zijn er ook andere dingen die een rol spelen binnen ACCA? Ja, er zijn best wel veel. Het heeft wel altijd qua concept te maken met actors. Er is nog iets anders en dat heet streams. En streams zijn eigenlijk een hoger level programmeer model bovenop actors. Dus daar kan ik misschien zo meteen het concept van actors staat wel heel erg centraal in ACCA. Daar is het wel zo dat er ook natuurlijk het ACCA team heeft ook allerlei dingen gemaakt met actors. Niet per se om de gebruiker te forceren om actors te laten gebruiken. Dus bijvoorbeeld er is een library ACCA Http. En daarmee kan je Http afhanden in ACCA GRPC is een andere. En die hebben allemaal api's of DSL's hoe je ze wil noemen. Die niet per se het noodzakelijk maken dat jij een actor maakt. Dus je kan dan gewoon zeggen van als het een get of een post complete met een ok, dan schrijf je geen actors. Maar ACCA Http is wel geschreven bovenop streams en streams zijn bovenop actors. Dus de actors zijn zeg maar de core primitive ofzo. De building block. Dus het is een manier van hoe je het gebruikt merk ik. En je kan het ook zonder actor models eventueel. Het is zeg maar de primaire building block van de toolkit. En in de toolkit zitten andere tools die het net een level hoger maken. Dus dan hoef je niet met de primitieve tool te werken, maar met een DSL. Maar in sommige gevallen is het heel erg handig om de manier van de actor model te gebruiken. Wat ook heel eenvoudig is in actors is state machines schrijven. Fijne state machines. Want je kan in die actor zeggen ik ben nu in state A. Dan krijg ik een berichtje. Oh, ik heb een berichtje gekregen. Ga nu naar state B. Dus dan verander je je receive method, zoals dat heet. Dan zeg je van nou, tenminste dat is de oude manier. Er is een aantal nieuwe APIs bijgekomen, maar je kan op basis van een bericht naar een andere state switchen. En die state switchings zijn ook weer per bericht. Dus je krijgt nooit het probleem dat je, oh ik heb in concurrently nog een bericht binnen gekregen. Nu zit ik ineens in het verkeerde state. Dus je kan heel netjes eigenlijk al die state machines maken. En dat kan je van hele simpele dingen doen of hele complexe dingen eigenlijk. Als ik het mag samenvatten, een state model zou je daarmee kunnen maken? Of zie ik dat verkeerd? Nou ja, ik weet niet wat je daar precies mee bedoelt. Nou, een model wat de staat van het systeem beschrijft. Ja, dat ga ik er zeker mee doen. En dat je dan akka, noem het maar even, gewoon al die details uitwerkt. Ja, dus een van de dingen die daarna vaak gebeurt, is iemand maakt bijvoorbeeld een actor, om een of andere businesslogica vast te leggen. Dat is heel erg handig, want je schrijft de API van de actor in vorm van berichtjes. Get article, put article, weet ik veel. Noem het maar op, ik ben al slecht in voorbeelden. Maar zeg maar een shopping basket, waar je een artikel terug toevoegt. En nog een artikel toevoegt, waar een paar mensen zegt ik ga dit spul kopen, dan ga ik naar een nieuw estate misschien wel. En zo verder en zo verder. En wat in ak ook mogelijk is, om te zeggen van nou, ik wil, want al die informatie die je een paar momentjes hebt, misschien wel een shopping basket niet zo heel relevant, omdat die, nee, gewoon een shopping basket. Ik wou gewoon zeggen, je wilt natuurlijk wel die blijk bestaan. Als er wat crasht of terugkomt. Als er even wat fout gaat, ok, maar je webbrowser refresh wil je gewoon dat je shopping basket er weer is en niet dat je 20 artikelen bij de bijeenkomst, weet ik veel, dat die een keer weg zijn. Dus een techniek die bestaat in akka om die state in die actor, dat state model vast te houden en ook weer terug te krijgen na een crash. Dat is de akka persistence module. En dan kan je in een event sourced manier, kan je de dingen die gebeurd zijn met die actor, kan je vastleggen in een journal. Dus een event journal. En dan kan je ook weer na een crash of misschien gaat je shopping basket, wordt er voor even niet gebruikt als je passivereert hem. En dan na een tijdje komen we terug met shopping basket, dan wordt die weer gerehydrate of deserialized van de journal. En dat werkt gewoon volgens de principes van event sourcing, zoals je die wel kent, denk ik. Of wat je ook al even over zei. Ja, die events worden zeg maar opgeslagen en dan kun je eventueel, ten eerste bij event sourcing, database of whatever, je kunt dat snapshot eventueel, dan zou je ook heel snel naar een bepaalde moment kunnen. Ja, cool. Dat zit ook in Acca persistence inderdaad. Dus als ik het goed begrijp, zou je Acca kunnen gebruiken, of nee, je gebruikt het vooral om je applicatie zo robust en schaalbaar mogelijk te maken, toch? Klopt, ja. Zodat je de high performance kan garanderen. Ja, high performance en schaalbaarheid zijn wel de redenen waarom je Acca gebruikt. En ook de robustheid, zeg maar, dat je ervoor kan zorgen dat het blijft werken. En het geeft je een hele manier van werken voor het maken van robuste software. Door middel van het feit dat die actors elkaar dus ook kunnen opvangen, als het ware. Als zo'n probleem ontstaat. ja, die Acca persistence daarin is er ook een module die hoeft niet per se te gebruiken, want dat gaat al bijna iedereen. Dat heet cluster sharding. Dus dan kan je eigenlijk ook heel erg schalen. En cluster sharding, ik wil eigenlijk wat je opdraaien. In Acca heb je dus actors. Die actors kan je draaien in een actor system. Zo heet dat. Als je programmeert, dan zeg je, nieuw actor system, of actor system in schalen. En dan zeg je, oké, ik start mijn main actor. Dat is gewoon een hoofdactor. Een guardian, wat het vaak gaan noemt. En dan daaronder maak je meer en meer actors die het echte werk gaan doen. En dat is natuurlijk wel leuk, maar dan heb je maar één JVM die draait met een aantal actors erin. En Acca heeft daarnaast dus ook Acca Cluster. En Acca Cluster zorgt ervoor dat die actors die je in je actor system hebt, dat die over een cluster van nodes aanwezig zullen zijn. En dan in cluster heb je weer een aantal tools. En een van die is cluster sharding. En die zorgt ervoor dat als jij zegt van, ik moet shopping basket 1 hebben, dan weet Acca Cluster wacht even, er is nog geen 1, die ga ik aanmaken. Ik ga hem aanmaken op node 3 bijvoorbeeld. En dan houdt hij bij, qua partitioning als er berichten komen voor shopping basket 1, dan ga ik altijd naar node 3, want daar zit een region met allerlei actors erin, die daar worden gespawned, die daar worden gecreëerd. En zo kan je dus een heel schaalbaar systeem maken die over meerdere nodes heen al die state, al die actors verdeelt. Oké. Maar wat ik dan wel begrijp, als ik het goed begrijp, dan zijn er qua infrastructuur, voor lack of better word, infrastructuur, want er is iets waar al die actoren in leven, dus als je net ook aangaf, dat systeem start en dan maak je actoren daarin aan. En dan zijn er dus bepaalde ja, is daar iets, ja daar hoef je niet zelf te proberen, maar dat wordt door AKA aangeleverd om te zorgen dat dat dan kan plaatsvinden, zeg maar, dus dat ze eventueel messages met elkaar, aan elkaar doorgeven of hoe moet je daar zelf iets voor doen? Dus stel dat bijvoorbeeld actor 1 iets wil sturen naar actor 2, wordt dat dan voor jou gedaan of hoe? Dan wordt dat in zekere zin voor je gedaan. Dat is niet, als jij zeg maar van actor 1 met actor 2 wil praten, dan moet je van actor 2 de actor reference hebben. En die actor reference die kan je op verschillende manieren krijgen, je kan ook vragen aan het actorsysteem, heb jij een actor met dit pad, dus alle actors zitten achter een soort van uniek pad, als het ware. En actor references kunnen ook wijzen naar een remote machine of kunnen ook wijzen naar een actor op het cluster. Dus er zijn verschillende manieren daarvoor. Alleen in zo'n algemeenheid wat je normaal gesproken zou doen, is dat je zegt van nou, ik ga gewoon een aantal JVM processen opzetten. En die JVM als onderdeel zijnde van hetzelfde cluster, die hebben ook allemaal gebruiken dezelfde code. En bij het opstarten van zo'n cluster is er een bootstrap moment om het cluster aan elkaar te connecten als het ware. Dus die actorsystems die zien, oh, er is eentje up. Ik ga ook up. Dan is er een bepaalde leader, een soort van exchange en een soort van handshake die gewoon gebeurt. En op een bepaald moment worden die nodes, al die nodes worden onderdeel van dezelfde groep, krijgen dezelfde group membership, zoals het heet. En op dat moment kunnen de actors in de tusser met elkaar praten. En wat er vaker gebeurt is dat je gewoon zegt van nou, ik ga een cluster sharding systeem opzetten voor shopping baskets bijvoorbeeld. En de ene shopping basket praat niet met de andere shopping basket. Dat is niet zo snel iets wat er gebeurt. Maar het zou wel kunnen zijn dat je misschien een andere service of iets wat gedeeld is door verschillende actors aanspreekt via een bepaalde actor reference. Alleen ja, er zijn dan wel wat ja, er zijn heel verschillende manieren om het natuurlijk te doen. En wat wij nu proberen te doen bij Lightband is ook om op een platform guide of we proberen hem niet te hebben. We hebben een platform guide om je uit te leggen van hoe ga je dit nou allemaal doen? Want er zijn heel veel keuzes en ik weet nog van heel lang geleden dat ik als consultant akka overal ging doen zegmaar. Dan werden altijd veel dezelfde vragen gesteld van ja, hoe gaan we waarom moet ik hier nu een actor gebruiken? Of hoe gaan we ervoor zorgen dat ze allemaal in het cluster draaien? Of hoe zorgen we ervoor dat die altijd blijft bestaan? Of dat er van sommige dingen moet ik er altijd één hebben in plaats van één in het hele cluster, want er is één centraal ding hoe je zegt. Dus daar omdat het dus zo'n toolkit is waar je heel vrij uit kan kiezen is het ook voor veel mensen best wel een lastig ding om zomaar even mee te beginnen, want er zijn heel veel onderdelen. En daarom hebben wij ik weet niet hoe lang we dit al doen, in ieder geval wel een paar maanden hebben we de akka platform guide en die laat je zien hoe je microservices met akka schrijft op een terminatet manier, in de vorm van event sourcing in de vorm van events, in de vorm van views, we noemen dat projections en in de vorm van in de vorm van die persistent actors die ik net zei. En dat ook in combinatie met GRPC. En daar hebben we nu ook recentelijk hebben we daar een product voor gebouwd voor Amazon. Dus in Amazon kan je de akka cloud platform vinden. En daarmee kan je gemakkelijker op Kubernetes zo'n akka microservice deployen. Dus dat is wel een goede vraag, want er zit heel veel infrastructuur altijd bij, van hoe start ik nou het hele systeem. En dat is best wel een uitdaging voor veel mensen. En dat is ook een van de redenen waarom ik eerder aan Cloudflow gewerkt heb. Cloudflow is ook een project van lightband. Het doet iets vergelijkbaars, maar dan voor streaming applications. Dus voor realtime streaming applications en in combinatie met streaming platforms. Want er wordt gewoon altijd weer wat ergens draaien, weet je wel. En tegenwoordig is het bij altijd Kubernetes, dus daar heb je gewoon wat hulp bij nodig, vaak. En ja, je noemt net lightband. Kan je daar iets meer over vertellen voor mensen die het nog niet kennen? Ja, lightband is het bedrijf dat achter ACA zit eigenlijk. Het heet vroeger TypeSafe. Op een bepaalde manier hebben ze die namen veranderd, want ze werden elke keer verkeerd aangeschreven als Typeface of iets anders. En dat ging ook op een bepaalde manier. Het is meer dan alleen maar TypeSafe programming languages, weet je wel. Dat is ook een naam vanuit Scala. Dus de bedenker van ACA, Jonas Bonner, die heeft op een bepaalde moment begonnen met ACA, een bedrijf vormeentjes gestart, het heette Scalable Solutions. En uiteindelijk zijn ze gaan praten met Martin Odersky, de maker van Scala. En die hebben toen samen een bedrijf gestart 10 jaar geleden denk ik. Ja, 10 jaar geleden ongeveer. En die zijn een bedrijf gestart, TypeSafe. En die wilden die combinatie van Scala en ACA aan de markt brengen. En uiteindelijk is Lightband de nieuwe naam van dat bedrijf al een hele tijd. Maar dat is het bedrijf dat achter Scala zit en achter ACA de toolkit. Maar we hebben ook we doen nu al iets minder mee, maar we hebben ook Play en Lightbombs, andere frameworks die we ook doen. Ja, vind ik zelf wel we zijn ook heel erg gefocust op de Java community. Want er zijn gewoon veel meer Java-programmeurs dan Scala-programmeurs. Ik vind het zelf ja, vele malen fijner in Scala. En ja, Java is natuurlijk wel heel erg gegroeid over de tijd en heel erg verbeterd. Het gaat ook steeds sneller nu met die nieuwe versies en zo. Maar ja, voor mij zelf persoonlijk is Scala nog steeds favoriet. Ja, voor je favoriete taal. Ja, nee, dat maakt niet uit. Het is voor mij, ik kijk van buiten zeg maar. Ik weet je, ik ben net ontwikkeld. Dus dat is echt precies het andere kant zeg maar. Maar dan hoor ik, ik hoorde wel heel vaak mensen over Scala spreken en heel positief zeggen oké, als ik in Scala doe, dan wil ik eigenlijk niet meer terug naar Java. Dat hoor ik wel vaker, dat sentiment. Nou, het is ook zo dat ik op een bepaald moment deed tot Java en toen ben ik in zekere zin geforceerd hem tot net te gaan doen. Dat maakte hem trouwens niet uit. Ik vind het gewoon allerlei tools die je gebruikt. Zo simpel is het. Maar toen kwam ik in C Sharp en dat was toen net framework 2.5 en dan 3.5. Dus ze hadden een 2 codebase en toen zijn we naar 3.5 gegaan. En daar zag ik al heel veel voordelen van dingen als link en andere functional programming style kwam daar steeds meer naar voren. En first class functions en dat soort dingen. Dus dat vond ik eigenlijk wel heel erg gaaf. Toen kwam ik op een ander project van we moeten het in Java doen, oké. En toen, oh man, dit is toch wel even weer een stap terug. Op dat moment. Toen ik daarna Akra zag staan met een voorbeeld uit de scale dacht ik, wow, dit is precies wat ik wil. Dit is eigenlijk nog beter dan C Sharp in die functional programming zin. En wat het allemaal bood. Dus een soort van een style waar je veel minder hoeft te typen. Een concise af en toe ben ik Nederlands een beetje kwijt, maar een beknopte taal. En ja, een hele goede support voor collections en dat soort dingen en voor alle dingen die je normaal gesproken tegenkomt. Er is iets, er is niets, de option types en alle andere dingen die je zo tegenkomt. Dus ja, Scala is wel steeds een favoriet. Wat ik ook wel zorg voor mensen is, ja, dit is gewoon veel te moeilijk voor mij. En het komt ook omdat er zijn mensen ook bezig met Scala om die lat nog verder te leggen. Dus die doen research en die gaan hele complexe dingen proberen die voor iedereen, niet voor de meeste mensen te ver gaan of onnodig zijn, maar in Scala zelf zit ook een hele functionele, en dan bedoel ik niet functional programming, maar een hele functionele core van simpele dingen die heel goed werken. Dus je hoeft niet al die hele moeilijke dingen te gebruiken, maar daar worden mensen wel door afgeslikt. Dus dat wordt nu een beetje in de nieuwe versie, moet het getracht om het een beetje simpeler te maken voor iedereen. Want ja, wie wil nou iets zo complex? Ik zat laatst nog een artikel te lezen over Scala en het vinden van goede developers in Scala. Wat is jouw blik daarbij? Wat vind je daarvan? Heb je daar zelf ook een beetje ervaring mee, dat je echt denkt van nou, er zijn toch echt wel schaarse Scala developers out there? Ja, dat is een beetje een gek verhaal, want toen ik dat project begon, voor het eerst met Scala, toen waren er geen Scala mensen. En toen heb ik gewoon een aantal collega's gevraagd, wie wilde graag eens nieuws doen? Nou, er waren er genoeg. En toen ik mensen mee ging interviewen, een ervan was de jongen waar ik samen in het boek mee geschreven heb, Rob Bakker. Die was ook geen Scala programmer, maar dat was een hele ervaring Java-programmeur. En die zag het ook wel zitten om wat nieuws te gaan doen. En toen waren we als team, denk ik met een man of vier, initial, we waren binnen nou, misschien twee weken of zo waren we gewoon, twee weken misschien, waren we zeker gewoon goed bezig, zeg maar. Dus ik denk niet dat je per se iemand moet hebben die al jarenlang Scala doet of zo. Het is natuurlijk wel leuk, maar ik denk niet dat het heel ver weg is voor mensen om daarmee te beginnen. Alleen je moet wel naar die kleinere set, naar die simpele set van dingen kijken. Dus als je meteen gaat naar... Er zijn veel mensen die in de Scala wereld die veel meer geïnteresseerd zijn in de pure functional programming kant. En de pure functional programming kant in de zin van Haskell. Dus dan krijg je heel veel abstracte modellen, et cetera. En dat is gewoon niet voor iedereen, simpel gezegd. Dus als je dat soort mensen wil vinden, dan moet je of een Haskell persoon vinden, of iemand vinden die echt die hele manier van Scala in pure functional programming echt ziet zitten en ook goed begrijpt. Daar zijn zeker voor- en nadelen aan, maar... Ik denk dat goede programmeurs sowieso lastig te vinden zijn, die echt goed zijn. Maar tegelijkertijd denk ik ook dat een goede programmeur niet alleen maar door technische skill wordt bepaald, zeg maar. Ik heb ook weleens met mensen gewerkt die technisch heel goed waren, maar daar kwam toch eigenlijk niks uit, op wat voor manier dan ook. Dus ja, het is wel zo, als je puur kijkt naar, ik wil een Scala-programmeur hebben met vijf ervaring, of zoiets, dan wordt dat een lastige uitdaging inderdaad. Dat is wel zo, als je zegt, dat is mijn maatstaf. Als je zegt, ik wil gewoon een goede programmeur hebben. En iemand die graag Scala wil leren, dan is het weer heel anders, want wij hebben ook iemand in ons team, al heel lang, en die had wel wat Scala gespeeld, maar die was gewoon 20 jaar C++ programmer. Dat kan helemaal goed. Maar ja, er zit ook wel een risico aan als je alleen maar blijft bij wat je al kent. Want juist in deze business moet je blijven leren. Ik bedoel, ik heb nu denk ik zo'n 3 jaar met Kubernetes gewerkt. Ja, dat moet je toch allemaal gewoon oppakken. Dan kan het niet zeggen, dat wil ik alleen maar in Scala doen. Dat kan helemaal niet. Dus je moet ook wat HelmCharts en wat Golang en allerlei verschillende dingen komen langs. Bash Scripts, maakt niet uit, Makefiles. Je hebt gewoon heel veel verschillende dingen nodig om echt iets werkend te krijgen. Ik kijk altijd naar mensen van, kan jij iets werkend krijgen? Kan je iets voor elkaar maken? Dat is eigenlijk het belangrijkste. Ja, zeker, zeker. Ja, nee, maar ik begon even over dit onderwerp omdat, ja, we zijn toch ook wel het is best wel schaars om Scala developers en misschien ook wel de goede, hoe je ze ook wil noemen, zeg maar, om die te vinden. Dus ik was even nieuwsgierig naar hoe bijvoorbeeld Lightband daarna kijkt. Ja, dus wat ik aan jou hoor is dat het voornamelijk gaat om dat je waarschijnlijk ook gewoon goed in concepten denken bent en dat je inderdaad wil blijven leren, nieuwe dingen blijven proberen. Wij nemen niet alleen maar mensen aan die alleen maar Scala programmeren, dat is sowieso niet. Maar we hebben natuurlijk wel een voordeel als we mensen willen aannemen die Scala programmeren. We zijn nogal een focal point, zeg maar, voor Scala programmers. Dus het is voor ons veel makkelijker om een Scala programmer binnen te krijgen dan een bedrijfje ergens in Nederland die wat Scala programmers doet. Ik wilde kort nog even over jouw boek hebben. Misschien ook wel leuk om even daarbij te staan. Dat was weer een tijdje geleden. Wanneer is je boek uitgekomen? En kan je er iets meer over vertellen? Ik krijg het gewoon. Ik weet het niet meer. Het is al wel, even kijken, in ieder geval 5, 4 jaar geleden. Het heeft me ook heel lang geduurd. Ze zeggen ook altijd tegen je van als je denkt dat je een boek gaat schrijven, doe het niet. Je kan nog meer geld verdienen als je zavond bij de Burger King gaat werken. Voor sommige boeken natuurlijk niet waar. Maar voor de meeste IT-boeken je wordt er niet schatterijk van. Dat is ook niet de reden waarom je het doet. Maar het is zeker een hard werk. Dat heb ik ook wel het onderschatten. Gelukkig had ik iemand die het samen met mij wilde doen. Dat was Rob Bakker. Een van de eerste projecten die we samen deden. Menning was aan het zoek naar iemand om het akka-boek te schrijven. Die hebben natuurlijk het akka-team zelf gevraagd. Hebben jullie interesse? Ja, die hadden we niet heel de tijd. Ik was ondertussen alweel bezig als contributor op het akka-project. En uiteindelijk zijn ze dan bij mij terechtgekomen. Dus ik weet niet hoeveel mensen er mee hebben gezegd. Om het zo maar even te zeggen voordat ze bij mij kwamen. Toen dacht ik al van dit is zoveel werk. Maar tegelijkertijd ook wel heel erg leuk om te doen. Een mooi doel om te hebben weet je wel. Ik had een boekopje in je kast met je eigen naam erop. Dat sprak me wel aan. Maar ik wist al wel van dat gaat me nooit lukken in mijn eentje. Dus toen heb ik aan Rob gevraagd of ik mee zou doen. En zo is het eigenlijk begonnen. En later heeft een andere jongen uit Amerika meegeholpt met de tekst, Rob Williams. Maar wij zijn toen met z'n tweeën daarmee begonnen met het boek. En hoe lang heb je er ongeveer over gedaan? Weet je dat? Ja, dat weet ik nog. Dat is ongeveer vier jaar geweest. Kijk, eigenlijk wil zo'n publisher dat je ongeveer binnen zes maanden klaar bent. Wat er gebeurde was... Ik had er nooit een boek geschreven, Rob ook niet. Dus je krijgt dan eerst een development editor. Die gaat je uitleggen, zo moet je een boek schrijven. Of dit zijn onze manieren van hoe je een boek schrijft. En het is daar ook heel lang bezig geweest met het eerste hoofdstuk. Waarom zou je nou Akka moeten hebben? En dat is niet een heel eenvoudig verhaal om het heel goed uit te leggen op dat moment. En Akka veranderde heel erg veel over de tijd. Die was nog erg in ontwikkeling. Dus we hebben ook hoofdstukken geschreven die nooit in het boek terecht zijn gekomen. Want die zijn in een latere versie van Akka verwijderd of vervangen door iets beters. En ook weet ik nog dat we waren op een bepaald moment klaar. En toen kwam net een heel belangrijk ding uit. Akka Streams. En ja, nee, dat moet toch in, hè, de boek? Ja, hoe gaan we dat doen? Want dat hadden we zo niet mee gewerkt. Dus toen was het ook van, oké, dan moet ik eerst leren hoe het werkt. Precies weten hoe het werkt. En dan kan ik er een hoofdstuk over schrijven. Dat kan je wel merken in het boek dat we daar wat minder kaas van hebben gegeten. Het blijft redelijk op een beginners niveau. Maar dat soort dingen maakten het heel moeilijk. En als je dan niet... Je moet zo'n 16 uur per week aan je boek werken. Als je het redelijk op tijd wilt doen. En dat was best wel veel. Dat is zeg maar heel weekend, elke week. Elke week ben je je weekend kwijt. Of je moet heel gedisciplineerd elke dag en twee uurtjes werken eraan. En op een bepaald moment wordt dat gewoon te veel. En dan stop je die weer even mee. En dan heb je weer later een plek. Dus als het je heel goed ligt, is dat misschien makkelijker. Ik vond het wel altijd heel leuk om dingen uit te leggen. En om ook presentaties erover te geven. Mensen in teams dingen uit te leggen. En daar heb ik zeker wel veel van geleerd. Dus dat zou ik wel aanraden. De ervaring heeft zeker wel grote voordelen. En ook, ik denk, een van de belangrijkste skills die je moet hebben als een goede programma is schrijven. Dus schrijven van tekst. Niet zozeer schrijven van code. Schrijven en communicatie zijn enorm belangrijk. En ondergewaardeerd. Iedereen denkt alleen maar van, hoe kan je deze bubbelsoort, weet je wel. Wat kan je deze, schrijven zijn van een paxos ofzo. Maar daar gaat het eigenlijk niet om. Naar mijn mening hoor. Het gaat voornamelijk veel meer over hoe je communiceren met je team. Hoe zorg je ervoor dat je je gebleem op kost en dat soort dingen. En schrijven heeft daar ook mee te maken. Je moet je designs delen met mensen. Je moet van alles schrijven. Dus ik dacht, nou ja, daar heb ik wel een voordeel aan. Ik heb ook een keer ergens iets over gelezen. Van dat het moment als je het gaat uitleggen aan een ander. Dan pas ga je echt leren wat je geleerd hebt. Je bent gewoon constant in practice mode. Dus als je iets aan het bouwen bent of wat dan ook. Het zou best zelfs wel kunnen zijn dat het je linker oor ingaat. En dan doe je je ding en in je rechter oor gaat het eruit. Ben je het al even vergeten? Maar het moment als je dan echt een training of een boek gaat schrijven. Dat is denk ik wel het moment dat je een reflectie doet over wat je echt weet. Ja, want wat mij betreft, vooral in dit vak. Misschien wel met bijna alles, maar vooral in dit vak. Weet je eigenlijk niet hoe het in elkaar zit. Dus je hebt een soort van mentaal model. Van hoe het werkt. En dat mentale model hoeft helemaal niet te kloppen. Het hoeft alleen maar te kloppen zoveel als jij kan zien. Dus als jij met Akka werkt en je werkt een paar weken ermee en alles gaat goed. Dan denk jij misschien wel dat het op een bepaalde manier werkt. Maar het hoeft helemaal niet erg te zijn dat het verkeerd is hoe je erover denkt. Totdat je het opschrijft, want als je dan gaat uitleggen. Ja, mijn mentaal model zit zo in elkaar en dat het moet kloppen. Dan ga je jezelf vragen, wacht even, zit het eigenlijk wel zo? Hoe zit het eigenlijk precies? Dat is wel interessant aan het uitleggen aan een ander. Je hebt gewoon wat meer diepgauw nodig dan wanneer je het zomaar gebruikt. Dat vind ik wel heel erg interessant van dit werk. Dat je in zekere zin helemaal niet door alle lagen heen kan overzien wat er precies gebeurt. Maar dat iedereen voor zichzelf een mentaal model maakt. En daarmee uit de voeten kan. Dat we dan toch nog dingen kunnen bereiken. Dat vind ik wel een heel interessant idee. Dat je op de schouders van de shoulders of giants, weet je wel. Dat je daar bovenop staat. Dat is wel heel gaaf. Ja, gaaf joh. En het schrijven van het boek zelf. Hoe is je dat bevallen? Kan je daar iets meer over vertellen? Initieel was het wel leuk. En aan het einde dacht ik, wanneer houdt dit op? Het is echt, nou ja, je gaat op een bepaalde moment. Wat ik heel lastig vond, was goede voorbeelden bedenken. Want voorbeelden moeten ten eerste niet te groot zijn. Als ik een heel echt systeem ga uitleggen aan je. Dan ben je een paar met de draad kwijt. Dan leer je meer over het echte systeem dan over bijvoorbeeld akken. En als er te weinig vlees aan de botten zit, zeg maar. Dan denk je van, ja, dit is een hele world-ding. Hoe ga ik dat dan gebruiken in mijn project? Dus je brengt op een bepaald moment een bepaald voorbeeld. En dan kan je er ook niet meer echt van af. Je hebt er allerlei dingen omheen geschreven. En op een bepaald moment ga je het voorbeeld steeds minder leuk vinden. Dus totdat je denkt van, oh, man, waarom heb ik nou dit voorbeeld gekozen? Dus het is best wel... Ja, er waren wel leuke dingen aan. Maar ja, tegelijkertijd de werkdruk die je dan gewoon in je normale dagelijkse werk hebt. En dan dit nog erbovenop. En dan je wilt nog een leven hebben, et cetera. Dus dat is best wel tricky. Ik zou het als waarschuwing geven aan mensen die... Als je lekker veel tijd over hebt, moet je het doen. Maar het is... Het is wat wel heel leuk was. Je gaat weer met die publisher, de mensen die helpen je daarbij. En die geven je allerlei tips. En dat is allemaal heel erg leerzaam. En dat je het dan ook samen doet. En dat je dan uiteindelijk het voor elkaar krijgt. Dat zijn allemaal hele leuke momenten. En dat je dan voor het eerst je boek binnenkrijgt op papier. Dat is echt heel gaaf. Ik heb later ook... Ze hebben het boek ook in het Japans en in het Koreaans uitgegeven. En daar heb ik ook copies van gekregen. Ik kan het niet lezen natuurlijk, maar het ziet er wel heel gaaf uit, weet je wel. En blijkbaar vinden ze het ook een goed boek in Japan. Een oud collega van ons, die woont nu in Japan. En die heeft contact gehad met de mensen die daar wat hebben geschreven. Of zeg maar de Japanse versie van hebben geschreven. Dat zijn allemaal hele leuke dingen. Dat je het voor elkaar hebt gekregen om het boek af te maken. Maar het was zeker bloedswetende traan, laat ik het zo zeggen. Net nadat we beide bij Xebia zijn weggegaan, heb ik je een beetje gevolgd via LinkedIn, geloof ik. Ik merkte wel dat je hier en daar in het buitenland bent gaan hoppen. Je hebt toch wel wat landen mogen werken, of heb ik dat verkeerd gezien? Ja, dat klopt. Ja, zoals ik al zei, ik heb in Zuid-Afrika gewoond. Maar ja, mijn vraag komt daar vandaan. En op een bepaald moment een lange afstandsrelatie. Dat moet op een bepaald moment een korte afstandsrelatie worden, anders wordt het niks natuurlijk. En dus daar. Maar ook op een bepaald moment een leuke opdracht. Als Scala freelancer in City bij Commonwealth Bank gekregen. En ik werd gewoon door iemand benaderd. Van, ja, gewoon, wil je dat doen? En ja, is goed, zeg ik. Maar dan moet je wel alles regelen. En ja, is goed. Oh, wacht even. Dit wordt interessant. Dus ja, zo ging het. En de eerste drie maanden ben ik dan met familie, zeg maar, daarin gegaan. Dat was echt heel gaaf. We hadden midden in de stad daar. En dan ging ik, daarna ging ik elke, wat was het? Elke drie maanden ging ik drie weken naar Sydney. En dat heb ik zo'n tweeënhalf jaar gedaan, denk ik. Ja, tweeënhalf jaar gedaan. Maar het maakt niet uit waar ik was, zeg maar. We hebben ook twee keer een half jaar in Sarasaka weer gewoond. En dan kwam mijn vrouw weer bij haar ouders en zo contact. En ook onze dochter kon dan met grote ouders en zo contact houden. Dus het was ideaal op dat moment. Rockstar. Geluk, hou geluk. Nou, het lijkt me wel leuk om de Developer Dilemma's nog eens een keer te gaan doen. Ik weet niet wat het is. Het is een beetje gejat van developerdilemma's.org, geloof ik uit mijn hoofd. Dat is een website, ja. En daar, ja, eigenlijk is het gewoon heel simpel. Er wordt een kaart getrokken en pick one. Dus er zijn twee stellingen op die kaart. En dan moet je iets kiezen. En ja, kijk, het is natuurlijk leuk om jou gewoon helemaal te verrassen. En dan jou in die zin te betrappen. Dus ik dacht, laten we het gewoon even vier keer even doen. En dan leren we je gewoon op die manier kennen. Dus ja, let's go. De eerste. A monolith of microservices? Je moet eentje kiezen. Microservices. Oké, waarom? Als je moet kiezen, ja. Ja, ik verwacht dat we het hebben over een groot systeem. Want anders dan heb je het niet over het een of het ander. Dan heb je het over een klein dingetje. En microservices zijn wel een manier om... Het gaat eigenlijk weer terug naar die communicatie wat je eerder over hadde. Als jij aan één systeem met heel veel mensen moet werken, dan krijg je steeds meer communicatie over het. Dus een grote systeem opsplitsen in bekende interfaces, in een duidelijke verantwoordelijkheid per onderdeel, is een goede manier om een grote problemen op te splitsen in kleine problemen. En in die zin zie ik dat een microservice daarin een goed idee is. Ook omdat je daarin als team of als subteam verantwoordelijkheid kan nemen voor een kleine onderdeel van het probleem. Waar je ook redelijk vrij in bent in het aanpassen en het veranderen van de software. Bij de monolith zit je meteen weer vast aan, we moeten alles samen deployen, maar ook samen version control, samen alles. Dus bij de microservices moet je wel wat meer qua design doen, en wat meer nadenken over die juiste kaders, die juiste constraints. Maar bij grotere systemen zie ik daar wel een voordeel in. Natuurlijk hebben microservices ook een nadeel, de chaos die er kan ontstaan, maar er zijn ook wel weer methodes en technieken voor waar je ervoor kan zorgen dat het minder een gevaar wordt voor standaard protocolen kiezen, voor standaard dingen als Kafka of message buses kiezen. Dus ja, ik ben er wel uit. Dus we zouden je niet gelukkig maken als een project voor je uit kiezen waar monolith wordt gekozen? Nee, dat maakt het project niet uit. Kijk, je moet het probleem oplossen en je moet gewoon, wat je ook moet doen, je moet het voor elkaar krijgen. En ook een monolith kan je mooi doen. Ik bedoel, al die jaren voordat mensen microservices benoemden, hebben we ook genoeg gemaakt. Het is niet een, hoe zeg je dat, een zilver bullet. Nou, hartstikke goed. Fijn, dankjewel. Het is goed om ook weer jouw kant van het verhaal te horen. Nou, we gaan nu door naar de volgende. Hang on, monorepo of multiple repos? Oeh, ja, vanwege de microservices kan ik zeggen multiple repo, misschien, af en toe als je verschillende teams hebt. Maar ik vind dat wel een lastige, want ik heb allebei gedaan in vorige projecten en ook geswitcht van de een naar de ander. Zowel van de een af naar de ander. Een monorepo heeft natuurlijk duidelijke voordelen in dat je niet elke keer hoeft te releasen, et cetera, van je sub-onderdelen. Dus dat geeft wel een beetje de voorkeur. Alleen, dat kan dus niet in elke situatie. Bijvoorbeeld in dat microservices systeem dat we net overhadden, is dat duidelijk een voordeel, omdat als je hele duidelijke kaders hebt, hele duidelijke afscheiding hebt in systemen, dan kan dat wel zin hebben. Maar ja, goed, er zijn natuurlijk ook genoeg bedrijven die hun hele bedrijf in een monorepo doen. Dus ik heb wel het idee dat dat redelijk zwaar wordt in Gitflow of iets anders, om het allemaal een beetje in kaartjes te houden. Ja, volgens mij hadden we ook een keer een aflevering, toen hadden we het over dat sommige repos echt zo groot werden dat men echt met USB-sticks en zo met elkaar moesten gaan delen. Weet je nog? Zo, ja, echt. In ieder geval via USB had je alles binnen kunnen trekken. Maar ja, dan moest je dan ook weer... Ja, het is echt bizar af en toe, maar goed. Het blijft lastig, he? Deze is inderdaad een it depends. Dat gevoel krijg je ook een keer weer. Ja, ik heb ook eerder wel eens... We hadden allerlei losse repos, maar na een tijdje krijg je een verschrijdend inzicht. Ik kwam erachter van, dit heeft eigenlijk allemaal met elkaar te maken. Nou, dan zijn die allemaal weer naar één repo gegaan. Dus ik denk dat dat ook iets heel natuurders kan zijn om die vraag telkens te blijven stellen. Niet per se te zeggen het is het een of het ander, maar op basis van context te bekijken. Ja, het is wat mij betekent ook vergelijkbaar met best practices. Best practices die volgen je als je het nog niet helemaal weet. En nadat je dat al heel lang gedaan hebt, kom je er misschien achter van, wacht even, dit is helemaal niet het ideale ding in onze context. Dus ja, niet vast komen zitten is een heel belangrijk ding om voor te waken. Zeker? Zeker. Oké. Nou, gaan we door naar de derde. Assembly of COBOL. Wow. Ik moet kiezen. Man. COBOL. Ja, ja, COBOL. Van wat ik moet doen elke dag? Ja, COBOL. Nee, als ik gewoon iets, als ik een perl interface ofzo moet schrijven of iets voor een, voor een of andere chipje ofzo, dan Assembler. Maar als iemand zegt van, maak even een website in Assembler, no ways. Nee, dat kan niet. Gewoon te veel werk. Als je zegt, als je zegt welke vind je leuker, dan is Assembler veel leuker. Je kan daar hele leuke dingen mee doen. Er zijn allerlei trucjes die je kan vinden. Oké, nou dan gaan we naar de laatste. Clean code of good documentation? Clean code. Ja, clean code. Ja, clean code heeft geen documentatie nodig dan. Ah, oké. Dat is een open deur deze. Ja, wat voor een documentatie, right? Documentatie op code is, in een uitzonderlijke situatie, noodzakelijk. Als je iets heel complex doet, dan zou je dat kunnen doen. Ik moet zeggen dat ik tegenwoordig steeds minder documenteer op code. We hebben er nog geen nadeel van gehad, maar het kan soms zijn dat de opdrachtgevers die dat niet verijzen. Of je schrijft een API, dan moet je heel veel documentatie hebben voor de API, maar niet voor de private parts. En clean code, dat moet je sowieso doen, in de zin van, ja, code wordt vaak weer gelezen, dan geschreven, et cetera. Maar ik ga er ook niet te ver in. Dus je kan ook te veel polijsten. Je kan te veel daarmee bezig zijn en niet je deadline halen, bijvoorbeeld. Dus technical debt is oké, zolang als je maar het wel in de gaten hebt. Je kan niet te gek gaan, maar alleen maar puur focussen op clean, clean, clean. Ja, daar kom je ook weer nergens mee, zeg maar. Je moet vooral doelgericht bezig zijn. Dat waren ze. Ja, joh. Wat vond je ervan? Ben je aan het zweten geweest, Remo? Nee, ik vind het wel leuk. Ik vind het sowieso wel leuk om daar code in het algemeen te praten en wat er toe duwt. Daar ben ik wel al veel mee bezig ook. Hoe ga je met je team echt het verschil maken? Dat is toch altijd maar de vraag. Zeker. Dat is een mooi bruggetje ook. Meestal doen we in elke aflevering, proberen we in ieder geval even een beetje te kijken van goh, wat is er de afgelopen tijd op Twitter gebeurd? Ik zag wel een linkje naar een Twitter feed van een der Obasanjo. Obasanjo, ja. Carnage for Life heeft hij als Twitter. Ja, dat is echt... Opinions about product management, technology news, inclusivity in tech. Diversity is about demographics. Inclusion is about creating a sense of belonging. Nou, hele wijze woorden. Maar wat hij zei, dat was trouwens 1 oktober afgelopen jaar. Dat is een beetje lang geleden, maar goed. The longer I'm in tech, the more I'm convinced that microservices were a technical solution to our organisational problem. Ja, dat klopt wel, ja. Ik bedoel... Ja, ik denk dat het wel... Er zit wel een waarheid in in ieder geval. Ik denk dat jullie ook al bij wel gehoord hebben van Conway's Law. Of van Conway's... Conway's... Dat het... Dat het organisatie zich afspiegelt naar... Of nee, dat... Het gedrag zich afspiegelt naar de organisatie. Of het draait nu misschien even een beetje verkeerd om, maar... De hele reden voor verschillende teams die werken aan iets en die organisatorische reden daarvoor die zorgt vaak voor de microservices. Het feit dat bepaalde mensen in een bepaalde afdeling zitten, andere mensen in een andere afdeling, die gaan allemaal wat maken, maar ze kunnen niet per se samenwerken, want ze zitten in andere afdelingen. Dat zorgt in zekere zin voor het moeten maken van afzonderlijke afdelen van software en die weer aan elkaar knopen. Ik weet niet hoe jullie zijn, maar ik werk het liefst met een team van ongeveer 5, 6 man. Weet je wel, als het groter wordt, dan wordt het allemaal weer heel moeilijk met communicatie en met wie gaat wat doen. Dus dat probleem van hoe organiseer je jezelf om grotere dingen te maken, dat kan je wel afspiegelt zien in die microservices manier van weten. Dat denk ik wel, ja. Nou goed, Ray, ben je een nieuw boek aan het schrijven? No way! Eén keer en nooit meer. Dat kost me gewoon te veel energie. Het was wel leuk, maar ik heb er echt geen tijd meer voor. Ik heb ook een paar mensen in Twitter ook wel aan me gevraagd van wil je niet de tweede editie doen, maar ik heb nu gelukkig een collega van mij gevonden die het waarschijnlijk afgaat maken. Je hebt mensen die elke paar maanden een boek doen. Die hebben het helemaal gevonden. Maar voor mij was het te veel werk om naast mijn werk te doen. Dat is al veel eisend genoeg. Ik moet mijn familie ook nog een foto zien. Maar het was wel heel leuk om het af te maken. Omdat we de checkboxen zetten. We naderen eigenlijk al bijna aan het einde. Maar voordat we dat gaan doen, leek me leuk om even stil te staan bij wat tips en tricks. Ray, heb jij misschien een paar leuke tips en tricks voor ons? Ik zit ook te denken van, wat zou een tip zijn? Ik probeer het een beetje on the spot te bedenken. Maar wat zou nou een tip zijn? Er zijn genoeg dingen op de lightband site die interessant zijn. We zijn nu ook met AK Serverless bezig. Dat is een nieuw product. Dat is helemaal gebaseerd op stateful functions. Maar ook event sourcing en dat soort dingen meer. Dus dat is zeker interessant. Dat is een beetje de nieuwe manier waarop we AK aan het publiek willen loosstellen. Dus dan halen we een heleboel dingen. Wat ik eerder al zei, die AK toolkit is een hele mooie toolkit. Maar wat moet je allemaal gebruiken? Dat wordt heel lastig. En eigenlijk willen mensen gebruik maken van de voordelen van AK. Want heel veel grote bedrijven maken gebruik van die enorme schalen. Zoals Apple, PayPal, doe ze maar op. Allerlei grote bedrijven die er gebruik van maken. Dus iedereen wil die voordelen. Maar niet per se de hele diepe kennis van al die systemen. Want die grote bedrijven stoppen daar veel meer tijd in. En AK Serverless is een model waarin je ook in andere talen dan Java en Scala gebruik kan maken. In zekere zin van AK. Dus intern draait er een AK Cluster met persistence en alles. Maar in AK Serverless kan je gewoon... Eigenlijk JavaScript, Golang, allerlei andere talen kan je ook gebruiken. Dus dat is misschien heel interessant om in te kijken. Dat zou dan wel een tip zijn. Ik zat toevallig vandaag op Twitter te kijken. En ik zag iemand posten over GitHub. Dat je ook Visual Studio Code in je browser kan openen. Dus dan moet je... Eén, ga naar elke repo op GitHub. Twee, vervang GitHub in de URL met GitHub 1S. Dus je voegt 1S toe. En dan voila, heb je Visual Studio Code. Ik ga het even proberen. Dus dan heb je GitHub 1S. Ja, nummer 1. Dit is cool. Ik zal ook straks de link even delen naar die tweet. Er is ook iemand die dan gereageerd had daarop. En het schijnt dus dat GitHub ook zijn eigen Codespaces maakt. Sorry, ik bedoel het heet Codespaces. Dat is dus ook zo'n instant dev-environment in je browser. Dus ze zijn ook bezig om een cloud-editor. Wauw, dit is wel heel nice. Ja, ze zijn lekker bezig, zie ik. En mijn laatste tipje, maar goed dat is meer persoonlijk misschien. Ik wil ook inderdaad wat meer in rust gaan duiken. Ik vind echt de documentatie van rust, die vind ik echt supergoed. Want dat legt je echt in hele simpele stappen uit. Dat doe je in kleine stapjes. Ja, dan moet je maar eens een keer gaan naar docs.rust. Ja, het is echt geweldig hoe ze dat doen. Ze nemen je in baby-stappen naar Hello World. En dan van Hello World weer naar het model dat rust omarmt. Het is echt heel nice. Daar wil ik ook meer mee gaan doen met rust inderdaad. Heel interessant. Mensen worden er rustig van. Zo, beste mensen, dat was hem weer. Ja, we gaan nu echt richting de afronding van onze podcast. Allereerst wil ik Raymond weer bedanken. Thanks man voor je deelname aan deze podcast. Alsjeblieft. We vonden het volgens mij allemaal hartstikke leerzaam. Ik denk dat we ook nu elkaar beter begrijpen in de software development landscape. Dus ja, super thanks daarvoor. Ja. Voor degene die nu zitten te luisteren. Je kunt je abonneren op onze CodeKlets podcast. In je favoriete podcast player. Zoek daar gewoon op CodeKlets en voeg ons toe aan je favoriete. Wil je ons spreken? Of in ieder geval chatten? Babbel dan met ons mee op Slack. We hebben verschillende Slack kanalen. Ga naar codeklets.nl om de link naar Slack te vinden. We hebben ook een Twitter en een Instagram account. Beiden zijn gewoon CodeKlets met een adje ervoor. Retweets en likes zijn altijd lief. Ik zal trouwens ook even de show notes en de linkjes naar de verschillende verdiepingen van deze podcast plaatsen. En ja, dat resteert mij alleen nogmaals bedanken voor het luisteren. En tot de volgende keer dan weer. Mazzo!",
"title": "Raymond Roestenburg over Akka",
"updatedAt": "2026-02-12T12:09:50.661Z"
}