I just discovered a new Vim trick I think I am going to use quite often, so I am sharing it here to look it up when I forget.

As you may know, you can issue the / command in Vim to start a search. Every character you type will be in the search, until you hit enter, which will jump you to the first occurance of your searched text.

Another thing you may know, is that you can use this search-motion as a motion to other commands as well. When you do v/here, you will visually select everything between the current cursor position and the first occurance of 'here' in the buffer. I use this to delete stuff that I can't target using the f and t motions.

Then there is the thing I once found out, but never could remember: once you press /, you are in a little submode I can find the name for. In this mode, you can use Ctrl+L and Ctrl+H to increase or decrease your search string by the characters of the first match. You can also use Ctrl+G to move that virtual cursor to the next match, or Ctrl+T to get to the previous. Once you hit enter you are on that last position, removing the need to do n.

But here it comes: when you are deleting with d/, you can also use Ctrl+G to get to that next match. If you searched for a small snippet that accidentally occurs before the place you wanted to go, you can press Gtrl+G to jump over it, and pressing enter will delete the full distance.

Gisteravond luisterde ik een aflevering van de Remote Ruby podcast met Derek Sivers, waarin hij uit de doeken doet hoe hij alle logica van zijn applicaties in de database zelf stopt, en waarin hij ook zijn persoonlijke database noemt, waarin hij zo'n beetje zijn hele leven vastlegt.

Zijn database staat in interessant contrast met de gebruikers van Obsidian, die juist voor 'plain text' gaan als opslagformaat, in de hoop dat tekst over twintig, vijftig, honderd jaar nog steeds gelezen kan worden door computers. Maar tegelijkertijd staat het óók in interessant contrast met de Ruby on Rails en Laravel developers die alle logica uit de database proberen te houden en de database alleen maar gebruiken voor domme opslag van data.

Het is fijn om af en toe even uit je comfortabele doos te worden gestuurd. Dit weblog slaat alle posts ook op in losse tekstbestanden en op mijn werk werk ik met Laravel en een relatief domme database.

Derek wijst in de aflevering ook op de Simplicity Matters talk van Rich Hickey, wiens talks eigenlijk allemaal heel goed zijn. De talk gaat in op de concepten 'makkelijk' (easy) en 'simpel' (simple), en hoe mensen die twee concepten door elkaar halen terwijl ze fundamenteel andere dingen zijn. Ook voor niet-programmeurs wel een aanrader, denk ik, al moet je af en toe even door wat jargon heen.

Ik ben dus mijn RSS-reader aan het uitmesten en daarbij leerde ik een paar dingetjes over HTML en CSS die ik kon niet wist of kende.

Bijvoorbeeld dat je dus een uitklapbare boomstructuur kan maken met alleen maar HTML en CSS, dus zonder Javascript, door gebruik te maken van <ul> en <li>, met daarin <details> en <summary>. Vooral die laatste twee elementen kende ik niet, weer wat geleerd.

In CSS-land zijn ze kennelijk ook bezig met een nieuwe manier van kleuren uitdrukken, genaamd LCH of oklch. Wie rgb of cmyk gebruikt, specificeert zelf hoeveel licht of inkt er moet worden gebruikt om de kleur te maken. In feite is dat een hele imperatieve manier van een kleur beschrijven. Een meer declaratieve manier is hsl, waarbij je je kleur beschrijft in termen van tint, verzadiging en helderheid. Deze methode heeft echter nog steeds een directe vertaling naar rgb en is dus een 'leaky abstraction'. De lch is een abstractie die rekening houdt met welke kleuren wij als mensen kunnen waarnemen, en maakt berekeningen met kleuren ('deze kleur maar dan iets donkerder') veel makkelijker.

Verder kwam Hidde met een leuke manier om flexbox te gebruiken voor data-visualisatie.

Er zijn een paar gevleugelde uitspraken die ik vaak gebruik op werk (zoals '500 is nooit het goede antwoord') en dit software-cliché is waarschijnlijk de aanvoerder op die lijst:

There are only two hard problems in computer science: naming things, cache invalidation and off-by-one errors.

