Der Spotify-CEO investiert 700 Millionen Dollar in Kriegsdrohnen — Geld, dass er sich von Millionen Künstler*innen angeeignet hat, die deshalb kaum oder nicht mehr von ihrer Musik leben können. Kündigen jetzt massenweise Menschen ihre Spotify-Accounts? Nein. Es gibt ein paar Musiker*innen, die die Umverteilung von Geld aus kreativer Arbeit hin zu tödlichen Waffen nicht hinnehmen, aber eine große Boykott-Welle bleibt aus.

Ich finde das ein interessantes Phänomen, dass auch in politisch gebildeten und informierten Kreisen so stattfindet. Was macht die Bequemlichkeit indirekter Gewalt so stark? Wer schon einmal versucht hat Menschen davon zu überzeugen Whatsapp, Google oder andere US-Tech-Dienste zu ersetzen weiß, wie groß die Hürde der Bequemlichkeit ist. Und das selbst, wenn die Alternativen sogar besser sind.

Dieser unglaublich starke Sog von Bequemlichkeit scheint ein wichtiger Aspekt des neuen Faschismus zu sein. KI in Form von LLMs ist nur ein weiteres Beispiel dafür. Auch hier schlägt Bequemlichkeit alle Bedenken über Ressourcenverbrauch, illegaler Erwerb der Trainingsdaten oder Manipulation der Ergebnisse durch den Eigentümer. Genutzt wird es trotzdem von vielen, auch auf "linker" Seite.

Dass es bequemer ist sich der Macht zu unterwerfen, ist kein neues Phänomen. Widerstand ist anstrengend. Ein weiterer Aspekt ist bestimmt auch die zunehmende Monopolisierung einzelner Konzerne, sodass manche Produkte und Dienstleistungen manchmal so gut wie alternativlos geworden sind.

Aber im Falle von Spotify gibt es SoundCloud, Apple Music, Tidal und weitere Anbieter. Sie haben sicherlich auch keine weiße Weste, aber zumindest gibt es keine Nachrichten über sie, dass sie einen großen Teil ihres Gewinns in computergesteuerte Kampfdrohnen stecken. Erreichen diese Informationen die Menschen nicht mehr? Oder gibt es einfach eine Gleichgültigkeit gegenüber militärische Investments aufgrund der Wahrnehmung, dass unsere Weltlage unsicher sei?

Was es auch ist, ich glaube, dass der Sog der Bequemlichkeit von manchen erkannt und bewusst für ihre Zwecke genutzt wird. Die offene Frage ist, ob demokratische Mitbestimmung auch so bequem werden kann.

Meine Seite läuft jetzt mit Kirby 5. Eigentlich schon etwas länger, weil das POSSE plugin schon vor mehreren Tagen aktualisiert wurde. Ich konnte allerdings bisher nichts posten, weil es einen ungelösten Bug in Kirby 5 gibt, der dafür sorgen kann, dass neue Pages keine neue UUID bekommen.

Ich hatte mich erst über den unkomplizierten Prozess des Updates gefreut, aber als ich freudig darüber berichten wollte, bekam ich beim Erstellen einer neuen Seite für meinen Post den Fehler. Heute hab ich versucht das Problem zu debuggen und konnte den Fehler auch beheben, indem ich Kirby’s __new__ Ordner gelöscht habe.

Falls ihr nach dem Update von Version 4 auf 5 auch keine Seiten erstellen könnt, weil die UUID angeblich vergeben sei, könnte das Löschen des Ordners auch euer Problem lösen.

Auch wenn meine Seite noch nicht mit Kirby 5 läuft, weil das POSSE plugin noch nicht aktualisiert wurde, hab ich bereits auf anderen Seiten das Update auf Version 5 durchgeführt und ein paar mögliche Probleme bei der Aktualisierung gefunden.

Mit Kirby 5 kann man zum ersten Mal Änderungen vor dem Speichern als Vorschau anzeigen lassen. Das ging vorher nur, wenn man Seiten duplizierte. Jetzt gibt es sogar einen Split-View, um die aktuelle Version und die geänderte Version nebeneinander anzuzeigen bevor man Änderungen speichert. Als ich das zum ersten Mal auf einer Seite mit Kirby 5 ausprobiert hatte, ging die Vorschau allerdings nicht. Das lag an zwei Dingen.

