167 lines
7.2 KiB
Markdown
167 lines
7.2 KiB
Markdown
---
|
||
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/).
|