11ème séquence - Jeu du Morpion

Le morpion est un jeu de réflexion se pratiquant à deux joueurs au tour par tour et dont le but est de créer le premier un alignement sur une grille.

Voir projet : Créér un jeu de morpion

Règles possibles à ajouter :

  • agrandir grille
  • Augmenter nombre pions alignés pour gagner
  • Une fois grille complète, on peut manger un pion de l’adversaire
  • Changer le jeu en puissance 4
  • Augmenter nombre de joueurs

Équipes :

  • Florian Patricia et fayal
  • Nicolas Mohamed Gwen
  • Adriel Soumayaat Laurine
  • Lydia Zakia
  • Del loan

Plénière du Lundi 24 février.

Sujet : Lecture du Code sur un Morpion en langage ADA.

Lien : https://openclassrooms.com/forum/sujet/algo-tous-langages-parties-de-morpion-96556
4eme post.

Le jeu se termine quand toutes les cases sont remplies OU si on a un gagnant.

Lignes 16 à 21 : On instancie des fonctions & des procédures.

Jusqu’à présent nous n’avons jamais vu de procédures.
La fonction est un type de procédure.
Il y a 4 fonctions, une qui test les lignes, une qui test les colonnes, et une qui test les diagonales et une pour les match nuls.
Elles servent à tester les conditions de victoires.

On essaie de deviner ce qu’est une procedure :
1ere théorie : Procedure permettent de récupérer toutes les interactions avec les utilisateurs (clavier, souris).

Ligne 23 à 31 : Fonction Test_Ligne

Elle prend la grille en paramètre.
Elle renvoie un joueur.
Ligne 25 : N est le compteur (i dans d’autres langages).
-> Lance une boucle avec son itérateur (N) qui commence à 1. G représente la grille.
On lance la boucle 1 seule foispour chaque élément de la grille.
Ligne 26 : = sert à faire une comparaison. /= sert à faire une comparaison mais négative (est différent).
-> Check toute la ligne, case par case.



if G(N,1) /= VIDE signifie « si la case elle est pas vide » et le reste de la ligne sert à comparer les autres cases.
On sort du if quand la ligne est remplie (quand elle contient 3 symboles identiques).
Et on renvoie un élément de la ligne en sortant. Si N = 2, on renvoie ce qu’il y a dans la case (2, 1).

Ligne 33 à 41 : Fonction Test_Colone

On a décidé que les lignes c’était 1 et que les colonnes c’était 2.
C’est un tableau avec plusieurs niveaux, un tableau à 2 dimensions.
On fait les mêmes vérifications que pour les lignes.
Si la première case est différente de la seconde, on passe à la suivante.

Ligne 43 à 52 : Fonction Test_Diagonale

Pareil que pour les lignes et les colonnes.
On part du centre de la grille (2, 2), et on test si les extrémités sont égales.

Ligne 54 à 64 : Fonction Match_Nul

Ligne 54 : On return un boolean donc on test si c’est soit vrai soit faux.
Ligne 59 : Ici on renvoie faux car il y a une case de vide, donc la condition de fin du jeu « quand toutes les cases sont remplies » est fausse.
Ligne 63 : Si tout est rempli et qu’il n’y a pas de conditions de victoires, Match Nul, on return TRUE.

Ligne 4 à 14: Procédure Morpion

Ligne 6 : On est dans un tableau à 2 dimensions.
:= Sert à affecter une valeur.
Ligne 9 : On construit un tableau avec une colonne de 1 à 3 en largeur et 1 à 3 en longueur. Donc on fait notre tableau avec nos 9 cases.
On manipule pas un Joueur, on manipule un état. Le choix du mot Joueur était peut-être pas le bon.
Ligne 11 : Record c’est quoi ? Type structuré (comme en C) « C’est en gros les ancètres des objets ». On peut en trouver par exemple en C++.

Pourquoi on définit la grille en L.9 ? Et pourquoi on le fait comme ça ?
Apporte de la flexibilité si on veut ajouter des dimensions.
C’est l’inverse de l’encapsulation. https://fr.wikipedia.org/wiki/Encapsulation_(programmation)

