5ème séquence - Chabot, robot de conversation

Construire un bot de conversation : conversation bot.

Apprentissage clef : réseau, protocole, comprendre l’utilisation des API, échange machine à machine (faire parler avec un autre serveur). Comprendre une documentation.

équipes

le pad pour l’organisation de la journée en remote

3 J'aimes

Journal
lundi 9 déc

  • Framapad.org
  • PID : process identifier (système UNIX ou windows)
  • vim --version
  • instalation de gvim pour pouvoir accéder à +servername
  • scp : secure copie (pour le partage doc vim)

Vim

mardi 10 déc

  • framapad plénière
  • API
  • backtick = ` (AltGr+7)
  • pip pour python (gem pour ruby) gestionnaire de bibliothèque(cf post de Yannick plus bas)
    sudo apt install python-pip
  • pour html, en md # = h1 ## = h2 etc…
  • les bibliothèques complexe utilise généralement d’autres bibliothèques
  • les bibliothèques peuvent-être installer localement juste pour le projet ou sur tout le système

[Penser à faire un require.txt pour informer ceux qui reprenne le code des bibliothèques utiliser]

Vim

  • diff entre O et o (saute une ligne et se met en mode insertion O => au dessus; o => en dessous)

python

mercredi 11 déc
plénière :

quelque chose :

  • port
  • 127.0.0.1 = Localhost adresse qui représente l’interface de la machine locale (celle sur laquelle elle est appelée). Cela permet de faire référence à votre machine, sans avoir à connaître son (ou ses) adresse(s) IP réelle(s). Ainsi, n’importe quelle machine supportant le protocole IP peut s’adresser à localhost, même sans être connectée à un réseau physique.

commandes bash

  • sudo useradd exemple -e AAAA-MM-JJ créé un nouveau utilisateur [avec date d’expiration (-e …)]
  • cat /etc/password exemple voir tout les user de la machine (entre autre chose)
  • sudo passwd exemple changer le password d’exemple
  • whoami voir sur quelle session tu es
  • su = switch user

Vimscripte

  • :source bot.vim exécute dans vimscripte le programme bot.vim

jeudi 12 déc

vim

  • rappel :%s pour remplacer le même mot par un autre dans tout le fichier.

vendredi 13 déc

  • a voir dans python {}.format()
    vim
  • '<,'>(dernière sélection faites en visual mode) normal I#(pour mettre des # en début de ligne

Journal du Lundi 09 décembre de l’an 2019

J’ai effectué quelques recherches concernant le projet et surtout la notion de serveur.
Cet après midi j’ai commencé à écrire un petit bout de code. Avant de GALERER a installer une simple bibliothèque en Python.
En gros d’un seul coup je pouvais plus utiliser python, ni pip d’ailleurs. Mais après un loooong moment à galérer, j’ai appelé Nico (meme si il est plus dans mon groupe).
Et ensuite Agathe est arrivée ! Et elle a trouvé ! Merci beauuucoup Agathe !!
Du coup maintenant j’ai une nouvelle erreur à l’installation de ma librairie. Et presque toute la doc est en Russe ou en Chinois (je crois), un vrai plaisir. Mais c’est pas grave, disons qu’aujourd’hui c’est la journée installation.
En espérant que demain soit plus productif comme dit Nico.

Journal du Mardi 10 décembre de l’an 2019.

Excellente journée !!
Hier j’ai juste fais des recherches sur le projet et j’ai fais plein d’installation.
Aujourd’hui grâce à la plénière avec Yannick je vois mieux où allez, et c’est vraiment top ! (Merci beaucoup) . On a reçu plein de documentation et du coup je vais pouvoir regarder tout ça ce soir (ou plus tard) à tête reposée.
L’après midi avec Marine était très chouette. J’appréhendais un peu parce que je ne pense pas être très pédagogue, ou du moins, j’ai l’impression que mes explications sont souvent flous. Je fais souvent des liens dans ma tête entre plusieurs choses pour en comprendre une seule, et tout le monde ne fait pas les mêmes liens. Pareil, j’aime bien me faire de petits exemples concret (en tout cas pour moi) pour mieux comprendre une notion, mais c’est pas forcément les meilleurs exemples pour tout le monde. Faut que je bosse la dessus.
Sinon en ce moment le midi j’essaie de faire un CV un peu graphique pour me démarquer, pour l’alternance. C’est pas facile de savoir ses points forts et ses points faibles … :thinking:

Liens concernant le projet


Lundi

  • Ada > à la maison
  • notion de server - client est trés intéressent
  • bien de retrouver les autres
1 J'aime

Journal du soir (9 décembre)

  • Ce matin, il pleuvait. J’ai décidé de ne pas aller à Ada et travailler en
    remote. J’ai appris qu’il était possible que des gens dans des contextes très
    différents en des lieux très différents peuvent tout de même se rendre dispos
    pour travailler autour d’un projet commun. C’est bizarre…

  • J’ai appris qu’on allait faire du client serveur. J’avais très envie de le
    faire en vimscript, même si c’est probablement une mauvaise idée.

  • Pour l’après-midi, je suis allé à ada.

  • J’ai appris l’existence de l’option de compilation +clientserver dans vim,
    et j’ai appris qu’il était présent par défaut pour les vim graphiques.

  • J’ai appris à lancer une instance de vim en mode serveur avec vim --servername NOMDUSERVEUR, ainsi qu’à envoyer des commandes vim en client
    avec vim --servername NOMDUSERVEUR --remote-send "icoucou<Esc>".

  • Je réalise que j’ai appris, à force, à lire la documentation intégrée de
    vim.

  • J’ai appris plus précisément ce qu’était un modèle « client - serveur ». J’ai
    encore besoin d’apprendre plus précisément ce qui fait partie de ce modèle de
    ce qui ne le fais pas. Les protocoles, les méthodes employées, le vocabulaire,
    tout ça. J’espère avoir des pleinières théoriques à ce propos.

Journal du midi (10 décembre)

  • Ce matin, j’ai appris ce qu’était un virtual environment, dans le contexte
    de python ou autre. J’ai appris l’option -r à pip qui signifie relative.

  • J’ai appris l’existence des fichiers requirements, et la possibilité de
    scripter un pip install -r dans ces fichiers. J’ai appris qu’il existait
    différentes philosophie dans la manière de les faire… Mais ça, comme toujours.

  • J’ai appris que les Bundlers de ruby en était l’équivalent. Je pense avoir
    bien compris ce concept et la problématique à laquelle il (en théorie) répond.

  • J’ai appris comment on pouvait travailler son projet en définissant à qui il
    s’adresse, à quel besoin il répond, etc pour éviter de faire de la technique
    pour de la technique. J’ai pu appliquer cet apprentissage sur le cas de notre
    projet en vimscript. J’ai conclu qu’il était destiné aux vimistes. Je reste
    assez terre à terre, en général… Et peut-être aux vimistes qui ont envie de
    faire du framapad sans trop se faire chier, et sous vim ? Le problème c’est
    qu’on s’éloigne un peu du chatbot… Du coup interagir avec Wikipédia ?

  • J’ai appris à créer un « bridge » entre riot et slack, en le faisant. J’ai
    appris que Hana a déjà utiliser un IRC. J’aimerais bien m’y mettre et elle m’a
    proposé son aide !

  • J’ai appris qu’un bridge entre riot et slack créé en fait un bot pour
    chaque utilisatrice dans les channels (rooms du point de vue de riot) qui
    lit ce qu’écrit l’utilisatrice, et le reproduit côté bot. J’ai appris qu’il ne
    m’était pas possible de lire tout ce qu’il se passait, parce que c’est aux
    utilisatrices (enfin je crois) de valider le fait qu’il existe un bot du côté
    riot. Ça m’embête car je ne veux pas demander cette charge mentale en plus
    (trois réseaux, je trouve que c’est beaucoup trop! (et encore, des fois c’est
    plus…)) aux membres de ada, d’autant plus que je suis tout seul sur riot

Journal du soir

  • Je fais un tout piti journal du soir parce que j’étais avec les enfants, et
    que je fais le journal scratch ailleurs…

  • J’ai appris à utiliser la commande vim scp://user@machine/relative/path pour
    copier le contenu d’un fichier à distance en local, en utilisant le protocole
    scp. J’ai appris que vim supportait aussi le http, le ftp, rsync, et
    puis un peu tout ce que tu veux en fait… Le défaut de scp, c’est que c’est
    un service ssh qui demande donc des « credentials » à chaque requête. Soit
    on donne sa confiance dans un fichier de config ssh, soit on utilise un
    protocole plus approprié. Je ne sais pas. Le http me tenterait bien…

  • J’ai appris le mot-clé del en python avec Wara. Il peut supprimer des
    variables de la mémoire (me semble un peu inutile…), mais aussi (et surtout!),
    il permet de supprimer l’élément d’index d’une liste.

  • Je suis désolé pour celles qui ont publiés leurs journaux avant moi et qui vont devoir scroller des heures… D:

Journal du midi (11 décembre)

  • J’ai appris ce qu’était une API en lisant l’article
    wikipedia
    .

  • J’ai appris que, dans le cas « client - serveur », l’API est l’ensemble des
    méthodes, classes et variables définies dans un processus exécuté sur une
    machine (locale ou distante).

  • J’ai appris que l’on pouvait considérer une bibliothèque (e.g la bibliothèque
    standard C
    ) comme une API. En fait, on peut aussi considérer que le langage
    de programmation en tant que tel est API vers le binaire ou un autre langage.
    La différence entre ce cas et le cas « client - serveur », c’est que L’API est
    définies dans un fichier de code source, plutôt que par un processus.

  • J’ai appris que le protocole de communication utilisée ne définissait pas
    l’API. Je pense avoir compris ce que Yannick (ou bien c’était Agathe?) a voulu
    dire quand il disait qu’il y a plusieurs définitions à l’API. Je pense en fait
    qu’il y en a qu’une seule, mais qu’elle s’applique à plusieurs domaines. J’ai
    appris qu’il est important de faire la distinction entre l’API, le serveur, le
    client, et le protocole de communication.

  • J’ai fait le journal du midi vraiment le midi ! :smiley:

Journal du soir

  • J’ai appris à lire le contenu du fichier /etc/passwd. Notamment, le x à la
    deuxième colonne, et la 6ème colonne systématiquement vide.

  • J’ai appris à utiliser la commande scp, et que le réseau c’est autant de
    couches de trucs qui s’empilent et qu’il faut configurer pour espérer que ça
    marche et pour que toutes les briques rentrent les unes dans les autres que
    c’est très relou si on n’a pas une connaissance solide des principes de base.

  • J’ai compris ce qu’était réellement un port grâce à l’article wikipedia. Ils
    ont dit qu’il ne faut pas faire la confusion avec un socket. J’ai arrêté de
    comprendre les ports, et les sockets (c’est pas si vrai ^^).

  • J’ai appris que le système de socket nous venait de Berkeley.

  • Avec Wara, on a appris et réussi à ping nos routeurs mutuels, mais on n’a
    pas réussi à communiquer ni avec scp ni avec ssh. Ça m’a un peu sapé le
    moral… Je ne sais pas vraiment comment il faut s’y prendre pour y ariver.

  • J’ai appris à sourcer des commandes ex dans vim avec la commande
    :source.

  • J’ai appris que runtime et source ne sont pas équivalents pour vim. J’ai
    besoin d’apprendre et de comprendre correctement la différence entre les deux.

Journal du soir (12 décembre)

  • J’ai appris les couches réseau plus en détail avec Élodie et Wara. « bits »,
    « paquets », « segments », « données ». J’ai un peu mieux compris ce qu’il
    était nécessaire de faire pour créer un tunnel ssh.

  • J’ai appris un peu plus de la syntaxe de vimscript, avec les g:, s:,
    a:, etc pour identifier une variable par sa portée. C’est à priori un
    langage que j’apprécie.

  • Je n’ai toujours pas appris à utiliser runtime, ni essayer de créer une
    fonction qui manipule directement le buffer courant.

  • J’ai appris l’existence de tests unitaires en
    vimscript
    . Ç’a l’air assez vieux,
    j’essaierai de l’utiliser à l’occasion pour identifier s’il y a un besoin de
    mise à jour ou de création d’un nouvel outil. Pour un éventuel projet très
    lointain. Ceci dit, 4 ans, pour du vimscript, il y a de grandes chances pour
    que ça marche encore… Je ferai l’expérience.

Journal du midi (13 décembre)

  • J’ai appris à ne pas kill un umount.

  • J’ai appris l’existence de udisksctl, un wrapper pour éviter de passer en
    sudo.

  • J’ai appris qu’il ne fallait pas oublier le faire un mkfs sur une partition
    après l’avoir créé (sinon ça va pas du tout!)

  • J’ai une meilleure compréhension globale de la gestion de disque sous UNIX !

  • J’ai appris à utiliser la commande strace avec l’option -p. Je suis très
    content ! Je ne suis pas encore très à l’aise avec cet outil, mais j’apprend
    progressivement à le lire…

  • J’ai appris qu’il est possible d’installer un système sur une carte SD. Ce
    n’est pas très surprenant mais c’est chouette de savoir que ça marche.

  • J’ai appris que tails peut être installé sur une clé <8GB mais qu’il refuse
    de se lancer s’il n’a pas les 8 gigas requis. Pour l’instant, je n’en comprend
    pas les raisons. Grrrrr…

Journal du soir

  • Aujourd’hui, on a construit nos roues de l’influence accompagnées par Élodie.
    J’l’ai pas fait du coup, et j’ai fini par être spectateur de l’atelier.
    C’était super intéressant, j’ai appris beaucoup de choses sur des personnes à
    ada.

  • En clôture, j’ai failli parler de moi, autrement que ce qui concerne du code
    ou des choses « faciles » à exprimer.

  • J’ai appris que ma mère a déjà expérimenté la roue de l’influence avec moi. Je
    lui en reparlerai. J’ai appris les règles de l’exercice, et j’aimerais bien le
    refaire avec d’autres personnes sans être certain de pouvoir l’encadrer
    correctement.

  • J’ai appris l’existence de vader.vim pour faire du TDD en vimscript (ou
    Vim script) (ou vimL) (ça dépend des écoles). J’ai appris qu’il existait
    des exercices sur exercism en vimscript. Curieusement, il n’y a pas assez
    d’élèves ni de mentor sur cette série d’exercices, et je ne peux que suivre le
    « practice mode ».

  • J’ai appris que le vimscript est un langage « Turing complet ». Ç’avait
    l’air de paraître évident pour Florian, mais pas pour moi et j’en ai un peu
    rien à foutre ^^

  • J’ai ré-appris la manière dont est implémenté la rotation des blocs dans les
    différentes versions de tetris… C’est relou… Il y a au moins six systèmes
    différents de rotations dans l’histoire du jeu. Donc avant de l’implémenter,
    j’ai bien envie de tenter la bonne compréhension des différentes
    implémentations. Et celle standard à l’heure actuelle.

Journal de Lydia

Lun 9.12.19 - LyMoNi avec @Mohamed et @Nydragon

  • Appris :
    - utilisation de la biblio socket et son articulation entre serveur et client

  • Vu :
    - API
    - serveur

Mar 10.12.19 - LyMoni avec @Mohamed et @Nydragon
Je suis à la ramasse aujourd’hui, j’ai une lenteur cérébrale incroyable (et j’ai dû m’absenter toute la matinée… super !)

Durant la plénière de ce matin, nous avons fait une séance en MobProgramming.

Nous avons toutes travaillées avec @B3RRY et @laurine sur leur projet de chatbot.

Nous avons parlé de chatbot, pour préciser ce que c’est. Nous en avons profité pour pointer sur des projets qui avaient été réalisé durant la formation « À mon tour de programmer » :

Nous avons également exploré Pip, l’outil de gestion de paquet, de bibliothèque externe majoritairement utilisé en python. Et nous avons évoqué le fait que chaque outil de gestion de bibliothèque propose un site pour rechercher dans la base de code existante

Nous avons rapidement évoqué le fait d’utiliser des personas pour envisager des usages pour le logiciel qu’on envisage d’écrire.

Nous avons parlé de drift comme d’un outil de chat (sur lequel parfois un bot est branché, mais c’est aussi souvent des humains). C’était un exemple vis à vis d’un chatbot de support pour aider à se servir d’un service ou d’un jeu.

Nous avons ensuite rapidement évoqué la documentation de l’API twitter

Nous avons également envisagé un bot slack (et listé deux urls de documentation sur le sujet)

Pour qu’un bot puisse fonctionner même quand son ordinateur est éteins, il faut le déployer en production, sur un serveur tier. Heroku est un des services en ligne qui propose un hébergement gratuit (à condition d’un usage assez limité).

Nous avons évoqué la différence entre les dépendances de développement et les dépendance de production.

pip install -r /path/to/requirements.txt
pip freeze

Et dans les pistes d’exploration, nous avons parlé des environnements virtuel en python (virtualenv) http://sametmax.com/les-environnement-virtuels-python-virtualenv-et-virtualenvwrapper/

Plus tard, dans l’après midi, j’ai partagé la référence Git https://try.github.io/ avec @Zakia. Elle pourra sans doute servir à d’autres personnes.

Plénière du Jeudi 12 décembre 2019.

Sujet : Savoir résoudre les conflits sur GIT .

Encadrant : KheOps

On bosse dans la sandbox, dans le dossier conflit_git.
On commence par créé 2 fichiers qui ont le même nom dans la sandbox. Nico en crée un, et KheOps également.
Nico a git push. KheOps a ensuite git push. Et la erreur ! Il faut git pull avant pour récupérer les modifications de Nicolas. Il s’execute, et là il y a conflit.
Concrètement, si on ouvre le fichier à ce moment la, on voit 2 contributions. Le code de Nicolas, et celui de KheOps, qui est entre <<<<<<<< HEAD et ====== et >>>>>>> numéro_de_commit.
Il faut donc éditer les 2 bouts de code qui ne vont pas ensemble. Ainsi que les HEAD, ==== et le numéro du commit.
Ensuite on git add le fichier modifié, on git commit, et on voit dans tig (qui sert à parcourir l’arbre git).
Une fois qu’on a git push avec le fichier édité, le conflit est résolu !

Rappel : git log sert à voir tout les commits effectués.

git rebase : il y a énormément d’utilisation à cette commande, mais nous allons voir l’utilisation que KheOps en fait.
On peut utiliser git rebase pour nettoyer les commits déjà effectués.
Si un commit suit un autre commit et qu’il n’y a pas trop de différence entre les 2, on peut les fusionner.
Par exemple, si on a 2 commits : un commit avec un ajout de code contenant uniquement un bug, et un commit contenant la résolution de ce bug, on peut les mettre ensemble.
La commande permet aussi de réordonner les commits. On peut rapprocher dans les commits, ceux qu’on veut fusionner ensemble.
On prend le numéro de commit de celui qui précède celui sur lequel on veut travailler.
git rebase -i + nom du commit qui précède.
On peut reword un commit = le renommer, c’est utile par exemple, si plusieurs commit ont le même nom.
Sur le tig, les petits traits jaune avant les noms de commits représentent les branches.
On peut aussi applatir un arbre et enlever les branches, si on a des conflits de branches.
A chaque commit où on reword, on peut modifier le nom du commit.
squash = utiliser le commit mais en le fusionnant avec le prédécent.
fixup = comme squash, mais en éliminant son message.

Comment supprimer un commit :
On se situe avant, on refait git rebase -i + numéro commit précédent.
On arrive dans l’éditeur de texte, et il y a un petit mode d’emploi sous le texte.
Il indique qu’en mettant un d devant le nom du commit qu’on veut effacer, il s’effacera.

git push --force, A UTILISER AVEC PRECAUTION : Quand on a réécrit l’histoire de git, et qu’il y a une erreur au moment de push.
Il faut surement les droits administrateurs pour le faire. Ne pas le faire pour rien. C’est une commande sensible !

Les branches git :
Concrètement une branche c’est quoi ? : Git est un arbre au sens mathématique du terme. Une de ses utilités est de modifier du code et de faire des tests, en gardant un historique principal.
La branche est un historique parrallèle dans lequel on modifie, sans toucher a la branche principale. En général on ramène les modifications dans la branche principale.
Parfois dans certains projets on a plusieurs branches, par exemple, une branche développement qui est en avance sur les autres branches.
On peut parfois faire une branche par fonctionnalité, et ensuite on met tout ensemble dans la branche principale quand ça marche.
Les modifications effectuées sur une branche n’impactent pas les autres branches, sauf si on regroupe les branches ensemble.

[ Les encadrants, votre « définition » est la bienvenue pour compléter ^^ ]

git checkout -b la-super-contrib-de-kheops : crée une nouvelle branche qui s’appelle la-super-contrib-de-kheops.
git checkout master pour revenir dans la branche principale (qui s’appelle toujours master).
git branch permet de lister toutes les branches.
git log montre également lorsque l’on change de branche.
git rebase -i dans notre propre branche avant de la fusionner à la branche principale.
On retourne dans la branche principale, on fait git merge la-super-contrib-de-kheops, pour ajouter la nouvelle branche, à la branche principale.
git push ensuite pour tout envoyer.

Forker un projet c’est quoi ? (= Fourcher un projet si on françise l’expression).
Si on a pas les droits dans un dépot, et qu’on veut participer, on peut allez sur github, sur le dépot, et cliquer sur Fork pour copier tout le projet sur notre ordi (bouton en haut à droite qui ressemble à une fourche).
On peut le modifier comme on veut, sans impacter le vrai projet, et ensuite proposer nos modifications aux auteurs du projet.
On peut push, ça modifiera que notre copie du projet sur notre ordinateur.
Pour envoyer sur le dépot principal, on peut faire une pull request . Qui va proposer notre modification à l’auteur principal. Il peut l’accepter ou la refuser.

Hésitez pas à modifier si tout n’est pas clair ou si les explications sont pas très justes !

Attention, tig n’est pas livré avec git c’est un outil à part.

Parfois, c’est git rebase --continue ou git merge --continue qu’il faut faire pour continuer le travail en cours (au lieu de git commit)

Un truc intéressant, c’est d’utiliser git push --force-with-lease à la place. Ça évite d’écraser si d’autres on fait quelque chose entre temps. Ça ne sera pas destructeur.

1 J'aime