Ok donc aller ! Je vire mon repo et je re-clone dés que c’est bon de ton coté !
Il n’empêche que si chaque personne qui veux dev pour Gladys doit pensé a reconfigurer son git il va forcément y avoir des soucis 
En espérant qu’on n’ai pas en arriver la…
C’est fait! tu peux reclone 
Oui, mais bon là c’est un truc hyper basique de développement, 100% des projets de développements informatique ont ce problème, et absolument tous les projets sérieux vérifient ça.
ça m’étonnerait qu’il n’y ait pas de solution
Ok alors c’est parti !
Bon problème fixé grâce au fameux fichier .gitattributes ! Merci @MathieuA d’avoir trouvé ça, au moins tout marchera pour les contributeurs windows
@MathieuA je veux bien ton avis sur la nouvelle architecture/façon de loader Gladys et les controllers.
Sinon, j’ai activé le check des types grâce à JSDoc + Typescript CLI (sans écrire de Typescript, juste en utilisant les commentaires)
Ah oui avec cette histoire j’ai pas pris le temps de regarder !
Pas mal le coup des classes ! Effectivement c’est plus jolie que des require sur chaque fichier ^^
Pour le coup ça me perturbe un peu d’avoir un dossier lib et un autre api. Surtout que j’aurais fais l’inverse perso
Dans le dossier api j’aurais mis le core de Gladys car je trouve ça un peu plus logique (si on peut dire ça comme ça) mais bon c’est une préférence perso
Je suis d’accord.
Sinon on peut renommer lib en core…
Ou alors mettre carrément ce dossier core dans api
api
----- controllers
----- core
----- middlewares
----- routes.js
----- index.js
Et alors renommer api en lib 
lib
----- controllers
----- core
----- middlewares
----- routes.js
----- index.js
En vrai je viens d’aller voir d’autres repos, j’ai vu du api et du lib, ça me choque pas tant que ça en fait.
Pour moi lib c’est vraiment Gladys core le code, et api c’est l’API Rest
Ouais je pense que c’est un peu à la préférence de chacun la dessus, il y a pas vraiment de best pratice !
C’est ton projet donc c’est toi qui décide, si pour toi c’est bon comme ça alors banco ^^
J’aime bien avoir des avis extérieurs, c’est important On va commencer comme ça on verra les autres retours.
Raah les index + foreign key avec Sequelize c’est le feu
C’est méga lourd 
J’ai mis à jour le README du repo Gladys 4 Playground avec toutes les instructions d’installations pour tester
N’hésitez pas à tester chez vous!
https://github.com/GladysAssistant/gladys-4-playground
Si vous cherchez un bon tool pour explorer des DB SQLite, je vous conseille TablePlus:
Franchement pas mal la structure très clair ! Petite question, je vois que tu utilise “joi”, pourquoi pas directement utiliser juste les contraintes de sequelize ?
Je pense que les contraintes de Sequelize ne seront pas suffisantes pour tout, je pense notamment pour valider les objets des scènes où des triggers qui seront des objets json nested.
Après tu as raison, ça vaudrait peut être le coup de tester de mettre cette validation supplémentaire dans une fonction dans le model 
Bonne remarque, je vais regarder.
Question orienté sécurité, dans ton manifest j’ai vu que tu avais dis de bien choisir les librairies qui ne sont pas pété. Par contre j’ai pas l’impression que tu mets en place un système permettant de check qu’un jour ces librairies sont justement cassé !
Peu-être il serait intéressant de soit:
Mais c’est compliqué, le mettre en place chez tout le monde ? ou juste quelques développeurs ? Ca permet de peut-être mettre en place des patch sécurité si besoin.
De plus, il faudrait je pense obliger chaque développeur de module de forcer à avoir des “good practices”, par exemple valider chaque fois que tel ou tel model a bien été validé au préalable, que l’on ne peut mettre par exemple uniquement une adresse mail dans le champ adresse mail et pas injecter du code / xss etc.
Pour ça c’est super simple:
1/ Github fait des checks-automatique tout seul déjà!
2/ Il y a greenkeeper (https://greenkeeper.io/) qui fait ça automatiquement. Je l’utilisais dans le repo Gladys actuel mais j’avais tellement de notifications à cause de sails qui est un nid à dépendance pas à jour que je l’ai désactivé. Je l’activerais sur Gladys 4! Greenkeeper fait carrément les PR tout seul dès que lib doit être mise à jour!
Complètement d’accord!
Les garde-fou sont fixé par deux choses
1/ Les technos qu’on utilise. Exemple: au niveau du front, Preact ne permet pas de faille XSS, c’est lui qui gère l’affichage des variables et tout est cleané par la lib pour que ce soit bien fait.
2/ Le linting statique. Ca c’est le rôle des règles très strictes que j’ai mis sur Eslint, qui force un coding style consistent et « aseptisé », et effectue un ensemble de check pour garantir une qualité de code. ( ça catch un nombre de bug/faille incalculable)
3/ les tests unitaires/d’intégrations bien évidemment. A nous d’écrire des tests très fin et d’avoir un code coverage élevé afin d’être sur que rien de non voulu ne soit possible. Gros plus, là on écrit les tests dès le premier jour, donc on peut facilement avoir un code coverage dans les > 90% et être robuste là dessus. Autre gros plus, mettre les modules interne dans le core permet d’écrire des tests sur les modules très facilement, et donc d’avoir les mêmes garanties sur les modules que sur le core.
Salut à tous!
J’ai bien avancé sur la modélisation, quasiment tous les modèles sont définis:
https://github.com/GladysAssistant/gladys-4-playground/tree/master/server/models
Niveau base de donnée les migrations ont bien avancées, il me manque à priori que les index et je suis bon!
J’ai effectivement utilisé partiellement ta réflexion, je me suis inspiré de ton repo Github (j’avais les yeux dessus!) quand j’ai fais le travail dessus J’avais perdu le lien du spreadsheet par contre, merci!
1/ Je ne comprend toujours pas pourquoi on voudrait des catégories + sous-catégorie! Si l’idée des catégories/sous-catégories c’est juste d’avoir dans l’UI un menu déroulant avec des catégories et des sous-catégories, alors oui c’est ce que je compte faire Mais c’est juste de l’UI. La base de donnée est une représentation d’une modélisation, mettre 2 fields type “category” “sub-category” ici, est-ce que ça apporterait quelque chose? En terme de modélisation strict, si on sépare un attribut en deux attributs, c’est qu’on souhaite qu’une sous-catégorie puisse appartenir à plusieurs catégories. Pas forcément ce qu’on veut, non? (question ouverte, dis moi si tu as un contre exemple je suis preneur! ).
2/ Une des valeurs que j’ai mis dans le manifeste, c’est que pour Gladys 4 “on ne fait pas tout, mais ce qu’on fait on le fait bien”.
Dans Gladys 3, j’ai trop souvent voulu partir dans tous les sens (pour “être sûr” de gérer le cas), il y a des catégories qui servent à rien, les types c’était open bar, on avait des “sentences” qui était câblé avec rien. Bref: j’ai eu les yeux plus gros que le ventre, et derrière pas mal de donnée statique n’était câblé avec aucun code. Et c’était con parce que l’utilisateur il voit la phrase il se dit “cool je peux gérer XX”, et en fait: non!
Ici j’ai listé la “base minimum” des catégories que je vois. Au fur et à mesure d’ajout des modules (qui seront dans le core je le rappelle), on rajoutera petit à petit des catégories. Mais tant qu’on a rien, pourquoi mettre des catégories si on ne sait pas les gérer?
3/ Ce qu’on s’était dis au meetup développeur, c’était que:
DeviceFeature
Si tu penses à des usages des sous-catégories (autre que trouver ça organisé pour le dev, c’est une modélisation là c’est pragmatique ce qu’on fait! ), dis moi, c’est effectivement un sujet qu’il vaut mieux régler maintenant!
PS: mais sinon oui on peut ajouter le capteur de pression, de toute façon il devra être ajouté dès qu’on ajoutera dans Gladys 4 un module qui doit en créer
