Comme chaque année depuis plus de 10 ans, s’est déroulé le Forum PHP à l’initiative de l’AFUP. Pendant 2 jours, développeurs, chef de projet et autres CTO ont présentés un total de 27 conférences, sur PHP et son écosystème. Faisant partie des développeurs PHP de SII, je vais vous résumer les conférences auxquelles j’ai pu assister.

Cet article sera découpé en paragraphe qui résumera les grandes lignes de chacune des conférences. Les liens des ressources liées à la présentation seront disponibles à la fin de chaque article.

P.S: Si vous manquez de temps, descendez à la fin. Une conclusion vous y attend ;)

Jour 1

N’ayant pas assisté à la première journée de cet événement, il m’est difficile de vous la résumer. Cependant, j’ai collecté pour vous les slides:

Jour 2

Frameworks: History of violence

Présenté par: François Zaninotto

Sur un ton teinté d’humour, prenant pour fil rouge une campagne électorale fictive menée par un parti électoral tout aussi fictif “Le parti de l’innovation”, François Zaninotto est revenu sur l’histoire des frameworks PHP. Depuis leur création jusqu’à leur hypothétique avenir. Il a également donné son point de vue sur l’attitude à adopter face aux changements à venir.

Il était une fois

Tout commence en 2000, où tout le monde veut son framework. Les premiers sont Apache Struts (que les plus séniors d’entre nous connaissent probablement) ou bien Maverick. Tous deux reposaient sur Java.

Un peu de structure

Puis en 2005, les design patterns montent en puissance, portés par PoEAA de Martin Fowler (un must-read pour ceux qui ne connaissent pas encore). Mais les frameworks web présents à cette période étaient basés sur Java ou C++. Octobre 2005, verra sortir la première release de Symfony 1. ZF1 suivra quelques mois plus tard.

PHP strikeback

C’est alors qu’en 2007, la contre-attaque de PHP s’organise. Avec en ligne de front, les CMS Wordpress et Drupal, présent depuis le début des années 2000, qui devenaient de plus en plus populaires. ZF1 et SF1 eux aussi ont gagnés en réputation après 2 ans d’existence. Dans le même temps, la mode était aux applications Ajax. Les frameworks JavaScript jQuery et Prototype étaient là pour assurer l’implémentation côté front. PHP, facile d’accès, était retenu dans la plupart des choix pour le backend. Le couple PHP/JS était alors né et permit à PHP de se répandre rapidement.

Les entreprises disent oui

En 2010, l’adoption des frameworks PHP par les entreprises est à son paroxysme. Afin de se pérenniser et de monter d’un cran dans la professionnalisation, le FIG est créé. Ce groupe ne tardera pas à définir le PSR-0, une norme destinée à favoriser l’interopérabilité entre les frameworks PHP (qui avait déjà plus de 5 ans d’existence). Leurs spécifications reposant sur des fonctionnalités fraîchement introduites dans PHP (autoloading, …) ont permis de développer un nouvel écosystème PHP, notamment incarné par Composer et ses packages, et de passer les frameworks à leurs versions supérieures. Zend Framework 2 et Symfony étaient nés. Seulement la menace n’est pas très loin, celui qui était l’ami de PHP hier, j’ai nommé JavaScript, va progressivement se retourner contre lui.

Une nouvelle ère

En 2012, la spécification HTML5, dont tout le monde parle depuis quelques années déjà, commence à être de mieux en mieux supportée par les navigateurs. Elle fait une utilisation intensive de JavaScript, ce qui va accroître sa popularité, déjà conséquente depuis l’avènement de jQuery, YUI et Prototype. Les frameworks front AngularJS et Backbone vont servir de relais de croissance. Dans le même temps, des développeurs ont eu la bonne idée d’utiliser le moteur JavaScript V8 du projet Chromium pour interpréter du code côté serveur. Cela donna naissance à Node.js. L’équation n’était pas compliquée, du JS sur le front, du JS sur le back : avouez, c’est plutôt tentant.

