• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Digging the Digital

Vol Blogdrift!

  • /Now
  • Nieuw? Start hier
    • Blogroll
    • Tag Index
  • Startgids Mastodon
  • WordPress en Indieweb
    • WordPress en het indieweb
    • Hoe gebruik je IndieAuth met WordPress
    • WordPress en webmentions
    • WordPress en Micropub
    • WordPress en de Post Kind plugin
  • Notities
  • Bookmarks
  • Likes

nodejs

Scratching an itch met setlist.fm

1 June 2019 door Frank Meeuwsen 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 🙂

Opgeslagen onder: webtech Tags: code, github, itdoesntgeteddievedderthanthis, nodejs, setlist

Public Folder, host je website lokaal en bij Amazon.

5 June 2018 door Frank Meeuwsen Leave a Comment

Ik was vanochtend eigenlijk op zoek in mijn Programma’s map of ik nog een offline RSS-lezer had. Zover kwam ik niet, want mijn oog viel op het programma PublicFolder. Ik wist eerst even niet wat het was maar nadat ik het opende zag ik al snel dat het een projectje van Dave Winer was. Een relatief kleine NodeJS applicatie die als losstaand programma kan fungeren. Wat doet het? Het fungeert als een soort privé Dropbox. Als het programma is gestart kun je bestanden in een zelf gekozen map plaatsen. Vervolgens, na wat configuratie, gaat PublicFolder deze bestanden automatisch kopieren naar Amazon S3, een online opslagplaats (Simple Storage Service)voor vanalles en nog wat.

Op Amazon S3 kun je instellen dat een specifieke map als website beschikbaar is. Zo kun je dus heel snel en eenvoudig een website hosten die je lokaal beheert. Deze website staat volledig lokaal op mijn laptop, en ik schrijf alle blogposts lokaal. Als ik tevreden ben kan ik met 1 druk nu de site via Github online zetten. Maar in de toekomst zou ik dat dus net zo makkelijk bij Amazon S3 kunnen doen. Ik betaal dan alleen voor de schijfruimte die ik daadwerkelijk gebruik en de site blijft razendsnel beschikbaar. Met de mogelijke veranderingen bij Github kan het geen kwaad om de alternatieven eens te bekijken voor de hosting van mijn site.

De code van PublicFolder is vrij in te zien op Github en Dave Winer heeft op zijn eigen traditionele manier de how-to geschreven die eigenlijk net te weinig informatie geven. Je moet dus zelf wat knutselen. Mijn belangrijkste tip: Zet in het config-bestand je S3Folder tussen slashes. Dus niet

"s3Folder": "publicfolderfm"

maar

"s3Folder": "/publicfolderfm/",

Oh en je kunt deze site als (voorlopige) mirror eveneens op deze prachtige URL vinden. Extern geladen afbeeldingen doen het niet, maar verder werkt alles prima! Ik moet deze stappen nog doorlopen om er een domein aan te plakken, dat volgt later wel. Als een snelle test in plusminus 10 minuten vind ik dit best geslaagd…

Opgeslagen onder: webtech Tags: bloggen, cheatsheet, code, nodejs

72 regels code als oplossing

28 April 2018 door Frank Meeuwsen 4 Comments

Een van de principes in het Indieweb-denken is “selfdogfood”, het idee dat je bouwt wat je zelf nodig hebt en gebruikt wat je zelf bouwt. Dit in tegenstelling tot de vele diensten die het werk uit handen nemen in de vorm van plugins, betaalde SaaS oplossingen of software waarvan je eigenlijk niet exact weet wat er achter de schermen gebeurt.

Mijn eigen vertaling van dit principe is om te proberen eigen oplossingen te bedenken voor relatief kleine vraagstukken. Als die dan leiden tot de goedkeuring van de godfather of blogging, dan is mijn week al weer goed!

Bouw op wat er al is

Vorige week beschreef ik het proces hoe ik een eigen oplossing wilde maken om op dit blog links te delen zonder de overhead van het maken van een complete blogpost in een editor. Het zou bijna zo eenvoudig moeten zijn als het delen van een link op Twitter. Om het geheugen nog eens op te frissen, mijn idee bestaat uit vier stappen:

  1. Ik deel iets op Pinboard of Inoreader met een speciale tag en tekst
  2. Op een eigen server hou ik deze RSS feeds bij
  3. Als er een nieuw item verschijnt in de feeds, zorg ik dat deze omgezet wordt in een artikel voor dit blog
  4. Op gezette tijden publiceer ik automatisch een nieuw link-item op dit blog.

Stap 1 had ik al in orde, stap 2 en 3 kan ik eveneens afvinken nu! Sinds gisteren heb ik werkende code op Github staan die voortborduurt op de ideeën van de vorige post. Het interessante van het complete proces is dat de hoeveelheid code die ik zelf heb geschreven minder is geworden omdat een hoop van het harde werk is verdwenen achter de schermen. Ik schreef vorige week al:

Dus ga ik dan toch overstag en hack ik mijn eigen ideeën in de DaveReader of ga ik nog even door met mijn eigen oplossing?

Ik ben uiteindelijk overstag gegaan. Omdat het simpelweg de beste oplossing was. Ik kwam er al puzzelend achter dat ik in de vorige versie van dit script veel werk reproduceerde wat al aanwezig was in de broncode van de DaveReader package. Toen ik een avond wat zat te spelen met de River5 code van Winer, waar de genoemde reader in zit, vielen er ineens wat puzzelstukjes op hun plek. River5 is een consumentenproduct volgens Dave, al durf ik dat wel tegen te spreken. Het is niet een app die je even installeert en it just works. Echter, als ontwikkelplatform is het best interessant kwam ik achter. River 5 is een simpele River of news applicatie, waar je nieuwe blogposts en ander nieuws als een stroom voorbij ziet komen. Inderdaad, zoals Twitter en Facebook werken, maar dan in eigen beheer en met bronnen die je zelf in beheer hebt. Zie hier een voorbeeld.

De applicatie komt met een aantal ingebouwde mogelijkheden om zelf iets te kunnen doen met nieuwe items die vanuit een RSS feed binnenkomen. In de code van de reader zit een voorbeeld van Dave, waar binnenkomende items in een feed lokaal worden opgeslagen in JSON formaat. Toen vielen er plots wat puzzelstukjes in elkaar.

72 regels code

Ik bedacht me dat ik de River 5 applicatie prima kan gebruiken zonder de webinterface die je hierboven ziet. In de River 5 applicatie zit eigenlijk alles wat ik nodig heb:

  • Het kan de feeds opslaan die ik wil bijhouden voor mijn links
  • Het kan periodiek de laatste items ophalen
  • Het heeft ingebouwde functies om iets met die nieuwe items te doen

Zoals Dave al zegt in zijn tweet en blogpost, ik gebruik River 5 niet als product, maar als API voor RSS feeds.

Zo’n helder moment zorgt er dan voor dat ik binnen een avond de code kon maken die doet wat ik wil. Ik hergebruikte oudere code om het Markdown template te vullen, dat had ik eerder deze week al als losse functie geschreven en getest. Ik wist alleen nog niet wáár in de logica ik het moest gebruiken. Nu vielen in een paar uur alle stukjes in elkaar. De 72 regels code die je hier ziet zijn niet op die ene avond geschreven. Maar het is het voorlopige eindpunt van een week puzzelen, proberen, leren en fouten maken. Ze doen het dubbele dan de 75 regels van een week eerder en ze hebben me weer meer geleerd waarom bepaalde code iets doet.

Volgende stappen

Inmiddels werkt de code en worden er templates weggeschreven met links die ik nog eens wil delen op mijn blog. Nu is het tijd voor twee nieuwe vraagstukken:

  1. Kan ik een Node JS applicatie draaien op dezelfde server als mijn blog?
  2. Hoe ga ik er voor zorgen dat de concept-posts daadwerkelijk op gezette tijden worden gepost en welke logica ga ik hiervoor gebruiken?

Voor beiden ben ik al iets verder in mijn denken dan alleen de vraag stellen.

Node op Github

Mijn blog draait op Github Pages. Dit is gratis webruimte die je krijgt bij een Github account. Heel mooi en prima om een compleet statische blog op te draaien. Maar Github Pages komt begrijpelijk met een aantal beperkingen. Zo kun je er niet alle plugins gebruiken die in de Jekyll-community aanwezig zijn. En het is niet mogelijk om een NodeJS applicatie permanent te laten draaien op de server. Nu kan ik twee kanten op, ik zet het Node script op een andere server bij Digital Ocean, waar ik eveneens mijn statistieken onderbreng en ik zorg voor een koppeling tussen die server en Github Pages. Of ik ga alles bij Digital Ocean onderbrengen.

De keuze valt logischerwijs op de laatste. Het is eenvoudiger om alles op één locatie te hebben in mijn optiek, al betekent dat wel weer een nieuw project. De migratie naar Digital Ocean.

Logica

Voor mijn tweede vraag, hoe zorg ik dat concept-posts netjes over de dag heen worden gepubliceerd, daar ben ik nog niet helemaal zeker van. Als ik het goed begrijp kan Jekyll de concepten op het juiste moment publiceren als de datum in de post in de toekomst ligt (de zogenaamde frontmatter). Ik heb dat echter nog niet goed genoeg getest om er zeker van te zijn dat het zo werkt. Ik kan dan concepten maken met een datum en tijdstempel die steeds verder in de toekomst ligt.
Een ander scenario is om concept-posts te maken zonder datum en tijd en door middel van een cronjob op de server steeds de oudste post te kiezen, de datum in de frontmatter te herschrijven naar de huidige datum en tijd en dan te publiceren.
Kortom: Zit de publicatie-logica bij het opslaan van het concept of bij het publiceren van het concept?

Beiden zijn volgens mij valide wegen die naar het einddoel gaan, de vraag is welke weg de minste beren heeft. Ik vermoed de laatste, omdat ik dan geen routine hoef te schrijven om steeds een datum in de toekomst te selecteren. Een cronjob is relatief eenvoudig te schrijven met sites als Crontab Guru, waarna ik me alleen maar hoef te concentreren op het kopieren van een bestaand bestand naar een andere map en het vervangen van de datum in dat bestand. Dat hoeft niet heel lastig te zijn.

Conclusies

Een paar eerste conclusies na deze eerste stappen in de wereld van NodeJS:

  • Het is geen enorm moeilijke taal. Omdat het Javascript is, waar ik al wat eerdere ervaring mee heb, kan ik relatief makkelijk instappen en de code lezen.
  • Voor mij nieuwe concepten als asynchrone en synchrone functies, promises en callbacks zijn nog lastig te doorgronden. Ik maak soms wat leaps of faith in mijn code en ik vertrouw er op dat het klopt wat ik doe
  • Wat ik interessant vind in mijn leercurve is dat ik van een behoorlijke berg code uiteindelijk weer ben teruggegaan naar het uitbesteden van relevante stappen in mijn project. Het ophalen van de feed en het bepalen wat er moet gebeuren als er iets nieuws binnen is gekomen, dat bestaat al. De creativiteit zit in wát er moet gebeuren.
  • Aan de zijlijn van dit ontwikkeltraject heb ik ontdekt dat ik nog veel heb te leren over het opzetten van een goede ontwikkelomgeving. Met software, plugins en instrumenten die het ontwikkelen en testen van scripts een stuk eenvoudiger maken. Daar mag ik nog wel meer tijd en onderzoek aan besteden.

Binnenkort meer over dit nieuwe avontuur wat weer is gestart!

Opgeslagen onder: webtech Tags: cheatsheet, code, creativiteit, github, indieweb, nodejs, pinboard

Hoe ik mijn eigen oplossingen maak met code en doorzettingsvermogen.

20 April 2018 door Frank Meeuwsen 1 Comment

De afgelopen dagen ben ik wat aan het knutselen geraakt met de programmeertaal NodeJS. Bij Olisto wordt vrijwel alles in deze taal geschreven en recent had ik de behoefte om een intern hulpmiddel voor onze helpdesk wat te verbeteren. Omdat al onze ontwikkelaars druk bezig zijn met de app zelf, besloot ik de mouwen op te stropen en zelf aan de slag te gaan. Met een doorklik-abonnement op Stack Overflow ben ik behoorlijk ver gekomen wat er weer toe leidde dat ik een lang gekoesterde wens voor deze blog toch eens aan wil pakken…

Waarschuwing vooraf: In het vervolg van deze blogpost komen veel afkortingen, programmeertermen en jargon voorbij. Mocht je het niet allemaal snappen, Duck Duck Go is je vriend!

Linkdump al de links!

Vanaf de begindagen van mijn blogcarrière heb ik de (eigenwijze?) behoefte om allerlei sites, artikelen en andere links te delen op mijn blog. Op mijn eerste blog Punkey.com waren de blogposts vaak niet langer dan een gemiddelde tweet en door de jaren heen heb ik altijd wel een blog gehad waar ik vanalles deelde. In plaats van het schrijven van langere blogposts zoals deze, deelde ik liever wat ik zoal tegenkwam.

Je bent wat je deelt.

Echter, met dit huidige blog doemde er nieuwe uitdagingen. Ik kom op allerlei plaatsen boeiende links tegen en dat zorgt voor het probleem waar ik het centraal kan opslaan. Daar zou deze blog natuurlijk ideaal voor zijn, volgens de Indieweb-gedachte. Ik heb al sinds jaren een Pinboard account, daar moet ik toch een koppeling kunnen maken met dit blog? De dienst komt met een uitgebreid systeem van RSS feeds, zodat ik behoorlijk nauwkeurig kan kiezen wat ik hier wil delen en met welke tekst. Maar tegelijk kom ik in mijn RSS reader zoveel boeiends tegen. Nu heeft Inoreader de mogelijkheid om iets te broadcasten waarmee ik zelf een korte tekst kan toevoegen aan een item wat ik wil delen. Dat heeft eveneens een eigen RSS feed.

Er is echter een klein probleem. Dit blog heeft geen ingebouwde mogelijkheid om relatief eenvoudig dit soort links te delen. Zeker al niet via mobiel. Dus ik moet een omweg bedenken. Nu is dat geen probleem, het is zo’n vraagstuk waar je je eigen oplossing voor kunt bedenken, ontwikkelen en uitvoeren. Ik heb nu het volgende in gedachte:

  1. Ik deel iets op Pinboard of Inoreader met een speciale tag en tekst
  2. Op een eigen server hou ik deze RSS feeds bij
  3. Als er een nieuw item verschijnt in de feeds, zorg ik dat deze omgezet wordt in een artikel voor dit blog
  4. Op gezette tijden publiceer ik automatisch een nieuw link-item op dit blog.

Wat betekenen deze stappen? En hoever ben ik?

Stap voor stap

Stap 1 is niet zo lastig. Zowel op Pinboard als Inoreader kan ik eenvoudig nieuwe items opslaan en delen. Dit kan ik mobiel en op de desktop. Voor Pinboard heb ik een fijn script gemaakt met de app Workflow, zodat ik uit vrijwel elke andere app een link kan opslaan op Pinboard. Daarmee is het direct beschikbaar via de RSS feed. Inoreader heeft recent de mobiele app geupdate en het is nu nog eenvoudiger om blogposts te taggen en te delen.

Stap 2 is al spannender. En daar ben ik deze dagen mee bezig geweest. Ik ben inmiddels zover dat ik lokaal een script heb draaien wat (nu nog handmatig) de RSS feeds van Pinboard en Inoreader leest en de individuele items opslaat. Ik heb hiervoor veel gebruik gemaakt van scripts die Dave Winer al heeft gemaakt rondom RSS, OPML en NodeJS. Het is voor mij enorm leerzaam om te begrijpen hoe dit soort zaken werken. En ik vind het gewoon leuk.

Stap 3 en 4, daar moet ik nog aan beginnen. Dit blog is opgebouwd in de taal Jekyll. Ik schrijf Markdown bestanden, een soort versimpelde Word bestanden, en daarmee kan ik dit blog voorzien van nieuwe artikelen. Het mooie is dat de opmaak vrij eenvoudig is én dat alle blogposts als statische bestanden zijn weggeschreven. Dit gebeurt allemaal met templates die relatief eenvoudig zijn te maken. Dat betekent dat ik bij een nieuw gedeeld item, zo’n template bestand moet vullen met informatie uit die RSS feed en zo een nieuw artikel samenstel. Klinkt ingewikkeld, om het te maken is het ook niet makkelijk, maar als het eenmaal werkt zal ik me hoogstwaarschijnlijk afvragen waarom ik zo lang bezig was met zo’n relatief simpele oplossing. De vierde stap is een voorzorgsmaatregel van mezelf. Ik lees veel in de ochtenden en avonden en dat zou betekenen dat er op die momenten vrij veel ineens wordt gedeeld op dit blog. Ik spreid het liever wat uit over de dag, dus ga ik er nog voor zorgen dat al die vooraf samengestelde posts netjes klaar staan om op bepaalde tijdstippen te worden gepubliceerd.

De wegen naar Rome

