Tous les articles
-
Après combien de soft bounces, sur quelle période, un expéditeur devrait-il cesser d'écrire à une adresse ?
Question ouverte : les codes de statut étendus séparent les échecs permanents (5.X.X) des échecs transitoires persistants (4.X.X), mais la norme laisse le cas transitoire à la politique de l'expéditeur ; quels seuils les expéditeurs ont-ils utilisés, et qu'est-il advenu des taux de récupération et de la réputation ?
-
Temps écoulé en Go : la sérialisation perd la composante d'horloge monotone
Séparer la mesure de durée locale des horodatages persistés et des politiques de délai inter-processus.
-
Nommage et casse cohérents des champs JSON
Choisir une seule convention de casse pour les noms de propriétés et l'appliquer partout : le guide de style JSON de Google et ProtoJSON utilisent le lowerCamelCase, de nombreuses API utilisent le snake_case. Au-delà de la casse, garder des noms porteurs de sens, des énumérations sous forme de chaînes, des horodatages en chaînes RFC 3339 et des entiers 64 bits en chaînes.
-
Générer, critiquer, réviser : quand une boucle d'auto-vérification est rentable
Une boucle dans laquelle le modèle critique et révise sa propre sortie améliore les résultats lorsque la critique dispose d'un signal externe (tests, un validateur, une source) et d'une grille fixe ; sans cela, des résultats publiés montrent qu'elle peut dégrader les réponses, et chaque tour ajoute au moins deux appels dont l'entrée croît avec le brouillon.
-
La spécification Standard Webhooks face à l'en-tête HMAC de Shopify et au jeton secret partagé de GitLab
La spécification Standard Webhooks définit les en-têtes webhook-id, webhook-timestamp et webhook-signature, un secret en base64 préfixé par whsec_ dont les octets décodés servent de clé HMAC, et une signature v1,<base64> calculée sur « {id}.{timestamp}.{payload} » ; les jetons de signature de GitLab (GitLab 19.0, disponibles en GA dans la 19.1) l'implémentent à l'identique. Shopify envoie à la place un HMAC en base64 du corps brut dans X-Shopify-Hmac-SHA256, et l'ancien X-Gitlab-Token de GitLab est un simple secret partagé, pas un HMAC.
-
Modèle d'hypothèse
Un canevas pour une hypothèse explicite et testable, et non un fait établi.
-
Transformer un périmètre d'évaluation autorisé en conditions d'arrêt exécutables
Aider un agent d'évaluation à s'arrêter à la limite convenue, même lorsque son action suivante suggérée semble techniquement pratique. La méthode traduit un périmètre approuvé par l'opérateur en décisions testables avant toute interaction avec la cible.
-
Unity Addressables : concevoir des durées de vie explicites pour le chargement et la libération
Attribuez un propriétaire clair à chaque chargement asynchrone, conservez son handle pendant toute la durée d'utilisation et définissez le nettoyage en cas d'échec ou de requête devenue obsolète.
-
Stocker des données dérivées dans PostgreSQL : colonnes générées contre vues matérialisées
Une colonne générée dérive une valeur par ligne à partir de cette seule ligne, soit virtuelle (calculée à la lecture), soit stockée (calculée à l'écriture), et ne peut utiliser que des expressions immuables ; une vue matérialisée stocke le résultat d'une requête quelconque et n'est fraîche qu'à hauteur de son dernier REFRESH. Utiliser des colonnes générées stockées pour la normalisation par ligne qui doit être indexée, des vues matérialisées pour les agrégats coûteux qui peuvent accuser un retard, et une table de synthèse maintenue lorsque ni l'une ni l'autre ne convient.
-
Tester que les mises à jour de profil ne peuvent pas modifier des champs de compte privilégiés
Créer une régression ciblée pour les mises à jour qui acceptent des données de profil ordinaires en même temps que des champs que l'appelant ne doit pas pouvoir contrôler. La méthode propose une propriété explicite des champs plutôt qu'une liste de contrôle générique de validation des entrées.
-
Stockage dans le navigateur : cookies, Web Storage et IndexedDB comparés
Les cookies voyagent avec chaque requête et sont de petite taille par spécification ; localStorage et sessionStorage sont des magasins de chaînes synchrones avec quelques Mio par origine ; IndexedDB est asynchrone, transactionnel et partage le grand quota de l'origine. Tout le stockage du navigateur est de type best-effort sauf si la persistance est accordée, et il est délimité par origine.
-
Champs Rust packed : éviter de créer une référence non alignée avant une conversion en pointeur brut
Comprendre pourquoi une référence temporaire peut déjà enfreindre les exigences d'alignement, et préférer un décodage explicite des octets lorsque c'est possible.
-
Écrire un test unitaire en JUnit 5 et xUnit.net : annotations, cycle de vie et cas paramétrés côte à côte
JUnit Jupiter marque les tests avec @Test, exécute @BeforeEach et @AfterEach autour de chacun sur une instance fraîche par défaut, et pilote les cas pilotés par les données avec @ParameterizedTest plus une annotation de source ; xUnit.net utilise [Fact], le constructeur et IDisposable pour l'initialisation par test sur une instance fraîche, [Theory] avec [InlineData] pour les cas, et des fixtures pour un contexte coûteux partagé. Écrire des tests de même forme dans les deux garde alignées les conventions d'une équipe polyglotte.
-
Détecter la falsification de paquets RPM installés avec rpm -V
rpm -V compare les fichiers installés aux sommes de contrôle, permissions et propriétaires enregistrés lors de l'installation du paquet ; ses codes d'une lettre indiquent précisément ce qui a changé. Cette méthodologie explique comment lire cette sortie et en rappelle les limites en tant que contrôle d'intégrité.
-
La politique de même origine (Same-Origin Policy) : ce qu'est une origine et ce qu'elle isole
Une origine est le triplet schéma, hôte et port d'une URL. Un script peut lire et modifier des documents, du stockage et des réponses de même origine ; les lectures cross-origin sont bloquées par défaut, tandis que les écritures cross-origin telles que les soumissions de formulaire et l'intégration telle que les images et les scripts sont généralement autorisées. CORS assouplit les lectures ; des défenses contre le CSRF restent nécessaires.
-
VACUUM, autovacuum et le ballonnement des tables
Le MVCC de PostgreSQL laisse derrière lui des versions de lignes mortes après les mises à jour et les suppressions ; VACUUM les récupère et maintient les statistiques ainsi que la protection contre le rebouclage des identifiants de transaction. Autovacuum devrait rester activé et être ajusté pour les tables très sollicitées.
-
Ce que garantit un cluster Raft : majorités, un seul leader et lectures linéarisables
Les systèmes de consensus tels qu'etcd (Raft) permettent à une majorité de serveurs de s'accorder sur un journal ordonné ; ils restent corrects quel que soit le nombre de pannes, mais ne progressent que tant qu'une majorité reste joignable. Les lectures linéarisables passent par le consensus et coûtent en latence ; les lectures sérialisables sont servies localement et peuvent être obsolètes.
-
Rendre un site web lisible pour des agents : robots.txt, sitemaps et llms.txt
Les agents et les robots d'indexation trouvent le contenu grâce à un petit ensemble de conventions : robots.txt pour les règles d'accès et l'emplacement du sitemap, un sitemap XML avec de vraies dates de modification, et llms.txt comme court guide sélectionné ; aucune de ces conventions ne remplace l'authentification.
-
Après l'arrivée d'un signalement de vulnérabilité : accuser réception, évaluer, corriger en privé, divulguer
Une fois qu'un signalement atteint le contact sécurité du projet, le travail est une séquence datée : accuser réception rapidement, classer (fonctionne comme prévu, bug, demande de fonctionnalité, vulnérabilité), convenir d'un embargo avec la personne qui signale, développer le correctif en privé, obtenir un identifiant CVE, puis publier une version et un avis nommant les versions concernées et corrigées, et créditant la personne à l'origine du signalement. Le guide des mainteneurs de l'OpenSSF et les recommandations de divulgation de GitHub décrivent ce processus ; cet article le condense pour un projet compté entre un et cinq mainteneurs.
-
Des comptes rendus de réunion avec une section décisions séparée réduisent la réouverture de décisions
Hypothèse : les équipes dont les comptes rendus de réunion listent chaque décision séparément (énoncé, options rejetées, responsable, date) et la recopient dans un journal de décisions durable rouvrent moins souvent des questions tranchées que les équipes aux comptes rendus narratifs, parce qu'une décision qu'on peut retrouver et citer a moins de chances d'être redébattue depuis le début.
Lisible par machine : JSON