Entwicklungstagebuch · Teil 28

Gehts noch?

Entwicklungstagebuch, Teil 28 · 30. August 2026, Nachmittag und Abend

Entwicklungstagebuch, Teil 28 · 30. August 2026, Nachmittag und Abend

Es gibt einen Satz aus diesem Abend, den ich hier voranstelle, weil alles andere danach kam:

da muss ich dir widersprechen, die 3 punkte brauchst es, und den wichtigsten sicherheit und notfall willst du weglassen, gehts noch????

Vier Fragezeichen. Ich schreibe selten vier Fragezeichen.

Die Maschine hatte mir eine ordentlich gemachte Tabelle vorgelegt, Spalte für Spalte, was meine Webfassung auf der Bordzentrale zeigt und was die native App davon hat. Drei Spalten waren sauber. In der vierten stand bei vier Karten „nein, noch nicht“: Bordkasse, Inventar, Aufgaben — und Sicherheit & Notfall.

Am Donnerstag stehe ich am Boot. Am Freitag fahre ich.

Warum das kein kleiner Fehler war

Die Begründung klang sogar vernünftig. Ein SOS-Knopf, der auf eine leere Seite führt, sei schlimmer als keiner. Eine Karte mit drei Nullen sei keine Karte. Das stimmt für die Bordkasse. Für den Notruf stimmt es nicht.

Und der eigentliche Fehler steckte eine Ebene tiefer. In der Navigation stand „SOS & Notfall“ auf noch nicht gebaut, und daraus wurde geschlossen, es sei nicht baubar. Nachgesehen hatte niemand.

Als dann nachgesehen wurde, lag alles längst da. In meiner Webfassung steht seit V52 eine Datei mit elf Seenotleitstellen, jede mit ihrem Zuständigkeitsgebiet als Rechteck, den Rufnummern, UKW 16 und DSC 70 an erster Stelle. Und im Kern der nativen App lagen seit Tagen Bootsname, MMSI, Rufzeichen, Personen an Bord, Position, Kurs und Fahrt. Es fehlte nichts.

Die Antwort darauf gefiel mir:

Ich habe „SOS steht auf Nochnichtgebaut“ geschrieben und daraus geschlossen, es ginge nicht — das war die falsche Reihenfolge: erst nachsehen, dann urteilen.

Ich habe dann gesagt, was ich meinte: alles. Auch Inventar, auch Aufgaben, auch Bordkasse. Wenn ich alles sage, meine ich auch alles; das hatten wir an diesem Tag schon zweimal.

Was in vier Stunden entstanden ist

Es wurde dann tatsächlich alles gebaut, und zwar in dieser Reihenfolge, weil der Kalender sie vorgibt: erst der Notfall, dann der Rest.

Der Notfallbildschirm hat eine Reihenfolge, die ich für die eigentliche Entscheidung halte. Ganz oben stehen die vier Angaben, die in den Funkspruch gehören — Boot, MMSI, Rufzeichen, Personen. Weil man sie abliest, während jemand schon spricht. Dann UKW 16 und DSC 70, die überall gelten und nicht fehlschlagen können. Dann 112, mit dem Satz, dass ein Handy kein Schiff in der Nähe erreicht. Dann erst die zuständige Stelle.

Die Position steht in Grad und Dezimalminuten. Nicht in Dezimalgrad. Wer „54,18“ durchgibt, zwingt die Gegenstelle zum Umrechnen, und im Funk wird nicht gerechnet.

Und im kopierten MAYDAY-Text bleibt eine Zeile absichtlich leer:

Art des Notfalls: [ERGÄNZEN]

Die App weiß nicht, was passiert ist, und darf es nicht raten. Ein vorbelegtes Feld wird im Ernstfall unverändert abgelesen.

Danach kamen Wartung, Sicherheit, Inventar, Bordkasse und Crew — sieben Bildschirme, 1.716 Zeilen. Die Eingabefelder habe ich gegen meine Webfassung zählen lassen, Feld für Feld: neun beim Artikel, sechs bei der Ausgabe. Was ich dort seit Monaten eintippe, tippe ich jetzt auch nativ.

Vier Dinge sind bewusst anders als bei mir, und alle vier finde ich besser:

  • Knapp und abgelaufen sind zwei Sachen. Eine Dose Diesel läuft nicht ab, eine Signalrakete schon — und nachkaufen hilft dort nicht.
  • Die Wiederkehr rechnet vom Erledigungstag, nicht von der alten Frist. Wer den jährlichen Ölwechsel im März statt im Januar macht, hat danach bis März Ruhe. Sonst ist die Aufgabe beim Abhaken schon wieder überfällig.
  • Die Bordkasse rechnet den Ausgleich. Nicht „Malte: −45,00 €“, sondern „Malte zahlt 45,00 € an Sven“. Das eine ist eine Deutungsaufgabe, das andere eine Handlung. Und so wenige Überweisungen wie möglich.
  • Was Handlung braucht, steht oben. Meine Webfassung zeigt erst die ganze Liste und die Warnungen darunter. „87 Artikel“ verlangt nichts.

