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 mardi 4 novembre 2014 3 commentaires

PHP 5.6 a été publiée le 28 août, un peu plus d’un an après la sortie de PHP 5.5 — essayant ainsi de se conformer au planning de releases qui prévoit, depuis PHP 5.4 il y a deux ans, la sortie d’une version mineure par an.

Dans la suite logique de ce qui avait été fait pour PHP 5.4 et 5.5 il y a respectivement deux ans et un an, PHP 5.6 apporte plusieurs nouveautés destinées à faciliter la vie des développeurs travaillant avec le langage, en particulier au niveau de la syntaxe de celui-ci — sans toutefois révolutionner quoi que ce soit1.

Je vais, au cours de cet article, passer en revue quelques-uns des points qui attirent mon attention vers cette toute nouvelle version.


Fonctions variadiques et unpacking d’arguments

Les deux éléments qui sont le plus souvent cités lorsque l’on parle des nouveautés introduites par PHP 5.6 vont de pair : il s’agit des fonctions variadiques et de l’unpacking d’arguments.

Une fonction variadique se déclare en utilisant le symbole ... avant le dernier nom de variable dans sa liste de paramètres :

function ma_fonction_variadique($a, $b, ... $params) {
    var_dump($a, $b, $params);
}

Elle s’appelle ensuite comme n’importe quelle fonction PHP, sans que l’appelant soit limité dans le nombre de paramètres qu’il peut passer :

ma_fonction_variadique(10, 20, 30, 40, 50);

La fonction recevra les deux paramètres qu’elle attendait — ici $a et $b — et tous ceux passés ensuite lors de l’appel se verront regroupés au sein du tableau $params. La sortie obtenue en exécutant cet exemple sera donc la suivante :

int(10)
int(20)
array(4) {
  [0] => int(30)
  [1] => int(40)
  [2] => int(50)
  [3] => int(60)
}

Inversement, l’unpacking de paramètres permet à un tableau de données d’être passé à une fonction sous forme de plusieurs paramètres. Par exemple, considérons la portion de code suivante :

function ma_fonction($a, $b, $c, $d) {
    var_dump($a, $b, $c, $d);
}

$tableau = [30, 40, 50, ];
ma_fonction(10, 20, ... $tableau);

Lors de son exécution, notre fonction ne recevra pas un ni deux paramètre(s), ni même cinq, mais quatre : le tableau spécifié en troisième position lors de l’appel sera découpé en plusieurs arguments, grâce à l’utilisation de l’opérateur ... (et la dernière valeur de ce tableau, 50, sera perdue puisqu’aucun paramètre du prototype de la fonction n’existe pour la recevoir).


Expressions scalaires pour les constantes

Même si l’évolution suivante semble plus mineure, je suis persuadé que c’est celle qui sera le plus rapidement et le plus largement utilisée2 : PHP 5.6 permet d’utiliser des expressions pour les valeurs de constantes lors de leur déclaration — ou comme valeurs par défaut pour les paramètres de fonctions.

En effet, il est désormais possible d’utiliser des écritures de ce type :

class MaClasse {
    const CTE_01 = 1 << 4;
    const CTE_02 = "CTE_01 vaut " . self::CTE_01 * 1.5;

    public function method($a, $b = 15*60*10) {
        // ...
    }
}

var_dump(MaClasse::CTE_02);

Vous reconnaîtrez que pouvoir utiliser 1 << 4 et 15*60*10 améliore grandement la lisibilité de cette portion de code — et que pouvoir construire la seconde constante en concaténant une chaîne avec une autre constante est fort appréciable !


use functions et use const

La fonctionnalité d’espaces de noms introduite avec PHP 5.3 incluait un mot-clef use, qui permet de faire référence à une classe d’un autre espace de noms sans avoir à passer par son nom pleinement qualifié, ainsi que d’aliaser des classes.

PHP 5.6, par le biais de use function, permet d’effectuer la même manipulation pour des fonctions.

Par exemple, considérons un fichier autrenamespace.php contenant cette portion de code :

<?php
namespace autrenamespace;

function fonction_autrenamespace() {
    var_dump(__FUNCTION__);
}

Ce fichier et cette fonction peuvent désormais être utilisés depuis un autre fichier de la manière suivante :

<?php
namespace monnamespace;
require __DIR__ . '/autrenamespace.php';

use function \autrenamespace\fonction_autrenamespace;

fonction_autrenamespace();

Avant PHP 5.6 et sans disposer de use function, il aurait fallu utiliser, systématiquement, le nom pleinement qualifié de la fonction pour pouvoir l’appeler :

\autrenamespace\fonction_autrenamespace();

Suivant la même principe, use const a aussi été ajouté à PHP 5.6, pour répondre à cette problématique pour l’emploi de constantes.


Et plein d’autres améliorations !

Quelques autres évolutions, que je ne détaillerai pas réellement ici, font aussi leur arrivée avec PHP 5.6.

Un nouvel opérateur de puissance a été introduit : **. Je doute qu’il soit très souvent employé, mais il permettra de rendre certaines opérations plus lisibles que lorsque nous devions passer par la fonction pow().

Les extensions PHP ont désormais la possibilité de surcharger les opérateurs pour les classes qu’elles définissent. Ce principe est déjà utilisé par l’extension GMP, menant à une écriture beaucoup plus intuitive (par rapport à l’emploi de fonctions) des opérations réalisées avec des grands nombres. Notez que la surcharge d’opérateurs n’est pas rendue possible à l’espace utilisateur.

De nombreuses améliorations ont été apportées au niveau de SSL/TLS, visant à améliorer la sécurité des applications développées avec PHP (en particulier, lors de l’utilisation de paramètres par défaut — qui sont souvent ceux employés par les développeurs peu expérimentés en matière de sécurité). A ce sujet, vous pouvez lire la section Changements apportés à OpenSSL pour PHP 5.6 du manuel.

Et, pour finir :

  • PHP 5.6 intègre le débogueur phpdbg — qui n’est pas encore supporté par les IDE les plus répandus, ce qui limite pour l’instant son utilité.
  • L’encodage par défaut est défini par la directive default_charset qui vaut désormais par défaut UTF-8. Il est maintenant utilisé par les fonctions qui dépendent de l’encodage, comme htmlspecialchars().
  • Un support asynchrone a été mis en place pour ext/pgsql.


Quelques risques potentiels ?

Cette nouvelle version mineure de PHP respecte assez bien le principe qui veut qu’une version mineure n’introduise pas — ou peu — de problème de compatibilité par rapport à la version précédente.

Toutefois, quelques points méritent qu’on leur prête attention — je pense en particulier à ceux-ci :

  • La vérification de certificats SSL qui est activée par défaut posera probablement quelques problèmes, en particulier en environnement de développement où nous travaillons souvent avec des certificats auto-signés.
  • Plusieurs fonctions mcrypt_*() échoueront si on leur spécifie des clefs ou IVs incorrects — ce qui est une très bonne chose en termes de sécurité, puisque cela force l’emploi de paramètres corrects (au lieu de se rabattre sur des valeurs peu sûres).
  • Enfin, l’upload de fichiers avec curl en utilisant la syntaxe @fichier n’est désormais possible que si l’option CURLOPT_SAFE_UPLOAD est renseignée à false : il convient de préférer l’emploi de CURLFile.
  • Les ressources GMP sont désormais des objets — elles ne doivent donc, en particulier, plus être validées à l’aide de is_resource().
  • always_populate_raw_post_data génère désormais une erreur de niveau E_DEPRECATED et php://input devrait être utilisé au lieu de $HTTP_RAW_POST_DATA, qui sera supprimé dans le futur.

Plusieurs de ces points sont liés à des problématiques de sécurité — ce qui explique que ces changements aient été acceptés pour une version mineure.


Bien sûr, les différents éléments abordés au cours de cet article ne constituent pas une liste exhaustive et correspondent principalement à ce qui attire mon attention vers PHP 5.6. Avant d’attaquer une montée de version de votre côté, pensez à consulter le guide de migration de PHP 5.5 à 5.6 !

Comme pour PHP 5.5 l’an dernier, je suis content de voir une nouvelle version qui apporte plusieurs nouveautés intéressantes, sans qu’elle ne constitue pour autant une révolution qui rendrait son adoption difficile.

Je conclurai en disant que j’ai hâte de pouvoir réellement me pencher sur la migration PHP 5.5 → 5.6 de quelques unes de mes applications, j’espère sur les prochains mois !

Et vous, quand prévoyez-vous de passer à PHP 5.6 ?



  1. après tout, PHP 5.6 est une version mineure : la compatibilité ascendante est primordiale pour qu’elle soit adoptée par les utilisateurs ! 

  2. Il m’arrive encore occasionnellement, y compris en PHP 5.5, d’être désagréablement surpris de ne pouvoir utiliser d’expression scalaire dans mes déclarations de constantes — alors que je sais depuis des années que ce n’est pas supporté ! 

