Jeudi 23 novembre 2017, toute l’équipe d’Imagile a participé à l’édition 2017 de Codeurs en Seine à l’Université de Rouen. Nous prenons toujours plaisir à assister à cette journée de conférences pour plusieurs raisons :
- c’est très bien organisé; merci à toute l’équipe !,
- c’est un bon moyen pour s’informer sur divers aspects de nos métiers web,
- c’est aussi l’occasion de retrouver des partenaires, comme Alexandre Ronsaut ou l’équipe de Wixiweb avec lesquels nous partageons de belles valeurs.
Voici quelques notes en rapport avec les conférences auxquelles nous avons assisté.
Vincent Cassé, développeur chez OVH, nous a fait part de son retour d’expérience sur la gestion de grosses requêtes HTTP en PHP à travers le développement de leur solution de cloud « Object Storage».
Vincent a passé en revue les différentes problématiques techniques auxquelles son équipe a pu être confrontée pendant la réalisation de ce projet et les solutions apportées :
- Téléchargement de fichiers de plusieurs Go grâce au callback de Curl qui permet de télécharger pendant des heures sans interruption serveur.
- Lecture de fichier à la volée avec fopen()
- Upload avec XMLHttpRequest permettant d’éviter un rechargement de page
- Traitement du « Same-origin policy » avec utilisation de CORS pour autoriser la communication multi-domaines.
Une présentation très instructive et pleine d’humour où Vincent nous relate, avec humilité et sans langue de bois, son quotidien de développeur pendant la réalisation de cette plateforme de cloud.
L’anecdote du proxy buffering nous fait penser qu’ils ont dû avoir quelques cheveux en moins sur le crâne à la fin de la semaine… 🙂
Retrouvez ici la présentation filmée : https://youtu.be/EfUps5hmZ_s
Avec Frédéric, nous discutons d’agilité depuis des années. Depuis que nous nous sommes rencontrés au Club Agile Caennais. Ses interventions ressemblent de plus en plus à des one-man shows : le par coeur et le rythme sont impeccables (chapeau bas). Nous attendons la perruque et la guitare électrique pour l’expérience ultime.
Lors du Printemps Agile ou lors de Codeurs en Seine, nous allons le voir, pour étudier comment il évangélise les concepts agiles, comment il fait vivre l’esprit agile, comment il suscite l’enthousiasme et redonne confiance à certains qui, a priori ensevelis dans le quotidien d’un développement informatique sans saveur ni sens, semblent retrouver de la force pour parler enfin à leurs collègues, leurs boss, leur clients ; On ne le répètera jamais assez : parler et s’écouter est la pierre angulaire de tout projet qui avance !
Voici ce que nous avons retenu de la conférence de Guillaume Scheibel :
Le déploiement continu a pour objectif d’augmenter la fréquence de mise en production, pour arriver à terme à plusieurs déploiements par jour. Guillaume Scheibel nous a présenté les techniques appliquées chez Expedia pour atteindre cet objectif.
Il a particulièrement insisté sur le fait d’y aller progressivement. Il y a de nombreuses dimensions à considérer et vouloir tout mettre en place du premier coup est trop ambitieux.
Le point principal est d’installer une boucle itérative permettant d’améliorer le processus et d’augmenter le niveau de confiance dans son application :
- Build
- Measure
- Learn
- Loop
Parmi les techniques à employer, on peut citer :
- Les tests d’intégration pour vérifier automatiquement que l’application fonctionne avant de la déployer.
- L’enrichissement des logs : au lieu de logger de simples messages, on log des données pour pouvoir ensuite les analyser (par exemple pour chaque événement un timestamp, un code, des propriétés, la version de l’application). Des outils spécialisés comme ELK (Elasticsearch, Logstash, Kibana) sont d’une grande aide.
- La collecte de nombreuses métriques pour surveiller les impacts des changements mis en production et permettre de réagir rapidement.
L’A/B testing pour diriger graduellement une partie des utilisateurs sur la nouvelle version de l’application. Cela permet de la tester en conditions réelles sans impacter tous les utilisateurs. - Le « fix forward » plutôt que le « rollback » : en cas d’erreur on redéploie une nouvelle version plutôt que de revenir à l’ancienne. Cela limite les risques de bugs qui pourraient être occasionnés par du code ancien appliqué à des données plus récentes.
- Enfin, au niveau humain, l’appropriation complète de son travail : les équipes sont responsables des fonctionnalités qu’elles ont développées de bout en bout. « Fini » veut dire en production et non seulement terminé sur le poste du développeur.
Retrouvez ici la présentation filmée : https://youtu.be/7dqMPkvyqiU
Voici ce que nous avons retenu de la conférence de David Wursteisen :
Dans cette conférence dynamique, David Wursteisen nous a montré les différences principales entre le développement d’une application « classique » et celui d’un jeu vidéo. L’accent a été mis sur les difficultés spécifiques et des astuces pour y remédier. Il existe un livre gratuit pour apprendre : « game programming patterns » http://gameprogrammingpatterns.com.
Pour gagner du temps, on utilise un moteur qui va fournir la plupart des fonctions indispensables à tout jeu. Le choix du moteur va dépendre du type de jeu : plateforme, stratégie…
Un jeu fonctionne avec une « main loop » : ce code est appelé 60 fois par seconde et se charge de réagir aux actions du joueur (appuyer sur un bouton), d’appliquer les modifications (calculer la nouvelle position de la voiture) et le rendu (calculer l’affichage de chaque objet présenté à l’écran).
Quelques-unes des particularités évoquées :
- Le référentiel : la position d’origine (0,0) n’est pas toujours au milieu des objets (par exemple si l’axe y est inversé). Cela a un impact notamment sur le calcul des rotations.
- La physique : tout est basé sur les vecteurs, il faut se replonger dans les maths du collège et lycée !
- Les interpolations : ces fonctions mathématiques permettent de casser les mouvements linéaires pour par exemple donner une impression d’accélération.
- Les collisions : le calcul de collision entre deux objets ne se fait pas toujours en vérifiant l’intersection entre leurs coordonnées x et y, car selon l’angle la formule change. Il faut utiliser des formules de mathématiques vectorielles complexes, c’est notamment pour cela qu’un moteur est intéressant (par ex. Box2d)
- Le debug : il est complexe car la main loop est appelée 60 fois par seconde. Une bonne technique est d’utiliser des indicateurs visuels comme des points et traits pour suivre les déplacements.
- Les assets : même un jeu simple en 2D utilise des sprites pour les animations. Cela demande beaucoup de temps en graphisme. Pour commencer il est conseillé de s’orienter vers un jeu simple nécessitant peu de graphisme.
Pour toutes ces raisons, il est conseillé pour démarrer d’utiliser des outils appelés « Tooling » comme GameMaker https://www.yoyogames.com/gamemaker qui fournissent beaucoup de fonctionnalités nécessaires et permettent de se concentrer sur ce qui fait le l’essentiel d’un jeu : son gameplay et le plaisir qu’en retire le joueur.
Retrouvez ici la présentation filmée : https://youtu.be/3XnqTRyerWU
Voici ce que nous avons retenu de la conférence de Thomas Zilliox :
Thomas Zilliox nous a présenté un retour d’expérience sur la mise en place de tests sur le CSS chez 6Play. Le CSS n’étant pas un langage « classique » avec un fonctionnement algorithmique, il est très difficile à tester. Cela complique l’utilisation de techniques habituelles comme les revues de code, le TDD… De plus, la surface du langage étant très grande (plus de 500 sélecteurs), lorsque l’on combine cela au grand nombre de sélecteurs HTML disponibles et à toutes les versions existantes des navigateurs, on obtient une infinité de bugs possibles.
En amont, l’utilisation d’une convention de nommage comme BEM permet de limiter la portée des sélecteurs et donc le nombre de bugs. Le code est plus facile à lire et la création de nouveaux composants n’a pas d’impact sur ceux existants. Un linter (par exemple Stylelint) permet de normaliser le code et de vérifier qu’il n’y a pas d’erreur comme des fautes de frappe ou des sélecteurs invalides…
Des tests fonctionnels vont s’assurer que les fonctionnalités essentielles sont opérationnelles. Par exemple, un test pourra vérifier que le bouton « Se connecter » est bien visible par un utilisateur et n’est pas caché derrière un autre élément. Cela ajoute une couche de confiance supplémentaire par rapport à un test d’intégration classique qui vérifierait uniquement que le bouton est cliquable sans s’assurer de sa visibilité.
Enfin, une fois le code en production, un outil comme Browserstack va automatiser les tests sur plusieurs versions de chaque navigateur, tandis qu’un autre outil comme Percy.io permet de détecter les régressions visuelles.
Au final, le plus important reste le facteur humain. Thomas a insisté sur l’importance de la formation des développeurs, sur le travail en équipe et la transmission du savoir entre les intégrateurs et les développeurs back-end. Nous avons beaucoup apprécié son humilité et l’accent qu’il a mis sur le fait que toutes ces techniques sont encore jeunes, complexes et nécessitent d’avancer ensemble pas à pas pour améliorer la confiance de l’équipe en elle-même et en son produit.
Retrouvez ici la présentation filmée : https://youtu.be/mnzO08iQndg