Artikel

Wenn Sie ein Modell um eine Antwort in JSON bitten, funktioniert json.loads() meistens problemlos. Die Ausfälle sind die, die Sie eine Debugging-Sitzung kosten: ein einzeiliger Kommentar innerhalb des Objekts, ein Markdown-Code-Fence darum, ein Schlüssel als userEmail geschrieben, wo Ihr Code user_email erwartet. Ein strikterer Prompt (“antworte NUR mit dem JSON-Objekt, kein weiterer Text”) macht diese Fälle seltener. Unmöglich macht er sie nicht, denn das Modell kann die Anweisung trotzdem ignorieren. Strukturierte Ausgabe macht diese Anweisung überflüssig: Sie übergeben der API ein JSON Schema, und das schränkt das Token-Sampling des Modells selbst so ein, dass die Antwort dazu passen muss. ...

Sie schreiben .sidebar .card { color: blue; }, laden die Seite, und die Card ist immer noch rot — wegen einer Regel, die Sie eine Stunde vorher hinzugefügt haben: .card { color: red; }. Ihre neue Regel steht später in der Datei. Sie verliert trotzdem. Der Browser vergleicht die beiden Selektoren mit einem festen Punktesystem, und .sidebar .card erhält eine höhere Punktzahl als .card, egal welcher zuletzt geschrieben wurde. Dieses Punktesystem ist die Spezifität. Sobald Sie sie auf den ersten Blick berechnen können, wird “warum wirkt mein CSS nicht” zu Arithmetik. Mit dem Layout hat das nichts zu tun: Grid oder Flexbox entscheidet, wo ein Element sitzt; die Spezifität entscheidet, welche Regel Farbe oder Größe setzt, wenn zwei Regeln sich widersprechen. ...

Ob Sie einen Schlüssel in einem Python-dict mit zehn Einträgen suchen oder in einem mit zehn Millionen: Es dauert gleich lange. Das liegt nicht an einer besonders schnellen Sprache. Pythons dict, Javas HashMap und JavaScripts Map sind allesamt Hash-Tabellen, und das gesamte Design existiert, damit Suche, Einfügen und Löschen im Durchschnitt mit O(1) laufen. Die Big-O-Notation nennt diese Suche “konstante Zeit”. Hier ist der Mechanismus, der das verdient. Wie eine Hash-Tabelle einen Schlüssel in einen Array-Index umwandelt Eine Hash-Tabelle ist ein Array plus eine Funktion, die einen Schlüssel in eine Position in diesem Array umwandelt. ...

Ein C-Programm, das einen Buffer freigibt und trotzdem weiter daraus liest, kompiliert problemlos. Danach beschädigt es den Speicher, manchmal sofort, manchmal erst drei Requests später, in einem Teil des Codes, der diesen Buffer nie berührt hat. Rust lehnt dieses Programm schon beim cargo build ab, ganz ohne Garbage Collector. Der Compiler verfolgt, wem jeder Wert gehört und wer ihn ansehen darf. Dieses Verfolgen ist Ownership und Borrowing. Was sind Rusts Ownership-Regeln? Rusts Ownership-Modell lässt sich auf drei Regeln zurückführen: ...

Ein Test für place_order braucht ein Payment-Gateway, einen SMS-Client und einen Steuerrechner. Setzen Sie die echten Objekte ein: Jeder Testlauf belastet dann eine Karte und verschickt eine SMS an eine echte Telefonnummer. Ein Unit-Test soll in Millisekunden laufen, ohne Netzwerkzugriff — also müssen alle drei durch etwas anderes ersetzt werden. Dieses „etwas andere“ gibt es in fünf Varianten, die jeweils ein anderes Problem lösen. Wer sie für austauschbar hält, erlebt im Code-Review immer wieder dieselbe Debatte: „dann mock das doch einfach“. ...

