18
JUIN

Retour sur le Symfony Live - Jour 2

Publié le 18/06/12 à 09h24 par Skwi

Voilà le deuxième et dernier article de notre visite au Symfony Live, n'hésitez pas à aller consulter le premier. Comme pour ce dernier, les slides sont disponibles sur joind.in

Symfony Live 2012

Designing HTTP interfaces and RESTful Web Services - David Zülke

Ce deuxième jour commence avec une session plénière avec David Zülke. Ce n'est surement pas un hazard, tant son aisance à animer sa conférence n'avait d'égal que l'intérêt que l'audience portait au sujet. Même les moins cafféinés d'entre nous n'ont eu aucun mal à suivre.

Il a d'abord fait un rapide rappel sur l'évolution des WebServices et sous quelles contraintes celle-ci s'est faite, ainsi que les problèmes que ces changements ont engendré.

Partant d'un exemple, il est progressivement monté, amélioration après amélioration, vers une vrai API REST :

- Architecture client/serveur
- Stateless, jamais une API rest ne doit se souvenir du client (cookies...)
- Cachable
- On peut la découper en couches (par exemple, on doit pouvoir rajouter varnish sans souci)
- Interface uniforme

L'interface uniforme, souvent le point faible des API que l'on trouve fréquemment, se fait sur plusieurs plans.

Le principal à mettre en place est le formatage homogène des URL, l'utilisation des verbes HTTP (GET, POST, PUT, DELETE) et des code de status (200, 404, ...) et surtout les hypermédias.

L'un des principes phares d'une bonne API REST est la construction sous le principe HATEOAS : hypermedia as the engine of application state.

Les hypermedias (ex: atom) sont des définitions qui indiquent que faire avec la resource présentée, comment la comprendre, quelle est la prochaine opération. C'est plus ou moins la "documentation" des ressources servies.

David s'est rapidement penché sur le choix de JSON ou XML dans un webservice, pour finalement conclure que les 2 ont leur intérêt, JSON pour sa légèreté, XML pour sa rigueur.

On peut généraliser en disant qu'il est conseillé d'utiliser XML lorsqu'un tiers entre en jeu, alors que JSON, moins sur, est plus adapté quand on contrôle client ET server.

Pour en revenir aux hypermedias, ils sont un moyen d'avoir une API claire, maintenable et évolutive sans impacts pour les clients. Tout bon webservice REST doit les utiliser s'il souhaite être pérenne.

 

Symfony Live

Crédit photo Emmanuel Vella

 

Advanced Service Container Utilization - Richard Miller

On enchaine avec une conférence technique sur l'injection de dépendances où l'on va apprendre à mieux utiliser le Service Container.

Après quelques exemples des différentes options offertes par le Service Container, on entre dans le vif du sujet : Gagner du temps en écrivant moins de configuration.

Même si l'injection d'interface semble une bonne idée pour optimiser la configuration, elle n'est techniquement pas implémentable. En revanche, il existe une alternative : les services parents. 

Les services parents permettent de découpler et surcharger plus facilement les classes du service container, tout en réduisant les répétitions de configuration.

La souplesse par rapport au concept d'injection d'interface réside dans la possiblité de se séparer à tout moment de la classe parent pour avoir une implémantation propre au fils.

Richard a ensuite abordé le sujet des multi-containers dans le cas par exemple d'un projet avec bundles. Il s'est penché sur l'ordre de compilation et le dumping et caching du container.

 

There is a bundle for that - Christophe Coevoet, Lukas Kahwe Smith

On poursuit avec une conférence au nom familier, animée par Christophe Coevoet (aka stof) et Lukas Kahwe Smith.

Vous l'aurez deviné, l'objectif de cette session est de promouvoir l'utilisation de Bundles.

Les Bundles sont un moyen de ne pas réinventer la roue. La plupart sont recensés sur knpbundles.com (index non officiel). Le système de points proposé par le site permet de se rendre compte de la qualité et de l'adoption d'un bundle. On gagne des points en écrivant des tests (et quand ces test passent sur Travis), en rédigeant la doc, ....

