Pascal MARTIN (n+1).zéro

Cet article est aussi disponible en français.

When I was younger and/or still a student, I wasn’t really used to drinking coffee: I would have one every once in a while, but nothing more — and it was definitely not a habit.

The day I started working in a consulting firm¹, I pretty much hadn’t taken a seat yet that one of my colleagues was asking me some “do you want a coffee?”. Considering the coffee machine would be a perfect way to get to know my colleagues², I accepted. Same thing for other colleagues I took a coffee with the following days. Or even for new hires I welcomed later on, btw.

A couple of months after the end of my internship and my hiring, with a little help from the upcoming release of a large project and unreasonable work schedules, I was still fixing tickets, saying to myself “there, one last coffee”, at more than 9PM…

I rapidly got to drinking 6 to 8 cups of coffee per day — you’d just have to count:

1. A first one early in the morning, at home, just after waking up, while reading my RSS.
2. A coffee when arriving at work around 8-9AM depending on the days, either while reading mails (alerts, crons, error reports, …) of the night, or having a coffee break speaking with other colleagues who had arrived early³.
3. Another coffee in the middle of the morning, around 10AM.
4. Yet another one at the end of the morning, around 11:45, before going to eat.
5. A fifth one just before 2PM, before going back to work.
6. A coffee in the middle of the afternoon, around 4PM — quite often, that one was the occasion for a coffee break spent with a colleague, speaking about a specific technical point of the project we were currently working on⁴.
7. And, finally, a last one around 5:30PM, before ending the day.

It’s easy: counting the points above, I’m already at 7. And that was for a normal day: working longer in the morning and the evening, during days of rush, I would sometimes have one or two additional coffee(s)…

Thinking about it, at a rate of about thirty (euro-)cents per coffee (especially during the years we had an automatic coffee dispenser at work) six or more times a day, it adds up to about 2€ (~ 2.5 USD) each day. Which represents a coffee-budget of about 400€ a year! And this doesn’t include the price of the one coffee I took every morning at home!

To those who, from time to time, were telling me “you’re drinking too much coffee”, I was answering “nah, no”: after-all, I wasn’t sleeping too bad and was feeling OK during the day (else, I was considering it was just because I was working too much).

On the other hand, almost every week-end, I was quite tired and I sometimes got headaches, especially on Sundays… Same thing during the holidays, when I often felt exhausted, even while sleeping a lot more than when working…

Last year, I kind of randomly (thanks Twitter) read an article explaining how coffee works in the brain⁵ and I realized tiredness and headaches during week-ends might be caused by a lack of coffee, as I was only rarely having coffee on Saturday and Sunday.

