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 mardi 1 juillet 2014 1 commentaire

Cet article est aussi disponible en français.

Before really talking about internals@: some of you have come see me during the PHPTour (a 2-days event organized in France by the AFUP — it took place this year on June 23rd and 24th in Lyon) to speak about this series of posts I’ve been writing for about a year and a half (about 6 months in English), thank me and encourage me, telling me this allows you to keep track of what’s going on around PHP’s development. Thanks!


June 2014 came back down to a reasonable 493 messages on PHP’s internals@ mailing-list, after a month of May with more than 800 mails, including some long discussions about phpng.

As a graph representing the number of mails per month for the last three years, we’d get (the full history since 1998 is available here):

Number of mails on internals@ these last three years


The release of PHP 5.6 keeps getting closer: on June 6th, Ferenc Kovacs announced beta 4, which should be the last version before the RC phase.

Indeed, two weeks later, PHP 5.6’s firt Release Candidate has been published!


According to RFC: Define PHP 5.3 end of life, the End Of Life of PHP 5.3 is fixed to one year after the release of PHP 5.5 — which took place on June 20th, 2013.

As the last bugfix release of PHP 5.3 has been published six months ago, Stas Malyshev said a last release would be published soon (probably in July), to fix a few remaining bugs.

Ferenc Kovacs noted it would be useful to insist on the fact there will not be any additional future release of PHP 5.3 — and it’s more than about time for people to switch to more recent versions!


Pierre Joye posted about a new tool which is currently being developed, to install PHP extensions: RFC: Pickle.

The mid/long term idea is to remove the pecl PEAR command, and for composer to be able to work with this new pickle tool to install extensions.


Right at the beginning of the month, Andrea Faulds wrote an RFC nammed “Bare Name Array”, which would bring two new syntaxes, a bit shorter than those we use today (like [] is shorter than array()), to work with arrays in PHP.

The first one would allow us to write arrays this way, without changing the current behavior of =>:

$tableau = [
    clef1: "valeur 1",
    clef2: 42,
    clef3: [
        sub1: 25,
        sub2: "aaa",
    ],
];

Later during this conversation, Adam Harvey asked if going farther was possible, setting up something like Ruby’s symbols — which would not be easy in PHP, especially when it comes to syntax.

The second idea would allow us to access array elements this way:

echo $tableau:>clef3:>sub2;

As these two proposals are quite distinct, Levi Morrison noted they should be split in two separate RFCs — and Andrea Faulds quickly created them: RFC: Bare Name Array Literal and RFC: Bare Name Array Dereference.

Votes on these RFCs have been opened after a few additional mails — and they both have been rejected (the first one with 14 “no” votes and 3 “yes” votes, and the second one with 15 “no” votes and no “yes” vote).

Basically, it seems those changes of syntax were not necessary and made the language more complex — having two syntaxes with distinct behaviors was not intuitive.


Last month (in May), a change related to serialization made its way to PHP 5.4.29 and 5.5.13. It caused a break in components such as Doctrine or PHPUnit, on a specific case sometimes used to create objects without the class’ constructor being invoked, (which is kind of a hack, especially when used on internal classes).

Both projects have quickly been updated, but Jakub Zelenka noted it would be interesting to quickly release a fix at PHP’s level itself, both for developers or other projects that might be suffering from the same problem.

As Benjamin Eberlei then said, if PHP was tested on a couple of projects and libraries (and not only on PHP’s tests themselves) before each release, this kind of regression could have been avoided1. That being said, as Johannes Schlüter answered, it would be helpful if developers using PHP were testing RC versions and posting feedback a bit more — which is not always easy and could be made easier if nightly versions of PHP were available on Travis CI.

The discussion about the solution that should be implemented mig/long-term lasted a bit of time — during which Travis CI switched to the last version of PHP, causing failures in PHPUnit tests on several projects. Still, Ferenc Kovacs insisted on the fact that pushing a fix too rapidly was not necessarily the best thing to do.

In the end, a basic solution has been implemented for PHP 5.4 and 5.5 in order to fix projects that were suffering from this break. A more complete solution will then be implemented for PHP 5.6.


Nikita Popov wrote the RFC: Uniform Variable Syntax, which aims to get a more consitent and complete syntax for variables, for PHP 62.

Even if the discussion hasn’t been long, the feedback has been quite positive. It has even been suggested some checks could be added in PHP 5.7 to facilitate detection of points that will likely break in the future.


Pierre Joye reminded us the security that corresponds to the open_basedir directive can be obtained by setting up permissions at the system level, be it with Windows or Linux — which means the effort required to maintain that directive might not be that useful. As a consequence, he suggested it could be removed for PHP 6.

Julien Pauli quickly answered it was indeed not needed anymore, it was easy to circumvent, and that removing it would allow for some cleaning up in several portions of PHP’s source code.

