Tous les articles
-
Quelle stratégie d'échantillonnage des traces garde les défaillances rares visibles dans un service à faible trafic ?
Question ouverte : les recommandations d'échantillonnage sont rédigées pour des services produisant des milliers de traces par seconde, où un pour cent reste un échantillon représentatif ; pour un service recevant quelques requêtes par seconde, quelle combinaison d'échantillonnage en tête, d'échantillonnage en fin de trace, de taux par route et de rétention a permis de garder disponible l'unique trace en échec de la semaine, à un coût accepté par l'équipe ?
-
Quelles règles de rétention limitent la taille d'un registre de conteneurs sans supprimer les images encore déployées ?
Question ouverte : le ramasse-miettes des registres ne supprime que les blobs qu'aucun manifeste ne référence, et les politiques de cycle de vie font expirer les images selon leur ancienneté, leur nombre ou un motif de tag ; quelle combinaison de règles des équipes ont-elles utilisée pendant des années sans croissance illimitée ni échec de retour arrière dû à la disparition de l'image nécessaire ?
-
Recherche plein texte dans PostgreSQL avec tsvector
PostgreSQL transforme le texte en un tsvector de lexèmes normalisés selon une configuration linguistique, le confronte à un tsquery, classe les correspondances avec ts_rank et l'indexe avec GIN ; il gère la racinisation et les mots vides, mais pas les fautes de frappe ni les synonymes sans configuration supplémentaire.
-
Déclencher les alertes d’astreinte sur les symptômes plutôt que sur les causes
Déclencher les alertes à partir de ce que vivent les utilisateurs (taux d’erreur, latence, disponibilité, fraîcheur des données), avec des seuils liés aux objectifs, les acheminer selon leur urgence et corriger ou supprimer toute alerte bruyante.
-
Event sourcing et CQRS : leurs avantages et leurs coûts
L’event sourcing enregistre chaque changement d’état sous forme d’événement immuable et reconstitue l’état courant par rejeu ; CQRS sépare le modèle d’écriture des modèles de lecture. Tous deux apportent de l’auditabilité et de la souplesse au prix d’une complexité accrue et d’une cohérence à terme.
-
Séparer les preuves d'intégration simulée des observations d'un service réel
Empêcher que des réponses de fixture et des substituts locaux ne soient pris à tort pour la preuve qu'une intégration externe réelle est configurée et fonctionne.
-
Mesurer sa vitesse de frappe chez soi : un protocole à texte et durée fixes, avec des règles écrites pour les mots et les erreurs
Ce protocole proposé pour un relevé personnel de vitesse de frappe inscrit les définitions dans le journal : un mot standard vaut cinq caractères, espaces compris, les débits brut et net suivent des formules explicites, et chaque session consigne le clavier, la disposition, le logiciel et le réglage de correction. Trois essais chronométrés de durée fixe portent sur des textes d’un type fixé, puis leur médiane est rapportée ; aucun débit, objectif ou progrès n’est annoncé.
-
Résumer une source sans la déformer
Un résumé fidèle conserve la force et la portée des affirmations de la source, les ordonne selon l’importance qu’elle leur accorde, accompagne les chiffres de leurs conditions, distingue restitution et approbation, et précise les omissions. Vérifier chaque phrase du résumé à l’aide d’une liste des affirmations de la source.
-
Comparer les décisions de transmission entre analyseurs sans construire de charge utile d'exploitation
Tester si des composants successifs s'accordent sur la signification, du point de vue de la sécurité, d'un fixture de requête inoffensif. La proposition se concentre sur les différences d'interprétation lors d'une transmission, à l'aide d'une instrumentation locale et de valeurs de marqueur inertes.
-
Quelles métriques de revue de code prédisent les défauts non détectés sans se prêter à la manipulation ?
Question ouverte : le délai de revue, la densité des commentaires et la taille des modifications sont faciles à mesurer, mais lesquels prédisent réellement les défauts découverts après fusion, et lesquels cessent d’être utiles dès que les équipes cherchent à les optimiser ?
-
Évaluer les sources : une fiche de travail
Les questions à consigner pour déterminer si une source étaye une affirmation.
-
Quelle stratégie de déploiement fonctionne sur un hôte unique avec Docker Compose et un reverse proxy ?
Question ouverte : les déploiements progressifs, blue-green et canary sont décrits pour les orchestrateurs, mais beaucoup de petits services tournent sur un seul hôte avec Docker Compose derrière Traefik, nginx ou Caddy. Quelles adaptations — second conteneur avec basculement de règle du proxy, répartition pondérée, start-first — les équipes ont-elles exploitées pendant des mois, qu’est-ce qui les a mises en défaut et à partir de quelle taille un orchestrateur devient-il avantageux ?
-
Choisir Go ou Rust pour un nouveau service : une procédure de décision sans benchmarks
Choisir entre Go et Rust pour un service à partir des propriétés documentées des langages et des contraintes de l’équipe plutôt que d’idées reçues sur les benchmarks : gestion de la mémoire, traitement des erreurs et concurrence, profil de la charge, bibliothèques nécessaires et personnes qui assureront la maintenance dans deux ans.
-
Des commentaires qui apportent ce que le code ne peut pas dire
Rédiger des commentaires pour expliquer les raisons, les contraintes et les conséquences peu évidentes, sans répéter le code. Les garder près du code décrit, les supprimer lorsque leur raison d’être disparaît et leur préférer un meilleur nom ou un test lorsque cela suffit.
-
Modes de défaillance de Jev 1.13 : lecture littérale, comptage, dates, indirection et dégradation du contexte
Les neuf modes de défaillance documentés par TypeSafe pour jev-1.13 (revus par le fournisseur le 2026-09-17), leurs implications pour un agent qui délègue des décisions au modèle et les contournements documentés : conditions exactes dans les instructions, arithmétique et traitement des dates dans le code, état filtré et absence de dépendance à des invariants structurels entre questions distinctes.
-
Quelles traces domestiques permettent de dater après coup le début et la fin d’une coupure de courant, et avec quels écarts ?
Question ouverte : après une coupure, un foyer dispose de plusieurs traces horaires, comme l’avis du distributeur, le journal d’un onduleur, la durée de fonctionnement d’un routeur, les redémarrages d’un serveur domestique (le manuel last(1) indique que last reboot fournit les heures de redémarrage, et journalctl peut lister les démarrages avec l’horodatage du premier et du dernier message de chacun), une horloge à piles restée à l’heure et une horloge secteur qui clignote. Lesquelles les foyers ont-ils réellement utilisées, de combien divergeaient-elles et lesquelles ont fourni les bornes les plus précoces et les plus tardives ?
-
Un secret a été committé : pourquoi supprimer le fichier ne suffit pas, et dans quel ordre réagir
Un identifiant poussé dans un dépôt Git persiste dans l'historique, les forks, les clones, les caches et les journaux de CI. Réécrire l'historique réduit l'exposition future mais ne peut pas rappeler les copies déjà faites ; la première étape consiste donc à révoquer et faire tourner l'identifiant, puis à nettoyer l'historique, puis à vérifier s'il a été utilisé.
-
Modèle de retour d’expérience
Un modèle clairement présenté comme tel pour rendre compte d’une expérience sans inventer d’éléments probants.
-
Les permissions des fichiers Unix et l’umask
Chaque fichier possède des bits de lecture, d’écriture et d’exécution pour le propriétaire, le groupe et les autres, ainsi que les bits setuid, setgid et sticky ; les permissions des nouveaux fichiers dépendent de l’umask du processus. Les secrets doivent être dans des fichiers en mode 0600, les répertoires nécessitent le droit d’exécution pour être traversés et les services doivent s’exécuter sous un utilisateur dédié.
-
Établir une référence avant d’entraîner le premier modèle
Avant d’exécuter un algorithme d’apprentissage, consigner les résultats d’un prédicteur trivial, d’une règle simple et du processus actuel sur la même partition, avec la même métrique. Chaque modèle ultérieur est présenté par son écart à cette référence, et un modèle qui ne fait pas mieux que la règle n’est pas déployé.
Lisible par machine : JSON