Tous les articles
-
Rédiger des suppressions de scanner avec une condition d'expiration réfutable
Rendre un résultat de scanner accepté à nouveau examinable après un changement de code ou d'environnement. Cette méthode proposée traite une suppression comme une affirmation bornée, avec un responsable et un déclencheur de nouvelle vérification, et non comme la preuve qu'une règle est globalement inutile.
-
Comment les équipes vérifient-elles qu'une suppression a bien retiré toutes les copies des données d'une personne, et qu'a révélé cette vérification ?
Question ouverte : qu'une tâche de suppression se déclare terminée n'équivaut pas à ce que les données aient disparu (versions de lignes mortes avant VACUUM, versions d'objets, caches, index, copies analytiques, sauvegardes, journaux, tiers) ; quelles équipes vérifient de bout en bout, par quelle méthode, et quels systèmes de stockage contenaient encore des données après une suppression déclarée terminée ?
-
Symbolication des crashs de jeu : associer chaque rapport au build exact livré
Transformer des adresses de crash en informations de pile exploitables : conserver les binaires et symboles correspondants, vérifier l'identité du build et distinguer le lieu de la défaillance de sa cause.
-
Paramètres de filtre, de tri et de sélection de champs pour les points de terminaison de liste
Les points de terminaison de liste finissent tous par acquérir les trois mêmes réglages : un filtre, un ordre de tri et une sélection de champs. Choisir une convention pour chacun (le sort=-created,title et le fields[type] de JSON:API, ou les chaînes filter et order_by des AIP de Google), rejeter avec un 400 ce qui n'est pas pris en charge, et traiter leur ajout comme facile et leur retrait comme une rupture de compatibilité.
-
Détection de collision continue : choisir une politique face à l'effet tunnel
Comprendre comment les balayages (sweeps) et les contacts spéculatifs traitent le mouvement entre deux échantillons de la simulation physique, puis choisir la couverture, les coûts et la gestion des échecs pour les objets rapides.
-
Rendre compte des contrôles sélectionnés, ignorés et exécutés dans un résultat de validation
Empêcher qu'une commande réussie soit présentée comme une couverture réussie alors que les contrôles prévus ont été ignorés, désélectionnés ou jamais découverts.
-
Entités externes XML : désactiver le traitement des DTD dans les analyseurs
Un document XML peut déclarer des entités qui se développent en fichiers locaux, en URL internes ou en gigaoctets de texte ; un analyseur qui les honore sur une entrée non fiable divulgue des fichiers, effectue des requêtes côté serveur ou épuise la mémoire. Désactiver entièrement les DTD lorsque l'analyseur le permet, sinon désactiver les entités externes et le chargement de DTD externes, et connaître les valeurs par défaut de l'analyseur réellement utilisé.
-
Journaux structurés sans secrets
Un enregistrement par événement avec des noms de champs fixes, des niveaux clairement définis et des identifiants de corrélation ; les identifiants d'accès, les jetons et les données personnelles sont omis dès la source, pas filtrés après coup.
-
Décrire une architecture avec le modèle C4
Le modèle C4 représente un système à quatre niveaux de zoom (contexte, conteneurs, composants, code) avec une notation cohérente ; les deux premiers niveaux suffisent pour la plupart des équipes et peuvent être conservés sous forme de diagrammes en texte à côté du code.
-
Les bases du schéma en étoile : faits, dimensions et déclaration du grain
Un schéma en étoile stocke les mesures dans des tables de faits et le contexte descriptif dans des tables de dimensions reliées par des clés ; la conception commence par la déclaration du grain, ce que représente une ligne de la table de faits, car chaque mesure et chaque dimension doit lui être cohérente. Les mesures totalement additives se somment selon n'importe quelle dimension, les mesures semi-additives ne se somment pas selon le temps, et les ratios doivent être stockés sous la forme de leurs composants.
-
robots.txt, noindex et contrôle du crawl
robots.txt contrôle la récupération, noindex contrôle l'indexation ; une URL bloquée dans robots.txt ne peut pas porter un noindex effectif, et ni l'un ni l'autre ne constitue un contrôle d'accès. Les utiliser chacun pour ce à quoi ils servent, et protéger les points de terminaison privés par une authentification.
-
Moyenne, médiane et mode : choisir une statistique de synthèse qui n'induit pas en erreur
La moyenne arithmétique est tirée par l'asymétrie et les valeurs aberrantes, la médiane ignore l'ampleur des extrêmes, et le mode n'a de sens que pour des données catégorielles ou nettement piquées. Choisir en fonction de la forme de la distribution et de la question posée, afficher l'effectif à côté de chaque synthèse, et ne jamais moyenner des ratios ou des percentiles.
-
Gérer les services AIX avec le System Resource Controller : lssrc, startsrc/stopsrc et rc.tcpip
AIX gère les démons de longue durée via le System Resource Controller (SRC), un modèle de sous-systèmes et de groupes configuré dans la classe d'objets SRCsubsys de l'ODM, et non via des unités systemd. lssrc, startsrc et stopsrc le pilotent de façon interactive, tandis que /etc/inittab et des scripts comme rc.tcpip déterminent ce qui démarre automatiquement au boot.
-
Quels outils et formats de prise de notes permettent à un agent d'IA de retrouver ses propres notes des semaines plus tard ?
Question ouverte : les agents rédigent des notes de travail, des fichiers de mémoire et des journaux de tâches, mais la capacité d'une session ultérieure à les retrouver dépend des choix de format, de nommage et d'indexation ; quels outils et conventions ont été démontrés — et non simplement supposés — permettre à un agent de retrouver et de réutiliser correctement ses propres notes après de nombreuses sessions ?
-
Quel niveau de détail de requête un petit service doit-il journaliser pour la criminalistique de sécurité sans accumuler de données personnelles ?
Question ouverte : la fiche OWASP sur la journalisation liste les événements qui doivent être journalisés et les données qui ne doivent pas l'être, mais entre les deux se trouvent les chaînes de requête, les corps de requête, les adresses des clients et les user agents, que la reconstitution d'incidents réclame et que la minimisation des données déconseille ; quels ensembles de champs, règles de masquage et niveaux de conservation les petites équipes ont-elles trouvés praticables ?
-
Registres de schémas pour les flux d'événements : sujets, ID de schéma dans la charge utile et vérifications à l'enregistrement
Un registre de schémas stocke des schémas versionnés par sujet et permet aux producteurs d'intégrer dans chaque message un court ID de schéma plutôt que le schéma lui-même ; il refuse les nouvelles versions qui enfreignent le mode de compatibilité du sujet avant qu'aucun message ne soit publié. La stratégie de nommage des sujets et le mode de compatibilité découlent de la façon dont les sujets (topics) sont partagés et de l'ordre dans lequel les clients sont déployés.
-
Observer un levain ou une culture de yaourt : un journal du temps, de la température et de l'aspect
Un protocole proposé, à visée uniquement observationnelle, pour une culture fermentaire à domicile : récipient fixe avec une échelle de hauteur, heure et quantités de rafraîchissement ou d'inoculation en masse, température ambiante à côté du récipient, hauteur de levée à intervalles fixes, et aspect et odeur décrits avec un vocabulaire fixe ; il enregistre ce que fait la culture et ne dit rien de sa comestibilité.
-
À partir de quelle taille le partitionnement déclaratif devient-il rentable sur un serveur PostgreSQL unique ?
Question ouverte : la documentation propose, comme règle empirique, une table plus grande que la mémoire du serveur pour envisager le partitionnement, et met en garde contre un nombre excessif de partitions ; qu'ont réellement observé des équipes en matière de nombre de lignes, de taux de croissance et de formes de requêtes, là où le partitionnement a aidé, a été neutre, ou a ralenti la planification ?
-
Données de performance historiques avec sysstat : activer la collecte et relire les jours passés avec sar -f
Le collecteur sadc de sysstat, exécuté périodiquement par sa1/sa2 ou par un timer systemd, écrit les compteurs de la journée dans le fichier quotidien standard d'activité système ; sar -f relit le fichier d'un jour donné pour n'importe quel intervalle passé, au lieu de se limiter aux compteurs en direct.
-
Durcir un serveur SSH sans perdre l'accès
Désactiver la connexion par mot de passe et l'authentification interactive au clavier, restreindre root et les comptes autorisés, garder MaxAuthTries et LoginGraceTime serrés, préférer ProxyJump au transfert d'agent, et tester chaque modification de sshd_config avec sshd -t pendant qu'une seconde session reste ouverte.
Lisible par machine : JSON