main
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DogFatherGit
|
077925ab25 |
Dreizehn rote Pruefungen, eine Ursache: openssl steht nicht im PATH
DER BEFUND
Im naechtlichen Lauf standen dreizehn Pruefungen mit derselben Zeile
rot:
[uncaughtException] Error: spawnSync openssl ENOENT
Kein Programmfehler. Die Pruefungen brauchen einen https-Vorbau (der
Sitzungskeks des Hauses ist `secure` und kommt ueber http nicht an),
und dafuer erzeugen sie ein Wegwerf-Zertifikat mit openssl.
GEMESSEN, NICHT VERMUTET
openssl liegt hier: C:\Program Files\Git\mingw64\bin\openssl.exe
C:\Program Files\Git\usr\bin\openssl.exe
im System-PATH steht: C:\Program Files\Git\cmd (nur git.exe)
im Benutzer-PATH: nichts mit Git
Wer aus Git Bash startet, erbt die mingw-Pfade und merkt nie etwas.
Die Aufgabenplanung startet `node.exe` DIREKT, ohne Shell -- und
bekommt sie nicht. Bei mir gruen, nachts rot, und der Grund steht
nicht im Code.
Das Schlimmste daran ist nicht der Ausfall: Dreizehn dauerhaft rote
Zeilen in einer Notiz, die Filipe morgens liest, gewoehnen einem das
Hinsehen ab -- und decken dabei die echten Befunde zu.
DIE REPARATUR
`server/helfer-openssl.mjs` sucht openssl erst im PATH (ohne `where`
oder `which` -- beides sind selbst Programme und koennen genauso
fehlen), danach an den Orten, an denen es auf einem Windows-Rechner
mit Git wirklich liegt.
Dazu `zertifikatBauen(schluessel, zertifikat, host)`. Die acht
Aufrufformen im Haus waren identisch bis auf die Variablennamen
(schl/zert, schluesselDatei/zertDatei, zKey/zCrt, sk/zt, key/crt) --
eine Stelle traegt alle neunundzwanzig. Zwei Tage zuvor war eine
davon um ein `-addext` aermer als die anderen; gemerkt hat es
niemand, weil der Browser den fehlenden Alternativnamen erst bei
einer Weiterleitung anmahnt. Eine Stelle kann nicht von sich selbst
abweichen.
KEIN EINTRAG IN DEN SYSTEM-PATH. `mingw64\bin` enthaelt rund hundert
Programme mit Unix-Namen (`find`, `sort`, `link`), die gleichnamige
Windows-Befehle verdecken. Das fuer eine Pruefung zu aendern haette
an ganz anderen Stellen Fehler verursacht, die niemand hierher
zurueckverfolgt.
GEGENPROBE IN BEIDE RICHTUNGEN, mit dem PATH des Nachtlaufs:
vorher (direkter Aufruf): ABSTURZ: spawnSync openssl ENOENT
nachher (ueber den Helfer): Zertifikat gebaut, 1236 Bytes
Und eine echte Pruefung unter denselben Bedingungen:
PATH ohne mingw64 -> pruef-chat-neu-stelle
63 Pruefungen, 0 Fehler, 0 Abstuerze
Genau diese Datei stand im Nachtlauf mit ENOENT rot.
EINE WACHE DAGEGEN
pruef-struktur prueft ab jetzt, dass niemand openssl wieder direkt
ruft -- der naechste merkt es dort und nicht erst in einem
Nachtlauf, den niemand liest. Drei Gegenproben.
Beim ersten Anlauf schlug sie auf ihre EIGENEN Probetexte an: Sie
liest alle Serverdateien, und dazu gehoert sie selbst. Die Texte
werden jetzt zusammengesetzt. Derselbe Selbsttreffer ist mir heute
schon zweimal passiert.
DER DRITTE AUSGANG BLEIBT, WO ER HINGEHOERT
`helfer-kachel-echtfarbe.mjs` faengt den Fehler weiterhin ab und
meldet `moeglich: false` mit Grund, statt abzubrechen. Eine
Sicherung abzuschaffen, weil ihr Anlass gerade behoben ist, ist der
Anfang des naechsten stillen Fehlschlags.
NEBENBEI: pruef-community-sicht
Sie war rot mit "ZU VIEL: reaktion.html" -- mein eigener Rueckstand
vom 28.09. Die Reaction steht als Kachel im Community-Bereich; die
Liste war nicht nachgezogen. Jetzt 10 / 0.
Die Liste bleibt bewusst von Hand gepflegt: Sie ist eine ABSICHT,
keine Ableitung. Aus rechte.js gelesen verglichen sich zwei Kopien
derselben Quelle -- immer gruen, nie ein Beweis.
GEPRUEFT
pruef-struktur ALLES IN ORDNUNG (mit der neuen Wache)
pruef-community-sicht 10 / 0
pruef-chat-neu-stelle 63 / 0 (mit dem PATH des Nachtlaufs)
pruef-notizen, -teamlage-karten, -werdegang: EXIT 0, keine Abstuerze
mess-quer EXIT 0
29 Dateien: node --check auf allen, kein direkter Aufruf mehr
|
||
|
DogFatherGit
|
b846693de5 |
Die letzten fuenf blinden Messungen bekommen einen Finger
Die Grundlinie der Fingerwache sinkt von 6 auf 1.
DIE SCHWEREN FAELLE
pruef-notizen, pruef-teamlage-karten, pruef-terminregel,
pruef-werdegang, pruef-befinden.
Bei diesen fuenf stand mitten im Ablauf ein
`setViewportSize({ width: 390 })`. Das aendert nur die Groesse --
`hasTouch` gehoert zum KONTEXT und ist beim Anlegen entschieden.
Nachtragen geht nicht; es braucht ein zweites Fenster.
DAS MUSTER, DAS FUER ALLE FUENF GETRAGEN HAT
const handyKontext = await browser.newContext({
viewport: { width: 390, height: 844 }, hasTouch: true, isMobile: true });
await handyKontext.addCookies(await kontext.cookies());
const handy = await handyKontext.newPage();
await handy.goto(seite.url(), { waitUntil: "networkidle" });
Drei Entscheidungen darin:
- Die Anmeldung wandert als Keks mit, statt sie zu wiederholen.
Eine zweite Anmeldung waere eine zweite Stelle, die veralten
kann.
- Die Adresse kommt von `seite.url()`. Sie ein zweites Mal
hinzuschreiben waere eine zweite Wahrheit darueber, welche
Seite gemessen wird.
- Das fruehere Zuruecksetzen auf 1280 px faellt weg. Die breite
Seite war nie schmal -- es gibt nichts zurueckzustellen.
Bei pruef-terminregel liessen sich die vier Schritte, die den
schwebenden Hinweis erzeugen, nicht uebernehmen: Sie werden im
neuen Kontext nachgefahren (oeffnen, "Neu", Datum eintragen).
ALLE FUENF DANACH GRUEN
pruef-notizen EXIT 0
pruef-teamlage-karten EXIT 0 (39 geprueft)
pruef-terminregel EXIT 0 (35 Pruefungen)
pruef-werdegang EXIT 0
pruef-befinden EXIT 0
Diese Seiten halten die Fingerregeln also schon ein. Es hatte nur
nie jemand nachgesehen.
EINES BLEIBT: pruef-grosscheck
Die Datei zu aendern waere ein Zweizeiler. Sie zu PRUEFEN hiesse,
206 Seiten ueber vier Rollen und zwei Bildschirmgroessen laufen zu
lassen -- das braucht Filipes Zusage. Eine Aenderung, die ich nicht
pruefen darf, liefere ich nicht aus. Die Grundlinie steht deshalb
auf 1 und nicht auf 0.
GEPRUEFT
pruef-fingermass 3 / 0, neun Gegenproben, Grundlinie 1
|
||
 DogFatherGitandClaude Opus 5
