Jour 0

Fin mars 2015, je voyais partir les élèves avec qui je venais de passer 6 mois. Nous étions ensemble à plein temps. Il y a eu des hauts et des bas, des débats aussi. Quelques grands moments et des coups de fatigue.

Quelques jours après je quittais l’entreprise dans laquelle j’avais réalisé cette expérience. Je venais d’y passer presque une année : la moitié en tant que bénévole, l’autre en tant que salarié, le tout à la place du responsable pédagogique, seul à avoir programmé dans un environnement professionnel.

J’étais venue en curieux pour voir cette « école » qui forme au développement, montée par des gens qui ne connaissent rien à la programmation…

Me voilà donc en février 2014 occupant les lieux en échange de quelques réponses aux questions des élèves de la première promo. Ces derniers ayant beaucoup de questions, j’y passais ma journée, et ça me plaisait. Au bout de quelque temps, on m’a demandé de venir à plein temps.

Sans argent pour me payer. Le deal était que je m’occupe bénévolement de la fin de la première promo (rallongée pour l’occasion), et je suis embauché à partir de septembre pour faire la deuxième. C’était parti, j’allais travailler pour Simplon’co.

La première promo a été une période de grande improvisation. J’ai essayé d’aider au mieux ce que les élèves avaient commencé seuls. Ça a été le moment pour moi de réfléchir à ce que je voulais faire mieux avec les suivants.

Durant la deuxième promo, j’ai rédigé un journal. Le but était de me permettre de prendre du recul sur mes sensations et réflexions de la journée. C’est vite devenu un moyen pour moi de réfléchir à comment améliorer l’expérience. Une sorte de rétrospective quotidienne, effectuée dans le RER en rentrant chez mois.

Ce journal était (est encore ?) proposé comme source d’inspiration pour les formateurs qui ont été recrutés ensuite, et je pense qu’il pourrait servir plus largement à partager ce que j’ai essayé, raté, souhaité améliorer, …

Voici donc ce journal que je livrerais petit à petit ici, et tel que je l’ai écrit à l’époque (je vais essayer de corriger les fautes d’orthographe au fur et à mesure).

Jour 1

Démarrage. Accueil. Discours de bienvenue médiocre, pas structuré. Bonne idée : faire intervenir Erwan (ou un autre fondateur ?) pour parler de Simplon, puis Stéphie (responsable Codev) pour parler des Compagnons du Dev.

Les locaux et le côté auto-organisé, pas forcement top. Peut-être faut-il imaginer des règles de base, un peu comme pour un forum ouvert (règle des deux pieds, bourdon, papillons), voire définir des éléments issus des Core Protocols (en partie et de manière peut-être moins formelle ?). En attendant, nous avons prévu de nous retrouver autour du sujet lundi prochain (nous avons décidé et imposer cela avec Élise). Nous verrons bien.

Point sur la pédago que je compte mettre en place. Intéressant, mais manque également d’histoires à raconter. Peut-être parce que je ne sais pas trop ce que nous allons réellement faire, à part tester des choses que j’ai en tête, peut-être parce qu’il ne faut pas trop rentrer dans le détail ? J’ai beaucoup insisté sur ma volonté de ne pas suivre une ligne, de ne pas dérouler un cours en laissant des gens derrière nous, mais plutôt d’avancer à la vitesse du plus lent.

Comment faire en sorte que les plus à l’aise soit heureux quand même ?

Tour de présentation : pas mal. Surtout en incluant toutes les personnes qui gravitent autour de Simplon. Possibilité de faire un peu plus formel en faisant en même temps une photo portrait ?

Repas. Bonne idée : ne pas être allé manger avec eux. Il faut leur laisser une zone et un temps de vie tranquille, garder une distance. Et puis pour le formateur, enfin pour moi, ça fait du bien aussi de sortir la tête du guidon.

Après midi sur les sujets vastes : qu’est-ce qu’un développeur ? Qu’est-ce qu’un logiciel ? Ce qui a bien fonctionné :

• leur avoir envoyé par mail les questions à l’avance,
• les faire travailler par groupe sur les sujets,
• mettre deux groupes par sujets.

Début de communication dans les groupes, échange, découverte de l’autre.

Un élève, à demander à faire/voir du code. Le groupe a apprécié et certains ont confirmé cette envie.

Le moins bien de la journée: le côté j’improvise qui apeut-être fait peur à certains.

Jour 2

Comme demandé, ce matin nous avons fait du code. Puisqu’un des paris c’est: vous donner les clefs que j’utilise aujourd’hui directement, sans passer par toutes les étapes que j’ai vécues, le code de ce matin sera en TDD. Après quelques explications de base autour de cette démarche, nous passons à un Kata FizzBu[zz en TDD en Ruby.

Le souci c’est qu’il faut expliquer chaque ligne puisque certains ne connaissent rien aux programmes. Mais les questions fusent et sont intéressantes.

J’ai, aujourd’hui, une sorte d’assistant temporaire(un ancien de la première promo), mais c’est dur d’avoir deux personnes qui répondent à une assemblée.

La configuration, deux personnes par ordi fixe, moi au milieu n’est vraiment pas bonne. Les binômes parlent entre eux, d’un côté ils n’entendent pas ceux qui sont de l’autre côté, et l’écran partagé via Google les a forcé à créer un compte.

Création d’un répertoire partagé sur Google Drive pour qu’ils puissent poser des documents (sûrement en vue de la restitution foad de vendredi). Problème encore puisque du coup ils doivent créer des adresses @gmail.

Comment sortir de google sur ces aspects ?

Après avoir mangé, création de groupes autour des sujets:

• la chaîne de fabrication du logiciel
• les OS (Systèmes d’exploitation)
• les faits marquants de l’histoire de l’informatique

Peut-être qu’il aurait été intéressant de faire plus de groupes et tous sur le sujet des faits marquants pour partager plus d’infos et d’éléments.

Ceux sur l’OS semblent avoir appris beaucoup de trucs mais n’arrivent pas à tout exposer.

La chaîne du logiciel est un sujet un peu bof.

Certains me parlent de soucis pendant la matinée sur les échanges et la compréhension. Je l’ai aussi ressenti.

Un élève absent aujourd’hui, et il n’a prévenu personne. Nous avons essayé de le contacter Élise et moi au téléphone, puis par email, mais rien.

Jour 3

Vu qu’une des compétences les plus importantes pour un développeur c’est la lecture de code (qui représente certainement autour de 80% du temps), nous essayons ce matin un exercice de lecture de code. Sur github, j’ai ouvert la page des projets la mode (sûrement ceux qui ont reu le plus de marque d’intérêt, mélangé avec une activité autour des commits et des issues), ouvert des projets au hasard, puis clique sur un fichier au hasard. Puis je lai distribué chacun.

Comment faire une retranscription pour la FOAD de cet exercice ?

Dans l’après-midi:

Nous avons fini le tour des revues de code. Mais le manque de dispo et la digestion ont bousillé un peu le truc. Ensuite nous avons fait la restitution de la prez sur les OS (pas eu le temps la veille). Ensuite ils se sont répartis, pendant que j’étais en réunion d’équipe, sur les sujets suivants:

• Les réseaux
• Les acteurs du logiciel
• Les moyens de distribuer le logiciel (mon souhait est de parler de comment le logiciel passe du dev à l’utilisateur, mais il semblerait que ça a été mal compris ?)
• Les licences

Demande de signature du doc de droit à l’image. Une élève, ayant fait du droit lit bien le truc et propose des changements pour que ce soit mieux. Il faudrait faire signer ces documents avant la rentrée, faire le dossier administratif avant.

Il n’y avait plus de papier les jours précédents, il a fallu aller en acheter nous-mêmes, du coup ils signent les feuilles d’émargement seulement maintenant. Faut-il tricher et les faire tous signer tout le temps, mais les moments où ils n’étaient pas là ?

Le nouveau vidéo-projecteur est arrivé, nous pourrons faire un essai demain, dans une configuration un peu plus groupée. Je pense que je vais demander si l’un d’entre eux veut essayer.

Beaucoup d’élèves ont amené leur machine… Est-ce que les forcer à travailler sur un fixe à deux est une bonne chose ? Je tiens bon en pensant que oui.

Toujours pas de nouvelles d’un des élèves. Nous avons statué en réunion d’équipe de lui donner un ultimatum: si aucun signe de vie jeudi midi, nous le considérerons en dehors de la formation et contacterons les 3 personnes qui se sont signalées pour le remplacer.

Jour 4

Point agenda en arrivant. Ça donne de la visibilité, c’est à refaire en mode +7 jours au moins.

Réalisation des entretiens pour les formatrices pour l’Arabie Saoudite. Pas préparés, pas assez d’éléments pour pouvoir vraiment expliquer le projet et répondre aux questions des candidates (malgré la présence de la chargée d’essaimage). Du coup, discussion tech et découverte de deux personnes intéressantes.

Début d’après-midi, je continue les entretiens one-to-one avec les élèves.

Les restitutions sur les sujets «réseau», «licence», «acteurs du logiciel» puis «mode de distribution» se sont bien passées. Un petit bémol sur réseau qui était un peu long et ne racontait pas une histoire (dommage), ça manquait d’un angle.

Faut-il définir l’angle ou l’histoire dans l’énoncé ?

La partie sur les acteurs est resté trop en hauteur. La case qui m’intéressait était un élément parmi d’autres : chef de proj, dev, designer, testeur… Mais ça nous apermis de parler de juridique. La présentation licence juste avant y est peut-être pour quelque chose ?

“Peut-être faut-il définir un peu plus le sujet, et prévoir un ordre de déroulement pour maitriser un peu les orientations que peuvent prendre les discussions (forcement influencées par la présentation précédente ?)”

Toujours pas de nouvelle de l’élève manquant. Conformément à ce que nous nous sommes dit en équipe, j’ai contacté les trois candidates potentiels, à voir si elles répondent.

Jour 5

Petit point sur mécanisme de la journée (façon rétrospective):

1. Intro: bonjour…
2. Récolte de données: mettre un ticket dans le tableau pour chaque truc que vous avez appris
3. Nous sélectionnons ce que nous aimerions transmettre
4. On rédige

Ce coup-là ça a été assez simple: une douzaine de sujets abordés dans la semaine, du coup, tout est pris en compte. Discussion poussée autour du tu ou vous, en prenant les dimensions :

• Tu parce que la personne qui va lire sera seule derrière son écran, nous essayons de créer de la proximité du coup, pour l’encourager et la motiver
• Vous pour créer un effet communauté, groupe. Nous élèves en présentiel, nous nous adressons au vous, groupe énorme des élèves distants. Vous êtes aussi un groupe de Simploniens.

Finalement, nous avons opté pour le Vous.

Une introduction a été rédigée. Cela prendra la place de la description de session (wording à changer sur simplonline). C’est une sorte d’édito hebdomadaire. Il faut ajouter dedans «le mot du formateur» histoire de montrer la présence et l’appui du formateur :-)

Je me demande comment ils vont extraire de l’information à transmettre quand on codera tous les jours ? Mais j’ai bon espoir que nous trouverons une solution. Je pense que nous proposerons beaucoup de code.

Les échanges/discussions sur les sujets préparés sont assez intéressants. Il faut garder ce format en le réduisant durant la formation: une présentation/discussion par jour après le repas. Cela permettra d’avoir 4 petits cours/discussions théorique pour la foad du vendredi. Le reste sera rempli par du code, ou un truc appris par le code.

Très agréable de se sentir appuyé/aidé par quelqu’un, dans ce cas : Laure.

Passsé pas mal de temps à faire de la paperasse administrative (doc d’entrée en formation). Il faut faire ça avant la formation, c’est sûr, ou alors avec une personne pour aider.

Jour 6

Je suis en retard ce matin. Mais chacun travaillait sur son sujet de groupe ou sur une lecture de code.

Après la réunion d’équipe, petit tour de l’équipe pour présenter une nouvelle élève qui prend la place de celui qui ne venait plus (dont nous n’avons toujours pas de nouvelle). Rappel sur le fonctionnement, sur le fait que tous n’ont pas le même niveau et que c’est normal.

Je n’ai pas fait d’entrevue one-one aujourd’hui (dommage, j’avais un créneau). Il faut que je continue.

Certains élèves essaient d’installer Linux en dual boot.

La présentation sur les langages a été l’occasion de parler un peu code. Le point était très intéressant et bien fait. Ensuite, deux élèves nous ont parlé du code source qu’ils devaient lire.

Cette présentation et celle d’avant ont clairement montré que certains ont des difficultés. Il faut les rassurer, ré-expliquer, trouver les métaphores pour faciliter la compréhension…

Un lve a abord l’apprentissage de syntaxe et l’apprentissage via les tuto en ligne, en demandant si je voulais qu’ils en fassent ou pas. Je leurs aie expliqué que pour moi l’important n’est pas d’apprendre une syntaxe, mais de prendre le bon comportement, d’avoir la bonne curiosité, les bons réflexes, que les syntaxes changent, en plus d’être différentes de langages en langages. En rentrant chez lui, il a fait suivre ce lien la liste : LearnXInYMinutes (Ce site illustre très bien mon propos je trouve :-)).

Demain, du code.

J’ai oublié de faire signer les émargements.

Jour 7

Code ce matin. Il y a eu des discussions intéressantes et des répétitions autour de ce qu’est un test, un programme, comment on exécute tout cela. Et des discussions plus poussées autour de l’implémentation.

Il y a vraiment beaucoup de monde pour faire un kata : 24. Je sens que nous avons tous besoins de travailler en petit groupe.

Le côté un peu scolaire de la présentation autour d’un sujet me gêne. Je vais leur proposer de faire un autre format pour voir: une discussion autour d’un sujet qu’ils préparent s’ils le veulent, chez eux ou sur les heures libres/bonus, en mode café du coin. Il faut juste définir une personne pour la prise de notes (ou deux ?) pour garder une trace des échanges et pouvoir en extraire du contenu pour le vendredi.

Certains semblent ronger leurs freins, il faut que je les lance sur du concret. le risque c’est de perdre des gens en route. Quelle articulation pour travailler sur des pages html par exemple, sans les laisser complètement seuls ?

=> Hangout ? pffff encore du google.

Échange autour de irc/hipchat. Andreï m’a mis admin, je vais pouvoir gérer les chans, stocker des archives et créer ce qu’il faut pour la FOAD et le groupe. Hipchat sera peut-être plus facile d’accès pour les néophytes. Existe-t-il une alternative libre ?

Stockage de photos et autres fichiers pour la FOAD. En fait c’est le soucis drive en version production on va dire. Il pourrait nous manquer de travailler en simultané sur les documents, mais en dehors de cela, pas besoin de drive. Comment remplacer drive pour la partie saisie simultanée ?

Jour 8

Petit point autour de l’agenda et des changements autour du flow des journées:

• Mardi prochain (le 23), normalement visite de Mozinor (attente de confirmation et d’une heure).
• Mardi en 8 (le 30) à 11h, normalement visite d’ICI Montreuil (attente de confirmation de François).

Explication de changement à propos des travaux en groupe: arrêt de la présentation en mode exposé pour l’orienter sur une discussion autour d’un sujet avec un ou deux scribouillards. La justification: vu que nous allons faire du code le reste de la journée (en dehors du début d’après-midi), je préfère qu’ils travaillent individuellement, quand ils le veulent, pour préparer un sujet. Les sujets seront fixés à l’avance pour un jour précis de façon à permettre à chacun de préparer pour celui qu’il veut.

Ensuite, nous avons fait deux groupes: ceux qui ont un site (à leur nom ou au nom d’un groupe, d’une asso), et ceux qui n’en ont pas. L’idée étant de trouver qui sera coach, et qui sera disciple. Ensuite, proposition de faire coder devant les autres un des binômes. Deux élèves se lancent. Flop. Je prends la place de l’un d’eux. Finalement, ça se transforme en explication autour de HTML et CSS. Nous parlons des points principaux, basiques. Un peu trop type cours magistral à mon goût, mais peut-être qu’il fallait en passer par là ?

Les groupes se forment, et quand j’arrive à 14h, ils sont tous à fond en train de coder. Manger à l’extérieur me fait du bien, mais du coup je ne pilote pas bien le début d’après-midi. Je les laisse faire, j’ai des choses à faire pour le Hipchat sur lequel j’ai maintenant la main. J’invite les élèves.

Certains élèves s’entraident et semblent apprécier de le faire. C’est vraiment cool. Tous s’éclatent. Une élève a préféré se mettre à part pour faire un tutorial html/css: dash assembly. Les autres l’aident, elle me demande aussi de temps en temps. C’est déjà ça. Il ne faut pas qu’elle reste coincée. Je me demande aussi comment fera-t-elle en groupe et projet imposé ?

Mise en place, enfin au moins au mur, d’un planning rotatif sur les 15 prochains jours. Je ne l’ai pas annoncé à haute voix. Il faudra le faire.

Jour 9

Surprise ! il y a une dizaine de personnes des centres sociaux qui font un atelier ou je ne sais pas quoi. Du coup explication courte, sans le vidéo-proj. L’idée c’est de mettre en perspective ce qu’ils ont découvert hier avec html/css. Explication du serveur HTTP, du réseau et du fait qu’un développeur simule cette situation sur son poste. Une raison de plus pour utiliser un Unix pour développer. Explication de la notion de cache du navigateur, et des deux lignes de commandes permettant de lancer un serveur web local à partir d’un répertoire.

Ils doivent également regarder par eux-mêmes git et github. C’est trop. Git aurait suffi je pense dans un premier temps.

Explications sur le terminal et ses commandes encore. Deuxième round d’explications pour les retardataires et parce que certains n’ont pas pu entendre ce que je disais avant. Un peu de passage auprès de certains pour expliquer en live.

Début d’après-midi, on parle du web. C’est un thème très généraliste. Est-ce bien nécessaire d’aborder ces sujets de cette manière ? Nous parlons un peu de tout: serveur, protocole, sécurité, chiffrement, quantique. Nous replaçons aussi les éléments dans leurs environnements (html/css/javascript sur le client, les langages de programmation sur le serveur).

J’ai abordé les branches, je n’aurais pas dû. Il faut explorer des choses simples, des choses justes nécessaires. Les branches ne le sont pas pour l’instant…

Il restera github pour lundi prochain.

Le format explication le matin et mise en pratique l’après midi semble vraiment un truc qui a très bien marché pour aborder le HTML/Css. Il aurait été intéressant de pouvoir tester de la même manière aujourd’hui.

Est-ce que ce format n’est pas indispensable ? Est-ce que les katas ne devraient pas tre faits dans l’après-midi ? Nous verrons quand nous commencerons faire des équipes.

Liste des projets potentiels:

• Le SIRH libre (Contacter fred et voir qui souhaite être le bêta client)
• Le projet Tryton (clone openerp) spécial association (voir avec Catherine qui va venir aider à mettre en place un réseau)
• Scratch (regarder le code source, type, langagem difficulté ?)
• Autonomie (app de gestion CAE, prendre contact avec Majerti et Marlène). Qu’est-ce que Coopaname utilise ?
• Publify (moteur de publication)
• Site de Simplon.co
• Simplonline
• Gestion élèves (candidature, suivi,…)

Trouver des projets dans des technos autres que Ruby et Python, pour l’exercice.

Un des élèves semble vraiment très facile, très à l’aise… Qu’est-ce qu’il est venu chercher ?

Soirée surprise, mais logique: je suis embarqué dans les portes ouvertes pour répondre aux questions. La plupart parlent de la FOAD ou la présentiel. Laure propose de faire une page explicative, voir une interview, une FAQ,… C’est une bonne idée, nous verrons demain comment faire.

Jour 10

Présentation du planning rotatif. Mea culpa sur le fait d’avoir balancé trop de choses la veille: je n’aurais dû aborder que Git, pas Github, et ne pas explorer tout git d’un coup, mais une utilisation basique.

Liste des éléments appris dans la semaine, ajout des thèmes comme les fiches de lecture et l’article pour expliquer ce que c’est que simplonline.

Essaie de démarrer un screencast pour expliquer FizzBuzz en TDD. Outre le problème de matériel, il existe un autre souci: c’est moi qui était au clavier, pas eux. Du coup ils ne savent pas vraiment par où prendre le truc et ne peuvent pas vraiment expliquer cet exercice. Du coup ils décortiquent en texte avec bout de code en expliquant ce qu’ils ont compris.

Nous avons aussi statué sur le fait que les élèves distants seront majoritairement sous Windows. D’une part nous pourrons proposer de l’aide à ceux qui veulent installer linux lors des rencontres physiques, nous pourrons les encourager à le faire, mais en aucun cas les cours FOAD doivent servir à cela, nous risquerions de perdre trop de personnes. Du coup chaque outil installé, chaque langage installé devra faire l’objet d’un morceau de cours sur comment on fait l’installation sur Windows et sur Linux (voir sur Macosx pourquoi pas).

Du coup reprise encore du cours sur le terminal.

Quelques groupes à 4 personnes, mais cela semble rouler.

Est-ce que tous les élèves ont des projets de startup cachés ? Si oui, il faut proposer une autre formule plus axée sur les projets que sur le code, mais est-ce que nous savons faire ? C’est peut-être des conséquences de la première promo et de la communication autour de codeur entrepreneur du départ ? Comment rectifier l’image de la formation dev ? Est-ce que nous le voulons ?

Ce matin, découverte de cafard. Stéphie passe des coups de fil pour faire venir des gens pour nettoyer les cafards (devis), et pour le ménage, et bien j’ai pris du temps sur les cours pour appeler et demander des devis. Il y aura des visites la semaine prochaine pour faire des devis. J’ai peur que ce soit un peu cher, mais c’est indispensable.

Quelques échanges à propos du fait de faire participer tout le monde au nettoyage quotidien. Je pense que c’est très difficile d’impliquer tout le monde, et je n’ai pas envie de faire la police et le contrôle de tout cela. Je pense que les élèves ne sont pas ici pour ça, ils ont déjà tant à apprendre. Peut-être que leurs apprendre la vie en société fait partie de l’impact social que nous voulons donner ? Mais comment le mesurer ensuite ?

Jour 11

Rappel de la façon dont nous allons travailler : faire comme si nous étions des équipes de dev, et apprendre en essayant de faire. Ceux qui connaissent déjà devront aider ceux qui ont besoin de comprendre.

Deux gros morceaux à faire passer: Installation et framework web.

Pour parler de l’installation de Ruby (pour commencer), rappel de ce qui caractrise un langage:

• Syntaxe, et ce qui est important: savoir où est la doc et comment la lire, plus que de connaitre la syntaxe.
• Environment d’execution: compilé, interprété, semi-compilé ou pseudo-compilé, programme à executer et options de lancement.
• Gestion de librairie/dpendances: Pour Ruby: Rubygems, pour Haskell Cabal,

Démonstration de l’utilisation d’un langage, ici Ruby pour faire une application web. Rappel de l’intérêt d’utiliser des langages et de la programmation pour faire une app web: le coté dynamique.

Nous construisons une interface graphique pour FizzBuzz. Rappel des phases requtes http, html, flux de travail, gem. Explication de Sinatra et erb.

Certains décrochent, quelques questions quand même. Il faudra sûrement passer plusieurs jours à décortiquer tout cela, à le ré-expliquer. Que mettra-t-on dans la FOAD(Formation Ouverte À Distance) ?

Suggestion d’une boite à questions/idées anonyme avec période fixe pour lire le contenu. Je me demande ce qu’il y aura dedans ? Demain j’essaie de trouver quelque chose pour la faire.

Des personnes débarquent en nombre, je ne sais pas qui c’est sur le coup, apparement les gens de la SNCF. Ils prennent des photos sans demander, comme si on était dans un zoo, et que nous étions dans des cages… Bof bof et assez mal perçu par certains élèves.

Un exterminateur de cafard passe et confirme qu’il y a des cafards, il trouve des déjections derrière le frigo. Quelques explications sur ce qu’il faut faire et ne pas faire. Il enverra un devis.

Visite d’une entreprise pour le ménage. C’est moi qui me retrouve à leur faire faire un petit tour du local. Ils envoient un devis aussi.

Comment passer à la suite ? Faire des équipes équilibrées. Le concret permettra sûrement à chacun de mieux comprendre les échanges. Pour le moment c’est flou. Commencer à faire des randoris avec 8 personnes volontaire, et les autres qui regardent ? Je ferais sûrement l’essai demain.

Pas de news des associés pour le fablab. Nous allons rester à Simplon du coup.

Jour 12

Visite de l’écodesignfablab de Mozinor. Très sympa. Explication de l’historique, échange autour des principes et valeurs qu’ils véhiculent et sur le fonctionnement de leur fablab. Evocation de projet avec le numérique qu’ils aimeraient faire avec nous. Pourquoi pas, ça fait un projet de plus.

Visite de leur espace de coworking, juste à côté. Très chouette, belle vue.

Échange, discussion plutôt, autour des éditeurs de textes et des IDE. Nous listons les existants, puis en parlons un peu. Je ré-explique le but: il faut qu’ils cherchent un peu des infos par eux-mêmes. Je ne vais pas faire difusion de savoir à chaque fois. Ils n’avaient pas compris. Comment faire pour qu’ils sentent qu’ils n’ont pas assez préparé le sujet ? Il faut peut-être que je les laissent lancer des questions, s’ils n’en ont pas, on passe au sujet suivant… Peut-être que malgré les réticences, je devrais rester en mode exposé ?

Ensuite nous devons aborder les soucis technique, mais ça vire à l’explication des groupes. Ils stressent à l’idée de se mettre en goupe ont dirait. Ils n’ont pas envie de réduire le volume ? Trop installés dans une habitude ?

Nous passons un certain temps ensuite (je ne sais plus comment c’est arrivé là) sur l’aspect cycle de vie d’une application: ce n’est jamais fini, jamais définitif. La seule chose qui le soit avec une application ou un logiciel, c’est le moment où on le jette. Ah, si, nous sommes arrivés là car ils évoquaient la possibilité de changer de groupe quand ils auraient fini avec un projet…

Jour 13

Des volontaires pour coder, 6 personnes, pour faire un FizzBuzz en TDD. J’ai parfois l’impression qu’ils pensent que Fizzbuzz est un outil magique et mélangent un peu TDD et énoncé. Doucement mais sûrement le groupe s’en sort. Je parle beaucoup trop. Tous posent des questions auxquelles il faut répondre. En petit groupe ça sera mieux où nous mettrons nous pour faire les dojo ? Dans la cuisine avec un écran peut-être ?

Présentation d’un bout de code simple en Ruby. Une hash de paramétrages et une fonction de vérification que certaines conditions sont bien remplies. Simple mais bien expliqué.

Discussion autour de l’hébergement. Ça tourne un peu trop autour de moi qui parle et eux qui posent des questions, c’est pas assez classe inversée à mon gout. Je vais peut-être reprendre l’aspect présentation d’un groupe sur un sujet. Est-ce l’oppurtunité de mixer les groupes de code, comme pour le dojo ? Nous avons abordé des sujets variés et intéressants.

Puisque les deux prochains jours, nous ne pourrons pas accéder au local, je leur demandent de:

• Refaire FizzBuzz en TDD.
• Essayer de déployer leurs pages HTML sur github pages.
• Pour les plus courageux, essayer de faire un screencast en faisant fizzbuzz.
• Préparer les sujets de discussion. En y pensant, je crois qu’il faut vraiment revenir au mode présentation
• Lire du code que je vais leur fournir (ou un autre bout de code).

Lundi nous ferons la FOAD. Mardi nous ferons les goupes.

Dans cette optique des groupes, je leur demande de faire une auto-évaluation et une évaluation par les pairs. En mode radar, ils ont selectionné quelques activités nécessaires pour travailler en équipe:

• Langages
• Linux/unix/terminal
• Communication/travail en équipe
• Environnement de dev (git, editeur)
• Web (http, html, css)
• Anglais

en mettant c quand ils ne savent pas par quel bout le prendre, b quand ils comprennent mais on besoin d’aide et a quand ils arrivent à se débrouiller tout seuls. D’abord en le faisant pour soi, puis je redistribue les tickets pour que 2 autres personnes donnent leurs avis. Il y a eu des discussions, quelques tentatives de blocage, mais je crois qu’ils ont compris que le but est plutôt de vérifier que nous nous améliorons. Je vais compiler les résultats et les afficher pour constituer les groupes. Je vais essayer de faire une enquête par email pour avoir tout le monde, au moins en auto-évaluation.

J’ai oublié de parler de Lord Kelvin: on ne peut améliorer que ce qu’on mesure

Fin de journée à 16h, Hager commence le déménagement.

Jour 14

Hackathon Hager

Jour 15

Hackathon Hager

Jour 16

Comme prévenus, nous avons passé quelques minutes à tout remettre en place suite au Hackathon Hager. L’équipes est plutôt bien disposée pour aider heureusement.

Je ne me rappelle plus vraiment ce que nous avons fait d’autre.

La FOAD du coup… Répartition des sujets. Difficile après le week-end: la FOAD doit vraiment être faite la semaine des apprentissages. Il aurait peut-être fallu faire sauter cette semaine là et l’ajouter à celle d’après ?

Difficile de faire un screencast. Ils scénarisent mais rien n’est tourné le moment-même.

Jour 17

kataGarros en Ruby (l’autre choix était FizzBuzz en Python). Intéressant de les voir sur un nouvel exercice. Attention, certains parlent de fizzbuzz comme une technique. Faut-il varier plus rapidement les sujets ?

Fait les groupes. Affichage des autoévaluation sur post-it. On parle des projets en même temps (suite à demande). Faire les groupes avant serais bien mieux, quitte à faire des mouvements au fur et à mesure. De même que les projets doivent-être mieux préparés. Au final, nous reprenons les tickets d’autoévaluation pour masquer les noms et faire une répartition par niveau. Phase intéressante et qui fonctionne.

Les critères relevés par eux ne sont pas tous à prendre au même niveau: l’anglais, il faut en avoir un ou deux qui s’en sortent, pas besoin de faire un groupe équitable sur le sujet, même chose pour linux et/ou l’environnement de travail peut-être ? Nous basons, avec quelques élèves les groupes sur les critères web et langages, en s’assurant que anglais, com/équipe, env de dev et linux/term soit aussi corrects dans chaque groupe.

Répartition des projets par moi directement, un peu au hasard. J’aurais du faire complètement au hasard ! Les groupes commencent à discuter. Je décèle un groupe un peu limite. Analyse de situation: il manque les critères de leadership potentiel et de confiance en soit. Dans un groupe, 4 à 5 personnes en manque de confiance, avec un leader caché derrière. Alors qu’un autre groupe à 5 personnes trop confiante et potentiel leader. Faut-il changer les goupes tout de suite ?

Toujours pas préparé les visites/rencontre.

Peut-être qu’il faut découvrir les projets au fur et à mesure, en proposant directement une tache ou deux à effectuer, en mode présentation grand public ?

Peut demander à chaque groupe de présenter un projet devant les autres: c’est quoi ? ça fait quoi ?

Jour 18

Kata FizzBuzz en Python (l’autre proposition était un Kata Bowling en Ruby). Bien apprécié de voir un nouveau langage apparemment. Mais cela amène à des discussions longues. La mise en perspective est vraiment intressante.

Présentation assez courte (le délai l’était aussi) autour de l’agilité en général. Nous abordons un rapide historique. Intéressant pour introduire le management visuel pour la gestion de leurs projets :-)

Rendez-vous avec une porteuse de projet autour de la reforestation en Tunisie. Elle est partante pour travailler avec les contraintes énnoncées: pas d’engagement de résultat. Elle me parle de ces partenaires: World Wide Web Woman qui l’aident pour du financement et autres. Peut-être des embauches en sortie ! Nous faisons ensuite venir l’équipe pour parler du projet. Certains parlent de choses qui les intéressent: le marketing. Je rappelle qu’ils sont là pour faire le dev, pas le marketing :-). Bonne intervention de certains qui posent de bonnes questions. Ce genre d’interaction est vraiment intéressant. Il faut que nous arrivions à faire que chaque groupe échange avec un pseudo-client.

Mise au point avec le groupe en potentiel risque. Après une explication claire le matin de ma part sur ce que je pense, mes doutes, ils ont discuté ensemble pour savoir comment réagir. Ils me disent qu’ils sont partants pour travailler ensemble et voir où ça les emmènent :-) Cool. Nous bouclons ensuite sur leurs projets:

• Scratch. Pas de code source, plutôt orienté sur la version HTML5. Le but pour eux sera de faire un scnario basique sur scratch, puis de le refaire sur la version HTML5 pour voir quel différence il y a (et donc qu’est-ce que nous devons coder pour y arriver ?)
• Tryton. Impossible de trouver les sources et les bugs en 2 minutes. Nous devons voir Catherine demain après-midi pour parler du projet, de son projet (dérivé de Tryton pour faire un SAAS pour association) et peut-être pour qu’elle les aides à mettre en place le projet en mode dev/test.
• Simplon.co. Revoir le site de Simplon. Je leur demande direct de le faire sur Publify. Est-ce vraiment une bonne idée ? Un site statique généré par jekyll ou hakyll aurait été un peu plus intéressant peut-être ? En y repensant, Hakyll aurait été intéressant pour l’usage d’Haskell, mais Jekyll me paraît mieux. Je leur en parle demain !
• Fat Fre Crm. Exit. Trop de projets web déjà. Et ils voulaient du C (scratch semblait en C, mais vue l’orientation HTML5)
• Redis. En C, utilisé par beaucoup de personnes. Projet intressant. Je n’ai pas donné de consigne sur ce projet il me semble

Trop tard pour voir les autres groupes…

Comment faire une rétrospective chaque semaine pour chaque groupe ? En même temps qu’une planning de sprint ? Faut-il faire du flux continue sur les tickets plutôt que du sprint ? Faire installer un serveur d’intégration continue !

Jour 19

Temps de setup un peu long prévoir une machine spéciale Dojo. Pas beaucoup d’avancées dans le code. À la fin, prise du clavier pour exposer le principe de reprsentation d’une donnée, d’un élément. C’est finalement un cours express sur les objets en Ruby.

Point avec un groupe à propos de leurs projets.

Un premier groupe:

• Publify: prendre les bugs dans la liste. Nous en sélectionnons deux pour le moment.
• HacketyHack: plateforme pour apprendre coder en Ruby. C’est une plateforme crée par “_why”. Peut-être la plateforme correspondrais à ce que nous voulons mettre en œuvre ? L’idée est donc d’en faire une présentation aux autres. Et de prendre en considration que peut-être la FOAD/Simplonline pourrait tourner dessus.
• FOAD/Simplonline: Liste de bugs simple à corriger pour m’aider. Approche de la démarche autour du changement de design autour de la question le goût et les couleurs versus l’utilisabilitée du site. Travailler par block. Ne pas faire tout en une fois, mais définir une zone de travail autour d’une stratégie: faciliter la navigation, faciliter la sélection des auteurs…
• Piwik: Abandonné.
• Discussion pour la sélection d’un projet avec un client autre que moi au bout: Soit Ariel et la re-écriture de Pommo en Python, Soit un des projet Ushaidi.
• Présentation de Catherine au groupe qui doit travailler sur Trython. Echanges intéressants, présentation du son projet et discussion autour du logiciel libre. Ils ont des premiers trucs à actionner. Simplon pourrait utiliser ce projet pour essayer d’améliorer sa gestion. Il faudra également voir si le SIRH et d’autres entrepreneurs du Mouves du ¹⁰⁄₁₀ pourraient être intéressés.

Au tour du groupe suivant:

• Shoes: Abandonné. Faire du JRuby et oublier le projet original est dommage.
• GitlabHQ: Explication sur lutilit et lusage. Ils doivent dj essayer de linstaller puis rsoudre un problme.
• EtherPad: explication sur le fait de linstaller et de corriger quelques bugs.
• Peut-être une place pour prendre le projet qui ne sera pas retenu par lautre groupe: Pommo ou Ushaidi. Sinon, travailler pour OpenStreetMap dans le code, pas les cartes :-))
• EcoFabLab: Très emballé. Qu’est-ce qu’ils veulent, et pourquoi ça n’existe pas encore ? Prendre un rendez-vous avec eux pour qu’ils viennent visiter et discuter avec le groupe pour préciser le besoin. Nous abordons aussi l’idée d’un e-shop et surtout de l’envie de mettre du Arduino et autres connecteur et micro contrôlleur dans les objets produit.