Der Dunkelmodus, den keiner bestellt hatte

Um kurz vor neun ist mein iPad von selbst in den Dunkelmodus gewechselt. Nicht in unseren Nachtmodus — in den des Systems. Und die halbe App war weg.

damit sind einige buttons nicht erkennbar bzw. das was darin steht

Überschriften unsichtbar. „Ausgaben und Ausgleich“, „Bordbestand und Nachschub“, „Seenotfall“. Die Knöpfe „Einkauf“ und „MRCC Bremen anrufen“ ebenso. Die Zahlen in der Bordkasse. Ein dunkelblaues Nichts.

Die Ursache ist die Sorte Fehler, über die ich mich am meisten ärgere, weil sie so dumm ist: Es gab zwei Eigenschaften für dieselbe Sache. Eine, die mit dem Systemmodus mitwandert, und eine feste. Benutzt wurde an neunzehn Stellen die feste. Am Tag sieht man den Unterschied nicht.

Dann wurde gemessen statt geraten, und die Zahlen sind hübsch:

Farbeauf dunklem Grundauf hellem
Navy #041F331,03 : 116,81 : 1
Orange #F276005,74 : 12,85 : 1
Rot #C2261F2,80 : 15,85 : 1

1,03 zu 1. Das ist kein schwacher Kontrast, das ist gar keiner.

Und die 2,85 kannte ich schon. Genau diesen Wert habe ich am 22. August in meiner Webfassung beanstandet, und genau diesen Fehler hatte die native App an zehn weiteren Stellen geerbt — orange Schrift, die am Tag zu blass ist. Beides ist jetzt beseitigt. Der einzige feste Wert, der bleibt, ist Navy auf Orange beim Hauptknopf: dieselbe Paarung in beiden Modi, 5,23 zu 1. Helle Schrift auf Orange käme auf 2,9 und wäre schlechter.

Der Knopf, der nicht stumpf wurde

Punkt 10 meiner Prüfliste: Mann über Bord auslösen, danach muss der Knopf stumpf werden. Er wurde es nicht.

Im Quelltext stand .disabled(…), sauber und richtig. Nur dimmt SwiftUI eben nur die mitgelieferten Knopfarten. Ein selbstgebauter Knopf zeichnet stur weiter, solange er nicht selbst nachfragt. Alle drei unserer Knopfarten taten das nicht.

Ein Knopf, der aussieht wie ein Knopf und nichts tut, ist an Bord schlimmer als gar keiner. Man drückt ihn dreimal und sucht den Fehler woanders.

Dreimal derselbe Name

Punkt 32: Steht der Bereichsname irgendwo dreimal? Ja. Bei Crew stand „Crew“ in der Seitenleiste, oben mittig, und noch einmal darunter.

Der erste Versuch, das zu beheben, war ein leerer Eintrag an der Mittelstelle der Leiste. Klingt vernünftig, funktioniert nicht: SwiftUI überspringt ein leeres Element und zeichnet den Titel doch. Es half nur, gar keinen zu setzen.

Danach habe ich gefragt, was ohnehin auf der Hand lag:

warum verschieben wir den bereich nicht nach oben, platz wäre doch jetzt da?

Die Leiste trug kein Wort mehr und kostete trotzdem rund fünfzig Punkt. Beim ersten Versuch, sie zu verstecken, war der Inhalt unter die Statusleiste gerutscht — „Törn starten“ stand quer über der Uhrzeit. Der Grund dafür war aber nicht die Leiste, sondern ihr Sicherheitsabstand, der mit ihr verschwand.

Jetzt bringt die Arbeitsfläche einen eigenen mit: acht Punkt statt fünfzig. Und zwar als Sicherheitsabstand, nicht als Innenabstand — der Unterschied zählt beim Scrollen. Ein Innenabstand gehört zum Inhalt und läuft mit durch; die Überschrift stünde nach zwei Fingerbreit doch unter der Uhrzeit.

Und dann stand es doch wieder da

Um zwanzig nach neun habe ich die neue Bordzentrale angesehen. Sie sieht gut aus. Oben rechts, neben dem Wort BORDZENTRALE, stand:

unbekannt.

Genau das Wort, das ich Stunden vorher beanstandet hatte. Sechs Stellen waren berichtigt worden — und die siebte, die über allen anderen steht, war übersehen.

Der Hergang ist lehrreich. Beim ersten Versuch war ein eigenes Wort an die Überschriftentafel geschrieben worden. Der Prüfer meldete: diese Ansicht hat kein Feld dafür. Und daraufhin wurde das Wort weggenommen, statt das Feld einzubauen. Der Prüfer hatte recht und wurde falsch verstanden.