|
256ea6f7c0 |
Team-Lage: die linke Hand traegt ihre Farbe -- und die rechte genauso
Filipe, mit dem Bildschirmfoto der Team-Lage: "die farbe der kachel soll die gleiche sein wie die farbe die der text linke hand hat, aber mach es richtig knallig so wie die farben bei den modis und linke hand. soll schoen auffallen bitte." AUF DEM FOTO WAR GENAU DAS DAS PROBLEM -------------------------------------- Die Marke "Linke Hand" leuchtet lila, die Karte darunter war fast farblos: Sie fiel auf den Ton der STUFE zurueck -- dieselbe Lage wie bei der rechten Hand vor dem 20.09. "DIE GLEICHE FARBE" IST NICHTS, WAS MAN AUFSCHREIBT --------------------------------------------------- Es ist etwas, das man ABLEITET. `#f0c14b`, `#d8a7f5` und `#8fd6ff` standen bisher verteilt in den Dateien: bei der Gruppenueberschrift, bei der Rollenmarke, und das Gold ein drittes Mal in module.css an der Karte. Drei Orte fuer dieselbe Farbe sind drei Gelegenheiten, dass einer beim naechsten Anstrich nicht mitgeht -- und dann traegt die Marke ein anderes Lila als die Karte, auf der sie liegt. Jetzt stehen die drei Toene an einer Stelle (:root in team.css) und werden ueberall von dort geholt. Auch die Namensfarbe ist abgeleitet statt aufgeschrieben: Sie war `#f7e3ac` und (im ersten Anlauf fuer die linke Hand) `#f2ddff` -- beides nichts anderes als "der Ton, stark aufgehellt". ICH HAETTE FAST EINE RANGORDNUNG GEBAUT --------------------------------------- Erst habe ich nur die linke Karte angefasst: Lila startet bei 34 % Ton, das Gold lag weiter bei den 11 %, die jede Karte hat. Nebeneinander sah die rechte Hand ploetzlich aus wie die schwaechere von beiden -- eine Rangordnung, die niemand bestellt hat. Daneben stand mein eigener, gerade erst geschriebener Kommentar: "gleiche Mittel, gleiche Staerke". Ein Kommentar, der eine Absicht beschreibt, erfuellt sie nicht. Jetzt EINE Regel fuer beide Haende; der Unterschied ist der Ton und sonst nichts. Wer morgen an der Wirkung dreht, dreht sie fuer beide. "RICHTIG KNALLIG" IST EINE ANWEISUNG, KEINE STIMMUNG ----------------------------------------------------- Deshalb tragen diese beiden Karten ihre Farbe auch in der FLAECHE und nicht nur an der Kante. Augenschonend bleibt es trotzdem, und das ist kein Widerspruch, sondern die Bedingung: kraeftig heisst GESAETTIGT, nicht hell. Der Grund bleibt sehr dunkel, die Farbe liegt als Verlauf darueber. Gemessen bei 1280 und 390 px, am gezeichneten Bildschirm: linke Hand Name 15,11:1 · Kleingedrucktes 8,18:1 · Marke 11,18:1 rechte Hand Name 15,63:1 · Kleingedrucktes 8,07:1 · Marke 12,49:1 Verlangt sind 4,5. MEINE ERSTE MESSUNG WAR FALSCH, UND SIE SAH ECHT AUS ----------------------------------------------------- Sie las `rgb(13, 8, 23)` und `color(srgb 0.87 0.71 0.96)` mit derselben Rechnung. Die zweite Schreibweise zaehlt aber in 0..1, nicht in 0..255 -- die helle Rollenmarke kam damit auf 1,09:1. Eine Zahl, die aussieht wie ein schwerer Befund und keiner ist; haette ich ihr geglaubt, haette ich eine funktionierende Farbe "repariert". Die Umrechnung steht jetzt ausgeschrieben in der Pruefung, samt Grund. GEPRUEFT -------- pruef-teamlage-karten: 39 Pruefungen, 0 Fehler (vorher 25). Neu darin: Traegt die Karte denselben Ton wie ihre Marke? Sind es zwei verschiedene Toene? Liegt die Farbe in der Flaeche? Tragen beide Haende dieselbe Staerke? Und: kann man den Text darauf noch lesen? Mit Gegenproben, die beide Richtungen abdecken: Eine Modi-Karte traegt die Leiste NICHT (sonst faellt keine auf), und mit absichtlich falschem Ton auf der linken Karte werden genau zwei Zeilen rot -- gemessen. Kein Neustart noetig: Es aendert sich nur Ausgeliefertes (CSS, Stempel) und eine Pruefdatei, die der Dienst gar nicht laedt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4b0cda7334 |
screen4: Die linke Hand ist ueberall zu sehen -- rechte Hand, linke Hand, Modis
"ich will dass die linke hand auch ueberall zu sehen ist. reihenfolge
immer. rechte hand, dan linke hand und dan modis. perfektionier das
bitte."
DER BEFUND: In workspace-teamlage.js stand
WHERE rolle IN ('hand','modi')
Eine abgeschriebene Rollenliste, und die linke Hand kam darin nicht
vor. Sie fehlte damit nicht nur als KARTE: Der Eingang derselben
Seite sammelt die Rueckmeldungen aus genau dieser Liste. Was sie
meldet, waere nirgends angekommen -- dasselbe, was am 11.09. schon
der rechten Hand passiert ist, an derselben Zeile.
Dieselbe Liste ein zweites Mal in workspace-bereiche.js: Ein Eintrag
im Entwicklungsbereich liess sich ihr nicht zuordnen, mit der Meldung
"Diese Person gehoert nicht zum Team." -- ueber jemanden, der sehr
wohl dazugehoert.
Beide lesen jetzt TEAM_DOGI_ROLLEN, die eine Liste des Hauses
({hand, linke, modi}). Kaeme morgen eine weitere Team-Rolle, waere
sie von selbst dabei.
DIE REIHENFOLGE STIMMTE SCHON. ROLLEN_REIHE nennt hand vor linke vor
modi, ROLLEN_SORTIERUNG leitet daraus das CASE ab. Sie war nur nie zu
sehen, weil eine der drei fehlte.
WARUM DIE PRUEFUNG DAS NICHT GEFUNDEN HAT -- und was daran mein
Fehler war: pruef-teamlage-karten legte eine rechte Hand und fuenf
Modis an, aber KEINE linke Hand. Eine Rolle, die in den Testdaten
nicht vorkommt, kann auch nicht vermisst werden. Sie ist jetzt dabei,
und drei neue Zeilen messen die Reihenfolge gegen ROLLEN_REIHE statt
gegen drei hier hingeschriebene Namen:
hand → linke → modi
"Rechte Hand 1 · Linke Hand 1 · Modi 5"
25 Pruefungen, 0 Fehler.
NEBENBEI: EIN EIGENER MESSFEHLER, DEN ICH RICHTIGSTELLEN MUSS
Auf dem Weg dorthin habe ich behauptet, der linken Hand fehlten
FUENFZEHN Seiten in der Rechtetafel. Das war falsch gemessen: Ich
habe den QUELLTEXT von rechte.js gelesen statt das Verhalten. Die
Tafel leitet seit dem 21.09. ab -- „die linke Hand bekommt die Seiten
der rechten", mit fuenf ausdruecklich begruendeten Ausnahmen
(Personen anlegen, Talente, Bewerbungen, vertraulicher Meldeweg,
Rechtetafel). Ueber `darfSeite` gemessen fehlen ihr genau diese fuenf,
und das ist so gewollt.
Derselbe Fehler wie heute Nacht bei pruef-haus-seiten, wo ich zwei
Listen mit einem regulaeren Ausdruck aus dem Quelltext lesen wollte.
Eine Regel steht im Code; ob sie WIRKT, sagt nur eine Messung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ba0e326585 |
Team-Lage: fuenf Stufen mit eigener Farbe, Karten neu gebaut, 404 wirft nicht mehr hinaus
B7 -- "wenn ich auf diese sachen drücke werd ich auf die startseite geschickt" und "ich will das es ein zwei kategorien mehr gibt und das soll geiler aussehen und jede seine eigene farbe, stark erkennbar" 1. DER RAUSWURF. Ein Druck auf einen Stufen-Knopf schickte auf die Startseite. Ursache: `hole()` stand ACHTMAL Zeichen fuer Zeichen gleich in acht Dateien, und darin warf JEDER 404 hinaus -- auch der auf eine blosse Handlung. Jetzt eine gemeinsame `assets/js/holen.js` mit der engeren, abgeleiteten Regel: Ein 404 wirft nur, solange die Seite noch gar nichts bekommen hat. 2. ZWEI STUFEN MEHR, und keine davon erfunden: "Fortgeschritten" gibt es im Entwicklungs-Katalog laengst (ENTWICKLUNG_ERWARTUNG), hier fehlte genau diese Mitte; "Vertretung" stand bis heute IN der Beschreibung von Senior. Keine Datenbankaenderung noetig -- die Spalte ist absichtlich ein TEXT ohne CHECK. 3. DIE FARBEN SIND GERECHNET. Nachgemessen lagen "Probe" und "Standard" bei 0,0576 OKLab-Abstand; MINDEST_ABSTAND ist 0,090 -- die beiden waren nebeneinander dieselbe Farbe, und alle drei lagen unter MINDEST_BUNTHEIT. Die neuen fuenf sind ein Faecher aus fuenf Farbwinkeln im Abstand von 72 Grad; der Versatz ist der, bei dem der kleinste Abstand am groessten wird. Ergebnis: 0,1531 untereinander, 0,1108 zur Rollenmarke daneben, Kontrast 7,4 bis 8,6. B8 -- "die sollen viel krasser geiler und übersichtlicher sein ... und die kacheln sollen viel krass geiler und spezieller aussehen auch der hintergrund, veränder das komplett" 4. DIE KARTE IST NEU: Kopfband in der Farbe der Stufe bis an die Kanten, Zeichen von 44 auf 52 px mit Ring, Zahlenband als eigene Flaeche, neuer Hintergrund (Farbschein unter dem Kopfband, feine Schraffur, dunklere Platte). 781 px hoch gemessen, danach 746. 5. DIE ROLLE STEHT JETZT DA -- als Marke auf der Karte und als Ueberschrift ueber jeder Gruppe. Sortiert war schon vorher nach Rolle; man konnte es nur nicht sehen. DREI FEHLER, DIE DABEI AUFFIELEN * `auto-fit` liess die einzelne Karte der rechten Hand ueber die ganze Bildschirmbreite laufen, sobald gruppiert wurde. `auto-fill` haelt die leeren Spalten offen. * Der Name der Person trug `tperson__namen` statt `tperson__name` -- ein Buchstabe, und damit die Klasse fuer graues Kleingedrucktes. Auf einer Seite ueber Personen war der Name kleiner als die Beschriftung darunter. Gefunden hat es die neue Pruefung, die ueberall "?" las. * `stufeSetzen()` suchte das Stufen-Schild mit `[class*="tmerkmal--"]:not(...)` -- einer Aufzaehlung dessen, was es NICHT ist. Sobald die Rollenmarke davorstand, traf die Suche sie: Ein Druck auf "Standard" haette aus "Modi" das Wort "Standard" gemacht. Und die Karte faerbte sich beim Setzen nicht mit um. DREI PRUEFUNGEN, ALLE MIT GEGENPROBE * pruef-holen.mjs (NEU, 14): fuehrt die echte Datei aus und misst fuenf Wege; dieselben fuenf noch einmal an der ALTEN Fassung, die bei genau zwei durchfallen muss. Dazu: laedt jede der acht Seiten holen.js, und zwar VOR ihrem Skript. * pruef-teamlage-karten.mjs (NEU, 22): im Browser. Gruppen, Rollenwort, Stufenknoepfe nur bei Modis, der Druck selbst (kein Sprung, ein Abruf, Schild und Kartenfarbe ziehen mit), Gegenprobe mit dem zweiten Druck, und die neuen Baender auf 390 px. * pruef-team-stufen.mjs (28 -> 47): die abgeschriebene Liste ["probe","standard","senior"] ist raus -- geprueft werden jetzt Eigenschaften und die Farbabstaende, gelesen aus team.css. Gegenprobe ist der Stand von gestern, der durch dieselbe Messung faellt. Co-Authored-By: Claude Opus 5 <[email protected]> |