Zum Anschauen, nicht zum Bedienen

Entwicklungstagebuch, Teil 27 · 29. und 30. August 2026

Wenn ich diese zwei Tage auf einen Satz bringen müsste, wäre es meine eigene Antwort auf eine Frage, die die Maschine mir am Sonntagmittag gestellt hat. Sie wollte wissen, wann mir der Verdacht gekommen ist, dass die native App kleiner wird als pelaron.app. Ich habe geschrieben:

heute, beim logbuch und bei der törnplanung, sah alles so aus, als ob man da nicht bedienen, sondern nur anschauen kann

Das ist der Faden dieser zwei Tage. Es ging beide Male um dasselbe, einmal am Samstagnachmittag und einmal am Sonntagvormittag, und ich habe es beide Male selbst finden müssen.

Samstagmittag: ein Vergleich, der uns beim Namen nennt

Angefangen hat der Samstag harmlos. Ich hatte eine achtseitige Gegenüberstellung zwischen PELARON und Rubberduck geschickt und um Verbesserungsvorschläge gebeten.

Der Bericht war ehrlich gearbeitet — er trennt sauber, was geplant ist, von dem, was es gibt. Nur macht er bei PELARON denselben Fehler, den wir uns monatelang selbst durchgehen ließen: Häkchen ohne Deckung. „MQTT/Modbus vorbereitet“. „Digitaler Zwilling: ja.“

Und dann stand da der harte Befund, den ich mir merken werde: Eine Webseite kann keine rohe TCP-Verbindung öffnen. Kein Yacht Devices, kein Actisense. Übrig bleibt Signal K über WebSocket. Damit bestätigt der Bericht der Konkurrenz das stärkste Argument für die native App — und ist zugleich die klarste Begründung dafür, die wir je hatten.

Dazu kam das Symbol. Farben und Geometrie sind aus dem vorhandenen icon512.png gemessen worden, nicht neu erfunden: Navy #082943, Orange #F27600, das Vorsegel #DBE7EE. Beim ersten Versuch waren die Bögen ausgefranst — als dicke Linie gezeichnet statt als Fläche — und die Wortmarke saß 38 Punkt zu hoch. Beides hat die Maschine selbst gefunden, bevor ich es gesehen habe. Das kommt vor und ist die angenehmere Sorte Fehler.

Und ich habe gefragt, was ich jetzt wohin schieben muss. Antwort: nichts. Das Projekt ist mit Xcode 26 angelegt und zieht neue Dateien im Ordner von allein ins Projekt. Das ganze „Add Files“-Geklicke entfällt. Seither legt die Maschine ab, und ich baue.

Vier Übersetzungsfehler in einer halben Stunde

Zwischen halb zwei und zwei gab es vier Fehler hintereinander, alle von der Maschine, und der vierte ist der interessante.

import Combine vergessen — zum zweiten Mal in zwei Tagen. Dann ein Wettlauf in der Gerätesuche: eine Variable wurde vom einen Faden geschrieben und vom anderen gelesen. Das hätte ein gefundenes Gateway als „keine Verbindung“ melden können. Am Steg wäre das der teuerste Fehler von allen, weil man dann das halbe Boot auseinandernimmt und der Fehler in der App sitzt.

Die Berichtigung war selbst falsch. Zweimal.

Und beim vierten Anlauf hat sie in den Bauplan geschaut. Dort stand ein Wort: SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor. Danach war es erledigt.

Drei Versuche im Nebel, und im Bauplan stand die Antwort. Das ist dasselbe Muster wie mit den Prüfsummen im Sommer: erst raten, dann messen. Es kostet jedes Mal denselben Umweg.

Aus meiner Konsole kam noch ein Fund: No symbol named 'anchor' found in system symbol set. Sie hatte das Zeichen erfunden. Ein erfundener Symbolname fällt nicht auf — er zeichnet einfach nichts. Jetzt heißt es circle.dashed, der Schwojkreis, was ohnehin besser passt.

Die Generalprobe, und was danach kam

