Mes notes du ForumPHP 2014, 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 ForumPHP 2014 à Paris.

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.

Les slides de la quasi-totalité des conférences sont disponibles en ligne (sur joind.in ou ce gist) et les vidéos captées lors de l’événement vont peu à peu être diffusées par l’AFUP sur youtube.

Frameworks: A History of Violence

François ZANINOTTO – Résumé, Slides, Vidéo

Pour nous mettre dans l’ambiance dès le départ, François a rappelé que symfony, en 2006, c’était bien… Alors qu’en 2011, plus autant que ça : les besoins des applications web se sont complexifiés. En somme :

• En 2000, tout le monde voulait son framework : c’était une vraie maladie dans notre communauté ! En même temps, c’était un peu le moment de PHP 4, où personne n’utilisait autre chose que C++ ou JAVA. À ce moment là, un framework jouait un peu un rôle de cadriciel et d’ensemble de classes : PEAR était ce qui s’approchait le plus d’un framework PHP.
• 2005 : arrivée des design patterns : on arrête de ré-inventer la roue. L’open-source commence à monter.
• 2007 : PHP contre attaque, avec des logiciels (drupal, wikimedia, …), le début d’applications en PHP du type de celles qu’on développait auparavant avec d’autres technos (symfony et zend framework jouant), débuts d’Ajax (et prototype.js pour sa démocratisation)
• 2010 : les entreprises disent “oui” : injection de dépendances, meilleur niveau d’abstraction, y compris pour les frameworks. Amélioration de l’interopérabilité avec PSR-0, composer et l’autoloading qui permettent de prendre des morceaux ici et là. Les entreprises ont validé l’utilisation de PHP. Et c’est aussi le moment où le geek est devenu sexy.
• 2012 : l’arrivée du cloud change la donne de l’hébergement. Il faut répondre au quoi plus qu’au comment. Le gros du développement se fait sur mobile (Objective C ou JAVA) avec du typage fort. Apache / PHP / MySQL ne sont plus trop adaptés et les développeurs regardent ailleurs. Les frameworks ont souffert des manques du langage.
• 2017 : phpng, Hack et Zephyr ont apporté, entre autres, de l’asynchrone. L’innovation se fait sur d’autres langages qui ont une plus grande vitesse de développement. La logique est déportée côté navigateur.
• 2020 “aujourd’hui” : Go ou JS, micro-frameworks et services, plus d’approche full-stack.

En somme, les frameworks, c’est bien quand ils sont petits ! L’approche full-stack est utile seulement le temps que la communauté devienne mature – et quand une application grandit, il devient temps de découpler. Au final, le langage s’enrichit de primitives qui permettent de se passer des frameworks.

En même temps, les frameworks ne meurent jamais. Vu le nombre d’applications qui les utilisent, il faudra 10 ans pour qu’ils disparaissent et il faudra toujours des développeurs PHP comme il faut aujourd’hui des développeurs COBOL. Les frameworks subissent aussi la sélection naturelle : ils reprennent les idées des autres, s’affrontent (si un framework n’est plus adapté, il ne sera pas utilisé sur un nouveau projet). Dans cinq ans, nous n’utiliserons plus les frameworks actuels et le framework qui sera le plus utilisé dans cinq ans n’est pas encore né. Les frameworks innovent de façon incrémentale, avec des innovations de rupture qui mènent à un rythme de croisière plus rapide. Mais les frameworks les plus populaires sont ceux qui évoluent le moins vite, puisque les utilisateurs veulent garder la compatibilité !

Les frameworks sont là pour pallier les manques des langages… qui, au bout d’un moment, intègrent les fonctionnalités initialement proposées par ceux-ci. Par exemple, HTML 5 a intégré des points de jQuery. Cela dit, les frameworks un peu anciens se basent sur des vieilles versions du langage. Finalement, pourquoi ne pas développer en node, plutôt que de passer par ReactPHP ?

À prendre aussi en compte : les frameworks pro, avec une entreprise derrière, ont une forme de vendor lock-in. Même si la communauté intervient, il y a une entreprise, qui fait du support, de la formation. Et, finalement, la simplicité d’utilisation peur être contraire aux intérêts de l’éditeur.

