Leny Bernard, 22/05/2017

Retour d'expérience sur le PHP tour nantes 2017

7 minutes de lecture

Le PHP tour 2017 vient de se terminer et l'heure est au retour d'expérience. Nous ne pouvons pas parler de toutes les conférences mais voici nos principaux ressentis !


Mark Baker


Does the SPL still have any relevance in the PHP7 ?


Mark Baker nous a fait une forte impression sur son talk Does the SPL still have any relevance in the brave new world of PHP7 ?


En effet, cette conférence n'était pas forcément très technique mais a expliqué chaque partie de la SPL en les comparant avec les autres manières de faire en PHP7. On peut complètement vivre sans PSL mais si vous faites la chasse à la performance et pour alléger le code, jetez un coup d'oeil: http://php.net/manual/en/book.spl.php

De mon côté, j'ai été très séduit par les DataStructures ( SplDoublyLinkedList, SplStack, SplQueue, SplHeap).

James Mallison


Dependency injection and dependency inversion in PHP


James Mallison a passé en revue le D de SOLID. Conf très intéressante qui réexplique les fondamentaux à mettre en place pour avoir un code objet testable et flexible: Slides


Récapitulatif, quand on développe, on doit :


- Dependency Injection is simply passing in object dependencies as parameters instead of instantiating them in the object using them

- Doing this gives you Inversion of Control, as the control over object creation is no longer delegated to the object using them

- If you use don’t do this, other people will hate you because they can’t mock your objects easily in their tests (so your code is not testable)

- Using interfaces, we can adhere to the Dependency Inversion Principle and depend on abstractions

- Code always starts off procedural, and builds objects up before executing them in an object oriented manner


A lire dans la même veine: the gang of four code / the clean coder / post your code on codereview.com

Claire ColomaSuzanne Favot


Comment marier Symfony et ReactJS ?


Pour react, Claire Coloma et Suzanne Favot ont pris le temps de nous faire un joli retour d'expérience sur le développement React avec Symfony. Cette conf nous intéressait particulièrement car nous commencons de plus en plus à aller dans cette voie-là.

Ce qu'on en a tiré c'est qu'on peut utiliser le bundle https://github.com/Limenius/ReactBundle afin de régler des problèmes de SEO liés aux rendus clients et afin de mieux wrapper l'utilisation de nos components dans nos applications.

Concrêtement, ces petits bouts de codes alternatifs servent à Render les composants Homepage uniquement en server_side, puis uniquement en client_side, puis le both, comme son nom l'indique, fera les 2 (par je ne sais quelle magie noire) :


{{ react_component('Homepage', {'rendering': 'server_side'}) }}
{{ react_component('Homepage', {'rendering': 'client_side'}) }}
{{ react_component('Homepage', {'rendering': 'both'}) }}


De plus, pour gérer les formulaires, la dernière chose qu'on ait envie de faire, c'est de les gérer en front et en back. Là aussi, un bundle de notre chèr Limenius vient à la rescousse, il s'agit du https://github.com/Limenius/LiformBundle.


Arnaud Langlade


Code moi une RH ! (slides)


Le titre n'est pas à la hauteur du talk pour moi et j'ai failli le rater en pensant que ca ne m'intéresserait pas... quel dommage :)

Arnaud Langlade nous a présenté avec brio une implémentation du DDD et du CQRS.


Quelques petites notes à retenir pour le DDD :

On voit souvent des classes EmployeeManager (Helper, Service...) qui donnent des classes huge et aux lourdes responsabilités. A la place, pour DDD, on va ajouter des verbes en fonction statiques dans nos models, hire, promote, fire, retire.

Et comme on ne construit pas un employé mais qu'on l'embauche, on va créer un constructeur privé. On appelera plutôt Employee::hire($uid, $name, $date, $contract);

On a tendance à utiliser Doctrine comme un entrepot de données or la définition du pattern Repository semble juste indiquer qu'il doit se comporter comme une collection d'objets uniques sans se soucier de la persistance.

On va donc créer une class Repository implementant EmployeeRepositoryInterface et n'étendant pas EntityRepository.


__construct(EntityManager)

get(Uuid $identifier) va se baser sur la méthode find de l'entity manager

add(EmployeeInterface) va se baser sur persist / flush d'em

remove(EmployeeInterface) idem

Les setters ne sont plus requis car Doctrine utilise la Reflection et on peut utiliser ocramius/instanciator pour bypasser le construct.

- Command to the rescue : Une commande simple avec les proprietés miroirs d'un formulaire. On passera donc la commande au form et ensuite on appelera la fonction statique Employee::hire(Uuid::uuid4(), $cmd->name, $command->date, $command->contract).

J'ai noté le bundle SimpleBus avec son bridge symfony sans bien comprendre à quoi cela fait référence mais ca a l'air cool (by Mathias Novak ❤️).


On va créer un handler pour traiter la commande :

Getters ? Noo, DTO to the rescue

L'opérateur new va permettre d'usiner des DTO.

On créé un EmployeeDTO avec les même proprietés que précédement. Il n'y a aucune logique ici, cela va juste faire transiter de la donnée. On peut créer un service EmployeeSearcher ayant une fonction findAll créant une query comme ceci:

$queryBuilder = $em->createQueryBuilder()->from('Employee::class, 'e')->select(

sprintf('NEW %s(e.id, e.name, e.position)', EmployeeDTO::class));


Pour récapituler, voici les étapes:


  1. Create a command
  2. handle the command
  3. create a model
  4. persist / remove / flush
  5. create a read model
  6. assign it the view

Bien sûr, il ne faut pas utiliser ce design pattern dans tous les cas, parfois c'est un crud qu'il faut donc pas de pression (on peut aller voir du côté du ResourceBundle de Sylius qui fait le job).

Choses interessantes survenues lors des questions, les namespaces. Arnaud sépare le côté DDD en 3 directories:


- App\Infrastructure (va embarquer tout ce qui est purement technique, persistance etc.)

- App\Application\Command\HiredEmployeeCommand

- App\Application\Presenter


Joel Lord


Learning about Machine Learning


Conférence tout à fait passionnante de la part de Joel Lord. Notre ami québecois a réussi à nous transmettre sa passion et nous donner l'envie de s'y essayer.

AI (pacman, credit card etc) ≠ ML (apprentissage thermostat, téléphone qui apprend ou on travaille, ou on habite, le chatbot @TayTweets qui est devenu raciste, homophobe etc)

"Don't be afraid of AI, be afraid of humanity" :)

Bien penser à mettre des mécanismes de défense pour empecher de lui apprendre des choses négatives :troll:

Réseau neuronnaux, TensorFlow, Google Cloud Machine Learning ( https://cloud.google.com/products/machine-learning...)

Supervised Learning https://www.wikiwand.com/fr/Apprentissage_supervis...

Unsupervised learning: https://www.wikiwand.com/en/Unsupervised_learning


The naïve Bayes classifier:


De notre côté, voici quelques idées d'application dans notre vie réelle d'agence:

  • pour un client qui a besoin de valider des entités crées par les internautes, il serait facilement faisable d'autoriser la soumission uniquement lorsque la comparaison avec un dictionnaire est au dessus d'un certain seuil (orthographe) et en dessus d'un autre (injures)
  • pour un client de crowdfunding, un système de ML pourrait analyser les précédents projets afin d'identifier les facteurs de succès des projets et établir des suggestions lors de la création d'un projet.


Genetic Algorithm

On cherche quelque chose. On créé une population de 150 individus avec des valeurs aléatoires. On prend les meilleurs, les plus proches de ce qu'on cherche puis on va les faire muter aléatoirement. Ensuite on prend cette population et on créé des enfants héritant des propriétés génétiques des parents etc. Ca donne des résultats étonnants !

En terme de techno, notre ami Joel utilise plutôt Python et conseille plutôt le célèbre https://www.tensorflow.org/ qui semble dominer le marché.

De notre côté, on a aussi trouvé https://github.com/php-ai/php-ml qui semble plutôt stable et pas mal utilisé en php. A suivre.


Jérémy Derussé


Grâce aux tags de Varnish, j'ai switché ma prod sur un Raspberry PI


Cacher une app pour Jérémy Derussé, c'est pas simple et notamment invalider le cache. Il existe 2 façons globales de faire :

Validation model: last-modified (application is booted, low)

Expiration model: expires (not up to date)

Mais Varnish peut être appelé pour invalider une partie du cache grâce aux Tags ce qui veut dire que le rapport de force est inversé. C'est le backend, qui sait quand les ressources évoluent, qui invalide le cache.

Concrêtement, pour Victoire, cela pourrait réellement changer notre façon de cacher les pages en les invalidant, widget par widget, business entité par business entité... A suivre encore une fois :)


Pour finir, merci à toute l'équipe de l'AFUP pour ces 2 belles journées et à tous les speakers, vous avez fait du très bon travail et c'est cool quand un évenement comme celui-ci est dans sa ville, vivement le prochain !

comments powered by Disqus

Nos derniers articles