Déjà, premier problème, le réseau. HTTP, c'est du "non connecté". Tu envois ta requette, le serveur repond, ok merci bye. Il y a des petits mecanisme en plus pour faire du keep-alive, mais l'idée est la. Donc, niveau sécurité et ouverture de flux, c'est simple. Tu ouvre le 80 dans un sens, et roule ma loutre. Si tu rajoute tout un tas de protocol avec tout un tas de port dans tout un tas de direction, déjà, pour le nat/pat, c'est foutu et ensuite pour la sécurité réseau, c'est un peu plus poilu (mais on s'en fou, je te l'accorde).
Du coup on préfère encapsuler son propre protocole transactionnel à l'intérieur du seul protocole qui n'est pas prévu pour ca mais que les admins réseau le laisse passer ... comme il est ... simple : appelons le SOAP
Du coup on réimplémente tout ce qui existe déjà sur le desktop avec des frameworks imbitables dans leur conception qui tourne avec le seul langage autorisé et qui n'est pas prévu pour ça à l'origine. Appelons le AJAX
Riche idée !
Ca crée des emplois et ca fait tourner l'économie.
Je veux bien croire qu'on veuille contraindre son modèle, mais j'ai du mal à comprendre la pertinence de ta limite : si une classe comporte des attributs publics, qu'ils soient rendus comme tel dans le modèle, de même pour les privés, protected.
Bref la bijectivité suppose que le modèle rende compte du code pour ce qu'il sais représenter : essentiellement les prototypes de fonction et la config.
Si ça contrevient à une règle posé, genre celle que tu cite en exemple, eh bien pond un warning, mais va pas dire que c'est pas bijectif :-)
C'est pourtant, ce que j'essaie d'expliquer. Tu raisonnes en te disant que ton modèle est ton code. Or ca n'a aucun intérêt à part faire chier les développeurs. L'intérêt est de "transformer" d'effectuer automatiquement des modifications simples pour éviter que le dev ne se les coltine. L'entrée et le résultat ne sont pas sémantiquement équivalents ni même bijectifs. Les warnings c'est super mais ca ne suffit pas. Il faut résoudre les conflits... à la mano.
C'est le couple RSM+Clearcase qui s'en charge.
Donc la bidirectionnalité est possible mais pas "automatique". C'est ce j'entends par bijectif. Elle est juste chiante.
C'est avec RSM que je devait faire mes boiboites (j'en ai envie de vomir rien que d'y penser, brrrrrr), et c'est une des interfaces les plus mal pensée et imbitable que j'ai jamais vu.
Avec les premières versions qui sont sorties juste après la spec UML 2.0, je ne te donne pas tort. Ca s'est pas mal amélioré depuis avec la 7.5 mais il traîne encore les hérésies ergonomiques du socle Eclipse.
Malheureusement, Topcased et Papyrus sont encore plus à la ramasse et je ne te parle même pas d'ArgoUML.
Tout ça décidé d'en haut par des abrutis qui n'ont jamais eu à y toucher. Voilà les dégats d'ingénieurs au poste de managment qui lisent des plaquettes de pub, et qui croient connaitre parce qu'ils ont codé 10 lignes de java ya 10 ans.
Fais toi plaisir. Chez nous, on fait du support sur les solutions qu'on propose donc les merdes c'est nous qui devons les gérer.
PS : Votre techno a 15 ans, il va falloir 15 autres années pour que ça parvienne au cerveau des industriels, on pari ? ;-)
A l'heure où on redéveloppe une appli par site web pour le consulter sur son mobile, où on encapsule tous les protocoles IP dans un protocole en mode non connecté, ou on revient aux clients lourds qu'on renomme riches pour faire passer la pilule, où réinvente le bon vieux RPC en le rebaptisant SOA, ... j'ai perdu mes illusions sur une informatique qui ferait gagner du temps à ses clients ;)
Alors si ça me gère les points d'insertion du code, en sachant qu'entre tel endroit tel endroit il doit pas y toucher, très bien. Le problème peut venir de l'incapacité de l'outil de comprendre que telle zone de code ne fait pas partie de ce qu'il a généré, typiquement le coeur d'une fonction.
Acceleo fonctionne, comme ca. Nous on utilise OAW Xtend avec le même principe de balises protected
La coque de la fonction, bref ce qu'il a généré, ne doit pas être touchée, on est d'accord, même si ça pourrait être plus pratique dans certains cas, surtout avec Eclipse qui te gère le refactoring automatique, alors que ton outil (je connais RSM + ClearCase) ne le fait pas, ce qui fait que tu dois le faire à de multiple endroits, moins nombreux certes, mais néanmoins multiples.
On est d'accord: un appel à 'une méthode qui a été renommée dans le modèle puis régénérée, ne ne sera pas mis à jour dans le corps de la méthode appelante alors que le refactoring s'en sortira mieux. Mais bon y'a pas mort d'homme. Pense que ton modèle une fois mis à jour te permettra aussi de mettre à jour d'autres briques qui ne seront pas couvertes par ton IDE. Par contre je ne vois pas le rapport avec RSM ou Clearcase là. tu compares un IDE avec un modeleur et un VCS
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Mais un conseil, veillez vraiment à la bijectivité, je pense que c'est un gros frain à l'adoption.
Le problème est que la bijectivité parfaite n'existe pas.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Et travailler vos interfaces de dev, parce que 20 clics (et j'exagère au pire d'un facteur 1,2) pour dire que ma fonction toto a un param machin de type string -----> Poubelle.
Là tu t'en prends plus au modeleur mais d'une manière générale, il faut éviter de bosser sur les diagrammes et attaquer directement la structure du modèle, voire utiliser un DSL texte (qui n'est rien d'autre qu'un langage)
Avec RSM le truc chiant c'est que pour créer le moindre lien entre 2 concepts il faut un diagramme. C'est perfectible.
A partir du moment où tu génères du code à partir d'un modèle tu as plusieurs voies possibles.
Si tu te lances dans du refactoring à tout va et que tu retouches le code généré en dehors des sentiers battus (balise preserved), ton modèle et ton code divergent et la moindre régénération de code suite à une évolution de ton architecture ou des specs va te lancer dans un interminable merge de ton code. Au fil du temps modèle et code sont de plus en plus éloignés et les réconciliations deviennent contre-productives.
Partant de ce constat:
Soit tu n'envisages le modèle uniquement que pour faire du one shot et tu peux effectivement douter de l'utilité des modèles (ecole du sketch modeling, on modélise sur un tableau pour des besoins ponctuels)
Soit tu essaies de ne pas trop faire diverger ton modèle et ton code
Soit tu te donnes les moyens de réconcilier les divergences.
Si tu adoptes une approche descendante. Tu te dois de respecter les zones de code non éditables et tout ce qui peut être ecrasé par le générateur.
L'aspect incrémental peut-être est assuré par l'outil de transfo (identifiants dans le code généré+balise preserve) ou par l'outil de gestion de version qui sait gérer le merge mieux que personne puisque c'est son rôle. Il est vrai que ca peut être un peu contraignant comme tu l'évoques mais une chaîne de travail bien pensée peut apporter un gain. Il faut aussi savoir se limiter sur ce qu'on veut générer.
Si on choisit de générer certaines parties du code c'est qu'on pense qu'il y un gain en terme de cohérence au niveau de ton archi. Le but n'est pas seulement de cracher un maximum de code automatiquement.
C'est toute la difficulté de l'exercice. Ne pas en faire trop.
Si malgré tout, tu veux te laisser la liberté de diverger au niveau du code en cassant les associations, en refactorant les classes ou les packages, en modifiant tes contrats de WSDL à la mano, ... tu as besoin de mettre en place une transformation inverse c'est à dire du code vers le modèle. Le problème est: que se passe t'il si ton modèle a aussi évolué entretemps. Tu te retrouves avec 2 versions de modèles à réconcilier, l'une modifiée à la main, l'autre obtenue par rétro-ingénierie.
Sans un bon outil qui te permet (cf. EMF Compare pour te faire une idée) de faire des merges de modèles et qui t'évite de te répeter tu es dans l'impasse (merge tracking)
Là où c'est assez drôle c'est que la suite que tu critiques (RSM + Clearcase je suppose) est à ma connaissance la seule qui prenne en charge ca à peu près correctement mais je l'opensource avance de son coté (cf Expand, Acceleo, EMF Compare, ...).
Tout ceci nous ramène une problématique classique de versionning.
Il faut y aller petit pas par petit pas pour ne pas faire de merge big-bang.
El là où ca devient intéressant c'est qu'on peut créer des modèles adaptés et compréhensibles par ceux à qui on s'adresse (modèle de processus métiers pour les Business Analyst, modèles d'analyse, modèles de conception, maquettes d'IHM, ...) tout ça grâce aux DSLs (Domain Specific Language) y compris textuels (cf. Xtext) ou à l'UML profilé. Si on dispose de transformations Modèle vers Modèle et d'un bon outillage ceci n'est pas hors d'atteinte et l'aspect incrémental consolide la chaîne.
Après je suis d'accord que ca peut devenir complexe, mais la réalité de ces projets est complexe et les gains se font sur l'échelle.
Je sais que je ne te convaincrai pas mais j'ai la faiblesse de croire que ca marche pas trop mal pour certains projets que j'ai pu croiser.
Et il devient très difficile ne ne pas tenir compte du phénomène d'outsourcing
Ok, là ça devient intéressant. Tu veux dire qu'après avoir fait ton petit pâté de boîboîtes face au client tout frétillant, tu refiles le sale boulot (le vrai boulot, en fait) à une autre entreprise ?
C'est mignon tout plein de nous faire croire que c'est ton boulot qui crée la valeur ajoutée.
Sauf que l'idée est aux antipodes de ce que tu décris. Il s'agit de te rendre plus productif toi qui connait bien le métier, en t'évitant les tâches répétitives et donc de rendre moins intéressant la sous-traitance vers les pisseurs de code. Un peu comme dans l'industrie avec les robots vs les délocalisations.
Dans les faits c'est pas gagné mais au moins on essaye.
C'est très joli, mais les IDE modernes font déjà 99% de ce travail. Quand je veux faire un nouvel objet, je tape juste son nom, la liste de ses propriétés et la complétion fait le reste. Il y a aussi la notion de template et d'assistant pour les morceaux plus complexes.
Sauf que tu raisonnes toujours par rapport à tes propres besoins de développeurs dans ton coin alors qu'on t'a expliqué en long et en large que l'application ne se limitait pas à ca. Le moindre changement dans ta conception peut impacter plusieurs projets avec moultes refactoring sur des technos et des équipes différentes. L'approche top down te permet justement de rester cohérent.
D'où ma question sans réponse pour l'instant (enfin, j'ai pas fini de lire le thread) : est-ce que quelqu'un a déjà vu un gros projet utiliser ce type d'outil ? Est-ce que ça a survécu avec le temps ?
Oui j'en ai vu un mais ca t'apportera quoi puisque tu trouveras à redire que ca rame parce c'est du JEE et que de toute façon t'aurais mieux à toi tout seul.
Fais toi plaisir.
Idéalement, ca serait un système qui permettrait d'invalider tout un fil qui ne nous intéresse pas, mais qu'en plus les nouveaux messages de ce fil ne nous soient pas notifiés lorsqu'on est connecté et qu'on consulte sa page perso.
L'objectif n'est pas de générer tout le code mais comme tu le dis les composantes techniques à faible valeur ajoutée.
On a renoncé depuis longtemps à spécifier les aspects dynamiques d'un système au niveau le plus bas.
Mais ce qui me fait marrer, c'est qu'on continue à dessiner des boiboites, qui sémantiquement ne valent rien : un User est une simple boiboite avec le titre User, et des champs à l'intérieur.
Sauf que tu ne critiques pas le bon outil. Ici c'est le modeleur mais on peut parfaitement définir son propre langage de modélisation dédié (Domain Spécific Language) y compris purement textuels (voir le projet xText).
Ensuite ici, il existe des modeleurs UML en mode texte qui peuvent faire l'affaire et tu n'es pas non plus obligé de faire un diagramme de classe, ca n'est qu'une démo.
Sinon cet usage des DSL en lieu et place de l'UML se démocratise maintenant que les outils commencent à arriver à maturité(voir Eclipse Modeling Framework)
Et là Acceleo et d'autre générateurs Eclipse répondent aussi à ton besoin.
Après, il y a une chose que tu oublies avec cette approche, c'est qu'elle centralise tes informations. A partir du même modèle tu peux aussi générer toute la tuyauterie pour les web services, cibler une autre architecture dans un environnement hétérogène, migrer vers un autre framework, ...
L'avantage c'est que toutes les parties prenantes partagent le même modèle et parlent le même langage. Ca facilite les échanges et c'est plus simple d'envoyer un bout de modèle à des développeurs de la couche noyau et à ceux qui sont chargés du middleware et de regénérer les docs de specs pour les AMOs, que de mettre à jour qui les WSDL, qui les contrats d'interface et qui les documents à la main.
Pire on voit à quel point c galère d'expliquer que la fonction findCategoryByName a un param String, ça prend 3 fois plus de temps que l'écrire, faut cliquer partout !
Ici, c'est comme le paradigme "convention over configuration". Ca te génère avec des présupposés. Ensuite, tu peux éditer ton code ou surcharger le modèle pour prendre en charge les spécificités. Libre à toi de choisir. Après, cette information saisie dans le modèle peut-être utile pour d'autres régénérations ultérieures (modèles qui évoluent en fonction des specs) ou pour d'autres cibles.
Mais si tu veux du "one shot", évidemment, c'est une perte de temps.
Développer quoi au juste, un portail web de micro-blogging ou une infrastructure b2b fortement dépendante des contraintes métier dans la banques banque, le transport de marchandise, de passagers ou la logistique ?
La vraie question serait plutôt:
"Faut t'il supprimer les dépêches ?"
Il faut se rendre à l'évidence et ne pas ramer à contre-courant.
Soyons honnêtes: Les dépêches n'intéressent plus personne.
- Les rédacteurs en ont marre d'être comparés au maître des lieux. L'indigence intellectuelle qu'on trouve séant me fait penser à ce roi nu que l'on flatte hypocritement au sujet de sa garde robe en s'interrogeant sur sa propre turpitude.
- Les lecteurs se détournent rien qu'à la vue des commentaires aigris de tout poil.
- Sous la pression du pagerank, les commentateurs les plus aguerris n'osent même plus faire des remarques pertinentes en rapport avec le sujet et préfèrent se quereller, qui sur l'orthographe, qui sur la licence ou qui sur le parti-pris des modos.
En plus je ne vois que des avantages à leur suppression:
- L'équipe de modérateurs grassement surpayés qui serait réduite à la portion congrue.
- L'argent des dons récupéré sur la corruption serait réaffecté à des choses bien plus utiles, comme le portage du site sous Mono et par Nono.
- Plus de guerres de chapelles intestines entre fanboys de tout acabit ou d'annonces sur la FestNose Ubundriva à Trifoullis les Oies , mais de vrais sujets de fond comme des reportages sur les conditions de détention de Reiser, ou des enquêtes fouillées en camera cachée sur les tractations secrètes entre Linus et RMS au sujet du merge entre le Hurd et Linux
...
Si je comprend bien:
Le BY ne leur suffit pas à cause de la paternité de tous les contributeurs trop complexe à gérer. Ils demandent un transfert de droit à la GNU Project.
Les BSDlike et le domaine publique ne leur conviennent pas car certains contributeurs s'y opposent. (d'où le SA)
[^] # Re: Web à tout faire.
Posté par El Titi . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 7.
Déjà, premier problème, le réseau. HTTP, c'est du "non connecté". Tu envois ta requette, le serveur repond, ok merci bye. Il y a des petits mecanisme en plus pour faire du keep-alive, mais l'idée est la. Donc, niveau sécurité et ouverture de flux, c'est simple. Tu ouvre le 80 dans un sens, et roule ma loutre. Si tu rajoute tout un tas de protocol avec tout un tas de port dans tout un tas de direction, déjà, pour le nat/pat, c'est foutu et ensuite pour la sécurité réseau, c'est un peu plus poilu (mais on s'en fou, je te l'accorde).
Du coup on préfère encapsuler son propre protocole transactionnel à l'intérieur du seul protocole qui n'est pas prévu pour ca mais que les admins réseau le laisse passer ... comme il est ... simple : appelons le SOAP
Du coup on réimplémente tout ce qui existe déjà sur le desktop avec des frameworks imbitables dans leur conception qui tourne avec le seul langage autorisé et qui n'est pas prévu pour ça à l'origine. Appelons le AJAX
Riche idée !
Ca crée des emplois et ca fait tourner l'économie.
[^] # Re: Web à tout faire.
Posté par El Titi . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 2.
ça tourne sur tout les téléphones portables qui ont un navigateur web ?
Tu veux dire que toutes les applis sur les stores dédiées à chaque site, c'est pour le chichi ?
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 5.
Je veux bien croire qu'on veuille contraindre son modèle, mais j'ai du mal à comprendre la pertinence de ta limite : si une classe comporte des attributs publics, qu'ils soient rendus comme tel dans le modèle, de même pour les privés, protected.
Bref la bijectivité suppose que le modèle rende compte du code pour ce qu'il sais représenter : essentiellement les prototypes de fonction et la config.
Si ça contrevient à une règle posé, genre celle que tu cite en exemple, eh bien pond un warning, mais va pas dire que c'est pas bijectif :-)
C'est pourtant, ce que j'essaie d'expliquer. Tu raisonnes en te disant que ton modèle est ton code. Or ca n'a aucun intérêt à part faire chier les développeurs. L'intérêt est de "transformer" d'effectuer automatiquement des modifications simples pour éviter que le dev ne se les coltine. L'entrée et le résultat ne sont pas sémantiquement équivalents ni même bijectifs. Les warnings c'est super mais ca ne suffit pas. Il faut résoudre les conflits... à la mano.
C'est le couple RSM+Clearcase qui s'en charge.
Donc la bidirectionnalité est possible mais pas "automatique". C'est ce j'entends par bijectif. Elle est juste chiante.
C'est avec RSM que je devait faire mes boiboites (j'en ai envie de vomir rien que d'y penser, brrrrrr), et c'est une des interfaces les plus mal pensée et imbitable que j'ai jamais vu.
Avec les premières versions qui sont sorties juste après la spec UML 2.0, je ne te donne pas tort. Ca s'est pas mal amélioré depuis avec la 7.5 mais il traîne encore les hérésies ergonomiques du socle Eclipse.
Malheureusement, Topcased et Papyrus sont encore plus à la ramasse et je ne te parle même pas d'ArgoUML.
Tout ça décidé d'en haut par des abrutis qui n'ont jamais eu à y toucher. Voilà les dégats d'ingénieurs au poste de managment qui lisent des plaquettes de pub, et qui croient connaitre parce qu'ils ont codé 10 lignes de java ya 10 ans.
Fais toi plaisir. Chez nous, on fait du support sur les solutions qu'on propose donc les merdes c'est nous qui devons les gérer.
PS : Votre techno a 15 ans, il va falloir 15 autres années pour que ça parvienne au cerveau des industriels, on pari ? ;-)
A l'heure où on redéveloppe une appli par site web pour le consulter sur son mobile, où on encapsule tous les protocoles IP dans un protocole en mode non connecté, ou on revient aux clients lourds qu'on renomme riches pour faire passer la pilule, où réinvente le bon vieux RPC en le rebaptisant SOA, ... j'ai perdu mes illusions sur une informatique qui ferait gagner du temps à ses clients ;)
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Alors si ça me gère les points d'insertion du code, en sachant qu'entre tel endroit tel endroit il doit pas y toucher, très bien. Le problème peut venir de l'incapacité de l'outil de comprendre que telle zone de code ne fait pas partie de ce qu'il a généré, typiquement le coeur d'une fonction.
Acceleo fonctionne, comme ca. Nous on utilise OAW Xtend avec le même principe de balises protected
La coque de la fonction, bref ce qu'il a généré, ne doit pas être touchée, on est d'accord, même si ça pourrait être plus pratique dans certains cas, surtout avec Eclipse qui te gère le refactoring automatique, alors que ton outil (je connais RSM + ClearCase) ne le fait pas, ce qui fait que tu dois le faire à de multiple endroits, moins nombreux certes, mais néanmoins multiples.
On est d'accord: un appel à 'une méthode qui a été renommée dans le modèle puis régénérée, ne ne sera pas mis à jour dans le corps de la méthode appelante alors que le refactoring s'en sortira mieux. Mais bon y'a pas mort d'homme. Pense que ton modèle une fois mis à jour te permettra aussi de mettre à jour d'autres briques qui ne seront pas couvertes par ton IDE. Par contre je ne vois pas le rapport avec RSM ou Clearcase là. tu compares un IDE avec un modeleur et un VCS
Pour RSM et ClearCase, je t'assure que j'ai jamais vu cette fonction de gestion de modification de source, mais on avait peut être une version trop vieille, je ne sais pas
Même question. Je comprend pas ce que tu veux dire. J'ai pas du être clair.
Mais un conseil, veillez vraiment à la bijectivité, je pense que c'est un gros frain à l'adoption.
Le problème est que la bijectivité parfaite n'existe pas.
Imagine un modèle avec une classe qui comporte des attibuts private et public.
Pour diverses raisons, tu as décidé que ton générateur de code transforme tous les attributs en public dans le code généré de la classe.
Si tu fais un reverse, tu n'as pas moyen de revenir au modèle initial en remettant les bon attributs.
Tu régenères donc une version de modèle qui a tous ses attributs à public et tu t'en remets au modeleur et à ses capacités à merger les modèles pour reconstituer le modèle que tu attends. La transfo inverse ne peut pas être automatique.
Pour une classe ca va, mais pour un projet complet.
C'est pourquoi, on privilégie une approche top down car le roundtrip est beaucoup trop complexe voire inapplicable.
L'autre solution consiste à conserver la tracabilité de la génération (modèle de marquages). La transfo modèle vers code (vu comme un modèle) mémorise chaque relation entre elt du modèle souce et du modèle cible.
Ca marche pas mal avec les modèles parce que tous les elts ont des identifiants immuables.
Avec du code source cet identifiant est dans les commentaires.
Ca reste ardu car il y a plein de cas tordu (cas des surjections: 1elt donne n elt dont 1 seul a changé dans le code , ...)
Et travailler vos interfaces de dev, parce que 20 clics (et j'exagère au pire d'un facteur 1,2) pour dire que ma fonction toto a un param machin de type string -----> Poubelle.
Là tu t'en prends plus au modeleur mais d'une manière générale, il faut éviter de bosser sur les diagrammes et attaquer directement la structure du modèle, voire utiliser un DSL texte (qui n'est rien d'autre qu'un langage)
Avec RSM le truc chiant c'est que pour créer le moindre lien entre 2 concepts il faut un diagramme. C'est perfectible.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Tout dépend de l'usage que tu en fais.
Cf. ma réponse à ton post plus bas.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Si tu te lances dans du refactoring à tout va et que tu retouches le code généré en dehors des sentiers battus (balise preserved), ton modèle et ton code divergent et la moindre régénération de code suite à une évolution de ton architecture ou des specs va te lancer dans un interminable merge de ton code. Au fil du temps modèle et code sont de plus en plus éloignés et les réconciliations deviennent contre-productives.
Partant de ce constat:
Soit tu n'envisages le modèle uniquement que pour faire du one shot et tu peux effectivement douter de l'utilité des modèles (ecole du sketch modeling, on modélise sur un tableau pour des besoins ponctuels)
Soit tu essaies de ne pas trop faire diverger ton modèle et ton code
Soit tu te donnes les moyens de réconcilier les divergences.
Si tu adoptes une approche descendante. Tu te dois de respecter les zones de code non éditables et tout ce qui peut être ecrasé par le générateur.
L'aspect incrémental peut-être est assuré par l'outil de transfo (identifiants dans le code généré+balise preserve) ou par l'outil de gestion de version qui sait gérer le merge mieux que personne puisque c'est son rôle. Il est vrai que ca peut être un peu contraignant comme tu l'évoques mais une chaîne de travail bien pensée peut apporter un gain. Il faut aussi savoir se limiter sur ce qu'on veut générer.
Si on choisit de générer certaines parties du code c'est qu'on pense qu'il y un gain en terme de cohérence au niveau de ton archi. Le but n'est pas seulement de cracher un maximum de code automatiquement.
C'est toute la difficulté de l'exercice. Ne pas en faire trop.
Si malgré tout, tu veux te laisser la liberté de diverger au niveau du code en cassant les associations, en refactorant les classes ou les packages, en modifiant tes contrats de WSDL à la mano, ... tu as besoin de mettre en place une transformation inverse c'est à dire du code vers le modèle. Le problème est: que se passe t'il si ton modèle a aussi évolué entretemps. Tu te retrouves avec 2 versions de modèles à réconcilier, l'une modifiée à la main, l'autre obtenue par rétro-ingénierie.
Sans un bon outil qui te permet (cf. EMF Compare pour te faire une idée) de faire des merges de modèles et qui t'évite de te répeter tu es dans l'impasse (merge tracking)
Là où c'est assez drôle c'est que la suite que tu critiques (RSM + Clearcase je suppose) est à ma connaissance la seule qui prenne en charge ca à peu près correctement mais je l'opensource avance de son coté (cf Expand, Acceleo, EMF Compare, ...).
Tout ceci nous ramène une problématique classique de versionning.
Il faut y aller petit pas par petit pas pour ne pas faire de merge big-bang.
El là où ca devient intéressant c'est qu'on peut créer des modèles adaptés et compréhensibles par ceux à qui on s'adresse (modèle de processus métiers pour les Business Analyst, modèles d'analyse, modèles de conception, maquettes d'IHM, ...) tout ça grâce aux DSLs (Domain Specific Language) y compris textuels (cf. Xtext) ou à l'UML profilé. Si on dispose de transformations Modèle vers Modèle et d'un bon outillage ceci n'est pas hors d'atteinte et l'aspect incrémental consolide la chaîne.
Après je suis d'accord que ca peut devenir complexe, mais la réalité de ces projets est complexe et les gains se font sur l'échelle.
Je sais que je ne te convaincrai pas mais j'ai la faiblesse de croire que ca marche pas trop mal pour certains projets que j'ai pu croiser.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Et il devient très difficile ne ne pas tenir compte du phénomène d'outsourcing
Ok, là ça devient intéressant. Tu veux dire qu'après avoir fait ton petit pâté de boîboîtes face au client tout frétillant, tu refiles le sale boulot (le vrai boulot, en fait) à une autre entreprise ?
C'est mignon tout plein de nous faire croire que c'est ton boulot qui crée la valeur ajoutée.
Sauf que l'idée est aux antipodes de ce que tu décris. Il s'agit de te rendre plus productif toi qui connait bien le métier, en t'évitant les tâches répétitives et donc de rendre moins intéressant la sous-traitance vers les pisseurs de code. Un peu comme dans l'industrie avec les robots vs les délocalisations.
Dans les faits c'est pas gagné mais au moins on essaye.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
C'est très joli, mais les IDE modernes font déjà 99% de ce travail. Quand je veux faire un nouvel objet, je tape juste son nom, la liste de ses propriétés et la complétion fait le reste. Il y a aussi la notion de template et d'assistant pour les morceaux plus complexes.
Sauf que tu raisonnes toujours par rapport à tes propres besoins de développeurs dans ton coin alors qu'on t'a expliqué en long et en large que l'application ne se limitait pas à ca. Le moindre changement dans ta conception peut impacter plusieurs projets avec moultes refactoring sur des technos et des équipes différentes. L'approche top down te permet justement de rester cohérent.
D'où ma question sans réponse pour l'instant (enfin, j'ai pas fini de lire le thread) : est-ce que quelqu'un a déjà vu un gros projet utiliser ce type d'outil ? Est-ce que ça a survécu avec le temps ?
Oui j'en ai vu un mais ca t'apportera quoi puisque tu trouveras à redire que ca rame parce c'est du JEE et que de toute façon t'aurais mieux à toi tout seul.
Fais toi plaisir.
[^] # Re: FOUTAISE !
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Dépêche éditée par
poltuiu
;)
[^] # Re: FOUTAISE !
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
[^] # Re: Avis d'une moule
Posté par El Titi . En réponse au journal Faut-il supprimer la tribune ? (suite). Évalué à 3.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 3.
On a renoncé depuis longtemps à spécifier les aspects dynamiques d'un système au niveau le plus bas.
Mais ce qui me fait marrer, c'est qu'on continue à dessiner des boiboites, qui sémantiquement ne valent rien : un User est une simple boiboite avec le titre User, et des champs à l'intérieur.
Sauf que tu ne critiques pas le bon outil. Ici c'est le modeleur mais on peut parfaitement définir son propre langage de modélisation dédié (Domain Spécific Language) y compris purement textuels (voir le projet xText).
Ensuite ici, il existe des modeleurs UML en mode texte qui peuvent faire l'affaire et tu n'es pas non plus obligé de faire un diagramme de classe, ca n'est qu'une démo.
Sinon cet usage des DSL en lieu et place de l'UML se démocratise maintenant que les outils commencent à arriver à maturité(voir Eclipse Modeling Framework)
Et là Acceleo et d'autre générateurs Eclipse répondent aussi à ton besoin.
Après, il y a une chose que tu oublies avec cette approche, c'est qu'elle centralise tes informations. A partir du même modèle tu peux aussi générer toute la tuyauterie pour les web services, cibler une autre architecture dans un environnement hétérogène, migrer vers un autre framework, ...
L'avantage c'est que toutes les parties prenantes partagent le même modèle et parlent le même langage. Ca facilite les échanges et c'est plus simple d'envoyer un bout de modèle à des développeurs de la couche noyau et à ceux qui sont chargés du middleware et de regénérer les docs de specs pour les AMOs, que de mettre à jour qui les WSDL, qui les contrats d'interface et qui les documents à la main.
Pire on voit à quel point c galère d'expliquer que la fonction findCategoryByName a un param String, ça prend 3 fois plus de temps que l'écrire, faut cliquer partout !
Ici, c'est comme le paradigme "convention over configuration". Ca te génère avec des présupposés. Ensuite, tu peux éditer ton code ou surcharger le modèle pour prendre en charge les spécificités. Libre à toi de choisir. Après, cette information saisie dans le modèle peut-être utile pour d'autres régénérations ultérieures (modèles qui évoluent en fonction des specs) ou pour d'autres cibles.
Mais si tu veux du "one shot", évidemment, c'est une perte de temps.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par El Titi . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 1.
[^] # Re: OWASP, Ô DÉSESPOIR
Posté par El Titi . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 3.
# Faux problème !
Posté par El Titi . En réponse au journal Faut-il supprimer la tribune ? (suite). Évalué à 10.
"Faut t'il supprimer les dépêches ?"
Il faut se rendre à l'évidence et ne pas ramer à contre-courant.
Soyons honnêtes:
Les dépêches n'intéressent plus personne.
- Les rédacteurs en ont marre d'être comparés au maître des lieux. L'indigence intellectuelle qu'on trouve séant me fait penser à ce roi nu que l'on flatte hypocritement au sujet de sa garde robe en s'interrogeant sur sa propre turpitude.
- Les lecteurs se détournent rien qu'à la vue des commentaires aigris de tout poil.
- Sous la pression du pagerank, les commentateurs les plus aguerris n'osent même plus faire des remarques pertinentes en rapport avec le sujet et préfèrent se quereller, qui sur l'orthographe, qui sur la licence ou qui sur le parti-pris des modos.
En plus je ne vois que des avantages à leur suppression:
- L'équipe de modérateurs grassement surpayés qui serait réduite à la portion congrue.
- L'argent des dons récupéré sur la corruption serait réaffecté à des choses bien plus utiles, comme le portage du site sous Mono et par Nono.
- Plus de guerres de chapelles intestines entre fanboys de tout acabit ou d'annonces sur la FestNose Ubundriva à Trifoullis les Oies , mais de vrais sujets de fond comme des reportages sur les conditions de détention de Reiser, ou des enquêtes fouillées en camera cachée sur les tractations secrètes entre Linus et RMS au sujet du merge entre le Hurd et Linux
...
[^] # Re: Plus de jeux vidéos.
Posté par El Titi . En réponse au journal Objective-C, C, C++, ou JavaScript uniquement sur l'iPhone OS4. Évalué à 4.
[^] # Re: punk ?
Posté par El Titi . En réponse au journal Punk's dead. Évalué à 4.
[^] # Re: Changement de licence
Posté par El Titi . En réponse au journal [OSM] Mappy veut bien piller mais pas contribuer. Évalué à 2.
Le BY ne leur suffit pas à cause de la paternité de tous les contributeurs trop complexe à gérer. Ils demandent un transfert de droit à la GNU Project.
Les BSDlike et le domaine publique ne leur conviennent pas car certains contributeurs s'y opposent. (d'où le SA)
[^] # Re: punk ?
Posté par El Titi . En réponse au journal Punk's dead. Évalué à 2.
Les Ramones ont influencé avec quelques mois d'avance la première vague punk anglo-américaine, en particulier The Clash et les Sex Pistols.
http://fr.wikipedia.org/wiki/Ramones
[^] # Re: punk ?
Posté par El Titi . En réponse au journal Punk's dead. Évalué à 2.
Ceux qui ont vraiment cassé la baraque, c'était les Ramones.
Mais bon, les gamins peuvent pas comprendre.
[^] # Re: réinvention de la roue ?
Posté par El Titi . En réponse à la dépêche Microblogging : envie d'un Twitter rien qu'à vous ?. Évalué à 0.
1 truk 2 l'epoch ?
[^] # Re: réinvention de la roue ?
Posté par El Titi . En réponse à la dépêche Microblogging : envie d'un Twitter rien qu'à vous ?. Évalué à 7.
===> []
[^] # Re: Ah la moderation
Posté par El Titi . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 3.
[^] # Re: Ah la moderation
Posté par El Titi . En réponse à la dépêche Bill Gates et la diversification externe. Évalué à 2.