Tous les markdown en extension html. Reste à en faire des pages

This commit is contained in:
Yannick Francois
2017-10-25 23:46:29 +02:00
parent 8ff6693601
commit 1677f3dd7a
29 changed files with 1589 additions and 9 deletions
+100
View File
@@ -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 dexecution: 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 lutilisation dun langage, ici Ruby pour faire une application web. Rappel de lintérêt dutiliser 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 dune boite à questions/idées anonyme avec période fixe pour lire le contenu. Je me demande ce quil y aura dedans ? Demain jessaie de trouver quelque chose pour la faire.
Des personnes débarquent en nombre, je ne sais pas qui cest 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 quil y a des cafards, il trouve des déjections derrière le frigo. Quelques explications sur ce quil faut faire et ne pas faire. Il enverra un devis.
Visite dune entreprise pour le ménage. Cest 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 cest flou. Commencer à faire des randoris avec 8 personnes volontaire, et les autres qui regardent ? Je ferais sûrement lessai 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 quils cherchent un peu des infos par eux-mêmes. Je ne vais pas faire difusion de savoir à chaque fois. Ils navaient pas compris. Comment faire pour quils sentent quils nont pas assez préparé le sujet ? Il faut peut-être que je les laissent lancer des questions, sils nen 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 à lexplication des groupes. Ils stressent à lidée de se mettre en goupe ont dirait. Ils nont pas envie de réduire le volume ? Trop installés dans une habitude ?
Nous passons un certain temps ensuite (je ne sais plus comment cest arrivé là) sur laspect cycle de vie dune application: ce nest jamais fini, jamais définitif. La seule chose qui le soit avec une application ou un logiciel, cest 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. Jai parfois limpression quils pensent que Fizzbuzz est un outil magique et mélangent un peu TDD et énoncé. Doucement mais sûrement le groupe sen 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 dun 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 lhébergement. Ça tourne un peu trop autour de moi qui parle et eux qui posent des questions, cest pas assez classe inversée à mon gout. Je vais peut-être reprendre laspect présentation dun groupe sur un sujet. Est-ce loppurtunité 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 quil 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 daide et a) quand ils arrivent à se débrouiller tout seuls. Dabord 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 quils 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.
Jai oublié de parler de Deming: on ne peut améliorer que ce quon 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