Un point sur le projet ZEP 12

Je m’étais promis de faire avant le premier avril un petit point sur l’avancement de la ZEP12.

Pour ceux qui ne savent pas ce qu’est une ZEP, voire qui ne connaissent pas zeste de savoir, je vous prie d’aller ici et .

Les ZEP sont souvent de très gros projets qui visent à améliorer le site d’une manière drastique ! Aujourd’hui, deux ZEP ont été menée à leur fin, la ZEP 03 qui permet aux auteurs de demander de l’aide pour améliorer leurs tutoriels et la ZEP 17 qui permet de mettre en place une API REST pour accéder aux informations publiques des membres. Elle permet aussi de gérer toujours en REST votre compte grâce à OAuth 2. Le but est bien évidemment de permettre à des applications tierces de profiter des données de zds, à terme il y aura tout (ZEP 02) mais on a commencé par les membres.

C’est super important car cela montre qu’il y a une vraie dynamique dans le développement (open source) de zds.

Une histoire d’offre et de demande

La ZEP 12 consiste à refaire de 0 notre module de tutoriel. La spécification de la ZEP 12 a été réalisée par pierre24, et pour y arriver, il a fallu que nous prenions en compte pas mal de choses.

Je sais que certains laissent entendre que le développement web, c’est le développement du pauvre, facile, peu de défi blablabla.

ZDS est un site de contenu, autrement dit, développer en backend, ça veut dire faire du CRUD. Oui, mais…

ZDS est un site de tutoriel, en fait cela a deux impacts très forts :

  • La demande (c’est à dire ce pour quoi les gens viennent chez nous) se trouve ailleurs (sur les forums, les questions…) que notre offre (le contenu en lui même : les tutos et articles).
  • Nous avons en fait deux communautés en une : les auteurs et les lecteurs.

Pour faire un parallèle, un blog ou un site de presse offre des articles et les gens ne viennent que pour les articles, la communauté n’est composée que des lecteurs, l’auteur c’est le journaliste ou le blogueur.

Cela signifie que nous devons travailler à contenter deux communautés, une de rédacteur qui demande un éditeur efficace, avec des fonctionnalités avancées, une mise en page simplifiée mais suffisamment personnalisable, une organisation claire mais pas trop découpée… une autre de lecteurs qui demandent une certaine ergonomie dans l’affichage, des textes pas trop longs pour ne pas s’y perdre, des forums qui ne paraissent pas vide, des accès “en un clic”, des rechargements dynamiques (ajax, websocket…).

Aujourd’hui, nous arrivons à fournir cela aux gens (sauf les websocket), mais… côté code, on a du mal à évoluer. Pour plusieurs raisons :

  • Les articles et les tutos étant deux choses sémantiquement différentes, on a créé deux modules qui ont évolué différemment, qui ont leur propre norme, qui sont documentés différemment, qui sont utilisés de… la même manière.
  • Notre modèle de données interne a été repris de celui de progdupeupl en lui ajoutant un support de git, une génération des exports avec pandoc…
  • On a une redondance très forte entre ce qui est enregistré en bdd et ce qui est gardé par git…
  • Mais cette redondance est complexe à maintenir car git versionne là où la bdd garde une image du tutoriel en brouillon.

Si on y ajoute que les performances se sont franchement dégradées (trop de requêtes, trop de double_check car sinon on a des bugs mystiques…) il fallait passer à l’action.

Alors la ZEP 12 est née.

Dilemne numéro 1 : scalpel ou marteau piqueur?

La ZEP 12 demande donc une refonte complète du modèle. On s’y est mis, on a pris notre temps pour tout comprendre les problématiques, on a débattu des différentes méthodes possibles aussi bien dans la spécification (ce qu’on va faire) que dans la conception (comment on va le faire), après une vingtaine de pages de débat, on s’y est mis. Pierre et moi nous développons donc la zep 12 sur une branche de mon fork de zds.

Mais voilà, une fois qu’on a changé le modèle, il faut adapter à peu près tout. En effet, nous gagnons tellement à factoriser (on évite les duplications de code), génériser (un tuto et un article? pareil en backend), à assouplir… que les vues doivent être revues de fond en combles.

Et là il faut se demander : est-ce qu’on reste comme aujourd’hui et on adapte simplement le code au cas par cas quitte à se ronger les doigts ou bien est-ce qu’on détruit tout?
Ce choix est cornélien, car maintenant qu’on a fait le second, il va falloir prévoir une migration des plus complexes, il va falloir s’assurer qu’on ne touche pas au SEO, il va falloir tout reconstruire le module de 0 du modèle de données aux vues en passant par les tests, les formulaires, les utilitaires… et leurs interactions avec le monde environnant.

