URL: https://linuxfr.org/users/sufflope/journaux/notifications-d-hebergements-pour-le-hellfest-en-rust Title: Notifications d'hébergements pour le Hellfest en Rust Authors: Sufflope Date: 2019年10月17日T22:23:51+02:00 License: CC By-SA Tags: rust Score: 22 # Le projet En 2020 je retourne au Hellfest, mais cette fois-ci, avec des proches qui sont [PMR](https://fr.wikipedia.org/wiki/Personne_%C3%A0_Mobilit%C3%A9_R%C3%A9duite). Ils auront donc accès aux plate-formes dédiées, mais en revanche ne peuvent pas se permettre de camper ou dormir sur un lit de camp dans mon hébergement habituel, ni marcher 30 minutes par trajet, avec du dénivelé. Ils ont besoin de trouver un hébergement chez les nombreux particuliers qui en proposent (ça, ce n'est pas très difficile, il y a une plateforme dédiée proposée par le Hellfest : [Hellfest Hébergement](http://hellfest-hebergement.fr/)), mais donc avec une vraie chambre et le plus proche possible du festival, et ça, comme tout ce qui est rare, il ne faut pas le rater. N'ayant pas tellement envie de [still in Memphis](https://xkcd.com/281/) le site pour les six prochains mois (étant le seul des trois dont ce n'est pas la première fois, et celui qui les a motivés pour y aller, je suis un peu le référent technique pour organiser cette sortie), et ayant remarqué que le site est une application Angular qui récupère les hébergements en JSON au chargement, je me suis mis en tête de faire un _poller_ qui nous notifierait des nouveaux hébergements qui peuvent nous convenir, pour qu'on puisse aviser si on se jette dessus pour réserver. Évidemment étant un [scalaiste qui ne bluff pas](https://linuxfr.org/users/sufflope/journaux/un-autre-taptempo-en-scala#comment-1745140) d'après martoni lui-même, j'ai failli partir sur cette solution de facilité. Mais je bave sur Rust depuis quelques années, et moi qui manque d'idées de projets persos sur lesquels tester des choses... c'était l'occasion rêvée. Vous pouvez consulter le résultat sur [HFH-notifier](https://gitlab.com/sufflope/hfh-notifier). J'ai essayé de faire quelque chose de propre : _parsing_ des annonces, sauvegarde des déjà-vus, _pretty printing_, notification par courriel, jolis logs... je suis assez fier du résultat, mais ça, vous pouvez le tester par vous-même. J'aimerais en revanche discuter avec vous de plusieurs sujets autour de ce projet. # Les enseignements ## Rust ### Pour un dev Scala C'est amusant, c'est très ambivalent. Certains paradigmes sont sans doute bien plus simples à appréhender pour moi (modulo l'adaptation à la syntaxe / l'implémentation d'iceux) ou pour un utilisateur de langage fonctionnel haut niveau, que pour un développeur C ou équivalent. _Pattern matching_, type `Option`, monades, _fold_, _map_ et ~~flatMap~~ _and_then_, immutabilité par défaut... je suis à la maison. En revanche... ### Le _borrow checker_, un ami qui vous veut du bien Évidemment j'ai eu des problèmes avec le _borrow checker_. Le seul réel problème que je n'ai pas pu résoudre grâce aux messages d'erreur de rustc uniquement, est visible via le changement d'itérateur dans [ce commit](https://gitlab.com/sufflope/hfh-notifier/commit/89f70cccb199050cba7b3825959119f345cc6ead) : ``` let wrapper = json.unwrap(); let interesting = wrapper .response - .iter() + .into_iter() .filter(|ad| ad.HFDist < MAX_DISTANCE); ``` Lorsque plus bas j'essaie de mettre les annonces qui m'intéressent dans ma BDD du pauvre (`seen.insert(ad._id, ad);`), je me fais insulter par des incantations ésotériques (qui le devenaient souvent d'autant plus que je tentais d'arnaquer le compilo) que j'ai préféré oublier. Je crois que je pouvais m'en sortir en implémentant `Clone` pour `Ad` mais pour moi ça sentait la mauvaise solution de contournement : pourquoi ne puis-je pas transférer ces objets dont je n'aurai plus besoin à un nouveau propriétaire ? Je n'ai pas envie de gâcher de la mémoire et du temps pour les copier pour rien (si si, je vous jure, je dev sur la JVM d'habitude). En résumé de ce que j'ai compris : `iter()` "laisse" la propriété de chaque élément à la collection qui les contient, quand `into_iter()` me permet de prendre la propriété (et d'ensuite la donner à la _HashMap_). Du coup dans le premier cas, à la fin de l'exécution de ma clôture, `response` étant libéré, les `Ad` aussi, et ça pète. Je n'ai pas bien compris pourquoi ; pour moi mon intention est claire (je "donne" les annonces à la map) et surtout réalisable (je n'essaie pas d'utiliser les annonces plus loin donc je n'essaie pas d'utiliser une variable que je ne possède plus). Mais bon apparemment ce n'était pas légal. Au final j'ai un peu mieux compris ces histoires de propriété. J'ai presque envie d'avoir un nouveau projet à écrire pour essayer d'autres constructions plus complexes pour me refaire fesser par le _borrow checker_. Euh, ça veut dire que j'ai passé le bizutage ? Ça y est, je suis un _rustacean_ ? ## AGPL J'ai failli encore oublier de mettre une licence. Je suis parti sur AGPL car j'aime son idéal de diffusion du partage, et là on ne peut pas dire que ça entre en conflit avec mon _business model_ donc je ne perds pas grand chose (je n'ai pas prévu d'_Enterprise Edition_). Mais, comme les plus affûtés d'entre vous auront remarqué, je n'ai pas prévu de fichier de configuration pour les variables, et j'ai tordu la bibliothèque de courriel pour s'adapter à la machine par laquelle j'envoie les notifications. Donc, pour être honnête, j'ai notamment mis les vrais _credentials_ dans le code avant de le compiler et le lancer sur ma machine. Ce qui tourne donc n'est, au sens strict, *pas* le code que vous pouvez voir. Alors, dans le cas présent, les seuls "clients" qui ont une interaction de cette nature (clientèle) avec mon instance sont mes proches à qui j'envoie les notifications, et je leur fais confiance pour ne pas m'assigner en justice pour réclamer le source avec le mot de passe. Mais supposons que j'ai poussé mon projet jusqu'à autoriser quiconque à s'inscrire pour être notifié. Pourriez-vous exiger les sources avec le mot de passe ? La licence prévoit-elle un "cas de force majeure", une "nécessité de fonctionnement" comme pour les cookies vitaux qui doivent pouvoir échapper au RGPD ? Aurais-je *dû* implémenter la lecture de ces valeurs depuis un fichier / les paramètres du binaire / quoi que ce soit qui me permet de les sortir du code, avant d'oser publier le projet ? Est-ce que les laisser dans le code mais avec un avertissement explicite que ces champs doivent être changés et gardés secrets (via un commentaire, une valeur par défaut `write secret here`...) suffit ? ## Diffuser un poll d'API à la hussarde, est-ce Charlie ? Pour ceux qui ne s'intéressent pas au Hellfest : c'est un évènement énorme dont la vente des billets est chaotique depuis quelques années et l'explosion de son succès, avec à peu près tous les poncifs de la vente de billet événementielle que vous pouvez imaginer. On a eu de la chance d'avoir nos quatre billets (oui j'ai dit trois plus haut, mais on a un quatrième qui a déjà fait un Hellfest, et puis il est valide comme moi alors on s'en tape). Et même si beaucoup de gens campent au camping fourni, ou retournent dans l'hébergement où ils sont allés aux éditions précédentes, on pourrait facilement imaginer quelques milliers de festivaliers qui souhaitent comme nous trouver le meilleur hébergement. Si tous se compilent leur petite instance et changent la période à quelque chose de trop faible, je peux imaginer que les responsables du site ne soient pas très contents. Étant donné que je ne publie pas de binaire, la forte adhérence à mon infrastructure (quoique, ça ça ne pètera qu'à l'envoi des courriels, pas au `POST`...) et la faible configurabilité, c'est quand même assez protégé contre les _script kiddies_ j'espère. Et en soi, si vraiment une foule de gens écroule HFH, c'est peut-être le signe qu'il y a un besoin de notifications ? Donc, je l'avoue, je n'ai pas proposé mon aide pour implémenter un système équivalent directement dans l'appli d'origine. A ma décharge j'ai cherché un dépôt des sources (vu les principes de partage qui sous-tendent HFH, je m'attendais à trouver un dépôt git quelque part) pour proposer des améliorations (j'ai possiblement quelques idées _front_ aussi) mais je n'ai rien trouvé (je suis plutôt du genre diesel à réfléchir sur les sources et sortir les idées (réalisées) après plutôt que discuter code avant). Alors si vous comptez utiliser ce projet : * soyez raisonnable n'allez pas écrouler HFH en spammant... * avant de vous ruer sur un riverain qui propose 4 places à moins d'un kilomètre, si vous n'êtes pas PMR, pensez à Proche 1 et Proche 2 qui sont vraiment hardeux mais qui sont vraiment cassés aussi :-) Et si vous êtes dev de HFH et êtes fâchés tout rouge : * n'hésitez pas à me contacter si ça vous a donné des idées * pensez à Proche 1 et Proche 2 avant de me bannir :-)

AltStyle によって変換されたページ (->オリジナル) /