Par Pascal MARTIN le mercredi 29 octobre 2014

Cet article est aussi disponible en français.

You can follow me @pascal_martin, and there is an RSS feed of the posts I write in English.

I have collected data and written about usage of each PHP versions a few times already — up until now, always in French: this is the first time I’m doing this in English. The first time I’ve done this was in September 2011 and the most recent one was almost one year ago, in November 2013. At that time, PHP 5.2 was still representing 34.4% of PHP installations, with PHP 5.3 ahead with 48.7%.

The data presented in this post have been collected during the week-end of October 2014 18th. Stable versions of PHP are PHP 5.4.34 (which is called old-stable), PHP 5.5.18 and PHP 5.6.2. PHP 5.3 is not maintained anymore, since August 2014 14th and PHP 5.2 has been out of support for almost 4 years.


Web Servers

Before talking about PHP versions, here’s the list of web-servers I identified the most often while collecting data:

  • Apache: 5,644,243 — 58.65%
  • IIS: 1,496,967 — 15.56%
  • nginx: 1,410,170 — 14.65%
  • Others: 456,985 — 4.75%
  • GSE: 312,448 — 3.25%
  • cloudflare-nginx: 134,131 — 1.39%
  • LiteSpeed: 107,378 — 1.12%
  • Oversee Turing v1.0.0: 61,127 — 0.64%

As a graph only representing the first few results:

Apache is still in the first place — and by far — but it loses ground bit by bit, especially to nginx, which rose in one year from 7.9% to 14.8%. IIS remains at the second place, but could very well fall down one step before my next post!


Major versions of PHP

When it comes to major versions of PHP, there is no real surprise:

  • PHP 3: 415 — 0.02%
  • PHP 4: 106,866 — 4.15%
  • PHP 5: 2,470,731 — 95.84%
  • PHP 6: 36 — 0.00%
  • PHP 7: 3 — 0.00%

PHP 5 is first in line, far from the other versions1 — which is, let’s admit it, quite logical.

Still, a great number of servers are still running PHP 4 — its last version having been released in August 2008.


Minor versions of PHP

Going on with minor versions of PHP, for PHP >= 3.x and PHP <= 7.x and only keeping versions that have been detected at least 10 times, we’d get the following data:

  • PHP 3.0: 402 — 0.02%
  • PHP 3.2: 12 — 0.00%
  • PHP 4.0: 834 — 0.03%
  • PHP 4.1: 1,823 — 0.07%
  • PHP 4.2: 1,967 — 0.08%
  • PHP 4.3: 22,537 — 0.87%
  • PHP 4.4: 79,702 — 3.09%
  • PHP 5.0: 2,500 — 0.10%
  • PHP 5.1: 39,144 — 1.52%
  • PHP 5.2: 586,490 — 22.75%
  • PHP 5.3: 1,141,116 — 44.26%
  • PHP 5.4: 583,423 — 22.63%
  • PHP 5.5: 113,582 — 4.41%
  • PHP 5.6: 4,464 — 0.17%
  • PHP 6.0: 34 — 0.00%

And, as a graph:

The first interesting thing is that PHP 5.3, which has not been supported anymore for a few month, is still the most used PHP version with 44.3%, far ahead of PHP 5.2 and 5.4 which are pretty much each as used as the other, with 22.8% and 22.6%.

PHP 5.5, released in June 2013, only gets the fourth place, far behind the other three versions. And PHP 5.6, the stable version released at the end of August 2014, is pretty much invisible on this chart, with a really small 0.2% of all identified versions.

With more than 2/3 of all servers running versions of PHP that are no longer officially maintained2, I’m coming back to what I say each time I take a look at those numbers: recent versions of PHP really are not adopted fast enough and too many servers aren’t updated often enough!


Patch versions of PHP