En conclusion, le programme du parti de l’innovation :

• Le domaine d’abord. Arrêter de structurer le code en fonction d’un framework !
• Non au full-stack. Privilégier les micro-frameworks.
• Applications plurielles. Mélanger les langages et les frameworks, être à l’écoute.
• Repenser le temps. Apprendre plein de langages, passer un jour par mois pour se former. C’est le plein emploi, c’est le moment de négocier avec les patrons !

Mon avis : Commencer cette seconde journée par une conférence animée, un peu en mode discours politique, était parfait pour le réveil après l’apéro communautaire de la veille ! L’idée que les frameworks (en particulier full-stack) sont là pour pallier les manques du langage en attendant que celui-ci les rattrape est intéressante – même si le langage, comme les frameworks, va subir la logique du plus il est populaire moins il évolue vite pour éviter de casser la compatibilité.

Bringing Sculpin to Life

Beau SIMENSEN – Résumé, Slides, Vidéo

Pour cette conférence, Beau nous a raconté l’histoire de comment un projet open-source (Sculpin, un générateur de site statique) est né, from-scratch.

Tout est parti des beer & code Seattle, qui ont permi à Beau de rencontrer des membres de la communauté, de sortir de sa bulle. Cet événement avait besoin d’un site web, dont la première version a été mise en place sous Jekyll, rapidement suivie d’une question “est-ce qu’il existe pareil en PHP ?”.

Ensuite, pas mal de temps a été passé à recoder des trucs, y compris un peu comme une couche de framework (NIH), au lieu de bosser sur des applications en elles-mêmes. Utilisation de symfony2 et de composants prometteurs, PHP 5.3 et espaces de noms aidant pour l’organisation du code, malgré le \ qui a causé quelques hésitations quand à l’avenir avec PHP.

Après deux ou trois sites sous Jekyll mettant en évidence une expérience de développement pas top (Ruby et trucs bizarres des développeurs Ruby), essai d’Octopress et contributions sur Jekyll et Octopress – en appréciant l’idée que le code n’a pas besoin d’être exécuté pour chaque requête (vu que sites statiques).

Pour ce qui est de PHP, sur d’autres projets, utilisation de Silex (symfony ayant un peu trop d’overhead et demandant d’apprendre trop de choses) distribué en Phar, sans avoir à se soucier de dépendances. Puis écriture d’un vendor.sh pour récupérer les dépendances, rapidement remplacé par Composer, en notant que c’est l’avenir de PHP !

Finalement, avec un sentiment de meh sous Jekyll et Octopress (incluant des absences de réponses pendant longtemps sur des PR pour finalement les voir être closes), s’est posée la question de pourquoi ne pas faire un générateur de site statique en PHP ? (il en existait quelques uns, mais basés sur PEAR ou avec une architecture bizarre). Une fois passée la difficulté de trouver un nom, 1er commit sur Sculpin le 21/12/2011 : basé sur Composer et publiant des bibliothèques, utilisation de composant symfony, intégration de React pour disposer d’un serveur web intégré.

Au niveau de la communauté : rencontre de gens (y compris rencontre IRL de développeurs précédemment vus uniquement en ligne), participation à des hack-days… Pour aller jusqu’à déménager depuis le milieu de nulle part vers une zone plus propice aux rencontres. Ensuite, participation à des conférences (avec plein de rejets lors de la première soumission de sujets). Important aussi de parler du projet, malgré les réactions parfois peu encourageantes du type “tu refais juste un CMS, y’a pas de raison d’en parler”.

En conclusion, créer un projet open-source, ce n’est que le début ; après, il y a la maintenance ! Et quelques enseignements :

• Ré-inventer la roue, ce n’est pas toujours mal,
• La crainte du rejet par la communauté freine les choses ; beaucoup. Il est important d’essayer ce qui existe, mais il ne faut pas se sentir mal de refaire si l’existant n’est pas OK.
• Il faut trouver et connaître ses raisons pour justifier ce qu’on fait.
• Il est primordial de faire ce qui est fun pour nous ! Et de build what you can use.
• Communauté ! Parler ! En face, sur Twitter, sur IRC, …
• PHP est flexible. Voir par exemple React. Ce n’est pas parce qu’un autre langage fait bien quelque chose que PHP ne peut pas le faire.
• Et pour finir : faites les choses !

Mon avis : Je pensais, avant le Forum, que cette conférence présenterait Sculpin. Ayant discuté la veille au soir du sujet avec Beau, je n’ai finalement pas été surpris ni déçu de plutôt entendre l’histoire derrière le projet. Un retour intéressant pour ceux qui se demanderaient comment un projet open-source peut se lancer. La notion de crainte du rejet me semble également importante, dans une communauté où les retours et jugements sont parfois un peu brutaux et pas toujours très diplomates (sans compter qu’ils sont parfois exprimés sans que leurs auteurs n’aient toujours pris la peine de bien comprendre le sujet…)

VDM, DevOp malgré moi

Maxime VALETTE – Résumé, Vidéo

Maxime a commencé par se présenter, en indiquant qu’il avait débuté en BASIC à 7 ans, pour faire comme papa, à grand coups de RTFM, avant d’obtenir son premier boulot chez Team AAA après avoir trouvé une faille dans leur site.

VDM est né un peu par hasard, sous la forme d’un blog perso – et ses deux utilisateurs recevaient occasionnellement des mails de gens qui voulaient ajouter leurs histoires, ce qui a entraîné l’ajout d’un formulaire de soumission. Au bout de quelques temps, à 10k visites par jour et un passage dans TéléMatin, ça a été le début de la fin : le site est tombé. Ça a été l’occasion de le revoir un peu, de passer au design en deux colonnes qu’il a encore aujourd’hui… Et avec 3000 à 4000 VDM proposées par jour, les week-ends étaient passés à modérer.

Passage dans le Grand Journal ⇒ 185k visites/jour. Travail sur FML en parallèle ⇒ succès à l’américaine avec 1M visites/jour. Plus le livre en français, qui a fait 1M ventes. Avec 250k visites de plus toutes les semaines, la question qui se pose rapidement est “comment gérer ça sans que ça s’écroule” – et la réponse “comme on peut !”

En termes système, hébergement chez OVH (rapide pour obtenir de nouvelle machines – et on prend ce qu’on sait faire), avec un round-robin DNS et du cache. Ajout ensuite de nouveaux serveurs Web et DB (réplication) et NFS et DNS pour arriver jusqu’à 7 serveurs MySQL. Puis mise en place d’un CDN, surtout pour les US (puisque les serveurs sont en France). Pour le monitoring, ça a commencé par des scripts qui pingaient pour voir si tout était up et qui téléphonaient à Maxime en cas de problème.

Au niveau du code, beaucoup de legacy en programmation procédurale, plusieurs années sont passées avant de basculer de mysql_*() vers PDO. L’internationalisation, au début, n’avait pas été prévue et le site était copié en entier pour chaque traduction. Le déploiement s’est pendant un bon moment fait par webdrive, avec montage de disque réseau et édition comme ça (ce qui entraînait des disparitions de fichiers, des fichiers écrits à moitié, …). Et le framework utilisé était l’adrénaline ! Aux moments avec un peu moins de rush, quelques améliorations ont été apportées, comme passer par des fichiers de langue ou un routeur PHP.

Finalement, une série d’évolutions ont été apportées, dont, notamment :

• Passage à Git et mise en place d’un environnement de staging.
• Apparition de code objet
• MySQL en master / slave (au lieu de réplication circulaire).
• Mais aussi : HAProxy, Heartbeat, Nagios, statsd, Sentry, utilisation de nginx pour le plus gros des requêtes, Redis au lieu de memcached pour les caches (x2 sur les perfs), CDN chez OVH

Aujourd’hui, les différents sites, cumulés, en sont à 3M visites/jour et 20,000 requêtes MySQL par seconde.

En conclusion, quelques points :

• Du bon code rapporte de l’argent et tient la charge : il s’agit d’un équilibre entre les deux.
• Un bon devops équilibre ses tâches et reste pragmatique.
• Un bon entrepreneur voit le futur.
• Est-ce qu’une refactorisation globale du code est prévue pour l’avenir ? Il est probable que ce ne soit jamais fait, pas besoin.

