Het is een leuk concept, zo'n zuignapafwasborstel, maar telkens als ik thuis kom ligt hij gewoon in de wasbak; dat kon die oude ook wel.
Seblog.nl
It seems like a lot of people (W, J and H) are cleaning up their <head>
. I always tried to be minimalist in my HTML (and I did meditate back when I build the current version of my site), so my head was actually already rather empty. I did however removed 'add Twitter metadata' from my personal backlog. Feels freeing.
Van de week boostte ik op Mastodon twee toots, over Twitter en over Github, maar zojuist had ik precies diezelfde ervaring op Youtube. Een popupje vertelde me dat ik nu ook posts en videos kan 'delen met mijn publiek' en mijn eerste reactie was: mijn publiek op Youtube, hoezo op Youtube?
Ik hoop dat meer en meer mensen dit blijven hebben. Het is zo'n verademing als die muren weg zijn.
Vanochtend schreef ik over de stress voor de wedstrijd, maar inmiddels weet ik: ik heb gewoon mijn record verpulverd met 1:12:24. Ging goed, heel blij mee.
Zevenheuvelenstress
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.
Muis
In de traditie van bloggen over beesten in mijn kamer, door de jaren heen, hier een nieuwe aflevering: ik had een muis.
Ik hoorde mijn buren al eens smoezen dat er muizen waren. O jee, dacht ik, daar heb ik dus hélemaal geen zin in. Ik negeerde het een beetje omdat ik zelf nergens last van had. Mijn bovenbuurman ging flink aan het schrobben, kon ik horen.
Op een dag kwam ik thuis en zag ik het snoer van mijn staafmixer half uit het keukenkastje hangen. Dat is gek, dacht ik nog, dat zou ik toch nooit zo laten hangen, ik werk vast veel te hard. (Ja.)
Een avond later die week was ik dus weer veel te hard aan het werk tot veel te laat, toen ik opeens iets bij de deur van mijn kantoor zag bewegen. Ik schrok daar een beetje van, maar het schrok ook van mij, en ging er in een dolle vaart vandoor.
Dit was het moment dat ik de connectie naar het keukenkastje maakte: in dat kastje zit achterin een gat naar een stopcontact, voor mijn elektrische fornuis. Toen ik het beter inspecteerde zag ik er inderdaad wat zaagsel liggen, alsof er iemand door dat gat naar binnen was gekomen.
Het punt van het keukenkastje is echter: zodra die dicht is gevallen, kan je als muis in elk geval niet zo makkelijk meer naar buiten via diezelfde weg. En verder zijn hier niet zo veel gaten in de muur, wat waarschijnlijk bijdroeg aan het feit dat ik het muizenprobleem tot nu toe kon negeren.
In die week verdween er inderdaad een hagelslagje dat ik zorgvuldig op een vlek in de vloer had gelegd: de muis was er nog steeds. Toch negeerde ik het nog wat verder, tot ik op een zekere nacht wakker werd van gekraak en geknaag.
Na wat gordijnen op zij te hebben getrokken zag ik hem: de muis zat ín mijn slaapkamer. Dit was vorige week zondag. Wat volgde was een halve nacht op de bank (ben ik veel te lang voor), diverse opruimacties om de muis te vinden, slapen op een luchtbed in een andere kamer, en vooral: de deur dicht houden.
Woensdag kwam de DAR langs, en die hebben ons alles uitgelegd over muizen. 'Als er een potlood in kan kan er een muis door.' Ik met grote ogen. 'Als een potlood past, past een muis,' bleef de muizenman stellig. Zo liepen we een rondje rond het huis en vonden we inderdaad veel gaten.
Ik had dingen te doen in de randstad, dus ik heb mijn spullen gepakt en ben een paar dagen bij mijn ouders gaan logeren. Op de kamer stond een val. Nu ik net thuis ben vond ik daar de muis in. Ik moet toegeven dat ik daar dan weer even bijna van moest huilen: het arme beest, moest hij nou echt dood voor mij?
De muis is opgeruimd, de gaten zijn dicht, er ligt gif in de kruipruimte, het lijkt de goede kant op te gaan. Maar zielig is het wel.
Slome Mastodon
Mastodon is nog steeds een hot-topic op mijn Mastodon- en feedreader-tijdlijn. Zo kwam ik dit artikel van Aral tegen waarin hij uitlegt hoe een beetje populair zijn (22.000 volgers op 3000 servers) en een beetje actief posten en reacties uitlokken al snel kan leiden tot een enorme queue en dus vastzittende instances.
Zijn oplossing: populaire mensen moeten hun eigen server draaien. Ergens is daar wat voor te zeggen, op Twitter waren het ook de populaire mensen die het meeste geld kosten (en opleverden waarschijnlijk maar soit). Het is logisch dat als jij veel interactie hebt, computers daar dus harder voor moeten werken, en dat je dan misschien wat meer moet betalen aan je Mastodon-host.
Maar los van dat computers draaien geld kost, kosten computers ook stroom en dus naar alle waarschijnlijkheid CO². Een beetje minder daarvan zou best fijn zijn, en dit is in mijn optiek wel een beetje een tekortkoming van Activitypub (te actief) en Mastodon (gekke technische keuzes).
Toen Twitter begon bouwden ze het platform op Ruby on Rails, een framework bekend om het gemak waarmee je een nieuwe applicatie kan opzetten, maar niet om z'n snelheid. Twitter liep echter tegen de grenzen aan van die architectuur, met veel plaatjes van een door vogels opgetilde walvis als het weer mis ging. In stapten ze over naar een andere architectuur en kwam er eindelijk een eind aan de 'fail whale'.
In 2016 deed Gargron de eerste commit voor Mastodon. Het zette een lege Ruby on Rails applicatie neer, die later uitgroeide tot de Mastodon die we nu hebben. Als het Twitter niet lukte ermee te schalen, heb ik ook vraagtekens of Mastodon het wel kan.
Maar daarnaast ook Activitypub nogal onnodig werk: op moment van schrijven heb ik drie features van het protocol geïmplementeerd op dit weblog (webfinger, de actor, de inbox) en één keer mijn 'profiel' bezocht via Mastodon.social. Sindsdien heb ik 1507 berichten ontvangen over verwijderde gebruikers. 1507 berichten, alleen omdat iemand anders (oké ik zelf) mijn profiel bezocht. (Ik begon vanochtend al met schrijven aan deze post, maar inmiddels zie ik dat Aaron nog meer deletes heeft ontvangen. Oeps.)
Ik ben een voorstander van 'eerst gebruiken dan pas de protocollen', en aangezien we nu Activitypub gebruiken is dat een beter protocol dan elke nieuwe die we verzinnen zonder actieve gebruikers, maar ergens hoop ik wel dat we dit nog kunnen fixen.
Sinds ik van Henrique een account heb gekregen op zijn Miniflux RSS-reader ben ik weer wat fanatieker aan het lezen en bloggen. Henrique moedigt mij steeds aan om ergens over te bloggen, en ik hem ook. In mijn geval gaat dat natuurlijk nergens over, maar hij komt met uitgebreide analyses van onze nieuwe OV-chipkaart, OVPay, en problemen met DigiD waar hij als Portugees in Nederland tegenaan loopt. Volg en lees.
Poging tot Mastodon
In navolging van velen sinds het aantreden van de nieuwe Oppervogelman ben ik vandaag bezig geweest met 'overstappen' naar Mastodon. In mijn geval betekende dat het opsnorren van mijn oude account, en een zoektocht naar de vraag: hoe werkt dat eigenlijk, Activitypub?
Als achtergrond: Mastodon's mogelijkheid om over meerdere servers heen met elkaar te kunnen praten is niet beperkt tot alleen servers die Mastodon-software draaien. Het is gebouwd op een open standaard die Activitypub heet. Ik heb vandaag een poging gedaan om die een beetje beter te begrijpen.
De volledige uitleg ga ik hier niet geven, want ik ben er ook maar pas net ingedoken. Maar interessante artikelen zijn deze van Eugen Rochko, de maker van Mastodon, en ook de followup ervan. Eugen legt hierin uit hoe je met wat statische bestanden en een beetje Ruby een paar Activitypub-dingen kan doen.
Een van die dingen heb ik toegepast: je kan dit domein nu webfingeren (jaja) en daarmee kan je mijn Activitypub Actor vinden, die weer leidt tot een Activitypub Inbox. Op het moment van schrijven is het er allemaal wel, maar ik beloof niets voor de toekomst, want ik ben er nog niet helemaal over uit of ik dit echt wil.
Het gevolg van het bovenstaande is dat je nu op @seb@seblog.nl
kan zoeken in je favoriete Mastodon-instance, en dat je mij daar dan ziet verschijnen. Je kan daar naar alle waarschijnlijkheid ook op 'Follow' drukken en daar krijg ik dan een melding over. Vervolgens doe ik daar helemaal niets mee, want zo ver ben ik gewoon nog niet.
Ik heb veel horrorverhalen gehoord over Activitypub en ik moet zeggen dat ze deels waar zijn: het is inderdaad behoorlijk veel gedoe allemaal. Om een bericht te accepteren moet je dingen doen met public en private keys, waarvan ik nog steeds denk dat ik het niet helemaal goed doe.
Bovendien ontvang ik sinds ik mijn naam bij Mastodon.social heb ingevoerd allerhande berichten over verwijderde gebruikers. Ik heb nooit om een lijst van alle gebruikers gevraagd, dus ik ben ook niet per se geïnteresseerd in elke verwijderde gebruiker, maar ik ontvang er nu wel bericht over. Ik hoop niet dat elke server in de Fediverse dit gaat doen, want dan ben ik er wel snel klaar mee.
Misschien dat ik morgen nog wat dieper duik, maar zoals gezegd beloof ik niets en verwijder ik de functionaliteit misschien zelfs wel. Het idee is alleen zo vet: met zo veel meer mensen in contact staan via een dergelijk protocol.
Wat verder ook niet onvermeld moet blijven is deze geweldige post over hoe je de verschillende Activitypub specs zou moeten lezen, in welke volgorde en hoe de boel zich tot elkaar verhoudt. Maar dat dus misschien voor morgen. Tot toots.
Ik heb uitgevonden dat ik nog een account op Mastodon had liggen uit 2016. Op dit moment accepteert die instance (Mastodon.social) geen nieuwe gebruikers meer, mede om decentralisatie te promoten, maar misschien ook om de load op de server beheersbaar te houden.
Die instance heeft dan wel een interessant extra 'probleem': als er veel mensen al een account hadden kunnen ze die allemaal activeren, om zo de server het alsnog zwaar te laten hebben. Een Mastodon zombie apocalyps.
Ik heb het een tijdje volgehouden, maar vandaag is het zo ver: ik heb de lader van mijn Apple Watch niet bij me, maar hij is wel leeg. Sinds 16 september heb ik de Series 8 en die draag ik nu ook 's nachts, maar dat betekent dat ik ergens op de dag moet bijladen. Wel 7 hele weken goed gegaan, maar vandaag dus niet.
DHH, met veel gebliepte scheldwoorden: huur je server niet maar, maar koop ze. De cloud is tegenwoordig even complex als het is om je eigen servers te beheren.
Terug naar de reader
De afgelopen jaren ben ik steeds minder actief op Twitter. Ik tel ongeveer 13 tweets dit jaar, 17 tussen nu en 1 november 2021. Ik heb altijd het idee dat ik in een leeg gat praat: de mensen die mij volgen zeggen niets terug en iedereen die ik zelf volg lijkt mij niet te volgen. Ik heb 480 volgers, maar mijn recente tweet kwam niet boven de 50 weergaven.
Nu met de ontwikkelingen rond de nieuwe Oppervogelman vraag ik me af: moet ik wel welke dag zijn app openen en doorscrollen? Dus nu ben ik weer voor de zoveelste keer terug bij een RSS-reader, ditmaal een Miniflux, gehost en mij aangeboden door Henrique.
Op moment van schrijven zit ik op 10 feeds, na dit weekend met 5 te zijn begonnen. Ik heb namelijk wel vaker feedreaders gebruikt, en altijd val ik in dezelfde val:
- ik gebruik geen feedreader
- ik neem er een, volg een paar mensen
- nog steeds erg leeg
- ik volg iedereen die ik maar kan verzinnen
- aaaaaaa
- ik gebruik geen feedreader
Hoewel ik steeds weer tegen Twitter zeg dat ik geen algoritmische tijdlijn wil, wil ik een algoritmische tijdlijn, blijkt keer op keer opnieuw.
Het grote voordeel van een feedreader is echter dat het me indirect aanmoedigt om meer te bloggen. Dit is waarschijnlijk vreemd: de meeste mensen gaan op Twitter omdat je daar makkelijker kan antwoorden. Omdat ik mezelf de regel heb gesteld dat alle antwoorden ook op dit blog moeten verschijnen heb ik reageren op Twitter zó moeilijk gemaakt dat ik het nooit doe.
Enfin, we zien wel waar deze episode eindigt. De vorige is alweer van 2020, zo blijkt. Wie erover schrijft kan terugvinden.
Voor oktober en november is de trailrun challenge van AV Cifla om Strava art te maken. Ik deed mee en maakte dit Melkmeisje van Vermeer.
Using PHPStan to fill Vim's Quickfix list
I am using PHPStan and the ALE plugin to add some error checking to my Vim. It gives red arrows on lines that contain errors in my currently opened files. But sometimes, in a big refactor, I want to know all errors in my project.
Vim has a build-in feature for this: the quickfix list. It is designed to take the error output of a compiler and lets you jump to all those locations with the :cnext
and :cprev
commands. I personally use the essential Unimpaired plugin by the one and only tpope, which maps these to ]q
and [q
.
I use these a lot: the :grep
command fills the quickfix list with all the occurrences of your search, like normal grep but with pagination (or, if you set your grepprg
to something faster: like ripgrep with pagination).
To get PHPStan to fill this quickfix list, I looked for plugins, but they all seemed hairy. I was convinced this should be simple, and it was. The following leader mapping seems to just work:
nmap <leader>pa :cexpr system('vendor/bin/phpstan analyse --no-progress --error-format=raw')<cr>
Customising Git: some things I did
One thing that always puzzled me a bit about my own workflow, is that almost all of it is based in the terminal (I use Vim and Tmux), except for Git: where most people seem to use the Git CLI commands, I use a graphical program (Fork, which is quite good).
Another thing then: I never used Github professionally, apart from the time I was a self employed web developer, but back then I was the only developer on my projects. All my previous jobs had a self-hosted Gitlab running somewhere.
Long story short: I am trying to get better at Git in the terminal and using Github. And 'better at Git' to me both means 'being able to confidently rebase' as well as 'customise my workflow'.
Aliases in the Gitconfig file
Customising Git means setting configuration in the ~/.gitconfig
file. This file contains settings for Git, like your name and email, but can also be used to add aliases. To create the first alias you can run git config --global alias.co checkout
. After this, you can use git co
as git checkout
, which is shorter to type and yes I use this often now.
Another alias I have is this one:
publish = !git push --set-upstream origin $(git symbolic-ref --short HEAD)
If you try to push a branch that has no linked branch on Github (the upstream), Git will complain about it. It will be nice to you and state the command you should have ran, but I got tired of having to copy and paste that new command.
fatal: The current branch feature/new-shoes has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin feature/new-shoes
In Fork, this was just a checkbox away. With my new git publish
command I get the convenience again: it will push the branch and set the upstream with the same name as I have locally, exactly as Git suggested I should have done, but in less typing.
Links to Github
So far we have seen two kinds of aliases: one that just aliases a simple Git command (b = branch
) and one that actually ran a shell command, because we started it with a !
(note that you will have to start with ! git
there). But there is another way: having a command that starts with git-
in your path.
I have the following file as ~/bin/git-github
, marked as executable (chmod +x ~/bin/git-github
) and in my path (export PATH="$HOME/bin:$PATH"
in my ~/.zshrc
file):
#!/bin/zsh
local url
url=$(git remote get-url $(git remote))
url=$(echo $url | sed 's/.*github\.com[:\/]\(.*\).git$/https:\/\/github.com\/\1/')
if [ -n "$1" ]; then
append="/$1/$(git symbolic-ref --short HEAD)"
fi
open -u "$url$append"
Yes, my ZSH is crude. Yes, I can better share this in Bash. Yes, it could've probably been on one line and be included as an alias in my Gitconfig. But it works for me.
The command figures out the Github URL of the project, based on the URL of the remote (it assumes you have only one). It then opens that URL with the macOS open
command. If an argument is given, it appends that to the URL, with the name of the branch too.
In my Gitconfig I have two aliases that use this command:
pr = github pull/new
compare = github compare
With git github
, my default browser will open a tab with the 'homepage' of the repository. With git compare
, it will open a tab that contains a diff of the current branch and the default branch on Github (the remote versions of those). With git pr
, the browser will open the correct page to open a for the current branch.
And you mentioned Vim and Tmux?
Yes, I actually use the obligatory Tim Pope plugin Fugitive. This means I can do a lot of things which you can also read about in the help file. (Which I read a lot these days.)
But this allows me to stage and commit and rebase and reword all my changes in Vim, and then when I am ready, run :G publish
and :G pr
and make a PR for it on Github. These two commands alone make me feel so much more productive: no longer do I have to search for another program to compose commits and then search for the browser to handle the cooperative side of it... I just handle everything in my editor.
For Tmux I have another nice addition: in my ~/.tmux.conf
I have the following command:
bind-key y display-popup -E -h "90%" "git log --oneline --decorate --graph --all"
This will – when I press <prefix> + y
– open a popup window, which closes when the command exits and has a certain height. It will show me an ASCII-art style graph of all the commits – one of the features I missed from Fork – as an overlay over my editor, a small keystroke away.
With this configuration – and a lot of reading the Fugitive help file – I feel much more at home with Git in the terminal.
I also watched this fantastic series on mastering Git and these unfortunately dated but still useful screencasts on Fugitive.