Thomas Panzeri

panzeri.rocks neu gebaut

Sun, 11 Oct 2026 00:00:00 +0000

Diese Seite hatte in drei Jahren drei Versionen. Die letzte ist die erste, die um das Schreiben herum gebaut ist statt um ein Werkzeug.

Wo es anfing

Die erste Version, im Mai 2023, war Hugo mit einem fertigen Theme: eine Startseite, eine Über-mich-Seite und ein paar Cheat Sheets, als Git-Submodul eingebunden. Bei jedem Build wählte sie sogar eine neue Akzentfarbe. Sie funktionierte und sah aus wie jede andere Hugo-Seite.

Das war in Ordnung. Niemand besucht eine persönliche Seite wegen des Themes. Man kommt wegen etwas, das du geschrieben hast, liest es und geht wieder.

Websites sind Dateien

Thu, 24 Sep 2026 00:00:00 +0000

Der zehnte und letzte Teil des Boring Stack. Die ersten neun handelten von Apps. Dieser handelt vom einfacheren Fall: Websites wie einem Blog, einer Kampagnenseite oder einer Infoseite für einen Verein.

Sie brauchen kein Backend. Also bekommen sie keines.

Einmal erzeugt, als Dateien ausgeliefert

Hugo ist ein Static Site Generator. Er nimmt Markdown-Dateien, Templates und eine Konfigurationsdatei und erzeugt einen Ordner mit einfachem HTML, CSS und Bildern. Dieser Ordner ist die Website. Jeder Webserver kann ihn ausliefern, und auf meinem Server tut das Caddy.

Ein Server ist leicht zu durchschauen

Thu, 27 Aug 2026 00:00:00 +0000

Teil neun des Boring Stack. Die App ist ein einzelnes Go-Binary mit ihren Daten in einer SQLite-Datei. Wo soll das laufen?

Die modischen Antworten sind eine verwaltete Plattform, Serverless-Funktionen oder ein Kubernetes-Cluster. Ich habe Kubernetes auf Bare Metal betrieben und auf dieser Seite darüber geschrieben. Für meine eigenen Apps miete ich einen virtuellen Server.

Das Setup

Ein VPS bei Hetzner, mit mehr CPU und Arbeitsspeicher, als meine Apps brauchen.
Caddy davor. Caddy ist ein Webserver, der TLS-Zertifikate selbst holt und erneuert. Er leitet jede Domain an die richtige App weiter. Statische Websites sind Ordner, die Caddy direkt ausliefert.
Docker Compose für die Apps. Jede App ist ein Container mit zwei Ordnern vom Host: einer für die SQLite-Datenbank, einer für hochgeladene und erzeugte Dateien. Der ganze Zustand liegt in diesen zwei Ordnern.
Cloudflare vor allem, für DNS und Caching.

Wie ein Deploy abläuft

Ein Push auf master startet die Pipeline auf einem selbst gehosteten GitHub-Runner. Sie lintet den Code, baut ein Docker-Image und versieht es mit dem Commit-Hash. Dann kopiert sie eine Compose-Datei mit genau diesem Tag auf den Server und führt docker compose pull && docker compose up -d aus.

Ein neuer Rechner braucht Docker und sonst nichts

Thu, 30 Jul 2026 00:00:00 +0000

Teil acht des Boring Stack. Die App ist Go, und templ und Tailwind erzeugen Code und CSS. Das sind drei Toolchains, bevor man eine Zeile schreibt. Dieser Text handelt davon, wie ich sie von meinem Rechner fernhalte.

Jedes Projekt, das ich baue, hat einen einzigen unterstützten Weg, es in der Entwicklung zu starten:

task dev

Das führt docker compose up --build aus. Dann öffne ich die App im Browser und fange an.

Tests ohne Mocks

Thu, 02 Jul 2026 00:00:00 +0000

Teil sieben des Boring Stack. Die Datenbank ist SQLite, und das Schema migriert sich selbst. Das macht die Entscheidung beim Testen einfach.

Ein verbreiteter Weg, einen Service zu testen, ist, seine Datenbank durch einen Mock zu ersetzen: ein falsches Objekt, das zurückgibt, was der Test ihm sagt. Der Test prüft dann, ob der Service das falsche Objekt mit den richtigen Argumenten aufgerufen hat.

Dieser Test beweist, dass der Service eine Funktion aufruft. Er beweist nicht, dass die Abfrage funktioniert, dass die Spalte existiert, dass der Constraint das Einfügen erlaubt oder dass das Ergebnis in der erwarteten Reihenfolge zurückkommt. Genau diese Fehler sollen Tests finden.

