[v5] Écriture des spécifications
Posté le 03/07/2018 15:57
Les besoins ont été validés, on passe maintenant à la rédaction des spécifications techniques.
Mémo rapide pour les contributeurs :
–
Besoins validés
–
Pad des specs
–
Règles de contributions sur les pads
Les spécifications sont là pour détailler la manière d'implémenter les besoins. On est pas dans les détails vraiment techniques, mais on s'en rapproche.
Exemple sur du front-end :
– Besoin : affichage clair des notifications
– Spec : pastille en bas à droite de l'avatar dans le menu
– Conception : mettre un
:after dynamique sur l'avatar
Exemple sur du back-end :
– Besoin : utilisateurs répondants aux points listés
– Spec : classe
Member héritant de la classe
User avec les attributs et fonctions suivantes
– Conception architecturale : détail des fonctions à implémenter dans la classe
– Conception détaillée : détail de l'algo pour sécuriser le code qui sera produit
La séparation de la conception en deux parties (architecturale et détaillée) n'est pas forcément pertinente pour toutes les specs, mais de toute façon c'est pas le sujet aujourd'hui.
Vous êtes invités à contribuer sur les specs ! Dans un premier temps, ça se passe
sur le pad correspondant..
La deadline pour la validation est reportée au 5 août (pour cause de vacances du patron
)
Règles de contribution sur les pads
– On se choisi une couleur et un pseudo
avant d'écrire
– La couleur respecte les yeux de chacun, j'ai pas un stock infini de collyre
– On efface la couleur de ce qui est écrit que lorsque c'est validé
– Si un truc n'a plus de couleur, quelqu'un se charge de mettre le point au propre sur le wiki
– Le plus important :
tous les membres peuvent participer !
Citer : Posté le 16/09/2018 22:52 | #
Je relance en faisant les diagrammes de classe (avec Dia, un FLOSS qui permet entre autres de générer le Python correspondant), mais quelques questions :
– Un contenu peut-il avoir plusieurs auteurs ? (attention à ne pas confondre avec les droits d'édition/suppression)
– Un commentaire peut-il être descendant d'un autre commentaire ? Ou seuls les contenus racine peuvent être parents ?
Le diagramme actuel :
Je compte l'avancer dans la semaine, sur ce qui est déjà fait, des remarques ? Je n'inclurais volontairement pas le système de permissions, qui va influer sur toutes les classes ici présentes.
Citer : Posté le 16/09/2018 23:16 | #
Tu veux dire, par exemple, un commentaire en réponse directe à un autre commentaire ? Ça pourrait être une bonne idée pour permettre les digressions sans interrompre le fil de la conversation. Toutefois, j'ai peur que les commentaires descendants d'autres commentaires perdent en visibilité, ce qui fait que, quand un membre pose une question, les autres risquent de moins bien profiter de la réponse à cette dernière. Je suis assez mitigé.
Dans quel cas un contenu aurait-il plusieurs auteurs ?
Citer : Posté le 16/09/2018 23:16 | #
Je conseille un seul auteur par contenu, mais s'il est possible, suivant ce que j'ai fait dans mes projets personnels, faire plusieurs types d'utilisateur :
- individu (l'actuel) ;
- organisation.
Pour les programmes, au-delà du contenu, je sais pas trop comment vous pourriez stocker ça de façon assez propre. Je dirais le contenu des programmes directement, mais à voir comment gérer s'il y en a plusieurs, s'il y a des pièces jointes (si certaines pièces jointes sont supprimées), etc. Stocker la forme décodée permet de re-wrap ça dans le format qui va bien derrière, à savoir g1m, g2m, g3m, g1r, g2r, g3r, cas (CaS ou CASPRO), cat, ctf, fxi ou grc.
Aussi, en fonction du contenu des programmes, avec des outils comme la refc, on peut déterminer avec quoi est compatible le programme, donc une table de compatibilité calculée ou remplie par l'utilisateur dans un premier temps peut être cool.
Mon blog ⋅ Mes autres projets
Citer : Posté le 16/09/2018 23:23 | #
Excellent l'idée des organisations. Drak, dans le cas d'un tutoriel par exemple, il peut y avoir plusieurs auteurs. Un programme aussi, un topic, en fait tout contenu qui n'est pas un commentaire.
Excellent aussi l'idée de ne pas stoker bêtement le programme, mais d'en faire quelque chose de plus poussé. Je sais que t'as pas trop envie de plancher sur la v5, mais si je te demande de l'aide sur ce point spécifique, tu serais de la partie ?
Pour les commentaires de commentaires, oui, c'est ça. Deux choix :
– on fait ce qui est fait ici (un commentaire hérite d'un contenu racine uniquement) ;
– on fait un système type Reddit, où il est possible de commenter un commentaire.
Question supplémentaire, je sais plus si on avait statué à propos des points de pertinence sur les commentaires/contenus ?
Citer : Posté le 16/09/2018 23:31 | #
Je peux regarder mais je préfère ne rien te promettre, vu ce qui s'accumule dans mon emploi du temps à l'occasion de cette rentrée des classes 2018.
Mon blog ⋅ Mes autres projets
Citer : Posté le 16/09/2018 23:38 | #
@Dark Storm : https://git.planet-casio.com/devs/PCv5/issues/10
Citer : Posté le 17/09/2018 21:34 | #
Mis à part les droits, des trucs que j'ai oublié ?
Citer : Posté le 17/09/2018 21:57 | #
Si je comprends bien, un commentaire partage les classes comment et content, c'est bien cela ?
Edit : et puis, comment est gérée l'image de présentation d'un programme ?
Citer : Posté le 17/09/2018 22:10 | #
Un commentaire, c'est la classe comment, qui hérite de content.
Pour les images du programme, je compte les gérer via les pièces jointes (attachement) : il suffit de lister les PJ, regarder celles qui ont une extension (+ vérification du header par sécurité) d'image pour qu'on les affiche. Sinon suivant l'extension, c'est un binaire.
Je précise bien qu'il est très important de vérifier le contenu du header des fichiers, pour ne pas filer au client un binaire typé en .png par exemple. Question de sécurité.
Citer : Posté le 17/09/2018 22:19 | #
D'accord, je vois.
Eh bien, je rajouterais un booléen dans la classe user pour indiquer s'il est actuellement connecté ou non.
Citer : Posté le 17/09/2018 22:23 | #
Le fait de savoir si un utilisateur est connecté ou non se détermine à partir de son nombre de sessions actives. Ce n'est donc pas quelque chose qui se stocke
Mon blog ⋅ Mes autres projets
Citer : Posté le 19/09/2018 18:50 | #
Je suis en train de commencer la rédaction des specs (en gros les méthodes et ce qu'elles vont devoir faire), donc si y'a des trucs à améliorer, c'est maintenant, parce qu'une fois que ce sera validé, ce sera trop tard. Donc soit y'a pas de commentaires et je valide, soit vous les faites vite.
J'ai mis à jour la deadline pour cette partie : Milestone #2, je valide tout pour le 30 septembre.
Citer : Posté le 19/09/2018 19:59 | #
Comment est géré le système de vues (alias nouveautés dans la boite de réception) ?
Vitesse des fonctions en Basic Casio | 7 days CPC | Casio Universal Wiki | Tutoriel Basic Casio
>>> Give me a click Brother
>>> Random Youtube Video
Citer : Posté le 19/09/2018 20:07 | #
Via un algo spécial de Lephe. En gros on a un tableau de bits, une ligne par membre, n bits qui correspondent à n topics.
Une table fait la correspondance entre le bit x et l'ID du topic. À chaque post, on décale tous les bits du tableau d'une colonne vers la droite, on ajoute une colonne de 0. Pour récupérer les nouveautés pour un membre, on regarde la ligne de bits.
Avec n = 256, on peut avoir jusqu'à 256 nouveautés par membre, pour 32 octets par membre. Donc 3,2 Mo pour 10 000 membres.
Citer : Posté le 19/09/2018 20:22 | #
Je précise qu'il s'agit d'une sorte de file circulaire donc quand on dit qu'on décale les bits vers la droite, on se contente de déplacer la frontière imaginaire entre les membres. Exemple ici, on a deux membres sur deux lignes, le bit de gauche représente l'article le plus vieux et celui de droite le plus récent.
|0 1 1 0 1|
|0 0 0 1 1|
...
Quand on veut ajouter un article plus récent, on se contente de décaler les frontières, comme ceci :
0|1 1 0 1
0|0 0 1 1
...
Ainsi le bit le plus vieux du membre du bas, qui a été éliminé de l'algorithme parce que l'algorithme ne garde en mémoire que les 5 dernières nouveautés du site (en pratique quelque part entre 250 et 1000), a été donné au membre du haut pour servir de bit plus récent.
Et ça recommence chaque fois qu'il y a de l'activité quelque part. Une fois que l'on a fait 5 rotations, on déplace les données du membre le plus bas dans la table vers la zone la plus haute dans la table pour assurer la rotation sur les membres.
Avec n nouveautés et m membres, les complexités sont grosso modo comme suit :
- O(m) pour ajouter une nouveauté (le décalage de membres après 5 rotations se fait en O(n) une fois tous les O(n) donc en amorti le coût est constant)
- O(n) pour ajouter un membre
Il faut ajouter à cela une petite structure (liste doublement chaînée, un truc du type) pour conserver la correspondance entre les positions dans la table et les IDs des membres.
Citer : Posté le 19/09/2018 21:09 | #
Bonsoir, je signale que je n'apporterais sans doute pas ma pierre à l'écriture des specs... mais mon éditeur de texte sera là pour écrire le code lorsque vous en aurez besoin.
Je n'aiderais pas(ou peu) aux spécifications car... 1. j'aime pas les graphiques 2. De ce que j'ai lu et vu... je n'ai rien à dire
Citer : Posté le 19/09/2018 21:14 | #
Les specs c'est pas que les graphiques hein
Y'a aussi une grosse partie sur la construction des classes et de leur contenu.
Citer : Posté le 19/09/2018 21:26 | #
Bah... Je re regarde ça et si je trouve des choses sur lesquelles je peux aider... je vais le faire
Citer : Posté le 19/09/2018 21:44 | #
Typiquemenr, définir la liste des méthodes de chaque classe. Tu peux mettre ça sur le pad
(J'ai commencé la classe Member, mais en local)
Citer : Posté le 19/09/2018 22:06 | #
Tu pourra envoyer tes modifs que tu à fait, j'ai un peu de mal à m'immaginer la v5 avec ce qu'il y à pour l'instant sur le pad et dans les graphiques