Pourquoi any fait-il perdre le type que vous avez passé ? Typez un paramètre en any et TypeScript arrête de vérifier tout ce qui sort de la fonction : 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compile, plante à l'exécution Vous savez que vous avez passé un tableau de nombres. Le compilateur, non, car any lui dit d’arrêter de regarder. n est de type any, donc appeler une méthode de string sur un number compile sans problème et lève TypeError: n.toUpperCase is not a function à l’exécution. ...

Ouvrez un fichier qui n’existe pas en Python, open() lève un FileNotFoundError qui remonte hors de votre fonction. Faites la même chose en Go, os.ReadFile vous renvoie une valeur error accompagnée d’un slice d’octets nil. Même échec, deux formes de code complètement différentes autour. La différence n’est pas cosmétique. Elle décide si l’appelant peut ignorer l’échec par accident, et si le compilateur le repère quand ça arrive. Qu’est-ce que les exceptions et les valeurs d’erreur font réellement différemment ? Une exception est un flux de contrôle qui saute. Quelque chose échoue, la fonction lève, et l’exécution quitte la pile d’appels en cours pour atterrir dans le premier bloc catch ou except correspondant, peu importe le nombre de niveaux au-dessus. La signature de la fonction ne donne aucun indice que cela puisse arriver. loadConfig(path: string): Config en TypeScript ressemble exactement à une fonction qui ne peut pas échouer, jusqu’à ce qu’elle lève une exception pour un fichier manquant. ...

Vous êtes en plein travail sur une branche de feature, trois fichiers modifiés, rien de commité, quand un collègue vous signale un crash null-pointer en production. Le réflexe habituel : git stash, checkout de main, correction, push, puis git stash pop, en espérant que rien dans votre feature inachevée ne dépendait des fichiers que vous venez d’abandonner. git worktree évite cette gymnastique. Il fait le checkout de la branche de hotfix dans un second dossier, à côté de votre branche de feature, les deux s’appuyant sur le même dépôt. ...

Un client coincé dans une boucle de retry sans backoff peut mettre plus de charge sur votre API en une minute que vos dix mille autres clients réunis. De votre côté, ça ne ressemble pas à une attaque. Ça ressemble à un bug chez eux, et ça devient un incident chez vous. Un rate limiter bloque ce client avant qu’il n’en arrive là. Que décide vraiment un rate limiter ? À chaque requête, le rate limiter se pose une seule question : cette clé a-t-elle fait trop de requêtes dans la fenêtre actuelle ? Trois choix transforment cette question en quelque chose d’implémentable. ...

Ce que fait réellement le function calling dans un LLM Demandez à un modèle « quel temps fait-il à Austin en ce moment » sans aucune connexion au monde extérieur, et il n’a que deux options : dire qu’il ne sait pas, ou inventer quelque chose. Le function calling lui offre une troisième option. Il décrit ce dont il a besoin, transmet cette description à votre code et attend une vraie réponse avant de répondre à son tour. ...

Un listener scroll sur window peut se déclencher des centaines de fois pendant un seul swipe. Si vous exécutez getBoundingClientRect() sur chaque carte d’un feed à chacun de ces événements, cinquante images suffisent à faire ralentir la page. L’Intersection Observer API retire cette vérification du scroll : vous enregistrez les éléments à observer, et le navigateur vous prévient quand leur visibilité change réellement. Comment fonctionne IntersectionObserver Un observer surveille un ou plusieurs éléments target par rapport à un root (le viewport, par défaut) et appelle une callback chaque fois qu’un target franchit un seuil de visibilité. ...

Ouvrez un fichier enregistré en UTF-8 avec un outil qui suppose un autre encodage, et café devient café. Les octets sur le disque n’ont pas changé. Seule la règle utilisée pour les retransformer en caractères a changé, et les deux règles ne sont pas d’accord sur ce que signifie l’octet 0xC3. La plupart des bugs de “caractères bizarres” partagent la même origine : noms de fichiers cassés, formulaires illisibles, un emoji qui fait échouer un insert en base de données, deux chaînes identiques à l’œil mais différentes à la comparaison. Dans chaque cas, on confond deux choses distinctes : Unicode et UTF-8. ...

Qu’est-ce qu’une closure en 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 s’exécute une fois, renvoie une fonction, et c’est tout : son stack frame n’existe plus. Pourtant, chaque appel à counter() lit et met à jour count, une variable déclarée à l’intérieur d’une fonction déjà terminée. count ne revient pas à 0, et n’est pas copiée. C’est la même variable, toujours vivante, trois appels plus tard. ...

Un test écrit après le code tend à vérifier ce que le code fait, pas ce qu’il était censé faire. Le développement piloté par les tests (TDD) corrige cela en inversant l’ordre : vous écrivez le test, vous le regardez échouer, puis vous écrivez le plus petit bout de code qui le fait réussir. Comme le test existe avant le code qu’il vérifie, il ne peut pas valider silencieusement tout ce que le code renvoie. Kent Beck a formalisé cette boucle sous le nom red, green, refactor dans son livre de 2002 Test-Driven Development: By Example. Le nom est resté. ...

Lancez npm install sur un projet, puis pnpm install sur le même package.json : vous obtenez deux arborescences node_modules différentes et deux lockfiles différents. Ajoutez un collègue qui utilise Yarn, et le dépôt finit avec trois lockfiles dans son historique, chacun décrivant une arborescence de dépendances légèrement différente. Les trois lisent le même package.json et téléchargent depuis le même registre npm. Ce sur quoi ils ne sont pas d’accord, c’est ce qu’il faut écrire sur le disque. ...