15 posts taggués « afup »

Par Pascal MARTIN le mercredi 12 novembre 2014

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 ZANINOTTORé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 SIMENSENRé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 VALETTERé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 REESRé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 KUDRYASHOVRé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-LABATRé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 BOGGIANORé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 !

Par Pascal MARTIN le jeudi 6 novembre 2014 8 commentaires

Le ForumPHP organisé par l’AFUP a cette année eu lieu les 23 et 24 octobre, au Beffroi de Montrouge à Paris.

Comme pour le PHPTour qui avait eu lieu en juin à Lyon, ces deux jours ont été l’occasion de revoir plein de monde (cela faisait trois ans que je ne m’étais pas rendu à un événement AFUP à Paris !), ainsi que de rencontrer plusieurs personnes avec qui j’échangeais déjà depuis un certain via Internet sans jamais les avoir vues IRL, ou d’assister à une quinzaine de conférences.

Je n’ai cette fois pas été retenu pour présenter de conférence basée sur le travail que j’effectue chez TEA, The Ebook Alternative, mais j’ai eu la chance de pouvoir animer une table ronde intitulée « État des lieux et avenir de PHP », à la fin du second jour de ce Forum.

J’ai tenté de prendre quelques notes lors de chaque conférence à laquelle j’ai assisté. Voici donc ci-dessous, dans l’ordre chronologique, celles du premier jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque conférence.

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.


La mesure, ce n’est pas que pour le devops.

Olivier Garcia et Patrick AllaertRésumé, Slides

En introduction de cette première conférence, Olivier et Patrick, qui sont en train de monter catchy.io, ont demandé qui dans la salle avait un projet de création d’entreprise : sur la vingtaine de réponses positives, il est probable qu’au moins la moitié se planteront. Avoir des métriques peut aider à piloter les directions prises.

Lean startup n’est pas une garantie que les choses vont marcher. Il faut savoir écouter les feedbacks :

  • certains sont à ignorer (Uber a ignoré ceux qui disaient que ça ne marcherait pas),
  • il faut se demander pourquoi les gens demandent un truc
  • et il est important de regarder les chiffres, d’analyser ce que font les utilisateur — et d’adapter en conséquence !

Lean Startup suit 4 principes : production par étapes “juste à temps”, offre adaptée à la demande, focalisation sur la production de valeur et amélioration continue. C’est assez proche de scrum, en ajoutant un côté commercial. Itération : hypothèses basées sur des données (A/B testing, par exemple) → expériences → amélioration ↻.

Pour ce qui est des mesures, les métriques doivent être “AAA” : Actionables (on peut en faire quelque chose), Auditables (la méthode doit être compréhensible et obtenir des chiffres doit être facile) et Accessibles (tous les développeurs y ont accès). Elles sont à l’opposé des métriques de vanité. Exemples : nombre de lignes de code vs ratio de code mort, nombre de followers sur twitter vs interactions avec ces followers, nombre de visiteurs vs nombre de visiteurs qui s’inscrivent, nombre d’utilisateurs vs nombre d’utilisateurs actifs au bout de six mois, …

Les métriques mesures “AARRR” : Aquisition (comment est-ce que les utilisateurs viennent), Activation (est-ce qu’ils s’enregistrent), Rétention (est-ce qu’ils reviennent / sont actifs), Referral (font-ils venir d’autres utilisateurs ? qui s’enregistrent ?) et Revenu (impact sur le CA).

Quelques outils de récolte de métriques :

  • Google Analytics, le plus connu : facile à mettre en place, dashboards standards. Il faut surveiller les événements, plus précis que les pages et valables pour les applications Ajax. Dashboards personnalisables (embed API) + extraction de tableaux via GA Query Explorer.
  • Statsd / Graphite, le plus en vogue en ce moment
  • Autres, souvent payant : Mixpanel, Pirate metrics, KISSmetrics, …

En résumé : le succès dépend d’un feedback mesurable. Lean startup et AARRR sont des pistes pour s’appuyer sur des métriques fiables.

Mon avis : Une bonne introduction aux métriques à mettre en place sur une application qui se lance (ou qui devraient être en place sur une application déjà lancée), en vue de guider son évolution. Vu qu’Olivier et Patrick sont en train de lancer leur boite, j’aimerais vraiment avoir un retour d’expérience, d’ici deux ou trois ans, sur quelles métriques ils ont mis en place, lesquelles leur ont apporté des informations utiles (et quelles étaient ces informations), ainsi que celles qui n’ont pas été utiles ou trop difficiles à interpréter.


Industrialisation des environnements de dev avec Puppet et Amazon

Nicolas SILBERMAN et Sébastien ANGELERésumé, Slides, Vidéo

Avec des changements de technos et la mise en place d’une nouvelle stack complexe (chez l’Express : 6 applications PHP, 15 bases de données MySQL ou Mongo, Redit, RabbitMQ et des applications découplées), il n’est pas facile d’installer celle-ci sur un environnement de démonstration ou de développement. Cela mène à des commentaires du type “chez moi ça marche”, “je ne regarde jamais cette partie du site”, “tu voulais tester ça aussi ?” ou “ça marche en prod”, qui ne sont pas rassurants !

Installer uniquement une partie de la stack / de l’infra ne fonctionne pas, principalement car il y a trop de dépendances entre les composants. Effectuer une installation manuelle identique à la plate-forme de production ne fonctionne pas non plus : cela entraîne des oublis et l’obtention de plate-formes ne fonctionnant qu’à moitié.

Pré-requis pour passer à une mise en place de plate-forme automatisée : versionner le code, avoir de l’expérience en déploiement continu et des compétences devops — en se rappellant que DevOps == “Travailler ensemble pour produire de la valeur pour l’entreprise”.

Mise en place d’une infra on-demand chez AWS (plus de liberté d’expérimenter, permet de lancer des instances de démo au besoin et de les couper quand elles ne sont plus utiles). Quelques pièges : grand nombre d’offre (besoin de conseil), le prix est variable selon les jours (puisque dépend des instances lancées) complexifie la maîtrise des budgets, veiller à ne pas laisser tourner de machine qui ne fasse rien !

Pour la gestion de configuration : historiquement bash et cfengine, puis bascule vers Puppet (car expérience sur des projets plus petits, pour des environnements de développement et volonté de lancer rapidement le projet). Utilisation de Foreman pour piloter, dès le départ (attention : fichiers de configuration non compatibles avec Puppet). Mais arbre de dépendances profond et complexe ⇒ difficile de trouver l’origine des problèmes.

Finalement, passage à Chef : bien documenté chez AWS, hébergeur utilise Chef en production et recettes plus simples à écrire. Jouer les recettes sur des AMI de base était long, donc utilisation de packer.io pour construire des AMI personnalisées incluant les logiciels les plus utilisés (nginx, mysql, …) ⇒ plus rapide pour mettre en place une instance. Utilisation de kitchen pour tests unitaires et fonctionnels sur les recettes (“infrastructure as code”).

Pour ce qui est des données :

  • Remontée des DB depuis la production, tous les jours ; plus de 30h au total pour tout remonter, ce qui est un peu long ⇒ travail d’arbitrage sur la fraîcheur des données, ainsi qu’optimisations sur la structure (découpage en bases plus petites, en séparant les données qui ne sont que rarement modifiées).
  • Pour les fichiers (400GB d’images), warmup avec un HDD, puis rsync régulier depuis la production.

Quelques outils développés en interne : tableau de bord des instances, formulaire qui lance des instances et déploie les logiciels dessus ⇒ quelques clics, pas de manipulation à la main sur les interfaces d’AWS. Utilisation des API AWS, faciles à intégrer à symfony2.

Bilan final : investissement lourd au départ, en mode projet dédié. Reste à généraliser le principe au lancement d’environnements de développement (peut-être ?). Difficultés pour les prévisions budgétaires.

Mon avis : Ayant pas mal bossé sur la mise en place d’environnement de devs (Cf « Notre environnement de développement n’est plus un bizutage ! » au PHPTour en juin) et n’étant pas encore allé jusqu’au provisionnement d’instances de démo/recette à la demande, je suis reparti de cette conférence avec quelques idées : ce que nous avons aujourd’hui sur nos postes de développement pourrait sans trop de mal être étendu pour démo/recette.


PHP dans les distributions RPM

Remi COLLETRésumé, Slides

Remi a commencé par rappeler qu’il maintient un dépôt de RPM (CentOS/RHEL/Fedora) depuis 2005, qu’il est packageur PHP pour fedora, qu’il fait pas mal de QA sur des extensions PECL et qu’il est contributeur à PHP depuis 2012.

Les distributions entreprise ont souvent une image de trucs complétements obsolètes ; ce qui correspond, cela dit, à leur objectif de stabilité (y compris au niveau des APIs et ABIs), avec un support supérieur à 10 ans (qui répond aux attentes de certaines entreprises — même si pas forcément à celles des développeurs). C’est encore plus vrai maintenant, où un serveur virtuel peut avoir une durée de vie illimitée, alors qu’un serveur physique ne durait généralement qu’environ cinq ans.

Quelques versions de RHEL, les dates de support et les versions de PHP correspondantes :

  • RHEL 4, support → 2012 : PHP 4.3
  • RHEL 5, support → 2017 : PHP 5.1.6
  • RHEL 6, support → 2020 : PHP 5.3.3
  • RHEL 7, support → 2024 : PHP 5.4.16

Note importante : les correctifs de sécurité sont backportés ! Cela signifie que le PHP 5.3.3 de Redhat n’est pas le 5.3.3 officiel : il intègre 150 à 200 correctifs supplémentaires. Tous les CVE sont fixés, y compris ceux qui ont été fixés en 5.5 ou 5.6 par php.net.