Mon avis : J’ai beaucoup aimé l’approche très terre-à-terre on fait avec les moyens du bord, qui reflète plutôt bien l’histoire de PHP, ainsi que l’idée que le bon code représente un équilibre – et pas du code parfait !

An introduction to the Laravel Framework for PHP.

Dayle REES – Résumé, Slides, Vidéo

En 2011, Dayle a commencé par utiliser Code Igniter, à l’intégrer sur de petits projets, ainsi qu’à y contribuer. Il a ensuite basculé sur Laravel 2.x, pour ses aspects clean, simple, qui changeaient de beaucoup d’existant en PHP. En parallèle, implication dans la communauté, sur IRC, ainsi qu’à travers l’écriture de tutoriaux.

Au moment de Laravel 3, il a commencé à participer plus activement au niveau du framework, malgré quelques problèmes au niveau du testing et l’extensibilité. Rappel : OSS = friendship.

La fin de la conférence à très rapidement évoqué quelques points intéressant de Laravel 4, initialement basé sur Silex, utilisant Composer et basé sur des composants. Cette version du framework effectue de la résolution automatique de composant, notamment par le biais de type-hinting – et on y retrouve bien sûr toute une série de fonctionnalités classiques existant dans d’autres frameworks.

Mon avis : J’espèrais avoir un aperçu technique de Laravel, qui a pas mal de succès aux US et UK et que je n’ai pas pris le temps de découvrir par moi-même… Mais trop de temps a été consacré à l’introduction de la conférence, pour ne finalement passer que beaucoup trop rapidement sur le framework.

Design how your objects talk to each other through mocking

Konstantin KUDRYASHOV – Résumé, Slides, Vidéo

Konstantin a commencé sa présentation en soulignant que les tests que l’on utilise parfois comme exemples (comme tester le résultat d’une multiplication) sont souvent simples et pas forcément proches du monde réel : dans monde réel, il existe des interactions et des dépendances entre plusieurs composants. De plus, en général, on teste le résultat final et pas la façon dont on y est arrivé – en conséquence, que se passe-t-il si le comment impacte le design ?

On arrive donc à une question : est-ce que c’est le message qui est important ? Ou l’état ? Considérant que l’idée derrière la programmation objet est de cacher l’état autant que possible, ce qui compte, ce sont les échanges !

En fonction des besoins, on peut mettre en place plusieurs formes de test doubles (qui constituent des solutions permettant d’isoler des choses – et même s’ils rendent souvent plus rapide l’exécution des tests, ce n’est absolument pas leur but premier) :

• Dummy : uniquement pour passer les type-hints, ne fait rien.
• Stub : une méthode avec des paramètres retourne une résultat pré-défini. Pas de vérification sur le fait qu’elle soit ou non appelée.
• Spy : on vérifie que l’appel ait effectivement été effectué.
• Mock : forme de Spy avec un délai.
• Fake : implémentation réelle de la classe.

Souvent, les développeurs ne mettent pas en place de test unitaire sur les contrôleurs. L’exemple de test sur contrôleur présenté à ce moment montre qu’on a plus de 10 objets différents utilisés par celui-ci, ce qui n’est pas idéal pour le Single Responsibility Principle. En ré-écrivant le test, on arrive à deux fois moins de classes et de lignes de code – en enlevant la complexité qui se trouvait dans le contrôleur et en la déplaçant vers le Model, le Repository, …

Viennent ensuite une série de principes :

• Open-Closed Principle : typiquement, sur un test de panier, lorsqu’on ajoute un mode de paiement, on ne devrait pas avoir à modifier le code du panier.
• Liskov substitution principle : on veut pouvoir remplacer une classe par une autre et que ça marche (passer par des classes différente avec un adapteur pour les utiliser).
• Interface segregation principle
• Dependency injection principle

Il est important de ne pas mocker de composants dont on n’est pas propriétaire. Et exposer les communications !

Et quelques notes pour terminer :

• Ne pas utiliser d’outil de mock cassé : passer par Mockery ou Prophecy
• Ne pas faker de Value Object ou de Collection : les utiliser. Pareil pour les parties d’objets, en les découplant.
• Ne pas utiliser de mock pour isoler.
• Le TDD centré sur l’état n’est pas la seule possibilité.
• Les messages sont plus importants que l’état : ils définissent le comportement des objets. Et en se focalisant sur les échanges de messages, on expose des problèmes de messages.

