El Titi a écrit 3940 commentaires

Espérons pour Thierry Lhermitte qu'après ses récentes déclarations sur Hadopi , il ne choisisse pas d'investir dans DMG

Disclaimer: comme je ne vois pas apparaitre les balises avant de poster, je replace les liens
http://lci.tf1.fr/high-tech/bono-veut-un-hadopi-mondial-5620(...)
http://eco.rue89.com/2010/01/06/hadopi-thierry-lhermitte-et-(...)

Ca ne concernerait que les projets java.

Pour ceux en ruby ou en perl, je verrais plutôt la somme de cailloux des copines de geeks, quoique ca risque de stagner un peu.

Voilà un commentaire bien original. ;-)

Pire !
Le hash SHA-1 de la release du projet.

Non, ca fait tache.

*PAN*

C'est marrant qu'on s'étripe sur le format RAW ou jpeg au niveau de la qualité et que personne ne se lance sur le terrain des libertés.

Personnellement et pour l'usage amateur que j'en ai, tant que ce format n'est pas complètement ouvert ou à minima que le standard n'est pas respecté par l'industrie, je n'en mesure pas l'intérêt.

Quant à la comparaison avec le MP3 et le FLAC, je mettrais plutôt en face de Apple Lossless

'Pour le porno, achetez vous un smartphone Android. Steve Jobs a beau être visionnaire et excellent marketeux, il vient peut-être de faire là une énorme bourde'

Non, ce n'est pas une bourde. C'est une conséquence logique du modèle choisi par Apple.


Si c'est une bourde, puisqu'on peut se contenter d'installer Android sur son iphone :D
http://linuxoniphone.blogspot.com/2010/04/ive-been-working-o(...)

Drôle de question de la part du modo de la dépêche.

Pas moyen de se renseigner auprès de l'auteur ou envie de sacrifier à la tradition du business loto sur les dépêches java ;)

CQFD ?

Le mieux ca serait de ne pas divulguer le code :O)

Oui, une fois

Je préfère un langage qui supporte les threads qu'un langage qui se réfugie derrière le multiprocess à cause du GIL (ou qui fait appel à des implémentations différentes pour pallier ses faiblesses comme ironpython ou jython)

Je préfère un langage qui fait la différence entre des champs privés publics ou protégé et qui ne réfugie pas derrière des astuces d'implémentation.

Je préfère un langage qui ne recourt pas à des idiomes pour que sa grammaire tienne dans une image réduite de flickr

while True:
do_something()
if condition():
break


Je préfère un langage qui fait supporte pleinement l'héritage ou le multi-héritage à du duck-typing qui te pète à la tronche en prod au lieu de la compil.

Je préfère un langage qui ne pète pas tout ton code à chaque réindentation

...

Compte tenu de la volonté de l'Élysée de copier la maison blanche, on peut espérer un changement de politique chez nous.
On peut seulement espérer, parce qu'en France, on en est plutôt là.
(INPI chasse le logiciel libre de la cité des sciences. Déjà traité mais ça ne fait pas de mal d'en remettre une couche).

La maison blanche, c'est aussi une vision très personnelle de la neutralité du net, pas si éloignée que ça de notre omniprésident et des intérêts de l'INPI.

http://www.numerama.com/magazine/15006-obama-34croit-fermeme(...)

Merci, ca pourrait servir.

Sympa les démos.

Vous filmez ca avec quoi ?

Oui j'imagine que les cathédrales étaient décrites en "langage naturel" et qu'aucun plan i.e une vue abstraite de la réalité à produire n'existait.

Très bon exemple.

Marrant je vois la même chose pour Android.
T'as déjà essayer de surfer sur un site quelconque plus de 10 mn sans piquer une crise de nerf.
Pourtant il existait un certain WAP qui devait régler le pb et la sauce n'a pas pris.
Serait-ce que le web for the masses, c'est pas ce qu'on croit ?

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.

ç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 ?

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.

Pas inutilisable.
Tout dépend de l'usage que tu en fais.
Cf. ma réponse à ton post plus bas.

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.

Je ne voudrais pas m'avancer mais Acceleo se base sur un langage de template et fait des transfos M2T. Il est donc dévolu au top-down pas au reverse

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.