Au hasard de mes consultations webiennes (à la recherche de règles
procmail filtrant cette saloperie de swen), je suis tombé sur le projet
gobie.
Ca m'a l'air mort depuis un certain temps, des nouvelles ? (à moins que
le projet soit victime du syndrome "n'est pas mort ce qui à jamais dort
?)
--
> X..., c'est un millefeuille avec une couche de crème patissière, une
> de sauce tomate et une de crème d'anchois... Mais c'est vrai que
> c'est un système ouvert: tu peux y rajouter des pépites de chocolat...
-+- Ol in Guide du linuxien pervers - "Remettez m'en une couche !" -+-
=> Je pense qu'il y a moyen de contenter tout le monde. Dans le cadre de tels projets, les étudiants doivent être encadrés par un ou plusieurs professeurs - avec éventuellement l'assistance de développeurs Open Source sur Internet pour éviter les problèmes d'absence de continuité et de support.
D'un point de vue "pratique" pour un enseignant, l'assistance extérieur, c'est dur à gérer, voir louche (le but d'un projet c'est quand même de valider un acquis, comment fait-on pour différencier le travail de l'étudiant et celui de l'assistance extérieur...)
Exemple de projet : interface de Ruby & sendmail Milter (<pub/> voir http://milter.free.fr/intro/ pour plus d'infos sur Milter </>)
Bon, ça commence mal, ruby... enfin je vais rien dire, mais un langage non typé tout ça... ;)
Pour intéresser et guider les étudiants on pourrait leur enseigner dans des cours au préalables : Ruby (language + écriture de modules d'extension en C) le protocole SMTP les threads sendmail & l'API MILTER (juste comment rajouter des filtres dans le sendmail.mc pas les rulesets/rules/defines, ansi que les based de l'API Milter en se basant par exemple sur un filtre tel que milter-regex) - Un exemple plus compliqué : un filtre Milter scriptable en python (http://www.bmsi.com/python/milter.html)
Le premier problèmes ici, c'est l'enseignement préalable. Tu ne fera jamais apprendre ruby dans une université française (ou alors un fou dans son coin), globalement, en France, l'univers fonctionnel/typage à une grande importance dans l'histoire de la recherche française. Ensuite enseigner des protocoles spécifiques alors que pour l'instant les cours de réseau sont à peine suffisant pour expliquer (sans même enseigner réélement) TCP/IP. Bon, les threads c'est bon, ça se fait déjà (quoi que, ya des endroits où il trouve plus intélligent de passer un semestre complet à faire du fork ;). Après on rentre dans le spécifique.
Donc en gros, tu dois, sur un semestre avec 4h par semaine, faire un résumé de : ruby, sendmail/SMTP, Milter. Et ensuite mené un projet... c'était bien essayé...
L'étudiant par un projets peut ainsi : - apprendre et appréhender un nouveau language - découvrir un protocole (SMTP) - appréhender un MTA - découvrir une API d'extension ("call-back oriented") - étendre un language tel que python/ruby en C - les threads - comprendre un programme existant (Python Milter) - créér une nouvelle solution : filtre Milter scriptable en Ruby annoncée ensuite sur Freshmeat
Bon il reste aussi les problèmes du réalisme pédagogique. En université on ne forme pas des gens vers la pratique et c'est volontaire. On ne peut pas en 2 ans de formations fournir une formation théorique et pratique correcte, les facs sont les seules à faire la formation théorique réélement, donc le choix a été fait. J'ajouterai que (point de vu personnel, tout ça) apprendre des choses pratiques en info (genre nouveau langage, protocol, utilisation d'API...) ça se fait tout seul devant sa box avec une bonne doc, ce que tu vas mettre 1 semaine en y consacrant quelques heures chaques jours, il faudrat 6 mois de cours+TD pour faire pareil, voir moins bien, je sais de quoi je parle c'est du vécu.
Penses-tu que ce soit trop difficile ou pas assez intéressant pour des étudiants de licence/maîtrise/IUT ?
Bon, je vais être un peu moins "méchant", mais ça peut rentrer dans le cadre d'un DESS (et même on peut y rajouter de la conduite de projet), où les cours sont beaucoup plus spécialisé et où l'accent est un peu plus mis sur la pratique (vu que finalement la théorie nécessaire, voir plus, a déjàété faite). Bon par contre pas à Orsay, ici le réseau ne décolle pas du bas niveau (traitement du signal, contrôle d'erreur et autre truc que l'on peut faire en intéraction avec les physiciens).
Enfin, pour clore le débat (pas que ça m'intéresse pas, mais bon, on a déjà tenté pas mal de chose...), on a déjà tenter de mettre en place ce genre de projet de nombreuse fois, je penses pas que, sauf dans les cas ou on avait de vrai dev parmis les étudiants, le résultat ai été très probant, ni pour le projet, ni pédagogiquement.
On 10 Oct 2003 19:57:49 GMT
Steph L <Stephane.Lentz@ansf.alcatel.fr> wrote:
=> Je pense qu'il y a moyen de contenter tout le monde.
Dans le cadre de tels projets, les étudiants doivent être
encadrés par un ou plusieurs professeurs - avec éventuellement
l'assistance de développeurs Open Source sur Internet pour éviter les
problèmes d'absence de continuité et de support.
D'un point de vue "pratique" pour un enseignant, l'assistance extérieur,
c'est dur à gérer, voir louche (le but d'un projet c'est quand même de
valider un acquis, comment fait-on pour différencier le travail de
l'étudiant et celui de l'assistance extérieur...)
Exemple de projet : interface de Ruby & sendmail Milter
(<pub/> voir http://milter.free.fr/intro/ pour plus d'infos sur
Milter </>)
Bon, ça commence mal, ruby... enfin je vais rien dire, mais un langage non
typé tout ça... ;)
Pour intéresser et guider les étudiants on pourrait leur
enseigner dans des cours au préalables :
Ruby (language + écriture de modules d'extension en C)
le protocole SMTP
les threads
sendmail & l'API MILTER (juste comment rajouter des filtres
dans le sendmail.mc pas les rulesets/rules/defines, ansi
que les based de l'API Milter en se basant par exemple sur
un filtre tel que milter-regex)
- Un exemple plus compliqué : un filtre Milter scriptable en
python (http://www.bmsi.com/python/milter.html)
Le premier problèmes ici, c'est l'enseignement préalable. Tu ne fera
jamais apprendre ruby dans une université française (ou alors un fou dans
son coin), globalement, en France, l'univers fonctionnel/typage à
une grande importance dans l'histoire de la recherche française. Ensuite
enseigner des protocoles spécifiques alors que pour l'instant les cours de
réseau sont à peine suffisant pour expliquer (sans même enseigner
réélement) TCP/IP. Bon, les threads c'est bon, ça se fait déjà (quoi que,
ya des endroits où il trouve plus intélligent de passer un semestre
complet à faire du fork ;). Après on rentre dans le spécifique.
Donc en gros, tu dois, sur un semestre avec 4h par semaine, faire un
résumé de : ruby, sendmail/SMTP, Milter. Et ensuite mené un projet...
c'était bien essayé...
L'étudiant par un projets peut ainsi :
- apprendre et appréhender un nouveau language
- découvrir un protocole (SMTP)
- appréhender un MTA
- découvrir une API d'extension ("call-back oriented")
- étendre un language tel que python/ruby en C
- les threads
- comprendre un programme existant (Python Milter)
- créér une nouvelle solution : filtre Milter scriptable en Ruby
annoncée ensuite sur Freshmeat
Bon il reste aussi les problèmes du réalisme pédagogique. En université on
ne forme pas des gens vers la pratique et c'est volontaire. On ne peut pas
en 2 ans de formations fournir une formation théorique et pratique
correcte, les facs sont les seules à faire la formation théorique
réélement, donc le choix a été fait. J'ajouterai que (point de vu
personnel, tout ça) apprendre des choses pratiques en info (genre nouveau
langage, protocol, utilisation d'API...) ça se fait tout seul devant sa
box avec une bonne doc, ce que tu vas mettre 1 semaine en y consacrant
quelques heures chaques jours, il faudrat 6 mois de cours+TD pour faire
pareil, voir moins bien, je sais de quoi je parle c'est du vécu.
Penses-tu que ce soit trop difficile ou pas assez intéressant pour
des étudiants de licence/maîtrise/IUT ?
Bon, je vais être un peu moins "méchant", mais ça peut rentrer dans le
cadre d'un DESS (et même on peut y rajouter de la conduite de projet), où
les cours sont beaucoup plus spécialisé et où l'accent est un peu plus mis
sur la pratique (vu que finalement la théorie nécessaire, voir plus, a
déjàété faite). Bon par contre pas à Orsay, ici le réseau ne décolle pas
du bas niveau (traitement du signal, contrôle d'erreur et autre truc que
l'on peut faire en intéraction avec les physiciens).
Enfin, pour clore le débat (pas que ça m'intéresse pas, mais bon, on a
déjà tenté pas mal de chose...), on a déjà tenter de mettre en place ce
genre de projet de nombreuse fois, je penses pas que, sauf dans les cas ou
on avait de vrai dev parmis les étudiants, le résultat ai été très
probant, ni pour le projet, ni pédagogiquement.
=> Je pense qu'il y a moyen de contenter tout le monde. Dans le cadre de tels projets, les étudiants doivent être encadrés par un ou plusieurs professeurs - avec éventuellement l'assistance de développeurs Open Source sur Internet pour éviter les problèmes d'absence de continuité et de support.
D'un point de vue "pratique" pour un enseignant, l'assistance extérieur, c'est dur à gérer, voir louche (le but d'un projet c'est quand même de valider un acquis, comment fait-on pour différencier le travail de l'étudiant et celui de l'assistance extérieur...)
Exemple de projet : interface de Ruby & sendmail Milter (<pub/> voir http://milter.free.fr/intro/ pour plus d'infos sur Milter </>)
Bon, ça commence mal, ruby... enfin je vais rien dire, mais un langage non typé tout ça... ;)
Pour intéresser et guider les étudiants on pourrait leur enseigner dans des cours au préalables : Ruby (language + écriture de modules d'extension en C) le protocole SMTP les threads sendmail & l'API MILTER (juste comment rajouter des filtres dans le sendmail.mc pas les rulesets/rules/defines, ansi que les based de l'API Milter en se basant par exemple sur un filtre tel que milter-regex) - Un exemple plus compliqué : un filtre Milter scriptable en python (http://www.bmsi.com/python/milter.html)
Le premier problèmes ici, c'est l'enseignement préalable. Tu ne fera jamais apprendre ruby dans une université française (ou alors un fou dans son coin), globalement, en France, l'univers fonctionnel/typage à une grande importance dans l'histoire de la recherche française. Ensuite enseigner des protocoles spécifiques alors que pour l'instant les cours de réseau sont à peine suffisant pour expliquer (sans même enseigner réélement) TCP/IP. Bon, les threads c'est bon, ça se fait déjà (quoi que, ya des endroits où il trouve plus intélligent de passer un semestre complet à faire du fork ;). Après on rentre dans le spécifique.
Donc en gros, tu dois, sur un semestre avec 4h par semaine, faire un résumé de : ruby, sendmail/SMTP, Milter. Et ensuite mené un projet... c'était bien essayé...
L'étudiant par un projets peut ainsi : - apprendre et appréhender un nouveau language - découvrir un protocole (SMTP) - appréhender un MTA - découvrir une API d'extension ("call-back oriented") - étendre un language tel que python/ruby en C - les threads - comprendre un programme existant (Python Milter) - créér une nouvelle solution : filtre Milter scriptable en Ruby annoncée ensuite sur Freshmeat
Bon il reste aussi les problèmes du réalisme pédagogique. En université on ne forme pas des gens vers la pratique et c'est volontaire. On ne peut pas en 2 ans de formations fournir une formation théorique et pratique correcte, les facs sont les seules à faire la formation théorique réélement, donc le choix a été fait. J'ajouterai que (point de vu personnel, tout ça) apprendre des choses pratiques en info (genre nouveau langage, protocol, utilisation d'API...) ça se fait tout seul devant sa box avec une bonne doc, ce que tu vas mettre 1 semaine en y consacrant quelques heures chaques jours, il faudrat 6 mois de cours+TD pour faire pareil, voir moins bien, je sais de quoi je parle c'est du vécu.
Penses-tu que ce soit trop difficile ou pas assez intéressant pour des étudiants de licence/maîtrise/IUT ?
Bon, je vais être un peu moins "méchant", mais ça peut rentrer dans le cadre d'un DESS (et même on peut y rajouter de la conduite de projet), où les cours sont beaucoup plus spécialisé et où l'accent est un peu plus mis sur la pratique (vu que finalement la théorie nécessaire, voir plus, a déjàété faite). Bon par contre pas à Orsay, ici le réseau ne décolle pas du bas niveau (traitement du signal, contrôle d'erreur et autre truc que l'on peut faire en intéraction avec les physiciens).
Enfin, pour clore le débat (pas que ça m'intéresse pas, mais bon, on a déjà tenté pas mal de chose...), on a déjà tenter de mettre en place ce genre de projet de nombreuse fois, je penses pas que, sauf dans les cas ou on avait de vrai dev parmis les étudiants, le résultat ai été très probant, ni pour le projet, ni pédagogiquement.
Le Sat, 11 Oct 2003 09:16:28 +0200, Patrick Lamaizière écrivit:
Parce que creer un petit logiciel, le finir et en plus q'uil soit utile ce n'est pas pedagogique ? "Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama
Le Sat, 11 Oct 2003 09:16:28 +0200, Patrick Lamaizière écrivit:
Parce que creer un petit logiciel, le finir et en plus q'uil
soit utile ce n'est pas pedagogique ?
"Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama
Le Sat, 11 Oct 2003 09:16:28 +0200, Patrick Lamaizière écrivit:
Parce que creer un petit logiciel, le finir et en plus q'uil soit utile ce n'est pas pedagogique ? "Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama
On Sat, 11 Oct 2003 09:16:28 +0200 Patrick Lamaizière wrote:
mips écrivait :
Parce que creer un petit logiciel, le finir et en plus q'uil soit utile ce n'est pas pedagogique ?
"Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama on ne termine pas un soft, on l'abandonne.
Non ce n'est pas incompatible. On peut tres bien finir un logiciel pour qu'il corresponde au cahier des charges. La maladie du programmeur c'est qu'il veut toujours faire mieux jusqu'au moment ou il s'en lasse.
mips
On Sat, 11 Oct 2003 09:16:28 +0200
Patrick Lamaizière <plamaiziere@alussinan.org> wrote:
mips écrivait :
Parce que creer un petit logiciel, le finir et en plus q'uil soit
utile ce n'est pas pedagogique ?
"Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama on ne
termine pas un soft, on l'abandonne.
Non ce n'est pas incompatible. On peut tres bien finir un logiciel
pour qu'il corresponde au cahier des charges. La maladie du
programmeur c'est qu'il veut toujours faire mieux jusqu'au moment ou il
s'en lasse.
On Sat, 11 Oct 2003 09:16:28 +0200 Patrick Lamaizière wrote:
mips écrivait :
Parce que creer un petit logiciel, le finir et en plus q'uil soit utile ce n'est pas pedagogique ?
"Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama on ne termine pas un soft, on l'abandonne.
Non ce n'est pas incompatible. On peut tres bien finir un logiciel pour qu'il corresponde au cahier des charges. La maladie du programmeur c'est qu'il veut toujours faire mieux jusqu'au moment ou il s'en lasse.
mips
espie
In article , Patrick Lamaizière wrote:
mips écrivait :
Parce que creer un petit logiciel, le finir et en plus q'uil soit utile ce n'est pas pedagogique ?
"Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama on ne termine pas un soft, on l'abandonne.
J'ai au moins un programme (tsort) dans l'arborescence d'OpenBSD que j'estime avoir fini.
Je suis aussi tres satisfait de mon makewhatis. Il peut subir des operations de maintenance liees a l'apparition de nouvelles bizarreries dans des pages de man que je n'ai pas encore vues.
In article <Xns84341B414756Eplam@news.free.fr>,
Patrick Lamaizière <plamaiziere@alussinan.org> wrote:
mips écrivait :
Parce que creer un petit logiciel, le finir et en plus q'uil soit
utile ce n'est pas pedagogique ?
"Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama on ne
termine pas un soft, on l'abandonne.
J'ai au moins un programme (tsort) dans l'arborescence d'OpenBSD que
j'estime avoir fini.
Je suis aussi tres satisfait de mon makewhatis. Il peut subir des
operations de maintenance liees a l'apparition de nouvelles bizarreries
dans des pages de man que je n'ai pas encore vues.
Parce que creer un petit logiciel, le finir et en plus q'uil soit utile ce n'est pas pedagogique ?
"Logiciel" et "finir" ce n'est pas un peu incompatible ? Ama on ne termine pas un soft, on l'abandonne.
J'ai au moins un programme (tsort) dans l'arborescence d'OpenBSD que j'estime avoir fini.
Je suis aussi tres satisfait de mon makewhatis. Il peut subir des operations de maintenance liees a l'apparition de nouvelles bizarreries dans des pages de man que je n'ai pas encore vues.