So, one summer Monday morning last year, I stopped drinking coffee. Well, I tried: at 11AM, I was already getting one ;-(

The following day, Tuesday, second try. More successful. But I felt a bit tired all day long. It was to be predicted…

Wednesday morning while going to work, standing in the moving subway, I was so tired I felt like I was going to fall. Still, the evening before, I had gone to bed early, as I was feeling tired, and I had slept a long night!

I remember some urgent / critical / important / … thing that felt on me that same Wednesday at work at the end of the afternoon: the first thought that came to my mind was “I need a coffee, rrrhhhaaaa a coffee I have to get a coffee, some coffee, I need a coffee!!!”.

In the end, I spent the whole week feeling tired⁶, sleeping a lot to compensate, and taking dolipranes one after the other to fight headaches that didn’t want to go away. I had to wait until Saturday before things began to get better, and Sunday afternoon to finally be OK.

That’s were this article’s title comes from: I kind of feel like I survived this week without coffee!

Still, I did that brutally, going straight from 6-8 cups of coffee per day to 0, which might explain these symptoms — at the risk of being considered as binary, I think it’s easier than going down bit by bit. That week and the following one, I was having water-breaks with colleagues on coffee-break :-D

The second week without coffee, everything was going fine.

And, of course, I re-started drinking coffee — one when waking up, a second one at 9:30AM after our stand-up meeting, and a third one at the beginning of the afternoon. I console myself thinking it was more reasonable than before!

After a few months, this year, I again had the impression I was tired during week-ends, with occasional headaches on Sundays. Less than last year, but still kind of the same thing.

So, during spring, I stopped again. I’ve had headaches for a few days, but less than last year — because it wasn’t the first time I was stopping? Or because I was having less coffee per day than before?

Now, I’m almost at five months without coffee. And, most importantly, I do not need coffee anymore, even when it comes to a big deploy at 4AM at work or a 10 hours long trip to go to holidays \o/.

Now, I have to find out if I’ll be able to just drink coffee from time to time, purely because I want to⁷… while not having a relapse!

Cet article est aussi disponible en français.

730 messages have been exchanged in September 2014 on PHP’s internals@ mailing-list — almost the same number as in August.

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

At the beginning of the month, Andrea Faulds wrote an RFC called “Implicit isset() in Shorthand Ternary Operator”. Its idea was to modify the ?: operator introduced with PHP 5.3 to automatically add an isset() and, so, prevent any notice from being raised.

The first answers indicated that the idea could be interesting, but, at the same time, several voices said changing the behavior of ?: in such a way might not be quite a good idea.

In the end, most of this RFC has been rewritten, leading to RFC: Null Coalesce Operator. The idea is now to add a new ?? operator, instead of changing the behavior of ?:. This new operator can be used like this:

// Uses $_GET['user'] if it exists -- or 'nobody' if it doesn't
$username = $_GET['user'] ?? 'nobody';

// Loads some data from the model and falls back on a default value
$model = Model::get($id) ?? $default_model;

With 31 votes “yes” and 3 votes “no”, this revamped version of the RFC has passed, which means PHP 7 will have a new ?? operator.

Leigh has written the RFC: loop + or control structure, which aims to add an optional block to PHP loops (for, while, foreach). This block would be executed in cases we don’t enter inside the loop (as the condition has not been true, even at first try). It would be introduced by the or keyword.

With this RFC, we could write something like this:

foreach (generator() as $k => $v) {
    // loop body
}
or {
    // executed if we never entered the
    // body of the foreach loop
}

This feature already exists in some templating languages — for instance, it is supported by Twig for its for loops, using the else keyword.

Note: using or would mean not adding a new reserved word, and else, which is used by other languages, cannot be used for PHP as it would lead to ambiguities in the language.

A few other things have been talked about in the conversation (we’ll see if someone pushes them farther, via other RFCs?), like the idea for a loop to systematically return the number of iterations done.

Robert Stoll suggested PHP 7 might be an occasion to make transtyping operations more strict. For example, (int)"a" would not longer be 0 and it would raise an error. Andrea Faulds quickly answered that explicit casts cannot fail and changing this behavior now would cause an incredible amount of bugs and BC-breaks.

Still, it might be possible to add some new transtyping functions that would be more strict — maybe like ext/filter already does? Another approach could be to use new keywords, like int('2'), or even a syntax close to constructors, like $a = new int('2').

Nikita Popov has written the RFC: Remove alternative PHP tags, which proposes to remove, for PHP 7, the alternative tags <% ... %> and <script language="php"> ... </script>.

Several answers have been quite positive, but others noted a script to facilitate the migration to <?php ... ?> would be helpful.

Votes have been opened a few days before the end of the month and results should be there at the beginning of October. For now, things seem to be going well for this RFC.

Levi Morrison noted that what is usually called type-hints are definitely not hints, as types fixed when declaring a function or a method are checked and an error is raised if passed parameters don’t match them. As a consequence, he asked if someone had a better name idea, or if we were going to keep calling those hints.

Andrea Faulds suggested Optional Type Declarations for parameters and Return Type Declaration for the return-type. As those types are not optional once they are set, Type Declarations might be a good compromise — or maybe Type Assertions.

On the other hands, Type Hints has been used for years in the manual and by the community… In the end, I’m curious to see if this proposal will go farther and if, one day, we’ll stop talking of hints for things that are actually not.

Tjerk Meesters noticed the tests of ReflectionFunction::isDeprecated() depend, for now, on functions flagged as deprecated — but, as those might get removed for PHP 7, these tests might have to be updated.

That test might also be fixed, so it finds a deprecated function by itself. Or, instead, would it not be interesting for PHP to define a __deprecated__() function, that would forever be flagged as deprecated — even if it would only exist when PHP is compiled in debug-mode?

During the conversation, Alexander Lisachenko noted that adding a deprecated keyword, that could be used from user-space, might be an interesting idea, especially for some big frameworks. I wonder if this idea has not already been suggested in the past…

Dmitry Stogov has written the RFC: Fix list() behavior inconsistency, which suggests to remove a few inconsistencies of list() when it comes to strings. Today, using list() on a string works, or not, depending on the situation:

list($a,$b) = "aa"; // $a and $b are NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a is 'a' and $b contains 'b'

For PHP to be more consistent, this RFC proposed to forbid using list() on strings, or to make it work in all cases. As Derick Rethans indicated, the second option would add a new behavior to PHP, while the first one would come to removing something that works today (even if not documented).

Votes have been opened right before the end of September. Considering how things are going for now, it is very likely something will be done, but it’s hard to predict which one of those two approaches will win.

I was saying last month a mailing-list had been setup for members of the French UG AFUP, to discuss, in French, about proposals that were announced on internals@.

Following our discussions of this month, I (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:

• Our opinion on RFC Make defining multiple default cases in a switch a syntax error
• Our thoughts about RFC Integer Semantics
• And our summary for the addition of the new ?? operator

In addition, we now have a blog. I’ll try posting, mainly in French, about the opinions we have expressed on internals@, and, if possible, a few sentences to summarize the goal of each RFC and why we’ve spoken the way we did: PHP Internals en français

Matt Wilmas worked on a patch that would bring a micro-second resolution (with a good precision) to functions such as microtime(). It might be added to a next minor version of PHP 5.6.

Andrea Faulds opened votes on RFC: Scalar Type Hinting With Casts, before pausing them to give people more time to discuss the matter… And, in the end, the RFC has been withdrawn.

Leigh proposed adding two new format codes to pack() and unpack(), related to 64 bits. RFC: 64 bit format codes for pack() and unpack() has been posted a few days later. This RFC passed, with 15 votes “yes” and 0 votes “no”.

Here’s another RFC written by Andrea Faulds: RFC: ZPP Failure on Overflow. It started off the fact that, today, when a floatting-point number too big to fit in the range of an integer is passed as a parameter to an internal function (exposed by PHP or an extension) that expects an integer, it is received by this function as… an integer… which causes loss of data. This RFC proposes that, when an integer is expected as a parameter and the received value is a float that cannot fit in an integer, the parsing of the parameters of the function fails, and a warning gets raised.

At the beginning of the month, Levi Morrison announced votes were being opened on RFC: Make defining multiple default cases in a switch a syntax error. With 28 votes “yes” and 0 votes “no”, it passed: it will not be possible anymore, with PHP 7, to write more than one default section in a single switch construct.

In the middle of September, Andrea Faulds indicated the beginning of the voting phase on RFC: Integer Semantics. With 16 votes “yes” and 8 votes “no”, it seems this RFC passed — even if votes got closed pretty much a day too early.

Kris Craig wrote the RFC: Change checkdnsrr() $type argument behavior, to change the default behavior of checkdnsrr(), to fetch more than only MX records.

And, finally, Nicolai Scheer noticed it isn’t possible to use an object as an array key, even if it defines a __toString() method: this one is not automatically called. Calling __toString() automatically in such a situation doesn’t seem right, as this method is used by some to produce a printable version of an object. Instead, a new magic method __toKey() could be added, so __toString() continues to return a printable string, while this new method would return a more technical identifier.

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.

This post is also available in English.

Septembre 2014 a vu 730 messages échangés sur la mailing-list internals@ de PHP, soit quasiment le même nombre qu’en août.

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

Je disais le mois dernier qu’une mailing-list avait é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 ce mois-ci, j’ai (en tant que coordinateur de celle-ci) posté l’avis de l’AFUP sur trois sujets :

• Notre avis sur la RFC Make defining multiple default cases in a switch a syntax error
• Celui à propos de la RFC Integer Semantics
• Et notre opinion autour de l’ajout de l’opérateur ??

En complément, nous disposons maintenant d’un blog où j’essayerai de poster régulièrement, principalement en français, les opinions que nous avons exprimées sur internals@, ainsi que, dans la mesure du possible, quelques phrases résumant en quoi consistent chaque RFC et pourquoi nous nous sommes exprimés comme nous l’avons fait : PHP Internals en français

Au début du mois, Andrea Faulds a rédigé une RFC nommée “Implicit isset() in Shorthand Ternary Operator”, qui proposait de modifier l’opérateur ?: introduit avec PHP 5.3 pour qu’un isset() soit automatiquement ajouté et, donc, qu’aucune notice ne soit levée.

Les premiers retours ont montré que l’idée pouvait être intéressante, mais, en parallèle, plusieurs voix ont souligné qu’il n’était peut-être pas judicieux de modifier le comportement de l’opérateur ?: de la sorte.

Finalement, cette RFC a été en grande partie ré-écrite, pour arriver à RFC: Null Coalesce Operator, qui proposait d’ajouter un nouvel opérateur ??, au lieu de modifier le comportement de ?:. Ce nouvel opérateur pourrait être utilisé de la manière suivante :

// Utilise $_GET['user'] si existe et 'nobody' sinon
$username = $_GET['user'] ?? 'nobody';

// Charge une donnée depuis le modèle et se rabat sur une valeur par défaut
$model = Model::get($id) ?? $default_model;

Avec 31 votes “pour” et 3 votes “contre”, cette version revue de la RFC est passée et PHP 7 disposera donc d’un nouvel opérateur ??.

Leigh a rédigé la RFC: loop + or control structure, qui propose d’ajouter un bloc, optionnel, aux structures de boucles (for, while, foreach) de PHP. Ce bloc serait exécuté dans le cas où on n’entre jamais dans la boucle (la condition n’étant pas vérifiée, et ce dès le premier passage). Il serait introduit par le mot-clef or.

Avec cette RFC, il deviendrait possible d’écrire quelque chose de ce type :

foreach (generator() as $k => $v) {
    // corps de la boucle
}
or {
    // exécuté si on n'est pas entré
    // dans le corps de la boucle foreach
}

C’est une fonctionnalité qui existe déjà dans certains langages de templating — par exemple, Twig supporte ceci pour ses boucles for, en utilisant le mot-clef else.

Il est à noter qu’utiliser or éviterait d’ajouter un nouveau mot réservé et que le mot-clef else employé par d’autres langage ne semble pas pouvoir être utilisé par PHP, car il mènerait à des ambiguïtés.

Quelques autres idées ont été levées dans la conversation (à voir si quelqu’un les poussera en avant à travers d’autres RFC ?), comme la possibilité qu’une boucle puisse systématiquement retourner le nombre d’itérations effectuées.

Robert Stoll a suggéré que PHP 7 pourrait être l’occasion de rendre les opérations de transtypage plus strictes, de manière à ce que, par exemple, (int)"a" ne vaille plus 0 et lève une erreur. Andrea Faulds a rapidement répondu que les casts explicites ne pouvaient pas échouer et que changer ce comportement maintenant mènerait à une quantité incroyable de bugs et de BC-breaks.

Par contre, une possibilité pourrait être d’ajouter de nouvelles fonctions de transtypage plus strictes — peut-être comme ce que fait déjà ext/filter ? Passer par de nouveaux mot-clefs comme int('2') ou même une syntaxe proche de celle utilisée pour les constructeurs, comme $a = new int('2'), pourrait être une autre approche.

Nikita Popov a rédigé la RFC: Remove alternative PHP tags, qui proposait de supprimer, pour PHP 7, les tags alternatifs <% ... %> et <script language="php"> ... </script>.

Une partie des retours ont été plutôt positifs, mais d’autres ont souligné qu’il serait bon de fournir un script facilitant la migration vers <?php ... ?>.

Les votes ont été ouverts vers la fin du mois et les résultats devraient arriver tout début octobre — les choses semblant plutôt bien parties pour cette RFC pour l’instant.

Levi Morrison a noté que ce qui est généralement appelé type-hints ne sont absolument pas des hints (“hint” se traduisant par “indice” ou “astuce”), puisque les types indiqués lors de déclarations de méthodes et fonctions sont vérifiés et que des erreurs sont levées si les paramètres passés ne correspondent pas à ceux-ci. Il a donc demandé si quelqu’un avait une meilleure proposition de nom, ou s’il fallait rester sur celui-ci.

Andrea Faulds a proposé Optional Type Declarations pour les paramètres et Return Type Declaration pour le type de retour. Ces types n’étant pas optionnels une fois qu’ils ont été positionnés, Type Declarations constituerait un bon compromis — ou peut-être Type Assertions.

D’un autre côté, Type Hints est utilisé depuis des années dans le manuel et par la communauté… Je suis donc curieux de voir si cette proposition aboutira et si on cessera un jour de parler de hints pour quelque chose qui n’en est pas.

Tjerk Meesters a remarqué que les tests de la méthode ReflectionFunction::isDeprecated() dépendent, aujourd’hui, de fonctions marquées comme obsolètes — mais, comme elles pourraient être supprimées de PHP 7, ces tests seront à revoir.

Le test en question pourrait aussi être modifié pour trouver par lui-même une fonction obsolète. Ou, à la place, est-ce qu’il ne serait pas intéressant que PHP définisse une fonction __deprecated__(), qui soit éternellement marquée comme obsolète — quitte à ce qu’elle n’existe que lorsque PHP est compilé en mode debug ?

Dans la conversation, Alexander Lisachenko a noté qu’ajouter un mot-clef deprecated qui puisse être utilisé depuis l’espace utilisateur serait peut-être une alternative intéressante, notamment pour certains gros frameworks. Je me demande d’ailleurs si cette idée n’avait pas déjà été évoquée par le passé…

Dmitry Stogov a rédigé la RFC: Fix list() behavior inconsistency, qui proposait de supprimer quelques inconsistences de list() par rapport aux chaînes de caractères. En effet, aujourd’hui, utiliser list() sur une chaîne de caractères fonctionne ou non selon les cas :

list($a,$b) = "aa"; // $a et $b valent NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a vaut 'a' et $b vaut 'b'

Pour rendre PHP plus cohérent, cette RFC proposait de complètement interdire l’utilisation de list() sur des chaînes de caractères, ou alors que la rendre possible dans tous les cas. Comme l’a fait remarquer Derick Rethans, la seconde option ajouterait un comportement fonctionnel à PHP, alors que la première reviendrait à supprimer quelque chose qui marche aujourd’hui (même si non documenté).

Les votes ont été ouverts quelques jours avant la fin du mois. Vu l’orientation qu’ils prennent, il est fort probable que quelque chose soit fait, mais il est difficile de prédire laquelle des deux approches sera privilégiée.

Matt Wilmas a travaillé à un patch permettant d’avoir une résolution à la microseconde (avec une bonne précision) pour les fonctions comme microtime(). Il pourrait être intégré pour une prochaine version mineure de PHP 5.6.

Andrea Faulds a ouvert les votes sur la RFC: Scalar Type Hinting With Casts, avant de les mettre en pause pour laisser le temps à plus d’échanges sur le sujet… après lesquels la RFC a été retirée.

Leigh a proposé d’ajouter de nouveaux codes de formats à pack() et unpack(), pour ce qui est 64 bits. La RFC: 64 bit format codes for pack() and unpack() a été rédigée quelques jours plus tard. Cette RFC est passée, avec 15 votes “pour” et 0 vote “contre”.

Voici une autre RFC proposée par Andrea Faulds : RFC: ZPP Failure on Overflow. Elle est partie du constat que, aujourd’hui, lorsqu’un flottant trop grand pour tenir dans les valeurs supportées pour les entiers est passé en paramètre à une fonction interne (fonction exposée par PHP ou par une extension PHP) qui attend un entier, il est reçu par la fonction sous la forme… d’un entier… ce qui entraîne une perte d’information. Cette RFC propose donc que, dans le cas où un paramètre entier est attendu et que la valeur reçue est un flottant trop grand pour tenir dans un entier, l’analyse des paramètres de la fonction interne appelée échoue, que la fonction retourne sans s’exécuter, et qu’un avertissement soit levé.

Au début du mois, Levi Morrison a annoncé l’ouverture des votes sur la RFC: Make defining multiple default cases in a switch a syntax error. Avec 28 votes “pour” et 0 vote “contre”, elle est passée : il ne sera donc plus possible, en PHP 7, d’écrire plusieurs sections default dans un même bloc switch.

En milieu de mois, Andrea Faulds a annoncé l’ouverture des votes sur la RFC: Integer Semantics. Avec 16 votes “pour” et 8 votes “contre”, elle semble être passée — même si les votes ont été clos pas loin d’un jour en avance.

Kris Craig a rédigé la RFC: Change checkdnsrr() $type argument behavior, qui propose de modifier le comportement par défaut de la fonction checkdnsrr() pour charger plus que les informations d’enregistrements MX.

Et enfin, Nicolai Scheer a fait remarquer qu’il n’était pas possible d’utiliser un objet comme clef d’un tableau, même s’il définissait une méthode __toString() : celle-ci n’est pas automatiquement appelée. Appeler automatiquement __toString() dans ce cas de figure ne semble pas optimal, puisque cette méthode est utilisée par certains pour produire une version affichable d’un objet. À la place, une nouvelle méthode magique __toKey() aurait l’avantage de laisser à __toString() le soin de renvoyer une chaîne utilisable pour affichage, alors que cette nouvelle méthode renverrait un identifiant plus technique.

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.

Je suis parti quelques jours en vacances en famille cet été et, le soir, au lieu de regarder la télévision¹, j’ai eu tendance à passer un peu de temps devant mon PC, principalement pour rédiger quelques articles² qui ont été — ou seront — publiés sur ce blog³.

Sans surprise puisque cela m’arrive régulièrement depuis une dizaine d’années, il m’a été demandé si “je travaillais”⁴. C’est une question qui revient assez fréquemment⁵ et j’y suis désormais habitué, mais il ne me semble pas avoir déjà écrit sur le sujet⁶.

Alors, pour mettre les choses au clair : non, quand je suis devant mon PC chez moi (ou en vacances), je ne suis généralement pas en train de travailler au sens usuel du terme.

Au contraire, depuis le tout début de ma carrière, j’ai limité au maximum le fait de ramener du boulot à la maison — quitte à pour cela parfois faire des horaires tout à fait dé-raisonnables (voire contre-productifs⁷), comme ça m’est plusieurs fois arrivé dans le passé. En particulier, je tâche de ne pas bosser sur “les projets du boulot” lorsque je suis chez moi.

Mais cela ne m’empêche aucunement de pratiquer une activité de veille, y compris, occasionnellement, sur des projets que j’espère pouvoir introduire ensuite au bureau !

C’est aussi sur ce temps que je passe chez moi que j’écris des articles de blog, un livre sur le développement d’extensions PHP, que je me tiens à jour sur des points ayant ou non un lien avec mon activité professionnelle, ou même que je prépare mes sujets et répète pour des conférences.

Certaines fois, lorsque je suis face à une réaction “mais pourquoi tu fais ça ?” ou “mais tu travailles trop !” quand j’explique avoir consacré une partie d’un week-end à une de ces activités, je me demande quelle aurait été la réaction si j’avais annoncé écrire un roman — plutôt qu’un article de blog ou un chapitre d’un livre technique…

J’ai la chance d’exercer un métier dans un domaine passionnant⁸, extrêmement vaste et en perpétuelle évolution — bien assez pour que j’y consacre, avec plaisir, du temps en dehors des quelques dizaines d’heures hebdomadaires que représentent mon travail !

Alors, quand TF1 vend votre temps de cerveau à Coca-cola, laissez-moi consacrer le mien à mon enrichissement ;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

• Usage avancé de Jenkins comme outil d’amélioration/intégration continue
• Hands on Elasticsearch & Kibana

Nous croiserons-nous à ce Forum PHP ?