Erstens hatte ich relativ strikte Header in dem Caddy-Server konfiguriert, die das Einbetten der Seite als iframe verhindern. Kirby’s Vorschaufunktion nutzt aber iframes, um Änderungen anzuzeigen. Die Lösung war die Caddy-Konfiguration anzupassen und den Header X-Frame-Options von deny auf same-origin zu stellen. Das erlaubt die Seite unter der gleichen Domain als iframe einzubetten, also genau das was Kirby macht. Nach der Änderung in der Konfiguration muss der Caddy-Service neu gestartet werden: systemctl restart caddy. Danach hat die Vorschau über die iframes funktioniert.

Dann bin ich allerdings auf ein zweites Problem gestoßen: Die Änderungen wurden in der Vorschau nicht angezeigt oder manchmal nur beim ersten Mal. Hier lag es an dem Caching, das ich in Cloudflare konfiguriert hatte. Wie ich Kirby-Seiten in Cloudflare cache, will ich demnächst noch in einem Blog Post teilen. Für die Vorschau in Kirby 5 war die Lösung eine neue Cache Regel anzulegen, die das Caching für alle URLs mit dem Query Parameter _token abschaltet. Dieser Parameter wird von Kirby an alle URLs der Vorschau-iframes übergeben.

Also hab ich eine neue Cache Rule erstellt, unter Custom Filter Expression bei Field die Einstellung Query String Parameter ausgewählt, bei Operator wildcard und bei Value den Wert _token=*.

Darunter noch Cache eligibility und Browser TTL auf Bypass Cache stellen und alle URLs mit dem Query Parameter _token werden von Cloudflare nicht mehr gecachet.

Mit diesen Änderungen bei Caddy und Cloudflare, funktioniert das Vorschau-Feature von Kirby 5 jetzt ohne Probleme. Ich freue mich schon Version 5 bald auch auf meiner Seite zu nutzen.

Das Kirby POSSE plugin von Philipp Defner läuft bei mir jetzt als composer package und mit der neusten Version. Dadurch kann ich einen Token direkt über die Einstellungen des Plugins konfigurieren. Vor der aktuellen Version hatte ich den Code des Plugins eingecheckt und angepasst, damit API Aufrufe auch über einen Token authentifiziert werden können. Das bietet die neue Version des Plugins jetzt selbst ans.

Philipp arbeitet gerade auf einer Branch schon an der nächsten Version, in der Templates für Posts über das Plugin als Snippets konfiguriert werden können. Bisher war meine Erfahrung mit Kirby-Plugins eher mittelmäßig, aber das Plugin funktioniert sehr zuverlässig. Ich empfehle selbst einmal durch dessen Code zu lesen. Er ist sehr gut strukturiert und hat eine hohe Qualität.

PS: GitHub scheint gerade aus irgendeinem Grund nicht die neuste Version der README auf der Seite des Repositorys anzuzeigen. Wenn ihr die REAME.md direkt öffnet, wird aber die neuste Version der Dokumentation inklusive Token korrekt dargestellt.

PPS: Meine Notizen haben jetzt auch ein neues Metabild, das näher am leicht veränderten Design meiner Webseite ist.

Der PHP-Prozess auf meinem Server ist in unregelmäßigen Abständen abgestürzt, wodurch dann alle Kirby-Seiten nicht mehr erreichbar waren. Ein manueller Neustart des FPM-Prozesses hat das Problem immer behoben, aber das ist natürlich keine langfristige Lösung. Also hab ich mich auf die Suche begeben, wodurch der Fehler entsteht.

Der erste Schritt war im PHP Log nachzuschauen, ob es eine Fehlermeldung gab:

cat /var/log/php8.3-fpm.log

Und tatsächlich wurde dort auch eine Warnung festgehalten, kurz bevor die Seiten nicht mehr erreichbar waren:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

Über eine schnelle Suche im Internet bin ich auf diesen sehr guten Post von Chris Moore gestoßen, der erklärt was pm.max_children und die weiteren Einstellungen bedeuten. Anscheinend hab ich das Problem, dass zu viele Menschen oder Bots gleichzeitg auf meine Seite kommen, sodass der FPM-Prozess die Anfragen mit den aktuellen Einstellungen nicht beantworten kann.

Chris Moore hat einen PHP-FPM Process Calculator entwickelt, mit dem man ausrechen kann, welche PHP-Konfiguration für die Leistung des eigenen Servers sinnvoll sein könnte.

