URL: https://linuxfr.org/users/sufflope/journaux/un-autre-taptempo-en-scala Title: Un autre taptempo en Scala Authors: Sufflope Date: 2018年07月27日T16:43:38+02:00 License: CC By-SA Tags: taptempo et scala Score: 15 Coiffé au poteau sur le créneau du taptempo en Scala par [martoni](https://linuxfr.org/users/martoni/journaux/taptempo-en-scala) (qui ne bluffait visiblement pas), alors que je mijotais ma version depuis des mois, j'apprends à la dure la loi impitoyable du [Time to market](https://en.wikipedia.org/wiki/Time_to_market) et ne puis plus qu'espérer récolter les restes. C'est bien, ça me pousse à publier même si les TU ne sont pas exhaustifs, même si c'est sur l'instance gitlab officielle et pas sur mon instance autohébergée qui est pas finite d'installer (avant je veux mettre mes services existants au propre, dans des conteneurs systemd-nspawn, et... bah j'ai pas commencé ; alors c'est pas gagné), même si... Je vous propose une implémentation plus ~~tarabiscot~~ idiomatique. Il y a : * de la [monade IO](https://typelevel.org/blog/2017/05/02/io-monad-for-cats.html) pour rester [référentiellement transparent](https://en.wikipedia.org/wiki/Referential_transparency), via [une petite bibliothèque](https://github.com/battermann/pureapp) pour faire ~~du sale~~ une application dans la vraie vie avec des effets de bords sinon il se passe rien. J'ai presque passé plus de temps à la tordre pour l'utiliser comme je voulais qu'à le faire, et il reste des artefacts (par exemple on ne peut pas passer une dernière commande avant de sortir lorsqu'on reçoit le signal de sortie (l'appui sur `q`), alors j'ai collé un vieux _shutdown hook_ avec un `println` qui s'accumule donc pendant les tests), mais c'était intéressant de valider que je peux l'utiliser en submodule git (à l'époque l'auteur ne l'avait pas publié en artefact), en relaxant mes options de compilation de nazis juste pour elle, ça pourra peut-être me servir dans des cas plus concrets * [refined](https://github.com/fthomas/refined) pour imposer au niveau des types la validité des arguments * du [scopt](https://github.com/scopt/scopt) pour la gestion des dits arguments * du [scalacheck](https://github.com/rickynils/scalacheck) pour des TU _property-based_, qui génère des données de tests aléatoires au lieu de faire confiance au programmeur pour penser aux cas chiants * des règles de formattage, des interdictions d'utilisation de fonctionnalités impures... bien strictes comme on aime [avec mon employeur](https://github.com/nrinaudo/kantan.sbt) * de l'[ADT](https://en.wikipedia.org/wiki/Algebraic_data_type) * du _pattern matching_ * des _case class_ et leurs _extractors_ * du Scala, quoi J'ai essayé de coller le plus possible à l'[original](https://linuxfr.org/users/mzf/journaux/un-tap-tempo-en-ligne-de-commande), évidemment pour les fonctionnalités mais jusqu'aux formats des chaînes en sortie, etc. La seule grosse concession dont je me souviens (j'ai fait ça vers le mois de mars avant d'être paralysé par _le mieux est l'ennemi du bien_...) c'est l'absence d'i18n. Félicitations tout de même à martoni, qui, lui, s'est lancé sans coup de pied au cul, raflant donc l'antériorité (et donc les parts de marché, le ROI, la future capitalisation licorne à 1G$), en plus d'être sorti de sa zone de confort pour découvrir ce langage ! Voici donc [staptempo](https://gitlab.com/sufflope/staptempo).