fast

projet/resources/playbooks/fao-geneve.yml

 clients: # The default management port for a client is 18965
   - "127.0.0.1"
-  - "129.194.187.130"
+  - "129.194.187.130" # Comment me for 1M1T
 
 chapters:
   FAO Geneve:

rapport/my.bib

@@ -72,9 +72,9 @@ In its fifth year, Data Never Sleeps shows exactly how much data is created ever
 
 @online{noauthor_usage_nodate,
   title = {Usage {{Statistics}} of {{JavaScript}} as {{Client}}-Side {{Programming Language}} on {{Websites}}, {{March}} 2020},
-  url = {https://w3techs.com/technologies/details/cp-javascript},
+  url = {https://w3techs.com/technologies/details/cp-JavaScript},
   urldate = {2020-03-17},
-  file = {/Users/theo.pirkl/Zotero/storage/UQPJXR2I/cp-javascript.html}
+  file = {/Users/theo.pirkl/Zotero/storage/UQPJXR2I/cp-JavaScript.html}
 }
 
 @online{noi_workers_nodate,

rapport/text/1-references.md

@@ -6,7 +6,7 @@
 
 #### Référence des URL {-}
 
-La plupart des illustrations venant de moi, j'ai mis leur emplacement dans ce projet.
+La plupart des illustrations venant de moi, j'ai mis leur emplacement dans ce projet. Elles sont aussi disponibles [sur le git de l'HEPIA](https://githepia.hesge.ch/theopirkl/bachelor-scrapper-058/tree/master/rapport/figs).
 \begin{tabular}{ p{3cm} p{9cm}  }
     \multicolumn{1}{l}{URL01} & \multicolumn{1}{l}{\url{https://www.domo.com/learn/data-never-sleeps-5}}\\
     \multicolumn{1}{l}{URL02} & \multicolumn{1}{l}{\url{https://anti-captcha.com/}} \\

rapport/text/2-introduction.md

@@ -7,6 +7,6 @@ L'Homme étant enclin à faire des erreurs, une solution humaine ne convient pas
 
 L'objectif de ce travail est donc de proposer un logiciel, que l'on nommera NScrap, étant capable de télécharger des données en masse, suffisamment flexible pour qu'il soit compatible avec la très grande majorités des sites web. Il devra proposer d'une façon ou l'autre un système suffisamment simple pour permettre à un utilisateur lambda de s'en servir. Pour faire un tel logiciel, il est nécessaire de s'inspirer des solutions existantes sur Internet aujourd'hui. Une fois ces dernières présentées, il sera question d'implémenter NScrap en se basant sur la liste des technologies des autres logiciels. Une fois le logiciel conçu, il sera question de mesurer son efficacité et de la comparer avec d'autres logiciels du même genre.
 
-Nous allons donc suivre le cheminement suivant : commencer par l'analyse des solutions actuelles en passant par les techniques employées, s'inspirer de ses dernières pour implémenter le logiciel dont la structure et le fonctionnement seront présentés; enfin, on mesurera l'efficacité de NScrap sur deux sites web bien différents, de façon à se donner une idée de sa performance. On la comparera avec celles théoriques d'un humain et celles d'autres logiciels, pour enfin conclure ce projet en tentant de déterminer si les objectifs que nous avons fixés sont remplis.
+Nous allons donc suivre le cheminement suivant : commencer par l'analyse des solutions actuelles en passant par les techniques employées, s'inspirer de ses dernières pour implémenter le logiciel dont la structure et le fonctionnement seront présentés; enfin, on mesurera l'efficacité de NScrap sur deux sites web bien différents, de façon à se donner une idée de sa performance. On la comparera avec celles théoriques d'un humain et celles d'autres logiciels, pour enfin conclure ce projet en tentant de déterminer si les objectifs que nous avons fixés sont remplis. L'intégralité du code, des mesures et des fichiers de configurations sont disponibles en public [sur le serveur git de l'HEPIA](https://githepia.hesge.ch/theopirkl/bachelor-scrapper-058).
 
 \pagebreak
\ No newline at end of file

rapport/text/3-etude.md

@@ -8,7 +8,7 @@ Faciliter la récupération de données est particulièrement important; Forbes
 de données par jour [@marr_how_nodate]. Cette quantité de données est affolante et il est très facile de se noyer dedans et de perdre de l'information.
 Pour se donner une idée, l'entreprise Nandex affirme qu'un employé perd 2.5 heures par jour à chercher des documents [@noi_workers_nodate].
 La récupération en masse de données est une solution permettant de diminuer la surface de recherche. En récupérant les documents en masse d'un site,
-on élimine déjà une quantité de documents inutile tout à fait considérable, ce qui permettrait de réduire ces deux heures et demi de perdus chaque jour.
+on élimine déjà une quantité de documents inutile tout à fait considérable, ce qui permettrait de réduire ces deux heures et demi de perdu chaque jour.
 
 On dénombre aujourd'hui plusieurs possibilités de récupérer une quantité importante de documents; il n'existe en outre aucun standard
 pour ces besoins. Chaque site web, application ou service propose le téléchargement de documents d'une façon différente.
@@ -28,12 +28,12 @@ pour l'ordinateur.
 
 Malheureusement, les (+API_a)s sont rares : beaucoup de sites n'en ont pas. Dans le cas où elles en proposent,
 elles sont souvent payantes ou accessibles sur permission uniquement. Une (+API_a) représente dans la majorité des cas une fonctionnalité
-supplémentaire au site, ce qui augmentes les coûts d'exploitation pour le propriétaire du site.
+supplémentaire au site, ce qui augmente les coûts d'exploitation pour le propriétaire du site.
 
 Sans (+API_a), une seule source de données est accessible: le site web lui-même. Dans ce cas, la récupération de documents doit être faite soit
 par un utilisateur de façon régulière, soit par une machine. C'est naturellement la seconde option que nous allons étudier ici.
 
-Il y a un manque de logiciel de scraping existant sur le marché aujourd'hui. Très peu de solutions proposent de télécharger des documents
+Il y a un manque de logiciel de scraping (c'est-à-dire la récupération automatisée de documents) existant sur le marché aujourd'hui. Très peu de solutions proposent de télécharger des documents
 en masse pour un site précis et il y en a encore moins permettant de télécharger des documents sur n'importe quel site. Deux types de services
 existent actuellement sur le marché : les solutions payantes en ligne, de type (+SAAS_a) et les solutions de type framework[^4].
 
@@ -62,7 +62,7 @@ Les (+SAAS_a) étant pour la plupart situés sur un ordinateur externe, il est e
 
 Dans les deux cas, il est nécessaire de prendre du temps pour comprendre comment le logiciel fonctionne. Un coût d'application a tendance à diminuer
 la courbe d'apprentissage, mais réduira la fenêtre d'action possible; un prix nul et la courbe sera plus forte mais cela permettra de faire plus
-une fois les difficultés passées. Un exemple intéressant pourrait être un site web complexe, il serait beaucoup plus facile de gérer cela nous-mêmes
+une fois les difficultés passées. Un exemple intéressant pourrait être un site web complexe, (possédant de nombreux menus, fonctionnant avec du JavaScript, etc), il serait beaucoup plus facile de gérer cela nous-mêmes
 en entier que via des fonctionnalités pré-pensées.
 
 Au vu de cette comparaison, il n'y a pas de solution meilleure qu'une autre. Les deux sont viables et utilisables, dépendamment de qui nous sommes et du site que nous essayons de traiter.
@@ -90,7 +90,7 @@ A l'inverse d'un framework, l'utilisation d'un service tiers pose donc une quest
 conçu par un tiers fonctionne. Dès lors, on ignore s'il y a utilisation de plateformes telles que celles citées plus haut.
 
 L'utilisation d'un framework n'évite naturellement pas d'éviter d'être amoral. Toutefois, avoir un contrôle total du comportement de
-l'application permet d'éviter l'utilisation accidentelle une plateforme exploitant des êtres humains.
+l'application permet d'éviter l'utilisation accidentelle d'une plateforme exploitant des êtres humains.
 
 [^6]: Les travailleurs de cette plateforme.
 [^7]: Un système permettant de différencier une machine d'un humain en demandant par exemple de faire une addition ou lire du texte
@@ -128,7 +128,7 @@ La très grande majorité des systèmes utilisent XPath car il permet de se rend
 
 ### Navigateur
 
-Pour scraper un site, il faut un navigateur permettant d'aller d'une page à une autre. Les différentes solutions utilisées n'utilisent pas tous le même navigateur, mais la méthode utilisée semble être relativement la même : le navigateur démarré est contrôlé par le système l'ayant démarré. De cette façon, ce n'est pas un humain qui doit cliquer sur les éléments du navigateur mais des instructions envoyées par le programme. De cette façon, un utilisateur et un scraper sont difficilement distinguables, les deux utilisant le même point d'accès pour se connecter à un site web.
+Pour scraper un site, il faut un navigateur permettant d'aller d'une page à une autre. Les différentes solutions utilisées n'utilisent pas tous le même navigateur, mais la méthode utilisée semble être relativement la même : le navigateur démarré est contrôlé par le système l'ayant démarré. De cette façon, ce n'est pas un humain qui contrôle sur quoi cliquer mais des instructions envoyées par le programme. Avec une telle méthode, un utilisateur et un scraper sont difficilement distinguables, les deux utilisant le même point d'entrée pour se connecter à un site web.
 
 ### Accélération
 

rapport/text/5-mesures.md

@@ -15,11 +15,11 @@ L'ensemble des mesures de ce projet sont disponibles dans le dossier `projet/res
 
 Nous allons nous intéresser au lancement de la récupération de $1000$ documents sur la FAO Genève. La configuration de NScrap sera faite de trois façons différentes :
 
-* Une machine, un travailleur (ce scénario sera abrégé 1M1T, pour une Machine une  Travailleur)
+* Une machine, un travailleur (ce scénario sera abrégé 1M1T, pour Une Machine Un Travailleur)
 * Une machine, six travailleurs (ce scénario sera abrégé 1M6T)
-* Deux machines, six travailleurs chacune (ce scénario sera abrégé 2M6T)
+* Deux machines, six travailleurs chacune (ce scénario sera abrégé 2M6T, où chaque machine a six travailleurs)
 
-On utilise le _playbook_ présenté dans le fichier `projet/resources/playbooks/fao-geneve.yml`. Nous utilisons six coeurs : en effet, la majorité des machines aujourd'hui ont huit coeurs présents dans leur processeur. Utiliser six coeurs permet d'éviter de surcharger la machine (et donc de potentiellement ralentir le système).
+On utilise le _playbook_ présenté dans le fichier `projet/resources/playbooks/fao-geneve.yml` mis en annexe. Nous utilisons six coeurs : en effet, la majorité des machines aujourd'hui ont huit coeurs présents dans leur processeur. Utiliser six coeurs permet d'éviter de surcharger la machine (et donc de potentiellement ralentir le système).
 
 ### Théorie
 
@@ -52,12 +52,12 @@ Nous obtenons trois graphiques, soit un par scénario :
   \caption*{Source : réalisé par Théo Pirkl}
 \end{figure}
 
-Comme nous pouvons le constater, nous avons largement dépassé la vitesse théorique d'un humain. En prenant le cas du premier graphique (c'est-à-dire le scénario 1M1T), on peut observer sur la courbe croissant le moins vite qu'on atteint une vitesse de traitement de données de 1.84 documents par seconde, soit une vitesse d'environ 110 documents par minutes, soit deux fois plus vite qu'un être humain.
+Comme nous pouvons le constater, nous avons largement dépassé la vitesse théorique d'un humain. En prenant le cas du premier graphique (c'est-à-dire le scénario 1M1T), on peut observer sur la courbe croissant le moins vite qu'on atteint une vitesse de traitement de données de 1.84 documents par seconde, soit une vitesse d'environ 110 documents par minute, soit deux fois plus vite qu'un être humain.
 Les temps moyens sont :
 
 * Dans le premier scénario on obtient comme temps $542$, $534$, $496$ et $398$ secondes, pour un temps moyen de $492.5$ secondes;
 * Dans le second, les temps sont de $271$, $181$, $212$ et $258$ secondes, donnant en moyenne $230.5$ secondes;
-* Le dernier scénario a des mesures de temps les plus petites, de $71$, $46$, $54$ et $52$ secondes, pour un temps moyen de $55.75$ secondes.
+* Le dernier scénario a les plus petites mesures de temps, de $71$, $46$, $54$ et $52$ secondes, pour un temps moyen de $55.75$ secondes.
 Au vu des temps obtenus, il est évident que le scénario la plus efficace est le 2M6T.
 
 On peut se donner une idée plus concrète de performance en convertissant les scores en pourcentage de performance. On prend le score moyen du scénario 1M1T comme base, et on divise ce score par les autres scores moyens obtenus, ce qui nous donnera un pourcentage de performance. Ce pourcentage sera par rapport à la performance du premier scénario. Cela donne :
@@ -78,7 +78,7 @@ Ces constats se basent sur les mesures faites et présentées plus haut : il est
 Au vu de ce qui a été dit plus haut, nous pouvons répondre aux questions que nous avons posé de cette façon :
 
 * L'automatisation du téléchargement des documents, dans le cas de la FAO Genève, est significativement plus rapide que le téléchargement des documents un à un;
-* La distribution des tâches de téléchargement rend ce qui était déjà rapide encore plus rapide avec un gain, comme nous l'avons observé, de $883\%$.
+* La distribution des tâches de téléchargement rend ce qui était déjà rapide encore plus rapide avec un gain, comme nous l'avons observé, allant jusqu'à $883\%$.
 
 Le scraping semble donc extrêmement utile dans le cas de la FAO.
 
@@ -87,7 +87,7 @@ Le scraping semble donc extrêmement utile dans le cas de la FAO.
 Nous allons maintenant analyser le module Swiss-Impex. Ce module est plus intéressant à étudier que la FAO Genève : en effet, Swiss-Impex est un scrapper de catégorie deux. Ces modules sont plus complets et complexes que ceux de première catégorie. La récupération des données prendra bien plus de temps que la FAO Genève.
 Dans le cas d'une analyse Swiss-Impex réduite, on ne s'intéresse qu'à une seule catégorie de marchandises. Dans ce cas, on s'intéressera à la catégorie *2709.0090*, ce qui correspond aux données pétrolières Suisses.
 
-On utilise le _playbook_ présenté dans le fichier `projet/resources/playbooks/swiss-impex-petroleum.yml`.
+On utilise le _playbook_ présenté dans le fichier `projet/resources/playbooks/swiss-impex-petroleum.yml`, mis comme première annexe.
 
 ### Théorie
 
@@ -95,17 +95,17 @@ Swiss-Impex propose un rapport d'import/export par mois depuis 1988 jusqu'à 201
 On peut donc calculer le nombre de documents à $12 * (2019 - 1989) = 360$.
 
 En admettant que chaque document prend une minute pour être téléchargé par un humain. Avec une seule machine ayant six workers, cela prendrait donc une heure. Pour réduire au plus ce temps, nous allons utiliser vingt machines. Chacune de ces machines aura un travailleur. Nous aurons donc un total de 20 travailleurs capables d'effectuer des tâches simultanément. Nous choisissons de ne pas mettre trop de travailleurs : en effet, trop de travailleurs déclenchent un déni de service accidentel sur le site, le rendant inopérant temporairement.
-Nous passons donc de une heure à dix-huit minutes théoriques.
+Nous passons donc de une heure à 18 minutes théoriques.
 
 ### Mesures
 
-Après envoi de la commande aux clients, on pourrait observer toutes les quinze secondes[^17] le nombre de documents téléchargés (le total calculé sur toutes les machines). Toutefois, compte tenu de nombre de clients, nous allons plutôt observer le nombre d'entrées dans la base de données centrale. En effet, chaque document à traiter correspond à une entrée dans la base de données. Cela ne changera rien à nos mesures. Le graphique sera toutefois inversé : plutôt que de commencer à 0 documents téléchargés, on commencera à 360 documents en attente de téléchargement. La courbe ne croîtra donc pas mais descendra progressivement jusqu'à 0. Toutefois, cela ne nous empêche pas de calculer le pourcentage de gain d'efficacité.
+Après envoi de la commande aux clients, on pourrait observer toutes les 15 secondes[^17] le nombre de documents téléchargés (le total calculé sur toutes les machines). Toutefois, compte tenu de nombre de clients, nous allons plutôt observer le nombre d'entrées dans la base de données centrale. En effet, chaque document à traiter correspond à une entrée dans la base de données. Cela ne changera rien à nos mesures. Le graphique sera toutefois inversé : plutôt que de commencer à 0 documents téléchargés, on commencera à 360 documents en attente de téléchargement. La courbe ne croîtra donc pas mais descendra progressivement jusqu'à 0. Toutefois, cela ne nous empêche pas de calculer le pourcentage de gain d'efficacité.
 
-[^17]: Observer plus rapidement que toutes les quinze secondes saturerait le protocole de communication : les mesures arriveraient tardivement et seraient décalées à la réalité. Nos mesures seraient alors biaisées.
+[^17]: Observer plus rapidement que toutes les 15 secondes saturerait le protocole de communication : les mesures arriveraient tardivement et seraient décalées à la réalité. Nos mesures seraient alors biaisées.
 
 ### Résultats
 
-Comme nous l'avons indiqué plus haut, les scrappers sont très sensibles aux changements de site. Si l'éditeur proposant le site n'a pas d'accord avec l'entité scrappant son site, elle peut du jour au lendemain mettre à jour son site et donc potentiellement rendre le scrapper inutile. C'est ce qui est arrivé dans notre cas : au moment de la mesure, Swiss Impex avait changé des informations permettant au moteur javascript de se repérer sur la page. Le scraper Swiss-Impex est alors devenu "aveugle" et ne pouvait plus traiter les documents proprement. La structure, l'apparence ou la logique interne du site n'avaient manifestement pas été changées : seuls les éléments permettant au scrapper de se repérer avaient été changés.
+Comme nous l'avons indiqué plus haut, les scrappers sont très sensibles aux changements de site. Si l'éditeur proposant le site n'a pas d'accord avec l'entité scrappant son site, elle peut du jour au lendemain mettre à jour son site et donc potentiellement rendre le scrapper inutile. C'est ce qui est arrivé dans notre cas : au moment de la mesure, Swiss-Impex avait changé des informations permettant au moteur JavaScript de se repérer sur la page. Le scraper Swiss-Impex est alors devenu "aveugle" et ne pouvait plus traiter les documents proprement. La structure, l'apparence ou la logique interne du site n'avaient manifestement pas été changées : seuls les éléments permettant au scrapper de se repérer avaient été changés.
 Toujours au moment de la mesure, il était trop tard pour mettre à jour le scrapper convenablement : il a donc été laissé en l'état.
 Des informations intéressantes ont toutefois pu être récoltées : il est nécessaire de limiter volontairement le nombre de travailleurs agissant en même temps sur un site, sans quoi l'on peut se retrouver banni. C'est ce qui arrivé : les ordinateurs de l'HEPIA n'ont pas été bannis, pourtant c'est eux qui ont généré le plus gros volume de données. Quant à l'ordinateur sur lequel ce projet a été conçu, il a été banni relativement rapidement (à ce jour, il n'a pas totalement été débanni). Cela laisse à penser que Swiss-Impex autorise toutes les adresses IPs étatiques à télécharger autant qu'elles le souhaitent. Enfin, au vu de l'échec de la récupération des données, de la difficulté à faire fonctionner proprement le scraper et des changements, il est possible que Swiss-Impex tente activement de bloquer les scrapers. Aucune preuve concrète n'est disponible, toutefois sur l'expérience de ce travail de semestre, cela reste une possibilité.
 

rapport/text/7-annexes.md

@@ -38,4 +38,15 @@ chapters:
                   - cleanup: yes
 ```
 
+\newappendix{Fichier fao-geneve.yml}
+```yaml
+clients: # The default management port for a client is 18965
+  - "127.0.0.1"
+  - "129.194.187.130" # Comment me for 1M1T
+
+chapters:
+  FAO Geneve:
+    pages: {start: 0, end: 100} # From 0 to 100 included
+```
+
 \pagebreak
\ No newline at end of file