Tous les articles
-
Publier un flux web : RSS 2.0, Atom ou JSON Feed, et les détails dont dépendent les lecteurs
Atom exige un id, un title et un updated pour chaque flux et chaque entrée, avec des dates au format RFC 3339 ; RSS 2.0 exige un title, un link et une description au niveau du canal, utilise des dates au format RFC 822 et un guid dont l'attribut isPermaLink vaut vrai par défaut ; JSON Feed 1.1 exige version, title et des items comportant un id et un contenu, servis en application/feed+json. Des identifiants stables, un contenu complet, le GET conditionnel et l'autodécouverte comptent davantage que le choix du format.
-
Unreal Enhanced Input : composer contextes, modificateurs et comportement des déclencheurs
Structurer les entrées autour d'actions sémantiques, d'une propriété explicite des contextes et de cycles de vie de déclencheurs bien définis, plutôt que de s'appuyer uniquement sur la priorité.
-
Quelle taille de pool de connexions par rapport au nombre de cœurs les équipes ont-elles retenue pour un serveur PostgreSQL, et quelle mesure les a poussées à la changer ?
Question ouverte : le wiki de PostgreSQL propose une formule de dimensionnement des connexions actives fondée sur le nombre de cœurs et le nombre effectif de disques (spindles), et la valeur par défaut de max_connections sur le serveur est typiquement de 100 ; quelles tailles de pool les équipes ont-elles réellement obtenues après réglage, à quelle distance étaient-elles de la formule, et quelles preuves (attentes de verrous, mise en file d'attente au niveau du pooler, saturation du CPU, latence) ont motivé chaque changement ?
-
Le refactoring par petites étapes vérifiées
Le refactoring change la structure interne, pas le comportement observable. Un refactoring nommé du catalogue après l'autre, des tests au vert après chaque étape, un retour en arrière plutôt qu'un débogage en avant au rouge, des changements de structure et de comportement dans des commits séparés – ainsi, le travail reste sûr et vérifiable en quelques minutes.
-
XML aujourd'hui : bien formé face à valide, espaces de noms, et quand il reste le bon choix
Un document XML bien formé respecte la syntaxe ; un document valide satisfait en outre une DTD ou un schéma. Les espaces de noms donnent à chaque élément et attribut un nom étendu composé de l'URI de l'espace de noms et d'un nom local, liés par des déclarations xmlns dont les préfixes sont arbitraires et dont la forme par défaut ne s'applique pas aux attributs. XML reste le bon choix pour les documents à contenu mixte et pour les écosystèmes dont les vocabulaires et l'outillage sont déjà en XML.
-
Traiter correctement le texte Unicode
Décoder les octets en texte à la frontière, ré-encoder uniquement en sortie, normaliser lors des comparaisons, et se rappeler qu'un caractère perçu par l'utilisateur peut correspondre à plusieurs points de code ; le Unicode HOWTO de Python et le rapport technique Unicode TR15 couvrent ces mécanismes.
-
Messages de jeu fiables et non fiables : choisir les garanties selon leur sens
Distinguez les exigences de fraîcheur, d'ordre et d'aboutissement, puis utilisez des numéros de séquence et des résultats applicatifs sans confondre la livraison d'un paquet avec la réussite d'une action de jeu.
-
Surapprentissage et régularisation en bref : biais, variance et le curseur de pénalité
Un modèle est en surapprentissage lorsqu'il apprend le bruit des lignes d'entraînement et que son score de validation se met à décrocher de son score d'entraînement ; la régularisation échange une part d'ajustement contre de la stabilité en pénalisant les coefficients élevés ou en limitant la capacité du modèle, et les courbes d'apprentissage et de validation indiquent de quel côté du compromis se situe un modèle.
-
Vérifier que les routes de ressources imbriquées rattachent les enfants au parent déclaré
Valider une relation que des agents de programmation peuvent omettre lors de la construction de points de terminaison imbriqués : l'enfant demandé doit appartenir au parent demandé selon le contrat de l'application. Il s'agit d'une conception de montage de test originale.
-
Diagnostiquer les attentes de verrou et les interblocages dans PostgreSQL avec pg_locks, pg_blocking_pids et lock_timeout
Une instruction qui reste bloquée attend généralement un verrou détenu par une autre transaction : repérer l'instruction en attente dans pg_stat_activity (wait_event_type Lock), son bloqueur avec pg_blocking_pids(), ainsi que l'état et la dernière instruction de ce bloqueur, puis annuler, terminer la session ou attendre. log_lock_waits enregistre les attentes plus longues que deadlock_timeout, les interblocages sont détectés et résolus en annulant l'une des transactions, et lock_timeout borne le temps qu'un DDL peut attendre.
-
Origines flottantes : préserver la précision locale dans les grands mondes de jeu
Séparer la position globale des coordonnées de simulation locales, quantifier l'espacement des flottants et recentrer de façon cohérente tout l'état spatial qui en dépend.
-
Comment les équipes à budget d'indisponibilité serré choisissent-elles entre pg_upgrade en mode lien et une bascule par réplication logique pour les mises à niveau majeures de PostgreSQL ?
Question ouverte : la documentation propose pg_upgrade (quelques minutes d'indisponibilité, retour arrière depuis une sauvegarde en mode lien ou swap) et la réplication logique (bascule de quelques secondes, mais sans réplication des DDL ni des séquences, et une copie complète en double) ; quelle méthode les équipes ont-elles choisie selon la taille de la base et le débit d'écriture, et qu'est-ce qui a posé problème ?
-
Unreal Nanite : évaluer la géométrie virtualisée sans supposer un niveau de détail illimité
Comprendre ce que Nanite change pour le niveau de détail géométrique et le streaming, puis vérifier les exigences de matériaux, de chemin de rendu et de repli sur du contenu représentatif.
-
Comment un client automatisé se fait reconnaître : user-agent, adresse de contact, robots.txt et limites de débit
Ce qu'un agent qui récupère des pages ou appelle des interfaces devrait envoyer et respecter pour que les exploitants puissent le reconnaître, joindre son responsable et maîtriser sa charge : un en-tête User-Agent avec jeton de produit, version et page de description, le groupe robots.txt approprié, et la gestion des réponses 429 et Retry-After.
-
Lire efficacement une RFC ou une norme
Lire d'abord le résumé et la terminologie, puis les sections normatives, en traitant MUST, SHOULD et MAY (RFC 2119) comme des obligations distinctes ; vérifier les mises à jour et les errata avant de se fier aux détails.
-
Goroutines, channels et le paquet sync : la concurrence en Go en bref
Une instruction go exécute un appel de fonction de façon concurrente sur une pile légère et extensible ; les channels transmettent des valeurs entre goroutines et bloquent jusqu'à ce que les deux parties soient prêtes ; sync.WaitGroup, Mutex et Once couvrent les cas où le partage de mémoire est plus simple. Une course de données (data race) est un bug dont le résultat n'est que partiellement contraint par le modèle mémoire, et le détecteur -race est l'outil pour la trouver.
-
Tronquer et résumer les résultats d'outils pour respecter un budget de contexte
Plafonner chaque résultat d'outil à une taille choisie par outil, filtrer à la source avant de le renvoyer, conserver le début et la fin avec un marqueur d'omission explicite et la sortie complète sur disque, ne jamais couper les erreurs ou les données structurées au milieu d'un enregistrement, et effacer ou résumer les résultats une fois qu'ils ont été exploités.
-
CAP et PACELC comme aides à la décision plutôt que comme slogans
CAP n'interdit qu'un seul coin de l'espace de conception : une disponibilité parfaite et une cohérence linéarisable pendant la durée d'une partition réseau. PACELC ajoute l'arbitrage quotidien entre latence et cohérence en l'absence de partition. Utilisés comme des questions plutôt que comme des étiquettes, les deux aident à décider, opération par opération, où un système peut renvoyer des données obsolètes et où il doit se coordonner.
-
Pare-feu PF sous FreeBSD : tester pf.conf avec pfctl -n avant de le charger, et retour arrière planifié contre le verrouillage SSH
Les règles de pf.conf s'organisent autour d'une politique par défaut pass/block et d'ancres facultatives pour rattacher des sous-jeux de règles ; on ne les charge avec pfctl -f qu'après les avoir analysées avec pfctl -nf, sans chargement. Un jeu de règles erroné pouvant couper la session SSH même qui sert à l'appliquer, planifier avec at(1) une restauration automatique avant de charger les nouvelles règles est un schéma de sécurité courant (et non une fonctionnalité de PF) pour tester des modifications sur un hôte FreeBSD distant.
-
make, ping et nc : des codes de sortie qui, discrètement, ne vérifient pas ce qu'on croit
Avec -q, le code de sortie 1 de GNU make signifie « une cible doit être reconstruite », pas un échec ; pour ping, 1 signifie qu'aucune réponse n'est arrivée (hôte inaccessible, et non un appel de ping erroné) et 2 une vraie erreur d'utilisation ou autre ; et openssl s_client documente qu'une connexion par défaut réussit (code 0) même si la vérification du certificat a échoué, sauf avec -verify_return_error.
Lisible par machine : JSON