Petit point spécial tableau à dimensions :
array(1..4,1..6) = tableau 4 colonnes et 6 lignes.

Ligne 1 et 2 : On ajoute une librairie. Ressemble à Python.

Ligne 110 à 135 : C’est quoi une procédure ?

Une procédure peut utiliser les fonction.
La procédure ici lance le tour de la personne.
Elle va remplir la grille. Et modifier les données.
Les fonctions lisent les données et les procédures modifient les données.
Les procédures n’ont pas de return.
L 110 on déclare la procédure qu’on nomme Jouer.
J1 et J2 dont des joueurs.
L 111 c’est une variable qu’on va manipuler ensuite. (Comme J2.)
L 126 & 127 : Boucle I correspond à la boucle des lignes et la boucle J correspond à la boucles des colonnes.
L 128 à 135 : On vérifie que la ligne est vide, puis on redéclare J1 et J2. Et on check si la ligne est vide.

Documentation sur ADA qu’on a vu ce matin :

Plénière du mardi 25 février 2019

1. Qu’est ce qu’un test ? Pourquoi les utiliser ? Nos peurs ?

@Wara : Permet de stabiliser le code. Permet de savoir si le code fonctionne.
Très utile pour le réfractoring.
Plus facile de coder avec des tests ?
@lyd.sanaa : Lors d’un forum ouvert, Yannick a bossé devant nous, et a codé avec des tests.
On comprend quand on nous le montre, mais de la à l’appliquer de nous même, c’est BEAUCOUP plus abstrait.
J’ai du mal à visualiser le test où au fil des lignes est ce que le test doit évoluer ? Et pourquoi ? Et comment ?
@Zakia : Yannick nous avait parlé du TDD avant de coder, au tout début. Ensuite on a découvert qu’il y avait plusieurs types de tests, et on sait pas comment les appréhender. Il nous manque la « map » de tout les tests qui existent.
Compétence extraordinaire qui est recherché sur le marché des devs.
Depuis le début j’ai envie de faire des tests. Ce weekend j’ai essayé de faire un test sur « Hello World ».
La partie test n’existe dans aucun projet. Oui il y a des katas, mais pas dans le projet.
@Sooumayat : Système qui permet d’avoir moins de stress, de mieux contrôler ce qu’on fait, garder confiance en soit et s’assurer que tout se passe bien au niveaux des tests.

2. Exercice de catégorisation

On reprend les idées de la partie au dessus, mais on va essayer de les classer.

  • TDD : Tests qui permettent d’écrire avant le programme, le code qu’on à prévu de faire.
    C’est une méthodologie de développement.
  • Test -> stabiliser code : objectif de développement -> stabiliser le code.
  • Refracto / commencer code -> plus facile ? : objectif de test -> Refracto.
  • Test utiliser en travaillant -> intéressant : Technique.
  • Ne sais pas commencer un test : Technique.
  • Système stressant -> permet de garder confiance : Objectif.
  • Compétence qui fait la différence sur le marché du travail : Compétence.
  • Pas tout saisi / difficulté à visualiser -> doit - il évoluer ? : Technique & Méthodologie.
  • Envie de commencer avec les tests -> manque de compréhension de la technique : Technique
  • Map des tests (typologie) : Méthodologie (Résumé d’une vision d’ensemble de tout les types de tests qui existent et leurs points communs).
  • Partie test jamais prévue dans les projets : Objectif de fin de cursus.
  • Environnement de tests (pytest) : Outil / Environnement.

3. On éclaircie les points

Types de tests :
Il existe des TDD, mais aussi une méthode BDD : https://www.arolla.fr/blog/2012/06/bdd-c-est-quoi-donc/

La on a grosso modo tout les types de tests.

4. On bosse en petit groupe pendant 40 mins

Concept du sujet, exemples, pour et contre du sujet.
But : avoir un petit résumé, avoir compris, expliquer aux autres, répondre aux questions des autres sur le sujet.
:thought_balloon: Avoir des outils pour décider et choisir des choses !