Das Binary migriert seine Datenbank selbst

Thu, 04 Jun 2026 00:00:00 +0000

Teil sechs des Boring Stack. Die App schreibt ihr SQL selbst. Die Tabellen, gegen die dieses SQL läuft, ändern sich mit der Zeit, und diese Änderungen brauchen einen Ablauf.

Der klassische Ablauf hat einen eigenen Schritt: Vor oder nach dem Deploy lässt jemand das Migrationswerkzeug gegen die Produktionsdatenbank laufen. Manchmal vergisst dieser Jemand es. Dann läuft neuer Code gegen ein altes Schema oder alter Code gegen ein neues.

In meinen Apps gibt es diesen Schritt nicht. Das Binary migriert seine Datenbank beim Start selbst.

Das SQL, das man liest, ist das SQL, das läuft

Thu, 07 May 2026 00:00:00 +0000

Teil fünf des Boring Stack. Die Daten liegen in SQLite. Dieser Text handelt vom Code zwischen App und Datenbank.

Die übliche Wahl ist ein ORM: Man beschreibt seine Tabellen als Klassen oder Structs, und die Bibliothek schreibt das SQL. Das fühlt sich produktiv an bis zur ersten langsamen Seite, wenn man herausfinden muss, welche der vierzig erzeugten Abfragen das Problem ist und wie man das ORM dazu bringt, eine andere zu erzeugen.

SQLite reicht

Thu, 09 Apr 2026 00:00:00 +0000

Teil vier des Boring Stack. Die App ist in Go geschrieben und rendert HTML auf dem Server. Jetzt muss sie ihre Daten irgendwo ablegen.

Die Standardantwort ist Postgres. Eine ausgezeichnete Datenbank, die ich jahrelang benutzt habe. Für die Apps, die ich heute baue, nehme ich SQLite.

Eine Datenbank, die eine Datei ist

SQLite ist kein Server. Es ist eine Bibliothek, die eine einzige Datei liest und schreibt. Die App öffnet ./data/app.db, und das ist die ganze Datenbank.

HTML vom Server

Thu, 12 Mar 2026 00:00:00 +0000

Teil drei des Boring Stack. Nach der Sprache und dem Router kommt die grösste Entscheidung: was im Browser läuft.

Der Standard für eine Web-App sind heute zwei Anwendungen. Ein Backend, das JSON liefert, und ein Frontend in React oder Vue, das aus diesem JSON eine Oberfläche macht. Zwei Codebasen, zwei Build-Pipelines, zwei Sätze Abhängigkeiten und dazwischen ein API-Vertrag, den beide Seiten synchron halten müssen.

Für die Apps, die ich baue (Formulare, Listen, Dashboards, Verwaltungsmasken), ist das eine Anwendung zu viel. Meine Apps rendern HTML auf dem Server und schicken es an den Browser. Drei Werkzeuge machen das angenehm.

Kein Router-Framework

Thu, 12 Feb 2026 00:00:00 +0000

Teil zwei des Boring Stack. In Teil eins ging es um die Sprache. In diesem geht es um die erste Abhängigkeit, die die meisten Go-Web-Apps dazunehmen, und warum ich es nicht tue.

Jahrelang war das Erste in einem Go-Webprojekt die Wahl eines Routers: gorilla/mux, chi, Gin, Echo. Der Standard-http.ServeMux konnte weder nach HTTP-Methode unterscheiden noch Parameter aus dem Pfad lesen, also brauchte man etwas darüber.

Mit Go 1.22 hat sich das geändert. Seither kann die Standardbibliothek beides:

Go, weil es sich in fünf Jahren noch gleich liest

Thu, 15 Jan 2026 00:00:00 +0000

Das ist der erste von zehn Texten über die Entscheidungen dahinter, wie ich Software baue. Jede hat eine Zeile auf meiner Stack-Seite, und jede ist mit Absicht langweilig. Die erste Entscheidung ist die, von der alles andere abhängt: die Sprache.

Ich baue in Go.

Was ich von einer Sprache brauche

Ich leite beruflich eine IT und schreibe Software am Abend und am Wochenende. Das bestimmt, was ich brauche. Ein Projekt bleibt vielleicht drei Monate liegen. Wenn ich zurückkomme, muss ich es in Minuten verstehen, sicher ändern und noch am selben Abend ausliefern.

Ready und Done

Thu, 11 Dec 2025 00:00:00 +0000

Der zehnte und letzte Teil der Werkzeugkiste des Product Owners. Der Backlog des Ferientools ist priorisiert. Bleiben zwei Checklisten, eine an jedem Ende des Sprints.

