Ik ben het helemaal eens met Marco. Ik heb Dave Winer erg hoog zitten, het is een van de OG bloggers. Maar sinds een aantal maanden zijn de korte posts in zijn RSS feed minder interessant voor me. Ik mis zijn overpeinzingen over software, het web. Ik heb geen behoefte aan journo-politieke polarisatie in mijn reader. Dave Winer zeurt af en toe een beetje. Dramt door. Is gepikeerd als hij wordt tegengesproken. Misschien wordt hij gewoon een dagje ouder…
Aantal Facebook gebruikers in Nederland daalt
Vandaag maakt Newcom bekend dat het aantal Nederlandse Facebookgebruikers daalt. En fors. Zo’n 640.000 gebruikers minder, aldus het AD vandaag.
6% daling in een jaar tijd. Dat is best flink te noemen. Het zou nog interessanter zijn om te zien wanneer deze dalingen inzetten. Bijvoorbeeld na het Cambridge Analytica schandaal en de oproep van onder andere Arjen Lubach? Of is het omdat jongeren afscheid nemen van het platform en zich richten op Instagram en andere nieuwe online plekken?
Nieuwe online oase’s
Tegelijkertijd stijgt inderdaad het aantal Instagram gebruikers, evenals voor Whatsapp. Je kunt er vergif op innemen dat de advertentiedruk op deze platforms zal toenemen om te blijven voldoen aan de druk van aandeelhouders en groei binnen het concern. Wat dit voor gevolgen heeft de komende jaren is afwachten. Zuckerberg heeft al te kennen gegeven dat hij de chat-functionaliteiten op de drie platformen interoperabel wil maken. Met je Instagram account kun je dan iemand op Whatsapp of Facebook messenger bereiken. Enorm handig en het biedt natuurlijk mogelijkheden voor adverteerders om multi-platform bereikbaar te blijven zonder overhead in beheer, configuratie en accounts.
Het is vanuit een commercieel oogpunt begrijpelijk dat Facebook BV besluit om deze interoperabiliteit binnen de eigen blauwe muren te houden. Kijkend naar het open web en de keuzevrijheid die we als consument zo graag willen, dan zou Facebook net zo goed het Activitypub protocol kunnen omarmen. Een technisch protocol wat exact hetzelfde doet, maar tegelijkertijd een veel breder ecosysteem van platformen, apps en mogelijkheden openstelt.
Maar ja, dan is het gevaar dat Facebook gebruikers andere online oase’s ontdekken waar vrienden en netwerken zitten, waar meer waarde is te vinden dan op Facebook zelf. Met alle gevolgen van dien.
Dansende banaan
De daling van Facebook is ingezet door het falende beleid van het netwerk zelf. De daling kan volgens mij doorgezet worden als alternatieven en nieuwe initiatieven bereikbaar en beschikbaar komen voor een groter publiek. Op dit moment zijn allerlei Indieweb en Decentrale Web projecten té technisch van aard en vereisen ze een te groot offer in tijd en energie voor de dagelijkse online consument om mee te starten. Niet in de minste plaats vanwege het argument “maar al mijn vrienden zitten op…”. Dat is een lastig maar geen onmogelijk argument. Er was een tijd dat we collectief op Hyves elkaar dansende bananen stuurden of pijn aan je retina kreeg van de MySpace layouts.
Ik geloof dat die tijd weer kan komen. Niet per sé van de dansende bananen (al zou dat wel leuk zijn) maar wel een breder en divers landschap van platformen en ecosystemen. Waar we elkaar kunnen vinden, met elkaar kunnen communiceren en waar niet pertinent een derde partij allerlei data van ons nodig heeft óm met elkaar te kunnen communiceren.
Laten we dat gaan doen.
Photo by Patrick Tomasso on Unsplash
Blinkenlights
Ik kende het niet, maar deze artifact uit de computergeschiedenis is heerlijk. De Blinkenlights. Voortgekomen uit de tekst die in veel computerlokalen was te vinden:
“Achtung!
Alles turisten und nonteknischen lookenpeepers!
Das komputermaschine ist nicht für der gefingerpoken und mittengraben! Oderwise ist easy to schnappen der springenwerk, blowenfusen und poppencorken mit spitzensparken.
Ist nicht für gewerken bei dummkopfen. Der rubbernecken sightseeren keepen das cottonpicken händer in das pockets muss.
Zo relaxen und watschen der blinkenlichten.”
Lees over de geschiedenis op Wikipedia
Het juiste zijpad kiezen
Ken je dat gevoel? Je bent lekker op weg met een project, het gaat de goede kant op. De hobbels die je onderweg tegenkwam heb je weten te overwinnen. Sommigen heb je nog even links laten liggen tot een later moment. Je denk dat het allemaal goed gaat.
En dan gaat het toch niet goed.
Dat overkwam mij de afgelopen dagen met de verhuizing van mijn blog. Mijn doel (lees hier en hier meer) is om dit blog nog meer zelfvoorzienend te maken. Nog minder afhankelijkheid van derde partijen en (wo)men in the middle. Dat doel zou een losse server zijn, waar ik zelf de software op installeer, zelf de scripts onderhoud, zelf de boel koppel aan mijn lokale bestanden en zorg dat alles netjes draait.
Helaas mag het niet zo zijn. Op dit moment zijn er beperkingen omdat ik dit blog gratis onderbreng bij Github Pages. Een puike plek en het werkt prima met Github. Maar helaas zorgen de technologische beperkingen dat ik allerlei omwegen moet bedenken en maken om mijn groeiende archief goed te beheren. Een simpel voorbeeld zijn de tags en tagpagina’s. Omdat Github Pages geen Jekyll plugins ondersteunt die dit snel en efficient kunnen realiseren, moet ik het met een omweg doen. Dat lukt wel, maar het is foutgevoelig en de opbouwtijd van de site gaat er enorm op achteruit.
Na de verhuisupdate van eind vorige week ben ik best wat verder gekomen. Ik heb het voor elkaar om een blog op een server te draaien zoals ik wil. Zonder tussenkomst van Github, met versiebeheer op de server zelf en met een snelle bouw- en laadtijd. Hiervoor ben ik afgestapt van de kant-en-klare bouwpakketten die Digital Ocean aanbiedt, zoals een server met Ruby en Rails al geïnstalleerd. Dat bracht weer andere beperkingen met zich mee. Ik heb uiteindelijk een losse server genomen, daar zelf Ruby en alle nodige pakketten op geïnstalleerd (wat vooral héél veel wachttijd is) en toen draaide alles als een zonnetje. Zoals ik wil.
Maar natuurlijk kwam hier weer een kink in de kabel. Ik ga proberen het niet té technisch te maken (succes Frankie…)
Eén van de interessante ontwikkelingen in het Indieweb is de ontwikkeling van Micropub. Dit is een protocol dat het mogelijk maakt om met diverse schrijfcliënts te posten op je eigen site. Het is een open protocol in tegenstelling tot bijvoorbeeld WordPress of Medium. Wat MicroPub doet is datgene wat jij ergens schrijft (bijvoorbeeld in Quill of Micropublish.net) in een algemeen format aanbieden bij je site, waarna de software van je site er mee kan doen wat nodig is.
Veel van de kant-en-klare scripts en open source apps die dit mogelijk maken op je eigen site, maken gebruik van de koppeling met Github. Eigenlijk doen ze dat allemaal wel. En laat ik die nu net hebben ontkoppeld. Dus dan kan ik twee richtingen op:
- Ik ga de open source scripts zelf omschrijven naar een manier waarop andere git-servers dan alleen Github wordt ondersteund
- Ik kies weer voor een koppeling met Github en ga op zoek hoe ik zonder gebruik van Github Pages mijn site kan hosten. Want dan heb ik meer vrijheid in Jekyll plugins en minder hoepels.
Ik heb twee dagen mijn tanden stuk gebeten op de eerste mogelijkheid. Maar mijn beperkte kennis van zowel de interne werking van git als van programmeertalen als Node of Ruby gaven me hoofdpijn. De hoeveelheid nieuwe kennis die op me afkomt is overweldigend. Enorm interessant, maar tegelijkertijd een stap te ver voor me. Ik wil graag bijdragen aan open source projecten en nieuwe mogelijkheden verkennen. Maar ik ben geen programmeur pur sang en heb niet de ambitie om allerlei randgevallen, unieke usecases en updatevraagstukken te gaan ondersteunen.
Dus heb ik een stapje terug gedaan. Ik kies er voor om de broncode van deze site bij Github onder te brengen. Maar de uiteindelijke site, waar je dit leest, die moet ergens anders worden ondergebracht. Dat brengt me weer op een volgende zoektocht. Ga ik dat doen via diensten als Travis CI, of kies ik voor een oplossing als Netlify? Of een van de vele andere statische site hosting oplossingen? En wat heeft dat voor gevolgen?
Soms vraag ik me wel eens af waarom ik het mezelf zo moeilijk maak. Maar goed, het blijft een hobby. Soort van.
Verhuisupdate
Ik ben bezig om deze site naar een nieuwe server te verhuizen. Een korte update na een dagje werken met allerlei commando’s, Stack Overflow lezen en Digital Ocean handleidingen volgen:
- Ik heb in elk geval een subdomein van dit domein naar een server bij Digital Ocean weten te wijzen.
- Op die server is Ruby al voorgeïnstalleerd, zodat de blogsoftware Jekyll zijn werk kan doen.
- Tevens heb ik op de server git geïnstalleerd, de versiebeheer software om nieuwe posts en andere updates te doen en te administreren.
- Ik kan met een account via SSH inloggen op de server vanaf mijn laptop.
- Ik heb lokaal een test repository gemaakt waarmee ik updates kan sturen naar de server via git. Ik kan dus zonder gebruik te maken van diensten als Github of Gitlab direct updates sturen naar de server.
Dat laatste is wel een behoorlijke overwinning voor me. In het afgelopen jaar heb ik veel geleerd over git en ik was me al langer bewust dat ik niet per se iets als Github hoef te gebruiken. Er is niets mis mee, maar het is een extra stap als ik nieuwe artikelen wil plaatsen. Als backup voor de code is het een prima oplossing natuurlijk.
De manier om dit mogelijk te maken is door op de server git te activeren en een kale git-repository te maken. Op mijn laptop verander ik de git-remote
URL’s naar het adres van de git repository op mijn server. De hobbel die ik hier nog tegenkwam is het gebruik van SSH keys. Hiermee kun je zonder wachtwoorden en op een veilige(r) manier communiceren met servers. Maar het vereist wel een nauwkeurige installatie en configuratie.
Vastlopers
Er zijn echter een paar zaken waar ik steeds hopeloos vastloop.
- De webserver nginx en apache zijn beiden geïnstalleerd. Ik wil het liefste nginx gebruiken, maar als ik de server herstart is apache weer actief. Dat moet ik nog uitzoeken.
- Zoals gezegd, ik kan updates van de lokale repo naar de server sturen. Daarna moet de site echter wel worden gebouwd door Jekyll. Dit lukt nog niet.
- Dit komt omdat ik ergens iets fout doe in het toewijzen van lees- en schrijfrechten van gebruikers op de server. Hoe ik dit moet oplossen, dat weet ik nog niet.
- Jekyll draait op Ruby. Voor Ruby heb je een zogenaamde versie-manager, RVM. Daarnaast is er nog een programma genaamd Bundler om allerlei plugins voor Jekyll te installeren. Zowel Bundler als RVM krijg ik niet goed aan de praat om netjes alles te installeren en te updaten. Hier lijk ik eveneens vast te lopen in een conflict tussen gebruikersrechten. Kort gezegd, als ik bijvoorbeeld
bundle -v
doe, krijg ik een ander resultaat dansudo bundle -v
(1.16.1 versus 2.0.1). Maar om die twee gelijk te trekken, dat lukt me dus niet. - Veelal zijn er problemen in het $PATH op de server. Dit is eveneens een concept wat ik nog onvoldoende in de smiezen heb om zelf veranderingen in aan te brengen en te snappen wat ik doe.
Ik ben op weg, maar het is nog een hobbelig pad, zonder duidelijke richtingsaanwijzers en de lokale inwoners spreken een taal die ik niet helemaal snap. Zo voelt het sinds een paar uur. Het begon goed, maar sinds ik op het punt ben om Ruby en Jekyll aan de praat te krijgen, loopt het krakend vast.
Ik hoop dit weekend nog wat tijd er aan te kunnen besteden. Al zal die tijd eerst zitten in nieuwe handleidingen en uitleg over gebruikers, groepen en rechten op Linux systemen.
Verhuizing in de planning
Het plan voor vandaag is om een serieuze stap te zetten in het verhuizen van dit blog. Sinds het begin wordt deze blog gehost op Github Pages. Een mooie, handige en gratis plek om een blog te hosten. Helaas zitten er beperkingen aan. Mijn blogmachine Jekyll heeft veel plugins en scripts die het leven makkelijker maken.
Helaas ondersteunt Github deze niet en kan ik ze niet gebruiken. Het meest in het oog springend is de mogelijkheid om tagpagina’s te ondersteunen. Ik had een workaround maar die was al snel weer stuk.
Dus vandaag ga ik allerlei losse aantekeningen op een rij leggen om de boel op een server te krijgen bij Digital Ocean. Waar mogelijk zal ik updates geven hoe ik alles doe. Sowieso voor mezelf om in de toekomst nog eens goed te kunnen lachen om al dat knullige Devops gedoe. Maar mocht iemand dezelfde stap willen zetten, dan is er in elk geval één Nederlandstalige handleiding.