Tous les markdown en extension html. Reste à en faire des pages
This commit is contained in:
+100
@@ -0,0 +1,100 @@
|
||||
### Semaine 3
|
||||
|
||||
Il tait une fois, un formateur Simplon en 2014 Pour en savoir plus sur la publication de ce jour, rendez-vous en sem[aine 0.](https://medium.com/@ya_f/semaine-0-introduction-a5fb7e35894d#.9kyxvij79)
|
||||
|
||||
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 linstallation de R[uby ](https://www.ruby-lang.org/fr/)(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: R[ubygems,](http[s://rub](https://www.haskell.org/)ygems.org/) 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](http://codingdojo.org/cgi-bin/index.pl?KataFizzBuzz). 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 lc[ofablab d](http://www.apedec.org/)e Mozinor. Trs sympa. Explication de lhistorique, change autour des principes et valeurs quils vhiculent et sur le fonctionnement de leur fablab. Evocation de projet avec le numrique quils 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éaparer 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
|
||||
|
||||
Reference in New Issue
Block a user