Still, even if open_basedir doesn’t bring a real level of security, this feature mitigates the risk for some kind of bugs to be exploited and facilitates their detection. Actually, provided developers use PHP’s streams properly and don’t think open_basedir is related to security, keeping this directive could be interesting.


The RFC: Fix handling of custom session handler return values passed for PHP 5.7, with 10 “yes” votes and zero “no” vote.

At the end of the month, Timm Friebe annouced votes were opened on RFC: Catchable “call to a member function of a non-object”. If this RFC passes, calling a method on something that’s not an object (like NULL, for examples) will trigger a E_RECOVERABLE_ERROR instead of a Fatal Error.

Andrea Faulds wrote the RFC: Big Integer Support, which aims to keep working with integers even for very large values, where PHP now falls back to floats when values don’t fit in the range integers can represent. The first answers have been rather positive, even if some points still need clarifications before the RFC can go forward in the next weeks.

David Zuelke posted a fix that will allow php-fpm to work better with Apache.

Finally, after an RFC about anonymous classes has been rejected some time ago, Sebastian Bergmann re-started discussions on this idea, with a case in which he thinks they could be useful (for tests). I’m curious to see if, this time, the idea will go farther — maybe PHP 6 could help with that?



internals@lists.php.net is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server news://news.php.net/php.internals.



  1. Actually, it seems this change had been identified before, but had then been forgotten in the discussions. 

  2. As this proposal can break some use-cases (which are rarely worked with), it cannot target a minor version such as PHP 5.7. 

Par Pascal MARTIN le mardi 1 juillet 2014 1 commentaire

This post is also available in English.

Avant de réellement parler de dépilage d’internals@ : vous avez été nombreux à venir me voir tout au long du PHPTour (qui a eu lieu, cette année, les 23 et 24 juin à Lyon) pour me parler de cette série d’articles que je publie depuis maintenant un an et demi, me remercier et m’encourager, en indiquant que cela vous permettait de savoir ce qu’il se passait autour du développement de PHP. Ça fait plaisir et chaud au cœur ; merci à vous tous !


Juin 2014 est redescendu à un volume raisonnable de 493 messages sur la mailing-list internals@ de PHP, après un mois de mai qui avait été animé par plus de 800 mails, dont de longues discussions autour de phpng.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Nombres de mails sur internals@ ces trois dernières années


La sortie de PHP 5.6 continue de se rapprocher : le 6 juin, Ferenc Kovacs a annoncé la bêta 4, qui devrait être la dernière version avant la phase de RC.

Et deux semaines plus tard, la première Release Candidate de PHP 5.6 a été publiée !


Comme décidé via la RFC: Define PHP 5.3 end of life, la fin de vie de PHP 5.3 devrait arriver un an après la sortie de PHP 5.5 — qui a eu lieu le 20 juin 2013.

La dernière release corrective de PHP 5.3 ayant été publiée il y a six mois, Stas Malyshev a annoncé qu’une toute dernière version serait publiée prochainement (probablement en juillet) en vue de corriger quelques derniers problèmes.

Ferenc Kovacs a noté qu’il faudrait alors insister sur le fait qu’il n’y aurait ensuite plus de nouvelle version de PHP 5.3 — et qu’il était temps pour tout le monde de migrer vers une version plus récente !


Pierre Joye a indiqué qu’un nouvel outil d’installation d’extensions était en cours de développement : RFC: Pickle.

A moyen/long terme, l’idée est de supprimer la commande pecl de PEAR et que composer soit capable d’utiliser ce nouvel outil pickle pour installer des extensions.


En tout début de mois, Andrea Faulds a rédigé une RFC nommée “Bare Name Array”, qui apporterait deux nouvelles syntaxes, légèrement plus courtes que celles existant aujourd’hui (un peu comme [] est plus court que array()), pour manipuler des tableaux en PHP.

La première permettrait de déclarer des tableaux de la manière suivante, tout en ne changeant pas le comportement actuel de => :

$tableau = [
    clef1: "valeur 1",
    clef2: 42,
    clef3: [
        sub1: 25,
        sub2: "aaa",
    ],
];

Plus loin dans la conversation, Adam Harvey a demandé s’il avait été envisagé d’aller plus loin, en mettant en place quelque chose s’approchant des symboles de Ruby — ce qui ne serait pas évident en PHP, notamment en termes de syntaxe.

La seconde proposition permettrait quant à elle d’accéder aux éléments d’un tableau comme ceci :

echo $tableau:>clef3:>sub2;

Ces deux propositions n’étant pas réellement liées, Levi Morrison a fait remarquer qu’elles devraient être découpées en deux RFC distinctes — et Andrea Faulds les a rapidement créées : RFC: Bare Name Array Literal et RFC: Bare Name Array Dereference.

Les votes sur ces deux RFC ont été ouverts après quelques échanges supplémentaires — et elles ont toutes deux été rejetées (la première avec 14 votes contre et 3 votes pour, et la seconde avec 15 votes contre et aucun vote pour).

