Bonjour à tou.te.s

Pour ce premier PSUG de printemps (si si, techniquement ce PSUG aura lieu au printemps), Gaël Renoux nous parlera de Slick et Hoai Nam Nguyen reviendra nous parler de tests de regressions.

Ce mois-ci, c’est Renault Digital qui nous accueillera pour la première fois, on les remercie d’avance.

/!\ ANNONCE IMPORTANTE /!\

À ce propos, afin de permettre l’accès aux locaux, il vous sera demandé de présenter votre PIÈCE D’IDENTITÉ et nous devrons fournir la liste des inscrits au AU PLUS TARD MARDI 27.

Slick

Présentation, bonnes pratiques et solutions (acquises dans la douleur)

Slick est surtout connu comme le framework d’accès aux données intégré à Play, mais il mérite bien d’être connu pour lui-même. Pourquoi ? Pour requêter en asynchrone. Pour travailler sur vos tables comme si c’était des collections. Pour avoir une vérification statique de votre mapping et de vos requêtes. Pour faire du pur SQL quand c’est nécessaire, toujours en asynchrone. Pour ne pas utiliser un ORM (parce que c’est trop la honte).

Le principal problème de Slick, c’est (hélas) sa documentation. Pas évident de s’y retrouver, ni quand on vient de s’y mettre, ni quand on cherche des bonnes pratiques et des solutions. Du coup, c’est ce que je vous propose : une introduction rapide, les problèmes que nous avons rencontrés, les bonnes pratiques que nous avons fini par adopter, et les solutions que nous avons mises en place. Il y aura des sorciers dedans.

Test de régression et les comparateurs

Les test de régressions sont populaires dans les projets sur les calculs numériques. Ces tests assurent que les valeurs numériques ne bougent pas par rapport à des résultats de référence persistés; mais ils ne disent pas exactement quels sont les endroits où le bug a été introduit. C’est la raison pour laquelle on a besoin d’un mécanisme de comparaison qui affiche en détail ces différences. Après une présentation du problème; je vais parler la conception d’une petite librairie de comparateur qui est utilisée dans mon équipe