Mes notes du Forum PHP 2016, jour 2

10 novembre 2016 php, afup, conference, forum-php

Le Forum PHP 2016 organisé par l’AFUP a eu lieu les 27 et 28 octobre, au Beffroi de Montrouge à Paris.

J’ai publié en début de semaine mes notes du 1er jour ; voici le moment de passer au second jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque conférence.

Retour d’expérience Auchan : surveiller ses applications en production

Alexandre SaloméRésumé

Pour commencer cette seconde journée, Alexandre a commencé par nous parler de surveillance d’applications en production, à travers trois couches : système, services et applications.

Deux types de choses qu’on peut tracer :

  • Des métriques : nombre qui change dans le temps (time-series), agrégation (somme, moyenne, 90ème percentile, min, max, …) possible (important quand on fait des requêtes et pour réduire le stockage requis), utilisation de la dérivée (oui, à 9h37 un second jour !) pour voir les changements à partir d’une série croissante.
  • Et des événements : message au format texte, comme logs d’une application ou d’apache / linux (et il y a des informations importantes au niveau du système !) / mysql : … Il est intéressant d’indexer tous les logs, en extrayant les champs (cf Logstash — le L de ELK — qui a déjà plein de règles toutes prêtes)

Il existe déjà de nombreuses solutions sur le marché, dont :

  • Stockage des métriques : graphite (agrégat), InfluxDb (clustering), OpenTSDB (scalable), Prometheus
  • Pour ce qui est système / services : collectd, zabbix
  • Penser à statsd pour la temporisation des métriques
  • Et à ELK pour les événements

Mais quoi mesurer ? → tout ! Quelques exemples : tout ce qui est obsolète dans l’application, performances du système et des services, erreurs, comportements utilisateurs, … Et brancher un système permettant d’être alerté, pour traiter les problèmes avant qu’ils ne surviennent (exemple : grafana supporte des alertes, pour graphite)

Chez Auchan, utilisation de splunk (en gros comme ELK mais payant, utilisable par toute l’équipe, permet aux business de créer des tableaux dynamiques croisés) + zabbix (système et services).

En conclusion : surveiller tout ce qui change + ce qui est critique. Et mettre les alertes à 60% et pas à 95%.

Allumez le feu !

Frédéric HardyRésumé

Par cette présentation, Frédéric souhaitait inciter les membres du l’audience à devenir conférencier, à oser se lancer.

Je me suis beaucoup retrouvé (et mon moi d’il y a quelques années !) dans certains passages, mais je réalise en repassant sur mes notes que je n’en ai vraiment pas pris beaucoup (peut-être justement parce que je m’y retrouvais…). En vrac et brièvement donc :

  • On a tous quelque chose à raconter !
  • Quand quelqu’un nous pousse (fortement ?) à donner un conf, surtout pour la première… Et bien on y va ! Même si on n’aurait pas osé se proposer au départ !
  • Notre 1er mode de communication, depuis des millénaire = l’oral. Et le cerveau est donc adapté à la communication orale.
  • Devenir conférencier, c’est un moyen de faire bouger les choses ;-)
  • Mais : on n’a pas le réflexe… Peut-être parce que l’approche suivie à l’école n’est pas la bonne ? Sauf qu’être conférencier, ce n’est pas comme un exposé à l’école, puisqu’on a le choix du sujet, du format et qu’on a plein de ressources à notre disposition !

Bref : lancez-vous ! Et si vous doutez, n’hésitez pas à demander de l’aide, il y a dans votre communauté des gens qui peuvent vous aider à préparer, à répêter, vous donner leur avis ou vous encourager !

Pattern ADR, PSR-7, actions framework-agnostic et autowiring avec Symfony

Kévin DunglasRésumé

Kévin a commencé par rappeler que les contrôleurs sous symfony ont quelques problèmes : ils contiennent trop de logique, trop de méthodes, ont trop de magie et d’implicite, sont container-aware, il est difficile de faire SOLID, le couplage à plein de dépendance complexifie les TU et ils sont, de plus, fortement couplés à symfony. Bref, pas terrible quand on a pour objectif, entre autres, d’écrire du code réutilisable.

Objectif : passer au pattern Action-Domain-Responder (qui serait une sorte de MVC avec des définitions plus précises), en enregistrant tous les services dans le conteneur d’injection :

  • Action : 1 classe = 1 action ; et pas d’accès on conteneur de dépendances : on n’injecte que ce qui est nécessaire
  • Domain : manager qui valide l’objet et le persiste + lève des exceptions au besoin
  • Responder : gére l’erreur + la vue

Pour réduire les difficultés de configuration (routing en YAML, entités en configuration, …) requises pour l’indépendance à un framework (ce qui permet aussi d’être plus strict, plus testable, d’avoir une meilleure structure, de réduire la duplication de code, …), utilisation d’autowiring. Ou, en allant encore plus loin : ActionBundle (cf ApiPlatform 2). Avec en bonus compatibilité PSR7 et 17.

Bon, j’avoue : j’ai un peu décroché sur la fin, je n’ai pas fait assez de symfony ces derniers temps… Mais je note l’idée du pattern ADR le jour où j’y reviens ;-)

Independence day

Frédéric BoucheryRésumé

Utiliser des bibliothèques développées par d’autres personnes (qui peuvent être une équipe… ou juste une personne qui fait ça quand elle a le temps), c’est super : ça permet la réutilisation de code, le partage. Mais la notion de dépendance, c’est aussi se coupler avec des paquets externes ! Il existe des paquets d’interopérabilité, mais seulement pour certaines choses spécifiques ⇒ on peut améliorer ça en passant par des adaptateurs depuis notre code, pour limiter le couplage avec les composants externes.

Quelques suggestions / idées à envisager :

  • Commiter, chez vous, les paquets externes (pour qu’ils restent disponibles même si leur repository d’origine est KO, pour pouvoir corriger des points en local si besoin, …)
  • Pour choisir un paquet, basez-vous sur plus que le seul nombre d’étoiles sur github ! Notamment : nombre de contributeurs actifs et gros, engagement et un cycle de vie.

Attention à certains pièges :

  • Le coup de “left pad” qui a cassé la moitié d’internet, quand le paquet a été retiré de npm
  • Semver ne signifie pas qu’il faut impérativement tout casser quand on change de version majeure !

Et en conclusion :

  • Utiliser des adaptateurs
  • Réduire le couplage avec les composants externes ou les centraliser à quelques endroits dans le code
  • Si on fait des paquets : ne pas tout casser ! Ou carrément changer de nom !

Bref : prendre de l’indépendance par rapport aux dépendances externes !

Middlewares : un vieux concept au coeur des nouvelles architectures

Matthieu NapoliRésumé

Pour commencer, Matthieu a rappelé qu’un middleware, c’est quelque chose qui prend une requête et retourne une réponse — définition un peu générale, qui s’applique à pas mal de composants ;-).

PSR-7 vient standardiser la structure des messages HTTP, dont une requête et une réponse. PSR-15 vient quant à elle standardiser l’interface des middlewares.

Plein de choses qui peuvent être faites avec des middlewares, que ce soit par un mécanisme de pipe (imbrication de middlewares) ou de routeur (qui peut être placé à la fin du pipe), comme de l’identification, de la gestion d’erreur, …

Sur cette conférence (fort intéressante), je n’ai pas pris tellement de notes non plus : j’avais assisté à l’atelier animé par Matthieu il y a quelques semaines et n’ai donc pas découvert grand chose ici, ayant pratiqué récemment ;-)

