ENIB S3-PRG-RUST - Programmation en Langage Rust

{} Activité

Cet enseignement vise à faire découvrir les principes de programmation que promeut le langage Rust, mais n'a pas vocation à passer en revue tous les détails de ce langage.
Il faudra exploiter autant que possible ces ressources et il est important de commencer par consulter :

les raisons du choix de ce langage,
et les objectifs de son étude.

La démarche d'étude consiste à découvrir quelques notions à travers ces réalisations pratiques :

01_Expe — Expérimentation préliminaire
02_Auto — Système automatisé ⟵ premier mini-projet
03_Game — Jeu en réseau ⟵ second mini-projet

Au fil de vos expérimentations et de vos réalisations, le compilateur signalera nécessairement de nombreuses erreurs.
Il faut lire attentivement ces messages car ils sont généralement très explicites, très instructifs (pour comprendre les règles du langage), et suggèrent souvent des corrections pertinentes.
C'est effectivement en étudiant scrupuleusement les recommendations du compilateur et du linter qu'on apprend le plus facilement les principes de ce langage.

Le travail aura lieu par groupes trois ou quatre élèves constitués selon l'organisation imposée dans la matière “Automatismes”.
Il n'est absolument pas interdit de réfléchir à plusieurs, de s'entraider✍ ou de s'aider d'un LLM pour comprendre.
L'important est que chacun sache utiliser les outils et réaliser toutes les formulations usuelles.

Si besoin, pour récupérer ou déposer des fichiers, vous avez accès à votre compte de Labo des salles sous Linux depuis l'extérieur selon cette procédure indiquée par le SNUM de l'ENIB.

{} Validation des acquis

L'évaluation a lieu par groupes trois ou quatre élèves constitués selon l'organisation imposée dans la matière “Automatismes”.
Elle repose sur la livraison, pour chaque mini-projet, du code source réalisé et d'un court compte-rendu.
Un tel compte-rendu devra indiquer la démarche suivie pour tester le bon fonctionnement à chaque étape de la réalisation, commenter les résultats obtenus.

Consignes générales pour chaque rendu

Chaque rendu, un par mini-projet, revient à livrer une archive selon la modalité précisée par la personne qui encadre la séance.
- À la fin de la sixième semaine du semestre pour le premier mini-projet.
- À la fin de la quatorzième semaine du semestre pour le second mini-projet.
L'archive doit être “légère”.
- Elle doit contenir le code source de votre réalisation✍
  Le répertoire de votre projet, dans lequel se trouve le fichier Cargo.toml.
- Elle ne doit pas contenir les très volumineux fichiers produits par la compilation ; exécutez cargo clean avant de produire l'archive.
- Elle doit également contenir votre compte-rendu✍
  Éventuellement avec des images lorsque c'est pertinent.
  .
Le compte-rendu doit être “léger”.
- De simples “copier/coller” des quelques lignes de texte du terminal suffisent parfaitement pour les illustrations.
- Il est disproportionné et inutile de générer de volumineuses images qui ne représentent rien de plus que du texte !
- Les seuls cas où une image est un illustration pertinente concernent quelques étapes du second mini-projet dans lesquelles l'effet observable est bien une image.
- La mise en forme n'est pas du tout le propos ici✍
  Un simple fichier textuel fait bien l'affaire, pas besoin de vous embarrasser d'un traitement de texte.
  Si des images sont parfois nécessaires, il suffit d'y faire référence dans le texte et de les inclure dans l'archive rendue.
  ; le seul élément structurant est le découpage clair des différentes étapes testées.
Le compte-rendu doit montrer comment a été testée chaque étape qui le demande explicitement✍
La fin de l'énoncé d'une telle étape vous le rappelle à chaque fois.
.
- Il est disproportionné et inutile de mobiliser un modèle génératif de langage pour paraphraser l'énoncé ; ce dernier est déjà lisible et connu des personnes devant corriger.
- Les cas testés doivent être contradictoires : la détection des variétés de cas problématiques ou normaux attendus.
- Il faut montrer et commenter dans les traces d'exécution relevées ce qui vous fait penser qu'un cas problématique est bien détecté ou, au contraire, que le fonctionnement paraît normal.

“Acquis d'Apprentissage Visé” n°1
À l'issue de cet enseignement, une personne ayant étudié est capable d'écrire✍ un programme simple qui respecte les exigences du langage Rust, en utilisant des fonctionnalités de bibliothèques, à partir d'éléments de documentation et d'exemples préalablement fournis.

Critère 1 : Compilation du code
Le code source se compile correctement et le linter ne signale aucune maladresse.
Critère 2 : Compréhension et respect d'un énoncé
Le code source tend à réaliser ce que le sujet du mini-projet décrit.

“Acquis d'Apprentissage Visé” n°2
À l'issue de cet enseignement, une personne ayant étudié est capable de décrire✍ dans un compte-rendu une démarche informelle de test de chaque étape de sa réalisation.

Critère 3 : Respect des modalités de rendu
Le compte-rendu, accompagné du code source, est livré dans le délai et la forme fixés par la personne en charge de cet enseignement.
Critère 4 : Cohérence entre code et compte-rendu
Le compte-rendu décrit des situations qui coïncident avec ce qu'il est possible d'observer en utilisant le code source livré.
Critère 5 : Description des tests
Pour chaque étape de la réalisation, le compte-rendu décrit précisément la démarche suivie pour tester, et donne une interprétation des résultats observés.

Pour chaque mini-projet, la note attribuée à un “Aquis d'Apprentissage Visé” prend en considération l'avancée dans le travail et les critères indiqués (lorsque le sujet s'y prête).
Au niveau de la matière, la note d'un “Aquis d'Apprentissage Visé” est la moyenne arithmétique des notes obtenues pour cet “Aquis d'Apprentissage Visé” sur tous les mini-projets.
La note globale de la matière est la moyenne arithmétique des “Aquis d'Apprentissage Visés” de la matière.