Dev nouveau module Forecast pour v4

Hello à tous,

Nouveau sur Gladys depuis quelques jours, j’ai profité de la release de l’alpha de la v4 pour me faire la main sur le développement de module ce week end.

J’ai donc créé un nouveau module météo car l’actuel me semblait assez sommaire, et je voulais quelque chose de simple pour démarrer (celui ci est toujours base sur l’api darksky).

Voici la liste des évolutions visuelles par rapport à l’existant :

  • Modification de la date pour avoir un affichage du type ‘Monday 01 July’
  • Ajout du nom de la maison servant de point de géolocalisation
  • Modification de la température (précision à 2 décimales)
  • Ajout des icônes météo manquantes
  • Ajout du taux d’humidité et de la vitesse du vent
  • Ajout des prévisions météo horaires pour les 8 prochaines heures avec icônes et températures ressenties
  • Affichage d’icônes de nuit lorsque le temps est clair et que l’heure est avant le lever du soleil ou après son coucher
  • Affichage d’alertes météo lorsqu’une alerte est renvoyée par darksky
  • Mise à jour des données météo toutes les 10 min au lieu de 30

Voici un screen du résultat, avec dans la colonne de gauche le module existant, et dans celle du milieu le mien.

Par contre, je ne suis pas sur de bien comprendre la philosophie (et ses conséquences) de la v4 par rapport aux modules.

On ne peut plus utiliser de modules qui n’ont pas été valides dans le repo principal du projet ? Que se passe t’il si un module n’est pas validé ? Un développeur peut il l’utiliser sur son installation tout de même sans se priver des maj futures, ou tout ce qui n’a pas été accepté officiellement est condamné à rester sur une instance de test sans mises a jour du core par la suite ?

Y a t’il une procédure pour pousser une PR sur le github (avertir / décrire le module / expliquer ses fonctionnalités et son développement / éventuellement discuter du but et de la pertinence de celui ci, etc…) ?

Jacky

4 Likes

Les modules n’existent plus. Faudra s’y faire

Tu as fais un super boulot sur le forecast, mais pourquoi un nouveau service, fallait juste améliorer l’existant car c’est une alpha donc strict minimum côté service.

J’adore le module ! effectivement le mieux serait de modifier l’existant, fait un petit PR pour modifier ca serait cool :slight_smile:

Pour les PR il y’a un template

La logique est similaire à tout les dépôts.

  • Fork
  • branch
  • tu push tes modifications
  • PR

Tu peux consulter le manifest de la V4 si tu souhaites avoir le pourquoi du comment.

https://docs.google.com/document/d/1zqH0vvIRICOiXsgJVHRanInBgJ8aoTWtnrNpyASW9b0/mobilebasic

Salut @Jacky,

Super beau, j’adore ! Vivement la PR :wink:

Merci pour les retours.

J’ai fais un nouveau service uniquement pour monter en compétence sur le développement de Gladys, et voir toutes les étapes nécessaires (et les fichiers à créer/modifier) pour la création de nouveaux modules :wink:

Je vais remettre tout ça dans le module existant avant la PR.

Par contre, j’ai un problème avec les tests, eslint me remonte des erreurs dans le core et quitte avec une erreur, m’empêchant de lancer mes tests.

/Projects/gladys/server/services/zwave/index.js
7:25 error Unable to resolve path to module ‘openzwave-shared’ import/no-unresolved

Impossible d’installer la dépendance openzwave-shared, même après une install système des paquets libopenzwave1.5 et libopenzwave1.5-dev

npm install openzwave-shared

[email protected] preinstall /Projects/gladys/server/node_modules/openzwave-shared
node lib/install-ozw.js
[email protected] install /Projects/gladys/server/node_modules/openzwave-shared
node-gyp rebuildgrep: /usr/include/openzwavevalue_classes: No such file or directory
gyp: Call to ‘grep -r GetTypeNameFromEnum /usr/include/openzwavevalue_classes | wc -l’ returned exit status 0 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: gyp failed with exit code: 1
gyp ERR! stack at ChildProcess.onCpExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:345:16)
gyp ERR! stack at ChildProcess.emit (events.js:189:13)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Linux 4.4.0-17134-Microsoft
gyp ERR! command “/usr/bin/node” “/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js” “rebuild”
gyp ERR! cwd /Projects/gladys/server/node_modules/openzwave-shared
gyp ERR! node -v v10.15.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm WARN [email protected] No description
npm WARN [email protected] No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Error: EACCES: permission denied, rename ‘/Projects/gladys/server/node_modules/.staging/fsevents-de4b6830/node_modules/tar’ -> /Projects/gladys/server/node_modules/.staging/tar-5fb72c61’
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Comment puis je faire pour installer cette dépendance ou pour uniquement lancer mes tests fonctionnels ?

Bah en fait juste un npm install dans le dossier server.

Mais ton install node npm est pas propre, je te laisse chercher :
Error: EACCES: permission denied, rename…

C’est ce que j’avais fait, et l’erreur que tu soulignes était un warning pour une dépendance optionnelle.
Mais peu importe, j’ai refais une install et tout marche bien maintenant.

J’ai également envoyé une PR pour un update du module weather )