Ecrire du code PHP “framework-agnostic”: aujourd’hui et demain

David NEGRIERRésumé

En introduction, David a présenté l’ennemi : la fragmentation de l’écosystème. Si l’auteur d’un paquet open-source crée un bundle, il ne sera que pour symfony ; s’il écrit un framework, il sera écrasé par les gros (ou se combattra lui-même comme drupal 7 vs 8) ; et pour un développeur, il sera difficile de migrer d’un composant à un autre.

Imaginons le cas de l’auteur d’un paquet open-source qui souhaite interroger une API météo. Il aura besoin d’effectuer une requête HTTP (avec quelle bibliothèque ?), de mettre les résultats en cache (avec quelle bibliothèque ?) et de logguer ce qu’il se passe (avec quelle bibliothèque ?). Pour éviter de coupler le paquet avec une bibliothèque donnée, il est important d’éviter de prendre une implémentation, pour à la place préférer une abstraction. Ici, HTTPplug et des adaptateurs + PSR-6 pour le cache + PSR-3 pour les logs ⇒ et c’est ça qui va dans le composer.json.

Utiliser des interfaces signifie que ce n’est plus à l’auteur du paquet d’instancier des objets : les services requis doivent m’être passés — et c’est donc à l’utilisateur de ma classe de s’en charger… Ce qui veut dire que c’est vers lui qu’on a poussé la complexité / le choix. Dans la vraie vie, les services sont récupérés depuis le conteneur de dépendances. Mais comme l’utilisateur (qui peut utiliser n’importe quel framework pour son application au sein de laquelle il veut brancher notre paquet) veut un module tout fait, qui gère déjà l’injection des services dans le conteneur, on doit mettre en place des modules pour 36 frameworks ;-(

Objectif pour le futur : avoir un seul module pour tous les frameworks, ce qui requiert de pouvoir écrire dans tous les conteneurs de dépendances, qui sont très différents → une sorte de service provider universel. Et c’est justement ce que visent PSR-11 pour getter et container-interop/service-provider (en bêta) pour setter !

Le point sur l’emploi des développeurs

Matthieu Segret, Antoine Crochet-Damais, Xavier LeuneRésumé

Pour terminer ce Forum PHP, un tour sur l’emploi des développeurs autour de PHP, en France — en se basant sur les résultats du baromètre 2016 qui vient de sortir.

Dans l’ensemble : 600 réponses, avec 40% de répondants entre 6 et 10 ans d’XP. 95% d’hommes et seulement 5% de femmes. Majorité en CDI avec un peu de freelance et de CDD. 17% de PHP 7 (adoption rapide).

Pour ce qui est des salaires :

  • 19% en moins hors-IdF vs IdF
  • Fracture entre les nouvelles technos et les trucs plus anciens ; palette large entre les CMS type wordpress et des frameworks beaucoup plus techniques comme symfony (le framework MVC qui s’est imposé en France ; 10% de salaire en IdF en plus par rapport à un profil non spécialisé)
  • De + en + d’expertise requise pour développer. On a des outils pour être plus productifs, mais les exigences sont également plus importantes. D’où barrière parfois plus grande à l’entrée quand on doit se former.
  • Beaucoup d’industrialisation de l’écosystème ces dernières années ; aussi pour arriver au niveau d’autres technos ⇒ beaucoup de composants existant qui aident, mais aussi d’autres problématiques qui apparaissent (“devops” par exemple)
  • Compétition entre les entreprises

Focus sur les femmes dans l’environnement PHP (chiffres sur IdF car c’est là qu’il y a le plus de réponses) :

  • 15% d’écart de salaire par rapport aux hommes tous postes confondus ; 11.2% d’écart pour le poste “développeur” — les femmes étant essentiellement à des postes de développement (et pas lead / architecte / consultant)
  • L’écart en PHP stagne d’une année sur l’autre. La moyenne en France est à 20%.
  • Travail qui se fait au niveau des formations / reconversions / bootcamps, avec autant de femmes que d’hommes. Peut-être que l’intérêt ne vient que après le lycée et la formation initiale ?
  • Il y a 10 ans, peu de gens se sensibilisaient au problème (exemple d’une conférence sur le sujet = personne dans la salle)
  • Image souvent donnée aux métiers peut donner l’impression que ce n’est pas fait pour les femmes, avec des expressions comme « trois mecs dans un garage »

Dernier axe : PHP vs le reste du monde :

  • Un salaire de développeur PHP en France paye 8823 big mac par an ; aux USA c’est à 10555 big mac par an ⇒ différence pas si importante sur la moyenne, même si on voit souvent les exemples extrêmes de SF ou NYC (il y a de grosses disparités géographiques, aux USA)
  • Les salaires PHP sont encore inférieurs à ceux de JAVA, même si ça augmente en PHP alors que ça stagne assez en JAVA. Explication possible : homogénéisation des bonnes pratiques, perméabilité entre les communautés. Rappelons que les deux langages sont sortis la même année — avec Sun/IBM derrière JAVA au départ, là où l’écosystème ne rattrape son retard que depuis 5-10 ans (et Facebook, aujourd’hui, c’est mieux que IBM)
  • Taux de pénétration de PHP, aujourd’hui, augmente ; y compris dans les grands groupes ; aidé par la capacité des frameworks / CMS à s’adapter
  • Nodejs reste encore très marginal, y compris au niveau des recrutements. Côté très hype des startups qui font des micro-services en node/go = ceux qui en parlent le plus, mais ne représentent pas la majorité. Cabinets de recrutement n’ont pas encore de chiffres de salaire pour nodejs !

Cloture

Fin de cette seconde journée, fin du Forum PHP 2016 — et annonce du PHP Tour 2017, qui aura lieu à Nantes ! Le CFP est déjà ouvert ;-)


En conclusion : ces deux jours de Forum PHP ont été l’occasion d’assister à une bonne quinzaine de conférences et d’en présenter une, d’avoir le plaisir de revoir ou de rencontrer pas mal de monde, de discuter de PHP et de sa communauté, de différents projets dont le livre PHP 7 avancé dont je suis co-auteur et qui est sorti deux semaines plus tôt. Bref, deux journées bien remplies, donc !

Encore une fois, merci à l’AFUP, à tous les membres de l’orga, aux conférenciers et au public — et à l’année prochaine ! Ou, peut-être, à dans quelques mois à Nantes ;-)


Mes notes du Forum PHP 2016, jour 1

8 novembre 2016 php, afup, conference, forum-php

Le Forum PHP 2016 organisé par l’AFUP a eu lieu les 27 et 28 octobre, au Beffroi de Montrouge à Paris.

Encore une fois, ces deux jours m’ont permis de revoir plein de monde, de découvrir de nouveaux visages, d’associer des têtes à des pseudos twitter, d’assister à de nombreuses conférences… Et, en bonus cette année, de parler (y compris avec plusieurs lecteurs) du livre PHP 7 avancé dont je suis co-auteur, publié aux éditions Eyrolles tout juste deux semaines plus tôt !

J’ai également eu la chance d’être retenu pour présenter une conférence sur les évolutions que nous avons apportées ces trois dernières années sur notre environnement de développement chez TEA, The Ebook Alternative.

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.

Keynote d’ouverture

Cyril PascalRésumé

Pour lancer cette nouvelle édition du Forum PHP, rapide sondage montrant qu’il y a beaucoup de gens dans la salle dont c’est le tout premier Forum PHP !

Cyril a enchainé en rappelant l’importance des sponsors pour un événement de ce type, puis en nous invitant à organiser des événements en régions ; voire même à monter une antenne locale pour des événements réguliers.

Headers HTTP: Un bouclier sur votre application

Romain NeutronRésumé

En introduction, Romain nous a raconté une anecdote : comment l’extension navigateur Blackfire avait échoué, de manière imprévue, lorsqu’il avait tenté de profiler Github — l’amenant à se documenter sur le sujet des en-têtes HTTP liés à la sécurité.

La suite de la présentation a passé en revue plusieurs types d’en-têtes ; pour certains et en allant au plus simple, il suffit de les ajouter dans la configuration de votre serveur web pour en bénéficier ;-)

Quelques en-têtes simples et rapide :

  • X-XSS-Protection sous Chrome et IE8+ pour lutter contre les XSS reflétées correspondant à du code qui serait injecté dans l’URL
  • X-Content-Type-Option pour désactiver l’auto-détection MIME en spécifiant nosniff
  • X-Frame-Options pour définir si votre site peut ou non être inclus dans une frame ou iframe — et lutter contre certaines tentatives de click-jacking.

L’en-tête Strict-Transport-Security (on parle parfois de “HSTS”) permet à un serveur de forcer le navigateur à l’interroger systématiquement en HTTPS et jamais en HTTP — ce qui évite le downgrade de sécurité vers HTTP. Ca ne fonctionne qu’à partir de la seconde requête (puisque cette information est renvoyée dans la réponse à une première), mais du preloading dans les navigateurs est possible, cf hstspreload.appspot.com.

Ensuite, passage à Content-Security-Policy (ou “CSP”), qui est supporté un peu partout puisque c’est une idée déjà ancienne ! L’objectif est de prévenir les XSS, en déclarant des directives à propos de ce qui peut être exécuté sur le site. En niveau 1, on peut définir des sources de types de données. En niveau 2 (pas encore supporté partout, mais peut tout de même être utilisé puisque les navigateurs ne le supportant pas fallbackeront sur le niveau 1), on peut aller plus loin, en autorisant uniquement certaines balises <script> via des nonces ou en validant leur contenu via un checksum.

Dans la vraie vie, CSP peut être difficile à mettre en place sur des projets legacy, mais des outils peuvent aider, comme nelmio/security-bundle ou des balises Twig pour le calcul des nonces et checksums. La directive suffixée par -report-only permet de tester les CSP et d’obtenir des rapports, sans pour autant bloquer les utilisateurs.

Notons que tout ceci ne fonctionne que pour les navigateur récents (d’où l’importance d’appliquer les MAJ quand on passe sur la machine d’un membre de la famille), que les extensions navigateurs peuvent tout faire et ne pas en tenir compte, qu’un CDN peut être compromis et injecter du code malveillant, et qu’il est intéressant désactiver les trackers (comme Google analytics, qui demande d’exécuter du code JS externe) sur les pages sensibles de vos sites !

Pour le futur, regarder subresource integrity, qui permettra de valider toute ressource via un checksum (date de fin 2015 ; déjà supporté par Fx et Cr), à condition de charger les assets en CORS.

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

Pascal MARTINRésumé

Sur ce créneau, c’était mon tour de présenter ;-)

J’ai parlé de notre environnement de développement au boulot chez TEA ; si vous souhaitez en savoir plus, voici :

Make is an actual task runner

Julien BianchiRésumé

Une partie de notre temps de développeur est utilisé à exécuter les mêmes tâches encore et encore, à longueur de journées ; donc, pourquoi ne pas automatiser ?

En PHP, on a plein d’outils d’automatisation de tâches : phing, robo, bldr, gruntphp, … Mais si un de ces outils dépend (via composer) de composants dont dépend aussi notre projet, mais dans une autre version ⇒ problèmes de conflits de versions sur ces composants. De plus, chaque outil a son propre format de configuration et il faudra donc en apprendre plusieurs au gré des projets.

En allant plus loin : quel outil choisir pour une application mono-repo, avec un projet regroupant plusieurs technos ? Est-ce qu’on prend un task runner en PHP ? En Ruby ? En JS ? Ou plusieurs ?

Dans notre métier, souvent, on ré-invente, alors qu’il pourrait être bon de regarder un peu vers le passé : les problèmes qu’on rencontre aujourd’hui, ce sont les mêmes que ceux qui existaient déjà avant ! Et, dans les années 70, il y avait déjà une réponse au problème de l’automatisation de tâches : make.

Il suffit d’une ligne de commande : make. Et on ajoute un fichier de règles, qui décrivent chacunes une ou plusieurs cibles (nom qu’on choisit ou fichier), dépendant chacune de pré-requis. Et chaque cible est construite par le biais de recettes, des commandes shell.

Cet outil est disponible sur tous les systèmes, il suffit d’un binaire, pas de dépendance au sein de votre projet, compatibilité avec n’importe quelle techno et version. Et fonctionnalités assez complètes (variables, parallélisation, …). Bref, au lieu de réinventer la roue encore et encore avec 36 lanceurs de tâches, peut-être qu’on pourrait en utiliser un qui existe depuis longtemps et qui est mûr ?

La place de PHP dans l’architecture technique de Radio France

Rodolfo Ripado, Florian TissotRésumé

Pour commencer, rapide présentation de Radio France : service public, une dizaine de sites + applis mobiles, évolution des usages rapide demandant de la souplesse dans les architectures techniques. Ancienne archi basée sur un seul site qui faisait tout ⇒ ne tenait pas la charge (ça a cassé pour les municipales 2014) ⇒ grosse refonte. Objectifs : indépendant, toujours disponible, rapide, simple, évolutif, et time to market.

Aujourd’hui, infra en gros dans le cloud, non liée à un vendeur spécifique (actuellement : du AWS et du Google engine), avec docker en développement (+ POC sous Kubernetes pour réfléchir à l’utilisation en production). Workflow de développement assez classique (gitlab, jenkins, capistrano) avec ~60 développeurs.

Au niveau applicatif : basé sur plusieurs technos (le besoin métier doit conditionner le choix technique et pas l’inverse) dont des API en node, du front en php/symfony et du back en php/drupal (pour les interfaces notamment), du go pour la génération de miniatures d’images, rabbitmq, varnish.

À noter : CQRS, PHP pour le gros des applis (XP sur PHP dans l’équipe), saisie des contenus en markdown pour permettre la sortie vers plusieurs formats (web, applis mobiles, …). Quelques éléments pas encore parfaits : trop de logique dans les templates, culture des tests pas encore trop là, “‘symfony’ vs ‘php’” et “‘drupal’ vs ‘php’”, il faut des fois tordre un peu drupal pour tout envoyer dans le bus.

En conclusion, un rappel important (qu’on pourrait généraliser encore, comme souligné par une question de l’audience) : au-delà de la technique, il faut savoir trouver les bons développeurs PHP (en général — et pas drupal / symfony).

Comment relire du code pourri sans se fatiguer

Damien SeguyRésumé

Pour cette session, Damien nous a proposé de passer en revue plusieurs types d’outils d’analyse statique de code, en illustrant à chaque fois ce qu’ils permettaient d’apprendre d’une application — sans que nous ne sachions à l’avance de quelle application il s’agissait ni ce que le code faisait.

Quand on parle d’analyse statique en PHP, on a plusieurs familles d’outils :

  • php -l pour la validation syntaxique du code (info au passage : il y de l’ordre de 2200 messages d’erreurs différents dans PHP 7)
  • Calcul de métriques : phploc, phpmetrics, phpmd
  • Revue de code automatisée : php7cc ; recherche textuelle par mots-clefs ou autres
  • Utilisation d’un AST (représentation du code en mémoire sous forme d’un arbre syntaxique) : php7mar, phan, exakat, sonarqube, phpstorm, …

Au final, le passage du code de l’application d’exemple sous différents outils d’analyse a illustré du code avec des inspirations modernes (des espaces de noms, des fonctions anonymes, …), mais ne fonctionnant qu’en PHP 5.6 au vu des spécificités syntaxiques et classes/méthodes employées (pas PHP 5.5 ni 7.0 — ce qui donne une idée sur la date de création du logiciel), avec des choses un peu étranges faisant un peu peur niveau qualité (comme un répertoire vendor2 et un autre vendor_user), tout en laissant comprendre qu’il devait s’agir d’une application gérant des cours en ligne avec du paiement.

En résumé : en moins d’une heure, passer plusieurs outils d’analyse statique sur une application peut permettre de se faire une idée de ce qu’elle fait et comment et avec quel niveau de qualité, sans avoir à plonger dans son code-source.

De CodeIgniter vers CQRS en passant par la case Capital

Gilles Roustan, Thomas GascRésumé

Un des premiers points abordés par Gilles et Thomas est l’importance des valeurs et pas du CV : les pratiques, les méthodes, les outils — et une discussion à un apéro peut mener à un recrutement au bout de quelques jours ;-)

On est beaucoup dans une mode des micro-services aujourd’hui, mais si chacun bosse sur son truc sans parler au voisin, cela n’arrange rien : il est important d’avoir quelque chose à mettre en production dès la première itération (dès le 1er sprint scrum, par exemple), en travaillant en équipe (et pas que les développeurs) et en pensant à produire de la valeur pour l’utilisateur final — en revenant au coeur du métier et en améliorant des morceaux du coeur du truc.

Suite à un passage à Capital, il est apparu que le site ne tenait pas ; donc mise en place d’une nouvelle application avec du CQRS. Pour rembourser la dette, il faut savoir être créatif (on peut commencer par migrer juste un petit bout de l’appli ;-)).

Au lieu de travailler pendant des mois en mode tunnel (ce qui ne mène à rien, le produit n’étant jamais fini il ne sort jamais), principe de livraison en continu, automatique dès qu’il y a un merge sur master. Demande de penser à effectuer des migrations progressives + feature-flags, en particulier lorsqu’il y a des migrations en DB.

Lightning Talks

Pour terminer cette première journée du Forum, une série de 7 lightning-talks de cinq minutes chacun — je n’ai pas tellement pris de notes, c’est difficile sur ce type d’exercice, mais les vidéos devraient être disponibles prochainement.

Tout de même, pour au moins garder la liste sous la main :

  • Chaînes et WTF en PHP : bon, on le sait, il y a des trucs un peu bizarres en PHP (chaque nouvelle version en corrige quelques uns ;-) )
  • PHP horror story
  • Array tips : en PHP aussi, on peut user et abuser de fonctions comme celles de manipulation de tableaux, pour écrire des trucs fanstastiques (et inmaintenables) en une seule ligne !
  • Atoum : quelques mots sur ce framework de tests unitaires
  • Stranger things : PHP a longtemps été synonyme d’outils comme phpnuke, spip, wordpress, … et nous ne serions certainement pas où nous en sommes aujourd’hui si ceux-ci n’avaient pas démocratisé le langage et sa philosophie
  • phpMetrics : un outil d’analyse statique qui vous donnera des informations sur le code de votre application
  • Et pour finir, quelques mots sur l’AFUP : cette association qui organise deux événements communautaires majeurs chaque année, qui est basée sur des gens qui font un super boulot, et qui a besoin de nous tous !

Pour la soirée, l’AFUP nous a proposé de nous rejoindre autour d’un verre — donnant l’occasion de revoir plein de membres de la communauté que je ne croise qu’une ou deux fois par an !


Transcript de ma conférence « Notre environnement de développement n’est plus un bizutage ! » au Forum PHP 2016 Paris

3 novembre 2016 afup, forumphp, conference

Le 27 octobre, j’étais présent au Forum PHP 2016 organisé par l’AFUP, pour une présentation intitulée « Notre environnement de développement n’est plus un bizutage ! ». J’ai publié les slides il y a quelques jours et, si vous voulez en savoir plus, voici une tentative de transcript de cette conférence — c’est la première fois que je rédige un post de ce genre, je suis preneur de vos retours ;-)

Vous trouverez en-dessous de chaque slide le texte correspondant, éventuellement enrichi de quelques informations que je n’ai pas données lors de la présentation, puisque celle-ci ne durait que 40 minutes questions incluses.

Slide n°001

Bonjour à tous ! Je suis ici aujourd’hui pour vous raconter une histoire, autour de l’environnement de développement avec lequel je travaille au quotidien.

L’installation d’un environnement de développement est parfois, ou souvent, vue comme un réel bizutage par les nouveaux embauchés… Alors que l’expérience gagne à être plus positive que cela !

Slide n°002

Il y a trois ans, j’ai changé d’employeur.

Slide n°003

Lors de mon arrivée au bureau le premier jour, un de mes collègues m’a dit « Bienvenue ! ». Il a enchaîné par « tu veux un café ? ». Ceux qui me connaissent devineront sans mal ma réponse.

C’était sympa, accueillant…

Slide n°004

… Mais, ensuite, il a continué avec ces quelques mots : « tu vas mettre une semaine à installer ton poste ».

Slide n°005

Bon, il n’y avait pas eu de nouvel arrivant dans la boîte depuis quelques temps, la plate-forme était peut-être un peu compliquée et il y avait certainement quelques petites choses à améliorer ou qui n’étaient pas encore parfaitement en place.

Je peux comprendre, les collègues avaient eu pas mal de boulot ces derniers temps, après tout.

Slide n°006

Quelques heures plus tard, après m’avoir présenté le gros de l’architecture de la plate-forme, un autre collègue — mon chef — en a remis une couche avec cette phrase : « ils ont dû te dire, tu vas en avoir pour deux semaines à installer ta machine ».

Slide n°007

Et là, tout de même, je me suis dit « what ??? ».

Slide n°008

Parce que même si l’archi était effectivement un peu complexe, je me suis sacrément posé des questions : pendant deux semaines, je n’allais rien faire ? Je n’allais rien déployer en production ? Je n’allais pas être productif ? Et aussi, un peu d’inquiétude : comment allais-je prouver que j’avais ma place dans cette entreprise, si je n’étais pas en mesure de montrer quoi que ce soit après tout ce temps ?

Slide n°009

Alors, avant de continuer, un peu de contexte, à la fois pour mettre un cadre autour de l’histoire et, peut-être, pour tenter d’expliquer pourquoi ces deux semaines

Slide n°010

Je bosse dans une société qui s’appelle « TEA, The Ebook Alternative ». On est une start-up dans l’univers du livre numérique, à Lyon, créée il y a un peu plus de 5 ans.

Slide n°011

Ajourd’hui, on est une petite vingtaine de personnes, dont 10 dans l’équipe technique. Mais, il y a trois ans, quand j’ai rejoint cette équipe technique qui était de taille plus réduite, je n’étais que le 4ème développeur.

