Si vous avez manqué le début…
J’ai contacté le Consistoire de Paris pour les aiderà refactorer la diffusion de la liste des produits cacher, actuellement en PDF, vers une technologie plus ouverte aux mobiles notamment.
Le DSI m’a demandé de l’aiderà bâtir la nouvelle architecture du SI, conjointementà la refonte du site Internet (et l’accèsà la liste en mode WAP), ce que j’ai accepté de faire, bénévolement,à mon temps pas si perdu que ça. Pour participer bénévolementà des actions communautaires et aussi pour entretenir la forme.
Dans un premier temps, sans parler d’urbanisme proprement dit, il a fallu revoir les entités et les objets “métier” manipulés. A cette échelle, ça se résume directement au MCD de la base de données, centralisée.
Le modèle de données
Nous avons choisi délibérément de nous consacrer aux deux fonctionnalités complexes du SI pour le refactoring : les synagogues et les produits.
Le modèle actuel (hébergé par une base MS Access) est disons… trop mûr (litote pour pourri) :
- Les synagogues : actuellement, la base contient un “fichier plat” des informations, très difficilement maintenable donc et très peu évolutif (les fonctions sont codées champ par champ dans la table). Il n’y a aucune séparation entre les contacts et les établissements.
- Les produits : il existe une distinction entre produits certifiés et surveillés, matérialisée fortement dans le modèle actuel. Même difficulté : les informations sont stockées “à plat” d’où le manque de visibilité et de maintenabilité évident.
Les améliorations apportées, en premier jet, sont les suivantes :
- Les contacts sont stockés séparément (objet métier distinct)
- Les propriétés des synagogues sont stockées dans une table distincte, et sont reliées dynamiquement aux établissements
- Les fonctions des contacts sont stockées séparément et sont dépendantes d’un contact et d’un établissement. Cet établissement peut être une synagogue (le cas échéant) ou un commerce, un restaurant etc. (non modélisés)
- Les décorations (médailles) sont stockées séparément, par contact
- Les tables produits et catégories sont normalisées
- Un produit peut être reliéà plusieurs catégories (les Danette sont des yahourts et des crèmes dessert)
- Il existe une catégorie principale par produit, pour un affichage simplifié sur papier
- Les produits certifiés et surveillés sont regroupés dans une même table
Actuellement, le modèle de la base est en cours de finalisation et il est visible sur cette illustration.
Sensation fraîcheur XP sur ce refactoring : cycles courts, livraisons itératives, participation anticipative des utilisateurs, pair-programming (ma femme et moi : ma femme me masse les épaules pendant que je code), etc.
Les contraintes techniques
Les contraintes étaient claires dès le début :
- Le site actuel est en ASP. On n’en veut plus !
- Pas de JAVA non plus
. PHP est la meilleure solution, en externe (hébergée pour le site Internet) et en interne : les compétences sont nombreuses et le langage est simple. - Gestion forte des habilitations sur les données internes. On ne parle pas de LDAP mais presque. Je ne suis pas expert sur le sujet, on verra bien.
- Les développements devront éviter au maximum d’accéder aux champs de la base de données par des requêtes statiques. On hume aisément une couche d’accès aux données (en anglais, DAL1 : Data Access Layer. Coïncidence ou signe du destin ?)
- Il devra exister une synchronisation entre les bases internes et externes, moyennant filtrage de certaines informations confidentielles ou non indispensables. Je vais me te leur fourguer un EAI, ça va être vite fait
.
Je ne crève pas la DAL
Dans le monde PHP, de nombreux frameworks existent pour faire ça tout beau. PEAR et les DataObjects, c’est nickel. Important mais classique : les tables sont normalisées sinon ça devient un brin trop douloureux.
Un premier POC a permis de valider la faisabilité technique (génération des classes d’accès en PHP, utilisation des objets dans des situations simples : recherche par valeur, récupération d’une grappe d’objets, ajout de méthodesà des classes générées etc.) et même de réaliser une version alpha via accès WAP. Si vous voulez tester, c’est là.
Une fois le MCD validé, la création de cette couche stable sera la prochaine étape, l’occasion pour moi d’en reparler sûrement.
Mes impressions
C’est top ! Faire du bénévolat me rend utile, et dans un domaine que je comprends (pas la prétention d’écrire “maîtrise”), ça fait vraiment plaisir. L’idée m’était venue il y a bien longtemps mais c’est la mission bénévole qu’a effectuée un collègue (EPA) pour l’ACTED et la façon dont ses yeux brillaient qui m’a motivé pour franchir le cap.
Alors en plus si ça rend un service communautaire…
Deuxième intérêt personnel : aller au bout de la démarche et ne pas abandonner en cours de route. Visiblement ils comptent sur moi et me font confiance, je ne peux pas faire l’enfant gâté et tout laisser tomber.
Troisième intérêt très personnel : de la reconnaissance. La bonne d’abord, celle des intéressés. Et la primitive, celle de ceux qui m’intéressent.
Qui sait ? Si un poste de DSI chez Pizza Cashà Sarcelles est vacant, qui dit qu’ils ne penseront pasà moi ?
1 : c’est mon trigramme OCTO



T’as vu le temps que t’as passé pour le rendre présentable ton blog (je te tutoie, désolé) !
Je ne vois pas le rapport ! je skinne mon blog joliment parce que j’aime le design. Je ne dis pas qu’il est beau mais…










