- Nach der Ermüdung durch die Softwarebranche und klassische Social Media wurde auch Mastodon ausprobiert, aber tatsächlich gebraucht wurde ein persönlicher Feed-Reader, der Texte und Benachrichtigungen aus dem Web bündelt, statt einer menschenzentrierten Timeline
- Das Ziel war keine rückstandsartige Liste wie ein E-Mail-Posteingang in einem RSS-Reader, sondern eine streamartige Oberfläche, in der beim Öffnen interessante Inhalte vorbeifließen – ähnlich dem Home-Feed von Twitter oder Mastodon
- Das Designkriterium war Benutzererfahrung > Betriebsfreundlichkeit > Entwicklungsfreundlichkeit, wobei Entscheidungen bevorzugt wurden, die sich einfach betreiben lassen, etwa htmx·hyperscript, eine monolithische Web-App, SQLite, Python sowie Erweiterungen wie gevent und Huey
- Während der tatsächlichen Nutzung kamen Funktionen hinzu wie das Lesen von Artikeln innerhalb der App, Pins zum Späterlesen, Bookmarks, Sortierung nach Veröffentlichungsfrequenz der Quellen und automatische Markierung als „bereits gesehen“ beim Scrollen
- Nach etwa drei Monaten lockerer Arbeit entstand feedi, das über mehrere Monate als „erste Seite des Internets“ diente und dabei das Gefühl von Kontrolle über die konsumierten Informationen zurückbrachte
Die eigene Webnutzung nach dem Burnout wiederfinden
- Durch eine Reihe schlechter Projekte und die Ernüchterung über die Softwarebranche trat ein Karriere-Burnout ein
- Die Arbeit wurde reduziert, der Job gekündigt und eine Therapie begonnen; außerdem wurden Gewohnheiten wie Essen, Bewegung und Meditation verbessert
- Programmieren und softwarebezogene Lektüre wurden eine Zeit lang gemieden, und auch Twitter, das letzte noch genutzte Social-Media-Netzwerk, wurde verlassen
- Beim Lesen von How to Do Nothing kam Mastodon als alternative Online-Community wieder in den Blick
Grenzen, die sich bei Mastodon zeigten
- Mastodon bietet einen chronologischen Feed ohne algorithmische Vermittler und vermittelt damit wieder ein Gefühl der Kontrolle über den Feed
- Menschen, die ähnlich unzufrieden mit der Softwarebranche und dem Web waren, schauten sich frühere Elemente des Webs wie RSS, BBS, Digital Gardens und Webrings erneut an oder stellten sich ein offeneres und unabhängigeres Web vor
- Der tatsächliche Einsatzzweck lag näher an einem Informations-Hub als an Microblogging
- Menschen wurden gefolgt, um benachrichtigt zu werden, wenn sie etwas auf ihrer Website veröffentlichten
- Bots wurden gefolgt, um Inhalte von Link-Aggregatoren zu erhalten
- Nach der Begegnung mit dem Konzept der IndieWeb-Social Readers wurde klar, dass das benötigte Werkzeug nicht Mastodon, sondern ein selbst anpassbarer Feed-Reader war
Benutzerziele für einen persönlichen Reader
- Gewünscht war kein rückstandsartiger Posteingang wie in üblichen RSS-Readern, sondern ein Stream, in dem beim Öffnen der App interessante Inhalte fließen
- Im Feed sollten verschiedene Quellen gemeinsam gemischt werden
- Artikel aus Blogs, Magazinen, Nachrichtenseiten und Link-Aggregatoren
- Benachrichtigungen persönlicher Konten wie Mastodon, Goodreads und GitHub
- Da die Datenformen je nach Quelle unterschiedlich waren, war anpassbares Parsing nötig, um ein konsistentes Erscheinungsbild zu schaffen
- Die sozialen Funktionen eines vollständigen IndieWeb-Readers gehörten nicht zum Umsetzungsziel
- Für Kommentare eine andere Registerkarte zu öffnen, war kein Problem
- Es war in Ordnung, wenn Inhalte auf Drittseiten verteilt blieben
- Das kurzfristige Ziel war, schnell zu prüfen, ob dieses Werkzeug zur primären oder sogar einzigen Informationsquelle im Web werden könnte; wenn nicht, sollte das Projekt sofort beendet werden
Entwicklungsprinzipien und Umfang
- Das Entwicklungsprinzip lautete
user > ops > dev- Bei Arbeitsprioritäten und Designkompromissen wurde Betriebsfreundlichkeit höher gewichtet als Entwicklungsbequemlichkeit
- Noch darüber stand die Benutzererfahrung
- Da es sich um eine persönliche App handelte, bedeutete „Benutzer zuerst“, die eigenen Bedürfnisse durch direkte Nutzung (Dogfooding) zuerst zu erfüllen
- Statt einen idealen Nutzer zu imaginieren, erschien es sinnvoller, ein ergonomisch auf die eigene Person zugeschnittenes Werkzeug zu bauen
- Dieses Projekt sollte weder ein Lernprojekt noch ein Portfolio-Projekt sein
- Ziel war nicht Produktivität, sondern wieder einen Zugang zur Freude an der Softwareentwicklung zu finden
- Die Freude sollte nicht aus dem „Etwas bauen“, sondern aus dem „Etwas Eigenes benutzen“ kommen
- Durch die Annahme eines einzelnen Zielnutzers konnten mehrere Entscheidungen aufgeschoben werden
- Benutzer-Authentifizierung, die nicht sofort nötig war, wurde vertagt
- Sehr spezifische Funktionen wie das Senden an Kindle konnten früh behandelt werden
- Für Feed-Parser-Anpassungen oder den Mastodon-Login durfte Programmierwissen vorausgesetzt werden
Entscheidungen zu UI und Architektur
- Um nicht nur auf dem Laptop, sondern auch auf dem Smartphone zugänglich zu sein, musste es eine Web-Anwendung sein
- Das war ein kosteneffizienter Weg, zwei Geräte mit einer Oberfläche zu unterstützen
- Vertrautes HTML und CSS konnten genutzt werden
- Durch serverseitig gespeicherten Zustand ließ sich die Synchronisierung zwischen Geräten lösen
- Die Web-UI musste in gewissem Maß dynamisch sein, aber eine separate Frontend-Anwendung oder das Erlernen eines neuen Frameworks war nicht gewünscht
- Nach dem Rat zu boring tech und radical simplicity wurde eine serverseitig gerenderte Bibliothek gesucht; eingesetzt wurden htmx und hyperscript
- Für Betriebsfreundlichkeit sollte Deployment und lokale Einrichtung einfach sein, ohne Docker oder Nix als Voraussetzung
- Ein vollwertiger IndieWeb-Reader, wie ihn Aaron Parecki beschreibt, zerfällt in Komponenten für Protokolle wie Micropub, Microsub und Webmentions, doch für den persönlichen Einsatz brachte das vor allem mehr Entwicklungs- und Betriebsaufwand bei wenig Nutzen
- Daher fiel die Wahl auf eine monolithische Web-Anwendung; als Datenbank wurde SQLite genutzt, um die Zahl installier- und konfigurierbarer Komponenten zu minimieren
Sprache und Hintergrundaufgaben
- Go schien für dieses Projekt gut geeignet: einfach und vielseitig, mit Garbage Collection, ausreichend schnell, mit gutem Concurrency-Modell und leicht verteilbaren Binärdateien
- Es war jedoch noch keine einzige Zeile Go geschrieben worden, und das Projekt sollte nicht zu einem Lernprojekt werden
- Deshalb fiel die Wahl auf Python, die vertraute Sprache, mit der sich am schnellsten ein Prototyp bauen ließ
- Nachteile von Python blieben Umgebungen und Abhängigkeiten, insbesondere Abhängigkeiten von Bibliotheken des Host-Betriebssystems
- Für regelmäßiges Feed-Polling sollten keine zusätzlichen Komponenten eingeführt werden; nach Recherche wurden gevent und die mini-huey-Erweiterung von Huey genutzt, um Hintergrundjobs innerhalb des Anwendungsprozesses auszuführen
- Dafür gab es in Python gute Bibliotheken für HTTP, Feed-Parsing und Scraping
Warum Tests aufgeschoben wurden
- Zu Beginn wurde entschieden, keine Tests zu schreiben
- Da geplant war, Funktionen durch Hinzufügen, Entfernen und Umordnen experimentell zu verändern, wurde der Pflegeaufwand für Unit-Tests höher eingeschätzt als ihr Nutzen
- Kleine Logikfehler wurden in Kauf genommen; weil die App täglich selbst genutzt wurde, wurde erwartet, dass wichtige Bugs mit der Zeit sichtbar würden
- Für Vertrauen in die Zuverlässigkeit erschienen Integrationstests wertvoller, doch viele Bugs in diesem Projekt entstanden bei der Anbindung externer Quellen und in der UI
- Integrationstests hätten manche Fehler und Regressionen zwar früher erkannt, wurden den anfänglichen Aufwand aber nicht für wert gehalten
Wie die tatsächliche Nutzung die Funktionen steuerte
- Durch die tägliche Nutzung als Endnutzer wurden Ideen, Experimente und Prioritäten bestimmt
- Nach verschiedenen UI-Layouts und Funktionen stabilisierte sich ein Nutzungsmuster
- App öffnen
- Durch den Haupt-Feed scrollen
- Einträge zum Späterlesen anpinnen
- Einträge zum Sofortlesen öffnen
- Einträge für späteres Nachschlagen bookmarken
- Gewünscht war eine Funktion, um Artikel zu lesen, ohne die App zu verlassen; ein Grund dafür war, Paywalls und Consent-Popups zu vermeiden
- Für die Extraktion von HTML-Inhalten wurden mehrere Python-Bibliotheken ausprobiert, doch keine funktionierte so gut wie readability, das auch Firefox verwendet
- Da readability ein JavaScript-Paket ist, kam Node.js als optionale Abhängigkeit hinzu
Feed-Sortierung und Kennzeichnung als „bereits gesehen“
- Selbst nachdem die Grundfunktionen vorhanden waren, machte es die reine Sortierung nach Veröffentlichungsdatum schwer, interessante Inhalte zu finden
- Seltene Blogbeiträge gingen hinter Mastodon-Toots unter
- Lange Magazinartikel verschwanden hinter täglichen Nachrichtenmeldungen
- Da alle verfolgten Quellen als interessant galten, wurde angenommen, dass Inhalte von selten veröffentlichenden Quellen zuerst gesehen werden sollten
- Wenn ein monatlicher Newsletter in den letzten Tagen erschienen war, sollte er über Microblogging oder täglichen Nachrichten stehen
- Die Quellen wurden in „frequency buckets“ eingeteilt und der Feed so sortiert, dass Buckets mit niedrigerer Frequenz zuerst erscheinen
- Um zu vermeiden, dass seltene Inhalte bei jedem Öffnen der App oben kleben bleiben, wurde eine Funktion hinzugefügt, die Einträge beim Scrollen automatisch als „already seen“ markiert
- So blieb stets neuer Inhalt sichtbar, ohne seltene Updates zu verpassen
Vom lokalen Rechner zum VPS
- Anfangs lief die App in einem Terminal-Tab auf dem Laptop, während Entwicklung und Nutzung parallel stattfanden
- Als die im Feed angezeigten Inhalte zu gefallen begannen, wurde sie auf einen Raspberry-Pi-Server im lokalen Netzwerk verschoben, damit sie jederzeit erreichbar war
- Mit der dauerhaften Nutzung auf dem Raspberry Pi wurde für den Zugriff per Smartphone das mobile Rendering verbessert
- Als die App auch unterwegs vermisst wurde, erfolgte das Deployment auf einen VPS
- Das VPS-Deployment machte es nötig, die aufgeschobene Authentifizierung und Mehrbenutzer-Unterstützung hinzuzufügen, und erlaubte einigen Freunden Beta-Zugang zum Testen
- Die VPS-Einrichtung führte dazu, eine Domain zu kaufen und diese Website zu bauen, und wurde zu einem weiteren Schritt hin zu den IndieWeb-Idealen, die ursprünglich inspiriert hatten
Das Ergebnis von feedi
- Nach ungefähr drei Monaten lockerer Arbeit entstand der persönliche Feed-Reader feedi
- feedi ist weniger ein fertiges Produkt als eher ein Werkzeug, das – ähnlich einer Emacs-Konfiguration – dauerhaft halb kaputt, aber mit dem eigenen Körpergefühl verwachsen ist
- Unter Produktivitätsgesichtspunkten ist es schwer zu rechtfertigen, doch als auf die eigenen Bedingungen zugeschnittenes Werkzeug ist es zufriedenstellend
- Über mehrere Monate hinweg wurde feedi als „front page of the internet“ genutzt
- Mit einem persönlichen Reader wurde die Kontrolle über den eigenen Informationskonsum zurückgewonnen, aktiv nach interessanten Blogs und Magazinen gesucht und die Offenheit für Entdeckung und Überraschung vergrößert
1 Kommentare
Hacker-News-Kommentare
urlwatch(https://urlwatch.readthedocs.io/en/latest/) einzurichten, hat ziemlich Spaß gemacht. Vor allem, wenn man über Puppeteer-Boilerplate hinauskommt und JavaScript-Sites mit einer Chrome-Instanz scrapen kann, fühlt es sich an, als würde man das Web nicht mehr aktiv heranziehen, sondern es kontrolliert zu sich pushen lassen
Es ist enorm nützlich, Websites ohne großen Aufwand zu überwachen und morgens kurz durchzusehen. Man kann Stellenanzeigen von Lieblingsunternehmen, Jobangebote/Deadlines des aktuellen Unternehmens, Produkte, bei denen man auf Sale, Wiederverfügbarkeit oder Refurbished-Angebote wartet, Corona-Abwasserstatistiken, Wohnungsangebote, interessante GitHub-Releases und sogar Änderungen an den Nutzungsbedingungen wichtiger Websites verfolgen
Ich persönlich nutze einen DigitalOcean $5 Droplet, weil ich auch meinen RSS-Reader und einen Telegram-Bot selbst hoste und oft kleine experimentelle HTTP-Sites baue; es muss aber nicht jeden Tag zur gleichen Zeit laufen, daher geht es auch auf einem Laptop
Da es nur für mich ist, bekomme ich nur Zusammenfassungen von Twitter-Updates zu meinen Interessengebieten und kann die Site selbst, giftige Debatten und nervige Werbung vermeiden
Der aktuelle Zustand der IT macht mich so wütend, dass ich es kaum sauber formulieren kann, aber manchmal stelle ich mir das Konzept eines „persönlichen IT-Betreuers“ vor. Jemanden, der sich um einen Teil des digitalen Lebens kümmert, so wie der Friseur im Viertel, der Hausarzt, der Schneider oder der Bäcker
So jemand hätte eine kleine lokale Infrastruktur, erstellt personalisierte Feeds, kümmert sich um Privatsphäre und digitale Gesundheit und verbindet einen über einfache Interfaces oder offene Protokolle mit Feed-Readern. Filme, Texte, Memes und unterhaltsame Videos wären ebenfalls dabei, aber der Kern wäre, dass es nicht um Algorithmen zur Gewinnoptimierung geht, sondern um einen Menschen, mit dem man sprechen kann
Mir kommen auch Ideen wie von lokalen Communities betriebene Rechenzentren als eine Art Bibliothek oder einfache Content-Dienste über das heimische Internet in den Sinn. Deshalb gefielen mir Ansätze wie Veilid(https://gitlab.com/veilid/veilid)
Es ist auch nicht das erste Mal, dass ich höre, jemand sei nach dem Wechsel ins Fediverse gesünder geworden. Ich lege selbst Skripte und Mini-Apps auf Puppeteer, lasse mit lokalem llamacpp Zusammenfassungen und Empfehlungen laufen und möchte das künftig weiter verfeinern und Freunden und Familie empfehlen
Diese Skripte habe ich „not a browser“ genannt. Ich will kein Web, das HTML/CSS/JS zusammen mit Daten ausliefert, sondern ein Web, das nur Daten bereitstellt und den Nutzern überlässt, wie sie angezeigt werden
Es gibt keine nutzerfeindlichen Algorithmen und keine werbebasierten Systeme, sondern Software, die im Großen und Ganzen die Nutzer priorisiert und von offenen Protokollen spricht. Wenn man in der IT-Branche ist und Server selbst betreiben kann, ist das möglich; die Frage ist, was Menschen machen, die das nicht können
Die Idee eines persönlichen „IT-Betreuers“ ist interessant. Ich frage mich, ob man so einen Service für Menschen anbieten könnte, die sich von Big Tech und Algorithmen lösen und etwas Persönlicheres nutzen wollen, denen aber die technischen Mittel fehlen
Bei Gesundheitsdaten ist es ähnlich. Ich mag nicht, dass meine Krankenakten in MyChart und verschiedenen proprietären Systemen gespeichert sind und ich keine Kontrolle darüber habe. Ich habe einen Supercomputer in der Tasche; warum kann ich nicht selbst eine Kopie meiner Unterlagen aufbewahren und sie beim Arztbesuch selektiv mit dem Arzt teilen?
Es ist auch seltsam, dass Krankenhäuser immer noch Faxe austauschen müssen. Ich sollte meine Daten mit einem einzigen Button teilen können. Apple Health kommt einigen Funktionen noch am nächsten, aber die Verbreitung in den USA scheint sehr gering zu sein, und selbst das begünstigt nur Apple-Nutzer. Gesundheitsdaten dürfen nicht in proprietären Systemen eingesperrt sein, selbst wenn die Form so etwas wie lokal laufendes Apple Health wäre; es braucht offene Protokolle und ein Ökosystem von Implementierungen
Bevor Marketing und Gier das Internet übernommen haben, gab es eine kurze, einigermaßen gute Phase. Etwas wie ein Synology NAS mit Apps, die Endnutzern nützen, plus ein „persönlicher IT-Betreuer“, der dabei hilft, könnte gut funktionieren
Wenn es nicht darauf ausgelegt wäre, persönliche Daten und Geld aus Nutzern herauszuziehen, käme es aus Nutzersicht einer Utopie nahe; wirtschaftlich wäre es aber vermutlich ein Geschäft mit niedrigen Margen und hohen Risiken. Zum Beispiel ist die Haftung bei Dateiverlust ein großes Thema
Man schreibt Code einmal und führt ihn dann fast ohne zusätzliche Kosten millionenfach aus. Alle strukturellen Kräfte scheinen in die entgegengesetzte Richtung zu wirken. Vielleicht wird es eher möglich, wenn KI all unsere Jobs ersetzt hat
Jenny Odells How to Do Nothing ist ein wirklich ausgezeichnetes Buch. Es ist vielleicht etwas anders als die übliche Leserschaft von Hacker News, aber ich empfehle es nachdrücklich allen, die anfangen, den Druck der falschen „Produktivität“ zu spüren, den die Aufmerksamkeitsökonomie erzwingt
Auch Jenny Odells andere Projekte sind sehenswert. Zum Beispiel The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html)
In diesem Zusammenhang empfehle ich auch Jenny Odells Saving Time. Ein stilles, aber sehr radikales Buch; persönlich fand ich es von den beiden besser. Die Erzählung war fokussierter
Über einen einfachen persönlichen Feed hinaus wünsche ich mir einen zeitlich begrenzten, ablenkungsfreien Feed.
Er sollte alle Textinhalte sammeln, denen ich folge, und mir jeden Tag eine Auswahl von Einträgen zusammenstellen, die etwa 30 Minuten Lesezeit ergibt. Blogposts, Artikel, Tweets usw. sollten alle enthalten sein.
Mit ChatGPT oder einem anderen Tool sollte er die „nahrhaftesten“ Inhalte herausfiltern und Inhalte priorisieren, die wertvoller sind als Wortgefechte. Danach möchte ich sie an einen Kindle oder ein reMarkable-Tablet schicken und sie fern von Farben, Blinkeffekten und schnellem Internet lesen.
Als nächsten Schritt würde ich gern die Feeds von Freunden abonnieren und gelegentlich auch „Gast“-Inhalte aus deren Feed bekommen.
Die Idee, GPT-Zusammenfassungen hinzuzufügen, gefällt mir, und wenn andere auch Interesse haben, könnte ich es aufräumen und teilen. Im Moment ist es eine einfache JavaScript-App, die lokal läuft, aber die Idee wirkt inzwischen spannender, als ich ursprünglich dachte.
Ich glaube, es war Douglas Engelbart, aber ich finde die Unterlagen zu Agenten nicht. Es könnte auch ein anderer Technologieexperte gewesen sein.
Mir fiel die bewusste Entscheidung auf, am Anfang nicht unbedingt automatisierte Tests zu schreiben, und ich konnte das gut nachvollziehen. Es hat eine ganze Weile gedauert, das ungute Gefühl zu überwinden, wenn man keine Tests schreibt, aber bei persönlichen Spielzeugprojekten gehe ich inzwischen ähnlich vor.
Zu viele Projekte sind ungefähr am ersten Tag gestorben. Eigentlich ist das der Moment, in dem man Schwung aufnehmen sollte, aber ich verlor die Motivation, während ich Testinfrastruktur und CI-Pipelines aufbaute.
Heute arbeite ich nach dem Maßstab: Wenn das Fehlen von Tests zu einem echten Problem wird, füge ich sie dann hinzu.
Was in einem ausgereiften Projekt mit vielen Entwicklern und großer Codebasis unverzichtbar ist, kann in einem kleinen Ein-Personen-Projekt eher Ballast sein.
Danach konzentriere ich mich darauf, bei jedem auftretenden Problem ad hoc Tests hinzuzufügen.
Vor ein paar Jahren habe ich als persönliches Projekt einen Atemgas-Analysator gebaut und Software geschrieben, die sich per Bluetooth verbindet und die Daten in Echtzeit anzeigt. Für Funktionen, die wissenschaftliche Berechnungen korrekt ausführen mussten, waren Unit Tests sehr nützlich, aber Tests für andere Teile der Oberfläche waren rückblickend fast reine Zeitverschwendung.
Nachdem ich sicher war, dass sich die Funktionen nicht mehr ändern würden, habe ich alle Tests entfernt. Wenn man allein entwickelt, können manuelle Tests durchaus ausreichen.
Ich habe einen neuen anonymen Account angelegt, um ehrlich über die Zukunft zu sprechen.
Dieser Beitrag hat mich überrascht, weil er sich anfühlte, als hätte mein zukünftiges Ich ihn geschrieben. Ich hatte so viel mit dem Autor gemeinsam, dass es kaum zu glauben war.
Ich hatte erkannt, dass ich ausgebrannt bin, und plante, Anfang nächsten Jahres meinen Job zu kündigen. Genau deshalb habe ich auch den anonymen Account erstellt. Wahrscheinlich gibt es viele, denen es ähnlich geht.
Noch erstaunlicher ist, dass das, was der Autor getan hat, fast genau dem entspricht, wovon ich während meiner Auszeit fantasiert habe. Ich habe darüber nachgedacht, wie ich mich am Open Web/IndieWeb beteiligen könnte, und plante, in diesem Bereich eine App zum Experimentieren zu bauen.
Sogar die technischen Überlegungen ähnelten sich: etwa das Problem, seltene Beiträge nicht in der Flut untergehen zu lassen, oder welche Sprachen und Technologien ich verwenden sollte. Bei der Webentwicklung bin ich ungefähr zehn Jahre im Rückstand, aber ich hatte auch vor, mit moderner Webtechnik etwas zu bauen.
Einerseits freue ich mich, weil sich meine jüngsten Gedanken und Gefühle bestätigt anfühlen. Es fühlt sich an, als wäre ich auf dem richtigen Weg. Andererseits bin ich traurig und auch ein bisschen neidisch, dass der Autor es zuerst geschafft hat.
Damals wollte ich meinen eigenen RSS-Reader. Die bestehenden Reader mochte ich nicht; ich wollte einen Reader, der nicht wie ein Posteingang aussieht, sondern wie ein normales Blog, und den ich nach meinen Wünschen gestalten kann. Also habe ich einen RSS-Feed-Parser gebaut und ihn so gestaltet, dass er wie mein normales Blog aussieht.
Später habe ich ihn so geändert, dass er den vollständigen Artikel abruft, wenn im RSS-Feed nur eine Zusammenfassung steht. Ich wollte nicht aus dem Reader herausklicken müssen, um den ganzen Artikel zu lesen; alles sollte im Feed-Reader sein. Als ich einen einfachen Page-Scraper hatte, habe ich ihn auch für Websites ohne RSS genutzt, und als Social Media populär wurde, war das besonders hilfreich.
Ich konnte die Inhalte, die ich wollte, in meinem Feed sehen, ohne die eigentlichen Social-Sites besuchen zu müssen. Da das Ding 20 Jahre alt ist, besteht es aus alten Technologien wie PHP und XSLT, und daran hat sich bis heute nichts geändert.
Jedenfalls kann ich nur nachdrücklich empfehlen, es selbst zu bauen. Es ist ein unterhaltsames Projekt. Es ist alt, rau, und das Scraping ist nicht perfekt, sodass manchmal gewünschte Inhalte nicht auftauchen, aber es gehört mir, und ich mag diesen Reader, den ich seit 20 Jahren täglich nutze.
Es gibt keinen Grund, warum ein ähnlicher Versuch nicht wirken sollte. Er war auch nicht der Erste, der einen persönlichen Reader implementiert hat.
Interessant ist: Als ich den IndieWeb-Artikel, den ich verlinkt hatte, noch einmal überflogen habe, hatte ich das Gefühl, die Ideen daraus fast wörtlich zu wiederholen. Ratschläge im Sinne von: „Versuche nicht, Software für alle zu bauen, sondern baue sie für dich selbst.“
Wenn man versucht, etwas Allgemeines zu bauen und es anderen leicht nutzbar zu machen, geht man möglicherweise Kompromisse ein, die der eigenen Nutzbarkeit schaden, oder entwirft für imaginäre Nutzer, die gar nicht existieren. Gemeint ist: Bau es eigennützig, damit es für dich nützlicher wird.
Das war wirklich erfrischend. Im letzten Jahr bin ich einen sehr ähnlichen Weg von Burnout/Erholung gegangen, und durch das Bauen nützlicher persönlicher Software habe ich wieder Freude an der Arbeit gefunden.
Ein weiterer großer Vorteil ist, dass man nach Belieben „unorthodoxe“ Technologien ausprobieren kann. Dinge wie eine moderne Single-Binary-PHP-Executable zu bauen, SQLite in Produktion zu nutzen oder ohne Docker zu deployen, machen Freude.
Solche Arbeiten hatten auch Auswirkungen auf meinen Hauptjob. Oft entdecke ich in meinen persönlichen Repositories neue Techniken und Optimierungen und bringe sie in die Arbeit ein.
Es ist interessant, dass Techniker nebenbei an Dingen herumprobieren und das Gelernte in nützlicher, manchmal wertvoller Form in ihren Beruf mitnehmen. Arbeitgeber werten solche Bemühungen jedoch manchmal ab oder bremsen die Begeisterung aus.
Vielleicht habe ich einfach in der falschen Art von Organisationen gearbeitet. Trotzdem freut es mich, dass du von solchen Spillover-Effekten profitieren konntest.
Ich mag die Feed-Denkweise lieber als eine Checkliste von Dingen, die man lesen/konsumieren soll. Über die Jahre habe ich ein paar RSS-Reader ausprobiert, bin aber nie lange bei einem geblieben
Ich fragte mich, ob ich wirklich noch einen weiteren Posteingang verwalten muss. Trotzdem werde ich mir feedi (https://github.com/facundoolano/feedi) ansehen
Vor der Einrichtung habe ich ziellos herumgeklickt und geschaut, ob es bei HN etwas Neues gibt, bei Reuters vielleicht auch. Meine Erfahrung passt zu https://news.ycombinator.com/item?id=38642092
Persönliche Mails, Mailinglisten und RSS-Feeds landen alle an einem Ort. Wenn man in separate Spools filtert und einen leistungsfähigen E-Mail-Client wie mutt dazu nutzt, ergibt das eine ziemlich angenehme integrierte Erfahrung
Der Autor scheint Authentifizierung hinzugefügt zu haben, um von überall auf die App zugreifen zu können
Ich frage mich, ob es möglich oder einfacher wäre, sie stattdessen hinter ein VPN zu stellen und dieses VPN von überall zugänglich zu machen
Ich möchte sicher auf persönliche Web-Apps zugreifen, suche aber nach dem einfachsten Ansatz. Jedes Mal, wenn ich Authentifizierung sehe, fühlt es sich wie ein Labyrinth aus Konzepten, Protokollen und Bibliotheken an, und ich möchte das nicht warten
Ich hoste zu Hause auf einem Raspberry Pi ein paar Apps wie Home Assistant und habe Tailscale auf dem Pi und meinem Smartphone installiert; das funktioniert sehr gut. Die einzige Authentifizierung, die nötig ist, lautet: „auf jedem Gerät bei Tailscale einloggen“
Wenn es darum geht, mit den eigenen Geräten einfach ein sicheres Netzwerk aufzubauen, kann ich Tailscale wirklich sehr empfehlen
Um meine Anwendung zu „schützen“, die nur von anderen Websites ausgeschnittene Textschnipsel hostet, reicht das aus
Es gibt viele Wege, aber der Kern ist, den VPN-Endpunkt und die Web-App am selben Ort zu betreiben, etwa auf derselben Maschine oder im selben Netzwerk, und den Zugriff auf die Web-App von anderen Orten aus einzuschränken
Caddy ist so konfiguriert, dass es nur Anfragen aus dem internen Netzwerk oder dem VPN per Reverse Proxy weiterleitet und sonst 404 zurückgibt. Wenn man also nicht im VPN oder im Heimnetz ist, sieht man gar nichts
Je nachdem, ob man Gästen das Netzwerk öffnet und welche Dienste man betreibt, kann ein VLAN oder ein separates Gastnetz nötig sein. Viele Dienste, die ich zu Hause betreibe, haben auch eine eigene Passwort-Authentifizierung, die ich zusammen mit der VPN-Beschränkung nutze
Diese Konfiguration war das Erste, was mir eingefallen ist, daher könnte sie aus Gründen außerhalb meines Fachgebiets unsicher sein. Der Vorteil ist, dass im selben Compose-File auch Pi-hole läuft, sodass ich, sobald mein Smartphone mit dem VPN verbunden ist, Remote-Adblocking „gratis“ dazubekomme
Tailscale ist einfacher einzurichten und hat eine bessere UI, aber unter iOS hat es viel Akku verbraucht, deshalb habe ich es aufgegeben. Dass man „den Servern anderer vertrauen“ muss, ist ebenfalls ein Problem, aber ohne das Akku-Thema hätte ich das zusätzliche Risiko für den Komfort wahrscheinlich in Kauf genommen
Die WireGuard-App hat auch eine praktische Funktion. Man kann festlegen, dass sie in bestimmten Netzwerken nicht laufen soll, etwa zu Hause; wenn man rausgeht, schaltet sie sich automatisch ein, und wenn man nach Hause kommt, wieder aus
Das kommt dem, was ich mir für eine Fahrtenyacht vorgestellt habe, erstaunlich nahe. Besonders auf hoher See ist die Verbindung nur sporadisch, daher würden zwei zusätzliche Dinge es genau passend machen
Man müsste in kurzen Momenten mit Verbindung, etwa wenn man an einer Insel mit LTE-Empfang vorbeikommt, jetzt synchronisieren drücken können. Außerdem sollte es standardmäßig Readability-Verarbeitung und einen lokalen Cache geben, damit man alle Inhalte inklusive Bilder offline lesen kann