Même si nous sommes autant que possible multi-task, certains d’entre nous sont plus orientés front, d’autres back, certains s’y connaissent plus en admin système que d’autres, … Et selon les personnes et les moments, nous allons du stage en alternance à 10+ ans d’XP.

Slide n°012

Plusieurs choses sont aujourd’hui fixées (et certaines l’étaient déjà il y a trois ans) et nous n’envisageons pas, aujourd’hui, de les remettre en cause :

  • Nous bossons sous Git avec Github — en faisant des PR pour tout
  • Nous avons des PCs sous Linux (distrib au choix) ou des Mac ; des portables, aujourd’hui.

Un point extrêmement important pour moi : quand un truc ne va pas, on l’améliore. Quand un truc va à peu près, on l’améliore. Quand un truc va super bien, on trouve autre chose à améliorer.

Et enfin (et ça peut avoir son importance pour la suite de cette conférence), même si on a des notions d’ops, ce n’est pas vraiment notre métier (et on a vraiment plein d’autres choses à faire — même à 20, on aurait encore du boulot), donc on a choisi de payer un hébergeur pour s’occuper des serveurs : nous ne sommes pas root sur nos machines de production et si nous avons besoin d’installer un service, nous saisissons un ticket.

Slide n°013

En parlant de production, nous utilisons plein de services différents, plein de technos différentes, plusieurs langages, différents frameworks ; bref, on ne s’ennuie pas !

Slide n°014

Sur tout ça, nous faisons tourner une vingtaine de projets avec une bonne dizaine de technos différentes. Et nos applications peuvent, dans certains cas, être fortement liées, communiquant par APIs (avec, donc, des clefs d’API configurées des deux côtés) ou via des requêtes base-à-base (même si c’est peu élégant, en somme, ça marche).

Slide n°015

Bien sûr, ces projets et technos utilisés en production, nous les retrouvons sur nos environnement de développement et ça participe à leur complexité.

En effet, autant que possible, nous souhaitons que nos environnements de développement soient proches de la production, pour être confiant dans le fait que nous ayons pris en compte les contraintes correspondantes ; et que ça marchera quand nous déploierons.

Nous nous permettons toutefois une exception : on ne reproduit pas, en environnement de développement, ce qui est du genre load-balancing, fail-over, réplication de base de données, … Tout ça, c’est du ressort de l’hébergeur et n’a généralement pas trop d’impact sur nos développements applicatifs.

Slide n°016

Quand je suis arrivé chez TEA, nous n’avions aucune automatisation pour la mise en place d’un poste de développement. Rappelons qu’au départ, il n’y avait que 2 devs pour tout faire — et pour une startup qui démarre, il faut livrer avant tout.

Slide n°017

En regardant ce que mes nouveaux collègues utilisaient, j’ai vu du VirtualBox sur leurs postes. Cool, de la virtualisation, c’est bon signe !

Mais en fait, aucun système de provisionning n’était utilisé. À la place, il fallait passer par une installation à la main d’une ISO (idéalement, la même qu’en prod), puis installer à la main tous les logiciels et services. Et ensuite, toujours à la main, il fallait mettre en place toute la configuration.

Slide n°018

Heureusement, il y avait de la doc \o/.

Mais elle était sur un wiki… En fait non, sur deux ! Et les deux n’étaient pas toujours d’accord entre eux ! Et ces documents étaient composés de notes allant un peu dans tous les sens, de commandes à copier-coller et/ou de fichiers à adapter ou d’instructions du genre « remplacer X par la bonne valeur ».

Et bien sûr, ils n’était aussi pas mis à jour aussi régulièrement qu’il n’aurait fallu.

Slide n°019

Au final, pour réussir à installer mon poste, je me suis retrouvé à devoir me connecter sur un peu tous les serveurs de prod pour voir quels services tournaient dessus, en quelles versions, et comment ils étaient configurés. Alors que je venais d’être embauché.

Bah… J’aime autant vous dire que ce n’est pas bien drôle ^^

Slide n°020

Et malgré tout ça, je ne m’en sortais quand même pas, je n’arrivais pas à installer et configurer l’ensemble des projets !

Finalement, pour que je m’en sorte, il a fallu qu’une de mes collègues prenne son PC (fixe à l’époque ; donc une tour + un écran) et vienne s’installer avec moi à mon bureau… Pendant une semaine !

Donc, pendant deux semaines, je n’ai pas été productif ; et en plus de ça, pendant une semaine, elle non plus ! Ca fait mal !

Et à force d’essayer un truc puis un autre, mon poste tout récemment installé, c’était un gros mélange de tentatives ratées et de fichiers de configuration qui tenaient avec des bouts de scotch !

Slide n°021

Quelques mois après, nous avions pour objectif d’accueillir plusieurs nouveaux dans notre équipe. Et donc, il devenait temps de réellement songer à améliorer cette partie !

Slide n°022

En termes d’outillage, nous avons gardé VirtualBox, qui marchait bien, que ce soit sous Linux ou sous Mac.

Et on a ajouté Vagrant et Chef pour automatiser.

Slide n°023

Vagrant, en faisant très simple, ça permet d’automatiser la création d’une machine virtuelle, de manière à ce qu’elle soit configurée à l’identique chez tout le monde.

Slide n°024

Par exemple, ici, nous avons un extrait de fichier Vagrantfile, qui permet de définir un nom de machine, une adresse IP, une quantité de mémoire…

Et vous utilisons un outil nommé chef solo pour le provisionning.

Slide n°025

Chef, c’est une grosse usine à gaz qui permet d’installer des logiciels de façon automatisée et reproductible sur plein de serveurs.

Ca fonctionne également sur une seule machine, comme dans le cadre de la VM créée juste avant avec Vagrant.

Slide n°026

Voici un exemple de recette Chef, qui installe un serveur Percona (une version de MySQL), crée un fichier de configuration à partir d’un template en l’affectant au bon utilisateur, active MySQL au démarrage de la machine et configure son utilisateur root.

C’est juste un exemple, mais il est proche de l’installation de notre machine virtuelle base de données — et l’exécution de cette recette donne toujours le même résultat : un serveur MySQL installé et configuré à l’identique, de manière automatique, chez tous les développeurs de l’équipe.

Slide n°027

Arrivés ici, on a des VM qui sont créées, avec les services installés et configurés. Il ne reste plus qu’à injecter des données dedans pour pouvoir bosser.

Nous avons des backups réalisés régulièrement en production. Nous pouvons donc les télécharger, puis les adapter en supprimant les données confidentielles ou en anonymisant certaines choses. Pour cela, nous avons fait simple : un peu de script bash et quelques requêtes SQL.

Un autre exemple de données : pour le moteur de recherche Solr que nous utilisons sur certaines applications, nous reconstruisons ses indexes depuis les données importées en base juste avant.

Slide n°028

Avec tout ça, monter un environnement de développement pour un projet devrait se résumer à quelques étapes : récupérer les sources du projet, créer et provisionner la machine virtuelle, installer les dépendances, et voila !

Slide n°029

Mais en fait non : après ces étapes, les tests des applications ne passent pas (et elles ne fonctionnent pas — ce n’est pas un problème du côté des tests).

Slide n°030

En effet, il reste un point important à prendre en compte : l’application doit être configurée correctement — et ce n’est pas aussi simple qu’on pourrait le croire. Rappelez-vous : nous avons de nombreuses applications, qui échangent parfois des données par le biais d’APIs, avec une clef secrêtes partagées des deux côtés.