Conséquence de la popularité croissante des solutions alternatives telle que JavaScript, on ne parle plus seulement de PHP pour les backend, mais aussi de Go, Ruby, Python et JavaScript. Ces langages qui sont bâtis sur d’autres paradigmes s’en sortent mieux pour certaines tâches.

La réponse de PHP ne se fera pas attendre. Elle aura lieu sur un autre terrain: les micro-frameworks. L’un des premiers venus sera Silex. Il n’embarque que le strict nécessaire et laisse le choix à l’utilisateur d’ajouter les composants. Une philosophie contraire aux frameworks historiques qui sont dit “full-stack”. Cette réponse arrive à point nommé alors que l’architecture microservices se popularise, notamment grâce à “Docker”.

En vérité, les frameworks PHP ont souffert des lacunes du langage.

L’avenir

Et maintenant ? Quid de l’avenir ? Ne parlera-t-on plus que de JavaScript et de Go en 2020 ? Les frameworks full-stack seront-ils minoritaires ? Jusqu’où ira cette frénésie du découplage et du minimalisme ? PHP sera-t-il dévoré par ses lacunes et ses querelles internes ?

Les leçons de l’histoire

Cette histoire nous donne quelques leçons. Tout d’abord les frameworks full-stack ont une propension à l’obésité alors que la tendance est à l’inverse: prendre moins de place, moins de ressources, moins de temps.

Les frameworks vivent longtemps, car les applications qui en dépendent ont de longs cycles de vie. Il n’empêche que comme tout autre outil, leur usage décroit au bout d’un moment et finit par devenir très minoritaire. Cela à cause d’autres frameworks qui naissent avec des fonctionnalités plus adaptées aux techniques du moment, avec des performances supérieures du fait de leur absence d’historique.

Les frameworks les plus utilisés n’évoluent pas assez rapidement à cause du nombre important d’utilisateurs. 7 ans séparent jQuery 1 et 2, Symfony 3 n’apporte pas beaucoup de changements par rapport à la version 2.

La neutralité des sociétés qui sont derrières peut être remise en cause: ont-elles intérêt à rendre le framework plus simple à prendre en main alors qu’une de leur source de financement est la vente de support ?

Pour résumer: * Intéressez-vous aux micro-frameworks * Partez à la découverte de nouveaux langages, d’autres paradigmes, et n’hésitez pas à les faire interagir. * Les frameworks sont éphémères, détachez-vous en au maximum en privilégiant le domaine dans votre architecture (Cf. (DDD)[http://www.infoq.com/presentations/model-to-work-evans]) * Utilisez au maximum les outils à votre disposition pour réduire votre temps de développement

Liens:

Bringing Sculpin to Life

Présenté par: Beau D. Simensen

Beau Simensen est l’auteur de Sculpin, un générateur de sites statiques. Il nous a expliqué comment s’est passée la création de son propre projet open-source: un générateur de sites statiques (GSS). Depuis l’idée jusqu’à l’application et sa communauté d’utilisateurs.

Un développeur enthousiaste

Beau Simensen est développeur depuis de nombreuses années. En 2011, il découvre Jekyll, un générateur de sites statiques écrit en Ruby. Il se demande si un outil équivalent existe en PHP. Dans le même temps, Symfony 2 et Composer sont publiés, il fait quelques expérimentations avec. Devenu utilisateur de Jekyll, il tente quelques contributions à ce projet et à l’un de ses concurrents: Octopress. Pendant, ce temps-là, la communauté PHP continue de se développer autour des composants et des micro-frameworks. Il prend beaucoup de plaisir à développer avec ces nouveaux outils PHP. Plein d’idées lui viennent et il se lasse de Jekyll et Octopress. Il se dit qu’il pourrait réaliser son propre GSS en PHP.

 Des précédents

Mais il n’est pas le premier à avoir eu l’idée, il y a eu un précédent: Phrozn. Il s’interroge sur le bien-fondé de son idée et finalement elle prend forme. Des templates utilisant Twig, un Composer embarqué, une application extensible: ça y est c’est parti ! Mais il faut d’abord trouver un nom … Ce sera Sculpin.

Le choix fut bon

Le premier commit a eu lieu le 21 décembre 2011. L’architecture s’appuie grandement sur Composer, pour la rendre le plus modulaire possible. Quelques mois plus tard, il se dit qu’il a fait le bon choix et continue le développement. La communauté se construit et il se rend à la conférence Symfony Live! à San Francisco en 2012. Il y rencontre le créateur de Composer en personne.

Gain de confiance

Il se dit qu’il pourrait lui aussi donner une conférence au prochain Symfony Live!, cela permettrait de faire connaître Sculpin. C’est alors qu’en 2013, après plusieurs propositions de talks, il se rend à Portland pour la conférence Symfony et parle de Sculpin. Tout se passe très bien, et depuis Sculpin n’en finit pas d’évoluer et sa communauté de grandir.

Pour conclure, Beau craignait beaucoup le rejet de la communauté parce qu’il réinventait la roue, mais cela s’avère payant parfois. Il conseille à tous les développeurs qui souhaitent faire comme lui, d’essayer les solutions existantes, de trouver des justifications, de construire des applications comme ils aiment, et dont ils pourraient être les utilisateurs.

Liens:

VDM, DevOp malgré moi

Présenté par: Maxime Valette

Inutile de vous présenter VDM, ce site où les internautes peuvent partager leurs mésaventures quotidiennes, et toutes ces situations où l’on se dit que c’est une “Vie De Merde”. C’est l’un de ses fondateurs, Maxime Valette, qui est venu nous raconter les péripéties du site depuis son lancement.

Au départ

Maxime Valette est un autodidacte, influencé par un père qui pratique le développement, il créé ses premiers programmes en BASIC. Plus tard, il montera sa première société, avant même sa majorité: un registrar. Il la revendra l’année de son bac, avant de se lancer dans VDM avec son associé rencontré quelques temps auparavant, chez les AAA. Ensemble, ils créent leur société: Beta&cie et donne naissance à la version 1.0 de VDM. Tout d’abord, sous la forme d’un blog minimaliste où seuls les administrateurs peuvent ajouter des “VDM”, ces petites anecdotes cocasses de la vie quotidienne. À cette époque, le blog connaît une fréquentation de 300 visiteurs par jour.

Le succès arrive vite

Le succès grandissant, les utilisateurs demandent la possibilité d’ajouter leurs propres VDM. Déjà très occupés par le trafic du site, ils codent rapidement un module pour répondre à cette exigence. Peu importe la qualité du code, l’important étaient de satisfaire les internautes.

Très (trop?) vite

Tout se passe correctement, jusqu’à ce week-end de février, alors que Maxime Valette et son associé participaient à un tournoi de E-Sports à plusieurs centaines de kilomètres de chez eux, ils reçoivent une alerte indiquant que le site ne répond plus. Branle-bas de combat, ils reviennent en urgence chez eux pour résoudre l’incident. La cause était une importante augmentation du trafic. En l’espace de 2 jours, plus de 10 000 personnes s’étaient rendues sur viedemerde.fr.

Repérés par les médias

Ce gain de popularité les conduisit à être médiatisés et la machine était lancée. VDM 2.0 fit son apparition quelques mois plus tard, le trafic passe à 45 000 visites par jour, 3000 à 4000 VDM sont postées quotidiennement. Ils sont à nouveau médiatisés, cette fois par Le Grand Journal sur Canal+, le trafic monte à 185 000 visites/jour.

VDM s’exporte et se diversifie

Un nouvel associé se joint à eux, Didier Guedj, avec qui ils envisagent de nouveaux projets pour VDM. C’est alors qu’en 2009, ils lancent FML (Fuck My Life), la version USA de VDM. Le site connaît un grand succès, le trafic s’établit rapidement à 1 000 000 de visiteurs/jours. Un livre en Français et un autre en Anglais sont publiés.

Et la technique ?

Les débuts de VDM étaient très rudimentaires d’un point de vue technique. Pas d’intégration continue, aucune méthodologie de développement, des outils non professionnels. Leur temps est vampirisé par les problématiques engendrées par le succès croissant du site. Entre nuits blanches à coder et les journées très chargées à modérer les VDM, il leur était impossible de trouver du temps pour mettre en place un workflow solide. Leur approche était très pragmatique. Par exemple, afin de distribuer la charge entre tous les serveurs ils utilisaient un DNS round-robin au lieu d’un load balancer.

Professionnalisation

Ce n’est que plusieurs années après le lancement, qu’ils pourront se consacrer à cette tâche. Les fichiers qui étaient poussés en production via un Webdrive laissent leur place à Git et son versioning. Du PHP procédural, ils sont passés au PHP objet. De Memcache à Redis. Et bien d’autres changements …

VDM aujourd’hui

À l’heure où je vous parle, VDM est visité par 3 millions de personnes par jour qui verront en tout 100 millions de pages en un mois. 11 millions d’anecdotes, 7.5 millions de commentaires et 3 milliards de votes ont été envoyés depuis le début. Le trafic est essentiellement mobile.

Maxime Valette à tirer les leçons suivantes de cette aventure: * Un bon code tient la charge et rapporte de l’argent * Un bon DevOps équilibre ses tâches et doit rester pragmatique * Un bon entrepreneur ne se jette pas sur la première opportunité sans réfléchir

An introduction to the Laravel Framework for PHP.

Présenté par: Dayle Rees

Dayle Rees est core dev sur le projet Laravel, un framework PHP créé par Taylor Otwell, auteur de plusieurs livres sur ce sujet et fondateur de la startup “Just Park”. Il nous a présenté l’histoire de Laravel et ses fonctionnalités actuelles.

La découverte de Laravel 2

Dayle Rees a découvert Laravel à sa version 2. Nous étions en 2011. Le website était simple, le code d’une grande clarté, mais très peu d’utilisateurs. Taraudé par l’envie de contribuer à un projet, il décida de s’investir dans Laravel. Il commença par être actif sur le chan IRC, où seulement 3 personnes étaient présentes au départ (contre 600 actuellement). Il écrivit quelques tutoriels qui reçurent de l’attention. Et c’est comme ça que l’aventure à démarrée.

Investissement dans Laravel 3

Laravel 3 a été l’occasion pour Dayle Rees de rentrer dans le vif du sujet. Il a soumis de nombreux patchs et features, a contribué au design du site Laravel, a créé quelques bundles et a continué de développer la communauté. Tout cela l’a conduit à devenir ami avec le créateur de Laravel. Cependant, la version 3 avait ses défauts. Les tests n’étaient pas simples à mettre en oeuvre et l’extensibilité était médiocre.

Avenement de Laravel 4

T. Otwell commença le développement de Laravel 4 en repensant l’architecture. Désormais, les composants sont à la base du framework, notamment aidé par Composer. Et certains de ses modules sont des briques open-source venant d’autres projets, tel que Symfony 2. Et pour améliorer la distribution de ce framework, un cycle de release stable et un retour d’expérience ont été mis en place.

Oui, mais …

Vous allez me dire “Oui, mais alors est-ce vraiment utile d’avoir créé un nouveau framework, alors que celui-ci utilise des briques open-source d’autres projets ?”. La réponse tient en un seul mot: philosophie. L’idée de base de Laravel repose sur plusieurs préceptes: * Le développement peut-être amusant * Le code peut être une forme d’art * La syntaxe doit être simple et limpide * Le framework doit évoluer avec vous * Le framework doit être une plateforme complète, couvrant vos besoins de bout en bout * Ses composants doivent être pertinents * Il doit adopter la philosophie open-source et en faire usage dès que possible * Il doit redistribuer à la communauté open-source * Et fédérer une communauté d’Artisans

C’est ainsi que s’appelle les développeurs de la communauté Laravel : les Artisans.

Fonctionnalités de Laravel 4

Rentrons dans le vif du sujet, en regardant de près ce que nous propose la dernière mouture de Laravel. * Un conteneur d’inversion de contrôle: Cela permet d’instancier n’importe quel type d’objet, n’importe où dans le code sans coder en dur les dépendances. La résolution de la classe se fait de manière automatique. php App::bind('foo', function($app) { return new FooBar; }); * De multiples services: routeur, gestionnaire d’évènements, validateur, système de queue, ORM, CLI, … ! * Un PaaS dédié : Laravel Forge qui propose des stacks avec PHP 5.6 ou HHVM

Liens:

Vers des applications “12 factor” avec Symfony et Docker

Présenté par: Geoffrey Bachelet

Geoffrey Bachelet, développeur indépendant, nous a présenté la méthodologie “12 factor”. Cette démarche créée par des ingénieurs de Heroku a pour but de faciliter l’exploitation d’une application en mode SaaS.

Codebase

Une codebase, c’est une “base de code”. Grossièrement, le code source pour UNE SEULE application sur un VCS (Git, Mercurial, …). Par conséquent, plusieurs codebase pour un seul et même projet signifie que ce n’est pas une application, mais un système distribué. Une codebase peut être déployée sur de multiples environnements (dev, staging, prod, …).

Dependencies

Elles peuvent être installées au niveau du projet ou au niveau du système. Elles doivent être déclarées dans un fichier séparé et isolées dans un dossier. Quid des outils systèmes tel (cUrl, imagemagick) ? La plupart, du temps il existe des alternatives qui peuvent être installés via votre système de gestion des dépendances. Évitez autant que possible les “shell out”, autrement dit l’appel d’une commande système depuis votre code (passthru, …). Cela vous couplerait à votre OS hôte. Si vraiment vous n’avez pas le choix, incluez le binaire du projet dans les sources (dans un répertoire bin/ par exemple).

Config

La configuration, doit contenir des éléments du type identifiants pour services en ligne (Amazon S3, Twitter, …), informations de connexion à des ressources (Redis, Memcached, …) ou des valeurs propres à un environnement de déploiement (dev, prod, …). Le fichier de config doit être séparé du code, et injecté dans l’application à l’exécution. N’hésitez pas à en créer autant que nécessaire. Les variables d’environnement sont très importantes pour atteindre le découplage maximum entre configuration/environnement et la codebase.

Backing services

Un “Backing service” est un service que l’application utilise pendant son fonctionnement normal. En pratique, cela peut être une instance MongoDB, un serveur Postfix, … Quelque soit le type de service, vous pouvez utiliser pattern Ambassador de Docker. Cela permet de découpler l’application du service qu’elle consomme. Ainsi, lorsque vous devez changer l’instance du service par une autre, pour prendre en compte les modifications, vous ne redémarrez pas l’application qui consomme ce service, mais son ambassador qui agit en tant qu’intermédiaire.

Build, release, run

Le déploiement d’une application se réalise en trois étapes. Tout d’abord, “Build”. L’application et ses ressources sont compilées, les dépendances installées. Ensuite vient la “Release”. Cette étape combine le build avec la config du déploiement en cours. Une fois terminé, l’application et tous les processus dont elle dépend sont lancés, c’est “Run”.

Processes

Chaque application embarque son volume de données propre. Les caches ne sont pas partagés, par exemple. Qu’en est-il des assets ? Mettez-les sur un CDN, ils seront disponibles à tout votre système et offriront la possibilité d’être distribué au plus près du client.

Port binding

Chaque application est autocontenue. Elle est dans un conteneur qui expose des ports pour permettre l’interaction avec d’autres conteneurs. Elle peut ainsi devenir un backing service très facilement.

Concurrency

Les processus doivent être facilement réplicables et instanciables pour faciliter la montée en charge. Par exemple, si un worker dédié à du traitement d’image fait face à une charge exceptionnelle, le système hôte doit pouvoir répliquer le processus de ce worker afin qu’il absorbe cette charge et maintiennent une qualité de service acceptable.

Disposability

Suite logique de concurrency, les processus doivent pouvoir s’arrêter/démarrer rapidement. Leur extinction ne doit pas influer sur le fonctionnement des autres processus. Un démarrage rapide permet une réponse à la montée en charge rapide.

Dev/Prod parity

Bien qu’avoir des environnements différents soit important, ceux-ci ne doivent pas être trop différents les uns des autres. Ils doivent aussi faciliter l’intégration continue, de cette manière un développeur qui passe des jours à développer, à un retour quasi immédiat sur le fonctionnement de son algorithme dans un environnement donné.

Logs

Chaque processus doit écrire son propre log sur stdout. En environnement de développement, le développeur les verra dans son terminal. Dans les autres environnements, ils seront capturés par d’autres processus qui les retranscriront sous un autre format (Dashboard, notifications …).

Admin processes

Les processus de maintenance doivent être exécutés sur la même codebase avec une configuration identique à l’application. Les scripts de ces tâches doivent être commités dans la codebase de l’application.

Bien que ces conseils peuvent se révéler très utiles, ne les appliquer pas les yeux fermés certains peuvent ne pas satisfaire vos contraintes.

Liens:

Cohabitation de PHP et Node.js au Monde, pourquoi et comment

Présenté par: Olivier Grange-Labat

Olivier Grange-Labat est directeur technique à Le Monde interactif, la filiale digitale du journal Le Monde. Cette entité, créée en 1998, a pour rôle la gestion du site Le Monde.fr ainsi que les applications mobiles et tablettes. Pour assurer ces missions, l’équipe est composée de 33 développeurs, 3 ops, 1 intégrateur et 4 managers. Chaque mois entre 500 et 600 millions de pages sont vues sur Le Monde.fr. Au moment où vous lisez cet article, 150 000 visiteurs sont sur Le Monde.fr. Les stacks front sont composées de Apache, PHP, Redis, Oracle. Quant aux stacks CMS, outil de gestion de contenu, elles reposent sur Node.js, AngularJS, Redis, PostgreSQL.

 L’histoire d’une refonte

Nous sommes au premier trimestre 2012. Les présidentielles se déroulant en mai, Le Monde.fr souhaitait être le premier à notifier les utilisateurs de son application du résultat de l’élection. Le système reposait jusqu’alors sur PHP. Le challenge était de taille, car il y avait de nombreux utilisateurs, la deadline ne pouvait pas être repoussé et était très proche.

Au deuxième trimestre 2012, le constat est fait que les outils de gestion de contenus, basés sur XUL, sont vétustes. Les rédactions papier et web avaient besoin de se rapprocher. Enfin, les performances sur les différents canaux devaient être améliorées. Un projet de modernisation est donc lancé pour répondre à ces problématiques.

À partir du 3e trimestre 2012, les différentes technologies sont étudiées, des PoC sont réalisés à partir de ces technos et d’une solution interne.

Au premier trimestre 2013, le choix d’une solution maison est fait. Et cela pour maîtriser la technologie, parce que des compétences étaient déjà présentes en interne et les solutions du marché sont toutes en retard. Désormais, les rédactions web et papier utilisent le même outil. Et le système de gestion de contenus sera développé en interne. Les technologies retenues sont AngularJS, Node.js, PostgreSQL et Github.

Pourquoi Node.js ?

Étant donné l’usage d’AngularJS sur le front, le paradigme et le langage étaient le même sur le front et le back. Cela facilite grandement le développement.

Le projet est orienté temps réel, il comprend des notifications push, de la collaboration, du chat. Node.js est un bon candidat pour ce type d’applications.

Les compétences étaient déjà présentes au sein de l’équipe du Monde interactif.

Enfin, une techno “cutting-edge” a tendance à attirer des développeurs “high-profile”, car ce sont ceux qui s’intéressent le plus aux technologies naissantes.

Etait-ce le bon choix ?

Node.js est en phase avec son temps, ce qui plaît beaucoup au développeur qui n’aime pas travailler sur des technologies obsolètes.

Node.js a permis aux DevOps de tous parler la même langue: JavaScript. Le backend, le front et les outils de déploiement (Grunt …) ou de tests (PhantomJS …) sont tous dans le même langage.

Le packager de Node.js est très efficace et propose des paquets qui ont répondus à toutes les problématiques du projet.

Les modules installés via ce packager respectent la philosophie Unix: des programmes qui font une seule chose, mais la font bien. Cela a accéléré la prise en main des dépendances.

Node.js est stable d’une version à l’autre. Les déploiements sont rendus très simple grâce à l’utilisation combinée de NVM (qui permet de gérer différentes versions de Node.js) et de NPM.

La qualité de la documentation de Node.js à permis l’adoption rapide au sein de l’équipe.

En revanche, la programmation asynchrone est difficile à appréhender. Pour réduire la difficulté async et les promises ont été utilisés.

Par rapport à PHP, précédemment utilisé, passer du paradigme “requête” à “serveur” n’est pas évident, car Node.js est à la fois interpréteur et serveur. Autre écueil, les exceptions logicielles. En effet, tout lancement d’exception arrête le serveur Node.js. Il faut donc veiller à ce que leur intégralité soit correctement prise en charge. Enfin, Node.js est sujet aux fuites de mémoire, il faut constamment garder un oeil sur la consommation de RAM.

Même si le packager est très bon, et que dans l’ensemble les paquets sont de bonne facture, certains sont immatures. C’est ainsi le cas de socket.io qui a été remplacé par Primus en cours de projet.

Node.js est relativement bas niveau, et cela introduit de nouvelles problématiques pour la gestion des processus notamment. Forkie a permis de trouver une solution.

Prévisions pour 2015

Nouvelle version du monde.fr. Pour l’instant, une architecture SPA est envisagée, mais cela pose plusieurs problèmes. Tout d’abord de SEO, car Google ne comprend pas très bien les sites en une seule page. Ensuite, les performances des navigateurs mobiles ne permettent pas l’usage d’un framework JavaScript haut-niveau. Enfin, la nature même du site est remise en cause: est-ce une application ou un site ?

Donc la solution favorisée pour le moment, se compose d’une API d’accès aux données reposant sur Node.js, de générations de pages HTML côté serveur et l’utilisation de web components.

Conclusion

La nouvelle stack à été mise en place avec succès. Node.js est prêt pour la production, ce n’est pas une techno éphémère, d’ailleurs beaucoup de sites à forte volumétrie l’utilisent (Groupon, Paypal, LinkedIn, …).

Cependant, la technologie n’est qu’un outil. Aujourd’hui Node.js est répandu, demain un autre prendra sa place. Il faut donc investir pour apprendre d’autres technologies.

Liens:

Table ronde “État des lieux et avenir de PHP”

Présenté par: Pascal Martin, Julien Pauli, Pierre Joye, Jordi Boggiano

Cette table ronde a réuni 4 acteurs majeurs du monde PHP francophone.

Tout d’abord, Pascal Martin, développeur PHP, qui a donné plusieurs conférences et a plusieurs publications à son actif. Il est membre de l’AFUP depuis plusieurs années, il y est responsable d’une mailing-list dont le sujet est les prochaines évolutions de PHP.

Ensuite, Julien Pauli, vous avez sûrement dû entendre ce nom si vous avez cherché des livres en français sur PHP. Il donne régulièrement des conférences et est release manager sur PHP 5.5 et 5.6.

Pierre Joye était aussi présent, il est actuellement expert PHP chez Microsoft, qui et l’un des plus gros contributeurs via des bugfixes et des QA test. Il a été mainteneur du dépôt PEAR et de plusieurs extensions tel que GD ou xmlwriter.

Enfin, nous pouvions compter sur la présence de Jordi Boggiano, lead développeur de Monolog et Composer.

Ce fut l’occasion de parler de l’état actuel de PHP, de la direction qu’il allait prendre dans les mois à venir, notamment face à la montée de la concurrence (HHVM, HippyVM, …).

PHP 7

Concernant PHP 7, les questions portaient sur la suppression des fonctions/extensions deprecated, l’Unicode et plus globalement sur la release de cette version.

Avenir des deprecated

Tout d’abord, la question n’est pas complètement tranchée sur les deprecated, car certaines personnes veulent les garder, d’autres les enlever. L’avis est principalement conservateur, en témoigne la RFC de Nikita Popov en discussion depuis bientôt 2 mois. Un sondage rapide dans l’assistance à permis de mettre en évidence que beaucoup de projets utilisent encore des deprecated ou des versions obsolètes de PHP.

Unicode

Au sujet, de l’Unicode dans PHP 7, il ne sera pas intégré complètement comme cela était prévu avec PHP 6. En revanche, les dernières RFC laisse penser qu’il sera bien présent, mais de manière progressive. En effet, la RFC UString proposé par Phil Sturgeon et Joe Watkins prévoit l’introduction d’un nouveau type de String, la UString. Celle-ci permettrait de manipuler des chaînes de caractères en Unicode, si nécessaire, sans toutefois remplacer l’API String actuelle.

Release process

Plus globalement, au sujet de PHP 7 et sa release, l’échec de PHP 6 est encore dans toutes les mémoires et Julien Pauli a affirmé que ça ne se reproduira pas avec PHP 7. La release de PHP 7 d’ici un an, tel que proposé par Zeev Suraski dans cette RFC, laisse beaucoup de monde sceptique et est très incertaine pour l’heure.

Autres points

En vrac, le typage statique dans PHP a été abordé, bien qu’une RFC concernant la déclaration du type de retour des fonctions est en cours de discussion, il n’est pas prévu de rendre PHP fortement typé (comme Java par exemple), selon J. Pauli.

Le multithreading coté kernel n’est pas prévu non plus, Julien Pauli a cependant donné une alternative userland qui donne de bons résultats: pthreads, développé par Joe Watkins.

Appel à la contribution

Enfin, cette table ronde a mis en avant le déséquilibre entre le nombre de contributeurs au core de PHP et le nombre d’utilisateurs dans le monde (Près de 82% des sites). Un appel à la contribution a été lancé. Tout le monde peut aider, sans forcément écrire une ligne de code. En traduisant la documentation, réalisant des tests sur les nouvelles releases de PHP ou en remontant les bugs par exemple.

Liens:

Conclusion

Ces 2 jours de conférence ont permis de faire ressortir les grandes tendances du moment. Je pense en premier à l’architecture microservices, implémenté par les micro-frameworks, conjugué à la conteneurisation des applications et lié par la philosophie Unix, permet de répondre aux problèmes de scalabilité que rencontre les applications d’aujourd’hui.

La montée en puissance de Node.js face à PHP à été mise en évidence, et au regard de la forme que prend PHP et son écosystème (release de PHP 7, concurrence de HHVM, …), on peut se demander si il ne serait pas judicieux d’avoir plusieurs cordes à son arc en se penchant sur d’autres technos. Cependant pas de quoi s’alarmer pour le moment, on voit que les frameworks majeurs sont toujours Symfony 2 et Zend Framework 2 et que Wordpress et Drupal reste en tête du classement des CMS PHP les plus utilisés. Toutefois des alternatives existent, Laravel et Cake PHP entre autres. Et si le full-stack ne vous convient pas, Silex, un micro-framework PHP, peut répondre à vos attentes. En un mot : PHP n’est pas mort, il continue de se renouveler. Et vous avez le pouvoir d’accompagner ce renouvellement en vous investissant dans la communauté PHP.

Un mot est souvent revenu : DevOps. Les frontières entre le développeur (qui écrit le code source l’application) et l’opérateur (qui déploie ce code source) sont de plus en plus minces. Et quand on voit l’expérience du fondateur de VDM, on se dit que l’on a tout à gagner à jouer sur les deux terrains. Docker, Fig, AWS, Scrutinizer, Puppet, Chef sont autant d’outils qui tendent à rapprocher dev et ops.

À l’heure où je publie cet article, les replays des conférences commencent à être disponibles sur la chaîne YouTube de l’AFUP, c’est un excellent complément à cet article et aux slides. Vous les trouverez ici.