Zwei Prüfungen, eine an jedem Ende des Sprints.

Definition of Ready

Die Definition of Ready ist eine Checkliste mit Kriterien, die ein Backlog-Eintrag erfüllen muss, bevor er vom Product Backlog in einen Sprint Backlog wechseln darf.

Den Backlog verantworten

Thu, 27 Nov 2025 00:00:00 +0000

Teil neun der Werkzeugkiste des Product Owners. Wir sind von der Vision bis zu kleinen Stories gekommen. Alle landen am selben Ort.

Der Product Owner, und nur der Product Owner, verwaltet den Product Backlog. Er ist dafür verantwortlich, dass der Backlog aktuell ist, und entscheidet, was gebaut wird und was nicht. Er sorgt dafür, dass die Sicht der Kunden in den Backlog einfliesst und der Backlog auf Wert ausgerichtet bleibt. Und er sorgt dafür, dass der Backlog priorisiert und aktuell ist und dass die Meetings und die Arbeit, die es dafür braucht, auch stattfinden.

Stories dünner schneiden

Thu, 06 Nov 2025 00:00:00 +0000

Teil acht der Werkzeugkiste des Product Owners. Im letzten Teil haben wir eine gute User Story geschrieben. Die meisten Stories fangen nicht so gut an. Sie fangen zu gross an.

Schneiden heisst, eine Story in kleinere, in sich stimmige Stücke zu teilen, die sich schätzen, bauen und testen lassen, alles innerhalb eines Sprints. Die Gründe sind verschieden: die Kapazität des Sprints, die Komplexität der Story, ein Teil davon, der noch unklar ist.

Eine User Story ist ein Versprechen, miteinander zu reden

Thu, 16 Oct 2025 00:00:00 +0000

Teil sieben der Werkzeugkiste des Product Owners. Die Story Map des Ferientools ist voller Karten. Jetzt schauen wir uns eine einzelne an.

Eine User Story beschreibt eine Funktionalität aus der Sicht eines bestimmten Nutzers. Meistens wird sie in normaler Sprache nach einer festen Vorlage geschrieben und ist bewusst kurz:

Als (Rolle oder Persona) will ich (Ziel oder Funktion), damit (der Nutzen).

Die Vorlage ist das Unwichtigste daran. Sie hilft, den Nutzer im Blick zu behalten, aber entscheidend ist, ob das Team vier Fragen beantworten kann: Warum bauen wir das? Für wen? Welches Problem löst es? Und wie bauen wir es technisch?

Von der Journey zur Story Map

Thu, 25 Sep 2025 00:00:00 +0000

Teil sechs der Werkzeugkiste des Product Owners. Für das Ferientool haben wir ein Epic und eine User Journey. Jetzt verbinden wir die beiden.

Features

Ein Feature ist eine Funktionalität oder ein Teil einer User Journey, aus der Sicht einer bestimmten Nutzergruppe. Es liefert einen Wert, der die Bedürfnisse dieser Gruppe erfüllt. Ein Feature wird über mehrere User Stories umgesetzt, die aus Sicht der Nutzer zusammengehören. Es dauert länger als einen Sprint und passt in ein Release.

Für wen ist das?

Thu, 11 Sep 2025 00:00:00 +0000

Teil fünf der Werkzeugkiste des Product Owners. Das Ferientool hat eine Vision und ein erstes Epic. Bevor wir das Epic in Features herunterbrechen, müssen wir die Menschen kennen, für die wir es bauen.

Personas

Eine Persona ist ein erfundenes, aber konkretes Mitglied einer Nutzergruppe, mit persönlichen Merkmalen, Absichten und Gefühlen.

Gute Personas entstehen aus Daten. Du sammelst sie mit Interviews oder Fragebögen, gruppierst sie mit einer Segmentierung oder Clusteranalyse und verdichtest jede Gruppe zu einer Persona. Eine Persona, die in einem Workshop von Leuten erfunden wurde, die nie einen Nutzer getroffen haben, ist ein Klischee mit Namen. Das ist schlimmer als gar keine Persona, weil es wie ein Beleg aussieht.

Epics sind Wetten

Thu, 28 Aug 2025 00:00:00 +0000

Teil vier der Werkzeugkiste des Product Owners. Das Ferientool hat jetzt eine Vision. Als Nächstes kommt das erste grosse Stück Arbeit.

