Un super outil à auto héberger qui permet de convertir des fichiers dans plein de formats
Ce tutoriel explique comment déployer Longhorn, une solution de stockage distribué, sur un cluster K3s (Kubernetes léger).
Il détaille les prérequis (Kubernetes 1.28+, 2 Go de RAM, open-iscsi installé), la préparation d’un dossier dédié (/opt/longhorn), puis l’installation via un manifest YAML personnalisé pour spécifier le chemin de stockage. Après déploiement, il montre comment vérifier l’état des pods, corriger une mauvaise configuration via un patch, et tester le stockage avec un PVC de 1 Go. Des astuces pour la mise à jour, la vérification de l’état du service et le redimensionnement des volumes sont aussi partagées. Idéal pour ajouter du stockage persistant et résilient à un cluster K3s avec peu de ressources.
Ce guide explique comment optimiser le chargement des polices web pour éviter de ralentir un site : privilégiez le format WOFF2 (le plus efficace et universel), hébergez vos polices vous-même pour améliorer les performances et la vie privée, et utilisez font-display: swap pour afficher immédiatement un texte de repli avant le chargement de la police personnalisée. Pensez à pré-charger les polices critiques avec <link rel="preload" as="font" ...>, à sous-ensembliser les polices (unicode-range) et à éviter les formats obsolètes (TTF, OTF, etc.). Intégrez les déclarations @font-face directement dans le <head>, choisissez des polices de repli système bien adaptées, et utilisez size-adjust ou font-size-adjust pour limiter les décalages de mise en page (CLS). Enfin, testez sur des réseaux lents et surveillez l’impact des polices sur les performances, en limitant le nombre de variantes et en évitant les polices d’icônes au profit des SVG. L’objectif : allier design et rapidité sans compromis.
L'auteur montre qu’il n’est pas nécessaire de migrer vers TypeScript pour bénéficier de sa rigueur : PHP 8.1+, couplé à des outils d’analyse statique (Psalm, PHPStan) et à des bibliothèques idiomatiques, permet d’obtenir des garanties similaires en typage, validation et maintenabilité. L’article détaille des équivalences concrètes : DTOs (classes typées + validation runtime), énumérations (PHP enums + match), génériques (via docblocks et analyse statique), métadonnées (attributs PHP), validation (Symfony Validator), gestion des erreurs (objets Result ou exceptions), et asynchrone (queues ou Fibers). L’approche est incrémentale, avec des exemples prêts à l’emploi, et met en avant les forces de PHP (écosystème mature, performances) tout en comblant l’écart avec TypeScript sur la sécurité et l’ergonomie. À retenir : combiner typage statique, validation aux frontières et design explicite pour un code PHP aussi robuste et maintenable qu’une base TypeScript, sans tout réécrire.
L’article explique comment gérer la traduction de contenu statique (menus, titres, boutons) dans Symfony à l’aide du composant Translation. Il détaille les étapes clés : installation via symfony composer require translation, configuration des locales dans translation.yaml et routes.yaml, utilisation de clés (ex: about_us) dans des fichiers YAML par langue (messages.en.yaml, messages.fr.yaml), et intégration dans Twig avec le filtre |trans et un sélecteur de langue dynamique. Il aborde aussi le débogage avec debug:translation et l’extraction automatique des clés manquantes, tout en évoquant l’option d’utiliser des services externes comme Crowdin pour une gestion collaborative. Une approche simple et efficace pour internationaliser une application Symfony.
L’article explique la différence fondamentale entre les DTO (Data Transfer Object) et les Entities dans Symfony, deux concepts clés pour structurer proprement une application. Les Entities représentent les objets métiers persistés en base de données, liés à Doctrine et souvent chargés de logique complexe, tandis que les DTO sont des objets légers, dédiés au transfert de données entre les couches (API, formulaires, services), sans logique métier ni persistance. Utiliser des DTO permet de découpler la validation, la sérialisation et la manipulation des données des Entities, améliorant ainsi la maintenabilité, la sécurité (en évitant d’exposer directement les Entities) et la clarté du code. L’auteur souligne que les DTO sont particulièrement utiles pour gérer les entrées/sorties des contrôleurs ou des services externes, tandis que les Entities restent le cœur du modèle de données. En résumé, bien distinguer les deux optimise l’architecture et réduit les risques d’incohérences ou de fuites de données sensibles.
L'auteur partage son parcours personnel et professionnel avec Kubernetes, soulignant qu’il n’existe pas de réponse universelle. Il a découvert l’orchestration via Docker Swarm, puis Kubernetes à travers des services managés comme AKS (Azure) et GKE (Google Cloud), avant d’expérimenter des solutions plus légères comme K3S et Talos Linux. Chaque approche—services managés, déploiements "the hard way", ou outils simplifiés—offre des avantages et des limites, selon le contexte et les besoins. L’important est de choisir la méthode qui suscite la curiosité et permet d’apprendre en pratiquant, car Kubernetes et son écosystème évoluent constamment, offrant de multiples angles d’entrée. L’essentiel reste d’oser explorer et comparer, sans crainte de se tromper.
Un analyste confronté à une requête lente sur une table de 150 millions de transactions (2 minutes d’exécution, parfois des timeouts) a optimisé son code en utilisant une CTE (Common Table Expression) avec WITH. Au lieu de joindre d’abord les tables puis de filtrer, la CTE filtre d’abord les transactions récentes (20M de lignes au lieu de 150M), réduisant le temps d’exécution de 127 à 11 secondes. En allant plus loin et en agrégeant directement dans la CTE, il a même descendu ce temps à moins de 6 secondes. La clé ? Filtrer tôt pour alléger la charge de jointure, clarifier la logique, et exploiter les optimisations des moteurs modernes (PostgreSQL 12+, BigQuery). Attention toutefois : les performances varient selon le SGBD (risque de matérialisation en tables temporaires sous MySQL ancien). Une leçon simple : une requête bien structurée = des gains de performance majeurs.
L'auteur explique que les bons ingénieurs logiciels fonctionnent en boucle : ils construisent un modèle mental des besoins, écrivent du code, comparent le résultat avec leur modèle, puis ajustent le code ou les exigences. Les LLMs, bien qu’efficaces pour générer ou modifier du code, échouent à maintenir ces modèles mentaux cohérents. Ils se perdent face aux échecs de tests, hallucinent des détails, et peinent à gérer le contexte ou à zoomer entre le global et le local — des capacités essentielles pour résoudre des problèmes complexes. Même avec des avancées, ils restent des outils d’assistance, pas des développeurs autonomes : c’est à l’humain de garantir la justesse des exigences et du code, surtout sur des projets non triviaux. On préfèrera donc miser sur une collaboration humain-agent, mais le développeur reste aux commandes.
Cet article détaille la configuration d’un serveur rsyslog sous Ubuntu 24.04 avec authentification TLS, afin de centraliser et chiffrer les logs en transit sur le réseau. Il explique pourquoi utiliser rsyslog (notamment pour sa compatibilité avec divers équipements et sa simplicité d’intégration), puis présente les étapes clés : génération de certificats (PKI interne ou auto-signés), configuration du serveur avec gtls pour valider les clients via leur certificat (mode x509/name ou empreinte SHA256), et gestion des droits sur les fichiers de certificats. Plusieurs scénarios sont abordés : authentification mutuelle, chiffrement seul, ou utilisation de certificats publics pour l’exposition sur Internet. Des exemples de filtrage des logs (par IP, chaîne de caractères) et de tests de configuration sont aussi fournis, le tout sur le port 6514/TCP. Une ressource utile pour sécuriser la centralisation des logs en respectant les bonnes pratiques (ISO27001, HDS, etc.).
Dans cet article, Milan Milanović partage les cinq livres qui ont marqué sa carrière d’ingénieur et son évolution vers le poste de CTO. Il explique comment "The Pragmatic Programmer" lui a appris à écrire du code professionnel, durable et adaptable, en insistant sur l’importance de l’itération rapide et de la responsabilité collective. "Designing Data-Intensive Applications" a transformé sa vision de l’architecture des systèmes, en mettant l’accent sur les compromis entre cohérence, disponibilité et tolérance au partitionnement, ainsi que sur la rigueur dans le choix des bases de données. "A Philosophy of Software Design" l’a aidé à lutter contre la complexité du code en privilégiant des modules profonds et bien conçus, faciles à maintenir. "Thinking, Fast and Slow" de Daniel Kahneman lui a révélé l’impact des biais cognitifs sur la prise de décision, l’incitant à adopter une approche plus analytique et moins intuitive. Enfin, "The 7 Habits of Highly Effective People" a renforcé ses compétences en leadership, en lui apprenant à se concentrer sur ce qu’il peut contrôler, à écouter activement et à investir dans son développement personnel. Ces ouvrages, au-delà des compétences techniques, lui ont offert des modèles mentaux essentiels pour devenir un meilleur architecte, décideur et leader. Une lecture inspirante pour quiconque souhaite allier expertise technique et croissance personnelle.
Un mémo des actions à faire pour passer de Debian 12 à 13
L'auteur présente 3 techniques pour déclencher un téléchargement de fichier :
- un attribut introduit en HTML5
- la simulation d'un clic en JavaScript, par exemple suite à une action utilisateur
- dans le cas du téléchargement de données générées dynamiquement, les transformer en Blob et utiliser la méthode précédente
Le débat entre monolithe et microservices évolue vers un équilibre pragmatique : la simplicité, l’expérience développeur et la maintenabilité deviennent prioritaires. Les entreprises, après avoir expérimenté les coûts élevés et la complexité des microservices, se tournent de plus en plus vers des architectures modulaires ou des monolithes bien structurés, comme en témoignent des exemples comme Amazon Prime Video, qui a réduit ses coûts de 90 % en revenant à une approche monolithique. La culture du "vibecoding" (optimisation du bien-être et de la productivité des développeurs) favorise aussi les monorepos et les architectures centralisées, tout en intégrant des outils modernes pour garder une flexibilité. L’enjeu n’est plus de choisir un camp, mais d’adapter l’architecture au contexte, en privilégiant la clarté, la résilience et l’alignement d’équipe, avec la possibilité de basculer entre les deux approches selon les besoins. Les outils comme Terraform, les devcontainers ou les CI/CD avancées permettent désormais de repenser les choix architecturaux avec plus d’intention et moins de dogmatisme.
Les branches divergentes : source de conflits en push/pull
Erreurs classiques :
! [rejected] main -> main (non fast-forward)
fatal: Need to specify how to reconcile divergent branches.Qu’est-ce qu’une branche divergente ?
Local et distant ont chacun des commits que l’autre n’a pas.
4 états possibles avec une branche distante :
- À jour
- Besoin de pull
- Besoin de push
- Divergée (il faut choisir comment résoudre le conflit)
Comment détecter une divergence ?
git fetch
git status
# Exemple de sortie :
# "Your branch and ‘origin/main’ have diverged, and have 1 and 1 different commits each."Solution rapide :
git pull --rebase(Mais il existe d’autres options, comme merge.)
À retenir :
git fetchrécupère les derniers commits.git pull=git fetch+git merge(ou rebase).
Git affiche constamment des diffs – mais parfois, ils semblent étranges.
Pourquoi ?
- Git ne comprend pas les intentions : un renommage (
git mv old.py new.py) est traité comme une suppression + ajout. - L’algorithme de diff compare simplement deux versions et essaie de résumer les changements de façon lisible… mais pas toujours avec succès.
Astuce :
- Git propose plusieurs algorithmes de diff. Par exemple, pour mieux gérer les réorganisations de code :
git diff --histogram
Git utilise un processus de commit en 2 étapes :
- Ajouter les modifications à la zone de staging (
git add,git rm,git mv). - Valider avec
git commit.
La zone de staging, 3 noms pour une seule chose :
- staged (
--staged) - cache (
--cached) - index (
--keep-index)
Astuces :
git add -ppermet de commiter seulement certaines parties d’un fichier.git diffne montre que les modifications non staged :git diff HEAD→ toutes les modifications non commitées.git diff --cached→ seulement les modifications staged.
git commit -ane prend pas en compte les nouveaux fichiers (il faut lesaddavant).
Git n’a pas de bouton "Annuler"
Pas de unadd, uncommit, unmerge ou unrebase. À la place, il y a git reset – puissant, mais dangereux.
Comment fonctionne git reset ?
- La plupart des commandes Git avancent la branche (
git commit,git merge,git pull). git resetpeut déplacer la branche n’importe où : en arrière, en avant, ou "de côté".- Exemple :
git reset HEAD^force la branche à pointer sur le commit parent, et déstage les changements.
Options clés :
- Par défaut : conserve les modifications dans le répertoire de travail.
--hard: supprime les modifications non commitées (attention, irréversible !).
Risques :
- Facile de "perdre" des commits en reculant une branche.
- Avec
--hard, perte définitive des changements non commités.
Le reflog Git, c’est quoi ?
Un historique de tous les IDs de commit qu’une branche, un tag ou HEAD a déjà pointés. Utile pour retrouver des commits "perdus".
Différences avec git log :
- Le reflog est local (non partagé entre dépôts).
- Il montre l’état des branches avant un rebase (contrairement à
git log). - Les entrées de plus de 90 jours peuvent être supprimées par
git gc.
Comment l’utiliser ?
- Lancer
git reflog(ougit reflog BRANCHpour moins de bruit). - Chercher un message de commit pertinent.
- Inspecter le commit avec
git show $COMMIT_IDougit log $COMMIT_ID. - Récupérer le commit avec
git reset --hard $COMMIT_IDougit branch $NAME $COMMIT_ID.
Limites :
- Le reflog d’une branche est supprimé si la branche l’est.
- Inutile pour récupérer un stash supprimé (
git stash drop). - Les entrées ne correspondent pas toujours aux commandes Git exécutées.
Dernier recours :
Si le commit n’est plus dans le reflog, utiliser git fsck pour lister les commits non référencés.
Exposer son localhost sur internet est indispensable pour tester des webhooks, partager des démos en direct, ou tester sur des appareils mobiles réels. L’outil open source Tunnelmole permet de créer un tunnel sécurisé entre un serveur local et une URL publique en quelques secondes. Après avoir lancé son serveur local (ex: localhost:3000), il suffit d’installer Tunnelmole (npm install -g tunnelmole ou via un script d’installation), puis de lancer tmole 3000 pour obtenir une URL publique HTTPS accessible partout. Idéal pour le développement, le débogage ou la collaboration, Tunnelmole est transparent, open source et permet même l’auto-hébergement pour plus de contrôle. Une solution simple et efficace pour sortir de l’isolement de localhost.