Maar klinkt dat niet erg als een wiel opnieuw uitvinden? In blogservices als WordPress zit dit allemaal ingebakken en heb je het vrij eenvoudig werkend. Dat klopt en het klinkt wat stupide om dit allemaal zelf te gaan doen. Maar het is een hobby. En hobbies zijn soms wat stupide. Ik heb niet de ambitie om WordPress na te maken, evenmin dat ik mijn uiteindelijke oplossing schaalbaar wil maken voor anderen. Ik probeer het wel zo te ontwikkelen dat anderen er eventueel op kunnen voortborduren. Tegelijk weet ik dat bij het zien van mijn code er al tientallen andere manieren zijn om doen wat ik wil doen.
Zo kwam ik er vanavond al achter dat Dave Winer een Github-repository heeft genaamd DaveReader, wat voor een groot deel al de onderdelen heeft die ik nodig heb. Zoals het beheer van bron-feeds, het periodiek uitlezen van deze feeds en er acties op ondernemen. Tegelijkertijd heeft het veel overhead zoals een interface om de feeds te lezen en een uitgebreide opslagstructuur voor alle feeds. Dat is weer iets wat ik niet nodig heb. Dus ga ik dan toch overstag en hack ik mijn eigen ideeën in de DaveReader of ga ik nog even door met mijn eigen oplossing?

Ik probeer nog even wat door te knutselen met mijn eigen oplossing. Je kunt al een beetje meekijken via Github, waar ik de code heb geplaatst. Veel werkt echter nog niet echt goed en is nog uitzoekwerk voor me. Maar het begin is er.

Hoofdbrekens

Waar ik nu over pieker zijn de volgende stappen:

  • Hoe sla ik zo handig mogelijk in een lokaal bestand de opgehaalde items op? Ik wil liever niet met databases gaan werken vanwege de extra overhead voor iets relatief simpels als dit.
  • Sla ik het op als Array, als Object of als JSON file? Welk formaat past het beste bij wat ik uiteindelijk voor ogen heb?
  • Hoe zorg ik dat ik nieuwe te delen items netjes aan dit bestand toevoeg zonder oude items er dubbel in te zetten?
  • Hoe word de logica om op gezette tijden (via een cronjob?) het oudste item uit de lijst te halen en om te zetten in een draft post voor mijn blog?
  • Hoe publiceer ik het op mijn blog? Ik schijn bij Github met webhooks te kunnen werken. Nog nooit gedaan, dus hoe zit dat?
  • Als ik dit allemaal voor elkaar heb, kan ik het dan nog eenvoudiger maken en toch alles in eigen beheer hebben in plaats van gebruik te maken van een andere dienst?

En waarom deed ik al weer? O ja, om mezelf wat NodeJS te leren, om te snappen hoe ik mijn eigen scripts kan maken en met name om boeiende artikelen en links hier te delen. Eigenlijk wil ik de aloude Leesmap weer wat liefde geven, zonder dat het een verplichting wordt elke week.

Al met al is het een leuk project voor mezelf. Ik leer er wat mee programmeren, ik begrijp iets beter hoe een moderne taal als NodeJS in elkaar zit en het geeft me de voldoening dat ik niet compleet afhankelijk ben van een andere dienst als ik iets wil maken voor mijn eigen gebruik.

Punkrock Publishing dus!

Opgeslagen onder: webtech Tags: cheatsheet, indieweb, Jekyll, nodejs, opml, pinboard

Footer

Wat is dit?

Frank MeeuwsenDigging the Digital is de digital garden of commonplace book van Frank Meeuwsen. Onderwerpen variëren van indieweb tot nieuwsbrieven, bloggen, muziek en opvallende gebeurtenissen op het internet.

Meer Frank

Bloghelden - De definitieve geschiedenis van webloggend Nederland

Op deze dag

  • 2 years ago...
    • Je notities zichtbaar verbonden in Obsidian
  • 3 years ago...
    • The Breakfast Club is jarig
  • 4 years ago...
    • The Breakfast Club 1984
    • Communities op de Dutch Comic Con
  • 10 years ago...
    • Hoe bepaal je de prijs van je eigen e-book?
  • 13 years ago...
    • Social Warfare tussen Nestl en Greenpeace
  • 20 years ago...
    • The hippie period of the Web is over
  • RSS
  • LinkedIn
  • GitHub
  • Mastodon
← An IndieWeb Webring →

Archives

  • Likes (268)
  • Bookmarks (267)
  • Notes (134)
  • Replies (53)
  • Articles (722)
  • All Posts

Digging the Digital staat op de state of the art server van Servebolt.
De snelste high-performance hosting met een sterke focus op schaalbaarheid en veiligheid.