Mes notes du ForumPHP 2015, jour 2

J’ai posté il y a quelques jours les notes que j’ai prises lors des conférences auxquelles j’ai assisté pendant le premier jour du Forum PHP 2015 à Paris.

Après une soirée communautaire qui m’a permis de discuter avec pas mal de monde que je ne vois que trop rarement et dans la suite de ce premier article, voici, encore dans l’ordre chronologique, mes notes du second jour. Notez encore une fois qu’il s’agit de mes notes, soumises à mon interprétation de chaque intervention.

A deep dive into image manipulations with Glide

Jonathan Reinink – Résumé, Slides, Vidéo

Pour attaquer cette seconde journée, Jonathan est venu parler de Glide, une bibliothèque de manipulation d’images, dont les principes sont : calculs à la demande et API simple par-dessus HTTP. Elle permet toutes les manipulations classiques (largeur, hauteur, bordures, watermarking, flou, …) en utilisant en-dessous gd ou imagemagick.

Exemple d’URL : http://images.example.com/products/123456.jpg?w=300&h=400&fit=crop

Dans le principe : on enregistre seulement l’image de base et pas les manipulations (par exemple : les différentes miniatures qu’on peut vouloir afficher sur notre site) et on requête les différentes versions à la volée. Stockage sur n’importe quel système (via Flysystem pour abstraire le FS ⇒ stockage en local, sur S3, …).

Au niveau fonctionnalités, on retrouve un peu tout ce qu’on pourrait attendre : presets (utilisables comme base pour plusieurs manipulations sans avoir à tout répéter), defaults (par exemple, pour toujours inclure le même watermark), taille maximale d’image (plus une sécurité qu’autre chose), … Possibilité de signer les URLs avec une clef secrête, pour éviter que n’importe qui ne puisse générer des millions d’URLs différentes (devrait toujours être utilisé, en production !). Possibilité d’activer ou non du cache (pour éventuellement laisser Varnish faire) ou de pré-traiter des images (avec une queue, par exemple).

Mon avis : l’idée est sympa et l’API par URL peut faciliter le branchement. L’asbtraction du système de stockage un plus important. J’ai passé une partie de la conf à me dire que ça répondait exactement à un besoin que j’ai au bureau ^^

ZF3, le futur de PHP

Sophie Beaupuis – Résumé, Vidéo

Sophie a commencé par indiquer que ZF3 était une sorte de ZF2 nouvelle version, s’inscrivant dans la continuité de la version précédente, avec comme principaux objectifs : séparation en plusieurs composants, performances, facilité d’utilisation (améliorée par rapport à ZF2) et centrage sur PSR-7 et Middlewares.

Depuis ZF2.5 : il ne s’agit plus d’un framework monolithique. Le framework est un méta-paquet qui référence différentes versions des composants (chaque composant a son repository, son propre cycle de vie). En dehors de ça, pas grand chose n’a changé par rapport à ZF2, d’une certaine façon :

• Gestionnaire de services : 4x plus rapide, compatible container-interop (interface commune à tous les conteneurs d’injection), nouvelle interface qui permet d’utiliser une factory commune pour les différents services.
• Gestionnaire d’événements : plus rapide, plusieurs méthodes trigger() spécifiques.
• MVC : modèle ne change pas, vue non plus. Ajout de “middlewares” : on peut remplacer un controlleur par un middleware ; ce sont des callables, compatibles PSR-7. zend-diactoros : implémentation de PSR-7 dans ZF. zend-strategility : permet d’implémenter de petites applications.
• Zend expressive : de quoi faire de vraies applications : routeur, container d’injection, middlewares (cf zend-strategility), micro-framework, orientation interopérabilité.

Mon avis : un peu comme pour la présenation sf3 d’hier, pas de révolution ; bon, ça fait des années que je n’ai pas bossé avec ZF, j’avoue.

Deploying PHP 7

Rasmus Lerdorf – Résumé, Slides, Vidéo

Pour commencer, Rasmus a fait un tour d’horizon des principales nouveautés de PHP 7 : grosses améliorations de performances (avec illustration sur de nombreux logiciels OSS, en comparant PHP 5, PHP 7 et HHVM), cache d’opcodes en fichiers (utilisable depuis la CLI), AST permettant de construire des outils d’analyse, exceptions pour certaines erreurs précédemment fatales, …

Parmi les points qui pourraient faire mal lors d’une migration PHP 5 → 7 (conseil : lisez la doc !) : parsing de gauche à droite avec la syntaxe uniforme pour les variables (aide : outil phan, tests unitaires) même si peu de problèmes dans l’ensemble, suppression du flag /e pour preg_replace() et parse errors sur des valeurs litérales invalides en octal (qui ont en fait permis d’identifier des bugs ;-) ).

