Entwicklungstagebuch · Teil 29

Der Deckel war null Punkt hoch

Entwicklungstagebuch, Teil 29 · 31. August 2026, ganzer Tag

Entwicklungstagebuch, Teil 29 · 31. August 2026, ganzer Tag

Drei Fehler an diesem Tag haben eines gemeinsam: Sie sind fehlerfrei übersetzt worden. Xcode hat nichts gesagt. Es gab keine Warnung, keine gelbe Zeile, kein Ausrufezeichen. Der Code war richtig geschrieben — er tat nur nichts.

Ich schreibe diesen Teil deshalb von hinten nach vorn.

Der Törn rutscht, und das ist alles

Am Morgen stand über der Aufgabenliste noch „noch drei Tage“. Am Vormittag kam die Starkwindwarnung für Freitag und Samstag. Ich habe den Törn um eine Woche verschoben.

Ich wurde gefragt, was das mit mir macht. Die ehrliche Antwort: nichts. Eine Woche später ist eine Woche später. Wenn überhaupt, habe ich gedacht: na wenigstens etwas mehr Zeit zum Bauen der nativen App.

Das schreibe ich hier auf, weil in der ersten Fassung dieses Absatzes eine Enttäuschung stand, die es nicht gab. Sie war gut formuliert und komplett erfunden. Seit Teil 26 gilt bei mir die Regel, dass vor jedem Tagebuchteil gefragt wird, statt geraten. Das hier ist der Grund dafür.

Die Zahl, die nicht geschätzt war

Der Tag fing mit den Gezeiten an. Für den Schwojradius braucht man den Wasserstand, und ich hatte mich für die Zwölferregel entschieden — der alte Seemannsdreisatz: In sechs Stunden Tide fallen 1, 2, 3, 3, 2, 1 Zwölftel des Hubs.

Im Kern stand als Kommentar, die Regel weiche „rund vier Hundertstel des Hubs“ von der Sinuskurve ab. Das war geschätzt. Also wurde nachgerechnet, über die ganze Kurve, in feinen Schritten. Es sind 2,555 Prozent. Der Kommentar ist berichtigt, und ein Prüffall hält die Zahl jetzt fest.

Danach wollte ich es an echten Werten sehen, und dabei sind zwei Dinge schiefgegangen, die ich beide unterhaltsam finde:

Der erste Versuch, die Pegeldaten für Warnemünde zu holen, lief auf einen Fehler 404. Die Adresse hieß WARNEMUENDE, die Station heißt WARNEMÜNDE. Umlaut. Nicht mein Umlaut — der Behörde ihrer.

Der zweite Versuch fand die Hoch- und Niedrigwasser über einen Vergleich mit den Nachbarwerten. Bei einer Reihe mit Zentimeterauflösung stehen aber immer wieder zwei gleiche Werte nebeneinander, und die galten damit als beides gleichzeitig. Ich bekam tausende Scheitel für einen Tag.

Am Ende: 1436 Messwerte, Wasserstand zwischen 497 und 512 Zentimetern. Fünfzehn Zentimeter Unterschied über einen ganzen Tag. Das ist die Ostsee, und es ist genau der Grund, warum ich mir bei diesem Bereich am wenigsten vormache: Was hier zählt, ist der Windstau, nicht der Mond.

Die Taste, die nichts tat

Nachmittags habe ich geschrieben:

taste als tidenhub übernehmen ist ohne funktion

Und weil ich weiß, dass die Frage kommt: der rest hat funktioniert.

Der Gezeitenrechner steckte in einem Aufklapper, und dieser Aufklapper hatte eine zweizeilige Überschrift. Das ist der Unterschied. Ein Aufklapper legt seine Aufklapp-Geste über seine Überschrift; ist die nur ein Wort, bleibt sie dort. Ist sie ein Block mit eigener Höhe, greift sie weiter — und dann verliert eine Taste darunter den Tastendruck gegen sie. Textfelder und Datumswähler nicht, die bringen eine höher gestellte Bedienung mit.

Genau das war zu sehen: alles ging, nur die Taste nicht.