Um die passenden Werte berechnen zu können, müsst ihr wissen, wie viel RAM euer Server hat und was die durchschnittliche Prozessgröße der aktuellen FPM-Prozesse ist. Um diese zu ermitteln, kann man folgenden Befehl ausführen:

ps -C php-fpm8.3 -o rss=
// mögliche Rückgabe auf eurem Server:
    31252
    44488
    43116
    39544

Die erste Zahl ist der Hauptprozess, der für die Berechnung laut Chris nicht relevant ist. Die anderen Zahlen sind die Subprozesse in Kilobyte. In dem Beispiel nutzen die Prozesse also ca. 39 bis 45 Megabyte.

Ich würde mich sicherheitshalber an der höheren Zahl orientieren (45 MB) und sie als Wert in den Calculator von Chris Moore als Process size (Mb) eintragen. Außerdem stellt ihr noch den RAM eures Servers ein, wie viel RAM ihr für andere Prozesse frei halten wollt und einen zusätzlichen prozentualen Puffer.

Die errechneten Werte aus dem Calculator passt ihr dann in der PHP Konfiguration an:

nano /etc/php/8.3/fpm/pool.d/www.conf

Nachdem ihr die Werte in der Datei geändert habt, muss der PHP-FPM Prozess neugestartet werden:

systemctl reload php8.3-fpm.service

Danach werden beim Ausführen von ps -C php-fpm8.3 -o rss= wahrscheinlich mehr oder weniger Prozesse anzeigt als vorher, je nachdem welche Werte ihr in der Config eingetragen habt.

Hinweis: Wenn ihr eine andere PHP-Version verwendet müsst ihr 8.3 bei allen Befehlen in eure PHP Version ändern.

Ich habe zusätzlich noch das Caching für meine PHP-Seiten angepasst, damit trotz mehr Ressourcen für die PHP-Prozesse weniger Traffic beim Server ankommt. Durch die beiden Änderungen hoffe ich, dass das Problem gelöst ist und PHP nicht mehr abstürzt. 🤞

Falls das nicht ausgereicht hat, werde ich mich erneut auf die Suche nach einer Lösung begeben und hier berichten.

Ich teste gerade das POSSE plugin von Philipp Defner. Wenn der cronjob funktioniert, sollte diese Notiz mit etwas Verzögerung automatisch bei Mastodon landen. Die direkte Veröffentlichung meiner Notiz über das Panel UI des Plugins hat schon direkt funktioniert. 🙂

„Der Kaiser ist nackt!“, möchte ich jedes Mal schreien, wenn wieder jemand sagt, dass "KI" alles verändern wird.

Wenn man nachfragt, wie genau "KI" alles verändern wird (obwohl jedes Hype-KI-Unternehmen Milliardenverluste schreibt und niemand so genau weiß, was man mit Chatbots nun genau machen soll, die nur mit einer 50-50 Chance oder schlechter das gewünschte Ergebnis liefern und dafür Unmengen an Energie verbrennen) wird auf eine Zukunft verwiesen, in der auf magische Art und Weise "KI" plötzlich all das kann, was es heute überhaupt nicht kann.

Erst mussten wir den Blockchain-Hype ertragen, dann den Metaverse-Hype, dann den VirtualReality-Hype und jetzt den KI-Hype. Immer wieder wird uns versichert, dass die neue Technologie alles verändern wird. Dass das alles nur der Anfang sei, die Technologie noch massive Sprünge machen wird, es ganz viele Anwendungsfälle gibt und wir jetzt vor allem ganz vorne mit dabei sein müssen, um nicht ersetzt zu werden. »Fürchte dich, durch meine Technologie ist deine Lohnarbeit in Gefahr!« Zeitungen und Medien übernehmen und verbreiten völlig unkritisch die PR-Mitteilungen der Tech-Konzerne. LinkedIn-Influencer ändern fleißig ihre Bios und werden über Nacht zu Experten. Und auch die Wirtschafts- und Investment-Bubble kennt über Monate nur noch dieses eine Thema.

Solange "KI" noch nicht durch den nächsten Hype abgelöst wurde, werden weiterhin ChatBots und "Agents" ohne Sinn und Verstand in jede erdenkliche Software gepresst, die wir nutzen. Dabei geht es nicht darum irgendeinen Mehrwert oder Nutzen zu schaffen, sondern einfach nur die Investment-Blase weiter zu füllen und den Shareholder-Value zu steigern.

