Les recettes du prof: Au-delà d’IFTTT

J’aime beaucoup le service IFTTT (IF This Then That). Il permet de créer ce qu’ils appellent des «recettes» qui sont autant de façons d’automatiser des tâches avec d’autres services web comme Twitter, Facebook, Instagram, Gmail et plusieurs autres. L’an dernier, par exemple, je me suis créé une recette qui me prévient par courriel des conférences de presse à l’Assemblée nationale.

Un collègue me demandait récemment s’il était possible d’automatiser le téléchargement, dans son compte Dropbox, de certains fichiers se trouvant sur le web. Ça tombe bien, Dropbox fait partie des services qu’on peut ajouter dans une recette IFTTT. Ainsi, il existe une recette qui permet d’envoyer à heures fixes un fichier dans Dropbox à partir d’une URL donnée.

Mais voilà, cette recette ne fonctionne qu’avec un seul fichier à la fois. Mon collègue voulait transférer à chaque jour plusieurs fichiers. L’URL de ces fichiers, par ailleurs, change de nom en fonction de la date, alors que la recette ne permet de donner qu’un seul URL. Le défi est donc trop grand pour IFTTT.

La solution? Faire sa propre recette. Celle que j’ai concoctée comporte quatre ingrédients.

 

Ingrédient 1 – Générer les URLs chaque jour

Pour cela, j’ai écrit un court script qui va chercher les fichiers qui intéressent mon collègue en changeant l’URL en fonction de la date du jour. Ça, ce n’est pas trop compliqué. Dans ruby, il suffit d’utiliser la classe Time et la méthode .day pour créer la variable jour.

jour = Time.new.day

Dans le cas précis qui intéressait mon collègue, il y avait un autre élément de l’URL qui changeait en fonction du document qu’il souhaitait télécharger. J’ai donc construit une variable qui contient ces éléments, qu’on va appeler codes:

codes = [
"CAN_mar.json",
"CAN_qc.json",
"CAN_on.json",
"CAN_pr.json",
"CAN_bc.json",
"CAN_ter.json"
]

On peut ainsi construire nos URL en mettant bout à bout leurs différentes parties à l’aide d’une boucle qui va passer chacun des quatre éléments de notre variable codes:

url1 = "https://www.cse-cst.gc.ca/day/"
url2 = "/metadatafiles/"

codes.each do |code|
  url = "#{url1}#{jour}#{url2}#{code}"
end

Si on est le 32 août, on aura donc les URLs des six fichiers qu’on pourra télécharger:

https://www.cse-cst.gc.ca/day/32/metadatafiles/CAN_mar.json
https://www.cse-cst.gc.ca/day/32/metadatafiles/CAN_qc.json
https://www.cse-cst.gc.ca/day/32/metadatafiles/CAN_on.json
https://www.cse-cst.gc.ca/day/32/metadatafiles/CAN_pr.json
https://www.cse-cst.gc.ca/day/32/metadatafiles/CAN_bc.json
https://www.cse-cst.gc.ca/day/32/metadatafiles/CAN_ter.json

Voilà pour la partie facile. Maintenant, comment envoyer ces fichiers dans le Dropbox de mon collègue? C’est un peu plus compliqué.

 

Ingrédient 2 – L’API de Dropbox

Je me suis servi du Core API de Dropbox. Bien documenté, il permet de lire et d’écrire dans le compte Dropbox de qui on veut, à condition que cette personne (ou ces personnes) nous en donne(nt) l’autorisation. Et pour obtenir cette autorisation, il faut créer une application dans Dropbox. C’est donc ce que j’ai fait.

J’ai envoyé à mon collègue un lien. Il a cliqué sur le bouton «Autoriser». Puis Dropbox lui a retourné un code, que j’ai entré dans mon script, qui, lui m’a retourné un «jeton d’autorisation» que j’ai inséré dans mon script. Et voilà!

