Salut à tous !
Voila (enfin) des news du projet 
L’architecture de Gladys
Suite à une longue et mûre réflexion, j’ai décidé de refondre l’architecture de Gladys. Le combo NodeJS/PHP était sympa, rapide à coder et à débugger, mais malheureusement, pour faire quelque chose de propre, optimisé, et pro, ça n’était pas adapté. Avant de développer une fonctionnalité, j’avais toujours à me demander “est ce que je le fais en JS, ou en PHP ?”, c’était bien au début, mais au vu des fonctionnalités que j’aimerais ajouter à l’avenir, ça n’était vraiment pas pratique.
L’architecture actuelle souffre aussi d’un autre problème : Je ne sais pas si vous avez vu, mais chaque classe comporte quasiment toujours les fonctions “Create, Get, Update et delete”, autrement dit, les 4 fameuses fonctions de base CRUD (Create Read Update Delete). Devoir les créer à chaque fois était contraignant, chaque nouvelle fonctionnalité demandant de réécrire ces fonctions basiques pour la classe, ce qui n’était pas pratique, long, et pas propre.
Je ne sais pas si vous voyez ou je veux en venir, mais Gladys nécessite une chose : un framework. Un framework va nous permettre de donner une structure propre au projet, et de ne pas réinventer la roue à chaque fois. Mais alors, on va utiliser un framework PHP pour Gladys ?
Je m’étais refusé à en utiliser un au début de Gladys, pour des questions de performances (Le Raspberry étant peu puissant, on n’imagine pas faire tourner Symfony dessus!)
Ainsi la réponse est bien évidemment [color=#FF0000]NON[/color] 
Nous allons utiliser un framework NodeJS : Sails.js ! C’est à dire que même la partie interface web de Gladys sera géré en NodeJS.
Ce framework va nous permettre de développer plus rapidement, et d’organiser mieux notre code. Plus besoin de réecrire à chaque nouveau modèle toutes les fonctions basiques, elles sont gérées automatiquement par Sails, plus besoin de vérifier les données, Sails.js le fait, etc… Sails.js a aussi toute une approche “temps réel”, intègre socket.io en natif, bref,ce framework est fait pour Gladys !
Les fonctionnalités
J’ai décidé de donner à cette nouvelle version une approche très Cloud et quantified self. L’idée est vraiment que si jamais on voulait un assistant Gladys “global”, gérant plusieurs maisons (résidence principale, maison de vacances, etc…), ça ne poserait aucuns problèmes. Gladys devient plus “omniscient, et interconnecté”, et au dela du multi-utilisateur, la gestion de plusieurs logements.
J’en profite pour vous donner un petit schéma de la base de donnée, dites moi ce que vous en pensez ! (si vous ne voyez pas tout, clic-droit sur l’image → ouvrir dans un nouvel onglet)
Je détaille certains points :
- LifeEvent : Cela correspond à des évènements du quotidien lié à un utilisateur, que Gladys enregistre : Heure du lever, heure du coucher, etc… Qui permettent à Gladys de faire des logs sur la vie de l’utilisateur (Gladys devient un peu BigBrother, désolé!), ce qui permet surtout de ressortir des stats : temps moyen de sommeil, etc… et avertir l’utilisateur si il ne dort pas assez (en fonction de son âge, et des recommandations de l’OMS par exemple). Mais ce n’est qu’un exemple, les LifeEvent, c’est à peu près tout ce que Gladys peut enregistrer, et qui permettrait de faire des statistiques pour mieux connaitre l’utilisateur, et permettre l’approche prédictive de Gladys.
-Token : Un token de connexion qui permet à un objet connecté d’utiliser l’API en tant qu’un utilisateur, sans s’identifier.
Voilà c’est à peu près tout, j’espère que j’ai été clair! Si vous avez des questions/réactions, n’hésitez pas en commentaire 
[EDIT 20/01/2015] Changement de l’image du modèle de Gladys