Installations et configurations logicielles pour le module CSC4102
Durée estimée ≈ 2h (à partir d'une installation déjà
proche de ce qui est nécessaire).
Quand : à faire AVANT LA SÉANCE 1.
- en vérifiant l'installation et la configuration de son compte Télécom SudParis / DISI, et
- en vérifiant l'installation et la configuration de sa machine personnelle.
Vérification de l'accès à GitLabEns
Durant tout le module, et dès le début du TP de la séance 1, nous utilisons Git avec la forge logicielle GitLabEns. Vérifiez que vous avez accès à l'interface Web. Pour ce faire, vous vous connectez à la plateforme GitLabEns de TSP (https://gitlabens.imtbs-tsp.eu) en utilisant l'authentification Shibboleth repérée par le bouton suivant :
Si vous n'arrivez pas à vous connecter à la plateforme, voici
le message de la DISI pour l'accès extérieur à la forge
logicielle :
« Nous avons ouvert la plateforme GitLabEns
depuis l’extérieur du campus a un nombre limité de
Fournisseurs d'Accès Internet (FAI), principalement Orange,
SFR, Bouygues, Free, mais il est possible que nous n'ayons pas
énuméré toutes les adresses sources dont ils disposent. Si
vous avez un refus d'accès, merci de retourner à la DISI via
le helpdesk l’adresse Internet (adresse IP) de votre point
d’accès (box, mobile, lieu d’hébergement...), adresse
disponible depuis votre terminal en allant sur le site
https://monip.org/,
afin que la DISI adapte les filtres IP d’accès à
GitLabEns. Retournez l'information (adresse IPv4)
obtenue sur cette page en envoyant un courriel :
"Subject: contrôle d'acces IP à gitlabens CSC4102, To:
helpdesk@imtbs-tsp.eu, Body: contenu de
https://ip.lafibre.info/" »
Configuration du compte Télécom SudParis / DISI
Toutes les manipulations de cette section sont à effectuer une fois connecté ou connectée sur une machine DISI, (1) en étant présent en salle TP ou (2) en utilisant une connexion SSH (p.ex. ssh -Y LOGINDISI@ssh.imtbs-tsp.eu).
Ménage du compte Télécom SudParis
Faites du ménage sur votre compte Unix TSP fourni par la DISI, et créez un répertoire ~/CSC4102 pour l'ensemble du module.
Pour faire du ménage après le module CSC4101, les coordinateurs de ce module proposent ceci : dans chaque projet Symfony (répertoire dans lequel se trouvent bin/console, composer.json, etc.)
Puis, globalement, dans le compte,
Création d'un couple de clefs (privée, publique) SSH pour les connexions avec la plateforme GitLabEns de TSP
Vous utiliserez le protocole SSH pour pouvoir réaliser les soumissions de vos travaux sur le dépôt Git de votre projet. Afin de permettre une manipulation fluide et sécurisée, vous utilisez un couple de clés SSH permettant de réaliser les authentifications SSH de façon « transparente ».
Il convient d'avoir un couple de clefs SSH spécifique pour chaque machine que l'on souhaite utiliser comme client SSH.
Pour information, les concepts du protocole réseau SSH sont présentés d'un point de vue « pratique informatique » dans la page suivant suivante.
Peut-être avez-vous déjà un couple de clefs SSH. Pour le savoir, étudiez le contenu de votre répertoire ~/.ssh.
Si vous avez un répertoire ~/.ssh avec des fichiers id_rsa*.pub et id_rsa*, c'est que vous avez déjà un couple de clefs SSH : un fichier id_rsa*.pub contient la clef publique et le fichier id_rsa* correspondant contient la clef privée permettant d'utiliser la clef publique (ce fichier est très sensible et son contenu doit toujours rester secret).
Si vous n'avez pas de couples de clefs SSH ou lorsque vous souhaitez générer un nouveau couple, utilisez la commande ssh-keygen comme suit :
- l'identifiant demandé dans l'option « -C » de la commande ssh-keygen est un commentaire du couple de clefs qui doit permettre à celui qui l'a générée de savoir de quel couple de clefs il s'agit. Pour ce faire, nous proposons que vous utilisiez un identifiant de la forme « nom_utilisateur@nom_hôte » pour que vous sachiez où le couple de clefs a été généré. C'est la manière la plus habituelle de procéder. Si vous ne mettez pas l'option « -C » alors, sur une machine de salle de TP, l'identifiant est de la forme « login@b0X-YY » ;
Vérification de l'installation du gestionnaire de versions Git
Vérifiez l'installation et la configuration avec les commandes suivantes :
Pour faciliter l'utilisation de Git en mode commande, les utilisateurs GNU/Linux ont préparés des « complétions de commandes ». Nous vous proposons de télécharger les shell script bash et de l'utiliser avec la configuration de votre compte.
Programmation JAVA
Nous avons besoin d'une machine virtuelle JAVA ayant une version ≥ 17, avant dernière version « Long-Term Support » qui est installée sur les machines des salles de TP. Nous recommandons le Java Development Kit de OpenJDK avec la version 17.
Spécification et modélisation avec les langages Markdown et PlantUML
Pour écrire la spécification et la modélisation, nous utilisons le langage Markdown pour GitLab (GLFM). Pour ce faire, nous vous proposons un outil pour écrire et un autre pour lire un fichier Markdown :
- sur GNU/Linux, écrivez avec l'éditeur emacs complété du paquet Debian elpa-markdown-mode, et lisez/visualisez avec l'outil ghostwriter installé avec le paquet Debian ghostwriter. Dans emacs, utilisez le menu Markdown pour l'édition des tableaux ;
- sur Windows, écrivez avec un éditeur de texte, par exemple NotePad++, et lisez/visualisez avec Ghostwriter ou VisualStudioCode (cf. dans la page d'aide, dans la section Markdown, la question Je souhaite utiliser VisualStudioCode sur Windows... )
- sur MacOSX, écrivez et visualisez avec l'outil MarkText (aide à l'installation).
Pour construire les diagrammes UML, nous utilisons le langage textuel PlantUML. Nous l'introduirons à la séance 2 avec le premier diagramme UML, le diagramme de cas d'utilisation.
Mais, dès maintenant, vérifiez l'utilisation de l'outil PlantUML avec le scénario qui suit. Il existe de multiples outils pour utiliser PlantUML. Nous proposons la manière la plus directe, c'est-à-dire l'édition de texte (p.ex. emacs sur GNU/Linux, NotePad++ sur Windows, etc.) et l'utilisation de l'archive JAVA.
Programmation avec l'environnement de développement Eclipse
Pour l'écriture du code, nous utilisons de manière standard Eclipse, version récente ≥ 2022-12 (cf. les instructions d'installation). Vous pouvez choisir un autre environnement de travail, à condition de vous engager à être complètement autonome.
Sur les machines des salles de TP, la DISI a installé la version 2022-12, qui est accessible par la commande en ligne de commande eclipse-java.
S'ils ne le sont pas déjà, installez aussi par l'intermédiaire du Eclipse Marketplace les greffons suivants (si vous avez choisi un autre environnement de développement que Eclipse, installez les greffons correspondants) :
- Greffon SpotBugs pour Eclipse : dans le menu Aide, entrez dans Eclipse Marketplace, cherchez le greffon SpotBugs en version ≥ 3.1.5 et installez-le ;
- Greffon Checkstyle pour Eclipse : dans le menu Aide, entrez dans Eclipse Marketplace, cherchez le greffon Checkstyle Plug-in en version ≥ 10.4.0 et installez-le.
Si vous avez une installation de Eclipse avec JAVA version 11, nous vous conseillons de passer à JAVA version 17 et de ré-installer Eclipse avec cette nouvelle version.
(Les utilisateurs de VSCode peuvent regarder la page des aides JAVA et IDE à la question « Configuration de Checkstyle pour VSCode » pour des indications fournies par un étudiant des années précédentes.)
Construction de logiciel avec Maven
Pour la construction du logiciel de l'application que vous réalisez, nous utilisons Apache Maven (cf. les instructions d'installation) dans une version ≥ 3.8.7. Au passage, vérifiez que vous utilisez bien l'installation JAVA que vous avez testée juste avant.
La première compilation et installation de logiciel avec Maven prend beaucoup de temps car le dépôt local (dans le répertoire ~/.m2/repository) est mis en place lors de cette première exécution avec le téléchargement de beaucoup d'archives *.jar. Veuillez exécuter le scénario qui suit :
Installations et configurations de votre machine personnelle
Dans le cadre du module CSC4102, la configuration nominale pour le travail en séances de TP est d'utiliser les comptes Unix depuis les postes de travail des salles de TP en environnement GNU/Linux (Ubuntu). Lors de vos travaux en hors présentiel, vous utilisez votre machine personnelle avec les installations et configurations logicielles qui suivent.
Machine personnelle avec un système d'exploitation GNU/Linux à jour
Nous considérons que vous avez accès à un système d'exploitation GNU/Linux sur votre machine personnelle : « nativement » (peut-être en dual boot) ou via une machine virtuelle. Pour ce faire, reportez-vous à la page « Trucs et astuces » du premier module (CSC3102) de première année.
Mettez à jour votre système : par exemple, allez vers la dernière version Ubuntu.
Installation et configuration logicielle
En ce qui concerne Git, l'installation recommandée comprend les « packages » du système Git, version ≥ 2.43 (cf. les instructions d'installation). Si nécessaire, c'est-à-dire s'il ne trouve pas l'un des outils qui suit, complétez l'installation de Git avec les outils suivants :
- outil gitk (paquet gitk sur Debian),
- (optionnel) outil tig (paquet tig sur Debian),
- outil git gui (paquet git-gui sur Debian), et
- outil meld (paquet meld sur Debian).
En ce qui concerne l'édition de fichier Markdown « gitlab/github » avec emacs sur système d'exploitation GNU/Linux, installez aussi le paquet elpa-markdown-mode.
En ce qui concerne PlantUML sur système d'exploitation GNU/Linux, installez aussi le paquet graphviz pour avoir le programme dot.
Vous êtes maintenant prêt ou prête à compléter votre installation en suivant similairement les consignes pour les machines des salles de TP. Donc, re-parcourez l'étape 2, mais cette fois-ci avec votre compte personnel sur votre machine personnelle.
