Deamonspace

Reconnu d'utilité publique depuis 1804

Symfony Live – Paris 2014 : mes retours

| 1 commentaire

Les 7 et 8 avril 2014, j’ai eu le plaisir de participer au Symfony Live à la Cité internationale universitaire de Paris, voici les retours in extenso que j’ai pu faire des conférences.

Symfony Live 2014 Paris

Lundi 7 avril

Keynote par Fabien Potencier

Twitter Github Site web

Le patron de SensioLabs ouvre le live avec un petit point sur la communauté Symfony en chiffres :

  • ≈ 1000 contributeurs
  • 150 000 développeurs dans le monde
  • 15 millions de visites sur le site symfony.com
  • 1 million de téléchargements du package d’install depuis le site chaque mois
  • Plus de 30 millions de téléchargements depuis Packagist (framework et bundles)
  • Plus de 2200 bundles issus de la communauté

Fabien revient sur le versionning de Symfony. Il présente le framework comme étant « un middleware pour PHP » et nous renvoie sur le site de la SemanticVersion : https://semver.org.

Il revient aussi sur le passage difficile que les développeurs ont connu entre Symfony 1 et 2, et annonce une migration plus simple entre les versions, et surtout moins douloureuse. Les migrations majeures (comprendre quand on passera à Symfony 3 J) se feront naturellement pour les personnes qui auront pris l’habitude de corriger leur code en n’utilisant plus de versions dépréciées (genre par exemple remplacer la méthode bind() / submit() par handleRequest() dans l’utilisation des forms).

Tout cela pour arriver justement à l’annonce de Symfony 3.0, pas de date prévue pour le moment, mais le travail est en cours. En attendant on peut suivre l’ordonnancement des prochaines versions 2.x (https://symfony.com/doc/current/contributing/community/releases.html#schedule) ou obtenir des infos depuis la page Roadmap de Symfony.com (https://symfony.com/roadmap).

Autres annonces notables :

  • Mise en place de RFCs pour Symfony
  • Le retour de la CoreTeam avec une approche plus structurée de l’équipe de développeurs (mise en place de mergers, de membres preneurs de décision), voir l’article concerné : https://symfony.com/blog/the-symfony-core-team-is-back

Solr et recherche dans un site ecommerce par Adrien Brault

L’intervenant, qui travaille chez Hautelook (https://www.hautelook.com), nous parle de sa récente expérience sur le projet sur lequel il est affecté. La présentation commence par une comparaison entre Solr et ElasticSearch (voir le site dédié https://solr-vs-elasticsearch.com), en démontrant l’intérêt de Solr par rapport à l’autre solution dans le contexte des problématiques rencontrées pour Hautelook.

Il nous fait ensuite une présentation complète sur l’installation et la configuration de Solr, sur l’art et la manière d’écrire un ETL bien structuré pour encaisser une grosse volumétrie de données, et enfin comment intégrer Solr dans un projet Symfony2 avec Solarium (https://github.com/nelmio/NelmioSolariumBundle) + quelques bundles sympas pour améliorer les perfs (https://github.com/hautelook/solarium-cache) et l’intégration (https://github.com/floriansemm/SolrBundle)

Slides de la présentation : https://speakerdeck.com/adrienbrault/solr-et-recherche-dans-un-site-ecommerce

« Un framework presque parfait ». On fait quoi avec Symfony à la télé ? par OIivier Mansour

Comme vous l’aurez compris, le présentateur est de chez M6, plus précisément M6Web. Il est venu nous parler de son retour d’expérience de l’intégration de Symfony2 dans ses projets. Pour info, chez M6 ils ont :

  • 306 repositories Git
  • 150 domaines actifs
  • Beaucoup de technos qui cohabitent sur les différents projets (Différentes versions de PHP, de MySQL, systèmes de gestion de files de messages, scripting en tout genre etc)
  • Leurs contraintes sont très serrées, ils doivent faire en sorte que leurs applications soient compatibles avec le maximum de supports permettant d’y accéder (PCs, tablettes, smartphones, liseuses, PDA, etc)

Déjà depuis plusieurs années, ils ont opéré une longue migration de toutes leurs applis de Java vers PHP, et ils codent véritablement avec Symfony2 depuis environ 18 mois.

Étant donné qu’ils auront moins de développeurs que de projets et moins que de technos, et que « nous écrivons tous du mauvais code » (sic), ils ont pris le parti de se créer une version de Symfony « M6 edition », comprendre que le framework reste inchangé, mais la configuration est calée aux petits oignons pour eux et pour les besoins qu’ils ont, ils limitent ainsi le syndrome du copier-coller malencontreux, et « suppriment le coût de la qualité ».

Ils partent également du principe de ne rien laisser au hasard en stockant toutes leurs dépendances sur des ressources gérées par eux, en mettant la règle packagist = false dans le composer.json comme expliqué ici : https://tech.m6web.fr/composer-installation-without-github.html. Notez que cette pratique définie comme une bonne pratique requiert une infrastructure complète gérée par sa société, capable de remplacer Github et Packagist.

On a eu droit ensuite à une petite session trolling sur les priorités données aux technos. Chez M6, on pense :

Varnish > Ngix > Ngix + Lua > NodeJS > Symfony

Cela en fonction de la charge et du la quantité de code à produire évidemment.

Comment mesurer la performance d’un site web ? C’est comme quand votre femme vous demande si sa nouvelle robe ne la boudine pas trop, si vous mettez trop de temps à répondre, vous avez forcément tout faux.

Cette petite blague est en introduction de la dernière partie de la conférence sur la nécessité de monitorer à l’extrême ses projets, aussi bien au niveau de l’intégration continue, que de la montée en charge, et de ne pas hésiter à déléguer cette dernière tâche à une société spécialisée pour éviter l’effet amateur en réalisant des tests de charge complaisants ou insuffisamment poussés.

Slides de la présentation : https://fr.slideshare.net/oliviermansour/symfony-la-tl

De nouveaux outils de debug dans les cartons par Nicolas Grekas

L’intervenant est venu nous parler du futur du débuggage dans Symfony2. En faisant un sondage rapide parmi l’assistance, nous sommes 99% à jouer du var_dump() dans notre code pour comprendre ce qu’il s’y passe. Nicolas Grekas est en train de faire évoluer le composant Debug en mettant en place de nouveaux mécanismes, qui seront capables, dans l’environnement de développement, de proposer une nouvelle façon de débugger. Parmi les fonctions apportées :

  • Logguer les erreurs silencieuses (les fameux @ devant les noms de fonctions).
  • Afficher l’état d’une variable (comme on le ferait avec var_dump()) dans un onglet dédié de la toolbar, sans casser le flux de sortie originel de la page.
  • Vérifier la cohérence des noms de fichier vs noms de classe, en allant jusqu’à la casse des caractères (erreur insidieuse difficile à repérer quand elle intervient).
  • Proposer une sortie améliorée des logs (notamment le filtrage par niveau d’importance)

Il existe déjà quelques approches comme Ladybug (https://github.com/raulfraile/Ladybug) mais jugées encore insuffisantes.

Arrive la proposition d’une nouvelle fonction visant à substituer var_dump() : debug(). Cette fonction doit répondre à un cahier des charges simple :

  • Etre exacte, mettre en évidence les références quand il y en a par exemple
  • Détaillée, avec des infos pertinentes en fonction de l’objet exposé (exit par exemple l’entity manager intégralement lié à une entité)
  • Jolie et pratique, capable de mettre en couleur en mode console, d’afficher les données de façon structurée en mode graphique
  • Peu gourmande en ressources, rapide et robuste, hors de question de faire tomber le serveur de la machine de dév en essayant de débugguer 🙂

Elle est bien entendu disponible aussi bien du côté PHP que pour Twig. Il a enchaîné sur une explication de son intégration au composant Debug pour Symfony2, config etc., une bonne occasion de voir comment créer ses propres onglets dans la toolbar du mode dév 🙂

Il a terminé sur les discussions en cours sur d’autres outils de debug. Le tout est en cours de stabilisation et sera disponible pour la version 2.5 du framework.

Slides de la présentation : https://speakerdeck.com/nicolasgrekas/debug-plus-symfony

Présentation de Behat 3 par Christophe Coevoet

Sans doute la présentation la plus énigmatique pour nous, le sujet était probablement très intéressant, mais même après avoir demandé qui utilisait l’outil, et constaté qu’environ 5 ou 6 mains se sont levées (sur les 600 personnes de la salle), Stof n’a pas jugé bon de présenter Behat, et a préféré enchaîner directement sur les nouveautés apportées par la version 3 qui sortira le 20 avril, et qui a été stabilisée juste avant le Symfony Live.

En se documentant un peu, il s’avère que Behat est un outil assez puissant d’intégration continue, focalisé sur les tests d’acceptation, qu’on peut facilement intégrer à Symfony puisqu’il peut être utilisé via les annotations.

Pas de slides disponibles à ce jour.

Site du projet : https://behat.org

Série de 2 articles (de 2012) sur l’installation et l’utilisation de Behat : https://blog.lepine.pro/php/behat-jour-1-comment-tester-son-produit-scrum & https://blog.lepine.pro/php/behat-jour-2-installation-et-premiers-tests

Faire de l’asynchrone en PHP ? C’est possible ! par Grégoire Pineau et Olivier Dolbeau

Le premier intervenant est un développeur de SensioLabs, le second est de chez BlablaCar.

Ils sont venus nous parler de l’intérêt de déporter certaines actions dans un sites web, présentées comme « immédiates » alors qu’elles sont traitées un peu plus tard. Le cas typique est l’envoi d’un e-mail pour un mot de passe oublié. Cela fait gagner en performance au serveur qui doit traiter la tâche et donne une impression de haute disponibilité à l’utilisateur. Evidemment il faut effectivement délivrer le message dans un temps raisonnablement court pour ne pas briser cette impression.

Cela nous amène naturellement au Advanced Message Queuing Protocol (AMQP) et les outils qui vont faire ce travail. On voit qu’il en existe une certaine variété (ActiveMQ, Apache Qpid, RabbitMQ etc.). L’outil retenu par les conférenciers est RabbitMQ.

Après un bref rappel du fonctionnement de l’outil (et du principe de AMQP), la conférence s’oriente évidemment sur comment intégrer tout cela dans une application PHP. Il apparaît vite que cela entraîne plusieurs difficultés en termes de fuites mémoire, performances, etc. Pour illustrer, ils nous présentent quelques outils créés qui ont déçu la communauté (en particulier phpamqplib qui subit un allumage en règle). Ils nous parlent donc d’un mini-projet qu’ils ont mis en place avant le Symfony Live pour nous monter pas-à-pas comment implémenter un worker PHP qui dépile un message AMQP.

Lien Github du projet : https://github.com/odolbeau/sflive2014-workers

Notes intéressantes :

  • Un for (;;) est plus rapide qu’un while (true)
  • Mettre le buffer_size à 50 dans la configuration de Monolog est une bonne pratique (quand on utilise un log « fingers_crossed »)
  • Pour eux, Symfony n’est pas la meilleure solution quand on fait de l’asynchrone en PHP (rires dans la salle)

Ils insistent eux-aussi également sur l’importance de bien monitorer une application en prod pour repérer les cas défaillants.

Enfin ils concluent en nous donnant le lien du projet Swarrot, une petite lib permettant de traiter des files d’attentes issues de RabbitMQ : https://github.com/swarrot/swarrot.

Slides de la présentation : https://speakerdeck.com/odolbeau/making-asynchronous-tasks-in-php

Comment construire un environnement e-commerce complet avec Symfony 2 ? par Fabien Gasser

Le présentateur travaille chez Smile et est un ancien de SensioLabs. Il se définit comme étant quelqu’un « passionné par le rap français et le e-commerce » (sa présentation s’en ressent beaucoup).

Il vient nous parler des solutions et bundles existants qui vont permettre de construire un environnement complet e-commerce avec un socle Symfony2. L’objectif est d’avoir une application robuste, rapide et attrayante pour donner envie au client de l’utiliser et de revenir fréquemment dessus.

Smile en chiffres, c’est :

  • Plus de 60 projets à > 250 jours
  • De multiples technos / CMS / frameworks (Magento, Drupal, Jahia, Symfony2, Spring…)
  • Une forte experience e-commerce avec la gestion de 10 millions de produits, des sites à fort trafic, des boutiques multi-sites, multi-canaux etc.

Il nous fait un topo complet sur les différents types de e-commerce, en ré-insistant sur l’importance de pérenniser le lien avec le client à moins « d’avoir un produit incroyable sans aucune concurrence ».

Il en vient donc à l’utilisation de Symfony 2, qu’il définit, en reprenant l’expression de Fabien Potencier lors de la keynote, comme « un standard du middleware PHP ». Il considère que que Symfony2 doit être le liant applicatif entre la boutique gérée par un outil spécialisé (Magento par exemple) et le reste des applications. Il est donc très important de bien séparer les choses. Par exemple c’est une mauvaise idée d’intégrer un blog au site e-commerce qui n’est pas prévu pour cela.

Il nous parle aussi du Minimum Viable Product (MVP), où l’application idéale qui offrirait à la fois juste ce qu’il faut en fonctionnalités pour satisfaire le client tout en gardant une bonne stabilité.

Il nous donne une série de recommandations pour l’utilisation de Symfony2 :

  • Découper l’application en petites briques et réduire le couplage.
  • Aller plus loin que l’architecture orientée services (SOA) et arriver à une architecture orientée web (WOA), avec tous les conseils qui vont avec (utilisation de REST, des microformats, de Varnish etc.)
  • Bien armer le socle technique avec les bons bundles, et adopter les bonnes pratiques.

Dans un souci de compétitivité, il est important de toujours rechercher les meilleurs outils pour les fonctionnalités qu’ils doivent satisfaire, d’où une veille permanente de ce qui se fait de mieux. Le reste de la conférence balaie d’ailleurs les bons outils du moment.

Slides de la présentation : https://fr.slideshare.net/w0arz/20140406-symfony2-ecommerce

Étendre Symfony, les bonnes pratiques par Jérôme Vieilledent

Très attendue, cette dernière conférence de la première journée est présentée par Jérôme Vieilledent, lead développeur chez eZ Systems, et qui a une très bonne expérience de ce qu’est « étendre Symfony », puisqu’il a activement participé au développement de eZ Publish 5 qui se base complètement sur Symfony2. Typiquement pour eZ, il a été nécessaire de sortir de l’ancien code, qui était certes robuste mais ancien et très difficile à maintenir.

Jérôme Vieilledent revient donc sur les bonnes pratiques et les pièges à éviter lorsqu’on souhaite ajouter des extensions à Symfony. La conférence est organisée en « astuces » :

  1. Configurer des bundles tiers depuis le sien : il nous explique comment ajouter de la configuration à un bundle développé par la communauté dans un bundle personnel en faisant la comparaison entre la méthode explicite et implicite en présentant leurs avantages et leurs inconvénients.
  2. Les service tags, ou comment étendre un service sans le modifier (cas pratique que nous utilisons souvent : les extensions Twig), illustré par un exemple de cache clearer.
  3. Les event listeners/subscribers, qui permettent de déclencher des actions et/ou modifier certains comportements (cas pratique que nous utilisons souvent aussi : les cycles de vie d’une entité qu’on va brancher aux évènements Doctrine). Il nous donne un panel d’events à utiliser dans nos codes et un exemple de subscriber.
  4. Etendre les services Symfony (sans les modifier 🙂 ) : à prendre avec des pincettes, bien adapté à des héritages simples, quand on a besoin de rajouter un simple paramètre par exemple. Attention à l’écueil consistant à vouloir constamment redéfinir les services des autres, le jour où ces autres modifieront leur service, il faudra faire très attention que les dépendances du nôtre ne sont pas rompues (utilisation des compiler passes). Une dernière solution consiste à utiliser des alias afin de substituer son service en lieu et place d’un service existant.
  5. Rendre soi-même son code extensible, car il est possible que quelqu’un d’autre veuille également étendre notre propre code pour ses propres besoins, autrement dit, suivre les mêmes pratiques que Symfony (utilisation de classes paramétrées, évènements, services tags, aliases…)

Pour l’anecdote, le conférencier s’est fait « stoffer » pendant sa présentation. En effet, Christophe Coevoet (Stof), est revenu sur le premier point où Jérôme Vieillement parle de l’extension implicite du bundle et présente comme inconvénient le fait de devoir vider le cache à chaque fois en debug mode lorsqu’on change la configuration du bundle. Il a posté une Pull Request en pleine conférence qui corrige ce point https://github.com/ezsystems/ezpublish-kernel/pull/791.

Slides de la présentation : https://lolautruche.github.io/ez/etendre-symfony.html

Mardi 8 avril

PHP optimisations et OPCache par Julien Pauli

Cette conférence très technique et pur PHP (et donc dure pour attaquer cette deuxième journée !) nous est présentée par Julien Pauli, de SensioLabs, mais également membre de l’AFUP.

Sa conférence commence par un rappel de comment PHP fonctionne, en particulier sa caractéristique « Fire & Forget » (le langage oublie immédiatement ce qu’il vient de traiter), et met en lumière le problème du processus « Compilation, exécution, oubli » que cela implique. Autrement dit, une page un peu complexe à compiler ou à exécuter, et qui sera appelée un grand nombre de fois, peut provoquer des problèmes de performances, surtout si ladite page produit toujours ou presque le même résultat. Intervient donc le cache, entre la compilation et l’exécution, qui va soulager un peu le serveur en renvoyant le résultat déjà pré-calculé.

De là, il propose également l’optimisation du code compilé (les OPCodes) afin de soulager encore un peu plus les temps de traitement, en repérant des opérations coûteuses pour les remplacer par d’autres équivalentes et plus performantes. Plusieurs exemples commentés sont donnés dans les slides.

Il arrive ainsi à OPCache, qui est le cache OPCode précédemment décrit. Il est disponible depuis PHP 5.3, et embarqué avec le langage depuis la version 5.5. OPCache est à la fois un gestionnaire de cache et un optimiseur de code. Jusqu’ici, beaucoup utilisent le cache APC, qui, s’il est très bien pour le cache, n’optimise pas le code. Julien Pauli propose donc de le remplacer par OPCache.

Il termine sa présentation avec un survol détaillé des possibilités de configuration d’OPCache.

Slides de la présentation : https://fr.slideshare.net/jpauli/yoopee-cache-op-cache-internals

Du SSO via OAuth pour mieux découpler votre application par Matthieu Moquet

Le présentateur Matthieu Moquet travaille chez BlablaCar, et revient sur son expérience de refonte complète de l’application web de BlablaCar (site de mise en relation de personnes souhaitant faire du covoiturage), depuis une grosse base de code monolithique. Ils ont profité de l’opportunité pour découpler complètement l’application.

Il revient sur les éternelles questions qui surviennent lors du lancement d’un tel projet from scratch, parmi lesquelles :

  • 1 ou N bundles ?
  • Les contrôleurs ont-ils accès aux repositories ?
  • Comment organiser ma couche métier ?
  • Dois-je mapper mes entités aux formulaires ?
  • Comment gérer les traductions ?
  • Etc.

Il explique qu’ils n’ont pas eu accès de suite à un designer à plein temps, et que donc la solution de secours fût Bootstrap 2. Leur autre problème fut de devoir sortir une application vite, ils ont donc dû embaucher pour avoir plus de main-d’œuvre, en gardant bien à l’esprit que plus de développeurs implique plus de code, donc un projet bien plkus volumineux, avec les contraintes que cela implique : tests unitaires vite monstrueux, vidage de cache lents, déploiements interminables. Ils ont donc commencé par paralléliser les tâches (en utilisant le cloud Amazon). Il attire également notre attention sur le fait un gros projet rend l’équipe moins réactive, et nous parle de Facebook qui est passé sous Mercurial suite aux mêmes problématiques (https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook).

Il s’interroge ensuite sur le coût d’un changement en profondeur des outils. Le framework backend ? Celui de tests ? L’ORM ? Le framework frontend ? Tout cela revient cher, et il faut limiter la dette technique. Tout comme dans la présentation Fabien Gasser de la veille, il recommande de découper l’application de façon la plus atomique possible.

Il préconise ainsi 3 modèles d’architecture :

  • Le classique Request-Response, accès aux ressources de manière synchrone, cependant un serveur frontend ne devrait pas accéder à la base directement, d’où l’intérêt de mettre en place des API, il propose REST, SOAP, XML-RPC, etc.
  • Command, on envoie des ordres sans attendre de réponse, pour des traitements asynchrones (envois de mails, indexation de données…), il nous parle de RabbitMQ et plus globalement des systèmes de gestion de files de messages.
  • PubSub, ou le système d’event dispatcher (observeur / observable) auquel Symfony se prête facilement. On peut l’utiliser avec des systèmes comme Haddop ou ElasticSearch Kibana par exemple.

En faisant le point sur ces trois architectures, RabbitMQ supprime le lien entre les services (dans les trois cas) : c’est ce qui est recherché.

Il continue sa présentation en détaillant comment ils ont réutilisé tous ces éléments chez BlablaCar pour découpler l’application au maximum :

  • Backoffice
  • Authentification avec OAuth et le FosOAuthServerBundle (passage de Ldap à OAuth en remarquant au passage qu’il existe des bundles pour les deux)
  • Renforcement de la sécurité avec un panel de bundles adéquats, utilisation de SSO etc.

Actuellement, le cœur d’application est ainsi léger, la suite de tests aussi. Il conseille de bien choisir ses outils et de ne pas hésiter à faire des expériences (en effet cela est rendu possible par le découplage, une expérience malheureuse ne cassera pas l’ensemble de l’application, mais uniquement la brique qu’elle affecte).

De la même manière qu’Olivier Mansour et M6, il préconise de réutiliser ce qui fonctionne, afin d’avoir très rapidement un environnement adapté pour toute nouvelle application.

Il conclue sa présentation avec un petit projet personnel, qu’il a mis en place pour BlablaCar, et qui permet de gérer les traductions directement depuis l’interface admin (un peu comme sur un CMS) : openl10n (https://github.com/openl10n/openl10n). Le projet sera bientôt mis en open source sur https://openl10n.io.

Slides de la présentation : https://speakerdeck.com/mattketmo/decoupling-your-application

Docker par l’exemple, une application Symfony2 multi-containers par Geoffrey Bachelet

Le présentateur est chez Stage1, c’est un ancien de KnpLabs. Il vient nous parler de Docker, ce que c’est et comment ça fonctionne.

Après avoir présenté grossièrement Docker comme un ensemble de petites VMs, il s’empresse de nous faire oublier cette idée en comparant le système classique VMs + Hyperviseur lourd à Docker et ses petites VMs Unix légères.

Il nous fait une passe sur l’installation d’un tel système sur une machine hôte Unix et la création de notre premier container. De là il met en place une série de containers Docker qui vont permettre d’exécuter n’importe quelle (ou presque) application Symfony., quel que soit l’environnement dans lequel on doit la déployer.

Il nous explique alors comment paramétrer son application Symfony pour pouvoir l’utiliser ainsi, avec une démo en live pendant la conférence.

Mini-projet de démo : https://github.com/ubermuda/sflive-docker

Slide de la présentation : https://speakerdeck.com/ubermuda/a-multi-container-symfony2-setup-with-docker

Gearman – big data without Hadoop par Guillaume Cavana

Responsable technique chez Lafourchette.com, Guillaume Cavana est venu nous parler des problématiques liées aux très gros volumes de données, comme il a pu en rencontrer sur l’application Lafourchette.

Il commence par faire un peu de pub pour sa boîte créée en 2007, et les besoins que l’application qu’ils fournissent doit satisfaire. Apparaît presque immédiatement le mot « Big data », qu’il nous définit. Ils doivent y faire face chez Lafourchette devant le nombre d’utilisateurs de plus en plus croissant (4000 à 10000 utilisateurs simultanés), et l’afflux massif de données en base (il nous parle en Péta-octets…). Beaucoup de données va impliquer des ralentissements pour tout accès à celles-ci.

Il en vient, comme les autres conférenciers avant lui qui ont traité le sujet, à nous parler de traitements asynchrones. Les solutions sont multiples, on y retrouve Hadoop, RabbitMQ, quelques outils obscurs et… Gearman.

Il fait un balayage des multiples technos qui vont être amenées à se confronter à du Big Data, et nous présente des (grosses) entreprises qui sont amenées à traiter de gros volumes de données. On citera Yahoo, Digg, Amazon…

Après in slide sur les cas d’utilisation, présentation de Gearman, son installation comme deamon et module PHP, et son utilisation dans le code.

Il existe une interface de monitoring pour voir l’état des jobs.

Bien évidemment quand vient la question de Symfony, le fameux « There is a bundle for that » intervient 🙂 (https://github.com/mmoreram/GearmanBundle). Son intégration au framework est bien faite, et utilise les annotations et des évènements spécialisés.

Le mini projet de démo pour la conférence : https://github.com/eljam/symfony-live-2014-gearman

Les slides de la présentation : https://speakerdeck.com/eljam/gearman-big-data-without-hadoop

La Migration continue vers Symfony: l’agilité sans feuille blanche par François Zaninotto et Simon Rolland

Simon Rolland est chef de projet technique chez 20minutes, François Zaninotto est lui CEO chez Marmelab, c’est un ancien de SensioLabs.

Placée astucieusement au premier slide, la date naissance de François Zaninotto est le 8 avril 1974, il fête donc ses 40 ans aujourd’hui, 600 personnes entonnent un « Happy birthday »…

Le sujet de la conférence porte sur la migration de 20minutes (PHP + Symfony1) vers un nouvel SI basé sur des technos récentes. Il y a 1,4 million de lignes de code à migrer vers un CMS propriétaire, Etna, basé sur Symfony2, avec une deadline à 6 mois, l’enjeu a donc été de ne pas la repousser sans cesse.

Sur un ton léger, François Zaninotto évoque les scénarii catastrophe que l’on risque lors d’une migration de cette ampleur :

  1. La migration qui n’en finit pas : 20minutes est constitué de multiples petites applications, se mettre dans une optique d’attente que la migration de l’appli N pour lancer celle de l’appli N+1, dans le but de tout avoir migré avant d’éteindre le système, repousse le délai à 24 mois.
    => En fait le système n’est jamais éteint, du moins pas avant la deadline, il faut privilégier les applications prioritaires, ou migrer des portions d’applications.
  2. L’effet tunnel : le nouveau système est tellement différent de l’ancien que les développeurs vont s’y consacrer à fond, laissant l’ancien en l’état, sans évolutions. Le jour de la mise en production, les utilisateurs découvrent une nouvelle appli, forcément un peu bugguée, et comme ils n’avaient rien vu pendant 6 mois, l’ancien système paraît mieux que le nouveau.
    => Il faut impliquer les utilisateurs pour répondre aux bons besoins, et intégrer sous forme d’évolutions les premières réponses à leurs attentes dans l’ancien système, pour limiter cet effet tunnel. Les premières mises en production doivent arriver très vite pour avoir rapidement des premiers retours et réajuster au besoin. La priorité sera donnée dans tous les cas au bénéfice utilisateur.
  3. Les mises en production ratées, et l’empilement de versions : On met en production avec un modèle de données tout neuf, mais celui-ci nécessite un import de données très important. Cela donne lieu à la prise de conscience de cas particuliers non gérées par l’import, mais auquel l’ancien système répondait. On corrige le bug et on réimporte (avec le temps de latence que ça implique). Mais entretemps, les utilisateurs ont commencé à utiliser le nouveau système, donc il faut créer un script d’export sans quoi les modifications seront perdues. Au final, on se retrouve avec un système non opérationnel 2 jours par semaine pendant 2 mois.
    => Ne pas attendre le dernier moment pour commencer à migrer les données. Partir du principe que les données initiales sont en mauvais état et que chaque script d’import est susceptible d’être rejoué plusieurs fois (même si vous n’en voyez pas l’intérêt au premier abord)

Ces trois scénarii comportent la même erreur de base, celle de penser que la migration sera ponctuelle alors qu’elle aura lieu dans le temps (l’effet « Bouton rouge »). Les deux conférenciers s’attachent alors à nous définir la migration continue, ils nous parlent de scrum et d’itérations et de la nécessité de migrer à chacune d’elles. Ils préconisent également d’associer le métier avec la migration, afin d‘avoir un ensemble cohérent qui ne change pas à chaque itération, mais évolue. Ils insistent également sur la perception utilisateur, qui doit sentir qu’il y a du changement, afin de ne pas subir la migration comme quelque chose de coûteux, long et sans intérêt.

Ils reviennent sur le découplage et l’aspect SOA que devra adopter la nouvelle application, insiste sur le fait que durant tout le processus de migration, les deux systèmes doivent pouvoir être utilisés en parallèle, comme s’ils ne faisaient qu’un. Au niveau graphique, ils proposent de migrer les éléments de page un par un, et de ne pas attendre que tout soit prêt pour migrer la page d’un coup, cela prend trop de temps.

Le découplage doit aussi avoir lieu entre les migrations, une migration ne DOIT PAS être dépendante d’une autre.

Aussi bien qu’au niveau logiciel, la nouvelle infrastructure qui va supporter la nouvelle application doit également être évolutive, un socle figé va constituer un carcan qui limitera les possibilités. Il faut également être un peu plus tolérant vis-à-vis des pannes, avoir une trop haute exigence quant au taux de disponibilité repousse mécaniquement la deadline.

Enfin ils conseillent d’échantillonner la production, car certains cas d’erreurs n’apparaitront qu’avec des données réelles, eux aussi nous parlent de monitoring avancé pour surveiller les comportements de l’application.

En conclusion, ils nous disent que la migration continue d’un SI important dans un délai très court est possible, il suffit d’être agile. François Zaninotto nous dit que « l’agilité nous apprend que quand ça fait mal il faut le faire plus souvent » 🙂

Même si cette conférence pouvait paraître à des années-lumière du thème général et de Symfony, elle était vraiment passionnante, ponctuée d’exemples concrets permettant à chacun de pouvoir s’identifier dans ce sujet que nous avons pu rencontrer à un moment ou l’autre.

Slides de la présentation : https://fr.slideshare.net/francoisz/la-migration-continue-vers-symfony

Retour d’expérience Motoblouz – Multi-sites et Routing par Alexandre Salomé

Le conférencier est consultant technique chez SensioLabs et vient nous parler de son retour d’expérience sur le site Motoblouz (https://motoblouz.com) conçu en Symfony2. Il a dû décliner le site en plusieurs marques, elles-mêmes en plusieurs langues, et chaque marque / langue comportait ses propres spécificités.

Cela implique :

  • Des URLs différentes (langue : inscription / registration par exemple)
  • Des vues différentes (un thème lié à la langue d’affiche, à la marque…)
  • Des comportements différents (inscription non disponible pour une langue, pas de mail de contact dans un autre…)

De là deux stratégies sont envisageables :

  • Un site = une application, avec des bundles transverses communs à toutes les applications (UserBundle…). Le principe est simple, mais la mise en pratique pénible
  • Multi-site, avec un seul dépôt, c’est bien sûr celle-ci qui sera retenue

Alexandre Salomé nous présente alors son MultisiteBundle (https://github.com/alexandresalome/multisite-bundle), son installation, sa configuration, des exemples d’utilisation via les annotations, dans Twig… Il nous montre comment initialiser le bootstrap de l’application avec les multi-sites.

Dans une seconde partie, il nous explique comment étendre le routing, pour cela, il s’est inspiré du JMSI18nRoutingBundle (https://github.com/schmittjoh/JMSI18nRoutingBundle).

Au final, on se retrouve avec une implémentation élégante du multi-sites avec peu de code, en utilisant la logique fournisseur/consommateur.

Slides de la présentation : https://github.com/alexandresalome/multisite-bundle/blob/master/slides.pdf

Symfony2 et Microsoft Azure, l’efficacité de PHP dans le cloud par Stéphane Escandell et Jérôme Respaut

La présentation est faite par deux employés de chez BrainSonic. Le premier est chef de projet, le second lead développeur. Ils viennent expliquer comment concilier deux technos à la mode, d’une part Symfony2, de l’autre la plateforme Cloud de Microsoft qui offre une palette de services en mode PaaS (Plateforme As A Service).

De prime abord, ils sont accueillis par une certaine réserve par l’assistance.

Après avoir rapidement présenté leur boîte, ils reviennent sur Azure, et les possibilités que la plateforme nous offre, puis comment développer et intégrer une application Symfony2 pour la déployer en mode PaaS dans Azure.
Parmi les choses à mettre en place :

  • Mise en œuvre de Webrôles
  • Utilisation de Microsoft Azure Storage avec SQL Azure et stockage sécurisé via les Blob Storage

Pour ce qui est de l’application Symfony, elle va reposer essentiellement sur du REST et utiliser leur bundle maison AzureDistributionBundle (https://github.com/brainsonic/AzureDistributionBundle).

En résumé, leur approche essaie de tirer le meilleur parti de deux mondes très différents en créant donnant la possibilité d’intégrer la communauté Symfony2 dans la sphère Microsoft.

Slides de la présentation : https://fr.slideshare.net/stephaneesc/symfony-live-paris-2014-symfony2-sur-azure

Ma première one page app avec une api REST hateoas symfony et un front ember.js par Cédric Lombardot

Le présentateur est un associé de la société Youcare, il est venu nous montrer comment, grâce à Symfony et le FosRestBundle, on peut réaliser facilement une API REST HATEOAS documentée et protégée par un OAuth2, le tout accessible dans une one page app construite grâce à Ember.js.

Il commence par nous parler de l’évolution continue des supports et des technologies, que nous avons à présent une multitude de systèmes différents, ce qui peut rendre l’accès à une application difficile si elle n’est pas compatible. Il parle d’Apache Cordova pour créer des applications mobile, nous laissons les partisans du développement natif se faire une opinion sur la question…

Nous apprenons au passage qu’Apple fait toujours des validations manuelles des applications soumises sur le store. Il semble trouver cela archaïque, mais beaucoup de gens dans la salle sont d’accord avec le principe (moi aussi 🙂 ).

Arrive le sujet de Symfony, le présentateur nous donne la liste des bundles « à avoir dans la poche » :

Pour son application à proprement parler, il part d’un cas pratique de gestion de bibliothèque pour l’exemple. Le reste de la conférence nous montre comment l’application est développée.

En complément de cette conférence, on peut lire l’article de l’AFSY publié pendant leur calendrier de l’avent 2013 (utilisation du framework Javascript AngularJS) : https://afsy.fr/avent/2013/16-symfony-et-angularjs-tips.

Slides de la présentation :
https://docs.google.com/presentation/d/1BljEywaZog7ZpcHhnH9zcE1CXog1IPEO_nUvvXItbvc/present

Ingénierie inversée du composant « Form » par Sarah Khalil et Hugo Hamon

Pour une des conférences sans doute les plus attendues, ces deux employés de SensioLabs sont venus nous parler du composant Form de Symfony2. Pas seulement de son utilisation comme on peut le retrouver dans la documentation, mais bien sa mécanique interne.

Ils commencent par une rapide présentation du composant en chiffres, pour nous rappeler son importance en terme de code et de complexité, puis nous rappellent ses dépendances et comment le récupérer sur Github.

On a ensuite un exemple très simple de formulaire avec 3 champs dont ils nous donnent le code (objet métier, form type et contrôleur. Ils nous détaillent alors tout ce que Symfony va manipuler avant de nous rendre le formulaire dans la page (arborescence détaillée des types).

Ils reviennent alors sur la construction du formulaire en lui-même. Ils commencent par la notion de type et nous montrent que chaque type de formulaire est en fait un service avec le tag « form.type » (par exemple form.type.date). Ils attirent ensuite notre attention sur le fait que la structure des types comporte deux types d’héritage :

  • L’héritage statique, dans le code, où le type hérite de AbstractType qui implémente FormTypeInterface.
  • L’héritage dynamique, en utilisant la méthode getParent() pour définir explicitement un type parent (par exemple le type Birthday va étendre explicitement Date).

Ils nous détaillent ensuite ce qu’il se passe exactement au sein du framework lorsqu’on appelle $this->createForm() dans le contrôleur, notamment la résolution de type, ils nous affichent ce qu’instancie exactement Symfony pour le type Birthday (dans l’exemple donné).

Ils en profitent pour nous rappeler que le débuggage de formulaire est présent dans l’environnement de développement.

Ils reviennent au détail de la mécanique du $this->createForm() avec le FormBuilder, qui est chargé de construire et configurer l’objet formulaire. De là, ils nous montrent comme il est facile d’injecter des valeurs par défaut avec la méthode setData() via un objet métier. De là nous avons le récapitulatif du cheminement de construction du formulaire de la factory d’instanciation jusqu’au rendu.

Nous arrivons à la normalisation des données. Nos conférenciers identifient 3 représentations :

  • Les « Model Data », celles qui sont directement issues du modèle de données
  • Les « NormData », données normalisées pour permettre leur conversion dans un autre mode représentation
  • Les « View Data », les données destinées à l’affichage final

Pour normaliser les données, deux règles sont à respecter :

  • Enrichir au maximum les données normalisées
  • La donnée ne doit pas être altérée en terme de contenu, seule sa représentation change. Par exemple, une date en format YYYY-MM-DD sera transformée en DateTime avec la bonne valeur.

Ils nous détaillent le passage Model Data => NormData > View Data, qui intervient entre les événements PRE_SET_DATA et POST_SET_DATA par le biais de DataTransformers. Le focus leur est donné aux slides suivants avec un détail d’implémentation sur l’exemple du début (convertir un tableau de strings (tags de l’article) en string séparé par des virgules) et son intégration au form builder. Ils en profitent pour nous rappeler les DataTransformers déjà embarqués par le composant.

Ils terminent avec la soumission des données du formulaire, nous nous intéressons à la méthode handleRequest() (anciennement submit() (et bind()…) qui est dépréciée). Cela instancie le HttpFoundationRequestHandler qui vérifie la conformité de la soumission avec le type de requête prévu, récupère toutes les données soumises (GET / POST / FILES) et les passe à Form::submit(). Ils nous détaillent l’opération inverse de dénormalisation des données afin de pouvoir les traiter. Ils complètent le DataTransformer de l’exemple avec la méthode reverseTransform(). Enfin ils nous parlent des événements qui jalonnent tout ce traitement de formulaire, avec des exemples d’utilisation.

Slides de la présentation : https://speakerdeck.com/hhamon/ingenierie-inversee-du-composant-form-de-symfony

Comment développer un helpdesk pour gérer des millions d’utilisateurs avec Symfony & Amazon dynamoDB par Gilles Guirand

Cette conférence était la dernière, malheureusement, nous n’avons pas été beaucoup à y assister, faute de temps et les impératifs dûs à nos trains, et les slides ne sont pas encore disponibles.

Cet intervenant, co-fondateur de Kaliop, est venu nous parler de son retour d’expérience sur un projet de grande ampleur, UNIVADIS (portail mondial pour professionnels de santé). Les problématiques majeures ont été l’énorme volumétrie de données à gérer, qui changent selon la législation des pays pour lesquels l’application est disponible, et les temps de réponse raisonnables, même à des moments de forte charge.

Pour cela, il revient sur l’architecture « légère » mise en place avec Symfony et Amazon DynamoDB. Ils ont utilisé un modèle entity / repository pour DynamoDB (en remplacement de Doctrine).

Quelques infos supplémentaires sur leur blog : https://blog.kaliop.com/blog/2014/03/04/amazon-dynamodb