Entwicklungstagebuch, Teil 1 · August 2026
Die ehrliche Antwort auf die Frage, warum ich noch eine Logbuch-App baue, lautet: weil ich keine gefunden habe, die tut, was ich brauche.
Das ist ein schlechter Grund. Wer so anfängt, endet meistens mit einem Werkzeug, das genau für eine Person taugt. Trotzdem war es der Grund.
Wie es wirklich anfing
Nicht mit Software. Mit einem Impeller.
Ich wollte einen auf Lager haben — und Motoröl gleich dazu, damit im Frühjahr nicht das Suchen losgeht. Also saß ich zu Hause und versuchte herauszufinden, welcher es denn nun ist. Nicht am Boot. Das Boot lag anderswo, und die Angaben, die ich brauchte, lagen dort auch: auf einem Aufkleber, an einer Stelle, an die man nur mit dem Kopf über der Maschine kommt.
Das ging noch. Beim nächsten Teil ging es nicht mehr.
Der Wassersammler im Auspuffstrang. Ich brauchte den Durchmesser, und keiner wusste ihn. Nicht das Forum, nicht der Händler, nicht die Herstellerseite. Was ich fand, war ein Beitrag von 2014, ein Video ohne Angabe zum Bootstyp und eine Seite, die alles verspricht und nichts erklärt.
Ich hätte fahren müssen, um nachzumessen. Wegen einer Zahl.
Das war der Moment. Nicht irgendein Einfall am Schreibtisch, sondern die simple Erkenntnis, dass das Wissen über mein eigenes Boot nicht bei mir liegt, sondern am Boot — und dass es dort auch bleibt, wenn ich es woanders brauche.
Zwei Dinge, die daraus wurden
Daraus entstand zuerst pelaron.de: Wissen an einem Ort, aus echter Praxis, mit Kosten und Fehlern statt Hochglanz. Was beim Refit der Bluebaerry gelernt wurde — Seeventile, Elektrik, Solar, Rigg, Motor —, sollte nicht wieder verstreut liegen. Welcher Querschnitt bei welcher Länge. Was nach fünf Jahren wirklich passiert. Was es am Ende gekostet hat.
Der Zettel kam später. Auf ihm standen die Dinge, die mich beim Segeln selbst störten:
Ein Logbuch, das ich bei sechs Windstärken mit einer Hand führen kann. Ein Ort, an dem der Motorstundenstand steht, wenn die Werft danach fragt. Eine Wartungsübersicht, die weiß, dass ein Impeller nach Betriebsstunden fällig wird und nicht nach Kalendermonaten. Und die Gewissheit, dass das alles funktioniert, wenn zwanzig Seemeilen vor der Küste kein Netz mehr da ist.
Nichts davon ist neu. Aber die Apps, die ich kannte, konnten immer einen Teil — und der Rest lag wieder auf Papier.
Was eine Maschine kann und was nicht
Ich bin kein Softwareentwickler. Den Code schreibt eine künstliche Intelligenz, der ich beschreibe, was gebraucht wird.
Wer daraus schließt, so etwas gehe schnell und ohne Reibung, irrt. Es geht schnell. Ohne Reibung geht es nicht.
Die Maschine tippt in Minuten, wofür ich Wochen bräuchte. Sie kennt Formate, Schnittstellen und Verschlüsselungsverfahren aus dem Stand. Was sie nicht kennt, ist das Wasser. Sie weiß nicht, wie es ist, mit nassen Fingern zu tippen. Sie weiß nicht, dass ein Ankeralarm, der einmal ohne Grund losgeht, beim zweiten Mal ignoriert wird.
Und sie weiß vor allem nicht, was sie nicht weiß. Deshalb muss jemand danebenstehen und fragen: Stimmt das so?
Neun Versionen, und in fast jeder ein „das hatten wir falsch“
Zwischen dem Zettel und heute liegen neun Versionen in wenigen Wochen.
Eine davon hat im Wesentlichen einen einzigen Punkt: Optionale Elemente verursachen keinen Programmabbruch mehr. Auf Deutsch: Die App stürzte ab, wenn ein Bedienelement fehlte, das gar nicht gebraucht wurde. Eine ganze Version, nur um das abzustellen.
Dann kamen die Integritätsprüfung, die Tagesübersicht, das Verbindungszentrum, die verschlüsselten Sicherungen, die Zugriffsverwaltung für die Crew.
In fast jeder steht mindestens ein Punkt, der eigentlich heißt: Das hatten wir vorher falsch.
Narben im Quelltext
An einer Stelle im Programm steht ein Kommentar, den ich mag:
Selbst wenn ein nachgelagertes Modul einen Fehler wirft, werden gespeicherte Logbucheinträge gelesen und angezeigt.
Dahinter steckt ein Tag, an dem das Logbuch leer blieb, obwohl die Einträge da waren. Irgendein Modul weiter hinten war gestolpert und hatte die ganze Anzeige mitgerissen. Seither gibt es dieses Netz — und den Kommentar, damit niemand ihn später für überflüssig hält und wieder entfernt.
Ein anderer Fehler ist mir besonders geblieben, weil er so unauffällig war: Fotos landeten am falschen Logbucheintrag. Neue Einträge werden hinten angehängt, gesucht wurde vorne.
Solche Fehler machen kein Geräusch. Sie schreiben still das Falsche, und man merkt es Wochen später.
Deshalb steht in vielen PELARON-Dateien inzwischen nicht nur, was der Code tut, sondern auch, was ein früherer Entwurf falsch gemacht hat. Das ist ungewöhnlich für Programmtexte. Ich halte es für das Nützlichste, was wir uns angewöhnt haben.
Was daraus geworden ist
Heute führt PELARON das Logbuch mit einem Fingertipp, rechnet den Verbrauch zwischen zwei Tankfüllungen aus, kennt neunzehn Reviere von der Nordsee bis Estland, zeichnet die gefahrene Strecke auf einer Karte, die auch ohne Netz funktioniert — und sagt, was sie nicht kann.
Der letzte Punkt ist mir der wichtigste. Wenn dort steht, dass der Ankeralarm keine Ankerwache ersetzt, oder dass echtes Wetterrouting ein Polardiagramm bräuchte, das die App nicht hat, dann steht es dort, weil beim Bauen jemand gefragt hat: Stimmt das so?
Den Durchmesser des Wassersammlers habe ich übrigens irgendwann selbst nachgemessen. Er steht jetzt in der App.
Im nächsten Teil geht es um zwei Tage im August, an denen dieses Stimmt das so? mehrfach nötig war — und um den Moment, in dem ich schrieb: Nicht raten.
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.