ZEP-12 : refonte du principe des tutoriels et articles

C'est mergé, à débugger.

@spacefox: ok, c'est bon alors, parce que justement, on avait constaté avec la base d'artragis qui était en latin1 que on avait quelques problème, mais quand tu la passe en utf-8, ça marche nickel (voir ici, donc artragis l'as passée en utf8_general_ci, même si je sais pas ce que ça change exactement en pratique, à part sur les comparaisons).

@artragis: je regarde ce que je peux faire ce soir (et j'en profite pour QA convenablement la PR de yapper-git)

Bonjour à tous, voici quelques petites news du front !

Hugo a fait un énorme boulot de QA. Pas de bug découvert pour l'instant en grande partie grâce au travail que Vayel a effectué en amont (ainsi qu'au travail des devs bien sûr).

Il ne faut pas oublier Sandhose qui teste en ce moment la migration des tutoriels et articles sur la béta (avec donc une base de donnée aussi réelle que possible) sous la direction de pierre-24 et artragis, pour avoir le moins de problèmes possible pendant la migration en production.

_{Et moi ? Euh, on va dire que je fais du soutiens moral... :-°}

M'enfin on a quand même découvert quelques bugs lors de la migrations, donc on est pas encore sorti de l'auberge (mais ça avance, promis).

Avec une PR de cette taille, l'inverse aurait été étonnant et même franchement mauvais signe (ie. QA pas assez testé). C'est normal. On vous fait confiance pour régler ça !

Bah en fait ce sont des bugs "comme je les aimes ou presque".

Pourquoi?

• bug qui génère un plantage bien visible (impossible d'indexer dans un cas, barre de pagination cassée dans un autre)
• bug situé sur une seule ligne

Ce qui est bien du coup c'est qu'on arrive vite à identifier le bug et sa cause, mais ce qui fait autant la force que la faiblesse du bug c'est qu'il n'est que sur une ligne et il faut donc la trouver car souvent le symptome n'est pas dans le module buggé.

Bref, on est dessus, ça va marcher et c'est en bonne voie

Je paye une bière à celui qui me trouve pourquoi certains articles génèrent une 400, parce que je m'arrache les cheveux dessus depuis tantôt

c'est vrai que 400 c'est étrange quand même.

Tant que c'est pas un 418 …

I'm a zestpot.

Petit compte rendu de l'avancée :

les tests, les bugs, les joies

• Nous avons corrigé tous les bugs génant qui apparaissaient lorsqu'on migrait sur du contenu réel, il ne reste qu'un léger problème à l'indexation,
• en parlant d'indexation contrairement à avant, elle ne s'arrête plus à la première erreur trouvée donc on aura toujours une recherche à jour même quand un tuto foire
• Andr0 a déjà réussi à transformer un bigtuto en moyen tuto \o/
• Le système est vraiment stable
• L'import est plainement fonctionnel
• Les pages de liste sont maintenant paginées. Pour l'instant nous mettons 50 éléments mais ce n'est pas optimal car 50 n'est pas divisible par 3, néanmoins une fois que spacefox se sera décidé pour le chiffre le plus efficace qui soit divisible par 2 ET 3 (pour les écran de taille réduite et les grands écrans) on aura une page bien plus légère à charger grâce à la pagination
• Les données sont correctement redirigées, donc aucune perte de SEO à signaler

Un ETA?

Non, avant de lancer la mise à jour en prod, il faudra faire un vrai dry run en preprod ce qui signifie de resynchroniser la préprod sur la prod et ça prendra du temps.

D'autant que tout cela n'est pas prioritaire, le site ne peut toujours pas importer de JPEG et vous savez sûrement que la version 15.8 attend d'être déployée, ces deux actions étant largement prioritaire.

Je ne peux pas non plus donner d'ETA car il faudra que VOUS testiez la zep12 sur la preprod avant qu'on l'envoie en prod. Cette ZEP est un changement MAJEUR sur le site, on ne peut pas se permettre de laisser des bugs bloquants passer et espérer un hotfix. il faut tester avant.

VOus pouvez faire tout ce que bon vous semble sur cette beta, par contre, je tenais à prevenir : nous avons encore un bug très léger lors de l'indexation, ce bug demandera une opération de "wipe" de lap art de sandhose qui dure environ 30 minutes. Durant ces 30 minutes, vous aurez simplement la page d'erreur 500, rien de plus : ce n'est pas une erreur de la zep, c'est juste que comme pour découvrir ce bug on a volontairement cassé des choses, bah faut repartir sur uen base pas cassée pour tester la résolution.

néanmoins une fois que spacefox se sera décidé pour le chiffre le plus efficace qui soit divisible par 2 ET 3

Un multiple de 12. C'est ce qui a toujours été utilisé, notamment dans la monnaie, pour pouvoir faire des fractions facilement. Et c'est à l'origine du système sexagésimal pour les minutes et les secondes (parce que 60 est un multiple de 2, 3, 4, 5 ET 6).

En fait, la distribution des valeurs nominales des pieces est plutot faites pour faciliter les algorithmes de rendus de monnaie (avec pour but de rendre le moins de pieces possibles). Typiquement, l'immense majorite des distributions de valeurs sont faites en sorte qu'un algorithme glouton soit optimal. En dehors de cas particuliers, le probleme est NP-Complet !

Contre-Exemple d'optimalite: Systeme de pieces {1,3,4}. Pour rendre 6 en pieces, un algorithme glouton ferait 4+1+1 soit 3 pieces, tandis que l'optimal est donne par 3+3.

La question interessante historiquement serait de savoir si:

• On a eu de la chance d'avoir de tels systemes qui sont apparus spontanemment
• Les gens se sont appercu que c'etait plus simple pour rendre la monnaie
• Le probleme etait deja etudie et resolu d'une maniere ou d'une autre a un moment donne de l'Histoire

C'etait la minute math.

Maintenant, je me pose une question. Pourquoi n'est-ce pas optimale (par rapport a quel critere ?) d'avoir 50 elements ? Quel est le rapport avec la divisilite par 2 et 3 ?

Nous avons trois colonnes sur grand écran, si notre nombre n'est pas divisible par trois, la grille sera donc incomplète.

Sur petit écran, nous n'avons que deux colonnes.

Donc il faut une divisibilité par deux ET trois.

La question interessante historiquement serait de savoir si:

Je n'ai pas étudié la question de fond en comble, mais en gros on a ce qui suit.

• Avant l'implantation d'États centraux très forts au XVIIIe et surtout XIXe siècle, la monnaie est une vraie merde. Il existe une monnaie de compte à peu près cohérente sur de vastes zones (chez nous, on a 1 livre = 20 sous = 240 deniers depuis les Romains), et qui fonctionne généralement de manière à faciliter les fractions, car des tas de choses, comme les impôts et autres droits seigneuriaux se transmettaient et donc se partageaient par héritage : notre système livre-sous-denier permet ainsi de partager en 2, 3, 4, 5, 6, 8, 10, 12, 15, 20, 30, 60, etc. À côté de ça, on a la monnaie réelle, constituée d'un fatras de pièces diverses et variées ayant des valeurs en monnaie de compte qui ne correspondent pas nécessairement à des subdivisions cohérentes (spéciale dédicace au Gulden autrichien du XVIe qui valait 252 Pfennig, ou à la guinée anglaise, qui valait 1 livre + 1 shilling). Donc, clairement, la question du rendu de monnaie en numéraire n'était pas pertinente.
• Avec la Révolution, la France adopte le système décimal et le 7 avril 1795, la monnaie s'y plie à son tour avec l'arrivée de 1 franc = 100 centimes. Comme pour les unités ordinaires, les autres pays sont passés à ce système à la suite des Français dans les temps qui ont suivi (1857 pour l'Autriche-Hongrie, 1873 pour l'Allemagne, 1971 pour la Grande-Bretagne, etc.). Là, la décision de passer au système décimal est manifestement dogmatique. Peut-être qu'après coup on s'est rendu compte de l'intérêt pour rendre la monnaie, mais je pense que c'est très tardif : en France encore, les subdivisions anciennes restaient dans l'usage populaire à la fin du XIX.

Pourquoi n'est-ce pas optimale (par rapport a quel critere ?) d'avoir 50 elements ? Quel est le rapport avec la divisilite par 2 et 3 ?

Si tu as 50 éléments, que tu essayes de répartir en 3 colonnes, tes colonnes auront une taille différente et ce sera moche.

6, parce que 2 x 3. Plus sérieusement, ce n'est pas à moi de trancher ça, mettez ce que vous voulez qui vous paraît cohérent.

42?

Merci de cette explication.

Merci pour les explications. Il est clair que les fractions simples a calculer avait un grand interet et pas que pour les pieces (meme si c'est relie) ! Par exemple, en Russie, Mendeleïev avait calcule que le titrage parfait pour la vodka etait 37.5, mais comme le calcul de l'impot etait rendu plus facile avec un titrage a 40 (pas que l'on payait l'impot en vodka la bas, mais sur la vodka – precisons :p), c'est celui-ci qui que le Tsar de l'epoque a impose et qui est plus ou moins reste.
Il me semble que le titrage minimal pour l'appelation vodka en Union Europeenne est de 37.5, correspondant a cette valeur optimale determinee par Mendeleïev.

Pour retourner et clore l'histoire des pieces, c'est assez marrant cette chance que ces systemes se soient imposes alors car a priori, a tirer une distribution quelconque, il y a fort peu de chance d'avoir un systeme canonique.

Hugo a tranché, ce sera 42

Le merge devrait avoir lieu aujourd'hui.

Ensuite faudra faire un dry run complet.