Rationalisation des outils de developpement

@Kje :

Je voudrais digresser sur les remarques de Kje mais du coup on s'écarte du problème "des outils".

Y'a aussi plusieurs phénomènes spéciaux avec le front et qui ne datent pas d'hier :

1. Tu l'as cité toi-même : "J'ai des goûts de chiotte, je peux pas m'occuper du front". Le front c'est pas que du design, je suis certain que tu pourrais faire plein de trucs même avec des goûts de chiotte. (Je ne sais rien dessiner à part Snoopy, je suis incapable de décorer un appartement, j'ai du mal à "sortir" du thème graphique de Bootstrap pour des projets persos, et pourtant je bosse sur des UI webs tous les jours). C'est un peu comme dire "Ouah non, j'peux pas toucher à du code back, je ne connais pas tous les design patterns de la planète". D'une part tu peux débuter sans (et heureusement), d'autre part ça se travaille, comme tout. Mais peu de gens font l'effort sans y être poussé.

2. Les bonnes pratiques front sont extrêmement diversifiées. Beaucoup de choix se respectent, il est très rare qu'une solution fasse l'unanimité. Tu connais Python et tu l'apprécies certainement pour le "une façon de bien faire". Pour faire l'analogie, le dev front c'est l'inverse, surtout au niveau des process' et de l'organisation (plus que pour le code lui-même). Je respecte l'avis d'Alex concernant les libs par exemple. Je ne parviens pourtant pas à m'en passer dans tous mes projets persos. Prenons un autre exemple : la gestion de dépendances en Javascript. Tout le monde s'accorde à dire que modulariser un projet JS c'est mieux (bah ouais). J'ai travaillé sur 3 ou 4 projets différents en JS, résultat : 3 ou 4 moyens de gérer les dépendances et l'injection de dépendances. (là où en Java si t'as vu Maven et Gradle t'as quand même vite fait le tour). Les "pipeline" en sont un (déclaratif, en haut d'un fichier), l'inclusion asynchrone en est une autre (require.js), AngularJS propose une mécanique d'injection de dépendance à sa sauce, etc. Dans tous ces cas le resultat du build fournit un fichier minifié. Y'a pas vraiment de bonne façon de s'y prendre. Et encore, ZdS reste simple au niveau front, mais pense aux "single-page-webapps" : entre AngularJS, React, Mithril, ça en fait des moyens de construire une application "full-js" comme pourrait l'être l'éditeur du site. Les compétences front sont très éparses au final, c'est malheureux mais c'est comme ça

3. Le front a mauvaise réputation. Et c'est sans doute l'un des freins principaux. Combien de dev on peut entendre dire "lol je toucherai jamais à du JS, ça pue" "mdr nodejs c'est à chier, comment on peut développer du code serveur en JS", "mais le mec qui a inventé le CSS est franchement tordu, c'est n'importe quoi". Bref, oui, le Javascript c'est parfois pénible à utiliser. Ça autorise à écrire des immondices, mais on n'a pas grand chose d'autre à se mettre sous la dent, et pour écrire du code asynchrone, ça reste moins pire que d'autres saloperies (Java entre autres). Et oui, le CSS me rend également barge par moment. Et ça, je peux prendre le pari que sur ZdS c'est un frein assez énorme. Plein de gens vont se tenir à l'écart du front parce que "ça pue". C'est malheureux mais c'est vrai

4. Le manque de "filets de sécurité". Dans le cas du back, y'a de fortes chances pour que si je casse quelque chose un TU voire un test d'intégration pète quelque part. Ça peut sembler anodin mais c'est essentiel quand on se lance sur un projet. Jamais, au grand jamais j'irai toucher à une CSS d'Alex sans en avoir discuté avec lui ou sans avoir une très bonne vue du projet. Y'a une chance sur deux pour que j'introduise une régression. Et même si ce genre de TI existent c'est quasiment impossible à couvrir (il faut tester qu'un élément se situe au bon "endroit" dans la page, même avec un browser embarqué la notion est complètement floue)

Je connais le JS et SASS, j'ai sans doute développé des trucs beaucoup plus compliqués que l'éditeur zMarkdown du site, mais parmi ces raisons il y en a certaines qui m'empêchent de contribuer, avant même de regarder le processus d'installation. Je pense notamment que les outils et choix technologiques sont le frein principal. Les choix ne sont pas mauvais du tout hein, je les respecte à 100%. Simplement ce ne sont pas les miens.

EDIT : pour faire quotidiennement du dev front et back, pour côtoyer des dev front "purs" et des dev backs "durs" je peux t'assurer que je ne suis pas étonné une seule seconde qu'il y ait aussi peu de devs front sur ce site. D'une c'est un travail extrêmement ingrat, d'autre part il est beaucoup plus délicat de "rentrer" dans le code front d'un projet aussi avancé (ne serait-ce que par la versatilité des outils existant et des façon d'organiser le code front d'un projet). La dépendance au back est un autre soucis : si tu n'as pas les données sous la main, ou les "mock" pour tester ce que ça donne tu perds un temps considérable. Etc. etc. Essayez de faire le ratio dev front/dev back sur les projets que vous connaissez bien. Est-ce-que vous avez au même calcul que moi ? Qu'est-ce-que ça donne par rapport à ZdS ?

C'est peut être là le problème ? Qu'on soit quelqu'un qui vient du back, ou un premier contributeur externe, c'est pareil : on ne maitrise pas encore entièrement tous les outils dispo.

C'est pas une question d'outils pour le coup, mais une question de connaissance et d'expérience.

J'ai beau commenter certaines PR, ça ne change rien au problème. J'ai vu firm1 mettre des propriété CSS n'importe où (et très sincèrement, je pense qu'il n'avait pas cherché à comprendre). Il s'agissait de boutons, il y a pourtant un fichier "forms" dédié aux formulaires et donc aux boutons. Ce simple exemple prouve un certain manque de recherche dans une logique établie dans l'organisation du projet. Et la doc n'y changera que très peu de choses, on ne dit pas "tout ce qui touche à la vue des tutos est dans tutorial/view.py …" c'est au dev de chercher 5 minutes en lui indiquant que chaque module a son dossier, ou alors on va avoir des doc imbuvables pour assistés.

le manque de contributeur est le vrai problème et je cherche justement à comprendre POURQUOI il y en a si peu sur le front.

Peut-être parce que je suis allé vite pendant juin/juillet et qu'à part Sandhose personne n'a tenté de s'accrocher au train en marche.

Aussi, j'ai la forte impression qu'il y a beaucoup moins de dev front que de dev back de façon générale (j'entends par dev front des gens qui maîtrisent HTML, CSS et JavaScript).

Le back n'est pas plus simple et pourtant des gens qui n'avaient presque jamais fais de python ou django arrivent a contribuer de manière utile.

Mais ils avaient des connaissances en POO, en MVC, etc. C'est la toute la nuance : ils connaissent les concepts. Un langage/framework, si tu connais les concepts derrière ça prend pas des plombes à assimiler (ou alors il est mal fait, ou alors il te manque des concepts).

Par exemple en front, ça reviendrait à dire qu'un mec connait LESS mais pas Sass. Il s'adapterait alors en quelques jours, car il a déjà acquis les concepts nécessaires à comprendre le code.

Si ici des personnes sont intéressées pour contribuer au dev front, elle peuvent s'y mettre, il y a une pile d'issues assez simples à corriger assez régulièrement (elles ont les tags front et facile)

Mais si on doit faire la liste des problèmes, alors le problème de comportement exécrable d'Alex-D en équipe en est un.

C'est plaisant de constater que mes efforts m'amènent à chaque fois à revoir les mêmes phrases me concernant. Et on ne peut pas me dire le contraire : j'essaye tant que je peux de me montrer ouvert ici, et on me dit finalement que je suis le problème.

Pour vous, ZdS est prisonnier de moi. Pour moi, je suis prisonnier de ZdS tant qu'il n'y aura personne d'autre. Chacun son point de vue.

Je vous annonce donc mon départ en tant que ce que qualifierais de "lead dev front" lorsque la page d'accueil sera terminée et que la doc front sera plus étoffée, qu'il y ait ou non quelqu'un pour continuer le dev front. Qu'on ne me dise pas encore que c'est une prise d’otage, j'ai envie de faire cette page d'accueil et alors j'estimerais ce que je voulais faire sur ZdS sera accompli.

peut-être faudrait-il décrire en détails comment on souhaite convertir en code la solution adoptée, histoire qu'à la fin, ça ne reste presque plus qu'un problème de dactylographie et de connaissance technique du langage.

Bah sur cette zep là en particulier c'est marqué non? C'est peut etre pas suffisament explicite, je peux le concevoir, mais tu part de notre markdown et on doit généré les différentes sorties. Cette Zep est particulière car elle parlais de points techniques et il a été choisi de ne conserver que pandoc (c'est noté dans le premier message normalement). Les raisons sont évoqués aussi (les avantages/désavantages de toutes les propositions, etc.)

Où ça en est actuellement, en effet, ce n'est pas dans le premier message, j'ai juste mis "en cours de developpement". Mais je le ferais quand j'aurais finis le premiere grosse étape.

Apres j'avoue que j'ai peu de motivations en ce moment pour refaire ce premier message pour rendre ça plus clair.

Mais bon, on est un peu HS là Il faudrait peut etre en reparler sur le post it définissant les zep

@Javier : Bonnes remarques, je vais y répondre :

1. Bon dans mon cas ça va plus loin que des gouts de chiottes hein ! De façon général le front ne m’intéresse pas et je n'ai pas envie d'y toucher. Cependant ce n'est pas le cas de tout le monde. Il y a plusieurs personnes qui ont voulu s'y mettre et ont abandonnés.
2. Comme je l'ai dis perso je n'ai aucun soucis à ce qu'il y ai des outils dédié pour le front. Si le front a besoin de node, ça ne me dérange pas. Mais je ne pense pas que ça explique vraiment le manque de contribution front. Le monde du back est au moins autant diversifié (que ce soit au niveau langage ou framework). Le couple Python + Django sans être un truc inconnu est, j'en suis surs, pas la paire la plus utilisé du monde. Si on avait voulu maximiser les compétences et les contributions on aurait peut etre du partir sur du PHP + Symphonie par exemple. Mais bref, on a des outils et manifestement ça n'a pas empeché certaines personnes à se former à ces technos (moi le premier, je n'avais jamais touché a Django avant ça et j'ai dut me remettre plus que sérieusement à Haskell pour le fork de Pandoc). Bref j'ai du mal a voir pourquoi sur le front ce serait plus un frein que sur le back.
3. Hum peut etre mais le fais que des personnes aient essayé me fait douter tout de même. Il y aussi, on le sait, plusieurs dev front de metier sur ce site (toi entre autre aussi par exemple ?). Pourquoi ne participent ils pas ?
4. Soit mais c'est entre autre pour ça qu'on fait des QA + passage en préprod. Et quand bien même, Alex est pret a aider a la formation des nouveaux. Ça ne me choque pas qu'il y ai un lead-front qui va reviewer une PR. C'est même le but des PR.

@Alex : je ne vais pas revenir sur tout, une partie est dans ma réponse à Javier. Sincèrement ce n'étais pas contre toi directement, je me demande juste pourquoi on a si peu de contributions front.

Pour vous, ZdS est prisonnier de moi. Pour moi, je suis prisonnier de ZdS tant qu'il n'y aura personne d'autre. Chacun son point de vue.

Comme je l'ai dis, ce n'est pas personnel. C'est malsain pour un projet de dépendre d'une seule personne. Et c'est d'ailleurs, je te le concède, chiant pour la personne aussi. C'est moi qui me prends tout ce qui a trait au markdown, c'est un peu pénible parfois, j'aimerais bien faire autre chose. Apres que cette personne soit toi, firm1, moi ou n'importe qui c'est pareil.

1. De façon général le front ne m’intéresse pas et je n'ai pas envie d'y toucher. Cependant ce n'est pas le cas de tout le monde. Il y a plusieurs personnes qui ont voulu s'y mettre et ont abandonnés.

Et t'es certainement loin d'être le seul. "le front ne m’intéresse pas et je n'ai pas envie d'y toucher" je l'ai entendu une paire de fois. Et ça rejoint mon point sur la mauvaise réputation. On est même à 100% dedans.

1. Comme je l'ai dis perso je n'ai aucun soucis à ce qu'il y ai des outils dédié pour le front. Si le front a besoin de node, ça ne me dérange pas. Mais je ne pense pas que ça explique vraiment le manque de contribution front. Le monde du back est au moins autant diversifié (que ce soit au niveau langage ou framework). Le couple Python + Django sans être un truc inconnu est, j'en suis surs, pas la paire la plus utilisé du monde. Si on avait voulu maximiser les compétences et les contributions on aurait peut etre du partir sur du PHP + Symphonie par exemple. Mais bref, on a des outils et manifestement ça n'a pas empeché certaines personnes à se former à ces technos (moi le premier, je n'avais jamais touché a Django avant ça et j'ai dut me remettre plus que sérieusement à Haskell pour le fork de Pandoc). Bref j'ai du mal a voir pourquoi sur le front ce serait plus un frein que sur le back.

C'est une question d'attractivité. Tout simplement. Python et Django ont le vent en poupe. Beaucoup de gens s'accordent à dire que tous ces frameworks "récents" (j'englobe Symfony, RoR, Django, Grails, Play!, … dans le même sac) sont élégants et sont la façon moderne de construire des sites webs.

Je me permets un petit pari. Vous auriez construit le site en tant que web-app : i.e. reposant uniquement sur des APIs, sans aucun template, avec énormément de dynamisme côté UI (re-rendus à la volée, …). Bref, les trucs "sexy" du front (j'en parlais plus haut : les "single-page-webapp" qu'on retrouve notamment sur les applications mobiles utilisant PhoneGap ou consorts), vous auriez attiré plus de devs front. Mais ce n'était certainement pas le bon choix pour un site comme ZdS. (vous avez fait le bon choix). ZdS est un site é-di-to-rial, pas une app.

Encore plus loin que les choix techniques : ZdS est un projet intéressant côté back. Rien que le modèle de données, la représentation des tutoriels, etc. est intéressant. Côté front c'est on-ne-peut-plus classique. Ce n'est pas attirant pour un dev front expérimenté, tout simplement.

1. Hum peut etre mais le fais que des personnes aient essayé me fait douter tout de même. Il y aussi, on le sait, plusieurs dev front de metier sur ce site (toi entre autre aussi par exemple ?). Pourquoi ne participent ils pas ?

J'ai donné les raisons en ce qui me concerne. Je n'y trouverais aucun intérêt, les choix techniques ne sont pas les miens. Autant côté back je me suis posé 200 fois la question (et là, la complexité d'install a clairement joué de côté là) autant côté front non.

1. Soit mais c'est entre autre pour ça qu'on fait des QA + passage en préprod. Et quand bien même, Alex est pret a aider a la formation des nouveaux. Ça ne me choque pas qu'il y ai un lead-front qui va reviewer une PR. C'est même le but des PR.

Oui, il est là pour aider. Mais franchement, vous n'avez pas de dev front dans vos boîtes ? Quand il part il se passe quoi en règle générale ? Perso j'ai toujours vu le même comportement, un mec arrive, il refait quasiment tout avec d'autres technos (sans oublier de râler). C'est systématique. Parfois la transition se passe de façon plus soft, mais c'est souvent ça. D'où l'intérêt de certaines libs comme Bootstrap en entreprise d'ailleurs. Mais ça ne solutionne pas tous les problèmes.

Après vous avez l'air d'avoir des infos que je n'ai pas "certains ont essayé et…" donc je veux pas non plus m'immiscer là-dedans. Mais perso la dépendance à UN dev front sur un projet comme ZdS ne me choque pas du tout (c'est regrettable hein, mais pas très surprenant).

J'ai du réinstaller un venv zds ces vacances et je vais donner ma vision de choses.

BACK

Pour le back rien ne me choque. Un simple requirements.txt, comme dans TOUS les projets Django. Après il y a les fixtures. OK comme dans PRESQUE TOUS les projets Django. Ensuite il y a le front et la c'est la merde.

Pour ce qui est de Haskell & co. je me suis jamais intéressé plus que ça à cette partie du code donc j'avoue ne pas en avoir eu besoin.

FRONT

J'ai pas l'habitude de bosser avec des dev front mais plutôt avec des frameworks comme Foundation 5. En général c'est assez simple : il n'y a rien à faire. Là il faut aller chercher un fichier pack.zip qui souvent n'est pas dans la version sur laquelle on bosse bref c'est vraiment la merde.

Je viens de découvrir la doc front (faite en JS. LOL.) j'avoue que son existence me rassure un peu. Est-ce que c'est possible d'avoir une truc :

• intégré avec le reste ;
• PAS en JS ;
• un peu plus complète ?

GIT

Une des choses ultra chiante que je reproche à process de dev c'est d'en avoir un peu de partout. Genre :

• https://github.com/zestedesavoir/zds-site/blob/dev/README.md
• https://github.com/zestedesavoir/zds-site/blob/dev/CONTRIBUTING.md
• http://zds-site.readthedocs.org/fr/latest/
• http://zestedesavoir.com/forums/sujet/324/comment-contribuer-comprendre-comment-suivre-le-workflow/
• https://github.com/zestedesavoir/zds-site/blob/dev/doc/workflow.md
• http://zestedesavoir.com/forums/sujet/316/gestion-des-tickets-sur-github-et-organisation-generale/
• http://zestedesavoir.com/forums/sujet/1351/la-qa-pour-les-nuls/

C'est juste insupportable quand j'ai besoin d'une info et que je dois plus ou moins tout me taper pour la trouver. En plus, certaines fois les informations divergent d'une page à l'autre. Est-ce qu'il est possible de centraliser tout ça ?

(Je sais pas si c'était le sujet pour mais ça avait besoin d'être dit)

@Javier

C'est une question d'attractivité. Tout simplement. Python et Django ont le vent en poupe. Beaucoup de gens s'accordent à dire que tous ces frameworks "récents" (j'englobe Symfony, RoR, Django, Grails, Play!, … dans le même sac) sont élégants et sont la façon moderne de construire des sites webs.

As-tu déjà touché à Django ? Si oui alors tu dois comprendre à quel point c'est agréable à utiliser, si non, je te conseille de le faire.

Pour moi, en fait le problème c'est qu'on a des "docs" qui ne sont pas marquées comme obsolètes quant à l'organisation.

Les seules doc maintenues et à jour sur ce point sont :

1. https://github.com/zestedesavoir/zds-site/blob/dev/README.md
2. https://github.com/zestedesavoir/zds-site/blob/dev/CONTRIBUTING.md
3. https://github.com/zestedesavoir/zds-site/blob/dev/doc/workflow.md

Les deux premières parce que ce sont des fichiers "standard" Github.

La troisième pour donner des détails utiles seulement à ceux que ça intéresse et à ceux qui veulent faire des choses avancées (gestion des tickets, releases, …) et qui ne sont pas dans les 2 premiers fichiers pour ne pas les surcharger.

@Javier : Je peut admettre que le front ne soit pas sexy, pourquoi pas. Perso c'est le projet qui m'a attiré, beaucoup plus que le dev back. Sincèrement ce n'est pas que le front que je n'aime pas, c'est le dev web de façon général. Et du parsing de texte c'est pas non plus ma tasse de thé¹. Si je participe c'est pour faire avancer ce projet, car il me plait. Ça m'oblige a faire des trucs qui ne m'attirent pas plus que ça mais soit…

Mais meme si ce n'est pas sexy, on en reste pas moins qu'on a un seul dev front et que c'est un problème. Démonstration :

Je ne veux/peux pas jeter la pierre a Alex. Il bosse, il a envie de faire autre chose, soit. Mais du coup nous on fait quoi maintenant? C'est pour cette raison que je cherche depuis tout a l'heure a comprendre pourquoi on a pas au moins une autre personne sur le front.

Maintenant c'est a la fois plus compliqué et plus simple. D'ici peu on a plus de dev front, on ne va plus avoir le choix que de trouver quelqu'un d'autres. Et si ça oblige à faire des changement technique pour cela, on aura pas trop le choix.

C'est juste insupportable quand j'ai besoin d'une info et que je dois plus ou moins tout me taper pour la trouver. En plus, certaines fois les informations divergent d'une page à l'autre. Est-ce qu'il est possible de centraliser tout ça ?

Oui l'idéal est que toutes les infos soient centralisé dans la doc qui servira alors de référence.

@gustavi :

Bah oui c'est même très exactement ce que je dis.

J'englobe RoR et Grails dans le même sac (Symfony je connais très peu). Ce sont des frameworks élégants et agréables à utiliser. D'où une certaine attractivité pour des développeurs back.

Framework agréable, élégant, à la mode => attractivité => tout plein de devs back intéressés.

Vous seriez partis sur une pile JEE standard, sans framework, brute, je peux vous garantir que vous auriez eu moins de contributeurs.

Et pour le front c'est un peu la même chose. ZdS ne justifie pas l'emploi de frameworks agréables, élégants, modernes, et "sexys" comme AngularJS, React, Mithril ou plein d'autres. C'est du standard, que tu peux trouver partout. C'est normal pour un site éditorial. Vous auriez construit une plateforme d'update temps-réel de news j'aurais tiqué, mais pour ZdS c'est parfaitement sensé.

@Kje : oui le projet est attirant. Mais on peut demander aux dev back, tous s'y sont mis parce que le projet les intéressait et un ptit peu aussi parce que c'est attractif. SpaceFox a chanté les louanges de Django, gustavi aussi un peu plus haut. Ça joue forcément. On ne peut pas mettre ça de côté.

EDIT : Autre bonne explication aussi de gustavi ci-dessous.

EDIT² pour Kje : En fait il y a beaucoup de façons de contribuer à ZdS. Je comprends ton point de "je l'ai fait parce que le projet m'intéresse, pas parce que c'est intéressant techniquement". Bah en fait c'est la même pour moi. Je trouve ZdS génial et je vais aider partout où je peux, en donnant mon avis, des conseils, en relisant les cours en bêta sur lesquels je suis compétent. Pour la technique, si ça ne m'intéresse pas je ne vais pas me faire violence pour la beauté du projet. Si je m'étais investi à l'époque où il n'y avait que la technique, comme firm1, comme SpaceFox, comme toi, alors ce serait sans doute différent.

Je pense tout simplement que le dev front est beaucoup plus compliqué quand on débute. Les issues faciles du back sont corrigeables même pas un débutant, pour le front c'est pas évident (à l'époque j'avais regarder un peu mais il n'y avait pas de doc, quand tu touches à un truc faut regarder sur n navigateurs, sur m tailles d'écrans bref c'est pas aussi simple que de balancer un flake8 et des tests unitaires). Alex-D a fait un travail remarquable et je l'en remercie, surtout que c'est pas facile de bosser seul sur un projet/une partie d'un projet.

Vous avez les gros arguments qui font que ZdS me lasse : ça n'est techniquement pas très intéressant. C'est un très bon exercice de style, mais au delà de ça, c'est tout.

Et ce que Javier est vrai : chaque dev front code son truc à sa sauce, ce qui fait qu'une doc ne servirait à rien pour le prochain car quelqu'un de bon saura lire le code, le comprendre et l'adapter/refaire à sa sauce.

Pour donner un ordre d'idée, je viens de commencer dans une entreprise, je remplace 3 personnes qui sont parties ces deux dernières semaines et il n'y a pas de doc : j'ai déjà recodé certaines pages. Et Bootstrap n'est pas une solution, j'ai vu des choses vraiment très mal réalisées malgré l'intégration de Bootstrap dans le projet.

Quand gustavi dit "j'utilise foundation c'est simple, là c'est compliqué" tu compare un simple framework au style d'un site complet et complexe avec des dizaines de vues différentes et des interfaces parfois complexes et variables. Foundation c'est une base et ils te fournissent à la fois les sources et le livrable.

Dans l'absolu, ce qu'on peut faire, mais qui est moche, c'est d'inclure les exports CSS, JS et images dans le dépôt. C'est immonde, mais tout le monde aurait tout à jour sans problème. Seul risque : quelqu'un qui modifie les fichiers compilés et qui serait écrasé à la prochaine modification propre.

Par curiosité Javier : quels choix techniques tu aurais fait sur un site tel que ZdS ? C'est le choix du from scratch qui te repousse ?

Tout d'abord, je tiens à m'excuser pour mon coup de gueule de ce matin. J'ai très franchement pas l'habitude d'être aussi violent, et j'étais un peu sur les nerds, en voyant ce qui me paraissait une n-ième attaque envers le front, pour essayer d'enlever nos outils, jugés trop compliqués, et pas fiables.

En voyant la suite de la discussion, il ressort quelque chose d'intéressant, et qui, pour le coup, me concerne: le front n'est pas sexy du tout.

Au début, j'ai rejoint ce projet déjà parce que Eskimon m'en parlait depuis des mois, et ensuite parce qu'en voyant les premières versions du sites, je trouvait que ça avait de la gueule.

J'ai commencé à contribuer, mais en soit, j'ai pas fait grand chose. J'ai beaucoup travaillé sur les outils, avoir un workflow plus moderne. Je rappelle qu'avant, les fichiers CSS compilés étaient dans le répo, et alourdissait les diff comme pas possible, et les dépendances type jQuery étaient incluent dans le projet. C'était bien dégueu, mais apparemment plus simple pour 95% des contributeurs, c'est à dire les devs back.

En soit, je suis certes un "dev front", mais je suis plutôt dans la catégorie "JS" que "design". Demandez moi de faire une maquette de page, comme Alex l'a fait récemment pour la homepage, je ne saurais pas faire.

Sauf que dans ce projet, niveau JS, y'a que dalle. Du coup, en ce moment, je suis le projet seulement de loin, en faisant des hotfix/de la QA par ci par la…

Après, y'avait le rêve d'Alex, qui m'a fait continuer sûrement plus longtemps, qui était de justement, dynamiser à mort le site côté client. On était pas loin d'une appli single-page dans l'idée. Peut-être que ça se fera un jour, mais on a toujours pas d'API sur laquelle se baser.

Peut-être qu'effectivement, le jour où le front sera plus intéressant, il y aura de nouveaux contributeurs pour le front. En attendant, le front, pour un site comme ça, nécessite une certaine expérience, et est, à la fois, complètement inintéressant pour quelqu'un d’expérimenté…

Et je doute que ça soit une question d'outil, ou même de doc

En espérant que ce message choquera moins que le précédent,

Sandhose

Et ce que Javier est vrai : chaque dev front code son truc à sa sauce, ce qui fait qu'une doc ne servirait à rien pour le prochain car quelqu'un de bon saura lire le code, le comprendre et l'adapter/refaire à sa sauce.

Pas forcément quand même.

Pour avoir été à la place de quelqu'un qui met les pieds dans du code front contraint et forcé (réduction de budget, tout le monde met la main à la patte, …), je peux te garantir que sur un framework fait maison, une doc aide quand même pas mal. C'est pas la panacée mais ça permet de rentrer dans le code plus rapidement, même si une relecture complète sera nécessaire.

Pour donner un ordre d'idée, je viens de commencer dans une entreprise, je remplace 3 personnes qui sont parties ces deux dernières semaines et il n'y a pas de doc : j'ai déjà recodé certaines pages. Et Bootstrap n'est pas une solution, j'ai vu des choses vraiment très mal réalisées malgré l'intégration de Bootstrap dans le projet.

Ça n'empêche pas de mal réaliser certaines choses. Cependant j'ai vécu la transition 1 dev front (intégrateur) => 0 dev front que des dev back. Et Bootstrap a énormément aidé sur ce point. Ses conventions sont assez faciles à comprendre pour n'importe quel développeur. Une fois le gros boulot pénible de "je surcharge Bootstrap pour qu'il colle à notre identité visuelle", ça rend quand même le boulot plus simple pour des développeurs qui ne sont pas spécialisés dans le front (c'est mon cas par exemple). L'énorme avantage, c'est que la doc est déjà écrite. En gros : adaptation de Bootstrap (ou un autre hein) à notre charte / identité visuelle, pour le layout on essaie de conserver le comportement de la doc. C'est pas la panacée absolue mais ça permet de s'en sortir.

Dans l'absolu, ce qu'on peut faire, mais qui est moche, c'est d'inclure les exports CSS, JS et images dans le dépôt. C'est immonde, mais tout le monde aurait tout à jour sans problème. Seul risque : quelqu'un qui modifie les fichiers compilés et qui serait écrasé à la prochaine modification propre.

C'est peut-être plus simple pour quelqu'un qui ne touchera qu'au back, c'est une piste à creuser que j'ai déjà vue appliquée en pratique.

Par curiosité Javier : quels choix techniques tu aurais fait sur un site tel que ZdS ?

Au niveau layout CSS, comme c'est vraiment pas mon métier à la base, si j'avais du m'y coller, j'aurais choisi Bootstrap pour les raisons citées plus haut.

1. Je serais quand même allé plus vite mine de rien. Ça me prend toujours du temps de faire de la CSS "from scratch" j'ai pas vraiment les bons réflexes et j'ai parfois du mal à debugger du CSS. Bootstrap m'a souvent aidé sur ce point. Notamment pour des colonnages "responsive" ou ce genre de choses. Quand je commence à fouiller dans les mediaqueries ça finit généralement en une CSS relartivement difficile à lire. Donc en connaissant mes faiblesses, j'aurais cherché à les contourner comme cela.

2. La doc. C'est con mais dire "c'est un bouton de soumission tu lui appliques la classe btn-submit comme c'est marqué dans la doc" bah ça va quand même plus vite que ré-écrire une doc. Sur ZdS c'est un peu le cas déjà, mais autant essayer de coller au plus près des normes qu'ils ont établies, ça permet de bénéficier de leur doc.

3. Le côté "chat perché". Justement pour ce qui se produit en ce moment si tu quittes le projet. T'as un bon argument pour dire "c'est pas la mort, vous prenez n'importe quel zozo qui connaît Bootstrap et vous lui montrez bootstrap-zds-override.css" et il devrait s'en sortir s'il est pas totalement manchot.

4. L'approche déclarative que je trouve plus lisible. Je surcharge bootstrap à UN endroit, après on retrouve l'organisation que tu as sans doute mise en place (un fichier css par famille de composants : forms, …). Le fait d'utiliser Bootstrap renforce un peu cette approche, puisque tout ce qui est différent du Bootstrap de base peut se trouver dans un seul et même fichier.

Au niveau JS la question est délicate.

Je n'aime pas faire du Vanilla JS, mais sans doute parce que je ne crée pas de site comme ZdS. Je fais essentiellement des UI de pilotage d'écrans, de gestion d'énormes monceaux de données, de présentation de trucs qui s'update en temps réel, qui bougent beaucoup etc. Voire des petits bouts d'app mobiles avec PhoneGap (toujours avec pas mal de contraintes d'interactivité, de réactivité, …). J'ai quasi-systématiquement besoin de me reposer sur une API pour me servir les données (et c'est d'ailleurs plus découplé et un peu plus facile à tester finement) et d'un framework JS pour organiser la page.

J'ai utilisé AngularJS, beaucoup, React, un peu, et j'ai vu Mithril par curiosité. Je comprends l'intérêt de React quand il y a un vrai soucis de performances. Je préfère par contre énormément l'approche AngularJS beaucoup plus déclarative. En regardant le template tu comprends mieux la structure de l'application et ses différents composants. La logique est bien découpée, bien séparée.

Maintenant pour ZdS est-ce-que c'était possible ? Non. Ou alors il aurait fallu partir sur une API à t0. Est-ce-que c'était un choix raisonnable d'imposer ça ? Non, probablement pas. Les écrans sont très statiques. Les templates Django m'ont l'air plutôt bien fichus (et encore une fois, plutôt dans l'ère des frameworks modernes plebiscités) donc autant en tirer parti. Il y a fort à parier qu'avec Angular ou un autre, la difficulté de transition avec un autre développeur aurait été encore plus grande. Et je ne pense pas qu'il y en avait réellement besoin. Seule la partie éditeur markdown (voire édition de tutoriel) aurait pu faire l'objet de cette réflexion (glisser / déposer pour organiser son tutoriel, …).

Maintenant, au niveau des outils techniques… Dur pour moi d'y répondre. Je n'aime pas "les outils front" tout seul. (genre gulp, grunt, et consorts). J'ai besoin qu'ils s'intègrent avec les outils du back. Si je prends par exemple mon projet perso (dont je parle vaguement ici), j'ai besoin de SASS, évidemment, d'Angular, puis de plein d'autres choses. Je vais avoir besoin de minifier les fichiers en prod mais pas en dev, bref, standard. J'ai essayé de ne travailler qu'avec des outils standards fournis par la plateforme (en l'occurrence des plugins Grails lui pour gérer les ressources et comment elles sont organisées et servies, lui pour angular, lui pour compiler à la volée en dev et minifier en prod, lui pour les menus, fil d'ariane etc.), quitte à mettre un peu de côté des fonctionnalités si jamais je ne pouvais pas les implémenter de façon standard.

Autre exemple, contexte pro. Si jamais on ne peut faire autrement que de faire appel à des tâches "front" (gulp, grunt, node, …), alors j'essaie de les wrapper dans un mécanique de build connu (plugin maven, tâche ant, ou mieux : tâche Gradle) pour que ce soit "découplable". Je ne sais pas si ce dont je parle s'applique à un projet Django, mais la lourdeur du processus d'install que vous décrivez serait sans doute (au moins partiellement) résolue par Gradle et une séparation en sous-tâches "setup-dev-environment", "build-back-only", "run-back-tests", le tout attaché à des scripts qui font le boulot pour vous (e.g. récupérer le résultat du build des fichiers scss et ne pas y toucher après, ou que sais-je encore).