Fedora, à l’inverse de RHEL, essaye plutôt d’utiliser les dernières versions, avec un cycle de vie court (1 an). L’approche est de travailler avec les projets upstream et de remonter des patchs. En complément, Fedora est la distribution upstream de RHEL.

Dans les cas où la version de PHP fournie est trop vieille pour des applications modernes (sur RHEL notamment) ou trop récente pour certaines applications (sur Fedora notamment), on peut se rabattre sur : mise à jour / build à la main / repositories tiers (pas idéal pour une distribution avec du support !) / docker / SCL.

Les Software Collections (ou SCL) permettent d’installer en parallèle plusieurs versions d’un logiciel, sans toucher au système de base (l’installation est effectuée à côté, typiquement dans /opt/<vendor>/<sclname>/), avec mise en place d’un lanceur pour activer la collection. Avec les SCL, RHEL 6 dispose de PHP 5.3 et 5.4 et 5.5, avec des paquets officiels ! Les SCL sont pour l’instant disponibles sur RHEL et devraient arriver sur Fedora dans le futur.

Pour ce qui est de la collaboration avec les projets upstream et downstream : les distributions et les utilisateurs veulent des trucs stables, de la documentation, de la vision sur la roadmap des projets. Les distributions font de la QA et de la CI, qui aident les projets qui en bénéficient.

Chez Red Hat, à chaque modification de PHP ou d’une de ses dépendances liées (extensions PECL, logiciels écrits en PHP, bibliothèques PEAR ou Composer, …), un build complet est lancé. Ce build implique une compilation de PHP, un lancement des tests de tous les paquets liés (dont Zend Framework, Doctrine, PHPUnit, Symfony, …). Cela facilite énormément la détection de régressions et de changements de comportement à chaque nouvelle version de PHP, y compris pour les Release Candidate ! En cas problème, la distribution effectue un bug-report auprès du projet concerné (y compris php.net, donc).

En conclusion : les distributions RPM sont un bon choix pour des développeurs PHP, que ce soit par le biais des SCL qui permettent de disposer de plusieurs versions (officiellement supportées) en parallèle, ou par le support qui est fait aux projets upstream.

Mon avis : J’ai souvent grogné sur les distribs entreprise qui distribuaient de vieilles versions de PHP (Hello RHEL 5 et ton PHP 5.1.6). Je suis donc fort content de voir que les choses évoluent, et dans le bon sens, à ce niveau là ! J’ai aussi appris que les vieilles versions fournies par ces distributions recevaient tout de même des correctifs de sécurité, même si elles ne sont plus maintenues par php.net (et c’est une bonne chose !). Et, finalement, le boulot fait sur l’intégration continue et le lancement de tests au niveau de PHP et de projets dépendants est vraiment super pour la qualité et la stabilité de PHP !


Laisse pas trainer ton log !

Olivier DOLBEAURésumé, Slides, Vidéo

Les fichiers de log permettent de garder trace de ce qu’il se passe, que ce soit dans le syslog, les access_log, les logs applicatifs, … Fréquemment, pour consulter un log, on se connecte en SSH au serveur concerné et joue avec tail ou cat et grep ou sed, avec des expressions plus ou moins rationnelles spécifiques à chaque fichier.

Stack ELK (supportée par l’entreprise ElasticSearch) :

  • ElasticSearch
  • Logstash : input + filter + output
  • Kibana : visualisation des logs via une jolie interface qui permet de réaliser des dashboards donnant une vue d’ensemble sur la plate-forme.

Pour ce qui est de syslog : utilisation de rsyslog pour tout envoyer dans logstash. Côté logstash, configurer l’import pour récupérer les logs, utiliser le filtre grok (fonctionnement par expressions rationnelles) et configurer la sortie pour un envoi vers ElasticSearch.

Pour les logs applicatifs : Monolog supporte de nombreux handlers, y compris pour envoyer vers ELK. Penser qu’on peut utiliser des processors pour enrichir les logs au passage, en particulier avec PSR-3 où chaque méthode de log reçoit un contexte en paramètre.

Chez BlaBlaCar, les logs sont utilisés pour comprendre ce qui a pu causer des erreurs. Ils stockent donc de nombreuses informations et ont un lag d’au maximum deux minutes par rapport à la production (pour permettre de comprendre les éventuels problèmes liés à une mise à jour). L’infra mise en place est assez grosse (1 serveur pour récupérer les logs, 2 redis, 3 logstash qui filtrent depuis redis et 5 elasticsearch pour le stockage), avec des machines qui ne sont pas trop chargées mais de gros besoins de stockage (20 à 25GB de logs applicatifs par jour + 10GB de syslog, conservés au maximum 30 jours puisque le but est de détecter / analyser les problèmes en temps réel).

Dans l’équipe, tout le monde regarde régulièrement les dashboards, pour voir s’il ne se passe pas quelque chose de spécial. Pas de mécanisme d’alerte automatique branchée dessus (aujourd’hui). C’est principalement utilisé par les équipes techniques, mais les équipent marketing disposent d’une stack du même type pour les données qui les intéressent plus (sur les paiements, par exemple) — tout en sachant qu’ELK n’est pas l’outil le plus adapté pour ce type de reporting.

Mon avis : Ayant beaucoup de logs (systèmes et applicatifs) en vrac sur une demi-douzaine de serveurs, sans réelle autre solution aujourd’hui que ssh + tail / cat + grep / sed, je suis ressorti de cette présentation en me disant que ELK serait probablement la première idée vue à ce ForumPHP sur laquelle on allait se pencher (et on a déjà commencé, depuis !). Sans forcément partir dès le début sur un système aussi complet que celui qu’Olivier nous a montré, mais au moins pour avoir les quelques briques de base, voir ce qu’on en tire, pour nous aider à mieux cadrer notre besoin et ensuite améliorer la stack.


Composer Best Practices

Jordi BOGGIANORésumé, Slides, Vidéo

Jordi, Lead Developper de Composer, a commencé sa présentation par un rappel sur ce qu’est le Semantic Versionning (semver.org), Avec ses trois numéros de versions : majeure (pour ce qui casse la compatibilité), mineure (pour les ajouts de fonctionnalités) et patch (pour les correctifs).

Il a ensuite parlé des contraintes de versions comprises par Composer :

  • Exact match : 1.0.0, 1.2.3-beta2, dev-master
  • Range : 1.0.*, 2.*
  • Unbounded range : >=1.0. Attention : si la 2.0 (nouvelle version majeure ⇒ cassure de compatibilité) sort, on va y passer !
  • Possibilité d’utiliser des opérateurs : , pour ET et | pour OU.
  • Next significant release :
    • ~1.2 : le chiffre de la version mineure peut augmenter, mais pas celui de la version majeure. Équivaut ici à >=1.2.0,<2.0.0
    • ~1.2.3 : le chiffre de la version patch peut augmenter, mais pas ceux de la version majeure et mineure. Équivaut ici à >=1.2.3,<1.3.0
    • C’est ce qui devrait systématiquement être utilisé par les bibliothèques — et par nous autres développeurs !

Pour l’installation de nouveaux paquets, composer require utilise par défaut ~ et crée un require qui matche la version courante. En termes de stabilité, Composer respecte la chaîne usuelle devalphabetaRCstable. Attention aux requirements trop stricts, qui peuvent rendre impossible la résolution de conflits entre plusieurs bibliothèques dépendant toutes du même paquet en des versions différentes.

Pour les tags, 2.0.2 correspond à une version stable alors que 2.0.2-betaX correspondra à une bêta. Pour les branches, utiliser le suffixe -dev, puisque la branche change et n’est pas stable (à l’inverse d’un tag qui ne bouge pas).

Quelques autres points :

  • Le fichier composer.lock ne doit pas être mis en .gitignore : il permet une installation plus rapide et nécessitant moins de mémoire, ainsi que des installations reproductibles.
  • La section scripts dans composer.json permet de mettre en place des commandes utilisables par composer nom-commande.
  • Pour ceux qui auraient besoin d’utiliser un projet forké : la section repositories dans composer.json est plus prioritaire que les autres repositories. Nos branches de travail sont disponibles et il est possible d’utiliser la syntaxe d’alias ma-branche as 2.5.0 pour injecter notre fork et notre branche en faisant croire qu’il s’agit d’une version donnée (ça peut permettre de faire des trucs horribles, attention à ne pas en abuser !).

La présentation s’est terminée avec un mot à propos de Toran Proxy, qui joue un rôle de proxy qui améliore les performances et la résilience (on peut déployer même si github ou packagist sont indisponibles) en réalisant un miroir de git et de fichiers zip et en permettant de l’hébergement privé de paquets (avec configuration en interface web). La licence payante permet aussi de financer composer et packagist (en particulier, le temps que Jordi passe à bosser dessus — et donc pas à gagner de quoi manger par le biais de son activité professionnelle ; le temps passé représente beaucoup plus que le coût du serveur).

Mon avis : J’ai beau utiliser composer régulièrement, c’est pendant cette présentation que j’ai enfin compris le sens de ~ ^^. Pas mal de rappels utiles, quelques moments de “oh c’est pratique” (notamment sur l’utilisation de repositories pour les repos forkés et de as pour aliaser des branches / versions). Le fait que Jordi ait fait cette conférence en français (qu’il n’utilise que rarement pour des discussions techniques) l’a certainement rendue plus accessible. Et j’ai vraiment été touché par les échanges en fin de présentation sur le fait que ce qui coûte cher aux mainteneurs de projets open-source, ce ne sont pas les serveurs, mais le temps passé et le manque à gagner qu’il représente.


