Ich war über Ostern in der alten Heimat von Frau. Schwiegermama und ich hatten Geburtstag, ein logistischer Albtraum für die Bauchspeicheldrüse. Und meinem Gürtel hat das alles so gar nicht gefallen.

Um die drohende Textil-Katastrophe abzuwenden und mich mental und körperlich auf das fantastische Abendessen vorzubereiten, blieb nur die Flucht nach vorne: Bewegung.

Und während ich versuchte durch den Ohrbergpark zu flanieren, um das Food-Koma wegzulaufen, begann ich zu ahnen: Ich werde älter.

Das merkt man nicht an großen Dingen. Nicht daran, dass man plötzlich freiwillig um zehn ins Bett geht. Sondern daran, dass man sich selbst dabei erwischt, wie man innerlich das Wort ‚Rabauke‘ formt.

Zungenschnalzen für Fortgeschrittene

Frau und ich schlendern also durch diesen schönen Park, für die Rhododendren war es natürlich zu früh, als plötzlich zwei Menschen auf dem Rad an uns vorbeifuhren. Quer durch den Friedwald, auf dem ein eindeutige Piktogramm die Benutzung von Fahrrädern untersagt! Meine Hände hinter dem Rücken verschränkt schüttelte ich nur meinen Kopf und dachte: "Rabauken!"

Ich war schockiert. Über mich. Aber irgendwie auch stolz.

Früher hätte ich gedacht: „Lass die doch.“ Heute denke ich: „Das gehört sich aber nicht.“ Und während ich noch überlege, ob ich noch mit einem mehrfachen Zungenschnalzen die beiden Menschen auch akustisch ahnde, wird mir klar: Das ist es also. Das ist dieser schleichende Übergang, wenn man anfängt, Ordnung für eine Tugend zu halten und die ironische Schale darum immer weiter zerbröselt.

Übrigens, wen es Interessiert: Familien- oder Freundschaftsbäume gibt es im Friedwald ab 3.900 Euro sowie 99 Jahre Ruhezeit. Solange der Vorrat reicht.

Das Grauen hat eine Zipfelmütze

Wenn ich von Skandal spreche, meine ich aber nicht die Radfahrenden. Ich spreche vom Zwergenbaum. Für alle, die nicht im Bilde sind: Vor zehn Jahren stellte jemand einen harmlosen Gartenzwerg in eine Buche. Süß, sollte man meinen, oder? Ein bisschen märchenhaft. Aber im Innersten können wir Menschen es ja nicht einfach mal gut sein lassen. Wir müssen größer denken, weiter wachsen, expandieren. Und so steht inzwischen vor der Buche ein Heer für mittellose Gartenzwerge. Da hocken jetzt fünfzig dieser Kerle rum. Plastik, Ton, Stoff. Und jetzt kommt der Teil, bei dem ich merke, wie alt ich werde: Ich verstehe plötzlich die Leute, die sich darüber aufregen.

Der logische Zerfall

Die Lokalzeitung nannte es ernsthaft „Umweltfrevel“. Natürlich mit einem Fragezeichen am Ende. Trotzdem: Ein große Wort für die kleinen Kerlchen im Unterholz. Aber ich fange es an zu verstehen. Ein Wald hat ein Wald zu sein. Da haben Bäume zu stehen, Vögel zu zwitschern und die Natur hat gefälligst so auszusehen, wie wir sie uns vorstellen, damit auch eine Wald-Erholung einsetzen kann! Da kann man nicht einfach unangekündigt das Proletariat der Vorgärten ansiedeln.

Der Blockwart in uns allen

In Wahrheit ist das natürlich herrlich bescheuert. Da beschwert sich jemand, wahrscheinlich mit akkurat gestutzter Hecke zu Hause, über den „Vandalismus“ kleiner Zipfelmützen. Und ich stehe daneben und merke, wie ich langsam in diesen Sog aus „Das gehört sich aber nicht“ gezogen werde. Mein neues Ich, der Mann, der „Rabauke“ denkt, muss natürlich den Kopf schütteln. Es ist eine wunderbare Übung in Ironie: Man regt sich über Dinge auf, die einem eigentlich völlig egal sind, nur um zu beweisen, dass man noch Anteil am gesellschaftlichen Regelwerk nimmt.