Vooral omdat het waar is: dingen een naam geven is moeilijk, en zonder namen zijn het eigenlijk alleen maar berekeningen zonder betekenis. Er valt pas geld te verdienen als er betekenis – en dus waarde – aan die getallen zitten.

Maar nu las ik een stukje van ntietz, waarin i signaleert dat beschrijvende namen voor stukken code problematisch zijn. De OrderCreateService maakt waarschijnlijk een order aan, maar zodra hij ook mails gaat sturen naar de klant, moet het dan niet de OrderCreateAndEmailSendService zijn? Succes met overal in je codebase de naam van de service aanpassen.

In plaats daarvan, zegt ntietz, moeten namen vooral leuk zijn (mijn vertaling). Diens belangrijkste punt: namen zijn een manier om identiteit uit te drukken, niet om te beschrijven. Het artikel noemt verder geen voorbeelden, maar in mijn hoofd heb ik nu een service genaamd Truus die de orders aanmaakt. De e-mail? 'O ja, die stuurt Truus.'

Ik denk niet dat ik mijn collega's overtuigd krijg, maar ik vind het een geweldig idee.

De afgelopen weken ben ik bezig met vegan kaas uitproberen. Aanvankelijk zag ik het als project om een lange blogpost over te schrijven, waarin ik alle opties die op de markt zijn op een rijtje zet, maar gaandeweg is die afgezwakt tot deze blogpost, waarin ik zeg: het is wennen, maar daarna goed te doen.

Ik eet al een paar jaar (vijf? zes?) geen vlees meer: een lang verhaal waarin een McDonalds op 50 meter naast mijn huis oppopt, en een weggegeven fiets werd omgezet in een avond in een restaurant waar ik het beste – en dus laatste – vlees ooit heb gegeten. Maar de belangrijkste reden is denk ik dat ik mezelf hypocriet vond dat ik wel vlees at als ik het niet herkende, maar niet als er nog bot aan zat.

Al een tijdje ben ik ook wat aan het zuivel-minderen, en de 'zuivel is niet zo zuiver als we denken' reclames maken dat ik daar nog net weer iets bewuster op let. Ik koop nu zelf geen kaas meer voor op brood, maar dat was ergens wel een gemis, want wat doe je er ander op? Ik ben fan van hagelslag maar alles heeft grenzen.

De vegan kaas biedt uitkomst. Vaak zijn deze kazen op kokos-basis, lijkt het, en hoewel dat je dat in het begin ook erg goed proeft, merk ik dat het me nu nauwelijks nog opvalt en dat ik het gewoon zie als een plak kaas.

Mijn trainingsplan om aan vegan kaas te wennen, wat stiekem ongeveer mijn eigen pad is: eet eerst een maand geen kaas. Koop daarna de vegan komijnenkaas van de Albert Heijn. Omdat de komijn extra smaak geeft en daarmee de specifieke vegan-smaak verhult, is dit misschien wel een goede start.

Probeer vervolgens eens de pittige smeltkaas van WildWestland. Ik heb hem zelf niet gesmolten, maar ik heb inmiddels een tosti-ijzer, dus als hij weer eens voorradig is ga ik dat zeker proberen.

Probeer daarna de Violife kazen. Er is een 'normale' en een Goudse variant, die ik in die volgorde heb geprobeerd. Volgens mij zijn dit hele prima kazen. Op dit punt in het proces kon ik al bijna niet meer beoordelen of dit nu écht zo goed naar kaas smaakte, of dat ik gewoon aan vegan kaas gewend was.

Ik heb net ook nog de Albert Heijn huismerk Goudse kaas geprobeerd en die was ook oké. Mijn stelling hierin is: ja, het is een ander smaakje, zoals ook soya-yoghurt en havermelk net een ander smaakje hebben, maar daar kan je aan wennen en als je er eenmaal aan gewend bent zijn ze heel lekker. Dat is het bespaarde dierenleed wel waard.

Ik speel sinds 2013 Go, 'het oudste bordspel ter wereld', en was er altijd trots op dat ik al speelde vóór de computer zo sterk werd dat geen mens er meer van kan winnen. Niet dat ik ooit van 'de computer' heb kunnen winnen: in 2013 was dat al alleen voorbehouden aan de sterkste spelers.

