Digging the Digital

Vol Blogdrift!

github

Scratching an itch met setlist.fm

door Leave a Comment

Eén van de principes van het indieweb is “scratching your own itch“, als je iets nodig hebt voor je site of je project, dan kun je altijd proberen het zelf te maken. Vandaag merkte ik weer wat een goed gevoel dat kan geven.

Setlist informatie

Ik ben bezig met een artikel voor Chordify.net over de aanstaande tour van Eddie Vedder. Wat ik er inhoudelijk ga schrijven, dat vertel ik nog niet. Want ik weet dat eigenlijk nog niet. Maar voor een gedachtengang in een paragraaf wilde ik weten hoeveel unieke nummers Vedder heeft gespeeld bij zijn vorige shows in Amsterdam.

Op Setlist.fm is alle informatie te vinden en een lijst met alle nummers had ik zo gevonden. Maar niet alleen voor Amsterdam en niet geordend op frequentie. Jammer.

Gelukkig heeft de service een API, die best goed is gedocumenteerd. Dus na het aanmaken van een API-sleutel kon ik aan de slag. Ik wist al ongeveer hoe ik het wilde aanpakken en via de app Postman kon ik de eerste output krijgen van de API.

Code op Github

Met nog wat NodeJS kennis onder de flanken ging ik verder. Na een uurtje of wat proberen en verschillende routes proberen kreeg ik een redelijk goede output. In elk geval voldoende voor mijn artikel.

Nu zou het zonde zijn om die code voor mezelf te houden. Waarom kunnen anderen er niet mee spelen en er misschien wat beters van maken? Of uitbreiden met meer mogelijkheden? Dus je kunt het ieniemienie script nu downloaden op Github. Ik heb het een beetje opgeschoond en beveiligd, zodat je in elk geval je eigen API key moet gebruiken.

Je kunt in het script zelf de opties aanpassen voor je zoekopdracht. Zoals de naam van de artiest, landcode, stad en jaartal. Maar er zijn meer mogelijkheden die je zelf mag ontdekken.

Maak je zelf iets beters van dit script? Deel het via de Github repo! Dan ga ik weer verder om het artikel te schrijven 🙂

Gaat Github Facebook achterna met hun monopolie voor open source software?

door Leave a Comment

GitHub and it’s monopoly on Open Source door Jeena Jeena (jeena.net)

History repeating

Jeena beschrijft het duidelijk in zijn blogpost:
"I guess GitHub right now is like Facebook was in 2012, everybody is on it, it’s a super vibrant community, it’s backed by a huge amount of money, it locks you in (at least with wiki, issues, URLs).

And my second guess is that it will also do what Facebook does, it will get out of control by trying to monetize on its monopoly."

Het juiste zijpad kiezen

door Leave a Comment

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:

  1. Ik ga de open source scripts zelf omschrijven naar een manier waarop andere git-servers dan alleen Github wordt ondersteund
  2. 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.

Hoe ik steeds leer met git en Github

door Leave a Comment

Dit blog is mede ontstaan omdat ik beter wilde begrijpen hoe het versiebeheersysteem Git en de bekende dienst Github werken. Door de jaren heen en na veel proberen en testen begin ik inmiddels wel te begrijpen wat de belangrijkste manieren zijn om met git te werken. Afgelopen week belandde ik in een situatie waar ik niet dacht dat het versiebeheer me zou kunnen helpen. Toch is dat gebeurd en het is de moeite waard om hier de uitleg te geven. Hopelijk kunnen anderen er zo in de toekomst weer profijt van hebben.

Let op: Wat nu volgt is een wat technisch verhaal over de werking van het git versiebeheer.

De situatie

Toen ik met dit blog begon schreef ik alles vanaf mijn laptop in tekstbestanden. Die bestanden staan op één centrale plaats op mijn laptop en als de blogpost lokaal klaar is, stuur ik hem naar Github met een paar commando’s.
Daar bouwt Github Pages de website op en presenteert hem. Dat is wat je hier en nu ziet.

De afgelopen maanden zijn de mogelijkheden toegenomen om dit blog vanaf andere plaatsen te updaten. Zo kan ik steeds eenvoudiger via mijn iPhone een update schrijven en publiceren met de app Editorial, even zo goed als ik dat via een Firefox extensie Omnibear kan doen. Hiermee benader ik de huidige situatie van moderne blogsystemen zoals WordPress, waar je op verschillende manieren een post op je blog kunt zetten.

Er is echter een groot verschil tussen WordPress en mijn systeem. Bij WordPress staat alles op één centrale plaats in een database, ergens op een server ergens op het internet. In mijn situatie is de centrale plaats Github, waar alle blogposts in Markdown zijn opgeslagen. Maar die centrale plaats is niet altijd gesynchroniseerd met mijn lokale versie van deze site. Nu kan zich de volgende situatie voordoen:

  • Ik schrijf een blogpost via de Omnibear extensie.
  • Deze wordt op Github opgeslagen en de site wordt opnieuw opgebouwd en gegenereerd.
  • Vervolgens schrijf ik iets via mijn laptop en ik synchroniseer dat met Github.
  • De site wordt weer opnieuw opgebouwd en gepresenteerd.
  • Maar op de een of andere manier wordt de eerste post dan verwijderd, inclusief de geschiedenis die Github normaal opslaat in de commit-history.

Kort gezegd, als ik er niet voor zorg dat telefoon, web en laptop in sync blijven, dan bestaat de kans dat blogposts ineens verdwijnen. Dat is vreemd.