Finally, if we take a look at patch versions of PHP 5.x, only displaying in this list the versions that are used the most3, we get the following data:

  • Pour PHP 5.0: the most used version is 5.0.4, with 0.06%.
  • Pour PHP 5.1: PHP 5.1.6 gets the first place, at 1.40%.
  • Pour PHP 5.2: here are versions with more than 0.5%:
    • 5.2.4: 16,109 — 0.65%
    • 5.2.5: 12,966 — 0.52%
    • 5.2.6: 58,772 — 2.38%
    • 5.2.9: 24,504 — 0.99%
    • 5.2.10: 19,529 — 0.79%
    • 5.2.13: 16,225 — 0.66%
    • 5.2.14: 15,734 — 0.64%
    • 5.2.17: 376,304 — 15.23%
  • Pour PHP 5.3: here too, versions with more than 0.5%:
    • 5.3.2: 36,505 — 1.48%
    • 5.3.3: 249,448 — 10.10%
    • 5.3.6: 16,333 — 0.66%
    • 5.3.8: 30,140 — 1.22%
    • 5.3.10: 108,865 — 4.41%
    • 5.3.13: 33,579 — 1.36%
    • 5.3.15: 12,839 — 0.52%
    • 5.3.23: 16,950 — 0.69%
    • 5.3.26: 28,704 — 1.16%
    • 5.3.27: 91,395 — 3.70%
    • 5.3.28: 210,465 — 8.52%
    • 5.3.29: 195,469 — 7.91%
  • Pour PHP 5.4: here are versions at more that 0.5% (and the last released version):
    • 5.4.4: 82,126 — 3.32%
    • 5.4.23: 13,759 — 0.56%
    • 5.4.24: 13,475 — 0.55%
    • 5.4.25: 13,650 — 0.55%
    • 5.4.26: 17,978 — 0.73%
    • 5.4.27: 24,689 — 1.00%
    • 5.4.28: 20,568 — 0.83%
    • 5.4.29: 27,846 — 1.13%
    • 5.4.30: 43,200 — 1.75%
    • 5.4.31: 66,772 — 2.70%
    • 5.4.32: 104,195 — 4.22%
    • 5.4.33: 77,474 — 3.14%
    • 5.4.34: 2,023 — 0.08%
  • Pour PHP 5.5:
    • 5.5.0: 953 — 0.04%
    • 5.5.1: 691 — 0.03%
    • 5.5.2: 309 — 0.01%
    • 5.5.3: 7,059 — 0.29%
    • 5.5.4: 1,005 — 0.04%
    • 5.5.5: 913 — 0.04%
    • 5.5.6: 1,561 — 0.06%
    • 5.5.7: 1,710 — 0.07%
    • 5.5.8: 1,374 — 0.06%
    • 5.5.9: 31,366 — 1.27%
    • 5.5.10: 2,287 — 0.09%
    • 5.5.11: 2,969 — 0.12%
    • 5.5.12: 3,031 — 0.12%
    • 5.5.13: 3,059 — 0.12%
    • 5.5.14: 5,117 — 0.21%
    • 5.5.15: 5,343 — 0.22%
    • 5.5.16: 23,864 — 0.97%
    • 5.5.17: 19,893 — 0.81%
    • 5.5.18: 1,054 — 0.04%
  • Et pour PHP 5.6:
    • 5.6.0: 2,743 — 0.11%
    • 5.6.1: 1,026 — 0.04%
    • 5.6.2: 692 — 0.03%

As a chart presenting all 5.x.y versions at more than 0.5% or with a version number greater than 5.4.04, we’d get:

Looking at this chart and the corresponding data, a few versions seem used more than the others:

  • PHP 5.1.6 (released in August 2006) is still here, probably because it was the version available for some entreprise (or derived) distributions (Redhat Entreprise, or CentOS 5).
  • For PHP 5.2:
    • PHP 5.2.17 (released in January 2011) is still the most used patch version of PHP, even considering all minor versions, with 15.23%.
    • PHP 5.2.6 (released in May 2008) comes on second place amongst 5.2.x versions. It was the default version of Debian Lenny and is still at 2.38%.
  • For PHP 5.3:
    • PHP 5.3.3 is the most used 5.3 version, with 10.10%. It’s the version of Debian Squeeze or CentOS 6.
    • PHP 5.3.10 came down from 7.2% to 4.41% in the last year: it was the default version of Ubuntu Precise (12.04LTS).
    • The three most recent versions of PHP 5.3 come after that, at 3.70% for PHP 5.3.27, 8.52% for PHP 5.3.28 and 7.91% for PHP 5.3.29 — updates to these versions probably correspond to hosting services that tend to use the most recent patch version available, but don’t want to update to the next (and maintained) minor version.
  • For PHP 5.4:
    • PHP 5.4.4 is number two for the 5.4 branch, with 3.32%. It’s the version of PHP of Debian Wheezy.
    • The last four releases of 5.4 are at 2.70% for PHP 5.4.31, 4.22% for PHP 5.4.32 and 3.14% for PHP 5.4.33 — PHP 5.4.34, which has been released only a few days ago, is for now only at a pretty shy 0.08%.
  • For PHP 5.5:
    • 5.5.3 is at 0.29%. It’s the default version of Ubuntu Saucy (13.10).
    • The first place, for the 5.5 branch, goes to 5.5.9 with its 1.27%: it’s the version used by Ubuntu Trusty (14.04LTS)
    • The most recent versions are at 0.97% for PHP 5.5.16, 0.81% for PHP 5.5.17 and 0.04% for PHP 5.5.18.
  • PHP 5.6 makes a shy debut here, with 0.11% for PHP 5.6.0, 0.04% for PHP 5.6.1 and 0.03% for PHP 5.6.2.

