(album: himmelfahrt)

Ein neues Album von Subway to Sally! Schön, aber auch egal. Ein paar Lieder sind okay, zwei, drei sind so, dass ich sie mir fast in eine Playlist packen würde. Das Album enthält noch Akustik-Versionen von ein paar Songs, die sind besser als die normalen Mixe. Das Highlight ist allerdings So Rot, was eigentlich auf Herzblut ist. Die neue Version ist immerhin der beste Song auf Himmelfahrt, aber natürlich keine wirkliche Verbesserung zum Klassiker von 2001.

Ich bin ja schon ein großer Fan von Let’s Encrypt. Ich gab in meinem Leben bestimmt fast 100€ für SSL-Zertifikate aus, damals, als sie noch nicht kostenlos waren.

Seit einigen Jahren gehört certbot für mich nun zum Standard Werkzeugkasten. So ein Tool, das man ständig installiert, wenn man mal eben ein SSL-Zertifikat braucht. Doch etwas störte mich immer. Ich glaube mich zu erinnern, dass ich am Anfang ab und zu ein paar Python-Probleme hatte. Jahre später musste ich plötzlich unter Debian snapd und so Kram installieren, um am certbot zu kommen. Alles machbar, fühlte sich aber nach Overhead an. Mittlerweile scheint es wieder ein direktes Debian-Paket zu geben, immerhin.

Heute baute ich an einem kleinen Script, mit dem ich einfache HTML-Seiten leichter deployen kann. Fast so, als würde ich Vercel benutzen, oder sowas. Will ich natürlich nicht, mehr dazu in einem anderen Post. Jedenfalls stand ich vor dem Problem, certbot benutzen zu wollen, um ein SSL-Zertifikat zu generieren, allerdings ohne, dass der ausführende User root ist. Direkt schlug es fehl, weil er nginx nicht steuern konnte und keine Ahnung. Statt zu versuchen, es mit certbot zum Laufen zu kriegen, fiel mir acme.sh vor die Füße.

Dabei handelt es sich um einen ACME-Protokoll-Client, der einfach in Shellscript geschrieben ist. Keine Abhängigkeiten! Außerdem schafft er es, Zertifikate zu beantragen, ohne root-Rechte zu benötigen. Also, vielleicht wäre das mit certbot auch gegangen, aber acme.sh hat mich auch so sofort überzeugt und wird ein neuer Teil des Werkzeugkastens!

Ich muss ja sagen, dass ich mich langsam an Docker gewöhne. Letzten habe ich gelernt, dass Docker Volumes eigentlich ganz schlau sind. Bisher habe ich eigentlich nie welche verwendet und immer direkte Filesystem-Mounts benutzt, doch jetzt im Zuge meiner großen Server-Konsolidierung, wo ich versuche, das meiste auf Docker umzustellen, hab ich mich nochmal tiefer eingelesen und habe nun weniger gefährliches Halbwissen!

Tatsächlich kam meine Abneigung zu Volumes wahrscheinlich daher, dass sie am Anfang unter MacOS (vielleicht immer noch?) halt nicht so funktionierten, wie ich das gerne wollte — in einem Dev-System will man ja immer direkten Zugriff auf die Daten, also zumindest, wenn man PHP entwickelt. Da mussten es natürlich direkte Filesystem-Mounts sein und die waren langsam und allgemein war Docker auf dem Mac am Anfang ja eher schwierig und hat bei mir zu großer Abneigung geführt.

Nun, informierter, und in einer anderen Umgebung, ich will ja jetzt keine Dev-Umgebungen deployen, sondern… funktionierende Anwendungen, weiß ich es plötzlich zu schätzen. Alles ist etwas aufgeräumter, und sauberer. Vielleicht ist es auch noch ein wenig schneller! Das wichtigste Feature für mich ist allerdings, dass Volumes beim Start des Containers mit dem Inhalt aus dem Container vorgefüllt werden! Das finde ich ein grandioses Feature.

In meinem Post zu Kioski, meiner Homeassistant-Sonos-Steuer-App, gab ich, unwissend, noch folgenden Schnipsel zum Starten an:

touch db.sqlite
docker run -d \
 -p 127.0.0.1:9901:9901 \
 -v $(pwd)/db.sqlite:/app/database.sqlite \
 ghcr.io/pwaldhauer/kioski:latest

Mit Volumes könnte man das Touchen der Datenbank nun einfach weglassen. Er würde einfach die (leere) Datenbank aus dem Image nehmen und sie beim Initialisieren des Volumes dort hin kopieren. Nice!

Zusätzlich könnte man, wenn man wollte, die Volumes auch per NFS oder sonstwas einbinden, da gibt es tausend Möglichkeiten, die man mit den Filesystem-Mounts nicht hat. Gute Sache!

Nach langem Überlegen, ob ich mein Kirby-ActivityPub-Plugin noch weiterentwickle und Dinge wie Likes und Boosts einbaue, habe ich beschlossen es nicht zu tun und es zu archivieren. Ich werde es auch hier im Blog entfernen und nicht weiter benutzen, der knuspermagier@knuspermagier.de Account wird damit auch nicht weiter befüllt werden.

Warum, fragt ihr euch vielleicht. Tja. Die Antwort ist vielschichtig, aber ich glaube, es ist einfach Quatsch. Erstens booste ich eh jeden Post vom Blog-Account, da kann ich die Links zu den Blogposts auch direkt posten, oder mit einem Script automatisch zu meinem Mastodon-Account schieben.

Zwar war es ganz lustig, das Plugin zu entwickeln und dabei viel über ActivityPub zu lernen, aber um einen richtigen Mehrwert daraus zu ziehen, hätte ich noch einiges einbauen müssen. Wäre ja zum Beispiel ganz nett, wenn ich als der Blog-Account mit Leuten reden könnte, die zum Beispiel auf einen der Posts per Reply reagiert haben. Letztendlich müsste das Kirby-Plugin ein kompletter ActivityPub-Client sein. Im Idealfall müsste er auch noch die Mastodon REST-API nachbauen, damit ich z.B. mit einem iOS-Client wie Ivory damit schreiben kann. Das ist alles völlig out of scope für ein Kirby-Plugin.

Die Frage ist auch, was es mir bringt, den Blog als eigenes ActivityPub-Ding zu haben. Aktuell gefühlt wirklich gar nichts. Der Blog wird ja hauptsächlich über RSS gelesen, oder über diese Webseite und nicht in einem ActivityPub-Client. Wäre auch etwas kurios, da ganze Blogposts in einer Timeline zu haben.

Ich habe noch kurz darüber nachgedacht, den Blog-Account weiterleben zu lassen und zum Beispiel einen leichtgewichtigen ActivityPub-Server wie GoToSocial aufzusetzen. Dort könnte ich auch automatisiert meine Posts hinschicken und… von meinem Hauptaccount boosten. Da seht ihrs, es wäre auch Quatsch. Wer pwa@norden.social folgt, der wird eh alle Blogposts mitbekommen und wer sollte meinem Blog folgen, ohne auch Zugriff auf meine sonstigen, sehr wichtigen und gehaltvollen Toots haben zu wollen?

Es war eine schöne Woche, in der ich das Plugin baute, aber nun bin ich auch froh, dass ich mir keine Gedanken mehr darüber machen muss! Bye, bye!

Heute hatte ich ein kleines Verständnisproblem in meinem Seeder und wollte daher mal notieren, wie es richtig geht.

Folgendes Problem: Ich habe, sagen wir mal, ein Model Post, das eine user_id hat.

Wenn ich nun ganz viele Posts in die Datenbank seede, möchte ich zwar, dass jeder mit einem User verbunden ist, aber ich will nicht, dass jeder Post auch seinen ganz eigenen User erstellt. Da kommt nun die recycle-Methode zur Anwendung

// PostFactory.php
public function definition(): array
{
    return [
        'text' => 'Hallo!',
        'user_id' => User::factory(),
    ];
}

// DatabaseSeeder.php
$users = User::factory()->count(10)->create();

Post::factory()
    ->recycle($users)
    ->count(100)
    ->create();

Nutzt man bei der PostFactory, wie dargestellt, nun recycle, führt das dazu, dass er die entsprechenden Models nutzt, statt Neue zu erstellen, wie toll ist das denn!

