Découpe de la semaine 3

2017-11-29 18:12:49 +01:00
parent e5fe329ddb
commit f411a81adb
6 changed files with 173 additions and 166 deletions
@@ -0,0 +1,59 @@
 ---
 title: "Jour 11 — Lundi 22 septembre 2014"
 date: 2014-09-22T13:15:29+01:00
 ---
 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](https://ruby-lang.org) (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](https://rubygems.org/), pour
    [Haskell](https://www.haskell.org/)
    [Cabal](https://www.haskell.org/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.
@@ -0,0 +1,36 @@
 ---
 title: "Jour 12 — Mardi 23 septembre 2014"
 date: 2014-09-23T13:15:29+01:00
 ---
 Visite de l'[écodesignfablab](http://ecodesignfablab.org) 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…
@@ -0,0 +1,64 @@
 ---
 title: "Jour 13 — Mercredi 24 septembre 2014"
 date: 2014-09-24T13:15:29+01:00
 ---
 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 Deming: on ne peut améliorer que ce qu’on
 mesure
 Fin de journée à 16h, Hager commence le déménagement.
@@ -0,0 +1,6 @@
 ---
 title: "Jour 14 — Jeudi 25 septembre 2014"
 date: 2014-09-25T13:15:29+01:00
 ---
 Hackathon Hager
@@ -0,0 +1,8 @@
 ---
 title: "Jour 15 — Vendredi 26 septembre 2014"
 date: 2014-09-26T13:15:29+01:00
 ---
 Hackathon Hager
@@ -1,166 +0,0 @@
 ---
 title: "Semaine 03"
 date: 2014-09-22T13:15:29+01:00
 ---
 *Du 22 au 26 septembre 2014.*
 ## Jour 11 — Lundi 22 septembre 2014
 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](https://ruby-lang.org) (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](https://rubygems.org/), pour
    [Haskell](https://www.haskell.org/)
    [Cabal](https://www.haskell.org/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 — Mardi 23 septembre 2014
 Visite de l'[écodesignfablab](http://ecodesignfablab.org) 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 — Mercredi 24 septembre 2014
 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 Deming: on ne peut améliorer que ce qu’on
 mesure
 Fin de journée à 16h, Hager commence le déménagement.
 ## Jour 14 — Jeudi 25 septembre 2014
 Hackathon Hager
 ## Jour 15 — Vendredi 26 septembre 2014
 Hackathon Hager
 Ceci est [l'histoire d'une de mes expriences en tant que formateur dans
 un bootcamp](https://yaf.github.io/journal-d-un-formateur-en-2015/).