136 posts taggués « php »

Par Pascal MARTIN le mercredi 10 septembre 2014

Cet article est aussi disponible en français.

I’ve been quite busy in August (and I’ve taken some holidays, during which I pretty much had no Internet access, which doesn’t help), and I haven’t been able to write my digest of internals@ for July 2014 in due time. Instead of writing it now and keeping getting late for August’s one, I’ve chosen to skip my digest of July — and to write August’s one, which you can read below.

August 2014 went back to a reasonable number of 700 messages on PHP’s internals@ mailing-list, after a busy month of July with 1144 mails.

As a graph representing the number of mails per month for the last three years, we’d get:

Johannes Schlüter started this month of August 2014 annoucing the first Release Candidate of PHP 5.3.29. Two weeks later, he announced the release of PHP 5.3.29, which marks the End Of Life of PHP 5.3 : no other new release of PHP 5.3 is planned (which means there won’t be any bug fix anymore — or even security fix).

As PHP 5.3 has reached its End Of Life, Jan Ehrhardt asked what would become of PHP 5.4. According to the Release Process, PHP 5.4, published in March 2012, should have gotten bug-fixes for two years. Still, like Stas Malyshev mentionned, it would be fair for PHP 5.4 to switch to “security fixes only” mode after PHP 5.6 is released — and maintaining two stable (5.4 and 5.5 — or 5.5 and 5.6) releases in parallel should be OK.

A few days later, Stas Malyshev announced that PHP 5.4.33 should be the last version of branch 5.4, except for possible security-fixes.

In the middle of the month, Ferenc Kovacs said the release of PHP 5.6 was getting close. And, a few days later, on August 28th, he announced the release of PHP 5.6.0!

In another thread, he explained why PHP 5.6 was two month late (according to the initial planning): several intermediate versions (alpha, beta, RC) have been released one or two week late, for different reasons — and, in the end, it adds up to two months.

Andrea Faulds noted it might be interesting to have one last 5.x version before the release of PHP 7 — which would mean PHP 5.7. The idea is that, as PHP 7 is a new major version, it will likely require about two years of work before it can be released — and it will include some new major features (and some BC-breaks).

A 5.7 release would facilitate the migration to PHP 7 — typically, by adding deprecation warnings for features that will greatly change. This intermediate version could also act as a fallback if PHP 7 was to be released later than expected. As Ferenc Kovacs pointed out, no minor release has, for now, been released in less than a year, and it seems hard to conceive that a major version (with more changes and more impact) could be released quicker.

Of course, as Derick Rethans, Zeev Suraski and several others answered, it might be better to put more energy into PHP 7, instead of dividing it between two versions. One should not reproduce what happened with PHP 6, where things stopped going forward because each developer wanted to add one more feature.

After the series of performances optimizations known as phpng had been developed on its separate branch for several months, Zeev Suraski opened the votes, at the beginning of the month, on RFC: Move the phpng branch into master, to decide if this branch would be merged to PHP’s master branch.

The matter had been debated a lot before and discussions were, this time, quite short — even if some indicated the changes brought by this branch were important and would have a strong impact.

In the end, this RFC passed, with 47 votes “yes” and 2 votes “no”. As a consequence, the phpng branch has been merged to master.

Andrea Faulds has written two RFCs related to functions and the Closure class:

The first one, which aimed to add a call() method to the Closure class, to allow binding at call-time, hasn’t been discussed much. Votes have been opened in the middle of the month and this RCS passed, with 13 votes “yes” et 0 votes “no”.

More messages have been exchanged about the second one: the idea was to add to PHP a syntax that would allow one to reference functions (in a more explicit way than just using their name as strings). As Stas Malyshev noticed, the proposed syntax might cause conflicts with passing parameters by reference, but the RFC seemed to be of interest for a few people.

Right at the end of July, Nikita Popov wrote the RFC: Abstract syntax tree, suggesting to add an intermediate step to the compilation process of PHP scripts.

This could allow new syntaxes that are currently impossible for technical reasons, might allow to remove a few hacks, and make the compilation of PHP scripts easier to maintain. By the way, the implementation that comes with the RFC already fixes a few syntax quircks (especially about yield and list). This change on the compilation process doesn’t have much impact on the execution of scripts: performances or memory usage will not change. Still, introducing an AST as some impact (10-15% gain for performances, at the cost of some increase in memory consumption) on the compilation phase.