Dans l’ensemble, les retours ont principalement insisté sur le fait que ces modifications de syntaxe n’étaient pas nécessaires et rendaient le langage plus complexe — et sur le fait qu’avoir deux syntaxes avec des comportements différents était peu intuitif.


Le mois dernier (en mai, donc), une modification apportée à PHP 5.4.29 et 5.5.13 au niveau de la désérialisation, sur un cas particulier parfois utilisé pour créer des objets sans que le constructeur de la classe correspondante ne soit invoqué (ce qui est un gros hack, surtout sur des classes internes), a entrainé une cassure au sein de briques comme Doctrine ou PHPUnit.

Les deux projets en question ont rapidement été adaptés, mais Jakub Zelenka a souligné qu’il serait bon de sortir rapidement un correctif au niveau de PHP lui-même, que ce soit pour les développeurs ou les autres projets souffrant éventuellement du même problème.

Comme l’a fait remarquer Benjamin Eberlei, si PHP était testé sur une série de projets et bibliothèques (et pas uniquement sur les tests de PHP lui-même) avant chaque nouvelle version, ce type de régression aurait pu être évité1. Cela dit, comme l’a souligné Johannes Schlüter, il serait utile que les développeurs utilisant PHP prennent la peine de tester un peu plus les versions RCs et de faire des retours — ce qui n’est pas forcément simple et pourrait être facilité si des versions nightly de PHP étaient disponibles sur Travis CI.

La discussion autour de la solution à mettre en place à moyen/long terme a duré quelques temps — alors que Travis CI a appliqué la dernière version de PHP, entrainant des échecs de tests PHPUnit sur plusieurs projets. En même temps, Ferenc Kovacs a insisté sur le fait que sortir un correctif à la hâte n’était pas forcément non plus la meilleure chose à faire.

Au final, une solution basique a été mise en place pour PHP 5.4 et 5.5 de manière à réparer les projets impactés. Une solution plus complète sera mise en place pour PHP 5.6.


Nikita Popov a rédigé la RFC: Uniform Variable Syntax, qui vise à introduire en PHP 62 une syntaxe plus homogène et complète pour les variables.

Bien que la discussion n’ait pas été très longue, les retours ont été plutôt positifs, allant jusqu’à suggérer l’ajout de vérifications dès PHP 5.7 pour détecter les points qui casseront dans le futur.


Pierre Joye a rappelé que la sécurité correspondant à la directive open_basedir pouvait être mise en place en réglant les permissions au niveau du système, que ce soit sous Windows ou sous Linux et que l’effort à fournir pour maintenir celle-ci n’en valait peut-être donc pas la peine. En conséquence, il a proposé de supprimer cette directive pour PHP 6.

Julien Pauli a rapidement répondu qu’elle n’était effectivement plus nécessaire, qu’elle était facile à contourner, et que la supprimer permettrait de nettoyer plusieurs portions du code source de PHP.

Toutefois, même si open_basedir n’apporte pas un réel niveau de sécurité, cette fonctionnalité permet de mitiger le risque d’exploitation de bugs et de les détecter. En fait, pour peu que les développeurs utilisent correctement les flux de PHP et n’affirment pas qu’open_basedir est une directive en lien avec la sécurité, la conserver pourrait être intéressant.


La RFC: Fix handling of custom session handler return values est passée pour PHP 5.7, avec 10 votes “pour” et aucun vote “contre”.

En toute fin de mois, Timm Friebe a annoncé l’ouverture des votes sur la RFC: Catchable “call to a member function of a non-object”. Si cette RFC passe, appeler une méthode sur quelque chose qui n’est pas un objet (comme NULL, par exemple) entrainera la levée d’une E_RECOVERABLE_ERROR à la place d’une erreur fatale.

Andrea Faulds a rédigé la RFC: Big Integer Support, qui propose de continuer à travailler avec des nombres entiers même pour de très grandes valeurs, là où PHP se rabat aujourd’hui sur des nombres flottants lorsque les valeurs manipulées ne tiennent pas dans la plage que les entiers peuvent représenter. Les premiers retours ont été plutôt positifs, même s’il reste des points à éclaircir avant que la RFC ne puisse continuer à avancer sur les prochaines semaines.

David Zuelke a posté quelques corrections qui permettront à php-fpm de mieux fonctionner avec Apache.

Et enfin, alors qu’une RFC sur l’idée de classes anonymes avait été rejetée il y a un moment de cela, Sebastian Bergmann est revenu à la charge sur le sujet, avec un cas où il voit leur utilité (pour la mise en place de tests). Je suis curieux de voir si, cette fois, l’idée ira plus loin — peut-être que PHP 6 pourrait faire pencher la balance dans l’autre sens ?



internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.



  1. En pratique, il semblerait que ce changement avait été identifié auparavant, mais qu’il ait ensuite été oublié dans la discussion. 

  2. Cette proposition peut casser quelques cas d’usages (rarement employés) et ne peut donc pas cibler une version mineure. 

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.