Rookies

Les activités / debief de la journée

Sakada à essayé d'installer un linter dans son éditeur de texte : Atom

Ça n'a pas fonctionné.
Un bon linter en JavaScript : eslint.
C'est un peu chiant à installer : certains plugin souhaite juste utiliser un linter déjà installé, et d'autres propose un linter embarqué...

Laurent, Étienne, Marine, Paul et Sakada ont discuté de ce qu'est MVC.

« design pattern » (patron de conception) : Model - View - Controller
C'est pas utilisé de la même manière dans une architecture web et dans une application client-serveur.
Connaitre l'histoire autour de ce pattern permet de mieux l'appréhender.
Le modèle c'est la partition, la vue c'est l'orchestre, le contrôleur c'est le chef d'orchestre.
C'est bien d'utiliser des métaphores pour parler.
On utilise souvent le même nom entre le modèle et le contrôleur.
Est-ce qu'il y a d'autre manière de penser l'organisation d'un programme, de faire un concert ?

Marine et Yannick on discuté de comment gérer une grosse feature dans un projet.

On a parlé feature toggle.
Yannick a découvert la gem Scientist.
Marine a fait un git rebase sans avoir peur, et fait un git push -f autorisé.
Quand tu fais une pull-request, les relecteurs vont lire les fichiers changé, pas les commits.
Ça rappelle des souvenirs à Laurent.

Laurent, Étienne, Sakada, Marine, Isabelle et Elsa ont fait un Kata Anagram

Après quelques tests pour mettre en place l'API, on est parti sur une stratégie brut force.
Ensuite, avec un résultat existant, on a exploré comment faire une implémentation plus rapide.
Et la chute : le kata tel que formulé sur le site du codingdojo.org n'a aucune solution.
le code source de cette implémentation.
Note intéressante : la pratique de mettre des parenthèses quand on appelle une fonction/méthode ma_fonction(truc) et de ne pas en mettre dans la définition def ma_fonction bidule.
Quand on pratique un langage assez souvent, tu prends l'accent : on peut se retrouver à faire du Haskell dans Ruby.
C'est bien quand c'est Laurent qui pilote le Kata et qu'il parle pour expliquer et consulter.
Un format MobProgramming strict rend le partage d'idée frustrant.
Sans connaitre le langage, on peut comprendre et suivre l'algorithmie.
« Apporter la fonctionnalité en généralisant » - parfois on est tenté de faire la fonctionnalité en faisant un remaniement.
En TDD, c'est mieux d'apporter un nouveau comportement par le biais d'un nouveau test, sans anticiper.
Important de faire des cas qui passent et des cas qui ne passent pas pour faire avancer le code.