PHP 7.x : slides du meetup AFUP à Marseille/Aix et Montpellier, les 21 et 22 février 2017

28 février 2017 slides, afup, conference, php

J’ai eu la chance d’être invité à Marseille/Aix mardi 21 février et à Montpellier mercredi 22 février par les deux antennes locale AFUP présentes dans chacune de ces deux villes, pour parler de PHP 7.


Sur une bonne heure et demie, j’ai commencé par un bref rappel de l’histoire de PHP, avant de passer le plus gros de la soirée à présenter les nouveautés de PHP 7.0 et de PHP 7.1.

J’ai ensuite rapidement listé quelques premiers points qui pourraient arriver avec PHP 7.2, peut-être en fin d’année, avec de rappeler à tous que l’appel à conférenciers et à conférencières est encore ouvert pour le prochain PHP Tour, qui se tiendra cette année à Nantes.

Enfin, gràce à Eyrolles, j’ai conclut en offrant quelques exemplaires du livre PHP 7 avancé dont je suis co-auteur.


Les slides que j’ai utilisés comme support sont disponibles en ligne1 : Meetup PHP 7.x, Marseille/Aix et Montpellier, février 2017.


Merci à @AFUP_Marseille et à @Afup_Mtp pour l’organisation de ces deux événements et leur accueil !



  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 Tour 2017 : à vous de présenter une conférence !

24 janvier 2017 php, afup, phptour

Le Call for Papers du PHP Tour 20171 est ouvert jusqu’au 12 mars.

J’ai assisté à de nombreux évènements organisés par l’AFUP ces dix dernières années. Je sais qu’ils regroupent toujours de nombreuses personnes avec qui j’aime échanger et qu’ils sont l’occasion d’assister à plusieurs conférences fort intéressantes — un bon nombre de sujets ont d’ailleurs déjà été proposés.


Cette année, j’aimerais voir un peu plus de nouvelles têtes, en particulier parmi les conférencières et conférenciers. Je souhaiterais apprendre de nouvelles choses, tout en aidant et encourageant des personnes qui n’ont encore jamais donné de conférence à se lancer.

Vous pensez n’avoir rien à dire ? Je suis convaincu que c’est faux ! Si vous êtes en train de lire ce post, c’est que vous êtes curieuse ou curieux, que vous aimez ce que vous faites et j’ai donc du mal à croire que ne fassiez rien d’intéressant !

Vous hésitez à y aller, vous stressez à l’idée d’être sous le feu des projecteurs, sur scène devant 50 à 500 personnes ? C’est normal ! Mais je sais qu’avec du travail, du temps de préparation2 et quelques répétitions, la conférence se passe très souvent fort bien.

Et en plus, plusieurs membres de l’antenne lyonnaise de l’AFUP sont disponibles pour vous aider, pour vous donner leur avis ou des conseils si vous le souhaitez, pour vous rassurer, pour que tout se passe au mieux ! N’hésitez pas à faire appel à nous ! Si vous n’êtes pas sur Lyon, je suis sûr que d’autres sauront être disponibles pour vous — et sinon, il y a Internet. ;-)


Un CFP, c’est aussi un jeu de nombres : si parmi les 400 sujets proposés, il y en a 5 à moi3, je diminue d’autant les chances d’une nouvelle personne qui n’en soumettrait qu’un ou deux. Et j’aimerais pouvoir donner un vrai coup de main à quelques personnes, au lieu de passer quinze à trente heures à bosser sur mon éventuelle conférence.

Pour ces deux raisons, je ne proposerai pas de conférence plénière au PHP Tour cette année4. À vous, maintenant, de jouer le jeu et de soumettre des propositions de conférences !

J’espère bien sûr pouvoir y être présent et avoir la chance de vous y rencontrer5 ;-)


Et donc : vous êtes future nouvelle conférencière ou futur nouveau conférencier, lancez-vous !



  1. Le PHP Tour 2017 aura lieu les 18 et 19 mai à Nantes. Plus d’informations sur event.afup.org

  2. Je ne vais vous pas mentir : préparer une conférence, ça prend du temps. Beaucoup de temps, même. J’ai l’habitude de compter entre 15 et 30 heures pour une conférence de 30 à 40 minutes, mais j’ai déjà vu quelques personnes y consacrer le double. 

  3. Je propose généralement plusieurs sujets ; et je suis déjà monté à 4 ou 5, je crois, pour des évènements français. 

  4. Je me lancerai peut-être sur un ou deux sujets de lightning-talk, cela dit — je n’ai encore jamais pratiqué cet exercice, ça doit être sympa également (mais une conférence me semble plus sage pour débuter). 

  5. Il me faudra peut-être discuter un peu plus que si je suis conférencier pour réussir à m’y faire envoyer tous frais payés, mais j’ai bon espoir ^^. 

Les 24h qui suivent la publication d'un article, d'après les logs d'accès nginx

5 janvier 2017 nginx, logs

Il y a quelques mois, j’ai lu l’article what happens to a new URL the first 10 minutes on the internet? de Mattias Geniar. Depuis, je me demandais occasionnellement ce qu’il en était pour les articles que je poste sur ce blog.


Finalement, j’ai fini par me pencher sur les logs des 24 heures qui ont suivi la publication du transcript de ma conférence « Notre environnement de développement n’est plus un bizutage ! » au Forum PHP 2016 Paris, début novembre 2016, pour voir ce que j’arrivais à en tirer d’intéressant.

