Oe! Hip!

Soms wordt er in werk situaties een soort rollenspel gespeeld waarbij de acteurs zich niet bewust zijn van hun negatieve rol. In sommige gevallen kan je in dat rollenspel een Drama Driehoek herkennen. De drama driehoek stamt uit de transactionele analyse en beschrijft gedrag waardoor communicatie en samenwerking sterk belemmerd worden. De drie rollen die in het model worden benoemd zijn: Aanklager, Redder en Slachtoffer. Deze negatieven rollen houden daarbij elkaar instant, en wisselen elkaar ook af.

Omdat XS4ALL wordt geintergreerd in KPN en omdat senior developers niet uitwisselbaar bleken begeef ik mij meer op LinkedIn en heb ik op mijn profiel ingesteld dat ik beschikbaar ben voor werk. Ik wist al van te voren dat ik rekening moest houden met veel berichten. Alleen de kwaliteit van de berichten viel mij regelmatig tegen. Een groot deel van die berichten doen pijn aan mijn ogen omdat de berichten alleen af gaan op één woord uit mijn profiel: PHP en geschreven lijken door een schoolverlater.

Bij het lezen over Domain Driven Design (DDD), kom je op een gegeven moment de naam Alberto Brandolini tegen. Hij is bekend als ‘uitvinder’ van Event Storming. Event storming kun je zien als een soort taal met ‘sticky notes’ waarmee je complexe systemen gezamelijk kunt modelleren. Wil je daar meer over weten dan kan ik je zijn boek aanraden. (het boek is alleen nog niet af) Maar als je zoekt op zijn naam zul je zien dat hij ook bekend is om: “The bullshit asymmetry”.

Onlangs kreeg ik de kans om mee te doen met een brainstorm sessie bij een mooie start-up. Het doel was om samen met twee andere software ontwikkelaars van gedachten te wisselen om te kijken of er ergens aanknopingspunten zouden zijn om verder onderzoek te doen naar een probleem wat een tijdje speelde. Na wat praten over elementen, services en systemen, heb ik mijn Miro board gedeeld en ben ik gaan modelleren via de Event Storming technieken van –Alberto Brandolini.

Lichten aan Klep open Vierkante lamp op de knoppen en in mijn oogen Bestekken pakken drogen en bakken Fluitend water tappen thee Lichten uit Typen meeting typen Lichten aan Klep dicht knoppen weg Bestekken borden potten pannen pakken Vuur Prikken bakken Choco en port Bestekken borden potten pannen rekken hangen Klep dicht Lichten uit Oogen sluit

Zien Ik kon altijd overal zien En mijn gezien werdt ook gezag Maar bij dichtbij zag ik het niet meer Dus verzonnen ze verziend En mijn toekomst voorzach een ziender voor er bij Door de ziender zag ik helder Ik kon weer kijken hoe ik kook Daarom ook stop ik mijn ziender in een koker Dat maakt mijn ziender helder Zelf meer dan ik kon voorzien En nu zie ik elke dag zoals ik zag

Gochme Gochme dat is zo’n woord wat je bijna niet hoort Je hebt het of je hebt het niet In talkshow’s op tv, een soort radio met beeld Daar wordt het weleens toebedeeld aan voetballers En dan zijn ze het meestal niet eens met elkaar Tenzij het een dood icoon betreft, dan wordt er instemmend geknikt Hmm ja dat kan je wel zeggen ja, maar wat er bedoeld wordt blijft raadselachtig

De handlers Een webserver handler heeft als parameters altijd een writer en een request object. Func blablaHandler(w httpResponceWriter, r *http.Request) { text := r.FormValue("v") if text == "" { http.Errorf(w,"missing value") return } fmt.Fprintln(w, text +" "+ text) } In de handler wordt het request gelezen. En het resultaat van de blabla handler funktie wordt via de Fprintln weggeschreven in de Writer Als in bovenstaande handler in het request “kletsen” als waarde wordt meegegeven, wordt in de writer “kletsen kletsen” geschreven.

Go testing Binnen een dir met go files mag je maar èèn package hebben. Daarop is èèn uitzondering en dat heeft te maken met het testen van je code. Want, om het mogelijk te maken om alleen de buitenkant a.k.a. de interface van je code te testen, mag je in een dir met go-files en packagename oehip ook package oehip_test maken. In het package oehip_test kan je dan de buiten kant van de oehip code testen net als of jij je eigen library gebruikt.