Ich bin dann weitergegangen, ohne einen Zwerg zu retten, anzuzeigen oder mit einem laminierten Zettel diese Umweltsauerei zu verdammen. Man hat ja Prinzipien. Außerdem war ich viel zu sehr damit beschäftigt, die Radfahrer im Auge zu behalten.

Prinzipien sind alles

Der Ohrbergpark ist nach wie vor eine Reise wert. Geht hin, genießt die Azaleen und die Aussicht ins Emmer- und Wesertal und schaut euch das Zwergen-Prekariat an, solange die Ordnungshüter es noch nicht geräumt haben. Ich für meinen Teil gehe jetzt nach Hause und schaue mal, ob mein Rasen auch die vorschriftsmäßige Länge hat. Nicht, dass hier noch jemand zum Rabauken wird.

Und wieder melde ich mich gut gelaunt und überhaupt nicht gefrustet aus dem Maschinenraum. Heute: Wie meine site()->index()-Abfragen meine Seite fast gekillt hätten. Und ich wie immer selbst daran schuld gewesen bin.

Aber von vorne.

Vielleicht war es keine gute Idee, an ein, zwei Abenden bei Trakt nachzupflegen, welche Serien ich alles schon gesehen habe. Denn das hat mich auf Ideen gebracht. Zum Beispiel: Ich könnte ja dann auch gleich alle Serien und alle Filme auf gesonderten Seiten ausgeben. Und bei Serien könnte ich ja auch noch, einfach weil es so schön ordentlich ist, die Staffeln sortieren und den Serien zuordnen.

Und wenn ich schon dabei bin: Das Ganze könnte ich doch langsam über APIs aufbauen. Klar, die Watchdaten sind nur so halb akkurat, weil ich erst ab diesem Zeitpunkt angefangen habe, Serien sauber zu tracken. Aber ganz ehrlich: Ein bisschen Unschärfe ist immer noch besser als gar keine Daten.

Und wenn ich dann schon ungefähre Watchdaten habe, kann ich ja auch direkt Watchlog-Einträge erzeugen. Wer weiß, wofür die noch gut sind.

Die Konsequenz? Plötzlich hatte meine Seite über 8.000 Watchlog-Einträge. Und über 8.126 Episoden und Filme. Mit einer Watchdauer von sage und schreibe 8,5 Monaten! Aber darum soll es hier gar nicht gehen. Manche Statistiken sollte man vielleicht einfach nicht berechnen.

Worum es geht: Ich hatte plötzlich keine kleine, gemütliche Seite mehr. Sondern ein leicht zickiges Monstrum, das morgens, wenn die Botschwärme aufwachen, meinen Server zuverlässig in die Knie zwingt.

Und schuld daran war natürlich ich.

Ich habe für jede kleine Anzeige von Content einfach site()->index() benutzt. Bedeutet: Immer erst einmal die komplette Website laden, alles durchscannen, tausende Seitenobjekte bauen und dann 99,9 Prozent davon wieder wegwerfen. Klassisches Beispiel:

„Gib mir alle Seiten, filtere Reviews raus, sortiere nach Datum und zeig mir die neuesten fünf.“

Das funktioniert. Aber eben nur so lange, wie die Seite klein ist.

Mit wachsendem Content wurde das zum Problem. Nicht, weil Kirby schlecht ist, sondern weil ich bequem war. „Hol alles, filter später“ ist einfach, aber teuer.

Was ich jetzt stattdessen mache:

Ich scanne die Inhalte genau einmal, ziehe mir daraus nur die relevanten IDs und speichere diese als Cache. Und danach arbeite ich nur noch mit diesem vorbereiteten Datensatz. Keine globalen Scans mehr pro Request, sondern ein vorbereiteter, günstiger Zugriff.

Das habe ich inzwischen umgesetzt für:

• Tag-Lookups
• Film- und Serienverzeichnisse
• Watchlog-Beziehungen
• den Home-Feed
• meine Stories-Rail

Das Prinzip ist immer gleich: einmal berechnen, dann cachen.

Dann kam die nächste „gute“ Idee: Prewarming. Also Seiten im Hintergrund vorladen, damit sie für euch schneller da sind. Klingt erstmal sinnvoll.

War es auch. Nur habe ich es natürlich übertrieben.

Ich habe das Prewarming als Self-Requests direkt bei normalen Seitenaufrufen eingebaut. Bedeutet: Ein Request erzeugt mehrere neue Requests auf sich selbst. Solange wenig Traffic da ist, geht das gut. Sobald aber Bots anfangen, parallel meine Seiten zu crawlen, kippt das System.

Und genau das ist passiert.

Bots wie GPTBot, AhrefsBot oder SemrushBot haben parallel angefangen, vor allem die Suche aggressiv abzuklappern. Gleichzeitig liefen meine eigenen Prewarm-Requests. Ergebnis: Alle Worker belegt, nichts geht mehr.

Deshalb habe ich jetzt zwei Dinge geändert:

Die Suche ist für Bots gesperrt
Prewarming passiert nur noch minimal, aktuell nur für die Startseite
Alles andere beobachte ich erstmal.

Die eigentliche Erkenntnis aus der ganzen Geschichte ist aber ziemlich simpel:

site()->index()ist nicht falsch, solange man es nicht übertreibt, so wie ich ich.

Wenn man es bewusst für globale Aufgaben nutzt, ist alles gut. Wenn man es aber im Frontend bei jedem Request mehrfach benutzt, während die Seite wächst und komplexer wird, dann baut man sich ziemlich zuverlässig einen Flaschenhals.

Ich musste innerlich lachen, als ich mich dabei erwischt habe, ernsthaft zu denken, dass meine kleine Kirby-Seite jetzt erst einmal feature-complete ist. Das war wirklich ein ernsthafter, ehrlicher Gedanke. Vollkommen unironisch.

Und trotzdem kenne ich mich ja schon auch ein bisschen und habe mich schon beim Denken über mich gewundert und deshalb die letzten Tage wieder etwas im Maschinenraum rumgeschraubt:

Ich habe jetzt meine Tags-Seite versucht zu durchhirnen und aufzubohren. Denn: Ich hasse es, Inhalte zu vertaggen. Aber: Ich finde es auch unglaublich hilfreich, wenn ich es denn mal gemacht habe, um schnell Sachen wiederzufinden.

Was ich dabei gemerkt habe: Selbst wenn es niemanden interessieren sollte, gebe ich mir bei den Bookmarks viel mehr Mühe, wenn ich die hier auf hnz.io reinhaue, als wenn ich sie bei Obsidian ablege oder in die Notiz-App paste. Die gefühlte Öffentlichkeit zwingt mich zu Struktur. Und das finde ich tatsächlich hilfreich.

Ich habe jetzt ein zweigliedriges Tag-System eingeführt. Ich wähle im Artikel einfach die Kategorie aus, Kirby zeigt mir die entsprechenden (vorher angelegten) Unterkategorien an und ich muss nur noch Häkchen setzen. Ich glaube, das bekomme ich hin.

Gleichzeitig habe ich zusammen mit Chatty (Codex mit GPT-5.4) eine Taxonomie-Seite gebaut: Jeder Tag hat jetzt (wie bei WordPress) einen Beschreibungstext und für die Suche noch Synonyme. Damit es egal ist, ob man bei mir nach llm, ki, ai oder so etwas sucht.

Diese Daten habe ich genutzt, um meine Tag-Seite aufzubohren, sodass sie für mich wirklich nützlich ist. Da steht jetzt erst einmal die neue Struktur mit Hauptkategorie und Unterkategorie.

Außerdem lasse ich dort meine Orte und Locations durchsuchbar ausgeben sowie alle Regie-Leute und Haupt-Casts von Serien und Filmen, die ich getrackt habe.

Teilweise nutze ich dafür auch einfach die Loupe-Suche, um Inhalte anzuzeigen. Also eigentlich für alles, was kein klassisches Thema oder Tag ist.

Dabei habe ich gemerkt: Ich muss da noch einmal ran und das besser auf meine Bedürfnisse zuschneiden. Und ich hoffe wirklich, dass ich es so umgebaut habe, dass auch andere gut damit klarkommen.

Denn, in aller Kürze: Ich habe viele Inhalte doppelt. Gefühlt und tatsächlich.

Wenn ich einen Film logge, wird der als Watchlog automatisiert importiert. Wenn ich dazu einen längeren Text schreiben will oder nur einen Kommentar, lege ich einen entsprechenden Post an und sage dem Artikel: Bitte zeige bei der Rezension die Watchcard an. Das hier ist zum Beispiel eine Rezension von mir mit einer zugeordneten Watchcard. Und das die entsprechende Watchcard.

Das führt dazu, dass bei einer Suche wie "Starfleet Academy" sowohl meine Rezensionen als auch die Watchcards aufgetaucht sind. Relevant sind aber eigentlich nur die Rezensionen, weil dort alles aus der Watchcard enthalten ist – plus meine mal mehr, mal weniger sinnvollen Gedanken.

Also: Watchcards ausblenden, wenn ein verknüpfter Text existiert.

Das gleiche Problem habe ich bei Tags. Wenn ich die Watchcard vertagge und später noch einen Beitrag schreibe, habe ich plötzlich doppelte Inhalte unter einem Tag: Watchcard und Rezension.

Das will ich nicht manuell lösen. Ich kenne mich. Das mache ich nicht.

Also habe ich auch hier eine Regel eingebaut: Wenn Inhalte verknüpft sind (Card + Content), werden die Tags übernommen und die Watchcard fliegt aus den Übersichten raus. Wie zum Beispiel hier. Man sieht nur noch die Rezensionen und Artikel – nicht mehr die Watchcards.

Ich muss mal schauen, ob ich mein Tag-Management GitHub-fähig bekomme oder ob das wieder viel zu speziell auf mein Hirn und dieses Projekt zugeschnitten ist.

Wen’s generell interessiert: Ich habe jetzt meine einfachen Plugins für die Sharecard, Exif-Import und AI-Text veröffentlicht.

Manchmal merkt man erst, wie langsam eine Website geworden ist, wenn man sie selbst aufruft und plötzlich Zeit hat, sich einen Kaffee zu holen.

Genau so ging es mir mit meiner Seite hier: Die Startseite brauchte plötzlich bis zu sechs Sekunden, bis überhaupt etwas passierte. Um mich nicht falsch zu verstehen: bis der erste HTML-Response kam. Danach liefen CSS, JavaScript und Bilder völlig normal durch. Das Problem lag also ziemlich offensichtlich vor dem Browser, irgendwo auf dem Server.

Sechs Sekunden sind nicht nur für einen Androiden, sondern generell im Web eine Ewigkeit. Also habe ich mir Chatty dazugeholt, um mir beim Debuggen zu helfen.

Die Ausgangslage war schnell klar: Der erste Request auf hnz.io/ hing. Danach ging alles zügig weiter. Das spricht meistens dafür, dass der Server beim Rendern der Seite lange beschäftigt ist.

Mein erster Reflex war die klassische Performance-Lösung: Caching.

Der erste Versuch: Staticache

Kirby hat von Haus aus schon ein Caching-Modul an Board, ich habe mich aber zusätzlich noch für Staticache entschieden. Das berechnet im ebsten Fall eine Seite bis zur nächsten Änderung einmal vor und gibt dann die Vorberrechnete Version an die Browser weiter.

