Warum geht der übergebene Typ bei any verloren? Wenn Sie einen Parameter als any typisieren, prüft TypeScript nichts mehr von dem, was aus der Funktion kommt: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compiliert, stürzt zur Laufzeit ab Sie wissen, dass Sie ein Array von Zahlen übergeben haben. Der Compiler weiß es nicht, weil any ihm sagt, nicht mehr hinzusehen. n kommt als any zurück, also compiliert der Aufruf einer String-Methode auf einer Zahl klaglos und wirft beim Ausführen TypeError: n.toUpperCase is not a function. ...

Öffnen Sie in Python eine Datei, die nicht existiert, wirft open() einen FileNotFoundError, der aus Ihrer Funktion heraus nach oben durchläuft. Tun Sie dasselbe in Go, gibt os.ReadFile einen error-Wert neben einem nil-Byte-Slice zurück. Derselbe Fehlschlag, zwei völlig unterschiedliche Code-Formen darum herum. Der Unterschied ist nicht kosmetisch. Er entscheidet, ob ein Aufrufer den Fehlschlag versehentlich ignorieren kann, und ob der Compiler es merkt, wenn er es tut. Was machen Exceptions und Error Values wirklich unterschiedlich? Eine Exception ist Kontrollfluss, der springt. Etwas schlägt fehl, die Funktion wirft, und die Ausführung verlässt den aktuellen Call-Stack und landet im nächsten passenden catch- oder except-Block, egal wie viele Ebenen weiter oben das ist. Die Signatur der Funktion gibt keinen Hinweis darauf, dass das passieren kann. loadConfig(path: string): Config in TypeScript sieht genau wie eine Funktion aus, die nicht fehlschlagen kann – bis sie bei einer fehlenden Datei eine Exception wirft. ...

Sie sind drei Dateien tief in einem Feature-Branch, noch nichts committet, als ein Kollege wegen eines Null-Pointer-Crashs in Produktion anklopft. Der übliche Weg: git stash, zu main wechseln, den Fehler fixen, pushen, dann git stash pop – und hoffen, dass nichts in Ihrer halbfertigen Feature-Arbeit von den Dateien abhing, von denen Sie gerade weggewechselt sind. git worktree macht dieses Hin-und-Her überflüssig: Es checkt den Hotfix-Branch in einen zweiten Ordner aus, neben Ihrem Feature-Branch, beide auf Basis desselben Repositorys. ...

Ein Client, der in einer Retry-Schleife ohne Backoff feststeckt, kann Ihrer API in einer Minute mehr Last aufbürden als Ihre übrigen zehntausend Clients zusammen. Von Ihrer Seite aus sieht das nicht nach einem Angriff aus. Es sieht nach einem Bug bei ihnen aus, und es wird zum Incident bei Ihnen. Ein Rate Limiter bremst diesen Client, bevor es so weit kommt. Was entscheidet ein Rate Limiter eigentlich? Bei jedem Request stellt der Limiter nur eine Frage: Hat dieser Key im aktuellen Zeitfenster zu viele Requests gemacht? Drei Entscheidungen machen daraus etwas, das Sie implementieren können. ...

Was Function Calling bei LLMs wirklich macht Fragen Sie ein Modell „wie ist das Wetter gerade in Austin" ohne jede Verbindung zur Außenwelt, und es hat zwei Optionen: sagen, dass es das nicht weiß, oder sich etwas ausdenken. Function Calling gibt ihm eine dritte Option. Es beschreibt, was es braucht, gibt diese Beschreibung an Ihren Code weiter und wartet auf eine echte Antwort, bevor es antwortet. Der Name ist etwas irreführend. Das Modell ruft nichts auf. Es gibt einen Block strukturierter Daten aus, der sagt, welches Tool es möchte und mit welchen Argumenten, und Ihre Anwendung entscheidet, ob sie es ausführt und was sie mit dem Ergebnis macht. „Tool Use" ist der genauere Begriff und der, den Anthropics Dokumentation verwendet; OpenAI und Google sprechen meist von Function Calling. Der Mechanismus ist unter beiden Namen derselbe. Das Modell erzeugt immer nur eine Anfrage, nie den Seiteneffekt. ...

Ein scroll-Listener auf window kann während eines einzigen Swipes hunderte Male auslösen. Wer bei jedem dieser Events getBoundingClientRect() für jede Karte in einem Feed aufruft, braucht nur fünfzig Bilder, um die Seite ins Stottern zu bringen. Die Intersection Observer API nimmt diese Prüfung aus dem Scroll-Pfad: Sie registrieren, welche Elemente beobachtet werden sollen, und der Browser meldet sich, wenn sich deren Sichtbarkeit tatsächlich ändert. Wie IntersectionObserver funktioniert Ein Observer beobachtet ein oder mehrere Target-Elemente relativ zu einem Root (standardmäßig der Viewport) und ruft einen Callback auf, sobald ein Target einen Sichtbarkeitsschwellenwert überschreitet. ...

Öffnen Sie eine als UTF-8 gespeicherte Datei in einem Tool, das eine andere Kodierung annimmt, und aus café wird café. Die Bytes auf der Festplatte haben sich nicht geändert. Geändert hat sich nur die Regel, mit der sie wieder in Zeichen zurückverwandelt werden, und die beiden Regeln sind sich nicht einig, was das Byte 0xC3 bedeutet. Die meisten Bugs mit “komischen Zeichen” laufen auf dasselbe hinaus: kaputte Dateinamen, zerstörte Formulareingaben, ein Emoji, das einen Datenbank-Insert zum Absturz bringt, zwei Strings, die identisch aussehen, aber beim Vergleich nicht gleich sind. Jedes Mal werden zwei getrennte Dinge verwechselt: Unicode und UTF-8. ...

Was ist eine Closure in JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter läuft einmal, gibt eine Funktion zurück, und damit ist es erledigt: Der Stack-Frame existiert nicht mehr. Trotzdem liest und aktualisiert jeder Aufruf von counter() weiterhin count, eine Variable, die innerhalb einer bereits beendeten Funktion deklariert wurde. count wird nicht auf 0 zurückgesetzt und nicht kopiert. Es ist dieselbe Variable, immer noch lebendig, drei Aufrufe später. ...

Ein Test, der nach dem Code geschrieben wird, prüft meist, was der Code tut, nicht, was er tun sollte. Testgetriebene Entwicklung (TDD) behebt das, indem sie die Reihenfolge umdreht: Sie schreiben den Test, sehen ihn fehlschlagen und schreiben dann den kleinsten Code, der ihn bestehen lässt. Weil der Test existiert, bevor der Code existiert, den er prüft, kann er nicht stillschweigend bestätigen, was der Code gerade zufällig zurückgibt. Kent Beck hat diese Schleife in seinem Buch Test-Driven Development: By Example von 2002 als red, green, refactor formalisiert. Der Name ist geblieben. ...

Führen Sie in einem Projekt npm install aus und danach für dieselbe package.json pnpm install. Sie erhalten zwei unterschiedliche node_modules-Bäume und zwei unterschiedliche Lockfiles. Kommt ein Kollege dazu, der Yarn nutzt, landet das Repository mit drei Lockfiles in seiner Historie, jeder mit einem leicht anderen Abhängigkeitsbaum. Alle drei lesen dieselbe package.json und laden aus derselben npm-Registry. Uneinig sind sie sich darüber, was auf die Festplatte geschrieben wird. Wie npm, Yarn und pnpm node_modules aufbauen Die Struktur von npm ist flach. Jedes Paket, das Ihre Abhängigkeiten brauchen, egal wie tief im Baum, wird in die oberste node_modules gehoben, solange kein Versionskonflikt besteht. Das ist seit npm 3 das Standardverhalten. Der Nebeneffekt: Ihr Code kann ein Paket per require() oder import laden, das Sie nie in package.json eingetragen haben, solange etwas anderes im Baum davon abhängt. Das funktioniert, bis dieses andere Paket die Abhängigkeit in einem Minor-Release fallenlässt und Ihr Build bricht, ohne dass Sie Ihren eigenen Code geändert hätten. Das ist eine Phantom-Abhängigkeit, und die Struktur von npm tut nichts, um sie zu verhindern. ...