Retour d’expérience : tests fonctionnels chez Maisons du Monde

Marc HUGONRésumé, Slides, Vidéo

La présentation a commencé par une histoire assez classique, d’un site e-commerce existant sur des technos commençant à dater, repris par une nouvelle équipe, sans test automatisé, avec des phases de recette de plus en plus longues, jusqu’à arriver à un tunnel de commande KO en production pendant un bon moment. Sans test au départ, avec un time-to-market très court, un manque de connaissance et un gros existant, est-ce que mettre en place des tests unitaires aurait permis d’éviter d’en arriver là ?

Pour avoir une vision plus globale sur le bon fonctionnement du site entier (et pas de composants distincts) et mettre en place de tests rejouables, choix de Selenium. Problèmes de ce type de tests :

  • Dépendance aux données (typiquement, que le produit testé soit en stock), d’autant plus qu’il faut tester des règles complexes dépendant fortement des données.
  • Selenium est sympa, mais problèmes de volumétrie, ainsi que de maintenabilité des tests (fortement liés à la structure HTML des pages).
  • Il n’est pas vraiment possible de tester ce qui arrive en base de données, l’utilisation de comptes utilisateurs différents à chaque lancement, la réception de mails de confirmation, …
  • Sur quel environnement faire tourner les tests ? Directement en production ?

En somme, récapitulatif des besoins : des tests compréhensibles et maintenables, réutilisables, accédant à la DB et à des Web Services, avec un outil de travail dédié. Choix de RubyMine (pour la possibilité de poser des breakpoints pendant l’exécution des tests, notamment) + Cucumber + Selenium pour l’exécution. Comparable à Behat maintenant, mais lorsque le choix a été fait il y a deux ans, cette solution, qui existait depuis plus longtemps, a été jugée plus mature.

Pour répondre à la problématique d’avoir des données, les tests sont joués sur des dumps légers, anonymisés, ne contenant que deux mois de données (import en 15 minutes) — via un script PHP qui filtre un dump SQL complet de la production.

Également, mise en place de bouchons :

  • Création de produits de test, correspondant aux différents cas de tests. Permet de ne pas modifier les données issues de la production, qui peuvent être utiles pour reproduire des bugs. Et code applicatif modifié pour tenir compte de ces produits de test, avec des portions du type if ($prod_id < 1000) { ... }.
  • Surcharge d’URLs d’appels à certains WebServices par le biais de cookies, renseignés uniquement pour les tests.
  • Mise en place d’un faux formulaire de paiement, qui entraîne le même type de retour que le paiement, sauf qu’il permet de spécifier le résultat attendu.

Au bout de deux ans : 10 développeurs et 3 testeurs (responsables des mises en production), environ 400 scénarios de test, 6 agents de build en jouant 3 en parallèle (pour que les tests ne durent pas trop longtemps), ~1000 commandes de test passées par jour. A permis une diminution forte des incidents majeurs et la garanti que le chemin critique est toujours fonctionnel avant chaque déploiement — y compris pour des points liés à des événements comme les soldes !

Il reste un problème qui n’a pas encore trouvé de solution : ces tests remontent pas mal de faux positifs, qui prennent beaucoup de temps à analyser.

Mon avis : J’ai retrouvé dans cette présentation pas mal de problématiques que j’avais rencontré il y a de nombreuses années sur une application e-commerce où nous souhaitions mettre en place de tests fonctionnels sur tout le workflow de gestion de commande (dans les grandes lignes, nous étions parti sur du phpunit pilotant Selenium, avec lancement de batchs entre temps pour les étapes sans écrans). Je suis à la fois content de voir que d’autres ont mis en place une partie des solutions auxquelles nous étions arrivé sur le coup (nous nous étions posé pas mal de questions face à l’usine à gaz que nous avions, à ses faux positifs, …) et un peu triste que la mise de tests fonctionnels complets ne se soit pas tellement simplifiée, plusieurs années après.


Retour d’expérience ARTE GEIE : développement API

François DUMERésumé, Slides, Vidéo

Pour donner rapidement le contexte de sa présentation, François a commencé par rappeler que ARTE regroupe 36 sites web, de la TV / replay, des applications mobiles… Qui nécessitent des API pour échanger des données, comme des metadonnées de programmes (horaires, casting, droits, …), des URLs de flux ou des statistiques de consultation.

La mise en place de nouvelles API a été l’occasion de partir sur une base symfony2 + MongoDB, avec synchronisation asynchrone via RabbitMQ et échanges en json:api. La sécurisation des API et leur throttling (y compris en-têtes d’informations dans les réponses) a été généré par un mécanisme de reverse-proxy identifiant (nginx + scripts en Lua) nommé OpenResty. L’utilisation de json:api (via HateoasBundle, avec quelques patchs complémentaires) qui permet d’inclure des sous-documents permet de limiter le nombre de requêtes.

Une solution alternative aurait pu être de gérer l’autorisation ouath via varnish et non côté nginx — la mise en place de TU n’est pas vraiment facile sur des scripts Lua pour nginx, soit dit au passage.

Mon avis : J’ai pris note de la gestion d’OAuth au niveau de nginx (ou de varnish), ça peut être une idée à fouiller dans le futur, pour alléger la charge sur les serveurs applicatifs pour des APIs fortement sollicitées.


Automate your Workflow: Removing Tedium in Everyday Work

Bruno ŠKVORCRésumé, Slides, Vidéo

Pour cette dernière conférence de la première journée de ce ForumPHP, Bruno, éditeur du canal PHP de Sitepoint, nous a présenté une démonstration d’un projet nommé Diffbot, qui vise à faciliter l’extraction de données de pages web. Il utilise cet outil afin d’automatiser une partie de son travail d’éditeur recevant de nombreux mails et brouillons d’articles, en particulier pour suivre les performances des auteurs — d’autres aspects automatisables étant le suivi de la compétition, la génération de factures, ou l’envoi de mails en masse.

Pour la démonstration, il s’est agit de montrer comment paramétrer Diffbot pour créer le portfolio d’un auteur, en partant d’une interface graphique qui permet d’extraire les données d’une page web ; y compris en gérant la pagination et des sous-données répétées sur chaque page. Le rendu peut ensuite être renvoyé via une API ou sorti sous forme de graphiques C3+D3.

Pour conclure, Bruno a rappelé que tout ce qui pourrait être automatisé devrait l’être : c’est ainsi que l’on gagne du temps pour coder ou bosser sur la qualité !

Mon avis : Je suis fan de l’approche qui dit qu’il faut automatiser tout ce qui peut l’être en vue de gagner du temps sur ce qui est important. Cela dit, j’ai trouvé un peu dommage que la présentation se soit concentrée sur un seul outil (qui a l’air de pouvoir faire quelques trucs sympas une fois pris en main, même si un peu cher pour mon usage personnel) : j’aurais probablement préféré une approche plus globale, donnant plusieurs pistes, quitte à moins détailler chaque point individuellement — et j’aurais adoré entre parler de génération automatique de résumé ou d’extraction de mots-clefs (j’ai eu l’occasion de m’amuser un peu avec ces sujets pendant mes études, vu que le labo rattaché à mon université faisait du traitement du langage naturel) pour faciliter certaines tâches de veille / suivi de mailing-lists (entre autres).


Mes notes du second jour de ce ForumPHP 2014 devraient être publiées dans quelques jours — le temps de finir de les mettre au propre ;-)


Par Pascal MARTIN le mercredi 17 septembre 2014 3 commentaires

Je serai présent au Forum PHP 2014 les 23 et 24 octobre à Paris !


Cette année, j’animerai une session de questions/réponses autour de PHP, de son état et de son évolution, à laquelle participeront trois intervenants :

  • Jordi Boggiano (Lead Developer de Composer), que je rencontrerai IRL pour la première fois,
  • Pierre Joye (Core Dev PHP, OSS développeur (curl, gd, etc.), Microsoft OSTC), avec qui j’ai longuement discuté lors du PHP Tour à Lyon en juin,
  • Et Julien Pauli (Release Manager de PHP 5.5 et co-RM de PHP 5.6), que je croise régulièrement depuis maintenant plusieurs années.


Comme d’habitude, la liste des conférences est bien fournie.