Zusätzlich habe ich die gzip-Komprimierung eingeschaltet. Gzip ist eine Technik, mit der Textantworten wie HTML oder CSS kleiner gemacht werden, bevor sie übertragen werden. Das spart Bandbreite und beschleunigt die Übertragung.

Der erste Test brachte allerdings eine kleine Überraschung: Die Startseite brauchte immer noch mehrere Sekunden.

Wenn Caching nicht hilft

Das war der Punkt, an dem klar wurde, dass der Cache gar nicht das eigentliche Problem löst.

Wenn eine Seite trotz Cache mehrere Sekunden braucht, dann passiert eines von zwei Dingen:

• Entweder der Request landet gar nicht im Cache.
• Oder der Request muss trotzdem noch viel dynamische Logik ausführen.

Raten bringt an dieser Stelle nichts. Also haben Chatty und ich angefangen zu messen.

Ein kleiner Performance-Schalter

Ich wollte eine möglichst leichte Lösung, etwas, das direkt auf dem Server mitläuft und nur dann aktiv ist, wenn ich es brauche und habe ich einen kleinen Schalter eingebaut.

Wenn man die Seite mit ?perf=1 aufruft und eingeloggt ist, schreibt die Anwendung Performance-Daten in ein Log. Zusätzlich erscheinen Timing-Informationen im HTTP-Header, die ich dann im Browser anzeigen kann.

Gemessen wurden drei Dinge:

• Bootstrap: der Start von PHP und Kirby
• Renderzeit: das eigentliche Erzeugen der HTML-Seite
• Gesamtzeit: alles zusammen

Zusätzlich habe ich kleine Marker eingebaut, mit denen man bestimmte Stellen im Code messen kann. Wenn ein Snippet oder eine Funktion auffällig langsam ist, taucht sie im Log sofort auf.

Das Ganze ist im Grunde ein sehr einfacher Profiler. Nicht besonders elegant, aber extrem hilfreich.

Die Spur führt ins Rendering

Die Messungen zeigten ziemlich eindeutig, wo die Zeit verloren ging und zwar, und das hat mir ungemein geholfen, nich im Netzwerk, DNS oder im TLS-Handshakke. Die ganze Zeit ging für das PHP-Rendering der Seite drauf: Der Server war mehrere Sekunden damit beschäftigt, die Startseite zu berechnen, bevor überhaupt etwas an den Browser geschickt wurde.

Damit war klar, dass wir uns meine Templates und Snippets anschauen müssen. War ja irgendwie auch klar.

In Kirby sind Snippets kleine wiederverwendbare Template-Blöcke. Man kann sie sich wie Komponenten vorstellen, die HTML generieren.

Viele kleine Verzögerungen

Die Logs zeigten ein interessantes Muster: Der heftigste Block war die Liste der Beiträge auf der Startseite. Das Snippet, das die Feed-Karten erzeugt, brauchte mehrere Sekunden.

Innerhalb dieses Blocks tauchten immer wieder ähnliche Zeitwerte auf. Viele einzelne Schritte lagen jeweils bei ungefähr 300 Millisekunden.

Das klingt erstmal nicht dramatisch, aber wenn ein Feed zehn Beiträge hat und jeder Beitrag mehrere solcher Schritte ausführt, summiert sich das schnell auf mehrere Sekunden.

Ein Beispiel waren Social-Links aus dem IndieConnector. Dabei handelt es sich um Funktionen, die automatisch prüfen, ob ein Beitrag auf Mastodon oder Bluesky veröffentlicht wurde und welche URL dazu gehört. Die hatte ich mal auf die Schnelle eingebaut. Und nun ja.

Man sollte nichts auf die Schnelle einbauen.

Niemals.

Zwar ist die Auflösung auf einer Detailseite völlig okay. Im Feed bedeutet sie aber, dass dieselben Informationen mehrfach berechnet werden.

Dazu kamen kleine Dinge wie Bild-Fallbacks oder Kommentarzählungen, die ebenfalls für jeden Beitrag erneut ausgeführt wurden. Teilweise mehrfach.

Der entscheidende Schritt