It’s nice to see that, for each minor version, the most recent releases are, in general, the ones used the most — even if many servers keep using the default versions provided by their distributions (which, for some, backport security fixes of later versions, without changing the version number of PHP).


Evolution

I will not try to write a long analysis of “why” those numbers are what they are: it’s up to you, if you want to comment on the fact that old and obsolete versions are still used and that updates are not applied often enough…

That being said, as this is not the first time I do this kind of collection of data about installed PHP versions, I thought it might be interesting to draw a chart showing the evolution of these versions. As a consequence, the following chart presents the evolution of all minor versions of PHP, since September 20115:

PHP 5.5 and PHP 5.6, the current stable releases of PHP, are barely visible on this chart… It’s up to us to ensure this changes!


Method and amounts of data

To finish this post, here are a few notes about the way I got the data presented here:

  • I started with a list of more than 12 million domain names (from Alexa’s top 1M, wikipedia dumps, …).
  • Of those 12M domains, 10.4M have been resolved to IP addresses — the remaining 1.6M were probably too old and not valid anymore.
  • Amongst the 10.4 millions of HTTP requests I’ve done, around 25% of all responses have been identified as generated by PHP. More precisely, I’ve identified 2,578,278 responses as corresponding to some kind of PHP.

With this relatively high amount of data, statistics presented earlier should be quite correct, or, at least, give results and numbers close to reality…

The informations about software and PHP versions have been obtained from the X-Powered-By and Server headers of HTTP responses, after a HEAD request, for each one of the 10.4M domains, on domain.tld, with a fallback on www.domain.tld in case the first one failed.

If you want more informations, you can take a look at the two long comments — in French — I posted a while back, to answer to a few questions that had been asked to me: the first one, and the second one.


And, you, are you using an up-to-date version of PHP?



  1. As PHP 5 is far ahead other major versions, I won’t do a graph of those: it wouldn’t be of much interest! 

  2. Some distributions (especially the enterprises-oriented ones) backport security fixes to older PHP versions. Which means some PHP 5.2 and PHP 5.3 servers might not suffer from security problems that have been fixed only after official support ended for those versions. 

  3. With about one patch release each month on two maintained branches, the full list of path versions is getting a bit long — which means I will not reproduce it in full. 

  4. With that many patch versions of PHP, I chose to only display on this chart, so it remains easy to read, versions with more than 0.5% for the oldest ones, and all versions since PHP 5.4.0 (which means all patch versions of minor versions currently maintained). 

  5. Data presented on the evolution chart are in percents, to be independent of the number of hosts, which changes each time. Please note I haven’t collected those data regularly in time, which means there is not the same amount of time between each date! 

Par Pascal MARTIN le mardi 28 octobre 2014 2 commentaires

This post is also available in English.

J’ai plusieurs fois collecté des statistiques à propos de l’utilisation des différentes versions de PHP : la première fois était en septembre 2011 et la plus récente était il y a presque un an, en novembre 2013. À ce moment là, PHP 5.2 représentait encore 34.4% des installations de PHP, avec PHP 5.3 en tête à 48.7%.

Les données présentées dans cet article ont été collectées le week-end du 18 octobre 2014. Les versions stables de PHP sont alors PHP 5.4.34 (qui est qualifiée de old-stable), PHP 5.5.18 et PHP 5.6.2. PHP 5.3 n’est plus maintenue depuis le 14 août 2014 et PHP 5.2 n’est plus supportées depuis presque 4 ans.


Serveurs Web

