FastCopy est un outil gratuit permettant de supprimer rapidement des millions de fichiers sous Windows, évitant ainsi des lenteurs et une surcharge des ressources système, notamment utile pour les fichiers de logs ou applicatifs. Compatible avec les versions de Windows de 7 à 11 et des serveurs de 2012 à 2025, il gère les chemins UNICODE et dépassant 260 caractères, tout en proposant des fonctionnalités de copie, synchronisation et déplacement. Une version Pro est requise pour un usage en entreprise, et le logiciel peut être installé ou utilisé en mode portable.

L’auteur explique comment il a modernisé un projet legacy reposant sur Alice, Nelmio, Hautelook et Faker pour le rendre plus maintenable avec Doctrine. Après avoir réduit la dépendance à Faker et converti les fixtures Alice de YAML à PHP, il a évité un piège courant : migrer Alice vers Foundry sans résoudre les problèmes sous-jacents, ce qui aurait prolongé la dette technique. En créant une commande personnalisée pour charger toutes les fixtures en une seule fois, il a simplifié le processus et supprimé plusieurs dépendances, dont doctrine/doctrine-fixtures-bundle. Cette approche a permis une migration rapide et une meilleure maintenabilité, illustrant l’importance de privilégier des solutions simples et intuitives plutôt que des refontes coûteuses et peu efficaces.

L’article explique comment résoudre les problèmes de confiance des certificats HTTPS générés par Symfony CLI sous WSL2 lorsque ces certificats sont utilisés depuis un navigateur Windows. L’idée principale est que WSL2 et Windows gèrent séparément leurs magasins de certificats racines, ce qui empêche Windows de faire confiance aux certificats locaux créés dans WSL2. L’auteur détaille d’abord l’installation du certificat racine local via Symfony CLI dans WSL2, puis la méthode pour exporter ce certificat depuis WSL2 et l’importer dans le magasin de confiance de Windows. Cette solution permet d’éviter les avertissements de sécurité dans les navigateurs Windows tout en maintenant un environnement de développement sécurisé.

Symfony 8.1 modernise les commandes console en intégrant les value resolvers Doctrine, comme #[MapEntity], déjà disponibles pour les contrôleurs depuis Symfony 6.2. Cette évolution permet de simplifier la résolution des entités directement dans la signature de la méthode __invoke() d’une commande, réduisant ainsi le code boilerplate. Par exemple, la commande app:user:2fa-setup peut désormais injecter une entité User via #[MapEntity], éliminant les méthodes manuelles de recherche comme findUser().

L’article illustre cette amélioration avec un cas concret : avant Symfony 8.1, il fallait gérer manuellement la récupération de l’utilisateur via EntityManager, tandis qu’après, l’entité est résolue automatiquement grâce à #[MapEntity], qui mappe l’argument console à une propriété de l’entité. Cette approche standardise le comportement entre les commandes console et les contrôleurs HTTP, tout en réduisant la complexité du code.

Enfin, l’auteur souligne que cette modernisation, bien que mineure, révèle des commandes obsolètes encore présentes dans le codebase, rappelant l’importance de maintenir un code propre. Il note aussi un prérequis non documenté : #[MapEntity] nécessite une contrainte d’unicité sur la propriété mappée pour fonctionner correctement.

L’article aborde les trois problèmes courants rencontrés lors de la configuration d’un environnement de développement Symfony 7 avec Docker et WSL2 sous Windows. L’auteur partage des solutions pratiques pour éviter ces écueils, notamment un conflit de port avec PostgreSQL (résolu en mappant le port 5433 sur l’hôte au lieu de 5432) et des soucis de permissions avec le groupe Docker sous WSL2 (corrigés via newgrp docker ou un redémarrage de WSL2). Il évoque aussi l’absence de démarrage automatique du démon Docker au lancement de WSL2, suggérant d’activer systemd ou de lancer manuellement le service. L’auteur justifie enfin son choix d’Apache plutôt que Nginx pour des raisons de simplicité dans un contexte de développement.

L’auteur relate un problème rencontré dans son lab où le redémarrage de systemd-networkd provoquait la perte du lien entre Incus et une interface réseau, car l’index de cette dernière changeait. Une solution a été trouvée en utilisant l’option KeepMaster de systemd, qui maintient l’index de l’interface lors des rechargements ou redémarrages, évitant ainsi la rupture avec Incus.

Le billet mentionne également une commande alternative (ip link set vxlan5 parent br5) pour rattacher explicitement une interface à une parente, bien que cette méthode ne soit pas documentée de manière évidente dans les ressources systemd. L’auteur souligne l’efficacité de KeepMaster pour résoudre son problème récurrent, lié à la gestion des interfaces VXLAN dans son infrastructure.

Ce retour d’expérience s’inscrit dans une série de notes techniques autour de l’administration système et du DevOps, avec une approche pragmatique pour contourner des dysfonctionnements courants dans des environnements Linux modernes.