Le groupe suivant:

• Point sur le projet AcaciasForAll (refosrestation Tunisienne). Définition d’un premier pas pour pouvoir discuter de la suite: fair eun formulaire simple pour uploader des données sur une plateforme. Formulaire en offline first.
• RefineryCMS
• Wiki des Petits Deb: essayer d’analyser le contenu. Prendre rendez-vous avec Tamer pour discuter des besoins.
• booktype: Abandonné, l’équipe n’apprécie pas trop le projet on dirait.
• LibreOffice: essayer de corriger des bugs.

Présentation sur les Bases de données. Bon programme, manque quelques éléments. Nous reprenons une liste des type SGBDR et NoSQL. Liste de quelques noms. Ajout également de type possible sur les NoSQL.

Sorte de mob programming sur l’installation de Simplonline. Et si à côté du projecteur on plaçait un PC fixe, connecté sur le réseau des élèves pour pouvoir faire les Katas, les démos, les prez et des scéances de mobprogramming ?

Les projets, c’est bien, mais mieux préparer ce qu’ils vont faire avec c’est mieux. Attention au piège des projets clients qui sont des projets qui démarrent de zéro. Ceci dit, c’est intéressant car plus évolutif comme difficulté. Un bon mixte des deux est vraiment intéressants !

Jour 20

Petit point rappel sur le fait que la FOAD s’ouvre lundi prochain. Donc en plus de faire les contenus de la semaine 4, il faut penser à relire, corriger les contenues de la première semaine.

Sur le tableau, liste des jours de la semaine, zone à propos des livres et des sorties, édito. Peut-être qu’il faudrait faire un format un peu plus retrospectivesque: leurs faire faire des post-its sur des trucs cool qu’ils ont appris/découvert. Les éléments comme les jours de la semaine, les sorties, les livres ne sont que des outils du facilitateur pour leur faire quelques points de refresh de temps en temps. Le faire par groupe ?

Petit point tête à tête avec certains élèves pour discuter de doutes et soucis qu’ils ont. Je ne comprend pas où nous allons est une des questions qui revient souvent. Faire un rappel à tous ?

Beaucoup de travail sur la plateforme pour reprendre du code fait à distance…

Jour 21

Petit rappel des règles de vie à Simplon Montreuil. Petit point calendrier et rendez-vous. Il y a des trous la semaine prochaine sur les échanges/présentations groupe.

Pas mal de travail en mode isolé pour la FOAD. C’est dommage, je m’éloigne des élèves du coup. Pourvu que ce ne soit que pour ce coup-là. Cette après-midi, encore des discussions avec certains qui trouvent qu’ils ne codent pas assez et que ce n’est pas assez concret. Je les aient laissé trop rapidement seuls sur les projets peut-être.

Faire les groupes/équipes dès le début en utilisant une (des ?) scéance radar compétences, présentation, «ce que je recherche à Simplon ?».

Accompagner un peu plus : kata le matin (d’abord moi au clavier, puis, petit petit, eux), présentation de sujet l’après-midi (ils ont du travail la maison alors, classe inverse ?), projet step-by-step. Ils prennent les projets une fois un peu sur les rails ?

=> Cela pose le problème du cheuvauchement.

=> Quand peuvent-ils partir travailler en groupe sur leur projet ? Avec plusieurs salles, on peut imaginer faire une salle commune dans laquelle il se passent du code commun en mobPrograming et certains peuvent aller travailler avec leur équipe dans une salle part.

Idée à creuser. Il y a en tout cas un passage à applanir : groupe, kata => projet sur du Logiciel Libre.

Jour 22

Modification de l’espace commun pour essayer de le rendre plus confortable. L’idée étant que je m’y installe pour être plus près et disponible pour les élèves.

visite d’Ici Montreuil. Très sympa. Je n’ai pas récolté les feedbacks encore, mais ça donne envie de faire des choses avec les résidents du lieu. Par contre difficile d’imaginer des interactions pertinentes pour le moment, à suivre. Découverte : ils sont en status SCIC ! En voil un truc pertinent !

Présentation du cycle de vie du logiciel. Présentation trop tournée sur les pratiques d’équipes. Nous avons eu l’impression de revoir la même présentation. Du coup grosse discussion sur ce que c’est la partie cachée du cycle de vie: la maintenance.

Ensuite, petit méa culpa de ma part sur le fait de les avoir lâché trop vite seuls avec 4 projets en leur disant: «essayez de corriger des bugs». C’était vraiment pas classe. Nous avons donc inauguré/testé un format de Mob Programming. Une équipe vient avec sont projet et nous essayons ensemble de passer à l’étape suivante. Nous avons aussi annoncé la suppression des projets annexes. Chaque équipe ne garde qu’un projet.

Certains ne jouent pas vraiment le jeux de l’équipe je trouve.

Jour 23

Encore une nuit à gérer le chat. Est-ce que c’était une bonne idée ? Quel intérêt ?

Kata du matin, nous abordons JavaScript avec Jasmine dans le navigateur. Il faudra faire un peu de JavaScript avec NodeJS plus tard. Le format est vraiment intressant. Par contre il manque l’aspect discussion sur un plan, une direction, une intention. Est-ce vraiment nécessaire ? L’exercice n’est-il pas de coder, lire du code, plus que de faire fonctionner le programme ?

Discussion autour de la veille techno. Finalement, ce n’est peut-être pas super intéressant. Beaucoup font déjà de la veille (ou on l’impression d’en faire). Faut-il utiliser certaines questions intéressante comme source de sujet.

Rendez-vous avec l’APEDEC et l’EcoDesignFabLab pour visite, et ensuite avec le groupe qui va travailler avec eux. Echanges ouverts, des choses à faire mais peut-être rien de sorcier. Projet à faire porter en partie par CoDev car ils ne veulent pas être en avant (pour fédérer plus facilement les autres fablab). Ils pensaient que Simplon pourrait porter, mais cela semble plutt fait pour CoDev (asso, fablab).

Debrief avec l’équipe. Ils partent sur une première app simple : documentation des projets au sein du fablab. Sinatra, basique. Ils ont besoin de recueillir des donnes pour savoir comment orienter le service. Comme expliqué, il faut faire un premier forumulaire très simple pour amener la discussion. Ils vont y aller la semaine prochaine Est-ce que je dois y aller aussi ?

Un peu d’aide pour l’équipe Tryton. Leur projet est vraiment bizarre par rapport ceux des autres. Faut-il faciliter la chose en faisant en sorte quils travaillent tous sur un style de projet commun ? Cette équipe pourrait travailler sur quoi ? Deux équipes travaillent sur des projets partant de zéro, l’une en Rails, l’autre en Sinatra. Les deux autres se partagent entre l’app de la FOAD (Rails écrit frachement) et Tryton (du Python, fork d’OpenErp, pas forcment web). Un peu dur pour la dernière équipe. Comment équilibrer ? Publify ? Re-criture de pommo en Rails ?

La question de la diversité des langages se posent également : s’ils font tous du Ruby, ils ne verront d’autres langages que au dojo. Faut-il imaginer leur ajouter des projets en Python par la suite pour quils voient d’autres source/contexte ?

=> Le groupe Tryton pourrait travailler sur un projet de gestion des élèves (de la candidature aux infos récoltées en cours de formation, de la gestion de la feuille de présence à l’autoévaluation…) et en Rails.

Jour 24

Rétrospective aujourd’hui, demain nous n’avons pas vraiment accès au local.

Nouveau format pour gnrer de la donne : chacun crit puis affiche ce quil a appris, ou aim dcrouvrir pendant la semaine. Cest un peu plus le format imagin au dbut. Des choses surprenantes apparaissent, et cest tant mieux. Sur une semaine de moins de 3 jours (lundi ayant t un peu beaucoup occup par la mise en ligne et du coup la relecture de la session 01, et demain tant une journe ESS), beaucoup de contenu sont apparu. Pour ressembler une retrospective il manque l’aspect implication de chacune via le tour de set the stage. À faire. Peut-être que des exercices de retro pourrait être détournés pour générer de la données.

Certains n’ont rien mis sur le tableau. Est-ce un problème ? Timidité, manque de confiance en soi, rien appris dans la semaine ? Faut-il les brusquer ? Les forcer à écrire un truc ?

Quelques soucis et dernier inscrits sur la FOAD. Vraiment pas très organisée notre histoire… Il faut penser à proposer une inscription avec solution de paiement directement sur la plateforme plus tard peut-être ?

Des photos qui disparaissent, mauvaise manip dans le FTP? Pas de backups… Mise en oeuvre d’un rsync avec le deuxième serveur. Il faut faire plus. Peut-être le moment de tenter à grande échelle le projet git-doc : un dropbox-like basé sur github. Il faudrait synchroniser avec le serveur distant.

Petit point avec l’équipe BBG’s : Vous êtes les seuls en Python sur un gros projet, sur mercurial et pas git, ça va créer un décallage avec les autres qui sont tous sur ruby/rails/sinatra et git. Est-ce que ça vous dit de prendre un autre projet plus en ligne avec ce que les autres font ? Ils sont d’accord. Ils héritent du projet élèves : suivi des élèves, de leurs candidatures jusqu’à un an après leur sortie de formation. Beaucoup de choses à mettre dedans mine de rien.

J’ajouterais des projets Python et autres le mois prochain

Trouver le moyen de rythmer des points avec les équipes, en mode planning & rétro si possible. Comment faire tenir tout ça en moins d’une heure ?

Je ne fait plus de point régulier en face à face depuis deux semaines. Cette pratique me semble pourtant très intéressante Il faut la garder, trouver le moyen de l’organiser, de la sacraliser…

Un élève a bien poussé pour que nous utilisions IRC plutôt que Hipchat, il a préparé un tuto, nous migrons.

Jour 25

La journée du Mouves: Le tour des solutions. ESS.

Le matin, atelier makesense, les élèves, ceux qui ont acceptés l’invitation, ne se sentent pas vraiment impliqué ou intressé. Certains changent avec les entrepreneurs.

Discussion autour du logiciel libre. Tous connaissent déjà, mais je lache quelques liens pour infos. Quelques échanges et questions. Finalement, les élèves ne sont pas mis à contribution. Une journée de perdu pour eux et pour moi. Les gens de l’ESS semblent content par contre. J’espère que ça nous permet au moins d’avoir un peu de sous pour payer du café et du sucre, parce que les élèves veulent lancer une caisse pour payer le sucre et le café…

Je suis de mauvais poil pour plusieurs raison, j’espère que ce genre de journée ne se refera pas un vendredi, voir pas dans les même locaux que la formation, et surtout sans moi et les élèves.

Jour 26

Kata Garros en JavaScript. Difficult avancer. Encore ce problme de comparaison de tableaux. En fait, il ne faut pas le faire en JavaScript. Il faut trouver une autre voie. Rodolphe ma fait un retour intressant: je leur dicte trop ce quil faut faire. Les laisser trouver une solution, et les aider la mettre en place. Lanne dernire (1er promo), je me mettais dans la boucle, est-ce que je doit me mettre dans la boucle ?

Pendant une heure ensuite, nous avons fait le commit sur Simplonline (et donc vue diffrents aspect de rails, de git et de github). Pas sûr qu’ils aient tous compris. Comment proposer un Mob Programming et faire en sorte que les autres puissent faire un truc de leur côté ?

Découvert à la réunion d’équipe que la TV vient demain matin et mercredi matin: comment gérer ce truc ? Faut-il faire cours ? J’ai peur de perdre du temps.

Évoquer aussi l’aspect Archipel en mode: nous pourrions peut-être nous y installer tout de suite ?

Reprise des cours pour découvrir comment on démarre un projet Rails. Trop de notions en même temps. Nous sommes sur le problème du démarrage de projet : trop de notions d’un coup. Je voulais les aborder au fur et mesure sur des points particulier au moment ou les problèmes apparaissent. En même temps, c’est plus clair en prenant dans ce sens, car il y a moins de notions directes sur place, ils construisent eux-mêmes. Le soucis est peut-être qu’ils ne font pas eux-mêmes vraiment. Ils attendent trop un résultat direct. Comment les faire patienter ?

Demain je testerais un nouveau kata et surtout de moins participer.

Jour 27

Ce matin, BFMTV. Ne souhaitant pas être filmé, je reste à l’écart. Rodolphe et là et ok pour jouer le jeux. Il fait un cours sur Rails et les formulaires. Il est tout le temps interrompu. Certains élèves ne souhaitent pas participer et se cachent. D’autres répondent aux questions. La formation devrait faire parler d’elle par ces réussite, pas parce que nous sommes «beau» à la télé.

Un groupe parle de HAML. Bonne présentation, j’ajoute juste une partie contextuelle. Quelques questions, mais ils semblent avoir saisi.

Nouvelles organisation suite aux remarques de Rodolphe: Je me mets dans la boucle, je fais le setup, et je ne dicte pas ce qu’il faut écrire, je me mets en mode je pose des questions. Cela semble bien fonctionner. Ils apprécient je crois et comprennent mieux. Par contre, Le groupe est trop volumineux, le dojo et certaines interventions devraient pouvoir ce faire en plus petit commité pour bien fonctionner.

Certains élèves ont parlé à Laure pour qu’elle me parle ensuite (ils me l’ont avoué, mais pourquoi pas directement ?), et nous allons mettre en place une sorte de table ronde. Utiliser un pseudo format retrospective ? Comment permettre à chacun de poser ses questions et à tous d’entendre les réponses ? À voir demain. Nous ferons ce point jeudi de 17h à 18h.

Jour 28

Ce matin, France24. Pas de cours, comme hier matin. Certains élèves jouent le jeu.

Après midi, une présentation sur JavaScript, mais ça part trop dans la syntaxe et le comment ça marche plutôt que dans le pourquoi ? Il faut que je pose des questions précises sur un sujet pour l’orienter.

Kata RomanToNumber en Javascript. Intéressant, mais long au démarrage. C’est bien de ne pas dicter mais poser des questions. Ils déclenchent une capture vidéo des kata maintenant

Kata NumberToRoman en Python. Ce kata assez simple est très instructif. Les élèves commencent à se sentir mieux on dirait.

Remonté par mail une série d’échanges d’IRC de personnes qui se plaignent un peu de la maigre qualité de la plateforme et de l’absence du prof et des fondateurs de Simplon, ainsi que du manque de suivi de progression.

Pour le premier point, a rejoint une discussion avec Laure qui propose de faire un partenariat avec 360learning’com et dutiliser leur plateforme. Ce qui me gne cest que cette plateforme nest pas libre, et surtout, je pense quelle ne nous permettra pas de faire ce que nous voulons au niveau des exercices (demander crire un fichier de test ET un fichier de programme). Mais cest peut-tre trop compliqu. Pour le forum, peut-tre faut-il brancher un discourse ? Peut-tre pourrions nous essayer de mettre en place une plateforme EDX ? Si je fait sauter mon envie de demander une certaine forme dexercice, je pourrais peut-tre ouvrir la porte dautres plateformes. Jtais parti sur lide davoir un truc tout intgr, mais est-ce quil ne faudrait pas avoir une multitude de morceaux qui font chacun un job bien ? Le wagon avait un simple discourse pour difuser les cours et chatter genre forum ?. Associ une instance Yose The Game, peut-tre que a pourrais faire le job ? Voir jouer avec un github ou un gitlab et leur demander de proposer du code selon un exercice texte simple, et automatiser le rsultat

Pour le deuxième point, c’est clair qu’il faudrait une personnes dédiée à la gestion de communauté. Elle pourrait faire d’autres trucs à coté sûrement, mais il faudrait qu’elle soit en permanence sur IRC et sur le facebook, ainsi que le forum. Une autre idée (pas forcement incompatible d’ailleurs) pourrait être de mettre une machine en libre accès chez Simplon, connectée en permanence sur le chat, avec un compte Simplonco ou un truc du genre, pour qu’à tout moment, une discussion puisse avoir lieu. Nous pourrions aussi mettre une webcam live ? Il faut déclencher une première rencontre physique rapidement.

Pour le troisième point, il faut que j’affiche un peu plus clairement la couleur, que je rappelle ce que je souhaite. Que je mette en forme ce que j’ai dans la tête…

Je me pose aussi la question des 4 semaines d’avance. Est-ce vraiment nécessaire ? Est-ce que nous ne devrions pas penser le vendredi aux cours que nous allons diffuser le lundi ? Que chaque élèves présentiel écrivent une sorte de journal de ce qu’il apprend, et que nous en fassions un cours ? Ça casse complètement ce que j’avais imaginé mais est-ce pour la bonne cause ? En fait ce que ça change c’est juste sur les 4 semaines d’avance : comment faire après la formation ? Que faire des cours déjà écrit ? (on peut les distiller…).

Est-ce que nous avons bien fait de faire cette FOAD ?

Jour 29

change téléphonique avec une connaissance (35 ans dans linformatique) pour lui demander quel tarifs les cabinet de recrutement pratiquent. Il confirme ce que je pense: 10 15\% du salaire annuel brut. Par contre il me prcise que de la part dune cole cest un peu louche. Je dois jeter un coup doeil la hacker school pour voir, leur business model semble tre bas sur cela ?. Il voque plutt le paiement pendant un stage (voir une alternance, on reviens cette ide). Je nai toujours pas regard le RNCP.

Ce matin, une élève a amené de la javel, elle à encore vue des cafards sur la cafetière. Ils doivent repasser ce soir. Nous nettoyons un bon coup ce que nous pouvons: verres en plastique, frigo blanc, canapé, poubelle et le placard/étagère noir qui est rempli de truc et de cafard.

Session un peu en retard du coup et plus ou moins mob programming avec l’équipe «hackersLab», mais en fait tout le monde est encore là (ou presque, il y en a un qui reste à l’écart, comme souvent). Nous reprenons leur projet. Ensemble nous déroulons le fil. Un lien, un formulaire… Revue des principes de communication HTTP, présentation des helper de rails, rappel sur la structure des dossiers. De toutes façon, c’est ça le principe, répéter. Ils semblent intéressés et posent des questions intéressantes. Quelques changements derrière le clavier. A un moment il faudra vraiment se mettre en mode mob programming: un timer sur 20 minutes (ou autre), une installation qui va bien (table, pc fixe, assise)… Petit manque également: TDD sur projet web.