Quand le script roule, il va ramasser différents fichiers sur le web. Il les copie d’abord sur mon ordi. Puis, il les envoie dans le compte Dropbox de mon collègue. Ce dernier m’a envoyé une capture d’écran de son PC pour me montrer que ça fonctionnait (je l’ai caviardée, car il ne souhaite pas encore que son projet soit connu). Il semblait content.

Maintenant (bis), comment éviter de me lever tous les matins à 6h00 pour télécharger les fichiers pour mon collègue? J’apprécie beaucoup ledit collègue, mais je suis désolé, je ne me réveillerai pas tous les matins à 6h00 pour ouvrir mon ordinateur et lancer mon script.

 

Ingrédient 3 – Un serveur maison

J’avais, au sous-sol, un vieux iMac. C’était notre ordinateur familial entre 2005 et 2012. Son écran s’est cependant mis à développer une pénible affliction: des lignes verticales qui, petit à petit, rendaient de grandes bandes carrément illisibles.

On l’a mis au rancart au profit d’une machine plus récente avec un bon moniteur. Mais il était autrement en parfait état de marche, en dépit de son grand âge.

Je l’ai donc recyclé en serveur. J’ai tout effacé, installé MacOSX Snow Leopard et voilà:

L’écran est toujours strié, bien sûr. Mais quand je me connecte à distance à mon serveur, rien de tout cela. Voici à quoi ressemble le partage d’écran:

J’ai donc un ordinateur qui fonctionne en permanence (sauf en cas de coupure de courant). J’aurais pu utiliser les Services web d’Amazon (AWS) qui, eux, ne sont pas sensibles aux coupures relativement fréquentes dans mon secteur. Mais je vais être franc: je ne sais pas comment m’en servir. Il était plus simple, mais aussi plus économique (car les AWS ne sont pas gratuits), de dupliquer un modèle que je connais bien sur un autre ordinateur à la maison.

Pour faire fonctionner des scripts à intervalles fixes sur cet ordi, toutefois, il me faut un dernier ingrédient.

 

Ingrédient 4 – Cron

Ce drôle de nom est le diminutif d’un vieil utilitaire UNIX, dont le nom complet est crontab, qui permet de planifier l’exécution de tâches à intervalles fixes.

Le crontab est en fait un fichier dans lequel on indique la liste des tâches qu’on souhaite effectuer automatiquement et à quel intervalle. Chaque ligne correspond à une tâche. Et chaque tâche a une syntaxe particulière. Elle comporte sept éléments décrits dans l’illustration ci-dessous (inspirée de Linux-config.org):

Mon collègue souhaitait avoir ses fichiers chaque matin pour le petit déjeuner. J’ai donc écrit, dans le fichier crontab de mon serveur, une tâche qui apparaît à la dernière ligne de la capture d’écran ci-dessous:

Le premier élément se lit «0/5». Cela signifie que mon script sera exécuté à partir de la «zéroième» minute, à toutes les cinq minutes.

Le deuxième élément se lit «6-10». Cela signifie que mon script sera exécuté entre 6h00 et 10h00. Mais, lorsqu’on tient compte du premier élément, mon script sera en fait exécuté à toutes les 5 minutes entre 6h00 et 10h55. Les trois astérisques qui suivent indiquent que la tâche sera lancée à tous les jours de tous les mois, donc sept jours sur sept.

Dans mon script, j’ai une boucle qui vérifie si j’ai déjà téléchargé les fichiers sur mon serveur. Si je ne les ai pas, il vérifie sur le site où ils doivent se trouver s’ils ont été mis en ligne (et s’ils sont là, je les télécharge sur mon serveur, puis, je les envoie dans le Dropbox de mon collègue). Mais si je les ai, c’est que je les ai déjà envoyés à mon collègue, alors le script se termine sans rien faire.

Sur cette même capture d’écran se trouvent aussi deux autres tâches. Elles n’ont rien à voir avec les téléchargements de fichiers que me demandait mon collègue. Je m’en sers pour un autre projet qui pourrait éventuellement intéresser les journalistes économiques et financiers, projet dont j’ai brièvement parlé à ProjetJ. Plus de détails dans un prochain billet de blogue…

---