Sur le papier, et sur la vidéo, à voir en pratique sur de vraies applications évidemment, on sent que le modèle de dev est vraiment souple et puissant. On peut spécifier les aspects statiques, mais aussi dynamiques style workflow et chaîne de traitements, etc, en se concentrant sur le coeur du truc et en évitant de noyer ce coeur dans un paquet de lignes de code, c'est vraiment ça la force du modèle.
Les faiblesses, sur la vidéo en tout cas : comme n'importe quelle approche générique, ça manque de "personnalisation" question présentation des données, mais
Alors, oui, n'importe qui ne peut pas forcément écrire les règles de transformations, mais en y réfléchissant :
-> si on reprends mon exemple de migration Cobol/java, si tu fais faire la migration par un développeur "à la mano", genre migrer pleins de formulaire,
* c'est répétitif, et il va forcément passer un peu de temps au début à réfléchir à comment migrer certains trucs, à se créer des patterns
* si tu fais faire ça par une équipe, tu vas donner des règles pour éviter de perpétuellement réinventer la roue, voire créer une biblio pour migrer
Ben c'est exactement le genre de travail que tu vas faire pour créer les règles de migration si tu veux mon avis.
Une fois que tu as fait ce travail le reste ce n'est qu'un boulot chiant et refaire sans cesse là même chose.
Bref, ce que permettent de faire ces technos : gagner en abstraction pour faire ressortir et se concentrer sur l'essentiel, automatiser, donc fournir des méthodologies toutes faites pour les migrations par exemple.
Tout ça c'est bien sûr modulo la complexité de la techno elle même et des biais technique qu'elle introduit, là je manque de recul pour ne voir ça que de loin.
Mais je suis plutôt optimiste:
-> C'est vraiment souple, tu peux représenter n'importe quoi comme un modèle, haut niveau, bas niveau, tout ce que tu veux
-> C'est vraiment générique, de la modélisation tu en fais dans tous les domaines, voire dans toutes les sciences, tu le fait DE TOUTE FAÇON d'une manière ou d'une autre quand tu codes, tes données, ton programme. Et du coup cette modélisation tu l'explicite et tu ne la noie pas dans le code.
-> C'est déjà utilisé avec succès industriellement.
[^] # Re: Ouille ouille
Posté par thoasm . En réponse à la dépêche Sortie de ATL 2. Évalué à 2.
Et peut-être (sûrement) que FredFrisk pourrait passer derrière moi pour corriger mes erreurs et mes approximations.
Mon exemple est tiré de la news http://linuxfr.org/2008/01/21/23592.html et la vidéo de démo est très parlante si tu veux mon avis.
Sur le papier, et sur la vidéo, à voir en pratique sur de vraies applications évidemment, on sent que le modèle de dev est vraiment souple et puissant. On peut spécifier les aspects statiques, mais aussi dynamiques style workflow et chaîne de traitements, etc, en se concentrant sur le coeur du truc et en évitant de noyer ce coeur dans un paquet de lignes de code, c'est vraiment ça la force du modèle.
Les faiblesses, sur la vidéo en tout cas : comme n'importe quelle approche générique, ça manque de "personnalisation" question présentation des données, mais
Alors, oui, n'importe qui ne peut pas forcément écrire les règles de transformations, mais en y réfléchissant :
-> si on reprends mon exemple de migration Cobol/java, si tu fais faire la migration par un développeur "à la mano", genre migrer pleins de formulaire,
* c'est répétitif, et il va forcément passer un peu de temps au début à réfléchir à comment migrer certains trucs, à se créer des patterns
* si tu fais faire ça par une équipe, tu vas donner des règles pour éviter de perpétuellement réinventer la roue, voire créer une biblio pour migrer
Ben c'est exactement le genre de travail que tu vas faire pour créer les règles de migration si tu veux mon avis.
Une fois que tu as fait ce travail le reste ce n'est qu'un boulot chiant et refaire sans cesse là même chose.
Bref, ce que permettent de faire ces technos : gagner en abstraction pour faire ressortir et se concentrer sur l'essentiel, automatiser, donc fournir des méthodologies toutes faites pour les migrations par exemple.
Tout ça c'est bien sûr modulo la complexité de la techno elle même et des biais technique qu'elle introduit, là je manque de recul pour ne voir ça que de loin.
Mais je suis plutôt optimiste:
-> C'est vraiment souple, tu peux représenter n'importe quoi comme un modèle, haut niveau, bas niveau, tout ce que tu veux
-> C'est vraiment générique, de la modélisation tu en fais dans tous les domaines, voire dans toutes les sciences, tu le fait DE TOUTE FAÇON d'une manière ou d'une autre quand tu codes, tes données, ton programme. Et du coup cette modélisation tu l'explicite et tu ne la noie pas dans le code.
-> C'est déjà utilisé avec succès industriellement.
C'est vraiment un niveau d'abstraction éle