Début d’après midi, je prends les membres de la team «anonyme» pour parler de Simplonline et des branches dans git. Le but est de mettre en place l’utilisation d’une plateforme de dev/demo sur laquelle nous pourrions déployer tout le temps (continue) et tester, voir faire tester par beaucoup avant de livrer. J’avance assez vite, je fait des explications rapides, quelques questions. Je pense que tout n’est pas compris, mais ça à certainement déposé un premier vernis vraiment intéressant. Nous modifions ensuite le script de déploiement, ça donne à Aurélie envie de faire du bash on dirait :-), Mehdi lance une proposition de Dojo en shell.

Présentation des Design Pattern. Vaste sujet qui a avalé l’équipe «Gecko». Mais cela me permet de leur parler de design et d’architecture, indispensable pour faire un bon logiciel. Il faudra rappeler le design émergeant lié aux tests.

Table ronde pour poser des questions sur l’après Simplon. Un peu de crispation. J’amène assez mal le sujet. J’ai du mal à voir l’intérêt de cet échange. Mais peut-être que certain y ont trouvé leur compte ? En tout cas ils veulent le refaire…

Plusieurs retours sur le fait que nous devons être la première école/formation où l’on apprend le TDD ;-). Selon les résultats ensuite, nous pourrons en parler peut-être.

La prairie écourte les cours. Je fais un tour sur le chat. Je n’ai pas pris le temps de demander à Laure si elle est ok pour essayer de gérer un peu la communauté : facebook, forum et IRC. Je n’ai pas non plus proposé l’idée de mettre une webcam live (pas pointée sur les cours… ou si ?) avec un ordi connecté à IRC avec un compte simplon…

Plusieurs ont remarqué des erreurs dans le cours sur l’installation de Ruby. C’est en cours de reprise.

Jour 30

Pour la première fois, nous essayons un outil de réstrospective. Cela fonctionne bien, ils vident un peu leur sac. Le soucis c’est que c’est long, et certains sortent, prennent une pause, s’absentent. Espérons que la prochaine fois, ça soit un peu moins long (moins de tickets). Ce qui est intéressant, c’est que ça ressemble à ce que nous avons essayé la veille en fin de journée, mais en plus structuré et peut-être du coup plus efficace ?.

Certaines actions remontent :

• Pour pallier à la sensation de manquer de temps, et pour pouvoir en faire plus, nous découpons les journées en tranches horaires. Deux le matin, trois l’après midi avec des pauses entre chaque.
• Je vais faire en sorte que nous gardions du mou (des tranches horaires vides) pour qu’ils puissent ensemble travailler certains aspects vus ensemble. Ça devrait me permettre de moi souffler aussi un peu. Mais je vais surement passer du temps avec eux malgré tout…
• Ils doivent nettoyer leur table le soir avant de partir
• Nous devons monter une machine avec irc et une webcam branché pendant la journée (10h -> 17h) Comment fait-on du live ?
• L’équipe qui faire l’édito choisi l’histoire de la session, sélectionne les chapitres à écrire.
• Nous limitons les contenus (en faire moins, mais mieux). On s’assure que deux personnes réalisent les contenus (pas moins)
• Seules les personnes qui ont un truc à partager participent à la rédaction. Ceux qui veulent apprendre en participant doivent maintenant le faire en relisant le contenu produit.
• Des problèmes de volumes sonores et d’organisation sont encore apparus, commen l’année dernière: IL FAUT TROUVER UNE SOLUTION POUR LE LOCAL

J’avais espéré tirer des éléments de contenu pendant la rétrospective, mais bon, tant pis.

Après une pause déjeuner, nous avons donc refait le jeu du qu’est-ce que vous avez appris pendant la semaine ? qu’avez vous envie de partager ?. les sujets sont beaucoup plus limités. Cela permettra peut-être d’ajouter des choses au dernier moment.

Je pense que les 4 semaines d’avance c’est trop. ça nuit un peu à la dynamique. Il faudra faire moins, peut-être juste une semaine d’avance.

La plateforme est pas complète. Je me demande si un truc à la stackoverflow serait intéressant à la place du forum… Le lexique aussi est un peu dommage, un moteur de recherche et le stackoverflow pourraient suffire !

Laure exprime des inquiétudes sur le fait que les contenus ressemblent trop à des articles de blog. C’est vrai qu’il y a une part d’article de sortie ou de livre qui peuvent être un peu limite. Il faut être vigilant sur les autres articles. Nous évoquons aussi ensemble les formats et l’opportunité de faire une petite vidéo pour nous présenter, ou nous voir en action. Est-ce qu’un élève ou deux ne seraient pas OP pour faire ça ? Je n’ai pas évoqué le côté webcam live à Laure à ce moment là, mais ça pourrait aussi faire sont petit effet :-)

J’ai évoqué à Erwan et Laure mon intention de préparer une présentation sur ce que nous faisons en cours. Je la roderais à Paris’rb, mais cela concernant le #mobProgramming et les #dojo de dev, je me permettrais de la faire tourner plus largement ensuite. J’espère que cela préparera certaines boites à recruter des élèves de chez nous.

Les référentiels de formation posent encore problème. Mais comment contourner cela ? Est-ce qu’une explication de nos méthodes n’est pas suffissante ? Les aspects d’évaluation sont également mis sur la table… Nous avons besoin de trouver des solutions, mais pour ça il faut connaitre le vrai problème : la «root cause».

Faut-il compter les jours du type hackathon Hager dans les jours de formation ou bien devons-nous décaler ?

Jour 31

Rencontre avec RezoSocial Entreprise de Service Numrique (dition de logiciel, infogrance) dinsertion. Structure intressante, orientation sociale. Un peu comme nous (Simplon) mais plus quali que quanti Leur statut dentreprise dinsertion leur permet de bnficier dune assistante social une fois par semaine. Nous devrions essayer de mieux prendre en compte ces aspects.

Début de Mob Programming avec l’équipe qui travail sur la FOAD. Style principalement. Nous passons pas mal de temps faire le setup. Ça sera vraiment bien avec le serveur LDAP et le NFS. Allez Catherine !

Nous avons revu des aspects simple sur la visualisation des cours, discuter CSS, revue un peu le dashboard. Echangé sur les aspects plus long termes comme le fait de remonter le contenu utile, celui de pouvoir ouvrir un dialogue clair avec l’utilisateur. Peu de personnes travaillent avec nous, mais l’équipe semble contente.

Jour 32

Arrivé à 10h et des bananes, peu de monde, tant pis on commence avec ceux qui sont là. Frustration de ne pas arriver à faire le kata. J’ai le sentiment qu’une élève n’a rien compris mais n’ose pas le dire (il y en a peut-être d’autres dans ce cas). Après l’exercice, je lui demande en apparté, elle me confirme qu’elle n’a rien compris du tout. Ce n’est pas la première fois. Que doit-on lui proposer ? Une ré-orientation ? Mais comment tiendra-t-elle encore 6 mois de plus…

Le ménage a (enfin) été fait, ça sent bon.

Pause déjeuner rapide, puis on continue sur une présentation Lean Canvas intressante, Quelques changes avec ceux qui sûrement souhaitent monter une boîte ensuite.

Après la pause, nous faisons une session Mob Programming avec l’une des équipes qui a l’application de suivi d’impact social. Ils n’ont pour le moment rien fait, nous devons commcencer de zéro. Je leur fait remarquer que je souhaite qu’ils apprennent des choses, mais que ça aurait été cool qu’ils fassent un truc sur cette app. Deux élèves notent tout, même les morceaux de code que je code… La prochaine fois ils prendront le clavier. Que faire avec les élèves qui restent en retrait, voire à part ?

Je dois préparer un bout de texte pour que chaque invité ait une idée de ce que j’attends d’eux et de ce que nous faisons chez Simplon. 4 personnes de la FOAD sont présentes, ça fait plaisir ! Tout ce déroule bien. L’expérience est vraiment bonne ! Ça me rappelle les formats de présentation du wagon (1er promo). Peut-être que se mettre en mode interview serait sympa ?

Jour 33

Le monsieur du ménage à refermé derrière lui, Une élève qui voulait venir tôt s’est retrouvée bloquée à la porte. Appeler l’ESAT pour leur parler de ça et surtout, en parler demain au monsieur !

Kata Roman to number en Ruby. Mise en place rapide pour se mettre dans les bons rails. Est-ce vraiment bien ? Peut-tre que ce matin a leur montr autre chose que les premires lignes. Toujours les mmes qui participent Comment impliquer tout le monde ?

Kata morse to text. Ça parait simple, mais peut-être pas tant que ça ? Une idée de kata à faire avec du son peut-être ?

Ce matin, un échange sur facebook fait parler de lui: beaucoup de ceux qui suivent la FOAD sont perdus, il y a même quelqu’un qui demande un remboursement via le formulaire. nous concluons avec Laure qu’il faut que je prépare un message dans lequel je vais expliquer ce que nous faisons, la pédagogie que j’utilise, et le pourquoi ils peuvent effectivement se sentir perdus. Il faut aussi revenir sur ce qu’il leur à été promis: Pour devenir développeur, il vont devroir travailler beaucoup beaucoup !

Je me demande vraiment si cette FOAD est à refaire ? Il faudra faire un sondage en fin de formation pour voir, je pense que la plupart ne la recommanderont pas.

Présentation des frameworks JavaScript front. Intéressant, permet des échanges sur le sujet.

Ensuite, pas de candidat pour un Mob Programming. Je vais traiter de l’administratif qui traîne.

Au moment de partir, en descendant dans la salle, des questions: Rester dans la salle dans l’après midi pour éviter cette effet retard sur le départ ?

Jour 34

Il semblerait que plusieurs des élèves, quand ils racontent ce qu’ils font à Simplon, font des envieux et/ou des intéressés. Comment faire des conventions de stage et/ou des alternances pour que les élèves puissent avoir une rémunération, et peut-être nous aussi par la même occasion ?

Kata lags en Python. Très intéressant de voir le passage du « je met des if partout » à « je découvre les boucles ». Est-ce que finalement ce n’est pas sur des aspects d’algo qu’il faut suivre une progression ? Pas sûr.

À la pause, discussion avec une élève qui à des soucis sur son approche, son organisation. J’essaie de lui faire comprendre qu’il faut qu’elle aille à l’essentiel, qu’elle ne cherche pas à tout comprendre dans les moindre détail (elle cherche à comprendre toutes les commandes shell alors que nous n’en utilisons que 3 ou 4…). Du coup retard pour la session suivante, nous ne faisons que quelques échanges vocaux.

Pendant le repas, nous abordons avec Laure et Élise le fait que la FOAD n’apporte pas ce qu’elle promet. Nous en reparlons dans l’après midi en évoquant le fait que pour la rendre intéressante, il faudrait avoir un prof dédié, donc un salaire de plus, alors que là, pour ce montant, nous n’avons pas atteind le nombre d’inscrits que nous voulions (si nous enlevons les inscrits via la campagne Ulule qui ne pourra pas être un outil renouvelable). La question en fin de promo devrait donc porter sur Souhaite-t-on continuer pour pouvoir donner un accès à une initiation au code et une communauté et du coup trouver les moyens de compléter ce coût ou bien faut-il tout simplement arrêter et chercher d’autres sources de financement pour que la formation longue reste gratuite ? Pour le moment je pencherais pour deuxième option, mais c’est discutable.

Début d’après midi, le groupe n’est pas prêt pour parler des navigateurs, nous évoquons donc ensemble ce qu’ils souhaitent faire ensuite : une majorité affiche une option recrutement, certains parlent de devenir indépendant et 3 ont un projets de startup. Je parle ensuite des CAE, mais je me demande si c’étais une bonne idée… Certains sont intéressés, mais vu les résultats d’avant, ce n’était peut-être pas nécessaire. Nous pourrions quand même faire venir quelqu’un de chez Port // ou Coopaname pour en parler. Est-ce qu’avec le projet Maidai cette option création de CAE ne prend pas une tournure différentes ? A méditer.

Un élève à mis un ticket en évoquant l’envie de travailler en tant qu’Admin Sys. Je crois qu’il ne sait pas trop ce qu’il veut, mais je vais voir si je peux l’aider à se faire embaucher dans le domaine. Pour le moment il reste à son bureau (il est installé à une machine) et regarde des mangas et les Simpsons… Attention à un autre élève en difficulté de communication qui traîne souvent avec lui…

Travail avec Laure sur le texte pour répondre au soucis apparu sur Facebook. Difficile mise au point, échange sur des aspects futur non pertinents sur le problème présent, mais c’est très intéressant.

Assistance à l’équipe des «anonymes» qui travail sur la FOAD justement. Ils finissent des modifications sur le dashboard.

Jour 35

Préparation de notre séjour à l’Archipel avec Alix : gestion des tables et camion de déménagement, de la cafetière, de la bouilloire, des câbles et autres vidéoprojecteur. Nous ferons tout cela lundi matin, une autre demi-journée de perdu.

Rétrospective. Des points intéressants autour du fait que certains sont perdus. Utilisation de deux outils pour signaler un soucis, une incompréhension : je lève la main pendant, ou je mets un post-it sur le mur pour en reparler plus tard. Je crois que certains ne sont vraiment pas en capacité à aller chercher par eux-mêmes, à apprendre, découvrir…

Le plan de FOAD est très léger. Une des équipes est quasi au complet en relecture. Est-ce qu’ils n’ont vraiment rien appris ? Faut-il casser ces équipes ? Peut-être que de les avoir fait trop tard, d’avoir recruté trop largement (des personnes qui ne savent pas forcement se débrouiller pour demander de l’aide ou comprendre les instructions claires) empêche un fonctionnement en équipe. Apprendre à travailler en équipe est vraiment important, mais est-ce que dans leur cas, l’équipe n’est pas le groupe entier ? Est-ce que dans une classe nous pouvons faire plusieurs équipe ? L’idée pourrait être de faire tout les lundi un tirage au sort de binôme, mis dans un ordre aléatoire. Puis chacune viendrait choisir un tâche (listé auparavant par mes soins) qui pourrait être la correction d’un bug ou l’ajout d’une fonctionnalitée. Ensuite, les après-midi seraient consacrées à ces scéances de travail, avec la possibilité pour chacun de venir faire une session commune de travail en mode MobProgramming (d’autres binômes pourraient-être invités) pour débloquer des situations.

Mais peut-être faut-il garder les groupes, et si l’un d’entre eux est en difficulté, il faut juste travailler un peu plus avec eux peut-être ? Résoudre leurs difficultés. Il y a un groupe en particulier qui à des difficultées. Si on reste en équipe, il faut remodeler ce groupe, et pour le faire, il faudrait modifier aussi les autres, est-ce qu’ils l’accepteraient ?

Si le but c’est: Apprendre à travailer à deux, et comprendre la gestion de projet ça peut fonctionner de faire les binômes. Si le but c’est apprendre à travailler en équipe, avec les parties de gestion de projet, priorisations, il vaut peut-être mieux rester en équipe.

Tout cela pose la question de que fait-on pour les deux équipes ayant des relation avec un client extérieur ? Je décide que c’est un faux problème.

Pour la FOAD, La contrainte temporelle de produire du contenu toute les semaines est un peu tendue. Elle génère du stress et des écarts. Passer dans un mode « je fais un blog amlioré durant ma formation », en mode « au fil de l’eau » est-elle une meilleure idée ? Elle serait en tout cas plus proche de la réalitée. Et chaque élèves pourrait partager quand il le sent, quand il a envie, ce qu’il apprend. Le formateur aussi pourrait partager ses impressions quand il le souhaite. Le délai dun mois nest pas non plus une bonne idée : cela nous gêne pour pouvoir être réactif. Est-ce que finalement nous ne pourrions pas faire un blog simplement ? Associer des exercices de code, avec des outils de relecture de code et validation à la façon de Gerrit, avec des choses comme Exercism, ou Yose the game ? Il faut ajouter un Shapado ou Discource pour permettre des échanges comme StackOverFlow. Peut-être que plutôt qu’un blog, un discourse pourrait faire l’affaire !

Une belle rétrospective en gros. Bizarre de faire une retrospective personnelle en même temps que celle des élèves, très perturbant.

Jour 36

Ce matin, rendez-vous à l’Archipel. Visite et discussion, il ny a toujours pas internet. Les gars qui s’en occupent court après Fred depuis un mois apparement ?

Avec Alix, nous partons louer un camion pour récupérer du matériel informatique qui servira surtout pour la formation référent numérique, et aussi un peu de mobilier qui nous servira tout de suite. Pendant ce temps les quelques élèves qui sont venus sont dans la chapelle. Beaucoup de poussières, je crois que certains ne viendront pas à l’archipel.

Beaucoup de temps perdu, à peine l’occasion de faire une rapide présentation de Haskell.

Doit-on compter ces journées comme cours ou pas ? Même question que pour les interventions TV et les hackathons qui empêchent l’accès au local.

L’agencement «bureau avec des petites pièces et une grande principale», voir une deuxième pour la partie nourriture et repos semble vraiment parfait.

Jour 37

Arrivé tôt à l’Archipel. Rangement des affaires déménagées le lundi. Beaucoup de merde, des étagères inmontables, du matériel informatique un peu collector, des livres anciens (informatique) et des classeurs vides…

Kata Morpion en Python, en deux phases: aprs la pause nous avons continu ! Surprenant et intressant. Il faudra le refaire en partant de linterface graphique la prochaine fois, dune manire gnrale, il faudrait faire a maintenant pour faire le lien avec les projets en cours et ajouter un peu de motivation. Raccourcir la boucle de feedback.

Il manque pas mal de matos à l’archipel. Mais en dépannage, on se débrouille pas trop mal. Il faudra quand même faire une liste pour déclencher des achats. Le routeur semble bousillé, nous n’avons pas réussi à le faire marcher.

Un lve nous prsenter le binaire, lhexadecimal, le moyen de convertir, et rapidement le calcul. Quelque dbordement sur wiresh[ark. Les s](https://www.wireshark.org/)ujets qui viennent deux sont assez intressants, une lve voulais faire un truc, je lui ait propos de travailler sur les types dans les langages. Prsentation base sur le volontariat au bout dun moment, cest srement le mieux faire pour rduire la voilure et donner plus de temps pour le code.

Longs échanges sur la façon de faire les projets. J’évoque mes problèmes:

• pas de livraison
• niveau hétérogène dans les groupes
• pas de lecture de code

Ma proposition était de faire un seul groupe de 24 avec tirage au sort des paires, dans un ordre aléatoire, puis chacun choisirait à son tour une des tâches restantes de la liste que j’aurais préparée. Le jeudi restitution/présentation devant tout le mode.

Une alternative est proposée : Garder les équipes, faire des vrai sprint, définir les sprints après avoir faire la démo le jeudi après midi. En 4h il faut avoir fini. C’est faisable, ça résoudra peut-être le soucis de livraison et j’espère mettra la pression sur les équipes pour travailler ensemble. Point à surveiller : est-ce que cela ne déclenchera pas des tensions dans les équipes ?

Pour la lecture du code, je vais utiliser le concept du tirage au sort de paires, que je brancherais à des programmes à lire, et ils feront une présentation dès que c’est fait, le midi, nous pourrions voir 4 à 8 présentations de code. Mettre en place cet outils, avec la possibilitée à terme de saisir les commentaires de code directement sur la plateforme ? Se baser sur les relecture de code peut-être ?

Rodolphe a rencontré un des fondateurs de pullreview à Paris.rb. Ce dernier aimerait que nous nous en servions. Je n’ai pas envie, je ne vois pas l’intérêt. Des outils comme CodeClimate, pep8, et autres existe en librairies diverses pour chaque langage. Je préfère donc utiliser de l’open source, adapté aux divers langages que nous allons utiliser (pullreview ne propose que du Ruby pour le moment).

Petit dojo en fin de journe sur n[umber to roman ](http://codingdojo.org/cgi-bin/index.pl?KataRomanNumerals)en Ruby. Sans moi. Ils sont tombs dans le pige de faire I, puis II, puis III Dur ensuite de reprendre le bon sens

Jour 38

À 10h, peu de monde et à 11h Fred doit venir pour parler avec les élèves, du coup on fait un mode questions/réponses large. Cela permet de revenir sur les objets instances et les classes, sur un peu de shell/terminal et autres.

Fred leur parle un peu de ce qu’il se passe à Simplon : Archipel, Essaimage, et de ce qu’il pourrait y avoir dans le futur. Des points réguliers sont annoncés, une idée de truc pour Noël évoqué, une rando au col du Simplon aussi… Certains élèves demandent des formations sur le community management et autres trucs un peu hors du cursus dev. Pas de soucis, on peut prendre des créneaux pour ça. Nous parlons aussi de la partie média, Fred parle d’organiser des scéances de média training. Hmm.

Après la réunion d’équipe, nous abordons groupe par groupe un petit point de situation projet, avec ensuite une série de tickets à faire pour le sprint qui viens. Jeudi prochain, démo et livraison de ce qui à été fait. Je reste sur l’idée que ça ne change pas grand chose à deux soucis : lecture de code et gestion de groupe/équipe. Le code + la gestion d’équipe, c’est très intéressant à aborder, mais tellement dur. Les faire coder en binônme, avec une gestion ouverte de la grosse équipe (équipe complète) me semble toujours plus intéressant. Mais là au moins je peux temporiser.

Il manque, pour pouvoir les faire travailler par paire, la gestion de la fin de travail et du commencement d’un nouveau travail. Comment faire ? En une fois, tous ensemble, c’est intéressant pour partager les résultats (bon ou mauvais), mais ça peut prendre du temps. Au fil de l’eau ça pose le problème du la rotation des équipes. Est-ce qu’une paire doit attendre qu’une autre au moins ait terminé pour pouvoir faire une rotation ?

Je vais travailler sur un outil de lecture de code par paire, en commenant sur la problmatique de gnrer des paires. Est-ce que je me base sur la librairie existante issue du wago[n ? P](https://www.lewagon.com/)ourquoi pas :-).

En fin de journée, nous avons essayé de travailler sur les projets, mais sans internet (ou en tout cas sans débit suffissant pour un groupe tel que le nôtre), c’est difficile. Nous partons donc pour faire un dojo rapide en Haskell sur ma machine (qwerty). Je crois que les élèves apprécient de découvrir un nouveau paradigme. Nous abordons un truc oublié dans la présentation de lundi : le pattern matching.

Pas d’enregistrement, il faut que j’installe Istanbul sur ma machine pour pouvoir faire des screencasts.

Jour 39

Nous sommes aujourdhui à l’Open World Forum (dont le nouveau nom est Open Source Summit). Amusant de voir certains arriver discuter avec des exposants et trouver potentiellement des entretiens

Beaucoup de questions : comment doit-on se vendre ? À quel poste peut-on prétendre ? Mettons en place ce moment/atelier pour les aider à y voir clair, et les préparer à ça.

Ils sont très intéressés par le programme de demain, nous reportons la FOAD et la rétrospective soit à lundi, soit on la fait sauter. Nous déciderons lundi.

Dans ce genre d’événement, je pourrais présenter l’orientation apprentissage par le code source ouvert que nous mettons en place. La lecture du code source pour apprendre, une des libertés du logiciel libre…

Quelques retour d’élèves qui apparement on des retour positifs sur le contenu de leur formation (dojo, mob programming, libre, projet, langages varié).

Une belle confrence sur l’IRILL éxpliquant qu’ils travaillent à fédérer des industrielles, des chercheurs et le grand public autour du logiciel libre. Ils sont intresssé par : - les boites qui peuvent les aider (financièrement et autres), - les enseignants qui peuvent partager (moi et mes pratiques peut-être ?), - les étudiants pour participer.

Nous pouvons surement utiliser leurs sujets comme étude de cas pour travailler

Jour 40

Les élèves sont retourné à l’Open World Forum. Je prépare le tableau d’information pour leur retour, je réponds à des emails…

Jour 41

Petit point matinal sur le planning, rappel de notre séjour à l’Archipel prévu pour jeudi et vendredi prochain. Évocation de la partie chasse aux blattes. Décision de le reporter au lundi 10, nous faisons le pont, le mardi 11 tant férié. Cela laissera juste le mercredi en mode pic-nique.

Plutôt que de faire la rétrospective et surtout la FOAD, les élèves préfèrent faire du code. Je me demande dans quel mesure les remarques sur le forum et autres ne les démotivent pas sur ce sujet…

Point aussi sur le tableau d’info avec les tickets à faire avancer.

Nous reprenons du code simple pour essayer de faire raccrocher certains. Python sur NumberToRoman du coup. En expliquant chaque étapes. Pour aller plus doucement, je ne participe pas. Après une pause, nous attaquons un RomanToNumber en Haskell. Intéressant.

Aprs le repas, Une lve se retrouve seule pour prsenter Go J[e ](https://golang.org/)la charrie un peu, mais elle sen sort bien. Elle fait une introduction et je complte. a nous permet de revoir des aspects bas niveau: gestion mmoire, pointeur. Je la chauffe en lui proposant de faire une dmo: un kata FizzBuzz. Nous arrivons crire quelques lignes, cest vraiment sympa. Ensuite, chacun essaie de faire avancer un ticket dans sa ligne.

Je continue de penser que le travail d’équipe est mal amorcé avec eux. D’ailleurs, est-ce que c’est en leur demandant de faire une équipe autonome que je vais vraiment leurs apprendre à travailler en équipe ?.

Nous voyons ensuite 5 personnes de chez Tigerlily. Ils nous exposent leurs faon de travailler avec P[ivotal ](https://pivotal.io/labs)et les pull requests. Est-ce que je devrais utiliser un outil dans ce genre pour leur assigner du travail par paire ?

Les soucis dans une organisation type une équipe de 24 personnes qui travail en paire ou plus, c’est:

• Comment faire les équipes ?
• Quand les renouveler ?
• Quand et comment faire les démos/restitutions ?
• Sélectionner le travail à effectuer ?

Faire les équipes et très dépendant des autres points. Pour faire les restitutions, le mieux serais un peu comme nous allons le faire jeudi prochain: tout le monde passe en une fois. Cela permettrais ensuite de regénérer des équipes/pair puis de les laisser prendre les taches à effectuer.

Reste comment faire la liste des trucs faisable ? Prendre un créneau ou deux pour faire la selection.

Les restitutions, pour bien fonctionner devraient se faire en… (7 * 60) / 12 = 35 minutes. Il faut prendre toute la journée et ne donner que 30 minutes à chaque paire. Dur dur dans certains cas je pense.

Nous verrons bien ce que donnerons les démos du jeudi prochain.

J’aimerais faire du flux continu, mais cela pose un soucis sur la façon de renouveler les équipes… Ce qui serait sympa c’est de ne pas limiter dans le temps, mais laisser les équipes essayer de fournir quelque chose. Au minimum une lecture de code dans un produit open source, au mieux un patch à proposer/accepter. Comment renouveler les équipes/pair dans ces conditions ? Peut-être en misant sur le fait que certains finiront plus ou moins en même temps. Les restitutions pourraient avoir lieu tout les débuts d’après midi, puis, on attend qu’au moins un ou deux autres équipes restituent pour regénérer des paires à partir de ceux qui ont terminé. A méditer…

Jour 42

Aujourd’hui, c’est un jour spécial, et pourtant nous n’avons rien fait de bizarre…

Quelques questions sur Git et Github (workflow de base). Ils ont besoin de voir et d’exprimenter sur le sujet. Puis un dojo en Ruby (fibo). Certains disaient: Facile ! mais finalement, ils n’ont pas fini.

Ensuite, petit tour sur Vim. Ils en entendent parler, ils veulent toujours le tester. Je leur explique que finalement c’est pas forcement le plus facile. Honte moi, je leur propose de faire du Emacs ! :-)

Ensuite, je passe de groupe en groupe pour fixer des problèmes. Beaucoup liés au déploiement !

Ils sont parti pour le Paris.rb, moi je vais voir les eXtreme Programmeurs :-) Dailleurs, Betclic qui sponsorise les pizzas de ce soir, qui fait principalement du .net serais assez intress pour:

• venir parler devant les élèves
• un membre de leur équipe, jeune, souhaite donner des cours
• les contrat pro, la diversité…

De très bon échanges, et du coup, j’aimerais introduire C# dans le cursus (via Mono !). Sinon, les échanges autour de Go donnent envie, une fois de plus, d’avoir l’occasion de pratiquer ce langage.

Jour 43

Comme d’habitude, il n’y à pas grand monde à 10h… Est-ce que je dois être plus strict sur les horaires ? Je crois surtout que je n’accepterais plus de remarques sur le fait de ne pas coder assez. Un autre point sur ce sujet, c’est le fait de parfois devoir répéter, non pas parce qu’ils n’ont pas compris quelque chose, mais parce qu’ils n’étaient pas là. Peut-être que pendant (ou à la fin de) chaque slot, les élèves pourraient mettre sur un post-it ce qu’ils ont appris pendant la session. Nous pourrions du coup tracer une sorte de cartographie de ce qu’ils ont vu faut-il le faire en individuel ? C’est une idée à méditer encore un peu sûrement, mais ça semble une piste intéressante pour effectuer du suivi (pour nous) et montrer un avancement (pour eux) ainsi que des référents potentiel autres que le formateur pour échanger sur certains sujets.

Nous enchainons sur les deux dojos mais en plus petit groupe: 5 personnes. Je ne me mets pas dans la boucle de la matinée, et je n’impose pas une liste de sujets, je les laisse le proposer. J’ai juste ajouté une proposition pour qu’ils fassent du go, mais ils n’ont pas voté pour. Peut-être que nous pourrions avoir une mécanique de hasard pour désigner un sujet plutôt ? Même chose pour les groupes qui passent. Cela forcerais certains à venir coder ? Faut-il les obliger ?

J’ai décoincé un groupe sur Rails (pas forcement les bonnes pratiques). Mais seul le groupe a assisté. Le soucis c’est que du coup je risque de répéter la même chose avec les autres groupes. Est-ce un soucis ?

Des élèves me reparlent de l’atelier CV, et en profitent pour revenir sur l’aspect plusieurs langages. Ils ont peur de ne pas être à la hauteur quand il faudra passer des entretiens. Je leurs explique que de toute façon faire 6 mois que du ruby, ou 6 mois de moins de ruby, mais de plus d’autres langage ne changerait surement pas grand chose pour les entretiens. Le coté plusieurs langages peut même être un atout. Ce qui est important, c’est la pratique.

Il faut d’ailleurs que je travaille sur cet aspect de groupe de paire aléatoire avec choix de ticket de travail qui me semble finalement plus pertinent que faire des équipes dans l’équipe. Ils ne peuvent pas tout apprendre, et la gestion d’équipe viendra bien plus tard ! C’est à moi de le faire pour le moment.

Demain nous serons à Archipel pour faire les démo de fin de sprint. J’espère pouvoir en reparler avec eux à ce moment là. S’ils sont ok, je pense que je peux gérer les paires par tirage au sort manuel, mais pour ce qui est des projets, il me faut surement préparer un peu la listes des bugs qu’ils pourraient essayer de corriger.

Jour 44

Archipel, analyse des résultat de sprint. Demo par équipe. Il est sûrement plus facile de faire des choses sur un existant que de créer quelque chose de nouveau. Une des équipe n’a pas fait grand chose (voire rien). Beaucoup de problèmes de groupe semble-t-il. Nous abordons quelques soucis avec eux, sans aller trop loin.

Réunion autour de la FOAD. Des orientations prises qui devraient rendre le travail un peu plus efficace. Espérons que ce ne soit pas juste des bonnes intentions.

Attention, j’ai passé trop de temps à faire une scéance de Mob Programming pour résoudre un soucis, au lieu de leur dire de revoir leurs copie. J’avais réussi à le faire jusqu’à présent, mais là, je me suis un peu trop laissé aller. Le dernier groupe est un peu expédié du coup. Il faut bien tenir le chrono pour pas déborder. Être plus attentif, un élève me l’avait dit, je n’ai pas réagi.

Ce qui est intéressant avec des scéances comme celle-ci, c’est que des sujets apparaissent dans les discussions. Comment faire des démos efficaces si je demande à tous de travailler en binôme aléatoire ?

Jour 45

Rétrospective un peu longue (démarrée tardivement ?). Puis travail sur les projets. Pour le reste, toujours les même soucis qui ressortent : pas d’internet à Archipel, c’est chiant, gestion du bruit et des interruptions à Montreuil c’est chiant aussi. Comment faire mieux ?

Pour le moment, gestion des équipes. Faire du travail par paire sera peut-être plus efficace. Nous pourrions aussi améliorer la gestion des présentations de langages.

Là ils préfèrent mettre de la lecture de code à la place d’un dojo. Je laisse faire. Ça pourrait être complémentaire avec le fait de gérer des projets libre l’après midi.

Quid des clients (acacias for all et apedec/eco design fablab) et de la relation avec eux ?

Jour 46

Le maire de la ville Roubaix et son équipe sont en visite dans les locaux. Il y a des travaux d’éléctricité qui amène des coup de perceuse. Du coup nous avons vite fini l’explication de code sur Go, puis chacun est parti se débrouiller avec son casque sur les oreilles. J’espère que demain ça ira mieux, mais cest pas gagné, jai vu du matériel en sortant. La zone cuisine n’est pas touché par les histoires de cafards, mais en fait nous en retrouvons encore plein (toilettes, cuisines). Peut-être faut-il tout traiter ?

En début d’après-midi nous voulons aborder les objets, méthodes et autres classes, mais la perceuse fait toujours des siennes. Nous avons donc repoussé les cours à 16h.

Je reste persuadé que faire UN projet from scratch n’est pas la bonne solution pour apprendre le code, c’est une solution de repli que j’ai mis en place pour répondre à leurs questionnements et la difficulté qu’ils avaient à aborder le code des autres (effet muraille infranchissable).

Je dois mettre en place un remplacement, fonctionner par paire. Beaucoup d’absents. Un décrochage ou bien un week-end prolongé ?

La difficulté pour faire les groupes c’est les sujets. Il faut que je liste des projets simples et utiles, qui peuvent nous toucher (ou toucher l’univers du dev) sur lesquels ils pourraient essayer de participer. Avec une deadline de 7 jours ou quelques chose dans le genre à l’issue de laquelle, au pire, la paire devrait présenter un bout de code du projet. Peut-être faut-il limiter les projets et les faires tourner, histoire qu’ils aient le temps de ce familiariser avec eux et leurs environnements ? Il faut des projets en Ruby, Python, Javascript (avec du NodeJS aussi), Haskell, Go. Bientôt nous pourrons ajouter Java et C#, il nous restera à ajouter Clojure, Scala, C, et Erlang. Les autres (Elixir, C++,…) pourrait être abordé en dojo, mais pas forcément en projet. Faut-il des projets pour chacun de ces langages d’ailleurs ? N’est-ce pas un peu trop ?

Jour 47

10h, pas grand monde (5 personnes). Du coup kata en Go avec les motiv et prsents. a se droule pas mal :-). Ensuite prsentation dune lecture de code Javascript sorti de la lib progres[sbar’js qui pe](https://kimmobrunfeldt.github.io/progressbar.js/)rmet de construire des animations de progression en SVG avec JavaScript. Intressant dvoquer ces points. Ils ont beaucoup explor, mais la prsentation nest pas forcement trs claire (le choix du bout de code prsenter ?). A force de lire du code ils dvelopperont un esprit critique sur le sujet et pourrons mieux choisir le code expliquer.

Après le repas, je voulais faire un rappel sur les objets, les classes et les méthodes. Sur une demande de leur part. Difficile car:

• après le repas, ils s’endorment,
• la question est floue et cache un autre soucis sûrement,
• je n’ai rien préparé (comme d’habitude).

Je dcide donc de partir sur le sujet du design de code. Jai le sentiment dtre un peu trop haut pour le niveau dattention quils ont. Aprs un rappel que ce que je fais cest pour eux, pas pour moi, je r-oriente lchange sur ce quest un programme : un outil de manipulation de donnes, et chaque paradigme utilise une faon diffrente de manipuler les donnes. Certaines questions random sur JavaScript et autres volent, cest vraiment trs brouillon. Nous coupons la prsentation. Ensuite je vais aborder lutilisation de gh-pages et des gnra[teurs de](https://pages.github.com/) sites statiques.

Plusieurs échangent en journée pour me dire que les groupes ne fonctionnent pas (ou équivalent). Faire une liste de projets et sélectionner une première session de tickets à faire deviens très important. J’espère que demain, pendant la FOAD, Laure s’occupera bien d’eux, cela me permettra de faire cette sélection. Il restera à tester le mode flux continu.

Je vais également modifier les tableaux pour revenir à une semaine flottante, avec agenda de base sur le côté, et exception mise sur la semaine tournante. Il faut aussi faire un tableau des tâches avec des colonnes:

• A faire
• En cours
• A Presenter
• A livrer
• A suivre
• A revoir
• Fini

C’est moi qui place des tickets dans la première colonne, C’est eux qui choisissent le ticket à faire, il le passent à présenter ensuite, et ce n’est qu’après qu’il faudra le livre (pull request ou livraison).

Un petit tableau à deux entrées pourrait accueillir les tickets nommés (ajouter le nom du binôme sur le ticket ou bien avoir un truc à part ?) Comment faire un suivi ? Comment faire en sorte que deux paires ne se retrouvent pas trop souvent ?

Jour 48

Dur travail de mémoire pour se souvenir de ce qu’ils ont appris durant ces 12 derniers jours ! Nous n’avons pas pu faire de FOAD depuis 2 semaines et demie. En essayant de remplir un calendrier des choses effectuées, certains se rappelent de choses et d’autres.

Laure viens prendre le relai pour présenter et organiser la FOAD pour essayer de faire un parcours.

Je passe une bonne partie de l’après midi à faire de la prod sur la plateforme de la FOAD pour résoudre des soucis et ajouter la feature qui permettra d’organiser les contenues comme convenu par Laure et Mathilde. Livraison en deux étapes. La première devrait avoir lieu ce week-end, et la seconde en fin de semaine prochaine (évitons l’effet nouveau contenu de lundi soir).

Jour 49

Nous partons pour essayer de faire un Sudoku en [JavaScript.](https://developer.mozilla.org/en-US/docs/Web/JavaScript)[ Ce](https://en.wikipedia.org/wiki/Test-driven_development)la permet daborder le ct visuel puis le ct code en TDD. O est la limite entre les deux. Mais nous avanons vraiment doucement.

Est-ce que je devrais me baser sur ce qu’ils choisissent et sur leurs connaissances pour choisir les logiciels sur lesquels ils pourraient intervenir ?

Beaucoup ne sont pas présents à 10h le matin, beaucoup ne participent pas aux exercices, pourquoi ?

Les entretiens individuels doivent avoir lieu sous peu : mardi prochain, je vais préparer des questions simples que je vais leur poser en avance, et l’entretien aura pour but de discuter des réponses et d’écouter leurs avis. Les questions possibles pourraient être :

• Que penses-tu de ton niveau ?
• Que penses-tu de ta participation ?
• Que penses-tu de ton assiduité ?
• Que penses-tu faire après la formation ?
• Que voudrais tu faire pendant les 3 mois qui restent ?

La dernière question est dangereuse car laisse ouverte la possibilité de changer, ce que je ne compte pas vraiment faire. Peut-être que les 4 premières suffisent ? Quel but a cet entretien pour moi ? pour eux ?

C’est un moment en tête à tête, où l’on peut exprimer beaucoup de choses. L’objectif pour moi serait de savoir ce qu’ils souhaitent faire ensuite individuellement pour commencer à placer (alternance ?), puis faire un point sur la situation de participation et de niveau… Je pense effectivement que les 4 premières questions sont les bonnes, en commençant peut-être pas la 4ième. et en fondant l’assiduité dans la participation peut-être… Je dois me noter ces questions pour ne pas oublier les objectifs pendant les entretiens. Est-ce que je squatte le bureau du haut ou je demande le salon d’Erwan ?

L’après-midi, nous parlons des API… ils dorment un peu j’ai l’impression. Ensuite nous reprenons le Sudoku. Est-ce que demain nous recommençons à zéro ? Est-ce que nous pourrions faire un morpion pour changer et aller plus vite ?

Il n’y a pas eu de discussion d’argent : combien peut-on demander à un client dans ce cas-là ? Combien pourrait-on demander à un client plus tard ? Dur de savoir… Combien vaut la formation que l’on dispense actuellement ? Aucune idée.

Je me demande s’il ne faut pas trouver un format différent, plus long ou au moins plus adapté à chaque entreprises. Nous pourrions renverser la vapeur en faisant une sélection forte des entreprises pour lesquelles nous formerions des développeurs (voir plus tard, fusion des formations ?) Idée tordue, mais à explorer peut-être… Le hic c’est la lisibilité plus dure si les frontières se dissipent.

L’autre orientation possible c’est faire de la prod en mode insertion. Faire des apps et être payé pour, faire des app sociales, trouver des idées et les mettre en oeuvre (idée originale d’Andreï et Erwan non ?).

Jour 50

Arrivée tard, les élèves préfèrent travailler sur les tickets et les présentations qu’ils ont à faire. J’en profite pour régler des points administratifs.

Démarrage aussi d’entretiens individuels, J’en ai vu 5. Je discute avec eux de :

• Leur situation par rapport à leurs attentes.
• Leur participation individuelle, dans leur équipe, dans le groupe, dans le groupe + moi, dans Simplon.
• Leur sortie de Simplon : que faire après ?

Nous abordons aussi d’autres sujets. Pour le moment j’ai fait les 5 les plus faciles en quelque sorte. Disons ceux avec qui je n’ai aucun problème humain ou de gestion. Pour certain, ça va être plus dur à passer je pense. J’espère pouvoir voir tout le monde rapidement.

Ensuite, deux élèves nous ont présentés du code Python dans le contexte de la librairie PyGames. Très amusant pour la peine. Faut-il traiter plus de jeux pour intresser ?

Jour 51

Ce matin, retard encore, mais nous démarrons un Kata Morpion en Ruby à 10h45.

Avec une presque nouvelle équipe de 5 (c’est un max finalement), nous partons donc sur une nouvelle façon de mettre en oeuvre ce kata morpion en Ruby: avec beaucoup plus d’objet. Un objet Morpion qui gère la grille et permet de savoir si un joueur est gagnant… Très intéressant car nous revoyons les objets, les attributs et des principes de base.

L’après midi est utilisée pour faire les entretiens individuels. J’en ai vu encore 5. Il me reste encore 11 personnes à voir.

Jour 52

Démo ce matin. Très peu d’équipes ont vraiment livré quelque chose. Est-ce parce qu’ils savaient que je voulais changer la façon de faire ? Je leur explique ensuite comment ça va se passer pour eux maintenant:

• Formation d’une paire
• Sélection d’un ticket
• Une fois fini: présentation.

Définition du fini :

• marre de travailler ensemble, mais nous pouvons au moins présenter un bout de code
• nous pensons avoir fini (bug fixé, feature livrée, présentation prête)
• nous n’y arrivons pas : présentation du code ou de ce que nous avons appris.

De mon coté, il me faut :

• sélectionner des tickets,
• sélectionner des sujets,
• suivre les tickets (pastille sur chaque post-it chaque jour)

Simplification de l’agenda rotatif : une semaine seulement, journée type affichée à côté. Nous n’affichons que les exceptions dans le planning.

J’espère que ça redonnera la motivation à ceux qui l’on perdu, en tout cas, ça devrait donner plus de rythme.

Jour 53

Encore une fois, pas grand monde à 10h… Nous attendons un peu. Nous faisons finalement la rétrospective. Je vais faire un email pour prévenir des nouvelles règles du jeu: après 10h30, si pas prévenu du retard, pas la peine de venir, si un vendredi absent sans avoir prévenu, pas la peine de venir la semaine suivante. A valider avec le staff car peut-être que cela peux nous faire perdre des sous de sub ?

Ensuite, je les laissent faire du contenu et de la relecture, mais ni Laure ni Mathilde ne sont là en fin de matinée. La reprise sera pour le début d’après-midi.

Je profite de cette après midi pour faire passer quelques entretiens de plus. Il m’en reste 7.

Jour 54

Ce matin, un peu plus de monde que d’habitude. Le petit mail un peu sévère a eu de l’effet. Par contre, je n’applique pas ce que j’ai dit que je ferais. Je ne renvoie pas les élèves chez eux s’ils arrivent en retard sans prévenir. Par contre je ne fais signer les feuilles qu’à 10h puis à 14h. Nous verrons bien.

Rappel sur le planning de la semaine, mercredi nous serons lAg[ile Tour Paris ](http://at2014.agiletour.org/fr/paris.html)

Kata [JavaScript](https://developer.mozilla.org/fr/docs/Web/JavaScript) sur un automate pour rendre la monnaie. Cest un peu laborieux, effet du lundi ? [Mais nous abordons des su](https://fr.wikipedia.org/wiki/Code_smell)jets intressants autour des mauvaises ordeurs de code. Les deux sessions sont sur le mme sujet, nous reprenons le code. Faire cela chaque fois pour voir plus de choses diffrentes ?

Aprs le repas, point avec les lves, en mode sta[nd-up meeting. T](https://en.wikipedia.org/wiki/Stand-up_meeting)iens, cest pas mal, mais eux taient assis, le refaire en leur demdandant dtre debout ? Je fais signer la feuille de prsence. Je lai laiss passer cette aprs-midi, je devrais peut-tre la suivre pour pas que certains signent pour la journe complte.

Je les laisse travailler sur leurs sujets. Je pense que certains sont dj prts mais nose pas le dire Esprons que demain a sera autrement. Grosse runion dquipe avec le staff (1h30), cumul un peu de retard aprs le repas et paf, nous voil rendus linvit du jour : Stphanie Ouillon,[ team scurit mobi](http://www.duchess-france[.org/ro](https://www.mozilla.org/en-US/)lemodel/stephanie-ouillon/)le chez Mozilla. Super intressant comme sujet. Bien sr, le sujet drive sur la place des femmes dans lIT.

Bon feeling du groupe en général. J’espère que ça va continuer.

Jour 55"

Ce matin entretien. En dbut daprs midi prsentation, une premire sur un bug sur Activ[eRecord, un ](http://api.rubyonrails.org/classes/ActiveRecord.html)peu dur, nous parlons un peu de transactionnel (soucis pour comprendre le[ bug et s](https://www.mercurial-scm.org/)on contexte). Puis rapide prsentation de Mercurial. Petit coup de main sur les maillers et la journe termine sur un apro FOAD.

Journée chargée, courte, avec pas grand chose à raconter.

Jour 56

Journée à l’Agile Tour Paris. Quelques déceptions, beaucoup de conférences tournent à la vente de produit. Dommage.

Jour 57

Ce matin, rendez-vous Société Générale dans les locaux, nous sommes repoussé un peu plus loin. L’activité démarre en retard. Après un petit point vers 11h, j’enchaîne sur un entretien.

Je passe un peu de temps ensuite à ajouter des tickets dans la liste. Il faut que j’en prévois plus le vendredi. J’espère aussi que les binômes vont tourner comme il faut.

Ensuite, je fais un peu d’administratif…

Jour 58

Rétro ce matin. Quelques retardataires, mais ils préviennent, nous les attendons. Les points que j’ai relevés sont:

• Agile Tour Paris: bof. Beaucoup de truc pas très intéressants, mais nous avons quand même appris des choses, ça fait du bien de sortir quand même.
• Toujours un peu brouillon. Proposition d’un projet fil rouge pour structurer l’information autour d’un projet. Les élèves (présent et distant) pourraient faire des pull request sur des sujets pour que nous puissions discuter de chaque proposition. Pour rester dans le multilangage, peut-être proposer un fil rouge en rails et un en Python ? Peut-être que les projets pour les deux clients ecoDesignFablab et Acacias pourrait être ceux là ?
• Encore des cafards
• Cool le nouveau format, genre enquête sur des bugs
• Aimerais devenir plus fort en refactoring => Ajout de tickets pointant sur des fichiers qui ncessiterais un refactoring. Un outil la co[de climate m](https://codeclimate.com/)ais pour plus de langage serait intressant.
• Intervenantes extérieures super

J’ai également vu encore 3 élèves en entretien individuel. Il me manque encore 2 pour avoir fait le tour. J’essayerais de le faire avant Noël.

Jour 59

Surprise en arrivant, une dizaine de personnes sont là. Il y a aussi Frankie, qui vient pour la semaine. Je n’ai pas trop compris l’histoire de pourquoi et comment il est là, comme d’habitude.

Nous faisons ce matin un kata en Ruby. Vu les esprits un peu embrumés, je propose Lags et RomanToNumber avec RSpec. Très intressant d’aborder RSpec. Mais il manque toujours le déclic pour avancer. Après la pause, toujours pas plus vivace, je prend le clavier pour un kata jeu de la vie. Je ne l’ai jamais fait, c’est l’occasion. C’est un krata, le chemin n’est pas clair. Arrêt sans avoir fini. Des pistes intéressantes autour de la manipulation d’objet. Mais embrouille entre la grille et les cellules. À revoir.

L’après-midi, visite de l’écodesign fablab, du coup je rate le skype sur EDX, j’avais zapé. Mais la mise au point avec l’Apedec est intéressante. Certains élèves sont parti pour préparer les stands des APIDays.

Jour 60

Élèves aux APIDays.

Jour 61

Élèves aux APIDays.

Jour 62

Pas beaucoup de motiv ce matin pour un dojo, effet APIDays ? Deux lves sont ok. Elles se lancent sur un sujet : faire un outil de censure. Amusant. On voque les DSL[, on](https://en.wikipedia.org/wiki/Domain-specific_language) essaie en deuxime partie den faire un, mais quand cest non prpar cest un peu une horreur Nous revenons ensuite sur le script de censure. Un point intressant de ce sujet cest de faire jouer un gnrateur alatoire pour faire les caractres de remplacement.

Faut-il faire des exercices de détection de code smell ?

Nous écourtons les présentations car l’invité arrive pour leur parler de son parcour.

Jour 63

Retrospective ce matin. Certains on envie de mieux situer leur niveau par rapport aux autres. Il y a des demandes de changements de formats du dojo (qui finalement se transforme en une meilleur préparation pour faire le dojo).

Aprs discution, je vais galement leur faire faire une journe sur Yos[ethegame. Ch](http://yosethegame.com/)acun pourra communiquer ou pas sa note Je dois galeme[nt travai](https://www.duolingo.com/)ller sur un duolinguo du code pour voir. Mais l jai du code faire.

Jour 64

La Poste en masse dans le local de Montreuil, du coup nous sommes envoyés sans internet ni chauffage à L’Archipel. Nous en profitons pour faire des révisions. Questions ouvertes, puis, point par point, nous travaillons dessus ensemble.

Jour 65

Rvisions encore aujourdhui. Nous attaquons par un gros morceau : Parseur. Jutilise souvent ce mot apparement. Cest normal, tout est parseur Nous regardons dans un cas concret : faire un gnrateur de CSS pa[rti](https://fr.wikipedia.org/w[iki/](http://le[sscs](http://lesscss.org/)s.org/)Feuilles_de_style_en_cascade)r de less (un moteur LESS, un parser LESS :-)).

Le singleton. Un élément de design pattern de moins en moins utilisé. Je montre quand même un exemple avec un fichier de configuration en XML et un object configurator en Ruby. Ça n’a pas de sens, mais c’est pour l’exemple :-)

Ensuite nous abordons des notions de render dans Ra[ils. ](http://rubyonrails.org/)Le contrlleur puis les vues partielles.

Nous faisons un ajout de fonctionnalit dans Acacias en permettant duploader une photo pour montrer comment faire. Certains simpatientent et souhaitent coder Et bien ils seront servis : le jeu de la vie en Go :[-)](https://golang.org/). Nous rencontrons beaucoup de difficults dfinir la faon de traiter le problme : juste en manipulant un tableau de cellules (cest trs objet), ou en manipulant uniquement la grille (dans un style fonctionnel). Jai limpression que la grille serait plus simple dans cette situation, mais nayant pas russi manipuler un tableau de tableaux, nous avons chang de direction en cours de route.

J’aimerais mettre mon journal dans un fichier unique doc sur le drive, comment faire ?

Jour 66

Nouveau format pour le dojo, suite à la discussion de vendredi pendant la rétrospective. A 10h, proposition de sujets par les élèves, vote, puis 1h pour préparer. A 11h, une équipe commence à coder dessus, puis à 12h on change d’équipe, potentiellement on repart à zéro ?

Au final, ce matin, 4 personnes prsentent 10h, dont 3 qui ne participe pas souvent au Dojo, donc la premire arrive annonce son sujet : faire un kata[garros en ](h[ttp:/](http://rspec.info/)/codingdojo.org/kata/Tennis/)RSpec. Cest celui retenu. Prparation sans moi comme convenu, puis une premire quipe (celle habitue des dojos finalement arrive) montre ce quils ont prpar. Des difficults, mais a avance. A 12h cest moi qui prend le clavier pour nettoyer lorientation, puis je laisse nouveau le clavier un autre binme. Mais nous navons pas organis de rotation.

Peut-être ne faut-il pas faire de randori ?

Cette après midi, ils travaillent sur leur ticket.

Jour 67"

Encore moins de monde ce matin pour choisir le sujet, du coup j’impose Lags en Python. Est-ce qu’il y a un soucis avec ce format ? À suivre demain en rétrospective.

Des difficultés durant le kata, je fini par prendre le clavier pour avancer. Est-ce que je devrais ? Ne faudrait-il pas plutôt commencer ensemble, échanger sur les possibles pistes, les laisser ensuite essayer d’avancer, puis débriefer ?

Présentation de Forem installé dans Simplonline. Des difficultés, mais une grosse partie du job à été fait ! Il faut faire le style et voir la gestion des divers utilisateurs.

Jour 68

Rétrospective ce matin. Les élèves m’ont demandés de participer moi aussi à la retrospective. C’était intéressant car effectivement, soit je devais en sortir, soit je devais y participer.

Par contre il va falloir gérer un peu mieux la transition.

Jour 69

Ce matin, divers rendez-vous extérieurs, du coup je suis en retard. Ils ont fait un kata WordChain : passer d’un mot à l’autre en ne changeant qu’une lettre à chaque fois, et retourner la liste des mots utilisés. Intéressant leur code, mais ils ont bouclé de la mauvaise manière :-)

Laprs midi, prsentations et discussions autour du code lcole et des outils dcouverts la prsentation chez Microsoft[. Puis, n](https://www.microsoft.com/fr-fr/)ous passons en mode rvision autour de diverses questions.

Difficile de les faire travailler sur les sujets prédéfinis. Ils souhaitent, pour certains travailler sur leurs propre projets. Je laisse faire. Je vais travailler avec ceux qui en ont envie. Tant pis pour les autres.

Jour 70

Je suis resté chez moi aujourd’hui. Les élèves ont fait un kata WordChain en Ruby avec RSpec et ont repris le how i start Go.

Jour 71

Les quelques lves prsents Simplon essaient de faire seuls un kata en Go s[eu](https://golang.org/)ls.

Jour 72

Le kata du matin à été choisi par un petit groupe, en mode concertation, et réalisé dans la foulée… pas vraiment de phase de préparation. Je me suis permis d’intervenir pour parler architecture et pour structurer leur programme, en rappelant des principes de base de limitation de responsabilités. Le format a bien tourné.

La présentation d’un fix sur GoHAML assez intressante.

Ce soir c’est la fête Simplon…

Jour 73

Peut de monde ce matin à la rétro. Nous parlons beaucoup du format des katas et un peu de la structure des tickets pour l’après midi. Les conclusions sont :

• Matin :
• Retour à deux sessions (peut-être le même kata avec une pause).
• Utilisation du même langage toute la semaine (défini par ceux qui sont là le lundi matin).
• Isolement dans le bureau du haut si nous sommes moins de 8.
• Sinon, dans l’espace commun, pas d’autres ordi que celui qui permet d’écrire du code.
• Pas de chrono, celle qui veut lâcher le clavier le fait, celle qui souhaite le prendre le demande.
• Après midi :
• Plus de binôme imposé, mais il est fortement conseillé de travailler à plusieurs (affichage du binôme sur le ticket)
• Définition de créneau prioritaire par jour (répartition des élèves sur les 4 jours productifs de la semaine)
• Pas rééllement de présentation, plutôt un passage public (pour ceux qui le souhaitent) pour parler/travailler/discuter de leur sujet
• Une aide par le biais de propositions

Cela laisse une plus grande autonomie pour l’après midi. A voir comment nous pourrons utiliser cela pour faire un peu plus de code, faire avancer les sujets. J’espère que cela n’isolera pas trop certains qui ne participent déjà pas beaucoup…

Beaucoup de discussion tournent autour de « On ma dit que… » ou bien des choses comme « Certains sont prensent que… ». Il y a des choses à désamorcer.

Jour 74

C’est la rentrée, nous mettons en place certains changement que nous avons décidé lors de la dernière retrospective:

Kata

Durant les Katas, nous ne faisons plus de rotation toutes les 5 minutes, et personnes n’est obligé de venir au clavier (au pire, c’est moi qui le prend :-)). Du coup, tout le monde est là pour regarder ou presque, Nolan et Damien reste comme d’habitude à l’écart… Nous choississons un langage pour la semaine.

Pour la reprise, la plupart choisissent Ruby, histoire d’y aller doucement. Le sujet est choisi en mode plus ou moins concensus (pas de vote), et nous partons sur un FizzBuzz avec interface graphique.

Projets/Ticket

Pour les tickets/projets, beaucoup plus de liberté également: priorité à 5 personnes par jour (6 pour le jeudi, il ne reste que 21 personnes qui suivent la formation 5+5+5+6). Si ils n’ont rien à demander/montrer/échanger, c’est libre, la personne qui à une question, qui veut montrer quelque chose peut le faire. Il n’est plus question de faire des PRESENTATION. L’idée est de permettre à chacun de travailler sur un truc qui lui fait plaisir. Je conseil quand même de travailler sur des projets opensource. Le nouveau tableau c’est: Les élèves avec un projet sur lequel il travail et le binôme associé. Plus la liste des élèves prioritaire sur chaque jour. Cela permet sur les zone libre de faire des révisions. Bien sur je garde un tableau avec des suggestions.

Deux élèves m’ont interpellé pour me parler d’un projet de suivi d’élèves dans les écoles (collège et primaire). Dommage que je n’ai pas pensé à leur dire de parler de cela devant tout le monde plutôt que dans un petit coin.

Jour 75

Ce matin, un peu de retard au démarrage. Il serait peut-être intéressant de regarder Rack ? Première partie toujours un peu laborieuse. Faire un setup de projet simple, commencer par un clone ? Pendant la pause, une question autour de la requête GET sur le / nous amène à une révision d’une heure sur le HTTP, les verbes, le navigateur et le serveur.

Après la pause, chacun travail sur ces sujets. Quelques questions autour de HAML, puis Chrisophe de PullReview arrive pour nous présenter (avec des slides, c’est une première !) sont parcour et ce qu’il fait aujourd’hui. Je dois partir tôt, mais il continue par une présentation de pullreview. Peut-être que sont utilisation pourrait être intéressante, si gratuite sur les projets open source. Les élèves qui vont au Paris’rb de ce soir l’accompagnerons normalement…

Jour 76

Ce matin, les partants commençait à regarder un kata lisant des données. Je leur ai proposé de faire un Kata appel du 18 juin. Ce kata lit un texte pour en apprendre la langue, puis doit être capable de générer un autre texte basé sur les probabilités trouvé dans l’analyse. C’est du machine learning. Assez intéressant, mais des difficultés à visualiser l’algo pour créer le dictionnaire.

Cette après midi, des questions autour de design, d’icone et d’emploi. Puis Eric Mahé nous à parlé de programmation parallèle. Sujet passionant.

Jour 77

SlowKata ce matin. Priorité à ceux qui habituellement reste sur le coté, sans forcement poser leurs questions. C’est intéressant, nous allons doucement, mais ça avance quand même un peu. Kata RomanToNumber avec interface graphique.

L’après midi, présentation de Docker. Bien faite, avec des exemples. Je pense que beaucoup n’ont pas compris, mais je leur signal que ce n’est pas très grave. Présentation ensuite sur le langage C. Très intéressant (surtout parce que finalement je ne connais pas ce langage :-)). Un fizzBuzz avec CUnit :-).

Ensuite, nous travaillons à plusieurs sur une application en rails d’un élève. Une sorte de blog. Nous nettoyons un peu le code, nous ajoutons une ou deux features, et il prend note de certains liens et piste pour avancer sur d’autre sujet. Cette partie de mob programming était finalement du binômage publique. Dommage ! Comment faire pour que tout le monde soit présent ? Est-ce bien ?

Jour 78

Rétrospective intéressante mais pas de grand changement. Une sorte de rendez-vous en début d’après midi pour évoquer ce que chacun fait, les besoins en binomes, et faire un petit teaser de ce qu’il va se passer l’après midi.

Quelques échanges autour de la FOAD, c’est de plus en plus une galère pour eux.

Le SpeedJobbing d’hier soir, bien qu’autour uniquement de Ruby, à permis à certains de se rassurer, de reprendre confiance. Commencer à prendre rendez-vous avec des recruteurs pour qu’ils viennent proposer des offres.

Jour 79

Réunion avec Matodzi, formatrice pour le simplon.co afrique du sud. Elle semble faire plutôt du php et ne pas forcement être rodé aux pratiques agiles. Sympa, mais peut-être un peu méfiante (normal). Pendant ce temps, les élèves, avec un peu de retard, choississent Javascript comme langage de la semaine. Il démarre avec un Kata RomanToNumber qui se déroule plutôt bien. L’après midi, nous commençons pas un petit point sur les envies de chacuns, et nous en profitons pour annoncer (et afficher) qui souhaite, ou bien n’est pas contre, avoir un binome pour travailler sur son sujet.

Jour 80

Ce matin, beaucoup de retard de la part de certains, et des difficulté à trouver un sujet. L’idée viens alors de faire du node. js. Nous explorons pendant l’installation les concepts de base. Puis nous nous lançons dans la construction d’un site qui afficherais les pire films à voir ! Après la mise en place de base, nous explorons l’architecture à mettre en place, ce qui nous vaut de grandes discussions, et de nombreux échanges/questions. L’après midi, présentation des serveurs d’intégration continue avec comme exemple, Jenkins et Travis. Quelques échanges et pistes pour travailler sur du refactoring dans Publify (un sur le notification mailer, et un sur le base helper). Nous n’étions pas beaucoup aujourd’hui. Les élèves ET le monde. Dans le local il y avait du calme et du silence, c’était vraiment très appréciable ! Par contre ce matin, Erwan est venu me demander s’il pouvait venir dans le local avec une 20aine de personnes d’une association d’insertion, pour leur montrer l’occulus et l’imprimante 3d, et au final, il c’est fait déborder et ils sont tous venu nous regarder, comme au ZOO. C’était une sensation assez désagréable.

Jour 81

Le kata de ce matin: slow kata. Nous discutons beaucoup autour de la problématique de smell code. La capacité à sentir le code dois être traviallé, afiné. Beaucoup plus de monde aujourd’hui dans le local, c’étais vraiment moins bien car beaucoup plus bruillant. La nouvelle configuration par contre permet un peu plus d’intimité pour le groupe qui souhaite travailler avec le vidéo proj. Très envie de tester certaines chose avec 2 vidéo proj. Certains visiteurs viennent (SAP je crois ?) et prennent des photos du code… Cela donne vraiment l’impression d’être dans une vitrine façon Amsterdam. Ce matin, une journaliste, sortie de nulle part, même pas dans l’agenda, trainais dans le local, alors que tous était en réunion d’équipe dans le bocal… Je pense avoir été très froid, mais bon. Etre prévenu serais le minimum. C’est le retour du tier lieux ?

Jour 82

Kata Slow sur un des exercice de exercism, Bob, le premier pour javascript. C’est un bonne outils, mais les tests sont déjà écrit. Comment transmettre le gout et la méthode pour écrire des tests ? Encore des visiteurs avec des personnes qui prennent des photos sans demander… Après midi bruillante, un peu chiant. Faut-il les pousser à réaliser des projets utilisant les technos choisi pour les katas de la semaine ? Dans ce cas, il faudrais surement prolonger. Une semaine c’est court pour réaliser certains projets et/ou certaines participations.

Jour 83

Peu de monde arrivé à l’heure encore une fois. Comment faire pour que tout le monde soit présent à 10h ? Difficulté à trouver un sujet de Kata… Pendant la pause, j’entame une gestion administrative pour les dossiers de transports en commun, ça déborde si bien que je ne donne pas beaucoup d’aide sur la deuxième partie du kata. Peut-être devrais-je prévoir un crénau pour cette gestion adminstrative ? Le mieux serais surement d’en faire un maximum avant le début des courts. L’après midi, Présentation de PHP sous deux forme: l’une faite par un élève, l’autre par Matodzi, la formatrice Afrique du Sud. La deuxième est du coup un peu plus poussé, mais c’est toujours “à la php”, c’est à dire phpMyAdmin pour gérer la base de donnée, et apache comme serveur web. Php n’évolue pas vraiment en terme d’outil. L’invité du soir permet de parler des boites de services, de java, de la notion de client et de gestion de carrière. Je continue mon journal ici car je ne crois pas avoir eu de nouvelle par rapport aux journaux des élèves…

Jour 84

Kata étrange ce matin, plutôt une sorte de mobProgramming session. Besoins de cas concret ? Surement. Quel est le but d’un kata ? Visite d’un consultant freelance sur OpenERP. Il improvise une présentation d’OpenERP (Odoo) plutôt intéressante. Je part à l’Agile Open France pour 3 jours, comment vont se passer ces journées ?

Jour 85

Je suis en congé, mais les élèves semble avancé. Le hic c’est que tous ne sont pas venus. Mais ceux qui sont là font des choses ensemble. Gros problème de bruit apparement (habituellement, je gueule et obtient un peu de reduction de volume).

Jour 86

Encore une journée de congé. Certains sont venu coder ce matin, mais d’autre attende l’après midi pour aller au remixjob days. Simplon tiens un stand, et les élèves cherche un taf :-)

Jour 87

Jour de congé encore. Ce matin, en retrospective, il y avait apparement pas mal de ticket positif ! Quelque reflexion sur la vitesse des exercices qui pourrait être piloté par ceux au clavier, encore faut-il qu’ils y viennent…

Jour 88

Ce matin, encore beaucoup de personnes en retard, certains ne viendront pas (malade ?). Choix du langage et du kata. Après la pause, je re-explique ce qu’il c’est passé en première partie. C’est intéressant comme façon de faire: Revenir sur un déroulement en refaisant le code. Trop de bruit encore aujourd’hui, certains partent car c’est impossible de travailler. On me demande de faire un email pour demander un effort à chacun. Ce local n’est vraiment pas fait pour donner des cours.

Jour 89

2 personnes à 10h. Dur. Est-ce que certains ont abandonné. Le format autour de la pratique et de l’autonomie ne conviens pas à tout le monde. Faire beaucoup plus attention au recrutement pour ne prendre que des personnes à qui ça conviendra. Ou alors il faudrait trouver deux rythme, deux déroulé… Deux profs et deux méthodes ? Quelques révisions, sur Git, un peu de code en Rails. Difficulté de faire participer tout le monde, mais certains essaie. Des personnes viennent en mode à priori improviste poru pitché, mais ce n’est vraiment pas le bon moment, l’invité du jour arrive. Du coup, je leur demande de revenir le lendemain.

Jour 90

Beaucoup d’absent encore ce matin. Nous attendons un peu. A 10h30, finalement nous décidons de commencer. Lentement. C’est intéressant de revenir sur des points basique les exercies en mode kata, où l’on repète des choses simple sont vraiment très intéressant. Ça permet à chacun de revoir des choses acquises, voir les remettre en question. Et pour d’autres, ça permet de découvrir des choses qu’ils avaient loupé une première fois. Certains peuvent aussi enfin oser poser une question. L’après midi, nous attendons les personnes qui doivent pitcher pour un hackaton, finalement elles ne viennent pas. Il semblerais que quelqu’un du staff leurs a dit de ne pas revenir… Nous revoyons certains notion sur les projets, et nous en commençons un de zéro pour un élève qui semble ne pas avoir décoler (après 4 mois, dommage). Des élèves de la première promo sont apparement missioné pour faire des cours de soutien. Mais je ne sais pas quoi leur dire quand ils viennent me demander quoi faire et pour qui (n’étant pas vraiment au courant de la demande).

Jour 91

Journée de workshop sur Odoo, 2 consultants sont là pour présenter et animer des ateliers sur le sujet. J’en profite pour mettre à jour de la paperasse autour des bourses au transport.

Jour 92

Rétrospective dans le bocal car il y a une réunion dans la cuisine. C’est plutôt intéressant de faire ça dans une salle à part. Il manquerais plus que l’on puisse fermer la porte, que l’on enlève la table et hop. Quelques échanges intéressant sur le déroulement des Katas. L’idée est d’essayer de faire participé plus de monde… Mais beaucoup préfère rester dans leur coin. Bref.

Jour 93

Peu de monde à 10h pour la selection du langage. Est-ce que le groupe ne serais pas mieux avec 7 +- 2 personnes pour un encadrant ? Le Kata se déroule sans précaution particulière pour organiser la rotation, mais ça tourne quand même. J’ai fait le setup pour mettre en jambe. Est-ce une bonne idée ? Après le repas, certains vont dans le bocal avec des élèves de la première promo: Tony, Ben et Rodolphe. Ils vont faire du html avec bootstrap apparement. Je l’ai appris par des élèves qui m’en ont parlé… Pourquoi ne suis-je pas dans la boucle ? Peut-être déjà un paria ? Le principal c’est que chacun puisse repartir avec ce qu’ils souhaitent avoir. Nous avons pendant ce temps des échanges autour de l’emploi et d’une sorte de carte de compétences. C’est intéressant. Nous parlons aussi beaucoup des offres d’emploi et de la façon dont ce déroule des entretiens. Il serait intéressant d’imaginer une façon original et surtout amusante de construire cette carte.

Jour 94

Ce matin, c’est un de ceux qui se débrouille le mieux qui prend le clavier pour commencer… Du coup la mise en place est rapide. Est-ce un pattern intéressant de faire commencer ceux qui s’en sortent le mieux ? Au moment de demander qui veux le clavier, il se lève, c’est surement le meilleur moyen de provoquer une rotation. Des étudiant d’une école Strasbourgeoise viennent en visite. J’avais mal saisi qui ils étaient: en fait des élèves d’une école d’entreprenariat original hébergé dans une école business classique, mais utilisant des pratiques venant d’une école Finnoise basé sur la pratique, l’auto gestion et autres idéé. Il faudrait les revoirs dans un autre contexte, peut-être aller leurs rendre visite ? C’est peut-être une reflexion personnelle. Leur présence non organisé deviens un peu n’importe quoi, j’espère que ça ne dérange pas trop les élèves. Au moment de refaire comme d’hab, ils parlent entre eux et se font reprendre… Nous aurions du expliquer les règles peut-être. Faut-il afficher des règles ? Peut-être celles qui se sont construite au fur et à mesure.

Jour 95

Toujours peut de monde présent aux Katas, pourtant ceux qui sont assidus sont ceux qui s’en sorte le mieux. Certains sont en train de passer des entretiens aussi. C’est calme, ça fait du bien, peu de bruit. J’ai pris le clavier et la “direction” en fin de deuxième partie… je n’aurais peut-être pas du. Cet après midi, cours de HTML/CSS avec Bootstrap pour certains, pour les autres nous continuons à débloquer les problèmes. Un élève, en privée sur slack me fait des reflexions sur le fait qu’apparement j’aurais des «chouchou» et qu’il mérite plus d’attention aussi… Pourtant, le matin, tout le monde peut venir, bien au contraire, et l’après midi, également, c’est aussi pour cela que nous faisons en groupe, pour que tout le monde, ou au moins tout ceux qui le souhaitent, puissent bénéficier de la discussion… Je crois que cet élève ne devrait pas être ici surtout.

Jour 96

Intéressant de voir comment même la répétition de geste semble prendre du temps pour leurs faire prendre conscience de la suite d’étapes à mettre en oeuvre pour produire un code fonctionnel. Trouver une nouvelle façon d’aiguiller ? Les passages de l’après midi se déroulent assez bien, mais il y a toujours un groupe qui ne participe pas… J’espère qu’ils travaillent sur les exercice proposé en ratrapage au moins.

Jour 97

Retrospective avec des personnes qui ne sont pas souvent là, c’est agréable. Même à distance, certains participe. Pas de grande révolution, le format tourne pas mal. Nous évoquons des manques par rapport à certains sujet. Faut-il forcer le traitement de certains sujet ? Sur quel rythme ? Traitement de tâches administrative l’après midi (dossier pôle emploi, fongecif et autres email en souffrance). Quelques échanges autour de l’emploi et d’une journée de recrutement organisé par Simplon. L’idée est bonne, mais puisqu’il y aura une jonction avec le promo #3, je ne participerais pas au démarche d’entreprise. Par contre je serais présent pour répondre aux éventuelles questions.

Jour 98

3 personnes ce matin pour décider du langage de la semaine, puis du Kata du jour. 2 seulement souhaite participer… Une 4ième personnes arrive à 10h05. Pourquoi tant de soucis pour venir à 10h ? Certains sont en rendez-vous, mais pas tous. Le lieu est trop éloigné du centre de Paris ? L’après midi s’enchaine, à coup de 30 minutes… Ce format à quelque chose de déplaisant… Peut-être le manque de coopération entre eux ? Ils prennent, je pense, une petite claque car l’un d’entre eux, un de ceux qui s’en sortent vraiment bien, viens de ce faire recaller à un entretien… Dur de devenir un dev. J’espère quand même qu’ils trouverons une petite place quelque part.

Jour 99

De nouveaux participants au kata ce matin (il n’est jamais trop tard). Est-ce lié à la fin de formation qui approche ? Ou bien au retour des premier entretien pour un job ? La sélection à l’entrée doit vraiment être clair et net. Pas de demi mesure pour pouvoir trouver un boulot de dev. Ou il faut faire au contraire beaucoup plus souple, mais dans ce cas, ne pas chercher à placer les gens, ne pas mettre en avant l’insertion, puisque ça ne peut pas fonctionner. Faut-il mettre l’accent sur PHP ? Techno beaucoup plus simple et donc certainement des emplois plus facile à trouver/accéder pour des débutants ? Les formats de l’après tourne bien, mais c’est vraiment très individuel, ça ne colle pas.

Jour 100

Un kata assez simple ce matin, tu coup, en deuxième partie, j’ai fait du blabla autour des bases de données NoSQL. Ce format où je parle me semble très peu efficace. Ils en resortent en disant «Yes, j’ai appris des trucs», mais en fait c’est plutôt «J’ai entendu parler de chose, mais je n’ai pas tout compris» je pense. Il faudrait imaginer des uses case avec mise en oeuvre ? L’après midi ressemble à toutes ces dernières après midi: les personnes défile avec leurs problèmes perso, et je les règles… Pas très optimisé je pense. Que faire ?

Jour 101

Encore le même kata (ça à été le même toute la semaine). Mais là nous avons réussi quelques chose. Pattern intéressant de faire le même langage et le même kata toute la semaine ? J’ai toujours un gros soucis avec l’ambiance de l’après midi, trop de projet perso. Quelques présentation un peu généraliste, mais du coup pas très impactante je pense. Toujours un gros problème de bruit. Ce matin, bocal occupé par une réunion, réunion aussi dans la partie cuisine, plus du monde dans les bureaux CoDev… Horrible. Cette après midi même topo. Un élève à suggéré de vendre des boissons, de faire salon de thé. Le public est déjà là il suffirais de lui vendre les boissons :-) Nous étions 24 au départ. 3 ont officiellement annoncé leur retrait. J’ai le sentiment que 2 de plus ne reviendrons pas, voir 3 ce qui nous faire 18 personnes restantes. Sur les 18, 3 ne suivent vraiment pas grand chose à la formation, un n’est presque pas là, ce qui fait un groupe restreint (mais pas toujours présent) de 14 personnes. C’est, pour un seul formateur, plutôt correct et presque viable, sans le bruit autour, ça irais presque. Attention à limiter la quantité de candidat.

Jour 102

Rétro du vendredi. Quelques prises de conscience : la fin approche. Comment optimiser ces derniers instants ? Certains demandent après les cours de soutien.

Jour 103

Kata avec représentation graphique… Un bon moyen de voir l’ensemble des parties. Quelques difficultés lié à l’ordre des bout de code à réaliser. Une petite retrospective après chaque activitées serais intéressante, cela permettrais d’une part de signaler la fin de l’activité, puis de voir comment s’améliorer sur la prochaine. Le format révision serais à revoir. Comment organiser les révisions ? Questions ouvertes ? Risque d’être trop large. Questions sur un point précis ? difficulté de présentation.

Jour 104

Un kata sous forme de mise en place d’un jeu. Nous nous laissons déborder par un peu trop de bruit et de fatigue, et hop, pas de test, pas de direction correct de l’exercice. J’espère qu’ils ont quand même apprit quelques trucs. L’après midi, un peu dissipé, mais quelques bon moment intéressant. Toujours un soucis sur le format de l’arpès midi. Nous parcourons aussi les offres d’emploi et nous discutons.

Jour 105

Refaire le même Kata, mais en prenant garde de ne pas tomber dans les pièges habituels. L’environnement pour de l’enseignement,comme pour une équipe de travail, est vraiment très important, et là, entre le volume et les passages, c’est vraiment dur. Le fait de répéter tout les jours la même chose commence à être vraiment usant. Le pattern d’expliquer semble ne vraiment pas fonctionner: je continue à expliquer des basiques à ceux qui ne participait pas.

Jour 106

Pas beaucoup d’interaction, intéressant de les laisser avancer seul un peu ?

Jour 107

Une bonne retrospective, des changements en perspective: Le matin nous travaillerons toute la semaine sur une application commune. J’espère que certains proposerons des kata l’après midi du coup.

Jour 108

Le matin, démarrage sur un projet, comme convenu le vendredi. Les élèves démarrent seul (j’ai eu un empechement). C’est assez chaotique, et du coup c’est toujours les même questions qui reviennent: Par où doit-on commencer ? Quel test écrire ? Quand faire un test et quand n epas en faire ? Comment les aider sans tuer le chemin de découverte ?

Jour 109

Reprise du projet, cette fois je pilote un peu plus… Difficile d’ailleurs: quel chemin prendre ? Celui qui avance dans la feature vers le fond, ou celui qui avance large et rend le peu déjà fait jolie ? Faut-il aborder le CSS tout de suite ? Mettre des helpers personnalisé (c’est une ap rails) ? Arrivé en retard, une équipe de tournage est là… Ambiance étrange. Du coup une élève essaye de me monopoliser pour une sorte de cours privée… Dur de répéter toujours non, mais pourtant c’est ce que j’aurais du faire. J’ai accepté de venir à coté d’elle, mais des tensions dans le groupe me font me lever. Je préfère reprendre la place du milieu, avec le projecteur et m’adresser à ceux qui écoutent. Au moins, mon aide est diffuser à plusieurs personnes. Demain, les cours particuliers (avec un ancien élève de la promo #1) repennent. C’est tant mieux pour ceux qui en ont besoin. Je crois vraiment qu’aujourd’hui marque pour moi le ras-le-bol vis à vis de ceux qui ne jouent pas le jeux et surtout qui essaie de me faire changer de route pour ! A la limite, que certains viennent et ne participe pas, avec 24 personnes au départ, ça ne me surprend pas trop et ça me va tant que ça ne gène pas ceux qui ont accepter de jouer le jeux. Je pense que je vais être beaucoup plus cash avec cet élève maintenant

Jour 110

Dans le salon d’Erwan ce matin. Nous sommes peu nombreux, c’est vraiment bien ! Limiter le nombre d’apprenant à 10 maximum en simultané me parait primordial pour une bonne qualité de cours. De plus, ceux qui sont venu ne sont que ceux qui s’intéresse à ce que nous faisons puisque j’ai demandé aux autres de ne pas venir (vu le peut de place dans le salon d’Erwan). Après manger, pas beaucoup plus de monde. Certains suivent le cours de rattrapage html/css avec Ben. Les autres passent chacun leur tours avec moi pour résoudre leurs problèmes… Ce format est ennuyeux je trouve, et frustrant pour moi. J’ai toujours envie de prendre le clavier pour faire aller les choses plus vite. Est-ce qu’il le faudrait ? Travailler sur une aplication par semaine me semble vraiment génial. Est-ce que ça pourrait occuper toutes les journées de la semaine ? Avec des phases différentes dans les journées, genre mobProgramming une demi journée, et analyse des pull request ensuite ?

Jour 111

Le format de l’application est intéressant: il permet de découvrir petit à petit divers façon de construire l’application, comment couper en plus petit bout. Le hic, c’est de ne pas lire du code existant… Peut-on faire un format similaire, c’est à dire tous ensemble, en mobProgramming, pour faire des résulotions de bugs sur des applications ? Il faudrait d’ailleurs reprendre les règles du mobProgramming pour appliquer les changements de pilote, et les pauses. De la même manière, il faudrait réviser comment faire avec le compte git. Créer un pseudo compte commun ? Après midi tranquille et rapide. Beaucoup de fatigue chez les élèves, certaines tensions lié à de la vie de groupe. Le lieu est tellement important dans l’ambiance qu’il installe !

Jour 112

Il est resorti de la rétrospective que l’environnement est effectivement important. La matinée dans le salon d’Erwan, au calme, a été apprécié. Nous y étions aussi peu nombreux, ça aide. Il faut demander à utiliser l’aquarium pour le matin au moins (voir toute la journée ?).

Jour 113

Une seule personne ce matin à 10h. Du coup nous partons sur un des projets qui lui tiens à coeur ! Certains sont déçu, tant pis, c’est le jeux. Quelques avancées intéressantes, mais je suis en terrain inconnue en terme de langage et encore plus de framework. Une belle mise en danger. C’est tout de même très enrichissant, par contre on avance moins vite. L’après midi, comme d’hab, certains viennent pour ce faire décoincé. Puis nous passons sur le mode annoncé en retrospetive: resolution de bug avec Yannick. L’idée est de voir comment je m’y prend et d’en profiter pour lire du code. Ce n’est pas forcement très facile, n’ayant rien préparé, le temps d’installation est délicat. Ces promenades en univers libre devraient être un peu préparer, mais quand préparer ? Il faudrait au moins repérer les projets qui s’y prete.

Jour 114

Nous avonçons sur le projet du matin, c’est intéressant de suivre un projet comme ça. Peu de monde aujourd’hui, j’ai compté 8 personnes en début d’après midi. Cours de rattrapage. Je commence à être rincé. Toujours gérer le bruit (provenant du staff et des autres activité dans le local), les questions, trouver des idées de sujets… Et tout ça avec des personnes qui continue à ne pas venir ou se plaindre… Heureusement qu’il y a ceux qui suivent.

Jour 115

Les petits groupes c’est vraiment pratique: les échanges y sont de meilleur qualité, c’est plus simple de se respecter les uns et les autres. En termes de volume, la petite pièce du haut est vraiment mieux également. Inaccessible quand nous sommes trop monbreux. En début d’après-midi, uniquement 8 personnes. Je me demande si je suis un bon formateur. Si je regarde uniquement au nombre de personne qui suivent le cours: non. Rapidement, plusieurs personnes ne sont plus venu régulièrement, ou bien en retard. Si je regarde une forme de resultat (est-ce que certains sont autonome), idem, assez peu de réussite (environ 5 à 6 personnes sont autonome il me semble, avec disons une partie qui l’était peut-être déjà et qui n’ont pas vraiment participé au cours). Certains me reproche cette façon de faire, me reproche la façon que j’ai de faire des cours, pour eux, je ne donne justement pas de cours. grosse remise en question personnel. Je pense pourtant avoir une approche qui pourrait fonctionner. Peut-être nécessite-t-elle d’être plus structuré ? Il faudra peut-être être plus strict sur le recrutement, ou au moins plus clair sur ce qu’il va se passer, pourquoi pas une journée d’essai ? Heureusement que tous ne sont pas comme ça, mais c’est dur. Surtout cumulé avec l’impression que Simplon fonce quand même dans ce schéma de formation pour insertion pro sans vraiment connaitre le métier.

Jour 116

Encore de beau apprentissages ensemble ce matin. Ce format d’un projet sur la semaine est vraiment sympa. Nous avons expérimenté 2 vidéo proj en simultané, un sur la doc, un sur le code. C’est intéressant de multiplier les sources. Peut-être qu’il pourrait y avoir deux équipes sur le même projet ? Il faudrait un espace aménagé autrement. Et répartir les compétences, connaissances, capacité ou je ne sais quoi entre les deux groupes. Un peu de perturbation l’après midi car présence de france2, mais ça va, Erwan et l’équipe gère bien le truc, ça ne dérange pas trop (en plus ils sont arrivé tard).

Jour 117

Rétrospective dans le bocal pour éviter France3. Peu de monde, mais ça se passe bien. Beaucoup de tickets à propos de la fin de promo qui arrive… Stress, mélancolie, difficile de gérer ce genre de moment. Cette après midi peu de monde, je ne suis pas très bien, je vais rentrer.

Jour 118

Record ! 16 personnes ! Est-ce le fait d’être dans un autre lieu ? Est-ce le fait d’être avec d’autres personnes pour gérer l’accompagnement ? Nous verrons. J’écris ces lignes le matin, en arrivant. Il y a des revenants dans le lots. Arrêt de journée pour moi, une contrainte familliale m’oblige à rentrer. Je laisse les élèves aux mains de Mozilla.

Jour 119

Journée off pour moi, contrainte familliale. Je crois que les élèves ont fait un kata le matin, puis leurs projets l’après midi.

Jour 120

Je reste encore chez moi. Les élèves sont à leurs deuxième journée chez Mozilla. Je crois que tout ce passe bien.

Jour 121

Assemblée générale. Erwan fait des annonces, listes les questions puis réponds. Rien de particulier à signaler. Je profite de cette étrange journée pour faire des entretiens individuels avec ceux qui l’avait demandé. Je crois que c’est bon, j’ai vu tout le monde.

Jour 122

Rétrospective. Retour au peu de monde présent.

Jour 123

Difficulté de trouver des idées, trop proche de la fin ? Difficile de se motiver. Après 6 mois, nous sommes toujours obligé de faire la police pour le volume. Ça va être ça jusqu’au dernier jour on dirait. Toujours peu de participant. Ce que je propose n’est soit pas compris, soit pas adapté aux personnes. Il faut vraiment avoir un message clair et tenir la ligne pour les recrutements. J’en suis à compter le nombre de jours qu’il me reste à faire avec eux… ou disons, dans ces conditions. Plus que 9 (en comptant le dernier vendredi).

Jour 124

Nous continuons à explorer un framework JS. C’est intéressant, mais les victoires sont très limitée, ou peu visible. L’intérêt de faire des exercices le matin c’est qu’ils permettent de parler de code et d’avoir des victoires plus visible ! Un peu tard pour changer de créneau. J’ai toujours aussi peut d’élèves présent: 8 ce matin, dont 4 seulement qui participe.

Jour 125

Peu de monde, pas vraiment d’exo. Certains ont travaillé ensemble pour avancer sur le projet de la semaine. Comment gérer la fin de promo et toutes les démotivations ? Le stress lié à la fin ? Ça serais intéressant de trouver des ateliers/workshop qui déstress ? qui permettent de penser à autre chose que la fin ? qui permettent de s’amuser.

Jour 126

Journée de présentation de Go. Un intervenant extérieur viens pour parler de tout ça. Le format de faire venir quelqu’un pour parler d’un langage en particulier fonctionne bien pour ceux qui participe. Il manque juste un projet concret à réaliser. L’intervenant n’en avait pas forcement, et nous n’en avons pas évoqué un. Un catalogue d’exercice et de projet à réaliser serais intéressant pour ce genre de situation comme pour d’autres. Toujours peu de monde, plus que 6 jours.

Jour 127

Retrospective soft. C’est la dernière à ce format là. Toujours aussi peu de personnes. L’apéro sera en mode restreint.

Jour 128

Nous travaillons sur une app avec un jeu de donnée. C’est intéressant, mais pas pour tout le monde. Beaucoup sont venue, mais juste pour la réunion à propos de la WebAgency. Il y a une ambiance de vacances, de fin de formation…C’est trop long, ça manque de congés, d’alternance, de chose qui change. C’est la dernière ligne droite, les derniers jours. Ils vont être vraiment spécial en plus puisque nous ne pouvons pas utiliser le local.

Jour 129

Petit comité dans le salon d’Erwan. Pas pratique, mais l’avantage c’est de ne pas être beaucoup. Nous testons un format où chacun avance sur un exercice commun, mais sur son propre code. Toutes les 15 minutes, tour de baton pour débloquer et voir où chacun en est. Pas top. Le temps de parole n’apporte pas grand chose. Faut-il imaginer une personnes seulement en ligne, sur le vidéoproj, avec les autres qui éventuellement peuvent avancer, mais c’est tout, et au moment du 15 minutes, on demande à tous de parler de ce qu’ils ont lu ? A voir. Après midi sur un projet. Révision sur la manière d’aborder le truc: plutôt par le client que par le fond des outils qui n’apporte rien à l’utilisateur. Suite à une demande de baisse de volume dans le local, il y a eu une reflexion genre “nous aussi il faut qu’on travail”. Ça confirme le sentiment que la formation n’est vraiment pas le soucis principal ici. Heureusement il ne me reste que 3 jours à faire avec les élèves. Sachant qu’entre le vendredi de dernière rétro, le jeudi dans le salon d’Erwan en petit comité, et le mercredi matin aussi, ça va être rapide et tranquille… A suivre.

Jour 130

Encore en petit comité dans le salon d’Erwan, cette fois avec le chauffage, c’est mieux. Nous travaillons encore sur exercism. Certains en binome, d’autres seul. Comment créer un environnement similaire à du travail en équipe ? Difficile à 2 jours de la fin. Demain, nous allons passer la journée dans cette situation, j’espère que ça ira bien. Nous allons surement continuer sur des exerices de code, mais j’aimerais reprendre un mode randori. Plus que 2 jours.

Jour 131

Petit comité dans le salon d’Erwan, focus sur un sujet exercise pour revoir un peu certaines bases. Nous parlons aussi pas mal de l’approche. Quelques échangent sur le après. Peut de monde… Dur fin. Je ne pense pas faire un log de la dernière journée demain, nous ferons une frise des 6 mois passés, et quelques articles pour la FOAD.

Jour 132

Fin.