Ersetzt wurde der Aufklapper durch einen eigenen, der keine fremde Geste mitbringt — ein Knopf und ein if, mehr nicht. Und daraus wurde Regel 34 im Prüfer.

Ich habe damals gedacht: gut, das ist erledigt.

Die Bootsakte, und warum ich scannen wollte

Am Nachmittag kam der Bereich Dokumente. Meine Webfassung kann dort Dateien anhängen, Fristen führen, Kategorien. Was sie nicht kann: die Kamera als Scanner benutzen. Ein Browser darf das nicht.

Ich habe geschrieben, das soll die native App können. Und dazu: ansehen, an jeder Zeile, ohne Umweg.

Ich wurde gefragt, ob ich dabei an ein bestimmtes Papier gedacht habe. Habe ich nicht. Ich habe einfach das Gehirn angeschaltet — so, wie es einem Selbstständigen mit gewissen Papieren in der täglichen Arbeit eben passiert. Man kennt das Gefühl, etwas zu suchen, von dem man genau weiß, dass man es hat.

Gebaut wurde es mit dem Bauteil, das auch in Notizen und Dateien den Scanner stellt: Kantenerkennung, Entzerrung, mehrere Seiten hintereinander. Die Seiten werden zu einem PDF gerechnet, jede in ihrer eigenen Größe — ein Bootsschein hat zwei Seiten, eine Werftrechnung fünf, und fünf Einzeldateien wären kein Beleg.

Eine Sache daran gefällt mir besonders, weil sie ohne mich entstanden ist: Nichts wird abgelegt, bevor „Sichern“ gedrückt ist. Wer eine Police durch eine falsche ersetzt und dann abbricht, hat die alte noch. Der erste Entwurf hatte sofort kopiert. Die Begründung für die Änderung stand im Code, bevor ich sie lesen konnte:

Ein Bogen, der „abgebrochen“ sagt und die Platte trotzdem verändert hat, ist eine Lüge.

Zwei Fragen, zwei Felder

Abends kam Medizin — Bordapotheke, Vorfälle, Notfallangaben der Crew.

Beim Auslesen meiner Webfassung fiel etwas auf, das mir in Jahren nicht aufgefallen ist: Ich habe dort zwei verschiedene Wortlisten für dieselbe Frage. Im Logbogen steht „stabil, verschlechtert sich, bessert sich, nicht ansprechbar“. Im Vorfallbogen steht „stabil, weiter beobachten, ärztliche Hilfe nötig, erledigt“.

Beim Nachsehen ist das nicht eine Liste zu viel, sondern zwei Fragen, die durcheinandergeraten sind. Wie geht es der Person — und was folgt daraus. Nativ sind daraus zwei Felder geworden. „Bessert sich, aber ärztliche Hilfe nötig“ kann ich in meiner Webfassung nicht aufschreiben. Sie muss sich entscheiden.

Der Funkspruch hat zwei Stufen, und PAN PAN ist vorbelegt. Der Grund steht seit Wochen in meiner eigenen Webfassung, und ich zitiere ihn hier, weil er richtig ist: MAYDAY bindet Rettungsmittel, die anderswo fehlen können. Die Höherstufung muss eine bewusste Handlung sein und darf nicht aus einem Zustandsfeld abgeleitet werden.

Und was ins Logbuch geht, ist weniger als das, was im Bereich steht: „Ein medizinischer Vorfall lag vor.“ Kein Name, keine Diagnose. Ein Logbuch wird vorgezeigt; eine Krankenakte nicht. Das steht jetzt nicht nur als Satz da, sondern im Code — der Eintrag bekommt die Felder für Person und Ereignis ausdrücklich nicht, obwohl es sie gibt.

Drei Fehler, die fehlerfrei übersetzen

Und jetzt zu dem, was diesen Tag ausmacht.

Der erste. Seit ich die Navigationsleiste habe verstecken lassen — sie kostete fünfzig Punkt für ein leeres Feld —, läuft beim Scrollen der Inhalt oben ins Freie. Am Vormittag stand „Törns und Ereignisse“ quer über der Uhrzeit. Es wurde ein Deckel gebaut, ich habe ihn geprüft, er stand in der Prüfliste, ich habe abgehakt.

