Le Forum PHP 2017, comme si vous y étiez
Ces 26 et 27 octobre, nous nous sommes rendus sur le Forum PHP organisé par l’AFUP, ravis d’assister à des conférences et talks que l’on attendait avec impatience. On peut vous dire qu’on n’a pas été déçu !
Arrivés en team pour vivre ces deux jours, nous avons également eu la chance d’échanger avec un grand nombre de participants, autour du stand Linkvalue, sponsor du Forum PHP, où nous avons pu vous rencontrer.
Après une Keynote d’introduction et la présentation de l’agenda de la matinée, on enchaîne directement avec une première conférence sur PHP 7.2.
PHP 7.2
Présentée par Rémi Collet de Red Hat, nous avons vu les prochaines dépréciations et les nouveautés de cette version. Les grands points à retenir :
- mcrypt définitivement supprimé,
- le mot object devient réservé,
- le « header already sent » pour les sessions va faire casser votre code,
- ajout de l’argon 2 pour le cryptage (attention toutefois, il peut prendre pas mal de temps),
- le type hinting peut être enlevé dans une classe enfant,
- xdebug non compatible pour le moment,
- les extensions php sans le type (ex: ;extension=php_shmop),
- simplification d’utilisation des protocoles tls et ssl,
- méthode __autoload supprimée.
Un descriptif plus complet est disponible dans la documentation officielle : http://php.net/manual/en/migration72.php
Attention : Une note sur le support des versions de PHP : les versions 5.6 et 7.0 auront des fix de sécurité jusqu’en décembre 2018 et la version 7.1 jusqu’en décembre 2019. Après ces dates, elles ne seront plus maintenues. Il est donc plus que temps de mettre à jour ses packages si ce n’est pas déjà fait !
Enfin, le gain de performance est de 5% comparé à la 7.1. Ils s’efforcent de maintenir ce gain constant entre chaque nouvelle version.
Le conseil de Rémi : “mieux vaut faire ses montées chaque année (ex: de 5.4 -> 5.5, puis 5.5 -> 5.6 l’année suivante) plutôt que de faire une grosse (5.4 -> 7.2) tous les dix ans.”
Slides : https://blog.remirepo.net/public/Docs/Paris-2017.pdf
AB testing M6
Fabien de Saint Pern et Nastasia Saby de M6 Web ont présenté leur manière de procéder aux tests AB sur 6play et ce que l’on pouvait en apprendre.
Basé sur l’utilisation d’une production cachée pour les utilisateurs et des fichiers de configuration JSON, leur outil Applaunch modifiait pour chacun le paramétrage de la page. Grâce à l’aide de leur data-scientists et la construction d’un « data lake », ils stockent la donnée venant de n’importe quel endroit (base Cassandra, MySQL, Hadoop, etc.) via Spark pour les analyser.
À partir de là ils ont pu récupérer les données comportementales des utilisateurs et créer leur segmentation.
De cette expérience, ils nous font ressortir quelques pièges, comme la saisonnalité (les métriques peuvent varier suivantes le moment où l’on teste) et la mise en production d’une nouvelle fonctionnalité. Cette dernière peut biaiser le vrai comportement d’un utilisateur.
Slides : https://www.slideshare.net/FabiendeSaintpern/ab-testing-chez-m6web/
Écrire des tests pour le long terme
Avec humour, en utilisant le thème de la nourriture, Charles Desneuf nous a encouragés à repenser nos tests, afin d’avoir plus de facilité à les maintenir.
Il revient d’abord sur les bénéfices des tests : détection de bugs / refacto plus facile / documentation / détection de problème de design / réflection sur l’interface système.
Mais, il ajoute aussi que ceux-ci doivent être rapides, être indépendants les uns des autres et surtout ne pas être directement relié à l’implémentation. Comprenez par là, le code de test ne doit pas être couplé au code de production.
Il montre que nos tests peuvent relier le vocabulaire métier au code de production. On peut passer par un meilleur découpage de classe (ex : EndiveBaseTest et EndiveCrueTest), interface, factory (Endive::crue), ou d’autres design patterns, comme le builder, pour avoir une meilleure compréhension du métier.
De la même façon, il met en relief les pièges fréquents lors de la construction de nos tests, afin qu’ils soient plus stricts et plus efficaces, pour ne plus dépendre du système (ex : Datetime), etc.
Conclusion, Charles nous a donné 2 choses : envie de suivre ses bonnes recettes, afin d’appliquer tous ces bons conseils et FAIM !
Slides : https://www.slideshare.net/CharlesDesneuf/recettes-de-tests
Signaux, process id et PHP
Cette fois-ci, une conférence en live-coding, où Alexandre Balmes détaille la bonne utilisation des signaux et des process id avec pcntl et posx.
Après avoir démontré l’efficacité d’un fichier .lock pour vérifier qu’une tâche est déjà en cours d’exécution, comparé à une gestion en base de données, Alexandre nous montre le comportement que peut avoir notre process en lui envoyant des signaux tels que SIGHUP ou SIGQUIT. Tout cela avec symfony/console qui nous facilite le travail.
Il finit par préciser que, bien sûr, le PHP n’est pas le langage le plus adapté pour ce type de traitement, mais que l’on peut désormais, à minima, faire un effort de qualité avec cette nouvelle gestion et en prenant le temps d’y ajouter des tests.
Slides : elles sont malheureusement en CLI :p
Maison du Monde et l’architecture orientée services
Retour d’expérience sur la migration de Maison du monde sur une architecture en micro-services par Marc Hugon.
Elle s’est faite de manière indépendante sur chaque service (Catalogue, Commande, etc.), étape par étape et surtout en n’ajoutant aucune nouvelle fonctionnalité dans le legacy. Ils ont désormais un seul endpoint par API qui récupère tout le contenu nécessaire pour l’affichage d’une page. Concernant la gestion des versions, un principe simple : « si on ne peut pas gérer la non-régression, c’est qu’on doit créer un nouveau service ».
La mise en place de cette nouvelle architecture a permis aussi d’y voir plus clair dans les rapports Scrutinizer et Sensio Insight désormais plus lisibles. La technique d’un hash dans le header qui est transféré entre chaque micro-service permet de bien gérer ses logs d’erreur.
Ils sont aussi passés au monorepo, c’est à dire à centraliser tous les services en un seul repo pour le versionning. Cela permet une meilleure lisibilité ainsi offre un PR plus global.
L’arrivée d’un nouveau développeur est aussi facilitée avec la création d’une commande « workspace » et l’utilisation de docker pour provisionner son environnement de travail en seulement quelques minutes.
Cette nouvelle architecture permet donc de rester souple et réactif, d’introduire de nouvelles technologies, gérer la croissance, la complexité globale et d’améliorer le quotidien des équipes.
Cependant, n’oublions pas de préciser que : “pour changer, il faut que la direction veuille changer aussi.”
Slides : https://fr.slideshare.net/secret/833S9wFAYnmLgu
Climbing the Abstract Syntax Tree
Conférence beaucoup plus technique, néanmoins intéressante sur l’explication et la compréhension du lexer et parser de PHP, durant laquelle James Titcumb nous immerge dans le cœur du langage.
Il nous montre une des raisons de la différence de performance entre la version 5 et 7 de PHP avec AST. Présentation de cette data-structure et ensuite tutoriel pour construire facilement notre propre Lexet, Compiler et Executer.
L’un des gros avantages de AST est qu’il est compréhensible et lisible par les humains grâce à une syntaxe simple. James nous précise avec humour que cela accélère le PHP et donc que si notre code ne s’exécute pas vite, c’est que la faute ne vient pas du langage, mais plutôt de nous ;).
Slides : https://www.slideshare.net/asgrim1/climbing-the-abstract-syntax-tree-forum-php-2017
Développer plus rapidement avec Symfony 4
Kevin Dunglas, contributeur au framework Symfony, est revenu sur les nouveautés de cette version avec laquelle une approche micro-framework, une compatibilité uniquement PHP 7 et Symfony Flex sont au programme.
Une nouvelle organisation du code est prévue, la plus légère possible, pour charger seulement les composants que l’on souhaite et un micro kernel. Cela marque aussi la fin certaine de Silex.
Grâce à l’autowiring, il y aura moins de configuration. L’implémentation sur les plateformes de cloud est plus facile grâce aux fichiers .env et on pourra utiliser simplement le preload pour l’HTTP2.
À noter également le 1er composant js développé par sensiolab, `Encore` qui permet d’integrer Webpack (https://github.com/symfony/webpack-encore). Il vient remplacer assetic, dont la documentation recommandait de ne pas l’utiliser au profits des outils js.
Un de nos articles vous aidera à compléter cette présentation : https://blog.positivethinking.tech/hands-on-symfony-flex-6429c5e6875e
Dernière chose, la version 4 étant rétro-compatible avec la 3.4 de Symfony pour faciliter la migration, n’attendez plus avant de vous mettre à jour ;)
Slides : https://dunglas.fr/2017/10/symfony-4-run-through-forum-php-2017/
Les hexagones de la ruche qui dit oui
La Ruche qui dit oui, représentée par Benoit Merlet fait un retour d’expérience sur sa migration d’architecture de 2015 à aujourd’hui.
Initialement sur une structure monolithique en Domain Driven Design, avec utilisation de différentes couches et design patterns, l’équipe partait pourtant sur une bonne construction. Cependant, le code métier n’était pas visible et organisé trop « verticalement ». Chacun des dossiers finissait par avoir un nombre considérable de fichiers.
Il a donc fallu réorganiser toute l’architecture en clarifiant les interactions et sous domaines, en regroupant mieux les fonctionnalités et en choisissant de grossir “horizontalement” cette fois.
Un premier test de modularisation en micro-services qui s’est révélé être un échec. Équipe trop petite, communication encore trop importante avec le monolithe, problème de monitoring et d’orchestration, une autre solution a dû prendre le relai.
Avec la construction en hexagone, le code est devenu mieux découplé et autonome, les différents domaines sont plus identifiables et le monitoring plus facile. Le métier reste séparé du framework et chaque nouvelle fonctionnalité conduit à la création d’un hexagone tout en supprimant l’ancien code legacy. Ils envisagent éventuellement de revenir aux micro-services, qui seront déjà prédécoupés avec les hexagones, quand l’équipe sera plus grande.
Quelques conseils pour une migration efficace :
- Ne pas coupler les différents contextes,
- Définir des Value Objects,
- Nommer les concepts de la même manière partout,
- Ecrire du code qui est facile à supprimer et non facile à étendre.
Slides : https://speakerdeck.com/trompette/les-hexagones-de-la-ruche-qui-dit-oui
19 millions de recherches par jour — Meetic
Sur un fond de Game Of Thrones où Jon Snow cherche sa Ygritte via le Search Engine de Meetic, Sébastien Le Gall (@seb_legall) présente comment ils ont pu atteindre des performances excellentes en termes de scalabilité et de vitesse.
Il explique tout d’abord leur architecture organisée en micro-services avec API Gateway, basée sur une utilisation du Domain Driven Domain et une communication via un event bus en Kafka. Chaque domaine, comme « Profil », « Picture » ou « Inbox » a son propre micro-service avec sa base de données. Chacun est responsable de sa donnée et doit être au courant de ses mises à jour.
L’utilisation conjointe de Spark pour exécuter des requêtes sur plusieurs serveurs à la fois leur permet de diminuer drastiquement la performance de leur script. Fait impressionnant, grâce à Spark, ils sont désormais capables de régénérer en quelques minutes seulement toute l’indexation ElasticSearch si, par exemple, un bug s’y immisce. Alors qu’en PHP la durée était estimée entre 5 à 7h, la solution d’Apache ne prend que 25min !
Aussi, afin de gérer plus facilement leurs requêtes ElasticSearch, ils utilisent le moteur de template Twig qui permet une meilleure lisibilité et une modularité efficace. Les fichiers sont ainsi centralisés et les JSON ne sont plus si imbuvables.
Encore une fois, pour leur besoin, ils ne sont pas les seuls à enfreindre des règles du micro-services. Pour de la recherche, les informations sont dispersées un peu partout et l’équipe n’hésite donc pas à les faire communiquer entre eux pour récupérer les données. Également pour éviter la dépendance, il peut arriver que la data soit dupliquée entre différentes bases de données.
Réécriture de code vieux de 17 ans
Sauveteuse de projet, Anna Filina, nous remet les clés pour commencer à refacto nos vieux legacy. Un talk avec de bonnes leçons et des exemples tous aussi vrai les uns que les autres.
L’important est de bâtir une stratégie. Rien n’est insurmontable, il faudra passer par une réécriture progressive de votre code. Choisir de toute refaire complètement à partir de zéro ne marche jamais vraiment selon son expérience.
Pour cela, on peut commencer à la faire par classe, par fonctionnalité, ou encore par endpoint http. Attention toutefois à partager les sessions et la base de données si on crée une nouvelle application à partir du legacy. Avec Apache et son mod_rewrite, on peut facilement router les différents endpoints en fonction de notre refacto. L’intérêt est que ce soit évidemment transparent pour l’utilisateur et sans perte de données.
Il est très important aussi de faire une sauvegarde et d’avoir testé au préalable une restauration. De même, pensez à anonymiser les données sensibles comme les transactions bancaires et bien sûr, évaluez les risques en amont. Utilisez également des données de production afin de ne pas avoir des tests biaisés à cause de données trop « parfaites ».
L’objectif ensuite est toujours le même : extraire les méthodes au fur et à mesure, en s’assurant que nos tests continuent de passer. Extraire et réécrire le design est aussi essentiel, car lorsque l’on reprend un code, on essaie de comprendre la méthodologie de développeur. Si une première refacto n’est pas efficace et que l’on doit essayer de comprendre les 2 différentes mentalités, la tâche devient plus ardue et plus longue.
Les éléments clés à retenir :
- faire une isolation rapidement,
- créer une stratégie,
- si on touche, on refacto,
- ne pas hésitez à échanger avec les autres pour s’inspirer,
- Chaque problème a une solution !
Si une refacto est estimée à 6 mois, c’est qu’elle est trop lourde et que les chances de succès sont minces. Il faut donc trouver d’autres solutions.
Pour éviter de tomber dans le travers d’un futur nouveau legacy 5 années plus tard, il faut s’efforcer de refactorer son code continuellement, avoir de bonnes pratiques et écrire une documentation lors de chaque pull request. En suivant ces bons conseils, nous n’aurons plus peur de nos vieilles applications !
Slides : https://speakerdeck.com/afilina/reecriture-de-code-vieux-de-17-ans
Nos collaborateurs participent régulièrement à des événements phares du monde de la Tech. N’hésitez donc pas à vous abonner à notre compte Medium pour suivre nos prochains retours de conférences et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
Les auteurs
Développeur back, bon pied gauche, FIFAtologue
Développeur back, technophile, adepte de gyroroue