Au premier coup d’œil, en voici quelques unes qui attirent mon attention et auxquelles il est probable que j’assiste — soit par pure curiosité, soit parce qu’elles pourraient répondre (ou, au moins, fournir des pistes de solutions) à des problématiques que je rencontre fréquemment :

  • PHP dans les distributions RPM : on dit très souvent que l’adoption des nouvelles versions de PHP est freinée par les distributions orientées entreprises, qui ont tendance à rester sur de vieilles versions dites stables. Pour moi qui suis plutôt Debian, je suis curieux de voir comment les choses évoluent à ce niveau côté Redhat.
  • Cohabitation de PHP et Node au Monde, pourquoi et comment : étant souvent en train de jongler entre plusieurs technos en fonction des projets, je suis curieux de voir comment certains problèmes que je rencontre au quotidien ont pu être approchés chez Le Monde.
  • Composer Best Practices : utilisant composer depuis plusieurs années, j’ai parfois l’impression de le subir… Je me dis donc qu’il pourrait être intéressant d’aller écouter son Lead Dev1 !
  • La mesure, ce n’est pas que pour le devops : pour celle-ci, il s’agit principalement de curiosité ;-). J’ai envie de profiter d’un retour d’XP sur le sujet Lean Startup, pour voir en quoi les différences avec une approche plus traditionnelle pourraient être bénéfiques, à la fois pour l’entreprise où je bosse et pour ses clients.
  • Laisse pas traîner ton log ! : avec une grosse dizaine d’applications qui logguent en vrac vers une quantité parfois effrayante de fichiers, j’ai besoin d’une solution qui me permette de les gérer — et surtout, d’en extraire les données importantes ! J’entends parler de stack ELK depuis un moment, sans avoir jusqu’à présent eu le temps de fouiller… Voici l’occasion d’en apprendre plus ;-)
  • Retour d’expérience : tests fonctionnels chez Maisons du Monde : j’ai plusieurs fois vu des batteries de tests fonctionnels, sans que les équipes aient forcément l’impression que ça marchait bien. Je suis donc curieux de voir comment d’autres ont fait et ce que ça leur apporte.
  • VDM, DevOp malgré moi : d’un site perso à des millions de pages vues par jour, ça a dû faire un bon exercice de scalabilité pour une stack PHP. Là où on commence à avoir des solutions assez classiques, ce n’était pas forcément le cas il y a quelques années — j’ai donc envie de voir comment ça s’est passé ici et de comparer avec les approches prises sur des applications sur lesquelles j’ai bossé.

En complément, je ferai peut-être aussi un tour aux conférences suivantes — pas tellement pour ce qu’elles m’apporteraient d’utilisable tout de suite, mais plus parce que j’ai entendu parler des sujets et que j’aimerais en savoir un peu plus, sans pour autant pouvoir y consacrer un week-end ou deux à fouiller par moi-même :

  • An introduction to the Laravel Framework for PHP : quand il s’agit de frameworks, je suis plus symfony… Mais Laravel fait beaucoup parler de lui ces derniers temps (peut-être plus outre-Atlantique qu’ici) ; j’ai donc envie de voir un peu à quoi ça ressemble.
  • Bringing Sculpin to Life : sans forcément être grand fan de générateurs de sites statiques, j’entends de plus en plus souvent parler de Sculpin. Voici donc aussi l’occasion d’en apprendre plus.

Bien sûr, je n’exclue pas la possibilité de changer d’avis au dernier moment avant de rentrer dans une salle… Et de partir vers une autre. Ça ne serait pas tout à fait la première fois ^^


Des ateliers pratiques d’une demi-journée sont organisés en parallèle des conférences.

Je recommande tout particulièrement celui que Julien Pauli va donner sur le développement d’extensions PHP2 : j’ai assisté il y a plusieurs années à une des premières versions de cet atelier et j’en étais ressorti avec plein d’étoiles dans les yeux. Je n’ai donc aucun doute sur le fait qu’il représentera cette année une demi-journée fort instructive pour ceux qui voudraient se lancer dans le sujet !

Pour vous inscrire, c’est par ici. Faites vite, il n’y a que 15 places — et la moitié sont déjà parties !

En fonction de vos préférences, vous pourrez aussi vouloir jeter un coup d’œil aux autres ateliers :


Nous croiserons-nous à ce Forum PHP ?



  1. Cette conférence pourrait compléter la conférence gestion de dépendances et composer qui a eut lieu à Lyon hier soir, qui parlait plus d’industrialisation (j’ai particulièrement été intéressé par le côté Satis pour ne pas dépendre de github). 

  2. Je n’assisterai très probablement pas moi-même à cet atelier : puisque je connais assez bien le sujet, je préfère laisser la place à quelqu’un qui aura plus de choses à découvrir que moi. 

Par Pascal MARTIN le mardi 22 juillet 2014 1 commentaire

J’ai posté il y a quelques jours les notes que j’ai prises lors des conférences auxquelles j’ai assisté le premier jour du PHPTour 2014 à Lyon.

En plus d’avoir pu échanger avec plein de monde et assister à une quinzaine de présentations, j’ai aussi cette année eu la chance de participer à deux conférences — toutes deux basées sur le travail que j’effectue chez TEA, The Ebook Alternative :

  • « Notre environnement de développement n’est plus un bizutage ! » avec Julien Fusco le premier jour,
  • et « PHP 5.3 → PHP 5.6 : no pain but gain ! » le second.

Dans la suite du premier post publié la semaine dernière, voici, encore dans l’ordre chronologique, mes notes du second jour. Notez 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 sur joind.in et les vidéos captées lors de l’événement vont peu à peu être diffusées par l’AFUP sur youtube.


Déploiement continu : Click and deploy !

Sophie BeaupuisRésumé, Slides

Après l’apéro communautaire de la veille, Sophie a eu la difficile mission d’animer une des premières conférences de la seconde journée de ce PHPTour. Elle a commencé par rappeler que le but de Zend est de rendre PHP professionnel et accessible aux entreprises — le sujet de sa conférence s’inscrivant dans cette logique.

Le constat initial est que les développeurs ont tendance à perdre du temps : correction de bugs, mise en place d’environnement, écriture de tests qui ne sont pas utilisés (lancés quand on est les écrit et quasiment plus jamais ensuite). Du point de vue des DSI, l’innovation est freinée par la lenteur technique, les pannes répétées impactent le CA, et les mises en production sont compliquées et échouent trop souvent.

Principes pour améliorer tout ça :

  • Automatiser : pas besoin d’un développeur pour faire quelque chose qu’une machine sait faire,
  • Répéter ⇒ meilleure maîtrise + détection des problèmes au plus tôt,
  • Monitorer : la collecte d’informations permet d’améliorer la qualité.

La seconde partie de la présentation était orientée autour d’une démonstration montrant comment déployer en production après chaque commit git — à travers un processus d’intégration continue sous Jenkins chargé de jouer les tests, de créer un package de déploiement, et de déployer celui-ci (cette dernière étape n’étant pour l’instant lancée qu’après validation par un humain).

Sous Jenkins, plusieurs jobs, qui correspondent chacun à des tâches Phing :

  • Un job qui extrait les sources depuis git,
  • Un job pour créer une archive de déploiement (archive qui pourrait alors être déployée sur un ou plusieurs environnement(s), sur un ou plusieurs serveur(s)),
  • Un job pour les tests en analyse statique,
  • Et un job pour le déploiement en lui-même.

Pour résumer : en principe, tout peut — et doit — être automatisé !

Mon avis : Maîtriser ses déploiements (et ne les effectuer que si les tests passent) me semble indispensable, mais plusieurs discussions que j’ai eu après cette conférence montrent que trop de développeurs n’ont pas encore industrialisé cela. Un rappel utile, donc.


Stop Multiplying by 4: Practical software estimation

Reeves CharlesRésumé, Slides

Charles a introduit sa présentation en indiquant qu’il travaille en freelance — et qu’il doit donc facturer ses clients.

Estimer permet de mesurer l’effort à fournir (et pas uniquement de calculer des deadlines) et les estimations devraient être réalisées par les développeurs, qui sont les propriétaires du code et savent quel effort un développement va nécessiter : les PO et CP ne devraient pas estimer, puisque leurs avis vont être biaisés (par exemple : ils connaissent le budget et vont faire en sorte que ça rentre dedans).

Les développeurs peuvent résoudre des problèmes complexes… Mais estimer est parfois à la limite de l’impossible !

Pour parvenir à estimer, il est indispensable d’avoir des requirements : des spécifications précises peuvent permettre de constituer un élément mesurable. Cette notion de précision dans les spécifications est indispensable. Par exemple, s’il est écrit qu’une donnée doit être “validée”, il est indispensable de savoir en quoi consiste cette validation (valider un format ? valider une donnée en appelant un web-service distant ? valider une adresse mail en envoyant un mail contenant un lien prouvant que le mail a été reçu ?).

Quelques autres exemples de modificateurs qui entraînent des spécifications vagues :

  • rapide, efficace ⇒ à reformuler en, par exemple, “5 secondes”
  • valide, etc, incluant mais pas limité à …
  • maximiser, minimiser, optimiser, au moins
  • simple, facile, user-friendly

Il est possible d’utiliser quelques méthodes pour s’aider lors des estimations :

  • Utilisation de données historiques
    • On sait combien de temps quelque chose prend en général ⇒ on réutilise ce temps
    • La vélocité peut aussi donner une idée
  • Partir sur un prototype ou sur les tests unitaires, pour avoir une idée du travail à effectuer
  • Estimer par un intervalle “entre X et Y” : il vaut mieux être à peu près juste que précisément faux
  • Répéter : ré-estimer le lendemain pour vérifier si on est d’accord avec l’estimation de la veille
  • Test absurde : on commence par des estimations “de folie” et on réduit de plus en plus précisément
  • Méthode Wideband Delphi : 3 chiffres successifs avec discussions entre pour affiner

Pour finir : il faut enlever les gens du problème, penser à l’intérêt des fonctionnalités (et pas rester sur les positions de chacun : on vise à arriver au minimum requis et, ensuite seulement, faire la suite). Ne pas négocier les estimations : les développeurs sont ceux qui savent combien de temps ça prend effectivement et ce qui est le mieux pour le code. Ajouter des développeurs ne résout pas forcément le problème. Et il faut itérer et être honnêtes.

Mon avis : Une passe intéressante sur plusieurs approches possibles pour affiner des estimations et arriver à des chiffres réalistes. L’idée que seuls les développeurs doivent chiffrer (et pas le chef de projet ni le product owner) est intéressante : après tout, c’est nous qui construisons l’application et sommes souvent les mieux placés pour déterminer combien de temps il nous faudra.


Everything you always wanted to know about UTF-8 (but never dared to ask)

