Entwicklungstagebuch, Teil 41 · 16. September 2026, abends
Der Tag fing damit an, dass ich mich geärgert habe. Das Terminal hing, schon wieder, und der Prüflauf brach mit derselben Meldung ab wie neulich: Eine Eingabedatei sei während des Baus verändert worden. Ich habe geschrieben, was ich dachte — es ging bisher immer, also liegt die Änderung wohl an Dir, irgendwas geändert wie Du die Dateien ablegst?
Es lag nicht daran. Nachgemessen war der letzte Schreibvorgang dreiundzwanzig Stunden her, und in der Minute des Abbruchs hatte niemand etwas angefasst. Der Grund saß woanders: Mein Projektordner liegt auf dem Schreibtisch, und der Schreibtisch liegt in iCloud. Während der Bau läuft, lädt iCloud die Zwischenstände hoch und tauscht sie unter dem Bauwerkzeug aus. Xcode stört das nicht, weil es seine Zwischenstände woanders ablegt — das Terminal schon. Ein Bau, der außerhalb von iCloud schreibt, läuft durch.
Das ist eine unspektakuläre Erkenntnis, aber sie hat mich einen halben Vormittag gekostet, und sie erklärt rückwirkend einiges. Ich mag solche Befunde: Man hört auf zu raten, wer schuld ist, und schaut nach.
---
Eingebaut ist nicht gezeigt
Danach ging es ans Prüfen. Die Lautstärke folgt jetzt, wenn ich am Gerät drehe — der Punkt, an dem ich gestern die ganze Runde abgebrochen hatte. Das war schnell erledigt.
Der zweite Punkt nicht. Ein Törn, den ich auf der Logbuchseite starte, ohne vorher einen Plan anzulegen: Im Logbuch stand er, auf der Törnseite stand er, und in der Törnplanung stand „Noch kein Törn“. Genau das, was vorgestern schon nicht ging.
Der Unterschied war diesmal ein anderer. Die Kennung stimmte — die war gestern repariert worden. Was fehlte, war die Anzeige: Die Törnplanung prüft, ob es Pläne gibt, und wenn keine da sind, zeigt sie nur die Einstiegstafel. Der Abschnitt mit den Törns ohne Plan hing an der Liste, und die Liste wurde gar nicht erst gebaut. Der Abschnitt fiel also genau in dem Fall weg, für den er gemacht worden war: bei jemandem, der noch nie einen Plan angelegt hat.
Also bei mir.
Ich finde diesen Fehlertyp interessant, weil er sich so schwer sehen lässt. Der Baustein war da, die Daten waren da, die Kennung war da — und trotzdem sah ich nichts. Eingebaut ist eben nicht dasselbe wie gezeigt. Beim zweiten Anlauf stand er da, wo er hingehört, und der Rest der Liste lief durch bis zum Ende. Das war die erste Prüfrunde seit Tagen, die ich nicht abgebrochen habe.
---
Zwei Zeilen, die neun Tage falsch standen
Am Nachmittag wollte ich wissen, was als Nächstes dran ist, und habe mir eine Liste vorlegen lassen. Vier Punkte, zwei davon als schwer wiegend markiert. Ich habe gesagt: dann bau das alles.
Beim Nachsehen kam heraus, dass zwei davon längst fertig waren. Der rückdatierte Handeintrag — der Punkt, bei dem ich darauf bestanden hatte, dass man an den Uhrzeiten eines Logbuchs nichts dreht, weil es vor Gericht Bestand haben muss — war seit fünf Tagen gebaut und von mir selbst am Gerät abgenommen. Die flatternde Quellenwahl ebenso. In meinem Aufgabenheft standen beide weiter als offen, weil beim Bauen die Zeile nicht nachgezogen worden war.
Hätte niemand nachgesehen, hätte ich heute Abend dieselbe Arbeit ein zweites Mal bezahlt.
Ich habe darauf gute Arbeit geantwortet, und das meine ich auch so. Nicht weil der Fehler schön ist — sondern weil er von selbst aufgefallen ist, bevor er etwas gekostet hat. Ein Heft, in dem etwas falsch steht, ist ein normales Problem. Ein Heft, in dem etwas falsch steht und es niemandem auffällt, ist ein anderes.
---
Die anderen Schiffe
Dann kam die Sache mit dem AIS, und die ist von einer Art, über die ich zwischendurch lachen musste.
Unser Bordnetz sendet die Positionen der Schiffe ringsum. Das tut es, seit ich das Gateway zum ersten Mal angeschlossen habe. An dem Abend in Warnemünde, als ich den Mitschnitt gemacht habe, waren es hundertsieben Schiffe, die meisten davon mit Namen — die Fähre nach Gedser, ein Taucherschiff, ein Ausflugsdampfer, eine ganze Reihe Segler am Steg nebenan.
PELARON hat sie zwei Wochen lang brav entgegengenommen, zusammengesetzt und dann weggeworfen. Nicht aus Versehen kaputt, sondern einfach nie gedeutet. Es fehlte nirgends etwas, es stand nirgends ein Fehler — die Daten liefen durch und verschwanden.
Mein Gedanke dazu war ziemlich unromantisch: Die App soll sich auch weiterentwickeln. Es ist ja gut, dass es auffällt. Jetzt stehen sie da, mit Namen und Abstand, und ich kann bei Gelegenheit nachsehen, wer da eigentlich neben mir liegt.
Wichtiger war mir die Frage, was damit passieren soll. Unter Fahrt braucht mich niemand zu wecken — dafür habe ich den Plotter, der macht das seit Jahren und macht es gut. Was ich unter Fahrt will, ist eine Zeile im Logbuch, wenn mir wirklich jemand nah gekommen ist, und zwar eine je Begegnung und nicht hundert. Vor Anker ist es umgekehrt: Da schlafe ich, da ist der Plotter aus, und da will ich geweckt werden, wenn mir einer zu nah kommt.
Es gibt dazu eine hübsche Zahl. An meinem Mitschnitt vom Liegeplatz wurde nachgerechnet, wie viele Logbucheinträge welche Regel erzeugt hätte: Ohne die Bedingung, dass das andere Schiff auch wirklich fährt, wären es in einer knappen Stunde siebzehn gewesen. Siebzehn Zeilen, alle von den Nachbarn am Steg, alle ohne jede Bedeutung. Mit der Bedingung: keine einzige.
Genau darum geht es. Ein Logbuch, das man nicht mehr lesen mag, ist keines.
---
Das hier wiegt schwerer
Und dann war da noch ein Befund, den ich nicht so leicht weglege.
Die Ankerwache kann in einen Zustand kommen, in dem sie nicht weiß, wo das Boot liegt. Die Position fällt aus, sie wird als unmöglicher Sprung verworfen, das Gateway fällt weg, die Antenne ist abgeschattet — es gibt genug Wege dorthin. Bis heute hat sie in diesem Zustand auf dem Bildschirm „Position unsicher“ angezeigt, in grauer Schrift, und sonst nichts getan.
Kein Ton. Keine Meldung. Nichts.
Das heißt: Ich hätte in der Koje gelegen und geschlafen, und die Wache wäre blind gewesen, ohne dass ich es erfahren hätte. Wer schläft, sieht nicht auf den Bildschirm. Wer auf den Bildschirm sieht, braucht die Wache nicht.
Das hat mich ehrlich bewegt. Sicherheitsvorkommnisse dieser Art dürfen einfach nicht geschehen. Es geht hier nicht um eine Zahl, die falsch gerundet ist, oder um eine Tafel, die hässlich aussieht — es geht um das eine, wofür diese Funktion überhaupt da ist. Eine Ankerwache hat genau eine Aufgabe, und wenn sie diese Aufgabe nicht erfüllen kann, dann ist die einzige ehrliche Auskunft die, dass sie es nicht kann. Laut, mit Ton, so wie bei allem anderen auch.
Jetzt ist es gebaut: Nach einer Minute ohne brauchbare Position steht es in der Vorgangstafel, nach fünf Minuten geht der Alarm los, und im Logbuch steht die Lücke. Wer später fragt, ob in dieser Nacht gewacht wurde, findet die Antwort dort, wo sie hingehört.
In Teil 40 habe ich geschrieben: lieber einmal mehr als einmal zu wenig. Das war die eine Seite — eine Wache, die zu oft weckt, ist mir lieber als eine, die zu selten weckt. Heute habe ich die andere Seite gesehen, und die ist schlimmer als beide. Eine Wache, die gar nichts sagt, weckt nicht zu selten. Sie weckt nie.
---
Der Rest des Abends
Drei Bauläufe hat es gebraucht, bis der Kern wieder durchlief. Beim ersten haben Fallunterscheidungen gefehlt, die beim Dazubauen übersehen worden waren; beim zweiten fielen vier Prüffälle, von denen zwei echte Fehler gefunden haben — einer davon hätte dazu geführt, dass die Ankerwache viel zu spät Alarm schlägt.
Das ärgert mich weniger, als man denken könnte. Diese Fehler sind am Schreibtisch gefallen, um acht Uhr abends, bei Licht. Nicht nachts, nicht vor Anker, nicht in dem Moment, in dem es darauf angekommen wäre. Genau dafür sind die Prüffälle da, und heute haben sie geliefert.
Am Ende des Tages: fünfzehnhundertsechsundvierzig davon, alle grün. Die Prüfliste am Schreibtisch komplett durch. Was offen bleibt, braucht das Boot — und das Boot liegt noch bis November im Wasser.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.