Fork me on GitHub
#clojure-france
<
2020-12-04
>
Michaël Salihi09:12:06

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.

Michaël Salihi09:12:28

Et vous, quelles sont vos préférences dans les libs d'injection de dépendences / reloaded workflow ? Et pourquoi ?

Michaël Salihi09:12:36

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/

papachan11:12:47

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.

Alexandre Grison13:12:54

Je préfère également Integrant

6
val_waeselynck13:12:31

Ç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é.

Michaël Salihi11:12:52

Merci pour ton retour d'expérience @U06GS6P1N 👍 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.

Alexandre Grison17:12:30

Ah ben c'est moi 🙂

🙂 3
val_waeselynck13:12:04

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.

papachan13:12:21

@vincent.cantin c'est en train de commencer

Vincent Cantin13:12:35

Je ne vois toujours rien dans Youtube

Vincent Cantin14:12:24

ok, it starts now

papachan13:12:55

Quelqu'un a deja essayé duct?

val_waeselynck14:12:44

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.

3
Alexandre Grison17:12:44

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.

Alexandre Grison17:12:03

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

Michaël Salihi11:12:15

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.

Michaël Salihi11:12:37

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.

👍 3
Michaël Salihi11:12:12

Au passage, top ton article @UE27GJZR8 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. 🙂

Alexandre Grison15:12:53

Super! Désolé pour le lag, faut vraiment que j'ajoute Slack aux app qui démarrent avec l'ordinateur 😕

Alexandre Grison15:12:00

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.

val_waeselynck14:12:10

Je dirais qu'aujourd'hui Duct est surtout optimal pour son auteur, qui veut pouvoir lancer plein de projets similaires très rapidement.

3
val_waeselynck14:12:54

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 ;)

val_waeselynck14:12:17

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

👍 6
papachan14:12:23

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.

papachan14:12:28

Pour ce qui est de re-frame c'est plus un comodity vu qu'on interagit deja un autre js framework react.

val_waeselynck18:12:19

Je ne sais pas si même dans les grandes entreprises ça aide vraiment à aller plus vite ; je dirais que ça optimise la vitesse de démarrage, mais pas la vitesse de croisière. Peut-être dans les boîtes qui sont vraiment fans de microservices, et qui passent donc vraiment beaucoup de leur temps à faire du setup de projet. Après, ce qui me semble certain, c'est que si tu as tellement de développeurs que l'overhead d'avoir choisi la mauvaise lib/architecture est toujours négligeable devant l'overhead de coordination entre développeurs, alors oui, autant prendre des technos qui s'installent vite et sont les mêmes pour tout le monde. C'est une situation (fréquente, j'imagine) dans laquelle l'organisation s'est déjà résignée à une productivité très faible par personne, donc autant se simplifier la réflexion sur les choix d'archi, vu qu'il n'y a pas beaucoup de vélocité à y gagner

Alexandre Grison17:12:16

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)

Alexandre Grison17:12:38

Mais je vois ce que tu veux dire par vitesse de croisière et démarrage, j'ai le même sentiment

val_waeselynck18:12:19

Je ne sais pas si même dans les grandes entreprises ça aide vraiment à aller plus vite ; je dirais que ça optimise la vitesse de démarrage, mais pas la vitesse de croisière. Peut-être dans les boîtes qui sont vraiment fans de microservices, et qui passent donc vraiment beaucoup de leur temps à faire du setup de projet. Après, ce qui me semble certain, c'est que si tu as tellement de développeurs que l'overhead d'avoir choisi la mauvaise lib/architecture est toujours négligeable devant l'overhead de coordination entre développeurs, alors oui, autant prendre des technos qui s'installent vite et sont les mêmes pour tout le monde. C'est une situation (fréquente, j'imagine) dans laquelle l'organisation s'est déjà résignée à une productivité très faible par personne, donc autant se simplifier la réflexion sur les choix d'archi, vu qu'il n'y a pas beaucoup de vélocité à y gagner

val_waeselynck18:12:41

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

papachan22:12:15

Quelqu'un a vu la derniere session de re:clojure?