Je souhaite voir toutes les requêtes, y compris celles effectuées par les bots (qui n’interprêtent pas forcément le code Javascript ou ne chargent pas toujours les images et ne sont donc pas visibles dans des outils comme Google Analytics) et je n’ai pas de système de cache devant mon serveur Web. Le log d’accès de mon nginx contient donc les informations dont j’ai besoin.

Cet article a été mis en ligne à 7h45. Il est immédiatement remonté dans le flux RSS de mon blog, mais je n’ai annoncé sa sortie via un Tweet qu’à 8h57. Pour cet article, je n’ai moi-même posté sur aucun autre réseau social (facebook / reddit / linkedin / autres).


La première heure après publication de l’article, je vois quelques visites de bots et les premières personnes arrivant via le flux RSS :

  • 07:45:04 : je viens tout juste de mettre l’article en ligne. Je suis le premier à le charger, pour vérifier qu’il rend bien.
  • 07:45:46 : moins d’une minute après publication, requête dont le User-Agent est Ruby, sans plus d’information. Un bot, ou un aggrégateur de flux RSS qui télécharge l’article ?
  • 07:46:13 : au tour du bot de Facebook (User-Agent facebookexternalhit/1.1). D’autres suivent, comme Slackbot-LinkExpanding 1.0 à 07:50:19, via le flux RSS.
  • 07:52:02 : 7 minutes après mise en ligne, première requête d’un vrai utilisateur (je ne sais pas d’où il est arrivé).
  • 07:57:59 : je suis en train de préparer un tweet (qui sera posté plus tard par Buffer) et je vérifie donc que le lien renseigné dans Buffer est correct.
  • 08:03:49 : un autre vrai utilisateur : le premier pour lequel je peux déterminer qu’il est arrivé via le flux RSS.
  • 08:04:55 : premier passage de Twitterbot/1.0 rapidement suivi d’autres bots comme MetaURI API/2.0, Applebot/0.1 ou Twingly Recon — je n’ai pas encore tweeté de lien vers l’article, à ce moment là
  • 08:16:03 : premier passage de Googlebot/2.1 — une demi-heure après mise en ligne, c’est presque tard.
  • 08:31:18 : première requête avec journalduhacker.net comme Referer. C’est l’un d’entre vous, peut-être un de ceux arrivés via le flux RSS, qui a posté le lien là-bas, merci !
  • 08:34:24 : on dirait que l’article vient d’être ajouté à Pocket pour la première fois. Je vois une requête avec le User-Agent PocketParser/2.0

À 8h57 (une heure et douze minutes après publication, donc), le tweet programmé un peu plus tôt via Buffer est envoyé !

  • 08:57:44 : première requête arrivée suite à un clic sur le lien présent dans ce tweet (Referer https://t.co/HuefERR5HR). Dans la minute qui a suivi l’envoi du tweet !
  • 09:03:13 : nouveau passage de Twitterbot/1.0, probablement pour voir ce qu’il y a derrière ce lien. Peut-être pour générer la vignette affichée sur la vue web de Twitter ?

La suite de la journée alterne des requêtes de vrais visiteurs et de bots. Je note quelques points intéressants :

  • 11:25:37 : quelqu’un a du poster un autre lien sur twitter récemment, parce que plusieurs visiteurs sont arrivés avec https://t.co/uwIqlfASLk comme referer, sur une plage de quelques minutes.
  • 14:17:02 : requête de Twitterbot/1.0 sur ?utm_content=buffer75bdd&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer suivie d’une série de requêtes avec ces mêmes paramètres ; et ça n’a pas l’air d’être moi qui ai twitté à ce moment là.
  • 16:05:09 : j’ai twitté une seconde fois. Je vois rapidement passer une nouvelle série de robots, ainsi que quelques visiteurs.


En nombre de requêtes, heure par heure, sur les 24h suivant la publication, j’obtiens ceci :

Sur ce graphe, on voit clairement les consultations instantanées après la publication de l’article et sa remontée en flux RSS et sur Twitter. Les choses se tassent très vite ensuite et restent globalement constantes sur la journée.


En listant les Referer les plus classiques, voici les nombres de requêtes dont le Referer contient :

  • HuefERR5HR (mon 1er tweet) : 83 requêtes
  • journalduhacker.net : 32 requêtes
  • uwIqlfASLk (un autre tweet, pas de moi) : 13 requêtes

Au vu des User-agents, j’ai l’impression que :

  • 524 requêtes ont été effectuées par de vrais utilisateurs
  • 100 requêtes ont été lancées par des outils : robots d’indexation, aggrégateurs de flux RSS, …

En parcourant rapidement et manuellement le Referer parfois envoyé lors des visites de vrais utilisateurs, je vois 29 accès depuis un lecteur de flux RSS — que ce soit depuis des solutions cloud comme Feedly ou via des approches auto-hébergées comme Tiny-Tiny-RSS que j’utilise moi-même.

Je vois également :

  • 518 requêtes en HTTP/1
  • 119 requêtes en HTTP/2

Et je note un dernier point intéressant dans le log nginx : j’observe trois tailles en octets, pour la page retournée par le serveur :

  • 13248 octets : 136 requêtes — la page compressée en brotli
  • 15766 octets : 250 requêtes — la page compressée en gzip
  • 58076 octets : 128 requêtes — la page non compressée

Sans trop réfléchir, je suppose que de nombreux bots ne supportent pas la compression (le serveur retourne la page compressée au mieux, selon les algorithmes que le client indique supporter via l’en-tête Accept-Encoding). Je constate qu’environ un tier des pages servies compressées sont en brotli, c’est encourageant !


Et vous, regardez-vous les logs d’accès lorsque vous publiez sur votre blog ? Qu’en tirez-vous d’intéressant ?


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 !