Le PHP Tour 2016 à Clermont-Ferrand en 10 minutes

…Ou plus !

Le PHP Tour 2016 de l’Afup avait lieu ces lundi et mardi à Clermont-Ferrand. En plein coeur des volcans et au sein du Polydome, nous avons bu de la Volvic de la Cristaline et assisté à de nombreuses conférences, dont cet article s’efforcera de vous conter les plus intéressantes !

Clermont-Ferrand

La base de données

Grown-up MongoDB: Schema Design for Optimal Performance

La première journée a commencé avec une présentation de MongoDB par Derick Rethans ; plus une introduction qu’une vraie entrée en matière en termes de performances, nous sommes un peu restés sur notre faim, faute de rapprochement avec les contraintes réelles d’un déploiement de MongoDB (replicaSet, sharding, timeout du socket PHP sur les opérations longues, performances de certaines opérations très basiques comme le « count »…).

Nous avons par contre beaucoup apprécié les exemples avec du Whisky et la validation de document arrivée en version 3.2, cependant cela ne va pas révolutionner notre utilisation de MongoDB (dont nous ne sommes pas vraiment friand au demeurant).

Phinx pour migrer vos bases de données

Rob Morgan a bénéficié d’une salle archi-comble pour nous présenter sa librairie Phinx (que personne n’utilisait dans l’assistance d’ailleurs !). Pour notre part, nous utilisons surtout Doctrine Migrations (et parfois Liquibase) pour gérer nos bases de données. L’approche de Phinx ne nous laisse pas indifférents car elle a l’avantage d’être agnostique contrairement à Doctrine.

Les futures fonctionnalités telles que la génération automatique de migrations et le support des bases de données multiples sont à surveiller.

Les performances et le débug

PHP Meminfo ou la chasse aux memory leaks

On le sait, les références cycliques causent des fuites de mémoire en PHP. Le problème a été réglé en PHP 5.3 avec l’apparition du Garbage Collector, mais celui-ci ne dispose que de 10000 entrées et impacte dangereusement les performances (vous vous souvenez de ce patch sur Composer ?). L’outil présenté par Benoit Jacquemont permet d’analyser ce que la mémoire de PHP contient à un instant T, et donc de trouver beaucoup plus facilement le ou les objets responsables de la fuite, et même leur source.

Un outil de qualité, très bien présenté, on a aimé !

Arrêtons de perdre du temps à débuguer !

Nastasia Saby nous a présenté son expérience de la TMA (tierce maintenance applicative), et ses quelques conseils pour faire face à la dette technique.

Bien entendu, user d’empathie envers les autres (mais aussi envers nos futurs nous) aide. L’amélioration continue, par de petits patchs, permet d’éviter le coût d’un grand refactoring tout en améliorant la qualité des méthodes dans lesquelles nous passons, tout en sachant que le refactoring complet est de toute façon souvent hors de portée, la faute à l’absence de tests.

En gros, les bugs et la TMA, c’est surtout de l’humain. Un message auquel nous adhèrons tout particulièrement. Un conseil pour rendre ça moins pénible tout de même : installer GifExceptionBundle !

Le Cache Component de Symfony

Nicolas Grekas a fini la seconde journée en nous présentant l’implémentation de PSR-6 embarquée dans Symfony. Cette PSR a fait couler beaucoup d’encre; en discussion depuis 2013, elle est enfin sortie mais sans l’aval de la team Doctrine, or la librairie de cache la plus utilisée dans l’éco-système PHP actuel est justement doctrine/cache. Ils ont par ailleurs publiquement critiqué PSR-6 avec des arguments par forcément pertinents et en conflit d’intérêt total, car effectivement, leur implémentation n’est pas compatible. À cela s’ajoutent les récents départs et drama du PHP-FIG, PSR-6 est né dans la douleur. Cette spécification a été tellement longue à sortir que packagist contient aujourd’hui un certain nombre d’implémentation se disant PSR-6 mais étant basées sur des drafts obsolètes…