Niquel, je te conseille d’ajouter la capture d’écran sur ta PR.

Yes ok, c’est fait )

Salut @Jacky, c’est du super boulot que tu nous as fais là, je t’ai répondu sur GitHub, je t’ai fais une review précise de ta PR :slight_smile:

Rien de méchant, quelques feedbacks à corriger mais globalement j’aime beaucoup.

Pour les autres, en gros j’ai proposé d’avoir 2 styles de box (une option de la box en gros), une box weather “minimale” et une box weather “complète”. Je pense pas que tout le monde ait forcément besoin des prévisions météos complètes sur leur dashboard, donc pouvoir choisir le style fait sens ici.

J’aime bien l’idée qu’on puisse garder une UI assez minimaliste.

Comme dit @Vonox, l’idée de modules c’est fini. Gladys c’est un tout, un produit complet dont on manage le cycle de vie de A à Z pour garantir une expérience qui fonctionne.

Trop de personnes dans Gladys 3 n’arrivait juste pas à utiliser Gladys à cause de l’expérience module qui n’était pas tip top.

Merci pour les retours )

J’avais déjà pensé à cette option, mais j’avais lu dans le forum, que tu souhaitais garder les choses simples, avec le moins de config possible.
Mais ok, je vais ajouter ça.

Concernant les modules, je comprends le point (même si ce de ce j’ai vu en testant la v3 quelques heures, le problème venait plus de la qualité variable des modules que du système ou de la philosophie de modularisation en elle même).
Je pense juste qu’il est dommage que les utilisateurs expérimentés ne puissent pas faire leurs propres modules selon leurs besoins (chacun utilise gladys de façon différente).

Ça aurait pu être fait au niveau de l’architecture, pour ne pas apporter de confusion aux utilisateurs finaux, avec un dossier spécifique ou développer nos modules, dans lesquels on appellerait les services “core” de gladys.

Mais ce qui m’inquiète surtout, ce sont les critères d’acceptation des évolutions proposées.

Par exemple, je compte développer une intégration à un serveur activesync pour récupérer le nombre de mails non lus, des taches en cours, etc… depuis mon serveur de messagerie. Est ce que cela sera accepté sachant que mon développement ne prendra en charge que les serveurs activesync (autrement dit Exchange compatible), et non gmail, apple, etc ?

J’ai bien conscience que l’intérêt de la communauté d’avoir ce module peut être assez limité (il faut avoir un serveur Exchange, et vouloir ces infos dans gladys, ce qui doit concerner peu de monde), mais il est assez grand pour moi…

Comment ça se passe dans ces cas la ?

1 Like

Bah ce sera un service supplémentaire qui pourra servir et être améliorer par d’autres.
Rien ne t’oblige à faire une PR, tu peux garder tes devs de ton côté. Mais je vois pas pourquoi on se priverai d’intégration supplémentaire.

Pour la configuration, il faut rester simple, faut pas être dev sénior pour que le service fonctionne. Mais les barbus du forum seront content de pouvoir paramétrer certaines choses :wink:

Bien vu! C’est vrai pour beaucoup de chose dans Gladys 4, après pour la personnalisation du dashboard comme c’est quelque chose de très personnels là pour le coup je trouve pas ça déconnant si on a plusieurs options pour que chacun puisse faire son dashboard à lui. Faut pas que ça parte dans tous les sens non plus, mais là pour ce cas ça fait sens.

Deux problèmes:

  • “La qualité variable des modules” est 100% dépendante de nos process de développements/release. Avec Gladys 3, tu poussais sur master un truc pas testé et hop ça partait dans la nature. Sur le forum on se retrouvait avec des dizaines de posts d’utilisateurs perdus, pour des erreurs souvent très bête (une variable pas définie par ex), chose qui au linter se voit en 1sec et ne passe pas! Avec Gladys 4, chaque module jouit des tests unitaires + du linting assez strict mis en place sur le repo principal. Aucun service ne peut être disponible à l’utilisateur finale sans avoir passé une batterie de tests très strictes. On garantie l’exécution et la stabilité, et ça c’est un gage important si on veut conquérir un public plus large.
  • “que du système ou de la philosophie de modularisation en elle même” => Bien-sûr que si ça a un lien! Dans Gladys 3, le système/la philosophie c’était d’installer le module côté client. Cela créait des problèmes d’installation souvent mystiques (problème de compilation des dépendances NPM, frontend qui sautait), et souvent ça pouvait bricker une installation Gladys. Le forum regorge d’exemples et on était souvent impuissant fasse à ces erreurs. Dans Gladys 4, on fournit un build final, build réalisé côté intégration continue une fois pour toute. Le build qui arrive chez le client est un build fonctionnel, testé, et on garanti qu’il va s’exécuter.

Tu peux toujours le faire, rien ne t’empêche de coder ton service de ton côté et de ne jamais le partager… Je ne vois pas en quoi ça change quelque chose…

Bien sûr que ce sera accepté! Ce sera un service “activesync”. Du moment que ton service respecte les règles du repo (lint, tests), il n’y a pas de raison, ça peut être utile à d’autres :slight_smile:

Si les règles d’acceptation d’un module sont les seules règles de codage, ok ça me rassure )

1 Like