MD Blog

J’ai participé la semaine dernière (18/09), comme spectateur, au passage à Paris du Google Developer Day.

Un petit retour rapide sur deux des présentations auxquelles j’ai assisté :

Android

J’ai eu envie d’en savoir un peu plus sur Android, un des buzz à la mode. Malgré un présentation plutôt sympa, pas d’annonce fracassante ni d’exclu juteuse. On n’a même pas pu voir le G1 « en vrai » !
Petite confidence « off » du conférencier : « j’ai un iPhone et un G1 et je préfère quand même l’iPhone » :-)

Un truc très sympa : un gagnant français du concours de développements Android (Android Developer Challenge) organisé par Google à parlé de son appli : un central de gestion de covoiturage (avec paiement éventuel et gestion de blacklist) intégrant la géolocalisation. A suivre probablement.

Au passage le concours en question, très bien doté puisqu’au total, ils ont distribué 5 millions de dollars, leur a permis de se constituer une logithèque de qualité (~2000 softs) avant même la sortie du mobile !
La vraie question est : nous, développeurs d’applis de gestion, devons-nous nous pencher sur le développement mobile ? Devons nous investir, nous former ?

Autant vous le dire, la présentation ne m’a pas apporté la réponse :-(

M2C : même si le rapport au mobile est aujourd’hui très « personnel » voire privé, il me semble que son coût extrêmement faible au regard de la technologie qu’il embarque devrait (moyennant un peu plus d’imagination que ce à quoi nous avons habitué nos clients) nous permettre d’explorer de nouveaux « use cases ». Désolé, ça reste vague, mais je pense que ça viendra probablement de la BI pour qui la diffusion d’informations, leur présentation, la dimension « aide à la décision » devraient être des moteurs. Je vais en causer avec mes voisins de bureau…

Google App Engine

La présentation pour laquelle j’étais essentiellement venu m’a laissé sur ma faim. Il m’a semblé que les deux conférenciers (non « Googliens ») avaient juste passé deux heures de plus que moi sur le sujet (j’avais téléchargé le SDK la veille et déroulé le « Hello World » : 10 mn montre en main) ! Ils ont déroulé le Hello World en une demi-heure puis passé en revue les services disponibles. A leur décharge, on ne peut pas dire que Google nous « arrose » d’informations sur le sujet !

Pour résumer, qu’est-ce que le Google App Engine ?

• Vision commerciale : c’est l’offre « cloud computing » de Google (essentiellement en réponse à EC2 d’Amazon).
• Vision technique : c’est un serveur d’application hébergé exclusivement chez Google et qui s’appuie sur son infrastructure et met à disposition ses services : authentification, mail, persistance dans « BigTable » (LA base Google), accès aux Google Apps…

Concernant la technique, plusieurs points peuvent faire « tiquer » : un développement pour Google App Engine est exclusivement pour Google App Engine ! Google n’a pas eu la volonté d’implémenter, avec ses ressources, un serveur d’appli « standard » (J2EE ?). Tout est un peu « exotique » : l’authentification nécessite d’avoir un compte Google (la page d’authent est la même que pour votre GMail), la base n’est pas relationnelle, le langage de programmation est Python… et, aujourd’hui, aucune solution connue (en tout cas utilisée dans ma boîte, Objet Direct) ne permet de développer facilement (c’est le point important !) des IHM web pour GAE.

Ca veut dire, investir pas mal pour un business à peine émergent (GAE n’existe que depuis avril !).
La donne va changer dès que les API java sortiront (ce qui ne devrait tout de même pas tarder, même si, même sous le sceau du secret, ils ont refusé de nous dire quand !).
Il est donc urgent d’attendre (mais pas longtemps, j’espère).

Une chose très sensible : ce sont des maniaques du secret. Je pense que même après douze bières, il est impossible de leur faire avouer quand java sortira sur GAE. Il doivent avoir un flingue dans le dos (et en tout état de cause, ils sont très, très « briefés »).
A part ça je confirme que l’accueil était très sympa et l’esprit (faussement !) startup affiché (allez voir les photos, il y a même une preuve que j’y étais !). Une bonne occasion de faire du networking » et/ou du recrutement ou tout simplement de croiser des gens sympas « en vrai » (salut Samuel :-) ) ou de vieilles connaissances.

Et, comme prévu, malheureusement, pas de MD chez Google pour le moment :-(

J’anime le 8 juillet à 20h, une des deux présentations du Paris JUG (Java Users Group). Le titre « Pourquoi tout le monde ne fait-il pas du MDA ? » annonce le ton. La présentation sera un peu polémique :-)

En particulier j’essaierai de montrer ce qui, aujourd’hui, freine l’adoption des démarches par transformation/génération (plate-forme incomplète, approche trop naïve, rareté des bons profils, changement d’organisation) et comment tenter d’y remédier.

En espérant vous y croiser et échanger sur le sujet autour d’une bière.

Ca se déroule dans les locaux de la FIAPP au 14 rue Cabanis dans le 14ème.

J’ai l’honneur de partager la soirée avec James Ward (Mr Flex chez Adobe) qui anime le slot 21h30-22h30 sur « RIA avec Flex et Java ».

J’anime le 12 juin après-midi à Grenoble un séminaire (gratuit !) sur MDA : « De la modélisation métier à l’application générée, comment tirer parti concrètement du MDA ?« .

Après une présentation générale des concepts j’expliquerai comment rendre efficace un processus MD. Je parlerai particulièrement de deux problèmes, à mon avis, difficiles :

