Journal Un autre taptempo en Scala

Posté par (page perso) . Licence CC by-sa.
Tags :
14
27
juil.
2018

Coiffé au poteau sur le créneau du taptempo en Scala par martoni (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 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 pour rester référentiellement transparent, via une petite bibliothèque 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 pour imposer au niveau des types la validité des arguments
  • du scopt pour la gestion des dits arguments
  • du 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
  • de l'ADT
  • du pattern matching
  • des case class et leurs extractors
  • du Scala, quoi

J'ai essayé de coller le plus possible à l'original, é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.

  • # Il est encore temps

    Posté par . Évalué à 2.

    Pour bien faire et implémenter le mode jeu, pour regagner du lead technique ! :)

  • # Licence ?

    Posté par . Évalué à 2.

    Une licence ? Ou tu fais du non libre :-P

    • [^] # Re: Licence ?

      Posté par (page perso) . Évalué à 3. Dernière modification le 28/07/18 à 11:17.

      Ha quel gland, il fallait bien que j'oublie quelque chose. J'vais réfléchir à ça mais ça sera sûrement GPL3, ou alors peut-être la même licence que l'original pour rester dans le délire du clone.

  • # Scala-func

    Posté par (page perso) . Évalué à 3.

    J'ai l'impression que ta version utilise vraiment le paradigme fonctionnel alors que celle de Martoni est plus impérative. Comme le Scala est multi-paradigme, elle mérite sa place en tant que Scala-func :-)

    J'ai trouvé une autre différence par rapport à l'original : si un argument est hors bornes, tu retournes une exception alors que l'original force à la valeur à celle par défaut.

    En tout cas, bravo !

    • [^] # Re: Scala-func

      Posté par (page perso) . Évalué à 3. Dernière modification le 28/07/18 à 11:59.

      En effet, j'ai rajouté refined en cours de route et j'ai oublié que l'original ne rejetait pas les arguments invalides, et voilà donc une autre différence.

      Techniquement je renvoie une exception dans mon code, ce qui est assez moche pour du Scala idiomatique, mais c'est comme ça que scopt fonctionne (sans doute parce que le parsing des types primitifs Java lève des exceptions). Elle est catch par scopt qui renvoie un Left[Seq[String], _] pour cet argument, les erreurs collectées (en gros le message de mon exception) sont affichées sur la sortie standard puis scopt renvoie None puisqu'il n'a pas réussi à construire une instance de ma classe Args, du coup la grosse for comprehension qui constitue STapTempo.pureapp ne fait rien du tout (donc le programme termine immédiatement).

  • # Un scalaiste qui ne bluff pas ;)

    Posté par (page perso) . Évalué à 6.

    Merci,

    Je vois qu'on a à faire à un expert en Scala qui ne bluff pas lui !

    J'avoue ne pas comprendre le quart des concepts que tu viens de décrire dans ton journal. De mon coté, TapTempo était mon premier réel programme en Scala.

    Je n'ai fait du scala que pour du HDL jusqu'ici (Chisel).
    Mais pour aller plus loin avec Chisel il est rapidement nécessaire d'apprivoiser les concepts fonctionnel de Scala.

    Voila un programme à décortiquer pour mes vacances.

  • # Test unitaire ?

    Posté par . Évalué à 1.

    Ça ne me semble pas une bonne méthode selon moi d'exposer les méthodes en publique pour pouvoir les tester.

    Un programme comme ça est pour moi testable que fonctionnellement et pas unitairement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.