Mes notes du Forum PHP 2016, jour 2

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 Hardy – Ré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 Dunglas – Ré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 Bouchery – Ré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 Napoli – Ré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 NEGRIER – Ré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 Leune – Ré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 ;-)