En parlant de phan : utilise l’AST de PHP 7. Option -b pour avertir si détecte des bc-breaks PHP 5 → 7. Quelques faux positifs, mais quand même utile dans l’ensemble, puisque permet de détecter des problèmes avant l’exécution.

Pour ce qui est des déploiements : il est important qu’ils soient atomiques, sans impact sur les performances (donc, pas de redémarrage de serveur, pas de vidage de cache). Basculer un lien symbolique, ça casse les requêtes en cours (qui se retrouvent à cheval sur de l’ancien et sur du nouveau code) ; autrement dit, n’utilisez pas capistrano ! Il faut pouvoir servir deux versions du site en même temps et, donc, basculer le document root de façon à ce que les requêtes commencées sur un docroot s’y terminent. Le docroot est donc la cible du lien symbolique, tout doit être relatif à ce documentroot et les assets doivent être versionnés. Pour nginx : fastcgi_param DOCUMENT_ROOT $realpath_root.

Pour finir : testez PHP 7 et vos applications ! Il existe des vagrant et docker tout prêts ;-)

Mon avis : encore une fois : PHP 7, nouvelles fonctionnalités, gros gain de perfs (mais rien de bien nouveau pour moi qui connaissais pas mal le sujet ^^). Les quelques mots sur le déploiement, en fin de présentation, étaient intéressants (qui a dit que j’utilisais capistrano au bureau ?) et méritent de fouiller un peu plus.

Magento 2 in Today’s PHP Universe

Gabriel Somoza – Résumé, Vidéo

Gabriel a ensuite fait un tour d’horizon des principales différences entre Magento 1 et Magento 2, d’un point de vue technique :

• Normes de codage : respect des PSR habituelles (0 et 4, 1 et 2, 3) + hook pre-commit phpcs. Les JS et CSS sont dans leurs propres fichiers, le HTML uniquement dans les .phtml. Utilisation de less. Semantic HTML. Reste à voir si cela sera suivi par les extensions.
• Contribuer : créer un compte sur magento connect, fork + pull. Definition of done écrite. Cadre autour des bc-breaks.
• Utilisation de composer. Dépendances entre modules de Magento. Unités cohérentes et semver. Toutefois, certains modules sont requis par à peu près tous les autres et ne sont pas extractibles (genre le module Sales ; mais d’un autre côté, pour une plate-forme d’ecommerce…)
• Framework : ce n’est plus (directement) Zend Framework. Mise en place d’un Framework Magento, qui dépend (aujourd’hui) de ZF1 (json, acl, …) ou de ZF2 (stdlib, http, …). Les classes de ces frameworks sont encapsulées par des classes Mage ⇒ on n’utilise pas ZF directement ⇒ permettra, en-dessous, de changer des briques !
• Injection de dépendances + services : utilisation d’interfaces → les modules dépendent de ces interfaces et pas des implémentations (qui arrivent via l’injecteur de dépendances)
• Pour ce qui est du front : les layouts XML sont conservés (et permettent toujours de faire plein de choses), CSS / less, grunt, require.js, jquery, jquery mobile, …
• Et tests automatisés, à la fois unitaires (en particulier sur le framework) et fonctionnels (selenium, notamment sur le front) ⇒ bien pour de l’intégration continue et le développement de modules. Tout n’est pas couvert, mais pas si mal comparativement à d’autres solutions ecommerce…

Magento 2 : publié il y a une semaine. Migration 1 → 2, bon, pas facile. Et le gros des extensions vont être à re-développer from scratch (mais nouvelles extensions pourraient être bien mieux conçues, si les développeurs suivent le framework, les guidelines, les tests et tout !).

Mon avis : j’ai eu plusieurs fois l’occasion de bosser sur des projets Magento 1.x ; j’étais curieux de voir quels choix avaient été fait pour Magento 2. Dans l’ensemble, je suis plutôt content, ça a l’air bien parti ! Reste à voir comment ça sera mis en application, maintenant, tant au niveau de l’écosystème de plugins qu’au niveau des prestataires qui se vendront comme experts magento !

Un éléphant dans le monde des licornes

Matthieu Moquet – Résumé, Slides, Vidéo

Chez Blablacar, après être basé sur un CMS aux environs de 2005, puis sur du code fait maison sur 2008-2011 (avec des trucs moches, de la dette technique, des variables globales, des singletons et 0 test), est venue l’idée en 2011-2012 de repartir from scratch. Comme Matthieu l’a souligné, cela signifie des développeurs contents et motivés, mais une bonne dose de risque – même si ce fût un bon choix, sur le long terme.

