L’équipe de Mapado était présente au PHP Tour à Clermont-Ferrand.

Grown-up MongoDB: Schema Design for Optimal Performance

Par Derick Rethans

Beaucoup d’infos sur mongo dans ce talk.

Il faut bien choisir si on “embed” ou “link” un document. Il nous a fait un point sur le explain des requêtes.

Depuis Mongo 3.2, on peut ajouter une validation des données facultative pour éviter d’insérer les objets là où l’on attends une string.

PHP microservices beyond the trench

Par Vincent Vermersch, et  Etienne Roudeix de DomRaider

Ils nous expliquent comment ils ont migré une grosse application monolithique vers une multitude de micro services.

Ils organisent leurs containers dockers avec Kubernetes. Ils utilisent ELK pour centraliser leurs logs, sentry pour les remontées d’erreurs.

Lancez-vous dans l’open-source

Par Matthieu Napoli, créateur (entre autres) de PHP-DI.

Matthieu nous parle des deux gros problèmes des projets Open-Source:

  1. Mon projet ne marche pas
  2. Mon projet marche !

Pour que votre projet fonctionne, il faut que vous ayez obligatoirement :

  • Le code
  • Des tests (un projet open-source non testé est un projet qui va planter)
  • git et github: ce sont les outils que tout le monde utilise
  • README.md : L’utilisateur va donner 5 secondes à votre projet en arrivant dessus. Si pas de README (ou doc), il va partir et ne pas revenir
  • composer + packagist : pour PHP
  • Travis, scrutinizer, StyleCI pour avoir des standards et ne pas se prendre la tête sur des PR illisibles
  • License (pas de license = non open-source)

Votre projet doit être différent, mais pas trop, utilisez le Semantic Versionning, les normes PSR (2 et 4)

Le code doit être explicite, la doc est extrêmement importante, cohérente, simple et concrète (avec des exemples par exemple).

Pour communiquer sur son projet, twitter c’est bien, et bienveillant. Reddit est moins bienveillant, mais apporte finalement les retours les plus intéressants.

Si votre projet fonctionne, la grosse majorité de votre temps va être à faire de la gestion de projet (50%).

Pour les contributeurs, avoir un fichier “CONTRIBUTING.md” un Template de PR, des label “easy-pick” sur les issues.

Il faut aussi savoir dire NON sans décourager les contributeurs, car vous avez une vision pour votre projet qui n’est pas forcément le même que le contributeur.

On a tué mon agilité

Par Frédéric Bouchery, CCM Benchmark

Frédéric reproche ici aux entrerpises de faire de l’agile simplement parce que c’est “à la mode”.

L’exemple typique : “Nous on est en agile : on fait des réunions debouts et on a des post-it”

Il manque toute la phase d’adaptation qui est le cœur de l’agilité.

Il nous cite aussi l’exemple d’un client qui veut faire de l’agile car “il ne veut pas s’embêter à faire un cahier de charges”.

Il reproche un peu à Scrum sa notion de “Sprint” car les équipes de dev ne peuvent pas toujours “sprinter”. Il se pose en rempart en amont de ses développeurs, pour éviter que ses développeurs aient trop de pression.

Ses slides

Arrêtons de perdre du temps à débugger

par Nastasia Saby, Zenika

Passée par une grande période de sa vie dans une TMA, elle nous explique le debugging est fastidieux, qu’on en retire peu de gloire, que c’est une perte de temps, et donc de business.

Elle nous dit qu’il faut différencier les bugs en pahse “build” et en phase de “run”.

Elle nous parle d’une grosse application écrite en Polonais (commentaires, nom de méthodes, etc.)

La phrase à retenir de la conférence est :  “Prière de laisser cet endroit plus propre qu’en entrant”

Elle nous indique que l’on ne peut pas tout changer d’un coup. La mise en place de test pour chaque bug est une bonne pratique. Mise en place de “pair-debugging”.

La résolution de bug est avant tout une affaire de communication.

wallabag: Migration vers Symfony 3

par Nicolas Lœuillet, Jeremy Benoist

Les deux contributeurs de wallabag nous expliquent comment ils sont passer d’une grosse application PHP “old-school” à une nouvelle version sous Symfony.

Je n’ai honnêtement pas trop trop suivi cette conférence, je préfère juste vous envoyer sur les slides.

Oublions mod_php

Rémy Collet, contributeur Fedora nous présente ici les défauts de mod_php et nous vante les mérites de FPM.

Il nous explique que mod_php ne devrait plus être utilisé et devrait être remplacé par fpm. La migration vers nginx n’est pas forcément obligatoire, apache avec le mod_proxy_fcgi faisant très bien le travail.

Il semble très simple d’avoir plusieurs versions de PHP en fonction du vhost apache en indiquant un “SetHandler” par vhost.

Répartition de charge: mod_proxy_balancer fait parfaitement le job pour répartir la charge sur différents serveurs FPM.

Pour passer de mod_php à fpm: une ligne à changer + restart apache.

Possibilité de lancer deux “pools” avec des extensions chargées distinctes (pour xdebug par exemple).

Le lien vers un blog post pour la configuration multi-instances de PHP par ici.

Le jeu vidéo à la rescousse du Web

Par François Zaninotto, fondateur de marmelab

Que peut amener le monde du jeu vidéo au web en terme d’interactivité ?

François fait le lien entre l’interactivité des sites web et les évolutions des jeux vidéos dans le temps.

Niveau 0 : site statique

Niveau 1 : site généré dynamiquement (wikipedia)

Niveau 2 : Mise à jour d’une partie de la page inspiré des “Sprites” (pas CSS, ni la boisson) pour redessiner un personnage dans un décors par exemple + notion de transitions. Implique d’utiliser un Framework côté front (jQuery par ex.) et côté back (Symfony, Laravel).

Niveau 3 : Gestion du rendu côté client et plus côté serveur. Client-Side Framework MV*. Gestion des routes, etc. François fait aussi un gros point sur ES2016. Utilisation de pub/sub pour être informé des mises à jour (meteor par exemple).

Pattern pour l’efficacité côté front : Flux (créé par facebook). Permet l’immutabilité.

Pour monter à 60fps, il faut re-rendre toute la scène, plus uniquement un seul changement. (j’ai comme une petite impression qu’il va parler de ReactJS, je me trompe ? 😀 … Ah ben oui, voila ! )

Il parle ensuite de “Optimistic UI”, le principe d’imaginer le retour du serveur pour afficher au client avant le retour du server et des applications “Universal”.

Avec tout ça, on arrive au Niveau 4 !

 

C’est tout pour le jour 1 !

Voir le retour du deuxième jour.