Die Lösung bestand letztlich darin, zwei verschiedene Kontexte sauber zu trennen: Die Startseite ist ein Listing. Sie zeigt viele Beiträge gleichzeitig. In diesem Kontext muss alles möglichst leichtgewichtig sein.

Eine Detailseite dagegen zeigt nur einen einzigen Beitrag. Dort kann man sich mehr Rechenzeit leisten.

Also habe ich einige Funktionen im Feed bewusst abgeschaltet oder vereinfacht.

• Social-Links werden im Listing nicht mehr komplett aufgelöst.
• Kommentarzahlen greifen auf bereits berechnete Metriken zurück.
• Einige Bildlogiken wurden reduziert.

Die Detailseiten behalten weiterhin die vollständige Funktionalität.

Das Ergebnis ist eine klare Trennung: Der Feed bleibt schnell, während Detailseiten alle Informationen anzeigen.

Und Chatty hat dabei geholfen, die kritischen Stellen zu identifizieren und die Messungen sauber auszuwerten.

Ein kleiner Nebeneffekt

Während wir ohnehin am Feed gearbeitet haben, habe ich auch die Bildgrößen angepasst.

Die Startseite lädt jetzt kleinere Vorschaubilder. Große Originale werden erst geladen, wenn man sie tatsächlich öffnet.

Das reduziert Bandbreite und sorgt dafür, dass der Browser weniger Arbeit beim Layout hat. Der eigentliche Performance-Gewinn kam aber weiterhin vom Server.

Was ich aus der Geschichte gelernt habe

Die wichtigste Lektion ist überraschend simpel:

• Performanceprobleme löst man nicht durch Rumratwn, sondern durch Messungen Und die Spurensuche hat echt Spaß gemacht, war mein erstes Mal.
• Caching ist hilfreich, aber kein Allheilmittel. Wenn der Flaschenhals im Rendering liegt, muss man verstehen, was genau dort passiert.
• Oft sind es nicht große, offensichtliche Probleme, sondern viele kleine Kosten pro Eintrag.
• Baue niemals auf die schnelle irgendetwas ein, ohne dir vorher Gedanken zu machen oder es zumindest zu testen.

Die letzten Wochen habe ich wieder im Hintergrund an meinem Kirby rumgeschraubt. Oder besser gesagt: rumschrauben lassen. Ich habe Codex mit meinem Visual Studio Code getestet und mal geschaut, wie dieses Vibe Coding so funktioniert. Und ich muss sagen: Zunächst wirkt es wie Zauberei, im Laufe des Projekts wird es dann etwas ernüchternder. Es fühlt sich eben an wie die Arbeit mit einer LLM, die schneller den Kontext verliert, als einem lieb ist, und ab und an schöne Dinge halluziniert. Im Endeffekt ging es trotzdem viel schneller als gedacht.

Mein ursprüngliches Ziel, das Layout komplett konsistent neu aufzuziehen, habe ich dabei allerdings etwas aus den Augen verloren. Manche Rundungen unterscheiden sich noch, manche Schriftgrößen stimmen noch nicht ganz. Aber ich bin auf jeden Fall auf einem guten Weg. Und ja, die Seite sieht jetzt anders aus. Beim ursprünglichen Layout habe ich mich noch stark an meiner alten micro.blog-Seite orientiert. Mit der Zeit und dem ganzen Rumfrickeln passiert es bei mir automatisch, dass ich mich Schritt für Schritt davon emanzipiere.

Was ich eigentlich noch gar nicht einbauen wollte, jetzt aber schon live ist, ist das Medientracking. Da habe ich mich natürlich auch wieder inspirieren lassen.

Felix hat auf seiner Seite einen River aufgesetzt, in den er alles reinschmeißt, was er gut findet oder konsumiert. Thomas hat mit seinem Recorder zwar eine andere Umsetzung, aber ein ähnliches Konzept. Das Leben zu loggen finde ich spannend. Auswertungen und Charts zu generieren finde ich ebenfalls großartig. Und jetzt gibt es das auch hier: Den Medienstrom.

Ich wollte mich dabei am IndieWeb orientieren, bin aber ehrlich gesagt noch in der Findungsphase. Es gibt jetzt die Bookmarks, in die alles reinkommt, was ich so lese und für veröffentlichenswert halte. Dann gibt es das Watchlog mit Videos für YouTube, Filme und Serien. Und schließlich noch den Audiofeed, in den ich alles werfe, was ich gerade höre. All das läuft jetzt im Medienstrom zusammen, den man auch, ich weiß zwar nicht genau warum, als RSS abonnieren kann.

Warum bin ich noch in der Findungsphase? Weil sich das für mich gerade so anfühlt, als wären das gleichzeitig auch Favoriten. Die Trennschärfe fehlt mir noch. Wenn alles klappt, sollen Einbindungen hier als Reposts gesehen werden. Eigentlich sollen sie das auch sein. Oder sind es doch Favoriten, weil ich auf einen bestimmten Text hinweisen möchte oder auf einen besonders guten Tröt? Ich bin da gerade selbst noch etwas verwirrt und hoffe, dass ich das alles so offen gebaut habe, dass ich es bei Bedarf schnell wieder umbauen kann.

Da ich mein eigenes Hirn aber gut kenne und weiß, dass es gerne den Weg des geringsten Widerstands geht, habe ich mir ein paar Prozesse ausgedacht, mit denen Inhalte automatisiert hier landen können. Oder zumindest ohne großen Aufwand.

Filme tracke ich über Letterboxd. Die bieten einen wirklich vernünftigen RSS-Feed an, in dem sogar schon eine TMDB-ID steht. Darüber kann ich mir über die TMDB-API noch zusätzliche Daten zu dem Film ziehen. Ein Importscript sorgt per Cron dafür, dass regelmäßig nachgeschaut wird und neue Filme automatisch hier auf der Seite erscheinen.

Bei Serien nutze ich trakt.tv und dessen API. Dort bewerte ich schnell eine Folge, die ich gesehen habe, und durch ein Importscript landet sie dann auch hier. Wenn ich noch schnell einen Kommentar schreiben möchte, geht das ebenfalls. Und wenn ich den Eintrag später auf die Startseite heben will, klappt das auch noch. Wie zum Beispiel hier.

Ganz automatisch funktioniert auch der Import über meinen RSS-Service Miniflux. Wenn ich dort einen Artikel markiere, habe ich hier einen Endpunkt eingerichtet, der die Daten per POST übergeben bekommt und dann entsprechend darstellt.

Und für den Rest habe ich mir tatsächlich Kurzbefehle auf meinem iPhone gebaut. Das Einrichten war ein ziemlicher Pain. Aber irgendwie hat es funktioniert. Und zwar sogar besser, als ich am Anfang erwartet hatte. Die Kurzbefehle nehmen einfach die URL aus der Zwischenablage, geben mir die Möglichkeit, einen Kommentar zu schreiben, und fragen dann ab, ob der Beitrag im entsprechenden Segment oder auch auf der Startseite veröffentlicht werden soll. So bekomme ich YouTube und Vimeo hier rein und generell Bookmarks, die ich nicht in meinem Feedreader finde.

Bei Podcasts habe ich es mir ehrlich gesagt etwas einfacher gemacht. Ich nutze die App Pocket Casts, die viele Verzeichnisse noch einmal selbst spiegeln. Die Daten hole ich mir dann einfach von dort. Falls ihr euch also fragt, warum meine Podcasts auf Pocketcast.com verlinken und nicht irgendwo anders: Das ist keine Empfehlung für die App oder sogar Werbung, es macht für mich einfach das Teilen leichter.

Deshalb habe ich jetzt auch drei Kurzbefehle. Einen für den Audiostream, einen für Bookmarks und einen für das Watchlog. Über „Teilen“ ist dann schnell ein Beitrag hier angelegt, der zumindest niemanden stört. Und mich freut.