Oui, tout cela sera long. Aujourd’hui, nous le disons fièrement, nous avançons bien ! Mieux : nous avançons avec une efficacité remarquable et nous engrangeons l’expérience, mais quelques monstres se dressent devant nous.

Parce qu’écrire du contenu c’est bien, en publier c’est mieux.

Premier défi qui nous reste à relever, la publication. Et quand je dis que c’est un défi, c’est un sacré euphémisme. En fait, l’une des plus grosses avancées de la ZEP 12 se situe dans une nouvelle méthode de publication du tuto qui permettra d’améliorer les performances et la fiabilité du site d’une manière phénoménale, tout en gardant la souplesse de notre nouveau modèle de données.

Je dis que c’est un “monstre” parce qu’on m’a toujours appris qu’on ne peut pas tout avoir. Et là je dis quoi “performance + souplesse + fiabilité”. Si j’étais commercial, on crierait au bullshit, non?
Par conception, notre modèle de publication et d’affichage des tutoriels devrait être bien plus performant, de l’ordre de 15% de demande d’IOPS en moins. Quand on sait que le module de tuto est celui qui bouffe le plus d’IO sur notre serveur, c’est pas négligeable.
Par conception, il est plus fiable puisqu’il se sert vraiment du versionning de git tel que ce dernier a été pensé, la bdd n’existe que pour savoir qu’il y a un tuto, et qui a le droit d’y accéder (les auteurs, le staff…).
Par conception, il est plus souple, puisqu’il ne possède que deux concepts :

  • une “section” est un conteneur qui peut contenir soit
    • Rien
    • Exclusivement d’autres sections
    • Exclusivement des éléments de texte
  • un “extrait” est l’élément de texte du tutoriel ou de l’article.

Grâce à cette généricité simplifiée, nous pouvons imaginer bien des fonctionnalités : validation partielle ultra simple (il suffit d’écrire un “manifeste de validation” qui n’écrit que les extraits validés), la fusion de plusieurs tutoriels, le déplacement d’un extrait d’une section à une autre…

Mais voilà, nous arrivons aujourd’hui à l’épreuve du passage de la théorie à la pratique et là, on n’a pas commencé à faire la publication et quand le ciel s’éclaircit à ce propos, le Scylla de notre Charybde pointe le bout de son nez.

Nous sommes un side project

La ZEP 12 est un projet dans le projet ZDS. Si ça n’arrive pas, on sera déçus, et on sera aussi bloqués pour quelques fonctionnalités et côté perfs. Mais en attendant le site est là et nous avons 20 développeurs qui l’améliorent tous les jours.

Nous avons commencé à refondre le modèle du module de tuto alors que le site était en version 1.4 et venait de lancer la préproduction de la 1.5. A l’heure actuelle, nous sommes en train de réparer la préproduction foireuse de la 1.7 et j’ai fait le test de qualification d’une correction bien sympatique qui paraîtra dans la 1.8, de même j’ai fait un bugfix qui est déjà prévu pour cette 1.8.

Nous sommes deux, et nous nous battons fièrement face au redéveloppement du module le plus crucial du site, mais le rattrapage fonctionnel et de bugfix va faire très mal, on le sait.

Et le pire c’est que d’autres ZEP arrivent, la 5 (amélioration de l’export) est à un état d’avancement élevé (le prototype est fonctionnel), l’API des messages privés arrive et sera sûrement suivie par d’autres (galleries, forum…).

Le mot de la fin

Zeste de savoir est un projet d’ingénieur. Sans snobisme, aucun. Notre équipe a des profils plutôt variés mais ce sont de vrais principes d’ingénierie qui ont été mis en jeu et ça se ressent parfois. Aussi bien dans la qualité du produit final qui est agréable à utiliser, dans la variété des outils (pandoc, git, munin, node…) que dans les longs débats où des idées très ambitieuses apparaissent et envoient du rêve. Mais voilà, rêver c’est bien, agir c’est mieux et j’espère vraiment que la réalité ne nous rattrapera pas violemment.

J’adore ce projet!

 

2 thoughts on “Un point sur le projet ZEP 12

  1. Pingback: Activité du blog, projets, tout ça tout ça | Blog de françois DAMBRINE

  2. Pingback: Tester un logiciel, le cas (d’école) de la ZEP-12 | Blog de françois DAMBRINE

Leave a Reply

Your email address will not be published. Required fields are marked *