A3P / IPO

A3P = Apprentissage Par Problème de la Programmation (IGI-3007 pour les E3ST)
IPO = Introduction à la Programmation Objet (IGI-1202 pour les E1)

I. Pédagogie différente :

de vos pratiques habituelles
de ce qu'ont vécu les étudiants dans leur scolarité
de ce que vivent simultanément les étudiants dans la plupart des autres matières

II. Profil des étudiants :

II.1

En E1, il y a 11 ou 12 groupes de 24 à 26 étudiants : numérotés de 1 à 12.
Compte tenu de la complexité engendrée par ces 12 groupes, vous serez affectés "au hasard" sur les différents groupes et ne suivrez donc pas forcément les mêmes étudiants. Pour une même séance, certains d'entre-vous encadreront 1 ou 2, voire 3 ou 4 groupes, pas forcément toujours les mêmes.
En E3ST, il y a 2 à 4 groupes de 24 à 26 étudiants (J1 à J4)
Vous ne pouvez encadrer qu'un seul groupe, pas forcément toujours le même.

II.2

En E1, les étudiants que vous aurez en TP étaient lycéens il y a encore quelques mois, et n'auront pas eu de cours avant ce TP sur le thème traité ; la plupart du temps, ils découvriront les notions dans la première page de l'énoncé et parfois aussi au fur et à mesure des exercices.
Par contre, ils auront déjà programmé en Java pendant les 34h d'IPA, uniquement de la syntaxe de base. Donc ils ne connaîtront pas classe, objet, attribut, méthode, constructeur, this, public/private, Math, System.out.println, main, ...
En E3ST, la plupart des étudiants que vous aurez en TP étaient en prépa il y a 3 mois. Ils ont fait du Python, mais certains avouent être passés totalement "à côté", surtout quand leur prof de maths n'était pas formé à l'informatique.
Pour information, ils auront en milieu d'unité 12+8h d'initiation au langage C.

II.3
Il faut donc être prêt à répondre de nombreuses fois aux mêmes questions sans avoir l'air de reprocher leur ignorance aux étudiants. Il faut même solliciter les questions si certains étudiants ne se manifestent jamais.

II.4
Dans la plupart de leurs autres matières, les étudiants font les TP en binôme. Ici, ils seront volontairement un seul par poste pour les forcer tous à réellement essayer de faire ce qu'on leur demande, et non se contenter de regarder leur copain (quand ils ne se mettent pas à parler ou bien à naviguer sur leur smartphone ...).
Tant qu'il y a un poste de libre (éventuellement sur 2 salles contigües), obligez-les à se séparer et à ne pas s'agglutiner avec 3 ordinateurs portables sur le même table.
Lorsqu'ils utilisent les postes de l'école, incitez-les à utiliser Linux, non pas pour la ligne de commande qu'ils n'ont pas encore apprise, mais simplement pour se familiariser avec ce système qu'ils craignent.
S'il manque des postes, demandez à ceux qui ont apporté leur pc personnel de l'utiliser. Au pire, dans une salle de 13 postes, il faut qu'au moins la moitié des étudiants aient apporté leur portable (il est rare que ce ne soit pas le cas).
En cas d'absence d'un intervenant, vous pouvez être obligé de vous déplacer sur les 2 salles contigües ; dans ce cas, me le signaler au plus tôt.

III. Réponses aux questions :