Je comprends que vous ayez fait appel à ces outils, mais ça me rend barge quand ce n'est pas correctement wrappé dans une mécanique de build connue et surtout commune à tout le monde. Sur un projet Java par ex. un dev back qui ne connaît pas Maven ou Ant (et plus récemment Gradle) ça me semble rare. Il sera à même de comprendre où et comment sont invoqués certaines tâches qui ne l'intéresse pas. "Ah ouais mais pourquoi je faire un gradle build-all j'ai pas besoin du front ! Bref, c'est un peu naïf expliqué comme ça sans connaître les outils existant en Python+Django.

C'est le choix du from scratch qui te repousse ?

Non, c'est le temps déjà, soyons honnête deux secondes. Je sais le temps que ça prend et j'ai envie (et presque besoin, en fait) d'avancer sur mon projet perso.

Ensuite, je suis incapable de faire ce que tu as fait visuellement, c'est pas mon métier. Je sais me débrouiller pour intégrer des maquettes et réfléchir sur l'ergonomie d'une interface, mais là y'a un vrai travail de design que je n'aurais pas pu faire moi-même (ou alors ça m'aurait pris un temps fou, que je peux me permettre sur mon petit projet à moi, mais pas sur ZdS).

Enfin, je l'ai dit, il y a 50 bonnes façons de s'investir dans ZdS, et développer en front pour ce site ne m'intéresse pas. Je le fais à ma sauce sur mes projets, je bidouille avec des frameworks inconnus au bataillon, … Bref, je m'amuse. Ici j'aime participer, essayer d'apporter un éclairage quand je pense que je suis à peu près compétent sur un domaine, aider quand je le peux. ZdS n'est pas le bac à sable dont j'ai envie côté front. Et je suis certain que je ne suis pas le seul, c'est pour cela que je faisais cette remarque à Kje.

Et je comprends aussi très bien qu'un dev back qui n'a quasiment jamais touché au front (autrement que pour s'amuser) ne puisse pas le comprendre. Je fais les deux, je m'éclate à chercher des solutions élégantes pour construire des APIs par exemple, ou modéliser un truc tordu de façon élégante côté back pour que ce soit réutilisable etc. J'aime ça, et ZdS est totalement là-dedans. Le module de cours est complexe, repose sur Git, etc. Une API se met en place et est vraiment cruciale pour le développement du site, et est vraiment destinée à quelqu'un d'autre qu'à toi-même (honnêtement c'est rare ce genre de projets, dans 80% des cas ton API tu la mets en place pour UN client voire le mec assis juste à côté de toi, ou un mec d'un service deux étages plus haut). C'est un excellent terrain de jeu et d'apprentissage. Depuis les specs jusque dans les tests.

Mais côté front on ne retrouve pas ça. Et je trouve dommage que certains ne le voient pas. Je pense qu'il faut imaginer un dev back sur un projet de gestion (genre avec que des lignes de saisie, des taux de TVA, et des rapports Excel à générer), le modèle est "straightforward", c'est des lignes les unes derrière les autres, Excel pourrait le faire mais le client veut un truc custom en Swing. Et attention : pas le droit à l'erreur, parce que d'une "C'est quand même pas bien compliqué pour quelqu'un comme toi !!" et de deux "c'est sensible !", ouais, mais c'est chiant à mourir.

Si certains dev back ne pigent pas trop le sentiment de Sandhose ou Alex, essayez de vous représenter cela. Pour un dev front, ZdS ça peut revenir un peu à ça.

Ensuite j'aimerais revenir deux secondes sur la réflexion de Shigerum. Alors j'ai pas toute la vue du projet, des gens, de ce qui se passe en coulisse etc. Mais je trouve, moi, ton message plutôt exécrable. Alors qu'on recherche des solutions (techniques d'abord, humaines ensuite) à un problème plutôt complexe honnêtement et qui mérite sans doute une bonne grosse dose de recul, parce que oui, ça fait intervenir l'humain, on est sur un projet non-professionnel : les gens ont pas nécessairement envie que ça leur bouffe du temps, et leur moral. Je suis pas vraiment convaincu que de rentrer dans le lard des deux principaux intéressés soit franchement la meilleure réaction à adopter.

