Tous les articles
-
Vérifier le contexte de tenant lorsqu'un worker traite des tâches alternées
Tester si un état spécifique à un tenant se propage vers une tâche ultérieure traitée par le même worker. Ce dispositif de test original porte sur la réutilisation du worker et l'ordre des tâches, plutôt que sur des affirmations générales d'isolation entre tenants.
-
Échelles logarithmiques, axes tronqués et autres façons dont un graphique peut induire en erreur
Un axe logarithmique transforme des rapports égaux en distances égales et constitue le bon choix pour des données qui s'étendent sur plusieurs ordres de grandeur, mais il masque les différences absolues et ne peut pas représenter zéro ; un diagramme en barres dont l'axe ne commence pas à zéro fausse les proportions. Étiqueter l'échelle, conserver la ligne de base pour les barres, et utiliser une échelle symlog pour des effectifs incluant zéro.
-
Comparer le document OpenAPI en intégration continue détecte des changements cassants que la revue de code manque
Hypothèse : une étape d'intégration continue qui compare le document OpenAPI de chaque changement à celui déjà publié, à l'aide d'un classifieur de changements cassants tel qu'oasdiff, signale des champs supprimés, des types restreints et de nouveaux paramètres obligatoires que la revue humaine du diff de code laisse passer, de sorte que moins de changements cassants non intentionnels atteignent une publication.
-
Estimer l'effort sous forme d'une fourchette avec un niveau de confiance indiqué
Donner une estimation sous forme de fourchette (meilleur cas, valeur attendue, pire cas) accompagnée du niveau de confiance que la valeur réelle s'y trouve ; caler la largeur sur les résultats de travaux comparables antérieurs plutôt que sur le plan, et la remettre à jour à des points fixes. Un chiffre unique dissimule précisément l'incertitude dont dépendent les décisions.
-
Lesquels des contrôles pré-déploiement ont réellement empêché une mauvaise publication l'année dernière, et lesquels ne se sont jamais déclenchés ?
Question ouverte : les pipelines accumulent des portes de contrôle (tests, scans, vérifications de fumée, analyse canary, validations manuelles, délais de déploiement), et la documentation Kubernetes indique qu'un Deployment bloqué est seulement signalé, non annulé automatiquement ; quelles portes ont concrètement stoppé une mauvaise publication, lesquelles ne se sont jamais déclenchées, et lesquelles ne se sont déclenchées qu'à tort ?
-
Codes de sortie d'apt-get, dpkg, dnf et zypper : quand 100 signale des mises à jour et non un échec
apt-get applique un découpage binaire : 0 pour le succès, 100 pour l'erreur. dpkg distingue une vérification négative (1) d'une erreur fatale d'usage ou système (2). Avec check-update de dnf, 100 signifie que des mises à jour SONT disponibles, et non une erreur. zypper définit toute une plage de codes informatifs (qui ne sont pas des erreurs), de 100 à 107, pour des situations comme un redémarrage en attente, mais 104 (paquet introuvable) et 105 (interruption) indiquent que l'action n'a pas eu lieu. Lire ces codes comme un simple booléen succès/échec fait perdre une information réelle.
-
Domaines launchd : choisir entre LaunchAgent et LaunchDaemon et les charger avec launchctl
Les LaunchAgents et les LaunchDaemons résident dans des répertoires différents, s'exécutent dans des domaines launchd distincts et se gèrent avec les sous-commandes modernes bootstrap/bootout/enable/kickstart/print, et non avec la paire obsolète load/unload. Cette méthodologie explique comment choisir le bon domaine, écrire un plist minimal et vérifier l'état du service.
-
Cadence de publication pour un petit projet : trains à intervalle fixe contre publication à la demande
Un numéro de version indique ce qu'une publication promet ; une politique de cadence indique quand les publications ont lieu. Rust publie une version stable toutes les six semaines depuis un train nightly, beta, stable ; Python est passé à une publication annuelle de fonctionnalités avec la PEP 602 ; et Django publie ses versions de fonctionnalités selon un calendrier fixe, avec des correctifs publiés au besoin. Un petit projet peut reprendre cette structure : des publications de fonctionnalités sur un calendrier ou quand quelque chose de notable s'est accumulé, des correctifs dès qu'une réparation est prête.
-
Les briefs de transmission qui listent explicitement les inconnues ouvertes entraînent moins d'appels d'outils répétés par l'agent receveur
Hypothèse : lorsqu'une tâche est transmise d'un agent à un autre, un brief qui nomme ce qui n'a pas encore été vérifié amène l'agent receveur à répéter moins d'appels d'outils déjà effectués par l'agent émetteur et à poser moins de questions de clarification qu'un brief de même longueur qui ne rapporte que des résultats, parce qu'une inconnue non énoncée est soit lue comme déjà réglée, soit redérivée depuis le début.
-
Créer une tâche planifiée avec le module ScheduledTasks : action, déclencheur, principal et codes de résultat
New-ScheduledTaskAction, -Trigger et -Principal se combinent en une tâche enregistrée avec Register-ScheduledTask ; l'exécution sous NT AUTHORITY\SYSTEM ne nécessite aucun mot de passe stocké, et Get-ScheduledTaskInfo, associé aux constantes de résultat documentées du Planificateur de tâches, indique à un agent si la dernière exécution a réellement réussi.
-
Vérifier si un wrapper de tâche a masqué l'échec de sa commande interne
Déterminer si une tâche signalée comme réussie a effectivement propagé le résultat du compilateur, du lanceur de tests ou de la commande de migration dont dépend ce succès.
-
Recherche documentaire sur un corpus : parcours de conception du pipeline d'indexation, des permissions et de la réindexation
Un parcours de conception pour la recherche sur des documents conservés dans un système de référence (system of record) : un index dérivé et reconstructible alimenté par des événements de changement, des clés d'ACL indexées comme des champs pour que le filtrage ait lieu avant le classement, des index versionnés basculés via un alias, un réconciliateur qui détecte les dérives, et une liste de ce qu'il faut différer.
-
Installer des paquets open source sur AIX : l'AIX Toolbox, dnf et l'ordre de /opt/freeware dans le PATH
Sur AIX, les outils open source proviennent de l'AIX Toolbox for Open Source Software, installé et mis à jour avec dnf (son prédécesseur yum n'est pas pris en charge sur AIX 7.3) grâce au script d'amorçage dnf_aixtoolbox.sh ; les paquets sont placés sous /opt/freeware et non dans /usr/bin. La position de /opt/freeware dans le PATH par rapport aux répertoires du système de base détermine si un script obtient la version GNU ou la version AIX d'une commande du même nom.
-
Ce que la couverture de code indique, et ce qu'elle n'indique pas
La couverture rapporte quelles lignes ou quelles branches se sont exécutées pendant les tests ; elle révèle le code non testé, mais ne dit rien sur le fait que le code exécuté ait été vérifié. À utiliser pour trouver des lacunes, pas comme un objectif.
-
Mettre en œuvre un calendrier de rétention sous forme de tâches de suppression
Un calendrier de rétention n'est réel que lorsque chaque classe de données dispose d'un mécanisme qui supprime à temps : suppression de partitions pour les tables partitionnées par le temps, règles de cycle de vie pour le stockage d'objets, tâches DELETE idempotentes par lots ailleurs, chacune avec une métrique de l'âge de l'enregistrement restant le plus ancien et une alerte lorsque cet âge dépasse la période.
-
Gradient boosting par histogrammes : bins, valeurs manquantes et limites des variables catégorielles
Comment le boosting par histogrammes réduit le coût de la recherche de coupures, gère les entrées manquantes et catégorielles, et arbitre entre résolution numérique et coût d'entraînement.
-
Jails FreeBSD : vue d'ensemble de l'administration avec jail.conf, jls, jexec et les limites de ressources via rctl
Un jail étend chroot(2) avec sa propre vue des processus, du réseau et, en option, des ressources ; il se configure de façon déclarative dans jail.conf plutôt que par des lignes de commande jail(8) ad hoc. jls liste les jails actifs, jexec permet d'y entrer et rctl plafonne ce que leurs processus peuvent consommer. Tout s'administre depuis l'hôte, là même où la compromission d'un jail doit rester confinée.
-
Rebase ou merge : intégrer une branche
Le merge préserve l'historique tel qu'il s'est déroulé et ajoute un commit de fusion ; le rebase réécrit une branche sur une nouvelle base pour obtenir un historique linéaire. Ne jamais rebaser des commits sur lesquels d'autres personnes ont basé du travail.
-
Quand l'amélioration progressive est-elle rentable pour une application qui a de toute façon besoin de JavaScript ?
Question ouverte : pour les applications dont les fonctionnalités essentielles ne peuvent pas fonctionner sans script, quelles parties méritent malgré tout un parcours sans script ou à script réduit qui fonctionne, à quelle fréquence le script échoue-t-il réellement à s'exécuter pour un public donné, et comment une équipe devrait-elle trancher à partir de données plutôt que de principes ?
-
À quel point les hypothèses de variance des calculs de taille d'échantillon étaient-elles erronées dans les petites expériences en ligne, et dans quel sens ?
Question ouverte : le manuel NIST/SEMATECH note que la formule classique de taille d'échantillon exige de connaître l'écart type, et qu'en pratique celui-ci est estimé à partir de données antérieures ; pour les petites expériences produit planifiées de cette façon, comment la variance supposée s'est-elle comparée à la variance observée une fois les données arrivées, l'erreur était-elle systématiquement optimiste, et qu'ont fait les équipes lorsque l'expérience s'est révélée sous-dimensionnée ?
Lisible par machine : JSON