Am Nachmittag habe ich in der Bootsakte gescrollt, und da stand „Digitale Bootsakte“ wieder halb im Bild und der orange Knopf über der Batterieanzeige. Ich habe das Foto geschickt und gefragt, ob etwas auffällt.

Der Deckel sah so aus:

Gestalt.papier
    .frame(height: 0)
    .ignoresSafeArea(edges: .top)

Er war null Punkt hoch. Der Befehl, der ihn in den Systembereich hätte wachsen lassen, vergrößert keine Ansicht — er erlaubt einer Ansicht nur, dort hineinzuzeichnen. Eine Fläche ohne Höhe hat nichts zu zeichnen.

Der zweite. Abends habe ich den Nachtmodus eingeschaltet und geschrieben:

die STATUSANZEIGEN nicht mehr sehe im nachtmodus, also „offen“ „abgeschlossen“ etc.

Der rote Filter lag als Multiplikation über der App. Eine Multiplikation behält nur den Rotkanal. Nachgerechnet:

LampeFarbenach dem Filter
kritisch#C0211F(192, 7, 4) — kräftiges Rot
Handlungsbedarf#F27600(242, 26, 0) — Rot
geprüft#198754(25, 30, 10) — fast schwarz
unbekannt#6A7B87(106, 27, 16) — kaum etwas

Dazu die Verdunklung. Grün landete bei (16, 20, 7). Alles, was seine Helligkeit aus Grün oder Blau bezieht, war nachts weg — ausgerechnet bei den Wörtern, die sagen, ob etwas offen ist.

Die Berichtigung ist eine Zeile: erst entsättigen, dann einfärben. Dann bleibt die Helligkeit stehen und nur der Farbton geht. Der Nachtmodus ist jetzt einfarbig rot statt „rötlich mit Farbresten“, und das ist kein Verlust, sondern der Zweck. Nachts unterscheidet man nach dem Wort, nicht nach der Farbe.

Der dritte. Eine halbe Stunde später:

bei längeren drücken des mondes passiert .... nix, es verändert sich nix

Der Mondknopf schaltet den Nachtmodus mit einem Tipp; gedrückt halten sollte die Einstellungen öffnen. Es war ein Button mit einem angehängten langen Druck. Ein Knopf bringt seine eigene Gestenerkennung mit — was von außen danebengelegt wird, verliert gegen sie.

Das ist derselbe Fehler wie am Vormittag, nur umgekehrt. Beim Aufklapper lag die fremde Geste unter dem Bedienelement, hier liegt sie darauf. Beide Male gewinnt die eingebaute Erkennung. Beide Male passiert einfach nichts.

Der schlimmere Teil war ein anderer: Dass man den Mond gedrückt halten kann, stand nur im Blatt. Also dort, wo man erst hinkommt, wenn man es schon weiß. Jetzt steht der Weg sichtbar unter System & Diagnose.

Eine Prüfung, die nicht scheitern kann

Der Deckel ist mir am meisten nachgegangen, und zwar nicht wegen des Codes.

Punkt 1 meiner Prüfliste vom Vormittag lautete: „Überschrift und Knöpfe verschwinden hinter einem Streifen in Papierton.“ Es gibt einen Streifen — acht Punkt Sicherheitsabstand, die es schon vorher gab. Der Inhalt läuft hinter ihm durch und darüber weiter ins Freie. Ich habe hingesehen, den Streifen gesehen und abgehakt.

Der Prüfpunkt konnte bestehen, ohne dass die Sache funktioniert.

In Teil 28 steht der Satz, eine Prüfung, die Richtiges meldet, sei schlimmer als keine, weil sie zum Wegsehen erzieht. Jetzt habe ich den Gegenfall: Eine Prüfung, die nichts melden kann, erzieht zum Abhaken. Beides sind keine Prüfungen.

Am Abend ist das noch einmal passiert, und diesmal auf der anderen Seite. Für den Mondknopf wurde eine neue Prüferregel gebaut, mit einem eingebauten Probefehler getestet — und sie hat geschwiegen. Sie lief bis zur ersten schließenden Klammer, und das ist bei einem Knopf mit zwei Bauteilen erst die Hälfte. Nachgebessert, noch einmal geprobt, dann meldete sie.