4 groupes :

  • TDD :
  • BDD : Lydia, Patricia, Soumayaat, Laurine.
  • Tests d’intégration : Zakia, Mohamed, Nico.
  • Outil / Environnement : Wara, Gwen

5. Synthèse avec tout le monde

Groupe Outil / Environnement :

  • Définitions :
  • Test : Processus vérification de potenciels problèmes (déjà présent ou pas encore)
    -> Selon nature de l’objet, structure de l’objet, propriété de l’objet.
  • Outil : Truc qui a déjà été fait. Spécifique a plusieurs langages. Utilisable immédiatement mais à choisir selon les besoins d’une équipe. On a besoin d’une doc, pas de conflit avec autres outils, facilement mis en place, manipulation facile ou compréhensible, adapté aux tests voulus, mis à jour régulièrement, prix, adapté à plusieurs types de tests ?
  • Environnement : Développeur doit le faire, et le stabiliser. Ne doit pas impacter l’utilisateur, proche de l’utilisateur, doit être testé avec des conditions spécifiques, doit maîtriser tes données. Doit être le plus proche possible de la production, doit être stable et flexible, et doit pouvoir évoluer.
  • Boite blanche & boite noir : https://www.nbs-system.com/blog/tests-en-boite-noire-grise-ou-blanche-quelles-differences/
  • Complément de Fanny :
    Chez Kisskiss… , il y a des tests unitaires. C’était pas foufou côté Front quand Fanny est arrivée, on lui a demandé en premier de produire des fonctionnalités (refaire le header, refaire tout le tunnel de dépôt de projet…), et donc pas le temps de faire des tests. D’autres personnes ont rejoins le bateau Front, et du coup tout le bateau a fait des tests. C’est compliqué d’écrire des tests en rétro-pédalage, donc ça a pas très bien marché. Mise en place de tests d’intégration, création d’un environnement spécial pour déposer le projet et tester le tester. Ce filet de sécurité permettait à toute l’équipe de savoir que tout le code fonctionnait et que la fonctionnalité marchait. Il y avait du refractoring et de nouvelles fonctionnalités en même temps.
    https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
    Voir notes de Gwen en bas.

Groupe Tests Intégration:

  • Définition / Concept :
  • C’est quoi ? C’est une phase dans les tests. Tests unitaires (pour vérifier une partie précise du code), deuxième étape tests intégration (on rassemble des unités indépendantes et on les tests ensemble), troisième phase, tests validations.
  • Pourquoi ? Objectif est de détecter les erreurs qui sont pas détectables dans la phase tests unitaires. Comme c’est dépendant, y’a des erreurs possibles. On vérifie l’aspect fonctionnel, les performances et la fiablité du logiciel.
  • Comment ? Programmes d’installations.
  • Choix d’une stratégie pour faire des tests d’intégrations. On sait pas encore comment on choisit :
    Le top down (on test le étape 1, puis on le test avec ses dépendances, (1, 2, 3, puis 1, 2, 3, 4 , 5, 6))
    permet de localiser l’erreur plus facilement, nécessite peu de driver ou de moq (?) Permet d’avoir rapidement un prototype, les erreurs de conception majeurs sont vites détectés .
    Le sandwich, (?)
    Le big mom, (?)
    Le bottom up, on test les fonctionnalités les plus basses, puis on remonte. Localisation facile des erreurs. Les modules réutilisables sont testés correctement. Les tests sont fait en parralèle du développement. On peut faire les 2 en même temps.

Gwen

24.02.2020

Aujourd’hui on a vu du code en ada, c’était sympas de faire cette lecture et compréhension.
L’après midi j’ai été avec Julien afin de le mettre a l’aise face à un terminal. Je lui ai montré et expliquer comment afficher l’alphabet a l’endroit puis à l’envers en python.
Je lui ai aussi montré et expliquer comment faire une recherche.

25.02.15

