@e.pampouille, @PetitPandaRoux, @will.i.am, @EricLT, @sarah007 et @yannick font un kata pokerHand:
On a parlé des approches top-down et bottom-up
en bash touch monFichier
« C’est quand même compliqué module.exports » – @PetitPandaRoux
en JavaScript module.exports.maFonction = maFonction; module.exports.monAutreFonction = monAutreFonction;
La différence entre le JavaScript dans le navigateur et NodeJS est pas évidente (particulièrement sur les histoires de modules et de scopes des fonctions).
en JavaScript var maFonction = require('monModule'); c’est un peu surprenant comparé à import monModule en Python ou require "monModule" en Ruby.
« C’est cool le poker » – Sakada.
C’est bien de pas être parti sur la génération de carte, ou la création du contexte d’un jeu de poker…
En JavaScript [1, 2] == [1, 2] => false.
Qu’est-ce qu’il y a dans le code de assert.equal().
git rm --cached <mon_fichier>.
On a fait un peu de bash en echauffement.
@yannick aimerait un cadre dans lequel les pratiquants construisent leurs connaissances en cherchant les réponses à leurs questions. Faire des rotations en mettant au clavier la personne qui pose une question (regle du binome : celui qui est au clavie c’est celui qui ne sait pas) ?
Ça serait intéressant de plus utiliser le REPL pour manipuler les concepts et répondre aux questions.
On pourrait écrire un test pour explorer des questions.
C’est peut-être mieux quand on est que deux pour travailler sur un Kata (quitte à avoir plusieurs groupe).
En mobProgramming, on va peut-être se focaliser plus sur des détails de programmation, alors qu’en petit groupe, on va plus se poser de question sur la conception.
@will.i.am, @Yuhiba, @EricLT, @PetitPandaRoux, @yannick parle du 5eme chapitre de Clean Code à propos de la mise en forme;
Quand il y a plusieurs type de groupe à la boutique, la pièce de millieu est un foyer, pas un bon lieu pour faire une activité. Quand il n’y a que les rookies dedans, c’est plus facile de faire cette activités dans cet espace.
Ce chapitre était plus simple que les précédents, plus repossant.
On parle de mise en forme vertical, de rythme vertical;
On range le code en mettant les informations / abstractions de haut niveau en haut, puis on descend au fur et à mesure.
Apparement, William avait une habitude consciente de faire l’inverse; est-ce une pratique de chercheur ? Il faudrait demander à Jibé.
« Quand on écrit un programme, on écrit une histoire » – @yannick
Dans le cas du rythme horizontal, on retrouve ce que dit @yannick tout le temps.
Est-ce que le nombre de colonne utilisé, accepté est de 80 (historique), de 100 ou de beaucoup plus ?
Est-ce qu’on est un nazi de la colonne quand on vérouille à 80 ?
On parle des linter et autres outils de check style.
Est-ce que les linters rendent ce chapitre obsélète ? Est-ce que c’est mal d’utiliser un linter ?
« Le linter c’est un peu les petites roulettes sur le vélo, au début ça aide pour apprendre à faire un code plus lisible, puis après on en a plus besoin. » – @yannick
Le chapitre pourrait être revisité pour parler plutôt de ce qu’est un code bien formaté, pourquoi on espace, pourquoi on fait attention au rythme vertical et horizontal, plutôt que d’évoquer des règles (pouvant être aujourd’hui dans des linter).
Une idée de projet pour le rookie club : écrire un linter :-)
@EricLT, @will.i.am, @PetitPandaRoux et @sarah007 (avec @yannick dans les parages) souhaitent retravailler sur le test de Gofer. Après avoir discuté un peu de comment s’y prendre, nous constitions deux groupes;
@EricLT et @will.i.am partent du code existant;
« J’ai l’impression que le code est super lourd » – @PetitPandaRoux
Comment fonctionne la boucle de missions ?
C’est peut-être une bonne idée de commencer par nettoyer le code pour mieux le comprendre l’ensemble (renommer, extraire des fonctions, …)
C’est plus difficile d’être en petit groupe, difficile de se rendre compte de la mauvaise direction.
Il y a une certaine difficulté à reprendre du code existant.
A quel moment on peut décider de jeter du code ? à quel moment c’est génant ?
Parfois difficile de gérer les contraintes imposées (ici par la prod), qui nous oblige à avoir une gestion particulière dans nos tests.
Un test ne doit pas avoir d’effet sur les autres. Il faut maitriser les entrants.
Parfois, c’est nécessaire d’effectuer plusieurs appels à une fonction pour obtenir l’effet voulu.
Est-ce que nous aurions pu mettre une boucle à l’extérieur du test ?
@PetitPandaRoux et @sarah007 repartent de zéro;
En reparant de zéro on comprend mieux des éléments.
Est-ce que le fait d’avoir fait le code à beaucoup la dernière fois gène l’appropriation ?
@Morendil, arrivé en cours de route, décide d’explorer l’exercice directement sur le serveur de prod;
En baissant le niveau de qualité, on peut aller plus vite.
On vérifie une série d’hypothèse rapidement, et ensuite on reprend.
@Alex fait des révisions pour 42. Il va plus vite qu’avant.
@yannick ajoute quelques notes de la journée;
Le choix d’un format est primordial sur les effets d’apprentissage.
Ça pourrait être intéressant de se mettre des contraintes (en tant que sachant).
Ne pas répondre directement, mais pas une question (approche Socratique) ?
Ne pas faire de schéma, mais demander à la personne qui a une question de la préciser (redondant avec le point au dessus ?).
Ça deviens intéressant / important de lister des formats possible, et leurs variantes sur des fiches.
Prendre des notes sur les points observer plutôt que de réagir directement.
Proposer des activités en fonction des points noté (le jour même ou la semaine d’après).
Importance de garder des petits groupes de travail et d’élargir sur les débrief.
Pour ne pas retomber dans un long debrief de fin de journée, en proposer en cours de route ?
Une plateforme discourse permettrait-elle vraiment de permettre à chacun de journaliser ?
Si chacun prend soin de son journal, comment avoir un impact pédagogique dessus ? Durant le débrief, la façon de poser des question, de creuser un aspect ou un autre, de donner des informations sur un sujet peut avoir un intérêt pédagogique ?
Peut-être que le role de l’animateur est de justement passer de groupe en groupe, à l’affut du moment où c’est une bonne idée de faire un debrief/journal pour ce petit groupe. La mise en commun n’ayant lieu de de manière décentralisé ?
Voir si sur le discourse, nous pourrions mettre en place un suivi des rookies qui le souhaitent, en utilisant les profiles de chacunes et chacuns, en utilisant des tags, des catégories, des messages et posts privées si besoin ?