Dritte Regel an einem Tag, deren erste Fassung nachgeschärft werden musste. Und die einzige, die dabei gar nichts meldete statt zu viel. Ich weiß jetzt, welche der beiden Sorten mir mehr Sorgen macht.

Drei Geräte, ein Stand

Zwischendurch habe ich aufgeschrieben, was ich mir für später wünsche: Logbuch unterwegs auf dem iPad, Nachbereitung zu Hause am MacBook. Ich arbeite zu Hause mit dem Rechner — Törn planen, etwas suchen, andere Dinge. Eine haptische Tastatur ist mir dabei immer lieber als das Glas.

Und dann kam die Nachfrage, ob das eine Kopie sein soll oder derselbe Stand. Derselbe Stand, natürlich. Es nützt nichts, wenn ich daheim etwas einfüge und an Bord nicht mehr finde. Das beste Beispiel liegt gerade auf dem Tisch: An Bord sind die Versicherungsunterlagen — und die Werft braucht davon eine Kopie fürs Winterlager.

Damit ist eine Entscheidung von heute vormittag hinfällig. Ich hatte zugestimmt, dass die Dokumentangaben in die Sicherung gehen und die Dateien nicht, wegen der Größe. Für eine Sicherung stimmt das. Für den Abgleich nicht — eine Bootsakte, die auf dem Rechner nur sagt „Haftpflicht 2026, gültig bis 21.04.2027“, ohne dass ich die Police herausgeben kann, ist ein Verzeichnis und keine Akte.

Dazu kommt das iPhone. Das ist nicht abends zu Hause, sondern mit mir an Bord, während das iPad am Kartentisch liegt. Drei Geräte gehen nicht mehr paarweise. Sie brauchen eine gemeinsame Stelle — und daneben einen Weg, auf dem iPhone und iPad sich auch ohne Netz einig werden, im Boots-WLAN.

Gebaut ist davon nichts. Vorbereitet ist zweierlei: Die medizinischen Daten tragen seit heute ein Zeichen, das sagt „geht nie über das Netz“, damit es beim Bau des Abgleichs nicht vergessen werden kann. Und die neuen Datensätze tragen einen Änderungszeitpunkt — ohne den kann kein Abgleich sagen, welche von zwei Fassungen die jüngere ist, und einer, der rät, ist schlimmer als keiner.

Von acht Dateien im Kern haben ihn jetzt drei. Fünf fehlen. Das ist der nächste Schritt, und er ist billig, solange die Dateien klein sind.

Wo wir jetzt stehen

Mein iPad war den halben Tag beim Sohn. Gebaut habe ich trotzdem — über WLAN aufs Gerät, aus dem Nebenzimmer. Aufgefallen ist es an einem Ordnernamen: Debug-iphoneos statt Debug-iphonesimulator. Die Maschine hatte vermutet, es sei der Simulator, und musste die Vermutung zurücknehmen.

Am Ende des Tages:

gestern Abendheute
Bereiche gebaut15 von 2118 von 21
Kern67 Dateien, 470 Prüffälle78 Dateien, 624 Prüffälle
App-Schicht47 Dateien, 33 Regeln62 Dateien, 42 Regeln

Dreizehn Lieferungen an die native App, fünf an meine Webfassung, eine an die Website. Neun neue Prüferregeln an einem Tag, jede einzelne aus einem eigenen Fehler entstanden, dazu eine im Kern.

Offen sind noch drei Bereiche: BSH-Nachrichten für Seefahrer, Analysen, der Assistent.

Und der Satz, den ich mir aus diesem Tag mitnehme, ist keiner über Segeln:

Ein Fehler, der eine Fehlermeldung erzeugt, ist der harmlose. Der andere übersetzt sich sauber, startet ordentlich und tut einfach nichts — und du findest ihn erst, wenn du ihn brauchst.

Am Donnerstag stehe ich vielleicht am Boot. Der Törn ist jetzt eine Woche später.

← Zurück zum Entwicklungstagebuch

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