On a fait une plénière sur les tests, à quoi ils servent, les différences et quand les utiliser. J’ai appris ce qu’étais une boite noire et une boite blanche, la différence entre un outil et un environnement et comment choisir (voir le poste sur les outil et environnement).
L’après midi je n’ai pas été très utile.

Outil - Environnement

Définitions:

  • test: procédure de vérification pour identifier les potentiels problèmes
  • outil: c’est quelque chose qui est déjà fait, on a juste à l’utiliser
    (librairie, framework). Ils sont spécifique à chaque langage.
  • environnement: c’est au développeur de le créer, de l’adapter et de le
    stabiliser.

On classifie les tests en 3 catégories :

  • selon la nature de l’objet (test unitaire, test d’intégration, test système,
    test d’acceptation);
  • selon l’accessibilité de la structure de l’objet (test de conception par boite
    blanche ou noire);
  • selon la propriété de l’objet (test fonctionnel, test de performance, test
    d’intrusion, test utilisateur);

Boite blanche: vérification de la structure interne de l’objet (test unitaire
ou d’intégration > spécifiés avec cette technique de conception).
Boite noire: vérification de le définition de l’objet (test système ou
d’acceptation > spécifié avec cette technique de conception. On peut aussi
l’utiliser les tests unitaires ou d’intégration).

Outils

Un outil permet d’être utilisé immédiatement mais doit être choisi selon les
besoins de l’équipe.
Il y a plusieurs paramètre à prendre en compte:

  • Les mise à jour;
  • Facilité à trouver une documentation;
  • Intégration dans l’environnement du projet / n’entre pas en conflis avec les
    autres outils;
  • Mise en place;
  • Manipulation facile ou compréhensible;
  • Adapté au niveau du test voulu;
  • Multiplicité des types de test;
  • Le prix.

Environnement

Avoir un environnement pour tester le code permet:

  • de ne pas impacter les utilisateurs;
  • de la tester avec certaines conditions spécifiques;
  • maîtriser ses donnée.

L’environnement doit être le plus proche possible de la production pour pouvoir
se mettre dans les conditions réelles.
Il doit également être isolé, stable et flexible.

Plénière du mercredi 26 février.

Sujet : Les règles de vies

:warning: Les règles sont établies jusqu’à ce qu’on rediscute ! :warning:
Les absents ont la possibilité de rediscuter des règles à la prochaine assemblée générale.

Groupe Organisation de travail :

Ne pas couper la parole aux autres :

  • Lever la main.
  • Checker si quelqu’un lève la main avant de parler.
  • S’autoriser de rappeler à l’ordre quelqu’un qui parle sans lever la main si elle a coupé la parole.

Projet -> tout le monde ne code pas au sein d’un groupe :

  • Essayer de switch au sein d’un groupe (heure ou jour).
  • Partage des tâches (dépend du niveau d’autonomie de tout le monde dans un groupe).
  • Aux encadrants de remarquer si quelqu’un ne touche pas le clavier.
  • Objectif : que tout le monde code.

Absence ? Remote ? :

  • Préciser si absent ou si dispo en remote (Le remote est pas encouragé !!).
  • Prévenir groupe & admin.

Projet -> pas d’organisation à distance :

  • Prévoir un frama pour le petit groupe.
  • Dire de quand à quand on va être dispo.
  • S’organiser & communiquer avec son groupe.
  • Avoir le réflexe de push.

Retard -> Comment rattraper son retard :

  • Checkez les notes sur le tribe en arrivant donc pas poser des questions à tout le monde en pleine plénière, sauf si c’est pour des précisions.

Commencer à 10h :

  • On fait comme au début, a 10h, on commence, qu’on soit 2 ou 10.
  • Ecole ouvre à 9h25 donc on a le temps de prendre un café et de se poser avant.

Fixer heure clôture :

  • Pause pipi ou pause clope avant, on s’en fou on commence.
  • Ne pas faire de clôture prématurée si 1 seule personne part plus tôt.
  • Heure clôture 17h45. Mise en place à partir de 17h40. Et tout le monde s’y met (chacun prend sa chaise).

