S02·015CodeKlets panel discussie over de Staat van Programmeren
We hebben het samen met Dennis, Redmar en Johnny over de Staat van Programmeren in 2022
We hebben het samen met Dennis, Redmar en Johnny over de Staat van Programmeren in 2022
- ▸Hoe je leert programmeren door andermans code te bekijken
- ▸Wat Clean Code leert over professioneel ontwikkelaarschap
- ▸Hoe bedrijfscultuur je applicatiecomplexiteit weerspiegelt
- ▸Wat het KISS-principe inhoudt voor eenvoudige codebases
- ▸Hoe WebAssembly nieuwe mogelijkheden biedt voor browsers
Dit is een speciale aflevering. De eerste CodeKlets "live" opname met publiek erbij. We houden een panel discussie over de "Staat van Programmeren". Het panel bestaat uit, als je onze podcast trouw hebt geluisterd, 3 bekende gezichten: Redmar Kerkhoff, Dennis Doomen & Johnny Dongelmans. Het panel leggen we een aantal stellingen en vragen voor, om een beetje een beeld te krijgen hoe het staat met de "Staat van Programmeren" in 2022.
Dit panel is mede mogelijk gemaakt door Aviva Solutions. We mochten daar te gast zijn op het Aviva Impulse event.
Random notes
Transcript
Nou, welkom bij een nieuwe aflevering van de CodeKlets podcast.
Het is een heel speciale.
De eerste aflevering die live is, de eerste aflevering met publiek, hebben we nog nooit
gedaan.
Het format is ook nieuw.
We hebben een panel met drie panelleden.
De eerste die voor mij zit, dat kun je niet zien via de luisteraar zeg maar, is Johnny.
Dat heb ik zelfs nog niet gezegd, we hebben teams, een aantal, hoe zeg je dat, teams
die vertegenwoordig, een vertegenwoordig C-Sharp, de andere Ruby, de andere Rust en Elixir.
Johnny is degene die team Ruby is in dit geval, Redmay gaat Rust en Elixir doen en Dennis mag
C-Sharp en .NET vertegenwoordigen, dus ik hoop dat je daar goed mee voelt, niet halverwege
gaan switchen.
We hebben een aantal stellingen, de vragen en stellingen, de vragen zijn steeds in het
lichtblauw, de stellingen zijn in het zalmroos gekleurd, dus dat zie je zo meteen op, het
publiek ziet dat op het scherm en jullie moeten ook maar op het scherm kijken, succes ermee.
Oké, de eerste vraag, als jullie nieuwe ontwikkelaars, zeg maar, een advies wat je aan de nieuwe
ontwikkelaars zou willen geven, waarom zou je mee moeten beginnen, Dennis, wat zou jij
adviseren?
Dat je heel goed leert zoeken op Google, dat is mijn mening serieus.
Dat is het ook?
Nee, nee.
Nee, best te beginnen, naar andermans code kijken, dat is denk ik wel een hele goeie.
Open source project, Stackoverflow is natuurlijk een belangrijke bron, maar kijk gewoon eens
wat andere mensen doen, kijk wat je daarvan kan leren.
Is het niet een specifiek platform of taal, dat is een soort van een goeie om mee te beginnen
of is dat...
Nee, ik denk dat hij zijn eigen voorkeur heeft natuurlijk.
Oké.
Nee, geen mening over.
Redmo, wat vind jij ervan?
Daar ga ik eigenlijk wel aan mee, de meeste junioren of jongens die beginnen met programmeren,
die vergeten eigenlijk dat je inderdaad ook hoort te googlen, dat is iets dat het mag,
zeg maar.
Soms zie je ze heel lang hun best doen en dan struggelen en dan, ja maar je mag ook googlen,
zo van doen wij ook.
Maar qua platform dacht ik eigenlijk aan Scratch, maar dat is meer voor als kinderen ermee willen
beginnen en als je er net mee in aankomt.
Swift Playgrounds is wel een eentje die heel leuk is, als je gewoon een iPad hebt dan kan
je dat installeren en dat is al iets voor iets oudere kinderen en volwassenen.
Ja, en ik zou zeggen van als je er net mee begint ook aan die schroom om no-code-tools
te gebruiken, dus gewoon veel meer, dus dingen aan elkaar kunnen klikken, gewoon begin er
gewoon mee, zeg maar, en vooral zoeken waar je plezier uit haalt.
Ja, oké.
Niet jezelf erg verplichten van ik moet dit doen, ga gewoon iets doen waar je op dat moment
gewoon plezier uit haalt.
Ik denk dat het wel uitmaakt voor advies of je waar je voor begint, dus nu je echt professioneel
wilt doen of dat je er kennis mee wilt maken.
Oké.
Johnny?
Nou, ik heb hier niet zo heel veel meer aan toe te voren, het laatste inderdaad was dat
ik dacht ja als je gaat programmeren, ja je moet er wel plezier uit halen, of het moet
iets oplossen of je moet er met name plezier uit halen voor jezelf, iets oplossen waarvan
je denkt dat lijkt me nou leuk om te kunnen doen, dat vond ik vroeger in ieder geval
toen ik begon het meest magische van programmeren, ja je gaat ineens iets automatiseren, je gaat
iets echt oplossen wat je vroeger met de hand moest doen bijvoorbeeld, dat vond ik mijn eerste
stap was echt iets automatiseren en dat vond ik gewoon heel erg leuk om te zien, om te
zien werken.
Ja, je hoort ook, dat is ook bij heel veel gasten zeg maar die we hebben gehad, dat ze
zijn begonnen met bouwen van games, omdat dat dan, ja dat spreekt meteen heel erg aan.
Dus dat...
Ik niet, nee.
Jij niet?
Nee.
Oké.
Als ik nog mag reageren, ik zou het me denken, ik had laatst ook een ontwikkelaar die eigenlijk
net van de universiteit afkwam en even los van de technieken, is misschien een beetje
afgezaagd maar er is een boek dat heet Clean Coder, niet te verwarren met het andere boek,
wat eigenlijk heel erg gaat over wat betekent het nou eigenlijk om professional te zijn.
Dus wat betekent het nou om te werken in een bedrijf, want het is bijvoorbeeld niet altijd
zo dat als een manager iets zegt dat je ja moet zeggen, daar gaat hij heel erg over,
dus dat boek focust zich heel erg op de soft skills die natuurlijk ook superbelangrijk
zijn.
En programmeren kan iedereen.
Dus ik denk dat iedereen wel kan leren programmeren, tot een zekere mate, maar om te acteren als
een programmeur, als een professieel ontwikkelaar, daar komt veel meer mee kei in, communicatie
en omgang met mensen.
Ja, dat is waar.
Ik ben zelf heel slecht in trouwens.
Dat is ook heel erg belangrijk.
Oké.
Schopen in een keer te binnen.
Ja, goeie toevoeging.
Dan komen we bij de eerste stelling, hopen dat er wat discussie loskomt.
Programmeren van moderne applicaties in 2022 is eigenlijk te complex.
Johnny?
Ja, dat hangt er vanaf.
It depends.
Is het over het algemeen te complex?
Ja, ik denk dat het met name vaak gewoon de bedrijfscultuur reflecteert.
Dat is een beetje hoe ik er altijd tegen nakijk tegen applicaties.
Het is een reflectie in afspiering van je bedrijfscultuur.
Dus hoe ingewikkelder de bedrijfscultuur, hoe ingewikkelder de applicatie, zou ik dan
kunnen zeggen.
Maar ja, het hangt er vanaf.
Natuurlijk zijn er complexe applicaties.
Natuurlijk zijn er applicaties die heel ingewikkeld in elkaar zitten, al dan niet de bedoeld
of al dan niet nodig soms ook.
Maar ja, op elk potje past een dekseltje, denk ik.
Als het het doel dient, en er zijn programmeurs die die code aankunnen en ook willen beheren
en ook willen programmeren, en er zullen ook genoeg applicaties zijn die niet makkelijk
zijn.
Maar ik zou niet durven zeggen dat het overal te complex is, eerlijk gezegd.
Ik denk dat er zoveel tooling en dingen tegenwoordig ook bij zijn gekomen, dat een hele hoop programmeerwerk
van tegenwoordig makkelijker is dan vroeger.
Maar maakt dat niet nog complexer, want er komen nog veel meer stuk dan dat er voorheen
kon.
Ja, dat is waar.
Dat is ook wel een ding.
Ja, Redmoor?
Ik denk het wel.
In de zin dat er steeds meer, er is meer van alles.
Ja, onder de noemer van toen ik begon, was het gewoon redelijk PAP en gewoon iets in een
pagina gooien, een paar regels, en je kon refreshen en je zag het, zeg maar.
En in die zin denk ik dat het complex is geworden als je net begint en dat je dan eigenlijk best
wel guidance nodig hebt van mensen om je een beetje wegwijs te maken, wat je het beste
kan leren en ook om focus te houden.
Het is een beetje gegeven hoeveel desktop apps er zijn die in elektron zijn gebouwd.
Op basis daarvan denk ik dat je bijna wel conclusie kunt trekken dat het gewoon te complex
is.
Ook de drang naar dingen als React Native op mobiel, ook al maar weer om gewoon weer
twee hele complexe eigen ecosysteem te kunnen overbruggen.
Voor mij is dat niet nog wel te complex.
Gegeven dat je nog weer doorgaat naar infra, dat hele Kubernetes-verhaal, dat duizelt
gewoon.
Als je naar de Kubernetes landscape kijkt, er staan echt volgens mij 500 bedrijven, 500
projecten op.
Ja, dat gaat volgens mij reis dat een beetje te pan uit.
Dus volgens mij zou het niet erg zijn om als branche meer te streven naar minder.
Hetzelfde als bij programmeertalen.
Blijf maar bouwen, bouwen, bouwen, nieuwe dingen erbij bouwen.
Ik denk dat het helemaal niet erg is om soms gewoon daarin juist te zeggen van hier stoppen
we.
En je maakt hetgene waar je mee bezig bent beter in de zin van bugs fixen, maar niet
per se alleen maar features blijven doorbouwen.
Oké.
Dennis?
Ja, ik denk zeker dat het antwoord ja is en wat jij zegt is zeker waar.
We hebben gewoon te veel keuzes, te veel platformen, te veel talen, te veel opties.
Zeker als je in de JavaScript-wereld kijkt, het vliegt te pan uit met alle frameworks.
Maar wat ook belangrijk is, is dat 20 jaar, 25 jaar geleden bouwden we vooral desktop-applicaties,
dingen die op een pc leven.
Nu zijn het allemaal websites en op het moment dat je iets op het internet zet, krijg je
aan een keer te maken met beveiliging, schaalbaarheid, weet je, allemaal van complexiteiten, wat
gewoon zo enorm complex maakt.
En infrastructuur, die zei jij ook al, Redmar, dat is ook wel een super belangrijke, komt
allemaal bij kijken.
Er zijn natuurlijk zat platformen waar je vrij snel een websiteje op kan zetten en dan wordt
het ergens gehost.
Maar op het moment dat het een beetje, hoe zeg je dat, massa krijgt of het publiek aantrekt,
ja, dan moet je gaan nadenken over security en cross-site scripting en cores en dat soort
zaken.
Dat kan je nu te bevatten tegenwoordig en infrastructuur is een hele mooie.
Tegenwoordig moet je ook dingen weten van Terraform en AWS en cloud en Google, wat allemaal
weer net anders in een andere manier werkt.
Het komt zoveel bij kijken.
Ik denk dat het ook veel waarde geeft aan tools zoals Webflow of Shopify, om dat juist
te gaan gebruiken.
Omdat het alternatief is zoveel complexer en daarmee ook zoveel duurder om het te bouwen,
want je hebt nog veel meer nodig.
Oké, ja.
Ja, ik zit een beetje te denken, is dat niet altijd zo geweest tot op zeker, kijk we hebben
nu meer keuze, dat ben ik helemaal met je eens, maar het is, kijk vroeger kon je ook kiezen
om het in Assembly te gaan schrijven, dat kan nu nog steeds overigens, er is bijna niemand
meer, maar vroeger was dat nog meer mainstream, om even zo te zeggen, en waren daar ook al
talen die daarop verder borduurden om bepaalde dingen uit handen te nemen en bepaalde dingen
voor je over te nemen.
Maar misschien is het wel zo dat de applicatie die we tegenwoordig bouwen, dus de eisen door
dat het op het internet staat, dat we daar meer eisen aan hebben gesteld.
Ja, maar er is ook om die eisen weer te vergemakkelijken zijn, is er natuurlijk gewoon een heel hoop toeling
meegebaan.
Ja, ik denk dat het dieper en breder is gegaan.
Ja, precies, ja.
Dus het is wel complexer geworden, maar niet per se makkelijker of moeilijker, maar dan
is dat het.
Maar je moet het wel eens zien te vinden.
Dat is het, welke keuze maak je?
Er zijn tegenwoordig hele studies binnen bedrijven, uit of uit gaan we nou voor React of U of
Svelte, wat dan ook, terwijl het misschien helemaal niet zo'n belangrijke keuze is, maar
dat is gewoon zoveel.
En vroeger, als je op het Windows machine zat, dan bouwde je iets met MFC en C++, je had
niet zoveel keuzes.
En als je cross-platform wilde doen, dan pakte je Java, want dat was cross-platform.
Ja, maar dan zat je wel weer ook vast gelijk daarin, dus je moest dan gelijk ook het curslijf
in van die specifieke taal, terwijl je nu dan wel de keuze hebt.
Maar dat is niet complexer, dat maakt het misschien simpeler.
Ja.
Alleen totdat je een bepaalde schaalgrote bereikt, dan wordt het in één keer weer een probleem,
maar dan kun je niet meer.
Dus ja.
Ik denk ook niet dat er een echt een ja of nee antwoord is.
Ik had wel een ja, dat had ik wel verwacht.
Dat is een antwoord op alles.
Dat is de stelling, hè.
Soms een tweede keer.
Oké, nou goed.
Dan gaan we naar een vraag.
Welke principes pas je toe in je toolstek om de situatie simpel te houden?
Sluit een beetje aan op wat we hiervoor qua stelling hadden.
Redmar?
Wat wij doen is onder andere echt religieus bijna kiss toepassen.
Kan het nog makkelijker?
Kan je er nog meer van afhalen?
Kan het nog makkelijker?
Met name als je een soort greenfield dingen doet, maar dat geldt eigenlijk ook voor als
je features toevoegt.
Van ja, maak het nou zo klein en zo simpel mogelijk.
Het is zelfs eigenlijk dat als je een nieuwe feature deploit, kan het ook met je feature
flag en kan je hem zeg maar over tien minuten live hebben.
Er zit niks in, maar we hebben wel een feature flag.
Kan je dan daarna iets erbij bouwen wat achter die feature flag zit en door itereren op productie?
Dat is inderdaad hoe wij het zo maar doen.
Met name de houding van dat je het zo simpel mogelijk moet houden.
Dat dat altijd de beste uithangspositie is.
In die zin is het ook design upfront natuurlijk.
Big design upfront en dan dat willen bouwen.
Ja, het is gewoon itereren, klein houden en vooruit zeg maar.
Dennis?
Ja, wat moet ik hier nou op zeggen?
Het is bijna mijn werk om dit soort dingen in kaart te brengen.
Nou, dan heb je hopelijk.
Ja, toolstack.
Ik bedoel, er zijn zoveel methodieke principes die moeten helpen om het simpel te maken.
Maar vaak heb je complexiteit nodig.
Dat is het voor anderen.
Je kunt dingen wel simpel willen houden.
Maar je requirements, je non-functions, die eisen geven met die complexiteit, die heb je gewoon nodig.
Dat kun je niet voorkomen.
Maar ja, ik heb net een hele dikke sessie gedaan over clean code en over testbaarheid en over interne kwaliteit.
Dat is allemaal onderdeel van dat proces om het simpeler te houden.
Nou ja, ik kan al mijn principes gaan noemen die ik toepas.
Ja, je mag er voor mij een paar noemen.
Toen er eens drie.
Solid, om maar iets te noemen.
Test driven development, infrastructures, code.
Die maken trouwens in die zin wel complexer.
Maar nogmaals, je hebt het nodig, want je moet dingen uit kunnen rollen.
En met de hand naar een cloud provider ga je je virtual machine uitrollen.
Dat maakt het niet simpeler.
Om het te automatiseren, dat maakt het natuurlijk simpeler, makkelijker, sneller, betrouwbarer.
Maar het hangt er vanaf over hoe vaak ga je het doen.
Ik ga het niet automatiseren als ik het maar één keer hoef te doen.
En ik span ergens een VM met je.
En daar draait een dingetje, een service shop, die vervolgens de komende vijf jaar er niet aangeraakt wordt.
Dan raak ik er geen hele automatisering omheen bouwen.
Dat is je non-functional.
Ja, non-functional is dat je waarschijnlijk niks nieuws gaat uitrollen.
Maar elk serieus systeem heeft natuurlijk...
Je krijgt altijd nieuwe requirements, nieuwe inzichten.
Dus er komt een punt dat het update, het uitrollen met de hand zo complex wordt en zo foutgevoelig dat je geen keuze hebt om te automatiseren.
Maar ook dat is een proces.
Je begint met een MVP en dat ontwikkelt zich door.
Dat wordt succesvol, hopelijk.
En dan moet je in één keer andere dingen gaan doen.
Dat is inderdaad iets wat ik in ieder geval bij mijn werkgever wel vaak zie.
Wat ik wel vaak zie is dat er heel vaak al van tevoren veel te complex wordt gedaan.
Dus altijd kritische vragen blijven stellen.
Dat is dan voor mij het antwoord op deze vragen.
Dus gewoon kritisch blijven.
Hey, oké, ja, je zegt nu dat je dit wil, maar is dat ook echt daadwerkelijk wat je wil?
Of wat wil je bereiken?
Heel vaak komt er bijvoorbeeld een opdrachtgever of iemand anders binnen het bedrijf komt dan met een oplossing naar je toe.
Iemand van sales komt met een oplossing naar je toe als developer.
En dan zeg je, ja, hallo, maar wat wil de klant nou precies?
Kunnen we dat dan niet oplossen met iets wat we willen hebben?
Dus gewoon continu die vraag blijven stellen.
Ik denk dat dat voor mij de meest.
Ik heb precies de situatie meegemaakt dat er twee applicaties moesten gesynchroniseerd worden.
En mijn vraag was uiteindelijk van, er moeten gebruikers gesynchroniseerd worden.
Maar hoe vaak moet het dan gebeuren?
Want de ontwikkelaars zei gelijk, oh, we moeten een service bussen.
We moeten dit en dat introduceren.
Wat blijkt nou?
Het hoeft maar één keer in de vijf tot tien minuten een beetje bijgewerkt worden.
Was het helemaal niet nodig om al die complexiteit toe te voegen?
Mas, mas, database replicatie.
Misschien.
Misschien, zelfs als er een optie is.
Het kan, weet je.
Het ligt aan de requirements uiteindelijk.
Maar niet elk probleem is een technisch probleem.
Het kan ook functioneel opgelost worden.
En dat vergeten heel veel ontwikkelaars.
Of met bestaande tooling die er al is.
Ja, bijvoorbeeld.
Jij wil natuurlijk alles tien keer zelf opnieuw uitvinden.
Dat is toch veel leuker.
Ik had ook nog een beetje gekeken wat de industrie hierover zegt.
We hebben de vraag van tevoren gekregen.
Dus een beetje uitzoeken daar maar.
En hetgeen wat op dit moment heel erg leeft in de industrie...
...is de vier key factors.
Vier key...
En dat is eigenlijk die...
Je hebt het bekende Accelerate-boek.
En die hebben zes jaar onderzoek daarnaar gedaan.
Een soort DevOps-researchteam.
En die zeggen eigenlijk andersom.
Dus die hebben zes jaar onderzoek gedaan naar succesvolle projecten.
Nou ja, succesvol is waar je kunt zeggen.
Die weten het nog simpel genoeg te houden...
...om nog te begrijpen wat aan het doen zijn.
En daar hebben ze vier key factors gehad.
Hoe snel kan je deployen?
Hoe snel kan je recoveren van een fouten deploy?
En nog twee.
Maar in dezelfde richting.
Nee, lead time totdat er een change in productie kan komen.
Dat is drie.
En nog eentje die er heel dicht naast schuurt.
Maar die vier komt overal terug.
En dat is wel interessant om te zien.
Sowieso is dat boek wel interessant, Accelerate.
Het is wel een beetje droog.
In de zin van het is heel erg een opschomming.
We hebben allemaal enquêtes gehouden en onderzoek gedaan.
En dan lees je die droogstof in die zin.
Conclusie is wel heel mooi.
En in die zin een goed streven wil je het simpel houden.
Daar hoort het automatiseren alweer bij.
Want dat is het deel van hoe snel je iets in productie krijgt.
Dat is ook het idee achter continuous deployment.
Dat is een ideaal streven.
Maar patten naartoe eist zoveel volwassenheid in je organisatie.
En alleen dat al voor elkaar krijgen.
Ieder stukje wat je daar voor elkaar krijgt helpt je als organisatie.
Dat je het eindelijk continuous delivery kan doen.
Perfect.
Er moet zoveel gebeuren.
Ik denk dat de relatie weer terug slaat over waar Johnny volgens mij net mee begon.
Dat het inderdaad iets aangeeft hoe je organisatie in elkaar steekt.
Dat dat weer terug slaat op of je dit aankomt.
De link naar dat boek dat delen we straks.
Ja, daar komen de show notes.
De fysieke show notes.
De fysieke show notes, ja.
Oké, dan gaan we naar de volgende stelling.
De enige manier om oplossingen te bouwen is middels de cloud.
Dat is de man.
Ja, tuurlijk.
Ik heb een aandeel in AWS en Azure.
Ja, ik weet het niet.
Misschien zijn er mensen die geloven dat alles nog cloud based moet zijn.
Ja, ik weet het niet.
Ik heb er altijd wel moeite mee.
Ja, dat hangt.
Het depends.
Het depends.
Het depends.
Uiteraard ja.
In de zin van wat je onder de cloud voor staat.
Maar als je gewoon VM's ook onder de cloud voor staat dan zou ik niet heel snel meer
Zou ik niet heel snel meer weten wat je eigenlijk op metaal doet.
Ook al gebruiken wij wel metalen bakken in onze infrastructuur.
En daar hebben we dan dus ook goede reden voor.
Ja, oké.
Dat is de vraag, ja.
Dus zodra je dat er onder verstaat dan zou ik echt niet meer weten waar je de service
zou gaan slepen.
Nou, dat is wel dat we die dus niet erbij rekenen.
Voor mij brengt gewoon letterlijk de cloud in de zin wat het nu is en wat nu als gehyped
is eigenlijk heel veel complexiteit met zich mee.
Het zijn met name allemaal eigen interpretaties van de cloud providers.
En zodra je ook voor een cloud kiest is het heel lastig om
alle concepten en alles weer even heel makkelijk over te brengen naar iets anders.
Dan vind je het wel zulke giganten dat je het ook niet snel zal wisselen, denk ik.
Dus wisselen van Azure naar Google of naar Amazon, zeg maar.
Dat is lastig.
Tenzij je het heel, kijk IA's natuurlijk, of dat is gewoon alleen maar VM'tjes opspinnen.
Ja, dat zal niet lastig zijn.
Maar zodra je wat complexer of wat rijker.
Ja precies.
Het lijkt me dat als je weer gewoon alle Kubernetes dingen gebruikt.
Dus als je aan die interface uit van Kubernetes.
Dan hebben ze alle grote giganten hebben gewoon in die zin gewoon.
Ja, de hoogste Kubernetes.
Dus is het eigenlijk wel weer makkelijk over te zetten.
Het is weer hoe diep je gaat, zeg maar.
Dan gebruik je minder de functies van de cloud zelf.
Ja, precies. Maar dat wordt wel weer complexer, zeg maar.
Want dan ben jij bezig om als het ware Kubernetes weer te babysitten, zeg maar.
En dan wordt het weer complexer, zeg maar, voor jezelf.
Dus als je het makkelijker wil.
En ja, weet ik veel.
Als je een functie bijvoorbeeld wilt gebruiken of Lambda's in AWS.
Ja, dat is makkelijker, zeg maar.
Maar het is niet zo makkelijk om over te zetten naar een andere cloud, als ik dat zo begrijp.
Ja.
Ja, oké.
Nou, ik geloof er wel in dat er echt wel heel veel onderdelen inmiddels al zijn die je echt niet zelf moet doen.
Zoals bijvoorbeeld de mailserver hosten zelf.
Waar je vroeger gewoon heel snel iets van de mailserver en de mailtjes uitstuurde.
Dat doe je gewoon niet meer.
En dat doe je echt alleen maar in de cloud.
Maar een oplossing bouwen, want daar is eigenlijk natuurlijk waar het om gaat.
Nee, ik zou het... Nee.
Denk ik niet.
Want ik zou het gewoon lekker zelf bouwen.
Het maakt het ook heel veel makkelijker als je het gewoon lokaal gewoon nog steeds aan kan raken en kan runnen en kan hosten, zeg maar.
Ja, oké, zo.
Ja.
Wat vind jij ervan, Dennis?
Nou, ik kan er twee dingen over zeggen.
In eerste instantie, ik zit bij een klant die in de industrie zit waarin het internetverkeer niet altijd beschikbaar is.
Dus dan heb je het over olieplatformen.
Dan is cloud helemaal geen optie.
Het tweede is, ik zie cloud meer als een grote bak met tools en dingen die je kan gebruiken.
En dan moet je keuzes maken.
Ik heb de laatste weken toevallig aan de Pox gedraaid om gewoon containers te kunnen draaien.
Even niet met Kubernetes, maar gewoon met AWS Fargate en Amazon.
Dat is het container interface.
Die werelden zijn al zo verschillend dat je niet eens kan praten over de cloud.
Als je Amazon wil gaan draaien, dan moet je gigantisch veel stappen doordat het ding überhaupt bereikbaar is op het internet.
Je moet elk subnetje, elk elementje moet je helemaal instellen.
En dat probeer ik dan te automatiseren met Pullimi.
Terwijl als je naar Azure gaat, dat is bijna één commando, dan staat het ding in de cloud en compleet beschikbaar.
Geen beperking, niks.
Die werelden zijn zo verschillend.
Mijn grootste probleem zit, wat jij net ook zei, is op het moment dat je alles in de cloud kunt draaien, kun je dus niks meer testen lokaal.
Ik vind het prettig dat ik iets lokaal kan starten.
Dat ik lokaal mijn build skip kan draaien.
Kan zien dat end-to-end testen draaien.
Op het moment dat alles in de cloud draait, ben je zo vanafhankelijk.
Dat is een dingetje.
Maar uiteindelijk is het gewoon een box met tools.
En als je jouw non-functionals of jouw specifiek situatie toelaat dat je het in de cloud kan draaien.
Nou bij alweer eens, doe het.
Ga je niet zelf je eigen hardware draaien.
Maar als je dat niet hebt, dan is het toch geen oplossing.
Dat is gewoon een oplossingsrichting weer.
Ja.
Sonny, wil je daar nog iets aan toevoegen?
Nee, niet echt per se toevoegen.
Ik denk inderdaad dat het gewoon een beetje gegroeid is.
De laatste, wat zal het zijn, tien jaar of zo, dat het nu echt een beetje...
Nou, niet zo lang denk ik.
Nee, wel.
Ik denk de laatste vijf jaar.
Ja, de laatste vijf jaar met name.
Ik kom juist met Kubernetes, denk ik.
Ja, en kijk, gewoon een service als een Digital Ocean of zo.
Ja, het is natuurlijk zo makkelijk om iets op te spinnen daar en dan gewoon te deployen en te gebruiken.
Ja, dan heeft het z'n plek en dan heeft het z'n functie.
Ja, dan is het misschien handig om het daar wel te draaien en dan ga je het niet zelf oosten.
Ja, zoals we begonnen, it depends, denk ik.
Ja, precies. Ja, absoluut.
Overal is het it depends.
Dat we de conclusie maken van elke stelling.
Ja, dat wordt de titel van de aflevering.
It depends.
Misschien komt er nog iets wat is het beste programme je hebt gehaald of zo, dan klaar.
Wat ben je zo bezig?
Oké, over welke technologie zijn jullie op dit moment heel enthousiast?
Johnny.
Jeetje, ik heb me slecht voorbereid.
Dat komt nu naar boven.
Redman, je mag ook, dan mag je nog even nadenken.
Ik heb helemaal geen slides gezien, ik wist helemaal niet wat we vragen hadden.
Oh, dat was een beetje, ja.
Mijn fout of jouw?
Nee, nee, waarschijnlijk mijn fout, maar ja, knippen eruit.
Oh gek, oh, kijk, ik ga me voorbereiden.
Wat ik had staan was Wasm, WebAssembly.
Dat is eigenlijk het verhaal dat alles naar de browser toe gaat en dat we dat ook nu zijn we daarmee aan het ontwikkelen.
En dan is, ja, dat vult gewoon op dit moment een gat wat gewoon heel interessant is om te zien.
Dat zijn toevallig projecten die ik dan heel erg van dichtbij volg.
Dat is een soort code editor.
Ik weet niet, Cloudline als editor.
Dat is in ieder geval, AWS heeft dat ooit opgekocht.
Dus ja, script editor in de browser.
Een beetje hetzelfde verhaal dat je naar github kan gaan, op puntje kan drukken en dan krijg je hele VS code achter de omgeving.
Zoiets is het.
Alleen, dat heeft hij dus helemaal gebouwd met zijn team.
Volgens mij maar twee of drie man ofzo.
En ik kom er eigenlijk steeds achter dat die browser heel vaak een beetje de, ja, factor is die het allemaal beperkt, zeg maar.
Je zit hele tijd vast aan die dom en het gaat zoals dat die browser doet, zeg maar.
En WebAssembly in combinatie met WebGL geeft eigenlijk een nieuw soort van kamp vast.
Een omgeving waar je vrijwel eigenlijk alles in kan doen.
Je kan gewoon compilen.
Als het eenmaal een soort van compile naar bottom, dan kan je erin runnen, zeg maar.
En die heeft nu ook na volgens mij twee jaar, heeft hij iets, ja.
Hij is even ver na twee jaar als hij vijf jaar in JavaScript was.
En bij JavaScript liep hij eigenlijk gewoon vast.
Want het kon gewoon niet meer verder.
De browser piepte en kraakte en het kon gewoon niet meer.
En nu heeft het in de rust zitten.
En je ziet nu ook wel meer bedrijven die het oppakken.
Natuurlijk ook zo'n tool als Figma ofzo, wat volledig gewoon.
Een van de eerste was die daar soort van commercieel dan ook nog heel veel succes mee had.
Dat is volgens mij trouwens in C++ geprogrammeerd.
En toen, zeg maar, gecompiled.
Maar goed, dat kan je op de achtergrond nu zelf weten wat je wilt.
Dat als technologie.
En een ander die ik had, volgens mij is hij ook één keer bij de podcast langsgekomen.
Dat is OpenAI Codecs.
Dus zeg maar die GPT-3 Artificial Intelligence die voor je programmeert.
En nu was volgens mij op het moment dat jullie hem bespraken was hij nog redelijk, zeg maar gewoon kansloos.
Maar die blijft maar bezig aan evalueren.
En die maakt nu wel af en toe.
Je hebt er wat demos van die je gewoon kan opzoeken.
Van OpenAI.
