Mes notes du PHPTour 2014, jour 2

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 Beaupuis – Ré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 Charles – Ré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 Folmer – Ré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 Dolbeau – Ré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 MARTIN – Ré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 Jaillot – Ré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 :

• Benjamin Clay a présenté 42 protips pour le dev’ PHP
• Clément Herreman a présenté Debugger efficacement son code ou la mort de var_dump et Le nouveau dans l’équipe, boulet ou messie ?
• Éric Daspet a présenté Rejoindre une startup a changé ma vie
• Joel Wurtz a montré comment mettre en place TravisCi en local en moins de 5 minutes
• et, profitant de quelques minutes de libres, Bertrand Dunogier et André Romcke ont conclu en parlant du cache d’eZ Publish Platform.

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 !