Salut
Salut @papachan @vincent.cantin, ça va les clojuriens FR ? Ca bosse sur quoi en ce moment ? Il y en a qui écrivent du Clojure quotidiennement et sont facturés/payés pour ?
Yes
Cool @baptiste-from-paris, en freelance, en remote ? Un société FR ?
Les deux et en indépendant
Yes, je viens de voir sur ton profil Linkedin. 👍
@baptiste-from-paris qui roule des mécaniques 😉
loool
du tout je réponds !
@cgrand et moi bossons ensemble
Pour ma part, initialement je suis dev PHP spécialisé dans le ecommerce (Prestashop) et depuis que j'ai découvert Clojure (fin 2018), je l'utilise pour le compte de mes clients dès que possible! J'ai souvent vu/lu le terme "Clojure enthusiast" et c'est très vrai ! Un langage m'a rarement aussi rendu accro , le temps dédié à ma veille techno a grandement augmenté ! 😉
> @cgrand et moi bossons ensemble Super ça. Clojure ? ClojureScript ? Les 2 ?
Immédiatement là tout de suite c’est du clj pur sur nos contrats en cours.
il exagère, Christophe a découvert TailwindCSS et depuis aime faire du design
(censuré)
Chez Electre, on est quelques un sur Paris à écrire du Clojure/Clojurescript pour un gros projet de refonte d’une app centrée sur un moteur de recherche avec beaucoup de data processing. Et on est assez heureux 🙂
Ha j’adore Tailwind CSS aussi 👍 ils ont fait un super boulot, j’ai même acheté une license Tailwind UI
> il exagère, Christophe a découvert TailwindCSS et depuis aime faire du design Haha, je comprends Tailwind CSS + Cljs, le pied !
@jeremie > refonte d’une app centrée sur un moteur de recherche avec beaucoup de data processing. Excellent, le projet doit être super intéressant. C'était quoi les technos avant Clj/Cljs ? > Et on est assez heureux Comme je vous comprends !
Pour info sur notre projet, tous le CSS est en CLJS avec https://github.com/clj-commons/cljss et ça marche plutôt bien, mais on a designer/UX full time qui sait écrire du clj…
Les technos étaient du C#/C++…
Ah oui, un belle refonte. 🙂
je l’ai utilisé c’est pas mal, surtout que ça diminue la taille de ton css
> https://slack-redir.net/link?url=https%3A%2F%2Fgithub.com%2Fclj-commons%2Fcljss&v=3 Top cette bibliothèque. C'est bon ça pour le designer/UX. Il a sans doute été formé sur place ? Ca était la syntaxe au début pour lui ?
Oui on l’a formé 🙂 la syntaxe est vraiment un non-sujet en fait, on lui a juste configuré son env de dév et du devcards pour qu’il soit autonome sans avoir besoin de toute l’infra…
Tiens j’avais fait ça il y a qqs temps, ça a un peu bougé mais pas tant que ça.. https://speakerdeck.com/jgrodziski/clojure-project-in-the-field
sur un précédent projet l’intégrateur n’avait aucun mal à aller modifier du clj (la “formation” s’étant résumée à lui montrer comment démarrer l’app avec autoreload)
@jeremie Impeccable, merci pour ton slide.
Je travaille en Clojure dans une boite qui n'utilise pas Clojure, dans l'equipe data. On m'a dit, tant que 2+2=4, je choisis la techno.
Mais bon .. je passe beaucoup de mon temps sur du sql
En ce moment, je developpe ma lib Vrac un peu chaque matin, et il s'avere tres prometteur et utile pour les utilisateurs. Je m'attend a une petite revolution dans le monde Clojure front end.
Je vais faire du no-React, puis faire un pont pour inclure des composants React.
Le systeme de souscription marche a base de diff, c'est l'utilisateur qui dit ce qui change, plutot que ca soit le systeme qui doivent le trouver.
Vrac inclue un graph de compited nodes qui marche aussi a base de diff. C'est ce sur quoi je bosse en ce moment.
La partie rendue est elle aussi assez space, c'est du pur declaratif a base de "smart template".
Le design est faite, tout est dans les brainstormings dans le channel #vrac, il reste plus qu'a implementer.
Oui du clojure au boulot.
OK, sympa. Toi @papachan, tu n'es pas en France si j'ai bien suivi, c'est ça ?
Très Intéressant tout ça @vincent.cantin 👍
> Je vais faire du no-React, puis faire un pont pour inclure des composants React. Bien ambitieux, ça serait top en effet.
Non. en amerique du sud depuis vingt ans !
@admin055 au fait, je suis bien intéressé par ce que tu as pu faire avec Clojure en e-commerce ou ce que tu aimerais pouvoir faire, et aussi ton retour d’expérience sur l’aspect productivité du développeur entre le monde PHP et Clojure 🙂
@admin055 Clojure en freelance aussi, en remote pour une start-up parisienne (je travaille depuis les Caraïbes)
comment il s’la pète
@jeremie vous bossez avec des gens en remote d'ailleurs par les temps qui courent ?
(pas pour moi, en tout cas pas à court terme, juste curieux)
@val_waeselynck ha le remote…vaste sujet…on y travaille mais c’est pas gagné. Stay tuned 😉
Dac
Je respecte
Wow sympa ! Et c'est ta boîte qui a migré vers Clojure pendant ton parcours ?
> Clojure en freelance aussi, en remote pour une start-up parisienne (je travaille depuis les Caraïbes) @val_waeselynck Sympa, ça donne envi présenté comme ça ! 🙂
> comment il s’la pète Je crois définitivement que c'est une qualité pour être un bon Clojuriens haha.
Ah bon ? J'aurais dit plutôt l'inverse
Ouais c'est cool qu'ils aient été ouverts d'esprit là dessus !
Juste une boutade haha
Il y a 6h de décalage horaire, ce qui force à beaucoup travailler en asynchrone. Dans notre cas ça a été plutôt un avantage en fait, forçant une communication ciblée et expéditive.
🙂
Oui le décalage horaire étant important, c'est aussi ce que je me suis dit, que c'était cool qu'il était open là dessus.
Récemment avec un client FR, on a travaillé avec une société indienne pour un développement spécifique et on a pu bosser en asynchrone sans souci...bonne expérience.
Je suis aussi en decallage avec la France pour mon daily job, 6 heures mais dans l’autre sens, depuis Taiwan.
Et vous travailler avec la France dans ta boîte taïwanaise ?
C’est une boite Francaise qui a une branche a Taiwan, mais mon equipe est en France.
> au fait, je suis bien intéressé par ce que tu as pu faire avec Clojure en e-commerce ou ce que tu aimerais pouvoir faire, et aussi ton retour d'expérience sur l'aspect productivité du développeur entre le monde PHP > et Clojure 🙂 @jeremie Merci pour tes questions. Alors j'ai un premier cas de figure qui s'est présenté en étant parfait niveau timing. J'avais suffisamment étudier Clojure/Script pour me sentir de le faire. Un client très fidèle (je bosse pour lui depuis 5-6 ans), qui a eu besoin d'un développement sur-mesure pour sa logistique lors d'un déménagement. Il est passé d'un entrepôt de 300m2 à 2000m2 et avait besoin de réorganiser ces références produits. Réorganisation faite par ses employées + interim avec lecteur de code barre et qui avait besoin d'avoir les infos en temps réel. Donc je lui ai fait une SPA avec (Reagent + Firebase realtime db) synchronisée via un middleware (ring/next.jdbc) pour la syncro avec la DB MySQL de Prestashop. Conclusion j'ai été épaté par le workflow, le peu de ligne de code et surtout j'ai poussé en prod et ça a fonctionné direct ! Aucun bug remonté par les employées !
Tout ça avec un langage que j'avais découvert 8 mois auparavant...what else ?! 🙂
OK, tu confirmes que ça marche très bien comme ça, top.
Ça me rappelle ce que je m'étais dit après mon premier projet en Clojure. "Hein !? C'est déjà fini ?"
Ca marche bien si la compagnie se donne les moyens d’etre organisee. La, c’est pas encore ca. Il y a trop de transmission de savoir a l’orale dans certaines equipes.
L’oral sans software
Je pense qu’il faut aussi relativiser, si tu prends Django en python, RoR pour Ruby ou Laravel en PHP, les types arrivent à te “chier” des sites CRUD très rapidement
Si ton client veut du “rapide/pas-cher”, c’est difficile commercialement de s’aligner je pense
Hum, c'était du data-mining sur des jeux de données de partitions, je doute que même RoR ait une gem pour ça 🙂
absolument, je parle spécifiquement du “site CRUD”, le fameux
Mais oui, l'écosystème Clojure n'est pas optimisé pour faire rapidement ce que tout le monde fait déjà
exactement 🙂
D'ailleurs, parlons en, de ce fameux "site CRUD".
(ou n'en parlons pas si ça vous saoule)
héhé
J'en arrive à me demander si c'est pas un peu un mythe ce truc.
J'entends des tonnes de gens dire "la plupart des apps sont naturellement CRUD". Mon expérience personnelle ne confirme pas ça du tout.
À chaque fois, lectures comme écritures étaient naturellement beaucoup plus sophistiquées que "CRUD", en terme de besoins produit.
Les lectures impliquaient plein de champs et de relations dérivées.
Les écritures étaient règles incrémentales et impliquaient souvent des règles qui impliquaient plein d'autres entités, de recalculer certains champs dans les transactions, etc.
Les suppressions voulaient bien plus souvent dire "archiver" / "désactiver" que "supprimer".
Le “CRUD” n’existe que dans les tutos mais pour en faire un avec @cgrand en ce moment, je me demande parfois si le gros de “la valeur” est dans l’XP-utilisateur et design versus la technique
Bref, le coup du "le CRUD c'est naturel", je crois que c'est des histoires que les programmeurs se racontent pour justifier l'utilisation d'outils familiers, un peu comme le coup de "les classes c'est naturel, c'est comme ça que marche le monde"
(Après je suis peut-être aussi biaisé par Datomic)
Hello, ceci dit pour le CRUD, il y a fulcro RAD maintenant non ?
C’étaient des contraintes bien compliquées ou la matérialisation d’un calcul dérivé ?
Pour le 2ème projet à l"étude, c'est indirectement lié au e-commerce mais au plutôt au business d'un de mes clients e-commerce. Ce client a une boutique en ligne de vente de musique libre de droit et radio ciblant les B2B. Son activité évoluant en réponse à la demande des clients, il souhaite une application mobile de stream audio. Je pars donc sur une application React Native en ClojureScript pour laquelle dans un premier temps le back end sera géré via les services Google Firebase (BDD, Authentification, Storage) afin de permettre un délai de mise en prod plus court pour ensuite migrer vers un back que je vais développé en Clojure. Le client a besoin d'un dashboard, d'exporter des données et stats de lecture des musiques et radio pour ses déclarations SACEM donc cela va être très enrichissant comme expérience je pense. 🙂
plutôt le 2ème je dirais
@admin055 non pas vraiment.