Clojurians Log v2
clojure-france
Merci @papachan 😉 Pour avoir tester Mount, Component, Integrant puis Clip, je peux dire que définitivement mon choix se portera soit vers Integrant ou Clip sur les prochains projets. 👍 Pour le moment, je n'ai pas encore de préférences entre ces 2 libs.
Et vous, quelles sont vos préférences dans les libs d'injection de dépendences / reloaded workflow ? Et pourquoi ?
Je met le lien ici pour ceux que ça intéresse. Des retours constructifs sont les bienvenus. 😉
Cela se passe sur la branche clip https://github.com/PrestanceDesign/todo-backend-clojure-reitit/tree/clip
Je n'ai pas ajouté cette "surchouche" sur la branche master pour que cela reste plus simple/compréhensible pour des non clojuriens curieux qui arriveraient via la page du projet : http://www.todobackend.com/
J'utillisais dabord integrant qui est super pratique, mais avec Mount j'ai vu comment on fait le wire up de plusieurs datasources pour un projet. Sous integrant depuis clip je suppose que c'est possible aussi, mais c'est un truc que je me suis pas encore penché dessus.
Je préfère également Integrant
Ça a l'air top Clip, je connaissais pas ! J'utilise Integrant, et recommande fortement contre Mount. J'ai utilisé Mount, et y ai trouvé beaucoup de problèmes et peu d'avantages ; mon impression est que les avantages perçus de Mount résident principalement dans une connaissance incomplète de la REPL (difficultés à reconstituer le contexte), et une importance trop grande accordée à la concision (voir comme problématique d'avoir un argument de plus au début des fonctions), tandis que le problème d'avoir des fonctions qui ne sont plus «self-contained» mais dépendantes d'un état global éparpillé dans des Vars est ignoré.
Merci pour ton retour d'expérience @val_waeselynck 👍 Très intéressant d'avoir l'avis d'une personne ayant le recul professionnel, pour ma part n'ayant étudier ces 4 bibliothèques que sur des projets tests. En tout cas, mon analyse rejoint la tienne et me mène clairement vers Integrant et Clip.
Pour info; re:clojure conf dans 15 min https://twitter.com/algrison/status/1334819279028498435
Ah ben c'est moi 🙂
Après je suis peut-être biaisé par les systèmes sur lesquels j'ai bossé ; surtout des serveurs qui s'appuient des BDD, et notamment Datomic, qui offre une prime très forte à avoir l'état du système incarné dans une valeur.
@vincent.cantin c'est en train de commencer
Quelqu'un a deja essayé duct?
Je ne vois toujours rien dans Youtube
ok, it starts now
On utilise Duct dans mon projet actuel. Je suis pas fan honnêtement, je trouve ça très mal documenté. J'ai eu l'impression que pour chaque heure de «plomberie» économisée par Duct, j'en ai perdu 5 à faire du reverse-engineering de Duct.
Je trouve aussi que c'est mal documenté, en fait la première version était très bien documentée, puis la doc a été laissé à l'abandon, la plupart des tutoriaux et exemples sur le Wiki ne fonctionnait plus.
J'étais assez enchanté par le concept, et je pense qu'avec une vraie doc tu peux itérer vraiment super vite sur de simples projets
J'ai uniquement suivi le "Getting started" de Duct donc je n'ai pas le recul nécessaire pour avoir un avis mais d'une manière générale, j'apprécie énormément de commencer un projet "from scratch" avec un simple fichier deps.edn renseigné à la main au fur et à mesure des besoins.
Et la manière dont sont pensées les libs de Clojure, c'est parfait (des pièces de Lego). Cela me permet aussi de mieux apprendre le langage, il y a moins de "magie" derrière comme avec Luminus ou Duct, etc.
Au passage, top ton article @a.grison https://grison.me/2020/04/03/fun-with-gtfs-and-clojure/ ! J'ai pu l'adapter pour la CTS (Transport de Strasbourg), on est voisin. 🙂
Super! Désolé pour le lag, faut vraiment que j'ajoute Slack aux app qui démarrent avec l'ordinateur 😕
Ca doit être un peu plus lent avec le réseau de bus de Strasbourg je pense, j'avais essayé avec Paris ça prenait beaucoup plus de temps à charger que Metz (quasi instant). Pour Luxembourg leur GTFS contient bus & trains donc c'est assez gros mais je me suis fait du coup des shortcut pour quand je prenais le bus pour rentrer du boulot, où j'ai pas mis les pieds depuis Mars.
Je dirais qu'aujourd'hui Duct est surtout optimal pour son auteur, qui veut pouvoir lancer plein de projets similaires très rapidement.
Après les avis sont partagés, je crois que Michel avec qui je bosse aime plus Duct que moi. Même chose pour re-frame d'ailleurs. Les frameworks, ça plaît plus ou moins ;)
Perso, ma philosophie en choix de technos n'est pas «éliminer les tâches les plus courantes», mais «résoudre mes problèmes les plus difficiles»... je comprendrais que des gens aient des priorités différentes
Là où je bosse c'est microservice Spring Boot, donc y'a pas mal de temps perdu à monter des projets, finalement j'ai monté un spring initializer en interne + une lib qui se load avec Spring qui contient tous les trucs de bases pour que les devs n'aient pas à le configurer (ELK, caching redis, gestion des JWT etc)
Mais je vois ce que tu veux dire par vitesse de croisière et démarrage, j'ai le même sentiment
Merci pour partager ton point de vue ou je suis complement aligné avec toi. Je suis venu a clojure justement parce qu'il n'existait pas encore de frameworks et on montait son projet comme on voulait. Maintenant je suppose que dans les boites noires des entreprises c'est obligé leur développeur a utiliser des outils qu'il leur permet d'aller plus vite bien que ces web frameworks ou boilerplates ne sont plus les acteurs principaux du langage comme django ou rails. Je les trouve interressant pour apprendre d'eux mais j'en recommende aucun en fait. la liberté de choisir pour tel ou tel projet c'est la force de clojure.
Pour ce qui est de re-frame c'est plus un comodity vu qu'on interagit deja un autre js framework react.
Mais quand même, j'ai l'impression que beaucoup de boîtes se racontent des histoires sur leur choix technos, avec l'hypothèse implicite qu'aller vite signifie démarrer vite
Quelqu'un a vu la derniere session de re:clojure?