Ok so let’s go! I’ll delete my repo and re-clone as soon as it’s good on your side!
That said, if every person who wants to dev for Gladys has to think about reconfiguring their git, there will definitely be issues 
Hopefully, we won’t have to go that far…
It’s done! You can reclone 
Yes, but well, this is a very basic development thing, 100% of software development projects have this problem, and all serious projects check for this.
I doubt there isn’t a solution
Okay, let’s go!
Great problem solved thanks to the famous .gitattributes file! Thanks @MathieuA for finding that, at least everything will work for Windows contributors
@MathieuA I’d like your opinion on the new architecture/way to load Gladys and the controllers.
Otherwise, I enabled type checking thanks to JSDoc + Typescript CLI (without writing Typescript, just using the comments)
Oh yes with this story I didn’t take the time to look!
Not bad with the classes! It’s indeed prettier than having requires on each file ^^
For my part, it bothers me a bit to have a lib folder and another api. Especially since I would have done the opposite personally
In the api folder I would have put the core of Gladys because I find it a bit more logical (if we can say it like that) but well it’s a personal preference
I agree.
Otherwise, we can rename lib to core…
Or put the core folder directly in api
api
----- controllers
----- core
----- middlewares
----- routes.js
----- index.js
And then rename api to lib
lib
----- controllers
----- core
----- middlewares
----- routes.js
----- index.js
In reality, I just went to check out other repositories, I saw some api and some lib, it doesn’t really shock me that much actually.
For me, lib is really Gladys core code, and api is the REST API
Yes, I think it’s a matter of personal preference on this one, there aren’t really any best practices!
It’s your project, so it’s up to you to decide. If you’re happy with it as is, then that’s great! ^^
That’s so heavy 
I updated the README for the Gladys 4 Playground repo with all the installation instructions to test 
Feel free to test at home!
https://github.com/GladysAssistant/gladys-4-playground
If you are looking for a good tool to explore SQLite databases, I recommend TablePlus:
Or sqliteonline.com for those who don’t want to install anything
Honestly, not bad, the structure is very clear! Quick question, I see that you use « joi », why not just use the sequelize constraints directly?
I think that the Sequelize constraints will not be enough for everything, I am thinking in particular of validating scene objects or triggers that will be nested json objects.
After that, you are right, it might be worth testing putting this additional validation in a function in the model Good remark, I will look into it.
Security-related question, in your manifest I saw that you mentioned to carefully choose libraries that aren’t broken. However, I don’t get the impression that you have a system in place to check if these libraries are actually broken one day!
Perhaps it would be interesting to either:
But it’s complicated, implementing it for everyone? Or just a few developers? This could allow us to implement security patches if needed.
Moreover, I think it would be necessary to force each module developer to have « good practices », for example, always validating that such and such model has been validated beforehand, that we cannot, for example, only put an email address in the email address field and not inject code / XSS etc.
For that, it’s super simple:
1/ GitHub already does automatic checks!
2/ There’s greenkeeper (https://greenkeeper.io/) that does it automatically. I was using it in the current Gladys repo, but I had so many notifications because of sails, which is a nest of outdated dependencies, that I deactivated it. I’ll activate it on Gladys 4! Greenkeeper even makes the PRs itself as soon as a lib needs to be updated!
Completely agree!
Safeguards are set by two things
1/ The technologies we use. Example: at the front end, Preact does not allow XSS vulnerabilities, it manages the display of variables and everything is cleaned by the lib to make sure it’s done properly.
2/ Static linting. This is the role of the very strict rules I have set on Eslint, which enforces a consistent and « aseptic » coding style, and performs a set of checks to guarantee code quality. (this catches an incalculable number of bugs/vulnerabilities)
3/ unit/integration tests of course. We have to write very fine tests and have a high code coverage to make sure that nothing unwanted is possible. Big plus, here we write the tests from the first day, so we can easily have a code coverage of > 90% and be robust on that. Another big plus, putting internal modules in the core allows us to write tests on the modules very easily, and therefore to have the same guarantees on the modules as on the core.
Hello everyone!
I’ve made good progress on the modeling, almost all models are defined:
https://github.com/GladysAssistant/gladys-4-playground/tree/master/server/models
As for the database, migrations have progressed well, I think I only need the indexes and I’m good to go!
I did indeed partially use your reflection, I was inspired by your GitHub repo (I had my eyes on it!) when I worked on it I had lost the link to the spreadsheet though, thanks!
1/ I still don’t understand why we would want categories + subcategories! If the idea of categories/subcategories is just to have a dropdown menu in the UI with categories and subcategories, then yes that’s what I plan to do But it’s just UI. The database is a representation of a model, putting 2 fields of type « category » « sub-category » here, would that bring anything? In terms of strict modeling, if we separate an attribute into two attributes, it’s because we want a subcategory to be able to belong to several categories. Not necessarily what we want, right? (open question, tell me if you have a counter example I’m interested! ).
2/ One of the values I put in the manifesto is that for Gladys 4 « we don’t do everything, but what we do we do well ».
In Gladys 3, I often wanted to go in all directions (to « be sure » to handle the case), there are categories that are useless, the types were open bar, we had « sentences » that were wired with nothing. In short: I had my eyes bigger than my stomach, and behind a lot of static data was wired with no code. And it was stupid because the user sees the sentence and says « cool I can handle XX », and in fact: no!
Here I have listed the « minimum base » of categories that I see. As we add modules (which will be in the core I remind you), we will gradually add categories. But as long as we have nothing, why put categories if we don’t know how to handle them?
3/ What we said at the developer meetup was that:
DeviceFeature
If you think of uses of subcategories (other than finding it organized for the dev, it’s a modeling there it’s pragmatic what we do! ), tell me, it’s indeed a subject that is better to settle now!
PS: but otherwise yes we can add the pressure sensor, anyway it will have to be added as soon as we add in Gladys 4 a module that needs to create one