Juliette Reinders FolmerRésumé, Slides

Pour introduire sa présentation, Juliette a demandé qui avait déjà utilisé UTF-8 et qui avait déjà eu des problèmes avec. Forcément, tout le monde a levé la main. Mais Unicode ≠ UTF-8 ≠ Internationalisation. Pourquoi penser UTF-8 ? Parce que rien n’est local. Même au sein d’une entreprise, on peut avoir des filiales à l’étranger, des fusions, des noms d’employés étrangers, … Et gérer tout ça, c’est plus facile si c’est fait dès le début !

Il existe plus de 7000 langues vivantes, dont plus de 300 parlées par plus d’un million de personnes (et la Nouvelle Guinée compte à elle seule 837 langues différentes). Parmi les 20 langues les plus utilisées, seulement 7 sont en script latin. Plus de 180 scripts d’écriture sont actuellement utilisés (certains sont utilisés pour plusieurs langues ; certaines langues ont plusieurs systèmes d’écriture ; et certains sont utilisés pour la religion, les cérémonies, ou purement pour le fun (Klingon par exemple)).

Character Set = groupe de caractères → code page → code point. Encoding = part du code page et donne le binaire qui stocke le caractère. Unicode (charset) couvre tout, et peut être représenté par plusieurs encodings (UTF-8, 16, 32).

UTF-8 est le plus simple des encodings Unicode :

  • compatible ASCII
  • taille de caractères variable
  • peut encoder tous les caractères Unicode
  • Défaut pour XML et standard pour HTML
  • peut être reconnu assez facilement, faible risque de confusion
  • tri par tableau d’unsigned ⇒ même ordre que le code point Unicode

Le problème est que tout le monde utilise autre chose par défaut et qu’il faut donc être explicite partout !

  • Ordinateur de l’utilisateur : peu de fontes sont capables de gérer plein de trucs Unicode : il faut travailler avec des fontes compatibles Unicode et ne pas réutiliser les codes ASCII pour d’autres caractères !
  • HTML : il faut déclarer l’encodage : en-têtes HTTP et tout en haut du document HTML (utile si l’utilisateur enregistre la page, par exemple — et n’a donc plus les en-têtes HTTP)
  • CSS : encoding sur la première ligne du fichier, utiliser des fontes compatibles Unicode (avec catch-all sur serif / sans-serif à la fin)
  • FTP : transférer les fichiers en binaire !
  • Réception de données depuis le client : utiliser accept-charset="UTF-8" pour les formulaires

Au niveau de PHP, les choses se sont un peu améliorées en PHP 5.3 (arrivée de l’extension Intl) ; et sont de mieux en mieux à chaque version (intl gagne en fonctionnalités). Toutefois, peu de fonctions de base sont en Unicode. Attention aux fonctions qui impactent le processus entier, comme setlocale() ou gettext().

Pour ce qui est de la base de données MySQL, travailler avec des versions raisonnablement récentes (>= 4.1), utiliser set names pour paramétrer l’encodage au niveau de la connexion, tout mettre en UTF-8 au niveau de la configuration du serveur.

Mon avis : Plusieurs rappels utiles ; j’ai bien accroché sur la partie sur les fontes (avec exemples en images sur les slides, illustrant différents types de problèmes), qui est assez éloignée de ce sur quoi je me concentre habituellement. Dommage que la présentation ait été trop longue pour tenir sur la durée allouée et que la fin ait donc été coupée.


L’asynchrone en PHP, c’est possible !

Olivier DolbeauRésumé, Slides

Pour introduire cette conférence, Olivier est parti d’un exemple assez classique : une fonctionnalité “mot de passe oublié” qui envoie un mail à l’utilisateur. Envoyer un e-mail est long et il est dommage de bloquer un processus serveur Web pour effectuer cette manipulation. A la place, il est plus intéressant d’immédiatement afficher un message à l’utilisateur indiquant que le mail est parti, tout en envoyant le mail un peu plus tard, en arrière-plan.

Le principe alors utilisé serait le suivant :

Serveur Web -> Broker --> worker (consumer)
               (AMQP) \-> worker (consumer)
                       \> worker (consumer)

Le broker est chargé de recevoir des messages et de les distribuer aux workers capables de les gérer. Olivier travaille avec RabbitMQ, mais le principe est sensiblement le même pour les différentes alternatives. Au niveau de PHP, l’extension php_amqp est utilisée.

Les workers sont des processus qui doivent tourner en permanence. Il faut donc éviter les Fatal Errors et/ou Exceptions non catchées (par contre, au développeur de logguer ce qui doit l’être, bien sûr). Pour éviter d’éventuels problèmes de fuites mémoire, les workers sont fréquemment redémarrés (après plusieurs minutes ou X messages traités) ; même chose lorsqu’il faut les mettre à jour : ils sont proprement coupés avant d’être mis à jour puis redémarrés.

Sur un projet symfony, il n’est pas forcément utile / recommandé de charger tout le framework pour un worker : chaque worker doit faire son job et rien de plus, ne serait-ce que pour limiter la consommation mémoire.

Quelques points supplémentaires :

  • Utilisation de supervisord pour construire des pools de workers
  • Attention aux outils / bibliothèques qui conservent plein de données en mémoire (comme le logguer finger crossed de Monolog qui, par défaut, garde tous les logs en mémoire)
  • En cas d’échec d’un worker lors du traitement d’un message, ré-essayer plus tard (30 secondes, puis 3 minutes, … de plus en plus longtemps)

Mon avis : J’étais déjà convaincu que sortir des traitements du serveur web pour les effectuer en arrière-plan était une approche viable en PHP (je le fais depuis des années en me basant généralement sur gearman, avec des pools de workers gérés par supervisord). Il était intéressant de voir une solution basée sur une autre brique technique, ainsi que sa mise en pratique sur des applications à forte charge, qui montre ouvertement que c’est possible.


PHP 5.3 → PHP 5.6 : no pain but gain !

Pascal MARTINRésumé, Slides

Pour cette seconde conférence que je donnais au PHPTour, j’ai commencé par rappeler les principales nouveautés qu’avaient apportés PHP 5.3, 5.4 et 5.5 — pour en arriver au fait que PHP 5.3 représente un peu plus de la moitié des installations de PHP 5, alors que PHP 5.5 n’en n’est qu’à environ 2%. D’ailleurs, PHP 5.3 est la version de PHP la plus utilisée actuellement, alors qu’elle va atteindre sa fin de vie cet été ! J’ai aussi passé rapidement en revue quelques-unes de nouveautés de PHP 5.6 (La conférence de Rasmus en ouverture des deux jours du PHPTour entrant plus en détails, avec exemples de code à l’appui, je suis passé rapidement sur cette partie).

En seconde partie, je suis entré dans le vif du sujet, en dressant un tour d’horizon des problèmes potentiels que l’on pouvait rencontrer pendant une montée de version de PHP. J’ai enchaîné avec plusieurs approches que l’on peut utiliser pour faciliter celle-ci, en insistant sur la mise en place d’analyse statique de code (avec PHPCompatibility, qui est un standard pour PHP_CodeSniffer).

Enfin, j’ai donné quelques conseils, basés sur les migrations successives que j’ai eu l’occasion de réaliser ces dernières années — nous sommes d’ailleurs, chez TEA, The Ebook Alternative, en train de finaliser une migration PHP 5.3 → 5.5 et pensons enchaîner sur PHP 5.5 → 5.6 en seconde moitié d’année.

Comme pour la conférence donnée avec Julien Fusco en fin du premier jour, je n’ai pas pris de note pendant la présentation (j’étais un peu occupé ;-) ), mais je vous encourage vivement à parcourir mes slides, en pensant à consulter les notes du présentateur : avant de diffuser ceux-ci, j’ai veillé à rendre ces notes aussi complètes que possibles, afin que les slides apportent un maximum d’informations à ceux qui n’auraient pas pu assister à la présentation.

Mon avis : Je me suis plusieurs fois plongé dans le sujet ces dernières années et il me tient tout particulièrement à cœur (ne serait-ce que parce que je souhaite pouvoir travailler avec les fonctionnalités des versions récentes de PHP — pour moi qui suis régulièrement l’évolution du langage, rester coincé sur une vieille version est parfois quelque peu frustrant ^^ ). J’ai donc beaucoup apprécié pouvoir donner cette seconde présentation lors de ce PHPTour.


Prévenez la dette technique de vos projets

Bastien JaillotRésumé, Slides

Pour cette dernière conférence de la journée, Bastien a commencé par rappeler que la dette technique est un emprunt réalisé sur la qualité en vue d’avancer plus rapidement, tout en sachant qu’on sera par la suite pénalisé. La dette technique est inévitable et n’est pas forcément une mauvaise chose, puisqu’elle permet de sortir des produits plus rapidement, en faisant passer les besoins fonctionnels avant les besoins techniques — il s’agit alors d’un problème plus humain que technique.

Il existe quatre types différents de dette technique :

  • celle causée par un développeur qui découvre une techno,
  • la dette SSII, que l’on trouve quand les développeurs sont payés au nombre de tickets traités,
  • la prise de raccourcis qu’on paiera plus tard,
  • et celle qu’entraîne un développeur qui n’a plus envie de toucher à une vieille techno, au bout de quelques années.

La dette technique a un impact majeur : pour un développeur, elle n’est pas vraiment attirante. Et là où un développeur peut quitter le projet, pour l’entreprise, ce n’est pas bon sur le long terme. En complément, on développe trop de choses : il faut savoir dire “non” et se concentrer sur l’essentiel (après tout, le meilleur code, c’est celui qui n’a pas besoin d’être écrit !).

Au niveau de la prise de décision, les gens ne se comprennent pas vraiment ⇒ on ajoute des intermédiaires et des dépendances à des gens “qui ne veulent pas”. On finit par penser plus à nos intérêts qu’à autre chose. Pour aider, la culture d’entreprise joue : elle pousse à vouloir faire bien (en échange, on fait des trucs fun). Il est important d’expliquer les contraintes et de comprendre les enjeux fonctionnels, sans hésiter à montrer la dette technique.

Pour ce qui est de la gestion du temps, penser qu’on ne peut pas avoir rapide + pas cher + bonne qualité. Le projet peut avancer, mais qu’en est-il de la dette technique et de la frustration des développeurs ? Prévoir la mise en production bien avant la fin de la collaboration et/ou du contrat, effectuer une release le plus tôt possible et les features suivantes arriveront après (et peut-être qu’on réalisera qu’elles n’étaient en fait pas utiles !).

En contre-partie, ne pas oublier que le beau code n’est pas utile s’il ne répond pas à un besoin, que le développeur est un créatif qui a son ego, et que la (sur-)qualité peut aussi être une source importante de dette technique (est-il vraiment utile de mettre en place plein d’outils… pour générer une page statique ?). Une ré-écriture de 0, même si l’idée est plaisante (le 1er jour) est quelque chose de dangereux, aussi !

Pour conclure : l’ennemi de la dette technique, c’est le pragmatisme. A nous de faire le maximum pour qu’on ne nous impose pas de rajouter trop de dette !

Mon avis : Une passe sympathique sur plusieurs causes de dette technique, ainsi qu’un rappel indispensable sur le fait qu’elle est parfois utile, mais aussi que c’est notre boulot de savoir la gérer (à la fois en l’acceptant lorsque c’est judicieux, mais aussi en sachant la rembourser lorsqu’on en a l’occasion).


Lightning talks

Cette seconde journée du PHPTour s’est terminée par 6 lightning talks :


En keynote de cloture, Mikaël Randy et Maxime Teneur ont indiqué que le Forum PHP aurait lieu les 23 et 24 octobre 2014 à Paris — le CFP est d’ailleurs ouvert !

Pour ma part, je suis reparti de ces deux jours épuisé (deux jours à me coucher tard après le diner des conférenciers et l’apéro communautaire, deux conférences préparées et présentées, deux journées sans faire de pause) et en pleine forme (plein de gens rencontrés, beaucoup d’échanges avec les autres conférenciers et avec le public, de nombreuses conférences intéressantes, et plein de bonnes idées en tête !). Vivement la prochaine fois !

Et pour finir, puisque c’est sans aucun doute eux qui ont fait le plus dur : merci à toute l’équipe d’orga qui a fait un super boulot !


Par Pascal MARTIN le mercredi 16 juillet 2014 2 commentaires

Le PHPTour organisé par l’AFUP a cette année eu lieu les 23 et 24 juin, à la Manufacture des Tabacs à Lyon.

Ces deux jours ont été pour moi l’occasion de revoir plein de monde, de mettre des têtes sur des noms et de rencontrer plusieurs personnes avec qui j’échangeais depuis des années sans jamais les avoir vues, ainsi que d’assister à une quinzaine de conférences.

J’ai aussi, cette année, eu l’occasion de participer à deux conférences — toutes deux basées sur le travail que j’effectue chez TEA, The Ebook Alternative :

  • « Notre environnement de développement n’est plus un bizutage ! » le premier jour,
  • et « PHP 5.3 → PHP 5.6 : no pain but gain ! » le second.

J’ai tenté de prendre quelques notes lors de chaque conférence à laquelle j’ai assisté. Voici donc ci-dessous, dans l’ordre chronologique, celles du premier jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque conférence.

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


Coding and Dreaming - PHP in 2014

Rasmus LerdorfRésumé, Slides, Vidéo

Les deux jours de conférences se sont ouverts sur une présentation de Rasmus Lerdorf, qui a commencé par un historique de PHP, avant d’enchainer sur les nouveautés de PHP 5.5 et 5.6, pour conclure sur le fait que ce qui compte dans nos métiers, ce n’est pas tant les applications que nous développons, mais plutôt ce qu’elles apportent.

Au départ, pour développer pour le Web, on écrivait des CGI en C, puis en Perl. Dès 1994, Rasmus aurait voulu quelque chose de plus sympa à utiliser — et PHP a commencé comme ça (avec de la syntaxe alternative pour les structures de contrôles, d’ailleurs). Avoir une syntaxe “HTML + balises” était une bonne approche, puisque ceux qui faisaient du web étaient plus souvent des documentalistes que des développeurs.

En 1996, PHP permettait déjà plein de choses. Et dès 1997, Rasmus a reconnu que PHP était trop large pour un seul mainteneur — il a donc dit à ceux qui ralaient à propos de bugs qu’ils pouvaient se débrouiller pour les corriger (même si ça n’a pas été facile pour lui, qui n’aurait des fois “pas codé ça comme ça”).

Pour qu’un langage fonctionne, c’est son écosystème qui compte : Perl et mod_perl n’étaient pas adapté à de l’hébergement mutualisé et ne satisfaisait donc pas les hébergeurs. PHP, par contre, chargé uniquement du contenu, était plus adapté, avec des gestions de timeouts, de limite mémoire, … La stack LAMP et le mod_php d’Apache, qui évite de forker à chaque requête, a fortement aidé à répondre au “problème du web”.

Des points que l’on considère pour certains comme horribles aujourd’hui ont aussi aidé PHP à démarrer et à se démocratiser :

  • register_globals, par exemple, rendait plus facile l’apprentissage du langage par les débutants,
  • la syntaxe à base de $var pour les variables était plus facile à parser,
  • les magic_quotes étaient pratiques pour la base de données utilisée par Rasmus,
  • et les inconsistances d’API s’expliquent par le fait que PHP est souvent un simple wrapper autour d’une bibliothèque C, en mappant 1-1 les paramètres.

La présentation a continué avec les principales nouveautés apportées l’an dernier par PHP 5.5 et celles qu’apportera bientôt PHP 5.6 — je ne les passe pas en revue ici. Par contre, PHP 5.5 est aujourd’hui la version minimale que nous devrions utiliser !

En dernière partie, Rasmus a expliqué que “Coding”, finalement, n’est pas si important, et qu’il faut un juste milieu avec “Dreaming” : ce qui compte, quand le monde change, c’est lorsque les hackers s’y mettent et que l’on combine des idées avec leur réalisation.

Il a rappelé qu’il venait d’un endroit où tout le monde se fout d’Internet et que ce que l’on fait ne compte pas pour la majorité du monde : nos applications pourraient disparaitre, ça ne serait pas grave. Ce qui compte, c’est de fournir plus de valeur que nous n’en extrayons.

Mon avis : J’avais déjà vu cette conférence (j’avais regardé la vidéo enregistrée à Mexico, où Rasmus avait donné une version plus longue de cette présentation), mais il est malgré tout toujours agréable d’entendre parler de l’histoire de PHP (ça aide à remettre des choses en perspective), et encore plus de la bouche de son créateur.


Extract Till You Drop

Mathias VerraesRésumé, Slides, Vidéo

Pour cette conférence, Mathias a réalisé une session de live-coding où il est parti d’un bout de code un peu legacy pour le modifier à travers plusieurs itérations visant à le rendre plus lisible, plus clair, moins couplé et plus maintenable.

En regardant la portion initiale de code, on pouvait notamment remarquer :

  • des variables peu claires et mal nommées,
  • des conditions imbriquées,
  • des exceptions correspondant à des règles métier,
  • ou encore, des méthodes dont le nom ne reflétait pas le comportement.

Les différentes étapes du refactoring ont globalement été les suivantes :

  • ajout de tests de non-régression avec mocks sur les interfaces,
  • coups d’oeil réguliers au code-coverage (pas dans le sens “métrique de vanité”, mais pour avoir une idée de ce qui est testé et pour vérifier que l’on test ce que l’on pensait qu’on testerait),
  • dés-imbrication des conditions pour diminuer le nombre de niveaux d’indentation,
  • suppression de variables temporaires en in-linant des appels de méthodes,
  • sortie de tests de validité et de levées d’exceptions vers des sous méthodes du genre guardAgainstDuplicate(),
  • déplacement de vérifications directement vers la couche métier (ainsi, accéder directement aux objets métier sans passer par la couche service ne permet plus de sauter de validation)

Au final, il en est ressorti :

  • une méthode principale beaucoup plus courte,
  • des tests correspondant aux règles métier,
  • et du code nettement plus lisible !

Mon avis : une passe sur des principes que l’on commence à connaître, mais que l’on prend trop rarement le temps de mettre en pratique à fond. J’ai réalisé pendant la session de live-coding que j’avais encore pas mal de raccourcis-clavier de PhpStorm à maîtriser ^^


PHP, au cœur de la stratégie Open Source de Microsoft ?

Pierre Joye, Benjamin Moulès, Frederic Aatz — Résumé, Vidéo

En première partie de cette conférence, Frederic a expliqué que l’organisation au sein de Microsoft changeait au niveau de toute la boite et que l’entreprise avait des personnes dans tous les pays pour expliquer ce que fait Microsoft et établir des ponts et passerelles. Le sponsoring du PHPTour à Lyon ou le partenariat avec SensioLabs autour de symfony et d’Azure s’inscrivent dans cette démarche.

