ZEP-12 : refonte du principe des tutoriels et articles

Avec pour base atomique ... l'extrait

Le problème exposé dans ce sujet a été résolu.

Bien le bonjour,

Tout d'abord, mes excuses pour mon non-investissement sur cette ZEP (mémoire). Je suis et je reste cependant convaincu qu'elle DOIT voir le jour et que j'y aiderai d'une manière ou d'une autre. Je meurt d'envie d'y toucher, mais si je fait ça maintenant, je bousille ma session d'examen. Je vais donc me faire violence et je recommencerai à chipoter à ça dans un mois très exactement.

Dans tout les cas, je ne suis pas uniquement venu ici pour vous parler de ma (inintéréssante) vie IRL. Je suis également venu faire une proposition de développement. À vrai dire, je n'ai pas bien suivi ce qu'artragis avais déjà fait (ping @artragis), parce que c'est noyé dans des commits de remise à niveau de la branche avec upstream. D'après ce que j'ai pu voir, le concept a été mis en place, "y'à plus qu'a" faire en sorte que ça s'interface avec ce qui existe déjà. Eh bien une idée m'est venue (hier), et ce n'est pas comme ça que je m'y prendrai.

Je propose au contraire de repartir sur une base propre. Puisque les deux systèmes doivent cohexister un moment, eh bien minimisons les conflits. Autrement dis: on crée un nouveau dossier dans /zds (qu'on pourrait appeler "tutorial2" ou une histoire comme ça), on redérive une nouvelle série de template (pareil, dans "tutorial2") et des nouvelles règles d'écriture d'url. But du jeu annoncé : éviter les conflits avec upstream (le développement va être long, autant éviter les MàJ foireuse qui écraseront nos modifs par erreyr), faciliter l'implémentation (puisqu'on ne touche pas l'ancien système, on ne risque pas de mettre le bronx là ou il faut pas), et permettre à la branche d'être alimentée en permanence. Puis on code, on code (convenablement, par morceau et avec des PR régulières), puis le moment voulu, on fait le switch, qui se résumera selon moi en grande partie à changer de nom les dossiers et à renommer les nouveaux. Ou pas, on peut même envisager une classe Tuto qui permettrait de "rediriger" sur l'ancien et le nouveau système en attendant que tout soit réglé coté transfo de ancien <-> nouveau.

Je suis conscient de ne pas être très clair, et peut être que l'idée n'est pas bonne et qu'il vaut mieux plus simplement aller réécrire dans les fichiers originaux. Je pense cependant que repartir sur base propre peut éviter des copier-coller faciles qui induiraient des contraintes par la suite. Je suis également conscient que c'est beaucoup de travail, mais je ne pense pas que ce soit le plus problématique dans tout ça. J'ai conscience que cette ZEP sera (très) longue à implémenter, et dès lors, je veux qu'on puisse se donner le temps de le faire.

Voilà :)

En fait le gros avantage de ce que tu propose (un deuxième module tuto en parralèle temporairement), outre faciliter le dev propre du nouveau, a aussi des avantages de transitions. On peut très bien imaginer faire une transition en douceur :

  • Un jours on branche les deux en faisant en sorte que les vues propose le contenu des deux dans les listes de tutos, et la génération de template adapté pour chacun (ducktyping power).
  • On developpe tranquillement un outils de migration ancienne version -> nouvelle version
  • On migre l'ancien contenu vers la nouvelle structure quand c'est pret et on désactive l'ancien module.

Je réfléchissais clairement à ce genre de solution pierre, parce que les heures passées à chercher un moyen de rendre la migration faisable m'ont juste convaincu qu'à l'heure actuelle, il faudra vraiment faire ça comme ça.

En fait il faudra faire ça en deux temps :

  • premier temps on passe à la version 1.zep12 où les deux systèmes cohabitent. La migration automatique permet d'envoyer les données dans les bonnes tables
  • deuxième temps, on fait une version 1.zep12_no_backup qui supprime l'ancien système de notre code.

Il faudra aussi documenter le fait qu'on ne peut pas passer directement d'une version pré v1.zep12 à une version post v1.zep12_no_backup.

Dans tout les cas, faudra en parler quand le module sera suffisament stable. Parce que là entre les améliorations de firm1 sur les commits, la zep03, les API qui arrivent et le passage à python 3 qui est envisagé…

L'API se fera par morceau, celui sur les tutos peut arriver en dernier. Idem pour le passage a python 3 : on en parle mais c'est pas pour demain. Donc continue dans le sens que tu veux/peux. C'est une zep structurellement importante, ces besoins peuvent faire patienter d'autres travaux.

Je peux bosser sur une branche à moi, c'était juste au cas où j'aurai bien avancé lorsque pierre arrivera.

Bah quand Pierre sera dispo, on pourra toujours la migrer. Faites comme vous préférez. Cette Zep est assez compliqué et importante pour ne pas vous prendre la tête avec des conneries comme ça. Demande et on s'arrangera.

Bon, demain, je me lance dans le développement d'un module en parallèle. Je le ferai sur mon propre github, je pense que le mieux c'est que les gens fassent des PR chez moi s'ils veulent aider.

artragis

Ok ok. Je vois que mon idée à du succès. Parfait :) (et merci pour avoir exprimé plus clairement que moi cette histoire de transition).