Damit der Post nicht nur hilfreich, sondern auch unterhaltsam ist, hier noch den Fehler, den ich machte, weshalb alles nicht funktionierte:

// DatabaseSeeder.php
$users = User::factory()->count(10)->create();

Post::factory()
    ->recycle($users)
    ->for(User::factory())
    ->count(100)
    ->create();

Ich versuchte recycle gemeinsam mit for zu benutzen. Das klappt zwar an sich auch, aber jeder Post bekommt leider den gleichen User, weil das for für alles gilt, was aus der Factory fällt. Ist also gar kein Fehler von recycle, sondern nur ganz allein meiner.

Wenn man kurz nacheinander mehrere Projekte startet, möchte man ungern immer wieder alles von vorne bauen. Vor allem Formularfelder, oder so einen Quatsch.

Ich schrieb mir bei Kioski also schon ein paar Blade-Komponenten und wollte die in Konpasu nun weiterverwenden, doch wie mache ich das am Besten?

Composer

Der erste Schritt war erstmal, die Komponenten in ein eigenes Composer-Package auszulagern. Dazu kopierte ich alles in einen Ordner und legte einen ServiceProvider an, der Laravel mitteilt, wo der Kram nun liegt:

final class PwaBluiServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Blade::anonymousComponentPath(__DIR__ . '/../resources/views/components', 'pwablui');
        Blade::componentNamespace('PwaBlui\\Views\\Components', 'pwablui');
    }
}

Ja, das ganze heißt PwaBlui. Für Philipp Waldhauer Blade UI. Ich muss das ja abgrenzen von meinen Vue-Componenten, die nur PWUI heißen. Ohne a. Was ist eigentlich los.

Jedenfalls kann ich die Komponenten nun benutzen:

<x-pwablui::form.row>
    <x-pwablui::form.label for="username">Username</x-pwablui::form.label>
    <x-pwablui::form.text name="username" type="text" placeholder=""/>
</x-pwablui::form.row>

Das Composer-Package habe ich mit diesem Trick für die lokale Entwicklung installiert, so wird es direkt lokal per Symlink installiert.

Tailwind

Nach der kurzen Freude kam direkt die Ernüchterung: Natürlich war im neuen Projekt jetzt auch alles Lila, denn die Komponenten benutzten alle bg-indigo als Farbe. Doch auch dafür gibt es eine Lösung, danke an den Tailwind-Experten Nils an dieser Stelle, denn über die Theme-API kann man Tailwind überzeugen, sowas ganz schlau zu handeln:

theme: {
    extend: {
        backgroundColor: ({ theme }) => ({
            primary:  theme('colors.emerald'),
        }),
        ringColor: ({ theme }) => ({
            primary:  theme('colors.emerald'),
        }),
        textColor: ({ theme }) => ({
            primary:  theme('colors.emerald'),
        }),
        borderColor: ({ theme }) => ({
            primary:  theme('colors.emerald'),
        })
    },
},

Nun kann ich in den Komponenten einfach bg-primary benutzen und in den Projekten einfach die entsprechenden Farben in der Konfiguration einstellen. Fast als würde man eine normale CSS-Datei nehmen und dort Variablen überschreiben.

Verrückt!

Vor ein paar Tagen habe ich angefangen, das Backend, das aktuell meine Locationdaten sammelt neu zu bauen. Nicht, dass es nötig wäre, aber mich stören so ein paar Sache an Compass, einer Software, die seit Jahren völlig problemlos funktioniert. Never change a running system, außer naja, man will dringend ein, zwei Features einbauen, oder ein süßes Bild was Midjourney generiert hat, auf dem Login-Screen verwenden.

Jedenfalls wollte ich mal meine uralten Daten aus der Moves.app, der/die ein/e oder andere erinnert sich vielleicht, importieren und dabei musste ich feststellen, dass in den ganzen Exportformaten, die sich in dem riesigen Zipfile verbergen, überall die Koordinaten fehlen! Zwar gibts die Koordinaten der Orte, an denen ich mich länger aufgehalten habe, aber für die Wege dazwischen fehlte alles. Furchtbar!

Nach ein wenig Sucherei fand ich die Daten zum Glück im GPX-Export. Nochmal Glück gehabt.