• Comment inclure les traitements métiers dans le modèle d’analyse ?
• Comment dépasser le modèle de domaine et mettre en oeuvre une vraie modélisation applicative ?

Je présenterai un cas réel de l’utilisation de prototypes fonctionnels pour simuler et valider une analyse MD (avec D.OM) et une mise en œuvre concrète de la plate-forme MDA d’Objet Direct (Metadone) sur laquelle je travaille.

Vous pouvez vous y inscrire en ligne ici. Je serai ravi de vous y rencontrer et d’échanger sur le sujet.

Je sais ça n’est pas du tout MD (encore que : quelle sera la première plate-forme à générer du code GAE ?)

Didier Girard organise un test de stress sur une appli Google App Engine (il va vraiment falloir se mettre au Python, à moins de le générer).
Donc, demain (vendredi 23 mai 2008) 16h, entraînez-vous à la frappe rapide.
Le post original est là (au fait, il se trompe d’heure : en été, la France est à GMT+2 et non +1 ; il risque d’avoir tous les étrangers à 15h !).

Dans tous les cas, je pense qu’on se doit de regarder GAE qui
- est un vrai changement par rapport à nos habitudes actuelles
- est poussé fortement par Google
- est un des trucs qui fait méchamment flipper Microsoft

Il existe un blog pas mal sur le sujet avec quelques liens intéressants.

Bienvenue sur le Cloud.

J’ai eu la chance de participer, pour Objet Direct, la semaine dernière, aux QCon à Londres. Malgré de nombreuses interventions de haut niveau, il y avait, malheureusement, peu de speach en rapport avec l’approche MD. Le thème sur les DSL était probablement le plus proche de mes préoccupations du moment. Le speach le plus intéressant était celui de Markus Völter, External Textual DSLs made simple, qui présentait XText. Il s’agit d’un outillage eclipse qui permet très simplement de produire un environnement de développement pour un DSL.

En effet, un des prérequis à l’adoption de DSL est la disponibilité d’outils de « développement » associé. Personne n’acceptera d’utiliser un DSL avec Word comme IDE…

Le principe de XText est simple : en entrée, on fournit une grammaire BNF du DSL (plus quelques infos facultatives supplémentaires : contraintes exprimées en OCL, contenu et structure des vues sur le code), l’outil génère, sous forme d’un plugin eclipse, un parseur, un modèle cible (EMF), un compilateur vers ce modèle et un éditeur qui fournit tout ce qu’on attend : coloration syntaxique, complétion du code, vue « outline » personnalisable, validation temps réel de contraintes.

Le « DSL-IDE » produisant de l’EMF, il est possible d’exploiter sa sortie avec tout l’outillage diponible : visualisation graphique, transformateurs de modèle, générateurs de code. En particulier, il est possible d’intégrer la compilation de ce DSL dans une chaîne de transformation OpenArchitectureWare (oAW Workflow).

Je pense essayer rapidement l’outil avec un petit langage orienté vers la saisie d’exigences métier. Je vous tiendrai au courant.

La période autour des fêtes a été l’occasion d’annoncer une avalanche de nouveautés (presque toutes mineures !) chez les éditeurs et les fournisseurs d’outils : Lire le reste de cet article »

Ce post fait suite au premier du même nom qui s’intéressait à l’implémentation de relation UML en java. On avait vu qu’une simple association 1-1 donnait déjà lieu à du code non trivial.

Un problème amusant (!) du même genre est la transformation en java, d’une relation multivaluée. L’objectif est, toujours, de conserver en implémentation le maximum d’informations contenues dans le modèle.

Pour planter le décor concernant nos époux (qui sont tous les deux des personnes :-) ), je vous propose d’étendre le domaine de notre application au delà de leur vie amoureuse. Considérons par exemple leur lieu d’habitation et leurs changements d’adresse successifs. Notre modèle de domaine ressemblera à ça :

Lire le reste de cet article »

Une nouvelle version d’Objecteering, la 6.1, est sortie en décembre.

Je vous en parle car parmi les nouveautés annoncées, une m’a particulièrement attiré l’oeil : jusqu’ici, tout le « scripting » lié à la transformation de modèle et à la génération de code s’écrivait à l’aide d’un langage propriétaire, « J ». Depuis cette version, on a la possibilité de développer directement en Java.

Lire le reste de cet article »

Qu’est-ce qu’ un DSL (Domain Specific Language ou Langage Dédié pour les intimes) ? Le dernier buzz word à la mode dans la communauté MD ! Si des gens aussi estimables que Martin Fowler prennent la peine d’écrire un livre sur le sujet, ça doit être un peu plus que ça.

J’ai glané quelques définitions sur le web (les traductions sont personnelles) :

Lire le reste de cet article »

Même si quand on pense modèle, on voit le plus souvent un diagramme avec des boites et des flèches, il est souvent plus intéressant de produire un modèle sous forme de texte compréhensible par un humain.

C’est en particulier souvent bien plus efficace pour exprimer la composante dynamique du modèle. Ceux qui me connaissent savent que je suis à la recherche d’un Graal : une syntaxe concrète correspondant à la sémantique des actions d’UML (ASL en est la syntaxe abstraite).

Pour parler clairement : un langage permettant d’écrire le corps des méthodes en UML sans être lié à une technologie ou un langage cible.

Il y a peut-être de l’outillage en vue : TMF (Textual Modeling Framework) serait le pendant textuel de GMF pour la partie graphique. GMF est un framework générique pour instancier le (méta-)modèle EMF via des éditeurs graphiques. TMF permettrait la même chose via des éditeurs textuels.

C’est encore à l’état de « proposal » mais ça mérite d’être suivi.