J'peux comprendre un certain agacement suite au message de Sandhose (qui a bien fait de s'excuser je le répète), mais il y a des réflexions et des mots pour lesquels je ne vois pas d'autre intérêt que de blesser. "le site d'Alex qui est trop claaaaaaaasse" : ça veut dire quoi sincèrement ? Etc.

Vraiment déçu pour le coup. Je m'étends pas plus parce qu'il y a certainement des raisons que je ne connais pas qui te poussent à penser cela. Soit.

Pas le temps de détailler, mais en effet tu n'as pas toute la vue du projet. D'ailleurs peu de personnes l'ont et c'est bien cela qui m'embête, car on peut chercher des solutions dans tous les sens, si on ne prend pas la peine d'évoquer tous les problèmes alors on manquera forcément quelque chose. Ce que j'ai dit ici, ça fait des MOIS que c'est également dit en privé, sans aucune réelle remise en cause de l'intéressé. Alors je le redis : le comportement qu'a eu Alex fait partie des problèmes et est l'une des causes (pas la seule) du manque de dev front. Plusieurs personnes que je ne nommerai évidemment pas ont clairement dit ne pas vouloir (ou ne plus pouvoir) travailler avec lui à cause de son comportement. Donc oui, c'est un problème et il faut le dire, car en le taisant on continue à laisser pourrir la situation. Maintenant, ce n'est qu'une des composantes du problème, on est bien d'accord.

Je peux comprendre que zds n'est pas sexy pour le front. Techniquement pour moi même le back ne l'est pas. Mais on va pas débattre sur ça pendant encore des pages et des pages.

Je trouve au passage ta réflexion sur le front et les outils assez intéressante.

Pour revenir au sujet je pense que le plus urgent actuellement est de préparer la transition sur le front.

PS: peu de personnes ont réagi au message de shig car effectivement on ne peut pas cacher qu'Alex a eu des "problèmes relationnel" avec pas mal d'autres membres.

Pour autant maintenant il faut passer outre et préparer son départ.

Alex, tu as parlé de plusieurs taches a finir avant ton départ, tu pense qu'elles seront terminés quand ? En gros ça nous aiderai de savoir quand tu va prendre du recul pour savoir le temps qu'on a pour s'organiser.

Quelqu'un a une idée sur comment on peut organiser "l'après Alex" ?

Bon, j'avoue je ne pensais pas que que ce topic prendrait tant d'ampleur. J'aimerai quand même qu'on se recentre sur le sujet principal : comment rationaliser au maxium les outils..

La question du pourquoi du manque de devs front est compliqué a expliquer aujourd'hui (beaucoup de raisons ont été cités). Mais comme l'a précisé Vayel, le problème touche aussi les devs back. Pour moi le fait de rationaliser les outils permettrait d’épurer le setup et donc ouvrirait la porte à plus de personne en entrée (front comme back).

J'ai noté dans les interventions des choses intéressantes. Je pense qu'il est important qu'après la rationalisation, on permettent aux devs front de garder leurs outils s'ils le veulent, mais aux devs back d'avoir une stack d'outils un peu différente avec laquelle ils peuvent faire tout ce qu'ils veulent. ça devrait être possible, mais je suis incapable de vous la sortir aujourd'hui sans avoir testé personnellement. En gros, ça reviendrait à faire en sorte que pour les habitués du back-end le build des scss et js se ferait avec une stack en python et nous aurons une stack (optionnelle) à base de Nodejs pour les devs front-end. ça permettrai de ne leser personne.

Aussi concernant les évolutions de ZdS, Javier a cité de nombreux outils sympa. Pour moi ce sont clairement des outils qui vont arriver dans notre Stack (je pense à des trucs comme Angular), mais ça serait du suicide de les faire rentrer aujourd'hui (principalement parce qu'il serait très mal utilisé tant qu'on a pas d'API).

Javier a aussi evoqué des trucs comme Bootstrap, certains connaissent bien mon avis la dessus. Pourquoi refaire des trucs from scratch alors qu'il existe des Frameworks qui font déjà le travail et qui sont pas mal éprouvés (sur toutes les plateformes) depuis ? Je pense aussi que c'est une des causes du manque de personnes coté front aujourd'hui. Je l'ai déjà dit depuis un moment, si on était parti sur un override d'un frameworks css, on aurait certainement aujourd'hui des gens capables de faire des correctifs simples sur le design. Aujourd'hui on a un framework maison et taillé au poil, c'est vrai, mais personne ne le connais, sa doc est presqu'inexistante, et surtout on a des bugs un peu partout qui donne l'impression de refaire en moins bien ce qui existe déjà ailleurs. J'encourage donc vivement d'ouvrir un topic sur "comment faire si Alex nous quitte ?" parce que c'est un vrai problème aujourd'hui. C'est comme avoir un site sans backup.

"comment faire si Alex nous quitte ?"

Plutôt "Évolution du front post-Alex" puisque son départ semble acté, il faut faire avec

Maintenir deux stack d'outils en parallèle c'est la garantie d'avoir des incompréhensions et des bugs mystiques.

On a une config assez finement réglée dans le gulpfile, si on change quelque chose dedans il faut aussi changer dans la stack python et donc on a pas les compétences.

En gros, ça reviendrait à faire en sorte que pour les habitués du back-end le build des scss et js se ferait avec une stack en python et nous aurons une stack (optionnelle) à base de Nodejs pour les devs front-end. ça permettrai de ne leser personne.

Tu décris quasiment un système de build comme Gradle là.

Je ne sais pas si tu connais, mais j'imagine que tu connais Maven et Ant. Je pense vraiment que c'est vers cela qu'il faut que vous vous dirigiez.

Tous les nouveaux frameworks que j'utilise ont fait ce choix, même ceux qui historiquement avaient leur propre système de build (et plutôt sacrément bien foutu). Du genre Grails, qui a foutu son système de build/gestion de dépendances entier à la poubelle pour le remplacer par Gradle.

On peut citer Rake aussi, qui, je pense fait plus au moins la même chose. Je pense qu'il faut vraiment vraiment s'inspirer de ce que font ces outils. Essayer de trouver un équivalent en Python.

A mon avis les idées principales à retenir :

• On doit pouvoir déclarer les dépendances dans un fichier de configuration (influences/docs/a regarder : Maven, Gradle, pip ?)

• On doit pouvoir définir des environnements simplement "je suis en mode dev back, dev front, les deux, pre-prod, prod, …" (influences : Gradle, Grails)

• On doit pouvoir découper le build en différentes tâches, et les lancer indépendamment (influences : Ant, Gradle, Rake, make). Il est possible d'établir une hiérarchie entre tâches gradle eclipse (prépare mon projet sous Eclipse) dépend de gradle pullDependencies (va chercher toutes les dépendances du projet) mais fait plus que ça, il génère les .classpath, .project, et tout le tralala.

• Les mêmes outils ne sont pas nécessaires aux différentes tâches (influence : Gradle. compile "org.apache:commons:3.0" vs. testCompile "org.apache:commons-lang:2.1". Deux phases différentes (compilation et lancement des tests) => dépendances différentes. Permet par exemple si on a besoin d'énormément de dépendances pour les tests d'avoir un processus de build très long pour les tests, très court pour la mise en prod une fois que les tests sont effectués)

• le fichier de configuration (pom.xml, build.xml, build.gradle, …) est clair, compréhensible, et peut quasiment servir de doc à lui tout seul

Exemple : ce que Vert.x a construit avec Gradle