Tuez la branche ZEP-12 actuelle du dépot. Je sais que c'est moi qui l'ai demandée, mais elle n'est plus à jour et actuellement, c'est pour moi un poids plus qu'autre chose. On la recréera le moment venu (un merge directement dans dev n'est pour moi pas envisageable, il faut qu'on passe par une branche intermédiaire). Je reste convaincu que c'est une bon système de développement (rappelez vous la PR désinscription), mais pour plus tard.

Ok aussi pour bosser sur le repo local d'artragis. Comme j'ai dit, je vais tenter de ne toucher à rien pendant un mois, mais je regarderai ce qui se passe, l'histoire de :)

Bonne chance, artragis, et promis juré je reviens de filer un coup de main dans un mois. Te fous pas la pression pour ça :p

Par contre, j'ai une petite question, puisque la ZEP ne le définit pas :

Quand on développe est-ce que :

  • On ne garde qu'une table "PubliableContent" ou bien est-ce que PubliableCotent est une classe simple, et on créer Tutorial et Article qui héritent de PubliableContent et de Model?
  • La réponse à la première question a un effet direct sur les "Note".

Dans ma tête, on ne garde que PubliableContent et Tutorial ou Article soient indiqué dans un attribut de cette classe (type ?), l'histoire de vraiment faire tomber toute différence entre l'un et l'autre. On peut même envisager ceci. En pratique, ce qui différencie article et tuto, pour moi, c'est pas la manière dont il est stocké/présenté, mais ce qu'il contient.

  • Un article est bref, brosse un aperçu du sujet, est plus là pour informer et faire découvrir que pour apprendre. Et en général, il est relativement court (comparé à un mini-tuto).
  • Un tutoriel s'intéresse à un sujet et cherche à apprendre quelque chose, qu'il soit petit, moyen ou gros.

En gros, j'imagine très bien que l'auteur choisisse au début si c'est un article ou un tuto qu'il veut créer (en gardant de manière artificielle la séparation entre les deux, par exemple, comme ce qui est fait pour le moment), mais que coté back, ça change rien et que ce soit juste un attribut.

Mais c'est peut-être un peu extrême ^^

+0 -0

Tient, tant qu'on en est a réécrire quasiment un module from scratch, y'a pas moyen de coder API friendly ?. J'veux pas dire par là qu'il faut implémenter l'API en même temps (hors-scope, demande trop de temps), mais que si il y a un style à adopter (me souviens entre autre qu'on reprochait aux views.py de ne pas être écrit de la bonne manière pour favoriser le développement d'une API), autant le faire maintenant, non ? Une bonne idée pour ça serait de relie la fin de la discussion sur feu la ZEP-02. Ça et contacter qui de droit (Andr0/GerardPalinguot1 ?)


  1. si je suis bien, c'est son nom sur GitHub :) 

+0 -0

Dans ma tête, on ne garde que PubliableContent et Tutorial ou Article soient indiqué dans un attribut de cette classe (type ?)

c'est ce que je fais actuellement, mais ma philosophie c'est "les seules questions stupides sont celles qui ne sont pas posées".

Oui pouvoir passer d'article a tuto serait bien pratique. Ce n'est que du contenu.

Ok, je prévois ça.

Tient, tant qu'on en est a réécrire quasiment un module from scratch, y'a pas moyen de coder API friendly ?. J'veux pas dire par là qu'il faut implémenter l'API en même temps (hors-scope, demande trop de temps), mais que si il y a un style à adopter (me souviens entre autre qu'on reprochait aux views.py de ne pas être écrit de la bonne manière pour favoriser le développement d'une API), autant le faire maintenant, non ? Une bonne idée pour ça serait de relie la fin de la discussion sur feu la ZEP-02. Ça et contacter qui de droit (Andr0/GerardPalinguot1 ?)

Je vais contacter Andro/GP pour qu'ils me disent quelles sont les bonnes pratiques retenues pour l'API, je suis un peu perdu dans leur thread.

+1 -0

Elle se trouve ici, et j'encourage toutes les bonnes volonté à faire une pull request.

Oui, mais je vois pas dans quoi la faire : on peut pas merger en l'état dans dev, malgré que ça va toucher à rien. Je proposais donc de merger ça dans la branche ZEP-12 quand on aura de quoi faire.

Du reste, j'ai un peu regardé model.py, pas mal du tout, beau travail. Reste à adapter views.py en fonction (et y'a encore quelque référence à tutorial, chapter et part, dans les méthodes dans la classe Extract). Bonne chance :)

Bon, pierre et moi on a commencé à coder. On y va à notre rythme, cette zep étant juste immense, mais juste un petit indicateur :

nous avons théoriquement migré les fonctionnalités suivantes :

  • afficher un tutoriel/article offline (avec le formulaire d'édition)
  • afficher un tutoriel/article en béta (donc ajout de fonctionnalité côté article !)
  • afficher un tutoriel/article online (avec le formulaire de réaction)

Et nous avons pour ces deux modules réunis 30 lignes de moins que le module de tuto seul (à fonctionnalité égale, mais avec plus de commentaires oO)

C'est pour montrer combien la duplication de code était immense. Là on va vraiment aller vers une base saine !

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte