REX Forum PHP 2020
Les jeudi 22 et vendredi 23 octobre derniers s’est tenu le forum PHP 2020 organisé par l’Association Française des Utilisateurs de PHP (AFUP). Une édition particulière cette année, tout d’abord un événement 100% digital et surtout un anniversaire : les 25 ans de la communauté PHP.
Arnaud, Bastien, Yann et Vincent, nos consultants limougeauds et nantais, vous proposent leur retour d’expérience sur 4 conférences les ayant marqués :
- Utopie de la généricité par Frédéric BOUCHERY, coach PHP chez Klaxoon
- Manipulons la donnée par Jonathan VAN BELLE, Lead Software Developer chez Stellar
- La scalabilité d’une équipe par Mickael RANDY, lead developer chez BedRock
- État de l’art d’Elasticsearch avec PHP par Damien Alexandre, développeur web senior chez JoliCode
Frédéric BOUCHERY : Utopie de la généricité
Frederic Bouchery, coach PHP chez Klaxoon, a lancé le cycle des talks non-orientés « techniques purs ». Une conférence très appréciée par nos collaborateurs et notamment Arnaud, consultant au sein de notre agence de Limoges, séduit par la réflexion et la prise de recul de cette présentation :
Sur un fond d’humour référencé et de manière très pédagogique, Frédéric BOUCHERY aborde les sujets qui tendent à toucher l’ensemble des solutions informatiques au fur et à mesure de la vie de ces projets.
Nous, développeurs, produisons du code pour répondre à un besoin en constante évolution. L’objectif étant de correspondre le plus possible à des cas d’utilisation de plus en plus spécifiques et donc de moins en moins simple à standardiser.
Il illustre cette complexité à travers le principe de Pareto aussi appelé principe des 80-20.
Phénomène empirique considérant que 80% des effets sur un produit représente 20% des causes, Frédéric BOUCHERY l’adapte à notre métier et révèle que 20% des efforts mis en œuvre par un développeur ou son équipe résoudra 80% du besoin. Par corollaire, 80% du temps et des efforts seront consacrés à la résolution de problèmes ultra-spécifiques ne représentant que 20% du résultat final.
Cette illustration pertinente nous fait prendre conscience de cet état de fait : « la vie d’un projet consiste principalement à tendre vers un idéal quasiment inatteignable. »
Pourquoi ? Tout simplement parce que le besoin est mouvant et que des éléments environnant le projet, qu’ils soient techniques ou pas, ajoutent leurs lots de difficultés.
Pour Frédéric Bouchery s’impose alors la réflexion que l’on doit se poser en tant que contributeur à ces solutions : « apprenons à être rationnels et évitons de tomber dans des biais intellectuels naturels comme celui des coûts irrécupérables. »
Il faut privilégier l’efficacité et la simplicité du code quoiqu’il en coûte afin de gagner en maintenabilité. Avoir investi des moyens considérables (économiques, techniques, humains) dans des éléments ne doit pas empêcher leur remplacement par des alternatives moins coûteuses et justifier un acharnement technique déraisonnable.
Un concept résumé dans cette conférence en une phrase : « Savoir s’arrêter c’est investir sur l’avenir ! »
Jonathan VAN BELLE : Manipulons la donnée
Jonathan Van Belle, Lead Software Developer chez Stellar, connu également sous le nom de Grummfy, a expliqué lors de sa conférence l’utilisation et la manipulation de colonnes JSON (JavaScript Object Notation) en base de données relationnelles (MySQL, MariaDB, PostgreSQL, etc.). Le Système de Gestion de Base de Données (SGBD) le plus approprié et compatible selon lui restant PostgreSQL.
Pour Jonathan Van Belle, il y a plusieurs avantages à utiliser du JSON en base de données :
- La structure JSON est simple, lisible
- Elle est validable tant dans la structure que dans le contenu
- Sa structure de donnée est indépendante et donc non soumise à variation
- Elle est facilement réparable en cas de problème
Son utilisation prend tout son sens lors de Value Object ou de collections de Value Object.
Il s’agit d’un petit objet qui représente une entité simple dont l’égalité n’est pas basée sur l’identité : c’est-à-dire que deux objets de même valeur sont égaux alors qu’il ne s’agit pas nécessairement du même objet .
Imaginons une table « Personne » contenant des informations d’identité et des tables « Téléphone », « Adresse » toutes deux liées à la table « Personne » contenant respectivement les informations de contact et de localisation de la personne.
Avec l’utilisation de JSON, seule la table « Personne » existe. Cette table est valorisée par deux nouvelles colonnes :
- La colonne « téléphones JSON » comportant la liste des informations de contact de la personne
- La colonne « adresses JSON » comportant les informations de localisation de la personne
Son utilisation permet par exemple de simplifier l’internationalisation d’un site web lorsque peu de langues sont proposées. Nous avons donc des colonnes JSON dont la clé des données est la locale.
{
“fr”:”Bonjour”,
“en”:”Hello”,
“es”:”Buenos dias”
}
De manière générale, tout ce qui a trait à de l’affichage applicatif peut être stocké dans des colonnes JSON sans contre-indication. Cependant, les données faisant office de critères de sélection ont vocation à être stockées dans des colonnes appropriées selon leur type.
Mikael RANDY : Conserver la cohésion technique et fonctionnelle
Mickael RANDY, lead developer chez BedRock, fournisseur français de plateformes de streaming vidéo de pointe pour les diffuseurs et médias en Europe, nous partage son retour d’expérience quant à la capacité à aborder la scalabilité du pôle technique au sein de son entreprise.
Une grande transformation passant de 10 équipes réparties en 3 verticaux techniques à plus de 30 équipes au sein de 5 verticaux techniques. Bouleversement qui entraîne de nouveaux enjeux tels que la conservation de la cohésion technique et fonctionnelle tout en optimisant les flux de développements.
Comment gérer l’évolution d’une équipe de 4 développeurs vers 300 ?
Le témoignage de Mickael RANDY démontrait l’évolution rapide de ces équipes en seulement quelques années et a surtout mis en exergue une nouvelle façon de travailler. Le principe consiste à essayer une forme de management d’équipe vis à vis d’un projet puis de constater les effets positifs ou négatifs de cette pratique.
La communication et la façon de communiquer entre les équipes sont observées. Pour optimiser la communication entre les équipes, des « Tech Lead Meeting » et un « Mercato des devs » ont été mis en place, permettant à chaque développeur de travailler avec une autre équipe et ainsi de réaliser un partage de connaissances tout en s’adaptant à ses différents collaborateurs.
Mars Climate Orbiter : une erreur à 150 millions de dollars
L’exemple scientifique donné par Mickael RANDY illustrait parfaitement la mise en place d’un partage d’information entre les équipes et les conséquences que peuvent avoir une mauvaise communication.
En 1999, la NASA perd la sonde Mars Climate Orbiter à cause d’une erreur d’unité de mesure entre les scientifiques. En effet, certains ingénieurs fournissaient des données en livre (unité de mesure du système anglais) tandis que leurs interlocuteurs les rentraient en newton (unité du système métrique). Conséquence : un changement de trajectoire conduisant à la destruction de la sonde dans l’atmosphère martien. Une erreur ayant coûté 150 millions de dollars à la NASA.
Une manière tout à fait pertinente de démontrer l’importance de la communication entre les équipes que Mickael RANDY clôtura par cette phrase : « Il faut garder un lien humainement gérable entre les équipes. »
Damien ALEXANDRE : État de l'art d'Elasticsearch avec PHP
Enfin, Damien ALEXANDRE, développeur web senior chez JoliCode, agence spécialisée dans la réalisation de projets web et mobiles, a animé la présentation d’Elasticsearch. Une conférence relayée par Vincent, consultant de notre agence de Nantes, qui revient en quelques lignes sur la compréhension de l’outil, son fonctionnement et la manière de l’implémenter dans du PHP :
Elasticsearch est un outil de recherche et d’analyse open source. Il est distribué dans la suite Elastic (Elasticsearch, Logstash, Kibana). Il sert de moteur de recherche et permet d’assurer des suivis de statistiques, du machine learning ou encore des dashboards Kibana.
L’exposition d’Elasticsearch en dehors de l’application est fortement déconseillée. La sécurité étant très faible, il n’est pas recommandé de faire du stockage de session ou de données critiques dessus.
Elasticsearch est un outil utilisant une base de données noSQL (orienté document au format JSON). À l’inverse d’une base de données classique, le noSQL fonctionne avec des index inversés pour pouvoir accéder facilement aux data.
Son architecture permet de visualiser rapidement les documents dans leur ensemble. Cela est rendu possible grâce à plusieurs nœuds qui constituent le cluster. Les shards viennent alors compléter cette construction pour y stocker les data.
L’application n’a aucun accès aux shards ou aux nœuds, cette dernière doit passer uniquement par le cluster via l’API REST au format JSON.
En attendant le dévoilement de PHP 8, sûrement en cette fin d’année 2020, nous tenons à remercier l’AFUP, la communauté PHP, les speakers et toutes les personnes ayant travaillé au maintien de ce forum. Une belle réussite qui a permis à tous les professionnels et amateurs du PHP de se retrouver.
Arnaud, Bastien, Yann et Vincent,
Consultants techniques