• il est indispensable de pouvoir lancer les outils front depuis cet outil de build (donc un bridge, un plugin, n'importe quoi de dispo pour faire ça). Et si possible, la config des outils front doit être déclarée au même endroit pour pas maintenir 43 fichiers de config (pas possible avec tous les outils front, pas forcément adapté dans tous les projets non plus)

Voilà à mon sens quels sont les sources d'inspiration pour avoir le système de build "parfait" (en gros, ton truc en une seule commande). Ça passe par un DSL en Python qu'il faut trouver (pas simple, mais en cherchant Rake equivalent Python sur Google j'ai vu quelques pistes qui va te permettre de décrire très simplement les différentes tâches.

Aussi concernant les évolutions de ZdS, Javier a cité de nombreux outils sympa. Pour moi ce sont clairement des outils qui vont arriver dans notre Stack (je pense à des trucs comme Angular), mais ça serait du suicide de les faire rentrer aujourd'hui (principalement parce qu'il serait très mal utilisé tant qu'on a pas d'API).

Les outils front y'en a plein, et ils sont tous très sympa pour peu qu'on les utilise pile dans le domaine où ils sont bons et intéressants. Mais je pense qu'en l'état ZdS n'en a pas besoin, non. Les deux pistes sont l'éditeur zMarkdown, voire un éditeur à plusieurs en simultané, avec un système de communication/synchro par websockets. Ça, ça serait un projet ultra sexy et formateur pour le front. Et là, y'aurait besoin de sacrés outils.

Javier a aussi evoqué des trucs comme Bootstrap, certains connaissent bien mon avis la dessus. Pourquoi refaire des trucs from scratch alors qu'il existe des Frameworks qui font déjà le travail et qui sont pas mal éprouvés (sur toutes les plateformes) depuis ? Je pense aussi que c'est une des causes du manque de personnes coté front aujourd'hui. Je l'ai déjà dit depuis un moment, si on était parti sur un override d'un frameworks css, on aurait certainement aujourd'hui des gens capables de faire des correctifs simples sur le design.

Sur le papier ouais. En pratique, c'est pas forcément toujours vrai malheureusement. "C'est pas aussi simple" je dirais, bien malheureusement. Là où le bas blesse, c'est quand tu commences à vraiment t'écarter de Bootstrap (pour avoir un site qui a sa propre identité visuelle), une fois sur deux Bootstrap va te casser les pieds (pourquoi il vient me coller du style sur des balises html et pas uniquement sur une classe ? fous moi la paix) voire carrément être un boulet à traîner qui va te faire écrire plus de code que si tu ne l'avais pas (donc exit la lisibilité). Donc ça peut devenir embêtant quand même… Parfois pire qu'un framework maison parce que tu pars du principe que dans Bootstrap ça fait ça, mais dans notre contexte non, t'es paumé, tu perds du temps, … Donc, oui et non :\ malheureusement.

@Alex : la config des outils front il faut la "wrapper" dans une config de plus au niveau. Par défaut les gens ne lancent pas ta tâche de build front, par contre ils ont besoin de son résultat.

Quand on y reflechit bien, si on s'arrange pour que les devs front utilisent ceux qu'ils veulent et qu'ils livrent justes des scss et des js en fixant par exemple la barre au niveaux de la version de sass suportée, on aurait aucun différentiel (en tout cas pour les points 1 et 2 du premier post). Pour le reste il faut creuser, mais c'est sur que si on ne cherche pas, on ne trouvera pas de solution.

Je connais pas Gradle aussi bien que Maven. Mais oui, j'ai le fonctionnement de Maven en tête qui pour moi reste un must.

C'est déjà ce qui est fait aujourd'hui

C'est clairement ce qu'on fait mal aujourd'hui je pense.

On est pas excellent là dessus aujourd'hui, mais je crois qu'on y arrive plutot bien.

Je pense plutôt qu'on devrait fuir la verbosité du xml de ce coté là. Mais c'est mon avis.

Je ne vais pas te cacher que j'ai quelque peu une sainte horreur de Rake, mais ça c'est surement personnel. Je vais tout de même y re-jeter un coup d'oeil.

Peut-être que Bootstrap devient très contraignant sur la durée, mais ce n'est pas le seul Framework css qui existe, il y'en a un paquet bien documentés et assez éprouvés.

Oui moi aussi. (il faut un langage qui permet à la fois de décrire une config, et d'écrire de petits scripts, c'est pour cela que Gradle a choisi Grrovy, ils l'expliquent là).

We think the advantages of an internal DSL (based on a dynamic language) over XML are tremendous in case of build scripts. There are a couple of dynamic languages out there. Why Groovy? The answer lies in the context Gradle is operating in. Although Gradle is a general purpose build tool at its core, its main focus are Java projects. In such projects obviously the team members know Java. We think a build should be as transparent as possible to all team members.

You might argue why not using Java then as the language for build scripts. We think this is a valid question. It would have the highest transparency for your team and the lowest learning curve. But due to limitations of Java such a build language would not be as nice, expressive and powerful as it could be. Languages like Python, Groovy or Ruby do a much better job here. We have chosen Groovy as it offers by far the greatest transparency for Java people. Its base syntax is the same as Java's as well as its type system, its package structure and other things. Groovy builds a lot on top of that. But on a common ground with Java.

For Java teams which share also Python or Ruby knowledge or are happy to learn it, the above arguments don't apply. The Gradle design is well-suited for creating another build script engine in JRuby or Jython. It just doesn't have the highest priority for us at the moment. We happily support any community effort to create additional build script engines.

C'est très clairement un wrapper propre qui vous manque. Si vous en trouvez un bon, le reste c'est plus que de l'organisation et description des tâches. C'est pas forcément facile hein (comment on découpe, toussa) ça va demander des itérations mais le plus dur sera fait. Bon courage dans tes recherches, j'ai maudit Maven et sa lenteur (même pour lancer des plugins simples) pendant des années avant de trouver ce que je considère aujourd'hui comme la panacée. Je ne peux pas concevoir que personne n'ait déjà développé un système intelligent de ce genre et interopérable avec Python.

N'hésite pas à me poser autant de questions que tu en auras. Si jamais j'ai la réponse sur "comment c'est fait dans d'autres systèmes / langages" je te répondrais avec plaisir.

Bon week-end à tous.

Sur le front on a déjà notre fichier de build avec toutes nos tâches : https://github.com/zestedesavoir/zds-site/blob/dev/Gulpfile.js

Et on a "build" pour la prod / back et "default" pour les dev front. Donc ce travail là on l'a déjà réalisé. Là n'est pas le problème. Ce qui semble déranger c'est la nécessité d'installer un outil de plus (node.js) pour utiliser tout ça. Donc il faudrait "simplement" convertir ce Gulpfile en quelque chose d'équivalent. Le soucis c'est de trouver l'équivalent.

Quand on y reflechit bien, si on s'arrange pour que les devs front utilisent ceux qu'ils veulent et qu'ils livrent justes des scss et des js en fixant par exemple la barre au niveaux de la version de sass suportée, on aurait aucun différentiel (en tout cas pour les points 1 et 2 du premier post).

Nop, on utilise une stack conséquente qui ne se limite pas à du Sass basique. Autant pour tout ce qui est uglify, Sass, etc on trouvera ce qu'il faut. Autant pour la génération des sprites ou encore l'auto-prefixage des propriétés, ça va être beaucoup plus compliqué je pense.