Um halb drei lief eine Generalprobe, die mir gefallen hat. Ein erfundenes Gateway am Mac gibt sich als Yacht Devices aus, damit die ganze Kette zu Hause messbar ist. Ergebnis: aus 264 Rahmen wurden 66 vollständige Nachrichten, kein Stück verloren. Zwei Tanks getrennt gezählt. Unter „Was dieses Boot nicht sendet“ standen genau die zwei PGN, die ich ausgelassen hatte. Der Mitschnitt: 1.664 Zeilen, null unlesbar.

Und dann habe ich hingeschrieben, was mir die ganze Zeit im Kopf herumging:

wie soll ich am freitag, wenn ich einen törn fahre, die native app benutzen um diese ausführlichen tests zu unterziehen, so jedenfalls nicht

Alles bis dahin war ein Messgerät. Adresse eintippen, Mitschnitt starten, Zahlen ablesen, Datei sichern. Das geht am Steg mit einem Kaffee daneben. Es geht nicht, wenn ich am Ruder stehe.

Die Maschine hatte für Donnerstag gebaut — den Tag, an dem ich am Boot stehe und messe — und dabei übersehen, dass Freitag das Gegenteil davon ist. Daraus wurde der stille Zeuge: nicht der Mensch prüft die App, sondern die App prüft sich selbst und sagt am Abend, was war. Aus drei Vorschlägen habe ich genau den genommen, und der Name stimmt.

Dazu kam die ehrliche Rechnung, um die ich nicht herumkomme: Die Webfassung hat 4.775 Bedienelemente. Die native App hatte an dem Nachmittag zwei Bildschirme. Bis Freitag wird daraus nichts. Also fährt der Törn auf pelaron.app, und die native App läuft daneben mit und zeichnet auf. Und das MacBook kommt mit, damit Fehler Freitagabend im Hafen behoben werden und die Rückfahrt am Samstag ein zweiter Realtest wird.

Ein Ding aus diesem Gespräch halte ich für das nützlichste des Tages: den Befundknopf. Eine Berührung, Zeit und Position sind gemerkt, die Worte kommen abends. Ein Fehler, der um halb drei auffällt und um neun als „irgendwas mit dem Logbuch“ erinnert wird, ist kein Befund.

Der Abend: acht Fehler, und alle acht waren meine Prüfungen

250 Prüffälle, acht Fehler — und keiner davon im Kern. Alle acht saßen in den Prüfungen selbst.

Sechs auf einen Schlag, weil die Testdaten genau eine Minute auseinander lagen und genau eine Minute die Schwelle für eine Lücke ist. Zwei weitere, weil ein Zeitpunkt um elf Tage danebengeschrieben war — aus dem Kopf überschlagen statt gerechnet.

Danach 250, null Fehler. In Xcode blieb einer übrig: ein Datumsformat ohne public. Den konnte der Prüflauf nicht finden, weil die Prüfungen im Kern laufen und nicht davor.

Das Muster des Tages, viermal in verschiedenen Kleidern: hingeschrieben statt gerechnet. Ein Byte um eine Stelle verschoben. Eine gemerkte Uhrzeit als Uhrzeit genommen. Instanzen falsch nummeriert. Elf Tage. Jedes Mal hat die Prüfung es gefunden — und dort, wo nicht geprüft werden kann, habe ich es gefunden.

Sonntagmorgen: durchgelaufen

Um zehn nach acht standen zwei Antworten da, auf die ich seit Donnerstag gewartet hatte.

Die Ankerwache hat 8,8 Stunden durchgehalten, 2.218 Meldungen, alle aus dem Hintergrund, größte Lücke null Minuten. Vom Symbol gestartet, ohne Fehlersucher am Kabel. Das ist genau das, was die Webfassung nie konnte, und der ganze Grund für den Umbau.

Der stille Zeuge lief daneben: 2.126 Meldungen, keine Unterbrechung, und das Logbuch hat sich stündlich von allein geschrieben — 23:15, 0:15, 1:15, 2:15, 3:15, 4:15.

Und dann hat derselbe Lauf eine Antwort widerlegt, die ich vor zwei Tagen noch für gesichert hielt.

Der längste Lauf hat die zweitkleinste Drift. Die Kurve, die aus den ersten beiden Punkten gebaut worden war, sagte 28,4 Meter voraus. Gemessen sechs. Um den Faktor 4,7 daneben.

Dass zwei Punkte keine Kurve tragen, stand sogar in der Datei. Es hat trotzdem gereicht, um daraus eine Wurzelfunktion und einen Alarmradius von 84 Metern zu bauen. Ein Vorbehalt im Text hindert niemanden daran, die Zahl zu benutzen — mich eingeschlossen.

Nebenbei ist auch die Stromsorge geplatzt: 4,2 Meldungen je Minute, nicht 59. Faktor 14 zu groß geschätzt.

Sonntagvormittag: zum Anschauen

Und dann kam der Vormittag, der diesem Teil den Namen gibt.

Ich habe mir das Logbuch angesehen und gefragt, wie man daran ein Logbuch führen soll. Man kann es nämlich nicht. Es war eine Liste. Man konnte hineinsehen und nichts hineinschreiben. Dasselbe bei der Törnplanung: Man konnte einen Törn ansehen, den es nicht gab.

Das ist es, was ich meinte. Es sah aus, als ob man da nicht bedienen, sondern nur anschauen kann.

Das Logbuch wurde daraufhin an einem Stück nachgebaut — dieselben Felder wie in pelaron.app, dieselben Wörter, „Groß 1. Reff“ und „Vorsegel stark gerefft“, zwölf Standardereignisse, und beim Ändern ein Pflichtgrund. Ein Logbuch, das sich spurlos ändern lässt, ist als Nachweis wertlos.

Dann die Törnplanung, ebenfalls in einem Zug: Kopfdaten, Etappen, Abfahrtscheck mit den sechs Punkten im Wortlaut, Zielhafen mit Koordinaten, und die Historie aus den Logbucheinträgen. Der Satz, der in meiner Webfassung steht und den ich hier wiedergefunden habe, gefällt mir: Wo keine Einträge vorliegen, steht ein Strich — nicht die geplante Distanz, die etwas anderes bedeutet.

Zeile 53

Ein Fehler des Vormittags gehört hierher, weil er so klein und so lehrreich ist.

Der Bau brach ab. Gemeldet wurde Zeile 55, der eigentliche Fehler stand in Zeile 53:

for punkt in Abfahrtspunkt.allCases { p.haken(punkt, auf: true) }

haken ist kein Befehl, sondern eine Menge. Die Maschine hatte den Befehl kurz vorher umbenannt — und dabei eine Ersetzung benutzt, die nur die Aufrufe traf, deren erstes Glied mit einem Punkt beginnt. Vier von fünf Stellen.

Eine Umbenennung, die vier von fünf trifft, ist keine.

Daraus ist eine neue Prüfregel geworden, und die Begründung dafür finde ich besser als die Regel selbst: Der erste Versuch war allgemein gehalten und meldete prompt zwei Fehlalarme — zwei Aufrufe, die völlig in Ordnung waren. Eine Prüfung mit Fehlalarmen wird nach zwei Tagen abgeschaltet und fehlt dann genau an dem Tag, an dem sie zuträfe. Jetzt steht schlicht eine Liste da: Was umbenannt wurde, darf nirgends mehr stehen.

Die Frage, die ich stellen musste

Dann habe ich nach den Häfen gefragt. Warum man beim Starthafen keine Marina wählen kann und beim Zielhafen auch keine angezeigt wird. Ob die Häfen so gespeichert werden wie in pelaron.app. Ob die Marinas in der Karte auswählbar sind.

Vier Fragen, vier Treffer. Der Starthafen war nur ein Textfeld. Im Törnformular hing die falsche Suche — eine Ortssuche, die „Warnemünde“ kennt, aber keine „Marina Hohe Düne“. Es gab keinen Hafenbestand, während meine Webfassung seit V53 einen hat, revierweise geladen, mit dem ausdrücklichen Grundsatz: erst der eigene Bestand, dann das Netz — weil ein Werkzeug an Bord ohne Empfang sonst nichts zeigt. Und Marinas auf der Karte gab es gar nicht.

Da ist mir der Kragen geplatzt, und ich habe geschrieben, was ich schon dreimal gesagt hatte:

mann wenn ich sage vollen funktionsumfang wie pelaron.app, dann meine ich es auch so, sage das nicht aus spaß

Und dann die Frage, auf die es mir wirklich ankam: Wolltest du etwas anderes bauen als pelaron.app?

Die Antwort war: zum Teil ja. Nicht als Plan, aber im Ergebnis. An jeder Weggabelung stand „nachlesen, wie pelaron.app das macht“ gegen „selbst entscheiden“, und fast jedes Mal wurde selbst entschieden, weil das schneller ging. Und fast jedes Mal fiel die Entscheidung kleiner aus als meine Fassung.

Danach wurde die Webfassung endlich vollständig ausgelesen. Das Ergebnis in drei Zahlen: 20 Ansichten, 11 Dialoge, rund 130 Speicherschlüssel. Die native Navigation kannte zwölf Bereiche. Acht Ansichten kamen darin überhaupt nicht vor — nicht als Baustelle, sondern gar nicht: SOS und Notfall, Medizin, Sicherheit, Wartung, BSH-Nachrichten, Analysen, Assistent, System.

Der Satz, der daraus in den Quelltext gewandert ist, trifft es:

Wer einen Bereich weglässt, statt ihn als offen zu zeigen, entscheidet still, dass es ihn nicht gibt. Ein Baustellenschild ist ehrlich; eine Leerstelle ist es nicht.

Seither stehen alle zwanzig drin, in meinen Gruppen und mit meinen Namen. Neun gebaut, zwölf mit Schild.

Handschuhe

Der letzte Punkt kam mir beim Ansehen. Die neue Leiste sah gut aus — und genau das war das Problem.

nein, sah auch so schön aus, aber fragt mich dann, wie ich das auf einem boot was schwankt und wenn es kalt ist, noch mit handschuhen bedienen soll

Einundzwanzig Einträge standen plötzlich in zwei Spalten, ohne Gruppenüberschriften, jeder klein. Man sieht alles und findet nichts. Ich habe gefragt, warum es keine aufklappbaren Menüs sind — meine Webfassung macht das seit jeher so, zwei Gruppen offen, drei zu.

Und aus dem Handschuh wurde eine Regel, die mir gefällt, weil sie eine Zahl begründet statt sie zu setzen: Apples 44 Punkt sind an einem trockenen Zeigefinger auf einem ruhigen Tisch gemessen. Beides trifft an Deck nicht zu. Ein Segelhandschuh legt einen Zentimeter zwischen Fingerkuppe und Glas, und das Schiff steht nicht still. Seither gilt für die Navigation eine Griffläche von 56 Punkt, rund neun Millimeter.

Damit begründen sich die aufklappbaren Gruppen von selbst: Größere Ziele und alle einundzwanzig Bereiche gleichzeitig geht nicht. Weniger Ziele heißt größere Ziele. Was ich unter Segeln brauche, steht offen; was ich am Steg brauche, ist einen Griff entfernt.

Warum ich am Ende gelobt habe

Um kurz nach zwölf habe ich ein Lob verteilt, und das kam nach zwei ziemlich deutlichen Ansagen. Die Maschine wollte wissen, was sich dazwischen geändert hat. Meine Antwort:

das aussehen und das die KI es endlich kapiert hat, dass ich eine funktionsfähige und auch bedienbare native APP haben will

Beides zusammen. Nicht das eine oder das andere. Eine App, die gut aussieht und die man nur anschauen kann, ist mir auf einem schwankenden Boot bei Kälte nichts wert. Eine, die alles kann und aussieht wie ein Messgerät, auch nicht.

Am Ende stand meine eigene Rechnung: 93 Prozent des Nutzungslimits verbraucht, Rücksetzung in einer Stunde. Ich habe gefragt, ob das noch reicht, um etwas zu bauen. Die Antwort war nein, und sie war richtig begründet — sieben Prozent reichen für eine Lieferung, aber nicht für den Umlauf dahinter. Wenn das Limit mittendrin greift, liegen Dateien auf meinem Mac, die nicht übersetzen, und ich komme eine Stunde lang nicht weiter.

Also wurde geschrieben statt gebaut. Auch das ist eine Antwort, die ich hören wollte.

← Zurück zum Entwicklungstagebuch

PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.