Mon avis : L’idée de tester les messages et les échanges plus que les états est intéressante (surtout considérant qu’on fait bien trop souvent l’inverse) et demande d’être creusée – je regarderai probablement quelques passages de la vidéo un de ces jours pour me remettre dedans (je commençais à penser à la table ronde que j’allais animer même pas deux heures après et, conséquence, j’ai décroché plusieurs fois pendant cette conférence :-( ).

Cohabitation de PHP et Node au Monde, pourquoi et comment

Olivier GRANGE-LABAT – Résumé, Slides, Vidéo

Olivier a commencé par rappeler que nodejs permet de développer en Javascript côté serveur, que ce soit pour du scripting (bower, grunt, …) ou pour mettre en place des serveurs (statsd, …).

Deux besoins chez Le Monde :

• Refonte des alertes sur applications mobiles (+ de 1M de devices), qui étaient en PHP avec quelques problèmes de performances – et puisque les média veulent tous être le 1er sur les alertes, un rework était nécessaire.
• Refonte du CMS interne (utilisé par les journalistes pour écrire leurs articles) : les outils éditoriaux existant étaient vétustes, il fallait rapprocher le print et le web (avec un outil unique pour toute la rédaction) et les performances étaient à améliorer ⇒ architecture SPA, angular, postgresql, PR pour tout.

Pourquoi nodejs sur le projet CMS ?

• Même paradigme côté client et serveur
• Temps réel → notifications, collaboration, chat, …
• Bien pour fabriquer une API
• Compétences existantes en interne + techno sympa qui aide à recruter.

Avantages :

• Javascript partout, y compris pour le déploiement
• Partage de quelques bibliothèques entre client et serveur (quelques unes – pas tant que ça non plus)
• npm = excellent packager
• modules simples, qui ne font qu’une seule chose
• stabilité
• déploiement très simple : nvm + npm (avec déploiement de node qui se fait automatiquement)
• documentation complète et à jour

Quelques aspects moins sympa :

• Asynchrone = difficile à appréhender (même avec async pour éviter le callback-hell)
• Approche serveur plutôt que requête qui impose de redémarrer pendant les livraisons ou de gérer les exceptions pour éviter que l’application ne s’arrête
• superviser la mémoire (risques de fuites)
• écosystème immature (même si ça s’améliore)
• problématiques bas niveau (fork)

Prochaine question qui va se poser : quid de la prochaine version du site web ? En SPA ? Problématiques de performances sur les navigateurs mobiles ? Ou sous forme d’applications ? Peut-être une API d’accès aux données en node avec du PHP et des web components. Dans tous les cas, pivoter autour des données pour mettre en place une nouvelle stack.

En conclusion : on est développeur avant d’être développeur PHP : les technos ne sont que des outils et il faut apprendre d’autres technos.

Mon avis : Un rapide tour sur les points que node aborde différemment que PHP et une illustration du fait qu’un langage n’est pas la solution à tous les problèmes, mais juste un outil. J’ai toutefois plus eu le sentiment d’une bascule d’une techno vers une autre que d’une réelle cohabitation ?

Table ronde “État des lieux et avenir de PHP”

Pierre JOYE, Julien PAULI et Jordi BOGGIANO – Résumé, Vidéo

Étant animateur de cette table ronde, je n’ai pas été en mesure de prendre de note.

Jordi, Julien et Pierre ont eut l’occasion de répondre à plusieurs questions posées par des membres du public, sur l’état de PHP aujourd’hui, sur la communauté au sens large et ses besoins, ainsi que sur les possibles évolutions du langage et la manière dont celles-ci pourraient arriver.

Mon avis : C’était la première table ronde que j’animais, j’étais assez curieux de voir comment ça allait se passer – et j’ai le sentiment que nous avons réussi à répondre à pas mal d’interrogations. 45 minutes à trois intervenants, par contre, ça passe vraiment vite !

Pour conclure, ces deux jours de Forum PHP ont été pour moi l’occasion d’assister à une petite 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, ainsi que d’animer ma première 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 !