Mes notes du ForumPHP 2014, jour 1

Le ForumPHP organisé par l’AFUP a cette année eu lieu les 23 et 24 octobre, au Beffroi de Montrouge à Paris.

Comme pour le PHPTour qui avait eu lieu en juin à Lyon, ces deux jours ont été l’occasion de revoir plein de monde (cela faisait trois ans que je ne m’étais pas rendu à un événement AFUP à Paris !), ainsi que de rencontrer plusieurs personnes avec qui j’échangeais déjà depuis un certain via Internet sans jamais les avoir vues IRL, ou d’assister à une quinzaine de conférences.

Je n’ai cette fois pas été retenu pour présenter de conférence basée sur le travail que j’effectue chez TEA, The Ebook Alternative, mais j’ai eu la chance de pouvoir animer une table ronde intitulée « État des lieux et avenir de PHP », à la fin du second jour de ce Forum.

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.

Les slides de la quasi-totalité des conférences sont disponibles en ligne (sur joind.in ou ce gist) et les vidéos captées lors de l’événement vont peu à peu être diffusées par l’AFUP sur youtube.

La mesure, ce n’est pas que pour le devops.

Olivier Garcia et Patrick Allaert – Résumé, Slides

En introduction de cette première conférence, Olivier et Patrick, qui sont en train de monter catchy.io, ont demandé qui dans la salle avait un projet de création d’entreprise : sur la vingtaine de réponses positives, il est probable qu’au moins la moitié se planteront. Avoir des métriques peut aider à piloter les directions prises.

Lean startup n’est pas une garantie que les choses vont marcher. Il faut savoir écouter les feedbacks :

• certains sont à ignorer (Uber a ignoré ceux qui disaient que ça ne marcherait pas),
• il faut se demander pourquoi les gens demandent un truc
• et il est important de regarder les chiffres, d’analyser ce que font les utilisateur – et d’adapter en conséquence !

Lean Startup suit 4 principes : production par étapes “juste à temps”, offre adaptée à la demande, focalisation sur la production de valeur et amélioration continue. C’est assez proche de scrum, en ajoutant un côté commercial. Itération : hypothèses basées sur des données (A/B testing, par exemple) → expériences → amélioration ↻.

Pour ce qui est des mesures, les métriques doivent être “AAA” : Actionables (on peut en faire quelque chose), Auditables (la méthode doit être compréhensible et obtenir des chiffres doit être facile) et Accessibles (tous les développeurs y ont accès). Elles sont à l’opposé des métriques de vanité. Exemples : nombre de lignes de code vs ratio de code mort, nombre de followers sur twitter vs interactions avec ces followers, nombre de visiteurs vs nombre de visiteurs qui s’inscrivent, nombre d’utilisateurs vs nombre d’utilisateurs actifs au bout de six mois, …

Les métriques mesures “AARRR” : Aquisition (comment est-ce que les utilisateurs viennent), Activation (est-ce qu’ils s’enregistrent), Rétention (est-ce qu’ils reviennent / sont actifs), Referral (font-ils venir d’autres utilisateurs ? qui s’enregistrent ?) et Revenu (impact sur le CA).

Quelques outils de récolte de métriques :

• Google Analytics, le plus connu : facile à mettre en place, dashboards standards. Il faut surveiller les événements, plus précis que les pages et valables pour les applications Ajax. Dashboards personnalisables (embed API) + extraction de tableaux via GA Query Explorer.
• Statsd / Graphite, le plus en vogue en ce moment
• Autres, souvent payant : Mixpanel, Pirate metrics, KISSmetrics, …

En résumé : le succès dépend d’un feedback mesurable. Lean startup et AARRR sont des pistes pour s’appuyer sur des métriques fiables.

Mon avis : Une bonne introduction aux métriques à mettre en place sur une application qui se lance (ou qui devraient être en place sur une application déjà lancée), en vue de guider son évolution. Vu qu’Olivier et Patrick sont en train de lancer leur boite, j’aimerais vraiment avoir un retour d’expérience, d’ici deux ou trois ans, sur quelles métriques ils ont mis en place, lesquelles leur ont apporté des informations utiles (et quelles étaient ces informations), ainsi que celles qui n’ont pas été utiles ou trop difficiles à interpréter.

Industrialisation des environnements de dev avec Puppet et Amazon

Nicolas SILBERMAN et Sébastien ANGELE – Résumé, Slides, Vidéo