Après cela, Pierre a présenté quelques statistiques en rapport avec PHP et a rappelé quel est le cycle de releases suivi par PHP ces dernières années. Le mécanisme d’évolution de PHP a été amélioré ces dernières années (via les RFC, les votes qui sont fait dessus, et une certaine diminution des batailles sur internals@), même s’il est encore parfois difficile de contribuer à cette communauté qui ne semble pas toujours assez ouverte.

PHP a accueilli ces derniers temps bon nombre de nouveaux contributeurs et Pierre souhaiterait voir dans le top 10 uniquement des “nouveaux”. Ajoutons que “participer à PHP” ne veut pas nécessairement dire “coder en C” : le projet a besoin de volontaires pour maintenir la documentation, écrire des tests, … En somme : contribuez !

Microsoft participe activement au développement de projets open-source, dont le noyau Linux, nodejs, samba, Vagrant ou Docker. Pour PHP, en plus de développeurs participant au projet, une plate-forme d’intégration sur des tests autour de PHP a été mise en place (sur une cinquantaine de grosses applications, une fois par jour, en modes NTS et TS).

Enfin, Benjamin et Stéphane ont parlé de déploiement de symfony sur la plate-forme Azure de Microsoft, notamment facilitée par un bundle permettant de travailler directement en ligne de commandes, ainsi que par le biais des fichiers .user.ini ajoutés à PHP >= 5.3.

Mon avis : Microsoft s’ouvre à PHP et aux logiciels libres, de plus en plus depuis quelques années, et c’est une très bonne chose pour la communauté — qui essaye elle-aussi d’avancer petit à petit, en structurant ses processus et se rendant plus accessible.


Comment grapher et visualiser vos data ?

Grégoire PineauRésumé, Slides, Vidéo

Pour la conférence suivante, Grégoire nous a parlé de Graphite et des outils qui vont autour.

Pourquoi grapher les données ? Par exemple, pour voir si une fonctionnalité est utilisée, ou pour voir si une page est lente alors qu’elle est appelée fréquemment.

Quoi grapher ? Les comportements utilisateurs (pages les plus vues, temps de chargements, … ), santé de l’infrastructure (charge, espace disque, … ), mais aussi et surtout : données métier. En fait, tout pourrait être graphé.

Quand on dit “Graphite”, on pense fréquemment à une pile composée de plusieurs éléments :

  • Application (PHP par exemple) qui envoi des données à Carbon
  • Carbon : démon (protocole texte) qui reçoit les données
  • Whisper : base de données stockant celles-ci via des fichiers de taille constante (+ rapide) avec agrégation des anciennes valeurs
  • Graphite : exploitation des time-series via un affichage de graphes brut ou au travers de fonctions (moyenne, différences, … )

Carbon ne garde, sur un intervalle, que la dernière donnée reçue. On positionne donc devant un démon statsd (en node.js, qui écoute en UDP — donc sans blocage, quitte à perdre quelques paquets) chargé de regrouper les données reçues sur cet intervalle pour n’avoir en sortie qu’une seule valeur. Attention à la configuration : les fenêtres de sampling doivent être identiques du côté de statsd et du côté de Carbon, et l’agrégation par défaut de Carbon (moyenne) n’est pas toujours la bonne et est donc parfois à configurer.

La pile devient donc : Application → statsd → Carbon → Whisper → Graphite

Pour les applications en PHP, il existe 36 bibliothèques, dont celle développée par m6web ou celle de berbelei. Pour symfony, il existe un MetricsBundle qui permet de se brancher sur plein de listeners.

Quelques astuces et points à retenir :

  • Nommage : on peut utiliser des * dans les noms des métriques. Pour les compteurs, utiliser des verbes au passé, comme machin.created
  • Graphite fait beaucoup d’I/O ; il est recommandé de l’installer sur un SSD
  • La configuration est écrite à la création des fichiers et ne peut plus être modifiée par la suite

Pour la visualisation des données, le moteur Graphite est directement utilisable mais moche. Il existe plein de moteurs de dashboard, comme Grafana (basé sur Kibana, tout en HTML/JS/CSS, avec auto-refresh, time-range, query-builder, …).

Mon avis : Tout au long de la conférence, je me suis dit “ça, il faut qu’on le fasse ; et ça aussi ; et ça aussi !” — et depuis, j’ai commencé à brancher quelques métriques ici et là dans nos applications qui, aujourd’hui, ne donnent pas assez d’informations sur ce qu’elles font et comment elles sont utilisées.


REST dans le monde Symfony

William DurandRésumé, Slides, Vidéo

William a commencé par présenter les quatre niveaux du Richardon Maturity Model, en vue de nous montrer que ce que nous faisons généralement n’est pas tellement du REST, mais plus du “HTTP++” :

  • Niveau 0 : HTTP est un tunnel ; cela ressemble à du RPC
  • Niveau 1 : notion d’identité d’objet, les ressources distinctes étant identifiées par leur URI
  • Niveau 2 : introduction des verbes HTTP et des codes de statut, méthodes safes (cachables) et idempotentes (résultat indépendant du nombre d’exécutions).
  • Niveau 3 : découverte de services par le biais de relations et de liens. Négociation de contenus (type, contenu, encodage, langue), Hypermedia (Atom, HAL), HATEOAS (permet de trouver son chemin dans une API)

Il a ensuite passé en revue un ensemble de bundle permettant de créer des API REST (ou “HTTP++”) avec symfony :

  • JMSSerializer : graphes d’objets, documents XML ou JSON
  • FOSRestBundle : boite à outils de services et listeners
  • BazingaHateoasBundle : permet d’atteindre le niveau 3, on définit les relations via des annotations
  • TemplatedUriBundle : niveau 3 aussi ; RFC 6570 : URItemplated
  • NelmioApiDocBundle : génération de documents pour les API à partir de la phpdoc, support d’autres bundles connus
  • LiipCacheControlBundle : ajout de fonctionnalités liées au cache, header Cache-Control et aide pour les proxies — rendu obsolète par FOSHttpCacheBundle
  • Pour OAuth (qui est un protocole d’autorisation et pas d’identification / d’authentification) : HWIOAuthBundle et FOSOAuthServerBundle et BazingaOAuthServerBundle

Mon avis : Ne bossant que peu avec symfony en ce moment et ne mettant pas en place tellement d’API REST, j’ai un peu déconnecté pendant la seconde partie de cette présentation.


Transition agile 4 real @ meetic

Nicolas Kalmanovitz, Thomas DiavetRésumé, Slides, Vidéo

Nicolas et Thomas ont commencé par dresser un rapide historique de l’entreprise : en 2001, 20 personnes (avec du PHP/MySQL “codé en prod”), équipe réactive, les choses marchent pas mal. 2005 entrée en bourse, 2006 rachat de la société. 2011 : 400 personnes dont 100 à la DSI (qui ne produit pas plus que lorsqu’ils étaient 10), équipes qui se critiquent les unes les autres, les choses sont compliquées.

Conséquence : en 2011, volonté de rompre avec le cycle en V, de passer à des méthodes agiles en vue d’améliorer la communication et la productivité. En parallèle, beaucoup de dette technique, plate-forme en PHP 4 procédural, monolithique, “pas le temps d’upgrader”, avec des outils maison, des équipes en silos, … Le “modèle startup” ne fonctionne pas avec 400 personnes.

Sur le gros de la présentation, Thomas et Nicolas ont raconté comment Meetic a effectué cette transition :

  • Tout d’abord, aller vers l’agilité, en scrum (donc : sprints, rituels, démos, …) : approche structurée, simple, efficace. Facile à apprendre. Rupture (et volonté de changer) par rapport à l’ancienne méthode.
  • Equipe scrum : Product Owner (duo composé d’un chef de projet et d’un chef de produit), Scrum Master, développeurs, intégrateur, testeur (pour sécuriser le livrable dès le développement) : tout le monde ensemble.
  • Mise en place de 8 équipes scrum et d’une équipe kanban. Approche “on livre peu, mais on livre souvent”
  • Premiers changements : git + branches (au lieu de SVN et cris à travers l’open-space pour dire qui “lockait” un fichier) et tests manuels mutualisés (sur paquet de release, toutes les deux semaines)

Avec ces premiers pas, en 2012, les équipes ont gagné en autonomie, communication, priorisation et qualité ; l’entreprise a retrouvé la croissance.

Toutefois, il reste encore pas mal de problèmes :

  • de l’accompagnement est requis pour aller au bout de la méthode,
  • l’idée de “double-PO” entraine un chevauchement des responsabilités,
  • la méthode agile n’a été mise en place qu’à la R&D, entrainant un fossé qui grandit par rapport aux autres équipes (et finalement, on retombe dans les anciens problèmes),
  • le time to market n’est pas optimal : il est difficile d’itérer, les releases sont longues à tester et chaque problème impacte la release entière.

Pour aller plus loin, passage à Kanban, et pas qu’à la R&D mais à toute la DSI :

  • marche mieux sur les équipes qui étaient déjà agile (en scrum) que sur celles qui ne l’étaient pas du tout,
  • affichage de boards un peu partout dans toutes les équipes ⇒ visibilité de ce qui est en cours,
  • limite de WIP : flux plus rapide et plus fort, pour améliorer le time to market,
  • FIFO (simple, pas de priorisation) + métriques + gestion des points de contention ⇒ livraison continue

Résultat : temps de cycle de dev et de QA divisé par deux, releases plus fréquentes avec moins de bugs (livraisons plus petites).