Au départ, nous suivions une logique assez classique dans la communauté PHP : des fichiers .dist commités. Pour installer une application, il fallait trouver tous les fichiers .dist du projet, les copier pour créer les fichiers correspondant sans le .dist, puis trouver toutes les valeurs à renseigner.

C’était juste infernal : les fichiers .dist commités n’étaient pas toujours à jour… Et allez deviner les bonnes valeurs à renseigner pour plusieurs dizaines de fichiers de configuration répartis sur plusieurs applications !

Du coup, on a complètement laissé tomber ce principe et nous avons choisi d’utiliser un petit utilitaire en ligne commande. Quelque chose d’extrêmement pratique et disponible sous Linux et sous Mac : stow.

Slide n°031

La meilleure façon de parler de stow, c’est de montrer ce qu’il fait.

Ici, on a un morceau d’arborescence d’un projet, extrait depuis Git. Notez l’existence du répertoire que nous avons nommé config-dist : il contient un répertoire par environnement — et le seul environnement qu’on ait ici est notre environnement de développement, nommé local. Ce répertoire contient tous les fichiers de configuration, avec les bonnes valeurs pour que le projet fonctionne.

On peut se permettre de commiter ces fichiers, puisque chaque développeur de l’équipe a le même environnement et que les mots de passe ou clefs d’API en développement, c’est du genre “toto” et “tutu”.

Slide n°032

Une fois le projet extrait depuis Git, on lance la commande stow en lui indiquant le répertoire config-dist où sont placées les configurations et le nom de notre environnement local.

Slide n°033

Quand on lance cette commande, stow recrée toute l’arborescence, via des liens symboliques depuis le projet vers l’environnement dans config-dist/local.

Et bonus intéressant : si quelqu’un modifie un fichier de configuration, la modification passe dans la PR de la feature sur laquelle il bossait et tous les collègues en profitent immédiatement.

Slide n°034

En production, nos applications se parlent via des noms de machine : « serveur de base de données », « moteur de recherche », …

Sur nos environnement de développement, nous souhaitons reproduire ce principe (et pas passer par des IP, par exemple). Donc, au départ, nous tenions à jour les fichiers /etc/hosts manuellement… Sur les 5 machines virtuelles et sur le poste physique de chacun des développeurs.

À raison de 4 développeurs dans l’équipe à ce moment là, nous avions 24 endroits à adapter à chaque modification. L’enfer !

Slide n°035

Pour simplifier, nous avons regardé un peu ce qu’il se faisait dans la communauté et nous avons choisi d’installer un serveur DNS nommé dnsmasq (bien plus facile à configurer que bind) au seul endroit qui soit toujours lancé : la machine physique.

Donc : nous n’avons plus qu’un seul endroit où effectuer les configurations IP ↔ nom de machine. Oui, c’est encore un peu manuel ; mais la manipulation n’est plus à effectuer qu’une seule fois par développeur… Il y a déjà du mieux !

Slide n°036

Et donc, enfin, on a atteint notre objectif \o/

Slide n°037

Nous n’avons plus que quelques commandes à exécuter pour récupérer les sources d’un projet, lancer sa machine virtuelle (ça la crée et lance le provisionning), installer les dépendances et déployer la config… Et, succès, les tests passent \o/

Slide n°038

Quand j’ai donné cette présentation pour la dernière fois, au PHP Tour Lyon il y a deux ans et demi, on s’était arrêté là…

Mais, depuis, on a continué à améliorer ! Et notamment, on a rapidement commencé à s’intéresser à un outil dont on parlait beaucoup, à l’époque, dans la communauté : docker. Points intéressant : isolation de services et plus virtualisation de machines (donc, moins gourmand en RAM — parce que 5 VM sur 8 GB de RAM, ce n’est pas facile, surtout quand on descend l’ensemble du jeu de données de la production !)

Slide n°039

Au risque d’en froisser quelques-uns, pour résumer rapidement, ce dont on a besoin pour notre environnement de travail se base sur trois idées :

  • Un fichier nommé Dockerfile permet de décrire comment créer une image
  • La commande docker build permet de créer cette image à partir du Dockerfile
  • Et la commande docker run permet d’exécuter un conteneur à partir de cette image.

Slide n°040

Nous voulions tester docker, mais sans pour autant basculer vers docker : l’environnement sous vagrant/virtualbox fonctionnait et, même si nous souhaitions tester un second environnement d’exécution, nous voulions initialement conserver les recettes Chef.

Objectif : un seul moyen de construire l’environnement de développement pour toute l’équipe (chef), même si deux environnements d’exécution (virtualbox / docker) étaient utilisés.

Slide n°041

Pour cela, nous sommes passé par un Dockerfile qui part d’une image Debian (à l’époque, une wheezy), y ajoute les recettes chef créées précédemment, puis les exécute — à l’aide du même chef solo que celui employé pour le provisionning sous Vagrant.

Slide n°042

À l’époque, il n’y avait pas d’outil bien foutu pour gérer le démarrage d’un container à partir d’une image (pas de docker compose ; et fig, son ancêtre, ne faisait pas ce dont on avait besoin). Donc on a fait quelque chose de bien moche (mais qui marchait et qu’on savait mettre en place facilement).

Slide n°043

Pour chaque projet, nous avons créé un fichier run.sh, qui contient la commande qui permet d’exécuter le conteneur correspondant — avec le partage de dossier contenant le code source, le pointage vers le serveur dnsmasq en local, …

Les dernières ligne en bas de l’écran, c’est la récupération de l’IP du container pour l’ajouter à la config dnsmasq et relancer dnsmasq. Non, ce n’est clairement pas parfait ; mais ça marche pas trop mal ; et ça répond à notre besoin.

Slide n°044

Il reste que constuire une image en exécutant les recettes chef, ça prend du temps, surtout quand on n’a pas la fibre au bureau.

Donc, pour faciliter les choses, une seule personne construit / met à jour une image et la partage aux autres. Ce partage se fait par le biais d’un registre (comme hub.docker.com qui permet d’obtenir des images de la communauté) interne à l’entreprise.

Slide n°045

Malgré tout, la maintenance des environnements est compliquée : puisqu’on n’a que rarement besoin de faire évoluer les recettes chef, nous ne sommes pas vraiment montés en compétence sur le truc… Et on galère pas mal !

Quand on a changé d’hébergeur, on a même proposé nos recettes (qui fonctionnaient !) à notre nouvel hébergeur, pour qu’il voit ce dont on avait besoin et peut-être même pour qu’ils s’en servent pour installer nos machines… Ils nous ont fait « oué en fait non, on va faire à notre façon »… Vous en tirerez le message que vous voulez ^^ (bon, ils utilisent un outil nommé puppet et pas chef, ça joue aussi)

Slide n°046

Tout à l’heure, je parlais du fichier Dockerfile, qui décrit comment construire une image docker.

Pour tester une migration vers PHP 7.0 et voir si une de nos applications tournait sur cette version, je ne voulais pas passer des heures à me battre avec des recettes chef. Donc j’ai tout refait, pour ce projet, uniquement via un Dockerfile.

Slide n°047

En simplifiant un tout petit peu, un Dockerfile, c’est juste une suite de commandes shell. En fait, à peu de choses près, on peut exécuter des commandes apt-get, les tester, et si elles marchent les copier-coller vers un fichier, rajouter RUN devant… Et voila, on a un Dockerfile !

Et une suite de commandes shell, dans l’équipe, tout le monde sait faire. Donc, une fois qu’on a vu à quel point c’était plus facile pour nous, on a décidé petit à petit de virer les recettes chef sur tous les projets, au fur et à mesure qu’on avait besoin de modifier des choses dedans (ça fait bientôt un an, il reste du chef sur deux-trois images qu’on ne reconstruit quasiment jamais, mais elles vont disparaitre dans le futur, je n’en doute pas).

Slide n°048

Le registre interne pour partager les images crées ou mises à jour, bien sûr, on l’a conservé : gros gain de temps, qui permet à tout le monde d’avoir une image à jour en 3 minutes (il suffit de pinguer sur Hipchat pour que tout le monde lance un docker pull et récupére l’image re-construite par quelqu’un d’autre).

Slide n°049

En plus, Docker est fort pratique pour valider des nouveautés, comme tester des nouvelles versions de PHP ou une nouvelle version de nginx qui permette d’activer HTTP/2.

Typiquement, quand j’ai une demi-heure à un moment, je peux switcher de version de PHP pour un projet (il suffit d’arrêter un container et d’en lancer un autre) et corriger une ou deux éventuelles incompatibilités ;-)

Slide n°050

Pendant des années, nous n’avions pas d’intégration continue ; et c’est quelque chose qui nous manquait ! À raison de deux semaines pour installer une machine, malheureusement, ce n’était juste pas possible.

Maintenant, il suffit d’un docker pull pour récupérer une image depuis notre registre interne ; et cette image marche, puisqu’elle est utilisée quotidiennement par les développeurs de l’équipe !

Donc, on a lancé un jenkins, puis on a joué les tests sur master d’un projet toutes les nuits… Et on a vu que des fois, on oubliait de lancer les tests en local et qu’on avait livré la veille des trucs cassés ! Puis on a fait pareil sur tous les projets. Et puis ensuite sur les PR (on fait toujours des PRs pour tous nos développements) d’un projet, et enfin sur les PR de tous les projets, avec intégration des résultats directement dans github \o/

Donc, le travail qu’on a fait sur nos environnements de développement, ça nous a également apporté en qualité et en confiance sur l’ensemble de nos projets !

Slide n°051

En fait, il est super important d’expérimenter : c’est comme ça qu’on a mis en place vagrant + chef. Puis qu’on les a viré parce qu’on a trouvé quelque chose qui répondait mieux à nos besoin !

Et puis, expérimenter, c’est aussi tester des logiciels, ou tester des choses (comme plusieurs versions de PHP) sur nos projets et applications ;-)

Par exemple, la prochaine chose qu’on va tester, c’est mettre à jour notre Elasticsearch. Facile, quand il suffit de stopper un container / en lancer un autre : pas besoin de passer des heures en installation ou de casser un environnement pour tester !

Slide n°052

Dans tous les cas, l’environnement de développement, la première chose qu’on lance le matin avant même de commencer à coder, c’est comme le code des projets : ça demande du travail pour corriger, améliorer et créer de nouvelles images quand on lance de nouveaux projets.

Et aussi et surtout, il faut savoir faire des compromis : les puristes diront qu’il faut faire ceci et cela, ou que ce que nous avons fait est moche. Et des fois, ça l’est, effectivement ! Mais ça marche et ça nous fait gagner énormément de temps — et c’est ce qui compte : notre métier, ce n’est pas de mettre en place des environnements de développement, mais de mettre des projets en prod !

Slide n°053

Finalement, aujourd’hui, monter notre environnement de développement n’est plus un bizutage !

Ou presque ?

Slide n°054

Bien sûr, on a encore du boulot et des choses qu’on peut améliorer.

Slide n°055

Il y a quelques semaines, un nouveau développeur a rejoint notre équipe. Son 3ème jour chez nous, en début d’après-midi, il a déployé en production pour la première fois. Oui, il lui a fallu moins de 3 jours pour installer son poste, découvrir un projet, commencer à coder, passer la pull-request et déployer !

Par rapport aux deux semaines qu’il m’avait fallu quelques années auparavant, hein ! J’aime autant dire que j’étais fier du travail accompli par toute l’équipe pour faciliter l’intégration des nouveaux arrivants !

Slide n°056

Mais pourtant, quand j’en ai parlé avec lui pour préparer cette conférence, il m’a dit quelque chose qui m’a rappelé ce que j’avais moi-même dit lorsque j’étais à sa place : « je ne me suis pas senti productif ».

Et là, on voit le pouvoir du nouveau : percevoir les choses différemment. Là où un ancien voit que les choses se sont (nettement) améliorées, un nouveau qui n’a pas la même histoire en tête verra qu’elles ne sont pas encore parfaites et qu’elles pourrait être améliorées encore !

Slide n°057

En fait, il reste encore plein d’opérations manuelles pour installer un poste de développement, malgré tout ce qu’on a automatisé et simplifié : il faut installer l’OS et les logiciels (avec une connexion ADSL, ça prend un moment), il faut cloner tous les repos de tous les projets, déployer leur configuration, installer toutes les dépendances, obtenir les images docker depuis le registre interne, télécharger les dumps depuis la prod (connexion ADSL à nouveau) puis les importer en local, créer/déployer les clefs SSH, configurer compte github, configurer compte google, …

Et bien sûr : il faut également comprendre comment le tout fonctionne !

Slide n°058

On dit souvent que passer du temps à dérouler des étapes d’installation est bien pour un développeur, que ça lui permet de découvrir la plate-forme.

Mais, quand même, une plate-forme entière présentée en moins de trois jours ? Aucune chance que le nouvel arrivant retienne tout, au contraire, vous allez l’assomer ! Encore plus si c’est un débutant, qui doit découvrir plein de technos en plus de vos projets !

Et puis, au fur et à mesure que l’équipe grossit, d’autre profils vont la rejoindre. Des dev front ou des intégrateurs HTML, par exemple. Et ils n’ont pas besoin de comprendre les subtilités des composants backend de la plate-forme !

Et aussi, puisque ça peut arriver à tout le monde et que ce n’est jamais drôle : il y a un peu plus d’un an et demi, en arrivant au bureau un matin, la porte était arrachée, tous les PC volés (aucun mac, bizarrement — ça doit pas permettre de bosser ?). Et là, c’est plus de la moitié de l’équipe qui a dû réinstaller son poste. Dur niveau productivité, si ce n’est pas une opération rapide !

Slide n°059

Au long de cette conférence, j’ai parlé de pas mal de choses, j’ai raconté un peu ce qu’on avait fait chez TEA ces dernières années.

Aujourd’hui, si je devais vous proposer une façon d’avancer, ça serait probablement celle-ci :

  • Commencez par mettre en place une image docker pour un projet ; celui que vous connaissez le mieux, celui qui vous amuse le plus, ou le plus simple.
  • Une fois que ça marche, parlez-en autour de vous, pour convaincre vos collègues que le gain de temps est réel.
  • Pour faire gagner encore plus de temps, d’ailleurs, un registre interne peut vous aider : c’est une image docker à lancer.
  • Bien sûr, documentez : ça peut servir si vous passez sous un bus !
  • Et puis, une fois que ça roule sur un projet, passez au suivant. Ou mieux encore, mettez-vous à deux avec un/une collègue, pour diffuser la connaissance dans votre équipe !

Slide n°060

Bien sûr, expérimenter ne mène pas toujours à une solution parfaite — et encore moins du 1er coup ! Mais c’est comme ça qu’on avance, par petits incréments.

Gardez tout de même à l’esprit que nous ne sommes pas là pour mettre en place un environnement de dev de façon parfaite ; on est là pour travailler sur nos projets !

