You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 22, 2020. It is now read-only.
Le projet usine distribuée a été développé très rapidement (un weekend en fait) afin de pouvoir répondre à l'urgence de la demande. Si le modèle initiale était à peu près défini, nous ne connaissions pas (personne d'ailleurs) tous les cas que nous devrions gérer.
Grâce au choix de postgreSQL, nous avons pû prendre pas mal de raccourcies en utilisant des champs en json-b pour gérer certains cas (les commentaires, les livraisons). Et cela convient parfaitement à l'organisation de la fabrication des visières pour la région Normandie.
Mais deux choses vont peut-être se produire :
de nouveaux type d'objet pourraient être pris en charge dans le cadre du projet
d'autres initiatives du type d'usine partagée pourraient se créer, et en l'état, le code du projet est trop spécifique à l'organisation ayant émergée en Normandie.
Si le code est dès le début ouvert et disponible à tous, le projet en lui-même n'est pas encore facilement partageable sans quelques adaptations.
D'ou l'idée de créer un fork du projet, fork à partir duquel nous pourrions mettre en place un modèle un peu plus généraliste, sans interrompre les développements très spécifiques du code déjà en production.
Les principaux points de blocage au partage du projet sont :
Une gestion des modèles pouvant être fabriqués directement dans des champs de l'objet request (mask_small_size_quantity et mask_large_size_quantity).
Une gestion des livraisons au sein d'un champs json-b delivery_traking.
Une organisation reposant obligatoirement sur des pôles de fabrication production_management, et des request uniquement associables à ces pôles de fabrication.
Pas de notion de producteur (fablab, usine, ...).
Il faudrait donc mettre en place un nouveau modèle qui permettrait :
De gérer une notion de modèles disponibles (autre chose que des visières).
D'inclure les producteurs finaux dans l'organisation.
D'activer ou non cette notion de pôle de production intermédiaire.
De gérer plus proprement les livraisons, les livraisons partielles devant être possibles (ce qui est déjà la cas dans le code existant).
The text was updated successfully, but these errors were encountered:
alexisjanvier
changed the title
Ouverture du projet d'usine distribuée
Partage du projet d'usine.s partagée.s
Apr 5, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Le projet usine distribuée a été développé très rapidement (un weekend en fait) afin de pouvoir répondre à l'urgence de la demande. Si le modèle initiale était à peu près défini, nous ne connaissions pas (personne d'ailleurs) tous les cas que nous devrions gérer.
Grâce au choix de postgreSQL, nous avons pû prendre pas mal de raccourcies en utilisant des champs en
json-b
pour gérer certains cas (les commentaires, les livraisons). Et cela convient parfaitement à l'organisation de la fabrication des visières pour la région Normandie.Mais deux choses vont peut-être se produire :
Si le code est dès le début ouvert et disponible à tous, le projet en lui-même n'est pas encore facilement partageable sans quelques adaptations.
D'ou l'idée de créer un fork du projet, fork à partir duquel nous pourrions mettre en place un modèle un peu plus généraliste, sans interrompre les développements très spécifiques du code déjà en production.
Les principaux points de blocage au partage du projet sont :
request
(mask_small_size_quantity
etmask_large_size_quantity
).delivery_traking
.production_management
, et desrequest
uniquement associables à ces pôles de fabrication.Il faudrait donc mettre en place un nouveau modèle qui permettrait :
The text was updated successfully, but these errors were encountered: