Compte-rendu de la réunion de développement de la v5
Posté le 07/06/2018 23:05
On a fait ce soir une réunion de la v5... pour se poser des objectifs MALINS. Alors voici pour vous l'état actuel des choses.
Le cycle en V
On part sur une méthode classique de développement : le cycle en V. Ça part d'en haut à gauche et ça va jusqu'à en haut à droite. À gauche, on conçoit de plus en plus détaillé, ensuite on implémente, et à droite on vérifie que le contrat qu'on avait annoncé à gauche a bien été effectué.
Analyse des besoins Recette
\ /
Spécifications Tests de validation
\ /
Conception architecturale Tests d'intégration
\ /
Conception détaillée Tests unitaires
\ /
Implémentation
Analyse des besoins
La première étape consiste à donner les grandes lignes du design : à quel besoin on veut répondre. En gros on a préparé ça avec Darks sur notre pad de brainstorming v5 il y a (déjà !) quelques années. Ce pad est un peu long mais il est public : vous pouvez aller le lire à loisir. (Veuillez ne pas le modifier toutefois.)
Pad Planète Casio v5
Un
document résumé de ce pad (qui n'est pas écrit dans un style très digeste) sera publié sur le forum pour que tous les membres puissent prendre connaissance de nos grands plans de chantier (deadline pour ce document: 10 Juin). Tous les contributeurs devront absolument le lire avant de commencer !
Spécifications
C'est là qu'on en est : les spécifications sont notre prochaine étape ! Il faut définir de façon plus précise
ce que la v5 sera du point de vue extérieur. On ne se pose pas encore la question de comment on la code ou comment elle marche en interne, mais on spécifie le résultat que l'on veut obtenir.
Par exemple, « les commentaires de programmes doivent posséder toutes les fonctionnalités des messages du forum » est une spécification un peu vague mais intéressante. On en déduira plus tard « la classe
Program hérite de la classe
Topic ».
Cette phase a déjà été un peu couverte par le pad ci-dessus où Darks et moi avons discuté un peu de tout de façon informelle, mais les spécifications doivent être détaillées et surtout
elles doivent être exhaustives. Si quelque chose manque dans les specs', on ne peut pas coder. Alors on pourra toujours affiner en cours de route, mais le but c'est de couvrir un max de terrain.
Tout ceci, on le fait dans un autre pad public, que vous pouvez aller lire sans compte et
dans lequel vous pouvez écrire ; n'hésitez pas à le surveiller et à donner régulièrement votre avis !
Stay tuned!
Pad Spécifications v5
Conception architecturale
Une fois la phase de spécifications finie, on passera à la conception architecturale. Il faudra diviser la v5 en petits morceaux indépendants qui communiquent d'une façon bien définie, et décomposer ces modules en morceaux avec des APIs...
J'ai déjà des bouts réutilisables pour cette phase, que j'ai écrits quand j'ai eu une idée claire du système de comptes ; ça me servait abusivement de specs'. C'est à cette phase que l'on définira la REST API.
La suite
C'est encore trop tôt pour parler des autres phases. Alors parlons de nos prochaines deadlines !
10 Juin: Mise en place de
http://v5.planet-casio.com
Le serveur peut délivrer des fichiers statiques mais on ne peut pas encore utiliser de scripts Python. Au 10 Juin il faudra qu'on puisse tester le code du Git avec !
Fait depuis : voyez le topic d'annonce
10 Juin: Tutoriel pour créer une environnement de développement local
Car on code avec nginx, sous Linux, avec Flask et
uwsgi... et c'est pas facile à configurer ! Un bon tutoriel pour mettre ça en place aidera les contributeurs à s'y retrouver.
Fait depuis : voyez Environnement de développement sur le wiki du dépôt
10 Juin: Une machine virtuelle de développement
Les utilisateurs de Windows ou les frileux de l'administration système pourront installer une machine virtuelle qu'on fournira pré-configurée avec un environnement de dev' pour tester la v5, la modifier en local, et partager les modifications sur le Git.
Fait depuis : voyez l'issue sur le dépôt
10 Juin: Le document de design
Fait depuis : voyez Analyse des besoins sur le wiki du dépôt
Samedi 23 Juin: La prochaine réunion !
Ce sera une réunion vocale pour aborder la suite du programme. Probablement planifiée à 20 heures sur le Mumble, comme pour aujourd'hui. Afin de pouvoir avancer, on incite très très fortement les participants à se préparer à l'avance, c'est-à-dire :
- Lire le document de design, qui aura été publié entre-temps
- Tester les Framapads ci-dessus, vérifier qu'il peuvent lire
et modifier
- Si vous planifiez de coder quelque chose, créer un compte sur le Gitlab
- De la bonne humeur !
C'est tout pour ce soir. On peut préciser ce qui n'est pas clair dans les commentaires, alors si vous avez des incertitudes, lâchez-vous !
Citer : Posté le 07/06/2018 23:13 | #
Je précise (très rapidement, je reviendrais là dessus) que toutes les bonnes volontés, qu'elles sachent programmer ou non, sont invitées à se manifester par le biais de la mailing-liste : https://framalistes.org/sympa/info/planetecasio-dev
On cherche des gens pour définir les specs, coder du Python, coder du html/css, coder du Js, faire de l'administration système, dessiner des visuels, rédiger des contenus, bref, faire plein de trucs. Donc si ça vous branche, inscrivez-vous sur la mailing
Citer : Posté le 07/06/2018 23:52 | #
Normalement, pour poser des objectifs MALINS, faut formuler sa phrase du type « Au 10 juin, nous aurons fait ceci » par exemple, mais je suis juste relou pour pas grand chose, c'est déjà super ce que vous avez posé ! Et 3 jours, vous êtes ambitieux
Mon blog ⋅ Mes autres projets
Citer : Posté le 08/06/2018 09:51 | #
J'ai complétement zappé la réunion ><.
Citer : Posté le 08/06/2018 09:57 | #
C'est pas faute d'envoyer des mails
Pour la prochaine j'essayerai de faire un rappel un jour avant.
Citer : Posté le 08/06/2018 09:57 | #
On en fait une autre samedi 23 à 20 heures, alors tu pourras toujours te rattraper !
Citer : Posté le 09/06/2018 11:15 | #
Merci pour ce compte-rendu ! Ca fait plaisir de voir des objectifs et des deadlines.
On sait qui fait quoi d'ici demain minuit ?
Merci Darks pour la mailing-liste, je m'y suis inscrit.
La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Citer : Posté le 09/06/2018 11:16 | #
Les deux premiers points sur pour moi, les deux autres pour Darks, en gros !
Edit : J'ai validé ta demande d'inscription.
Citer : Posté le 09/06/2018 11:20 | #
Ah ouais ça fait beaucoup de boulot pour deux...
T'es vraiment sur tous les fronts Lephé' !
Sur les quatre points je ne sais pas trop comment aider. Éventuellement pour la définition des spec' je peux faire un tour sur la centaine de page des suggestions et essayer de trouver des choses que la v42 ne propose pas mais qui pourraient être sympa à inclure dans la v5. Si ça n'est pas le moment dites moi, je trouverai bien autre chose à faire.
La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Citer : Posté le 09/06/2018 11:27 | #
En fait, tant que le document de design n'est pas prêt (il est actuellement sur le wiki mais j'aimerais le relire au moins une fois), vous pouvez difficilement contribuer. Éventuellement, tu peux trouver à la ligne 299 du pad Planète Casio v5 un condensé de toutes les choses intéressantes qui ont été dites sur le topic de suggestions de PC ; comme il n'y a plus de numéros de pages indiqués, c'est que j'ai dû finir de lire toutes les pages. Ce sont de sujets typiques que tu peux commenter pour faire avancer la réflexion. Merci de ton aide.
Je ne suis pas administrateur de ce site pour rien ! Et tu ne le sais pas encore car tu n'as pas été à la réunion, mais j'ai déjà configuré la moitié les jours précédents, comme en témoigne cette page statique :
http://v5.planet-casio.com/static/index.txt
Citer : Posté le 09/06/2018 15:53 | #
Je voulais pas pourri le doc donc je le mets ici pour le moment :
La v5 doit limiter l'usage des ressources, que ce soit coté client ou serveur, et que ce soit d'un point de vue bande passante ou consommation CPU.
Réduction du nombre de requêtes
Fusion des scripts communs
Optimisation des CSS
Utilisation des icones en base64
Optimisation des caches
Réduction de l'usage du Javascript au strict minimum, là où il est nécessaire pour la fonctionnalité
Limitation du nombre d'images chargées : utilisation des icones en base64
Pour les parties en gras : depuis quand réduire le nombre de requêtes en augmentant la bande passante utilisée est une optimisation ? Surtout à l'heure où les navigateurs font un max de requêtes en parallèle… (corrigez-moi si je me trompe).
Pour la partie soulignée : les fonctionnalités utilisant le JS doivent être facultatives (qu'il ne soit pas critique de ne pas les avoir). Donc j'ai envie de dire qu'il n'est jamais nécessaire, mais je pense que les fonctionnalités ne sont pas « avoir des notifications » mais « avoir un "pop-up" de notification », par exemple (je veux dire que ça dépends de la façon de voir les choses, je sais pas si c'est clair).
Citer : Posté le 09/06/2018 16:02 | #
Oui, envoyer un seul gros fichiers est plus rapide que plusieurs petits.
Source : https://medium.com/@asyncmax/the-right-way-to-bundle-your-assets-for-faster-sites-over-http-2-437c37efe3ff
Citer : Posté le 09/06/2018 16:03 | #
Tu tapes très précis je vois. J'étais tombé sur ce passage et je voulais justement le modifier. La base 64 n'est pas une solution très intéressante ; utiliser du clipping est probablement plus efficace à la fois en termes de requêtes et en termes de quantité de données chargées.
Pour le JS, il peut traîner des choses à la con, un peu comme les cookies qui sont nécessaires de se connecter. La vision que j'en ai, c'est qu'on doit faire marcher le forum avec le minimum de JS, et qu'ensuite on peut en rajouter autant qu'on veut tant qu'il y a des options pour le contrôler. D'où les fonctionnalités en plus. Je pense que je vois ce que tu veux dire avec la pop-up ; je propose une autre analogie entre « voir les réponses aux topics » et « voir les réponses aux topics en temps réel ».
Citer : Posté le 09/06/2018 16:32 | #
@Xavier59 : effectivement, cependant la base64 augmente de 30 % la taille des fichiers (environ et en moyenne), donc je ne suis pas sûr que ce soit vraiment une bonne idée. De plus, cela dépends de la connexion utilisée, je suppose.
Le clipping n'augmentant pas la taille de la donnée, l'idée me semble déjà plus intéressante.
@Lephenixnoir : oui, aussi, par exemple. On est d'accord.
Citer : Posté le 09/06/2018 21:23 | #
Bon voilà, j'ai pas mal avancé déjà, et j'ai sorti une première version du tutoriel d'installation d'un environnement de développement.
Experts only pour l'instant parce qu'il y a pas mal de petites choses à ajuster.
Et à côté de ça, le serveur de dev est presque en place ! Je posterai une update quand je serai arrivé au bout
Citer : Posté le 10/06/2018 00:10 | #
La base64, c'est uniquement pour les icônes, donc pas grand chose finalement. En fait je pars du constat que la très grande majorité des requêtes actuelles sont pour charger des images (icônes, css, smileys, etc.) qui peuvent sûrement être intégrées à la page d'une manière plus efficace.
Après on peut virer ça. Dans les besoins faut juste laisser « Le site doit être optimisé pour un chargement rapide ». Les solutions techniques, ça vient dans les specs voir la conception architecturale.
Ajouté le 10/06/2018 à 00:10 :
Et parfait pour le tuto, je m'occupe de la VM demain !
Citer : Posté le 10/06/2018 13:01 | #
Hello ! Je passais dans le coin et le sujet a l'air intéressant
Au niveau des icônes, vous parlez de quelles icônes en particulier ?
Suivant les besoins, le mieux en terme de poids et de qualité c'est les images vectorielles (svg), surtout que la densité de pixels augmente de plus en plus sur de nombreux écrans, et les images matricielles apparaissent flou si on ne prévoit pas de x2 (voire x4).
Sinon pour les images qui nécessitent obligatoirement du matriciel c'est une bonne idée de partie sur du clipping !
Ensuite pour le fait de tout mettre dans le même fichier : Oui et non.
Certes le chargement de la première page sera plus rapide, mais je ne suis pas sûr que le navigateur puisse cacher ces images / fichiers pour les prochaines pages donc on multiplie la bande passante utilisée par le nombre de pages consultées.
Je me trompe peut-être après, j'ai pas testé pour voir si les base64 / script intégrés dans une balise HTML étaient cachés :x
Citer : Posté le 10/06/2018 13:05 | #
Par exemple les icônes qui sont actuellement au-dessus de l'éditeur de messages, et pour lesquelles il n'existe pas forcément de caractères unicode. Les smileys, peut-être... et puis les petites icônes qui traînent sur les pages statiques, il y en a partout.
Pour ce qui est de tout mettre dans le même fichier, Xavier faisait juste référence au clipping je pense. Pour justifier que les performances étaient meilleurs que servir des icônes individuelles. Côté cache je pense que c'est toi qui as raison en tous cas.
Du reste oui, le SVG est une question à étudier ; plus moderne, vectoriel... une police pourrait aussi servir pour ça, je ne sais pas quels sont les effets en termes de performance mais il me semble que pour le rendu pur côté navigateur c'est intéressant.
Citer : Posté le 10/06/2018 20:22 | #
Les polices d'icônes, je suis pas chaud du tout, ça donne des trucs juste immondes dans le code, et je mâche mes mots. Le reste, ça s'étudie, mais en effet les images dans le html en base64 ne sont pas inclues dans le cache.
Enfin, c'est du détail technique, on en est pas encore là
Citer : Posté le 10/06/2018 21:41 | #
Ça y est, la v5 est en ligne, le serveur est configuré, le service est configuré, tout roule !
»» http://v5.planet-casio.com/ ««
Plus qu'à configurer la mise à jour automatique du git depuis SSH et on aura, à quelques ajustements près, un environnement de développement aussi complet que celui de la v42, mais en plus reproductible en local et tweakable à loisir puisqu'on a les accès au serveur.
Champage !
Citer : Posté le 11/06/2018 19:06 | #
La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !