Quotidien Shaarli

Tous les liens d'un jour sur une page.

October 25, 2025

Image Dithering: Eleven Algorithms and Source Code | tannerhelland.com

L’article explique en détail le dithering, une technique toujours utile en traitement d’image, même à l’ère des écrans haute résolution. Le dithering permet de simuler des couleurs ou des nuances indisponibles en répartissant intelligemment les pixels disponibles, ce qui est particulièrement utile pour réduire la taille des fichiers, adapter des images à des imprimantes en noir et blanc ou à des palettes de couleurs limitées. L’auteur présente onze algorithmes de dithering, dont les célèbres Floyd-Steinberg, Jarvis-Judice-Ninke, Stucki, Atkinson, Burkes et Sierra, en expliquant leur fonctionnement basé sur la diffusion d’erreur. Chaque algorithme utilise une matrice spécifique pour propager l’erreur de quantification aux pixels voisins, améliorant ainsi la perception visuelle des dégradés. L’article inclut des exemples visuels comparatifs et des conseils pour implémenter ces méthodes, ainsi qu’un lien vers un moteur de dithering open-source (PhotoDemon). Une ressource précieuse pour les développeurs et designers souhaitant optimiser ou styliser des images sous contraintes de couleurs. Lire l’article complet.

Éviter les chevauchements temporels

L’article explore trois méthodes pour gérer les chevauchements temporels dans une base de données PostgreSQL, en prenant l’exemple d’une application de location de vélos. La première méthode utilise deux colonnes (start_datetime et end_datetime) avec un déclencheur PL/pgSQL pour vérifier les conflits, ce qui est efficace mais complexe à maintenir. La deuxième méthode exploite le type TSTZRANGE et une contrainte d’exclusion avec un index GiST, offrant une solution plus élégante et performante, surtout depuis PostgreSQL 9.2. Enfin, la troisième méthode, introduite avec PostgreSQL 18, utilise la clause WITHOUT OVERLAPS pour simplifier la déclaration de cette logique directement dans une contrainte unique. L’article compare les performances d’insertion, la taille des index et les temps de recherche : les solutions basées sur les plages de dates (range) sont plus rapides à l’insertion, mais les index GiST occupent plus d’espace disque. Les tests montrent aussi que l’optimisation des requêtes dépend fortement de la structure des index et du type de recherche effectué. En conclusion, le type range et la clause WITHOUT OVERLAPS apportent une gestion plus propre et intégrée des chevauchements, au prix d’un stockage légèrement plus important.

Fix the 'host key verification failed' issue | DeepakNess - Liens en vrac de sebsauvage

Je copie colle ^^

Sous le coude : la commande à utiliser quand la clé ssh d'un host a changé.
ssh-keygen -R

Expliquer un concept avant de le nommer

L'auteur partage une réflexion sur l’importance d’expliquer un concept avant de le nommer, surtout dans un contexte technique ou d’équipe. Selon lui, partir d’un problème concret, explorer les solutions possibles et leurs implications permet à l’équipe de comprendre et d’adhérer à une approche avant même de lui attribuer un nom — souvent un « buzzword » qui peut générer des biais ou des préjugés. Il illustre cela avec l’exemple de l’architecture hexagonale, adoptée naturellement par son équipe une fois le besoin et la logique compris, alors que le terme seul aurait pu être rejeté d’emblée. L’enjeu est d’éviter que les mots ne deviennent des arguments d’autorité et de privilégier la compréhension profonde pour évaluer la pertinence d’une solution. Une pratique qui favorise la réflexion critique et l’adhésion collective.

How Shopify Handles 30TB of Data Every Minute with a Monolithic Architecture | by Himanshu Singour | Oct, 2025 | Medium

Shopify gère 30 To de données par minute pendant des événements comme le Black Friday, tout en maintenant une architecture "monolithique modulaire" et scalable. Leur secret ? Une approche disciplinée basée sur un monolithe modulaire en Ruby on Rails, organisé en "quartiers" logiques (checkout, paiements, commandes, etc.), chacun avec sa propre équipe et ses responsabilités claires. Ils utilisent l’architecture hexagonale (Ports and Adapters) pour isoler la logique métier des dépendances externes, et des Pods (clusters isolés) pour répartir la charge et limiter les pannes. Leur pipeline de données repose sur Debezium + Kafka pour du traitement en temps réel, tandis que MySQL, optimisé avec des centaines de shards et un équilibrage dynamique, supporte 10 millions de requêtes par seconde. Grâce à des outils internes comme Packwerk (pour la modularité) et Sorting Hat (pour le routage intelligent), Shopify prouve qu’un monolithe bien conçu peut rivaliser avec des architectures microservices, même à l’échelle mondiale — tout en restant simple, fiable et "ennuyeusement" efficace. Une leçon de sobriété technique à l’ère de l’hyperscale.