Welkom bij aflevering 12 van CodeKlets, een aflevering dit keer met mij en Bernard.
Hallo.
We hebben vandaag een gast en ik ben blij dat jij erbij bent Bernard, want dit is een
onderwerp waar ik gewoon echt geen ervaring meer heb.
Misschien heb ik één keer een idee geopend.
Ik ga even niet zeggen welke idee, want dan verklap ik het meteen.
En ja, dat is een keer iets gemaakt, maar daar niet noemenswaardig.
Onze gast van vandaag is Jeroen Leenaerts.
En Jeroen is sinds 2002 werkzaam als software ontwikkelaar.
Sinds iOS 3, dat is trouwens echt lang geleden, is hij gespecialiseerd in iOS ontwikkeling.
Over de loop van jaren heeft hij met verschillende technologieën en stacks gewerkt.
Waaronder Java.
Ja, daar moeten we misschien nog even over hebben.
Eclipse.
Oké, Django.
IOS microservice architectuur.
En nog meer.
Ja, dat nog meer is altijd wel...
Dan moeten we nog naar vragen.
Ik ben ook Microsoft Certified Application Developer geweest.
Echt?
Wauw.
Wel in .net 1.1 hoor.
Oh, dat vind ik ook interessant.
Goed.
Op dit moment is Jeroen lead iOS developer in de context van drie development teams.
Tevens is actief als security champion in iOS.
Verder is Jeroen ook community lead van Cocoa Heads Nederland, NL.
En organiseert al zeven jaar maandelijkse meetups voor iOS en Mac ontwikkelaars.
Verder, teraan alsof dat nog niet genoeg was, werkt hij ook onder zijn eigen naam AppForceOne.
En heeft hij deze week zijn eigen podcast gelanceerd.
Nou, deze week is natuurlijk een beetje lastig.
Als wij dit gaan publiceren, dan zijn we denk ik anderhalve week verder.
Ja, 20 oktober.
Dan moet het zo ook even over hebben.
En de podcast heet AppForceOne, News and Information for iOS App Developers.
Dus een Engelstalige podcast neem ik aan.
Ja, klopt.
Oké.
Ja, ja, ja.
Cool.
Kunnen we het ook nog over hebben.
Nou, welkom Jeroen.
Ja, hoi.
Woehoe.
En daar heb ik trouwens nog een heel mooie mooie scene.
Heb ik die heel lang gezocht en heb ik hem niet gebruikt.
Die kun je ook maar één keer.
Je kunt hem niet multiple triggeren.
Jammer.
Nou, gaan we weer knippen.
Welkom, welkom, welkom.
Ja, dit is een indrukwekkende bio.
Ik vind het wel grappig, want je bent sinds 2002.
Dus als ontwikkelaar begonnen, was je toen met .net begonnen of niet?
Nou ja, dat is.
Want .net 1.1 is 2003 ongeveer.
Ja, 2003.
Ja, ja, ik ben mijn opleiding heb ik van 1998 tot 2002 gedaan.
HBO in Zwolle.
En dat was een beetje een aparte opleiding, want na de eerste twee jaar toen was er gewoon geen curriculum meer.
Dus toen zijn we met zes man voor de examencommissie gegaan en van eigenlijk gewoon de vraag gesteld.
Oké, en nu?
Nou, toen hebben we voor de laatste twee jaar hebben we een docent toegewezen gekregen die een fulltime voor ons zesde bezig was.
En toen hebben we de laatste twee jaar van onze opleiding eigenlijk zelf ingevuld.
Dus dat was echt flink feesten.
Nou, en uiteindelijk heeft hij het papiertje opgeleverd dat ook nog geldig is.
Als we vragen van wat is je diploma, dan zeg ik HBO IT.
En dan geloven ze me, dus het zal wel goed zijn.
Dus ja, in mijn opleiding veel met Java gedaan.
Want ja, in die jaren was het echt alles Java, Java, Java, Java, Java.
Zoals het nu allemaal Python is, geloof ik heel veel op hoge scholen en universiteiten.
Oh, dat weet ik niet eens trouwens, ja.
En ja, dus ik ben dus eigenlijk als een soort Java developer,
ben ik het werkveld ingerold bij InfoSport.
Dat is een consultiebedrijf ergens in en daal.
Ja, dat ken ik.
Negen jaar gewerkt. Maar toen ik daar begon, was het allemaal een beetje zo van ja, we zijn een dotnet bedrijf.
En ja, je krijgt nu eerst een half jaar trainingen voor Microsoft.net.
Nou, en zo ben ik dus inderdaad gecertificeerd geraakt voor Microsoft Certified Application Developer.
En ja, ik lag me nog steeds kapot, want ik ben dat ooit geweest,
maar ik heb er eigenlijk nooit wat mee gedaan.
Ik heb mijn afstudeerproduct, wat ik bij mijn eerste werkgever had gebouwd,
we hadden hem in Java geschreven en toen hadden we hem gewoon voor de grap.
Om te leren hadden we hem nog een keertje in dotnet herschreven.
En dat was het allermooiste, dat ding dat heette Mealyways.
En het was een applicatie op het internet waarmee je broodjes kon bestellen voor de lunch.
Dus heel nuttig.
Ja, zeker.
Ja, en het was echt een multi-tenant applicatie,
want je kon gewoon meerdere leveranciers konden een menu erin in krijgen.
En aan het einde van de maand dan rolde daar een printje uit.
Dat ging naar de loonadministratie toe.
En dan kon je zien hoe erg de schade was op je loonstrook.
En toen ik per het bedrijf wegging, dat was negen jaar later,
toen draaide dat ding nog steeds.
Oh, echt?
Over de loop der jaren wilde iemand anders hier en daar langzamer ge-upgrade.
Ik weet niet of het nu nog draait,
maar zo ben ik dus inderdaad met dotnet in aanraging gekomen, heel even.
En toen heb ik eigenlijk eerst tot heel veel Java-dingen gedaan,
maar rond de Eclipse RSHP, front-end, back-end,
nou ja, echt ouderwet Java Enterprise Beans geschreven.
Dat je echt gewoon iets van vier verhaals nodig hebt
om één objectje te definiëren op IBM WebSphere.
Ook met Oracle.
Ik weet niet meer eens hoe het dat ding heet, joh.
Dat was nog voor die goudvis applicatieservice.
Ik weet niet eens hoe die meer heet.
Ik weet het ook niet.
Ik weet dat er...
Sun Microsystems bestond toen nog.
Ja, maar dat heeft nog genild.
Dat is op zich nog best wel lang doorgegaan.
Het is niet per se heel lang geleden dat Oracle het overgenomen heeft.
Maar dat is wel in ieder geval...
Nee, Oracle had toch...
Ja, een applicatieservice die draaide op die database ofzo.
Dat weet ik niet hoe dat...
Ja, ik bedoelde dat de hele play van Oracle was altijd
dat ze gewoon die database door je strotten en doorduwen.
En als je dan die database had,
dan was je op een gegeven moment afhankelijk van ze.
En dan gingen ze de licenties opschroeven.
Dat is wat Oracle altijd gedaan heeft.
Ja.
Heel verkenbaar.
Kijk, Java, voorbij Java.net, bedoel ik ben...
Java.net is een beetje Ajax Feyenoord.
Ja.
Ja, dat is gewoon...
Wat is je voorkeur?
Nou, dat zal wel.
Maar Oracle, dat is echt...
Ik weet het niet.
Ik vind het niet zo'n heel relaxed bedrijf,
omdat dat heel erg salesgedreven is.
Ja, ze wilden laatst wel bijna TikTok kopen.
Ja, dat is volgens mij nog steeds aan de hoogte.
Maar de manier ook van hoe die licentie...
Ja, precies wat jij zegt,
hoe het heel erg opgedrukt wordt om maar meer licenties te verkopen.
Ja, dat zal bij Microsoft ook gebeuren met SQL Server
en andere bedrijven ook.
Maar bij Oracle was het heel erg agressief.
Maar goed, dat...
In ieder geval heel veel dingen met Java gedaan.
Echt van alles en nog wat.
Ook wel eens een keer naar een conferentie geweest in de Amerika ervoor.
En gewoon echt leuke dingen gedaan.
Ik heb bijvoorbeeld bij de NS aan een planningsproduct gewerkt met Eclipse RCP.
Dus dan heb je dus de Eclipse IDE, die ken je wel.
Ja, ja.
Nou, een Eclipse RCP is dan dat ding, maar dan uitgekleed.
En dan maak je daarin eigenlijk je eigen applicatie, zeg maar.
Dus dan is dat een soort van runtime plug-in architectuur,
waarin je dan leuke dingen...
Beetje zoals nu Electron is, zeg maar.
Nou vloek ik, maar dat is wel een beetje stil.
Ja, misschien wel. Ja, ik ken Electron goed genoeg.
Ja, want het principe... Ja, goed.
Ik heb zelf niet met Eclipse gewerkt,
maar ik heb toen...
Nee, de Java-developer was waar ik mee werkte, zeg maar.
Of die in ons team zaten.
Die hadden Eclipse.
En er was één jongen, die zei dat toen ook.
Die heeft me toen laten zien van oké, je kunt Eclipse ook gewoon als platform
en gebruiken om naar je eigen applicatie te draaien.
En dat was op zich wel, vond ik wel, een interessante propositie, zeg maar.
Maar dat is nu ook wel...
Ja, dat is niet per se commercieel een enorm succes of zo.
Niet dat ik weet.
Maar Electron is op zich heel populair.
Ik weet niet, iedereen klaagt natuurlijk dat het veel gebruik is.
Maar dat is wel zo.
Het enge van Electron vind ik dat je eigenlijk gewoon een complete webomgeving
op je machine draait.
En dat werkt heel mooi.
Je bent er heel snel mee waarschijnlijk en zo.
Maar qua security, die hele browser sandbox die eromheen zit in je webbrowser,
die is gewoon weg.
Dus als er gewoon een vulnerability in dat Electron zit,
dan ben je binnen.
Dat vind ik een beetje het nadeel van Electron.
Zeker als het slack is bijvoorbeeld.
Ja, ik weet niet wat slack verder nog doet.
Al die gekke gifjes en zo die je binnen krijgt.
Dat weet ik van wat mensen allemaal posten.
Als je een inline documentje viewt of zo.
Bam, roet, doei.
Ja, ik weet het niet.
Ik weet niet wat slack daar aan doet.
Ik vermoed, want Visual Studio Code is natuurlijk ook...
Ja, maar dat is anders.
Ik bedoel Visual Studio, dan ben je zelf meer in controle.
Je installeert wat plugins en zo.
Maar het is niet dat een random weirdo die ook al bij jou op de Slack channel zit,
gewoon bestandjes naar je kan sturen.
Dat is wel een verschilletje.
Ja, klopt.
Dat valt me dan tot nu toe op.
Dat er nog niet een, ja, misschien is er wel.
En dan weet ik het nu nog niet.
Maar op zich zijn er nog niet heel veel breaches geweest, volgens mij, in Slack zelf.
Slack zelf, nee, dat klopt.
Maar goed, we zijn er weer afgetwaald, geloof ik.
Ja, dat gebeurt vaker.
Ja, laten we kijken hoe jij bent begonnen met iOS.
Ja, ik zat dus bij dat infosupport en dat was hartstikke leuk en zo.
En toen had je op een gegeven moment de iPhone 2, of ik weet niet hoe die heet,
maar in ieder geval die zilverkleurige achterkant met die zwarte rand aan de onderkant was, geloof ik.
Ja.
Nou, dan had ik echt zoiets van...
Toen was in die tijd van ja, we hebben helemaal geen appjes nodig.
JavaScript, dat is prima genoeg en alles in de browser.
En toen je met iOS 3 bedacht dat dat toch niet zo'n goed idee was,
of tenminste Steve Jobs dacht dat het niet zo'n goed idee was.
Nou, wacht, dat is het minste.
De overlevering is dat Steve Jobs die vond dat browser idee goed
en de rest volgens mij van de bedrijven die zei nou,
misschien moet je dat maar even iets omheen doen.
Nou, en toen kwam dus dat iOS, dat werd toen zeg maar,
dat je echt daarop kon ontwikkelen.
Nou, dat leek mij wel interessant,
dus daar ben ik er gewoon in mijn eigen tijd een beetje naar gaan kijken.
Toen op een gegeven moment ook gewoon zo gek geweest
dat ik voor mijn eigen geld een MacBook,
volgens mij was het een MacBook Pro, echt zo'n G4 was dat gekocht.
Ja, want je hebt toch een Mac nodig om iets met die spullen te kunnen doen.
En nou, dat was leuk, een beetje spelen.
Dat was nog net voor dat Xcode uit was gekomen.
En had je nog echt de interface beelden, had je nog echt apart.
Nou, echt joh, dat was echt verschrikkelijk.
En toen was het eigenlijk,
zat ik eigenlijk een beetje mijn manager binnen dat bedrijf,
zat ik ook een beetje te pushen van ja,
kunnen we niet even een klusje vinden voor een mobile ofzo,
iets met iOS ofzo, het lijkt me wel leuk.
Kunnen we dat niet doen?
En constant, constant volhouden gewoon.
En uiteindelijk heb ik daar dan een soort of proof of concept
voor Kaspank mogen doen in Amsterdam.
En dat was met grafiekjes en zo.
En dat moest dan een iPad app worden.
En dat mocht ik twee weken aan besteden.
Dus echt twee weken er echt als een debuul op de keer gegaan, zeg maar.
Ik had nog geen kinderen,
dus dat kon gewoon oneindig tijd in een week, zeg maar.
En dat was leuk.
Maar het was geen project geworden.
Nou, ik balen natuurlijk, want wat nu dan?
En toen ben ik uiteindelijk ben ik een beetje gaan solliciteren, zeg maar.
En toen kwam Xebia, die kwam in beeld.
Daar ken ik Kishen ook van.
En toen heb ik eigenlijk gewoon gezegd,
ja, ik wil best wel bij jullie werken eigenlijk.
Maar dan wil ik wel gewoon iOS doen.
Ik heb geen ervaring eigenlijk die noemenswaardig is,
maar dat is wat ik wil doen en niet iets anders.
Dus kan dat?
Nou, dan hebben ze even wat moeten overleggen en zo.
En toen hebben ze, uiteindelijk hebben ze bij een grote klant van hun,
hebben ze dat eigenlijk voor elkaar gekregen.
Dus ik had getekend en toen mijn eerste dag,
ik zat gelijk aan de Haarlemmerweg in Amsterdam,
in hoofdgebouw 2 bij de ING.
Nou, dit is Jeroen. Hij is heel goed in iOS.
En vervolgens liep mijn nieuwe manager heel hard weg.
Oké.
Dat scheelde. Ik had daar wel een collega bij me, Andrew Snair.
Dat was een Australier en echt een hele coole, goede vent is dat.
En die heeft me eigenlijk gewoon,
na 2, 3 weken heeft hij me eigenlijk onder zijn vleugel genomen.
Dat was een directe collega van Xebia,
dus dat kon een beetje harsje, harsje onder de hoed, zeg maar.
En na 2, 3 weken had hij zoiets van,
dit loopt wel los.
Die Jeroen, die kunnen we gewoon zijn ding laten doen, zeg maar.
Nou, en toen ben ik eigenlijk gewoon een beetje onder job met AOS development begonnen.
Dat was in de tijd dat die ING-apps,
je had eerst van die vier grote knoppen, zeg maar,
en dat is toen na zo'n hamburgermenu gegaan.
Ja, cool.
Dat hamburgermenu heb ik gemaakt.
De pinpad die er nu net sinds,
ik denk dat het er nu anderhalf jaar echt uit is of zo,
met die stelletjes die een beetje pulseren, heb ik gemaakt.
Maar de spaarbalk die die animatie er in schuift, die je nog steeds ziet,
die heb ik gemaakt.
Dat is heel grappig, want zoveel jaar later zitten er nog steeds dingetjes.
Ja, natuurlijk, de code zal al lang veranderd zijn,
maar je herkent wel dat dan een bepaalde touch van je er nog aan zit, zeg maar.
Want ik zat er altijd echt ontzettend lang door te zeuren van,
ja, met animaties en zo.
Ja, dat moet allemaal, nou ja, echt allemaal bizarre dingen.
Want als je bijvoorbeeld zo'n sterretje,
wat dan in zo'n pinschermpje, wat dan in beeld komt,
heel veel mensen denken, ja, plop,
één fate en één scaling en het is klaar.
Maar dat ding komt op het scherm met vijf verschillende animaties,
die allemaal op verschillen, en dan de drie ervan,
zit op een andere tijdlijn dan die andere twee.
Oké.
En dat allemaal maar gewoon om, ja,
goed, ten eerste omdat het leuk is en ten tweede omdat het kan.
En ten derde, verkopen het ook goed,
ja, want dan is het dan voelen mensen zich geconnected met,
en daar hebben wij goed.
Op een gegeven moment leer je het heel goed verkopen, zeg maar,
en je gewoon leuke dingen kan bouwen die je zelf wil.
Nou heb ik dus echt vier jaar en drie maanden bij de ING gezeten,
dus gewoon Dedicate het iOS Development gedaan,
daar dus eigenlijk gewoon begonnen.
Toen ook, daar komen we straks nog wel op denk ik,
op een of andere manier Cocahats ingerold, zeg maar.
En aan het eind van die rit heb ik nog een soort van conversieproject gedaan
met Jeroen Willemsen en Nan de Baars,
die waren toen ook van Xebia.
En toen hebben we eigenlijk de onderliggende netwerklaag van de app,
hebben we toen als een soort van component eruit getrokken,
of eigenlijk opnieuw gebouwd en dan gebaseerd op wat ze daar hadden,
zodat ze dat op andere mobiele producten konden gaan hergebruiken.
Dus dan heb je het over SCP-6a, en dat is dan een passwordafleiding,
en allemaal encryptie en weet ik veel wat allemaal.
En dat je dan dus dat allemaal maar een beetje in je vingers moet krijgen
en dat je denkt van ja, wacht even, ze zeiden toch altijd iets met encryptie,
dat moet je toch nooit zelf doen.
Nou, maakt niet uit, we gaan gewoon bouwen.
Er komt een security review en dat komt wel goed.
En inderdaad gewoon met de drieën daar gewoon volgens mij negen maanden
echt aan zitten klussen, zeg maar.
En toen was het eigenlijk voor mij, er kwam dus een situatie dat ik,
toen ik bij Xebia begon ook mijn huidige vrouw leren kennen,
nou goed, dan op een gegeven moment komt het onderwerp kinderen in beeld
en toen toch vanwege reistijd een move gemaakt weer.
Dus ben ik weg gegaan bij Xebia,
ben ik bij een kleine agency in Apeldoorn terecht gekomen.
Dat was negen maanden, ja, dan werd ik net te gek van mijn baas.
Dus toen had ik zoiets van dit is hem niet.
Toen ben ik weer terug gegaan naar een bedrijf in Amsterdam.
Dat was een iPad app die voor fashion retail inkoopbegeleiding deed.
Dus dan kon je dat als mode winkel of mode keteneigenaar,
ga je eigenlijk gewoon ook kleding kopen.
En alleen ja, de schaal waarop je dat doet is natuurlijk,
als ik naar de kledingwinkel ga, dan koop ik eens een shirtje van broek of zo,
en dan ben ik klaar.
Maar die luiden kopen gewoon compleet dingen wat ze noemen maatbogen.
En dat is eigenlijk gewoon de kleine maat en een beetje de grote maat en een beetje.
En hoe meer het naar het gemiddelde komt, hoe meer ze ervan willen hebben.
Oh ja, ik snap het.
Het zijn dus echt luid.
Die gaan gewoon even shoppen en die doen even een rondje bij ja,
eigenlijk gewoon fashion bedrijven die dan ook gewoon een soort van
warehuizen in Nederland hebben waar je dus je inkoop kan doen.
Dus daar hangen er artikelen gewoon om daadwerkelijk te kijken en te voelen.
Dat is voor die mensen heel belangrijk.
Want ja, het is toch een heel erg persoonlijk en intiem productkleding.
Maar dan lopen ze zo'n gebouw binnen en dan gaan ze shoppen, shoppen, shoppen,
shoppen en aan het eind van de dag hebben ze vier tonnen uitgegeven.
Alleen ze hebben echt geen flauw idee hoeveel ze eigenlijk ingekocht hebben.
En daar begeleidt het product dan dus eigenlijk bij.
Dat je ook kan zien van nou, heb ik een beetje de goede mate?
Heb ik niet te veel van één kleur?
Want het was ook allemaal visueel met foto's en weet ik voor wat allemaal.
Nou, dat was hartstikke leuk, want daar zat dus ook een heel groot cloud component bij.
Dus Amazon Web Services met Django Rest back-end microservices.
Maar in welk jaar was dit dan?
Dat was bij...
Ja, ik moet even denken wat het was.
We zitten nu al in...
Nu moet ik ook mijn eigen aantekeningen pakken hoor.
Ja, op dat je 2020...
Nee, dat was in 2017.
Daar ben ik in 2017 begonnen.
Ik heb in 2016 negen maanden bij de App Agency gezeten.
Toen in 2017 ben ik bij Neon Fashion Retail gaan werken.
Daar heb ik een jaar en vier maanden gewerkt.
Echt super naar mijn zin gehad.
Dat was echt zo van...
Ja, ik heb ooit wel eens iets met back-end gedaan, Java.
En Erwin was dan de lead developer daar.
Hij zei, oh, maar dan kun je ook wel Python en Django Rest.
En hier heb je een PyCharm licentie. Succes.
Succes, ja.
Ga maar krassen.
Gelukkig was ik dan redelijk thuis in Unix en Linux en al die command line shizzles.
Dat was een van de redenen waar ik ook een interesse in Mac had.
Omdat daar toch een Unix gebaseerd subsysteem op zat.
Het is geen echte Linux, maar toch.
Je hebt een volwaardige command shell en zo.
Ja, dat klopt.
Wat is het? Default bash shell en...
Precies.
Ja, nu is het C-shell.
Ja, dat klopt.
Ja, ik had hem zelf wel als default.
Nu op Mac is dat de default als je kala installeert.
Ja, klopt. Daar had ik hem niet door.
Dat was wel even wennen hoor.
Ja, voor mij viel het mee.
Want ik doe niet per se heel erg rare dingen.
Want ik installeer, weet het, O-My-Z-Shell.
O-My-God, weet ik veel.
Ja, O-My-Z-Shell.
Heb je allemaal completions en zo, ook voor Git.
Ja, precies.
Dus dat heb ik dan allemaal.
En dan kun je op command al heel cool doen.
Alsof je, hoe heet het ook weer, Pauline bent.
En alles van Git af weet.
Gewoon tap, tap, tap, tap, tap.
En het staat allemaal voor je neus.
Dat, ja, ja, ja.
Dus dat is echt, ja, dat heb ik niet.
Ja, dat.
Dus ik ben vooral echt gebruiker.
Maar dat is ook echt wel lang geleden op school.
Zeggen we toen echt Unix op SunOS.
Zeg, SunOS.
Klopt dat, SunOS?
Ja, Solaris.
Ja, Solaris, ja, precies.
Nee, SunOS is iets anders volgens mij.
Maar goed, Solaris.
Ja, toen had ik echt wel wat Shell scripts en zo.
En dat had ik me daar wat meer even diep.
Maar dat weet ik echt nu helemaal niet meer.
Ik ben gewoon echt redelijk gebruikt.
Alleen, ik vind Cometa wel fijn geworden.
Elke dag, toch even een beetje.
Ja, het is toch fijn.
Het is vaak op bepaalde dingen.
Maar even terug.
Ja, ik zat dus in 2017 bij dat fashion bedrijf.
Ja.
Met Python, Django.
En ook heel veel op bepaalde stukken op een gegeven moment van die stack.
Omdat het heel erg elastic wat we daar qua load hadden.
Hebben we dat op een gegeven moment ook naar lambda functies herschreven.
Dus daar kwam er op een gegeven moment gewoon een nieuwe catalogus van een bedrijf binnen.
En ja, lambda dat zijn, zeg maar, functions as a service.
En dan kwam dat gewoon binnen.
En dan, nou ja, dan in plaats van dat er dan een VM met je al stond te pruttelen en er klaar voor was.
Die volledig unrespect was voor wat je nodig had.
En dan vervolgens als je nou twee uur aan het stampen was.
Nou, dan had je gewoon met lambda functies had je gewoon.
Nou, dan was je jobs moest je even opknippen, starten.
En dan ging dat parallel met 150 instances en dat duurde dan een minuutje of zo, weet je wel, in plaats van twee uur.
En het was nog eens goedkoper ook.
Dus nou, iedereen blij.
En nou, betere kwaliteit en je bent sneller.
Wat wil je nog meer?
En dat soort dingetjes hadden we daar dus.
Maar goed, ook daar gewoon echt gewoon Linux server onderhoud moeten doen.
Natuurlijk wel virtueel.
Maar ja, die krengen, die moesten wel geupdate worden.
Dat was allemaal een beetje op de bonnen voor je, was het allemaal ontstaan daar.
Dus het was ook niet helemaal infrastructure as code, zeg maar.
Dus het was allemaal nog wel een beetje handmatig je instances bijwerken en updaten.
En nou, hartstikke leuk.
Maar ja, toen kwam de tweede.
Kind.
En toen was het verdraaid.
Ja, het is toch wel fijn om toch wat dichter bij huis te zijn.
Ja, dat snap ik.
En het grappige was toen dat van mijn huidige werkgever.
Ik werk bij Achmea, een grote verzekeraar met callcenters en zo.
Dat even terug grijpen naar die opmerking voor iemand.
En toen was het eigenlijk, dat was dan die recruitment daar.
Maar daar had ik dan contact mee vanwege CocoHats.
En nou ja, daar hadden we eens een keertje een meetup mee georganiseerd.
Dat was allemaal prima.
Maar ze bleef maar achter me aan zitten, bleef maar achter me aan zitten.
Dus elke maand of zo, dan kreeg ik wel een belletje of een e-mailtje.
Ik werd gewoon gestalkt door haar.
Maar uiteindelijk had het effect.
Dus ben ik op een gegeven moment zoiets van nou, oké, vooruit dan.
Ik kom wel een keer op gesprek.
Een week later had ik een contract.
Ja, dat snap ik.
En daar werk ik nu sinds 2018 alweer.
Zo de knut.
Dat was al 2,5 jaar.
Ik ben in mei 2018 begonnen.
Dus dat is een beetje wat ik qua werk gedaan heb.
En ja, en eigenlijk bij Achmea weer volledig op iOS gefocust.
En ja, ook het backhandwerk een beetje weer laten gaan.
Maar ja, goed, dat zijn van dingen die je prutsen eens een keer wat aan.
Of je helpt eens een keer iemand op wat kleinere schaal.
En dan blijft het toch wel een beetje mee bezig.
Ja, precies.
Oké, nou, duidelijk.
Kan je misschien iets vertellen over hoe dat dan gaat?
Zo'n iPhone appje bouwen.
Wat gebruik je?
Waar begin je?
Wat gebruik je niet?
De huidige staat van iPhone development voor newbies.
Ja, als je echt gewoon met iOS development wil beginnen,
dan is het eigenlijk gewoon gaan naar de App Store.
En zoek op Xcode en download dat.
Als je op download hebt geklikt, dan kun je waarschijnlijk nog eventjes boodschappen gaan doen ofzo.
Want dat is echt een hele grote download.
Een paar gigabyte.
En het gaat om de ene van de reden niet zo heel snel.
Als je die ge-download hebt en je start voor de eerste keer op,
dan kun je nog een keer boodschappen gaan doen.
En als je dat gedaan hebt, dan heb je ze eigenlijk gewoon in IDE beschikbaar.
Waar dan ook een virtuele simulator van een iPhone of een iPad of dat soort dingen zit erin.
En dan is het best wat je eigenlijk kan doen,
is gewoon eens een keertje op de developer documentatie van Apple kijken.
Gewoon kijken wat daar een beetje staat.
Eerst een beetje bekend raken met de dingen daar staan.
Op zich wel een paar basale tutorials, om het zo te zeggen.
En dan komt er een punt dat je op een gegeven moment echt serieus moet gaan worden.
En dat heb ik gemerkt dat dat voor de meeste mensen die er echt in willen stappen,
dat dat dan toch wel het beste gaat met een boek dat heel lang heel erg populair was,
was van de Big Nerd Ranch.
En dat is echt een soort van guide.
Als je daar gewoon aan het begin begint,
ze beginnen een beetje eerst met de taal en dan op een gegeven moment
een beetje wat de echte concepten zijn binnen iOS,
je viewcontrollers en wat je restricties zijn waar je rekeningen moet houden
omdat het een mobiel device is.
En dan ga je er gewoon doorheen.
En dan begin je met de type in de...
Ja, eigenlijk wel.
Dat zijn we echt van die tutorialachtige stappen waar je dan doorheen gaat.
En hopelijk valt dan op een gegeven moment het kwartje.
Want het probleem van heel veel developer documentatie
en ook bij Apple is dat de voorbeelden die ze erbij als code hebben, zeg maar,
dat zijn allemaal heel erg van die afgeschermde, ingekapselde kleine voorbeeldjes.
En het probleem daarvan is dat iedereen dan die er niet verder denkt,
denkt ja, zo moet je doen.
En dat resulteert dus dat echt iedereen alle code maar gewoon in een viewcontroller pleurt.
Ja, dat wordt vrij snel, vrij onoverzichtelijk en lastig, zeg maar.
Ja, maar nog even een stapje terug.
Is het dan, de big nerd range boek was volgens mij Objective-C, als ik het goed heb.
Volgens mij zijn ze ook wel geüpdatet nu naar een Swift.
Maar wat is Objective-C en wat is Swift en is dat niet hetzelfde, stiekem?
Oh nee, zeker niet. Nee, nee, nee.
Eigenlijk Objective-C, dat is voor de nieuwe iOS developers,
die proberen dat echt gewoon alleen maar aan te raken met een hele lange stok.
Het is een soort van Frankenstein creatie tussen C en smalltalk, om het zo te zeggen.
Dus ja, wat is het eigenlijk?
Het is een soort van syntactic sugar over C heen,
die je eigenlijk ook helemaal niet ziet, dat die syntactic sugar er op meen zit.
Die syntactic sugar is wel echt bizar met vierkante blokhaken.
Ja, veel vierkante blokhaken.
Als je een C-achtige taal gewend bent,
dan de eerste keer dat je Objective-C code ziet, dan denk je echt van, hoe dan?
Wat is dit? Hoe lees ik dit?
Het gekke is een beetje als je mensen spreekt die voor geruime tijd Objective-C geprogrammeerd hebben,
die vinden overal waar ze binnenkomen, vinden ze de functienamen en de variablenamen tekort.
Want Objective-C is een taal die zich ontzettend leent
om echt functienamen en klassennamen te verzinnen die echt stukjes proza zijn bijna.
En ja, wat is Objective-C?
Dat is eigenlijk een dialect over C heen die objectorientatie toevoegt aan een C-taal.
En het grappige is ook dat je in Objective-C dus ook echt volledige toegang hebt tot alles wat je in C kan doen.
Is heel leuk. Is ook heel gevaarlijk.
Want wat kun je met C? Hele mooie crashjes veroorzaken.
En dat is dus ook wel echt een van de grootste pluspunten van als je Swift gebruikt.
Ik leg zo uit wat dat een beetje is.
Dat is dat Swift je veel meer beschermt tegen die typische memory- en stack-gerelateerde fouten die je in C kan maken.
Je zet gewoon overal een uithoerteken achter.
Nou...
Optionals zijn cool.
Doe dat niet.
Mensen die overal een bang achter zetten hebben echt zoiets van nee, niet doen.
Nee, doe dat niet.
Nee, dan kan je net zoveel kapotmaken als in Objective-C bijna.
Het crasht dan net zo hard in de dag.
En wat is Swift?
Swift is eigenlijk een nieuwe taal ontwikkeld door Chris Labner.
Die zat toen hij dat deed bij Apple.
Inmiddels heeft hij alweer bij de Tesla gezeten en ik weet niet waar hij nu zit.
Maar die heeft in ieder geval in opdracht van Apple een taal ontwikkeld dat aanvankelijk pitcht.
Dus het is een Objective-C++ geloof ik zelfs nog.
Maar het is dus echt een C-achtig opgemaakte taal.
Dus inderdaad met typische accolades en functiehaakjes zoals je dat eigenlijk een beetje kent vanuit C.
En dat soort talen is Java of C-sharp.
En het geeft je gewoon veel meer houvast in ieder geval voor wat betreft memory management.
Want toen ik begon met iOS development had je echt nog dat je handmatig je geheugen beheer moest doen met retains en releases en zo.
En je had ook wel van die autorelease-pools en zo.
En die werden nooit op het juiste moment gedraind en zo.
Maar wat Swift dus eigenlijk deed, die heeft een iets elegante manier om je reference counting te doen.
En daardoor heb je, sowieso als je met Swift programmeert,
heb je iets minder kans dat je echt grote memoryproblemen veroorzaakt.
Ik bedoel je kan nog steeds dezelfde problemen veroorzaken.
Maar goed, wat is het voordeel van Swift ten opzichte van Objective-C?
Swift is een taal die voor de gemiddelde ontwikkelaar wat beter leerbaar is.
Omdat het gewoon een wat meer eenduidige syntax is.
Er zitten minder bizarre implementatiedetails aan.
Want dat was toch wel een dingetje met Objective-C.
Omdat het een soort van uit de hand gelopen hek op C is,
zaten er best wel spannende dingen in af en toe, zeg maar.
Ja, ik ben ook wel blij dat ik van die .h-files af ben, merk ik nu.
Want ik zit nog op projecten die worden door elkaar gebruikt.
Swift en Objective-C.
En ik begin er toch al stiekem aan te wennen dat die weg zijn.
Of weg raken.
Maar als je dan zit te typen in Swift of in Objective-C,
wou je ook zo de interface op, gewoon in code?
Ja, daar zijn de meningen over verdeeld.
Je hebt in, van oudsher, als je Apple-gerelateerde development doet,
heb je een concept wat ze de interface builder noemde.
Voordat er Xcode was,
was de interface builder echt daadwerkelijk een apart programma
wat je naast je, volgens mij heette het project editor ofzo,
ik weet niet eens meer hoe het ding heet,
maar dat was inderdaad soorten met van je code editor.
En je had dus echt je code editor en je visuele editor,
dat waren gewoon twee dingen die je naast elkaar gebruikt.
Twee applicaties.
Xcode, dat was het grote ding van Xcode, die integrerde dat met elkaar.
En ja, wat je dus qua user interface kan doen,
je kan ten eerste natuurlijk al je user interface elementen gewoon in code definiëren,
dat je dus inderdaad de dingen aanmaakt en dat je het op z'n plek zet
en alle layoutzaken, dat je die ook gewoon goed doet,
zodat het ook inderdaad, zodra je het op je scherm ziet,
dat het ook op de plek staat waar je het wil hebben.
Maar je kan ook interface builder gebruiken
en dan kun je dus eigenlijk in een soort van visuele manier
kun je componentjes op een scherm slepen
en dan kun je dan inderdaad, ja, wat ze dan noemen,
die kun je dan wiren met je code,
zodat je dus vanuit je code en dat wat je visueel hebt opgemaakt,
dat daar dan ook een verbinding tussen is.
En ja, wat daar vervolgens weer op nieuw gekomen is,
is wat ze nu noemen SwiftUI.
En dat is een, ja, dat is iets nu wat nu,
sinds iOS 13 kun je dat als iOS developer doen.
Dat is een meer declaratieve manier om user interface te definiëren in code.
Maar zoals we het opgezet hebben,
kan het ook heel goed een soort van preview rendering doen
van datgene wat je in code aan het doen bent.
En dat maakt eigenlijk dat je,
terwijl je typt en het syntactisch weer correct is,
dan staat het gelijk in het schermpje ernaast bijgewerkt op je scherm.
En dat zijn nu eigenlijk de drie smaken die je hebt.
En ja, in ieder geval, bij Achmea zijn we nu echt bezig voor het centraal beheerproduct
om, ja, nog steeds om de Objective-C code te lozen.
Er zit nog iets van 15 procent van onze code is nog Objective-C.
Maar we gaan zeer binnenkort echt volle bakken op SwiftUI duiken.
Raak je dan niet oude iOS-feesjes kwijt?
Ja.
Zo beerd?
Ja, we weten de percentage van eindgebruikers die daar last mee krijgen.
Ja, dat zijn er niet veel.
En Business heeft natuurlijk wel op input van de development teams.
Hebben die besloten dat inderdaad het verlies van die gebruikers niet opweegt tegen de
pluspunten ten aanzien van verwachte productiviteiten toename.
Nee, je kent alle voor's en tegenste wel dat je iets kost je wat, maar het levert
ook wat op en het valt nu positief uit.
En daar zijn we als developers erg blij mee.
Oké.
Maar vanaf welke versie zeg maar, welke versie valt af?
Volgens mij voor 13.
Ja.
Oh, oké.
Dat is wel redelijk recent.
SwiftUI is beschikbaar sinds iOS 13.
Ja, oh ja, SwiftUI, sorry.
Kijk, en dat we ermee bezig gaan betekent ook niet gelijk dat we het al live hebben.
Natuurlijk.
We blijven.
Nee, maar goed, ik dacht vooral omdat security voor in de financiële sector is wel
redelijk belangrijk.
Dus je kunt ook zomaar zeggen van ja, heel leuk.
Maar we gaan iOS, ik weet niet eens wat, 9 of 10 ofzo.
Ja, die wordt niet meer geupdate en dan komen we geen security patches meer op.
Maar die gaan we dus gewoon niet meer ondersteunen, omdat het operating system zelf gewoon
niet veilig is.
Dat weet je, dat je vanuit die insteek.
Ja, het is eigenlijk, als je puur door een securitybril kijkt naar het iOS-ecosysteem,
dan moet je eigenlijk alles voor iOS 13, moet je al niet meer gebruiken.
Moet je gewoon echt niet doen.
Kijk, iOS 12.4 is nog, er wordt nog wel gepatcht, zeg maar.
Maar ja, er zijn echt gewoon, op iOS 12 zijn al gewoon issues bekend die niet opgelost
zijn.
Ja, het is gewoon, wat moet je anders?
Je kent altijd wel die oude oom of tante die nog een telefoon van vijf jaar oud
heeft en roept dat ze het nog prima doet.
Ja, dat klopt.
Dat is wel weer zo.
Maar goed, ja.
Ja, aan de andere kant, want mensen klagen er wel van dat het niet, dat je niet meer
ge-updated wordt.
Maar het feit is wel dat je in het, als je een iPhone koopt, als je nu vandaag naar
de winkel gaat, oké, als je nu vandaag op het internet gaat en je koopt een iPhone,
dan weet je eigenlijk vrij zeker dat je daar minstens vier, vijf jaar updates op
krijgt.
Ga je een Android kopen, dan, nou, als je, als je één of twee jaar updates krijgt,
dan heb je geluk.
Ja, dat is echt een groot verschil.
Het is misschien, ja, goed, volgens mij met Google Telephones is het nog.
Ja, maar wie koopt er nou een Pixel?
Nou ja, de price-prestage-verhouding is volgens mij best goed.
Dat wel, ja.
Dan heb je dus het voordeel dat die, dat die bijgeweegd.
Maar goed, even, dat is even...
Dat is een ander probleem, hoor.
Ja, precies.
Nee, maar goed, ik begrijp, dus dat telt dus wel mee.
Dus dat je ook gaat kijken van, oké, hoe veilig is dat op deze situatie?
Ja, want het is wel, als je kijkt naar de toestellen die iOS 13 kunnen draaien,
ja, de cut-off van de device, dat ligt echt iets van vier jaar in het verleden.
Dat zijn de devices die toen uitkwamen, die supporten we dan niet meer.
Ja, en als iemand dan niet beslist voor zichzelf om niet naar een nieuwe iOS-versie te updaten,
ja, dat is aan de eindgebruiker zelf natuurlijk.
Ja.
Want iemand wil zijn jailbreak niet kwijtraak ofzo.
Ja, nou ja, heel flauw gezegd.
Die eindgebruiker wil je ook niet hebben dat die je verzekeringen-app eigenlijk draait.
Want ja, hoe lekker zijn mandje is dat device van die gebruiker?
Want je bent als...
Ja, precies.
Je bent als leverancier van die software, dat appje,
ja, je wordt er wel op aangekeken als er toch onverhoopt iets misgaat.
Ja, klopt.
Ondanks dat je er...
Het staat in de voorwaarde, je hebt mensen gewaarschuwd.
Ja, het kan toch best nog wel eens misgaan.
Is het wel zo dat opzet van het product waar ik aan werk,
dat je eigenlijk niks kan, ook al heb je full access
tot de gegevens van die eindgebruiker op het toestel.
Maar dat is meer gewoon omdat er bepaalde keuzes zijn gemaakt,
ook qua backend implementatie.
En daar wordt natuurlijk ook het nodige goed in de gaten gehouden.
Ik heb nog een hopelijke slimme vraag.
Dat weet ik niet zeker, maar dat gaan we nu merken.
Er is Objective-C en er is Swift.
Nou goed, dat heb je natuurlijk net al gezegd.
Maar er is ook iets als een ABI compatibility.
Ik weet niet of je daar iets over kunt zeggen,
maar wat mij opviel, zeg maar,
omdat ik develop meestal gewoon altijd tot net.
En als er dan nieuwe versies komen, dan is het ja,
oké, er komt gewoon een nieuwe versie, ga met de banaan,
niks aan de hand en tot een bepaalde hoofd
is er een bek op de compatibility, op de framework
en in bepaalde applicatiedraad nog.
Maar goed, dat is allemaal redelijk duidelijk
en dat is niet zo heel, heel spannend, zeg maar,
om naar een nieuwe versie te gaan.
Alleen, ik zie iedere keer, oh, Swift 3, ABI-stabiliteit, bla, bla, bla.
En als je, die term hield ik nooit rekening mee.
En het is wel heel logisch, het geldt voor alle talen en platformen.
Maar kunnen jullie, of heb jij in ieder geval iets uit te leggen
over wat een taal überhaupt is?
Er is een tijd geweest dat je als developer op het Mac-ecosysteem
echt helemaal knettergek werd
als er weer een nieuwe Swift versie uitkwam,
want je kon dan vervolgens je hele codebase
weer eigenlijk gaan aanpassen.
Dat was eigenlijk gewoon van, ja, sorry, de sprint,
die gaan we niet halen,
want we moeten nu even alle breaking changes van Apple
moeten we eventjes gaan oplossen.
En dan had je gewoon inderdaad een paar dagen werk aan.
Dus ja, alles wat je in je sprint had staan,
ja, doei, dat ga je nooit halen meer.
Ja, en wat is daar de oorzaak van?
Volgens mij, we zitten nu op Swift 5, geloof ik.
Ja, Swift 5.
En ze hebben nu sinds een jaartje, geloof ik, vorig jaar hebben ze,
pin me niet op de exacte visie,
maar ze hebben sinds een jaartje ABI-stabiliteit.
En wat dat dus eigenlijk betekent,
is dat, ja, waar staat de afkorting eigenlijk voor ABI?
Ja, volgens mij het binair formaat, zeg maar.
Ja, het is binary interface,
maar ik weet even niet waar die A voor staat.
Het komt er eigenlijk op neer,
dat als je ABI-stability hebt,
dan maakt het eigenlijk niet uit met welke compiler je het compileert,
dus welke Swift-versie.
Het zal draaien op de runtime-omgeving die gebruikt wordt.
Want wat zag je ook tot,
wat zag je op een gegeven moment ook als eindgebruiker,
kun je het misschien gezien hebben,
want er is een moment geweest dat in één keer alle apps op de App Store,
dat die gewoon zo'n 20, 40 MB kleiner werden.
En dat was dus omdat gewoon die complete Swift runtime
niet meer in de app meegepakt werd,
maar dat die gewoon op je toestel draait.
En daarom was het zo'n groot ding dat die ABI-stabiliteit kwam.
Want ten eerste, het is wat makkelijker voor de developers,
maar voor de eindgebruikers schilder je een boel bandraten.
En Apple heeft bewust gekozen om die stabiliteit een tijd lang niet te bieden,
omdat ze anders tegen ze houden in het kunnen ontwikkelen van de taal Swift.
En op een gegeven moment hadden ze iets van na vier jaar of zo,
van nu is Swift voldoende uitontwikkeld.
Voorzien we niet hele grote breaking changes meer,
dus hebben ze aangegeven van nu hebben we ABI-stabiliteit.
En zullen de wijzigingen op dat gebied heel wel overwogen en goed doordacht gedaan worden.
Dus het kan nog steeds wel zijn dat er een keer een breaking change zal zijn,
maar ze kiezen er nu wel voor omdat in ieder geval forward compatible te hebben.
Dus als je een nieuwe versie hebt, dan in ieder geval een oude versie,
gecompileerd dat die gewoon wel blijft werken.
En andersom geven ze geen garanties hoor.
Je moet altijd de nieuwste Xcode gebruiken volgens Apple.
Oh zo.
Application Binary Interface.
Dat kan ik nu heel wijs zeggen.
En wat is dat een Application Binary Interface?
Je hebt eigenlijk je operating system, dus iOS,
en je hebt jouw code, dus jouw programma.
En wat dat Application Binary Interface is,
dat is eigenlijk het contract wat er op heel laag niveau leeft
tussen het platform waar je op draait en jouw executable.
Want je kan je voorstellen als jouw executable,
als die een functie wil aanroepen om iets naar het netwerk te doen,
dan moet die dat wel kunnen aangeven aan het operating system.
En wat dat ABU dan eigenlijk voor je regelt,
is eigenlijk dat het is beschreven wat waar staat,
dus dan kun je die functie aanroepen.
En als je een breaking change in je ABU compatibility hebt,
dan is het adres gewijzigd van de functie.
En probeer je beste vriend meest te vinden
als die niet vertelt waar hij naartoe verhuisd is.
En dan heb je een probleem.
Ja, ik begrijp me.
Dat heb je in principe met Windows, de DLL.
Die hebben natuurlijk ook een formaat.
En op Linux wil ik het zo even kunnen zeggen.
Linux heeft ook een naam daarvoor.
Dus dat zijn ook allemaal indelingen.
Dat was echt wel lang geleden.
Dat is toen ook nog wel wat wijziging geweest.
Alleen, wat mij opviel is dat dat
die indruk, dat binaire formaat, zeg maar,
dat die heel erg gekoppeld zat aan de versie van de taal.
En ik dacht van ja, goed.
Niet de versie van de taal,
de versie van de compiler die eronder zit.
Ja, maar goed, dat werd gekoppeld voor oké, de Swift 5.
En misschien is daar nog weinig een ontkoppeling.
Dat weet ik dus niet genoeg.
De koppeling tussen de taalversie en de compiler,
die is redelijk één op één.
Dat wel.
Ja, ja, precies.
Dus je zou zeggen,
ik kan er wel over net spreken,
maar dan heb je de runtime, zeg maar,
dat is eigenlijk een soort van virtual machine, zeg maar,
waar de applicatie op uitgevoerd wordt.
Zelfde als bij Java.
Dan zit er de bytecode, zeg maar, die dan daarop draait.
Die is gewoon stabiel.
En dan kunnen een versie van C Sharp 7, 7.1, 7.2, 7.3,
die draaien allemaal nog steeds op diezelfde runtime, zeg maar.
En die runtime verandert zich sowieso al veel minder snel
dan de taalfeatures.
Dus dat is helemaal in het begin,
dit is echt helemaal een saai ding,
de taal C Sharp en VB.NET,
die ondersteunde geen generics in versie 1.
Ja, dan moet ik even heel goed opletten,
dat is 1.1 met 1 of 1.2.
Volgens mij in 2.0 kwam generics,
maar de runtime, die ondersteunde het wel.
Daar kon je wel generics mee doen,
maar de taal ondersteunde het niet.
Dus dat was even een, ja,
ik denk, oh, oké, dat is logisch,
want er zitten ontkoppelingen in.
Maar goed, dus daarom had ik altijd zo van,
oké, hoe zit dat nou bij Apple?
Omdat Apple toch altijd net het wat anders doet.
Want die dingen van Java en .NET,
die lijken heel veel op elkaar.
Apple heeft best wel lang nodig gehad
om die abi-stabiliteit aan te kondigen.
En dat schijnt een hele bewuste keuze te zijn geweest van hun.
Nee, begrijp ik ook.
Ik bedoel, dat is natuurlijk wel...
Ik bedoel, je kan wel over wijsneuzen,
want dan zullen ze echt wel heel goed over nagedacht hebben.
Dus dat is wel oké.
En goed, wat je net zei, die interface-beelden.
Kijk, de keren dat ik dus Xcode,
waar ik in het begin allemaal zo moeilijk over deed,
Xcode openen om te kijken,
oké, ik ga even een application maken.
Dat was voor mij echt wel heel erg anders.
Want in...
Ja, er wordt altijd heel veel gekscherend gedaan over Microsoft,
maar het gemak waar je in VB,
en daar later in VB.NET,
een UI maakte,
dat ging echt nergens over.
Je had gewoon een form,
je sleepte een aantal knoppen erop,
dubbelklik op een knop,
en je zat daar in de code,
code erbij,
en ga met de banaan.
En dat waarde heel erg...
Ja.
Ja, dat is veel declaratiever inderdaad.
Dat klopt.
Ja.
Ja, dat klopt.
Dus dat was zeg maar, ja sorry,
dat was in eerste instantie,
hoe we formulieren maakten, winforms, zeg maar, heette die.
En later hebben we,
dat was nog niet per se declaratief,
dat was echt in code.
Later kregen we zeg maar,
dus de declaratieven,
dat is de XAML, zeg maar, formaat.
Dat is een XML-formaat
waar je in je declaratief,
vergelijkbaar met HTML, UI,
defineert.
En dat werd dan onder water weer vertaald naar
een aantal andere zaken,
zeg maar, dat was heel de async geprogrammeerd.
Dus dat was best wel een shift, zeg maar.
En dat lijkt volgens mij wel meer op, ja,
wat er nu mee gedaan wordt met Swift.
Zeg ik dat nu goed?
Ja, met SwiftUI.
Ja, niet SwiftUI.
Ja, precies, ja.
Ja, ik heb nog niet heel veel ervaring met SwiftUI.
Ja, de gebruikelijke tutorials heb ik wel gedaan
en daar is ik een keertje van meegeprobeerd.
Maar het grappige is wel dat
interface-beelden files,
zoals cips en storyboards,
die zijn ook XML, hè?
Ja.
Ze zijn alleen niet heel erg leesbaar, zoals...
Ja, precies, zoals het eindelijk
soort van bedoeld was.
Ja, je weet dat je inderdaad gewoon
een ervaren iOS-developer bent
als je met enig vertrouwen inderdaad
een merge-conflict in een storyboard kan oplossen
en dat het dan daarna ook nog werkt.
Dat is echt wel zeg maar een soort
van achievement als iOS-developer.
Ja, ja.
Oké.
Ja.
Oké, duidelijk.
Saber, ja, nog een vraag?
Wil jij hier op een haken weer?
Nee, niet direct.
Want we hebben een aantal vragen.
Ten eerste, ik zie een aantal vragen staan.
Dus ga je in gang, als je erin...
Ja, nou, goed.
Kijk, omdat jij ook net iets zei over security
en safety van je appje.
Is je mindset bij het maken van zo'n iPhone-client
of, ja, laten we daar even bij blijven,
heel anders als je met security begint
dan als je dat later toevoegt?
En hoe kan je dat doen bij iOS?
Nou, poeh, waar zal ik eens beginnen?
Ten eerste, iOS als platform
heeft security aardig goed op orde.
Als eindgebruiker, het allerbelangrijkste wat je moet weten
is zorg dat je een passcode op je device hebt.
Want als je dat hebt,
dan zijn eigenlijk heel veel dingen al voor je geregeld.
Nou ja, waarom is dat zo?
Het is eigenlijk als je een device passcode hebt ingesteld op je toestel,
dan wordt daarvan een encryptiesleutel afgeleid
en daarmee wordt alles beveiligd op je toestel.
Dus als iemand jouw telefoon zou vinden
en zo weet je jouw passcode niet,
is alles versleuteld, altijd.
Ook als je hem gewoon aan hebt staan
en je hebt hem alleen niet unlocked.
Ja, en waarom is dat?
Dat is natuurlijk omdat je met de bekende app-sandbox te maken hebt op iOS.
Natuurlijk, dat is veel meer dingen,
maar dit is eigenlijk voor developers het meest relevante aspect.
Want de app-sandbox, dat is eigenlijk de speeltuin waarin jouw app mag draaien,
en daar mag hij dus ook niet buiten komen.
Dus dat is een plek waar je dus je instellingen kan opslaan,
je kan daar bestanden opslaan,
je kan daar eigenlijk gewoon je ding doen, zeg maar.
Dat staat op je cashing in en zo.
Maar daar kun je gewoon niet buiten komen.
Dus je kan niet, je kan eigenlijk niet eens zien
wat er buiten die sandbox is.
Je hebt gewoon een API waar je mee kan werken
en that's it.
Het voelt misschien, als je een Linux developer bent,
redelijk beperkend,
want laten we eerlijk zijn,
als je een echte hacker bent,
en een hacker in de goede zin,
dan wil je weten hoe alles werkt
en dan wil je vooral ook gewoon eens een keer
gewoon ergens je vinger in steken
en kijken of het stuk gaat.
Dat kan op iOS natuurlijk wat minder makkelijk.
Het voordeel is wel, omdat je dus die app sandbox hebt,
dat je dus inderdaad gewoon als eindgebruiker
weet dat je spullen redelijk veilig daarop zijn.
Natuurlijk is het ook wel zo dat je daar wel
afhankelijk bent van wat de software-entwikkelaar
doet van het appje dat je gebruikt.
Want als je als software developer bezig bent,
dan moet je nog steeds wel gewoon,
ook al werk je binnen de
condities en restricties van Apple,
je moet nog steeds wel goed nadenken
over wat je doet, want je kan nog steeds gewoon hele
domme dingen doen, zeg maar.
En waaronder inderdaad gewoon
niet goed omgaan met netwerkverkeer.
De spullen die echt kritisch zijn
voor de privacy van de eindgebruiker,
dat je die op de verkeerde manier op slaat bijvoorbeeld,
want die sandbox is wel veiliger,
maar ik zou daar bijvoorbeeld niet,
het BSN-nummer
van de eindgebruiker in
zomaar op slaan.
Dat zou ik echt wel over nadenken hoe ik dat doe,
want je hebt nog steeds dat je
eigenlijk hetgene waar ik van uitga
is eigenlijk een aantal dingen.
Als je software ontwikkeling doet, je hebt data at rest,
en data die dus gewoon
opgeslagen is.
Dan moet je bedenken van oké,
als ik het opgeslagen heb, is het veilig.
Als dit gewoon op straat komt te liggen,
is dat oké.
Als dat niet oké is, dan moet je natuurlijk maatregelen opnemen,
dus versleuteling, of gewoon niet opslaan.
En je hebt
data in transit, dus dat is gewoon
data die je gewoon in het geheugen hebt, of data die
je het netwerk overstuurt.
Wat je daar dus eigenlijk gewoon als
iOS-developer, volgens mij net zoals elke
software-developer gewoon moet doen, is gewoon
bewust zijn wat je verstuurt, en
ook bedenken van, ik heb deze
data, maar
wil ik deze data überhaupt wel?
En als ik die data heb,
moet ik hem dan wel vast houden.
Want als ik mee heb gedaan waar het voor
nodig was, dan data die je niet opgeslagen
hebt, kun je ook niet kwijtraken, zeg maar.
En er zijn natuurlijk
bepaalde middelen in een iOS
omgeving waar je gewoon dingen kan
opslaan. Je hebt de keychain, die kennen
we waarschijnlijk allemaal ook wel als je op een Mac werkt.
Er staan al je internetwachtwoorden,
kun je daarin zetten enzo.
Als iOS-developer kun je
daarop, als je daar iets in opslaat,
kun je ook aangeven van
wat van restrictiestijl op zit. Je kan bijvoorbeeld
aangeven als developer van ja, ik wil dat dit
niet het device verlaten. Ik wil niet dat dit naar
Apple gesynchroniseerd wordt.
Of je kan instellen van ja, ik wil dat
als de gebruiker dit benadert, dan moet
hij zijn device ownership
bewijzen. Dus je
devicecode invoeren
of je touch ID of je face ID.
En dat heeft dan weer met die secure
enclave te maken die in
Apple devices zit.
Dan krijg je gelijk de vraag, wat is de secure enclave?
Ja, dat is een soort van
ja, dat is een soort van
system on a chip die
in elke iPhone en elke Mac
tegenwoordig zit. Die volledig
afgegermd is. Nou, en dan was er nu net wel
een paar weken terug dat daar wel weer een of andere
security lag in zit natuurlijk. Ja, klopt, ja.
Maar dat de
path to exploitation van dat ding
is vrij bewerkelijk. Dus je bent nog steeds
veilig als gemiddelde eindgebruiker.
Maar wat dat secure enclave doet, dat is
eigenlijk gewoon een system on a chip
met een eigen stukje opslag
waar dan eigenlijk
waar gewoon eigenlijk
encryptiesleutels in worden opgeslagen.
En waar je dus alleen bij kan komen
als je device ownership bewijst.
En het ligt een beetje aan hoe je het instelt.
Dat mag zijn dat je dat eenmalig hebt
gedaan bij het starten van je toestel.
Het mag ook zijn dat dat gewoon elke
keer dat je het uit wil lezen. Ja, maakt me niet uit.
Je moet het gewoon bewijzen nu.
Nou, en dat is het betekent
dus ook dat je als je op die
manier de login van een gebruiker beveiligt.
Dus het zit in de secure
en je wil Face ID login
aanbieden aan je eindgebruiker.
Als je dat doet, dus je moet door die secure
ankleven en dan doe je het goed.
Maar je hebt ook zoiets dat je, hartstikke leuk
voor developers, maar dat je gewoon eigenlijk gewoon
aan, dat is een API
beschikbaar in iOS, dat je kan vragen
nou, vraag me naar een eindgebruiker of
een Face ID of een touch ID
doet en geef me maar true
of false terug of het goed is.
Ja, en dan als het
goed is, als je true krijgt,
dan lees ik een waarde uit de keychain en
succes, we gaan weer verder.
Dan wil je dat, eigenlijk
dat beveiligde element, wil je dan
echt in die secure ankleven hebben
zitten, in plaats van dat het gewoon in de keychain slaat.
Ook al is het voor de eindgebruiker, die
ziet gewoon hetzelfde. Die zegt
ik wil inloggen en bwap, daar krijgt
de ding in zijn gezicht van, oh,
ik moet even glimlachen naar de camera
en je gaat
weer verder. Maar ja, dat soort details
moet je wel gewoon rekening houden, dat je dus inderdaad
je kan dingen over verschillende dingen
oplossen, maar ja, je keuzes hebben wel
effecten voor
ja, waar je data is opgeslagen
en hoe veilig het nou werkelijk
is. Bij het
project waar ik nu dus op werk bij de
Achme, ja, is het zo dat
ja, dat iOS device
hartstikke leuk.
We slaan alles zo veilig
mogelijk op.
Maar dan, er zijn bepaalde
elementen aan data die we dus danig
belangrijk vinden.
Die slaan we dus op met een
sleutel die is afgeleid van de
gebruikersinvoer, dus de pincode.
Nou, en waar
zorgen we dus voor? We zorgen ervoor dat datgene
wat we afleiden van die pincode,
dat is
gewoon die gebruikersinvoer met een salt
en dat ga je hashen en dan heb je
een mooie reeks en bytes, heb je dan
wat dan je sleutel is.
Ja, die houden we natuurlijk
zo kort mogelijk in het geheugen,
zodat als we ermee hebben gedaan wat we
ermee willen doen en we hebben het niet meer nodig, nou, weg
met dat ding, want ja, eigenlijk
in security is eigenlijk alles wat met security
te maken heeft, dat is eigenlijk radioactief
afval en je
bent het liever kwijt aan rijk, zeg maar.
Ja, precies, ja.
Tuurlijk, als je gewoon een
leuk appje schrijft die
gewoon wat leuke dingen doet
voor de gebruiker, ja, dan kun je er misschien een heel anders
mee omgaan dan als je daar inderdaad
je bank- of verzekeringszaken mee
doet. Ja, ja, dat is wel wat kritischer.
Ja, natuurlijk. Ja, en
alles staat of valt natuurlijk
met hoe goede PIN-codes, hoe goede
wachtwoorden hier gebruikt.
Want je kan
echt nog steeds
gewoon Fort Knox hebben, zeg maar, als
huis, maar als je
je PIN-code op een poster op de
voordeur plakt, ja, hallo,
doe effe niet,
dan gaat het er vrij makkelijk mis.
Ja.
Ja, maar dat spreekt eigenlijk ook. Ja, goed, dat
spreekt voor zich, dat blijft. Hoeveel
mensen ken jij met een device PIN-code van 0000?
Dat zijn er
veel hoor. Let
maar eens op, als mensen hun device inlokken
met een PIN-code, hoe vaak je ze ziet, dat
ze gewoon op één saai weer tik, tik, tik, tik, tik doen.
Dat is echt wel grappig om te
zien. Ja, dat klopt, dat is wel een ding.
Nee, die begrijp ik al,
maar goed, het is op zich wel, ik denk dat
mensen niet eens zich zorgen maken om
de bankzaak, want dat
denken ze misschien niet
per se aan als ze over die PIN-code
nadenken, maar
ja, weet ik veel dat je niet wil dat
als je hem achterlaat dat jouw collega
lekker even je WhatsAppjes uit kan lezen of
dat soort dingetjes vinden mensen misschien nog
veel erger. Ja, dat klopt. Mensen dat bedenken
zich makkelijker dan dat ze denken, oh, wacht even,
maar mijn bankier is misschien niet
veilig als ik dit zo doe.
Nou ja, je merkt wel vaker,
mensen, als ze er
gezichtsverlies van leiden, dan is het vaak toch wel
een dingetje en als ze er niet over nadenken,
dan maakt het inderdaad niet zoveel uit.
Ja, je zei net ook, ik werd
een beetje getriggerd, want
de Cocoa Heads
is een
community, zeg maar. Klopt. Maar die naam
is natuurlijk niet op niks gebaseerd. Kijk, voor mij
is dat, ja, ik heb dat ooit eens gehoord, maar
ik denk dat niet iedereen weet wat Cocoa
überhaupt is.
Ik zie wel verschillende termen langs
Cocoapods, zeg maar.
Maar kun je vertellen
sowieso wat Cocoa is en
daarin in het verlengde,
wat Cocoapods voorstellen.
Ja, het is eigenlijk...
Ja, oh ja, sorry, ja.
Cocoa, dat is eigenlijk gewoon als je
die hard Mac developer bent, dan is dat
eigenlijk de user interface library
die je in AppKit gebruikt.
En AppKit is dan eigenlijk een beetje
het algemene
user interface framework voor op de Mac.
Nou, Apple heeft daar natuurlijk
ook een iOS variant van
geschreven, die heet
UIKit. En die
user interface stukken erin,
dat valt een beetje onder de noemer Cocoa Touch.
Ze hanteren die naam Cocoa
niet meer zo heel veel tegenwoordig,
maar dat is de origine daarvan.
En het is eigenlijk, ja,
Mac developers hebben een beetje de neiging,
en iOS developers ook, om alles
wat maar een beetje met user interface
te maken heeft, of in ieder geval een beetje
idiot zijn over development op de Mac.
Cocoa, whatever.
Cocoa Pots, Cocoa Touch, Cocoa
Heads, zeg maar.
En als je dan naar dat Cocoa Heads kijkt,
het bestaat al vrij lang, nog van voor
dat ik met app development in aanraking
kwam.
Was het eigenlijk al gewoon een soort van
ja, meetup, los,
vast, een beetje zoals de HCC,
misschien wel.
Dat je van, ja,
ik ben een
vakidioot, ik heb er zin in, ik wil andere
mensen zien, en
het moet een beetje een naam hebben die
voor de inkrouwt
een beetje laat zien waar het over
gaat. Cocoa Heads.
Dus je bent
gewoon Cocoa-minded,
zeg maar.
En daar komt het vandaan.
Dat waren meetups maandelijks, en
toen dat nog mocht, wat voor aantallen
moeten we dan denken? En was dat dan
Amsterdam of Utrecht?
Dat Cocoa Heads komt
uit Amerika, en dat was inderdaad een beetje
een hobbycomputerclub,
en dat is tien jaar geleden door
Pieter Robinet, is dat hier in Nederland
begonnen, want ja, er was een expat
die uit New York kwam, en die kwam in
Nederland en had zoiets van, ja, ik
wil mensen leren kennen, we hebben dat eerder gehoord.
Ik ga meetups organiseren, goh,
dat is toch wel een bekend onderwerp
in deze podcast, heb ik het idee.
En die is daar toen mee begonnen.
En, nou ja,
ik ben er desto ooit een keer ingerold,
en ja, we hebben nu dus eigenlijk meetups,
als we ze in persoon doen,
dan hangt het eigenlijk een beetje af van de
locatie waar we zijn, want
ja, we kunnen tien man bij elkaar krijgen,
we kunnen dertig man bij elkaar krijgen, we kunnen
150 man bij elkaar krijgen.
Want het is op dit moment het bereik
van, in ieder geval,
van mensen met in ieder geval een interesse
die ze aangegeven hebben,
dat zit nu ergens in de 1200
mensen, die
in ieder geval updates krijgen
als we weer een nieuwe meetup organiseren.
Ik moet wel zeggen,
en dat heeft volgens mij elke
meetupgroep heeft dat, het is
hetgene waar we eigenlijk het meeste tegen aan het
knokken zijn, is het terugdringen van het
aantal no-shows, want
dat is echt niks zo bloedirritant dat je voor
veertig mensen eten hebt en daar dan volgens mij twintig
man in dat zaaltje staat, zeg maar, en dat is
ja, dat is
ja, daar loop ik me echt om op
te vreten, en ja, en om altijd eten zelf in de
3 weken lang hetzelfde, zeg maar.
Ja, dat wil je ook niet. Je wil gewoon
dat mensen komen, of in ieder geval tijdig
aangeven dat ze niet komen.
Maar ja,
over het algemeen, een
meetup van CocoHertz is zo'n
30 tot 50 mensen, meestal.
En dat ligt aan de locatie.
Want wat we doen is eigenlijk,
ja, we lopen eigenlijk gewoon
alle bedrijven die iets met
Mac of iOS die verder maar doen,
die zijn welkom.
En die bieden dan eigenlijk gewoon
hun kantoor aan. Daar gaan we
naartoe. Er wordt eten en drinken
geregeld en wij regelen een
spreker en de locatie die regelt
de andere spreker, want ja, die hebben natuurlijk ook een belang
bij dat al die mensen binnen zijn. Die willen gewoon
contacten krijgen
met potentiële nieuwe
medewerkers of inhuur.
Ja, ja, duidelijk.
Oké, grappig.
Ik
zat op je website te kijken vandaag
en toen zag ik daar een blogpost over
Xcode met
een wat hele handige shortcode
keys, dus daar wilde ik je voor bedanken. Ik heb vandaag
al tien keer Control 6 in getypt.
Ja, die is goed, hè? Ja, die is heel goed, ja.
Heb je ook iets tegen
Xcode?
Nee.
Niks?
Ik weet niet of ik last heb van
Stockholm-syndroom, maar
het is wel iets
wat...
Xcode is wel een acquired taste,
heb ik het idee. Het is qua IDA,
het ziet er wel allemaal heel slick uit.
Het heeft ook wel eens
in zijn hele lifecycle ook wel
periodes gehad dat het echt gewoon,
dat het gewoon niet
stabiel is.
De derde keer dat je
compilert, garandeert een crash.
Ja, en dat is natuurlijk bloed
irritant. Vooral als dan ook al zijn
cash's corrupt zijn en je dan vervolgens weer de
eerste vijf minuten naar zo'n indexer zit te kijken
die dan bezig is.
Maar ja,
eigenlijk qua IDA, ik kan er
gewoon alles mee wat ik voor
ARS development doe, maar het is wel...
Soms zit ik ook weleens qua code editing,
dan is het gewoon niet handig om dat in
Xcode te doen.
En dan pak ik bijvoorbeeld
Visual Studio Code.
merk dat ik met de type
af en toe erger van, dan doe je iets en dan
is het gewoon niet wat je bedoelt met een
copy paste actie of wat ook met die
auto tap completion.
En dan erg ik me, maar voor de rest is het
prima.
Ja, wat je wel merkt
op dit moment is volgens mij dat de meeste
IDA's die echt wel een beetje
naam hebben, dus dan heb je over
de spullen van JetBrains, Visual Studio
en dan niet Visual Studio. Volgens mij is alles
Visual Studio Code nu bij Microsoft, toch?
Nee, nee, nee.
Ja, de gewoon grote mensen,
Visual Studio.
En Visual Studio.
Je ziet dat die qua editing experience
in ieder geval, en dan heb ik het niet
over alle plugins en helpers
en dingen die eromheen zitten, maar dat is qua editing experience
wel redelijk met elkaar omparst.
Natuurlijk, de shortcuts die liggen anders
en je muscle memory zul je
niet meenemen.
Dat viel me wel op.
Dat is wel
verbeterd, toch?
Het is nog steeds, als je
refactoring gewend bent, zoals
in de gemiddelde Java IDE
of in Visual Studio,
daar is niet.
Van JetBrains heb je wel app code,
ja,
je hebt niet zo makkelijk
extract method en
renaming heb je dan wel van een type name.
Dat gaat ook niet gegarandeerd
altijd goed als je net een compiler
hebt, maar
het is wel iets wat, refactoring
support is op Xcode inderdaad.
Dat is een zwakke plek,
maar ik mis het eigenlijk ook helemaal
niet, want het is als je gewoon
een beetje vlot kan editen en
goede finds en replays kan doen,
dan lukt het allemaal wel.
Je zei net even
heel snel app code,
want ik wilde me een vraag stellen
over een alternatieve IDE voor
iOS en
Mac development, maar app code is er dus
één. Ja, app code is
eigenlijk gewoon
IntelliJ, maar dan voor
alles wat je
met Xcode kan doen. Dus daar kun je
Mac apps en iOS apps in draaien,
alleen het nadeel is wel,
om JetBrains
app code te kunnen
gebruiken, moet je Xcode geïnstalleerd
hebben, want bepaalde dingen
kun je gewoon alleen maar in Xcode doen.
En dat is
gewoon, ja oké,
dat is zo.
En ik merk wel
dat
Xcode heeft nu wel, zeg maar, sinds Xcode
10, hebben ze wel
een beetje zo'n kantelpunt bereikt
dat je
in mijn beleving steeds minder mensen die
helemaal
app code minded zijn en absoluut geen
Xcode willen gebruiken.
Ik zie steeds meer dat mensen,
oké, app code hartstikke leuk, maar het gaat
allemaal net even iets flotter in
Xcode, zeg maar.
Want app code is toch best wel vaak bezig met
allerlei compiles en indexing en dat soort
dingen die echt lang duren.
En ja,
ik heb het wel eerst een
keertje geprobeerd, ook omdat ik met PyCharm
gewerkt heb. Dat is zeg maar de
Python IDE van
JetBrains.
Ja, dat probeer je
toch eens een keer, want dan denk je, nou, dan kan ik alle
dingetjes die ik ken uit PyCharm kan ik dan ook
gewoon meenemen naar app code. Maar ja,
het is er toch op de enige manier net niet.
En ja, het is heel persoonlijk.
Ik bedoel, het is niet of je
een iOS of Mac developer bent, dan kun je
gewoon niet om Xcode heen.
Ja, oké.
Ik hoor
geluid, maar ik weet niet waar het vandaan komt.
Of is het bij mij?
Dat is niet bij mij.
Oké, ja, dat had hij ook
kunnen. Ik was al blij
dat er niet allerlei rare vogels
zijn. Wie zijn jullie dan?
Oh ja,
dat is
ook een beetje
pet. Maar goed,
er zijn alternatieven en die ken ik niet allemaal, maar
je hebt vast van Xamarin gehoord.
Ja, hoe wordt daar
tegenaan gekeken? Dus vanaf
de native developer
met Xcode.
Want ja, ik zie dat vanaf
de andere kant van .NET
en Michael de Casa, zeg maar, die
de oprichter is
van Xamarin. Op zich wel
een slimme vent en die ook trouwens
ook af en toe is in
Swift developed.
Maar hoe wordt daar tegenaan gekeken?
Is dat heel gek?
Ja,
Xamarin development
is echt anders dan
als je, zeg maar,
native Xcode
of eigenlijk iOS development doet.
En je hebt
eigenlijk twee soorten reacties die
mensen geven. Je hebt echt mensen die
Xamarin looser
doen. Doe het gewoon echt, weet je wel.
Doe het doel nep.
En je hebt inderdaad de categorie
van ja, oké, het bestaat en
ja, het doet het. Niet mijn ding.
Ja, en er zijn
mensen die natuurlijk gewoon met Xamarin development doen.
de grote belofte van Xamarin is natuurlijk
dat je gewoon de typische Java
belofte hebt. Write once,
run op twee plekken dan.
Dus op Android en iOS.
Ja, en
dat klopt. Maar
als je in Xamarin een app wilt schrijven die
op iOS echt gewoon
een goede iOS app is en op Android
echt een goede Android app
is. Ja, dan kun je eigenlijk net zo goed die
beide apps gewoon los van elkaar schrijven.
Want hoeveel effort die je moet doen
om het op beide platformen
echt gewoon goed te laten werken. En ook dat
iemand in zo'n app zit en ook echt zo van
wat is dit dan? Maar dat het echt gewoon
voelt als een goede app.
Ja, dat kost gewoon net zoveel tijd.
Dus als je gewoon
twee codebases hebt en je
gaat er gewoon volle bak op, dan denk ik dat je
gewoon, ja,
minstens net zo snel kan zijn als met
Xamarin, zo niet sneller. En dat heeft
vooral met te maken dat je met Xamarin, als je
wat dingen wilt doen die
dus niet zo direct supporten zijn
dan moet je zelf, ik geloof dat het
Bridges ofzo heet en dat je die moet schrijven, maar dan moet
je dus eigenlijk gewoon stukjes
platform
native dingen gaan schrijven om over te zorgen
dat je dat kan exposer binnen
Xamarin.
En daar hoor je wel,
als dat aan de orde komt,
ja dan
ben je eigenlijk af, want dan
voor de meeste developers wordt het toch
dusdanig ingewikkeld dat het niet weer voor iets is
wat er zo even bij gedaan wordt.
Ja, het is weer die 80%-20%.
Dus voor 80% kan het
best wel fitten, maar als je dan die 20%
nog wil bereiken dan kost het weer 80%.
En onderhoud.
Een typische
use case waar ik denk dat
Xamarin heel erg goed geschikt zou zijn
is inderdaad gewoon voor die
in-house applicatie.
Het correct functioneren,
dat dat belangrijker is dan dat
het echt gewoon helemaal op een top
goed smoelt
in de App Store of in de Play Store.
En dan heb je echt wel
winst van zoiets als Xamarin, want dan kun je inderdaad
snel gewoon naar een in-house app
uitpompen die gewoon in ieder geval op veel devices
kan draaien en die ook redelijk
duidelijk werkt bij de platformen.
Ja, en dan, kijk,
als je al gewoon een .NET
shop bent, ja, dan
denk ik dat je
wel goede redenen moeten hebben om dan
voor een in-house applicatie inderdaad niet
Xamarin te gebruiken.
Nee, nee, precies.
En zo zijn er nog andere varianten, volgens mij zijn er
andere... Ja, je hebt React Native
bijvoorbeeld, of nou ja, liever
heb ik het over, je had React Native.
Ja, is dat nog zo?
Wat is er nu, want dat hoor
ik nu verschillende dingen over, want het
was een enorme hype.
En ik kon op zich een mooie belofte.
Je hebt mensen die inderdaad
gewoon webdevelopment doen met React
en dat bevalt die mensen
goed en dat snap ik, want
ja,
een web applicatie, ook al
is het een single-page applicatie,
dat leent zich heel goed voor
een reactive manier van programmeren.
Misschien
een beetje lastig om daar nu een beetje
te diept in te gaan, maar het komt
erop neer
dat dat gewoon een bepaalde manier van software
ontwikkelen is.
En als een single-page
web applicatie
past binnen je doelstellingen, dan is
React heel erg mooi.
Want dan kun je heel snel zijn.
Het is een eenduidig platform,
het is een goede lifecycle, het is goed duidelijk
te doorgronden inderdaad van wanneer nou
wat gebeurt, ook als je iets op het scherm
krijgt. En met React Native
hebben ze datzelfde programmeermodel
ook naar Android en
iOS en destijds ook naar Windows
Mobile willen krijgen.
En dat hebben ze ook wel echt wel voor elkaar
gekregen. Het draait, je kan apps
in ontwikkelen, er zijn ook echt grote apps in ontwikkeld.
Facebook Messenger was er
een van.
Wat wel heel erg typisch is,
React Native is dus
door Facebook ontwikkeld als platform.
Is dat Facebook
nog niet zo heel lang geleden een hele Messenger app
heeft herschreven naar
volledige native apps.
En ja, en
volgens mij hebben ze het ook nooit in de
in de Facebook app zelf gebruikt,
weet ik niet zeker. Ik ben geen developer daar
geweest.
Ik weet wel dat Facebook
app ooit ook, zeg maar,
of het React Native is,
dat durf ik niet te zeggen, maar het was wel
een soort van
een schil zeg maar, die dan native
draait met daarin een webview, zeg maar.
En daar zijn ze
van los, dat hebben ze achter zich gelaten, want dat
vervormde ook vroeger echt je meter.
En het probleem,
wat ik, ik heb zelf nooit
met React Native gewerkt, maar wat ik gewoon
inderdaad op mijn netwerken heel vaak hoor,
is dat
mensen gaan met React Native van de gang
en dat gaat als een T-release,
ze leveren functionaliteit op als een mallen,
zeg maar. En dan
komt er een software update van
React Native library en moeten ze het updaten
en upgraden en
hoeveel het hoofdpijn die dan
ontstaat is, is toch best wel
best wel spannend, eigenlijk.
Want ja, je wil eigenlijk gewoon hebben
dat, ja, je, eigenlijk je dependencies,
daar wil je gewoon zo min mogelijk last van hebben.
En je wil niet hebben dat je project gewoon
in één keer een paar dagen
of nog erger stilvalt, omdat je
even wat updates moet doen.
En dat is dus echt, dat heb ik al
meerdere malen zien gebeuren, dat het met React Native,
dat ze dus daar nog breaking changes ook in
een API maakte, dat het gewoon niet even
meer bij te komen was.
Ja, en ja, het
voordeel van React Native is
dat je het in JavaScript kan doen.
Nou ja,
nadeel is natuurlijk ook weer gelijk dat het JavaScript
is, volgens sommige mensen.
Ik ken JavaScript niet goed genoeg om te zeggen
van nou, Poe.
Ik heb ook weleens iemand horen zeggen
JavaScript, dat is eigenlijk gewoon
list met een rare syntax, als je het op de
goede manier gebruikt. Ik weet ook niet waar die vandaan
kwam. Nou ja, dat is niet helemaal
gek, zeg maar.
Ja, dat is niet helemaal
raar, ja. Nee, klopt.
Ja, wat je dus wel met
React Native merkt is dat het gewoon
ja,
je moet er wel de mensen voor kunnen vinden
en dat geldt eigenlijk voor elk cross platform
development. Je moet niet alleen
het platform kennen waar je mee werkt,
maar je moet ook de onderliggende platformen,
iOS en Android, toch wel
op een zekere hoogte
snappen en kunnen
om inderdaad gewoon zeker te zijn
dat je dingen echt klaar krijgt
ermee. Ja.
En het schijnt volgens mij
wel makkelijk te zijn om React Native op
Android te gebruiken dan op
iOS, omdat
iOS, dan gaat het het vaker
stuk, zeg maar, in de stack.
Oké.
Ik denk dat het wel duidelijk
is dat ik zelf niet heel erg fan ben
van cross-platform
Ja, maar ik begrijp dat op zich wel
hoor, want het is mijn
mening.
Dus met Xamarin
ik ben zelf geen, want ik vond het wel
cool, van oh, tof, even
kijken wat het nou is. Toen had ik
zoiets van ja, dan ga je
nooit de echte native experience
erin krijgen, want dat is natuurlijk de kwaliteit
van wat het platform biedt, dus wat Xamarin
gaat aanbieden en de concepten
die je in C-Sharp
of ja, volgens mij, kunt
programmeren, hoe goed zijn die
doorvertaald naar
AOS en welke
functionaliteit van AOS
kun je gebruiken. Dus dat telt
mee. En ik had al zoiets van nou ja,
weet je, haal ergens
twee hele goede ontwikkelaars.
De ene is heel goed in
dus eigenlijk weet je wat jij ook
zegt, in iOS development, eentje is
heel goed in Android development, en laat
die dat doen, zeg maar. En dan
een aantal argumenten die je dan krijgt, van ja,
maar dan kun je geen code delen. En dan weet je, ja,
maar dan heb je bepaalde business code die je dan wilt
delen over die twee platforms eens.
Ja, dat kan wel.
Natuurlijk zou dat ook kunnen, maar ik denk wel, welke business code
wil ik dan in die app, stel dat ik
een API heb, en daar de business
app draaien.
Ja, want dat is inderdaad,
wat je daar zegt, is wel een punt inderdaad,
want je hoort inderdaad, ja, maar ik
wil mijn code delen en zo, maar de meeste
apps
zeg maar op Android en IOS,
ja, die ontlenen het grootste deel van
hun waarde toch eigenlijk ook wel aan de backend
waarschijnlijk. Ja, dat is de meeste business logic.
Ja, precies. Ja, mijn ervaring
met dat soort oplossingen is eigenlijk, dat het
weet je, elke extra laag
ertussen zorgt ervoor dat het, dat je
iets eerder, dat het gaat wringen.
Weet je, dan lukt het net niet en dan moet je
in een rare bocht gaan zitten werken, om iets voor
elkaar te krijgen waarvan je denkt, nou ja,
dit kan niet zo moeilijk zijn. En dat is ook
niet zo moeilijk als je niet,
als je gewoon bij de native code blijft.
En hoe snel het gaat wringen,
ja, dat ligt dan een beetje aan die laag.
Maar ja,
ik ben er wel eens heel snel tegen aangelopen. Ja,
dat beviel me niet.
Ik zit dan liever dichter op
het OS en
in dit geval dan Swift Objective-C, dan
verder weg.
Ja. Ja.
Ja, dat is ook,
ja, het is een deelsmaak
en deels, ik denk ook, als je
de case gaat maken,
zeg maar, wat gaat het met kosten, even heel
concreet. Dus dat ik denk,
nou, een hele goede developer
van alle tweede platforms, die gaat gewoon
echt sneller zijn. En als die een factor
twee keer zo snel is, ja,
dan denk ik dat die business case
heel snel gemaakt is om gewoon die twee mensen
in te duren. Maar dan heb je nog, als je zo
gaat redeneren, dan moet je natuurlijk ook die mensen kunnen vinden.
En dat is
ook, ja,
maar wat is het? Maar wie vind je
makkelijker, de Xamarin developer of de NATO developer?
Ik denk dat er minder
Xamarin developers zijn dan de NATO developers.
En daarbij, wat is,
zeker als je snel wil zijn,
moet je dan eigenlijk wel
willen dat je twee
apps tegelijkertijd ontwikkelt.
Kun je dan niet beter die twee developers op of
Android of iOS zetten, dat
die dan eerst gewoon, je gaat gewoon eerst
MVP halen. En wat ga je dan de eerste doen?
iOS.
Ja, dat is heel simpel. De meeste bedrijven
kiezen dan iOS. En de reden daarvoor
is dat, ja,
het schijnt dat iOS
gebruikers, ja,
de euro's gewoon iets losser in de portemonnee
hebben zitten. En dat heeft
niet zozeer te maken met
koopkracht
en dat soort dingen. En niet gewoon
zozeer van het inkomen letterlijk van de persoon,
maar meer met het
gemak waarop je op iOS,
je geeft
iets makkelijker geld op iOS uit
dan op Android. En ik weet niet waarom
dat is, want je hebt mensen die
zweren bij Android en die
wonen in een kast van huis en dan denk je echt van ja,
wat loop je nou moeilijk te doen over een appje van
1 euro. En
ja, terwijl bij
bij iOS
zie je toch echt mensen die hebben echt,
ik weet niet wat voor apps hebben ze allemaal uit de app store
staan,
waar ze ooit een keer wat voor betaald hebben. En dan denk ik echt
van ja,
want het feit
wel dat
het aantal iOS devices ten opzichte
van Android devices
die in het wild leven, zeg maar.
Ja, er zijn gewoon echt al minder
iPhones dan Android toestellen.
Elk jaar worden er minder
iOS devices
verkocht dan Android devices.
Ja, ik begrijp het ook.
Er waren ook wel meer van die
verbazingen. Dit zijn wel
hele oude cijfers. Maar als we bijvoorbeeld
gingen kijken naar,
hoe heet dat?
Als je op een web server
ging kijken van waar komen de hits vandaan?
Dat er dan veel meer
iOS
device, zeg maar,
aanklopte dan Android device.
Terwijl Android was er in absolute nummers
veel, waren er veel meer van.
Dus dat was, ja,
ik kon dat niet verklaren, ik had er toen ook geen
verklaring voor gekregen. Maar daar
zit dus echt wel ander gedrag op, op
Android als op iOS.
Ik weet niet hoe dat nu is.
Het is op zich wel iemand die gewoon
de flagship phone van
Samsung koopt.
Ik denk dat je die wel redelijk kan gebruiken,
vergelijken met de persoon die de flagship
phone van Apple koopt.
Je hebt alleen wat minder keuze bij Apple, natuurlijk.
Allewel, je kan nu kiezen tussen een mini,
normaal en pro, geloof ik,
en ook nog meer.
Ja, precies.
Je kan nu uit vier dingen kiezen,
en wat kleurtjes.
Maar bij Android is het ook gewoon,
ja, daar heb je Samsung,
en wat is nog meer de grote op dit moment?
Ja, volgens mij,
LG, ik weet niet hoe groot die zijn.
Huawei was heel groot,
maar dat is echt helemaal ingekakt, natuurlijk, nu.
Ja, door de
ene of andere oranje vent.
Hoe heet het? Ja, precies.
OneNote,
de OnePlus, nee,
hoe heet dat ding? One
plus two, ja, whatever.
HTC? Nee, niet HTC.
Het is een Chinese merk,
Apple is het moedermerk.
En voor de Europese markt,
hebben ze de OnePlus. Nog iets.
Ja, nog wat. OnePlus, nog wat.
Het zijn net van die codes die
ook achterop op dure auto staan.
Ik zie hier
640 staan, maar er zit niet de 6,4
liter in. Hoe zit dat nou?
Nee, precies, ja. Nee, maar goed,
die was in eerste instantie, die was
de prijsprecentatie was heel erg
goed, zeg maar. Maar je ziet dus,
dat vind ik wel grappig.
Dat is effe niet per se development,
maar je merkt dat er heel veel kritiek
iedere keer is op iOS of Apple
producten.
Maar dat dan uiteindelijk
binnen een half jaar of een jaar, dat andere
merken dezelfde dingen overnemen.
dat was anders,
maar de, hoe heet het ding,
de notch, zeg maar, is overgenomen.
Nou, eigenlijk, kijk, de hele touch screen is
natuurlijk ook hoe dat nu,
dat Apple met iPhone
als eerste was en dat de andere het overname.
Dus dat,
ja, dat vind ik dan wel weer opvallend.
Dat had wel een beetje, ja,
geklaagd wordt over Apple, maar andere nemen
het ook over gewoon.
Ik vind die hele strijd niet zo interessant.
Ik zit prima
in mijn ecosysteem.
Ja, wat je wel ziet
met,
dat merk ik uit mijn omgeving
in ieder geval, is dat
je nu steeds meer hoort van, ja,
weet je, mijn iPhone
11 of mijn iPhone
10, die is nog goed genoeg.
Ik hoef die 12 niet, ik wacht nog wel een jaar.
Ja, de ontwik van de devices.
Ja, wat is nou nog?
Hoe nieuw en schokkend is het nieuwe
en schokkende van de nieuwe iPhones?
Ja, het grootste nieuws
van de iPhone dit jaar is dat er een iets
kleinere versie is.
En verder,
ja, hij is sneller en
een betere camera, maar
hoe goede camera moet je hebben, uiteindelijk?
Ja,
ik deed het eerst iedere twee
jaar upgrade ik.
Maar ik heb nu een iPhone
X, de iPhone 10.
En ja, dat ding was,
dat is sowieso, volgens mij,
in één keer een veel dure telefoon.
Want ik had ook die, ja goed, die
256 gigabyte.
Dat ding was echt belachelijk dure.
Want al had ik al eens iets van, oké,
misschien dat ik met deze iets
langer ga doen. En ik
zie eigenlijk, nu ik de nieuwe,
ja, los van het design is wat anders,
heb ik niet zoiets van, oké, ik moet nu per se
de nieuwe hebben. Dat heb ik echt al,
ja, dat heb ik gewoon niet meer
sinds een jaartje of twee, drie.
Komt het nou omdat we kinderen hebben?
Nee, ik heb dat heel lang niet.
Nou goed.
Wat ik ook merk is,
als ik een Xcode test, dan
kies ik gewoon de kleinste oude telefoon
in mijn Simulator. Want als
het daarop past, dan heb ik in ieder
geval ruimte genoeg.
Ja, dat wordt nog wel een dingetje
op de iPhone mini, want
die schaalt
eigenlijk alles wat er op
een iPhone 12 getoond wordt.
Op een iPhone 12 mini wordt het allemaal
iets kleiner weergegeven.
Dus dan moet je...
Dat wordt voor de leesbaarheid nog wel een usability
dingetje, denk ik.
Want het is heel typisch. Wie kopen
over het algemeen de kleinere
toestellen?
Zonder gelijk weer
te stereotyperen, want ik weet
dat we het over community guidelines en zo
gehad hebben op deze podcast.
Maar de
kleinere toestellen worden toch vaak door
dames en oude mensen gekocht.
En waarom is dat?
Ja, zo'n enorme roeispaan
past niet in je broekzak.
Want ik weet niet of je het wel eens
vergeleken hebt, hoe groot een broekzak
van een herenbroek is vergeleken met die van een
damesbroek. Het is echt belachelijk.
Dat past bij mij, in mijn broekzak, past
gewoon vier keer zoveel als dat
bij mijn vrouw in de broekzak.
Wat wel grappig was, zeg maar,
toen de iPhone...
Er was toen een trend, dus al die telefoons werden groter.
En Apple die bleef maar hangen op
Ik weet niet, rond de 6 of zo, die was
allemaal wat kleiner.
En toen kreeg je in een keer de 6...
Is dat de 6 Plus of de 6S Plus?
Weet ik veel, de grote.
Ja, op een gegeven moment had je de Pro en de Pro Max
en dat je echt denkt, wat zijn die namen joh?
Dat je echt denkt, wat?
Maar het werd echt groter en dat was
echt een soort van statussymbol.
Je zag dus juist een vrouw, want je zegt ook van
een vrouw kleiner, maar die vrouw
die liep altijd met zo'n hele grote, zeg maar.
Ja.
Volgens mij
moeten we ook oppassen dat we niet
al te veel generaliseren en opmerkingen
maken. Nee, het was niet
generaliseren, maar dat merken ze.
Dat hebben ze onderzoek naar. En bijvoorbeeld ook in China
zeg maar, was het een statussymbol, dus die
grote verkocht gewoon beter, gewoon puur
om te kunnen laten zien, kijk, ik kan die
de duurste en de grootste kan ik betaal, terwijl
ik heb de 6S Plus, die heeft
mijn zoontje nu, ze slaapt eigenlijk ook nergens op.
Als ik dat ding vasthoud, denk ik, ja
dat ding is gewoon te groot. Weet je,
ik had zoiets van, ja,
ik kwam toen van een 5S,
dat formaat vond ik echt goed.
En toen dacht ik, ja, oké, nou ja,
Apple gaat groter, zeg maar, en dan weet je, als ik dan toch
groter ga dan, dan my all the way.
Dat sloeg helemaal nergens op.
Zo groot dat je broek ervan afzakt inderdaad.
Ja, echt. Dat ding was eigenlijk helemaal niet praktisch.
Die kon je niet in je broek dragen.
Had je gewoon een tasje nodig om hem mee te nemen.
Ja, ik vind de iPhone 10,
die ik nu heb, dat vind ik op zich een goede
goede grootte.
Ik moet alleen uit mijn hoofd praten dat ik
niet de Pro Max
of whatever dat ding ook heet,
ga kopen omdat dat ding een iets
betere camera heeft. Je zei net
van ja, wat maakt die camera uit? Maar ja, goed,
ik maak best, weet je, de kinderen
maken wat foto's van.
Ja, iPhone camera is de meest gebruikte
camera in de wereld.
Ja, dat klopt.
Dus dat is echt wel
grappig.
Ja.
Even kijken.
Ik weet niet of wij nog andere vragen
willen stellen. Heb jij nog iets, Bernard?
Nee, ik denk dat we een leuke overview hebben gehad
over iPhone ecosystem
en ontwikkeling.
We kunnen wel,
nou ja, laten we dat niet doen, de diepte in gaan
op patterns
of wat ook.
Tijd voor een rant, of niet?
Ja, dat is een hele goede.
Saber.
Heb ik daar, ik heb geen mooie
rant, jingle.
Ja, dat is een nieuw onderdeel.
Ik heb gewoon geen...
Geen jingle?
Nee, geen goede.
Die airhorn, deze die...
Dat is geen rant.
Maar ja, je kunt wel aankondigen.
Rant, ik heb
niet zelf eentje, volgens mij heb ik daar zelf geen
gevonden.
Ik zag wel
dat Jeroen
een tweet aanhaalde
van Emily
Kager.
Kager is ook
in het Engels.
Kager, ja.
Ik zag er zelf sowieso
een aantal keer langskomen en
ze had, dit ging over, je moet me even korrigeren,
want het ging over een TikTok video,
die wordt alweer gepost op Twitter,
ingewikkeld.
En daarin
speelt ze een soort van job-interview
van
een arts of een chirurg, die
wordt
ondervraagd.
En dan vragen ze ook van, hey, maar...
Je opereer je ook in je vrije
tijd. Je opereer je ook in je vrije
tijd. Dat die anderen denken,
oh, zo. En dat een beetje
om te vergelijken met, hey, waar de developers dan
om gevraagd worden van, hey,
hoe zit het nou? Waarom
moet je in je vrije tijd nog werken, zeg maar,
gratis en voor niks?
Maar dat zei jij ook, van, ja, ik ging
ook die
replies, zeg maar, even checken.
Een aantal waren gewoon, denk, oké.
Ja, die waren ontoppen, zeg maar.
Ja.
Nou ja, er zaten ook, op het eerst diegene die ik zag, was ook van,
nou, ja, hoezo? De vergelijking is
niet helemaal oké. Het was al een beetje
mansplaining, werd het al een beetje.
Toen dacht ik, ja, oké.
Nou, van allerlei dingetjes. Maar ik weet niet welke dingen
jou opviel.
Nou ja, wat me vooral inderdaad
opviel, was dat inderdaad alles werd gelijk
weer ontkracht van, ja, dat is niet
zo. En inderdaad, wat je al zei, mansplaining
inderdaad, dat je echt denkt van, gast,
ben je dom of doe je dom?
Ja, precies. En iemand die reageerde,
ook weer van, ja, vervang die arts maar gewoon
met elk beheerdekeurig ander beroep
en het klinkt nog steeds net zo belachelijk.
Ik bedoel, het timmerman, die zit ook niet in
zijn vrije tijd te timmeren, zeg maar.
Ja. En
want het hele idee
van die video van die dame was dat
het eigenlijk best wel raar is
als je een software developer bent,
dat dat dan eigenlijk ook gewoon
het enige en het alles is
wat je doet. Want dat het eigenlijk,
want je ziet het best vaak dat inderdaad software developers
wat hebben die als hobby? Software development.
Ja, denk ik. Terwijl
heel veel andere mensen, die hebben
wel een hobby naast hun werk, was
dan eigenlijk het punt van die video. Dus
waarom zouden software developers dan
dat niet mogen hebben?
Want dat
is natuurlijk ook een beetje de Amerikaanse
cultuur, denk ik dan. Want daar
werk je en dan werk je gewoon helemaal
op het schompus. Want oh jee,
als je de baan kwijt raakt misschien ofzo.
Maar ja,
dan
je zou dan volgens blijkbaar
sommige partijen geen goede software
ontwikkelaar zijn als je daar niet 80 uur per week
mee bezig bent. Ja.
En dat was een beetje het punt dat gemaakt
het. Maar het ging in die hele commentary
het gelijk over
zoveel andere dingen. Ja, nou goed.
Ja, maar ze maakt er wel
een grap over. Ja. En mensen
namen het gewoon echt serieus. Ja.
Ja, maar ook gewoon van,
ook één kritiekpunt was ook van
ja, waarom doe je dan zo'n filmpje?
En waarom doe je dat dan gewoon
met een decolleté in dat ik je BH kan
zien? Ja. Ik denk van ja,
weet je, als zij dat aan wil en
ik weet niet. Ja.
Dat is heel raar, dat je echt denkt
van kijk, als ik gewoon inderdaad gewoon
een iets te diep decolletétje in m'n shirt zou hebben,
dan, nou volgens mij als man moet je dat niet hebben,
geloof ik. Maar in ieder geval, als je in ieder geval zo'n
fitness shirtje aan hebt, dat je gewoon iets te veel
borsthaar kan zien, zeg maar.
Ja. Ja, daar zal
niemand op reageren dan.
En omdat je dan
een vrouw bent en omdat je oh
jee, het komt in de buurt van dat er iets boezem
misschien in beeld zou kunnen zijn,
is het gelijk een issue.
En ook een beetje aansluiten
op wat er al eerder in de podcast gezegd
had ik echt wel zoiets van, ja,
dit is weer echt typisch zo'n voorbeeldje, weet je wel?
Ja, ik brouw nu een beetje
door die commentaren en ja, dat slaat gewoon helemaal nergens op.
Maar ja, het is echt,
maar ook echt binnen
twee minuten ook gewoon dat het gelijk die kant op gaat.
Dat je echt denkt van hoe dan?
Ja, goed.
Ja, het is ook wel gewoon, ja, het is het internet
en het is Twitter.
Dat is sowieso
een mooie brandbielen bij elkaar, of niet?
Ja, het is op zich.
Je kunt er met popcorn een keer naar kijken.
Ik raak dan wel getriggerd
soms. Ik had bijna een reactie gezegd,
want dat ding was al een paar dagen geleden ofzo.
Wat had je willen typen dan?
Is het nog relevant? Nou nee, er was
één Nederlandse, die zei dat haar
collega's iets hadden gezegd,
als ik
als man zei, ook iets over
die decollete.
Als ik die kleren zou draaien, weet ik veel.
Ik had een raar comment en toen wilde ik nog zeggen
en dat is serieus zo.
Toen dacht ik, ja weet je, dat komt niet geloofwaardig over,
laat maar zitten. Maar ik had
dus echt serieus, dat klinkt heel stom
misschien, maar ik had
die decollete nog niet door. Daar stonden
allemaal tekstjes, zeg maar.
Ik zat te lezen, ik had niet eens gezien.
Dus ik zat echt serieus te lezen en ik had haar tweet gelezen.
Toen dacht ik, oké, dus
ik had het filmpje echt denk ik
vier of vijf keer gezien, serieus.
Dat je echt denkt, valt mensen dat op?
Ja, en toen ging ik kijken
en ik, oh ja, maar dat was echt
nou ja, goed blijkbaar, en
als het je dan opvalt, hoezo moet je
er dan een heel ding van, maar goed.
We doen het nu ook weer, heb je een doel?
Ja, inderdaad.
Het is wel
zo, als man kun je
inderdaad gewoon, je kan je spetter
aandoen en een spijkerbroek, en je gaat
lekker op kantoor aan je bureau zitten.
En echt niemand die dat interesseert.
Maar moet je het als vrouw gaan doen? Ja,
dan ben je gelijk onverzorgd en
kleedjes een beetje aan enzo.
Ik heb zulke opmerken wel eens van dichtbij
iemand zien maken naar iemand.
Dat was zoveel jaar geleden, toen was ik echt
nog, als ik dat nu zou zien gebeuren, dan zou ik echt
zeggen, ja gast, doe van normaal.
Gelukkig, er veranderen stap voor stap
veranderen wel dingen, ja, het is dus wel
maar goed, dat hebben we in eerder podcasts ook al gezegd.
Ja, laten we dat niet helemaal weer uitkouwen.
Hey, we gaan naar de
vorige sectie, developer dilemmas.
Oh, ik was er al bang voor.
Ja, we hebben er een
aantal, je mag niet,
ja, je moet kiezen.
Het is een binaire keuze.
Ja, we kunnen het erover hebben,
natuurlijk, maar goed, de eerste,
monolithe versus microservices.
Nou, moet ik eerlijk zeggen,
nou ja, goed, ik heb hier wel een antwoord
voor, maar jij mag eerst.
Ja,
en monolithe neig ik
dan naar? Nou, ik
vind hem lastig. Bernard?
Ja, it depends.
Dit hebben we eerder gehad en dit kom ik bekend voor.
Ja, klopt.
Ja, ik zou het ook zeggen, want het is
mag niet. Ik ben niet.
Ik ben niet van de de
omdat het de hype nu is microservices van
oh ja, dan microservices is de betere.
Er is niet de betere,
zeg maar, en ja,
die je kiest en ik kan heel
goed begrijpen, want de argument
om een monolithe te nemen, ja,
dat is minder complexiteit.
Het grappige is wel,
want kijk, uiteindelijk als je microservices
architectuur neerzet, dat is wel gewoon een samenhangend
geheel en het hele
geheel wat je schrijft kan niet zonder elkaar.
Dus uiteindelijk het
systeem is nog steeds een monolithe, alleen hoe je
het in deelt en waar het draait is misschien iets anders.
Ja, maar goed, het is een
microservices gaat vooral
over het
ja, het deployment aspect, zeg
maar ook, dus dat je het los van
elkaar kan deployen en dat het afgebakende
kleine systeempjes
zijn die onafhankelijk van elkaar kunnen werken.
Dus dat is dan wel anders, zeg maar.
Ja, dat je ook
volgens mij met microservices is nog heel
belangrijk dat je infrastructuur in code uitdrukt,
toch?
Dat is, zeg maar, om het makkelijker
te beheren, zeg maar, om het beheerbaar te houden.
Daar ga je dan wel heen.
Kijk, als je alles met de hand gaat deployen,
ja, dat werkt.
We kunnen steeds spreken van een microservices architectuur,
maar dat is een ander aspect.
Sommige mensen koppelen dat meteen aan
dockercontainers en Kubernetes, zeg maar.
Je kan het ook op PM-niveau doen.
Precies.
Dus dat is
iets anders, zeg maar.
Dus in die zin, ja, ik vind
dat is voor allebei is te zeggen.
Je kunt binnen een grotere oplossing, zeg maar.
Weet ik veel, een 5, 6 systeem.
Dat kan best zijn, dat een systeem een monolith is,
een ander systeem microservices architectuur.
Dus dat kan gewoon, zeg maar.
Het grappige is wel, de app waar je kan
werken is op zich, een app is een monolith.
Dat is per definitie zo.
Maar binnen die app hebben we wel
op framework-niveau,
het zijn een soort modules,
hebben we het wel gewoon als een soort van
micro-framework architectuur opgenomen.
Zodat je dus op
team-niveau en ook op
functioneel niveau kun je gewoon wel
scheidingen leggen. En dat is op zich
qua microservices. En ook micro-frameworks
is dat wel een voordeel, dat je dus inderdaad
van dat je het zo opknipt, zeg maar,
is het heel duidelijk waar de contractuele afspraak
tussen API's liggen.
Dat is niet grijs.
Je gaat je runtime uit
naar een andere runtime toe, dus daar ligt
een contract. En dat is gewoon de API.
En dat is wel
een groot voordeel, denk ik, van
van zo'n systeem, omdat je ze onafhankelijk deploybaar
van elkaar maakt, maar ook onafhankelijk van elkaar
ontwikkelbaar. En dat is
voor wat wij doen.
Is dat wel het grootste voordeel
wat wij nu merken? Want we deployen
nog steeds gewoon als één geheel uploaden naar Apple.
Nou, volgende denk ik.
Ja, zeker.
Mono repo versus
multiple repos.
Echt?
Ook bij microservices?
Ja, daar werk ik nu
natuurlijk niet mee. Microservices
zou je kunnen stellen
van wel, maar ook weer niet.
Ja, dit is een beetje
het voordeel van Mono repo
is dat je het geheel
wat je deploit, het geheel
wat dus een versie is,
dat dat gewoon één plek is, één
tag. Er is gewoon één punt
in tijd op één plek die gewoon
juist is.
En dat is met
multiple repositories is dat natuurlijk niet.
En dat is zelfs
als je bij iOS development
inderdaad een dependency manager gebruikt,
CocoaPods bijvoorbeeld, of er zijn
nog een paar andere.
Je trekt dan eigenlijk gewoon code uit
een andere repository
ergens op het internet.
En dan wordt er in je
logfile, wordt dan wel
de hash van die
commit wordt opgeslagen. Maar
uiteindelijk je beschrijft het op
een tag niveau. En een tag
denken mensen vaak al van
in Git dat dat iets heel erg stabiels is.
Maar dat is niet.
Dat is echt gewoon een
tag. Een tag is alleen maar een label
aan een commit.
We noemen het een tag.
Dus ik ben wel
het voordeel vind ik wel voor iOS development in ieder
geval dat een monorepo dan
de versie die je in je app hebt staan
is op jouw repository ook gewoon één tag.
En die
ik heb ook met my third party dependencies
ook liefst in die repository erbij inzitten.
Ja, maar goed,
dat was de discussie. Die hebben we op ons slack ook
wel een beetje gehad. Dat is van een EK en
ja, branching en weet je,
dan wordt dat feestje wordt wel.
Ja,
misschien wat lastiger, misschien
niet zo induid. Dus
zeker als je echt los
systemen vaker los
van elkaar wil. Nee,
sorry, maar bij microservice zijn die dingen afgebakend.
Er zijn duidelijke contracten tussen die verschillende systemen.
Dus dan zou ik het niet in een micros
of in één
monorepo stoppen
en aparte repos per microservice.
Maar als het een monolithe is en er zijn
meerdere systemen,
meerdere
applicaties, dan kun je
ze wel bij elkaar houden.
Want het wordt soms complexer om dan verschillende
repos te gebruiken
om überhaupt iets te kunnen ontwikkelen.
Je zult iets nodig hebben
wat het samenstellen van je release inderdaad.
Je gaat nog steeds ergens beschrijven van
wat bij elkaar gezocht inderdaad
je hele complete
werkende systeem is.
Wat zat er in die release?
Inclusief alles wat je erin
propt van externe lips,
iets voor pots of...
Oké,
nog twee, denk ik.
Eentje?
Welke wil je?
Volgens mij hebben we die al gehad, die volgende.
En deze wil ik ook doen.
Misschien moeten we geen doen, want ik vind hem niet zo leuk.
hetgeen die we wilde doen was Taps vs. Spaces.
Ja, die kan heel kort.
Het zat me echt...
Nu, wacht even, sorry.
Het was eerst...
Het boeide me echt niet.
Als ik in een team kom en
we zitten met vijf man die andere vier zeggen
we doen Taps, dan zeggen we oké, doen we Taps.
Dus doen we Spaces? Ja, dan doen we Spaces.
Want die IDA's, die zorgen dat het
wel weer goed komt.
En ik hou me gewoon aan wat de rest van
het team als standaard heeft.
Per zelf had ik nooit
een voorkeur.
Wat iemand wel zei is dat als je
Taps gebruikt,
dan heb je de mogelijkheid om te zeggen
oké, in mijn IDA is één Taps
visueel
zijn het vier Spaces.
Of één Spaces. Wat jouw
eigen voorkeur is.
Terwijl het gewoon als karakter is getypt
is het één Taps. Dus dat is wel iets
wat je wel met Taps kunt doen, met Spaces niet.
Want dan moet je al die Spaces gaan vervangen door.
Volgens mij, was dat niet een
discussie van iemand die slechtziend was?
En dat voor hem heel veel uitmaakte als
hij ging oplezen ofzo?
Dan kon hij het echt veel beter zichtbaar maken
als de Taps stonden in plaats van Spaces.
Dat snap ik.
Toch kies ik Spaces voor mezelf
in mijn eigen project.
Ik kies eigenlijk ook altijd wel Spaces.
En het klopt
inderdaad, je IDA
die helpt je wel. En als je echt in een omgeving
komt dat het heel specifiek iets anders is
dan zet ik zelfs mijn accoladen wel
op dezelfde regel in plaats van de volgende.
Ja...
echt...
ik kan er niet zo heel op punt van maken.
Als het maar binnen het team een beetje oké is.
Ja, als het in de CodeBase zelf
maar op één manier gedaan wordt. Anders word ik gek.
Ja, dat wel. Daar heb je wel een punt.
Dat klopt.
Oké.
We hebben blijkbaar, ik weet niet of
dit is wel een tricky ding.
Misschien.
We kunnen nog wat weggeven.
Dat volgens mij wel.
Ja, daarom.
Dus vorige keer hebben we een aantal codes
gekregen voor manningboeken.
Die zijn nog niet allemaal vergeven.
En nou is het grappiger.
Kijk, als het tussen nu en dat gepubliceerd is
dat ze wel vergeven zijn, dan is dit stukje
de rest van de wereld
niet te horen krijgen.
Als het nog niet zo is, dan
blijft dit er mooi in.
Er is sowieso één-één discount
voor 35% korting
op manningboeken.
Die code kun je krijgen
via onze Slack.
Dus dan moet je maar
naar onze Slack komen.
En de andere is
een prijsvraag. Die was in de vorige
aflevering.
En de vraag
was, dan moet ik het even uit mijn hoofd doen,
is in welk
land heeft Pauline geprogrammeerd?
Dat was de vraag.
Gewerkt.
Sorry, sorry.
Het is veel te laat, joh.
Ik ben al helemaal niet meer scherp.
Maar goed, dat dus.
Ja, en als je
een antwoord hebt, dan
kun je één van ons, Kishen, Bernard,
Johnny, Pauline of
mij een DM-tje
sturen en dan
gaan we kijken of je
het juiste antwoord had.
En op tijd, ja, want er zit
nog wel een soort van deadline. Maar goed,
als je te laat bent, dan heb je pech.
Oké,
ja, er is nog één ding.
Ja, we maken ook wel
wat kosten in deze podcast.
Nou is het niet zo dat ik meteen allerlei mensen
vraag om geld te doneren.
Kan, mag, maar dat is niet waar ik op uit ben.
we nemen nu weer,
vanwege corona nemen we online op
en we gebruiken daar
de tool Zencast
ervoor. We worden gesponsord.
En Salves Test Services
die heeft
een donatie gemaakt
zodat wij Zencast
kunnen gebruiken.
Op de kosten van, daar betaalt
Salves voor.
Dat is heel fijn. Shout out naar
Salves.
Ja, dank je wel.
Werkt goed hoor.
Ja, dat gaat.
Ik hoop
dat het nu helemaal vast.
Hoor je mij?
Ja, precies als je de gode verzoekt.
Goed.
Dat was hem weer eigenlijk.
Wil je nog iets zeggen ter afsluiting?
Heb je nog een tip voor
de ruitse knallen?
Of iets anders?
Ja, dat is een hele goeie.
Sorry dat ik je onderbreng.
Ik ga er wel snel overheen, want we doen normaal sproken tips
en boekentipsen. Dus als je een tip hebt,
dan is het...
Dat is voor
de iOS developers dan
een beetje specifiek. Maar er is een podcast
die kun je ook vinden. Dat is de iOS Lead Essentials.
Dat is als je een lead developer
of senior wil worden. Ik denk ook wel
als je sowieso een developer bent.
Dat zijn twee gasten. Dat is echt
supergoed.
Ze zijn wat lastiger te vinden op het internet,
want je komt dan gelijk in hun web
van sales terecht,
zeg maar. Maar dat is
echt een goeie podcast om eens een keer te luisteren.
Als je gewoon eens wat getriggerd
wil worden over
ja, hoe ben je senior?
Hoe help je mensen in je
team bijvoorbeeld verder? Dat is toch
vaak wat heel onderschat wordt. Een lead developer
is over het algemeen wat minder met code bezig,
helaas. Ik vind
ergens wel jammer.
Ik schrijf gelukkig nog steeds meer dan de helft van de tijd code.
Maar een van de hele belangrijke
aspecten van een lead developer is ook dat je
gewoon kijkt wat er binnen je team
rondloopt. En hoe je
eigenlijk die mensen verder kan helpen.
Gewoon als persoon,
maar ook gewoon vooral als developer.
ja, ik streef er altijd
nadat als ik met iemand samenwerk,
ja, tuurlijk, het maakt me wel uit
of ze gaan of dat ze blijven.
Een fijne collega natuurlijk, iemand waar je lang mee wilt samenwerken.
Maar ja,
als ze dan ooit een keer vertrekken, dan hoop ik toch echt
wel dat ze terug kunnen kijken van ja,
ik heb hier zoveel geleerd.
En als dan ook nog mijn naam
erbij onthouden wordt,
dat zou ik echt heel gaaf vinden.
Dat iemand gewoon ook echt met een fijn gevoel
terugdenkt aan het samenwerken
met mij en nou ja, echt dat je samen
dingen gedaan hebt, maar dat je ook
iemand het gevoel hebt gegeven dat ze gewoon
zonder heel erg die maximale
druk erop te hebben, maar dat je wel gewoon de uit
hebt gehaald wat erin zit, zeg maar.
Cool, heb je de URL?
Als je die doorkopt, dan kom je die in de show notes.
Ja, die komt zeker in de show notes.
Ja, oké, dan
komen we later met die URL. Cool.
Ja, ik heb geen tips.
Nee, ik kan alleen bedenken
lees de stripboek The Watchman, maar ja,
dat is altijd een goede tip.
Ja, dat zeker. Die moet je echt lezen.
En de Pregmatic Programmers 20th
Anniversary Edition is ook nog wel goed.
Ik weet niet.
Als ik een junior in mijn team krijg,
dan krijgt hij die cadeau.
Ja, heel goed. Ja,
dat is sowieso wel.
The Watchman, joh.
Ja, je zegt nu The Watchman, joh.
Heb je Providence?
Ken je dat van hem, Alan Moore?
Nee, ben ik ook benieuwd naar.
Die wil ik ook wel, want Alan Moore heeft The Watchman.
Die heb ik nog niet.
Maar Vivo van Dert heeft ook een hem.
Die heb ik allebei, maar die Providence
ben ik nieuwsgierig naar.
Maar die is nieuwe of niet?
Die is heel recent, in de laatste 10 jaar.
Oh, oké.
Ja, ja, ja.
De serie is ook een tip trouwens,
maar dat moet je maar...
Ja, die wil ik eruit zien.
Ja, die moet je echt zien.
Want die is echt heftig.
De film vond ik niet zo goed
als de serie, want
de novel is heel erg goed,
maar de film, ja, het is wel mooi
gefilmd en zo, maar het doet
het verhaal geen recht toe,
vind ik.
Oké, goed.
Genoeg daarover.
Dit was hem weer.
En ja, zoals altijd,
als je niet geabonneerd bent, dan moet je abonneren,
maar ik denk dat als je zover bent gekomen
als nu, dat je denk ik wel al geabonneerd bent.
Dat is gewoon...
En zo leuk is dit gewoon, dat kan niet anders.
Ja,
we zouden het heel leuk vinden
als je nog niet op onze Slack bent geweest,
dat je, ja, kom naar onze Slack, het wordt steeds gezelliger.
Daar is trouwens je roen ook te vinden.
ik denk met iets minder berichtjes nu,
want ik was aan het bijluisteren met alle afleveringen,
dus ik had op elke aflevering
heel veel te merken, geloof ik, qua inhoud
of dat ik nog een discussie opstartte.
Ja, ga dus naar onze site,
codekelets.nl, daar kun je gewoon de links
vinden om te subscriben
met je favoriete podcast-app
of om bij onze Slack te komen.
Dus dat zijn al de links.
Je kunt ons vinden op Twitter
appstaatje codekelets
en LinkedIn.
Dan moet ik trouwens wel een beetje mijn huisweg
weer wat meer doen, om te zorgen
dat we wat meer berichtjes uitdoen.
En een nieuwtje is
dat er ook een
nieuwsbrief gaat aankomen.
Die gaat op de site
zichtbaar zijn, dus de hele tijd dat dit gepublished is
dan staat die link erbij.
Het idee is dat er iedere twee weken
dat er een nieuwsbrief uitkomt, met gewoon
nieuwtjes en
wat interessante links, zeg maar, voor
software-ontwikkelaars. Een klein
beetje duiding en
goed dat je even in een korte tijd
even een aantal nieuwe, interessant
onderwerpen of
GitHub-repositories die nuttig zijn
dat je die even voorgeschoten
krijgt. Even zien hoe dat gaat.
De eerste gaat er
voordat deze
aflevering is, gaat die
eruit.
Of in ieder geval als die beschikbaar is, dan kun je in ieder geval subscribe.
Dat is
het. Meer heb ik niet
te melden.
Ik wil jou nogmaals bedanken, Jeroen.
Graag gedaan.
En
het was top. We gaan trouwens ook jouw podcast.
Je hebt een podcast
die je in de show notes zet.
Mocht je nog
meet-ups hebben of zoiets dergelijks.
Die de komende tijd relevant zijn.
Ja, ik zal ze zeker even melden in de Slack.
Ja, in de Slack is dat sowieso
handig.
Podcast kun je gewoon vinden in je player en zoeken op
AppForce One. Eén aan het einde.
En dan vind je hem wel.
Het getal één. Cool.
Nou, dat was het dan.
Tot de volgende keer. Maar dan weer
het luisteren. Doei, doei.
Doei, doei.