10ème séquence - Gilded Rose

Bonjour et bienvenue dans l’équipe de la Rose dorée.

Comme vous le savez, notre petite taverne située à proximité d’une cité importante est dirigée par l’amicale aubergiste Allison.

Nous achetons et vendons uniquement les meilleurs produits. Malheureusement, la qualité de nos marchandises se dégrade constamment à l’approche de leur date de péremption.

Un système a été mis en place pour mettre à jour notre inventaire. Il a été développé par Leeroy, une personne pleine de bon sens qui est parti pour de nouvelles aventures.

Votre mission est d’ajouter une nouvelle fonctionnalité à notre système pour que nous puissions commencer à vendre un nouveau type de produit.

Mais d’abord, laissez-moi vous présenter notre système :

  • Tous les éléments ont une valeur sellIn qui désigne le nombre de jours restant pour vendre l’article.
  • Tous les articles ont une valeur quality qui dénote combien l’article est précieux.
  • A la fin de chaque journée, notre système diminue ces deux valeurs pour chaque produit.

Plutôt simple, non ?

Attendez, ça devient intéressant :

  • Une fois que la date de péremption est passée, la qualité se dégrade deux fois plus rapidement.
  • La qualité ( quality ) d’un produit ne peut jamais être négative.
  • « Aged Brie » augmente sa qualité ( quality ) plus le temps passe.
  • La qualité d’un produit n’est jamais de plus de 50.
  • « Sulfuras », étant un objet légendaire, n’a pas de date de péremption et ne perd jamais en qualité ( quality )
  • « Backstage passes », comme le « Aged Brie », augmente sa qualité ( quality ) plus le temps passe ( sellIn ) ; La qualité augmente de 2 quand il reste 10 jours ou moins et de 3 quand il reste 5 jours ou moins, mais la qualité tombe à 0 après le concert.

Nous avons récemment signé un partenariat avec un fournisseur de produit invoqué (« Conjured »). Cela nécessite une mise à jour de notre système :

  • les éléments « Conjured » voient leur qualité se dégrader de deux fois plus vite que les objets normaux.

Vous pouvez faire les changements que vous voulez à la méthode updateQuality et ajouter autant de code que vous voulez, tant que tout fonctionne correctement. Cependant, nous devons vous prévenir, ne devez modifier en aucun cas la classe Item ou ses propriétés car cette classe appartient au gobelin de l’étage et il rentrera dans une rage instantanée et vous tuera sans délai : il ne croit pas dans le partage du code. (Vous pouvez ajouter une méthode updateQuality et des propriétés statiques dans la classe Item si vous voulez, nous vous couvrirons)

Juste une précision, un produit ne peut jamais voir sa qualité augmenter au-dessus de 50, cependant « Sulfuras » est un objet légendaire et comme tel sa qualité est de 80 et il ne change jamais.

5 J'aimes

https://www.cyber-dojo.org/individual/show/

  • safa key module pour firefox

  • https://jasmine.github.io/

  • à faire ajouter un plugin dans vim pour supprimer les parenthèses

  • sans plugin f(F)

  • vim : f {char} , pour suivant ; pour précédent

  • subtilité vim : p pour paste après le curseur P pour après le curseur si dd c’est sur toute une ligne donc paste sur ligne après

  • vim : pour ajouter un espace en mode normal faire une macro avec q à voir

  • bash : --version (-- pour un mot complet / - pour une lettre) -v sauf exeption

  • boiler plate : fondation du code : ce que l’on doit set up pour que le code fonctionne

  • https://brave.com/fr/ (Momo à ça je crois je reconnais le lion à demander)

  • plénière Clevy cf post de @laurine plus bas

  • Golden master : test fonctionnel qui vérifie ce que fait un code existant et fonctionnel

  • DDD ; TDD

  • bash : python3 golden_master > machin.txt prend ce qu’à écrit le test dans machin.txt

  • à redemander : bash : diff file1 | python3 code.py ?

  • bash `shutdown now

  • vim : a = append c = change d = delete …

  • vim : effacer ce qu’il y a entre des parenthèse di( ou di) + () da( ou )

  • vim ajouter qqch à la fin de plusieurs ligne :epour editnomDeFichier

  • bash : echo comprend un retour à la ligne echo -n pour ne pas avoir le retour à la ligne

  • bash : diff file1 files2

  • bash : cat file1 | diff file2

  • bash : faire man stdin

  • bash : sortie standard par défaut => terminal ; entrer standard par défaut clavier.

  • https://mattermost.com/product/

  • https://www.backmarket.com/ des trucs à moindre prix. https://fonts.google.com/ typo
    merci @patdc

  • https://nestcloud.org/ bon site ?

  • https://github.com/tpope/vim-surround | https://github.com/junegunn/vim-plug

branche github :

  • git branch -r ou --remotes pour voir les branches distantes
  • git branch -a ou --all pour voir toutes les branches distantes et locales
  • git branch -d branche1 ou --delete supprimer une branches local -D pour forcer la suppression (~ -rf)
  • git checkout -b branche1 --track (ou -t) origin/branche1 crée branche1 localement et suivre branche1 distant.(origin par convention voulant dire distant)
    ou
    git checkout -b branche1 puis git checkout -t origin/branche1
2 J'aimes

@loan je suis totalement rentrée dans le scénario, c’était magique.

Journal de Gwen

03.02.2020

Absente mais lu la documentation rust que @Adriel m’a envoyé.

04.02.2020

Abs le matin
J’ai vu le projet et j’ai lu le code. début de compréhension des différents fichiers et de leurs utilités. J’ai vu que pour donnée une valeur 0 à quelque chose on peut dire valeur1 = valeur1 - valeur1

Adriel a choisi le langage rust pour le projet et ça le semble intéressant de le voir sur ce projet.
J’ai quelques questions sur le code qu’il a fait hier et je lui poserais demain (pourquoi toute une partie du code est en commentaire? est-ce pour se rappeler des différents items? Comment fait il pour les objet « invocated »?)
Demain on complété les test et on commence a refactorer

05.02.2020

Ce matin on a eu une plénière sur les test afin de mieux comprends comment faire les test pour notre projet.

Cet après midi, avec @Adriel on a nettoyé notre code et simplifié même si certains points ont du être modifier dans le fichier tests (les valeurs n’étaient pas correctes).
J’ai appris les raccourcis vim :

  • u = retour en arrière
  • yi" / yi( = copier quelque chose entre " " / parenthèses
  • c = supprimer le texte sélectionner
  • :h = afficher l’aide de vim

06.02.2020

Ce matin j’ai encore essayé de réparer mon bluetooth et j’ai découvert que pour trouver un driver realtek sur linux c’est compliqué.
On a eu une Masterclass avec des dev qui ont créer un nouveau langage afin de simplifier la création de chat-box car jusque là il fallait plus d’un an pour créer un chat-box clair. Grace à ce nouveau langage (codé sur une base de rust) pour le même résultat il faut moins d’un trimestre.

Cet aprem on a fait du BDD et du TDD en python.

Journal (lundi 03)

J’ai pris connaissance de l’historique et de la philosophie du langage rust.
J’ai appris comment compiler un projet avec la commande cargo, pour build et test.
J’ai appris l’existence du paradigme « concurrentiel », j’ai besoin de me renseigner un peu plus.
J’ai appris que le rust était développé par la fondation « Mozilla ».

Journal (mardi 04)

J’ai appris que pour écrire des tests, j’ai toujours besoin de me demander :
« Comment je peux écrire mon test pour avoir l’assurance que ça pète en cas de régression ? »,
« Qu’est-ce qui peut arriver de mal qui ne soit pas encore prévu par mes tests ? »
J’ai l’impression que c’est en tournant les choses dans ce sens que j’arrive à rédiger mes tests.
Je pense plus aux « edge cases » qu’aux cas de figures récurrents que je n’ai pas besoin de tous tester.

Journal (mercredi 05)

J’ai appris qu’on pouvait utiliser >, < (et =) en mode -- VISUAL BLOCK --.
La puissance de vim est encore démontrée… Merci Del !
J’ai appris l’existence du mode -- (insert) VISUAL -- et dérivés (visuel ligne et block).
On peut y accéder en mode insertion via ^Ov, ou avec la souris avec :set mouse=a.
vim nous cache ses modes…

J’ai appris à utiliser les match en rust.
J’ai appris que la documentation de rust est très bonne (en tout cas elle me plaît beaucoup).
J’ai appris à déclarer une fonction, et le type de son retour (ce qui est très clair).
J’ai appris qu’on ne déclare pas d’objet en rust : on implémente (impl).
J’ai appris que la bibliothèque standard est très compartimentée (::string, ::vec, etc).
J’ai appris que rust te fait l’affront de décider des conventions d’écriture à ta place.

On est toujours dans cette séquence ? Je ne comprends plus…

Journal (lundi 10)

J’ai appris à faire un découpage d’une feature en vue de sa réalisation technique et concrète.

Journal (mercredi 12)

J’ai une meilleure compréhension de la structure d’un serveur apache.
J’ai une meilleure compréhension de la structure d’un projet.
J’ai appris que l’on pouvait faire des requêtes SQL avec php.
J’ai appris que le rôle du serveur doit effectivement être le plus léger possible (le fichier principal)

Je suis encore dans le flou à propos de SSL/TLS, les certificats (de types MIMES ?)

En essayant de l’implémenter, j’ai une idée de ce à quoi ressemble le code d’apache serveur, par exemple.

Plénière du mercredi 05 février 2020.

On reprend un code déjà existant de Alya. Le code est en javascript, framework jasmine. Permet de faire des tests en js.

Le principe de ce code est de faire une boutique de location de dvd.

Ce code est de base dans le bouquin refactoring qu’on a à l’école. Mais en version java, Alya a donc trouvé un code javascript sur internet et va nous envoyer le lien.

Mindmeinster -> permet de faire des petits schémas pour mieux comprendre le code/ mieux s’organiser. https://www.mindmeister.com/fr

On traduit le code en schéma pour mieux l’appréhender.

Le code est en plusieurs fichiers, dans plusieurs dossiers. Le code principal est dans le dossier ‘src’, on suppose donc que dans le dossier ‘spec’, il y a les tests.

On est dans le fichier PlayerSpec.js

On check que les tests déjà existants fonctionnent. C’est le cas, on va passer à nos tests.

On crée une variable customer, qui a pour caractéristiques : name & rentals.
On crée une variable movies.
-> 2 nouveaux objets.

On copie colle le code dans le navigateur, on check si tout va bien et si nous nouvelles variables sont bien.

On supprime nos nouveaux objets, on avait pas encore fait de tests, il vaut donc mieux checker si tout fonctionne et ensuite y ajouter des éléments.

On test le customer.

On crée un test, pour vérifier que le résultat attendu, est égal au résultat. expect(resultatAttendu).toEqual(resultat);

Le test fonctionne. Le code arrive a créé un statement.

On crée un tableau Movie, qui contient l’Id d’un film, qui lui même contient son code, et son titre.

(Le code d’un film a été établi par le client théorique. On ne sait pas exactement à quoi cela correspond.)

Var movies = [{ “movieID”: { “Code” : “regular”, “Title” : “Titanic } }];

Ou

Var movies = { “movieID”: { “Code” : “regular”, “Title” : “Titanic } };

Le second code est le bon.

Toute petite réflexion sur la différence entre un dictionnaire, une table, un array, une liste et un pointeur. (Mais je crois qu’il faudra en reparler.)

Le résultat de notre test est juste, mais il est écrit FAILURE. Cela signifie que notre test a mal été écrit, même si le résultat que l’on a est le bon.

On a écrit un seul test qu’on a modifié 6 fois.

Plus les tests sont précis, plus on comprend précisément le problème, et moins on a de bug.

On peut se resservir d’un test, pour en améliorer un autre.

Dans statement.js, il y a une fonction qui nous return ‘result’, qui est une chaîne de caractères.

Exercice de Refractoring dans l’aprem

On a repris le code de ce matin.
Comme il était en une seule fonction, on l’a divisé en 5 fonctions. Une pour le statement, une pour le résultat en html, une fonction pour updater le nombres de points de fidélité, une fonction qui calcule le montant total qu’on doit, et une pour le montant par film.

La fonction qui transforme le code en html n’est pas encore faite. Mais elle va faire appel à chaque petite fonction qu’on a créé.

Lundi 03.02.20

Mon binôme pour ce projet est Lydia. On a choisi de travailler sur Python car c’est un langage que je ne connais pas du tout, et ça permettait à Lydia de le réviser.
On a créé le repo en décidant de rédiger à tour de rôle une journée chacune.
Je me suis familiarisée avec Unittest pendant l’après-midi pour savoir comment faire des tests sur Python.

Mardi 04.02.20

On a passé la matinée à faire un exercice de test sur une méthode qui permet de savoir si une année est bissextile ou non.
L’après-midi, on s’est attaqué aux tests avec Lydia, on a choisi de faire une méthode test qui permet de vérifier tous les types de produits différents sur une durée de 30 jours, pour pouvoir regarder l’évolution de la qualité des items. On a réussi à faire marcher notre test à la fin de journée donc on était contentes.

Mercredi 05.02.20

Le matin on a encore vu les tests avec Alya mais en javascript cette fois-ci.
L’après-midi, on a corrigé le code de base. On a ajouté un attribut « category » aux Items pour nous permettre de faire un code plus clair, et pour permettre l’ajout d’items plus facilement sans modifier le code. Il reste beaucoup de if, mais le code est beaucoup plus clair et beaucoup plus lisible. Et surtout, il marche et les tests donnent les résultats attendus. On a ensuite tout push sur notre repo en commun.

J’aime de plus en plus Python car c’est un langage qui ressemble beaucoup à Ruby, que je connais un peu, donc je ne suis pas trop perdue et je peux avancer dans le projet. Et c’est trop bien de bosser avec Lydia :slight_smile: J’ADORE SON ÉNERGIE .

Jeudi 06.02.20

Masterclass intéressant avec les gens de Clévy même si j’ai très peu d’intérêt pour les chat-bots et pour l’entrepreneuriat donc j’ai pas trop suivi en fait lol.

L’après-midi, j’étais un peu soûlée. Je n’ai pas aimé l’atelier (même si le refactoring est hyper intéressant), je trouve qu’on a perdu du temps sur la configuration de l’espace, sur la méthodologie à adopter, sur la compréhension de l’exercice qu’on était en train de faire. J’aurais préféré continuer le projet. Je pense que l’atelier aurait été plus pertinent à un autre moment de la semaine. Et j’ai pas pu travailler avec Lydia du coup :disappointed_relieved:.

Vendredi 07.02.20

J’ai pas travaillé mais j’ai passé une très bonne journée. C’était sympa de discuter avec Laurine, Lydia, Zadia et Mohamed. J’espère un peu plus travailler les prochains vendredi quand même. Et j’espère avoir plus de tunnels de code dans les semaines à venir pour écouter de la musique.

Lundi 10.02.20

On a fait un nouveau projet qui impliquait tous les apprenants. Je me suis mis avec Adriel et Lydia pour s’occuper de la partie compte/inscription/connexion. On a d’abord découpé ce qu’on devait faire en plusieurs parcours utilisateurs. Puis avec l’aide précieuse de Fanny (<3), on a découpé techniquement ce qu’on devait faire.
On a décidément d’un accord avec tout le monde qu’on allait travailler sur ce projet tout ensemble comme dans une vraie boîte. Je trouvais que c’était une superbe idée. Cependant, je crois qu’on n’a pas clairement défini le rôle de Marine.
C’était très sympa d’apprendre à travailler avec Adriel.

Mardi 11.02.20

On s’est divisé les tâches dans mon groupe, Adriel et Lydia étaient sur la partie serveur, tandis que moi je m’occupais du front et donc de la mise en forme des différentes pages. Je me suis un peu pris la tête au début à essayer de le faire en python, mais j’avais du mal à trouver les bonnes infos et rapidement j’ai vu que c’était une galère en python, la plupart des tutos suggéraient d’utiliser un framework, or j’ai aucune idée de comment manipuler un framework python et ça supposait que les autres se servent du même framework. Je me suis donc tourner vers HTML / CSS, c’était sympa de renouer avec ces 2 langages simples que j’aime bien. J’ai passé ma journée à faire ça tout en communiquant avec Adriel et Lydia pour savoir où ils en étaient. On faisait des points en fin de journée avec les autres groupes pour se tenir au courant des avancements du projet.

Mercredi 12.02.20

J’ai continué à bosser pour le front, mais j’avoue que je m’ennuyais un peu, j’aurais peut être du me mettre plus en danger et choisir une mission que je ne connaissais pas du tout comme la database ou le serveur pour apprendre plus de choses. C’était sympa de bosser avec Patricia l’après-midi. J’avais l’impression que le projet prenait forme avec les autres et qu’on allait pouvoir commencer à tout connecter le lendemain pour voir s’il y a quelques éléments qui marchent ensemble.

Jeudi 13.02.20

J’étais hyper déçue que la masterclass soit annulée, elle m’intéressait beaucoup. J’ai pas foutu grand chose la matinée :’(.
L’après-midi était un peu chaotique pour ma part, déjà on n’a pas du tout continuer à coder avec le groupe. Puis c’était l’heure de la rétro qui a duré une éternité selon moi. J’ai un peu déchanté aussi parce que j’avais pas l’impression qu’il y a tant de problèmes que ça avec le projet pendant la semaine parce que pendant les points en groupe tout se passait bien, et là tout d’un coup, je réalise qu’il y avait plein de problèmes non résolus.
On a parlé de problèmes en long et en large, c’était hyper redondant, sans trouver de solutions, ça partait dans tous les sens, avec des sous-problèmes parfois entre petits groupes qui pouvaient se régler entre les concernés selon moi. On a donc fait une sorte de réunion à 10-15 de 14h à 17h et des poussières, je doute de l’efficacité des réunions, non préparées par les participants, à la rallonge dans ce format là avec autant de monde. J’étais en train de perdre en patience car j’avais du mal à voir l’intérêt de l’exercice, donc quand on m’a parlé la parole, j’ai complétement perdu patience, et je préférais sortir et m’aérer plutôt que de m’énerver irrationnellement. Je suis très contente d’être sortie, ça m’a fait du bien.

Vendredi 14.02.20

DevFest

Plénière CLEVY - Chatbot - Créer son propre langage

[Les slides seront envoyés]

Boite de moins de 3 ans.

Spécialisée dans les chatbots.

Fournissent la plupart du temps des chatbots en entreprise pour de l’usage interne.

Définir un Chatbot:

  • Quand un être humain parle avec une machine via une interface de chat, en langage humain.
  • On peut relier ce chat a un moteur d’intelligence artificielle, ou le relier à quelque chose qui permet de donner des ordres, type: “Machin allume la lumière” et la, la lumière s’allume
  • Tout le chatbots n’ont pas d’intelligence artificielle
  • But : automatiser des choses de manière sympa / Optimisation de support interne / Réduire les couts des supports / Augmenter la productivité / Améliore l’expérience utilisateur.

Clients Clevy :

  • Roche
  • Danone
  • Sanofi
  • Ministère des armées
  • SNCF
  • Yves rocher
  • Chanel
  • Crédit Agricol
  • Agence nationale de l’habitat

5 composant communs à tout chatbot :

  • Message
  • Orchestration (afficher un truc à un moment donné plutôt qu’un autre truc)
  • Se connecter avec des API
  • Mémorisation
  • Compréhension

Faire un chatbot:

  • 1ere solution : Création graphique de chatbot (compliqué de gérer 14 scénarios d’exception) - Permet de faire du glisser déposer des éléments qui vont faire le chatbots.
  • 2eme solution : On prend un langage, on fait toute la stack de base (2 semaines de boulot) pour faire tout le boulot derrière.

Pour un chatbot, le messaging doit être riche.

Le but de clevy est de permettre à tout le monde de créer son propre bot sans avoir nécessairement fais des études en programmation.

Ils ont créé leur propre langage parce que dans tous les autres, la logique est beaucoup plus longue. Avec leur langage csml (https://www.csml.dev/), on peut faire un chatbot SIMPLE en 5 lignes. On a comparé avec le premier projet github de chatbot en python, le fichier fait 200 lignes pour un résultat plutôt simple.

Ils ont fait leur langage en Rust, mais leur langage final ne ressemble pas à du rust. Il y a de la logique de js, et de python.

Ils ont créé leur fonctions (par exemple button) de manière à tout simplifier, pas besoin de connexion d’api, la fonction le fait.

Leur langage permet de se souvenir des préférence de l’utilisateur, même une fois qu’on recommence une conversation avec le bot.

On peut faire un chatbot sur toutes les plateformes comme slack, messenger, ……

Ils ont un “espèce d’appstore” qui nous permet de télécharger (par exemple giphy), pour nous permettre de répondre des gifs.

Petite parenthèse inutile : On a aussi cette fonctionnalité sur le slack d’ada, si on tape “/giphy ours”, on obtiendra un gif aléatoire qui a un rapport avec un gif. C’est rigolo pour répondre à quelqu’un :wink:

Créer un nouveau langage pour les chatbots, COMMENT ?

(je suppose que la logique peut s’appliquer pour n’importe quel langage que l’on crée, pas nécessairement chatbot.)

Définir la mission du langage csml :

  • Réduire de 90% le temps que ça prend à un développeur pour créer un chatbot, et le déployer.

Définir qui on target :

  • Startups, agences qui ont des commandes clients pour faire des chatbots, ou des entreprise qui veulent créer leur propre chatbot en interne et qui ont pas bcp de gens pour le faire, et pas beaucoup de temps.

Définir à quoi ça ressemble:

  • But: que ca ressemble au plus à un langage humain, très peu de keywords.
  • Un verbe d’action suel ou un verbe d’action et une action à faire.
  • Pas de return, pas de ternaire

Définir tous les concepts:

  • bot?
  • Métadonnée?
  • Réponse?
  • …………

Définir une architecture :

  • Comment on fait tourner le programme ?
  • Comment on se débrouille pour qu’il n’y ai pas de temps de latence, pour que tout soit synchroniser.
  • ……………

Résoudre les problèmes de chatbots avec du “langage design”.

Reprendre les 5 composants de tout chatbots (voir au début du post) et les modifier de manière à coller avec le but de notre chatbot.

Il faut écrire des tonnes de chatbots pour mieux comprendre ce qu’on souhaite.

Montrer son nouveau langage à d’autres devs pour savoir si il est assez facile d’utilisation.

Dans ce cas la, l’UX de l’utilisateur c’est le langage.

Ils ont écrits des tonnes de docs, pour bien tout définir.

2 liens vachement intéressants pour construire un nouveau langage :

Les erreurs que clevy a fait :

  • Mal définir un float, il changeait en fonction des personnes.
  • Il avaient prévu que les utilisateurs allaient coder une boucle de telle manière, mais dans la réalité, personne ne le faisait de la même manière, ils rencontraient donc un bug. Cela leur a pris 3 mois pour repenser cette boucle.
  • Ils voulaient utiliser les stacks pour se souvenir de tout l’historique de la conversation d’il y a 3 semaines. Concrètement personne ne l’utilise, parce que “tout le monde s’en fou de savoir que notre couleur préférée à été rouge, puis verte, puis bleu”. Résultat, ils enregistrent tout les éléments comme avant, mais ils ne donne accès qu’à la dernière version.

Les choses qui se sont bien passées :

  • Langage est très différent de ce que les gens connaissent.
  • L’utilisateur a le contrôle du langage.
  • “Le langage csml a gardé que les trucs cool.”
  • Technologie est mieux que celle des concurrents.
  • On peut rajouter des fonctionnalités du langage comme on veut, sans dépendre des mises à jour de python ou autre.
  • Ils se sont bien entourés de gens en qui ils avaient confiance, et des gens qui étaient trop fort.
  • Le choix de Rust pour créer leur langage est bien parce que même si le langage est difficile à prendre en main, le langage est hyper stable.

Contact :
Fondateur : francois@clevy.io
Postuler : https://jobs.clevy.io

Tester leur langage : https://www.csml.dev
La documentation de csml : https://docs.csml.dev

4 J'aimes

Merci Laurine, tu gères !

1 J'aime

Lundi 10 février 2020

Plénière discussion sur les fonctionnalités avec Agathe

(Les fonctionnalités avec un carré rouge sont les plus « galères » à développer & les vertes sont les plus « faciles »)

  • Faire remonter les produits populaires :red_square:
  • Vitrine pour afficher les produits :green_square: (Soumayaat, Gwen)
  • Catégoriser les produits :green_square: (Patricia, Wara)
  • Suggestions :red_square:
  • Pouvoir acheter un produit :green_square:
  • Tracking :red_square:
  • Avoir un compte (Loan, Lydia, et Adriel)
  • Avoir un panier (multi produits) :red_square:
  • Avoir un catalogue :green_square:
  • Système de données (Zakia, Nicolas, Laurine)
  • Interface admin
  • Alerte produit en stock :green_square:
  • Mails automatique :red_square:
  • Donner avis sur les produits :green_square: (Fayal, Mohamed, Florian)
  • S’inscrire à la newsletter :green_square:
1 J'aime

Plénière du mardi 11 février 2020 avec Alya

Discussion sur les problèmes qu’on va rencontré à bosser tous ensemble & comment les résoudre

  1. Conflits GIT -> branches => <!> Fichiers séparés

  2. C’est souvent le bazar, il nous faudrait un « maître » du bazar pour nous aider à nous organiser, et nous remettre dans le droit chemin quand on dévie trop du sujet principal. Et le « maître » du bazar nous aiderais à communiquer : Marine ?

  3. BDD:

  • de tests, pré-remplis ?
  • Chaque groupe
  • Map de la base ?
  1. Nécessaire d’avoir un serveur pour tout le monde ? -> oui
    Il n’y a pas de groupe qui s’en occupe, c’est embêtant.
    On peut utiliser le serveur de la base de données. Mais est ce que c’est mieux de coder notre propre serveur ?
    Adriel se dévoue pour faire un petit fichier serveur avec quelqu’un d’autres.

  2. La BDD est le cerveau du projet, et le front est son corps. Donc il faut COMMUNIQUER.

  3. Actuellement le projet peut faire avancer le temps et prend en compte le stock, pour permettre l’achat de produits.

  4. Faire des points tous ensembles:

  • Limiter ces points
  • S’y tenir
  • 1 personne par groupe ? (Pour les points improvisés)
  • Sans ordi
  • Il faut que ce soit efficace
  • Pas plus de 10 mins
  • Allez à l’essentiel
  • 1 point par demi journée ?
  1. 3 dépots avaient été crées pour cette semaine. On choisit le dépot « Gilded_Rose_Ada_Project ».

« Compte rendu » des points du mardi 11 février.

Matin:

Groupe du Front veut un point avec Adriel pour le serveur.
Le groupe Front, se demande si ils mettent tout leur code dans un main et « les autres se démerdent après ».
ou si ils coupent dans des petits fichiers.

Point du Mardi à 12h :

Catégories : On différencie les rayons et les catégories. Les rayons sont pour les acheteurs et les catégories
pour les vendeurs.
Les produits peuvent être dans plusieures catégories.
Les Rayons ne seront pas intégrés maintenant, car c’est une évolution. On part du code déjà existant de Loan & Lydia.
Un rayon = 1 ID (par exemple: ID1: Habillement, ID2: Collector).

Mardi 12h30 : Mini-cours sur les branches d’Adriel.

  • git checkout -b vitrine-du-site : Créer une branche qui s’appelle vitrine du site.
  • git branch : Liste les branches, celle qui a une petite étoile, c’est celle sur laquelle on est.
  • git push --set-upstream origin vitrine-du-site : On envoie la branche sur git
  • git checkout master : On renvient sur la branche master.
  • git branch --all : on liste toutes les branches pas forcément qu’on a sur notre pc, en local.
  • git checkout origin/db_branch : on télécharge db_branch sur notre pc.
  • git pull : Pour choper toutes les branches.

Attention !!! On push QUE sur notre branche, SURTOUT PAS sur master.
Vérifiez bien que votre push à réussi à chaque fois. Si il y a « fatal error » à la fin, y’a un soucis.
Checkez bien que vous bossez sur votre branche.

Mardi 14h :

Groupe base de données : Programme de l’aprem : Commencer par faire le README, pour que tout le monde ai les infos, ensuite on va faire des map SQL, et finir par faire les tables dans la base de données en fonction de ce que les autres groupes vont nous donner. On pense utiliser mocodo.net pour les map.
Groupe mon_compte : Recherche sur comment créer un compte en Python

Mardi 17h :

Groupe serveur / Avoir un compte :
Ils ont repris quelques lignes plutôt courtes pour faire serveur.
Ils ont terminer leur journée en codant une fonction qui sert à rendre des pages en HTML.
Ils veulent faire en sorte que le serveur puisse requêter la base de données.
Loan : Partie FRONT : préparer terrain pour page connexion, inscription, profil.
Ils sont partis du principe que quand on est administrateur, on a pas un compte spécial, mais on a une plateforme à part.
Profil a juste besoin du mail & du mot de passe.
Le serveur sert à gérer le passage du temps.

Groupe base de données :
Ils ont partis de la table PRODUIT & la table STOCK.
Ils ont fais des points avec plusieurs groupes :

  • groupe mon_compte : ont exprimé leur besoin d’une table USER. Pas besoin d’un admin.
  • groupe avis : ont exprimé leur besoin d’une table AVIS.
  • groupe categorie : ont papoté de l’utilité d’une table CATEGORIE pour mettre plusieurs catégories pour un seul produit. Résultat, pas de double catégorie, et pas de table catégorie. On intègre la catégorie dans une colonne du produit.
  • groupe FRONT : Pas de points entre le Front & la base de données pour aujourd’hui.

« Dites les gens, vous voulez vous connectez à la base de données ? Ou l’importer ? » (de Zakia)
-> Réponse : On s’y connecte.

Groupe categorie :
Sont entrain de construire des pages qui vont se regroupés avec le groupe FRONT.

Groupe FRONT (& groupe avis, ils se sont regroupés) :
Ils sont en PHP.
Header & footer se retrouvent dans toutes nos pages. Le footer est statique.
Ils ont séparés dans pleins de fichiers.
Ils voulaient utiliser bootstrap. Ils hésitent à faire un mix entre css et bootstrap.
Ils utilisent le rose d’Ada en fond.

=> Prochain point : mercredi fin de matinée.

Avancement des groupes (Mardi 11 & Mercredi 12):

Groupe Base de données :

Création des tables :

Une map de la base de donnée est disponible sur la télé.

Le (PK) signifie Primary Key, permet de faire appelle à la table grâce à cette Primary Key.

PRODUIT : Id_Produit (PK), Categorie, Nom, Qualite, Jour_Vente.
STOCK : Id_Stock, Id_Produit, Categorie_Stock, Quantite_Stock, Date.
USER : Id_User (PK), Mail_User, Name_User, Surname_User, MDP_User.
AVIS : Id_Avis, Contenu_Avis, Id_User, Id_Produit,Date_Avis.

Table Avis dépend de Table User. La primary Key pour les 2 est : Id_User.
Table Stock dépend de Table Produit. La primary Key pour les 2 est : Id_Produit

  1. Point avec groupe mon_compte : a besoin d’une table USER qui contient:
  • Id_User (PK)
  • Name_User
  • Surname_User
  • Mail_User
  • MDP_User
    Le mot de passe sera modifiable, ainsi que le nom. L’email n’est pas modifiable.
    On peut supprimer son compte. Donc effacer toutes les données.
    Lydia part avec Adriel faire un serveur en Python.
    Loan part faire des recherches sur comment faire une création de compte en Python.
  1. Point avec groupe catégories :
    Catégorie = descriptif (par exemple: gants = vêtement).
    Fais partie du Produit.
    /!\ Dans le site, on part du principe que pour trouver un produit on passe par sa catégorie.
    Pour l’instant il existe 5 catégories : Légendaires, Nourritures/Boissons, Tickets, Vêtements, Armes.
    Par la suite on pourra modifier ces catégories, en ajouter, et en supprimer.
    On peut avoir plusieurs catégories pour un seul produit.

  2. Point entre groupe serveur & Front (espionné par Laurine):

  • Qui fait la fonction qui renvoie le code python en page html
  1. Point avec groupe Avis : a besoin d’une table AVIS:
  • Id_Avis (INT)
  • Contenu_Avis (MEDIUMTEXT)
  • Id_User (INT)
  • Id_Produit (INT)
  • Date_Avis (DATETIME)
  • (?) Note (INT 0-5)
    Une personne peut mettre autant de commentaires qu’il veut, sur autant de produits qu’il veut.
    Peut-être mettre un commentaire uniquement si on est client.
    L’id_user nécessaire dans la table implique qu’on doive être connecter pour mettre un commentaire.

Pas de news de l’équipe Front.

Précisions:
Id_Var sert à savoir de quel type de variation on parle (Sell_in/Quantite/Qualite).
COMPORTMENT signifie la variation des seel_in/Quantite/Qualite des produits.

=> POUR DEMAIN : Ajouter la notion de date à la mise d’un produit en stock (merci Alya on avait zappé)

1 J'aime