Parlons de Gladys V4

[peb]

@pierre-gilles

Je ne vois pas l’idée ^^

En fait, l’idée est d’empêcher l’exécution ou non d’une scène si un appareil n’est plus présent ou pas dispo. S’il est nécessaire : erreur, s’il est facultatif : avertissement.

@pierre-gilles

Ici, je parlerais du dashboard d’accueil.

Les deux types de dashboard me semblent une bonne idée !

Je pense que l’utilisateur sera moins perdu s’il a le contrôle sur les deux coordonées. Pour moi c’est plus sûr de se dire que la boite est à gauche et en dessous de la boite X, plutôt que seulement après telle autre boite.

@pierre-gilles

Au final, ces guidelines sont valables pour l’ensemble de Gladys, mais bon les box sont un bon exemple.

Pour le cycle de vie des boxes, j’approuve à 100% !

Quelques ajouts aux guidelines :

• Mettre des loaders dès le démarrage de la box, ça évite d’avoir des box vide au chargement de la page
• Mettre des loaders par sous-partie de la box peut se révéler intéressant. (Exemple : La vérification des utilisateurs présent peut être fait à des moments différents et/ou prendre plus de temps pour un utilisateur que pour les autres)
• Utiliser un code couleur et des icônes pour les informations/avertissements/erreurs, ça aide visuellement à savoir ce qui se passe.
• Mettre uniquement les informations essentiels dans les box, quand il y a beaucoup de choses à mettre (gestion des ampoules par exemple) utiliser tout l’espace à disposition, sous forme de grille plutôt que de liste

Ces quelques points peuvent paraître évidemment, ou simplets, mai ils aident à améliorer l’UX et l’UI

EDIT cursiosité : Est-ce qu’il sera possible d’avoir des box qui prennent 2 ou 3 colonnes pour les box qui prennent de la place, comme le calendrier ?

[lmilcent]

Super boulot

C’est fou comme, en un an a peu près, la documentation pour les développeur s’est améliorée ! C’est même devenu un des points important dont tu t’occupe (et d’autres) et tant mieux car c’est le plus important pour enrichir Gladys.

@pierre-gilles

L’utilisateur doit savoir quand quelque chose se passe en arrière-plan. Si vous lancez une requête, vous devez l’indiquer dans l’UI avec le loader de Gladys 4 standard.

J’ajouterai qu’il faut aussi un timeout.
En tant qu’utilisateur je n’aime pas voir un loader tourner en boucle pendant 10 minutes sans infos. Je préfère qu’une erreur soit affichée après quelques secondes voire une minute.

[jeremy37]

@pierre-gilles
Je pensais à un truc quand je faisait mon scenario sur android. ça serait dur d’avoir des scenario “graphique” comme automate sur android ?

Bon j’ai plein d’idée mais je n’ai pas les connaissances malheuresement

[AlexTrovato]

@pierre-gilles j’ai l’impression qu’il n’est plus possible de créer un compte, on est directement redirigé vers la page de login, mais mon image docker est toute neuve.
Une idée ?

[pierre-gilles]

@peb

En fait, l’idée est d’empêcher l’exécution ou non d’une scène si un appareil n’est plus présent ou pas dispo. S’il est nécessaire : erreur, s’il est facultatif : avertissement.

Je vois, mais comme je disais je ne pense pas que ce soit à l’utilisateur de décider ça. Nous on conçoit un système qui marche, c’est tout.

@peb

EDIT cursiosité : Est-ce qu’il sera possible d’avoir des box qui prennent 2 ou 3 colonnes pour les box qui prennent de la place, comme le calendrier ?

Ce n’est actuellement pas possible, mais ton idée est intéressante. Actuellement ce que j’ai fais c’est un système de 3 colonnes clairement séparé. Fixe en largeur et infinie en hauteur:

Après, si on regarde le template que j’utilise, eux ils ont une grille différente.

Ils ont seulement 2 colonnes principales, et dedans ils découpent:

Ce serait possible de faire ça, mais mon avis c’est que ce genre de dashboard est beaucoup moins beau en vrai qu’en mockup Je m’explique:

Pour diviser ta colonne en 3 comme ils font, il faut avoir 3 boxs similaire à placer. Disons 3 box température. Pareil pour diviser en 2.

Et si jamais tu n’as que des box « larges », et bien ton écran n’est coupé qu’en deux.

Ce qu’on pourrait faire, c’est laisser une certaine liberté à l’utilisateur d’avoir 1, 2, 3, 4 colonnes, et ensuite de re-découper à l’intérieur de chaque colonne. Néanmoins, ça reste un assez gros développement de faire un « dashboard builder récursif ».

Je garde l’idée en tête et je vais regarder, mais pas sur que ce soit un chantier pour l’alpha.

@lmilcent

Super boulot

Merci!

@lmilcent

J’ajouterai qu’il faut aussi un timeout.

Effectivement, il faudrait le préciser.

@jeremy37

@pierre-gilles
Je pensais à un truc quand je faisait mon scenario sur android. ça serait dur d’avoir des scenario “graphique” comme automate sur android ?

Hello! J’en ai parlé plusieurs fois et personnellement je ne suis pas fan de ce genre d’éditeur, c’est pas très grand publique je trouve.

Je trouve que c’est une approche très « programmation » qui nous parle beaucoup à nous mais peu à des non programmeurs. Et surtout visuellement c’est vite de le bazar.

@AlexTrovato

@pierre-gilles j’ai l’impression qu’il n’est plus possible de créer un compte, on est directement redirigé vers la page de login, mais mon image docker est toute neuve.

Ah, j’ai effectivement changé un truc là dessus récemment, je vais regarder.

Ce que j’ai rajouté c’est la sécurité habituelle: il n’est possible de créer un compte que si la table user est vide en DB. Si il y a déjà un utilisateur, il n’est possible que de se logguer.

[pierre-gilles]

Pour ceux que ça intéresse, je vous propose un appel développeur demain samedi 18 Mai à 9h heure française pour vous montrer comment setup un environnement de dev Gladys 4 !

ça se passe ici:

[ Appel développeur ] Je vous montre comment setup Gladys 4 pour développer

Salut à tous! Suite à la demande de @NilkOne, je vais faire un appel ce weekend avec qui veut pour vous montrer comment installer Gladys 4 sur votre machine, et comment développer pour Gladys 4 Comme je l’ai annoncé récemment, il est l’heure de migrer/développer des services Gladys 4, c’est donc le bon moment si vous voulez aider! Je vous propose ce samedi 18 Mai à 9h heure française. Qui est intéressé ? :warning:Attention, cet appel s’adresse à un public qui s…

cf @NilkOne

[jeremy37]

@pierre-gilles

Hello! J’en ai parlé plusieurs fois et personnellement je ne suis pas fan de ce genre d’éditeur, c’est pas très grand publique je trouve.

Je trouve que c’est une approche très “programmation” qui nous parle beaucoup à nous mais peu à des non programmeurs. Et surtout visuellement c’est vite de le bazar.

Pas de soucis et ton point de vu n’est pas faux

[pierre-gilles]

Si vous vous demandez comment mettre en place un environnement de dev Gladys 4, le replay de l’appel est en ligne!

Mettre en place un environnement de développement Gladys 4

[pierre-gilles]

Afin que ce soit clair pour les nouveaux arrivants, j’ai fermé toutes les issues ouvertes sur le repo Gladys 3, et à la place j’ai créé une issue:

[TO READ FIRST] Update 19 May 2019 : Working on the next major release of Gladys, Gladys 4 🚀

Cela permet de rediriger ceux qui veulent aider vers le repo Gladys 4

Bien entendu, lors du déploiement de Gladys 4, le repo “gladys-4-playground” sera mergé sur le repo Gladys principal.

[Pti_Nico]

Salut @pierre-gilles,
Beau boulot pour la V4

En regardant un peu les PR en cours, je me suis rendu compte que beaucoup de modification de code était du à la mise en forme des fichiers (exemple ci-dessous) :

N’y aurait-il pas moyen d’ajouter un linter, ou une configuration type pour chaque IDE, pour éviter ça ?

Pour info, au boulot, sur mon projet actuel, on utilise Husky, qui permet de checker le code avant chaque ‘git push’. Pour résumer, ça lance les tests et le linter à chaque ‘git push’, pour pas tout péter

[NilkOne]

Salut @pierre-gilles , super job !

Concernant la page des services “Integrations”, je rejoinds l’idée de @Tlse-vins et de @peb :

• ajouter une catégorie “Mes services actifs / configurés”
• et une catégorie “Tous les services (disponibles)”
  Ce sera plus clair pour l’utilisateur à mon sens.

@pierre-gilles, concernant ta question sur le dashboard :
je suis partisan pour le mode édition avec les flèches de positionnement, celui que tu montres dans le gif, je trouve ça top
et puis par la suite le drag n drop dans l’idéal.

Y a t-il un doc d’une roadmap avec l’ensemble des dev / évolutions recensées ? (par toi et les demandes de la communauté) puis les précisions de ceux qui sont planifiées ? ainsi que des votes ?
ou est-ce qu’on utilise uniquement les issues de Github ?

[pierre-gilles]

@Pti_Nico

N’y aurait-il pas moyen d’ajouter un linter, ou une configuration type pour chaque IDE, pour éviter ça ?

C’est le cas, et je peux t’assurer que je suis plutôt un extrême là dessus

Tu as un fichier .eslintrc.json pour le server, et le front.

Là il s’agit d’un fichier .json, effectivement il doit manquer une indication pour ce genre de fichiers, je vais vérifier.

@Pti_Nico

on utilise Husky, qui permet de checker le code avant chaque ‘git push’.

Je ne suis pas fan des pre-commit/pre-push hooks, ça n’encourage pas un rythme de commit/push fréquent (si tu dois attendre 7 minutes pour pusher tu le fais moins souvent). C’est assez controversé comme pratique.

Pour moi, comme chaque push est forcément sur une PR, c’est côté CI que ça doit péter et indiquer que le style de code n’est pas bon. Après c’est à la discrétion du développeur de lancer les tests en local avant de pusher, si il ne le fait pas c’est tant pis pour lui il verra sur le CI qu’il y a des erreurs de linting et il devra les corriger pour que sa PR puisse être mergée

@NilkOne

• ajouter une catégorie “Mes services actifs / configurés”
• et une catégorie “Tous les services (disponibles)”
  Ce sera plus clair pour l’utilisateur à mon sens.

Je suis d’accord, il va falloir trouver un moyen d’afficher ça dans l’UI… pour l’instant j’ai rien en tête.
Si quelqu’un a une idée, je suis preneur.

@NilkOne

Y a t-il un doc d’une roadmap avec l’ensemble des dev / évolutions recensées ? (par toi et les demandes de la communauté) puis les précisions de ceux qui sont planifiées ? ainsi que des votes ?
ou est-ce qu’on utilise uniquement les issues de Github ?

Oui! Tu as sur GitHub 70 issues, chaque issue est une feature à développer.

Pour la roadmap elle se trouve plus haut dans ce sujet, mais elle est aussi inscrite dans GitHub avec 6 milestones créés avec chacun une date de release:

[pierre-gilles]

@Pti_Nico: Après m’être renseigné, le linting de fichier .json c’est pas simple. J’ai ajouté une règle Eslint pour être sur que les fichiers JSON sont bien formatés, après pour valider l’indentation par exemple, j’ai rien trouvé. Si tu as une lib/plugin eslint en tête, je suis preneur.

Une solution pourrait être de transformer ces fichiers en .js, mais je suis vraiment pas fan de cette solution (car du coup ça compte comme “ligne de code” alors que c’est de la conf). Et surtout pour les fichiers de traductions ça nous empêche d’utiliser des tools automatique genre POeditor qui mange des JSON.

[Edit]: J’utilisais déjà Prettier, mais il était pas enforce. Au niveau du style il est plus strict que ma config actuelle, j’ai donc setup prettier sur le back + front. Normalement on devrait plus avoir de problème.

Normalement, si tu configure le format on save sur VSCode, ton code sera nickel avec prettier et passera au CI

[pierre-gilles]

Salut à tous!

Ce matin j’ai réfléchi sur le process de CI/build de Gladys 4. L’objectif est d’avoir un process 100% automatisé et surtout performant.