Avec des changements de technos et la mise en place d’une nouvelle stack complexe (chez l’Express : 6 applications PHP, 15 bases de données MySQL ou Mongo, Redit, RabbitMQ et des applications découplées), il n’est pas facile d’installer celle-ci sur un environnement de démonstration ou de développement. Cela mène à des commentaires du type “chez moi ça marche”, “je ne regarde jamais cette partie du site”, “tu voulais tester ça aussi ?” ou “ça marche en prod”, qui ne sont pas rassurants !

Installer uniquement une partie de la stack / de l’infra ne fonctionne pas, principalement car il y a trop de dépendances entre les composants. Effectuer une installation manuelle identique à la plate-forme de production ne fonctionne pas non plus : cela entraîne des oublis et l’obtention de plate-formes ne fonctionnant qu’à moitié.

Pré-requis pour passer à une mise en place de plate-forme automatisée : versionner le code, avoir de l’expérience en déploiement continu et des compétences devops – en se rappellant que DevOps == “Travailler ensemble pour produire de la valeur pour l’entreprise”.

Mise en place d’une infra on-demand chez AWS (plus de liberté d’expérimenter, permet de lancer des instances de démo au besoin et de les couper quand elles ne sont plus utiles). Quelques pièges : grand nombre d’offre (besoin de conseil), le prix est variable selon les jours (puisque dépend des instances lancées) complexifie la maîtrise des budgets, veiller à ne pas laisser tourner de machine qui ne fasse rien !

Pour la gestion de configuration : historiquement bash et cfengine, puis bascule vers Puppet (car expérience sur des projets plus petits, pour des environnements de développement et volonté de lancer rapidement le projet). Utilisation de Foreman pour piloter, dès le départ (attention : fichiers de configuration non compatibles avec Puppet). Mais arbre de dépendances profond et complexe ⇒ difficile de trouver l’origine des problèmes.

Finalement, passage à Chef : bien documenté chez AWS, hébergeur utilise Chef en production et recettes plus simples à écrire. Jouer les recettes sur des AMI de base était long, donc utilisation de packer.io pour construire des AMI personnalisées incluant les logiciels les plus utilisés (nginx, mysql, …) ⇒ plus rapide pour mettre en place une instance. Utilisation de kitchen pour tests unitaires et fonctionnels sur les recettes (“infrastructure as code”).

Pour ce qui est des données :

• Remontée des DB depuis la production, tous les jours ; plus de 30h au total pour tout remonter, ce qui est un peu long ⇒ travail d’arbitrage sur la fraîcheur des données, ainsi qu’optimisations sur la structure (découpage en bases plus petites, en séparant les données qui ne sont que rarement modifiées).
• Pour les fichiers (400GB d’images), warmup avec un HDD, puis rsync régulier depuis la production.

Quelques outils développés en interne : tableau de bord des instances, formulaire qui lance des instances et déploie les logiciels dessus ⇒ quelques clics, pas de manipulation à la main sur les interfaces d’AWS. Utilisation des API AWS, faciles à intégrer à symfony2.

Bilan final : investissement lourd au départ, en mode projet dédié. Reste à généraliser le principe au lancement d’environnements de développement (peut-être ?). Difficultés pour les prévisions budgétaires.

Mon avis : Ayant pas mal bossé sur la mise en place d’environnement de devs (Cf « Notre environnement de développement n’est plus un bizutage ! » au PHPTour en juin) et n’étant pas encore allé jusqu’au provisionnement d’instances de démo/recette à la demande, je suis reparti de cette conférence avec quelques idées : ce que nous avons aujourd’hui sur nos postes de développement pourrait sans trop de mal être étendu pour démo/recette.

PHP dans les distributions RPM

Remi COLLET – Résumé, Slides

Remi a commencé par rappeler qu’il maintient un dépôt de RPM (CentOS/RHEL/Fedora) depuis 2005, qu’il est packageur PHP pour fedora, qu’il fait pas mal de QA sur des extensions PECL et qu’il est contributeur à PHP depuis 2012.

Les distributions entreprise ont souvent une image de trucs complétements obsolètes ; ce qui correspond, cela dit, à leur objectif de stabilité (y compris au niveau des APIs et ABIs), avec un support supérieur à 10 ans (qui répond aux attentes de certaines entreprises – même si pas forcément à celles des développeurs). C’est encore plus vrai maintenant, où un serveur virtuel peut avoir une durée de vie illimitée, alors qu’un serveur physique ne durait généralement qu’environ cinq ans.

