Redmar Kerkhoff & Benoist Claassen over Crypto Trading

Oké, dus in Ruby heb je niet hele fijne ideës om mee te werken? Jawel. Goeie ideeën. De beste is RubyMine in mijn optiek en iedereen die het eigenlijk niet meer eens is, die moet lekker Vim gaan gebruiken. Helemaal goed. Starting a war. Welkom allemaal weer bij een nieuwe aflevering van CodeKlets. Dit keer zitten we alweer in aflevering 4 van seizoen 2, wat gaat de tijd toch snel. Vandaag zijn we met 2 hosts, Johnny en ik, Saber die hebben we lekker een dagje vrijgegeven vanavond. Maar goed, wel leuk weer om met Johnny een podcast op te mogen nemen. Hoe gaat het Johnny? Yes, goeienavond. Ja, gaat prima. Mogen niet klagen. Lekker weer een gezellig avondje podcasten. Ja, heel gezellig. Het is wel een beetje beroerd weer. Ik heb buiten gekeken, alle hagelstenen die komen op mijn raam, dus ik hoop niet dat de podcast daar last van heeft. Maar ja, ik hoop dat we het allemaal gaan overleven. Maar goed, ook vanavond hebben we weer 2 hele leuke gasten uitgenodigd. Onze eerste gast van vanavond is Redmar Kerkhoff. Hallo. Welkom. Ja, dankje. Ja, Redmar is een echte entrepreneur volgens mij. Hij is een eigenaar van Creative Code en verder hakt hij graag in rust Elixir en Ruby, toch? Ja, klopt allemaal. Ja, mooi. Nou, daar zullen we straks wat meer over vragen. Onze tweede gast van vanavond is Benoit Klaassen. Welkom. Goedenavond. Dat is ook echt een entrepreneur volgens mij. Ja, klopt. Benoit is eigenaar van Altrade, Neighbor Secure en volgens mij heb je nog wel een paar bedrijven die ik niet heb opgenoemd. Ja, klopt. Ja, ik heb nog Appmonet samen met Redmar, Coinray en ik heb dan nog een eigen holding bv waar ik eigenlijk uit werkte als freelancer, waar ik eigenlijk nu mee ga stoppen of afgestopt ben eigenlijk. Oké. Nou, daar kunnen we straks nog wel even over hebben. Maar ik had ook begrepen dat je een echte crypto trader bent, toch? Ja, klopt. Ja. Ja, ik ben daar in 2017 net voor de grootste bitcoin hype ooit ben ik daarmee begonnen. Oké. En voor degenen die nog nooit wat met crypto gedaan hebben en zoals ik dus, echte noobs tussen ons, zou je crypto trading kunnen uitleggen? Ja. Ja, crypto trading dat ja, het begint eigenlijk bij je dat je dat je de munt moet hebben, dus je moet een stukje van de munten moet je kunnen kopen en daarvoor moet je dus bij een exchange of een broker zitten. Dus als je daar dan een account hebt aangemaakt en je bent door het verificatie proces heen gegaan, dan kun je op dat moment kun je dus gewoon met ideal bijvoorbeeld kun je wat geld storten en zodra je dan wat euro's gestort hebt, dan kun je bij de broker bij de exchange kun je gaan zoeken naar een markt of naar een munt die je wil hebben en die je dan met euro's kunt kopen en als je dan een order plaatst dan kun je kijken of iemand akkoord gaat met de prijs die jij ervoor wil betalen en als je bijvoorbeeld 100 euro wil kopen dan zeg je ik wil 100 euro en ik wil er maximaal 10 cent voor uitgeven of maximaal 10 cent voor betalen. Nou dan kun je dus 1000 muntjes kopen en als iemand daarmee akkoord gaat dan krijg jij die munt in je bezit en dan ben je crypto-eigenaar. Oh wauw, nou mooi man en kan je daar een beetje rijk mee worden? Er zijn er vele die dat wel hebben gedaan ja dat kun je wel goed rijk mee worden. En andersom niet rijk? Ja je kunt er ook heel veel geld mee verliezen ja volgens mij was het laatst nog in het nieuws dat iemand die had weer tranen, dikke tranen omdat hij al zijn studiegeld en dergelijke erin had gegooid en helaas ging alles weer naar beneden en volgens mij als hij het nu vasthouden had dan had hij nog vijf keer zijn inleg teruggekregen dus ik denk dat hij nu huilt van beleidschap. Nou mooi en ik las ook ergens dat je je eigen platform ook in cryptotrading hebt ontwikkeld of dat klopt ja en hoe ben je begonnen? Ja ik ben toen ooit begonnen met een scanner en die scanner ja het was eigenlijk om even dan terug te gaan naar het hele verhaal van mijn crypto avontuur. Ik was dus in 2017 ermee begonnen toen had ik wat gekocht en eigenlijk niet in de intentie om daarmee te handelen dus ik heb ik heb dat gewoon laten staan en op dat moment was het in waarde verdubbeld en toen zag ik het zeg maar elke dag heen en weer schom en toen dacht ik nou misschien moet toch maar eens wat gaan verkopen om het weer terug te kopen en om te kijken of ik er misschien iets meer van kan maken. Nou daardoor was ik eigenlijk per dag na vier of vijf uur kwijt aan het zoeken naar markten om om in te kunnen handelen maar ik had eigenlijk geen idee wat ik aan het doen was dus toen ik op vakantie was en in de zondag stierlijk verveelde en toen heb ik wat YouTube video's opgezocht en toen kwam ik uit bij de YouTuber Quick Fingers Look en die had eigenlijk een hele duidelijke strategie over hoe je nou het beste kunt handelen in de crypto en ja zijn strategie past heel erg bij de manier waarop ik zou willen treden meest bekende strategie is En daar haaf hij eigenlijk zeg maar een leidraad in. Zo van nou als die dan zeg maar hier naar beneden gaat, dan moet je daar op deze weg weer gaan verkopen. En toen op zijn YouTube kanaal, toen vroeg hij dus ook van ja, als er nog developers zijn, dan zou het wel fijn zijn als een keertje iets van scanners kunnen krijgen voor onze strategie. En nou ja, aangezien ik er heel veel tijd aan kwijt was en zeg maar eigenlijk ook op zoek was naar zo'n scanner, ben ik die keertje op een avondje gaan kijken van hoe ver kan ik komen. En al vrij snel had ik iets wat kon werken. En ik herinner het me nog goed dat ik op een avond had ik weer een avondje doorgewerkt en ik ging naar bed toe en ik zei tegen mijn vriendin, ik zei, volgens mij heb ik nu iets wat best wel groot kan worden. Dat was ook echt een van de eerste keer dat ze ook echt zoiets had van oké dit klinkt echt alsof dit dat kan worden. Het gevoel was zo goed. En ik heb dat dus verder uitgebreid. Ik heb dat in de markt gezet en ik heb toen dat met Quick Fingers Look besproken en ik had ook daarbij aangegeven dat het eigenlijk altijd een betaalde dienst zou zijn. Ook omdat ik zeg maar zelf ondernemer ben, en ik ook niet zo geloof in het gratis gebruiken van ander man software om er zelf rijk mee te worden. En ik wilde natuurlijk ook gewoon een goede dienst kunnen leveren dus moest het niet zo zijn. Zeker in die periode toen de bitcoin echt maar alle kant opging lagen al die andere platformen lagen er ook continu uit en ik wilde ook gewoon wel goede service neer kunnen zetten om ervoor te zorgen dat het in ieder geval blijft draaien op de momenten dat het moet draaien. En als je terugkijkt van hoe je bent begonnen zou je dat nog een keer willen doen? Ja, zeker, ja. Geen spijt gekregen daarvan? Nee, het was dat het op dat moment pas kwam maar ja dat dit soort dingen dat is waar ik voor leef zeg maar oplossingen vinden voor problemen en het leven makkelijker maken met name voor mezelf en als anderen daar ook profijt van kunnen hebben dan is dat mooi meegenomen. In ieder geval aan, het is begonnen met een simpel programmaatje om basis te scannen zoals je dat dan noemde. Wat is het inmiddels geworden want ja je hebt dat was in 2017 dus er zit inmiddels een jaar of 3, 3,5 denk ik aan programmeerwerk dan in. Wat is het platform nu? Wat behelst het? Ja nou ja dus zeg maar toen de mensen het gingen gebruiken was eigenlijk al de respons was eigenlijk behoorlijk positief en ja het gaf alleen maar aan dat de vraag daar echt naar was en we zijn dus gewoon met die mensen in gesprek gegaan en zo van oké nou wat wil je dan hebben wat kunnen we nog verder toevoegen? Uiteindelijk of in eerste instantie kwamen ze alleen op dingetjes om de scanner uit te breiden maar later werd dus ook de vraag van ja ik zou wel graag de charts wat beter willen zien en ik zou graag wat meer informatie over de markt zelf willen zien en dat groeide dus eigenlijk uit tot een tot een volwaardige handels platform waar je gewoon makkelijk vanuit kunt traden en de grootste kracht zitten in het feit dat je op alle exchanges tegelijk kunt traden die wij aanbieden dus je hebt zeg maar één tool nodig je hoeft het maar één keer te leren en je hebt dus geen last van de verschillen tussen verschillende exchanges En je kan dus zeg maar eigenlijk met vanuit één platform kan je op inmiddels 8000 verschillende markten handelen. Oké, dus jullie zijn eigenlijk, want jullie zijn zelf dus geen exchange, jullie handelen zelf geen geld. Jullie zijn eigenlijk een schil om een exchange heen, of om meerdere exchanges heen dus. Ja, het is echt een hulpmiddel, je kunt bij ons geen crypto kopen of verkopen, je kunt alleen via ons op de exchange handelen, dus wij maken verbinding met die exchanges en dan kun je op een eenvoudige manier dan handelen. Ja, wat ik van trading weet is dat het echt enorm snel gaat he, dat is echt niet normaal gewoon. Maar hoe programmeer je zeg maar software hiervoor? Eigenlijk op de manier zoals ik altijd software ontwikkel en dat is gewoon zorgen dat je zo snel mogelijk iets hebt draaien en de rest komt later wel eigenlijk. Dus zeg maar in het begin had ik die snelheid helemaal niet nodig voor de b-scanner bijvoorbeeld, dat ging op tijd op een tijd frame van een uur, dat werd elke 15 minuten werd dat een keer geupdate en de prijzen die werden misschien elke minuut of elke drie minuten werden die een keertje verversd. Maar naar mate de vraag groter werd om een volwaardiger handelsplatform. Ja, toen moesten we dus sneller gaan en daar heb ik toen ook met Redmar over gesproken en gezegd van hoe kunnen we dit in een sneller hoe kunnen we de data sneller overbrengen en toen is Redmar eigenlijk begonnen met het maken van een van een websocket service om de data eigenlijk in in in realtime of near realtime aan te bieden aan de gebruikers. Oké, dus om het even een beetje kort samen te vatten. Jij hebt Make It Work zegmaar gedaan, gewoon verzorgen dat het gaat werken. Technical Dabbed. En Redmar heeft even gekeken naar hoe kan ik het performance maken? Ja, en zeg maar dat was dan echt voor de data aanlevering. Daar is dat echt heel erg van belang van belang en verder heb ik natuurlijk gewoon zelf ook de technical dab weggewerkt waar dat nodig was. Ik ben ik ben wel van mening dat je dat je zeg maar dingen best wel een beetje in elkaar mag hacken, zolang je het geïsoleerd kan laten staan. En als het dan niet meer goed is, dan gooien het weg begin je opnieuw, maar dan begin je met een klein stukje opnieuw, niet je hele software platform. En zo werk je rustig aan aan de verbeteringen en aan de versnellingen en krijg je eigenlijk een heel mooi performant platform op een gegeven moment. Mooi dat je rustig noemt. Maar ben ik even benieuwd naar Redmar zijn mening. Heb je daar ook rust voor gebruikt? Ja, er komt nu de sluit eigenlijk steeds meer rust in op dit moment. Eigenlijk het platform wat we nou beschrijven bestaat eigenlijk heel erg uit twee delen. Heel erg de smoel wat de verbruiker ziet, de UI en ja, eigenlijk de langzaam bewegen onderdelen. Eigenlijk als je normaal naar een chart kijkt, dan is dat langzame info om zo maar te zeggen om terug te refereren aan dat je net zei dat het allemaal heel snel gaat. Dat is eigenlijk de trage info. Die kun je gewoon eigenlijk langzaam ophalen van exchange. Die kun je dus ook voor genereren om zo maar te zeggen en gewoon laten zien. Maar op het moment dat je echt echt op de markt wil zitten. Ja, daar kwamen ze allemaal die websocket verbindingen bij. Ze bieden eigenlijk websocket verbindingen aan of via rest. Maar op rest zit eigenlijk wel heel snel een limiet, dus je mag eigenlijk ook niet heel vaak ze gaan pullen, want dan ligt er eigenlijk al heel snel via redelimit ligt eruit. Dus kwamen eigenlijk op die manier al heel snel op het plan om al die exchanges aan te sluiten via websocket. En daar kwam ik eigenlijk vanuit de hoek, vanuit dat ik vrij veel al met Elixer had gedaan, kwam Elixer eigenlijk naar voren van dat dat een goede kandidaat zou zijn. En om even snel gelijk dan naar rust toe te springen, wat je wat je vraag was. Het bleek eigenlijk ook tegelijkertijd weer dat dat Elixer ook wel heel snel weer door zijn knieën kon gaan door al het geweld wat vanuit exchanges binnenkwam. Dat op plekken waar we zagen dat het gewoon niet meer, dat het de boel niet meer trok, toen rust gebruikt. En ik moet zeggen, ik ken Elixer als een vrij performant, ja, programmeert taaltje om het even kleineren te zeggen. Je zegt al, het ging toch door zijn hoeveel, ja, zijn dat dan zulke enorme hoeveelheden data? Waar moeten we aan denken bij dat soort dingen? Ja, hetgeen waar het in ieder geval bij mij gelijk, of niet waar ik dan niet goed op match, zeg maar, want het is inderdaad een redde performant, is dat heel veel numerieke dingen bijhouden in arrays. En dat is precies het deel waar Elixer neigt heel snel juist naar linked list-achtige structuren. En er was ook niet echt een hele goede soort decimal-achtige library. Die was er wel, maar die was dus niet, die is heel erg in soort van een, ja, het standaard user space gemaakt, die voor de rest niet versnelt ofzo. En daar heb ik het eigenlijk ingevuld met rust. Maar als je het aan aantallen, af en toe dan zien we gewoon, ja, iets van 15 of 1000, als je alles bij elkaar optelt, iets van 15 of 1000 updates per seconde vanuit de exchanges binnenkomen. En dat is piek. Enkele exchanges zijn vaak 5, 6 duizend events per seconde. En events, dat zijn vaak geaggregeerde, dus dat je meerdere events van alle markten, dat is eigenlijk hetgeen wat we dan in het geval doen. Dus dat we voor alle gebruikers subscriben op alle markten die er zijn van een exchange. Dat is eigenlijk ook een beetje de reden, je zoekt het zelf eigenlijk ook wel op, doordat je allemaal alle info wil hebben van alles wat ze hebben, zeg maar. En dan schiet het eigenlijk af en toe dus naar zo'n soort pieken. En zeker als die opeens instort of juist heel erg omhoog gaat, dan zien we goed pieken richting die 25, 30 duizend events per seconde. In ieder geval, dat is dan niet ongewoon. En ja, het zou wel niet zin in kunnen liggen bij ons aan servers, want we daten ook niet op de allergrootste en duurste servers. Maar goed, dat is ook weer een afweging, een balans die je maakt met, ja dat is de deur dat we eigenlijk op alles subscriben, op alle markten, voor een, voor bij elke exchange. Er komen ontzettend veel events per seconde binnen, wat richting de 25, 30 duizend per seconde gaat, over alles genomen. En alleen al dat feit, dat kan ook gewoon voorgezorgd hebben dat gewoon Elixir in het terug naar een soort van balans en wat we in de toekomst willen, want we willen eigenlijk meer exchanges aansluiten. En dan ga je ook gewoon kijken hoeveel kost het dan om bijvoorbeeld een, want je kan een grotere server inzetten, of je kan het meer performant maken. En daar hebben we eigenlijk gewoon gekozen, en ook wat we hebben gezien in de rust, dat je vrij, met vrij weinig effort en vrij naïve code, waar je dus niet al te erg je best op hebt gedaan, is het al heel erg performant. Dus hebben we eigenlijk voor gekozen om daar meer naar rust toe te brengen, om straks gewoon voor minder geld eigenlijk qua serverkosten nog meer exchanges te kunnen aansluiten en ook die peak performance beter aan te kunnen. Hoe ga je, hoe ga je zoiets te werken? Je kwam bij rust uit na een kleine zoekactie, of wist je al het een en ander over rust en weet maar gewoon gaan proberen op te kijken van hoe het schaalt en hoe het tegen elkaar uit te spelen is? Ja, ik had al wat, ja, wat gespeeld, zeg maar, met rust. En ik was ook nog een andere library tegengekomen die het heel goed laat mengen, dus elixer en rust. Dus die een soort soort, ja, wat je ook voor Ruby hebt, dat je heel makkelijk met rust kan integreren. In dit geval is het rustler. Ja, dat is een soort van, je doet even een skeleton generatie en dan kan je eigenlijk heel snel gewoon een algoritme, gewoon in rust schrijven en daarna beschikbaar maken weer in elixer. En ja, het was eigenlijk gewoon dat je eigenlijk gewoon vanuit een beetje hobbyen ermee al door had dat het zo snel was, dat het wel de moeite waard was om gewoon, ja, delen om te coden daarin. En we zagen het inderdaad gewoon in peak performance sowieso goed door de knieën gaan. En dat is weer iets wat bij elixer gebeurd is, dat kan ook een deel aan mij hebben gelegen. In de zin van dat je kan het ook nog beter scharden, maar wat elixer heel erg doet is dat een enkele actor, want het is natuurlijk de actor programmeur model. En als je een ene actor heel erg druk maakt, dus dat hij heel veel CPU pakt, dan wordt hij juist eigenlijk door het hele systeem, wordt je een beetje naar de achtergrond gedrukt met het idee van we moeten wel zorgen dat alles blijft werken. En dat is juist eigenlijk wat je soms niet wil, want je wil eigenlijk soms juist met een hele hoge fiek, wil je eigenlijk gewoon je blijven processen eigenlijk. En dat is wel op te vangen in elixer, alleen dat is eigenlijk wel weer misschien om het feit heen werken van wat je wil doen. En daar is, daar zie je sowieso bij veel number crunching, zie je veel mensen op dat moment binnen elixer of Erlang, ja, grijpen naar die externe libraries, dus die noemen ze dan NIF. Ik weet niet of je het weet, een neder interface volgens mij. In ieder geval dat je dan naar C kan toe gaan of dus in het beval naar Rust, binnen je je VM. Hoeveel exchanges hebben jullie nu aangesloten inmiddels? We zitten op tien, tien exchanges. Een paar in de running, zeg maar. Hier altijd zo van twee of drie, we zijn er nu nog mee bezig. Ja, oké. En ja, elke exchange heeft zijn eigen API. Kan ik me zo voorstellen. Hoe ga je daarmee om? Hoe ga je te werk? Waar loop je tegenaan? Ja, nou ja, ik ben dus, want Coinray is eigenlijk ontstaan vanuit een groot gedeelte uit Altrady. Ik had al, zeg maar, de begincode gemaakt om de trade informatie, order book informatie en de candlesticks. Dus dat zijn echt trade onderdelen vanuit het handelsplatform om die rest API's gewoon elke minuut op te halen. En ja, eigenlijk zeg maar, op een gegeven moment, dan je begint met één exchange. Dan kijk je naar de documentatie van de API, van de exchange zelf. En dan pak je daarna een tweede. Dat doe je eigenlijk wel vrij snel achter elkaar, want je wil niet, zeg maar, dat je al helemaal klaar bent met één exchange, omdat dan bijvoorbeeld achter te komen dat het bij de andere exchange compleet anders is. En dat gebeurt. Dus dat is wel handig om even van tevoren te bekijken. Dus als je er dan één, twee, nou, dan heb je de derde erbij. En dan heb je eigenlijk wel een groot gedeelte van de exchanges gezien en alle exoten die daarin zitten. En heel lang heb ik, zeg maar, alle code gewoon gedupliceerd. Dus als ik, zeg maar, een exchange toevoegde, dan pakte ik alle code op, kopieerde ik het en dan deed ik de wijzigingen die nodig waren voor die exchange. En dat heb ik later, heb ik dat weer gereffecteerd naar dat het, zeg maar, een beter model was, waarbij je dan eigenlijk alleen nog de uitzonderingen per exchange overhield. En zo was het, zeg maar, toevoegen van een nieuwe exchange. Nou, ik heb het laatst weer eentje toegevoegd op die manier nog. En dan ben je vier uurtjes bezig, hooguit. En dan heb je een nieuwe exchange toegevoegd. Of voor de voor de rest kan staan. En dan heb je dus weer technical debt, die je het maar op mag ruimen, of zie ik dat verkeerd? Niet echt, want dat zijn wel echt twee gescheiden, gescheiden dingen, want de websockets, dat is wel echt een hele andere tak van sport. En en ja, daar hebben we eigenlijk wel een beetje hetzelfde gedaan, hoor. Dus het is gewoon ja, in mijn ogen is het gewoon helemaal niet verkeerd om op die manier te beginnen. Dus dus gewoon zeg maar zoveel mogelijk kopiëren en dan en dan en dan een beter beeld krijgen van wat zijn er daadwerkelijk de verschillen om het dan daarna gewoon een rondje te refactoren. Daar ben je dan misschien een dag of twee bezig en dan dan heb je eigenlijk de code zoals je het zou willen schrijven. Maar als je dat vanaf het begin af aan doet, dan en dan heb ik altijd het gevoel in ieder geval dat ik ergens tegenaan zit. De hekel om het mooier te maken, om het mooi te maken. Maar uiteindelijk moet het moet de code gewoon draaien en moeten gewoon geld mee verdiend worden en hoe het er dan precies uitziet. Ja, dat maakt niet zo heel veel uit, zolang het maar gewoon klein is, geïsoleerd en makkelijk opnieuw te schrijven. Nou, in die zin is het hier ook een voordeel als je het redelijk geïsoleerd houdt per exchange, want de changes bewegen ook per exchange. Dus op moment dat je iets moet aanpassen, zeg maar, zal het vrijwel nooit zo zijn dat je over alle andere exchanges, dus de code van alle andere exchanges moet gaan, omdat de changes die gebeuren ook juist heel plotseling, soms onaangekondigd, gewoon in productie, binnen sommige exchanges. Dus je moet soms juist heel snel kunnen handelen. En als je moet handelen op basis dat je nog rekening moet houden met alle exchanges die je ook nog hebt draaien, dan zou dat juist juist onhandiger zijn, eigenlijk in dit geval. Bijvoorbeeld in ieder geval de base class die alles voor alles en iedereen doet met heel veel cases erin verwerkt. Dat is juist eigenlijk in dit geval onhandiger. Ja, ja, je zei het al een beetje. Het kan dus ook een stuk gaan in productie. Wat zijn dat een beetje de dingen waar je tegenaan loopt? Of heb je nog vrij vaak? Oké, er zijn er zijn bepaalde exchanges, ik zal geen namen noemen, maar die die echt heel vaak gewoon dan gaat het wel een stuk. Dus we krijgen in de Altrady kanaal, we zien gewoon mensen om hulp roepen van er is iets kapot. Dan gaan we kijken. Dan zijn er geen. Want het eerste wat je meestal doet is dan naar de status pagina kijken van exchanges. Soms is de status pagina gelijk aan een Twitter account. En dan zie je dat er niks aan de hand is. Maar dan moeten we eigenlijk in onze log in kijken. En dan zie je gewoon dat er iets is veranderd en dat was de dag ervoor niet. Of het uur ervoor was dat er gewoon nog niet. En dan hebben we dat gewoon echt aangepast. En dan moeten wij scramble om het maar weer weg te werken. Of weg te werken. Ja, en soms is dat ook dus gewoon per markt. Dus het is niet zo dat wij geen alerting erop hebben staan. Ik bedoel, als er echt iets mis is, dan dan krijgen we daar ons eigen alert van. Maar heel vaak dan zegt en dan horen van gebruikers. Oh, die markt, die doet daar en daar iets raars. En dan ga je kijken en hebben ze bijvoorbeeld alleen voor die markt, hebben ze de symbols omgedraaid. Dus dan handel je niet in een bitcoin euro, maar in euro en bitcoin bijvoorbeeld. Dat soort dingen. Ik moet ineens denken aan alle alle schade claims die je misschien zou kunnen krijgen. Daarmee heb je ook al zoiets meegemaakt? Nou, die vraag wordt wel gesteld van wie is er nou verantwoordelijk? Dus als er iets misgaat. Maar eigenlijk staat er in de disclaimer van de Trady heel groot, dat je je eigen risico moet kunnen dekken. Wij zijn daar niet voor verantwoordelijk. Wij bieden aan wat een exchange aan kan bieden. Als een exchange daar last van heeft, dan kunnen wij ook niet bij de exchange onze schade claimen. En de bedragen die je bij ons betaalt, die staan ook niet in verhouding tot eventuele schade claims. Dus ja, zeg maar, als we dat wel zouden willen doen, dan betaal je misschien een tienvoudige. Ja, dat is op de reden waarom een exchange zijn ook gewoon binnen Nederland. Dat de Nederlandse bank zich al snel ermee gaat bemoeien, dat dat ook de reden is, zeg maar. En dat doen we niet. We zijn in die zin gewoon meer een doorgeefluik. En zijn dus echt ook in de afhankelijkheid van hoe de exchanges performen. Ja, en de exchanges zelf geven die garanties ook niet. Dus ook al, zeg maar, als al je geld daar op stort en er gaat iets mis, technisch gezien en alles wordt verkocht, dan is het heel soms dat de exchange zegt, nou, dit was echt onze fout en we zullen de schade dekken. Maar negen van de tien keer is het gewoon van, oh ja, sorry jongens, we gaan het oplossen, we gaan het verbeteren. Maar je hulp ben je kwijt. Dat gebeurt dan. Is dat nou ook iets waarvan jij dan nog zou zeggen dat dat wel, want relatief gezien is bitcoin toch nog wel een soort nieuw iets en een beetje een niche markt. Zou je ook zeggen dat dat soort dingen nou juist beter moeten worden voordat in het geval bitcoin een betere adoptie zou krijgen? Of is dit juist ook de charme van bitcoin, dat dat zo ongeregulert is? Als je het mij vraagt, is het wel die charme ervan. Ik weet niet of jullie in vorige podcasts al gehad hebben over de gamestop. Nee, nog niet. Oké, nou, dat was zeg maar op de stokmarkt, was dat een van de ja, meest recente. Ja, bull runs, zoals ze dat noemen. En dat werd eigenlijk veroorzaakt door een groep traders. En dat zorgde voor zoveel volatiliteit dat dat mensen daar in één klap heel rijk mee konden worden, maar ook heel erg snel geld mee konden verliezen. En in dit geval waren het dus de mensen die juist zitten op al die regeltjes en regelgevingen en al die dingen die die waren nu zeg maar aan de verliezende kant en die grepen gelijk in. En die zorgden er dus voor dat zij hun eigen geld gewoon snel ja, hun schade konden beperken. En juist daarom zou ik zeggen van laat bitcoin lekker zoals het nu is. Laat het vrij en dan is het spel is gewoon eerlijker. Dus het is zeg maar ja, mensen met weinig geld kunnen toch nog heel veel geld maken en mensen die heel veel geld hebben, hebben niet zeker de garantie dat ze daar nog veel meer van kunnen maken. Ja, ja, want ik kreeg inderdaad ook een mailtje. Ik heb een account bij de Giro en inderdaad met de hele GameStop nieuws kreeg ik wel ineens een mailtje van ja, sorry, we hebben de we hebben de trading op GameStop stilgelegd. En toen dacht ik oh, ik had dan niet ik ben niet ingestapt. Maar stel ik was was ingestapt. Dan kan ik het ineens niet meer verkopen ofzo. Wat? Dat is wel een beetje een vreemde gang van zaken. Natuurlijk dat een bedrijf dat zomaar kan beslissen voor jou over. Ja, ja. Ja, en in de crypto kan dat eigenlijk niet nu. Ik bedoel ja, een specifiek exchange kan de handel even stilleggen. Met wat voor reden dan ook? Dat gebeurt ook wel eens. Bijvoorbeeld als ze onderhoud moeten plegen, dan leggen ze gewoon de hele handel stil. Maar op de andere exchanges gaat het vrolijk door en minder met die decentralized exchanges. Ja, precies. Dat is dat is zeg maar nog een nog een stapje verder. Dus dat zeg maar echt iedereen onderdeel is van een exchange en dat je dus niet één centrale server hebt die dan regelt. Maar sowieso bij de crypto is het zo. Ja, spreiding is altijd beter. Dus je kan makkelijk over verschillende exchanges je portfolio beheren. En als er dan dus één exchange is, dan heb je in ieder geval nog op de ander genoeg staan. En als je dus zeg maar ergens je investering veilig wil stellen, dan kan dat. Als jullie team zouden mogen omschrijven, hoe groot is jullie team om dat platform zeg maar een beetje in stand te houden? Inclusief developers of misschien hebben jullie wel mensen die de boel monitoren, et cetera. We zijn heel klein begonnen. In eerste instantie was het alleen ik en de designer. Ik heb eigenlijk al vanaf dag één heb ik gewerkt met met mijn vertrouwelijke designer. Die zit in in de Oekraïne. En na je later kamer er steeds meer mensen bij. Ik heb een aantal keer mensen via Upwork op internet ingehuurd en ook weer afscheid van genomen. En inmiddels zijn we met z'n tienen nog steeds meeste freelance. Dus ik heb nog al 2d bv heeft nog geen medewerkers, maar er gaat waarschijnlijk in de dichtst bezende toekomst gaat er verandering in komen. En dan zullen de eerste werknemers op de loonlijst komen. Oh, nice. En even gekeken naar de software die jullie in het platform zelf gebruiken. Nou, rust werd net al genoemd. Zijn er nog andere technieken die jullie gebruiken om die software zeg maar live te brengen of misschien ook wel te testen, te monitoren en dat soort dingen? Kunnen jullie daar iets meer over vertellen? Ja, of het grootste gedeelte nog van van Altrady zelf is in Ruby. Maar de dingen waar de snelheid in moet komen, daar heb ik dan een mix van Crystal. Crystal is een Ruby-like taal en is ook super snel. Daarnaast ben ik toen een paar weken geleden ook begonnen met dingetjes van rust toe te voegen. Dus daar draaien nu ook wat rust services. Nou ja, zoals je al hoort, praat ik over services en is eigenlijk alles als een soort van micro architectuur. Het draait op dit moment in een Rancher cluster en dat is dan nog de Rancher 1.6 variant. En dat betekent dat zijn maar alle containers, alle Docker containers die worden dan beheerd door de Rancher zelf. Maar in de toekomst zullen we wel gaan switchen naar Kubernetes. Niet omdat we Rancher niet meer mooi vonden, want het liefste zouden we daarmee verder gaan. Maar dat wordt helaas niet meer doorontwikkeld. Dus we moeten naar de nieuwe variant van Rancher, Rancher 2.5 of 2.6 inmiddels al. Maar die gebruiken in ieder geval Kubernetes als onderliggend architectuur. Dus daar gaan wij dan ook op over. Nou ja, voor Conrad, kan Redmar misschien iets over vertellen? Ja, Conrad's stack is dat begonnen in Elixir. We hebben een REST API die op Ruby en Rails zat omgezet naar Elixir. En onderdelen in Elixir, bepaalde daadsecturen, die zijn al rust. En de upstreams die richting de exchanges praten, dit is ook allemaal Elixir, maar dat zal waarschijnlijk ook allemaal rust worden. Dat staat eigenlijk allemaal in de stijgers om dat allemaal om te zetten naar rust. En eigenlijk is daar, het is echt hetzelfde wat ik ben al net opbeschreven, het zijn allemaal aparte containers, vaak wel uit een meer monolithische codebase, maar deploybaar, of in ieder geval te parametriseren per exchange als je ze start. En dat draait ook allemaal op nog op datzelfde rangercluster eigenlijk. Dat zal ik straks allemaal naar u verschenken, hoogst het Kubernetes gaat. Met ranger ervoor als UI. Ja, en in de front-end, dat ben ik nog vergeten te vertellen, maar in de front-end wordt eigenlijk alleen maar React gebruikt. Dus voor de desktop applicatie, de web applicatie en de mobiele applicaties gebruiken we allemaal React. Voor iOS en Android gebruiken we nu nog React Native, maar daarvan gaan we ook afstappen en we gaan over op gewoon een volledige React implementatie, zodat we straks één codebase hebben voor alle front-end gerelateerde zaken. Ja, hebben jullie daar ook een speciaal, dat klinkt altijd heel mooi in de oren van één codebase die alle verschillende gebruikers gaat serveren. Is dat waar? Heb je dat echt gezien dat dat werkt? Ja, ik heb het dus de iOS applicatie is al 80, 90 procent gedeelde code. De overige 10 procenten heeft eigenlijk alleen te maken met wat wat kleine mobiel specifieke onderdelen, maar daarnaast de UI zelf. Dus ja, je moet gewoon een mobiel vriendelijk navigation UI hebben. Dus daar onderscheidt het zich dan in. Maar er is helemaal niks mis mee om dat gewoon in één applicatie te stoppen en te zorgen dat je dat je applicatie gewoon responsive reageert en eigenlijk op elk formaat goed zichtbaar is. Ja, ja, mooi streven. Ja, absoluut, absoluut. Ik had ook nog een vraag rondom monitoring. Ik lijk me best wel belangrijk dat dat jullie ook tools moeten hebben om de boel te monitoren. Kunnen jullie daar iets meer over vertellen? Ja, we gebruiken voornamelijk New Relic. Eigenlijk omdat we daar al omdat de Ruby on Rails implementatie van New Relic was eigenlijk altijd al heel goed. Alleen New Relic was heel lang eigenlijk veel te duur. Dus we gebruikten alleen de gratis versie van New Relic en dat was zeg maar je had je een 24 uur retentie erop. Maar ja, dat was voor ons in principe prima want we gebruikten het om te kunnen zien wat er nu aan de hand is om alerts te kunnen krijgen als er iets mis is. En inmiddels zijn we sinds een maandje zijn we gestapt op de betaalde versie dat ze een pricing model hebben aangepast waardoor het eindelijk een keer betaalbaar werd. Ja, in de oude versie moesten we meer dan de servers bij elkaar betalen en nu is het misschien naar 5 procent van de server kosten. Dus dat is weer uiteindelijk een keer de moeite waard om aan te schaffen. En kun je dan wat meer proactief gaan monitoren of hoe wat voor voordelen biedt dat? Ja, het voordeel eigenlijk was de gratis versie nog steeds prima voor ons. Dus voor mij was het gewoon uitgezet. We hadden geen keus en nou ja, ik bedoel, ik vind het helemaal niet erg om ergens voor te betalen, want ja, daar krijg je als het goed is ook wel weer wat voor terug. Maar nu is het ook wel weer fijn dat je je krijgt nu wel de extra retentie. Dus je krijgt nu wel de voor bepaalde onderdelen zeven dagen en dan kan je wel wat makkelijker zien van oh, hey, ik zie nu hoog verkeer. Is dat normaal op een maandag of is er nu iets geks aan de hand? Dus dat krijg je er dan voor terug. Dat is op zich wel fijn dat dat nu inzichtelijk is. Ja, want jullie houden het zelf nog steeds allemaal bij. Dus is of is er een aparte opser die die bijvoorbeeld dit soort dingen in de gaten houdt of ben je dat nog zelf? Nee, operation doen we er gewoon een beetje bij. Dat is allemaal niet zo moeilijk. Ja, nee, waarom niet? En ik denk dat het ook wel een goede is, want ja, dan leer je gewoon echt kennen wat er gebeurt in de markt, maar ook wat je gebruikers ervaren. Ja, nee, het fijnste van het zelf doen is dat je zeg maar een hele hoop fluff kan weglaten. Dus dingen die je niet nodig hebt. Kubernetes is zo ontzettend groot, we gebruiken er bijna niks van en dat hebben we ook gewoon niet nodig, want als je met z'n tienen bent en drie minder dan vijftig applicaties op je platform, dan heb je meeste van die dingen ook gewoon helemaal niet nodig. Nee, ja, lekkere lean en mean opbouwen merk ik aan je verhaal. Ja, zeker het design for today en dat soort dingen. Ja, in die zin kan het ook nu nog in deze fase. Het is ook dat met name bijna ook gewoon alle service desk vragen ook gewoon nog ziet langskomen, zodat je er gewoon met alles zet je er nog zelf allemaal heel dicht op. Nu kan dat nog en hopelijk kan het allemaal nog zo lang mogelijk. Dan zijn daardoor ook de lijntjes kort, want je bent vaak zelf in staat om eigenlijk over de hele stack te bewegen. Ja, dat werkt gewoon beter als je in dit stadium zit. Ja, helder. Ja, precies. En dan als het op een gegeven moment echt big bang schalen wordt, dan dan kan je altijd weer denken over hoe je het wil aanpakken. Maar precies dan heb je dan heb je als het goed is ook de middel om dat te kunnen doen. Dus ja, precies. We wilden ja, we hebben ook geen investeringen van buitenaf. Dus alles is zeg maar de meeste investeringen is tijd en en de investeringen geld dat dat was eigenlijk ook gewoon wat daar binnen kwam, dat werd eigenlijk gewoon direct daar weer in terug stopt. Dus vandaar dat we het altijd zonder investeringen hebben kunnen doen. Maar Kishen, jij bent van de Quality Assurance, toch? Ja, zeker. Daar heb ik nog niks over gehoord. En je hebt er ook niks over gevraagd. Ben je bang voor het antwoord? Ja, ik ben echt heel erg bang. Nee, ik had inderdaad een vraag in petto, want monitoring hoort daar ook wel een beetje bij. Dus wat je graag zou willen is dat je je klanten natuurlijk zo snel mogelijk helpt als het misgaat. En sterker nog, voordat het misgaat dat je ze helpt. Ik had ook nog even een vraag over testenachtige zaken. Als je kijkt naar hoe jullie codebase nu opgebouwd is. Kun je iets roepen over hoe jullie met jullie testen, zeg maar, omgaan? En dat bedoel ik mee de controles die jullie doen voordat jullie een nieuwe release de deur uitbrengen. Ja, dat gaat nu toch dat vervelende antwoord komen. Want dan ben ik toch wel een behoorlijke cowboy, wat dat betreft. Nee, ik ben altijd wel geweest van van testen waar dat zinvol is. En automatisch testen ben ik ook altijd de voorstander van geweest. Maar dan wel de nuttige dingen. Dus ik heb sowieso zeg maar. Ja, overal waar het nodig was, heb ik een automatisch test sweet draaien. En zeg maar, voordat de docker gebouwd wordt, dan moet die test sweet slagen. Anders kan de docker niet gebouwd worden. En dan daarna gaat het naar een staging omgeving en dan kun je het doortesten. En als dat dan werkt, dan deploy je naar productie. En inmiddels hebben we ook gewoon een quality assurance persoon die die tickets test. Dus zeg maar, als tickets klaar zijn, dan gaan ze in test en dan test hij ze door. En als het goed is, dan komt het in de nieuwe release. Maar dat is merendeel is dat voor de front-end. Dat heeft eigenlijk ook mee te maken met dat de front-end dat daar het meeste werk in zit nu. En de back-end is ja, dat draait nu gewoon al heel lang. En daar zit heel weinig extra doorontwikkeling in. Dus zeg maar, als er iets gedaan moet worden, dan zijn meestal. Misschien 20, 30 regels code die je dan doorvoert. En dan is dat eigenlijk makkelijk zelf te testen nog. Moet ik dat een beetje zo zien? Eigenlijk dat het merendeel van de code is gewoon het aggregeren van de data. En er is maar een klein stukje code waarbij je echt zou zeggen dit is ons eigen sausje. Het zoeken naar die basis zoals je het noemde. Dat is dan maar een klein gedeelte van de code. Ja, denk ik een beetje uit het verhaal zo af te leiden. Is dat correct? Ja, het merendeel van het handelsplatform zoals je net ziet. Dat is niks anders dan gewoon een beetje krut. Dus waar Ruby on Rails eigenlijk gewoon echt perfect voor is. Dat doet het nu. Dus het merendeel is gewoon iets uit de database ophalen. En het in het JSON-formaat neerzetten en klaar. Dat is eigenlijk alles wat het doet. En ja, die algoritme die dan wat meer intellectueel eigendom en code bevatten. Die zijn nu niet getest. Dat is eigenlijk geen testsoort. Dus dat is meer gewoon een visueel dingetje. Maar dat heeft er ook mee te maken met die code. Dat is ook geheim. Dus dat wordt ook niet zomaar gedeeld. Maar dat is wel een backtester tool toch? Ja, die heb ik ook zelf gemaakt. Dus je hebt wel een soort van test in de zin van je weet dat het algoritme het doet, zeg maar. Precies. Ja, omdat je natuurlijk een groot onderdeel van je algoritme is ook om te kunnen laten zien dat het werkt. Dus daarvoor moet je statistieken kunnen tonen. En die statistieken geven dus ook tevens aan dat het werkt. En als dat dus goed uitziet. En wat voor tooling of libraries, wat heb je daarvoor gebruikt? Voor de automatisering. Ja, precies. Voor de automatistest gebruik ik nu gewoon de standaard RSpec test die in Rails, voor Ruby eigenlijk daarbij krijgt. En ja, dat is eigenlijk op dit moment het enige wat ik aan automatistest heb. En die doen ook gewoon volledige integratietest. Het is ook gewoon een soort van buitenom testen. Ja, precies. Dus je doet sowieso altijd op de unit en het component, maar ook van buitenaf? Ja, klopt. Oké, ja. En heb je daar ook echt serieus wat werk aan of valt dat wel mee? Nou, dat valt op zich wel mee. Het is de reden dat ik, ja, ik schrijf niet overal tests voor. Omdat ja, vaak is het nog wel zo dat je dat je dan zeg maar eigenlijk wat ik vaak gezien heb in test is, is dat mensen een test schrijven om te kijken of een bepaalde regelcode in een in een controller staat. Ja, dat is niet zo zinvol. Dan test je niet zoveel, want eigenlijk moet het zo kunnen zijn dat als je een test hebt, dat je wel wat regels code moet kunnen aanpassen zonder dat je testfiet breekt. Dat zou moeten moeten kunnen zijn. Maar als je bij bij elke aanpassing in je controller een test moet aanpassen, dan ben je misschien iets gegevens aan het doen. Ja, ja, je wilt natuurlijk je wilt uiteindelijk zien dat je echt iets iets iets waardevol spreekt inderdaad. Ja, precies. Zoals een algoritme of ja. Dus en zit er veel business logica in jullie? Ja, in jullie architectuur of source code? Zit er veel in de in de backend valt het wel mee. Ja, het is wat analytics voor voor je voor je trades. Dus dat is het dat is het spannende gedeelte. Dus zeg maar, hoe doe ik het nou eigenlijk in de trading en de portfolio calculaties? Dus zeg maar, hoe groeit mijn balans over tijd? Dat is voornamelijk de business logica die er nu in zit. En gebruik je ook veel mocs of stubs om situaties te simuleren? Ja en nee. Voor bepaalde dingen, dus bijvoorbeeld voor de voor een exchange import. Dus je kunt zeg maar bij exchange kun je CSV files downloaden en die kun je dan importeren. Nou, daar gebruik je dan gewoon wat wat mocs voor. Dus dan kan ik zien of die die import goed werkt. En voor bijvoorbeeld de trading module. Ja, om te weten of de trading module werkt tegen de API en of die nog steeds werkt, dan zul je toch echt de API moeten callen. Dus dan dus ik heb een test suite die daadwerkelijk orders plaatsen en weer annuleert. Om te kijken of die exchange API gewoon goed werkt. Ja, hetzelfde voor de voor de websocket. Het is eigenlijk meer van je wil echt testen dat het nu werkt. Want de issues die vaak voorkomen zijn dus dat zij het zelf op productie eigenlijk hebben gesloopt. En vaak, want je ziet natuurlijk, je hebt VCR in Ruby. Dat heeft eigenlijk heel weinig nut. Want dan krijg je dan een soort vals zekerheid. Want dan betekent dat het nog werkt tegen de API die een week geleden nog werkte. Terwijl de issues die waar wij tegenaan lopen, is vaak dat de exchange nu kapot is. En het moet nu werken met de exchange. Dus daardoor zijn eigenlijk al die soort tests meer ingericht om rechtstreeks met de live exchanges te kunnen testen. Ja, dat is wel een goede aanpak. Want blijkbaar hoor ik uit jullie verhaal dat het risico daar natuurlijk groter is. Of dan moet ik eigenlijk zeggen de kans. De kans is veel groter dat er natuurlijk een integratie ergens niet meer gaat werken. Dus met andere woorden, je gaat gewoon veel meer integratie testen. In plaats van dat je misschien allerlei unit testen gaat bouwen die allerlei moxen en een hele ideale situatie voor je creëert. En dan ga je inderdaad helemaal terecht. Ga je false positiefs krijgen omdat je denkt dat het allemaal goed is. Maar dan ga je in de integratie omgevingen. Dan komen ineens wel die fouten naar boven die je anders niet had geschreven. En dan is er nog een deel dat veel exchanges de sandbox gewoon... Je had een tijdje dat ze wel sandboxen hadden aangeboden om mee te testen. En je ziet dat het vaak ook gewoon verdwijnt omdat het zo te duur is om gewoon alleen maar een sandbox up te houden. Dus zeggen ze eigenlijk in die zin ook gewoon wat we net beschreven. Test maar gewoon dat trading in productie. Dus ja, dan doen we dat maar netjes. Maar dan weet je ook zeker dat dat ook werkt. Ja, ik denk dat dat ook wel een beetje een beweging is waar iedereen mee te maken heeft hoor. Je hoort het steeds meer in continuous delivery achtige hoeken van testen in productie. Laten we eens kijken wat er gebeurt als we de performance, weet je wel, aantasten. Ja, en een andere strategie die we ook wel hanteren is door gewoon heel vaak heel weinig te deployen. Dus zeg maar, je houdt je changes echt super klein. Dus je weet ook gewoon direct van oh, ik heb net iets gedeployed. Nou, dat moet en het gaat nu niet meer goed. Dan is dat het geweest. Het is niet dat je zeg maar een hele week van ontwikkelen hebt en dat je dan eens een keertje uiteindelijk wat gaat releasen. Nee, het is eigenlijk ben je aan het einde van de dag klaar? Oké, deployt maar. In die zin zitten we inderdaad echt heel dicht op het Nieuw Relic en Sentry. Dat je deploit en je zet eigenlijk die scherm er gewoon constant bij om dan te zien of het komende uur zeg maar goed gaat. En mocht er dan iets misgaan, dan weet je vrijwel zeker dat er of een exchange uit ligt. Wat altijd kan, of het is je eigen code en dan draaien we dat gewoon weer terug. En ja, en terwijl je op zoek gaat naar wat dan de fout is. En meestal fix je het dan ook weer gewoon forward. Dus dat je je ziet wat de fout is. Dus je fixt het en je bent eigenlijk een paar minuten later dan is het weer live. Ja, veel vast, veel early dat principe dus. Ja, ja, ja, en het is ook belangrijk dat je dus heel snel kunt deployen. Dus we hebben ook geen hele grote integratie testen die jammer dat het een uur duurt voordat je überhaupt iets kunt deployen. Nee echt, het is gewoon lokaal testen. Draait je testje, prima, oké, deployen. Nou, het klinkt als een mooi product, maar het product is nog niet af, neem ik aan. Want jullie zijn nu met tien man daarmee bezig. Wat zie jij voor de toekomst? Of wat zien jullie voor de toekomst eigenlijk? Wat gaat er gebeuren? Wordt het een kwestie van meer exchanges aansluiten? Wordt het een kwestie van nog meer nieuwe algoritmes bedenken? Of heb je ideeën voor de toekomst? Of heb je ideeën voor de hele crypto-markt als toekomst? Nou ja, we willen sowieso meer exchanges toevoegen. Ook gewoon dat je dan meer mensen kunt aansluiten. Die bijvoorbeeld niet in Amerika mag je niet op elk exchange handelen. Dus er zijn alweer speciale exchanges voor. Dus om dan zeg maar de Amerikaanse markt te kunnen voorzien, moeten we ook kijken naar exchanges die alleen in die regio te gebruiken zijn. Daarnaast willen we inderdaad ook nog meer algoritmes gaan toevoegen. Maar dat staat wel eventjes op een laag pitje, omdat we nu druk bezig zijn om onze smart trading functionaliteit uit te breiden. We hebben nu al wat smart trading functies. En met smart trading functies bedoel ik zeg maar dat je, je kunt dan orders klaarzetten. En zodra er dan, zodra een order is uitgevoerd, dan gaat het systeem automatisch voor jou de volgende stap doen. En nu is het zeg maar, je doet één ding en dan doet het systeem daarna nog één ding. En dan is het klaar. Maar we zijn nu bezig om dan te kunnen zeggen, van dat je eigenlijk een hele positie van tevoren kunt gaan klaarzetten. En dan koopt hij alles wat jij op de weg naar beneden hebt staan. En dan gaat hij alles op de weg naar boven, gaat hij het weer verkopen. En dan kun je makkelijk in- en uitstappen. En je kunt rustig naar bed gaan. En dan gaat het systeem, houdt de trades voor jou in de gaten. En kun je slapen het rijk worden, zeggen ze dan. Living the dream. Iets wat we eigenlijk ook alle gasten altijd vragen. Eigenlijk is dat altijd in het begin van de podcast. Maar goed, dat doen we gewoon lekker aan het einde boeien. Laten we even bij Redmar beginnen. Hoe is het eigenlijk bij jou begonnen dat je ontdekt hebt dat je software development ambities had? Hoe is het bij jou begonnen? Een beetje rond 6, 7 of zo. Toen kwam een kennis bij ons binnenwandelen die twee dochters hadden. En die hadden geen interesse in al zijn oude computers. En die dachten we kunnen we hier wel droppen. Dus je kreeg letterlijk ook echt een grote doos met een MSX. En dan komt er door 64 met een tape recorder erin. En dan een hele oude tv waar je altijd een paar keer op moest rammen. En dan deed je het weer. En dat was dan op zolder. En dat was gewoon lekker helemaal op los gaan. In de zin van niemand keek echt met je mee. Dus je kon er gewoon helemaal mee experimenteren. En allemaal van die programma's die je dan uit zo'n soort boek komt natypen. En dan kreeg je opeens een spelletje. En daar is het een beetje begonnen. En toen is het meer naar 0,86 toe gegaan. Zo'n oranje beeldscherm. En daar een beetje met QBasic aan de haal. En toen is het een beetje doorgerold naar bijna verslaving van Quake. Quake-verslaving. First person shooter. En toen had ik eigenlijk nogal wat motten met mijn ouders. Die trok ook af en toe gewoon de kade eruit. Of stoppen als ik er te lang door ging. En toen kwam er opeens een hele hoge telefoonrekening van over de duizend gulden. En toen had ik een probleem. Want toen moest ik dat op een of andere manier zien te betalen. Want mijn ouders zeiden, ja, het is leuk dat jij heel veel gespeeld hebt. Maar ga het maar eens even terug verdienen. En toen kwam eigenlijk het verhaal van, nee, je kan je ook geld mee verdienen. Ik had aardig wat tijd erin zitten om een clan homepagina te maken. Dat was toen volgens mij met Flash. Ja, en gewoon HTML, CSS. En toen ging ik gewoon ergens gewoon, het was een beetje bij toeval, kwam ik ergens terecht. En daar kon ik gewoon 25 euro per uur krijgen van die man. Dat was een eenmanszaak. Als ik hem ging uitleggen hoe hij dat moest doen en gewoon voor zijn klant te werken. Dus ik had die duizend schulden vrij snel weer terug verdiend. En mijn ouders had echt zoiets van, is dit wel helemaal kosver? Is het niet zo dat hij andere dingen aan het verhandelen is of zo? En vanuit daar is het eigenlijk in één keer doorgerold naar, ja, eigenlijk zo snel mogelijk toen ik 18 was, schaam van koophandelen, maar aanvragen en ja, en er gewoon in werken ook gewoon, omdat ik het gewoon heel leuk vond om te doen. Je wordt er allemaal mee creëren, zeg maar. En zo is het eigenlijk gaan rollen. En toen HVU en dat was eigenlijk te makkelijk. En toen ben ik naar TU Delft gegaan en daar kwam ik dan Benoit tegen. Ja, en de rest is history. En Benoit, hoe is het bij jou begonnen? Ja, ik was iets meer volwassen toen ik begon. Ik was 12. En ja, ook gewoon begonnen met wat basic scriptjes. Toen we dan voor het eerst een webbrowser kregen, ben ik al gelijk html pagina's gaan maken. We hadden nog ineens internet, maar webpagina's maken. Dat vond ik wel leuk. En en en dat toen ik 15 was, heb ik dat ook een paar keer voor wat geld gedaan, maar niet heel veel. Ik was eigenlijk liever lui dan moe. Dus ik werkte ook nergens anders. Ik had heel veel gespaard in mijn leven. Dus ik hoefde ook niet te werken om gewoon uit te kunnen gaan. Maar als je dan 16 bent, dan gaat je geld ook nog wel redelijk snel op als je gaat stappen. Dus op mijn 19e moest ik wel echt gaan werken. Dus toen ben ik meer gaan werken. Maar dat was niet nog in de IT. Wel met elektronica. Ik was gewoon verkoper in de elektronica zaak. En dat was wel oké. Wel veel verkoopervaring opgedaan. Dus dat was goed. En daarna ben ik bij de Phono's gaan werken. En toen ik bij de Phono's werkte, toen heb ik nog meer aan mijn sales kunsten gewerkt. Maar toen bleek toch wel dat het het ontwikkelen van web applicaties, dat dat meer bij mij lag en dat ik dat leuker vond. Dus toen ben ik naar de Phono's ben ik bij als freelancer aan het werk gegaan. Bij een IT bedrijf hier in Den Haag. En dat heb ik eigenlijk steeds verder uitgebreid. Totdat ik samen met Redmar eigenlijk bij Digidentity terechtkwam. Waar we later ook Johnny tegenkwamen. Hallo. Dat was een klein geheimje. Ik ken jullie al eigenlijk. Dat heb je goed. Beter verborgen te houden. Ja, precies. Nee, oké. Johnny, hoe is het bij jou eigenlijk begonnen? Ja, ik heb het nog niet verteld in de podcast volgens mij. Maar het is inderdaad voor mij wel een beetje een soort ander verhaal. Ik was meer gewoon een gebruiker. Ik ben ook iets jonger dan Redmar. Het scheelt niet zo heel veel, maar een paar jaartjes. Dus ik ben net even wat later het internet opgeklommen. Maar ik was met name inderdaad een gamer en een gebruiker. En ik was heel erg behendig geworden vooral in het downloaden van allerlei dingen via Kaza en iDonkey en al dat soort programma's. We zullen er niet over hebben wat het dan allemaal was en of dat allemaal zo netjes was natuurlijk. Maar goed, daar was ik met name mee bezig. En ja, op een gegeven moment werden de social platforms weer een ding. En kreeg je CU2 en Hives en al dat soort dingen. En bijna bij CU2 volgens mij was er echt een stukje dat je jezelf ook echt HTML kon schrijven om je pagina er koeler uit te laten zien. Dat hebben ze volgens mij later bij Hives ook nog wel een stukje overgenomen. En daar ben ik eigenlijk pas begonnen. Omdat ik toen al vrij snel tegen de limieten van die platforms aanliep. Ja, heb ik daar een link neergezet naar mijn eigen webpagina die ik toen bij de DSL provider kreeg. En op die manier ben ik inderdaad met een simpel editertje een beetje gaan lopen HTML'en. En ja, daar was het vrijwel bij gebleven. En ik was gewoon in mijn puberteit met name een gamer. En ik heb altijd in de supermarkt gewerkt. Ik heb elf jaar in de supermarkt gewerkt en daar verdiende ik best lekker voor die begrippen. Dus ik kon ook altijd alles doen wat ik wilde. En toen op een gegeven moment ben je klaar met je middelbare school. En dan is het van ja, wat gaan we doen? En dan was het van nou ja, ik ben wel goed met computers volgens mij. En zo ben ik een beetje ingerold. Toen ben ik maar informatica gaan studeren. En ja, van het een is het ander allemaal gekomen. En ik moet zeggen, het bevalt me uiteindelijk prima gelukkig. Maar ik ben gewoon in loondienst en ik ben een loonslaaf. En ik hoop ooit wel eens inderdaad ook een eigen bedrijf te vinden. Of in ieder geval een mogelijk business case te vinden voor een eigen bedrijf. Maar dat is op dit moment nog niet gebeurd. Maar ja, dus een hele andere route naar programmeur dan van Redmar en Benoit. Nou leuk, dankjewel dat je het even gedeeld hebt. Een beetje een soort gelijke ervaring. Volgens mij was ik wel rond de 14 ofzo. Toen was ik ook veel met het leren hoe in DOS het beep geluidje werkte. Dat kan ik me nog wel herinneren. Ik was daar zo van gefascineerd dat je het beep geluidje in een batch bestand kon aanpassen. Dus dat je ook verschillende tonen eruit zou kunnen halen. En ik weet nog wel dat ik daar ook op een gegeven moment een deuntje uit... Zo is het bij mij in ieder geval begonnen, je gekte. Ik stel voor dat we doorgaan naar de volgende rubriek in onze podcast. Dat is de developers dilemma's. Nou, wat we daar doen. We vragen onze gasten om een keuze te maken uit twee dilemma's. Dat doen we drie keer. Laten we eerst maar even voor de grap beginnen bij Redmar. Dus hou je vast. Kom maar op. En Benoit, val hem aan als je wil. Als je het niet eens bent. Dat doen we nooit. Maar goed, de eerste om een beetje warm te draaien. Pingpong of voetbal? Voetbal. Waarom? Ja, weet ik niet. Ik weet eigenlijk allebei wel leuk. Voetbal kun je veel blijven staan. Dat is wel het voordeel. Misschien meestal omdat je gewoon met meer mensen eromheen staat. Dat is meer met z'n allen. Ja, ja, ja. Ah, oké. Nou, het schiet er ook iets bij mij binnen. Inderdaad. Als je pingpong zou kiezen, dan, ja. Wil je dan? Ik weet het niet. Ja, ik kan ook pingpongen met z'n tweeën misschien, maar goed. Oké, de tweede. Developer doing design of designer doing development? Ja, dat is een goeie. Ik moet even kiezen. Ja, voorlopig eigenlijk ook zou het developer doing design zijn. Want in die zin heb ik gewoon heel veel, ja, van die tijd interesse in design. Dus dan zou het dat zijn. Nou, je moet kiezen, dus dan is dat het. Ja, eigenlijk is het gewoon een recipe for disaster. Is dat zo? En jij, Benoit? Ik ben altijd super slecht geweest in design. En ik denk dat je een aantal designers nog wel basis en dingen aan aan programmeren kunt leren. Maar een developer echt laten designen, als die daar geen kaas van heeft gegeten, dat wordt toch wel erg lastig. Dus ik zou dan zeggen dat een designer best development kan doen, gegeven een specifieke taak. Ik heb dat bijvoorbeeld gezien aan mijn eigen designer. Die is inmiddels ook gewoon HTML en CSS aan het leren. En dat kan die prima. Hij kan dus prima gewoon in de code base rondgaan om hier en daar de design elementen aan te passen. En dat is eigenlijk wel een perfecte combinatie. Dus je moet designers gewoon lekker laten designen en het dan zeg maar pixel perfect kunnen maken. En dan developers lekker laten developpen. Ja, ik zit ook zelf in een agile team met multidisciplinaire teammembers. En wat er altijd geroepen wordt is dat iedereen maar alles moet kunnen. Ik denk dat dat wel gewoon wel een terechtpunt is wat je zegt. Dat op een gegeven moment heb je toch ergens. Ja, gewoon even net wat meer ambitie of misschien ook wel bepaalde kwaliteiten in dan. Het is het is ook wel leuk als je als je alles kunt en alles weet. Maar dan weet je van alles een beetje. Dus je hebt ook je hebt wel echt experts nodig. En en en zeg maar wat ik dan als developer aan design doe, dat is zeg maar een paar schetjes maken. Dat ik denk van nou zo dan zou het er in mijn optiek ongeveer uit moeten zien. En dan geef je het aan de expert en die maakt het daadwerkelijk iets moois van. Ja, ik ben toch ook inderdaad altijd een beetje tegengekomen dat als je als developer een design aan het maken bent, dat je eigenlijk een design altijd aan het maken bent, wat past bij hoe je developer hoe je code base eruit ziet, zeg maar een beetje in welke stappen je code base gaan gaat ook ineens. Wordt elk stapje in je code wordt een scherm, terwijl dat niet per se altijd het meest vriendelijke voor de gebruiker of voor de voor design of te zijn. Nee, maar in het begin is dat wel echt een hele zinvolle manier. Om om je product te beginnen. Ja, want want dan krijg je het tenminste wel heel snel in de markt. En dan kun je later al altijd nog de designs fine tune en zeggen van nou welk scherm kunnen we samenvoegen? En dan hou je die weg en dan pas je je code daarop aan. Maar ja, om toch gewoon een beetje snel eruit te kunnen gaan is het helemaal niet verkeerd om te zeggen. Nou, we maken de designs die passen bij onze code base en die passen bij onze architectuur die wij voor ogen houden. Ja, oké. Nou, de laatste die gaan we richting Benoit gaan we wel even naar toe pushen. 100 procent CPU. Of 2 procent batterij. Ja, het is allebei frustrerend. Maar ja, 100 procent CPU dan maar. Ja, want daar is 9 van de 10 keer toch nog wel net iets mee te doen. Met 2 procent batterij houden we toch wel snel op. Ik had zo net even de 100 procent CPU probleem. Maar we zijn er weer, dus dat is snel opgelost. Ja, ja, dat is ook wel zo. Dat is waar. 2 procent batterij als je in de trein zit is toch echt wel frustrerend. Ja, dat is helemaal waar. Dat is helemaal waar. Nee, helemaal goed. Even kijken. We hadden ook nog een andere ertussen staan. Ah ja, er was nog eentje van Saber. Hoe is het? Ja, die had dat opgeschreven. Saber wilde heel graag een code, of nee, programmeertaaloorlog. Oh ja, die had ik er voor de grap in gezet. Nou goed, dan stel ik voor dat we nog even kort stilstaan op een best wel belangrijke vraag, vind ik. Welke programmeertaal is nou de beste? Haha. De beste programmeertaal. Is die er? Nee. Nee, die is er niet. Nee, wel niet. Nee, nee. Ja, bedoel, als je het aan mij vraagt, welke programmeertaal zou je kiezen voor? Dan is negen voor tien keer het antwoord Toby. En dat heeft er dan gewoon mee te maken met dat het voor mij is het super makkelijk. Ik werk er al zo lang mee. Ik weet precies hoe ik daar heel snel dingen mee kan realiseren. En als je dan daarna doorgaat, dan ga je langzaamaan dingen vervangen voor andere talen omdat Ruby dan gewoon tegen limieten aanloopt. En zo kijk ik eigenlijk altijd naar dingen. Dus ja, maar je moet gebruiken wat het snelste jouw doel bereikt. En als jouw doel is om het zo snel mogelijk in de markt te zetten, kies dan iets wat dicht bij je past, iets wat makkelijk voor je is, waar je bedreven in bent. Waar je eigenlijk geen vragen hebt over hoe zou ik dat zo moeten aanpakken, dan kies je die taal. En als je tegen limieten aanloopt, dus als je doel is om de applicatie zo snel mogelijk te laten draaien, dan ga je misschien kijken naar talen zoals Rust. En zorg je dat je je daar eigenlijk tot je doel komt. En in dat geval is dan vaak de snelheid. Ja, want ik weet nog wel ergens in het begin, volgens mij was dat Redmind inderdaad. Die werd gevraagd om iets in C aan te passen waar je niet zo blij mee was. Ja, dat is een langlopend project waar ik een soort van verantwoordelijkheid voor heb gepakt. En dat is een soort embedded C-achtig verhaal. En dat is eigenlijk alleen maar hetgeen waarom het niet heel erg leuk is, is er eerder omdat het gewoon het stukje embedded is dat heel langzaam gaat. En waarbij je heel erg verhankelijk bent van de fabrikant, dat het allemaal precies zo werkt als dat zij aangeven dat het werkt. Het is vaak moeilijk om de juiste vraag te stellen en het juiste antwoord te krijgen van zo'n fabrikant, terwijl je al verdwikkeld bent. Dus het is eerder de frustratie misschien niet zozeer van de taal zelf dan meer van de gang van zaken met de fabrikant ervan. Allewel het wel zo is dat als je eenmaal rust hebt gedaan en je gaat C doen, dan krijg je heel veel frustratie omdat je dan merkt hoeveel de compiler voor je doet bij rust. Dus kleine foutjes, typos enzovoort, eigenlijk niet serieus typos, misschien wel meer inhoudelijke issues, waarbij je verkeerd doet met een pointer wat dan ook. En rust zorgt gewoon voor dat je dat niet kan doen eigenlijk. Oké, moet ik dan denken aan IDA ondersteuning of runtime hulp? Waar moet ik aan denken? Het zit in de compiler, maar het wordt ook in je IDA aangegeven. Dus uiteindelijk merk je het eigenlijk super snel, want meestal binnen een paar seconden zie je al gelijk, ik denk dat het vaak zelfs onder een seconde zit, zie je gewoon een aanpassing, zie je een rode streepje eronder, wat dan ook, en dan zie je gewoon dat de compiler je waarschuwt in je IDA, dat je iets aan het doen bent wat niet helemaal mag. En wat dan in Cezar maar gewoon tot een zegval zou leiden, maar in rust krijg je gewoon een compiler error dat het niet meer goed zit. Ja, dus je compiler leeft gewoon echt met je mee en die helpt je. Nou, dat is in ieder geval mooi om te horen. Zijn dat soort praktijken ook bij Ruby aan de gang? In welke zin? Nou, gewoon dat je echt tot de ondersteuning krijgt. De developer-ondersteuning. Dat je sommige fouten die je compiler gewoon sneller ziet, dat je gewoon snel ziet van, oké, er gaat iets mis. Ik denk dat het een van de grootste nadelen is van Ruby, dat het dynamisch is. Maar je hebt altijd nog Wim. Oh, oké. Wim! Ja, ja. Ik zat er tevallig vandaag nog mee. Oké, dus in Ruby heb je niet hele fijne ideeërs om mee te werken? Jawel, ja. De beste is RubyMine in mijn optiek. En iedereen die het eigenlijk niet meer eens is, die moet lekker Wim gaan gebruiken. Helemaal goed. Starting a war. Nee, RubyMine is echt... Ja, dat was echt een geschenk wat kwam. Daarvoor was het TextMate. En TextMate was een fijne editor om gewoon lekker snel in te kunnen typen. Maar om gewoon snel code te kunnen schrijven, dan is het ook wel handig dat je heel snel door code heen kan springen en kan zien wat de oorspronkelijke sourcecode is van bepaalde implementaties. En daar is RubyMine echt geweldig voor. Je hebt eigenlijk geen Ruby documentatie nodig, want dat zit gewoon in je idee daarin begrepen. En die helpt je ook gewoon nog wel met codeanalyse. Dus zeg maar, als jij een functie probeert te callen die niet bestaat, dan zegt hij ja, volgens mij bestaat die niet. Maar in Ruby kan dat wel hoor. Dus die functie kan gewoon bestaan, maar dat de idee het niet ziet. Dus dan negeer je dat soort meldingen. Ja, mooi. Oké. Nou, dan hebben we een kleine oorlog. Nou, het was niet echt een oorlog, vond ik. Maar goed, we hebben een leuke discussie ook. Ja, jullie kennen elkaar zo goed, dus kom op. Wat willen jullie? Dan moet je de juiste onderwerpen pakken. Ja, ja, ja, ja. Nou, goed. Even kijken. Ik stel voor dat we weer doorgaan naar een andere rubriek. Dat zijn onze rants in de developer land. En ik zag een hele mooie die Johnny had opgeschreven. Misschien kan jij hem even verder toelichten. Ja, goed, het scheme er net al een beetje door. Natuurlijk. Ik ken Redmar en Benoit en wij programmeren alle drie of programmeerden. Alle drie, ook in Ruby. En in Ruby was afgelopen na twee weken geleden inmiddels een aardige shitstorm ontstaan. Omdat er een licentie probleempje was. En aangezien Redmar en Benoit ook in die Ruby wereld zitten, hoopte ik stiekem dat ze dat ook mee hadden gekregen. Hebben jullie dat toevallig of niet? Ik van de MIME types. Ja. Ja, en ik vroeg me af, want om even een klein beetje achtergrondinformatie. Er is dus een library die veelvuldig gebruikt werd in Ruby wereld, ook door Rails zelf. Dus een bepaalde versie van het Rails framework, wat voor webdevelopment in Ruby gebruikt wordt. Daar zat een licentie probleempje in verstopt. Want die gem die gebruikte een bepaald onderdeel wat gelicenseerd was onder. Ja, dan moet ik het goed zeggen. Die was gelicenseerd onder GPL en de gem die het gebruikte was gelicenseerd onder de MIT license. Wat er eigenlijk zoveel zegt als ja, dat stukje wat er nou wat gebruikt werd, dat mag helemaal niet opnieuw onder een MIT license worden uitgegeven. En alle software die daar vervolgens gebruik van maakte van deze gem, in MindMagic in dit geval. Die was dus eigenlijk een soort van instrijd met de licentie overeenkomsten die je aangaat zodra je die software gaat gebruiken. En dan vroeg ik me af, dit is nou iets wat naar boven is gekomen en hals over kop. Iedereen kon ineens zijn applicatie niet meer bouwen, want de versies van die library werden gewoon keihard van het internet afgejankt. En daardoor falden beelden her en der. Dus ja, een soort van hele ruby wereld stond in brand. En ik vroeg me af, hebben jullie een mening over open source software en de licensing en hoe gaan jullie daarmee om? Want ik moet zeggen, ik heb zelf nog nooit een license zitten lezen van een stukje software wat ik gebruik of een library die ik wil gaan gebruiken. Maar ja, nu blijkt dat dat soms dus toch best voor problemen kan zorgen. Hebben jullie daar een bepaalde mening over? Ja, we hebben al een tijd toen we bij Dignity heel actief waren, waar we eigenlijk wel het woord van mening, dat je eigenlijk alles gewoon moet bundelpekken. En dat heeft ons eigenlijk wel een paar keer volgens mij wel geholpen. Dat is natuurlijk niet direct misschien antwoord op je vraag over die licenties, maar wel een deel wat er nu fout is gegaan volgens mij. En dat is dat ze zomaar de boel hebben gejankt, de package weg hebben gehaald en dat iedereen een probleem had. Ons hele idee van het bundelpekken was juist dat je eigenlijk wat je oplevert, dat het een artifact is en dat het altijd soort van moet kunnen blijven draaien. Volgens mij is het ook een beetje ingehaald door Docker en dat was toen eigenlijk nog voor Docker. Dat je tenminste altijd kon zeggen vanuit je source tree van dit is een artifact en dit is te bouwen, zeg maar. En volgens mij sinds Docker zijn we daar een beetje van afgestapt omdat we toch al nog steeds artifacts bouwen, maar nu zit het allemaal in een Docker verstopt. Dan heb je dan een voordeel met Ruby dat je daar gewoon die library gewoon uit kan plukken, de source code. Want had je dit dan, zeg maar, in een gecompileerde taal gehad, dan had je daar alleen maar de binary staan. Ik ben zelf van mening bij zulke soorten issues als dit, dat je eigenlijk immutable repos hoort te hebben. En volgens mij zijn die er ook in sommige talen. Dat de package, zeg maar, immutable is. Dus dat je het niet zomaar kan yanken en als je het wil yanken, dan moet je het soort van in overleg doen met het team wat daarachter zit. Want ja, het is een beetje de vraag of dit niet een beetje een te zwaar middel is geweest. Het is een beetje net als een security, als er een security fix is, die echt super, super high profile is, dan yank je ook niet alles wat er voor zit en maak je een fix aan. Want het resultaat is dat heel veel bedrijven volgens mij hier echt echt goed last van hadden. En misschien wel zelfs down konden gaan als je dus gewend bent om heel snel door te ontwikkelen. Gelijk tijd is het misschien ook weer dat je heel erg met je neus op de feiten bent gedrukt, dat je hier dus een plan B voor moet hebben, dat je hier op voorbereid moet zijn. Maar licensing wise, gewoon puur van of we daar op letten. Ik probeer altijd wel een beetje te letten op dat het niet A, G, P, L, G, P, L is, omdat dat voelt gelijk al van hier moeten we wat mee. En heel vaak kan je het gewoon op MIT of B, C, D, Aachterlijzen al lang krijgen. Dus in de zin van als je die keuze hebt, dan is die snel genomen. Maar ja. Ja, de vraag die een beetje bij mij naar boven kwam was, je zou kunnen stellen dat als jij software hebt wat van jou is en wat closed source is, maar wat al deze dingen gebruikt, ben je dan niet in strijd met die licensing. En ja, hoe ga je daar dan mee om op het moment dat de rechthebbende van in dit geval het GPL of het MIT license bestandje, sorry, het GPL license bestand, of die niet gewoon jou een hele nare tijd kan bezorgen door te gaan zeggen ja, maar jij gebruikt dit en jouw code is closed source. Maar ja, dat is nu in strijd. Ik had er een hele hoop vragen bij, dus ik dacht misschien heb jij daar ook een, of hebben jullie daar een andere mening over? Ja, in mijn beleving van die license is het ook zo dat het alleen een probleem wordt als je echt de software als pakket verkoopt. Dus als jij zeg maar de software op je eigen service draait, dan moet zeg maar de eigenaar van die software, dat ben je dan zelf, moet toegang krijgen tot de broncode. Die heb je. Maar om jouw dienst te kunnen laten draaien. Je hoeft niet je gebruikers van de dienst, zoals platforms als Altrady, toegang te geven tot de source code in dat geval. Ze krijgen de software niet. Ze maken alleen gebruik van je dienstverlening. Zo heb ik hem altijd begrepen, dus ik maak me er ook nooit zo heel erg druk over. Maar ik let er altijd wel op dat het een MIT of een Apache license is, voor zover ik het kan zien. Maar ik ga niet helemaal uitpluizen of elke library die MIT zegt te zijn, ook daadwerkelijk MIT is volledig. En dat je dus niet zoiets hebt zoals nu met die MIME types. Dat het dan blijkt dat ze een GPL license gebruiken. En eigenlijk ook moeten voeren in plaats van een MIT license. Daar let ik dan zelf niet zo op. En ik vind het dan ook, ja, zoals ze het nu opgelost hebben. Ze hadden een backwards compatible fix klaargezet. Dus ja, het was even. Ik werd er even mee overvallen, want ik moest snel een fix uitrollen. En dat ging toen niet, want ik zat toen precies tegen die package aan. Dus ik moest hem even updaten. Daardoor ging mijn uitrol tijd van een normale 1 minuut, ging het naar 15 minuten. Omdat die in Docker, zeg maar, alle gems opnieuw moest bouwen. Dus dat is dan wel vervelend en dan word je wel een beetje boos. Dus vandaar dat je dan, zeg maar, wel een beetje kan renten daarover. Maar ja, aan het einde van de dag, ja, weet je, de gem updaten en klaar. En niet meer over nadenken. Ik heb niet eens opgezocht wat nou daadwerkelijk het issue was. Het was gewoon deze gem bestaat niet meer. Oké, nou prima, pak de volgende versie. Ja, ja, in dit geval was het ook nog een beetje een soort hetse. Omdat de volgende versie juist ook weer niet correct was. En die developer, die had een aardige f app ervan gemaakt. Dus in die zin was het wel een ja, ja, wat Redmo ook zeiden. Je werd wel aardig met je neus op het feitig gedrukt van ja, dit kan gebeuren. En dat kan dus inderdaad betekenen dat je ja, dat je gewoon ja, Ja, nee, goed, je had natuurlijk ook nog met Leftpad in Node.js. Dat was ook een van de grote waar ze gewoon eventjes een library onder je neus vandaan jenken. Ja, dat dat zeker in het geval van Leftpad. Je moet dus ook altijd wel kijken. Heb ik deze dependency wel nodig? Want Leftpad, dat waren vijf regels code geloof ik. Maar met half internet hing er vanaf. Ja, soms moet je ook gewoon eens kijken. Kan deze code niet gewoon overnemen en het in mijn repo zetten en dat ik er dan gewoon zelf eigenaar van word. Voor bepaalde kleine dingen kun je dat best doen. Voor grotere dingen moet je gewoon even goed kijken. Van is dit echt nodig? Kan ik het niet anders oplossen? En als dat niet kan, kijk dan even. Is het MIT license? En denk er daarna niet te veel over na. Ja, dat hele licensing verhaal is echt een vak apart hoor. Ik merk dat ook weleens in de quality assurance wereld. Dat zijn sommige afdelingen waar ik dan heb, vooral bij de grotere bedrijven. Dat zijn gewoon bijna halve juristen. Die weten echt alle ins en outs. En vooral wat je net zegt Benoit. Als je je product echt daadwerkelijk gaat verkopen, of gaat handelen zeg maar. Dan is het inderdaad heel erg belangrijk dat je weet wat je shipt. Ik kan me best voorstellen dat dat wel wat problemen veroorzaakt. Dat is de software die je echt downloadable maakt. Dat zijn volgens mij ook wel oplossingen geworden. Volgens mij heb je in Rust een... Sowieso voor Rust, weet ik het zeker. Die zal je ook gewoon in Ruby hebben. Zo'n soort tooling die je in CI kan hangen. Die dan er maar bij houdt of je een license gebruikt die dan niet zou mogen. Dus daar is eigenlijk een soort van grote lijst met... Dat wel de allow list of de deny list, dat wel of niet mag. En dan kan je het eigenlijk automatiseerd doen. Maar goed, volgens mij is het daar het probleem ook weer over... Hoe groot is je bedrijf? Ben je voor jezelf bezig? Ben je een start-up die heel snel beweegt? Of ben je een grotere bedrijf? Daar zie je toch vaker dat je met meer mensen... Meer relatie hebt van programmeurs, mensen, medewerkers... Die alles gewoon naar binnen trekken en niet echt goed kijken. En dan heb je eigenlijk juist weer wel echt quality assurance nodig... Om te garanderen dat je daar dus niet fout gaat. Dat hangt ook een beetje van het onderwerp af, zeg maar. Maak je zo'n corona-app melder of zo... Die je meer deel van Nederland zou moeten gebruiken... Dan is het heel belangrijk dat je het heel netjes in de gaten hebt gehouden. En ben jij nog net aan met je paar eerste klanten bezig... Dan denk ik dat het minder van belang is. Ook is het belangrijk dat je het een keer bijhoudt... Maar als je nog geen geld verdient is het misschien minder belangrijk... Dat je iets gaat verspreiden over half-Nederland. En in dit geval ga je er ook maar vanuit... Dat de license die de andere auteur aangeeft ook weer klopt. En in dit geval lag daar het probleem. Dus jij kan een goede inschatting maken. Je ziet een license van een bepaalde library die je gaat gebruiken. Prima, die mag ik gebruiken. En dan vervolgens blijkt dat niet te kloppen. Dan valt het alles nog in het water. Ik denk zelf dat die oplossing het immutable zou zijn. Het immutable maken van die package registry. Dat het een fout is geweest. We gaan het oplossen, maar we gaan het voorwaarts oplossen. En dan is het klaar. Ik kan me ook nog herinneren dat een van die bedrijven waar ik gewerkt heb... Dat ze SNIC gebruikte. Dat is misschien wel leuk om ook te melden in de tips sectie zo meteen. SNIC is een security first-achtige platform. Die dus al je codebases scant op allerlei zaken. Wat misschien sowieso op security goed controleert. Maar ook op licensing. Dat doen ze ook best wel goed heb ik gezien. Dus dan checken ze inderdaad alle vulnerabilities in al die licenses. Die je dan eventueel meeshipt. Dus dan checkt hij elke library individueel ook weer door. Dus we hebben een enorme database inmiddels. Maar helemaal terecht, dat soort tools zijn er zeker. Volgens mij zijn er ook nog open source databases waar je tegenaan kan checken. Nou, mooi. Ik heb het zo net al een beetje verklapt. We gaan nu door naar ons laatste rubriekje. Dat is de tips sectie. De sectie is eigenlijk vrij simpel. Misschien dat jullie wat tips hebben voor onze luisteraars. Ik heb er ook eentje. Maar ik ben wel even nieuwsgierig naar jullie. Als jullie een tip zou mogen geven, dan begin ik even bij Redmar. Wat zou dat zijn? Wat is je opgevallen de laatste week of misschien laatste maand? Dat zou een boektip zijn. Heel erg richting de stack die wij onder andere ook gebruiken. Dat is een boek van Elixir. Programming Live View. Van Progmatic Programmer. Dat is eigenlijk een beetje waar iedereen op dat moment een beetje omgehypt was. Van dat stuk Live View dat Phoenix biedt. Wat trouwens een beetje soortgelijk is aan wat Ruby on Rails nu ook heeft. Met Hotwire geloof ik. Lijkt op elkaar. Maar dat boek zit wel goed in elkaar. Dat neemt je aan de hand mee. Niet te makkelijk, niet te moeilijk. Het trekt je door die hele stack heen. Met een project maken. Om dat onder de knie te krijgen. Ik vond het wel een goed boek. Het is trouwens nog in beta. Je kan hem volgens mij nog niet in puur papieren versie krijgen. Ik heb hem digitaal. Volgens mij is Pragmatic Programmers een label toch? Of is dat nou dat ze inderdaad, net als een startup, een boek opbouwen? Eigenlijk is daar ook met Ruby on Rails begonnen. Volgens mij was een van hun eerste boeken de Ruby Pickaxe van Dave Thomas. Wat hij vertaald had vanuit Japans. Dat heeft Ruby een beetje naar het westen gebracht. Volgens mij was een van de eerste boeken daarna het Ruby on Rails boek. In 2005 van David Meyer Hansen. Leuke tip. En vooral omdat het ook zo nieuw in de making is. Benoit, heb jij misschien een interessante tip? Ja, misschien niet helemaal onverwachts. Maar ik zou zeggen, als je nog geen crypto hebt. Het is altijd een goed moment om in te stappen. Van de signalen die wij krijgen is het zeker niet het laagste punt wat we tot nu toe gezien hebben. Dus het kan altijd nog zakken. Maar dit is wel de toekomst hoor. Dit gaat niet meer weg. Het wordt alleen maar meer. Het wordt alleen maar groter. En als je nog niks hebt, doe iets wat je kunt missen. En doe ook wel vooral iets wat je kunt missen. Want als je je huis gaat verkopen, dat is niet zo handig. Maar als je nog een paar honderd euro over hebt, doe je zelf een plezier. Koop er wat van, kijk er niet naar om. En kijk een paar maanden later om te zien of het tranen van geluk of tranen van verdriet is. Als het tranen van verdriet is, dan wacht je nog drie maanden. En dan lach je en kijk je nooit meer terug. Ja, want de eeuwige discussie is natuurlijk bitcoin to the moon. Wat gaat het worden ooit? Gaat het een miljoen raken? Gaat het een ton raken? Een ton is niet zo heel ver weg meer inmiddels. Ja, het zou zomaar kunnen. De bitcoin technologie zoals die er nu is, zou ik zeggen dat die niet helemaal haalbaar of houdbaar is. Omdat de energieconsumptie daar stelt mensen natuurlijk wel heel veel vragen bij. Overigens is de negatieve trend daar omheen niet helemaal terecht. Want er zijn ook echt wel goede dingen die daar uit naar boven komen. En met name juist de technologische vooruitgang om op zoek te gaan naar duurzame en goedkopere energie. Dus net zoals de Formule 1 super vervuilend is, zorgt de Formule 1 er ook voor dat de auto's zuiniger gaan lopen. En zo zie je nu ook dat dat een trend ontstaan in de bitcoin mininghandel, waarbij ze dus op zoek gaan naar de goedkopere en de duurzamere energiebronnen. Dus ik denk dat daar nog wel een goed dingetje uit kan. En dat bitcoin is de eerste en het gaat zeker omhoog. Mensen verwachten dat het een miljoen is. Ja, ik weet het niet. Ik hoop het. Zit ik al warmtjes bij deze winter? Ja, maar zie jij dan ook cryptocurrency met name als, ja, je hebt een handels, of tenminste, je hebt een streaming handelsplatform daarin. Zie je crypto als meer voor de handel of zie je crypto als toekomst ter vervanging van geld, van de huidige monetaire systemen, of waar zie jij de toekomst van crypto? Nou ja, zeker dat het echt een vervanging kan zijn voor je valuta in je eigen land. En daar hebben wij nu niet zo heel veel last van. Maar in landen zoals Venezuela bijvoorbeeld, ja, daar hebben ze echt enorm veel last van, van hun eigen valuta. En de enige uitweg die zij hadden is crypto. Dus de mensen die geluk hebben gehad, die hebben bijna al hun hun pesos verkocht en hebben dat omgezet in bitcoin. En die zijn dus niet meegegaan in de devaluering van hun eigen valuta. En die kunnen dus nu gewoon nog boodschappen doen. En mensen die alles op een spaarrekening hebben moeten laten staan, die kunnen niet eens een kopje koffie kopen, want dat kost al zeg maar een veertig dollar voor een kopje koffie in die termen wel groot. Maar goed, als de crypto valuta zo volatiel is, kan dat natuurlijk daar ook gebeuren. Dus dan los je dan het probleem of verplaats je het probleem? Nou, het probleem juist is dat landen zo centraal de touwtjes in handen hebben en dus juist hele gekke dingen kunnen doen. Bijvoorbeeld gewoon vijf keer zoveel gaan printen. En met bitcoin kan dat niet. Je kunt in je eentje niet een beslissing maken over de valuta zelf. En de enige reden waarom bitcoin meer of minder waard wordt, is door het gebruik. Dus hoe meer mensen er gebruik van gaan maken, hoe meer waard de coin wordt. Als de adoptie wegvalt, dan heb je pas te maken met een devaluering van de munt en dan gaan mensen het verkopen voor lager en raak je geld kwijt. Maar zodra mensen het echt gaan zien als een serieuze investering, als een serieuze vervanger voor het gereguleerde betaalverkeer, zoals we dat nu kennen, dan is dat wel echt de toekomst. En ik zag vandaag ook weer een ding voorbijkomen, dat je bij Amazon straks kunt gaan betalen met crypto-munten. Het is, je Tesla kun je er ook mee kopen. Ja, wat je een beetje ziet gebeuren is dat er een verschuiving is van de traditionele markten die meer interesse tonen voor de crypto-markten. En dat is wel een verschuiving die er nog niet was. En die kan er alleen maar voor zorgen dat het meer volwassen wordt binnen de crypto. Ik denk ook dat in dit verhaal veel meer laagjes zitten. Je noemde ook heel vaak bitcoin, maar er zijn er zoveel meer dan bitcoin die ook echt daadwerkelijk interessant zijn. Bijvoorbeeld al die gedescentraliseerde exchanges, maar ook coins, en daarin ook stablecoins, die zijn natuurlijk superinteressant. Daar ga je niet in zitten om dan je geld heel veel meer waar te maken. Maar het feit dat zo'n coin eigenlijk heel goed rond in dit geval de 1 dollar kan blijven. Dat is natuurlijk best wel interessant. Met name voor zulke soorten landen die devaluatie hebben. Dat je eigenlijk juist, aan de ene kant noemen we heel vaak bitcoin van dat heel volatiel alle kanten opschommelt. Die kant gaat wel tot nu toe bijna met de hockeystick geloof ik omhoog. Maar aan de andere kant heb je zulke stabiele coins die juist heel stabiel blijven. Dus er is gewoon heel veel meer aan de hand. Dus in die zin kan je ook zien als een soort van evolutie met heel veel verschillende strategieën die mensen uitproberen als coins. En ja, eentje zal er winnen. Of in ieder geval meerdere kunnen er ook winnen in die zin. Want je kan ook zien dat het 1 is het goud. In die zin bitcoin is het goud eigenlijk waar je het in kan stallen. En je hebt andere coins waar je in kan betalen. Je hebt ook coins die super snel zijn. En ook nauwelijks dat de transactie ook heel snel gaat. Dus ik denk dat het gewoon eigenlijk zo is. Het wordt gewoon langzaamaan volwassen. Ik zie het in die zin ook niet heel snel meer weggaan. Of met name ook door al het gedcentraliseerde spul. Ja, het is inmiddels wel een beetje too big, too veel aan het worden. Dat zie je wel. Maar Bernard, kunnen we al betalen met bitcoin bij Alltradee? Ja, zeker. Zodra de eerste betalleveranciers dat aanboden, hebben we dat gelijk toegevoegd. Dat is natuurlijk wel iets wat je eigenlijk vanaf dag één moet doen. Als je daarin bezig bent, dan moet je ook dat faciliteren. Ja, dat is wel grappig inderdaad. Want ook in podcasting is er nu een podcasting 2.0, wordt het dan genoemd door Adam Curry met name. En daar kun je dus nu inderdaad ook met behulp van het bitcoin lightning netwerk, ja, kun je betalen eigenlijk voor het luisteren naar een bepaalde podcast. Dus op die manier wordt het ook steeds meer ingezet. En ja, wat je zegt, een Tesla er mee kunnen kopen of dat soort dingen. Ja, de adoptie zorgt voor dat het wel steeds meer draagvlak krijgt en hopelijk ook gaat houden. Zeker. Even kijken, ik heb ook nog een klein tipje. Dat is meer vanuit de test automation wereld. Ik hoor steeds meer om mij heen dat men aan het overstappen is van Selenium Webdriver naar Playwright. Hebben jullie daar iets toevallig over gehoord? Ik niet. Oké, nou mooi. Dan heb ik hier wel een gouden tip gegeven. Voor al onze integratietests. Ja, precies. Precies, die twee. Maar Playwright is volgens mij overgenomen of misschien wel door iemand van Microsoft opgezet. En wat wel gaaf is, is dat het is met Node.js library gebouwd. En je kan daarmee dus tegen Chromium en Firefox. En eigenlijk alles wat de web toolkit van Chromium en Firefox gebruikt. En de marketing van Playwright zegt op dit moment dat het echt gebouwd is om webautomatisering via verschillende browsers mogelijk te maken. Die altijd groen en kapabel en betrouwbaar en snel is. En ik hoor dat er steeds meer teams over zijn. En ze zijn dus ook echt al hun selenium testen aan het omscripten. Dus ze hebben allerlei conversiescriptjes gemaakt, zag ik. En ja, ze geloven daarin. We stoppen de link zo meteen in de shownode. Kijk er eens naar en probeer het eens uit. Er zijn ook wat onderzoekjes die je op Google kan vinden die echt aantonen dat het sneller is. Nou, dat was mijn tip. Heb jij nog een tip, Johnny? Nou, ik heb geen tip van mezelf, maar ik heb een tip van een van onze gasten of eens van onze vorige gasten van de podcast. In november is Jeroen Leenaerts te gast geweest over iOS development. En hij vroeg bij ons in de Slack of hij zijn boek mocht promoten. En ja, dat boek heet Lead Developer, Best Practices and Tips for Lead Software Developers by Jeroen Leenaerts. Dat heb ik gelijk zelf even aangeschaft, omdat mijn huidige werkveld daar toch wel een beetje mee samen hangt. Ik heb hem nog niet gelezen, moet ik wel eerlijk bekennen, maar het boek is 47 pagina's lang, dus het valt allemaal best wel mee. En speciaal voor de luisteraars van CodeKlets had Jeroen gezorgd voor een leuke korting. Uiteraard is nu precies de link dood, dus ik kan het nu even niet bekijken. Volgens mij was het 50 procent. Dus dan kun je een leuk boek van een van onze oudgasten aanschaffen en hem daarmee helpen en supporten. Dus nogmaals, Lead Developer van Jeroen Leenaerts. Allemaal super tof. Dankjewel voor het delen inderdaad. Ik was het alweer vergeten. We zagen dat in de Slack kanaal. Oké, nou dat was hem weer, beste luisteraars. Allereerst heel erg bedankt Redmar Kerkhoff en Benoit Klaassen voor jullie deelname. We hebben echt veel geleerd over crypto trading en het platform Altready. Dus ja, ik denk dat we veel luisteraars hiermee blij kunnen maken door het even vanaf het begin uit te leggen wat het nou precies inhoudt en de details over hoe jullie het platform hebben opgebouwd. Dus dank voor het delen daarvoor. Nou ja, in ieder geval leuk dat jullie hebben geluisterd weer. We verwelkomen jullie ook op onze website codeklets.nl. Daar staat een link naar onze Slack kanaal waardoor je ons kan vinden en verder zou kunnen kletsen over code of andere zaken. We tikken al de 102 mensen aan, dus join the fun zou ik zeggen. Verder nog Salves ook heel erg bedanken voor het mogelijk maken van onze online opnames. Het gaat niet altijd heel erg probleemloos zoals vandaag, maar goed, we hebben het beste van gemaakt. En ja, we zijn daar natuurlijk uiteraard dankbaar voor aangezien we elkaar niet fysiek mogen ontmoeten. Nou, dat resteert mij nogmaals iedereen te bedanken. En ja, tot de volgende keer weer. Doei!