Approche “les plus rapides mangent les plus lents” ⇒ nécessité de déploiement rapide du code en production, avec une dizaine de mises en prod par jour et n’importe qui dans l’équipe peut déployer (responsabilise tout le monde). Workflow classique avec une branche par feature puis merge et deploy. Feature flags pour tout ⇒ on peut pousser du code et ne l’activer que pour une partie des utilisateurs ; activation partielle pour tester / valider les impacts. En complément : mécanisme de MAJ des traductions à chaud, en prod, sans avoir besoin d’un développeur !

Viennent ensuite quelques notes sur différents sujets :

• ORM : pratique au premier abord, des cordes pour gérer plein de choses, cool pour bootstrapper. Mais entités un peu partout dans l’application et plein de relactions dans tous les sens ⇒ compliqué pour sharder ! Et les validations s’appliquent partout, y compris sur des pays où il n’y a pas certains champs dans les formulaires, pas top.
• Bundles : en fait, trop couplés au framework. Il vaut mieux développer une application indépendante du framework et, seulement ensuite, utiliser celui-ci comme glue. Typiquement : ne pas utiliser FOSUserBundle, qui couple au framework et à Doctrine.
• Events : permet de découpler une application. Mais : utilisation d’événements Doctrine (pre flush et tout ça) est une mauvaise idée : ça devient vite le bordel et on ne sait plus qui écoute quoi ⇒ voir event sourcing, placer les événements au coeur et pas comme bouées.
• Tests : fonctionnels avec phpunit = trop de code de tests fonctionnels, long, maintenance compliquée, même avec des helpers. Plutôt regarder Behat pour tester des comportements.

Pour finir : application monolithique fortement couplée = pose des problèmes. A la place, mise en place d’une gateway qui permet d’isoler chaque brique métier des autres, avec interdiction de jointure entre types d’entités. Permet de remplacer facilement une brique par une autre. Exemple pour des messages : API → JAVA → Cassandra (et pas de PHP).

Dernier point : réplication / sharding dans le monde entier ; bascule en cours sur une architecture à base de containers (coreos), facilitée par le traval de découplage.

Mon avis : comme pas mal de monde, je n’ai pas, en ce moment, les mêmes problématiques que BlablaCar (même si ça me fait un peu envie des fois ^^). Mais certaines idées recoupent certains sujets de réflexion dont je discute parfois (genre ne pas dépendre des events de l’ORM).

Suivre ses séries avec des API

Maxime Valette – Résumé, Vidéo

Maxime a commencé par présenter rapidement betaseries. En 2006-2007, il y avait plein de séries TV, pas que sur TF1, et pourtant, pas de planning d’épisodes à regarder. Le site a commencé avec un planning global pour tout le monde, puis ajout d’une notion de compte utilisateur. Gratuit, pas de publicité, 4 ou 5 modérateurs. Aujourd’hui : 700k membres, 12k séries, 250k sous-titres, 150 applicatios actives, 2 API.

Au départ : une seule source de données (il n’y avait pas grand chose, en 2007) : epguides.com ; pas d’API, mais page HTML simple ⇒ preg_match() \o/. Pour les sous-titres, seriessub.com avec obtention via file_get_contents(). Ca a donné naissance à l’API v1 de betaseries, en uniformisant les données récupérées. 2008 : beaucop de sites, pas d’API, obligé de scrapper, une seule source par type de données, évolution nécessaire mais pas urgente.

Evolution en 2009-2011 : commence à se baser sur plusieurs sources et sur les enrichissements de la communauté. Migration entre sources de données, manuelle. Ajout d’autres sources (y compris certaines où “l’API” fournit l’URL d’un fichier .zip contenant l’ensemble des données…) ⇒ correspondances manuelles entre les noms des séries, selon les sites (pas toujours d’identifiant commun aux différentes sources !). API v2 : oauth obligatoire, URLs propres, JSON et XML, code OOP.

Arrivée en 2015 : 23 sources utilisées (données, sous-titres, internes (push, mails), boutiques (affiliation), synchronisation, réseaux socieux, …) ; avec des API + ou - faciles à utiliser et + ou - synchronisables.

• Parfois, de bonnes surprises : API pensées ouverture, flexibles sur les données, utilisant des identifiants de référence, permettant des MAJ facilités (Last-modified, since), fournissant des bibliothèques PHP.
• Souvent, des mauvaises surprises : pas de versionning d’API, MAJ imprévisibles, ou pas d’API du tout…
• Et coût de maintenance : les API aussi, il faut les maintenir ; nagios pour tester les APIs ; outils accessibles via une interface d’administration pour permettre aux équipes d’intervenir.

En conclusion :

• Bien : valeur ajoutée pas faisable sans API, facilite le travail des équipes, nouveaux moyens de monétisation.
• Moins bien : pas deux API qui aient le même comportement, on fait confiance aveugle aux sources, beaucoup de maintenance imprévue, difficile de savoir du 1er coup si ce qu’on utilise est la bonne API.
• Attention : penser aux imprévus (cache systématique, asynchrone pour tout, monitoring automatisé + humain, prévoir des maintenances). Respecter les sources (API, oui, mais on ne peut pas tout faire avec ⇒ lire les conditions d’utilisation ! Appeler avec parcimonie, donner du sens aux sources, redistribuer la valeur ajoutée (via d’autres APIs, RSS, iCal, …), partager l’XP).

Mon avis : j’aime beaucoup l’approche très pragmatique qui consiste à prendre ce qui apporte de l’information, quitte à faire du code pas génial, mais pour arriver à quelque chose qui marche. La conclusion, l’idée que les API ne sont pas magiques et qu’il faut du travail conséquent de maintenance, tout en n’oubliant pas que ce sont des services externes qu’il ne faut pas bourriner sauvagement, était également appréciable à écouter !

What We Talk About When We Talk About Distributed Systems

Alvaro Videla – Résumé, Vidéo

Pour introduire sa conférence, Alvaro a noté qu’il était content qu’on ne fasse pas que du PHP à une conférence PHP ;-)

Il a ensuite attaqué sur son sujet : les systèmes distribués. Un sujet touffu, sur lequel il y a de nombreux papiers de recherche à lire, pour lequel l’histoire a de l’importance et où le terme de computer science a encore du sens !

Le sujet est complexe et vaste ; et mieux que mes notes qui sont assez brouillon (ça allait vite, sur un sujet que je ne connaissais quasiment pas ; je me suis plus concentré sur le suivi de la présentation que sur la prise de notes), je vous conseille de parcourir cet article, où Alvaro a retranscrit les idées présentées lors de sa conférence.

Mon avis : j’en ai retenu que c’est compliqué ^^. Un peu rapide comme introduction, bien que le sujet soit extrêmement intéressant (et qu’il nous concerne quasiment tous les jours : il suffit de penser au nombre de fois où on envoie des requêtes sur le réseau… Et quand on ne reçoit pas de résultat, on ne sait pas si c’est la requête qui s’est perdue, ou la réponse !)

Table ronde

Pascal MARTIN, Rasmus Lerdorf, Zeev Suraski, Remi Collet et Julien Pauli – Résumé, Vidéo

Pour terminer cette seconde journée de conférence, j’ai eu la chance d’animer une table ronde qui a permis aux membres du public de poser les dernières questions qu’ils pouvaient encore avoir à l’esprit.

Je n’ai malheureusement pas pu prendre de note, j’étais un peu occupé, mais n’hésitez pas à suivre la vidéo, qui a été mise en ligne il y a quelques jours !

Mon avis : ma seconde table ronde \o/. Comme l’an dernier, j’ai bien aimé ce format avec des questions posées par le public et j’ai le sentiment qu’il a permis de répondre à des interrogations encore en suspend après deux jours de conférences. Si on me propose de recommencer l’année prochaine, par contre, je partirai plutôt sur 3/4 d’heure, pour éviter les quelques minutes de mou à la fin de l’heure.

Keynote de clôture

Maxime Teneur – Résumé, Vidéo

Après deux jours d’évenement et un super boulot d’organisation, voici venu le moment de se dire au revoir… Et d’annoncer le prochain PHP Tour, qui aura lieu à Clermont-Ferrand les 23 et 24 mai 2016 !

Pour conclure, ces deux jours de Forum PHP ont été pour moi l’occasion d’assister à une bonne quinzaine de conférences, d’avoir le plaisir de rencontrer ou de revoir pas mal de monde, de discuter de PHP, de sa communauté, de différents projets, ou même de mon livre “Développer une Extension PHP” ou du travail en cours sur le livre “PHP 7 avancé”, ainsi que d’animer ma seconde table ronde – deux journées bien chargées, donc !

Encore une fois, merci à l’AFUP, à tous les membres de l’orga, aux conférenciers et au public – et à l’année prochaine ! Ou, peut-être, à dans quelques mois ;-)