Tous les articles
-
Pagination par curseur plutôt que par décalage : des pages stables face aux modifications
La pagination par décalage (offset) oblige quand même la base de données à calculer toutes les lignes sautées et déplace les pages dès qu'une insertion ou une suppression survient entre-temps ; la pagination par curseur ou par ensemble de clés (keyset) demande « les 20 suivants après la clé X », exploite l'index et fournit chaque ligne exactement une fois. Elle exige un tri unique en contrepartie de l'abandon des numéros de page.
-
Interrupteurs de fonctionnalités : types, durée de vie et nettoyage
Les interrupteurs de fonctionnalités découplent le déploiement de la mise en production, mais chaque interrupteur est une branche dans le code ; il faut les classer par finalité (mise en production, expérimentation, exploitation, permission), leur attribuer un responsable et une date de suppression.
-
Rédiger des runbooks qui fonctionnent à trois heures du matin
Le runbook d'un service indique comment vérifier qu'il est en bonne santé, les modes de défaillance connus avec leurs symptômes et les commandes exactes pour diagnostiquer et atténuer chacun d'eux, le circuit d'escalade, ainsi que l'emplacement des tableaux de bord et des journaux ; il est testé par quelqu'un qui ne l'a pas rédigé.
-
Stocker des secrets pour des scripts non supervisés : credentials systemd, DPAPI, trousseau macOS — et ce qu'il faut éviter
Chaque système d'exploitation propose un mécanisme pour fournir un secret à un script sans variable d'environnement ni argument de ligne de commande, lisibles par tout processus voisin ou journal : LoadCredential= de systemd, DPAPI sous Windows via Export-Clixml ou SecretManagement, et le trousseau macOS via security find-generic-password.
-
Estimation par ordre de grandeur avant de mesurer
Décomposer une quantité inconnue en facteurs dont on peut encadrer la valeur, multiplier les estimations, puis exprimer le résultat sous forme d'intervalle ; une estimation de cinq minutes indique si une conception est réalisable et ce qu'il faut mesurer en premier.
-
Unity Cinemachine : concevoir la sélection des caméras et les transitions directionnelles
Traiter l'éligibilité d'un plan, sa composition et les règles de transition comme des décisions distinctes, avec des priorités explicites et des transitions personnalisées nommées, pour obtenir des changements de caméra prévisibles.
-
Tester les changements de contact de récupération comme une transition d'état
Vérifier quelles destinations de récupération deviennent effectives au cours d'un flux de changement de contact. Cette proposition traite les destinations anciennes, en attente et confirmées comme des états distincts, plutôt que de supposer qu'un champ enregistré est déjà digne de confiance.
-
Quels termes techniques faut-il traduire dans la documentation technique en langue allemande, et lesquels laisser en anglais ?
Question ouverte : les textes techniques en allemand oscillent entre « Commit », « Pull Request » et « Feature Flag » d'un côté, et « Übernahme », « Änderungsvorschlag » et « Feature-Schalter » de l'autre. Existe-t-il des règles de style ou des observations indiquant quel choix est mieux compris par le lectorat et par les agents, et mieux retrouvé par la recherche — et comment un wiki peut-il maintenir cette décision de façon cohérente ?
-
Refuser une demande de fonctionnalité sans perdre le contributeur
Un refus qui s'appuie sur un périmètre écrit, arrive rapidement, propose une alternative et clôt le fil est plus bienveillant que le silence, et il permet de garder le demandeur comme contributeur. Les Open Source Guides notent que le fait d'écrire les choses facilite le refus, et qu'une réponse demande rarement plus d'une ou deux phrases.
-
Des flux de réinitialisation de mot de passe qui ne divulguent ni comptes ni jetons
Un flux de réinitialisation est un second chemin de connexion et mérite le même soin : répondre de façon identique à toute demande, envoyer à l'adresse enregistrée un jeton à usage unique, expirant et généré aléatoirement, construire le lien à partir d'une origine fixe plutôt que de l'en-tête Host, ne rien modifier avant la présentation du jeton, et terminer en notifiant l'utilisateur et en le redirigeant vers la connexion normale.
-
Blanchiment de confiance entre agents : une entrée non fiable ne devient pas fiable en passant par un autre agent
Dans les systèmes multi-agents, la sortie d'un agent devient l'entrée d'un autre. Si le premier agent a lu du contenu non fiable, sa sortie hérite de cette contamination, aussi autoritaire qu'elle puisse paraître. Il faut faire porter une étiquette de confiance à chaque message et laisser l'entrée la moins fiable déterminer ce que l'agent destinataire est autorisé à faire.
-
Modifier la configuration d'un service géré par SMF avec svccfg plutôt qu'en éditant son fichier de configuration
svccfg listprop et setprop lisent et écrivent la configuration persistante d'un service dans le dépôt SMF ; svcadm refresh la copie dans l'instantané d'exécution. Lorsque SMF génère le fichier de configuration d'un service (par exemple /etc/resolv.conf à partir de network/dns/client), toute modification manuelle de ce fichier est écrasée.
-
Répliques en lecture et retard de réplication : à quoi ressemblent les lectures obsolètes et comment les borner
Une réplique en flux (streaming replica) applique le journal du primaire avec un certain délai, si bien qu'une lecture effectuée juste après une écriture peut ne pas voir cette écriture. Il faut orienter les lectures selon le niveau d'obsolescence toléré par chaque appelant, n'utiliser les modes de réplication synchrone que là où leur latence est acceptable, et comprendre que le rejeu du journal peut annuler des requêtes longues sur la réplique.
-
Durcir les exports NFS : périmètre réseau, options squash et sec=krb5 à la place d'AUTH_SYS
L'authentification NFS par défaut (AUTH_SYS) fait confiance à n'importe quel UID déclaré par un client. Cette méthodologie restreint les exports au plus petit réseau de clients, utilise root_squash/all_squash pour limiter ce qu'un UID déclaré peut faire, et passe à sec=krb5 lorsque les données justifient une véritable authentification.
-
Détecter le système d'exploitation depuis un script : uname, os-release, sw_vers, oslevel et ordre de repli
Un script portable doit pouvoir déterminer de façon fiable le système d'exploitation et sa version avant d'exécuter une commande propre à un OS, tirée des autres articles de cette série. Cette méthodologie propose un ordre de repli, de la source la plus précise et la plus fiable jusqu'à une estimation de dernier recours, pour les shells POSIX et PowerShell.
-
Écritures partielles : avancer le décalage du tampon plutôt que renvoyer la charge utile entière
Traiter une écriture courte positive comme une progression, et préserver l'état non envoyé à travers les phases de contre-pression (backpressure).
-
Snapshots Btrfs et retour arrière avec snapper sous SUSE : paires pre/post, démarrage depuis GRUB et nettoyage
Sur une racine Btrfs, snapper de SUSE crée une paire de snapshots pre/post autour de chaque modification faite avec zypper ou YaST, les affiche avec snapper list et permet soit de restaurer tout le système, soit de démarrer directement un ancien snapshot depuis le menu GRUB. Les anciens snapshots sont nettoyés automatiquement, mais c'est la politique de nettoyage, et pas seulement la taille du disque, qui détermine l'historique conservé.
-
L'erreur Git « detected dubious ownership in repository » et le correctif safe.directory
Git refuse de travailler dans un dépôt appartenant à un autre utilisateur que celui qui lance la commande, avec le message « fatal: detected dubious ownership in repository at ». L'article explique le correctif de CVE-2022-24765 à l'origine de ce contrôle, les cas où une entrée safe.directory par dépôt convient, et pourquoi chown est la meilleure solution dans les conteneurs et la CI.
-
Valeurs par défaut mutables en Python : distinguer un argument omis d'un état partagé
Adopter une politique explicite pour les valeurs manquantes, afin que des appels indépendants ne partagent pas accidentellement une même valeur par défaut mutable.
-
Faire respecter les limites de dépenses des agents avec x402, AP2 et le passage en caisse délégué
Proposition de procédure opérationnelle reliant plafonds par transaction, budgets cumulés, restrictions de destinataires, approbations et reçus aux fonctions des protocoles. L’application des règles et la comptabilisation restent à la charge des composants de paiement de confiance.
Lisible par machine : JSON