De test

Ik vroeg me af of dit niet is op te lossen. Immers, Git en Github zijn onder andere een soort oneindige stroom van updates in een bestandsysteem, waarbij die updates nauwkeurig worden gedocumenteerd. Het zou toch mogelijk moeten zijn om de verloren gewaande updates terug te vinden en weer in mijn blog te plaatsen? Of er zou een andere manier moeten zijn om dit te voorkomen? Wat een nog betere en meer duurzame oplossing zou zijn.

Ik besloot op een testserver te situatie te reconstrueren. Al snel kwam ik daar een op dat moment voor mij onbekende melding tegen toen ik de fout wilde nabootsen. Ik kon niet zomaar de online versie van de repository overschrijven omdat git dat tegenhield.

Ik kreeg een melding dat mijn lokale versie van het testblog achterliep met de live versie. Ergens zit er dus een check in het git-beheersysteem wat dit in de gaten houdt. En ergens heb ik dat dus weten te overschrijven met mijn eigen blog…

De oplossing

Een van de beste bronnen om snel te leren over specifieke prorgammeertalen is Stack Overflow. Zo leerde ik dat er zoiets bestaat als een dry-run voor veel git commando’s. Hiermee kan ik een commando gesimuleerd uitvoeren. En zó kwam ik er achter dat om een of andere reden ik ooit ergens had ingesteld dat de posts die ik vanaf mijn laptop stuur altijd naar de live server kunnen, zonder de check of de live-versie niet voorloopt op mijn lokale systeem.

Na wat verder speuren kwam ik terecht bij een blogpost uit 2012 die mij ooit hielp in de begindagen van dit blog. Ik was nog niet zo thuis in git en Jekyll en ik wist eerlijk gezegd niet precies hoe het allemaal werkte. Brett Terpstra is een slimme man en als hij een oplossing geeft voor een probleem wat ik dacht te hebben, dan volg ik die oplossing.

Maar nu blijkt zijn oplossing ten eerste niet nodig te zijn. Github en Jekyll zijn inmiddels veel verder geëvolueerd. Ik hoef geen synchronisatie te doen tussen de master branch en de gh-pages branch. Ten tweede geeft de oplossing onverwachte bij-effecten die ik destijds niet had kunnen voorzien.

Ik hoefde slechts één regel in een configuratiebestand te verwijderen en als het goed is werkt alles nu weer naar behoren.

De vervolgstappen

Op een zondagmiddag heb ik weer een hoop geleerd over git en de principes van versiebeheer. Hoe meer ik er van leer, hoe meer ik me verwonder over de mogelijkheden van dit versiebeheer, hoe flexibel het is en tegelijk hoe oplettend je moet zijn op wat je doet. Mocht je ergens een fout maken dan is er vaak een manier om het terug te draaien. Maar het is prettiger om vooraf goed na te denken wat je waar en wanneer doet. Dat maakt het werken met git een stuk prettiger.

Ik wil nu op mijn laptop een script plaatsen wat periodiek checkt of de online versie van mijn weblog-repo synchroon is met de lokale versie. Zo niet, dan moet de lokale versie worden geupdate.
Tevens begin ik meer de kriebels te krijgen dat dit blog op een server draait bij Github. Er is niets mis met Github en het is fijn dat alles gewoon draait. Maar tegelijk zou ik toch wat makkelijker op de server willen rondkijken wat er allemaal gebeurt, de verschillende bouwstenen van dit blog (micropub, webmentions etcetera) beter bij elkaar houden en net wat meer controle hebben over de server zelf.

Genoeg nieuwe klussen voor deze hobbyblog!

Github’s reflog – Git Tips – Medium

door Leave a Comment

Het nadeel van alles zelf in elkaar willen knutselen is dat er soms scenario’s zijn waar je niet over hebt nagedacht. Zoals een post doen via een Firefox plugin, die wordt via Github op mijn site geplaatst en gepubliceerd. Als ik echter daarna via mijn laptop een post doe, dan wordt de geschiedenis op Github op de een of andere manier overschreven. En zijn de oudere posts weg. Nu heb ik dankzij deze uitleg wel de posts van dit weekend terug weten te vinden. Vanavond ga ik eens op mijn gemak bekijken hoe ik dat kan voorkomen…

Mocht deze post vanavond weer weg zijn, excuses! Ik leer vanalles over dat indieweb!

In de trein testen

door 4 Comments

Test vijf hoor jongens: Terwijl Ton Zijlstra en ik onderweg zijn in de trein vanuit Nurnberg naar Utrecht kijken we de livestream van de demo’s die tijdens de IndieWebCamp zijn geproduceerd. Tegelijkertijd kreeg ik een melding dat het eerdergenoemde script om webmentions te sturen is geupdate naar een nieuwe versie naar aanleiding van mijn opmerking in de Github repository. Dus nu is de ultieme test. Ik stuur deze blogpost inclusief wederom een link naar de Webmention testtool. En ik ben benieuwd wat er gaat gebeuren….

Update: Het werkt! Hoera! Check de bovenstaande blogpost van Ton en je ziet mijn blogpost daar als reactie staan. Dát zijn dus webmentions. Ik kan nu reageren op blogposts met een eigen blogpost. Dit is wat ik echt voor elkaar wilde krijgen met deze IndieWebCamp en dat is me dus gelukt. Al is het in de trein op de terugweg en kost het me mijn EU maandbundel van T-Mobile. Maar ik ben een blij ei nu! Ik vier het meteen met een Bitburger!

Bitte ein bit