J’aimerais voir si on pourrait utiliser CircleCI au lieu de TravisCI pour le CI. L’utilisant sur d’autres projets, c’est vraiment plus rapide que Travis.

Voilà les étapes du processus de build que j’ai en tête:

Explication:

• Ce schéma est un “Workflow” CircleCI.
• Chaque bloc est un “build” CircleCI.
• Les flèches indiquent des dépendances entre les build. Les builds en vertical sont exécutés en parallèle, et pour passer au groupe de blocs suivant, il faut que tous les builds précédent soient exécutés. Exemple: Ici, “Netlify Webhook” ne sera exécuté que lorsque les 4 build Docker seront terminés.

@VonOx ça devrait t’intéresser ! Si tu as le temps pour qu’on regarde ça ensemble je serais chaud

J’ai créé une issue Github pour référencer le développement:

https://github.com/GladysAssistant/gladys-4-playground/issues/120

[pierre-gilles]

@pizza6

pourquoi rebuilder le gateway frontend dans une étape de release ?

Car le frontend du Gateway sera le même frontend que Gladys dans Gladys 4 Dans Gladys 4, il sera possible d’aller sur gateway.gladysassistant.com et de voir la copie conforme de ce que tu vois en local sur Gladys ! (mais hors de ton réseau en passant par le gateway en chiffré de bout en bout)

@pizza6

Personnellement la partie documentation + demo website, j’aurais plus vu ca dans un step “Documentation” que “Release”.

C’est juste un nom dans ce schéma ^^ Pour moi, c’est la même chose, quand on release on release tout: du code à la documentation.

@pizza6

De même la partie “Building” dans la mesure où elle fabrique certes l’image mais elle push surtout dans le registry ressemble pour le coup plus à une étape de “Release”, non ?

Si tu veux Je peux retirer les noms au dessus si ça te gêne ^^ c’est purement à titre indicatif dans ce schéma.

@pizza6

D’ailleurs ne devrais-tu pas tagger aussi ton code github une fois le build de l’image réussi ?

Le tag est à faire par le développeur, pas par l’intégration continue. C’est le développeur qui choisit de sortir une nouvelle version de Gladys! D’ailleurs si tu regarde le bloc n°3 entre « Testing » et « Building », le CI ne passe à « Building » que si il s’agit d’un build taggué, pas un push classique sur une branche (ou dans ce cas là seul les tests sont exécutés)

[VonOx]

Oui Avec plaisir.

[Tlse-vins]

Salut à tous,

je sais que Gladys peux être installé sous Windows, Linux, Raspeberry, …;
Mais est ce que Gladys V4 pourra être installer sous respeaker V2?

[pierre-gilles]

@VonOx

Oui Avec plaisir.

Je vais faire un premier setup CircleCI aujourd’hui, tu pourras m’aider pour la partie build Docker ARM ensuite? (c’est toi l’expert là dessus!)

@Tlse-vins

Mais est ce que Gladys V4 pourra être installer sous respeaker V2?

Je suis allé voir, le Respeaker v2 c’est du Debian, comme le Raspberry Pi. A mon avis ça tournera sans problèmes (tout comme Gladys 3 devrait fonctionner sur le Respeaker v2 sans problème)

[VonOx]

Oui une fois que tu as push je fork

[pierre-gilles]

@VonOx Finalement ça sera plutôt demain!

Aujourd’hui j’ai continué mon travail sur les boxs de l’écran d’accueil, j’arrive au bout de cette partie.

J’ai notamment beaucoup bossé sur la box “Camera”, et notamment sur le service “RSTP Camera” de Gladys 4.

C’est très proche de ce qu’avait fais @piznel sur Gladys 3, j’utilise ffmpeg pour lire un flux RTSP et garder l’image la plus récente des caméras en mémoire (j’en ai déjà parlé plus haut dans ce topic si ça vous intéresse)

Quand le frontend charge et request une image de caméra, une image compressée est envoyée au frontend par Gladys elle même (sans donc appeler la caméra en direct), ce qui a l’avantage de fonctionner même hors du réseau ET même via le Gateway, et c’est ça qui est fort!