Les pieds dans le code

Pour apprendre à programmer, le mieux est de metre les pieds dedans.

Participantes

@Yannick : Expérimenter des formats d’apprentissage, faciliter une communauté d’apprenants.
@Yuhiba : Trouver un job chez Octo ou à la Combe du lyon vert ou chez Arolla ou avec d’autres gens bienveillant dans le même genre.
Étienne : Simplifier l’inscription des élèves au collège.
@tho : Prendre le temps pour respirer et de prendre du recul.
@akhardya : Trouver un job de développeuse junior.
@elsa31 : Trouver un job de développeuse junior.
@sarah007 : Où me situer pour répondre à des offres (freelance ou pas ? graphisme ou code ou les deux ?).
@PetitPandaRoux : Être à l’aise avec JavaScript, et basculer dans un métier plus technique ?
Hafid : Savoir faire du machine learning.
Isabelle : Trouver un job dans la DataScience.
@Morendil : Monter en compétence sur un langage fonctionnel (avec PureScript) et front.

Paul à parle d’authentification et d’autorisation avec Étienne et Yohann.

@Morendil, @Yuhiba et @Yannick ont exploré les exceptions en Ruby.

Une phase d’alignement sur les échanges entre @Morendil et @Yuhiba.
Une fois évoqué l’écart dans le dialogue, on a l’impression que chacun a fait un effort vers l’autre pour facilité l’échange.
@Morendil utilisait une approche Socratique
Le chemin suivi était d’écrire du code avec des tests pour explorer l’usage.
@Morendil c’est donnée du mal en faisant de faire ça dans Vim.
Les exceptions permettent d’envisager une action en cas de problème.
Une exception remonte la pile d’appel jusqu’à « qui n’en veut ».
raise, begin, rescue, assert_raises(Error) { puts "truc"}
Selon comment on organise le code, on peut se passer d’exception.

Yohann a fait un peu de NodeJs via un tutorial.

@sarah007 a joué avec des choses.

De la neige en JavaScript/canvas.
Des boutons animé en CSS.
Pas facile d’explorer des choses rapidement ET de trouver des noms pertinant.
transition, vertical-align, transform: background 6s ease, .maclass:hover {}, border-radius, transform: translate(0px, -200px);

Étienne, @Yuhiba, @tho, @sarah007 et @Yannick ont fait un Kata Tennis en Ruby.

On a utilisé MiniTest.
On a fait du mobProgramming : celle au clavier ne tape que ce que les autres lui dicte, on tourne toute les 15 minutes.
Difficulté de trouver le vocabulaire et les éléments dont on parle.
C’est important de faire un travail vers le domaine métier.
Est-ce qu’on a fait du DDD ?
On a plutôt fait du TDD, et vu un design émerger.
C’est chouette le mob.
Nous avons parlé de « pourquoi on écrit des tests avant de réfléchir ».
Le plan n’était pas partagé.
C’est bien de faire des croquis pour visualiser le plan.
Quand on code à plusieurs, on peut bénéficier d’autres visions.
@Yannick à un peu trop participé peut-être.
Peut-être que la prochaine fois, il faudrait essayer de faire toute l’API en testant avec un seul joueur, puis à la fin, introduire le deuxième joueur pour régler les cas particuliers d’égalité et deux points d’écart.