Ein Epic beschreibt ein grosses Bedürfnis oder Problem: so gross, dass seine Lösung eine echte Investition ist, oft so gross, dass es einen schlanken Business Case braucht. Es ist die grösste Art von Backlog-Eintrag und sollte leicht verständlich sein. Es sagt grob, warum etwas gelöst werden soll und was, mehr nicht.

Von Air zu Watchexec

Mon, 18 Aug 2025 00:00:00 +0000

Als Entwickler sind wir Gewohnheitstiere. Wir finden Werkzeuge, die funktionieren, und bleiben bei ihnen, manchmal weit über ihr Ablaufdatum hinaus. Jahrelang habe ich beim Hot Reloading auf Air für Go geschworen. Es war einfach, es funktionierte (meistens), und meine Go-Projekte liefen damit rund. Aber wie in vielen langen Beziehungen wurde aus Bequemlichkeit irgendwann ein Kompromiss.

Der Wendepunkt kam, als ich mehr mit Projekten aus mehreren Modulen und gemeinsamen Bibliotheken arbeitete. Plötzlich waren die Grenzen von Air keine kleinen Ärgernisse mehr, sie haben meine Produktivität aufgefressen.

Eine Vision, mit der man Nein sagen kann

Thu, 07 Aug 2025 00:00:00 +0000

Teil drei der Werkzeugkiste des Product Owners. Im letzten Teil hing am Ende jeder Backlog-Eintrag an einer Vision. Jetzt brauchen wir eine.

Eine Produktvision beschreibt in einer kurzen Aussage, warum es ein Produkt gibt, für wen es ist und was es besser macht als die Alternativen. Sie ist langfristig. Sie gibt allen, die am Produkt arbeiten, eine Richtung und etwas, woran sie ihre Arbeit messen können. Jeder Backlog-Eintrag, auf jeder Ebene, sollte das Produkt näher an sie heranbringen.

APIs sind nicht optional

Thu, 31 Jul 2025 00:00:00 +0000

Moderne Anwendungsentwicklung fühlt sich oft wie ein Rennen an. Schneller bauen. Früher ausliefern. Ständig iterieren. In dieser Eile bieten Plattformen wie Firebase und Supabase eine verlockende Abkürzung: Sie versprechen, dass du dich nicht um die Backend-Infrastruktur kümmern musst. Einfach die App direkt mit der Datenbank verbinden, ein paar Regeln darüberlegen, fertig.

Diese Denkweise hat aber einen grundlegenden Fehler, und der ist nicht nur theoretisch. Echte Firmen und echte Nutzer lernen ihn gerade auf die harte Tour.

Just in Time spezifizieren

Thu, 24 Jul 2025 00:00:00 +0000

Das ist der zweite Teil der Werkzeugkiste des Product Owners. Das durchgehende Beispiel ist ein Tool, das die Tabelle ersetzt, in der eine Firma mit 300 Leuten ihre Ferienanträge verwaltet.

Früher hätte man für das Ferientool zuerst ein Pflichtenheft geschrieben: vierzig Seiten über jede Abwesenheitsart, jeden Bewilligungsweg und jeden Sonderfall rund um den Jahreswechsel, unterschrieben, bevor jemand eine Zeile Code schreibt.

Das scheitert auf zwei Arten, und beide kosten Geld.

Der Inhalt veraltet. Anforderungen ändern sich, während man sie aufschreibt, und das Umfeld ändert sich mit. Bis die Entwicklung bei Seite 30 ankommt, beschreibt Seite 30 ein Bedürfnis, das es nicht mehr gibt. Das Schreiben war verlorene Arbeit, das Nachführen ist noch mehr davon.

Die Werkzeugkiste des Product Owners

Thu, 10 Jul 2025 00:00:00 +0000

Ich war mehr als vier Jahre Product Owner: zuerst für die TV-Produkte von Quickline, dann bei localsearch, dann als Head of Product Owners bei Lifestage, bevor ich die IT übernommen habe. Heute sitze ich auf der anderen Seite des Tisches. Ich arbeite mit Product Owners, ich stelle sie ein, und ab und zu muss ich erklären, warum ein Team mit vollem Backlog trotzdem nichts liefert, was zählt.

Selten fehlt dafür eine Methode. Meistens sind alle Methoden da, nur weiss niemand mehr, wofür. Die User-Story-Vorlage ist perfekt ausgefüllt, es gibt eine Definition of Ready, die niemand liest, und im Backlog liegen 600 Einträge, die niemand übers Herz bringt zu löschen.

Mit Ubuntu Cloud Images arbeiten

Sat, 23 Mar 2024 00:00:00 +0000

