Symfony Live 2019, on vous dit tout : JOUR 2

Technique

5 avr, 2019

Nous sommes de retour, pour vous raconter la suite de nos aventures en ce deuxième jour du Symfony Live. En espérant que vous n’ayez pas raté notre débrief du premier jour.

#Open source, renouveau de l’Humanisme – Jérôme Vieilledent

visuelsymfony21 Symfony Live 2019, on vous dit tout : JOUR 2

Jérôme vient nous parler d’un sujet non technique, mais qui est autant voire plus important même. Nous vivons dans un monde où il faut se rappeler que les valeurs humaines sont plus importantes que tout, et que chaque individu peut contribuer au collectif.

C’est en réalité un cercle vertueux, l’individu trouve le bonheur en se sentant utile au collectif et le collectif se sent avancer grâce aux individus. La connaissance est libre, partageable à l’infinie et c’est ce qui fait avancer l’humanité. C’est de là que sort l’open source.

Le travail communautaire, le partage des points de vue, l’esprit de partage… La connaissance libre rend libre. Pour entretenir ce cercle vertueux, chacun doit pouvoir trouver sa place et se sentir utile, à travers des vrais projets de fond et ne pas hésiter à participer, à tenter des choses et faire avancer le collectif.

Chez DISKO, nous sommes très attentifs à cela. Chez nous, tout le monde à le droit à la parole. Chacun est libre de ses choix et peut participer à l’évolution de l’agence. C’est une de nos valeurs, l’innovation.

#Doctrine en dehors des sentiers battus – Romaric Drigon

Au-delà des rappels de base sur Doctrine (notions de relations propriétaires et inverses, d’unidirectionnalité et de bidirectionnalité…), nous retiendrons quelques tips pour améliorer les performances de l’ORM, comme :
– changer le mode d’hydratation (on peut par exemple préférer l’hydratation en array à l’hydratation en objet, qui reste très lourde, surtout avec des objets associés),
– diviser le processus d’hydratation en plusieurs requêtes (multi step hydratation),
– utiliser les partial objects, avec parcimonie (attention aux optimisations prématurées, don’t be STUPID !)
– filtrer les requêtes avec Criteria

Ou encore des fonctionnalités intéressantes et pourtant parfois peu utilisées, comme :
– les lifecycle callbacks lorsqu’on a besoin d’effectuer certaines actions avant l’insertion d’une entité par exemple,
– les embeddables, permettant de réduire la duplication de code et de mieux séparer les concepts à travers des classes qui ne sont pas à proprement parler des entités mais qui restent tout de même requêtables.

A tester également : le bundle Doctrine-stats, qui permet d’obtenir davantage d’informations sur les performances de Doctrine que celles communiquées par défaut par le profiler de Symfony.

Pour retrouver la présentation, c’est par ici : Speakerdeck.com/romaricdrigon

#Leçon N° 139, API Platform ce n’est bon qu’à faire un POC, FAUX ! – Grégoire Hébert

symfonylive22 Symfony Live 2019, on vous dit tout : JOUR 2

Nous n’allons pas nous attarder très longtemps sur la présentation de Grégoire, bien qu’elle soit intéressante car il nous présente comment fonctionne théoriquement et techniquement API plateforme.

Il serait dommage de ré-expliquer ici ce qui est déjà bien expliqué sur le site d’API palteform et sa présentation.

Chez DISKO, nous restons attentifs à l’avancement de cet outil.

#Symfony HttpClient, what else? – Nicolas Grekas

symfonylive23 Symfony Live 2019, on vous dit tout : JOUR 2

Nicolas nous présente une nouvelle feature de Symfony. Depuis décembre, il travaille sur ce nouvel élément qui a pour but de remplacer Guzzle. Beaucoup de différences entre les HttpClient et Guzzle (abstraction, gestion des headers simplifiée, des options supplémentaires etc).

Le mieux est de regarder les slides de Nicolas : Speakerdeck.com/nicolasgrekas

#Voyage au coeur de React-admin, l’admin generator d’API Platform – François Zaninotto

symfoylive24 Symfony Live 2019, on vous dit tout : JOUR 2

François souhaite nous séduire par le coeur et la raison avec son code javascript.

React-admin est une librairie open source javascript qu’API platform intègre via API platform admin. Basé sur Material Design, un des design systems les plus performants, elle permet de générer tout ce dont on a besoin pour faire une administration (login, menu, crud, animations…). React-admin intègre des composants déjà tout faits permettant de réaliser la majeure partie de ce dont on peut avoir besoin.

A ne pas utiliser : les admin builders. Dans la majorité des cas, il vaut mieux avoir la main sur son administration.

Quelques conseils quand on développe en React :
– Les guessers permettent de générer le code React.
Evitez les embed.
– Soyez optimiste (React stocke les informations dans le store local et va faire sa vérification après coup sur le serveur, l’avantage c’est que l’interface réagit directement et n’attend pas le résultat de l’API).
– Sortez des CRUDités !
– La configuration est à mettre dans le runtime et non dans le build time. La configuration et les variables d’environnement sont à mettre dans le template principal.

L’atout maître de React est le JSX, basé du javascript et qui doit être compilé en javascript pour être lu. C’est un langage de templating… mais pas que. Tout simplement parce que c’est un langage de configuration. En Symfony, on pourrait dire que c’est un mélange de twig et de yaml. Mais pas que. C’est aussi une structure de données où il est possible de factoriser le code et de le simplifier au maximum…. mais pas que. Il peut aussi faire de l’injection de dépendance (en faisant une sorte d’inception de composant).

Dans React, tout est remplaçable. Si un composant ne va pas pour tel ou tel endroit, dans ce cas faites-le vous-même et remplacez-le.

Beaucoup d’humour dans cette présentation, un speaker au top !

#RabbitMQ simplement – Frédéric Bouchery

symfonylive25 Symfony Live 2019, on vous dit tout : JOUR 2

Rabbit MQ pour Message Queuing, c’est un système basé sur la réception de messages venant d’une application qu’on stocke pour être consommé par une autre application au fil de l’eau. L’avantage, c’est que tout se fait en Asynchrone.

Celui qui envoie les données est appelé un publisher (producer, dispatcher, sender) et celui qui reçoit s’appelle un consumer (worker subscriber…)

Publisher => Queue => Consumer

Par défaut, une queue reste active même sans consumer et est effacée au redémarrage. De base, les messages sont supprimés au redémarrage. Pour qu’ils restent, il faut les mettre en mode persistant. Un message disparaît lorsque la queue reçoit un message du consumer disant qu’il a été traité (c’est ce qu’on appel un nack).

Mais en réalité, le publisher est connecté à un exchange et pas directement à une queue, le but étant de pouvoir mettre plusieurs queues, comme on peut mettre plusieurs consumers.

Publisher => Exchange => Queue => Consumer

A chaque queue, on peut associer des binding keys et sur chaque message on peut lui donner une routing key. Les queues prendront les messages dont le routing key correspond au binding key de la queue.

Ce process correspond au mode “topic” de l’exchange, mais il existe d’autres modes comme direct, header et fanout.

Mais comment gérer avec Symfony ?

Avec le composant messenger de Symfony. On crée un Objet Message, un Handler de message puis on utilise un BUS (qu’on a configuré avec ampq pack) et on dispatche le message dans le BUS. Ensuite, le message est consommé avec la commande de messenger le permettant, et le tour est joué !

Frédéric a su faire, de manière très pédagogue, une bonne présentation sur le fonctionnement de rabbitMQ et des cas d’usages.

#Développement d’applications TDD avec Symfony et ses amis en situation réelle – Chris Holland

symfonylive26 Symfony Live 2019, on vous dit tout : JOUR 2

Chris nous explique pourquoi il est important et simple de mettre en application le test driven development sur Symfony 3.4 avec un cas concret de la gestion des courses façon Uber.

Qu’est-ce que le TDD ?

C’est un processus qui se décrit en 5 étapes :

1 – Écrire un seul test qui décrit une partie du problème à résoudre ;
2 – Vérifier que le test échoue, autrement dit qu’il est valide, c’est-à-dire que le code se rapportant à ce test n’existe pas ;
3 – Écrire juste assez de code pour que le test réussisse ;
4 – Vérifier que le test passe, ainsi que les autres tests existants ;
5 – Remanier le code, c’est-à-dire l’améliorer sans en altérer le comportement.

Pourquoi écrire des tests ?

Pour pouvoir tester du code, on exécutera un ensemble d’actions rudimentaires comme ajouter du code pour débugger (var_dump, xdebug…). Ces actions peuvent être très coûteuses !
Dans un flux de travail TDD, on fera abstraction de toutes ces actions simplement en faisant tourner le test écrit en amont. On obtiendra un gain de temps en validant l’implémentation via la console sans passer par les tests dans le navigateur.

Les tests permettent également de documenter car nous pouvons, grâce à leur lecture, comprendre le fonctionnement de l’application.

Les outils de test

Quand on conçoit des applications, on passe beaucoup de temps à jongler avec les données et à penser la logique business.

Il existe beaucoup de fonctionnalités communes (REST / authentification / gestion des utilisateurs….) entre les applications, c’est pour cette raison que Chris recommande d’utiliser les bundles :
FostRestBundle pour le développement d’API REST
FOSUserBundle pour la gestion des utilisateurs (celui-ci n’est plus utilisé avec la version 4 de Symfony)

Les frameworks TDD :
– PHPUnit
– Codeception

Afin d’expérimenter en situation réelle, nous devons tester nos entités et nos repositories avec de vraies données sans pour autant altérer le schéma de la base pendant les développements. Le couple Doctrine + SqlLite sera utilisé pendant l’écriture des tests et une fois validée, la base de données pourra être mise à jour grâce à DoctrineMigrationsBundleLe mini projet pour avoir une première approche des TDD avec Symfony est disponible sur github.

Comme à l’accoutumée, ces deux jours de conférences furent enrichissants sur de nombreux points. On retiendra notamment cette tendance à privilégier de plus en plus des architectures orientées ressources à rebours d’architectures monolithiques, comme le bon vieux pattern MVC. Sans doute une meilleure approche pour préparer l’avenir, notamment à l’aube de l’internet des objets. Plus que jamais, les technologies évoluent à vitesse grand V et posent de nouvelles questions en termes d’organisation, des bonnes pratiques ou encore d’usages.

Chez DISKO, nous suivons de très près toutes ces évolutions et nous interrogeons constamment sur notre travail afin de proposer des produits innovants et au plus proche des attentes de nos clients. Innover ou mourrir, c’est bien là une des valeurs de l’ADN de l’agence. Nous aurons toujours de nouvelles choses à vous proposer, et c’est ce qui fait qu’on ne s’ennuie jamais. En ce sens, le métier de développeur reste une formidable leçon d’humilité !

 

 

 

Laisser un commentaire.