Introduction

Cette deuxième journée a été je trouve un peu plus mitigée au niveau de l’intérêt des sujets traités, sûrement parce que certains avaient déjà été traités pendant la première journée.

Malgré tout, j’ai assisté à quelques conférences intéressantes et je vais vous faire un retour là-dessus.

Catching opportunities with Open Source, par Stefan Koopmanschap et Christian Schaefer

La but de cette conférence était de faire l’apologie de l’open-source, pour une personne seule ou pour une entreprise entière. A mon avis, une partie voire la totalité du public était déjà convaincue...

En gros, l’open-source n’a que des avantages. Cela peut être un CV en soit : les recruteurs peuvent savoir ce que vous faites et juger de vos compétences, ils vous connaissent déjà avant de vous avoir rencontré ! Plus vous participez et plus vous aurez de chance d’intéresser. Surtout si la qualité est au rendez-vous.

Même d’un point de vue personnelle, vous aurez des opportunités de vous améliorer en partageant votre code puisque vous pourrez avoir des retours immédiats. Des retours au sujet de la sécurité, comme des "pull requests" (cf. github) pour de nouvelles fonctionnalités ou autre. Participer à l’open-source peut même vous apporter la gloire !

C’est également vrai en tant que personne morale (une entreprise) : Sensio est partie d’une simple agence pour arriver à un leader mondial en se basant une technologie open-source. Il n’y a d’ailleurs pas que les éditeurs qui peuvent contribuer, un site de contenu (de presse ou autre média) pourra très facilement contribuer puisque le business model reste basé sur le contenu : l’important n’est pas le code qui n’est qu’un outil.

Les nombreux avantages de l’open-source sont ainsi visibles et on peut encore en trouver d’autres comme le fait de pouvoir se baser sur l’expérience des autres et ne pas réinventer la roue à chaque nouveau projet, ou encore le fait de pouvoir constamment apprendre de nouvelles choses.

Bref, l’open-source, c’est la vie !

Maitrisez les structures de données 102, par Patrick Allaert

Ne cherchez pas ce qu’est une structure de données 102, le numéro est juste la notation américaine des cours d’université : 102 équivaut à un cours avancé (contre 101 pour une introduction).

Bref, la présentation s’est concentrée sur ce que sait faire PHP nativement comme types de données, notamment les Arrays. Le postulat de base, c’est qu’ils sont mauvais car en interne, ce ne sont pas des tableaux mais des listes chaînées associées à une "hash table".

Du coup, quand il faut manipuler les tableaux d’une manière spécifique, il existe sûrement des alternatives moins gourmandes en mémoire.

Par exemple :

• pour une "struct" : une Class en PHP 5.4 consommera moins
• pour créer un tableau de taille fixe (connue à l’avance) : utiliser SplFixedArray
• pour créer une file (FIFO) : SplQueue
• pour créer une pile (LIFO) : SplStack
• pour créer un ensemble (des valeurs groupées non ordonnées) : utiliser les clés des Arrays (les valeurs étant true ou 1 ou autre non null) ou bien des defines si l’ensemble est connu d’avance ou encore SplObjectStorage pour un ensemble d’objets.

Pour le dernier point, il existe également un concept qui s’appelle les filtres de Bloom, implémenté dans le package PECL bloomy et qui permet de gérer des ensembles avec un gros volume de données d’une manière probabiliste. En gros, quand vous demandez si un élément appartient à l’ensemble et que le filtre vous répond "oui", alors c’est que c’est probablement vrai. Par contre s’il vous répond "non", c’est sûr qu’il n’y est pas.

La qualité au-delà du code, par Jean-Marc Fontaine

En terme de statistique de début, cette présentation commence fort : 70% du temps d’un développeur est passé à faire de la maintenance et pas de l’écriture de nouveau code. Ce qui veut dire qu’il y a de l’intérêt à créer du code de qualité qui soit lisible et maintenable. Surtout que plus le code sera pourri, plus le temps passé à faire de la maintenance va rester à ces 70% voire augmenter !

Du coup, il y a quelques critères de qualité à avoir en tête et respecter lors du développement d’un projet :

• la compréhensibilité
• la cohérence
• l’exhaustivité
• la concision
• la portabilité
• la testabilité
• la fiabilité
• la maintenabilité

Concrètement, les commentaires doivent être là pour compléter le code et non pas perdre le relecteur dans des explications brumeuses ou redondantes avec du code évident. Le code ne doit donc pas être trop complexe non plus (cf. la complexité cyclomatique).

Toujours au niveau du code, il devrait être homogène au niveau de sa mise en forme (indentation, position des accolades, ...), tout comme le nommage des variables, des fonctions, des fichiers et des dossiers du projet. Tout cela doit être logique, cohérent et pertinent.

En plus, il ne faut jamais commiter du code commenté ! Le relecteur s’arrachera les cheveux à savoir pourquoi c’est là (je sais que c’est arrivé à tout le monde ça).

En dehors du code, la documentation qui va avec devra être exhaustive mais sans être trop verbeuse. C’est un compromis pour qu’elle soit utile, maintenue et surtout lue !

Il faudra bien sûr faire attention aux codes inutiles : les bouchons, les librairies inutilisées ou même le code mort (qui n’est jamais exécuté). Pour ce dernier, il existe l’outil PHP DCD qui permet de le détecter.

Dans le même esprit, le code dupliqué pourra être factorisé et détecté grâce à PHP CPD (qui est assez gourmand, attention).

En ce qui concerne la configuration de l’application, il faudra la prévoir afin qu’elle puisse s’adapter à tous les environnements : le dev mais aussi la recette, la pré-prod, la prod etc. Une idée de bonne pratique : que l’exploitation (l’équipe s’occupant des machines physiques) mette à disposition un fichier de configuration regroupant les IPs des machines, les accès etc. sur les serveurs, que les applications pourront ensuite lire sur chaque environnement.

Concernant les tests, il en existe plusieurs types avec chacun des outils permettant d’aider à l’automatisation :

• unitaires grâce à PHPUnit ou Atoum
• fonctionnels avec Cucumber ou Behat
• de charge : JMeter, Siege ou encore http_load

Le principal sur cette partie est de bien définir les critères d’acceptation à l’avance, de les faire valider par le client final afin d’avoir des valeurs concrètes et réalistes.

Enfin, l’application devra être la plus tolérante aux erreurs possibles (par exemple en ayant le moins de dépendances possibles à des services externes comme Facebook ou les régies publicitaires), voire même devra pouvoir être placée en mode "dégradé" par rapport au coeur de métier grâce à du feature flipping (qui n’a rien à voir avec flipper le dauphin), et puis son installation ou sa mise à jour devra être simple (ce qui est facilité par de l’intégration continue) et elle devra également proposer des logs pertinents pour aider à la compréhension des problèmes.

Automatiser la qualité, par Damien Séguy

Cette présentation était intéressante pour son nouvel angle d’appréhension : Damien travaille exclusivement en Chine avec des développeurs Chinois. C’est donc une autre culture, qui ne connaît que très peu la qualité et il y a donc tout à apprendre et mettre en place.

La conférence a donc balayer pas mal de sujets déjà abordés auparavant dans les autres conférences, comme l’utilisation d’outils tels que PHPCS ou PHP Loc (qui compte le nombre de lignes de code) etc.

Globalement, les quelques astuces que j’ai retenues sont le fait de récupérer régulièrement l’activité du système de gestion de version (SVN ou git) pour le mettre sous forme de graphe et suivre l’avancement des projets grâce à ces indicateurs.

Autre asture : utiliser PhantomJS pour prendre des screenshots de l’application régulièrement et coupler avec un outil de "perceptual diff" pour comparer les versions et vérifier les modifications.

Enfin, le principe de test fuzzing qui automatise les tests de formulaires avec des valeurs aléatoires ou qui vérifient les failles courantes.

Scaling Communication through Continuous Integration, par LB Denker

Une conférence sur comment cela se passe au niveau de l’organisation des développements chez Etsy.

En gros, ils utilisent des méthodes de déploiement continu, d’intégration continue et de confiance.

Le déploiement continu consiste à laisser libre les développeurs de pusher du code même en production à tout moment : en 20 minutes ou moins, on peut déployer du code en production.

L’intégration continue permet quant à elle de pouvoir tester automatiquement quand on le souhaite tout ou partie du code.

Les grands principes sont les suivants :

• Always be pushing
• Don’t push in Red : sachez ce qui est couvert par les tests, soyez sûr de pouvoir détecter les erreurs et de savoir qui peut les corriger
• Write Clean Tests
• Too much to read : il faut simplifier les interfaces de visualisation comme celle de Jenkins par exemple
• Write Clean Code
  • c’est le principe le plus compliqué à réaliser
  • utiliser PHP Lint (php -l) au pre-commit
  • utiliser PHP CS (mais limiter aux fichiers qui ont changés récemment)
  • envoyer des mails de "blame" lors de commits foireux
  • organiser des compétitions de correction de bugs
• Trust La clé, c’est le dernier point : il faut faire confiance aux autres et être sûr qu’ils vont faire les choses bien.

Accès concurrents et scalabilité, par Jérôme Vieilledent

