Accéder au contenu.
Menu Sympa

educ - Re: [EDUC] Github/Edu

Objet : Liste de discussion du groupe de travail Éducation et logiciels libres de l'April (liste à inscription publique)

Archives de la liste

Re: [EDUC] Github/Edu


Chronologique Discussions 
  • From: Gérard Vidal <gerard.f.vidal AT gmail.com>
  • To: educ AT april.org
  • Subject: Re: [EDUC] Github/Edu
  • Date: Mon, 16 Apr 2018 16:43:14 +0200
  • Authentication-results: vip.april.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i= AT gmail.com header.b="Sbggh0P2"; dkim-atps=neutral

Bonjour,

je crois aussi que git est une solution à envisager pour l'éducation même si mes expériences actuelles avec les enseignants sont plutôt décevantes :'(. je pense qu'il faut tout de même être prudent car git a tendance à entraîner ses utilisateurs vers des usages complexes (syndrome du tout est possible tout est réalisable..); je ne pense pas qu'on puisse utiliser git avec une classe si on n'est pas soi même impliqué dans un travail collaboratif utilisant un outil git (ou mercurial).  La notion de travail collaboratif (au vrai sens complet du terme) est facile à comprendre et à mettre en œuvre techniquement mais beaucoup moins facile à vivre au quotidien...;-) Un peu comme la notion de bien commun à laquelle elle est fortement liée d'ailleurs.

je souscris à ce qui est dit sur l'alibi sécuritaire qui envahit le second degré et conduit à une stérilisation complète des usages, ce qui requiert que nous puissions proposer des stratégies alternatives.

Même si cela requiert quelques compétences je crois qu'il ne faut pas  évacuer d'office un serveur interne (surtout si on envisage une innocente raspberry O:-)). Il existe quelques outils libres proposant des interfaces plus ou moins conviviales et configurables qui pourraient être déployés  interne juste pour une classe ou un projet. Dans le monde python kallithea peut rendre des services et permet d'avoir une sorte de github privé  en interne et d'organiser le travail autour d'un flux principal (mainstream) avec une ou deux branches et un ensemble de flux secondaires (forks) permettant à tous de voir le travail de chacun et à chacun de faire remonter  ses contributions.

Bon travail

PS : si le codage en utilisant une interface web fournie par une raspi vous intéresse voici la partie github du travail https://github.com/g-vidal/CahierDeProgrammes


Le 16/04/2018 à 15:51, Grégory Mounié a écrit :
Bonjour

 Je ne suis pas exactement dans le même cas (mes 250 étudiants ont 20 ans, une moitié aimant les math, une moitié aimant l'info, en début d'école d'ingénieur, et ils ont fait 10h d'UNIX avant de voir git) mais je pense que c'est une excellente idée.

  - Git est au final facile à apprendre en 1h30 parce que finalement il n'y a que deux concepts: enregistrer localement des changements (add, commit) et déplacer des changements entre deux machines (push, pull).

  - En 1h30, ils arrivent *tous* à utiliser git et créer leur propre dépôt (sur une machine avec ssh) en 1h30. Le seul raccourci que nous utilisons à ce moment là est de faire "git commit -a" plutôt que d'expliquer l'index. Nous faisons un TP pas à pas (création, clone, édition, fusion, édition, fusion, etc.), en équipe de 2-3. Le faire en équipe est important pour qu'ils voient l'intérêt.

  - En utilisant gitlab, la création/clonage devient triviale (click, taper un nom, click, copy-paste, enter, done). Avec juste ssh, nous sommes plutôt de l'ordre de 15-30 minutes sur ce seul point, en donnant les commandes à taper.

 - Il y a un support git dans tous les bons éditeurs (et quelques mauvais) mais pour des débutants je trouve plus simple pour eux de tout faire en ligne de commande pour bien comprendre les concepts, le vocabulaire et ne pas les mélanger avec ceux de l'édition.

Un point sur lequel nous insistons est qu'ils arrêtent les échanges par email/USB car cela cache des changements à git et du coup augmente leurs conflits de fusions.

 Bon cours
 Grégory

PS:  Pour Mercurial, qui est aussi un bon choix, il y a longtemps, "l'interface" était plus simple que celle de git, mais ce n'est plus vrai, et sur le fond le concept des têtes multiples de Mercurial reste pénible à manipuler et à expliquer à des débutants.

Le 15/04/2018 à 12:19, William Gambazza (wgambazza AT yahoo.fr via educ Mailing List) a écrit :
Le 15/04/2018 à 12:07, Marc Ferraton (marc.ferraton AT laposte.net via educ
Mailing List) a écrit :
...

Bon peut être que la mise en œuvre d'un  serveur en EPLE est
impossible, mais "booter" une machine avec une clef USB et adjoindre un
disque externe pour les datas dans le cas du projet me semble facile,
et formateur, et surtout infiniment plus "secure" que d'ouvrir un accès
à un git(hub ou pas) où bien-sur on trouvera le meilleur et le pire
d'application ....

Bonjour,
alors ... pour ce qui est du disque externe, de plus en plus, les ports
USB sont bloqués pour "raisons de sécurité" donc exit le disque externe...
Mais de toutes façons, je ne vois pas vraiment en quoi cela résoudrait
mon pb ...
Je vais préciser mon idée de départ :
les élèves ont 10 séances de 2h pour développer un projet à 2 ou 3 (plus
ce qu'ils peuvent faire chez eux). Ceci, sur des postes informatiques
d'une même salle mais qui peuvent être différents d'une séance à l'autre
et pour lesquels nous n'avons que peu de marge de manoeuvre de
configuration.
Mon idée était de leur permettre de travailler séparément sur le projet
un peu comme dans une entreprise ou chacun fait ses commit et on sort
une version au bon vouloir de l'avancée ....
À l'heure actuelle, ils en sont à utiliser des docs ou ils
copient-collent le code python qu'ils testent pour se le partager.
Certains travaillent sur un seul poste mais du coup ne se répartissent
pas vraiment les tâches

D'ou mon idée d'utiliser un vrai système de gestion de code source.
La question semble être maintenant : comme il faudra les former au
fonctionnement et à l'utilisation de ce système et que cela n'entre pas
dans les objectifs du programme, est-ce que c'est réalisable dans un
temps modéré (<2h) ?

En espérant avoir été plus clair ...
Merci encore
William



--
Pour vous désinscrire de cette liste : https://listes.april.org/wws/sigrequest/educ

Pour connaître la configuration de la liste, gérer votre abonnement à la liste educ et vos informations personnelles :
http://listes.april.org/wws/info/educ





--
Pour vous désinscrire de cette liste : https://listes.april.org/wws/sigrequest/educ

Pour connaître la configuration de la liste, gérer votre abonnement à la liste educ et vos informations personnelles :
http://listes.april.org/wws/info/educ






Archives gérées par MHonArc 2.6.19+.

Haut de le page