Quelques versions de RHEL, les dates de support et les versions de PHP correspondantes :

• RHEL 4, support → 2012 : PHP 4.3
• RHEL 5, support → 2017 : PHP 5.1.6
• RHEL 6, support → 2020 : PHP 5.3.3
• RHEL 7, support → 2024 : PHP 5.4.16

Note importante : les correctifs de sécurité sont backportés ! Cela signifie que le PHP 5.3.3 de Redhat n’est pas le 5.3.3 officiel : il intègre 150 à 200 correctifs supplémentaires. Tous les CVE sont fixés, y compris ceux qui ont été fixés en 5.5 ou 5.6 par php.net.

Fedora, à l’inverse de RHEL, essaye plutôt d’utiliser les dernières versions, avec un cycle de vie court (1 an). L’approche est de travailler avec les projets upstream et de remonter des patchs. En complément, Fedora est la distribution upstream de RHEL.

Dans les cas où la version de PHP fournie est trop vieille pour des applications modernes (sur RHEL notamment) ou trop récente pour certaines applications (sur Fedora notamment), on peut se rabattre sur : mise à jour / build à la main / repositories tiers (pas idéal pour une distribution avec du support !) / docker / SCL.

Les Software Collections (ou SCL) permettent d’installer en parallèle plusieurs versions d’un logiciel, sans toucher au système de base (l’installation est effectuée à côté, typiquement dans /opt/<vendor>/<sclname>/), avec mise en place d’un lanceur pour activer la collection. Avec les SCL, RHEL 6 dispose de PHP 5.3 et 5.4 et 5.5, avec des paquets officiels ! Les SCL sont pour l’instant disponibles sur RHEL et devraient arriver sur Fedora dans le futur.

Pour ce qui est de la collaboration avec les projets upstream et downstream : les distributions et les utilisateurs veulent des trucs stables, de la documentation, de la vision sur la roadmap des projets. Les distributions font de la QA et de la CI, qui aident les projets qui en bénéficient.

Chez Red Hat, à chaque modification de PHP ou d’une de ses dépendances liées (extensions PECL, logiciels écrits en PHP, bibliothèques PEAR ou Composer, …), un build complet est lancé. Ce build implique une compilation de PHP, un lancement des tests de tous les paquets liés (dont Zend Framework, Doctrine, PHPUnit, Symfony, …). Cela facilite énormément la détection de régressions et de changements de comportement à chaque nouvelle version de PHP, y compris pour les Release Candidate ! En cas problème, la distribution effectue un bug-report auprès du projet concerné (y compris php.net, donc).

En conclusion : les distributions RPM sont un bon choix pour des développeurs PHP, que ce soit par le biais des SCL qui permettent de disposer de plusieurs versions (officiellement supportées) en parallèle, ou par le support qui est fait aux projets upstream.

Mon avis : J’ai souvent grogné sur les distribs entreprise qui distribuaient de vieilles versions de PHP (Hello RHEL 5 et ton PHP 5.1.6). Je suis donc fort content de voir que les choses évoluent, et dans le bon sens, à ce niveau là ! J’ai aussi appris que les vieilles versions fournies par ces distributions recevaient tout de même des correctifs de sécurité, même si elles ne sont plus maintenues par php.net (et c’est une bonne chose !). Et, finalement, le boulot fait sur l’intégration continue et le lancement de tests au niveau de PHP et de projets dépendants est vraiment super pour la qualité et la stabilité de PHP !

Laisse pas trainer ton log !

Olivier DOLBEAU – Résumé, Slides, Vidéo

Les fichiers de log permettent de garder trace de ce qu’il se passe, que ce soit dans le syslog, les access_log, les logs applicatifs, … Fréquemment, pour consulter un log, on se connecte en SSH au serveur concerné et joue avec tail ou cat et grep ou sed, avec des expressions plus ou moins rationnelles spécifiques à chaque fichier.

Stack ELK (supportée par l’entreprise ElasticSearch) :

• ElasticSearch
• Logstash : input + filter + output
• Kibana : visualisation des logs via une jolie interface qui permet de réaliser des dashboards donnant une vue d’ensemble sur la plate-forme.

Pour ce qui est de syslog : utilisation de rsyslog pour tout envoyer dans logstash. Côté logstash, configurer l’import pour récupérer les logs, utiliser le filtre grok (fonctionnement par expressions rationnelles) et configurer la sortie pour un envoi vers ElasticSearch.

Pour les logs applicatifs : Monolog supporte de nombreux handlers, y compris pour envoyer vers ELK. Penser qu’on peut utiliser des processors pour enrichir les logs au passage, en particulier avec PSR-3 où chaque méthode de log reçoit un contexte en paramètre.

Chez BlaBlaCar, les logs sont utilisés pour comprendre ce qui a pu causer des erreurs. Ils stockent donc de nombreuses informations et ont un lag d’au maximum deux minutes par rapport à la production (pour permettre de comprendre les éventuels problèmes liés à une mise à jour). L’infra mise en place est assez grosse (1 serveur pour récupérer les logs, 2 redis, 3 logstash qui filtrent depuis redis et 5 elasticsearch pour le stockage), avec des machines qui ne sont pas trop chargées mais de gros besoins de stockage (20 à 25GB de logs applicatifs par jour + 10GB de syslog, conservés au maximum 30 jours puisque le but est de détecter / analyser les problèmes en temps réel).

Dans l’équipe, tout le monde regarde régulièrement les dashboards, pour voir s’il ne se passe pas quelque chose de spécial. Pas de mécanisme d’alerte automatique branchée dessus (aujourd’hui). C’est principalement utilisé par les équipes techniques, mais les équipent marketing disposent d’une stack du même type pour les données qui les intéressent plus (sur les paiements, par exemple) – tout en sachant qu’ELK n’est pas l’outil le plus adapté pour ce type de reporting.

Mon avis : Ayant beaucoup de logs (systèmes et applicatifs) en vrac sur une demi-douzaine de serveurs, sans réelle autre solution aujourd’hui que ssh + tail / cat + grep / sed, je suis ressorti de cette présentation en me disant que ELK serait probablement la première idée vue à ce ForumPHP sur laquelle on allait se pencher (et on a déjà commencé, depuis !). Sans forcément partir dès le début sur un système aussi complet que celui qu’Olivier nous a montré, mais au moins pour avoir les quelques briques de base, voir ce qu’on en tire, pour nous aider à mieux cadrer notre besoin et ensuite améliorer la stack.

Composer Best Practices

Jordi BOGGIANO – Résumé, Slides, Vidéo

Jordi, Lead Developper de Composer, a commencé sa présentation par un rappel sur ce qu’est le Semantic Versionning (semver.org), Avec ses trois numéros de versions : majeure (pour ce qui casse la compatibilité), mineure (pour les ajouts de fonctionnalités) et patch (pour les correctifs).

Il a ensuite parlé des contraintes de versions comprises par Composer :

• Exact match : 1.0.0, 1.2.3-beta2, dev-master
• Range : 1.0.*, 2.*
• Unbounded range : >=1.0. Attention : si la 2.0 (nouvelle version majeure ⇒ cassure de compatibilité) sort, on va y passer !
• Possibilité d’utiliser des opérateurs : , pour ET et | pour OU.
• Next significant release :
  • ~1.2 : le chiffre de la version mineure peut augmenter, mais pas celui de la version majeure. Équivaut ici à >=1.2.0,<2.0.0
  • ~1.2.3 : le chiffre de la version patch peut augmenter, mais pas ceux de la version majeure et mineure. Équivaut ici à >=1.2.3,<1.3.0
  • C’est ce qui devrait systématiquement être utilisé par les bibliothèques – et par nous autres développeurs !

Pour l’installation de nouveaux paquets, composer require utilise par défaut ~ et crée un require qui matche la version courante. En termes de stabilité, Composer respecte la chaîne usuelle dev → alpha → beta → RC → stable. Attention aux requirements trop stricts, qui peuvent rendre impossible la résolution de conflits entre plusieurs bibliothèques dépendant toutes du même paquet en des versions différentes.

Pour les tags, 2.0.2 correspond à une version stable alors que 2.0.2-betaX correspondra à une bêta. Pour les branches, utiliser le suffixe -dev, puisque la branche change et n’est pas stable (à l’inverse d’un tag qui ne bouge pas).

Quelques autres points :

• Le fichier composer.lock ne doit pas être mis en .gitignore : il permet une installation plus rapide et nécessitant moins de mémoire, ainsi que des installations reproductibles.
• La section scripts dans composer.json permet de mettre en place des commandes utilisables par composer nom-commande.
• Pour ceux qui auraient besoin d’utiliser un projet forké : la section repositories dans composer.json est plus prioritaire que les autres repositories. Nos branches de travail sont disponibles et il est possible d’utiliser la syntaxe d’alias ma-branche as 2.5.0 pour injecter notre fork et notre branche en faisant croire qu’il s’agit d’une version donnée (ça peut permettre de faire des trucs horribles, attention à ne pas en abuser !).

La présentation s’est terminée avec un mot à propos de Toran Proxy, qui joue un rôle de proxy qui améliore les performances et la résilience (on peut déployer même si github ou packagist sont indisponibles) en réalisant un miroir de git et de fichiers zip et en permettant de l’hébergement privé de paquets (avec configuration en interface web). La licence payante permet aussi de financer composer et packagist (en particulier, le temps que Jordi passe à bosser dessus – et donc pas à gagner de quoi manger par le biais de son activité professionnelle ; le temps passé représente beaucoup plus que le coût du serveur).

Mon avis : J’ai beau utiliser composer régulièrement, c’est pendant cette présentation que j’ai enfin compris le sens de ~ ^^. Pas mal de rappels utiles, quelques moments de “oh c’est pratique” (notamment sur l’utilisation de repositories pour les repos forkés et de as pour aliaser des branches / versions). Le fait que Jordi ait fait cette conférence en français (qu’il n’utilise que rarement pour des discussions techniques) l’a certainement rendue plus accessible. Et j’ai vraiment été touché par les échanges en fin de présentation sur le fait que ce qui coûte cher aux mainteneurs de projets open-source, ce ne sont pas les serveurs, mais le temps passé et le manque à gagner qu’il représente.

Retour d’expérience : tests fonctionnels chez Maisons du Monde

Marc HUGON – Résumé, Slides, Vidéo

La présentation a commencé par une histoire assez classique, d’un site e-commerce existant sur des technos commençant à dater, repris par une nouvelle équipe, sans test automatisé, avec des phases de recette de plus en plus longues, jusqu’à arriver à un tunnel de commande KO en production pendant un bon moment. Sans test au départ, avec un time-to-market très court, un manque de connaissance et un gros existant, est-ce que mettre en place des tests unitaires aurait permis d’éviter d’en arriver là ?

Pour avoir une vision plus globale sur le bon fonctionnement du site entier (et pas de composants distincts) et mettre en place de tests rejouables, choix de Selenium. Problèmes de ce type de tests :

• Dépendance aux données (typiquement, que le produit testé soit en stock), d’autant plus qu’il faut tester des règles complexes dépendant fortement des données.
• Selenium est sympa, mais problèmes de volumétrie, ainsi que de maintenabilité des tests (fortement liés à la structure HTML des pages).
• Il n’est pas vraiment possible de tester ce qui arrive en base de données, l’utilisation de comptes utilisateurs différents à chaque lancement, la réception de mails de confirmation, …
• Sur quel environnement faire tourner les tests ? Directement en production ?

En somme, récapitulatif des besoins : des tests compréhensibles et maintenables, réutilisables, accédant à la DB et à des Web Services, avec un outil de travail dédié. Choix de RubyMine (pour la possibilité de poser des breakpoints pendant l’exécution des tests, notamment) + Cucumber + Selenium pour l’exécution. Comparable à Behat maintenant, mais lorsque le choix a été fait il y a deux ans, cette solution, qui existait depuis plus longtemps, a été jugée plus mature.

Pour répondre à la problématique d’avoir des données, les tests sont joués sur des dumps légers, anonymisés, ne contenant que deux mois de données (import en 15 minutes) – via un script PHP qui filtre un dump SQL complet de la production.

Également, mise en place de bouchons :

• Création de produits de test, correspondant aux différents cas de tests. Permet de ne pas modifier les données issues de la production, qui peuvent être utiles pour reproduire des bugs. Et code applicatif modifié pour tenir compte de ces produits de test, avec des portions du type if ($prod_id < 1000) { ... }.
• Surcharge d’URLs d’appels à certains WebServices par le biais de cookies, renseignés uniquement pour les tests.
• Mise en place d’un faux formulaire de paiement, qui entraîne le même type de retour que le paiement, sauf qu’il permet de spécifier le résultat attendu.

Au bout de deux ans : 10 développeurs et 3 testeurs (responsables des mises en production), environ 400 scénarios de test, 6 agents de build en jouant 3 en parallèle (pour que les tests ne durent pas trop longtemps), ~1000 commandes de test passées par jour. A permis une diminution forte des incidents majeurs et la garanti que le chemin critique est toujours fonctionnel avant chaque déploiement – y compris pour des points liés à des événements comme les soldes !

Il reste un problème qui n’a pas encore trouvé de solution : ces tests remontent pas mal de faux positifs, qui prennent beaucoup de temps à analyser.

Mon avis : J’ai retrouvé dans cette présentation pas mal de problématiques que j’avais rencontré il y a de nombreuses années sur une application e-commerce où nous souhaitions mettre en place de tests fonctionnels sur tout le workflow de gestion de commande (dans les grandes lignes, nous étions parti sur du phpunit pilotant Selenium, avec lancement de batchs entre temps pour les étapes sans écrans). Je suis à la fois content de voir que d’autres ont mis en place une partie des solutions auxquelles nous étions arrivé sur le coup (nous nous étions posé pas mal de questions face à l’usine à gaz que nous avions, à ses faux positifs, …) et un peu triste que la mise de tests fonctionnels complets ne se soit pas tellement simplifiée, plusieurs années après.

Retour d’expérience ARTE GEIE : développement API

François DUME – Résumé, Slides, Vidéo

Pour donner rapidement le contexte de sa présentation, François a commencé par rappeler que ARTE regroupe 36 sites web, de la TV / replay, des applications mobiles… Qui nécessitent des API pour échanger des données, comme des metadonnées de programmes (horaires, casting, droits, …), des URLs de flux ou des statistiques de consultation.

La mise en place de nouvelles API a été l’occasion de partir sur une base symfony2 + MongoDB, avec synchronisation asynchrone via RabbitMQ et échanges en json:api. La sécurisation des API et leur throttling (y compris en-têtes d’informations dans les réponses) a été généré par un mécanisme de reverse-proxy identifiant (nginx + scripts en Lua) nommé OpenResty. L’utilisation de json:api (via HateoasBundle, avec quelques patchs complémentaires) qui permet d’inclure des sous-documents permet de limiter le nombre de requêtes.

Une solution alternative aurait pu être de gérer l’autorisation ouath via varnish et non côté nginx – la mise en place de TU n’est pas vraiment facile sur des scripts Lua pour nginx, soit dit au passage.

Mon avis : J’ai pris note de la gestion d’OAuth au niveau de nginx (ou de varnish), ça peut être une idée à fouiller dans le futur, pour alléger la charge sur les serveurs applicatifs pour des APIs fortement sollicitées.

Automate your Workflow: Removing Tedium in Everyday Work

Bruno ŠKVORC – Résumé, Slides, Vidéo

Pour cette dernière conférence de la première journée de ce ForumPHP, Bruno, éditeur du canal PHP de Sitepoint, nous a présenté une démonstration d’un projet nommé Diffbot, qui vise à faciliter l’extraction de données de pages web. Il utilise cet outil afin d’automatiser une partie de son travail d’éditeur recevant de nombreux mails et brouillons d’articles, en particulier pour suivre les performances des auteurs – d’autres aspects automatisables étant le suivi de la compétition, la génération de factures, ou l’envoi de mails en masse.

Pour la démonstration, il s’est agit de montrer comment paramétrer Diffbot pour créer le portfolio d’un auteur, en partant d’une interface graphique qui permet d’extraire les données d’une page web ; y compris en gérant la pagination et des sous-données répétées sur chaque page. Le rendu peut ensuite être renvoyé via une API ou sorti sous forme de graphiques C3+D3.

Pour conclure, Bruno a rappelé que tout ce qui pourrait être automatisé devrait l’être : c’est ainsi que l’on gagne du temps pour coder ou bosser sur la qualité !

Mon avis : Je suis fan de l’approche qui dit qu’il faut automatiser tout ce qui peut l’être en vue de gagner du temps sur ce qui est important. Cela dit, j’ai trouvé un peu dommage que la présentation se soit concentrée sur un seul outil (qui a l’air de pouvoir faire quelques trucs sympas une fois pris en main, même si un peu cher pour mon usage personnel) : j’aurais probablement préféré une approche plus globale, donnant plusieurs pistes, quitte à moins détailler chaque point individuellement – et j’aurais adoré entre parler de génération automatique de résumé ou d’extraction de mots-clefs (j’ai eu l’occasion de m’amuser un peu avec ces sujets pendant mes études, vu que le labo rattaché à mon université faisait du traitement du langage naturel) pour faciliter certaines tâches de veille / suivi de mailing-lists (entre autres).

Mes notes du second jour de ce ForumPHP 2014 devraient être publiées dans quelques jours – le temps de finir de les mettre au propre ;-)