Een ander feitje over Go dat ik graag herhaal, is dat het meer bordposities heeft dan schaken. Bla bla, de computer won al van de mens met schaken in 1977, en dan noem ik het aantal atomen in het zichtbare universum, alsof ik weet waar ik het over heb.

Maar met grote verbazing las ik dus net in NRC dat er een ander spel is dat nóg meer bordposities heeft en waar de computer het nóg moeilijker mee had. Door de bordposities, door het aantal mogelijke begin-opstellingen, én door het feit dat de tegenstander niet weet waar de stukken staan. We hebben het over Stratego, wie had dat gedacht.

Zometeen is de start van de Zevenheuvelenloop en hoewel ik weet dat ik er gewoon van moet genieten ben ik behoorlijk zenuwachtig en onzeker. Mijn huidige record is 1:15:10, die liep ik in 2017. Daarna heb ik hem in 2019 nog eens gelopen in 1:22:04. Het idee is dat ik hem deze keer weer rond de 1 uur en 15 minuten zou kunnen lopen.

Maar de zenuwen zitten er dan nu in dat het, als ik dat wil, vandaag wel moet gebeuren. Het is behoorlijk kouder dan de afgelopen tijd, en het gaat waarschijnlijk vanmiddag nog regenen ook. Ik ben nu een beetje aan het samenstellen wat ik aan moet tijdens de wedstrijd, maar waarschijnlijk ga ik net te veel aan hebben omdat ik niet te weinig aan wil hebben.

En dan de training. Het ging echt heel erg goed, met meerdere keren per week een rondje, maar de afgelopen twee weken heb ik het helemaal laten versloffen. Zo voelt het, maar aan de andere kant kan je dit 'taperen' noemen en dan is het precies het juiste. Maar heb ik wel genoeg gegeten in de afgelopen week? Drink ik vandaag genoeg of net te veel? Allemaal onzekerheden.

Een paar weken geleden droomde ik dat ik naar een hardloopwedstrijd had moeten gaan, maar dat ik niet ging, omdat het niet meer ging, omdat ik niets meer gedaan had in de weken ervoor. Ik droomde de zelfsabotage die ik nu een beetje voel dat ik weer aan het doen ben. Je kan ook zeggen dat het druk was op werk.

Enfin, het plan ligt klaar, het horloge aan de oplader, de kleren hier naast me op de bank. Als het echt niet gaat gelden er twee regels: hou je vorm goed, geniet van de tocht.

In mijn post van vorig weekend wilde ik niet toegeven dat de requests die Mastdon naar mijn inbox stuurde helemaal niet door mijn eigen verificatie-code heen kwamen.

Het stappenplan is als volgt: Mastodon stuurt een bericht naar mijn inbox, stuurt daarbij een HTTP-header met daarin een keyId, een signature en een lijstje aan namen van headers. Ik moet dan de waardes van de HTTP-headers bij de namen zoeken, de keyId ophalen (dit is een URL) en dan verifiëren of de signature van de headers inderdaad ondertekend is met de public key uit de keyId. Omdat het cryptografie is gaf de functie alleen maar false terug, zonder enige verder info.

Na heel veel zoeken bleek dat in elk geval de deletes een simpele verklaring hadden: zodra de Actor is verwijderd is ook de public key weg, en dus valt er niets te verifyen. Dat is geen bug, zeggen ze. Ik negeer nu lekker alle Actor-deletes want ik haal toch geen profielen op. Follows en Follow-Undo's die ik als test bleef doen bleven wel falen.

Na letterlijk uren te hebben doorgebracht met specs zoeken en code lezen uit Pixelfed (PHP Laravel) en Pleroma (Elixir), bleef ik er toch echt van overtuigd dat ik alles goed berekende, aan elkaar knoopte, ophaalde, alles. Heel frustrerend.

Maar, wat bleek: de (request-target) vulde ik aan als (request-target) /inbox, terwijl ik mijn inbox op /activitypub/inbox had neergezet. De andere implementaties plakten die path dynamisch op uit de Request/conn. Daar ging 6 uur waarin ik al heel veel verder kon zijn geweest met Activitypub. Maar goed, volgend weekend weer een weekend.