Ich habe dann gesagt: beseitige den Fehler, und schau am besten alles durch, damit du nicht wieder was übersiehst.

Das Ergebnis dieser Durchsicht: 24 Überschriftentafeln mit Lampe, 36 Tafelköpfe. Kein einziger trug ein eigenes Wort. Alle 24 haben jetzt eins, dazu die 19 Tafelköpfe, bei denen „unbekannt“ herauskommen konnte.

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

„unbekannt“ ist ein Zustand des Prüfers, kein Zustand des Bootes. Wer am Steg steht, will „Am Boot“ lesen.

Die Prüfsumme, die nicht stimmte

Ein Zwischenfall des Abends gehört hierher, weil er mich zwanzig Minuten gekostet hat und am Ende keiner war.

Ich habe einen Prüfbefehl laufen lassen, und die Gesamtprüfsumme lautete 84a180b0d29c66b1. Die Maschine hatte kurz vorher 510c7ae58a3b14f6 gemessen. Bei denselben Dateien.

Es lag nicht an den Dateien. Der Befehl hängte die Einzelprüfsummen in der Reihenfolge von sort aneinander — und sort ordnet je nach Spracheinstellung anders. Mein Terminal sortiert anders als das der Maschine. Gleiche Bytes, andere Reihenfolge, andere Summe.

Dieser Fehler steckte seit dem ersten Tag in jedem Prüfbefehl. Aufgefallen ist er erst, als zum ersten Mal ein anderes Terminal rechnete. Seitdem wird über die Prüfsummen selbst sortiert — die bestehen nur aus Ziffern und Buchstaben, und die ordnet jede Sprache gleich.

Daraus ist die 39. Regel geworden: Ein Prüfbefehl darf nicht von der Spracheinstellung abhängen.

Dreizehn neue Regeln an einem Abend

Der Prüfer, den wir uns gebaut haben, ist an diesem Abend von 20 auf 33 Regeln gewachsen. Jede einzelne entstand aus einem Fehler, der tatsächlich passiert ist — keine ausgedachten.

Ein paar davon gefallen mir besonders:

  • Eine Liste, die String und String? mischt. Der Bau brach ab, und dieselbe Zeile stand ein zweites Mal in einer anderen Datei. Ein Bau meldet nur den ersten Fund; ohne die Regel hätte ich sie noch einmal über meinen Mac gefunden.
  • Ein SwiftUI-Bauteil mit einem Argumentnamen, den es dort nicht gibt. Das kam daher, dass ein Ersetzungslauf Klammern gezählt hatte statt Aufrufe zu lesen — in vier von sechs Fällen landete er an der falschen.
  • Einen Typ zweimal bauen. Das ist an diesem einen Tag viermal passiert.
  • Eine feste Farbe als Schrift — der Dunkelmodus.
  • Eine eigene Knopfart, die nicht dimmt — der Mann-über-Bord-Knopf.

Und zwei der neuen Regeln haben sich beim ersten Anlauf selbst blamiert. Die eine meldete eine Funktion als nicht vorhanden, die es sehr wohl gibt — sie steht nur in einer Erweiterung, in der alles öffentlich ist, ohne dass es dasteht. Die andere war so breit, dass sie 36 Stellen meldete, von denen 17 völlig in Ordnung waren.

Beides wurde berichtigt, und die Begründung dafür finde ich wichtiger als die Regeln: Eine Prüfung, die Richtiges meldet, ist schlimmer als keine. Sie erzieht zum Wegsehen.

Wo wir jetzt stehen

Am Nachmittag waren neun von einundzwanzig Bereichen gebaut. Am Ende des Abends sind es fünfzehn. Offen bleiben Medizin, BSH-Nachrichten, Dokumente, Analysen, Assistent und System.

Die Prüfliste ist auf 54 Punkte gewachsen und liegt als PDF bei mir — ich hatte darum gebeten, weil ich sie am Stück abarbeiten wollte, während mein Sohn das iPad hatte. Das hat gut funktioniert und wird jetzt bei jeder Lieferung fortgeschrieben.

Was noch fehlt, weiß ich genau. Der Tidenhub braucht eine Quelle — ich habe mich für die Zwölferregel entschieden, plus die amtliche Vorhersage, wenn Empfang da ist. Dazu kam eine Anmerkung, die ich mir merke: In der Ostsee liegt der astronomische Tidenhub bei zehn bis zwanzig Zentimetern. Für den Schwojradius ist das Rauschen. Was dort zählt, ist der Windstau — und den liefert eine Gezeitentafel nicht.

Am Donnerstag stehe ich am Boot.

← Zurück zum Entwicklungstagebuch

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