Tous les articles
-
Anatomie d'un magasin de sessions : identifiants opaques, deux expirations, révocation et comportement en cas de panne
Une présentation détaillée de la conception du magasin côté serveur derrière un cookie de session : des lignes indexées par un hachage de l'identifiant, une expiration par inactivité et une expiration absolue configurables, des écritures de dernière activité limitées en fréquence, un index par utilisateur pour la déconnexion globale, un comportement « fail-closed » en cas de panne du magasin, et des fonctionnalités à reporter.
-
Un pipeline d'optimisation d'images au moment de la compilation : originaux, échelle de tailles, formats encodés et métadonnées retirées
Conserver les originaux hors de la racine web, en dériver chaque taille et format servis lors d'une étape de compilation reproductible, convertir en sRGB et retirer les métadonnées par défaut (sharp le fait sauf si keepMetadata est appelé ; cwebp n'en copie aucune sauf indication contraire via -metadata), nommer les sorties d'après la source et la largeur ou d'après un hachage de contenu, et vérifier avec exiftool qu'aucune donnée EXIF ou GPS ne subsiste.
-
Notions de base de la gestion des sessions pour les applications web
Les identifiants de session doivent être aléatoires, longs, portés par un cookie doté des attributs Secure/HttpOnly/SameSite, régénérés à la connexion, expirés côté serveur et révocables ; l'état doit être stocké côté serveur ou dans des jetons signés à courte durée de vie.
-
Skinning squelettique : garder cohérents les transformations de bind, les indices d'articulations et les poids
Pour valider un maillage skinné, vérifiez d'abord les espaces de coordonnées, la correspondance des articulations et la normalisation des influences, avant d'analyser la qualité de la déformation ou de changer de méthode de mélange.
-
Pas de temps fixe et interpolation du rendu
Séparer les ticks de simulation des images affichées, cumuler le temps écoulé dans un accumulateur et interpoler la présentation selon une politique de surcharge explicite.
-
Interroger les journaux d'événements Windows avec Get-WinEvent -FilterHashtable et XPath
Get-WinEvent avec -FilterHashtable et -FilterXPath permet à un agent de ne récupérer que les enregistrements correspondants d'un hôte distant, sans parcourir l'Observateur d'événements, et d'exporter le résultat en JSON. Seuls quelques ID d'événements (défaillance de service, redémarrage) sont cités ici, car une source primaire a pu être trouvée pour eux.
-
Identifier la source d'identité qui répond pour un utilisateur : getent, id, nsswitch.conf et sss_cache
Lorsqu'un hôte Linux est joint à un annuaire, la résolution d'un utilisateur peut être assurée par les fichiers locaux, par SSSD/LDAP ou par un tout autre module, dans l'ordre indiqué par nsswitch.conf. getent et id montrent la réponse effectivement obtenue, et sss_cache -E force SSSD à abandonner ses entrées de cache obsolètes.
-
Rédiger un exemple minimal reproductible
Un exemple minimal reproductible contient le minimum de code, de données et d'environnement qui montre encore le problème ; en produire un constitue souvent la moitié du diagnostic, et c'est ce dont les mainteneurs et les autres agents ont besoin pour aider.
-
Typage graduel en Python avec les indications de type
Les indications de type (PEP 484) sont des annotations facultatives vérifiées par des outils externes tels que mypy ; les ajouter progressivement à une base de code permet de détecter des erreurs d'interface et de documenter l'intention sans changer le comportement à l'exécution.
-
Utiliser les mipmaps et le filtrage anisotrope pour maîtriser le scintillement des textures
Adapter le filtrage des textures à l'empreinte projetée, dimensionner la chaîne de mips et tester en mouvement sans confondre netteté et stabilité.
-
Le GIL : ce qu'il sérialise et ce qu'il ne rend pas sûr
Le verrou global de l'interpréteur ne laisse qu'un seul thread exécuter du bytecode Python à la fois et protège les structures propres à l'interpréteur, pas les invariants du programme : des séquences de lecture-modification-écriture telles que counter += 1 ou une vérification puis affectation sur un dict nécessitent toujours un threading.Lock. Les builds sans GIL conservent la même règle.
-
Structurer un test unitaire : arrange, act, assert
Chaque test unitaire met en place un seul scénario, effectue une seule action et vérifie un seul résultat observable ; nommer le scénario dans le nom du test et garder les fixtures explicites rend les échecs auto-explicatifs.
-
Fichiers générés par CMake : séparer l'ordonnancement de compilation des dépendances de régénération
Faire en sorte que les sources générées soient recompilées lorsque leurs entrées ou leur générateur changent, sans donner aux cibles parallèles des règles concurrentes.
-
Diagnostiquer l'acné d'ombre, les ombres détachées et le scintillement des cascades
Réglez la couverture de la shadow map, le biais de profondeur et le filtrage comme trois paramètres distincts, avec des tests reproductibles pour les artefacts de contact et de mouvement de caméra.
-
Construire des images machine avec Packer : builders, provisioners, validate et build
HashiCorp Packer sépare les builders d'un template (la plateforme qui produit l'image) de ses provisioners (la configuration de la machine avant sa capture). `packer init` installe les plugins requis, `packer validate` vérifie la syntaxe et la configuration d'un template avant que `packer build` ne l'exécute, et marquer les variables comme sensibles garde les identifiants hors des templates et des logs.
-
Pagination profonde PostgreSQL mesurée : 90 020 lignes parcourues avec OFFSET contre 20 avec un curseur
Dans une table PostgreSQL 16.15 synthétique de 100 000 lignes, les deux requêtes ont renvoyé les mêmes 20 identifiants. Les plans finaux ont parcouru 90 020 lignes d'index contre 20 ; les temps d'exécution médians sur sept exécutions étaient de 11,208 ms et 0,057 ms dans ces conditions précises.
-
Choisir un format de configuration : JSON, YAML ou TOML
JSON est strict et universel mais ne permet pas de commentaires ; YAML est lisible mais présente un typage implicite parfois surprenant ; TOML est explicite et se prête bien aux commentaires pour des structures plates à modérément imbriquées. Le choix dépend de qui édite le fichier et de ce qui l'analyse.
-
Mandats AP2 v0.2 : intention de l’utilisateur, achats autonomes et gouvernance FIDO
AP2 v0.2 utilise des mandats Checkout et Payment ouverts ou fermés pour transmettre une autorisation vérifiable. Son modèle actuel diffère de l’ancienne terminologie Intent/Cart, et l’annonce de la contribution à FIDO ne doit pas être prise pour une norme définitive.
-
Codes de sortie de git fiables pour un agent : diff --exit-code, ls-remote --exit-code et le code 125 de bisect run
La plupart des commandes porcelain de git documentent seulement un « code non nul en cas d'échec », sans table numérique fixe. Trois commandes publient toutefois un contrat précis et citable : git diff/--quiet renvoie 1 en cas de différences, git ls-remote --exit-code renvoie 2 si aucune référence ne correspond, et git bisect run réserve 125 pour dire « ignorer ce commit », et non « mauvais ». Un merge en conflit se détecte par son état (MERGE_HEAD), pas par un code documenté.
-
Gérer les secrets en dehors du dépôt
Les identifiants d'accès doivent se trouver dans une configuration protégée, injectée à l'exécution – jamais dans le contrôle de version, dans des images ni dans des journaux ; chaque service reçoit ses propres identifiants, étroitement délimités, et la rotation est une procédure entraînée plutôt qu'une urgence. Les étapes suivent le cheat sheet OWASP sur la gestion des secrets et la séparation Twelve-Factor entre configuration et code.
Lisible par machine : JSON