Et pour aller jusqu’au bout :

  • tout le monde ensemble dans la même salle, avec livraisons quotidiennes, outils collaboratifs et sessions de tests collaboratifs,
  • intervention d’un consultant extérieur : même constat que l’équipe avait déjà fait. Equipes par fonctionnalités, projets pilotes et mesure des résultats, formation et conduite au changement.

Au final, et j’ai beaucoup aimé la conclusion : les équipes travaillent ensemble, en ayant retrouvé ce qui était bien dans la startup il y a dix ans. En bottom-up, c’est possible. Et sinon… La boîte disparait !

Mon avis : Un retour d’expérience intéressant — j’ai reconnu pas mal de points cités, pour les avoir déjà vécu — avec de bonnes pistes d’améliorations, pour peu que chacun ait envie d’avancer (et c’est souvent le cas).


Take a walk on the OPS side

Baptiste DUPAINRésumé, Slides, Vidéo

Baptiste a commencé par indiquer que m6web regroupe de l’ordre de 30 sites, incluant TV online et portails thématiques. Son métier est de faire passer le code de localhost à la production — sur des sites à forte charge.

La première partie de la conférence avait pour but de présenter quelques outils permettant de débugger une application PHP, en production, sans utiliser PHP lui-même :

  • sysdig : enregistre tout ce que fait le système et donc, ce que fait PHP
    • pour enregistrer sysdig -w php.scap (relecture avec -r pour appliquer des filtres)
    • permet aussi d’analyser des requêtes (sql, redis, … ) en live : sysdig -A proc.name=php5-fpm and evt.buffer contains SELECT
  • curl pour regarder les en-têtes HTTP (leurs applications retournent pas mal d’informations sous cette forme) : curl -Iv monsite.com -s | sort

Il est important de surveiller et mesurer ce qu’il se passe sur la plate-forme, typiquement à l’aide d’outils comme statsd et graphite (chez m6web : de l’ordre de 610,000 métriques et plus de 100 dashboard), ou encore :

  • collectd : récupère tout ce qui est système
  • sensu : monitoring distribué, où chaque serveur effectue ses vérifications et les expose à un démon central
  • seyren : alerting basé sur graphite
  • mayday : contextualisation des alertes
  • Oculus (à l’étude) : corrélation entre les problèmes (par exemple : “il y a des erreurs 500 ET un serveur MySQL est tombé”)
  • riemann (à l’étude) : alertes ou actions, en fonction de règles

Il faut aussi donner du sens à ses logs, qui contiennent plein d’informations qui peuvent permettre de comprendre un incident ou de vérifier des comportements :

  • Problématiques de formats : CSV, JSON, pipe-separated, binaire, … + compression dans certains cas
  • Traitement : synchrone ? asynchrone ?
  • Outils de traitement de logs (450 à 750 million de lignes par jour chez m6web. Environ 50% des informations sont utilisées. 40 informations par ligne de log nginx) :
    • Logs HTTP : roadster
    • PHP : scripts Python
    • MySQL : Anemometer
    • Firewall / syslog : Rsyslog central
    • grokdebug.herokuapp.com : pour parser des logs (genre stacktraces PHP) avec des regex
    • En cours d’étude : stack ELK
  • Outillage :
    • ElasticSearch + logstash + Kibana ⇒ pour prendre les logs, les indexer et les présenter
    • R pour les statistiques. En entrée : logs, SQL, CSV, … Quelques exemples d’usage : filtrer les appels lents, statistiques des pays les moins cachés.

En dernière partie, Baptiste a présenté quelques outils permettant de tester son application (si on passe sur Capital, on prend un gros pic de charge) :

  • Tout d’abord, trois types de tests :
    • test de charge = “est-ce que ça tient avec plein d’utilisateurs ?”
    • test de stress = “voir jusqu’où tient l’infra”
    • test de perfs = “qu’est-ce qui est acceptable pour l’expérience utilisateur ?”
  • Quelques outils :
    • Jmeter / gatling, Siege / Wrk, Tsung
    • gor : réplique du traffic (de production par exemple) en temps réel (vers un environnement de test par exemple)

Mon avis : Pas mal d’outils intéressants pour aller plus loin que PHP en lui-même. J’ai découvert sysdig pendant cette conférence et je l’ai déjà utilisé depuis pour trouver la cause d’un problème incompréhensible (sur une appli en JAVA, closed-source, peu documentée et sans log) ^^


Notre environnement de développement n’est plus un bizutage !

Pascal MARTIN, Julien FUSCORésumé, Slides

Pour terminer cette première journée du PHPTour, Julien et moi avons présenté les améliorations qui ont été apportées ces derniers mois à la mise en place de postes de développement chez TEA, The Ebook Alternative, où nous travaillons tous les deux.

Nous sommes parti du constat difficile à accepter que, lorsque j’ai rejoint TEA il y a un peu moins d’un an, il m’a fallu environ deux semaines pour installer mon poste. Nous avons ensuite expliqué comment nous utilisons désormais des outils comme Vagrant, Chef, ou Stow pour rendre cette installation plus facile et beaucoup plus rapide.

Nous avons au final gagné en maitrise de nos environnements, ceux-ci sont plus à jour (ce qui est indispensable si l’on souhaite, par exemple, monter en version de PHP), nous avons plus de liberté d’expérimenter, et l’intégration d’un nouvel arrivant à notre équipe n’est plus perçue comme un bizutage !

Je n’ai pas pris de note pendant la conférence (j’étais un peu occupé ;-) ), mais je vous encourage vivement à parcourir nos slides, en pensant à consulter les notes du présentateur : avant de diffuser ceux-ci, nous avons veillé à rendre ces notes aussi complètes que possibles, afin que les slides apportent un maximum d’informations à ceux qui n’auraient pas pu assister à notre présentation.

Mon avis : Ma première conférence en duo et la première fois que je présentais plus un retour d’expérience qu’un sujet vraiment technique — une expérience plutôt sympa pour moi, que je renouvellerai probablement dans le futur !


Mes notes du second jour de ce PHPTour 2014 devraient être publiées dans quelques jours — le temps de les mettre au propre ;-)


Par Pascal MARTIN le mercredi 25 juin 2014 1 commentaire

Les slides que Julien Fusco et moi avons utilisés comme support pour notre conférence « Notre env. de dév. n’est plus un bizutage ! » au PHPTour 2014 à Lyon sont disponibles en ligne : Notre env. de dév. n’est plus un bizutage !.

Pour ceux qui voudraient plus d’informations que les slides en eux-même, nous avons noté quelques points dans les notes du présentateur, accessibles via la touche s.

Et si vous étiez présent au PHPTour et que vous avez assisté à cette conférence, nous sommes bien entendu preneur de tout retour — vous pouvez retrouver toutes les conférences, dont celle-ci, sur joind.in.

Par Pascal MARTIN le mercredi 25 juin 2014 2 commentaires

Les slides que j’ai utilisés comme support pour ma conférence « PHP 5.3 → 5.6 : No pain but gain ! » au PHPTour 2014 à Lyon sont disponibles en ligne : PHP 5.3 → 5.6 : No pain but gain !.

Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s.

Et si vous étiez présent au PHPTour et que vous avez assisté à cette conférence, je suis bien entendu preneur de tout retour — vous pouvez retrouver toutes les conférences, dont celle-ci, sur joind.in.

Par Pascal MARTIN le lundi 2 juin 2014 1 commentaire

Lors de l’ApéroPHP lyonnais du 27 mai 2014, j’ai eu l’occasion de donner une présentation de HHVM et Hack. Après quelques mots sur le moteur d’exécution HHVM, j’ai passé en revue une partie des points que le langage Hack apporte par rapport à PHP.

Les slides que j’ai utilisés comme support sont disponibles en ligne1 : HHVM et Hack : slides de ma présentation à l’AperoPHP lyonnais du 27 mai.


Puisque le sujet a été abordé après la présentation, je profite de ce post pour rappeler que je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.


Et, aussi pour rappel : toutes les fin de mois2, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.



  1. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s

  2. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

Par Pascal MARTIN le lundi 30 septembre 2013

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

L’apéro du 25 septembre 2013 était un peu particulier, puisqu’il a réuni des développeurs PHP et des développeurs Python, un développeur de chacune des deux communautés présentant son langage aux développeurs de l’autre communauté.

Les slides que j’ai utilisés comme support pour présenter PHP aux développeurs Python sont disponibles en ligne2 : Présentation de PHP, pour des développeurs Python.

Les slides utilisés par Arthur Vuillard, qui a fait la présentation inverse, sont eux aussi disponibles : Python pour les dévs PHP.



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui n’ont pas pu assister à la présentation en live et voudraient plus d’informations que les slides en eux-même, j’ai noté plein de choses dans les notes du présentateur, accessibles via la touche [s]

Par Pascal MARTIN le lundi 29 juillet 2013

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

Lors de l’Apéro du 24 juillet 2013, j’ai eu l’occasion de donner une rapide présentation, où j’ai parlé des nouveautés apportées par PHP 5.5, la dernière version stable de notre langage de prédilection, qui a été publiée fin juin.

Les slides que j’ai utilisés comme support sont disponibles en ligne2 : PHP 5.5 : slides de ma présentation à l’AperoPHP lyonnais du 24 juillet.


Et puisque j’ai eu plusieurs discussions à ce sujet après la présentation :

  • Je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.
  • Les articles de mon blog sont bien sûr disponibles via un flux RSS ;-)



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s. Vous pouvez aussi vous reporter à la série d’articles que j’ai rédigée sur PHP 5.5 il y a quelques mois : j’y ai couvert, en détails, la plus grosse partie des nouveautés présentées lors de cet AperoPHP.