III.1
Ils ne peuvent réellement apprendre (c'est-à-dire retenir) quelque chose que s'ils l'ont eux-mêmes "trouvé". Aussi, il ne faut jamais leur dire ce qu'ils doivent taper, mais leur faire "deviner" en leur donnant suffisamment d'indices, ou en leur posant une question qui leur fait comprendre la similarité avec une situation qu'ils connaissent déjà.
Par exemple, s'ils vous demandent comment appeler la méthode sqrt :
- ne pas leur répondre "Math.sqrt(x)"
- mais leur répondre "Comment appeler une méthode statique quand on sait à quelle classe elle appartient ?"
Si vous perdez patience après 2 ou 3 échanges infructueux sur le même sujet avec le même étudiant, vous pouvez lui indiquer la solution, mais le mieux reste de lui montrer où cette solution est écrite ou expliquée.
L'essentiel est de vous assurer que l'étudiant obtient toujours la réponse à sa question, éventuellement en plusieurs fois.
Ne pas rester trop longtemps avec un même étudiant (< 5mn ?), car les autres finissent par ne plus appeler l'intervenant.

III.2
Ils ont le droit de communiquer (à voix basse) avec leurs voisins (éviter qu'ils soient souvent debout), mais ils ne doivent absolument pas regarder la solution sur l'écran d'un autre : ils auraient alors perdu la possibilité d'apprendre/mémoriser ce qui était souhaité dans l'exercice considéré. Il faut aussi répéter aux étudiants qu'ils peuvent aider un camarade, en lui expliquant quelque chose, mais jamais en lui donnant ou montrant la solution.

III.3
Essayez de repérer ceux qui n'appellent jamais : cela fait partie de votre mission d'aller voir leur travail et de leur signaler ce qui ne va pas dans leur code ou s'ils partent sur une trop mauvaise piste.
Passer voir systématiquement tous les étudiants permet aussi de constater l'avancement du groupe et de chacun.
Ne pas laisser partir un étudiant qui a soi-disant tout terminé sans avoir vérifié son code (Est-ce bien programmé ? Et les conventions de nommage sont-elles respectées ?).

III.4
Il est bien sûr essentiel de ne pas répondre quelque chose de faux : quand vous ne savez pas, il faut dire "Je ne sais pas.". Il y a toujours un collègue dans votre salle ou une salle contigüe. Si personne ne sait, envoyez-moi un mail (ou un sms), et en dernière extrémité, dites simplement à l'étudiant de me poser plus tard la question en 5356 ou par mail.

IV. Organisation de l'unité :

IV.1
Étalée sur plusieurs mois, cette unité est découpée en séquences, chacune autour d'un thème, plus un projet qui se déroule en parallèle.
Chaque séquence se décompose généralement en : TP + TD + Pers + Cours, mais il y a des variantes, plus les TP de projet.

IV.2
Toutes les ressources et le séquencement se trouvent soit sur Moodle, soit sur ma page web (selon les années) sauf les corrigés qui vous seront envoyés par mail.
Les énoncés pourront légèrement évoluer par rapport aux anciennes versions.
Il est indispensable d'avoir sur vous pendant les TD/TP les sujets (pour pouvoir noter les coquilles/problèmes/ambiguïtés), ainsi que les corrigés (pour savoir ce qui est attendu dans chaque question).
Lorsqu'ils vous sont envoyés suffisamment à l'avance, je souhaite que vous lisiez les sujets et les corrigés avant la séance pour me faire remonter les éventuelles incompréhensions, ambiguïtés, erreurs ou ommissions.
Je suis également très friand de toutes vos remarques et suggestions après une séance, et en particulier de toute correction que je pourrais effectuer avant que d'autres groupes d'étudiants ne soient concernés.

IV.3
Lorsque l'unité est sur le Moodle de l'université :
- Vous y avez accès en tant qu' Enseignant non éditeur.
- Chaque séance apparaît dans la bonne semaine calendaire sur la page principale et renvoie à un article de forum pour son contenu, ce qui permet aux étudiants de simplement y répondre pour poser une questions s'y rapportant. Je vous invite naturellement à participer à ces discussions.
- Compte tenu du nombre élevé d'étudiants en E1, je souhaiterais que chacun(e) d'entre-vous s'inscrive aux forums au moins sur la période janvier-avril, et réponde aux questions si je ne les ai pas encore vues. Si vous ne répondez pas exactement de la manière que j'aurais souhaitée, je posterai simplement un message pour compléter votre réponse.

IV.4
Vous devrez saisir les absences et retards dans Aurion (WebAurion, Scolarité, Mon planning, cliquer sur le créneau, Apprenants, ne pas oublier de valider), soit avant la fin de la séance, sinon avant la fin de la journée ; c'est par cette même connexion que vous attestez de votre présence à la séance prévue dans votre emploi du temps.
Dans le cas d'un départ prématuré de certains étudiants, noter le nombre de minutes manquantes dans la colonne "Retard".
Dans le cas où un étudiant refuse de faire le travail prévu pour le TP considéré, après le lui avoir demandé explicitement, vous devez le noter absent et me le signaler.
Si un étudiant a TOUT terminé (y compris les parties indiquées à terminer en travail personnel), et qu'il vous a appelé pour que vous vérifiiez son code, et que vous ne trouvez rien à lui faire améliorer, il peut partir en avance.

IV.5
Il est fortement conseillé de vérifier son emploi du temps une semaine à l'avance, car il peut arriver qu'une modification ne soit pas signalée explicitement, et de le revérifier la veille car au moins la salle a pu changer.
Merci de me prévenir aussitôt en cas d'absence d'un intervenant : je peux peut-être le remplacer au pied levé, et s'il a un autre TP après, je peux l'appeler pour qu'il arrive.
Rappel sur ADE : choisir l'utilisateur lecteur1 sans mot de passe, puis taper son nom dans le champ de recherche (des CTRL-clics bien choisis permettent de sélectionner plusieurs jours ou semaines).

V. Vocabulaire :

TP : dans une salle de PC, 24/26 étudiants sur 24/26 postes avec 2 enseignants, ou bien, 12/13 étudiants sur 12/13 postes avec 1 enseignant (dans ce dernier cas, les 2 demi-groupes sont planifiés dans 2 salles contigües, et les 2 enseignants sont censés "naviguer" dans les 2 salles, quand ils ne sont pas "accaparés" dans l'une)
Nouveauté à partir de 2021/2022 :
Vous êtes seul (dans une salle de 12/13 ou 24/26 postes) avec 24/26 étudiants ; un TP seul est comptabilisé comme un TD.
Le sujet commence souvent par une partie à lire (ceux qui l'ont lue avant rentabilisent mieux le temps-prof). Lorsque vous n'êtes pas accaparé par les questions, vous devez aller voir les étudiants qui ne vous ont jamais appelé pour voir s'ils avancent tout seuls ou s'ils sont bloqués et n'osent pas demander.
Aucun rapport de TP n'est demandé en fin de séance, même pour les questions qui sont posées dans les énoncés. Ils ont simplement intérêt à noter leur réponse, et à demander s'ils ne savent pas y répondre.
Il faut simplement leur rappeler à chaque fois qu'ils doivent terminer le TP en travail personnel.
Le sujet est fourni directement sur la page web de l'unité.

TP de projet : il y en a très peu :-(
Certains TP n'ont pas d'énoncé spécifique ; les étudiants devront juste avancer dans les exercices du projet. Votre rôle consistera à les aider à résoudre leurs problèmes en Java, pas à accepter des modifications du cahier des charges. Si vous avez besoin de les aider à comprendre un exercice, bien lire l'énoncé et les questions/réponses du forum juste en-dessous.
Attention! Bien qu'il n'y ait pas d'énoncé, les étudiants doivent au début du TP consulter la séance sur le web pour voir ce qu'ils sont censés faire : parfois remplir un compte-rendu d'avancement, par exemple.

TD : dans une salle de cours, 24/26 étudiants avec 1 enseignant, éventuellement disposés en ilôts de 4 étudiants (éventuellement 3, si ça ne tombe pas juste), sur le même thème que le TP précédent, pour être capable d'écrire du code java sur papier (interdire l'usage d'un compilateur sur ordinateur, autoriser la consultation du cours sur documents ou internet, ne pas laisser seuls ceux qui n'écrivent rien et détecter ceux qui n'appellent jamais ; se faire appeler en cas d'incompréhension, de blocage, ou de réussite ; sauf exception, pas de solution donnée au tableau). C'est leur meilleur entraînement pour les contrôles écrits.
Leur rappeler à chaque fois qu'ils doivent terminer le TD en travail personnel, et si possible, le passer sur machine pour en vérifier le bon fonctionnement.
Le sujet est fourni directement sur la page web pour vous, et sous forme papier en 24/26 exemplaires pour les étudiants.
Le corrigé est destiné à l'enseignant, surtout pour qu'il sache exactement ce qui est attendu des étudiants. Il doit donc être lu avant le TD !
Sauf situation exceptionnelle, ne jamais mettre de corrigé complet au tableau. Parfois, il peut être nécessaire d'écrire du code au tableau, étape par étape avec l'explication de la démarche.

Résa ou Pers : dans une salle de PC, 24/26 étudiants sur 12/13 ou 24/26 postes sans enseignant pour être sûr d'avoir un PC pour avancer leur travail.
Certaines séances sont dédiées (pour rendre le projet, par exemple).
Il y a généralement une réunion MS Teams prévue en même temps pour que les étudiants puissent poser une question à un intervenant en cas de blocage.

Cours : Denis BUREAU en amphi, par demi-promo, avec slides, pour "restructurer" ce qui a été vu en TP+TD(+projet)

Toutes ces séances peuvent avoir lieu en présentiel ou en distanciel. Dans ce cas, les étudiants (et les enseignants !) doivent se connecter sur la session MS Teams correspondant au bon groupe.

Ce type de séances n'existe plus :
- TP+c : TP de projet avec coach, sur 2 salles de 12 contigües ou 1 salle de 24
  - le contenu de la séance est toujours sur iCampus et commence généralement par la mise à jour du Compte-Rendu d'Avancement
  - le suiveur (technique) du groupe aide les étudiants (des 2 salles) à résoudre leurs problèmes en java (par contre, seul Denis BUREAU peut autoriser un changement de cahier des charges)
  - le coach établit un contact différent avec chaque étudiant (des 2 salles), détecte les pbs scolaires ou extra-scolaires, fait prendre conscience de la situation à l'étudiant, le conseille pour rattraper un éventuel retard, l'incite à poser des questions et à aller voir les enseignants informe l'intervenant technique des points saillants, rend compte rapidment à Denis BUREAU des problèmes dans chaque groupe. Il doit notamment de pas se faire "embobiner" par les étudiants qui ne s'inquiètent pas de leur retard : il faut leur demander systématiquement quelles mesures concrètes ils vont prendre et exactement quand.
- TP proj : TP de projet avec un seul intervenant technique sur 2 salles de 12 contigües ou 1 salle de 24
  - Le contenu de la séance est toujours sur iCampus et commence généralement par la mise à jour du Compte-Rendu d'Avancement.
  - L'intervenant technique aide les étudiants (des 2 salles) à résoudre leurs problèmes en java (par contre, seul Denis BUREAU peut autoriser un changement de cahier des charges).
  - En cas de TP d'évaluation de l'avancement, l'intervenant technique évalue l'avancement réel de chaque étudiant (des 2 salles).
- TDc : TD de coaching, 24 étudiants avec un coach dans une salle de cours juste une heure pour éviter certains écueils récurrents.

VI. Les salles à partir de 2021/2022

Le matin, vous trouverez fréquemment votre salle fermée. La clé se trouve dans la boîte à clé fermée par un code tout près de la porte (les codes sont consultables ici).
En cas de problème de clé, vous pouvez contacter l'accueil ou les gardiens.
Merci de bien toujours ouvrir les deux portes pour des raisons de sécurité en cas d'évacuation.
À ce propos, en cas de sonnerie incendie, merci de faire sortir TOU(TE)S les étudiant(e)s le plus rapidement possible et de les accompagner en général en bout d'épi pour aboutir sur la pelouse derrière les bâtiments.
Les salles 5101, 5103, 5301, 5309, 5401, 5403 possèdent 26 postes en double-boot Linux / Windows 10.
Les salles contigües et communicantes sont : 5101+5103 et 5401+5403.
Les salles 1107, 1109, 1205, 1207, 1209 ont la même configuration que ci-dessus, mais seulement 13 postes et il est moins facile de se faufiler derrière les étudiants pour voir leur écran.
Les salles contigües et communicantes sont : 1107+1109 et 1205+1207 / 1207+1209.
En cas de manque de salles, nous pouvons être amenés à utiliser des salles moins bien adaptées telles que 520x, 400x, 410x, 330x, 340x, 230x, 240x, ...
Si vous avez besoin d'écrire au tableau, munissez-vous d'un feutre pour tableau blanc.

homedir

VII. Le projet :

Il s'agit du projet Zuul proposé dans le livre Objects First with Java, projet remanié au fil des années pour aboutir à la Liste officielle des exercices que les étudiants doivent suivre scrupuleusement.
L'objectif de ce projet n'est pas le jeu obtenu à la fin, mais plutôt d'apprendre plus de Java et notamment la conception objet qu'on ne peut pas apprendre sur de "petits" TP.
Le moteur de jeu sera construit pas à pas dans les TP 3.1 et 3.2, puis les élèves devont développer leur projet essentiellement en dehors des heures planifiées.
~~Vous devez aussi vous inscrire à l'unité Zuul pour avoir accès à tous les détails.~~

VIII. Les logiciels :

JDK 11 (pas la dernière version JDK 17, mais le JDK 11 pour rester compatible avec les postes ESIEE, même si on n'utilise que la syntaxe du JDK 7)
BlueJ (entre 4.2.2 et 5.0.3) pour rester compatible avec les postes ESIEE

Chaque intervenant doit se familiariser avec BlueJ, notamment l'inspecteur, le debugger, le code pad, et l'exécution de tests unitaires. Il y a suffisamment peu de menus pour pouvoir les regarder tous.
Il est nécessaire de demander l'affichage des numéros de ligne dans les préférences. La complétion de code existe avec CTRL-SPACE, mais n'est pas forcément utile aux étudiants à ce stade. On peut arrêter une boucle infinie en cliquant-droit en bas à droite de la fenêtre.
Si un étudiant a choisi le français dans BlueJ, lui conseiller de repasser en anglais (nécessite le redémarrage de BlueJ, mais on ne perd rien), car c'est un bon moyen d'apprendre du vocabulaire.

Pour le bon fonctionnement de l'unité, il est nécessaire de lire vos mails tous les jours, et de rediriger votre mail esiee sur la boîte que vous lisez le plus souvent.
Si vous désirez malgré tout ne pas utiliser l'adresse @esiee.fr, merci de me le dire.

IX. Le langage Java

Il est bien évident qu'on ne peut tout enseigner et que des choix ont dû être faits. Plusieurs techniques ou concepts ne sont vus que dans le projet, et pour certains, pas du tout (exemple dans l'ex-A3P en E1).
D'autre part, certains partis-pris sont inévitables dans le vocabulaire employé (3 sortes de méthodes par exemple) et dans ce qui est considéré comme de la "bonne programmation".
La lisibilité est toujours favorisée par rapport à la concision. Le seul ennemi absolu est la duplication de code.
Enfin, des "obligations pédagogiques" s'ajoutent aux contraintes du compilateur et au Guide de style classique, notamment le nommage des variables (a,p,v), this., final, @Override, etc.
Ces obligations leur permettent d'éviter certaines erreurs qu'ils ont du mal à trouver : this. systématique évite de redéclarer un attribut dans un constructeur, final systématique évite d'inverser l'ordre d'une affectation, @Override systématique évite les erreurs de paramètre, voire de nom de méthode, etc... et (a,p,v) systématique en début de variable leur permet de mieux comprendre ce qu'ils manipulent.
Si vous voulez voir à quoi resssemble le code avec toutes ces conventions, cliquez sur "Tout Déployer" ici.

Je suis bien entendu à votre disposition pour toute question sur cette unité ou sur Java.

Denis BUREAU (5356)