Absence non prévenues :

  • Le dire au début de la semaine si on le sait.
  • Le communiquer dès qu’on le sait & le rappeler au groupe (la veille ou en début de semaine).

Demander l’avis de tout le monde avant d’emmener quelqu’un :

  • Consulter groupe pour les moments de cloture ou rétrospective.
  • Demander l’avis de l’ensemble du groupe.
  • Demander autorisation pour cloture ou rétro ? Juste prévenir sur le reste.
  • Pinguer sur slack si quelqu’un arrive “chez nous”.
  • Prévenir si c’est pour une journée entière ou un moment.

Ceux qui font autres choses pendant que les autres bossent :

  • Le dire quand ça dérange
  • Aller de soi même se mettre “de côté”

Groupe Ménage :

  • Gérer ses propres affaire et uniquement les siennes
  • Ranger avant 14h (ne pas empiéter sur le temps de travail) et avant de partir.
  • Faire sa vaisselle.
  • Checker la nourriture dans le frigo le vendredi soir pour que rien ne pourrisse.
  • Lave vaisselle : ranger le propre avant de mettre de la vaisselle sale.
  • Prévoir un torchon différent pour la vaisselle et pour les mains. Préciser leurs usages respectifs.
  • Eteindre les multiprises (les barettes comme dirait Gwen :wink: )

Groupe Bruit:

  • de 12h30 à 14h, libre de faire du bruit, mais hors des tranches horaires on fait gaffe
  • Lieu de calme dans la salle du bas. Nombre de personnes illimités. Si des groupes veulent bosser en bas, pas plus de 2/3 personnes. On peut chuchoter, mais attention au bruit ! Comme une biliothèque.
  • Réparer la porte
  • Soulever sa chaise quand on la bouge et ne pas la grincer par terre.
  • Tout le monde doit faire un travail sur soi au niveau du bruit. On peut dire à quelqu’un qu’il fait trop de bruit.
  • On peut faire « CHUUUUUUUUUT!! » pour demander à ce que le bruit baisse. Ne pas le prendre agressivement, c’est gentil :slight_smile: !
  • Quand on veut parler à quelqu’un on se rapproche de lui, on cri pas à 5 mètres de lui.
  • Les personnes qui arrivent en retard se taisent et posent des questions à la fin de l’activité.
  • On réchauffe les plats dans les micros-ondes du bas. Pas en haut !
  • :warning: : Pas de café après 10h pour la plénière !!! (Pour l’instant)

Les plateformes :

  • Discord c’est pour les étudiants.
  • On communique les trucs les plus importants sur slack !

Assemblée générale :
Pas de date pour la prochaine.
Elle servira à s’exprimer sur ce qu’on a fait remonter pendant les vacances.
Plutôt un format de questions/réponses.
A instaurer régulièrement ?

Masterclass du 27 février 2020.

Marie Terrier (31 ans)

est une développeuse qui a crée un produit au sein de la boîte, qui a finit par devenir une autre boîte. Elle viendra vous parler de son parcours d’intrapreuneuse. Elle va vous expliquer comment déployer un assistant vocal, et va vous présenter dialogFlow !

@materrier
marie@yelda.ai

CTO Yelda -> plateforme qui permet de déployer des assistants vocaux.
Google assistant & Alexa permet de « télécharger » des assistants vocaux en compléments de ce qu’ils font. Par exemple un téléphone fait déjà beaucoup de chose, mais on peut télécharger des applis pour rajouter des fonctionnalités.

CommitStrip : bd faite par un développeur qui parle des développeurs. Faite par le boss de Marie.
LadiesOfCode : elle est membre.
NodeSchoolParis : initiative mondiale qui propose des ateliers de NodeJS. Gratuit, All day, nourriture du midi fournie.

Parcours :

From Dev to CTO :
Toujours su qu’elle aimait bien la tech, mais ado elle a eu du mal à rentrer dans ce milieu, donc elle a mis ça de côté.
Ecole & prépa d’ingénieur, pas orienté tech. Quand elle est entré à l’école elle a voulu faire de la tech, son école ne proposait rien, donc elle a rencontré des jeunes qui s’y connaissaient beaucoup.
1er stage école d’ingé : Elle a appris à coder & elle a voyagé.
Elle est parti à Dakar, dans une petite startup qui proposait un impact social. Situation complexe avec perte électricité donc toute personne même novice était la bienvenue. Ce stage était en PHP.
Lorsqu’elle en avait l’opportunité pendant sa scolarité, elle a fait des stages sur le dev.
Elle voulait être développeuse mais elle avait pas trop confiance en ses capacités.
Il y avait moins de développeurs recherchés à l’époque.
Agence web : boite qui vend des projets web et les développeurs prennent part au projet.
Pleins de petits projets ultra régulièrement.
Sa boite proposait des applications Facebook. La boite était à moitié en Inde. Elle voulait entrer en temps que chef de projet pour se diriger vers le développement.
Entretiens très techniques. Elle les a réussi, et elle est parti bosser en Inde. En arrivant elle pensait donc être chef de projet, mais elle est arrivée directement en temps que développeuse.
=> Croyez en vous !!
C’était un peu compliqué pour elle de mener à bien son premier projet, mais ça s’est super bien passé.
Au début elle était en contrat local payé entre 600 et 900 euros par mois. Elle a accepté ça au début parce qu’elle manquait de confiance en elle, et que le mec en face était très charismatique. Ca a duré 6 mois sous ce contrat.
Barrière de la langue, barrière de la vision d’un projet, et problème de communication entre les chef de projets et les développeurs.
Dans la culture indienne, on fait ce que disent les chefs sans poser de questions parce que les chefs savent. C’est également important de satisfaire les autres. Quand quelqu’un te pose une question, même si tu sais pas, tu réponds quand même un truc au pif. Et surtout ne pas trop poser de questions. Ce qui compte le plus c’est la hiérarchie.
Mais Marie a posé des questions ! Et ça a servi à tous, parce que elle a vachement aidé à la communication. Au final elle a fini médiatrice (elle s’est créée un nouveau poste), elle assistait à toutes les réunions pour aider tout le monde à communiquer.
Elle s’est également créé un autre poste, qui consistait à résoudre les bugs que les clients remontaient. Ca lui à très vite appris à rentrer dans une code base, elle a lu le code de pleins de gens, ça lui a également appris à résoudre des bugs super vite, et à identifier et délimiter un bug. => Nouveau poste : Pompier de la prod.
1 an et demi qu’elle est dans la boite. La boite grossi beaucoup. La boite a monté un petit truc de formation, dont elle s’est également occupé. Elle a pas tout fait toute seule, mais elle suivait les nouveaux, et elle s’occupait de leur trouver des spécifications techniques.
Elle leur a préparé tout les mots clés à rechercher, des code review (process de relire le code de quelqu’un : détecter les erreurs, détecter les morceaux de code un peu compliqué, il faut poser des questions, commenter le code, demander à la personne qui à développer de suivre des conventions de code).
2 an et demi dans la boite.
Elle était sous contrat VIE, salaire fixe dans chaque pays, pas d’impôts, sécurité sociale d’expatriée. Valable 2 ans (non renouvelable) dans tout les pays du monde. Vise beaucoup d’ingénieurs, mais il y a aussi des postes de développeurs. En Inde elle était payée 2000€ sans impôts!
A la fin elle a eu un CDI en France payé l’équivalent d’un smic, et le reste était payé en Inde en roupis. Le salaire en Inde était équivalent du VIE.
Elle est devenue consultante technique. C’était la concrétisation de ce qu’elle faisait déjà, mais ça ajoutait des responsabilités.
C’était une très bonne nouvelle, mais elle avait peur de ce nouveau statut.
Fake it until you make it -> vidéo youtube qui explique comment se mettre dans la peau d’un nouveau rôle, avant de se sentir confortable dans ce rôle.

Devenir CTO : tu fais le développeur, mais tu es garant de l’intégrité de toute ta tech. Tu fais de la code review, tu recrutes des gens, tu développes de nouvelles features …
Mais ça fonctionne surtout quand t’es une petite boite, quand tu grossis, tu as besoin de faire évoluer ton infrastructure. Il faut donc plusieurs petits postes.
Le CTO de sa boite a eu besoin de ne plus toucher à la prod. Il en avait marre et il avait trop de trucs à gérer. Son CTO préferait les ordinateurs que les gens, donc il a laissé tomber un côté. Le CTO était donc dispo QUE 1 matinée par mois. Elle a donc débarquée dans un monde complètement nouveau.
=> Plus un truc nous fais peur, plus il faut y allez.
Le CTO est finalement parti faire un tour du monde pendant 1an, l’équipe à eu 1 mois de transition. Le CTO a fait une petite doc avec tout ce qu’il estimait nécessaire, mais c’était pas très fournit et aimait pas trop partager ses infos.
5 ou 6 ans qu’elle est dans cette boite, elle voulait voir autre chose. (C’était y’a 3 ans).

Intrepreneuriat / Entrepreneuriat :
A ce moment là, Facebook a ouvert ses API, et tout les clients voulaient des chatbots.
Ils ont créé une agence dans l’agence, spécialisée dans les chatbots. Elle a fini CTO de l’agence des chatbots, et elle gérait 3 développeurs. Au bout d’un moment elle en avait marre, et ça faisait 3 ans qu’elle faisait des allés retour France/Inde. Elle a essayé de se démarquer dans les chatbots, en faisant un truc qui générait des chatbots.
Au final ils ont décidés de créer carrément une autre boite (pour lever des fonds plus facilement & pour ne pas faire de la concurrence à la boite principale). Les fondateurs de l’agence sont allés voir les business angels de l’agence pour leur demander de l’argent. Ils ont donné 200 000€. En mai 2018 ils ont commencé la boite, ils ont ramenés un développeur indien que Marie avait formé il y a 6 ans. Elle a décidé d’être salarié de cette nouvelle boite, et pas associée. Elle a gardé le même salaire + des BSCPE (ça te donne le droit de demander de l’argent si ton entreprise vaut + qu’avant).
=> Si vous avez des questions sur les avantages des salariés … POSEZ LES ! (Sur slack, en meetup, les gens autour de nous).
=> Ne pas hésitez à demander augmentation avec les bons arguments !

Assistants vocaux

Google Assistant
DialogFlow

C’est quoi pour vous un chatbot ?

  • Outil conversationel
  • Programme qui parle

-> A computer program designed to simulate conversation with human users, especially on internet.
Potenciellement transformation voix en texte,
Comprendre ce qu’on dit (niveau scientifique en pleine expention actuellement).
Ne contient pas nécessairement du machine learning.
Clients s’attendent à ce que le produit mime extremement bien un comportement humain.
Sa boite a déployé un chatbot sur google assistant.

  • vim :
    • :%s/trucàchanger/lechangemant/g = % range = tous le fichier ; s subtitut ; g global pour ne pas faire qu’un changement pas ligne ; cette ligne utilise le regex
    • :e nomDuFichierAOuvrir ouvrir un fichier avec vim en étant déjà dans vim => e pour edit
    • di( ou di) effacer entre ces parenthèses
  • w3c : world wild web consortium : organisme de stadardisation à but non lucratif, chargé de promouvoir la compatibilité des technoligies (HTML, HTML5, XTML …) => « un seul web partout pour tous »
  • `git commit -av : affiche dans vim lors du nommage du commit les différences avec ?le commit d’avant ?
  • ruby : pour pouvoir utiliser les variables dans d’autre class/fichier utiliser : attr_reader; attr_writer; attr_accessor(qui fait les deux) dans la class où est la variable. C’est plus sécuriser que de déclarer une variable globale avec $
  • bash : shutdown now
  • ADA :
    • 1…Nb : de 1 jusqu’à entier Nb
    • fonction : return donc revoie une information
    • procedure : modifie les données pas de return
1 J'aime