Comment on this RFC have been quite positive and, without much surprise, it passed, with 47 votes “yes” and 0 votes “no”.

As a complement, it should be possible, in the future, to expose this AST to user-space (for static code-analysis, for example) and to provide extensions with some hooking mechanism so they could intervene during the compilation process.

Andrea Faulds wrote the RFC: Integer Semantics, which aims to improve cross-platform consistency for PHP integers by fixing a few cases for which behavior wasn’t clearly defined.

Kris Craig noted the role of a high-level language — such as PHP — should be to hide this kind of differences. Even if they made some sense when most developers were coming from a C-background, it’s less the case today.

Derick Rethans answered one must be extremely careful before breaking compatibility, including for a future major version like PHP 7. Any change that would be difficult to detect will create frustration for end-users and slow down the adoption of that new version. Several developers have confirmed this idea, pointing towards problems shown by Python 2 and 3 or Perl 6. Still, a major version definitely is the right time for improving the language.

Sara Golemon has written the RFC: Make defining multiple default cases in a switch a syntax error which wants to forbid using several default cases in a single switch block (today, only the last default is taken into account). Responses have been quite positives, to remove this odd behavior.

Some suggested a change of this type could have its place in PHP 5.7 — but it would go against the idea of not breaking compatibility between minor versions, which means this fix should find its place in PHP 7. Raising a E_DEPRECATED warning should be possible for PHP 5.7. After a while, Peter Cowburn asked if all this process (RFC, discussion on the mailing-list, votes) wasn’t a bit too much for something that could be considered as no more than a bug.

In parallel, votes had been opened, before some developers noticed the required minimum duration for discussions on a RFC, before opening it to votes, is two weeks. Considering those debates for something that felts like a bug-fix, Sara Golemon dropped the matter. Levi Morrison re-started it a few days later.

Note: the detection of this inconsistency is one of the first results of work started last month on the specification for PHP.

Marc Bennewitz wrote the RFC: Binary String Comparison, which states PHP’s behavior for comparisons is sometimes surprising when dealing with strings, as some type-casting is automatically used (basically, comparisons are non-strict) and proposes to change the behavior of non-strict comparisons for string so they become strict.

Several answers indicated changing this behavior today would cause problems, as it would break a major feature of PHP. In any case, considering some first responses, it doesn’t seem like this RFC is going to have much success.

Right at the beginning of the month, a mailing-list has been created for members of AFUP (French User-Group), to discuss in French about RFCs announced on internals@.

Following the discussions we’ve had on this mailing-list, I have (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:

Basically, we would like for the community (using a User-Group, to have some official entity) to participate more in the evolution process of PHP. This mailing-list and the resulting mails to internals@ seem to us like a good first step toward that goal.

Votes on RFC: intdiv() have ended: adding a new operator for integer division has been rejected (with 24 votes “no” and 5 votes “yes”) and the alternative solution — adding an intdiv() function — has passed (with 28 votes “yes” and 0 votes “no”).

To help with debugging, Dmitry Stogov suggested to add a new get_resources() function that would return a list of all existing resources (optionally limited to a specific type). This changes has been commited a few days later — no need for an RFC for such a simple thing.

Michael Wallner wrote the RFC: Add pecl_http to core. For now, only a few mails have been exchanged, but Johannes Schlüter noted it might be interesting to use this implementation for internal HTTP(s) stream — and for this extension to systematically (or, at least, by default) be enabled.

After several months of debates, Anatol Belski annouced the 64-bits patch for integers and strings length has (finally) been merged.

Dmitry Stogov set up a new memory manager for PHP 7. The matter has not been discussed much, but it seems this manager brings some performance gain — even it it might be relatively limited.

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.

Par Pascal MARTIN le mercredi 10 septembre 2014 3 commentaires

This post is also available in English.

Ayant eu un mois d’août assez occupé (et je suis parti en vacances sans réelle connexion Internet, ce qui n’aide pas ^^ ), je n’ai pas réussi à rédiger mon dépilage d’internals@ pour Juillet 2014 dans les temps, d’autant plus que juillet a été chargé. Au lieu de rédiger celui-ci maintenant et de continuer à accumuler du retard pour celui d’août, j’ai choisi de sauter le dépilage de Juillet — et donc de passer directement à celui d’août, que voici.

Août 2014 est revenu à un nombre raisonnable de 700 messages sur la mailing-list internals@ de PHP, après un mois de juillet qui avait été animé, avec 1144 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient :

Johannes Schlüter a ouvert ce mois d’août 2014 en annonçant la première Release Candidate de PHP 5.3.29. Et, deux semaines plus tard, il a annoncé la sortie de PHP 5.3.29, qui marque la fin de vie de PHP 5.3 : plus aucune nouvelle version de PHP 5.3 ne devrait être publiée (ce qui signifie aucune correction de bug, ni même de faille de sécurité).

PHP 5.3 ayant atteint sa fin de vie, Jan Ehrhardt a demandé ce qu’il advenait de PHP 5.4. D’après le processus releases, PHP 5.4, sorti en mars 2012, aurait du recevoir des correctifs de bug pendant deux ans. Toutefois, comme l’a souligné Stas Malyshev, il serait raisonnable pour PHP 5.4 de passer en mode “corrections de failles de sécurité uniquement” une fois PHP 5.6 sortie — et il ne serait pas choquant de maintenir deux versions stables (5.4 et 5.5 — ou 5.5 et 5.6) en parallèle.

Quelques jours plus tard, Stas Malyshev a annoncé que PHP 5.4.33 devrait être la dernière version issue de la branche 5.4, sauf correction de failles de sécurité.

En parallèle, en milieu de mois, Ferenc Kovacs a annoncé que la sortie de PHP 5.6 approchait. Et quelques jours plus tard, le 28 août, il a annoncé la sortie de PHP 5.6.0 !

Dans un autre fil de discussion, il a expliqué pourquoi PHP 5.6 était sortie deux mois en retard par rapport au planning initial : plusieurs versions intermédiaires (alpha, beta, RC) ont, pour différentes raisons, pris une ou deux semaines de retard — et le tout cumulé mène à deux mois.

Andrea Faulds a souligné qu’il pourrait être intéressant d’avoir une dernière version 5.x avant la sortie de PHP 7 — ce qui mènerait à PHP 5.7. En effet, PHP 7 étant une nouvelle version majeure, il semblerait probable qu’il faille environ deux ans avant de pouvoir la sortir et elle inclura de nouveaux points majeurs (et quelques cassures de compatibilité).

Une version 5.7 permettrait de faciliter la migration vers PHP 7, typiquement en ajoutant des avertissements d’obsolescence pour les fonctionnalités qui seront profondément modifiées. Cette version intermédiaire pourrait aussi jouer le rôle de solution de repli si PHP 7 venait à être repoussée pour une raison ou une autre. Comme l’a noté Ferenc Kovacs, aucune version mineure n’a pour l’instant été réalisée en moins de un an et il semble difficile d’imaginer qu’une version majeure (incluant plus de changements ayant plus d’impact) puisse être publiée plus rapidement.

Bien sûr, comme l’ont fait remarquer Derick Rethans, Zeev Suraski et plusieurs autres, il pourrait être préférable de consacrer plus d’énergie à PHP 7, plutôt que de diviser l’effort entre deux futures versions. Il ne faudrait pas non plus reproduire ce qui s’est passé avec PHP 6, où les choses ont fini par cesser d’avancer parce que chacun voulait ajouter encore une fonctionnalité.

Alors que la série d’optimisations orientées performances connues sous le nom de phpng était développée sur une branche distincte depuis maintenant plusieurs mois, Zeev Suraski a ouvert les votes, en début de mois, sur la RFC: Move the phpng branch into master, pour déterminer si cette branche allait être mergée vers la branche master de PHP.

Le sujet ayant déjà été (longuement) débattu, la discussion a été cette fois-ci assez brève — même si plusieurs ont souligné que les modifications apportées par cette branche étaient importantes et auraient un impact fort.

Au final, la RFC a été acceptée, avec 47 votes “pour” et 2 votes “contre” : la branche phpng a donc été mergée vers master.

Andrea Faulds a annoncé l’ouverture de deux RFCs en rapport avec les fonctions et la classe Closure :

La première, qui proposait d’ajouter une méthode call() à la classe Closure, permettant de binder à l’appel, n’a pas tellement été discutée. Elle a été ouverte aux votes en milieu de mois et a été acceptée, avec 13 votes “pour” et 0 vote “contre”.

La seconde a généré plus d’échanges : elle proposait d’ajouter à PHP une syntaxe permettant de faire référence à des fonctions (autrement que par leur nom sous forme d’une chaîne de caractères). Comme l’a souligné Stas Malyshev, la syntaxe proposée entre potentiellement en conflit avec le passage par référence, mais l’idée a semblé en intéresser plus d’un.

À la toute fin juillet, Nikita Popov a rédigé la RFC: Abstract syntax tree, qui proposait de mettre en place une structure intermédiaire dans le processus de compilation des scripts PHP.

Cela pourrait permettre de nouvelles syntaxes techniquement impossibles aujourd’hui avec une compilation en une seule passe, et permettrait de supprimer quelques hacks ainsi que de rendre l’implémentation plus claire et plus facile à maintenir. D’ailleurs, l’implémentation proposée corrige déjà certains points de syntaxe (notamment sur yield et list). Cette modification sur la compilation n’a globalement pas d’impact sur l’exécution : les performances ou l’occupation mémoire ne changeront pas. Par contre, l’introduction d’un AST a un impact (amélioration de 10-15% pour les perfs, mais augmentation de la mémoire consommée) sur la compilation.

L’idée a été fort bien reçue et, sans surprise, cette RFC est passée, avec 47 votes “pour” et 0 vote “contre”.

En complément, il pourrait être possible à l’avenir d’exposer l’AST à l’espace utilisateur (pour de l’analyse statique de code, par exemple), ainsi que de permettre à des extensions de se brancher dessus pour intervenir lors de la compilation.

Andrea Faulds a rédigé la RFC: Integer Semantics, qui propose d’améliorer la consistance cross-plateformes des entiers PHP en corrigeant quelques cas dont le comportement n’était pas clairement défini.

Comme l’a fait remarquer Kris Craig, le rôle d’un langage de haut niveau — comme PHP — serait effectivement de masquer les différences de ce type. En effet, même si ces elles avaient un sens lorsque nombre de développeurs venaient du langage C, c’est nettement moins le cas aujourd’hui.

Derick Rethans a rebondi sur le sujet, en notant qu’il fallait être extrêmement prudent avant de casser la compatibilité, y compris pour une future version majeure comme PHP 7. En effet, tout changement qui serait difficile à détecter entraînera de la frustration pour les utilisateurs et freinera l’adoption de cette nouvelle version. Plusieurs intervenants ont confirmé cette pensée, faisant notamment référence aux problèmes de Python 2 et 3 ou à Perl 6. En même temps, une version majeure est définitivement l’occasion d’améliorer le langage.

Sara Golemon a rédigé la RFC: Make defining multiple default cases in a switch a syntax error qui proposait d’interdire l’écriture de plusieurs cas default au sein d’un même bloc switch (en pratique, aujourd’hui, seul le dernier default est pris en compte). Les retours ont été plutôt positifs pour supprimer ce comportement aberrant.

Certains ont suggéré qu’un changement de ce type pourrait être mis en place pour PHP 5.7 — mais ce serait violer le principe qui interdit les cassures de compatibilité sur des versions mineures et ce changement aurait donc plus sa place pour PHP 7, quitte à générer une E_DEPRECATED en 5.7. Au final, Peter Cowburn a demandé si tout ce processus (RFC, discussion sur la mailing-list, votes) n’était pas un peu lourd pour quelque chose qui pourrait être considéré comme n’étant qu’un bug.

Entre temps, les votes avaient été ouverts, avant que plusieurs intervenants ne fassent remarquer que la durée minimale de discussions sur une RFC, avant ouverture des votes, est de deux semaines. Face à ces débats pour ce qui lui semblait n’être qu’une simple correction de bug, Sara Golemon a laissé tomber le sujet. Levi Morrison a repris le sujet en main quelques jours plus tard.

Il est à noter que la détection de cette incohérence fait suite au travail commencé le mois précédent autour d’une spécification pour le langage PHP.

Marc Bennewitz a rédigé la RFC: Binary String Comparison, qui part du constat que le comportement des comparaisons de PHP est parfois surprenant lorsque l’on compare des chaînes de caractères, puisqu’un transtypage est automatiquement appliqué (en somme, la comparaison est non-stricte) et propose donc de modifier le comportement des comparaisons “non-strictes” de chaînes de caractères afin de les rendre strictes.

Bon nombre de retours ont indiqué que modifier ce comportement serait problématique aujourd’hui, puisque cela casserait une fonctionnalité majeure de PHP. Quoi qu’il en soit, considérant les premiers retours, cette RFC ne semble pas vraiment bien partie.

Au tout début du mois, une mailing-list a été mise en place pour les membres de l’AFUP, en vue d’échanger en français sur les propositions annoncées sur internals@.

Suite aux discussions que nous avons eu sur cette mailing-list, j’ai (en tant que coordinateur de celle-ci) posté l’avis de l’AFUP sur trois sujets :

Le souhait que nous avons est d’essayer d’impliquer plus la commauté (par le biais d’un user-group, pour donner un sens officiel) au processus d’évolution du langage. Cette mailing-list et les mails vers internals@ qui en résultent nous semblent constituer un bon premier pas.

Les votes sur la RFC: intdiv() se sont terminés : l’ajout d’un nouvel opérateur de division entière a été rejeté (par 24 “contre” et 5 “pour”) et la solution de repli — l’ajout d’une fonction intdiv()a été acceptée (avec 28 votes “pour” et 0 vote “contre”).

Pour faciliter le debuggage, Dmitry Stogov a proposé d’ajouter une nouvelle fonction get_resources() qui retournerait la liste de toutes les ressources existantes (en se limitant éventuellement à un type donné). Cette modification a été réalisée quelques jours plus tard — pas besoin d’une RFC pour un ajout simple et précis comme celui-ci.

Michael Wallner a rédigé la RFC: Add pecl_http to core. Pour l’instant, peu de retours sont arrivés, mais Johannes Schlüter a noté qu’il serait intéressant d’uniformiser en utilisant cette implémentation pour les flux HTTP(s) internes et que cette extension soit systématiquement (ou, au moins par défaut) activée.

Après de longs mois, Anatol Belski a annoncé que le patch 64-bits pour les entiers et les longueurs de chaînes de caractères avait (enfin) été mergé.

Dmitry Stogov a mis en place un nouveau gestionnaire de mémoire pour PHP 7. Le sujet n’a que peu été discuté, mais ce gestionnaire semble apporter un gain de performances — même s’il ne serait que relativement faible.

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.

Par Pascal MARTIN le lundi 8 septembre 2014 2 commentaires

Le 30 juin 2009 sortait PHP 5.3.0.

Après des années d’efforts et alors que PHP 6 ne semblait pas réellement se rapprocher, PHP 5.3 a apporté un lot de nouveautés importantes. Pour n’en citer que quelques-unes qui m’ont le plus marquées1 :

  • Le support des espaces de noms,
  • Les fonctions anonymes et les closures.
  • Plusieurs classes de l’extension intl visant à faciliter l’internationalisation et la localisation d’applications.

Ces évolutions — et surtout les deux premières — ont posé les fondations utilisées ensuite pour revitaliser le développement en PHP : je pense en particulier aux travaux effectués par la communauté au niveau de l’auto-loading (notamment via la PSR-0), la mise en place et l’acceptation de composer, ainsi que le lancement de frameworks de seconde génération.

Pour moi qui ai commencé à travailler avec PHP dans un contexte pro sous PHP 5.1 et qui ai suivi — avec plus ou moins de retard en fonction des projets — les montées de versions successives vers PHP 5.2, puis 5.3 et maintenant 5.5 et bientôt 5.6, cette version 5.3 a marqué un tournant au niveau du langage et de sa communauté : d’un langage souvent perçu comme utilisé par des bidouilleurs, nous sommes passés à un langage et à des solutions résolument orientés professionnels.

Au niveau de l’évolution du langage en lui-même, PHP 5.3 a aussi ré-amorcé la pompe : avec l’admission que PHP 6 n’était pas encore prêt, PHP a recommencé à évoluer — et cela s’est vu à travers les versions qui ont suivi, avec PHP 5.4 en 2012, PHP 5.5 en 2013 et PHP 5.6 cette année.

Mais aujourd’hui, après tant d’années de bons et loyaux services, il est temps de dire adieux à PHP 5.3.

En effet, comme annoncé lors de la sortie de PHP 5.4, PHP 5.3 a atteint sa fin de vie2cet été : plus aucune correction ne sera apportée à PHP 5.3, que ce soit pour des bugs (y compris majeurs) ou même des failles de sécurité.

Si vous ne l’avez pas encore fait, il est donc plus que temps de songer à migrer vers une version plus récente — la raison voudrait que vous passiez à PHP 5.5 dès maintenant, en commençant dans la foulée à étudier la migration vers PHP 5.6 qui vient de sortir. J’ai moi-même réalisé la migration 5.3 → 5.5 cette année3 sur plusieurs applications et j’ai été agréablement surpris de voir à quel point elle a été sans douleur4 !

Et pour conclure, j’adresse un grand “Merci !” à tous ceux qui ont fait de PHP 5.3 la version mineure majeure qu’elle a été : contributeurs, Release Managers, testeurs, évangélisateurs, utilisateurs, …

  1. Je parlerais bien de goto, mais vu que je n’en n’ai toujours pas utilisé (ni vu utilisé) en toutes ces années, je ne peux dire que ça m’ait vraiment marqué ^^ 

  2. “Fin de vie”, ou “EOL” pour “End Of Life”

  3. J’ai d’ailleurs donné une conférence intitulée « PHP 5.3 → 5.6 : No pain but gain ! » au PHPTour 2014 à Lyon. Les slides sont disponibles, de même que la vidéo

  4. Bien sûr, si vous tournez encore sur une version encore plus ancienne — comme PHP 5.2 —, les choses pourraient être un peu plus complexes… Mais est-il utile de vous rappeler que PHP 5.2 a atteint son EOL il y a encore plus longtemps ? 

Par Pascal MARTIN le mardi 22 juillet 2014 1 commentaire

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

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

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

Dans la suite du premier post publié la semaine dernière, voici, encore dans l’ordre chronologique, mes notes du second jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque intervention.

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

Déploiement continu : Click and deploy !

Sophie BeaupuisRésumé, Slides

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

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

Principes pour améliorer tout ça :

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

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

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

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

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

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

Stop Multiplying by 4: Practical software estimation

Reeves CharlesRésumé, Slides

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

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

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

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

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

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

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

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

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

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

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

Juliette Reinders FolmerRésumé, Slides

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

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

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

UTF-8 est le plus simple des encodings Unicode :

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

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

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

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

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

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

L’asynchrone en PHP, c’est possible !

Olivier DolbeauRésumé, Slides

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

Le principe alors utilisé serait le suivant :

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

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

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

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

Quelques points supplémentaires :

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

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

PHP 5.3 → PHP 5.6 : no pain but gain !

Pascal MARTINRésumé, Slides

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

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

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

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

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

Prévenez la dette technique de vos projets

Bastien JaillotRésumé, Slides

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

Il existe quatre types différents de dette technique :

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

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

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

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

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

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

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

Lightning talks

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

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

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

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

Par Pascal MARTIN le mercredi 16 juillet 2014 2 commentaires

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

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

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

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

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

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

Coding and Dreaming - PHP in 2014

Rasmus LerdorfRésumé, Slides, Vidéo

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

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

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

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

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

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

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

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

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

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

Extract Till You Drop

Mathias VerraesRésumé, Slides, Vidéo

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

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

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

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

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

Au final, il en est ressorti :

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

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

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

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

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

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

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

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

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

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

Comment grapher et visualiser vos data ?

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

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

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

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

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

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

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

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

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

Quelques astuces et points à retenir :

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

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

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

REST dans le monde Symfony

William DurandRésumé, Slides, Vidéo

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

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

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

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

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

Transition agile 4 real @ meetic

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

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

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

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

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

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

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

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

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

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

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

Et pour aller jusqu’au bout :

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

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

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

Take a walk on the OPS side

Baptiste DUPAINRésumé, Slides, Vidéo

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

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

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

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

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

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

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

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

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

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

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

Pascal MARTIN, Julien FUSCORésumé, Slides

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

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

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

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

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

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

Par Pascal MARTIN le 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.

Par Pascal MARTIN le jeudi 5 juin 2014

Cet article est aussi disponible en français.

The month of May 2014 that’s just ended has seen 816 messages on PHP’s internals@ mailing-list. After a calm month of April, we’re back to a higher volume of discussions!

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

First of all: the release of PHP 5.6 keeps getting closer: Ferenc Kovacs announced beta 2 on May 2nd. It’s been followed by beta 3 the 15th.

Right at the beginning of the month, Dmitry Stogov started writing about a series of changes, named phpng, that would allow a great performance gain: up to 10% to 30%, depending on the applications.

The initial idea started with the fact the PHP engine works with data-structures that always require memory allocations and reference counting — a typical PHP application can spend 20% of its CPU time managing memory, 10% manipulating HashTables, 30% in internal functions and only 30% in the VM. Reworking internal data-structures to minimize memory allocations should help with that.

This means a great deal of refactoring (4 months of work) has been done on the PHP engine. It improves performance, memory usage, and sets up the first steps that could be used as a foundation for other future evolutions, such as JIT compiling.

This work is, of course, not finished yet (it would require at least a couple of months before one could consider it as alpha), but people quickly suggested it could be one of the big things for PHP 6 — which could be released in something like two years.

phpng should not have any impact on behavior has seen by users, but it will require updates on all PHP extensions to adapt them (changes on data-structures used internally by PHP have to be taken into account by extensions, as they are close to PHP itself). To document the migration to phpng for developers of PHP or extensions, a wiki page has been initialized: Upgrading from PHP5 to NG.

During the conversation, the idea of removing old SAPIs has been talked about once again — some going as far as suggesting that mod_php should not be supported anymore, as it’s often better to replace it with Apache/mod_fcgid or nginx/php-fpm. Still, even if those have a better architecture, one must not forget that swapping a component has a cost.

Pierre Joye quickly noticed the phpng branch conflicts with the work done since several months on 64 bits support (it has not been merged to PHP 5.x branch as it brings too many changes). To prevent this kind of situation from happening again, it really is necessary to communicate more — and working in an open mode would allow more developers to help.

He then posted a few numbers about the impact the 64bits branch has on memory usage: it needs between 2% and 5.5% more memory on real applications. The relative impact would be greater with the phpng branch, as it changes several internal data-structures. If you want to know more, here are a few notes about the goals of this branch.

A bit later, Anatol Belski announced votes were opened on the corresponding RFC: 64 bit platform improvements for string length and integer in zval. In the thread, Ferenc Kovacs summarized part of the problem: on one side, phpng aims to improve performances and reduce memory usage, and, on the other side, the 64bits branch aims to get better internal typing while using a bit more memory.

As discussions weren’t really constructive anymore, Nikita Popov suggested to find a common ground, using some evolutions from the 64bits branch (64 bits integers, unsigned-sizes, size_t for strings’ length) but not going to 64 bits where it costs too much memory and corresponds to less interesting features (lines numbers, numbers of parameters, HashTables sizes).

This proposal has been quite appreciated. As Rasmus Lerdorf answered, this idea is coherent and takes into account work done on both sides. Because of problems with the mailing-list, a new RFC has not been created right away and sould land soon.

At the end of the month, after a post writen by Joe Watkins about phpng had appeared on php.net, Ferenc Kovacs asked what should be done about it: keep it as-is, delete it, re-write it to be more formal and more factual, or post another article clarifying the matter is still subject to controversy and this post was more the personal opinion of one developer than an official statement.

Several expressed their surprise about this post, as php.net is not supposed to be used as a personal blog. In addition, as many websites had already re-posted the news, just deleting it did not seem to be the best approach — but, in the same time, it’s probably too early to begin talking officially about these evolutions and this post was not really formulated in a way that was objective and professional.

Still, as Philip Sturgeon said, several high-traffic websites had already started talking about phpng — not always successfully summarizing what it is and what it means for the future of PHP (and, of course, posting about PHP in a negative way is often a good way to generate traffic).

Levi Morrison then brought some explanations about the idea behind this post: as “phpng” was being talked about in the community, bringing some clarifications about it was a reasonable idea. In a way, it could be perceived as an attempt to communicate towards developers using PHP, about what was being discussed on internals@1; and trying to move forward is never easy.

Joe Watkins added he didn’t intend to post a news on php.net and was trying to launch a developers blog. This idea, by the way, is close to one of the missions of planet-php. In fact, this idea of “blog of developers”, with posts about what’s happening around the development of PHP and internals@, is kind of what I didn’t find when I begun posting these digests — even if it would be interesting having posts going farther into details, less in a “digest” mode.

In the end, Zeev Suraski removed the entry from the homepage of php.net so it has less visibility, keeping it in the archives 2014 — which was pretty much the right thing to do for many people.

Dmitry Stogov wrote the RFC: Fast Parameter Parsing API which would bring a faster alternative to zend_parse_parameters()2 to read parameters of a function or method.

Introducing a large amount of new macros and a more verbose syntax seems to be of interest to some, but others noted this would lead to heavier code. As Pierre Joye said, it would also be great to clean internal APIs: a more pleasing code-base would facilitate work for the next 10 years.

On the other hand, a gain of a few percents (between 2% and 5%) on performances, while only updating the most important functions… In effect, The RFC should insist of the fact the idea is to update only a few functions of PHP.

Stas Malyshev announced the RFC: Keeping PHPT Tests Green had passed, with 16 “yes” votes and no vote “against”. When a test doesn’t pass anymore, two solutions are possible: revert the change that broke it (after two days), or update the test. Of course, the second option should only be chosen when the new behavior is expected.

In the following days, Stas Malyshev sent some mails when changes broke the build, asking for the corresponding problems to be fixed. Reactions have been quite positive, and this should be a good thing for stability.

Andrea Faulds indicated that, in order to pass, an RFC needs 50%+1 votes “for” — and 2/3 votes “for” if it’s about a change that impacts the language itself. That being said, he noted that “change impacting the language” is not always easy to judge and that “50%+1 to pass” means some RFCs can be accepted even if they only have a small majority.

As a consequence, he proposed that all RFCs could now require 2/3 of “yes” votes in order to pass. This way, only changes well accepted by developers would pass (in effect, all RFCs that have been accepted for PHP 5.6 had at least 2/3 of “yes” votes — which means this idea would not really stop PHP from evolving).

Zeev Suraski answered that 50%+1 was, in his opinion, good enough for changes on extensions, functions, version numbers — basically, for targeted changes with no impact on the general direction PHP is going to. On the other hand, it could be interesting if only developers really concerned by a change could vote on it (for instance, developers working on the engine would vote for a central change, while those working on documentation would vote on changes linked to it). Still, as Andrea Faulds answered, changes on the Zend layer will tend to impact everyone.

Actually, as Dmitry Stogov indicated, some changes on the engine require a real technical expertise to be understood. And this technical expertise could help getting to better solutions — which is something that’s sometimes being done, as several recent RFCs have been written by teams of developers, with newcomers being guided by more ancient ones.

In the end, judging for the discussion, these 50%+1 and 2/3 will probably remain as they are today — and the distinction between the two types of RFCs should be made more clear.

A few mails arrived in the thread about the RFC: Return Type Declarations. Mainly, the proposed syntax has the advantage of being similar to what’s used by other languages and to be compatible with the one chosen by Hack.

Josh Watzman posted some notes about some incompatibilities between this RFC and Hack’s implementation. For example, Hack uses this as return type where PHP would prefer self.

After points of views had sometimes been expressed with a bit of vehemence, Levi Morrison reminded us that, even if each one can have his own vision of how PHP could be improved, the goal of everyone is the same — and he posted a list of a few points he considers as OK or not.

Martin Keckeis suggested for PEAR to not be integrated to PHP’s sources anymore. Still, as Hannes Magnusson answered, PEAR is also used to install PECL extensions — which means it is still useful and cannot be removed for now.

Michael Wallner said he started thinking about the loading of extensions that depend on others (today, it’s up the the user to deal with that himself, to load those extensions in the right order). Julien Pauli answered that something had been started on the subject a while ago and it could be interesting to share ideas. As a matter of facts, as noted by Hannes Magnusson, the extension mechanism might need more work than this single point!

Sara Golemon wrote the RFC: Add typehint accessors to ReflectionParameter which aims to have better handling of type-hints when using Reflection. Levi Morrison noted that taking into account the RFCs on return types and nullable types could be useful too; and, as a consequence, the RFC has been updated.

Sara Golemon also wrote the RFC: Fix handling of custom session handler return values — as the corresponding fix breaks backward-compatibility, an RFC can be required (at least, to decide for which PHP version this can be done).

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. Johannes Schlüter noted I had been doing a monthly digest of internals@ for some time — and also in English after a little push by Ferenc Kovacs. 

  2. zend_parse_parameters() is the C function used internally by all functions of PHP and its extensions when they need to receive parameters. This changes would, as a consequence, be invisible for developers using PHP.