Discussion:Atelier Web

De Ensiwiki
Aller à : navigation, rechercher

Discussions

Votre commentaire ci-dessous.


Critiques et discussions avancées

Pourquoi avoir forcément donné un doctype xhtml strict pour des personnes qui n'ont pas une pleine maitrise du css. L'utilisation de balises telles que center ou u sont bien plus évidente pour des débutants comparé à un p style="text-align:center". Le xhtml transitional est w3c et mieux adapté pour les débutants à mon sens (bien que tu n'ai pas parlé sur comment centrer du texte, peut être que tu allais y venir).

Il y a eu du monde pour cette scéance ? --Petitlo 15 novembre 2008 à 23:07 (UTC)

Parce que je désapprouve ce genre de pratiques, et donc que je pense que c'est une mauvaise chose de leur apprendre ça ; mon but n'est pas de leur apprendre le Web dans toute sa crasse, ça ils découvriront d'eux-mêmes, bien assez tôt. Je veux juste que mon atelier reste quelque chose de propre et d'ordonné, avec des concepts simples et clairs, tels qu'une séparation de la sémantique et de la présentation. La rigueur est une bonne chose quand on débute.

Le CSS viendra. Je veux faire quelque chose de clean côté XHTML, pour ajouter rapidement du CSS, qui est la partie généralement fun pour les débutants, de voir leurs machins prendre forme.

J'ai volontairement centré le côté XHTML sur la sémantique, parce que je pense que c'est comme ça que les choses devraient être, donc devraient être enseignées, c'est un choix, et j'assume que cela ne plaise pas à tout le monde. :) Puis, pédagogiquement, cela les mettra en contact avec quelque chose qui est un pur format de données dissocié du traitement que l'on veut en faire (ici, l'affichage), et à mon avis, c'est formateur.

Sinon, étant donné que la séance est pour après les partiels, le monde, je ne sais pas encore s'il y en aura, on verra bien... j'aimerais autant qu'il y ait du monde, mais je ne me fais guère d'illusions. Après, Moy m'a dit de faire de la pub, faudra déléguer ça à quelqu'un...

p.s. : Typiquement, les ateliers sont one-shot, je compte pas sur les gens pour revenir, donc je me sens obligé de faire ce que je pense être « bien » dès le premier jet. J'ai pas plusieurs heures pour commencer par un truc « moins bien » pour après dire « mais maintenant on a mieux ». Ils vont voir tout ça en 1h30, faut pas oublier...

--Len 16 novembre 2008 à 00:35 (UTC)


Pour une prochaine fois, une bonne démo serait de faire les sujets en html (pour montrer le bon example ;-)). De même pour les slides en ajoutant un peu de javascript, par exemple avec S5.

Sinon une info pour ceux que ça peut intéresser : un livre sur CSS est offert pendant encore une dizaine de jours. Je ne l'ai pas lu en détail donc je ne peux pas vraiment donner un avis éclairé.

--Emonet 19 novembre 2008 à 20:42 (UTC)

Personnellement l'idée de devoir écrire en HTML ne m'enchante guère, mais je peux le faire pour les TP ; pour les slides, je préfère garder quelque chose de sain (JS hater inside).

--Len 21 novembre 2008 à 12:50 (UTC)

JS c'est très bien mais un débutant ne doit pas voir son contenu car c'est un langage de programmation donc => on change de contexte. (<feed-da-troll>et js c'est très bien !</feed-da-troll>) --Petitlo 21 novembre 2008 à 13:30 (UTC)

Btw, pour la question initiale du monde ; pour l'instant il y a 28 inscrits pour la séance 1, ce qui est tout à fait raisonnable. Après, je pense qu'il y en aura forcément qui nous ferons défaut, mais apparemment il y en a aussi qui veulent venir tout en ayant trop la flemme de s'inscrire (doh...) parce qu'ils sentent qu'ils sont contraints de venir sinon. Donc avec de la chance ça va compenser.

Mais bon, les gens ont du mal avec le mail aussi. J'ai envoyé un mail général pour éventuellement splitter en mercredi / jeudi, à tout le groupe ce matin à 9h et pour l'instant j'ai eu une seule réponse, alors que plusieurs personnes s'étaient exprimées sur le sujet... Il est 22h et une seule personne a checké son mail @ensimag ? Erf...

Sinon, il est vrai que ce serait peut-être pas plus mal que l'on ait un intervenant qui soit un vrai webbeux, parce que bon moi je suis un systémeux et un compileux avant tout, j'aime pas le GUI, les trucs fancy et je vis sous Emacs, donc forcément, il y a hum comme un choc culturel. :D

p.s. : Qui est Emonet ? Un seul message sur le Wiki et c'est celui-ci, pour commenter un pauvre article au fin fond du Wiki. :D Pas de page descriptive, inconnu au ZENITH, pas de compte sur le telesun, et le seul compte que j'ai toruvé, sur l'ensisun, n'a aucune description associée, pas de real name ou quoi... enfin, juste une curiosité personnelle. :) --Len 21 novembre 2008 à 21:18 (UTC)

(Rémi) Emonet est un ancien Ensimag, en fin de thèse, et maintenant ATER ici. Moy 23 novembre 2008 à 13:07 (UTC)

Merci Matthieu, ça résume assez bien. Je suis assez occupé en ce moment mais j'espère pouvoir contribuer un peu plus activement au wiki plus tard dans l'année. --Emonet 26 novembre 2008 à 07:46 (UTC)


Wow je pensais pas qu'il y aurait autant de monde dès la première séance, c'est génial ! J'aurai bien fait l'intervenant webbeux mais bon je suis plus occupé que jamais en ce moment donc je ne pourrais pas assurer... dommage. Mais il faudra un in tervenant là dessus parce qu'un plain html à coup de table ça ne suffit plus pour faire un site qui pete de la GUI. Mais après est-ce que c'est vraiment le but de l'atelier ?

Parce qu'après le web c'est un petit morceau, il y a énormément de techno différentes et longues à apprendre (si on attaque dans le JS, on a droit à l'ajax, les effets graphiques, la manip XML et je parle pas des XSLT ou XPath). Il faudrait définir le but final des séances... --Petitlo 21 novembre 2008 à 22:19 (UTC)

De l'objectif des ateliers

Honnêtement, moi le Web c'est pas mon truc ; c'est juste pour leur donner des bases avec des technologies grand public, même si elles sont merdiques (pas que le reste soit de la pure jouissance non plus...). Je ne compte pas poursuivre plus que ça sur le Web ; de toute manière s'ils veulent, ils auront largement l'occasion d'aborder tout un tas de technologies Web-oriented, en temps voulu (et je pense que la 2A peut leur donner les outils d'explorer ça selon leurs désir).

Pour ce qui est de l'orientation à donner aux ateliers, pour l'instant, je vise à centrer ça autour de questions assez basiques (« informatique et programmation pratiques ») ; ça sert absolument à rien qu'ils aient des notions de XML-branlette alors qu'ils ne savent pas écrire de parser, n'ont jamais travaillé avec des tables de symboles, etc. Pour l'instant, les ateliers pourraient s'appeler « compléments de base ». Évidemment, je ne veux pas faire ça de manière trop scolaire, donc on applique ça à des domaines, mais dans l'idéal, il faudrait qu'ils retiennent du XHTML et du CSS des concepts de séparations de tâches, de description de données, tout ça, plutôt que « oh tiens je sais faire une page Web ! »

Par ailleurs, pour l'instant, je suis le seul à investir quoi que ce soit dans les ateliers, et tant que les ateliers ne seront pas une structure suffisamment robuste pour tenir d'elle-même (si cela arrive un jour...), ils seront forcément limités à des sujets qu'au moins je ne déteste pas complètement (et le Web est déjà à la limite, mais alors les technos de Webapps que j'exècre au plus haut point... sans plaisanter). Donc, « le but des ateliers », pour l'heure, c'est « ce que Nhat Minh Lê pense que les 1A devraient savoir faire » (avec des compromis, comme le Web). :) Ça peut paraître très égocentrique comme point de vue, et ça l'est, mais bon, j'ai pris en charge toute cette idée d'ateliers, avec comme seul retour (potentiel) le satisfaction d'avoir enseigné quelque chose que je pense « juste » à des gens intéressés. Pour moi, le « mind sharing » est ma seule récompense, mais j'y tiens. :)

Plus concrètement, ce que j'aimerais (mais si ça tourne autrement, ou si ça meurt avant, c'est la vie), c'est former des gens au C, et à la programmation pratique (pour parodier Pike, comment faire 99% des programmes du quotidien avec des listes, des tableaux, des arbres binaires et des tables de hachage), d'ici la fin de l'année. Parce que j'estime que mon langage préféré n'est pas suffisamment abordé. :) Et puis, il faut bien que mes skills en C servent à quelque chose ; aller faire mon chaud et cramer des jeunes sur le projet C alors que j'ai probablement en nombre d'années plusieurs fois leur expérience, c'est d'un intérêt nul. :D

--Len 22 novembre 2008 à 00:25 (UTC)

Salut,

Ne t'en fais pas pour le C, trois semaines de C intensif, ça fait des miracles : je suis passé du niveau "y connaît rien en C, et considère ça comme un sous-java" à un bon niveau (je pense) avec uniquement le projet C (et un stage d'été, mais je pense qu'une bonne partie des ensimag font des stages où ils codent en C/C++). En plus de ça, il y a les TP de SEPC obligatoires en 2A (ptet pas dans la nouvelle école, remarque, à vérifier) qui apparemment font faire du système en C. Et des options pour ceux qui font la filière info.

Ca serait pas plus intéressant de faire ça sur des trucs un peu plus obscurs, non enseignés à l'imag ? Par exemple, dans aucun cours à ma connaissance n'est enseigné de langages dynamiques, et des trucs comme faire des petits scripts en perl ou autres, et ça me paraît quand même assez important.

J'avais une idée similaire l'an dernier, que j'ai jamais concrétisé par flemme et timidité : des "lightnings talks". L'idée était que, une fois par semaine ou un truc comme ça, soient organisés des petites (genre 10 mins + 10 mins questions) démonstrations, faites par des volontaires (et pas uniquement les organisateurs) de sorte que les étudiants puissent faire partager leurs connaissances sur un sujet précis ou leur enthousiasme pour un truc qu'ils ont découvert. J'avais pensé à des sujets comme git, des concepts de langage de prog (les continuations en lisp, les monads en haskell, des trucs du genre), mieux utiliser emacs/vim, tel ou tel détail de linux ou d'un autre OS ... le but principal étant de faire découvrir le truc en question à des gens, et de piquer suffisamment la curiosité de ceux que ça intéresse vraiment pour qu'ils approfondissent par eux même.

  • Pour ce qui est de Git, on en a causé avec Nhat Minh qui est pas super chaud, mais moi, je co-encadre un atelier dessus quand tu veux (j'essaye de convaincre mes collègues de remplacer SVN par Git dans le projet GL mais c'est pas gagné ;-) ). Par contre, je pense pas que 10 min + questions puissent suffire pour ça. Moy 23 novembre 2008 à 13:16 (UTC)

Voila, si ça intéresse quelqu'un de reprendre le concept ... En tout cas, très bonne initiative, j'espère que l'atelier web sera le premier d'une longue lignée.

--Levitta 22 novembre 2008 à 10:12 (UTC)

Hum, désolé d'être sceptique mais les skills que tu acquières en trois semaines de code intense avec une deadline menaçante, ce sont des survival coding skills. Ça ne te donne ni le recul, ni l'expertise nécessaire pour être « bon » ; tout ce que ça t'assure, c'est que si on te jette dans un environnement hostile, forcé à faire du C, tu pourras faire un truc qui marchotte. Voilà pour les choses désagréables. :)

Après je n'ai pas dit que je ferai du C forcément, et si ça n'intéresse pas, bah, tant pis. Après, si tous les imagiens pensent qu'ils sont trop bons en C pour avoir besoin / envie d'en apprendre plus, beuh, c'est la vie. [juste, no offense intended :p]

Pour ce qui est des langages dynamiques, on va probablement faire PHP en atelier Web et on fait du scripting shell en cours d'Unix avancé, donc ils auront leur dose de scripting ; après, apprendre un nouveau langage, ce n'est pas le plus intéressant. Ah, et Perl, j'aime pas. :p

  • Pour l'Unix avancé, c'est 4 séances d'1h30, donc très peu. Y'a largement moyen de faire plus de choses intéressantes. Moy 23 novembre 2008 à 13:43 (UTC)

Pour l'histoire des talks rapides là, franchement, je pense que tu mesures mal l'audience générale de l'imag ; en 1A, tu as de la chance si tu trouves quelqu'un qui te fait la différence fonctionnel / impératif. Et puis faudrait voir que ça ne devienne pas une espèce de blog IRL géant où chacun parle de sa branlette du jour. Mais pourquoi pas, si on trouve du monde pour y assister, je parlerais volontiers de choses qui m'intéressent, et d'un meilleur niveau que mes ateliers.

Pour « mieux utiliser Emacs », je comptais en faire un atelier, mais j'ai sondé les gens, ya pas masse d'intéressés.

Après, ce que j'aurais aimé faire, pour en revenir aux ateliers, c'est des trucs plus ciblés, mais pour ça, faut des outils, c'est pour ça aussi que je voulais faire le C avant, mais bon, on verra bien. L'idée, c'est que faut que les ateliers restent in sync avec la promo, et en 1A en gros, les gens (pour la plupart, à part ptet une poignée qui viennent d'IUT info) ont un peu de culture informatique mais ils ne savent encore rien faire, ne maîtrisent aucun langage / outil / etc., donc pour faire des ateliers applicatifs c'est difficile.

Enfin, laissons décanter ; moi je vais réviser mes partiels...

p.s. : Btw, t'as fait un stage en 1A avec du C ? Tain, je veux faire ça moi. :D Enfin, ça a pas l'air gagné pour trouver un stage...

--Len 22 novembre 2008 à 13:01 (UTC)

Sur le stage C : j'ai pas dit que ça m'avait rendu guru du C, mais franchement, trois semaines à bosser en groupe sur un sujet intéressant (et la deadline, c'est loin d'être un problème si tu sais déjà un peu coder avant, donc c'est pas vraiment stressant et ça permet de prendre son temps), ça apprend pas mal, surtout si tu te limites pas aux sources d'information fournies à l'imag (bien que le poly de C d'intro au C distribué soit super, ça remplace pas le K&R). D'autant plus qu'avec les cours d'assembleur d'un côté et d'ada/java de l'autre, le sujet du projet qui fait toucher à des trucs "fondamentaux" (les différentes phases de compilation notamment) et le fait qu'on y retouche pas mal en 2A, je pense pas que yait forcément besoin de rajouter des trucs en C (je ne dis pas que ya rien à apprendre de plus, hein)

Je me rends probablement pas bien compte du niveau en info des gens de l'imag, mais une bonne grosse partie vient de MP info, et ils ont fait du caml pendant deux ans (voire plus :]), donc ils doivent au moins connaître deux trois trucs sur la programmation fonctionelle.

Concernant Emacs, ça m'étonne. Pas mal de gens avaient l'air intéressés par apprendre à se servir d'emacs, notamment pour interfacer avec des programmes externes utilisées en cours (scilab, R, matlab, sql ...). Et quand on voit en TX les gens sous emacs qui sauvegardent leur fichier avec file/save, ou qui changent de buffers en cliquant sur la barre en bas (et recommencent parce qu'ils ont loupé le buffer qu'ils voulaient), on se dit que ça doit pas être bien difficile de les convaincre qu'ils pourraient aller beaucoup plus vite sans trop d'efforts.

Bon courage pour les partiels. Moi j'ai encore trois semaines :)

Pour le stage 1A : Google summer of code :) (et en plus, il a été validé comme stage entreprise, ce qui fait que je peux faire un stage dans un labo cette année). De toute façon, t'inquiètes pas c'est pas bien dur de trouver un stage avec du C, a priori.

--Levitta 22 novembre 2008 à 17:16 (UTC)

Bon je pense que tu ne vas pas aimer vu ta passion Emacs :). Mais j'viens de penser à un cours sur la productivité via un quelconque IDE (Netbeans / Eclipse ou autre). A l'imag il n'y a aucun cours concernant "Comment bien coder". Dans certaines écoles (epita ou autre), ils appliquent une charte de code et qu'il faut respecter à la lettre (sinon points en moins pour accolade mal placée). Je suis contre le mécanisme mais ici on est très voire un peu trop laxistes.

Exemple tout simple, un imagien ne sera pas gêné par une fonction de 300 lignes, une classe de 3000 lignes, du code redondant, des espacements fait au hasard, des conventions majuscules/minuscules changeantes et je ne parle pas des couplages des classes. Or les IDE fournissent des outils magnifiques pour appliquer des méthodes agiles (du genre d'extreme programming) de façon très très efficace. Quelques exemples tout bêtes : Une fonction de 300 lignes est découpable quoi qu'il arrive, à coup d'"extract method", on peut obtenir du code joli et maintenable en moins de 2 min. Ou encore, une exception doit être levé en un clic (ou alt+entrer ou F1 suivant les IDE) on a un try... catch ou throws qui apparait. Le reformat-code qui réarrangera les indentations/espaces pour avoir un code lisible.

Le mieux dans ce genre de domaine est la programmation Java car les IDE sont vraiment impressionnantes de possibilités (mon IDE me crie dessus si j'ai deux boucles imbriqués dans mon code). J'aimerai qu'on ai pareil pour C++ (à part Visual C++), Eclipse est bon mais très limité dans ce genre de features. Mais bon... après ça c'est un autre débat...

Bref c'est un peu méchant de ma part de proposer ça parce que ce n'est qu'une idée qui part dans le vent puisque je ne pourrais pas m'en occuper :'( vu le boulot que j'ai. Il faudrait essayer de voir tous ceux qui serait volontaires pour faire des petits ateliers comme ça !

--Petitlo 22 novembre 2008 à 14:38 (UTC)

Des ateliers sur comment bien coder, ça m'intéresserait de les faire, mais j'ai peur que le public ne suive pas. Par contre pour tous les trucs automatisés, on m'en a beaucoup parlé, effectivement, mais sans vouloir troller, on peut très bien coder de manière clean en C sans y avoir recours, les gens font ça depuis des lustres bien avant que toutes ces features voient le jour, mais je ne nie pas que ça aide. Et puis, pour des débutants, il vaut mieux qu'ils comprennent comment on fait ça « à la main » d'abord ; aucune règle automatique n'est parfaite. Et c'est un bon exercice, pour l'esprit, d'apprendre à décomposer le code sans attendre que ce soit trop gros et imbouffable pour enfin se dire « tiens, je vais sortir mon super tool qui va me le refactoriser », et comme tous les outils puissants, c'est l'impression que l'IDE va donner aux débutants. Tout ça pour dire qu'il vaut mieux apprendre à discipliner son code, avoir un style cohérent et des habitudes saines, que savoir utiliser Eclipse, parce que ça, dans la vie, ça peut aider à refactoriser, même quand on a rien de spécial, juste un ptit éditeur de texte (ou un gros, dans mon cas :p).

Pour ce qui est du troll Emacs, l'indentation automatique d'Emacs est tout à fait au point (du moins pour le C). Pareil, les insertions de code marchent bien. En fait, Emacs n'a aucun support sémantique (même si ya des gens qui bossent dessus, moi j'y crois bof), mais le support syntaxique est excellent. Historiquement, je ferai aussi remarquer que l'indentation automatique intelligente d'Emacs existait bien avant Eclipse. :p

Btw, je ne suis pas contre ce genre de features, donc si quelqu'un veut faire ces présentations, pourquoi pas. Ah, et faut pas croire que parce que j'utilise Emacs maintenant, je n'ai jamais utilisé MSVC ou des choses comme ça par le passé. :D

--Len 22 novembre 2008 à 15:25 (UTC)

Ce n'est pas spécialement pour permettre aux gens de coder sale et avoir un outil qui remet ça proprement. C'est que les méthodes de travail pour des problèmes classiques (pauvre base de donnée simple ou autre) se retrouvent dans les méthodes rigides telles que Merise, on construit toute l'application sur UML et après le codage se fait "automatiquement" sans beaucoup réfléchir. Toutefois quand on se retrouve face à des problèmes plus expérimentaux où on ne voit pas vers quoi ça va aller on est obligé d'utiliser des méthodes plus agiles. En clair, on va coder très une partie, la valider et on passe à une autre partie, quitte à refactoriser par là suite. Par exemple, j'ai passé mon été à faire un gros projet et je n'arrête pas de refactor (alors que des analyses ont étés faites proprement).

Le refactor ce n'est pas parce que les gens ne savent pas coder propre, c'est juste une manière d'aller vite en méthode agiles. Et c'est là que ces outils fonctionnent efficacement.

Mais bon, pour en revenir à ce que je proposais c'est que quand on se retrouve avec ceci :

apply(unObjet.uneMethode().toSomething());

Et que l'on veut rajouter un logeur qui imprime le something avant très rapidement: sélection via ALT et SHIFT ; CTRL+SHIFT+V (extract variable, certains IDEs proposent des noms en fonction de la sémantique), et le logeur à coups d'auto-completion (CTRL+SPACE). Et on obtient rapidement :

Something objet = unObjet.uneMethode().toSomething(); 
log.info(objet);
apply(objet);

Ca peut paraitre complètement anodin mais à force d'application de raccourcis du genre, la productivité est énorme. Et je ne parle pas de la génération de code genre Generate Constructors from Fields ou l'inverse, ou Generate Setters/Getters.

Après concernant le "troll" Emacs / IDE, moi si tu as des méthodes qui te permettent de faire pareil sous Emacs tant mieux ! Le but est pas de te faire passer sous IDE mais juste présenter ce genre d'outils. --Petitlo 22 novembre 2008 à 16:35 (UTC)

Ce genre de fonctionalités c'est je pense assez inutile en C : ça a tendance à utiliser moins de concepts qui se prêtent bien à du refactoring, et si ya besoin de répéter souvent des trucs, le préprocesseur est là pour ça. Par contre en Java, ça doit être extrêmement utile ouais. Mais je pense pas que le besoin s'en fasse sentir en 1A (peut être en 2A dans le projet BD ?) : c'est pas pour les trois quatre TP qu'on a à faire en java que ça va servir ...

--Levitta 22 novembre 2008 à 17:16 (UTC)

Comment s'est passé la première séance ? Pour info, je suis en train de réfléchir mais je pourrais faire une intervention sur le javascript (manipulation de formulaire, manip de dom et forcément ... ajax), je garantis rien parce que mon emploi du temps se fait un peu au jour le jour, mais ça doit pouvoir se faire. --Petitlo

Et bien, on n'était pas beaucoup (1/3 seulement des inscrits sont venus ! pour diverses raisons mais c'est vraiment peu). Mais c'était pas mal. Mon cours était pas terrible parce que j'avais pas l'habitude, mais je ferai mieux la prochaine fois. On verra bien la prochaine fois. --Len 3 décembre 2008 à 22:50 (UTC)