Entwicklungstagebuch, Teil 10 · 19. August 2026
Jemand anders hat sich PELARON angesehen. Nicht ich, nicht die Maschine, die den Code schreibt — ein Prüfbericht von außen, zwanzig Punkte lang, mit Noten von 9,1 für die Website bis 7,0 für die Verkaufsreife.
Die Versuchung ist, so etwas von oben nach unten abzuarbeiten. Ich habe es anders gemacht und die Punkte zuerst danach sortiert, ob sie stimmen.
Das hat einen Tag gekostet und war jede Stunde wert.
Messwert 0,0
Der schwerste Befund stand in der Mitte des Berichts, zwischen zwei Formulierungsfragen.
Das Demo-Boot hat keine Tanks, keine Batteriebänke und keine Motorquelle. Trotzdem meldete die App:
Kraftstoffreserve prüfen · Messwert 0,0
Der Zeitstempel war von heute, 19:13 Uhr. Kein alter Verlaufseintrag — die Regel feuerte gerade.
Die Ursache ist eine Zeile, und sie ist lehrreicher als der Fehler.
Die Funktion, die den Messwert liefert, macht alles richtig: Ist kein Tank eingerichtet, gibt sie ausdrücklich „kein Wert“ zurück und nicht etwa null. Genau die Unterscheidung, die der Prüfbericht fordert, war eingebaut.
Die Auswertung hat sie unbrauchbar gemacht. Sie wandelt den Wert in eine Zahl um und prüft danach, ob es eine gültige Zahl ist. Nur ergibt die Umwandlung von „kein Wert“ die Zahl null, und null ist gültig. Danach ist null kleiner als zwanzig, die Regel greift, und die Meldung schreibt „Messwert 0,0“ — weil der Wert an dieser Stelle tatsächlich null ist.
Die Schutzabfrage stand da. Die Umwandlung davor hat sie ausgehebelt.
Das Bemerkenswerte: Bei einem fehlenden Feld hätte es funktioniert. Es scheitert ausgerechnet an dem Wert, den die richtige Seite absichtlich sendet, um zu sagen, dass sie nichts weiß.
Vier Zeilen. Vorher prüfen statt nachher.
Dreißig Sekunden
Der Prüfer suchte Häfen bei Rostock und wartete rund dreißig Sekunden, während nur „Marinas werden gesucht …“ dastand.
Die Marinasuche fragt drei Kartendienst-Spiegel ab, jeden mit einer Zeitgrenze von zwanzig Sekunden. Nacheinander. Antwortet der erste nicht, wartet man seine volle Grenze ab, bevor überhaupt jemand anders gefragt wird. Im schlimmsten Fall dreimal zwanzig.
Und jetzt kommt der Teil, der mich beschäftigt hat.
Über der Abrufschicht in einer anderen Datei steht seit dem 14. August ein Kommentar von mir, der genau davor warnt: nacheinander summieren sich die Wartezeiten. Gemeint waren dort die Spiegel innerhalb einer Abfrage. Eine Ebene höher passierte dasselbe, in einer anderen Datei, unbemerkt.
Das ist, soweit ich sehe, das erste Mal, dass diese Gestalt in meinem Tagebuch steht: Eine Regel gab es schon — und eine andere Stelle kannte sie nicht. Am 28. August habe ich sie an einem einzigen Tag siebzehnmal wiedergefunden.
Jetzt laufen die drei gleichzeitig. Aus fünfundvierzig Sekunden im schlimmsten Fall werden fünfzehn, aus achtzehn werden drei.
Nebenbei fiel auf, dass die App nach zwanzig Sekunden auflegte, während die Abfrage selbst bis fünfundzwanzig rechnen durfte — wir haben also Antworten weggeworfen, auf die wir gewartet hatten.
Ein Fähranleger ist keine Marina
Unter den Treffern standen ein Fährterminal, ein namenloser Eintrag „Marina / Hafen“ und mehrere Stege ohne erkennbaren Gastliegeplatz.
Das kommt aus der Abfrage. Sie holt drei Merkmale aus OpenStreetMap, und zwei davon erfassen jeden Hafen — auch einen Fähranleger, auch einen Umschlaghafen.
Wer als Segler einen Hafen sucht, sucht einen Liegeplatz. Nicht jede Stelle, an der ein Schiff festmachen kann.
Zwei Zeichen für dieselbe Marke
pelaron.de und pelaron.app trugen verschiedene Zeichen. Die Website die Wortmarke mit den zwei Bögen und den Segeln, die App ein quadratisches Symbol.
Erklärbar ist es — das Quadrat ist als Symbol für den Startbildschirm entstanden, wo eine Wortmarke nicht funktioniert, und dann in die Kopfzeile gewandert. Wann das passiert ist, weiß ich bis heute nicht.
Jetzt steht in beiden dasselbe Zeichen. Das Quadrat bleibt, wo es hingehört: Startbildschirm, Favicon, Kachel.
Was ich mitnehme
Zwanzig Befunde. Davon zwölf bestätigt, einer ernst, zwei bereits behoben, einer selbst falsch, zwei nicht nachvollziehbar.
Ein Tag Arbeit, um sie zu sortieren, bevor eine einzige Zeile geändert wurde.
Ein fremder Befund ist eine Beobachtung, keine Aufgabe. Vor der Aufnahme in die Liste steht die Frage, womit gemessen wurde.
Denn ein Abruf ohne Skriptausführung sieht die halbe Seite nicht — genau der Fehler, der mir in Teil 4 selbst passiert ist, als das Tagebuch angeblich nicht verlinkt war. Eine Ladezeit vor einer Serveränderung ist keine Ladezeit danach: Die im Bericht genannten 4,9 Sekunden waren vor der Kompression gemessen, heute sind es 1159 Millisekunden auf dem iPad über Hotspot.
Und eine Angabe über mein eigenes Boot kann falsch sein, auch wenn vier andere davor stimmten.
Die beiden Korrekturen, die den Tag am meisten wert waren, standen in keinem Bericht: die Seemeilen und die Länge des Wetterfensters.
Beide kamen nicht vom Prüfen, sondern vom Segeln.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.