25 mei Involved @ Techorama 2021
Techorama 2021, dit keer een virtuele editie, zit er weeral op. Een aantal Involved collega’s hebben zich weer laten inspireren door het grote aanbod aan technische sessies rond thema’s als .NET, JavaScript, Cloud en vele andere.
Stef, Ante, Viktor en Johnny nemen je graag even mee terug naar de presentaties die het meeste impact hadden op hen.
Stef @ “An exception occurred… Please try again”
Zoals gewoonlijk zijn er op Techorama zeer veel interessante sprekers. Toch is er één die er voor mij écht uitsprong: de sessie van Laila Bougria genaamd “An exception occurred… Please try again”.
Deze sessie ging over iets waar we vaak niet genoeg bij stilstaan: foutafhandeling. Het is iets wat veel impact kan hebben op de gebruiksvriendelijkheid van je applicatie. Zo kan het er voor zorgen dat je eindgebruiker al snel naar andere software zal gaan zoeken als er iets fout loopt dat niet goed werd afgehandeld. Daarom is het dus van groot belang om ervoor te zorgen dat een mislukte actie opnieuw wordt uitgevoerd. Loopt er dan toch nog iets mis, dan moet je de nodige gegevens opslaan om de fout achteraf te kunnen onderzoeken. Het is hoe dan ook belangrijk dat de gebruiker zo snel mogelijk verder geholpen wordt.
Er werden een aantal tools besproken die je kunnen helpen bij het ontwikkelen van een correcte foutafhandeling. De eerste was Polly en deze zorgt ervoor dat bepaalde operaties automatisch opnieuw geprobeerd worden. Dit kan direct na de fout of na een vastgezette tijd. Eigenlijk automatiseert dit dus hetgeen we als IT’er vaak zeggen: kan je het eens opnieuw proberen?
Een ander framework waarover gesproken werd was NServiceBus. NServiceBus helpt ons om via een “message-based”-architectuur te werken (software patroon). Ik had er zelf wel al eens van gehoord maar nog nooit mee gewerkt. Het was dus heel handig om te zien hoe krachtig dit framework is in het opnieuw verzenden van berichten en het opslaan of doorsturen van berichten die falen.
Mijn conclusie is dus dat ik zeker eens ga proberen werken met beide tools in toekomstige projecten. Jij ook?
Ante @ “Plain Text”
Dit jaar heb ik mijn eerst Techorama bijgewoond, jammer genoeg was deze digitaal, maar ik kijk er zeker al naar uit om er volgend jaar in levende lijve bij te zijn. Er was een zeer groot aanbod aan technische presentaties over de nieuwste technologieën maar er was toch één niet zo technische presentatie die mijn aandacht trok: “Plain Text” door Dylan Beattie.
Er zijn zo veel verschillende talen in de wereld, sommige zelfs met hun eigen alfabet, en toch is het zeer gemakkelijk om informatie te delen over het internet. Wat betekent de term “plain text” precies? Iedereen heeft wel eens gehoord van ASCII en Unicode maar weten we ook waarom ze zo belangrijk zijn? Al deze vragen, en meer, werden door Dylan behandeld!
Je zou verbaasd zijn van de hoeveelheid verborgen context in onze dagdagelijkse communicatie. En dan heb ik het niet alleen over non-verbale communicatie, maar ook om de context waarin onze woorden zich uitdrukken. Neem bijvoorbeeld volgend handgebaar: ✌. Vandaag de dag krijg je hiermee 2 pintjes op café maar in de tijd van de Romeinen zou je 5 pintjes krijgen. Of neem nu het volgende, kan jij het resultaat verklaren?
"Т" == "T" => false
Het eerste symbool is de Cyrillische voorstelling van de letter T en het tweede symbool is de Latijnse voorstelling van de letter T.
Nu is het duidelijk dat beide verschillende karakters zijn en dus niet aan elkaar gelijk zijn. Of toch? Voor een computer is het verschil heel duidelijk, maar voor mensen hebben beide karakters dezelfde betekenis, dezelfde uitspraak en zien ze er volledig hetzelfde uit. Hoe stel je regels op over hoe je iets moet vergelijken als je niet eens weet wat je aan het vergelijken bent? Men zegt vaak: “een beeld zegt meer dan een duizend woorden”, en dat ik precies hoe we onze taal vandaag de dag uitbreiden. Met emojis kunnen we ons uitdrukken op een volledig nieuwe manier, weet jij welke film dit is? (🦁👑)
Gelukkig zorgt Unicode ervoor dat software developers niet wakker moeten liggen van hoe al deze verschillende karakters beheerd moeten worden.
Viktor @ “Build software like a bag of marbles, not a castle of LEGO®”
Toen de agenda van Techorama gepubliceerd werd was mijn goesting meteen getriggerd door “Build software like a bag of marbles, not a castle of LEGO®”.
Als junior in de .NET-wereld is software-architectuur vaak een heuse doolhof. Software-architectuur is dan ook geen exacte wetenschap en er bestaan geen regels over hoe het wel of niet moet. Iedere Software architect of Software developer heeft zijn eigen manier van werken gebaseerd op eigen aangeleerde ervaringen en smaak. Hierdoor wordt het concept van een architectuur opzetten heel interessant maar ook heel moeilijk om “de juiste weg te vinden”. Om enkele paden te verlichten tijdens deze zoektocht zijn er meerdere principes neergeschreven waar een codebase aan zou moeten voldoen.
Zelfs met deze principes, bijvoorbeeld SOLID, zijn er nog vele andere manieren om een goede structuur op te bouwen. Gelukkig voor ons zijn er al gekende structuren gepubliceerd waar wij onze architectuur op kunnen baseren. Een van deze structuren is Onion-Architecture. Omdat Onion-Architecture, of het meer hippe “Clean-Architecture”, naar mijn smaak het dichtst aanleunt bij de SOLID-principes en de mogelijkheid naar scalability had ik mezelf al aangeleerd waar je deze kan toepassen en wat de voordelen hiervan zijn. Deze presentatie van Hannes Lowette was een toepassing op de deze Onion-Architecture waarbij het doel was om een plugin-structuur te ontwikkelen die loosely-coupled is aan de softwarearchitectuur met alle uitdagingen die erbij horen. Als een losse plugin aan een codebase gehangen moet worden moet de core van deze applicatie overweg kunnen met deze dynamische plugins. Hier werd dan ook opnieuw de meerwaarde van contracten via interfaces duidelijk en hoe deze tijdens het compileren van een applicatie worden gebruikt.
Een andere uitdaging die boven kwam drijven was: “Hoe ga je om met Entity Framework Core en Entity Framework Core Migrations?”. Stel dat je plugin zijn eigen migraties en (een deel van) een DBContext bevat, hoe kan je hier dan mee omgaan? Tijdens de sessie werd er een oplossing voorgesteld waarin je de migraties zou kunnen vervangen via het FluentMigrator framework en hoe je Entity Framework Core kan “manipuleren” om meerdere DBContexten als één te zien.
Deze presentatie heeft mijn ogen opnieuw geopend: software-architectuur kan veel verder gaan dan enkel een structuur volgen en geeft me energie om hiermee meer te gaan experimenteren!
Johnny @ “Building resilient microservice applications with Dapr”
Ik ben al vele jaren enthousiast over containers en gedistribueerde applicaties. De komst van containers binnen softwareontwikkeling heeft mijn programmeer-leven heel wat eenvoudiger gemaakt. Ik hoef me niet meer zo druk te maken over de verschillende omgevingen waarop mijn applicatie gedeployed moet worden en welke fysieke computer-architectuur of besturingsystemen er gebruikt gaan worden. Als mijn applicatie kan draaien in een container en als de deployment-omgeving overweg kan met deze containers zal alles wel in zijn plooi vallen.
Maar wat als de applicatie die je ontwikkeld bestaat uit meerdere kleinere applicaties die met elkaar moeten samenwerken? Noem het een gedistribueerde applicatie of zelfs een micro-services applicatie. Hoe zal de communicatie tussen de containers dan verlopen? Welke infrastructuur zal er gebruikt worden? HTTP? Messaging? Wat als er iets misgaat in één service en de andere services daardoor niet verder kunnen?
Ik had de term Dapr al vaak horen vallen, maar had me nog nooit verdiept in het doel van de technologie. Dankzij deze presentatie van Jakob Ehn heb ik genoeg inspiratie gekregen om deze zomer zelf aan de slag te gaan met Dapr.
Dapr is een verzameling van technologieën die je kunnen helpen om je services in een gedistribueerde of micro-services applicatie te laten samenwerken. Je hoeft geen grote hoeveelheden code te schrijven om alle services aan elkaar te hangen via verschillende communicatie technologieën en protocollen. Dapr voorziet een uniforme API in jouw programmeertaal naar keuze en zal achter de schermen gebruik kunnen maken van al deze verschillende vormen van communicatie: HTTP, REST, Message Queues, gRPC, … Dit alles wordt mogelijk gemaakt door een apart proces dat naast je eigen service zal worden opgestart. Dit proces wordt de Dapr SideCar genoemd. Maak je gebruik van containers of zelfs container-orchestratie zoals Kubernetes? Geen paniek! De Dapr SideCar kan tijdens deployment automatisch geïnjecteerd worden in je container of in je Kubernetes Pod. Op deze manier blijft je code eenvoudig te schrijven en te lezen, maar kan je wel gebruik maken van geavanceerde technieken voor inter-service communicatie en meer.