Liberating Structures - een introductie

Dit artikel is eerder gepubliceerd op de website van Team Rockstars IT.

Je loopt de eerste meeting van de dag uit en je bent er eigenlijk al weer klaar mee. Je voelt je leeglopen bij de gedachte aan een dag vol meetings, meetings die allemaal net zo beroerd verlopen als deze eerste. Het begon er al mee dat opnieuw niet duidelijk was wat het doel van de meeting was. Een aantal mensen die duidelijk niet uitgenodigd hadden moeten worden, waren wel aanwezig, wat de sfeer er niet beter op maakte. Ondertussen waren collega’s die wel iets wezenlijks hadden kunnen bijdragen, juist niet uitgenodigd. Precies na een uur kwam er eindelijk schot in de zaak: de conclusie was dat de meeting herpland moet worden, maar dan met de juiste mensen en een duidelijke agenda.

Klinkt dit bekend? Heb je ook het gevoel dat vergaderingen vaak hun doel voorbijschieten? Gelukkig zijn er manieren om dit soort frustrerende situaties te voorkomen. Lees dan verder om te ontdekken hoe Liberating Structures kunnen helpen meetings om te vormen tot productieve en betrokken sessies waarin iedereen effectief kan bijdragen.

De business of onze business? Hoe ons taalgebruik kan bijdragen aan meer verbinding en minder polarisatie in organisaties

Taalgebruik. Iets waar we te weinig over nadenken. De taal die je gebruikt kan, bewust of onbewust, je gedachtes, gevoelens en zelfs je motivatie beinvloeden. Het kan uit elkaar drijven of juist voor verbinding zorgen. Het verschil tussen het gebruik van “de” of “onze”, in de uitspraak “de business” of “onze business”, je zou er een compleet boek over kunnen schrijven. Benieuwd hoe je met het juiste taalgebruik kunt bijdragen aan meer verbinding en minder polarisatie in de ‘us vs them’-discussie? Lees mijn artikel nu en ontdek hoe subtiele veranderingen in taalgebruik het verschil kunnen maken.

Architectuur design met het C4-model

Dit artikel werd eerder gepubliceerd in het SDN Magazine.

Samenwerken. Dialoog. Conversatie. Elk boek over softwareontwikkeling besteed er aandacht aan. Het is misschien wel het belangrijkste middel om succesvol software te ontwikkelen. Of het nu gaat over domeinen, specificaties of architectuur, uiteindelijk moet er een ondubbelzinnig beeld ontstaan van het te ontwikkelen software systeem. Ook bij het ontwerpen van de architectuur is de dialoog belangrijk. Het is daarbij van belang dat alle betrokkenen begrijpen hoe de architectuur van het softwaresysteem er uit ziet.

Groeien door fouten te maken

Soms krijg je bij een coachingsgesprek ineens een pareltje voorgeschoteld. Vorige week had ik een coachingsgesprek met een junior ontwikkelaar en het eerste dat ter sprake kwam was dat hij voor het eerst een fout had veroorzaakt op een productieomgeving. Waarop ik, zonder er over na te denken, meteen zei: “gefeliciteerd”. We hebben er even over doorgepraat en ik heb uitgelegd waarom ik hem feliciteerde. Uiteindelijk is dat het volgende verhaal geworden.

Een monoliet? Nee, dat hebben wij niet meer!

De monoliet wordt vaak gezien als een anti-pattern en er wordt veel aandacht besteed aan het opsplitsen van monolithische applicaties naar microservices. Meestal gaat het hier over de applicatie-monoliet, maar er andere varianten van de monoliet die, onterecht, minder aandacht krijgen. In dit artikel laat ik een aantal van deze varianten de revue passeren, toon hoe deze monolieten er uit zien en waarom ze meer aandacht verdienen.

Externe REST services aanroepen met Refit

Dit artikel werd eerder gepubliceerd in het SDN Magazine.

Je kunt je bijna geen applicatie meer voorstellen die geen gebruik maakt van externe gegevens. Vaak komt deze data uit REST Api’s¹. Als developer kan het behoorlijk saai zijn om de zoveelste API te moeten ontsluiten maar gelukkig zijn er mogelijkheden om dit een stuk eenvoudiger te maken. Één van die opties is het gebruik van Refit².

Om te laten zien hoe je met behulp van Refit² een API aan kunt roepen gebruik ik een een voorbeeeld API met een 5-tal methodes. De voorbeeldcode is ook beschikbaar op GitHub³. De API ziet er zo uit:

Diagrammen maken met Mermaid

Steeds weer kom ik Mermaid tegen als het gaat om het maken van diagrammen. Persoonlijk werk ik graag met (Plant)uml maar meestal moet ik diagrammen dan exporteren naar een afbeelding voordat ik het in de documentatie kan gebruiken.

Microsoft DevOps heeft ondertussen ondersteuning voor Mermaid, Github heeft nu ondersteuning voor Mermaid en aangezien dat twee platformen zijn die ik veelvuldig gebruik lijkt het me tijd om me eens te gaan verdiepen in Mermaid.