-

Bon et bien je crois que l'avis est unanime. Je pense qu'il va falloir faire un bon sujet dans la dev zone concernant ce point et plus généralement la refonte du module de cours.

J'approuve, parce que pour le moment, y'a plein de code qui se répète.

Ce thread rejoint donc celui sur le système de PR sur les tutos. Quitte à refondre le module, autant l'inclure dans le design au même moment.

Ca va probablement être le premier gros morceau de la vie du site public en termes de développement.

Notamment l'occasion de voir comment réellement bosser à beaucoup sur "du code neuf", avec les problématiques de qui-fait-quoi, et surtout de mettre au point à plusieurs des specs très précises en amont de tout ça.

L'occasion en or de faire valoir ton titre de DTC

Exactement, ça me met un coup de pression d'un coup.

Je pense au passage que les articles devraient être revus pour factoriser le code au maximum. Et techniquement utiliser des classes abstraites pour faire l'équivalent des interfaces Java, histoire que côté front on ait tout le temps les mêmes noms de variable.

Et techniquement utiliser des classes abstraites pour faire l'équivalent des interfaces Java, histoire que côté front on ait tout le temps les mêmes noms de variable.

Non. Ça n'a absolument aucun intérêt d'utiliser des classes abstraites pour ça en Python. Pire encore, c'est une très mauvaise pratique en Python que de chercher à faire "comme en Java" ou "comme en C++" ; ça aboutit systématiquement sur un code inutilement lourd et non idiomatique.

Non mais cela dit, sans s'attarder sur l'implémentation technique, définir un contrat sur la structure des objets côté serveur pour rendre le travail des devs côté client beaucoup plus simple, ça par contre c'est une bonne pratique, et pour avoir fait été des deux côtés de la barrière dans ma carrière, voire dans l'entre-deux avec le développement et l'utilisation d'APIs, je peux t'assurer que c'est pas du tout un luxe

Ah, ça je dis pas le contraire. Je réagissais juste au post d'Alex qui disait une aberration technique.

Et ca vaut le coup d'en faire encore 3 post ? Franchement c'est gratuit la. Ou alors vous savez pas lire entre les lignes. Alex dit en substance qu'il faut uniformiser les choses pour avoir un truc propre (tout le monde n'est pas pro du python et peut donc faire des comparaisons hasardeuses avec d'autres langages). OK il c'est ptet plante, j'en sais rien je debute en Python. En attendant il y a une idee, on prend ou pas mais pas la peine de chambrer la dessus.

Bref : l’idée de fond : Faire un truc uniforme pour simplifier le travail des deux cote.

Euh, j'espère que ton message s'adresse pas à moi, parce qu'en substance c'est exactement ce que j'ai écrit.

Bien sûr que l'idée de fond est bonne. D'ailleurs, pour information : il n'y a besoin d'aucun mécanisme technique particulier pour ça.

Par contre, d'un point de vue plus global, il faut bien se rendre compte qu'on est partis d'une feature permettant de créer des tutos de taille intermédiaire, et qu'on en arrive déjà à se dire "il faut refaire tous les tutos et les articles".

Je ne dis pas que ce n'est pas justifié, mais je pense qu'il faut aussi introduire quelques éléments de réalité là-dedans :

• on n'a pas, en date, les ressources pour absorber cette charge (grosse refonte de la moitié du site), il va donc falloir recruter,
• ça va être long à développer et très long à QA-iser,
• ça demande dès maintenant un travail de spécification minutieux (et assez gros) qu'on devrait pouvoir lancer rapidement, à condition qu'on l'organise correctement (ce qu'on n'a pas encore eu besoin de faire en date) : il y a déjà eu des discussions sur le processus de spec, mais vu qu'on est en freeze actuellement, elles ont été remises à plus tard, donc il va falloir les reprendre et les conclure avant d'avancer,

J'en arrive donc à la question suivante, naïve, mais à laquelle il faut qu'on réfléchisse : sommes-nous obligés de faire cette évolution en une seule goulée, ou bien est-ce qu'on peut la séparer en étapes intermédiaires ?

J'en arrive donc à la question suivante, naïve, mais à laquelle il faut qu'on réfléchisse : sommes-nous obligés de faire cette évolution en une seule goulée, ou bien est-ce qu'on peut la séparer en étapes intermédiaires ?

J'ai envie de te dire qu'il faudrait déjà qu'on définisse les spec sur ce que l'on veut obtenir, le comparer à ce qu'on a pour en déduire si il y a un chemin possible par étape. Mais tant qu'on a pas eu le débat sur les spec complete de la refonte du systeme de tuto, on pourra pas y répondre.

J'étais en train d'éditer pour dire exactement ça en même temps que tu postais.

J'étais en train d'éditer pour dire exactement ça en même temps que tu postais.

Je connais un renard qui te dirais qu'il ne faut pas éditer pour rajouter des commentaires de fond

PS: La rançon de la gloire, ne plus avoir le temps d'éditer

Va dire ça à celui qui a implémenté le filtre antispam de 15 minutes : je réfléchis trop vite pour lui.

Oui mais il t'aura à l'usure !

Fais-nous une PR qui désactive le filtre pour le Staff.

J'avais suggéré que ce soit désactivé pour le staff, mais firm1 n'avais pas souhaité ça

Encore heureux ma foi.