Ubuntu von einer ISO-Datei zu installieren heisst, sich jedes Mal durch einen Installer zu klicken. Die Cloud Images von Ubuntu ersparen das. Sie sind vorinstallierte Disk-Images, dieselben, die Cloud-Anbieter starten, und sie richten sich beim ersten Start mit cloud-init selbst ein: Hostname, Benutzer, SSH-Schlüssel, Pakete.

Platz von einer vergrösserten physischen (oder virtuellen) Disk nutzen

Wed, 13 Mar 2024 00:00:00 +0000

Zuerst musst du die Disk vergrössern, die Linux zur Verfügung gestellt wird. Meistens erweiterst du dafür die virtuelle Disk in KVM, VMware oder Hyper-V oder vergrösserst das Volume im RAID-Controller oder Speichersystem. Das geht oft, während Linux läuft, ohne Herunterfahren oder Neustart. Für mein Beispiel habe ich eine Disk von 100 GB auf 200 GB erweitert.

Danach musst du Linux eventuell dazu bringen, die Disk neu nach freiem Platz abzusuchen. Starte cfdisk und prüf, ob freier Platz angezeigt wird. Mit «q» verlässt du das Programm wieder.

Snap ein für alle Mal entfernen

Thu, 07 Mar 2024 00:00:00 +0000

Warum man Snap nicht verwenden sollte

Ob man Snap aus Ubuntu entfernt, hängt von persönlichen Vorlieben, den Ressourcen des Systems oder dem konkreten Einsatzzweck ab. Das sind einige Gründe, warum jemand Snap entfernen möchte:

Ressourcenverbrauch: Snap-Pakete können mehr Speicherplatz belegen als klassische Debian-Pakete. Manche Nutzer, vor allem mit wenig Speicher, entfernen Snap, um Ressourcen zu sparen.
Performance: Snap-Pakete haben den Vorteil, dass sie in einer Sandbox laufen und alles mitbringen. Manche Nutzer sind aber der Meinung, dass klassische Paketverwaltungen schneller sind und Anwendungen schneller starten.
Doppelte Pakete: Manchmal gibt es dieselbe Anwendung sowohl als Snap als auch als APT-Paket. Manche Nutzer bleiben lieber bei einem einzigen Paketsystem, um doppelte Installationen zu vermeiden.
Anpassung und Kontrolle: Wer mehr Kontrolle über sein System will und bei den Paketen aus den offiziellen Ubuntu-Repositories bleiben möchte, entfernt Snap vielleicht. So bleibt die Paketverwaltung schlank und klassisch.
Sicherheit: Snap-Pakete sind zwar mit Blick auf Sicherheit entworfen, aber manche Nutzer haben eigene Vorstellungen oder Bedenken und wählen deshalb andere Paketformate.
Community und Lizenzen: Ab und zu gibt es Bedenken der Community oder zu Lizenzen rund um das Snap-Format. Wer viel Wert auf Open-Source-Prinzipien legt, entfernt Snap vielleicht zugunsten anderer Paketformate.
Persönliche Vorliebe: Am Ende ist es oft eine Frage des Geschmacks und davon, mit welchem Paketsystem man sich wohlfühlt. Manche mögen einfach die Vertrautheit und Einfachheit der klassischen Paketverwaltung.

Selbst gehostete GitHub-Runner in Kubernetes

Wed, 06 Mar 2024 00:00:00 +0000

Die von GitHub gehosteten Runner sind bequem, aber sie werden pro Minute abgerechnet, erreichen nichts in deinem Netzwerk und starten jedes Mal auf einer leeren Maschine. Wenn du schon einen Kubernetes-Cluster betreibst, kannst du die Jobs dort laufen lassen. Actions Runner Controller (ARC) startet für jeden Job einen frischen Runner-Pod und entfernt ihn danach wieder.

Kubernetes auf Bare Metal

Wed, 06 Mar 2024 00:00:00 +0000

Voraussetzungen

Das sind die Mindestanforderungen, um einen Kubernetes-Cluster auf Bare Metal aufzusetzen:

Ein kompatibler Linux-Host. Das Kubernetes-Projekt stellt allgemeine Anleitungen für Debian- und Red-Hat-basierte Distributionen bereit, und für Distributionen ohne Paketmanager.
Mindestens 2 GB RAM pro Maschine (mit weniger bleibt kaum Platz für deine Apps).
Mindestens 2 CPUs pro Maschine.
Volle Netzwerkverbindung zwischen allen Maschinen im Cluster (öffentliches oder privates Netz spielt keine Rolle).

Bestimmte Ports müssen auf deinen Maschinen offen sein. Details weiter unten.