Et voilà, je commence à devenir Symfoniste.
J’avais déjà un peu touché Symfony il y a quelques années puis je me suis tournée et je me suis expertisée en Zend Framework. Cependant il faut voir, Symfony déjà est un produit français, très sollicité en entreprise, et derrière regroupe une communauté vivante et très contributive (il suffit de voir l’espace « Connect » de Sensio pour s’en rendre compte), ce qui est beaucoup plus sympa que le cas de ZF. Donc je me suis tournée naturellement vers ce framework je que ne connais que peu en fin de compte.
Pour commencer, j’ai fait une virée de deux jours dans les locaux de Sensiolabs pour faire une formation sur la gestion des composants et Drupal. Puis le grand évènementiel a lieu : deux jours à la Cité Internationale Universitaire de Paris. Les stands y sont très sympas et remplis de goodies (j’ai eu l’occasion de gagner un Lego Star Wars et de participer au concours de la bonbonnière – que j’ai remporté !).
Le contenu des conférences est alléchant :
- Monoltith repositories with Git (Fabien Potencier) : faire du pluri-repo, c’est bien. Le code isolé peut être réutilisé, on a des repositories de petite taille, les frontières sont claires, le contrôle d’accès facile, ça simplifie l’intégration continue. Mais on peut utiliser efficacement un repo monolitique et plusieurs petits repo. Du coup, le subtree ça change la vie ! http://www.git-attitude.fr/2015/01/30/git-subtrees/
- Guard dans la vraie vie (jeremyFreeAgent) : Guard est un nouveau composant « security » de Symfony. Il facilite l’authentification dans un code qui peut être complexe. La librairie continent une interface, GuardAuthenticatorInterface, qui permet d’utiliser les composant d’une authentification (gestion du Token, succès de l’authentication, traitement de la « response », cookie pour le « remember_me » etc …). Ensuite, un cas pratique avec trois sites qui utilisent trois systèmes d’authentification différents (mot de passe, numéro de téléphone) nous est proposé. Au final l’outil se révèle très puissant, et demande moins de dépendances vers d’autres bundles.
- R2D2 to BB8 (Vincent Chalamont) : Un titre plus parlant serait « Refonte du site lafourchette.com ». A savoir que le site est au départ une grosse machine qui implique : plus de 12 pays, 32000 restaurants, 350000 réservations par mois, et plus de 70 développeurs derrière. Le « Fork Manager V2 » doit pouvoir gérer : les réservations, le contenu, le marketing & CRM, les stats et les plans de salle, tout en sachant en ce qui concerne la V1, que la « dette technique » (quand le site de départ est une usine à gaz avec du ode spaghetti derrière, en gros) est conséquente, les mises à jours sont difficiles, les fonctionnalités obsolètes et non ergonomiques, et qu’il y a des projets interdépendants. Les solutions envisagées ont donc été : création d’une API, la mise en place d’une migration continue, un LegacyBundle, des loaders et des transformers.
- PHP Meminfo ou la chasse aux memory leak (Benoit Jacquemont) : Jeune programmeur, attention aux effets dévastateurs d’une fuite de mémoire ! Moins de mémoire pour les autres programmes, perfs qui chutent, et processus qui n’arriveront jamais à terme ! Le système basique de cache de PHP permet toutefois un ménage : au bout de 10000 objets, le garbage_collector s’éxécute, et son activité peut être mesurée par une appli, « Visual VM », mais attention aux processus du garbage_collector, qui baissent les performances. Il faut donc pour cela fixer les fuites de mémoire. Good practices : monitorer les processus, éviter les services « stateful », utiliser une mémoire limite raisonnable, et garder un nombre raisonnable d’objets en mémoire.
- Retour d’expérience Reactive Architecture et Microservices : Comment découpler mes applications ? (Fabien Meurillon) : Retour sur des migrations de back-office, cette fois chez Auchan. L’utilité d’utiliser des micros-services : un composant applicatif (package Composer), un domaine métier (Domaine Driven Design), et probablement moins de 5 agrégats exposés sur l’API. Les applications doivent être responsives, les services résilients, scalables. Il faut gérer les grosses charges. Restent à mettre en place : le mono-repository, exploiter la bulle d’échange, gérer la propagation de l’information, automatiser les déploiement, et surtout évangéliser les gens 🙂 …
- Performance au quotidien dans un environnement SF (Xavier Lejeune) : La performance à un cout … dans notre cas on chiffre à : 100 euros si le bug est détecté pendant le dev, 1500 si il l’est pendant la recette, 1500 si il l’est en prod. La pattern Data Mapper a donc été choisi, Active Record a été rejeté, pas d’abstraction en programmation. TING a été choisi à la place de doctrine, le cache privé et public a été obtenu. Attention, Composer install génère un cache !
Crédit photo de une : Sensio Labs. Une Amelaye s’y trouve dedans, vous pouvez l’y chercher.