Quelques conseils lorsque l'on crée un bundle :

- S'assurer qu'il n'existe pas déjà un bundle existant faisant la même chose
- Injection de dépendances : utiliser l'alias du bundle comme préfixe, définir explicitement les paramètres de configuration, utiliser les CompilerPass pour interagir avec les autres containers
- Utiliser Composer pour gérer les dépendances du Bundle, et ajouter le Bundle sur Packagist
- Ecrire des tests (utiliser JMSCommandBundle pour générer un Kernel de tests fonctionnels indépendant)
- Utiliser Travis-CI pour lancer des tests automatiques et multi-plateforme des Bundles Open Source

Les bundles recommandés par Christophe et Lukas :

- FOSUserBundle pour la gestion d'utilisateurs (non lié à l'authentification)
- JMSExtraSecurityBundle (présent de base dans Symfony) offre des options supplémentaires au composant sécurité
- FOSRestBundle pour construire plus facilement des API
- JMSSerializerBundle pour sérialiser/désérialiser des Objets et graphes d'Objets
- StofDoctrineExtensionBundle pour ajouter des fonctions telles que timestampable, sluggable, etc aux entités
- KnpMenuBundle pour construire des menus à partir d'objets
- LiipImagineBundle pour manipuler la librairie imagine depuis twig

La session se termine par une petite démo où un membre de l'audience choisi une fonctionnalité et les 2 animateurs montrent la marche à suivre pour rechercher un Bundle adéquat et l'implémenter.

 

Symfony Live

Crédit photo Nicolas Hachet

 

Behat by example - Konstantin Kudryashov

Après la pause déjeuner, la journée reprends sur une conférence très attendue : Behat by example.

Konstantin annonce la couleur d'entrée de jeu, cette session n'a pas pour objectif d'apprendre à coder des tests Behat, mais plutôt à saisir l'esprit des tests de comportement et la façon dont ils doivent être rédigés.

Le but de Behat n'est pas de faire des tests fonctionnels mais de vérifier qu'une application respecte bien les besoins métier du client.

Ce n'est pas un outil destiné à apprendre au client à faire des tests, mais plutôt à faire comprendre au développeur ce dont son client à réellement besoin.

D'ailleurs même quand le client ne sait pas vraiment ce dont il a besoin, Behat permet de mettre les choses à plat et éliminer ce qui est plus de l'aspect de l'envie que de la nécessité.

Konstantin montre alors avec quelques exemples bien choisis des tests Behat rédigés dans une approche développeur qu'il corrige progressivement pour être plus proche des vrais besoins.

On peut en retirer quelques bonnes pratiques :

- Toujours bien identifier qui va bénéficier de la fonctionnalité testée
- Ecrire le test avec un niveau de technicité adapté à ce bénéficiaire
- Garder un style narratif, ne pas trop rentrer dans les détails (inutile par exemple de tester chaque champ d'un formulaire)

Behat est compatible avec plusieurs langues (on peut facilement récrire les instructions), il ne faut pas hésiter à l'utiliser dans la langue qui permet un meilleur échange avec le client.

 

Symfony2 CMF - Lukas Kahwe Smith

Symfony 2 CMF est un projet encore en développement (l'alpha 1 est sur le point de sortir). Son objectif n'est pas de créer un nouveau CMS, d'autres sont déjà très bien (petit clin d'oeil à Drupal 8 qui intègre des composants Symfony). L'idée est plutôt de remixer Symfony à l'aide de différents bundles pour créer un framework servant de base au développement de CMS.

Contrairement aux CMS qui sont un casse tête à "bidouiller", le Symfony CMF a vraiment pour cible les développeurs. 

Plusieurs parties du framework ont été remaniées. Le routing de base de Symfony est remplacé par un routing plus dynamique, généré automatiquement à partir de la base de données.

L'autre gros morceaux est la couche d'accès au model remplacée par PHPCR (inspiré du module java JCR), un "content repository" composé d'un mix entre une base de données par fichiers (type MongoDB) et une base de donnée sous forme d'arbre XML. Ce type de stockage de données est plus adapté qu'un SQL aux besoins d'un CMS par sa façon d'organiser l'information et sa souplesse pour versioner le contenu.

Même si le CMF n'est pas encore finalisé, quelques fonctionnalités intéressantes ont déjà été implementées :

- Caching et invalidation automatique du cache quand le contenu est modifié
- Le menu est totalement dynamique, il se met à jour avec le contenu
- Le choix a été fait de ne pas utiliser d'internationalisation, mais de pouvoir fournir du contenu dans différentes langues (avec fallback)
- Les système de tag peut être "entrainé" à comprendre les textes pour suggérer de nouveaux tags

La présentation était beaucoup tournée sur l'aspect démo. Je vous invite à tester directement sur http://cmf.liip.ch/fr pour vous faire une idée de ce que peut faire le framework à l'heure actuelle.

 

Symfony Live

Crédit photo Jacopo Romei

 

Agile and Symfony 2 - David Buchmann

On finit ces 2 jours de conférences de façon moins technique. Le sujet est tout de même très intéressant puisqu'il s'agit de savoir profiter des possibilités de Symfony dans un contexte de gestion de projet Agile.

David commence donc sa session sur une rapide présentation des méthodes agiles et la façon dont ils les ont mises en place chez Liip, la société où il travaille.

Puis vient le vif du sujet, Symfony. Il faut savoir qu'avec son architecture très bien découplée, le framework s'adapte au travail en mode agile, chaque développeur pouvant s'occuper de sa tache sans trop craindre d'impacter les autres développement.

Au niveau des tests, l'utilisation de LiipFunctionnalTestBundle est conseillée. Il propose un ensemble d'outils (mockups des services du container, mise en place d'une base de test, chargement de fixtures ...) permettant d'isoler les composants développés et les tester séparément.

Avoir un coverage de 100% n'est pas le but des tests. Le véritable objectif est de tester les bonnes fonctionnalités pour qu'aucun bug ne soit introduit par erreur en production, et que les développeurs n'aient pas d'hésitation pour modifier un bout de code.

La couverture doit tout de même être importante sur les librairies réutilisables et les composants qui font le coeur de l'application.

Si possible, il faut prévoir une intégration continue sur un environnement iso-prod.

Les migrations Doctrine introduites dans Symfony 2 sont également parfaites pour le développement agile. Elles permettent de gérer de façon très simple le refactoring du modèle, en conservant toujours un historique de la base.

Lorsqu'on modifie le modèle, il ne faut pas utiliser les commandes doctrine:database:drop et doctrine:database:drop qui perdent toute l'information des différentes versions de la base, mais l'ensemble des commandes doctrine:migration:* qui sauvegardent un historique

Dernier point important, le déploiement. L'upload d'une nouvelle version via FTP ou SFTP doit être proscrit. L'utilisation du contrôleur de code source est une bonne alternative, mais la solution conseillée est de créer des packages (debian, rpm, fpm, ...) pour déployer les applications. C'est simple, sûr, et reproductible. La gestion des dépendances avec Composer est encore une fois recommandée.

Pour conclure, on se trouve dans de bonnes conditions de développement agile lorsque l'on peut oser changer les choses, sans craindre de casser l'existant.

 

Lightning talks

L'événement de terminera pas quelques Lightning Talks où ceux qui ont un projet à présenter auront l'opportunité d'en faire part à toute l'audience, en 7min chrono.

Personne n'a baraguiné de chtite phrase pour le moment !


Ajouter un Commentaire

Pour poster un commentaire, vous devez être identifié. Vous pouvez choisir parmi ces trois méthodes d'identification:

Compte la Ferme du Web

Identifiez-vous
Inscrivez-vous

Compte Facebook

Connexion avec Facebook

Compte Twitter

Connexion avec votre compte twitter
Rechercher sur la Ferme du web