Keskeou

Keskeou

Motivation:

Répondre à une des problématiques actuelles du lab: dire où se trouvent (où sont sensés se trouver) les dizaines de milliers d'objets présents: outils, composants, vis, matériaux, appareils.

Obstacle: le logiciel nécessaire dépasse les moyens du lab.

Réponse proposée:

• Plutôt que de créer un outil ad hoc, visant les seuls besoins du lab, viser un outil plus général: outil open source, avec une base d'utilisateurs plus large, et donc une meilleure maintenance.
• Utiliser les technique "modernes":
  • base nosql
  • framework python

Inconvénients:

• moins accessible au PHP-iste de base.
• plus de prérequis exigés pour une install.

Avantages:

• les participants sont "tirés vers le haut".
• meilleure fiabilité que sql (base répartie, auto-réparante).
• schéma plus souple que le sql.
• meilleure évolutivité.
• plus facile de faire coopérer des cadors du libre.
• plus de souplesse attendue dans la relation clients/implémenteurs.

Quelques lignes sur le mouvement "no sql". Il s'appuie sur:

• La perception, par tous les acteurs un peu sérieux et attentifs, des limitations du modèle relationnel. Limitations théoriques, entrainant des limitations pratiques: lenteurs, compromis avec les principes, difficultés d'évolution à partir d'un certain niveau de complexité. Questionnez autour de vous, le constat est général.
• le design d'un certain nombre de solutions non-sql: mongodb, etc, libres, solides, abouties, puissantes.
• leur adoption par de grands acteurs, à la fois prouvant et confirmant leur validité et leurs performances: google, amazon, facebook et j'en passe.

J'ai pour ma part:

• participé à la maintenance d'un framework python sql, avec les meilleurs outils, mais prouvant ces limitations.
• un peu joué avec mongodb, et été frustré de ne pas continuer.
• une bonne maîtrise de python, et de ses frameworks web.
• membre de l'afpy, je pense pouvoir demander de l'assistance pour monter un tel projet.

Base keskeou: keskecé?

La base keskeou, c'est ma vision d'un projet plus large que le besoin du lab. À vrai dire, bien avant d'adhérer au lab, j'y voyais la base de la gestion d'un "club bricolage", assurant le prêt d'outillage à ses membres.

Une base keskeou permet d'établir des relations entre des objets et des lieux.

La relation principale sera: tel objet est dans tel lieu.

Mais ce n'est pas la seule. On peut avoir: tel objet a sa place dans tel lieu; mais il se trouve dans tel autre lieu.

On a des relations lieu-lieu: exemple: la perceuse (objet) est dans le placard, qui est dans la salle 18 de la zone méca de l'électrolab: placard, salle 18, zone méca, électrolab sont des lieux, avec une relation "est dans".

On a des objets-lieux: boite à forets, boite à outils...

On a un autre "objet riche", la personne (physique et/ou morale), qui peut être:

• propriétaire de l'objet
• détenteur provisoire (suite à un emprunt, ou parce qu'il le déplace d'un lieu à un autre)
• maitre de l'accès à un lieu: via une clef, rfid, ou à distance, il peut donner accès.
• celui qui valide une manip: prêt, déplacement, utilisation.

On a aussi des relations objet-objet très riches: par exemple la "perceuse sans fil équipée" est composée d'une simple perceuse sans fil, d'un chargeur et d'une clef à mandrin: relation de composition?

Mais surtout, on peut distinguer des "objets abstraits" et des objets réels. Un objet réel est une instance d'objet abstrait. Il peut être déplacé, perdu, volé, pas un objet abstrait.

Le vocabulaire des langages objet est pertinent ici: les objets réels sont des Objets, les objets abstraits sont des Classes. Un Objet est l'instance d'une Classe, une Classe peut dériver (héritage) d'une autre Classe. Exemple:

La perceuse qui vient de cramer, objet réel, était une instance de Peugeot 70-za, modèle préféré des modélistes. Ce modèle est lui-même dérivé de "perceuse sans fil", lui-même dérivé de "perceuse" Et de "outillage sans fil". Ces deux dérivent de "outillage électro-portatif".

On a donc possiblement un ensemble de relations très riches, Et on voit venir le problème: si il faut 400 000 lignes de codes avant de trouver un tournevis, on n'est pas rendus!

Intervient ici un autre concept fondamental: le développement agile, ou développement spirale (ça se recouvre en partie, c'est pas synonyme). Je ne peux pas développer, seulement illustrer pour notre cas; on veut à la fois:

• pouvoir commencer à travailler vite, alors que 10% du code seulement est écrit.
• évaluer le développement en cours, non pas sur des documents, mais sur une implémentation réelle.
• décider que telle feature, dont on s'est passé jusqu'à présent, devient urgente.

Pour y parvenir:

• des cycles de développement très courts: 2 à 4 semaines, se finissant par:
  • présentation au client.
  • critique de l'ihm et des modèles mis en oeuvre.
  • accord sur les objectifs pour le prochain cycle.
• Les premières implems visent à être didactiques plutôt que précises: on passe sans couture (seamlessly) du prototype à l'implémentation.

Zouplesse, molesse:

Si l'on veut quelque chose d'utile rapidement, il va falloir être souple, plus que souple. En particulier:

• un objet, c'est un objet réel, ou une classe d'objets.
• quand on cherche un tournevis, on cherche rarement un tournevis précis: on cherche une instance quelconque de la classe tournevis. Plus précisément: on veut un objet réel, mais peu importe lequel.
• Un système qui indiquerait où sont sensé être les tournevis serait donc déjà une grande aide!

Une relation "classe d'objets"/lieux serait donc, dans un premier temps, un grand secours: une appli qui dirait non pas ou est tel tournevis, telle pince, mais ou sont les tournevis (de tel type), où sont les pinces (de tel type). Pas où ils sont, plutôt où ils sont sensé être.

Disposer d'une description fiable, précise, modifiable, disant où sont sensé être les choses, serait déjà un grand, grand pas!

Roadmap:

Je pense, j'espère, avoir montré qu'un tel projet est possible, qu'il peut apporter au lab une fonctionnalité incontournable ... en un temps raisonnable!

Ça reste un développement hasardeux. D'autant plus que plusieurs équipes sont sollicitées: deux au lab, les "clients", qui définissent le besoin, les admins, qui mettent en place, répondent aux questions des utilisateurs, et une équipe afpy (qui reste à convaincre), qui assure le développement.

La seule multiplicité des équipes, on sait que c'est un facteur de risque, de désaccords, de retard, etc. Mais c'est aussi une opportunité de coopération exceptionelle. Rien n'est plus stimulant pour un développeur que d'avoir un client réactif et intelligent. Et rien n'est plus stimulant pour un client que d'avoir un développeur réactif et intelligent.

Alors?

Note: ce texte a été écrit en restructuredText C'est un "langage de markup léger", comme celui utilisé sur le wiki, mais de bien meilleure facture. Il est facilement traduit en html, latex, pdf: on peut être léger et solide. À coté, le langage utilisé sur le wiki ressemble à une illustration de ce qu'il ne faut pas faire. Mais c'est un autre débat.

Les versions rst et pdf sont stockées sur le wiki. (à faire)