Der Anker war bereits oben

Entwicklungstagebuch, Teil 31 · 2. September 2026, ganzer Tag

Der Tag hatte zwei Hälften, und sie hätten kaum verschiedener sein können.

Die erste bestand daraus, dass ich immer wieder dieselben Fehler zurückgemeldet habe. In der zweiten sind sieben Lieferungen gebaut worden, Apple hat nach zehn Tagen die Freigabe geschickt, und am Ende hat mir die eigene Totmannschaltung einen Fehler gezeigt, der größer war als sie selbst.

Dazwischen liegt ein Satz, den ich mittags getippt habe und der den Rest des Tages verändert hat.

Ein Komma, das nicht kommen wollte

Angefangen hat es klein. Die Tiefenwache hat eine Schwelle — wie viel Wasser unter dem Kiel bleiben muss, bevor es klingelt. Ich wollte sie auf 1,5 Meter stellen.

die schwelle kann ich nicht über 0,99 setzen, kommen nicht an die vorkommastelle

Das Feld ließ mich nur zwei Nachkommastellen tippen und schluckte alles davor. Es kam eine Berichtigung. Dann das nächste:

leerer bekomme ich das feld nicht, wieder ein fehler :-(

Und danach noch eins:

null bleibt auch stehen und springt nicht zurück auf 0,5, wieder fehler

Drei Anläufe für ein Zahlenfeld. Ich stand immer noch bei Punkt 1 der Prüfliste.

Das Ärgerliche daran ist nicht das Feld. Es ist, dass ich jedes Mal bauen musste, um zu sehen, dass es wieder nicht stimmt. Jeder Anlauf kostet mich eine Viertelstunde am Mac und eine Übertragung aufs iPad.

Und es ist nicht der einzelne Fehler, der einen fertigmacht. Es ist das Gefühl, alles mehrfach sagen zu müssen — und die Arbeit kommt trotzdem nicht so zurück. Ein Fehler, den ich einmal beschreibe, darf beim zweiten Mal nicht wieder dastehen. Hier stand er über mehrere Lieferungen hinweg immer wieder da, und das ist etwas anderes als ein Versehen.

Die gepackten Dateien

Dann kam etwas, das mich mehr aufgeregt hat als das Feld.

Ich habe die Lieferungen als gepackte Archive bekommen — Dateien, die ich selbst entpacken und einsortieren soll. Dabei steht seit Tagen im Aufgabenheft, dass die Dateien direkt in den Projektordner gehören. Der Ordner liegt offen, Xcode nimmt neue Dateien von selbst auf, weil das Projekt seine Quellen aus dem Dateisystem liest und nicht aus einer Liste.

und warum hast du wie im aufgabenheft nicht entpackt?

Und als klar wurde, dass ich vorher schon mehrere solche Pakete von Hand ausgepackt hatte:

ich brauche diese scheiß gepackten dateien nicht!!!!

Es geht dabei nicht um Bequemlichkeit. Jedes Paket, das ich selbst auspacke, ist eine Stelle, an der eine Datei im falschen Ordner landen kann — und dann suche ich einen Fehler, den es gar nicht gibt.

Zwanzig Dokumente, eine Regel

Der eigentliche Bruch kam am frühen Nachmittag. Ich hatte mehrmals auf Regeln verwiesen, die längst aufgeschrieben waren, und bekam trotzdem etwas anderes.

steht alles im aufgabenheft, liest du das überhaupt?? dran halten tust du dich jedenfalls nicht

Beim Nachsehen kam heraus: Die Regeln standen tatsächlich alle da. Nur eben verteilt über mehr als zwanzig Dokumente — jede in dem Übergabepapier des Tages, an dem sie entstanden war. Zusammen zweiundvierzig Stück, keine davon an einer Stelle, an der man alle sieht.

Und dann noch, als die Suche erst nach dem Bauen begann:

warum suchst du jetzt erst, dass hast du dir durchzulesen bevor die arbeiten beginnen und dich dann danach zu richten

Seitdem stehen sie in einer Datei, und die wird zu Sitzungsbeginn gelesen. Ich habe an dem Nachmittag noch etwas anderes geschrieben, und das war eigentlich die ganze Anweisung:

denke lieber länger nach, prüfe und messe und liefere erst dann

Danach lief es. Nicht weil irgendetwas Neues gebaut wurde, sondern weil vor jeder Lieferung erst gemessen wurde. Sieben Lieferungen am Nachmittag und Abend, sechs davon auf Anhieb bestanden.

Der Fehler, der auf meinem Boot gar nicht auffällt

Einer der Befunde hat mich beim Lesen stutzen lassen, weil er mich selbst nie getroffen hätte.

Die App kann Bordnetzdaten lesen. Auf der Bluebaerry hängt ein NMEA-2000-Netz, und das versteht sie. Der ältere Standard — NMEA 0183, die Sätze, die mit $GPRMC und $SDDBT anfangen — wurde zwar empfangen, gezählt und als „nicht verstanden“ beiseitegelegt. Gedeutet wurde kein einziger.

Auf meinem Boot merkt das niemand. Auf einem Boot mit einem älteren Gateway hätte die App überhaupt nichts angezeigt: Verbindung steht, Daten kommen an, Bildschirm leer.

Ich hatte das vor Wochen schon einmal gesagt, in einem anderen Zusammenhang: Wir bauen das für alle Netzwerkarten, nicht nur für meine. Jetzt werden vierzehn Satzarten gedeutet — Position, Kurs, Fahrt, Tiefe, Wind, Log, Steuerkurs, Wassertemperatur.

Der Seewetterbericht kommt jetzt vom Amt

Zwei Sachen, die ich mir gewünscht hatte, sind an dem Nachmittag gebaut worden.

Die Wellenperiode — bis dahin stand im Logbuch nur die Wellenhöhe. Zwei Meter mit vier Sekunden Periode sind ein steiler, unangenehmer Seegang; zwei Meter mit elf Sekunden ist eine lange Dünung, in der man schlafen kann. Die Höhe allein sagt darüber nichts.

Und der Seewetterbericht des Deutschen Wetterdienstes. Nicht die Modellzahlen, die die App ohnehin schon holt, sondern der Bericht, wie er im Seefunk verlesen wird: Nord- und Ostsee, neun Gebiete, mit Seegang. Dazu die Küstenvorhersage mit acht Gebieten.

Mein Wunsch dazu war, dass die App das Gebiet einblendet, das zur Position des Schiffes passt, und die Wellenperiode mit ins Logbuch schreibt. Je genauer und detaillierter das Logbuch, desto besser.

Was ich nicht wollte: die Umlaute zurückwandeln. Der Rohtext des DWD schreibt ae, oe, ue, und ich habe zuerst gefragt, ob man das nicht lesbarer machen kann. Dann kam die Überlegung, dass eine Rückwandlung raten muss — bei Eigennamen und Abkürzungen geht das schief, und ein Wetterbericht, der Wörter erfindet, ist schlimmer als einer, der Boeen schreibt. Also bleibt der Wortlaut, wie ihn das Amt sendet. Er steht auf einem eigenen Blatt, umschaltbar zwischen gegliederter Darstellung und Wortlaut, mit dem Quellenvermerk darunter.

Die Mail um halb sechs

Am späten Nachmittag kam etwas, worauf ich seit dem 24. August gewartet habe.

Apple hat die kritischen Hinweise freigegeben.

Das ist die Erlaubnis, eine Mitteilung zu schicken, die den Lautlos-Schalter und den Fokusmodus durchbricht. Für einen Wecker, der um drei Uhr nachts sagt, dass das Boot aus dem Ankerkreis läuft, ist das keine Spielerei — ein Alarm, den „Nicht stören“ schluckt, ist kein Alarm.

Zehn Tage Wartezeit, und man bekommt sie nicht einfach so — man muss begründen, wofür man sie braucht.

Was ich beim Lesen empfunden habe, war schlicht Erleichterung. Nicht Triumph, nicht abgehakt. Der Ankeralarm ist der Grund, aus dem diese App überhaupt angefangen hat, und ohne diese Erlaubnis hätte er nachts gegen einen Schalter verloren, den man abends aus ganz anderen Gründen umlegt.

Eingerichtet war es am selben Abend. Die Berechtigung ist übrigens die einzige in Xcode, die man nicht anklicken kann — sie muss von Hand in eine Datei geschrieben werden. Dafür gab es dann eine eigene Anleitung, Schritt für Schritt, weil ich das an einem Abend nach der Arbeit nicht suchen wollte.

Fünf Meter gibt es nicht

Zwischendurch ein kleiner Punkt, der zeigt, wie schnell etwas Erfundenes in eine Prüfliste rutscht.

In der Prüfliste stand, ich solle den Ankerradius auf 5 Meter stellen. Ich habe es versucht:

ankerradius geht auch nicht auf 5 Meter

Ging auch nicht, und zwar zu Recht: Der Schieber geht von 10 bis 250 Meter, und das steht auf dem Bildschirm daneben. Die 5 waren einfach hingeschrieben worden, ohne nachzusehen.

Das ist dieselbe Sorte Fehler wie die erfundenen Prüfsummen vom Vormittag — es sieht plausibel aus, es ist nur nicht gemessen. Eine Prüfliste, die eine Einstellung verlangt, die es nicht gibt, verbrennt meine Zeit an einer Stelle, an der gar nichts kaputt ist.

Der Anker war bereits oben

Und dann der Moment, um den es in diesem Teil eigentlich geht.

Ich saß zu Hause im Garten. Der Anker war im Garten gesetzt — das klingt albern, ist aber die einzige Art, eine Ankerwache zu prüfen, ohne dafür rauszufahren.

Ich habe die Totmannschaltung geprüft. Sie ist dafür gebaut, dass ich merke, wenn die Wache aufhört zu wachen — weil das iPad ausgeht, die App abstürzt, iOS sie schließt. Kommt eine Viertelstunde lang keine Position mehr an, meldet sie sich.

Sie hat funktioniert. Der Alarm kam, und mein erstes Gefühl war Erleichterung: Sie meldet sich also wirklich. Das ist die eine Sache, die diese Schaltung können muss, und sie konnte es.

Dann habe ich die App geöffnet.

die totmannschaltung hat gegriffen, hat alarm gemeldet, allerdings war nach öffnen der app, der anker bereits oben

Und da war die Freude wieder weg. Der Wecker hat geklingelt, und was ich danach in der Hand hatte, war nichts.

Der Ankerpunkt lag nur im Arbeitsspeicher. Position, Radius, Ankergrund, meine Bemerkung zum Ankerplatz, der gemerkte Fallpunkt — alles weg, sobald iOS die App beendet.

Das heißt: Genau in dem Fall, für den die Totmannschaltung überhaupt gebaut ist, weckt sie mich, ich stehe nachts an Deck, ich mache das iPad an — und die Ankerwache ist leer. Ich weiß nicht mehr, wo der Anker gefallen ist, und ich weiß nicht, ob das Boot noch dort liegt.

Die Totmannschaltung hat bei ihrem ersten Einsatz etwas gefunden, das größer war als sie selbst.

Eine Wache, die sich still wieder aufnimmt, lügt

Bei der Frage, was die App nach einem Neustart tun soll, gab es zwei Möglichkeiten: die Wache selbst wieder scharf stellen, oder fragen.

Ich habe gesagt: immer fragen.

Der Grund ist derselbe, aus dem hier schon manches nicht gebaut wurde. Eine Wache, die sich nach einem Neustart still selbst wieder aufnimmt, behauptet damit, sie hätte durchgewacht. Hat sie aber nicht. In der Lücke — fünf Minuten oder fünf Stunden — hat niemand hingesehen, und das Boot kann in dieser Zeit geschwojt sein oder der Anker geslippt.

Also steht die wiedergefundene Wache jetzt ganz oben auf dem Ankerbildschirm, mit der Länge der Unterbrechung, dem Ankerpunkt in Grad und Dezimalminuten, dem Radius, dem Ankergrund und meiner Bemerkung. Zwei Knöpfe: wieder aufnehmen, oder verwerfen, weil der Anker oben ist. Und darunter der Satz, dass ich vorher prüfen soll, ob das Boot überhaupt noch da liegt.

Die Länge der Unterbrechung zählt weiter, solange die Tafel dasteht. Sie endet nicht damit, dass ich die App öffne — sie endet, wenn ich antippe. Solange ich davorstehe und überlege, wacht auch niemand.

Die Lieferung, die nie ankam

Zum Schluss noch etwas, das mir gefallen hat, obwohl es ein Fehler war.

Vor dem Ablegen der letzten Lieferung wurde nicht einfach kopiert, sondern vorher der ganze Projektordner gegen den Arbeitsstand gemessen — alle 166 Swift-Dateien einzeln, mit Prüfsumme. Erwartet waren vier Unterschiede: die vier Dateien der neuen Lieferung.

Es waren fünf.

Die fünfte war eine Datei vom Nachmittag, die berichtigt worden war und nie bei mir angekommen ist. Ich hatte seit 16:41 Uhr mit der alten Fassung gebaut. Auf den Prüfpunkt, an dem ich gerade saß, hatte das keine Auswirkung — aber gefunden hat es niemand durch Nachdenken. Gefunden hat es das Messen.

Genau das ist der Punkt, an dem ich heute Mittag gestanden habe. Eine Lieferung, die „geliefert“ heißt und nicht auf meinem Rechner liegt, ist keine Lieferung. Und sie fällt sonst erst auf, wenn irgendein Prüfpunkt scheitert und man den Grund an einer ganz anderen Stelle sucht.

Wo wir jetzt stehen

Sechs Prüflisten abgearbeitet, eine liegt für morgen bereit.

Was ich mir vom Vormittag merke, ist nicht der einzelne Fehler. Es ist, dass derselbe über mehrere Lieferungen hinweg stehen blieb, obwohl ich ihn beim ersten Mal beschrieben hatte. Ein Fehler ist ein Fehler. Ein Fehler, den man zum dritten Mal erklärt, ist eine Arbeitsweise.

Und der Satz, den ich aus dem ganzen Tag mitnehme, ist der, den ich mittags selbst getippt habe — und den ich abends von der anderen Seite wiederbekommen habe:

Prüfen und messen kommt vor dem Liefern. Auch dann noch, wenn schon geliefert ist.

← Zurück zum Entwicklungstagebuch

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