Ici, la particularité de la présentation est qu’elle est orientée vers le CMS eZPublish. Le but était de voir comment on pouvait rendre une application PHP réactive et scalable tout en restant dynamique (avec du contenu frais).

Tout le monde le sait, PHP est synchrone, avec des processus isolés, sauf que les utilisateurs et les contributeurs ne le sont pas, eux...

Du coup, la génération de cache à la première requête sur un site à fort trafic est en fait une génération de cache sur plusieurs requêtes concurrentes. Cela peut donner lieu à plusieurs problèmes comme des deadlocks (un chargement infini d’une page), des écritures concurrentes donc un cache corrompu etc.

Les solutions possibles sont alors :

• la pré-génération du cache (se pose la question de ce que l’on sert pendant la génération)
• l’utilisation d’un CDN (qui coûte horriblement cher)
• la mise en place de Varnish (ce qui rend le site plus statique)

La solution préconisée sera alors le "Stale Cache" : un cache expiré qui ne sera pas supprimé mais pourra être utilisé pendant la génération du nouveau : il suffit de flaguer la génération en cours pour pouvoir faire le test de cette génération et ainsi prendre l’ancien cache.

En ce qui concerne la scalabilité, on a souvent une architecture horizontale où on aligne les serveurs (physiques ou virtuels) sur lesquels on duplique les sources. Le problème réside dans le fait que chacun de ces serveurs devra pouvoir servir le cache (et le même) ainsi que les fichiers statiques (toujours les mêmes) : il faut donc synchroniser !

Les solutions potentielles :

• un montage NFS (Network File System) : ça n’apprécie que très moyennement PHP
• SAN (Storage Area Network) : ça coûte cher
• Rsync, qui est lent et avec lequel on n’aura pas de contrôle applicatif
• DRDB (Distributed Replicated Block Devices) : plus rapide que Rsync mais les mêmes inconvénients au global
• La solution ici préconisée sera de mettre en place un Cluster PHP.

La forme pourra être une librairie qui se subsistera aux fonctions natives, ou tout simplement un stream wrapper (http://fr.php.net/stream_wrapper).

Je retiens de cette présentation également une petite chose : le header "X-SENDFILE" supporté par quelques serveurs HTTP afin de créer des serveurs de ressources statiques où PHP n’aurait qu’à indiquer l’emplacement du fichier et où ce serait le serveur HTTP qui se chargerait de le faire télécharger au client : plus besoin de le lire et d’envoyer toutes les données depuis PHP.

Table ronde des DSI

La journée s’est terminée pour moi par une table ronde où étaient présents plusieurs membres d’importantes DSI du web français :

• e-TF1
• M6Web
• Le Monde Interactif
• L’Express
• LaFourchette
• La mairie de Lille

Il a été question de PHP évidemment, de savoir comment cette technologie était arrivée au sein de ces sociétés, comment elle évoluait au travers des développements et des contraintes des DSI respectives et puis de l’avenir biens sûr.

Ce qui revient souvent, c’est que PHP a été choisi pour sa facilité et rapidité au développement, parce que les développeurs PHP n’étaient pas difficiles à trouver sur le marché du travail, mais que les besoins des DSI avaient évolués et que désormais, elles essaient toutes d’industrialiser leurs méthodes, d’utiliser une batterie d’outils ou de frameworks (Symfony 2 est utilisé par 4 membres sur 6) et que du coup les critères de recrutement se sont un peu étoffés au fil du temps : les développeurs PHP ne sont plus si faciles à trouver...

Au niveau de la communauté Open-Source, certaines sociétés s’engagent à dévoiler du code (LaFourchette) dans un avenir plus ou moins proche, d’autres estiment participer au travers de retours d’expérience comme au forum PHP (leMonde ou M6Web) et d’autres encore incitent leurs développeurs à contribuer en leur nom à des projets (e-TF1).

Globalement, toutes les DSI ont confiance en l’avenir de PHP, même si quelques unes s’intéressent de près à ce que fait node.js et estiment que cette technologie est en passe de faire de l’ombre à PHP dans les futures années.

Conclusion

Ce forum PHP a pour moi été riche en partage et j’ai beaucoup apprécié y assister. J’espère que vous avez autant apprécié lire mes retours sur les conférences, j’espère qu’ils ont été assez explicites et que je n’ai pas été trop confus.

Bien sûr, si vous avez des questions, des suggestions, des corrections à me proposer ou autre, n’hésitez pas à m’envoyer quelque chose comme un tweet (@lpointet), un mail, des lauriers sur l’intranet ou un simple Werther’s Original...

N’hésitez pas également à tester les outils ou technologies dont j’ai parlé ici, ce sont de bonnes pistes !