Licence CC 0

Compte rendu du zest-meeting mai 2017

Les développeurs sont back in the game

L’équipe technique s’est réunie mardi dernier pour un zest-meeting, le premier depuis longtemps. Nous avons parlé du changement de DTC, des versions passées et de l’organisation du projet. Voici le compte-rendu !

La passation des DTC

Comme vous le savez peut-être, le DTC est le directeur technique de Zeste de Savoir. C’est la personne qui s’occupe de gérer le développement, de choisir les priorités et d’effectuer la plupart des mises en production. Après 11 mois et 5 versions, victor a légué son rôle à artragis. gustavi reste quant à lui toujours DTC. :)

Quelques remarques de victor

Mon but était d’améliorer la partie technique existante plus que d’y ajouter des fonctionnalités. Je voulais une codebase plus propre, plus maintenable, et un processus plus solide. En deux mots : plus stable. Après beaucoup de nettoyage et de refactorisation, je considère que c’est assez réussi. Les performances ont également pris un bon coup, notamment avec l’arrivée de la v20 et du cache des templates.

Côté nouveautés et nécrologie : les tribunes libres, la recherche, le support unicode dans nos messages (emoji unicode par exemple), la mort des ZEP.

Une semaine après avoir repris ce projet, un problème chez notre hébergeur a causé une perte de données. Lisez l’article si vous avez oublié l’histoire. Je reviens là-dessus pour dire que vérifier que nos backups sont faites ET restaurables est primordial. Perdre un disque pour ensuite constater que nos backups n’ont mystérieusement plus été faites depuis 3 mois, c’est dommage.

La v22 et la v23

Comment se sont passées les 2 dernières releases (victor)

v22

La MEP s’est bien passée si je m’en souviens bien, c’était y’a longtemps

v23

Là aussi ça s’est bien passé, il y a eu quelques ennuies avec Munin en prod parce que les instructions de l’update.md n’étaient pas correctes.

En revanche la MEB a été difficile, la v23 introduisant du code qui d’après l’update.md devait être activé par le settings_prod.py et le code en question plantait intégralement ZdS. Ce n’est jamais une bonne idée d’introduire dans settings_prod.py des trucs qui sont pas dans settings.py, vu que Travis passera pas dessus. Si ça avait été fait proprement, la suite de test aurait été rouge comme un poisson et la PR introduisant ce gros bug n’aurait pas été mergée.

Remarques générales de victor

  • La raison pour laquelle la MEP se passe bien est que la prod et la beta sont ISO, et que chaque MEB est une répétition générale de la MEP.

  • Si vous trouvez une faille dans ZdS, contactez l’équipe avant toute chose. Ouvrir un ticket expliquant comment exploiter la faille, c’est dangereux. Ce qu’on fait généralement c’est qu’on patch sur la prod, puis quand c’est sécurisé on fait le hotfix.

  • Faites gaffe avec les données de la prod. Suivez bien la procédure quand vous synchronisez la prod vers la bêta. Ne faites pas de tests sur la bêta qui exposent potentiellement les données. Ne mettez pas quelqu’un dans un groupe d’administration sur la beta, il y a des données très sensibles.

  • Les serveurs ont une whitelist d’usernames, et on ne peut se logger que par clé, pas par mot de passe. Ne changez pas ça.

  • Ne venez pas avec une grosse feature pour disparaitre sitôt qu’elle est mergée. C’est très pénible quand une PR ajoute un truc compliqué mais que l’auteur disparait sitôt que c’est en prod et n’est pas disponible pour aider à réparer les bugs qui peuvent survenir.


Résumé de la marche à suivre en cas de faille de sécurité

Quelques remarques pour le développement

Eviter de proposer de grosses fonctionnalités si vous pensez ne pas être disponible sous peu. Ou alors faire au mieux pour transmettre la connaissance.

Pour le module tutorialv2 :

  • points positifs : les méthodes utilitaires sur les modèles (in_public, etc). La doc est bonne.
  • point négatif : les templates (on ne sait pas forcément quel type d’objet est quel variable).

À priori, ça va de mieux en mieux.

Crainte de la part de sandhose pour le front de manière globale
  • Templates mal répartis
  • Beaucoup d’override
  • Le CSS a sûrement été pensé « sémantique » plutôt que « composant ».
  • Manque de leader côté front

Organisation et retours divers

Premièrement nous avons identifié un problème majeur : il y a besoin de plus d’engagement pour la QA car l’attente est trop longue. Ce n’est pas surprenant, la QA n’étant pas quelque chose de gratifiant. Est-ce qu’on pourrait trouver quelque chose pour motiver les gens ?

Utilisation de l’interface de projet sur GitHub

Le but est d’essayer de communiquer au mieux le développement du site tout en s’organisant. Voici les remarques des participants :

  • Un peu lourd et l’interface n’est pas top. Les milestones sur GitHub sont plus facilement utilisables.
  • Dashboard sur GitLab, c’est mieux.

Les Gros Travaux (majuscules obligatoires, svp :p )

  • Django 1.10 : 95% d’avancement, la 1.11 sera pour plus tard (version suivante idéalement, ça devrait être plus trivial)
  • Interface de rédaction du contenu (partie JS à retoucher, mais ce n’est pas bloquant). Le besoin de QA est important.
  • API des forums (Anto59290).
  • Interface des contenus (ça avance par blocs mais il manque quelques composants).
  • Interface de merge des contenus (Anto59290)

La demande sur l’opengraph (et la pertinence des miniature) a été remise en avant durant la réunion.

zmarkdown

