Vous le savez peut-être déjà mais malheureusement le Forum PHP 2012 est déjà fini ! En effet, cet évènement absent du calendrier depuis novembre 2010, était très attendu et courtisé par les nombreux développeurs. Ce dernier est qualifié comme le plus grand événement national consacré à la plateforme PHP et aux technologies Web ! Et déjà, le premier constat que je peux faire c’est qu’au vue de la qualité des orateurs et des “geeks” ayant répondu à l’appel, cet adjectif est bien choisi.
En effet, cette année encore le programme a été en ce sens ! Les thématiques principales annoncées étaient : “la performance, la qualité et les nouveaux usages”. Là encore, challenge réussi on a été servi !
Vous croyez que je ne vais qu’encenser l’évènement dans cet article ? Non pas vraiment… Certes comme vous avez pu le lire je reviens très enthousiaste de cette édition, mais mon but de blogueur est aujourd’hui de vous faire, ou refaire pour certains, vivre cet évènement comme si vous y étiez. Déjà, sachez que j’ai rédigé un article assez conséquent, pour être bien dans le thème il représente environ 500 lignes de code HTML, qui regroupe mes différentes notes sur les conférences auxquelles j’ai pu assister, ainsi que les liens vers les différentes présentations de chacun. À noter qu’à l’heure où j’écris ces lignes, toutes n’ont pas encore été publiées et j’éditerais le billet pour les ajouter.
Mais à quoi sert cet article ? Ce dernier va simplement agréger et résumer les conférences pour lesquelles j’ai été réellement attirées. De plus, je vais présenter les à côtés de l’évènement.
Que serait un évènement “national” PHP sans le fondateur du langage ? Certes peut-être que ce dernier aurait le même effet, mais je dois dire qu’écouter Rasmus Lerdorf c’est quand même cool. Celui-ci a vanté les mérites de “son” language, scalabilité, performant, éprouvé, tout en plaçant subtilement une petite phrase humoristique “PHP has 100% market share in the porn industry. And that makes a lot of PHP”. Pour le future, PHP va tenter d’améliorer la gestion de l’Unicode et essentiellement apporter du sang neuf dans l’équipe de développement. Enfin, Rasmus n’a pas oublié de mentionner qu’il est nécessaire de contribuer au langage, (rapport de bug, d’éditer la documentation, et de tester la dernière version afin d’envoyer des rapports d’intégration).
Et puis, comme mot de conclusion il invite toutes les personnes ayant des instances de PHP inférieures à la version 5.3 de mettre à jour celles-ci les avantages sont innombrables.
Par la suite, après avoir assisté à la conférence de Grégoire sur comment tirer parti de Postgresql en PHP avec Pomm, j’ai pu assister à celle intitulée “Anatomie du test” !
Celle-ci, animée par Frédéric et Ivan, allez mettre en exergue un aspect fondamental pour tous les développeurs : les tests. Cette partie souvent mise de côté par les développeurs, et plus généralement par les chefs de projet qui imposent des contraintes de délais bien souvent trop courtes. Malheureusement, il ne faut pas voir les tests comme une contrainte, mais davantage comme une valeur ajoutée à votre projet. En effet, les tests unitaires valident les briques de base d’une application. Si lancer des tests peut sembler quelque peu complexe, l’utilisation d’un framework simplifie emplacement la création de l’exécution des tests, et permet en général la génération des rapports et collecte possiblement des métriques. À ce jour, on peut citer PHPUnit, certainement le plus connu, mais d’autres tels qu’Atoum, pour lequel je reviendrais dans un futur article dédié à ce dernier, Praspel, Jenkins ou encore Behat tirent leur épingle du jeu. Comme le mentionne Frédéric dans la présentation, il est très difficile de conseiller un framework de tests optimal, à part Atoum ! (normal il s’agit de son bébé ;)) En effet, vous allez devoir expérimenter, tester afin de faire votre choix et ainsi trouver celui que vous maitrisez le mieux et pour lequel vous êtes le plus efficace. Cependant, attention votre choix initial s’avère quasi déterminent puisqu’il est difficile de changer de framework de tests unitaires, ces derniers étant souvent incompatibles entre eux.
Mais que faire alors ? Si le test a posteriori est à éviter puisqu’il génère des API souvent inadaptées, l’idée principale est donc de réaliser le test avant de coder ! Ce principe se nomme TDD (Test Driven Development) ! L’idée est tout simple : une barre rouge on peut commencer à écrire du code, une barre verte, on écrit un nouveau test ! Ainsi, on commence par écrire des tests, et l’écriture de ces derniers ne s’arrête que lorsque le résultat désiré est obtenu !
Le résultat dans tout ça ? Vous avez la garantie d’avoir un code de qualité et vous évitez la régression !
Mais comment ça marche ? En binôme, le ping-pong est l’idéal ! Une personne code en premier le test, le second la méthode ! Attention par contre, cette méthode peut être fatigante. Veuillez l’utiliser à bon escient. Le principal avantage, outre le faire d’écrire du code efficace et testé, est que cela permet à tous d’avoir une vision globale du projet et du code source. Le partage du savoir est indispensable dans un projet. Se restreindre à une partie s’avère périlleuse.
Au final mon client gagne quoi ? Il s’agit d’une question épineuse ! En effet, tous vos clients ne vont pas voir de suite le bénéfice et les coûts demandés pour la mise en place d’une telle méthode de travail ! Mais attention, si cette partie n’est pas financée par ces derniers, sachez que le principe du TDD va vous permettre de réduire considérablement les coûts dans le future. Qu’y a-t-il de plus contraignant que de corriger un bug suite à une régression ?
Pour conclure ? Manger du test et imposez-le dans vos équipes de développement. Vous vous ferez certainement pas des amis dans un premier temps, mais ces derniers vous remercieront dans le futur !
Après cette conférence qui place déjà la barre très haute, et au détour d’un petit café et biscuit, on enchaine avec le “monitoring applicatif : Pourquoi et comment ?” animé par Kenny DITS ! Et là, la révélation de ce forum ! Du lourd, très lourd ! En effet, déjà fortement intéressé par la présence d’un membre d’M6 Web, pour qui j’ai pu visualiser différents slides sur les stratégies de l’entreprise, je me retrouve parachuté dans une conférence dont j’ai appris tout quasiment de A à Z (du moins dans la partie “comment”, le reste étant déjà un vécu professionnellement) ! Autrement dit, que du bonheur…
Déjà, la première que l’on se pose, c’est pourquoi monitorer ? Les réponses peuvent être simples et évidentes mais celles-ci sont souvent omises : être alerté en cas de panne, et ce avant que ce soit les utilisateurs qui vous remontent l’information, améliorer le support de la charge, ou encore trouver la ou les RootCause lors d’un incident. De plus, – accessoirement – cela vous permet d’avoir une vue globale de tous les projets, et de donner celle-ci aux développeurs.
Que doit-on monitorer ? La réponse est un mot : tout ! En effet, plus vous allez avoir des métriques, plus vous allez pouvoir agir et analyser. Ainsi, comme exemple de métriques, vous allez retrouver les appels aux services applicatifs, la gestion des utilisateurs, l’utilisation et le temps SQL, la consommation CPU, le temps d’affichage des pages, les erreurs applicatives, ou encore l’utilisation des caches…
Comment monitorer ? Là est la partie la plus complexe de la présentation, mais là encore la réponse se résume à deux termes : Graphite et StatsD ! La première va respectivement s’occuper de toute la partie exploitation des données, la seconde étant la partie cliente et serveur des données. StatsD qui se base sur le protocole UDP, Fire & Forget, va ainsi s’occuper d’envoyer des paquets UDP qui contiennent les données extraites au serveur NodeJS !
A network daemon that runs on the Node.js platform and listens for statistics, like counters and timers, sent over UDP and sends aggregates to one or more pluggable backend services (e.g., Graphite).
Dès lors, Graphite va récupérer ces métriques à la demande. Il va ainsi pouvoir générer des graphiques, tels que le comptage de select en base de données, ou le taux de HITS par rapport aux MISS dans memcached ! C’est un dashboard extrêmement complet. À noter qu’il est possible de faire son propre dashboard, selon les métriques à extraire qui nous intéressent. Vous allez également retrouver un marqueur de mise en production et de fait analyser les potentielles anomalies suite à la mise à jour de votre application.
Au final j’obtiens quoi ? Avec la combinaison de ces deux outils, vous allez avoir la possibilité de sortir des métriques brutes, mais également de cibler très précisément les sites qui ont été mis à jour, et déterminer très exactement d’où vient l’erreur, si erreur il y a. Vous allez ainsi diminuer considérablement le nombre d’anomalies applications.
C’est le temps de la pause déjeuner ! Bien rangé en pile FIFO, nous récupérons sagement notre repas ! Avalé en deux temps trois mouvements, et après avoir rechargé également les batteries du Mac il est temps de faire un petit tour dehors ! Pourquoi je vous mentionne ceci ? Tout simplement pour vous dire que le cadre était vraiment extra ! On a pas enfermé des “geeks” dans une cave, où encore dans un hangar, mais bien dans un superbe château avec un grand parc à la Cité Universitaire Internationale !
14h, c’est l’heure de reprendre ! Julien en profite pour nous parler de l’anatomie, le fonctionnement et les performances de PHP. S’il est nécessaire de retenir une phrase c’est celle-ci : “PHP n’est pas responsable de la lenteur, seulement si l’on code mal !”. Je vous recommande de lire mes notes pour en apprendre davantage, celles-ci étant assez exhaustive. De plus, Julien a déjà mis les slides en ligne alors autant en profiter.
Ensuite, j’assiste à la session de Jean-Marc qui nous parle de la gestion des dépendances dans un projet PHP. On y découvre, pour la première fois mais pas la dernière sur ce forum, Composer. C’est incontestablement l’attraction de ce forum ! S’il s’agit d’un projet récent, celui-ci se veut très actif aujourd’hui. Il dispose de trois principaux outils : un gestionnaire de paquets en ligne de commande (comme pear, apt-get, …), Packagist qui contient les librairies (les majeures se retrouvent intégrées à ce dernier – adoption croissante, sources variées : Git, SVN, Mercurial, …) et enfin Satis qui offre une distribution aisée de vos propres paquets. Si à l’heure actuelle il est possible de se brancher sur la version de développement ainsi que la version alpha 3, une version stable est en vue !
Au final, l’utilisation de Composer va, côté client, permettre de récupérer très simplement un projet, et du côté du distributeur, d’utiliser simplement le composer.json, où plutôt de coder votre propre fichier de déploiement. De plus, veuillez noter que vous avez la possibilité de créer votre fichier à partir d’un modèle.
L’avant dernière conférence de la journée est animée par Antonio Fontes, et concerne la modélisation des menaces d’une application web avec une étude de cas. Plutôt qu’un long discours, je ne peux que vous recommander de lire les slides de sa conférence, vous avez tout ! Puis, on finit par les fonctions avancés du driver MySQL natif pour PHP. Dans celle-ci on y découvre mysqlnd, le driver MySQL natif dans le cœur de PHP 5.4 ! À noter que ce driver est déjà existant dans la version de PHP 5.3, cependant vous devrez recompiler PHP pour l’activer et l’exécuter.
Côté fonctionnalité, vous allez retrouver des améliorations de la connexion persistante, le support du SSL, la possibilité d’utiliser mysqli_fetch_all() pour récupérer un ensemble de résultat et une gestion asynchrone mysqli_poll. Enfin, dernier élément à noter, c’est que le driver est extensible grâce à des extensions. Le seul hic, c’est qu’actuellement il est seulement possible d’en concevoir en C…
Ainsi s’achève cette première journée riche en découverte ! Autant vous dire que j’avais réellement envie d’être à la seconde de suite… J’y reviendrais certainement demain dans un prochain article…
Si vous avez des questions, des interrogations sur les conférences et plus particulièrement les résumés que je viens de faire, n’hésitez pas à poser vos questions à la suite de cet article je tenterais d’y répondre, et dans le pire des cas je demanderais à l’orateur d’intervenir.