Slide n°061

Je m’appelle Pascal MARTIN, vous avez mes infos de contact à l’écran. Je bosse chez TEA, à Lyon.

Merci tous pour votre attention :-)

Slide n°062

Pour terminer et avant de prendre quelques questions, j’aimerais vous parler d’un projet qui me tient particulièrement à coeur : j’ai participé à l’écriture d’un livre nommée « PHP 7 avancé », publié il y a tout juste deux semaines. Si vous connaissez des étudiants ou avez des collègues qui souhaitent se mettre à PHP, pensez-y, ce livre est fait pour eux ;-)

Merci !


Introduction à Sysdig : slides de ma présentation à Lyon, le 26 septembre 2016

26 septembre 2016 slides, sysdig, afup, aperophp

J’ai eu la chance d’être invité mercredi 26 septembre par l’antenne lyonnaise de l’AFUP, pour parler de sysdig, en introduction à une conférence sur le monitoring donnée ensuite par Rachid Zarouali.

Sur une douzaine de minutes, j’ai présenté rapidement l’outil et, surtout, montré des exemples d’utilisation que j’en ai, sur des cas réels rencontrés au boulot : des projets principalement en PHP, exécutés sur mon environnement de développement, dans des containers docker.


Les slides que j’ai utilisés comme support sont disponibles en ligne1 : Sysdig : une introduction, AFUP Lyon, 21 septembre 2016.


Merci à @AFUP_Lyon pour l’organisation et l’accueil, ainsi qu’à Rachid Zarouali pour sa conférence !



  1. 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

PHP 7.1: a few bc-breaks and conclusion

September 16, 2016 php, php-7.1, engligh

Cet article est aussi disponible en français.
This is the 11th — and last — post in a series about PHP 7.1.


To conclude this series of posts about PHP 7.1 I started two weeks ago, I will list a few points that could, especially if your code is a bit legacy, slow down upgrading.


A few BC-breaks?

In the mind of many of us, a minor version should not bring any change that breaks compatibility: code running on PHP 7.0 should work the same way on PHP 7.1 and this new version should only bring new features and bug fixes.

This principle is also written down in the Release Process RFC:

Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6.


Still, we often consider as OK for a minor version to add new E_DEPRECATED or E_NOTICE warnings, to highlight features that will be removed in the next major version or points that could be linked to bugs in our code — I even wrote about this yesterday.


That being said, behavior of some things — quite specific and rarely used — will change with PHP 7.1. I’ll list them here, as they could be of interest if your code was depending on those.


Warn about invalid strings in arithmetic

PHP is a weakly typed language, and we can do numerical calculations on strings: they are converted to integers, following the rules specified in the manual. For example, "10 pommes" can be interpreted as the number 10.

This means the following piece of code actually adds two numerical values:

var_dump('10 apples' + '5 oranges');
// int(15)


This approach was fitting well in PHP’s mindset some years ago, but is now often thought as surprising.

PHP 7.1 still accepts this syntax, but will generate a E_NOTICE warning each time such a conversion is done automatically, to get the developer’s attention:

// Notice: A non well formed numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 7
// Notice: A non well formed numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 7

If you really want this kind of conversion, you can still use explicit type-casting like (int)"10 apples".


Another case has been changed for PHP 7.1, when a string is converted to a numeric while it didn’t contain one:

var_dump(10 + "plop");
// int(10)

Instead of a E_NOTICE, this case, more surprising and probably caused by an error, now raises a E_WARNING warning:

// Warning: A non-numeric value encountered in .../01-warn-invalid-string-arithmetic.php on line 12

Note this is a warning and not a TypeError exception, which would have a much higher impact on compatibility.

‣ The RFC: Warn about invalid strings in arithmetic


Fix inconsistent behavior of $this variable

Up to PHP 7.0, we could in some situations redefine the $this variable, using a variable variable:

class MaClasse
{
    public function method()
    {
        $var = 'this';
        $$var = "plop !";
        var_dump($this);
        $this->otherMethod();
    }

    public function otherMethod()
    {
        var_dump(__METHOD__);
    }
}

$obj = new MaClasse();
$obj->method();

This portion of code, run with PHP 7.0, leads to the following output:

string(6) "plop !"
string(21) "MaClasse::otherMethod"

The first var_dump() show $this has been redefined and now contains "plop !", but the second var_dump() proves calling $this->otherMethod() still works!


As this behavior is quite surprising, this kind of redefinition of $this is not accepted by PHP 7.1 anymore and will cause an Error exception:

Fatal error: Uncaught Error: Cannot re-assign $this in .../02-fix-inconsistent-this.php:8

‣ The RFC: Fix inconsistent behavior of $this variable


Replace "Missing argument" warning with "Too few arguments" exception

With current versions of PHP, we can call a function, passing it less arguments than it expects:

function my_function($a, $b)
{
    var_dump($a, $b);
}

my_function(10);

Until PHP 7.0, this was causing a E_WARNING warning, and unspecified parameters were set to NULL:

Warning: Missing argument 2 for my_function(),
    called in .../03-missing-argument-exception.php on line 9
    and defined in .../03-missing-argument-exception.php on line 3
int(10)
NULL

As the second parameter is declared in the function’s prototype, we rarely take the time to check if it’s been received — which can lead to strange behaviors.


With PHP 7.1, this warning is transformed to an Error exception; which is much harder to just ignore!

Fatal error: Uncaught Error: Too few arguments to function my_function(),
    1 passed in .../03-missing-argument-exception.php on line 8
    and exactly 2 expected in .../03-missing-argument-exception.php:3

‣ The RFC: Replace “Missing argument” warning with “Too few arguments” exception


Forbid dynamic calls to scope introspection functions

PHP gives us a few functions that manipulate their caller’s scope: extract(), compact(), parse_str(),… They all have access, in read or write mode, to variables defined in the function from which they are called.

For example:

function my_function()
{
    $vars = [
        'a' => 123,
        'plop' => 'Hello',
    ];

    $func = 'extract';
    call_user_func($func, $vars);

    var_dump($a, $plop);
}

my_function();

With PHP 7.0, this portion of code gets us the following output:

int(123)
string(5) "Hello"

Still, with dynamic calls like call_user_func() or the $func() syntax (or other approaches), the way these functions behave is not always clearly defined — I was almost lucky it did what I wanted; here…


With PHP 7.1, dynamic calls to functions that manipulate scope are not allowed anymore and will result in a E_WARNING warning:

Warning: Cannot call extract() dynamically in .../04-dynamic-call-scope-introspection-functions.php on line 11
NULL
NULL

‣ The RFC: Forbid dynamic calls to scope introspection functions


PHP 7.1, conclusion

To conclude this series of almost a dozen posts about PHP 7.1, what can I say?


This second minor version of the PHP 7 branch, which is going to be released about one year after PHP 7.0, brings its share of new stuff — including features I find interesting and will use, like:

  • nullable types
  • The iterable pseudo-type
  • The Closure::fromCallable() method
  • A few small enhancements to syntax and consistency

It is also, clearly, an evolution and not a revolution: this should make migrating from PHP 7.0 quite easy.


Still, I’m a bit sad seeing several bc-breaks, which don’t all seem justified to me for this minor version. Even if they should not have much impact on the applications I’m working on, they might scare less adventurous developers and slow down adoption of this new version.


And, finally, one reminder: take a loot at the Supported Versions page every now and then. You’ll for example notice active support for PHP 7.0 ends in about one year, leaving place to PHP 7.1 ;-)