Avant de commencer à parler de versions PHP, voici la liste des serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

  • Apache : 5,644,243 — 58.65%
  • IIS : 1,496,967 — 15.56%
  • nginx : 1,410,170 — 14.65%
  • Autres : 456,985 — 4.75%
  • GSE : 312,448 — 3.25%
  • cloudflare-nginx : 134,131 — 1.39%
  • LiteSpeed : 107,378 — 1.12%
  • Oversee Turing v1.0.0 : 61,127 — 0.64%

Sous forme graphique, en ne représentant que les premiers résultats :

Apache est toujours en première place — et de loin — mais il perd petit à petit du terrain, principalement au profit de nginx, qui est passé en un an de 7.9% à 14.8%. IIS reste en seconde place, mais pourrait bien descendre d’un cran d’ici à ma prochaine collecte de données !


Versions majeures de PHP

Aucune surprise au niveau des versions majeures de PHP :

  • PHP 3 : 415 — 0.02%
  • PHP 4 : 106,866 — 4.15%
  • PHP 5 : 2,470,731 — 95.84%
  • PHP 6 : 36 — 0.00%
  • PHP 7 : 3 — 0.00%

PHP 5 est en tête, de loin1 — ce qui est, admettons-le, fort logique.

Toutefois, un nombre important de serveurs sont encore sous PHP 4, dont la dernière version a été publiée en août 2008.


Versions mineures de PHP

Si on passe aux versions mineures de PHP, pour PHP >= 3.x et PHP <= 7.x et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

  • PHP 3.0 : 402 — 0.02%
  • PHP 3.2 : 12 — 0.00%
  • PHP 4.0 : 834 — 0.03%
  • PHP 4.1 : 1,823 — 0.07%
  • PHP 4.2 : 1,967 — 0.08%
  • PHP 4.3 : 22,537 — 0.87%
  • PHP 4.4 : 79,702 — 3.09%
  • PHP 5.0 : 2,500 — 0.10%
  • PHP 5.1 : 39,144 — 1.52%
  • PHP 5.2 : 586,490 — 22.75%
  • PHP 5.3 : 1,141,116 — 44.26%
  • PHP 5.4 : 583,423 — 22.63%
  • PHP 5.5 : 113,582 — 4.41%
  • PHP 5.6 : 4,464 — 0.17%
  • PHP 6.0 : 34 — 0.00%

Et sous forme d’un graphique :

Il est intéressant de noter que PHP 5.3, qui n’est plus maintenu depuis quelques mois, est toujours la version de PHP la plus utilisée avec 44.3%, loin devant PHP 5.2 et 5.4 qui sont quasiment à égalité, respectivement à 22.8% et 22.6%.

PHP 5.5, publiée en juin 2013, n’arrive qu’en quatrième place, loin derrière les trois autres versions. Et PHP 5.6, qui est la version stable publiée fin août 2014 fait une entrée timide dans ce classement, avec un petit 0.2% des installations identifiées.

Avec plus de deux-tiers des serveurs qui tournent sur des versions de PHP qui ne sont plus officiellement maintenues2, j’en reviens à ce que j’écris à chaque fois que je regarde ces chiffres : les versions récentes de PHP ne sont que beaucoup trop lentement adoptées et trop de serveurs ne sont pas suffisamment mis à jour !


Versions releases de PHP

Enfin, si on descend au niveau des versions release de PHP 5.x, en ne conservant pour l’affichage de cette liste que les versions qui sont le plus souvent utilisées3, on obtient les données suivantes :

  • Pour PHP 5.0 : la version la plus représentées est 5.0.4, avec 0.06% des installations.
  • Pour PHP 5.1 : PHP 5.1.6 remporte la première place, avec 1.40%.
  • Pour PHP 5.2 : voici les versions à plus de 0.5% :
    • 5.2.4 : 16,109 — 0.65%
    • 5.2.5 : 12,966 — 0.52%
    • 5.2.6 : 58,772 — 2.38%
    • 5.2.9 : 24,504 — 0.99%
    • 5.2.10 : 19,529 — 0.79%
    • 5.2.13 : 16,225 — 0.66%
    • 5.2.14 : 15,734 — 0.64%
    • 5.2.17 : 376,304 — 15.23%
  • Pour PHP 5.3 : ici aussi, voici les versions à plus de 0.5% :
    • 5.3.2 : 36,505 — 1.48%
    • 5.3.3 : 249,448 — 10.10%
    • 5.3.6 : 16,333 — 0.66%
    • 5.3.8 : 30,140 — 1.22%
    • 5.3.10 : 108,865 — 4.41%
    • 5.3.13 : 33,579 — 1.36%
    • 5.3.15 : 12,839 — 0.52%
    • 5.3.23 : 16,950 — 0.69%
    • 5.3.26 : 28,704 — 1.16%
    • 5.3.27 : 91,395 — 3.70%
    • 5.3.28 : 210,465 — 8.52%
    • 5.3.29 : 195,469 — 7.91%
  • Pour PHP 5.4 : voici les versions à plus de 0.5% (et la dernière version publiée) :
    • 5.4.4 : 82,126 — 3.32%
    • 5.4.23 : 13,759 — 0.56%
    • 5.4.24 : 13,475 — 0.55%
    • 5.4.25 : 13,650 — 0.55%
    • 5.4.26 : 17,978 — 0.73%
    • 5.4.27 : 24,689 — 1.00%
    • 5.4.28 : 20,568 — 0.83%
    • 5.4.29 : 27,846 — 1.13%
    • 5.4.30 : 43,200 — 1.75%
    • 5.4.31 : 66,772 — 2.70%
    • 5.4.32 : 104,195 — 4.22%
    • 5.4.33 : 77,474 — 3.14%
    • 5.4.34 : 2,023 — 0.08%
  • Pour PHP 5.5 :
    • 5.5.0 : 953 — 0.04%
    • 5.5.1 : 691 — 0.03%
    • 5.5.2 : 309 — 0.01%
    • 5.5.3 : 7,059 — 0.29%
    • 5.5.4 : 1,005 — 0.04%
    • 5.5.5 : 913 — 0.04%
    • 5.5.6 : 1,561 — 0.06%
    • 5.5.7 : 1,710 — 0.07%
    • 5.5.8 : 1,374 — 0.06%
    • 5.5.9 : 31,366 — 1.27%
    • 5.5.10 : 2,287 — 0.09%
    • 5.5.11 : 2,969 — 0.12%
    • 5.5.12 : 3,031 — 0.12%
    • 5.5.13 : 3,059 — 0.12%
    • 5.5.14 : 5,117 — 0.21%
    • 5.5.15 : 5,343 — 0.22%
    • 5.5.16 : 23,864 — 0.97%
    • 5.5.17 : 19,893 — 0.81%
    • 5.5.18 : 1,054 — 0.04%
  • Et pour PHP 5.6 :
    • 5.6.0 : 2,743 — 0.11%
    • 5.6.1 : 1,026 — 0.04%
    • 5.6.2 : 692 — 0.03%

Sous forme d’un graphique reprenant toutes les versions 5.x à plus de 0.5% d’utilisation ou dont le numéro est supérieur ou égal à 5.4.04, on obtient :

En consultant ce graphique et les chiffres correspondant, on identifie plusieurs tendances et plusieurs versions qui semblent plus utilisées que d’autres :

  • PHP 5.1.6 (qui a été publiée en août 2006) est toujours représentée, probablement parce que c’était la version disponible sur certaines distributions entreprise ou dérivées (Redhat Entreprise, ou CentOS 5).
  • Pour PHP 5.2 :
    • PHP 5.2.17 (publiée en janvier 2011) est encore la version release de PHP la plus utilisée, toutes versions mineures confondues, avec 15.23%.
    • PHP 5.2.6 (publiée en mai 2008) arrive en seconde position parmi les versions 5.2.x. Il s’agissait de la version proposée par défaut sous Debian Lenny et elle représente encore 2.38%.
  • Pour PHP 5.3 :
    • PHP 5.3.3 est la version la plus utilisée de la branche 5.3, avec 10.10%. Il s’agit de la version fournie sous Debian Squeeze ou CentOS 6.
    • PHP 5.3.10 est descendue de 7.2% à 4.41% en presque un an : il s’agissait de la version distribuée par Ubuntu Precise (12.04LTS).
    • Viennent ensuite les trois versions les plus récentes de PHP 5.3, à 3.70% pour PHP 5.3.27, 8.52% pour PHP 5.3.28 et 7.91% pour PHP 5.3.29 — les montées vers ces versions doivent correspondre à des hébergeurs qui ont tendance à utiliser la version release la plus à jour disponible, sans pour autant souhaiter effectuer une montée de version mineure (vers une version maintenue, s’entend).
  • Pour PHP 5.4 :
    • PHP 5.4.4 est numéro deux des versions 5.4, avec 3.32%. C’est la version fournie par Debian Wheezy.
    • Les quatre dernières versions de 5.4 sont quant à elles à 2.70% pour PHP 5.4.31, 4.22% pour PHP 5.4.32 et 3.14% pour PHP 5.4.33 — PHP 5.4.34, qui est sortie il y a quelques jours, n’étant pour l’instant qu’à un timide 0.08%.
  • Pour PHP 5.5 :
    • Pour ce qui est de PHP 5.5, la version 5.5.3 est à 0.29%. C’est la version fournie par défaut pour Ubuntu Saucy (13.10).
    • La première place, pour la branche 5.5, revient à PHP 5.5.9 avec ses 1.27% : c’est la version distribuée par Ubuntu Trusty (14.04LTS)
    • Les versions les plus récentes sont quant à elles à 0.97% pour PHP 5.5.16, 0.81% pour PHP 5.5.17 et 0.04% pour PHP 5.5.18.
  • PHP 5.6 fait une timide apparition, avec 0.11% de PHP 5.6.0, 0.04% de PHP 5.6.1 et 0.03% de PHP 5.6.2.

Il est agréable de constater que, sur chaque version mineure, les releases les plus récentes sont, globalement, les plus utilisées — même si de nombreuses installations restent sur les versions fournies par les distributions (qui, pour certaines, intègrent des correctifs de sécurité de versions supérieures, sans pour autant changer de numéro de version).


Évolution

Fidèle à mon habitude, je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présentés ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Cela dit, puisque ce n’est pas la première fois que j’effectue ce processus de collecte de statistiques à propos des versions de PHP utilisées, je me suis dit qu’il pouvait être intéressant de tracer un graphe représentant l’évolution de ces utilisations.

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 20115 :

PHP 5.5 et PHP 5.6, les versions actuellement stables de PHP, sont à peine visible… À nous de faire en sorte que cela change !


Méthode et volumes de données

Pour terminer, voici quelques brèves notes à propos de la façon dont j’ai obtenu les chiffres présentés ici :

  • Je suis parti d’une liste de plus de 12 millions de noms de domaines (obtenue depuis le top 1M Alexa, des dumps wikipedia, …).
  • Sur ces 12M domaines, 10.4M ont pu être résolus vers une adresse IP — les 1.6M restant étant probablement trop vieux et plus valides.
  • Sur les 10.4 millions de requêtes HTTP effectuées, environ 25% des réponses ont été identifiées comme générées par du PHP. Plus précisément, j’ai identifié 2,578,278 réponses comme correspondant à du PHP.

Avec ce nombre relativement conséquent de réponses, les statistiques présentées plus haut devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…

Les informations de logiciels et de versions de PHP ont été obtenues en analysant les en-têtes X-Powered-By et Server des réponses HTTP obtenues en effectuant une requête HEAD, pour chacun des 10.4M de domaines, sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Pour ceux qui voudraient plus de détails, je vous invite à lire deux commentaires romans que j’avais postés suite à l’article de janvier 2013, en réponses à quelques questions qui m’avaient été posées : le premier, et le second.


Et vous, utilisez-vous une version à jour de PHP ?



  1. PHP 5 étant loin devant toutes les autres versions majeures, je ne présenterai pas de graphique : il n’aurait pas un grand intérêt ! 

  2. Certaines distributions (principalement celles orientées entreprise) backportent des correctifs de sécurités vers les vieilles versions de PHP. Certains installations en PHP 5.2 ou 5.3 ne souffrent donc peut-être pas des failles de sécurité corrigées après l’arrêt de la maintenance officielle de ces versions. 

  3. À raison d’environ une release par mois sur deux branches maintenues en parallèle, la liste complète des versions releases se fait un peu longue — je ne la reproduit donc pas intégralement ici. 

  4. Avec autant de versions release de PHP, j’ai choisi de n’afficher sur ce graphique, pour qu’il reste lisible, que les versions à plus de 0.5% pour les plus anciennes et toutes les versions depuis PHP 5.4.0 (pour présenter l’ensemble des versions release de versions mineures aujourd’hui maintenues). 

  5. Les chiffres présentés sur le graphique d’évolution sont en pourcentages, afin d’être indépendants du nombre d’hôtes interrogés, qui varie à chaque série de collectes. Notez que les collectes n’ont pas été effectuées de manière très régulière dans le temps ; il n’y a donc pas le même écart entre chaque date !