Mes notes du Forum PHP 2016, jour 1

8 novembre 2016php, afup, conference, forum-php
 Cet article a été rédigé il y a plusieurs années et peut ne plus être tout à fait à jour…

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 !