Skip to content
Snippets Groups Projects
Commit 854ed794 authored by Hudelot's avatar Hudelot
Browse files

Update tweeter

parent 2c9b338d
No related branches found
No related tags found
No related merge requests found
Images/testcoverage.png

57.5 KiB

Images/testcoveragebis.png

47.8 KiB

Images/testcoverageter.png

52.4 KiB

Images/timeseries.png

41.6 KiB

......@@ -34,7 +34,128 @@ Pour cela, il faut d'abord que vous installiez [`pandas`](https://pandas.pydata.
Si vous ne connaissez pas cette bibliothèque, prenez les 15 min nécessaires pour faire ce [très court tutorial](https://pandas.pydata.org/pandas-docs/stable/10min.html)
Ecrivez maintenant une fonction qui prend en entrée un objet de type `Status`, le type de retour des données renvoyées par `tweepy` et qui construit à partir de cet objet un `dataframe` pandas avec les informations que vous saouhaitez garder.
Ecrivez maintenant une fonction qui prend en entrée un objet de type `Status`, le type de retour des données renvoyées par `tweepy` et qui construit à partir de cet objet un `dataframe` pandas avec les informations que vous souhaitez garder.
Nous allons ici nous familiariser avec l'approche de développement [**TDD (Test Driven Development)**](https://fr.wikipedia.org/wiki/Test_driven_development) qui consiste à spécifier le comportement attendu via un test avant de l’implémenter effectivement. Le principe est donc d'écrire en premier lieu le test et ensuite le code le plus simple possible qui permette au test de passer et donc de satisfaire le comportement spécifié. Le code peut ensuite être amélioré. L'idée est donc de se focaliser sur les fonctionnalités plutôt que sur le code.
Le **TDD (Test Driven Development)** est un développement dirigé par les tests et donc la première ligne de votre programme doit être dans un fichier de tests. Dans notre cas, nous utiliserons le module [`pytest`](https://docs.pytest.org/en/latest/) qu'il faut donc ajouter à votre projet. Le principe du TDD repose sur 3 étapes complémentaires.
+ Première étape (**<span style='color:red'>RED</span>**) : Ecrire un premier test qui échoue.
+ Deuxième étape (**<span style='color:green'>GREEN</span>**) : Ecrire le code le plus simple qui permet de passer le code.
+ Troisième étape (**REFACTOR**) : Améliorer le code source.
Nous allons donc appliquer cette méthode à la fonctionnalité de la création de la grille du jeu 2048.
#### **<span style='color:red'> ETAPE RED</span>**
Notre premier test va consister à tester que lors de sa création, la dataframe pandas possède bien l'ensemble des champs voulus (c'est-à-dire l'ensemble des informations voulues pour l'analyse).
Dans notre cas, supposons que seul le champ `text` nous intéresse et qu'il est stocké dans la colonne 'tweet_textual_content' du dataframe . Alors on pourra écrire un test comme
```PYTHON
from twitter_predictor.twitter_collect import collect
from pytest import *
def test_collect():
tweets = tweet_collect.collect()
data = transform_to_dataframe(tweets)
assert 'tweet_textual_content' in data.columns
```
Ce test vérifie que votre dataframe est bien formé.
Recopier ce code dans un fichier `test_nomdumoduleatester.py`
Ce test doit échouer, puisqu'en l'état actuel du projet, le code pour `transform_to_dataframe` n'existe pas et on a donc l'erreur suivante lors de l'exécution du code <span style='color:red'>`ImportError: cannot import name 'transform_to_dataframe'`<span>
#### **<span style='color:green'> ETAPE GREEN</span>**
On va maintenant écrire le code qui permet de faire passer ce test le plus rapidement au vert.
Ecrivez ce code et re-tester.
#### **<span style='color:black'> ETAPE REFACTOR</span>**
La dernière étape consiste en une étape de [refactoring](https://refactoring.com/), à mettre en place si nécessaire.
Le [refactoring](https://en.wikipedia.org/wiki/Code_refactoring)(ou réusinage de code) est un principe de programmation qui consiste à changer la structure interne d’un logiciel sans en changer son comportement observable. C'est une étape qui doit toujours être exécutée quand les différents tests sont au vert et qui n'est pas obligatoire. Elle doit surtout permettre d'améliorer la **qualité du code** par exemple en améliorant :
+ **la conception** : decoupage en fonctions, modules ou classes afin de rendre votre code le plus simple possible.
+ **la lisibilité du code** : il faut ici prendre le temps d'appliquer les principes du [clean code](https://cleancoders.com/cart) introduit par Robert C. Martin dans l'ouvrage du même nom et dont un des principe est celui des boy-scouts (*« The Boy Scout Rule »*): *« Toujours laisser un endroit dans un état meilleur que celui où vous l’avez trouvé »*.
Dans notre cas, une des premiers principes est de vérifier du bon nommage (variables, fonctions, packages, classes et cie) et de la présence de commentaires dans notre code.
Vous trouverez [ici](https://github.com/zedr/clean-code-python#objects-and-data-structures) quelques principes du clean code transposé au langage python. Prenez le temps de lire rapidement ce site et appliquer ces différents principes au code que vous allez écrire.
Dans cette étape **<span style='color:black'> ETAPE REFACTOR</span>**, on peut aussi travailler à l'optimisation des performances du programme si cela s'avère vraiment nécessaire.
#### **ATTENTION**
1. **Après cette étape, n'oubliez pas de relancer les tests pour vérifier que le comportement de votre code n'a pas changé et que tout est encore bien AU VERT !**
2. On vient ici de terminer la réalisation de l'étape *Création d'un dataframe `pandas` avec l'information utile* et il convient donc de **committer ce changement dans votre gestionnaire de version avec un message de commit explicite reprenant l'objectif de l'étape**. Pensez aussi à mettre à jour votre dépôt distant.
#### **A VOUS de JOUER!**
On vous maintenant permettre la création d'un dataframe pandas avec uniquement les informations utiles. à partir d'un fichier json.
Ecrivez le code correspondant à cette tâche et tester le (ou alors appliquer à nouveau l'approche TDD pour cela).
## A propos de la couverture de code par vos tests
Une couverture de code par les tests (code coverage) nous permet de connaître le pourcentage de notre code qui est testé et donc cela permet d'avoir une idée de ce qui reste d'ombre dans notre projet.
En règle générale, on considère qu'une couverture de code supérieure à 80% est signe d'un projet bien testé et auquel il sera alors plus facile de rajouter de nouvelles fonctionnalités.
Pour connaitre le taux de couverture de notre projet, nous pouvons utiliser des bibliothèques python [`coverage`](https://coverage.readthedocs.io/en/v4.5.x/) et [`pytest_cov`](https://pypi.org/project/pytest-cov/) qu'il faut donc installer soit en ligne de commande soit depuis votre IDE.
`pip3 install coverage`
`pip3 install pytest-cov`
Il faut ensuite vous placer dans le répertoire de votre projet et lancer la commande suivante :
`pytest --cov=tweet_collection --cov-report html test_*.py`
Cette commande permet de tester les fichiers contenus dans le dossier 'tweet_collection', crée un rapport en html et le place dans le répertoire `htmlcov` et utilise les tests qui sont dans ce répertoire et qui sont de la forme `test_[caracteres].py`.
L'ouverture du fichier `index.html`dans le répertoire `htmlcov`vous permet de visualiser un bilan du test de couverture qui devrait être bon dans la mesure où nous avons utilisé l'approche TDD. Un clic sur chacun des fichiers permet aussi d'avoir un bilan propre à chaque fichier.
![testcoverage](./Images/testcoverage.png)
La visualisation du fichier `index.html` généré.
![testcoverage](./Images/testcoverageter.png)
Le détail pour chaque module.
![testcoverage](./Images/testcoveragebis.png)
## A propos de la gestion des versions
<span style='color:blue'> Pour toute la suite du projet, il vous est demandé de :</span>
+ <span style='color:blue'>Faire un commit dès que la réalisation d'une fonctionnalité ou d'une sous-fonctionnalité est finie.</span>
+ <span style='color:blue'>Tagger à la fin de chaque journée votre dernier commit </span>
+ <span style='color:blue'>Pousser (Push) votre code vers votre dépôt distant sur GitLab.</span>
+ <span style='color:blue'>Faire un test de couverture de code à la fin de chaque journée et de pousser le bilan obtenu vers votre dépôt distant sur GitLab.</span>
Nous avons maintenant terminé le Sprint 1 et nous pouvons passer à la [**Fonctionnalité 5** : Quelques informations statistiques.](./S2_Pretraitement.md)
......
# Fonctionnalité 5 - Quelques informations statistiques
L'objectif ici est de tirer parti des dataframes pandas pour faire des premières analyses statistiques et obtenir des premières informations sur les tweets collectés.
Ici, il peut être nécessaire de refaire une étape de conception avec l'ensemble de parties prenantes pour être certains d'extraire les bonnes informations.
Supposons que dans l'étape précédente, nous ayons récupéré nos tweets sous la forme d'un dataframe comme ci-dessous :
```
tweet_textual_content len ... Likes RTs
0 RT @EmmanuelMacron: Old demons are rising agai... 140 ... 0 4233
1 @1tortuerouge @EmmanuelMacron D’accord. 39 ... 0 0
2 RT @lesRepublicains: 🌱 « C'est de l'écologie, ... 140 ... 0 34
3 RT @LivelyLoyce: #IGF2018 Hate speech and onl... 140 ... 0 6
4 RT @LydiaGuirous: Erdogan n’a pas sa place à l... 140 ... 0 1103
5 RT @FLOTUS: Thank you @EmmanuelMacron and Mrs.... 140 ... 0 4989
6 @Europe1 Rien ne sert de recruter s'ils se don... 140 ... 0 0
7 @JustinTrudeau @EmmanuelMacron Thank you for c... 144 ... 0 0
8 RT @jtmetrop: @EmmanuelMacron ne sent pas la c... 96 ... 0 1
9 RT @SecPompeo: It is a humble honor to join @P... 139 ... 0 2681
```
On a donc les colonnes `tweet_textual_content`, `len`, `ID`, ..., `Likes` et `RTS`.
On peut par exemple, extraire le tweet qui a le plus de mention de `retweet` de la manière suivante :
```PYTHON
rt_max = np.max(data['RTs'])
rt = data[data.RTs == rt_max].index[0]
# Max RTs:
print("The tweet with more retweets is: \n{}".format(data['tweet_textual_content'][rt]))
print("Number of retweets: {}".format(rt_max))
print("{} characters.\n".format(data['len'][rt]))
```
Ce qui donne dans mon cas ici :
```
The tweet with more retweets is:
RT @EmmanuelMacron: Patriotism is the exact opposite of nationalism. Nationalism is a betrayal of patriotism. By putting our own interests…
Number of retweets: 72043
139 characters.
```
Placer vous ou créer un package `tweet_analysis` à votre projet et concever et programmer un ensemble de fonctions permettant d'extraire des informations pertinentes d'un ensemble de tweets.
## A Faire
+ <span style='color:blue'>Faire un commit dès que la réalisation de la fonctionnalité ou d'une sous-fonctionnalité est finie.</span>
+ <span style='color:blue'>Pousser (Push) votre code vers votre dépôt distant sur GitLab.</span>
Nous pouvons maintenant passer à la fonctionnalité [**Fonctionnalité 6** : Visualisation de l'évolution d'une caractéristique.](./S2_TweetTimeSeries.md)
# Fonctionnalité 6 : Visualisation de l'évolution d'une caractéristique.
Les tweets sont diffusés en continu et il peut être intéressant de regarder leur évolution temporelle.
Là aussi, on peut tirer parti de la bibliothèque `pandas` qui a un moyen de construire des séries temporelles.
Par exemple, si nous voulons comparer sur une période donnée l'évolution du nombre de `retweets` versus le nombre de `Like`, nous pouvons le faire comme ci-dessous.
```
tfav = pd.Series(data=data['Likes'].values, index=data['Date'])
tret = pd.Series(data=data['RTs'].values, index=data['Date'])
# Likes vs retweets visualization:
tfav.plot(figsize=(16,4), label="Likes", legend=True)
tret.plot(figsize=(16,4), label="Retweets", legend=True)
plt.show()
```
Ce qui donne
![TimeSeries](./Images/timeseries.png)
## A vous de jouer !
Ajouter des fonctions permettant de visualiser l'évolution de caractéristiques d'intérêt dans votre corpus de tweets.
**Pensez à tester et à documenter votre code !!!**
Cette étape terminera votre fonctionnalité mais aussi le Sprint courant.
Il faudra donc :
+ <span style='color:blue'>Faire un commit.</span>
+ <span style='color:blue'>Tagger votre dernier commit </span>
+ <span style='color:blue'>Pousser (Push) votre code vers votre dépôt distant sur GitLab.</span>
+ <span style='color:blue'>Faire un test de couverture de code et pousser le bilan obtenu vers votre dépôt distant sur GitLab.</span>
Nous pouvons maintenant passer à l'analyse d'opinions avec [**Fonctionnalité 8** : Prise en main de Textblob](./S3_textblob.md).
# Fonctionnalité 9 : Prise en compte de l'opinion
A l'aide de Textblob, écrivez le code nécessaire à l'analyse de l'opinion pour un candidat donné. Votre code devrait vous permettre de pouvoir mettre en oeuvre ce type d'instructions :
```PYTHON
print("Percentage of positive tweets: {}%".format(len(pos_tweets)*100/len(data['tweet_textual_content'])))
print("Percentage of neutral tweets: {}%".format(len(neu_tweets)*100/len(data['tweet_textual_content'])))
print("Percentage de negative tweets: {}%".format(len(neg_tweets)*100/len(data['tweet_textual_content'])))
```
**Pensez à tester et à documenter votre code !!!**
ET :
+ <span style='color:blue'>Faire un commit.</span>
+ <span style='color:blue'>Pousser (Push) votre code vers votre dépôt distant sur GitLab.</span>
Et nous arrivons à la fin de notre MVP la [**Fonctionnalité 10** : Afficher le résultat de l'analyse.](./S4_displayresult.md)
\ No newline at end of file
# Fonctionnalité 8 : Prise en main de Textblob
[Textblob](https://textblob.readthedocs.io/en/dev/quickstart.html) est une bibliothèque python qui permet de faire de l'analyse de textes et de l'analyse de sentiments très rapidement.
Pour commencer, il faut l'installer et la rattacher à votre projet
`pip3 install textblob`
Puis, regardez et faites [son tutorial](https://textblob.readthedocs.io/en/dev/quickstart.html).
Pour vous entrainez avec cette bibliothèque, écrivez une fonction qui permet d'extraire le vocabulaire d'un ensemble de tweets en récupérant les mots uniques et lemmatisés. On pourra aussi supprimer de la liste obtenue les mots fréquents ou `stop-words`.
**Pensez à tester et à documenter votre code !!!**
Cette étape terminera votre fonctionnalité .
Il faudra donc :
+ <span style='color:blue'>Faire un commit.</span>
+ <span style='color:blue'>Pousser (Push) votre code vers votre dépôt distant sur GitLab.</span>
Et nous arrivons à la fin de notre MVP avec notre avant dernière fonctionnalité : [**Fonctionnalité 9** : Prise en compte de l'opinion](./S3_opinion.md)
\ No newline at end of file
# Fonctionnalité 10: Afficher le résultat de l'analyse
Il s'agit ici de visualiser le résultat de notre analyse de manière visuelle. Pour cela, nous utiliserons la bibliothèque [`seaborn`](https://seaborn.pydata.org/examples/index.html) qui possède de nombreux outils et méthodes de visualisation.
Vous pouvez notamment faire un tour dans sa [galerie](https://seaborn.pydata.org/examples/index.html).
Prenez en main cette bibliothèque et créer différentes visualisations à partir de votre collecte de tweets et de son analyse.
Avant de finir :
+ <span style='color:blue'>Faire un commit.</span>
+ <span style='color:blue'>Tagger votre dernier commit </span>
+ <span style='color:blue'>Pousser (Push) votre code vers votre dépôt distant sur GitLab.</span>
+ <span style='color:blue'>Faire un test de couverture de code et pousser le bilan obtenu vers votre dépôt distant sur GitLab.</span>
Nous avons maintenant notre MVP. Prenez le temps de faire un bilan, d'en discuter et proposer comment l'améliorer. Vous pouvez par exemple mettre un fichier `TO_DO.md` dans votre dépôt `git` listant les différentes fonctionnalités voulues..
Nous pouvons maintenant passer à l'[objectif 2](./TemplateProject_Twitter.md).
......@@ -17,6 +17,21 @@ Si ce n'est pas déjà fait, [créer un projet Pycharm](./pycharm.md) que vous a
Comme vous devrez apprendre à le faire de manière systématique pour tout travail de développement informatique à plusieurs, vous devez passer le projet **`twitterPredictor`** sous Git.
Pour commencer, et pour comprendre git, faites le rapide tutorial disponible [ici](http://rogerdudler.github.io/git-guide/index.fr.html).
D'autres tutoriaux très bien:
+ [http://marklodato.github.io/visual-git-guide/index-en.html](http://marklodato.github.io/visual-git-guide/index-en.html)
+ [https://openclassrooms.com/fr/courses/1233741-gerez-vos-codes-source-avec-git](https://openclassrooms.com/fr/courses/1233741-gerez-vos-codes-source-avec-git)
+ ...
Ensuite nous allons mettre en place un dépôt git pour notre projet.
+ Depuis Pycharm, vous pouvez le faire depuis le menu **(`VCS | Enable Version Control Integration`)**.
+ Faire un premier `commit`contenant le fichier `__init__.py`
+ Créer un dépôt **`twitterPredictor`** sur GitLab qui vous servira de **depôt distant**.
......@@ -45,7 +60,28 @@ Vous allez maintenant ajouter votre binôme et votre enseignant comme collaborat
## Déposer sur GitLab
Il vous sera demandé plusieurs fois le long du projet et des séances de pousser votre code sur le dépôt distant. Pour ceux d'entre vous qui débutent, on se contentera de suivre un workflow classique sans branches, avec des `commit` sur la branche principale `master`chaque fois que cela vous est demandé et systématiquement en fin de séance. Pour ceux d'entre vous qui sont déjà très familiarisés avec git, vous pourrez adopter la démarche plus classique consistant à développer une branche par fonctionnalité et à fusionner ensuite dans la branche `master`.
Il vous sera demandé plusieurs fois le long du projet et des séances de pousser votre code sur le dépôt distant.
Pour ceux d'entre vous qui débutent, il serait plus facile de se contenter au début de suivre un workflow classique sans branches, avec des `commit` sur la branche principale `master`chaque fois que cela vous est demandé et systématiquement en fin de séance. Pour ceux d'entre vous qui sont déjà très familiarisés avec git, vous savez que la démarche plus classique consiste à développer une branche par fonctionnalité et à fusionner ensuite dans la branche `master`.
Nous allons procéder comme suit pour le projet :
+ Vous aurez un dépôt distant commun pour le binôme.
+ Chaque membre du binôme construira une branche qui lui sera proche.
```
git checkout -b projet_membre_x
git push origin projet_membre_x
```
+ A chaque fois que vous terminerez une fonctionnalité, vous procederez alors à un `merge request` avec la commande
`git merge <branch>`
+ Il vous faudra donc pour ne pas avoir trop de problèmes sur cette opération, vous mettre d'accord sur votre code (en faisant une sorte de cycle de [pair programming](pair programming))
Vous pouvez maintenant continuez par le [Sprint 0 : Analyse du problème](./Sprint0Analyse.md).
\ No newline at end of file
......@@ -33,10 +33,9 @@ Ce concept de MVP a été introduit par Eric Ries, l'auteur de [The Lean Startup
+ [**Fonctionnalité 3** : Collecter des tweets relatifs à une élection.](./S1_twittercollectquery.md)
+ [**Fonctionnalité 4** : Stocker les tweets.](./S1_twitterstorage.md)
+ **Sprint 2** : **Représentation et analyse des tweets**
+ [**Fonctionnalité 5** : Pré-traiter le texte des tweets pour ne garder que l'information utile.](./S2_Pretraitement.md)
+ [**Fonctionnalité 6** : Représentation du contenu textuel des tweets.](./S2_TweetRepresentation.md)
+ [**Fonctionnalité 7** : Associer un tweet à un candidat.](./S2_TweetAnalysis.md)
+ **Sprint 2** : **Traitement et Analyse des tweets**
+ [**Fonctionnalité 5** : Quelques informations statistiques.](./S2_Pretraitement.md)
+ [**Fonctionnalité 6** : Visualisation de l'évolution d'une caractéristique.](./S2_TweetTimeSeries.md)
+ **Sprint 3** : **Ajout de l'analyse de l'opinion avec [Textblob](https://textblob.readthedocs.io/en/dev/)**
+ [**Fonctionnalité 8** : Prise en main de Textblob](./S3_textblob.md)
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment