[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 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
Citer : Posté le 19/09/2018 23:38 | #
Y'a pas grand chose à partir du diagramme qui a changé (juste une classe "Author" en plus qui est le parent de toutes les classes de personnes (morales et physiques) qui peuvent poster des trucs (organisation, membre et invité)).
J'ai mis à jour le pad, à partir de la ligne 60 j'ai mis une idée de ce que tu peux produire (en gros faut ça, en exhaustif, pour chaque classe).
Citer : Posté le 20/09/2018 17:12 | #
Honnêtement je ne vois pas l'intérêt de poster en tant qu'organisation. On s'associe assez rarement, et je pense qu'on peut se permettre un one-to-many entre les tutoriels et les auteurs. En plus la notion d'organisation pose plein de questions pas forcément nécessaires : peut-on se connecter en tant qu'organisation ? poster sur le forum en tant qu'organisation ? envoyer un MP à une organisation ? Si la réponse à toutes ces questions est non alors faites une liste d'utilisateurs là où c'est nécessaire. Je ne vois que les tutoriels ; pour les premiers messages de topics, ça me semble inutile car un travail collaboratif est forcément plus qu'un simple post.
Pour les commentaires, je crois qu'on va exploser si on complexifie les fils. A-t-on vraiment besoin de machins imbriqués ? Si vous voulez répondre vous pouvez mettre un ID de réponse de sorte que (je caricature) en haut du poste il y ait marqué « en réponse à #18244 » ou un truc du style. Comme ça vous avez les réponses mais la conversation est linéaire. Cela dit on le fait déjà avec les quote aujourd'hui, le seul intérêt que j'y vois c'est de notifier la personne citée. (Mais je préférerais ajouter en-dessous de l'éditeur des cases à cocher avec « notifier les auteurs récents du topic : [] Cakeisalie5 [] Dark Storm [] Lephenixnoir ».)
Gérer les images du programme avec une pièce jointe, c'est élégant, clean, parfait.
Voilà ensuite pour les différentes tables/classes que tu proposes. D'abord on est d'accord que pour la plupart de ces tables il nous faut des IDs et des index dessus ?
attachment
Actuellement je vois les pièces jointes comme étant un dossier genre /upload/msg/<id> du coup le chemin pourrait être déduit de l'id, et ça permet d'uploader plusieurs fichiers dans le même post à condition que la taille totale reste raisonnable. Je serais donc pour remplacer path par name dans l'optique où on sait que c'est juste un nom de fichier dans un dossier fixe. Je ne sais pas si stocker les métadonnées du fichier est pertinent par rapport à les obtenir avec stat() pendant la génération ; en tous cas c'est très facile de les ressortir depuis Lightscript. Rajouter le nombre de téléchargements, vu que c'est utilisé pour les programmes aussi ?
content et comment
J'ai bien suivi si je dis que la one-to-many entre les deux c'est pour savoir sur quel topic/programme/etc on a posté ? Je suis bel et bien pour que seuls les contenus racine puissent être utilisés ici, comme je l'ai laissé entendre en parlant de commentaires imbriqués plus tôt. J'ai déjà parlé de mon point de vue sur les organisations (je ne pense pas que ce soit utile) ; pour le reste des auteurs (dans une table invisible si j'ai bien compris), comme on a l'abstraction d'une autre table on s'en sortira quitte à la retoucher un poil. J'en reparle à propos de user versus guest plus loin.
survey et option
Pour le coup je pense qu'il faut un truc plus complexe pour le système de sondages, car tu n'as pas que des choix à faire dans des listes déroulantes je pense. Je le laisse toutefois à plus tard pour nous concentrer sur le principal, ça te convient ?
topic, tutorial et progam ; tag et category
Pour les topics, il n'y a pas de compteur de vues, de chemin de catégorie du forum (maybe catégorie/sous-catégorie ? cf. Casiopeia, TI-Planet, etc, c'est peut-être mieux que notre découpage actuel) ? Ou alors les tags remplacent ça ? Je ne sais plus trop comment c'était supposé marcher (je suis pas trop humeur tags en plus aujourd'hui, diantre >_<). D'un autre côté si les programmes sont catégorisés mieux vaut se mettre d'accord pour tout. Bon et les post-its.
Pour les programmes, il semble manquer la licence, les participations aux concours, le nombre de vues.
calculator
On peut rajouter plein d'infos au passage pour peupler les tables descriptives des pages statiques : fabriquant, CAS/mode examen, fréquence proco, dimension, prix, type de proco, etc.
user et guest ; trophy, title et private_message
Grosso modo je pense qu'ils devraient s'appeler member et guest, et hériter d'une classe commune user qui sert essentiellement d'auteur. Actuellement la distinction manuelle membre/invité partout est horrible, la POO devrait nous aider ici. Pour l'utilisateur il manque quelques paramètres et (dans une autre table, sans doute) les privilèges.
Voilà, c'est déjà un bon début que tu nous a fait là !
J'ai une remarque assez importante par contre : moi de mon côté j'ai divisé le forum (et le code, implicitement) en plusieurs parties, et l'API REST avec, donc faudra faire attention au moment de coder, que tout soit bien dans sa section.
Citer : Posté le 20/09/2018 19:04 | #
Honnêtement je ne vois pas l'intérêt de poster en tant qu'organisation. On s'associe assez rarement, et je pense qu'on peut se permettre un one-to-many entre les tutoriels et les auteurs. En plus la notion d'organisation pose plein de questions pas forcément nécessaires : peut-on se connecter en tant qu'organisation ? poster sur le forum en tant qu'organisation ? envoyer un MP à une organisation ? Si la réponse à toutes ces questions est non alors faites une liste d'utilisateurs là où c'est nécessaire. Je ne vois que les tutoriels ; pour les premiers messages de topics, ça me semble inutile car un travail collaboratif est forcément plus qu'un simple post.
C'était une idée soulevée par Cake, qui permettait de dissocier l'image d'un membre de celle d'une organisation. Par exemple les développeurs d'un outil, etc. Après c'est sûr que la plus value n'est pas si grande, à voir. Ceci dit c'est pas compliqué, si on part là dessus, de rajouter une classe organisation si le besoin s'en fait sentir. Donc je le mets pas dans les trucs prioritaires à faire, mais c'est une idée qui me semble avoir sa place dans la v5.
- Member
- Guest
(- Organization)
Je pense que ça peut être bien en effet d'ajouter un champ (ou un truc, à voir dans les specs justement
L'avantage du champ dédié, c'est qu'on a pas besoin de citer expressément un bout du message pour que la relation soit faite entre les messages. On peut donc avoir une interface de ce type :
——————————————————————————————————————————
Vous savez, je ne crois pas qu'il y ai de bonnes ou de mauvaises situations. Moi si je devais résumer ma vie avec vous aujoud'hui, …
\o/
On est parfaitement d'accord, je n'ai pas non plus représenté les attributs [one|many]-to-many par soucis de clareté.
Actuellement je vois les pièces jointes comme étant un dossier genre /upload/msg/<id> du coup le chemin pourrait être déduit de l'id, et ça permet d'uploader plusieurs fichiers dans le même post à condition que la taille totale reste raisonnable. Je serais donc pour remplacer path par name dans l'optique où on sait que c'est juste un nom de fichier dans un dossier fixe. Je ne sais pas si stocker les métadonnées du fichier est pertinent par rapport à les obtenir avec stat() pendant la génération ; en tous cas c'est très facile de les ressortir depuis Lightscript. Rajouter le nombre de téléchargements, vu que c'est utilisé pour les programmes aussi ?
Deux remarques à ça :
– Ok pour l'arborescence, c'est propre et facile à gérer. Par contre le nom de l'image est une chaine générée aléatoirement et suffisament grande pour éviter que quelqu'un ai accès à un truc qu'il n'est pas censé voir (PJ de topics privés par exemple). Ou alors on overide le path pour pas que ce soit en accès direct, mais à ce moment là Flask va devoir se taper toutes les PJ à chaque fois que quelqu'un veut y accéder. Pour une image dans un topic public fréquenté, ça peut vite être lourd.
– Pour les stats, ça peut fonctionner si on est pas en accès direct justement. Idem pour le nombre de vues/DL.
À la réflexion, je pense c'est pas mal de proxyfier tous les accès aux PJ. On a nos stats à nous, on gère les permissions comme on veut, etc.
Donc si je résume, on aurait : GET /upload/msg/image.png → Flask get_attachement(msg, 'image.png') → check permissions → récupération de la PJ dans ./uploads/msg/image.png → update des stats → envoi de la PJ.
J'ai bien suivi si je dis que la one-to-many entre les deux c'est pour savoir sur quel topic/programme/etc on a posté ? Je suis bel et bien pour que seuls les contenus racine puissent être utilisés ici, comme je l'ai laissé entendre en parlant de commentaires imbriqués plus tôt. J'ai déjà parlé de mon point de vue sur les organisations (je ne pense pas que ce soit utile) ; pour le reste des auteurs (dans une table invisible si j'ai bien compris), comme on a l'abstraction d'une autre table on s'en sortira quitte à la retoucher un poil. J'en reparle à propos de user versus guest plus loin.
Ouaip. Mais du coup on aura une one-to-many uniquement sur les contents susceptibles d'accueillir des commentaires. C'est pas plus mal, comme ça si un jour on veut un contenu primaire qui n'accepte pas les commentaires, ça sera by-design sécurisé.
Pour le coup je pense qu'il faut un truc plus complexe pour le système de sondages, car tu n'as pas que des choix à faire dans des listes déroulantes je pense. Je le laisse toutefois à plus tard pour nous concentrer sur le principal, ça te convient ?
Ouais, le système de sondage c'est clairement pas le plus important à ce jour. Ceci dit mon système actuelle ne s'arrête pas aux choix par liste déroulante, mais il est pas non plus hyper efficace. Si quelqu'un veut s'y pencher, y'a du taf.
Pour les topics, il n'y a pas de compteur de vues, de chemin de catégorie du forum (maybe catégorie/sous-catégorie ? cf. Casiopeia, TI-Planet, etc, c'est peut-être mieux que notre découpage actuel) ? Ou alors les tags remplacent ça ? Je ne sais plus trop comment c'était supposé marcher (je suis pas trop humeur tags en plus aujourd'hui, diantre >_<). D'un autre côté si les programmes sont catégorisés mieux vaut se mettre d'accord pour tout. Bon et les post-its.
Hmmm, en effet j'ai oublié la classe "Forum", qui permet de catégoriser les forums entre eux. Ça sera dans l'update du schéma.
Pour la licence, c'est facile. Y'aura une classe License histoire d'avoir un truc plus souple qu'actuellement… J'ajoute ça dans l'update. Pour le nombre de vues, je ne sais pas si ça vaut le coup de le garder, si on a un Matomo pour les stats. Sauf si ça rentre dans le progrank (actuellement ce n'est pas le cas). Et pour les concours, j'ai aucune idée de comment organiser ça proprement, faudra sûrement faire des classes en rab, j'attends vos idées.
On peut rajouter plein d'infos au passage pour peupler les tables descriptives des pages statiques : fabriquant, CAS/mode examen, fréquence proco, dimension, prix, type de proco, etc.
Ouaip. On met ce qu'on veut en attributs, donc on pourra classer les caltos par tout un tas de critères.
Ça c'est un truc (la liste des arguments) à mettre dans le pad des specs.
Grosso modo je pense qu'ils devraient s'appeler member et guest, et hériter d'une classe commune user qui sert essentiellement d'auteur. Actuellement la distinction manuelle membre/invité partout est horrible, la POO devrait nous aider ici. Pour l'utilisateur il manque quelques paramètres et (dans une autre table, sans doute) les privilèges.
Ouaip, dans la v2 que j'avais faite, j'avais séparé ça à partir d'une classe Author. Mais on peut la renommer en classe User sans soucis.
YW! o/
Mmm, mouais, mais on en est pas là.
Citer : Posté le 20/09/2018 19:16 | #
- La classification "organisation" je comprends pas trop ce qu'elle fait dans les mêmes trucs que membre/invité, ce serait pas plutôt une qualification comme modo/admin ?
- Les commentaires nestés ça a pas sa place sur un forum
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/09/2018 19:21 | #
Nope. Les organisations, ça serait plus comme les groupes dans GitLab par exemple. Elles n'ont aucun rôle dans les droits, ou du moins pas globalement. Elles servent juste à représenter un ensemble de membres.
« Les commentaires nestés ça a pas sa place sur un forum surtout qu'après il faut gérer des trucs genre 100 niveaux de nesting etc. »
On est bien d'accord, par contre ça me semble important d'avoir une référence claire au messages précédents si ça saute le fil chronologique de manière trop brutale. D'où l'intérêt d'avoir une relation inscrite quelque part.
Citer : Posté le 20/09/2018 19:23 | #
Dans ce cas il faudrait un pop-up avec le message qui apparait lorsqu'on hover sur la référence en #1234.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/09/2018 19:24 | #
Nope, les trucs au hover, t'oublie. Par contre j'ai rien contre un lien
Ajouté le 20/09/2018 à 19:24 :
https://doisjeutiliser.fr/unControleAuSurvol/
Citer : Posté le 20/09/2018 19:26 | #
Même si les hover ne sont pas utilisables par tout le monde, rien n'empêche d'en mettre
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 20/09/2018 19:27 | #
Non. Si t'hover un commentaire de 500 lignes, tu fais quoi ?
Pis ensuite t'hover des hover ?
Citer : Posté le 20/09/2018 19:28 | #
Ok, bon pour moi. Ils font ça sur les chats de Stack Exchange, je trouve ça plus simple que les fils complexes de Reddit.
Je pense que le nom doit être exactement celui du fichier d'origine, en particulier pour qu'on puisse mettre dans les posts une image dont l'url est genre :truc.png pour parler d'un fichier uploadé ; et pour éviter les problèmes quand on télécharge un fichier depuis un programme.
As-tu d'autres exemples que les PJ de topics privés ? Car ici on peut se permettre de vérifier les droits à chaque chargement de l'image, il n'y a pas tant de gens dans l'équipe.
Je pensais plutôt au nombre de clics sur le truc « fichier joint », qui passe sans doute par un script avant de servir le fichier statique. Pour les images dans les posts on se moque pertinemment de savoir combien de fois elle a été vue
Je ne suis pas trop pour servir les images statiques des posts non sensibles derrière un script, ça va alourdir inutilement toutes les pages...
Il faut qu'on réfléchisse au rôle des tags dans tout ça du coup, parce que leur intérêt « diminue » une fois que les topics sont bien catégorisés.
En jouant avec la classe qui gère ceci : https://www.planet-casio.com/Fr/adpc/events.php (prototype). Le reste de ce que tu proposes pour les programmes, je suis ok.
Go for it!
Citer : Posté le 20/09/2018 19:32 | #
On peut avoir différentes catégories de privé. Membres de l'équipe, de CC, admins, etc.
Si c'est facile de forger une adresse, alors il faut tout vérifier. Surtout si on veut pouvoir garder la possibilité de déplacer facilement un topic/lui changer ses droits d'accès.
Ce dernier point entraine ainsi l'impossibilité de mettre en place de manière triviale une solution type uploads/adminzone/msg qui elle serait proxifiée.
Ajouté le 20/09/2018 à 19:35 :
Pas tant que ça. L'exemple le plus évident que j'ai en tête, c'est le tag Résolu. Je rappelle aussi qu'on ne peut ajouter que 3 tags max sur un contenu racine, et que les tags sont créés uniquement par l'équipe.
Citer : Posté le 20/09/2018 19:35 | #
Concernant les organisations, mon idée ne vient pas de nulle part, c'est standardisé comme ça dans des protocoles de la fédération de microblogging aussi appelée « fediverse » :
https://www.w3.org/TR/activitystreams-core/#actors
Mais même si on définit occasionnellement plusieurs auteurs pour un post, pas de soucis, ça se représente par un groupe formé spécialement pour un post.
Promotion ordinaire sur les inscriptions sur
Mon blog ⋅ Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Citer : Posté le 20/09/2018 19:38 | #
À vrai dire je ne suis pas très chaud pour entretenir le secret ou quoi que soit sur CC. Je pense qu'avoir des topics privés pour l'équipe suffit, et qu'on n'a besoin de rien d'autre. Si on veut communiquer de façon secrète, un forum (place publique) n'est pas le bon endroit, on n'a qu'à le faire par mail.
Pour assurer l'étanchéité des droits de façon un peu plus générales, je propose que les scripts exécutés par un membre de l'équipe ou administrateur se change en un groupe spécial (genre staff) qui ait les droits d'accès aux fichiers concernés en lecture. Les membres normaux pourront avoir l'URL, mais l'accès au fichier leur sera interdit par les permissions de Linux.
Okay pour les tags qui ne caractérisent pas particulièrement le contenu alors. On verra ce qu'on arrive à en faire.
Admettons, mais ça ne me convainc pas spécialement qu'on en a besoin sur Planète Casio...
Citer : Posté le 20/09/2018 19:49 | #
Je prenais l'exemple comme ça, mais je pars du principe que la v5 doit pouvoir être modulable facilement et finement. Quand on voit le bordel que ça a été pour mettre des topics privés ailleurs que dans la section privée, je me dis qu'on peut faire mieux.
Tiens, autre exemple intéressant : les news postées en avance, comment tu gères les permissions des contenus ? D'autant plus si, par exemple, des images annoncent un concours. On pourrait suggérer de les mettre dans la section privée puis de les déplacer, mais tu perds encore une fois en souplesse, c'est un bordel montre à gérer (tout déplacer à la bonne heure) et c'est pour le coup pas du tout intuitif.
Perso je vois pas d'inconvénients à mettre un nom random sur un fichier. C'est ce qui est fait avec 100 % des hébergeurs d'image par exemple, et ça pose de problème à personne pour les intégrer un peu n'importe où.
Ah oui, j'oubliais, mais il va de soit que, dans ce cas de figure, on n'autorise pas l'autoindex dans les répertoires…
Pour les organisations, on peut valider le fait que c'est pas prioritaire du tout, mais qu'avec ce que j'ai proposé plus haut, c'est facilement implémentable en cas de besoin ?
Ajouté le 20/09/2018 à 20:08 :
Vlà comme promis le diagramme mis à jour.
Pour info, les images ont une durée de vie d'un an.
Citer : Posté le 20/09/2018 20:28 | #
Ok, eh bien voilà : on a deux systèmes, images statique normale et image protégée par un script, et les membres de l'équipe peuvent cocher une case pour utiliser le mode protégé quand ils uploadent.
Vraiment, je suis pas chaud pour toucher aux noms de fichiers. On n'y gagne rien en plus...
Citer : Posté le 20/09/2018 21:28 | #
Et comment tu fais pour migrer les fichiers protégés vers le non protégé, proprement et automatiquement lorsqu'une news sort ?
Parce que si on laisse les images protégées (même sans droits) en page d'accueil, ça revient au même.
Citer : Posté le 20/09/2018 21:47 | #
La news est publiée par une cron, on peut probablement migrer les images au passage.
Citer : Posté le 20/09/2018 21:54 | #
J'aimerai avoir d'autres avis, parce que ça me parait bancal, peu évolutif et pas safe.
Citer : Posté le 20/09/2018 23:14 | #
Imaginez que je suis un cheveux et vous vous êtes la soupe. Et bien me voilà, vous interrompant sauvagement et de manière totalement impromptue, pour vous demander s'il est prévu d'avoir un lien direct vers un dépôt Git depuis la page d'un programme lorsque celui-ci l'utilise ?
La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Citer : Posté le 21/09/2018 06:28 | #
Bien vu !