Vielleicht würde mich der KI-Hype heute weniger nerven, wenn ich meine ganze Karriere nicht in der Tech/Software-Branche gearbeitet hätte. Meine Arbeit ist Software zu entwickeln, deshalb ist es schwer den Hype-Wellen aus Silicon Valley zu entfliehen. Mit "KI" wurde aber ein neues Level erreicht. Jetzt begegnet mir der Marketing-Bullshit auch außerhalb der Tech-Bubble, sei es in Meetings mit Menschen aus anderen Bereichen, beim Abendessen mit Freunden oder beim Besuch der Eltern.

Der bekannte Designer Bret Victor wurde peinlicherweise auf der letzten Pressekonferenz von Figma zitiert bevor sie ihre neusten AI-Features vorgestellt haben. Anscheinend haben sie überhaupt nicht verstanden, worin das Ziel und die Leistung seiner Arbeit steckt. Ich zitiere stattdessen den letzten Satz auf seiner Webseite und schließe mich ihm voll an:

“Do not talk to me about AI.”

Ich habe gerade die Jung & Naiv Suche aktualisiert. Sie nutzt jetzt Version 0.8 von flexsearch, die den Fehler aus 0.7 behebt, dass beim Exportieren vom Suchindex selbst hinzugefügte Felder fehlen.

Durch den Bug der vorherigen Version musste der Index deshalb im Browser erstellt werden. Wer bisher auf die Seite kam, hat gesehen, dass im ersten Schritt alle Untertiteldateien aller Videos geladen wurden. In einem zweiten Schritt wurde dann noch lokal ein neuer Suchindex erstellt, indem alle geladenen Dateien durchlaufen und zum Index hinzugefügt wurden.

Durch den Bugfix der neuen Version können Indizes korrekt exportiert und importiert werden. Deshalb kann der Index jetzt heruntergeladen und importiert werden. Der zweite prozessorlastige Schritt fällt also weg und der erste Schritt lädt jetzt den fertigen Suchindex herunter, statt die rohen Untertiteldateien.

Der neue Nachteil ist, dass der gesamte Index für alle "Jung & Naiv" Videos mit 500 MB ziemlich groß geworden ist. Vor der Suche muss also ein halber Gigabyte heruntergeladen werden. Das ist nicht besonders datenschonend.

flexsearch hat mit der Version 0.8 die Möglichkeit erhalten Indizes auf verschiedene Arten persistent zu speichern. Statt in mehreren Dateien kann ein Suchindex auch im Browser mit IndexedDB, aber auch auf dem Server mit SQLite, Redis oder Postgres importiert und durchsucht werden.

Ich werde deshalb dem Projekt demnächst eine Datenbank hinzuzufügen, sodass der halbe Gigabyte große Index auf dem Server liegt und nur noch Suchbegriff und Ergebnisse zwischen Server und Browser ausgetauscht werden. Weil das Projekt aber noch bei Vercel liegt, statt auf meinem Server, braucht es auch ein neues Server-Setup, um das kostengünstig zu ermöglichen. Wenn ich das Projekt auf einen neuen Server umziehe, sollte der gleich mit Coolify oder Dokploy gemanagt sein. Außerdem läuft das Projekt noch mit Svelte 4, was nicht mehr aktuell ist. Und dann wärs natürlich noch schön, wenn neue Videos automatisch zum Suchindex hinzugefügt werden würden, statt dass ich ab und zu manuell Skripte dafür ausführen muss.

Es gibt also noch einiges zu tun, um das Projekt wirklich automatisiert und zugänglich für alle zu machen. Ich bleibe weiter dran, weil das ganze Self-Hosting-Thema mich sowieso sehr interessiert und ich darin noch deutlich mehr Erfahrung sammeln möchte.

Wenn es um Entscheidungen geht, erlebe ich selbst in demokratiefördernden Organisationen ein starkes Schwarz-Weiß-Denken. In den Diskussionen über Entscheidungsprozesse gibt es häufig nur zwei Optionen: „ich entscheide“ oder „jemand anderes entscheidet.“

Selbst zu entscheiden wird mit Freiheit, Selbstbestimmung und Selbstverwirklichung begründet. Diese Haltung kommt häufig aus dem Bereich der Selbstorganisation und New Work. Andere entscheiden zu lassen wird vor allem mit Pragmatismus, Effizienz oder Alternativlosigkeit begründet. Sie kommt vor allem aus hierarchisch geführten Unternehmen, weil die Hierarchie die häufigste Organisationsform und somit den meisten Menschen auch bekannt ist.

Gemeinsame Entscheidungsprozesse liegen hingegen nur selten auf dem Tisch. Obwohl gemeinsames Entscheiden die größte Vielfalt an Gestaltung und Prozessen bietet, beschränkt sich das Wissen der meisten Menschen auf nur zwei Arten: Konsens und Mehrheitsentscheid, die beiden schlechtesten Varianten des gemeinsamen Entscheidens. Wir haben eine riesige Bildungslücke bei gemeinsamen Entscheidungsprozessen. Weil nur die beiden schlechtesten Varianten bekannt sind, hat gemeinsames Entscheiden auch einen schlechten Ruf und wird dadurch in Diskussionen über das Entscheiden nur noch selten als Option aufgemacht.

Dabei sind Präferenzwahl, Bewertungswahl und systemisches Konsensieren Entscheidungsprozesse, die die negativen Aspekte des Konsens- und Mehrheitsverfahrens schon lange hinter sich gelassen haben. Sie sind schnell, einfach, erlauben differenzierte Mitbestimmung und führen zu Prozessen, in denen sich alle Menschen auch gehört fühlen. Der wichtigste Grund für uns konsens zu entwickeln und kostenlos zur Verfügung zu stellen war, dass wir das Wissen und die praktische Erfahrung mit gemeinsamen Entscheidungsprozessen stärken wollen.

Vor allem in demokratiefördernden Organisationen müssten demokratische Entscheidungsprozesse die Norm statt die Ausnahme sein, weil ohne demokratische Praxis im Alltag fehlt die Erfahrung mit demokratischen Prozessen. Und wenn die Erfahrung fehlt, wird gemeinsames Entscheiden unnormal, abwegig und schlimmstenfalls irgendwann auch als schlecht bewertet.

Das Ziel von Demokratie ist, dass möglichst jeder Mensch an Entscheidungen, die ihn betreffen, mitwirken kann. Das Ziel von Demokratie ist die Maximierung der Freiheit aller Menschen. Maximale Freiheit kann mit Einzelentscheidungen aber niemals erreicht werden. Das Normalisieren von Einzelentscheidungen verringert aktiv die Freiheit von Menschen, die nicht mitentscheiden, und schadet damit der Demokratie. Um Demokratie und Freiheit zu stärken, müssen deshalb Einzelentscheidungen zur Ausnahme und gemeinsame Entscheidungen zur Norm werden.

Es geschehen gerade sehr viele negative Dinge in unserer Welt, die wir nur schwer beeinflussen können. Aber es gibt auch einen riesigen Bereich, den wir jeden Tag aktiv gestalten. Alle Organisationen, die sich als Ziel gesetzt haben Demokratie zu stärken, sollten gerade jetzt ihre eigene demokratische Praxis überprüfen und erhöhen. Wer jeden Tag mehr Mitbestimmung, Gemeinschaft und Wirksamkeit erfährt, kann diese Energie, das Wissen und die Erfahrung auch nach außen tragen und mit anderen teilen.

Demokratie und Freiheit zu stärken bedeutet ganz konkret im Alltag, dass alle Menschen mehr gemeinsam entscheiden als bisher.

Nachdem ich heute meine Lösung geteilt hab, den <title> im lokalen Kirby-Panel anzupassen, sodass er sich vom Live-CMS unterscheidet, hat mir Thomas Günther auf Mastodon geantwortet.

Kirby bietet die Möglichkeit über die config auch das Favicon zu ändern. Das ist noch sauberer und für mich deshalb die bessere Lösung. Der einzige Nachteil ist, dass man ein gutes Bild fürs Favicon braucht. 🖼️

Da ich jetzt schon mehrfach den Fehler gemacht hab Inhalte im lokal laufenden Kirby statt auf der Live-Seite zu erstellen, wollte ich den Unterschied zwischen lokalem CMS und Live-CMS im Tab sichtbar machen.

Um eigenes JavaScript im Kirby-Panel auszuführen, reichen ein paar Zeilen in der config Datei für die lokale Instanz, die auf die zu ladende JavaScript-Datei verweist:

'panel' => [
  'js' => 'assets/js/panel.js',
],

Innerhalb von panel.js hab ich eine Funktion geschrieben, die ein Emoji vor den Titel der Seite hängt. Alle Tabs mit lokalem Kirby sind dadurch leicht erkennbar. Das Hinzufügen des Emoji wird durch einen MutationObserver ausgelöst, der auf Änderungen reagiert:

function updateTitle() {
  if (!document.title.startsWith("⚙️")) {
    document.title = "⚙️ " + document.title;
  }
}

new MutationObserver(updateTitle).observe(document.querySelector("title"), {
  childList: true,
});
document.addEventListener("DOMContentLoaded", updateTitle);

Wahrscheinlich gibt es noch eine "sauberere" Variate, die auf Vue.js und Kirbys Panel reagiert. Der Vorteil dieser Variante ist, dass der Code auch weiterhin funktioniert, wenn Vue.js oder Kirby neue APIs nutzen oder Kirby zu einem ganz anderen Framework wechseln sollte.

Mein Kirby Panel begrüßt mich jetzt freundlich und fragt mich, was ich tun möchte:

Es gibt leider kein type: button in Kirby, deshalb hab ich ein Info Feld mit Link verwendet. Der entsprechende Teil im Blueprint für das Design oben sieht so aus:

fields:
  headline:
    label: Hey Max 👋
    type: headline
    help: Was möchtest du tun?
  notizenLink:
    label: ""
    type: info
    theme: warning
    text: |
      **(link: /panel/pages/notizen text: Notiz erstellen)**
    width: 1/5
  notesLink:
    label: ""
    type: info
    theme: warning
    text: |
      **(link: /panel/pages/notes text: Add note)**
    width: 1/5
  blogLink:
    label: ""
    type: info
    theme: passive
    text: |
      **(link: /panel/pages/blog text: Blog schreiben)**
    width: 1/5
  line:
    type: line

Durch Kirby läuft meine Webseite zum ersten Mal mit einem richtigen CMS. Die Möglichkeit Seiten zu bearbeiten, möchte ich deshalb so einfach und bequem wie möglich machen. Wenn mir z.B. ein Tippfehler auffällt, will ich ihn schnell korrigieren können.

Ich wollte aber keinen Button zu meiner Seite hinzufügen oder irgendwo verstecken und auch keine Logik schreiben, um ihn nur anzuzeigen, wenn ich im CMS angemeldet bin. Wie kann ich trotzdem schnell ins CMS zum Bearbeiten der aktuellen Seite wechseln?

Mit einem Keyboard-Shortcut!

Ein paar Zeilen JavaScript reichen aus, um Browser auf die entsprechende Panel-URL von Kirby weiterzuleiten. Die Entscheidung welches Tastenkürzel es sein soll, war gar nicht so einfach zu treffen. Ich hab mich letztendlich für Cmd+Opt+. entschieden. Die Kombination ist eher unüblich, gleichzeitig noch bequem genug, aber trotzdem relativ unwahrscheinlich, dass man sie versehentlich nutzt.

Wenn ihr auch einen Keyboard-Shortcut auf eurer Webseite haben wollt, um direkt ins Panel zum Bearbeiten der aktuellen Seite zu springen, könnt ihr euch folgenden JS-Code kopieren (und mit der Tastenkombination eurer Wahl anpassen):

window.addEventListener("keydown", (event) => {
  if (event.metaKey && event.altKey && event.code === "Period") {
    const url = new URL(window.location.href);
    window.location.href = `${url.origin}/panel/${
      url.pathname === "/"
        ? "site"
        : "pages/" + url.pathname.slice(1).replace("/", "+")
    }`;
  }
});

Update: Der JS-Code leitet jetzt auf der Homepage zur Startseite des Panels weiter, statt auf eine falsche Panel-URL. Falls ihr lieber beim Bearbeiten der Homepage landen wollt, ersetzt "site" mit "pages/home".

Ich bin mir nicht sicher, welche HTML Tags RSS Reader unterstützen. Deshalb teste ich mit dieser Notiz einmal verschiedene Tags:

• Eine Liste
• mit mehreren Punkten

Eine Zwischenüberschrift

Das ist ein Zitat.

<web-component>Code-Test</web-component>

Funktioniert eine Linke mit <hr>?

---

Die Linie sollte über diesem Text angezeigt werden.

Wie sieht es mit <details> aus? Kann man Klapptexte in RSS Readern haben?

Das ist die Vorschau

Hier ist der Text innerhalb von <details>.

So das waren erstmal alle Tests. Die Tags, die nicht funktionieren, werde ich in Kirby für meine Notizen deaktivieren.

Ich steigere lieber menschliche Intelligenz als künstliche.

Ich hab diese simple Definition von Wissenschaft auf Bret Victor’s Webseite gefunden und wollte sie hier teilen und festhalten.

“Rhetoric” is trying to convince others that you’re right.

“Science” is trying — by every conceivable means — to convince others that you’re wrong, and failing.

Übersetzt auf Deutsch:

„Rhetorik“ ist der Versuch, andere davon zu überzeugen, dass man Recht hat.

„Wissenschaft“ ist der Versuch, andere mit allen erdenklichen Mitteln davon zu überzeugen, dass man im Unrecht ist und dabei scheitert.

Seit wenigen Minuten läuft meine Seite über Kirby statt Astro. Bisher sollte alles größtenteils beim alten sein. Nur ein paar URLs haben sich geändert und werden jetzt auf neue weitergeleitet.

Außerdem haben sich die URLs von meinen RSS-Feeds geändert. Laut der RSS-Spezifikation sollten RSS-Reader einen 301 Redirect erkennen und automatisch auf die neue Feed-URL wechseln. Ob das wirklich funktioniert, wird diese Notiz zeigen. Wenn es klappt, sollte sie gleich in meinem Reader erscheinen. 🤞

Update: Meine Notizen werden jetzt mit scroll-driven animations eingeblendet. Ich wollte diese neue Browser API schon lange ausprobieren und meine eigene Webseite ist der beste Testraum, um neue technische Möglichkeiten auszuprobieren.

Die scroll() Timeline hat sofort funktioniert, aber die view() Timeline nicht. Es hat eine Weile gedauert bis ich herausgefunden habe, dass wenn ein parent element overflow: hidden hat, die view-Timeline nicht mehr funktioniert. Falls ihr also auch noch keine Erfahrung mit scroll-driven animations gemacht habt und eure view() timeline irgendwie nicht funktionieren will, dann schaut mal auf den Elternelementen nach, ob irgendwo overflow auf hidden gesetzt ist.

Die neuen CSS-Zeilen für die Animation sehen übrigens so aus:

.note {
  @media (prefers-reduced-motion: no-preference) {
    animation: linear scale-up;
    animation-timeline: view();
    animation-range: entry 0% entry 50%;
  }
}

@keyframes scale-up {
  from {
    opacity: 0.5;
    transform: scale(0.95);
  }
  to {
    opacity: 1;
    transform: scale(1);
  }
}

Ich musste noch ein paar technische Änderungen an meinen Feeds machen. Ich fand dabei dieses Tool zum Validieren der RSS Struktur hilfreich. Andere Tools, die ich vorher ausprobiert hatte, haben mein Feed zu lange im Cache behalten, sodass Änderungen nicht neu validiert wurden.

Wenn alles glatt läuft, wird beim Veröffentlichen dieser Notiz außerdem auch der Cloudflare Cache automatisch geleert, damit ich das nicht mehr manuell machen muss. 🤞

Ein weiteres kleines Update heute: Mein RSS Feed zeigt jetzt in euren Feed Readern auch meine Illustration als Logo an. Ich bin mir nicht ganz sicher, ob es die zusätzlichen Favicons oder die Ergänzungen im RSS Feed war, die das Problem behoben haben. Wahrscheinlich gehen die Feed Reader unterschiedlich mit Bildern um und man muss sowieso verschiedene Möglichkeiten angeben, damit sie das Bild auch finden. In meinem Feed wird das Logo für meine Seite jetzt korrekt angezeigt.

Vorher hatte ich nur eine einzige PNG-Datei als Favicon im <head> angegeben. Dann hab ich wie immer das fantastische Tool RealFaviconGenerator genutzt, um mehrere Favicon-Dateien und den dazugehörigen Code zu generieren, damit es auch möglichst überall korrekt angezeigt wird.

Außerdem hab ich in der RSS Spezifikation und anderen RSS Feeds mit Logo gesehen, dass es <image>, <logo> und <icon> Elemente gibt. Also hab ich die auch direkt noch hinzugefügt.