Sie speichern eine Datei, Prettier formatiert sie neu, und ESLint meldet sofort einen Fehler in der Zeile, die Prettier gerade angefasst hat. Beide Tools sind konfiguriert, beide laufen, und statt zu helfen, bekämpfen sie sich gegenseitig. Die beiden Tools erledigen unterschiedliche Aufgaben. Das Problem: Beide haben eine Meinung zu genau einer Sache — wie der Code auf der Seite aussieht. Was ESLint tatsächlich prüft ESLint zerlegt Ihren Code in einen abstrakten Syntaxbaum und führt Regeln gegen dessen Struktur aus. Der größte Teil seines Nutzens kommt von Regeln, die echte Bugs finden: eine Variable, die nie definiert wird, ein nicht erreichbares return nach einem anderen return, ein ungenutzter Import, der nach einem Refactoring übrig blieb, ein doppelter Objekt-Key, der den ersten lautlos überschreibt. Das sind semantische Prüfungen — ESLint liest, was der Code tut. ...

Warum eine Banküberweisung mehr als zwei UPDATE-Anweisungen braucht Verschieben Sie 50 € von einem Konto auf ein anderes, und die naive Version sind zwei Anweisungen: vom Konto A abziehen, dem Konto B hinzufügen. Führen Sie sie getrennt aus, und wenn der Prozess abstürzt oder die Verbindung zwischen den beiden abbricht, ist das Geld von A verschwunden und kommt nie bei B an. Die Datenbank hat genau das getan, was ihr gesagt wurde, zweimal. Das Geschäft hat trotzdem 50 € verloren. ...

Warum “sieht richtig aus” kein Test für einen Prompt ist Sie schärfen die Formulierung eines Prompts, der Tickets routet, testen ihn an den drei Beispielen, die in Ihrem Scratch-Notebook offen sind, und bringen ihn live. Eine Woche später landen Rechnungsbeschwerden, die früher in der richtigen Warteschlange ankamen, plötzlich bei “Frage”. Nicht die drei Fälle, die Sie geprüft haben: die anderen vierhundert, die Sie nicht geprüft haben. Nichts stürzt ab. Es gibt keinen Stacktrace. Der Prompt klingt, laut vorgelesen, immer noch gut. ...

Eine Chat-Komponente baut ihre WebSocket-Verbindung jedes Mal neu auf, wenn Sie einen Buchstaben in ein Suchfeld eingeben, das mit dem Chat nichts zu tun hat. Eine andere Komponente rendert sich in einer Schleife neu, bis der Tab einfriert. Eine dritte loggt beim Mount zweimal aus ihrem useEffect, aber nur in der Entwicklung. Keiner dieser Fälle ist ein React-Bug. Die ersten beiden sind das Dependency-Array, das genau das tut, was Sie ihm gesagt haben, und der dritte ist der Strict Mode, der prüft, ob Ihr Effekt sich selbst aufräumen kann. ...

<.+> gegen <b>bold</b> and <i>italic</i> findet nicht <b>. Es findet die gesamte Zeichenkette, vom ersten < bis zum allerletzten >. Nichts ist defekt. Genau das soll ein greedy Quantifizierer tun, und es ist auch der häufigste “Regex matcht zu viel”-Bug überhaupt. Sobald klar ist, was die Engine beim Lesen des Musters tut, hören dieser Bug und die meisten seiner Verwandten auf, Rätsel zu sein. Wie eine Regex-Engine Ihr Muster Liest Eine Regex-Engine vergleicht Ihr Muster nicht mit der Zeichenkette wie man zwei Zeichenketten auf Gleichheit vergleicht. Die Engines, die Sie täglich nutzen (re in Python, RegExp in JavaScript, PCRE, .NET, Java), sind regex-directed: Sie lesen das Muster von links nach rechts, Token für Token, und versuchen für jedes Token, Zeichen aus der Zeichenkette an der aktuellen Position zu konsumieren. Wenn ein Token passt, rückt die Engine sowohl den Muster-Zeiger als auch den Zeichenketten-Zeiger vor. Wenn ein Token fehlschlägt, macht die Engine Backtracking: Sie geht zum letzten Punkt zurück, an dem sie eine Wahl hatte, etwa ein Quantifizierer, der weniger Zeichen hätte matchen können, oder ein noch nicht probierter Alternationszweig, und probiert die andere Option. ...