Ça avance pas mal. Il y a plusieurs contributeurs donc c’est cool. Scénario optimiste : cet été.

Ce qu’il reste à faire :

  • faire passer tous les anciens tests Python-ZMarkdown
  • quelques plugins pour textr de manière à avoir une bonne typographie
  • manque les ping, grid_tables, typographie, par exemple.
  • la transformation AST => latex ça se fait, mais il faut un peu de connaissance en latex.
    • il nous faut un template latex qui passe par pdftex et contenant tous les éléments de nos contenus (markdown)
    • => demander sur le fofo => gustavi se propose pour faire un sujet sur le forum <3 AmarOk peut aider aussi
    • L’idée est donc que quelqu’un crée une feuille de style latex pour nos contenus, avec des macros/commandes latex permettant de générer nos blocks ’perso’, genre \questionblock{mon block question}. Le but est d’avoir toutes nos features et d’avoir un beau rendu PDF. Ensuite on fera AST -> latex.
  • Sandhose va travailler sur un éditeur de texte, potentiellement intéressant pour ZdS aussi.

Il faudra trier les vieilles PR/issues qui ne bougent pas.

Certaines personnes sont intéressées pour le déploiement continu (du moins en bêta). Mais le ratio effort/bénéfice est en doute. (victor : ouais amha on a de plus hautes priorités, du coup sauf si on tombe sur la personne idéale qui veut s’y mettre à fond pour une longue période, ça vaut pas vraiment le coup, concentrons-nous sur notre core business).

Il faudrait utiliser les ModelForm pour améliorer la codebase. Ça permet d’utiliser des CreateView et UpdateView, ce qui est bien (exemple) !

Les parcours : peut-être un jour, si ça passe les PR tant mieux. Courant juin, on pourrait envisager le module de vote générique : gustavi veut s’y pencher ! Comment mettre en avant les billets (ratio de votes + temps de lecture sur le billet). On peut utiliser l’algorithme de HackerNews.

Participation de la communauté


En conclusion, le développement est en bonne progression. De gros chantiers sont en cours et nous espérons qu’ils pourront bientôt voir le jour. Si vous êtes intéressé par le développement du site, n’hésitez pas à contribuer vous aussi. :)

7 commentaires

Premièrement nous avons identifié un problème majeur : il y a besoin de plus d’engagement pour la QA car l’attente est trop longue. Ce n’est pas surprenant, la QA n’étant pas quelque chose de gratifiant. Est-ce qu’on pourrait trouver quelque chose pour motiver les gens ?

… Non :p

La QA est une bonne chose, qui doit continuer, mais c’est pas marrant, loin de là, et je pense savoir de quoi je parle. Et en plus de pas être un processus anodin, c’est quelque chose qui s’improvise difficilement: et d’une parce qu’il y a une étape de relecture de code (qui demande de connaitre le code de ZdS un minimum) et de deux parce qu’il y a une étape de QA en elle même qui demande un minimum de savoir faire (et encore une fois de connaissance du code, certaines fonctions ayant des effets là ou on ne les attend pas forcément). C’est malheureusement pour ça que cette étape ne doit pas disparaître (quand on découvre des bugs en bêta, c’est jamais drôle), et c’est malheureusement pour ça que cette tâche est loin d’être facile.

À mon sens, y’a pas de bonne solution à tout ça. On peut bourinner les tests unitaires, bourinner les étapes de lint, rien y fait. On peut difficilement automatiser plus que ça ne l’est déjà (peut être avec des tests "fronts", comme ça a déjà été proposé, mais ça reste un garde fou).

D’ailleurs, ceux qui sont vraiment programmeur … Comment ça se passe, en vrai, dans une entreprise ?

La demande sur l’opengraph (et la pertinence des miniature) a été remise en avant durant la réunion.

+100000. Techniquement, c’est relativement simple à mettre en place.

il nous faut un template latex qui passe par pdftex et contenant tous les éléments de nos contenus (markdown)

Ça, je veux bien aider.

Notez que la dernière fois que j’en avais discuté, on m’avais remonté que ça reste très difficile à mettre en place, en particulier au niveau des tableaux1 (un tableau en LaTeX, qui est très touchy et un tableau en HTML ou on peut mettre virtuellement n’importe quoi, c’est très difficile à concilier). Y’a aussi le concept de flottants qui n’existe pas en HTML (ça veut pas dire la même chose) mais qu’on est obligé (ou presque) d’employer en LaTeX.

(merci pi-pierre).

Blackline

C’est gentil, mais je suis loin d’être le seul à y avoir contribué ;)


  1. en fait c’est faux. Il "suffit" d’employer une minipage. Le problème, c’est que c’est réellement des saloperies, et qu’on doit en connaître la taille à l’avance. 

+2 -0

Bravo et merci à toute l’équipe. ^^

Y’a aussi le concept de flottants qui n’existe pas en HTML (ça veut pas dire la même chose) mais qu’on est obligé (ou presque) d’employer en LaTeX.

On peut se débrouiller sans flottants en utilisant le package caption pour les légendes et en laissant chaque image/tableau/code à sa vraie place. Mais les tableaux par contre, une vraie plaie à gérer…

+0 -0

@pierre-24 il n’a jamais été question de faire disparaitre la QA, hein. Juste de se demander comment faire mieux :)

Dans le dernier lieu où je travaillais, la QA était faite par le "gérant" de la partie du code visée.

Dans le lieu où je vais travailler, il me semble qu’il y a un temps donné pour la QA à pas mal de personnes.

Dans tous les cas ce ne sera pas le cas pour zds, car on ne va pas obliger les gens à faire la QA.

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