Quoi qu’il en soit, Symfony avait depuis longtemps besoin d’un composant de cache et c’est maintenant chose faite, avec une implémentation minimaliste mais efficace de la recommandation.

Retours d’expérience

Migration de Wallabag de raw PHP à Symfony

Jérémy Benoist et Nicolas Lœuillet nous ont présenté l’outil open-source de lecture asynchrone Wallabag (similaire à Pocket pour ceux qui connaissent), et surtout sa migration du code spaghetti vers le framework Symfony 3.

Ils rencontrent des difficultés propres à beaucoup d’outils clé en main open-source :

  • le bug tracker utilisé pour du support utilisateur ;
  • la diversité des configurations serveur à supporter ;
  • la définition d’une roadmap qui plaise à tout le monde ;
  • la réception de cette nouvelle version par les utilisateurs de longue date…

Maintenant, ils ont des outils de déploiement, de migration, un vrai CHANGELOG, et une roadmap.

Dans les nouvelles versions sont prévues l’arrivée du message queuing pour mieux paralléliser tous les traitements, une intégration Elasticsearch pour de la vraie recherche™ (Damien est sur le pont). De même, un SaaS, brandé Wallabag et non Framasoft est également au programme. Si vous cherchez un remplaçant à Pocket, ou un projet open-source auquel contribuer, lancez-vous…

Lancez-vous dans l’open source

Matthieu Napoli, contributeur et initiateur de quelques projets open source connus, nous a donné quelques conseils pour se lancer dans la création et la maintenance d’un projet open source.

L’initialisation du projet est une étape importante, et elle commence par mettre en place des tests, ils garantiront la qualité du projet que l’on souhaite développer. Il est également indispensable d’appliquer une licence au projet. En l’absence de licence, les droits d’auteurs s’appliquent et votre code source ne pourra pas être réutilisable légalement par la communauté.

Le choix du nom du projet détermine aussi une part de son succès, il doit être concis, inédit, et simple. La description du projet est aussi très importante, il s’agit de faire comprendre aux membres de la communauté en quelques mots l’intérêt du projet.

La documentation doit être irréprochable, afin que les issues du repository du projet ne se transforment pas en tickets de support. Pour faire connaitre le projet, Matthieu nous recommande d’utiliser Twitter pour la viralité, et Reddit pour le feedback critique. Enfin, il nous est promis un torrent d’amour des utilisateurs si le projet rencontre du succès, et des mentions Twitter pleines de love.

Le jeu vidéo à la rescousse du web

Après une belle introduction pleine de bon sens sur notre condition humaine, François s’est attaché à nous raconter l’histoire du Web en parallèle de l’histoire des jeux vidéo.

Les parallèles suivants peuvent être exposés :

  • les jeux vidéo 2D utilisent des sprites pour ne pas avoir à dessiner tout l’écran pour déplacer un personnage, nous utilisons l’Ajax ;
  • les jeux en réseaux sont passés d’architecture client à client vers du client à serveur et nous avons fait la même chose avec nos sites basés sur des API ;
  • les loop de rendu qui assurent un framerate constant séparent le calcul de l’affichage du calcul des états du jeu, et c’est ce que nous faisons avec React et le VirtualDOM.

Nous ne savons pas exactement quoi retenir de ses propos, si ce n’est qu’effectivement, il semblerait que le Web ait quelques années de retard sur le jeu vidéo. Le futur serait donc composé d’intelligence artificielle et de réalité virtuelle, sujet sur lequel nous vous proposerons probablement un article prochainement !

Être gentil avec sa production

Un titre qui cachait une conférence sur les feature flags par Olivier Dolbeau et Benjamin De Bernardi de BlaBlaCar.

L’exemple qui revient souvent lorsqu’on nous parle de feature flags est la possibilité de déployer des nouvelles fonctionnalités et de les tester en production. Mais nous avons bien aimé l’idée de les utiliser pour construire une version dégradée du site (en cas de passage télé par exemple).

La conférence détaillait l’implémentation (perfectible) de BlaBlaCar, basée sur la librairie qandidate/toggle et sur un storage Redis.

On notera la difficulté, déjà rencontrée par nos équipes, de tester du code utilisant des feature flags, et la combinatoire possible. Difficile de penser à toutes les combinaisons possibles et de nouveaux bugs peuvent être introduits à chaque changement de configuration.

Nous notons d’ailleurs qu’ils n’ont pas mis en place de log / diff des changements de valeurs, qui pourraient être corrélés à l’apparition de nouveaux bugs. Kudos par contre pour l’ajout du contexte dans les traces d’erreurs, qui permet ensuite de chercher quelles features étaient activées.

Worker et microservice

En route vers le multi-tâche !

Julien Bianchi nous a présenté ce qu’était le multi-tâche (différence entre code parallélisé et code concurrent) ainsi que les différents moyens à notre disposition pour le faire en PHP :

  • Workers : nécessite une infrastructure plus lourde ;
  • PThread : extension PHP ;
  • Sous processus : natif en PHP avec proc_open, stream_select ;
  • ReactPHP : une « vraie » run loop mais blocages possibles si un traitement prend du temps ;
  • Icicle : similaire à ReactPHP, avec une interface Awaitable. Fortement basé sur des générateurs, Icicle est à utiliser avec PHP 7+.

Julien nous a également montré une toute autre façon d’utiliser les générateurs (apparus avec PHP 5.5) : mettre en pause une fonction dans le but et ainsi permettre de faire du multi-tâche simplement. C’est sur cette idée que repose son projet async-generator (un ensemble de fonctions ré-implementées pour tirer parti des générateurs).

La tolérance d’erreur pour micro-service

Orientée micro-service mais applicable à tout type de logiciel, Samuel Roze nous a présenté sa librairie de gestion d’erreur pour PHP, ainsi que quelques outils qu’il utilise pour monitorer et assurer la reprise d’erreur.

Sa librairie Tolerance donc, permet de décorer du code et de définir un comportement en cas d’erreur :

  • réessayer 10 fois ;
  • retourner une réponse par défaut ;
  • rate-limiter l’appel…

Chez JoliCode, nous sommes très friands de microservices et nous avons notre propre tooling nous permettant d’améliorer et d’enrichir la gestion de nos services. Cette bibliothèque nous semble intéressante et d’une ergonomie agréable, nous allons investiguer. De plus, Samuel nous indique utiliser Kubernetes de Google sur une « petite » architecture de cinq serveurs. Nous allons certainement nous laisser tenter à tester ces prochains mois.

Pour conclure

Pour finir, nous pouvons vous parler de l’organisation, qui a une fois de plus fait un très bon boulot avec l’assistance de Clermont’ech. La soirée communautaire a été pleine d’échanges et d’opportunités (et de « Campus »), et les deux salles étaient bien équipées.

Pour les points négatifs, nous avons subi quelques impressions de « déjà vu ». Peut-être que nous allons trop souvent aux événements PHP mais certaines conférences avaient déjà été vues en live, et nous regrettons que la programmation des Forum PHP et du PHP Tour ne soient pas mieux corrélées (sans compter les meetups et autres événements Symfony). L’absence de lightning talk est aussi regrettable tant le format est rafraîchissant et permet des parler de sujets qui ne méritent pas 40min. Mais on salue les ateliers qui ont eu beaucoup de succès (Joël a eu l’occasion d’introduire Docker auprès de 15 personnes !).

A noter que les deux déjeuners nous ont rappelé un Forum PHP pas si ancien – on vous pardonne mais nous avons rarement vu un jambon-beurre aussi triste !

Nous serons bien sûr présents au Forum PHP, toujours en tant que sponsor bien entendu, la confiance reste et les événements AFUP sont pour nous la référence en France quand il s’agit de parler de PHP.

Clermont-Ferrand
blog comments powered by Disqus