new Blog( perso );

La licence GPL a fait couler beaucoup d'encre, et canalisé quelques frayeurs - auxquelles j'ai moi aussi participé - sur son aspect "viral". Symbole d'un idéalisme du libre, elle s'est longtemps heurtée à la réalité du monde économique purement guidé par des considérations lucratives.

Aujourd'hui, retournement de situation, la GPL devient l'arme numéro 1 de l'entreprise désireuse de porter son outil fétiche. Quelques exemples au hasard :

• L'excellent librairie EXT-JS
• SpringSource Application Platform
• Le framework de Lyria
• et plein d'autres que je vous laisse découvrir...
  

L'idée derrière tout ça ? Fàce aux géants du logiciel et à des développeurs Java qui misent beaucoup sur l'opensource, la licence GPL assure à une société de ne pas se voir canibaliser son code (et ses bonnes idées) tout en touchant un public aussi large que possible.

S'il s'avère que SpringSource à raison avec sa "plateforme", à mi-chemin entre OSGi et JEE, IBM ne pourra pas lui piquer - même par morceaux - pour l'intégrer à Websphere 9.

Retournement amusant de situation pour cette licence pas comme les autres ;-)

Lors d'un développement GWT, le mode Hosted permet de deboguer à loisir depuis Eclipse, ce qui est extrêmement puissant si on compare aux solutions existantes pour le développement JavaScript.

Mais le debogueur ne fait pas tout, et l'utilisation de logs est un complément indispensable.

Petit coup de pub donc pour la librairie gwt-log, qui propose une interface de type log4j pour produire des logs.

Premier point, le code des logs sera totalement supprimé lors de la compilation par GWT pour la combinaison log_level=OFF. Ceci permet donc de ne pas pourrir l'application de production avec des logs. Une "variante" peut être compilée en mode log_level=DEBUG pour le développement, et l'ajout d'un simple paramètre à l'URL permet de la sélectionner - merci la gestion combinatoire du compilo GWT !

Second point, gwt-log sait envoyer ses logs vers à peut près tout ce qu'il est possible d'imaginer :
un [div] de debug, le shell du mode Hosted, la sortie standard (i.e. la console d'Eclipse), ou la console de Firebug pour les amateurs ... Chacun prendra ce qui lui convient le mieux !

En attendant que le projet log4gwt du même auteur murisse, c'est une solution simple, utilisant le mécanisme de compilation de GWT avec intelligence.

J'ai raté la sortie d'Hibernate4Gwt en version 1.1. En plus de corriger quelques bugs, cette version est une mise à niveau pour GWT 1.5.

Pour ceux qui ne connaissent pas, H4GWT permet d'utiliser les entités Hibernate/JPA comme données dans une application GWT, ce qui comporte pas mal de complications techniques, habilement résolues par Bruno Marchesson.

Avec le support de Java5 dans GWT, et une "émulation" des annotations JPA, il devient possible d'utiliser le même modèle métier depuis la couche de persistance jusqu'à l'IHM web. Tout le code de type "contrôles et validation" peut alors être placé dans les setters du modèle, c'est à dire là ou il est finalement le plus logique de le placer !

Je n'ai pas pu tester personnellement (mon projet actuel ne s'y prête pas) mais l'idée me plaît beaucoup et me fait définitivement apprécier le concept phare derrière GWT : un langage et une plateforme pour toute la chaîne de développement.

Je viens de découvrir le dernier jeux en Flash, très bien réalisé : labrute.

On s'y combat entre avatars, en mode "spectateur", autant dire un combat de lancé de dés. C'est donc totalement inutile mais absolument incontournable. Si vous avez deux minutes à perdre, venez vous frotter à mon avatar http://cyberloof.labrute.com/

Originalité du jeu (tout de même), la possibilité de revoir les combats passés, ce qui nous offre quelques perles, comme un Microsoft vs Apple.

Je regrette juste de ne pas pouvoir coller mon chocobo préféré comme personnage...
A quand un Final Fantasy en flash ?

Je pars en congé pour une semaine en Allemagne.

Sachant que j'ai fait Allemand première langue, avec 7 années de cours pendant lesquels mes profs se sont acharnés pour me faire comprendre le gérondif, ai-je une petite chance de savoir aligner deux mots ?

Déjà à l'époque j'étais très mauvais en Allemand (j'ai préféré présenter l'option "dessin" au bac), alors aujourd'hui il n'en reste plus grand chose.

Une pub pour des cours de langue dit "il vaut mieux apprendre le français que chercher à comprendre un Français qui parle anglais", j'ai peur de ne pas faire entorse à la règle :-/

update :

De retour d'Allemagne, après une semaine formidable, accueilli dans une famille d'une gentillesse inouïe, j'ai quelques kilos à perdre - la bière Allemande est vraiment excellente - et le retour à la dure réalité est un peu rude ...

Ce jumelage a été une expérience géniale, que je vous recommande si votre ville en propose un, et les 14h de car (!) sont vite oubliées.

Hier soir j'ai passé deux heures dans les locaux de l'Ordre des Architecte pour négocier une résolution à l'amiable du conflit qui m'oppose à Mme B... sur la rénovation de ma maison.

De mon point de vue, 11% de dépassement du budget, un retard conséquent (2 ans depuis le lancement du projet), une méthode purement pifométrique, une comptabilité pitoyable, et enfin une communication minable pour une transparence nulle.

Le médiateur qui s'est chargé du dossier a été très bon, ramenant le calme et ne cherchant pas à enfoncer l'un ou l'autre tout en soulignant les torts respectifs. On s'en sort donc avec une sorte de "50/50" de marchand de tapis, mais au moins l'affaire est close.

Heureusement que ce genre de situation ne nous arrive jamais à nous, Architectes Java ;-)

Didier ne se contente pas de faire des présentations sur GWT, il fait aussi des applications avec ;-)

Il lance aujourd'hui un projet sur googlecode : NouvelleCuisine. Il s'agit d'un portail web dans l'esprit d'un Netvibes ou d'un iGoogle, mais développé en GWT et uniquement basé sur des ressources statiques : pas de serveur au sens traditionnel ! Même la configuration se fait via une feuille Google SpreadSheet...

Un portail web pour 0€, infrastructure comprise, qui dit mieux ?
Que va t-il rester aux bon gros serveurs de Portlets ?

Si vous cherchez comme Didier un moyen rapide, élégant et moderne pour classer vos fiches de cuisine, c'est l'une des solutions à tester. Ca marche d'ailleurs pour plein d'autres utilisations ;-)

Amusant aussi de découvrir sur ongwt.com le compte rendu du commité de revue de l'architecture technique - comprendre le coin de nappe en papier de la cafet'.

Didier Girard (application-servers, onGwt... c'est lui !) accepte l'invitation du BreizhJug pour venir animer la réunion d'inauguration, dont la date est fixée au 15/09.

Une excelente nouvelle pour le JUG, qui s'offre ainsi une inauguration en grande pompe avec un conférentier de talent sur un sujet "chaud". Si Google avait le bon gout de finalier GWT 1.5 pour cette date ce serait le top ;-)

J'ai le plaisir de vous annoncer le lancement d'un Java User Group sur Rennes !

2008 sera l'année des JUGs en france, avec le lancement réussi du ParisJug et du ToursJug, et bientôt des initiatives sur Nantes et Bordeaux, mais on parle aussi de Toulouse, Metz, Brest ...

J'ai le plaisir de présider le BreizhJug et en conséquence de rechercher activement sponsors et conférenciers. Si l'aventure vous intéresse, que vous voulez présenter votre travail lors d'une de nos réunion, ou que vous connaissez quelqu'un que ça pourrait intéresser, ou encore que votre société cherche à promouvoir une image "techno-innovante" et est prète à nous épauler, n'hésitez surtout pas à faire connaitre notre email : team@breizhjug.org

Lors de la réalisation d'un prototype basé sur GWT, je me suis intéressé à la testabilité du framework. GWTTestCase est très décevant car il utilise un navigateur "hosted mode" caché et lance tout le module GWT. C'est donc un bon support pour des tests d'intégration mais nettement trop lourd (et particulièrement lent) pour des tests unitaires.

Je reprend donc mes marque-pages, et je relis cet article et celui-ci.

Avec GWT 1.5, l'utilisation des types génériques permet de créer un modèle simple pour la mise en oeuvre du pattern "Supervising Controller" :

D'abord la notion d'événement, dédié à un composant donné (nb: à cause d'un bug de blogger, j'ai mis des crochets pour la déclaration des types génériques) :

1. public abstract class Event[T]
2. {
3. private T source;
4. public Event( T source ) {..}
5. }

..la source qui produit ces événements :

1. public interface EventSource[T]
2. {
3. void addListerner( Listener[Event[T]] listener );
4. void removeListerner( Listener[Event[T]] listener );
5. }

..et une classe abstraite pour construire nos SupervisingControllers :

1. public abstract class SupervisingController
2. implements Listener[Event[T]]
3. {
4. protected T view;
5. public abstract Object getModel();
6. public void setView( T view )
7. {
8. this.view = view;
9. view.addListerner( this );
10. }
11. }

Il suffit ensuite de définir la "vue" par une interface, comme dans cet exemple ma pop-up de login :

1. public interface LoginDialog extends EventSource[LoginDialog]
2. {
3. String getLogin();
4. String getPassword();
5. void hide();
6. }

Le contrôleur, lui, étend notre SupervisingController en le typant avec l'interface de la vue "supervisée".

1. public class LoginController
2. extends SupervisingController[LoginDialog]
3. {
4. private LoginService service;
5. ...
   

.. et sur réception d'un événement de type 'validation du formulaire de login', il n'a plus qu'à invoquer le service RPC de connexion, mettre à jour les éléments visuels qui vont bien, et fermer la popup :

1. public void on( Event e )
2. {
3. loginService.login( view.getLogin(), view.getPassword(),
4. new AsyncCallback[Utilisateur]()
5. {
6. public void onSuccess( Utilisateur result )
7. {
8. view.hide();
9. }
10. } );
11. }
    

Gràce au génériques, il n'y a pas de cast à déclarer et le code reste donc plutôt simple.

Qu'est ce que ça change ? Et bien maintenant, avec un simple Mock pour mon interface LoginDialog, et un service RPC de test, je peux tester dans un test jUnit classique la logique IHM de mon contrôleur. Elle est triviale dans l'exemple, mais vous devinez que la gestion d'un formulaire de 20 champs avec des controles croisés peut devenir un enfer sans un bon mécanisme de test.

Ce qu'il manque pour faire "encore mieux" :

• un mécanisme de data-binding entre les widgets et un "modèle". Il existe quelques initiatives opensource, dont le succés et la pérennité sont à évaluer.
  
• un spring-gwt, qui permettrait de déclarer dans l'exemple ci-dessus l'injection de la vue et du service RPC via une annotation @Resource. Dis Monsier Rod Johnson, tu peux m'inclure ça dans la roadmap spring 3.0 ;-)
  

Suite à la demande de quelques un d'entre vous, je vous informe que le "poussin" qui apparaît en haut à droite de ce blog est en fait un (bébé) Chocobo, personnage issu du jeu Final Fantasy 7, l'un des rares jeu vidéo (avec Doom) auquel j'ai joué assidument.

En fait, je pense qu'elle est déjà très répendue, mais qu'on a pas forcément mis un nom dessus jusqu'ici. Un grand bravo aux créateurs de ce site !

Valtech organisait jeudi une journée atelier RIA, une formule originale permettant de comparer sur le terrain Gwt, Flex et SilverLight. Ces trois noms dominent en effet (pour l’instant ?) le monde très actif des Rich Internet Applications.

Petite mise au point pour commencer : une Application Internet Riche n’est pas juste une application web bourrée d'effets visuels. Ce n’est pas non plus une application utilisant Ajax pour en améliorer l’ergonomie ou la réactivité.

Une RIA c’est une application qui a été conçue pour déporter sur le client la couche présentation, tout en conservant sur le serveur des services métier de haut niveau, autant que possible sans état. C’est donc à mis chemin entre le client lourd + serveur de données et le client léger + serveur web de présentation. Le serveur devient alors un conteneur de services métier, ce qui permet de converger avec l'approche SOA.Un exemple parmis d'autres, parleys.com (en version Flex ou Gwt) : le serveur héberge les vidéos et les indexes, toutes la mise en page étant gérée sur le client.

Bien sur, cela s’accompagne souvent d’effets graphiques haut de gamme pour se démarquer des applications web devenues trop statiques. Il faut bien un moyen d'accrocher l'internaute !

Quelle est la difficulté sur ce type d'applications ?

1. la mutliplicité des technologies qu'on doit couvrir pour une même application : HTML + CSS + DOM + JavaScript + HTTP/Ajax + JSP + Java + ...
2. les exigences de multi-plateforme, en particulier si on vise le monde mobile
   
3. le delta qui existe entre un "hello world" et une application de 100 écrans, en particulier pour venir ajouter de nouvelles fonctionnalités
   

SilverLight est la solution RIA proposée par Microsoft, nécessitant un runtime encore peu répandu, mais qui pourrait rapidement se généraliser via le meilleur outil de promotion : Windows Update ;-)

La présentation SilverLight était assez décevante, trop orientée design pour un public de purs programmeurs, et ne connaissant pas l'outil Blend la première heure a quasiment été perdue. Nous sommes nombreux à en avoir eu une image négative, sans doute fausse par rapport à cette technologie. J’en retiens trois points majeurs :

• SilverLight et les outils qui l’accompagnent manquent encore de maturité (nous avons utilisé des versions beta, avec de nombreux bugs). Nous n’avons pas utilisé Visual Studio, aussi c’est donc peut-être une fausse impression.
• Le choix de Microsoft de séparer les outils de Design (Expression) de ceux de développement est discutable. Même en confiant ces rôles à deux personnes, on peut être amené à jongler entre les deux.
• SilverLight a l’avantage d’être très homogène, client et serveur se programmant en C#, notion que l’on retrouve dans Gwt.

Flex utilise le runtime Flash 9, déjà installé sur de très nombreux postes.

La présentation Flex était très démonstrative, mettant en avant les capacités graphiques du format Flash. L’environnement FlexBuilder est très appréciable (175€), même si de nombreuses fonctionnalités habituelles en Java manquent (formateur de code, refactoring…). Flex permet de laisser aux graphistes le soin de préparer les objets Flash avec toute la puissance de cet environnement. La programmation nécessite cependant de se familiariser avec ActiveScript, pas infaisable mais pas immédiat non plus. Se pose aussi la question du débogage sur des applications ambitieuses. Flexbuilder est très aboutit et probablement indispensable pour envisager ce type de développement.

Pour ces deux premiers candidats, se pose la question de la disponibilité d’un runtime sur toutes les plateformes, en particulier sur mobiles, marché d’avenir pour ces applications.

GWT est un peu l’intrus dans cette journée. Il se positionne fonctionnellement très en dessous de ses concurrents, sans support pour des effets 3D ou vidéo. Par contre, il est le seul à ne nécessiter aucune installation de runtime.

La présentation GWT était plus une visite guidée d’une application GWT, mettant en évidence les principes clé. Le très gros point fort est le développement 100% Java, qui permet ainsi de coder/tester/deboguer sous Eclipse, par simples « save + refresh », et de bénéficier de l’environnement JDT pour « découvrir » l’API GWT. La programmation GWT est donc assez naturelle pour des développeurs Swing.

Absent de cet atelier, JavaFX, pour lequel je me pose pas mal de questions. Ne se programmant pas en Java, on ne retrouve pas les avantages de Gwt ou Silverlight. Générant une application type Swing, quelle différence de fond par rapport à Java Web Start ?

J’ai été impressionné par la facilité de construction d’une IHM Flex, et surtout par le très bon niveau de FlexBuilder, qui malgré la filiation du langage ActiveScript avec JavaScript propose un éditeur riche et assez proche de celui d’Eclipse pour Java. Je n’ai pas accroché sur SilverLight, ne serait-ce qu’à cause du langage C# qui m’est peu familier, mais c’est clairement une plateforme avec laquelle il faudra compter. Enfin, GWT a été très bien vendu par Sami ;-). Il reste tout de même un besoin de compétence pour la mise au point des CSS, tout aussi peu homogène au niveau des navigateurs, point qui n'est pas abordé par Gwt - domage.

Mes conclusions ?

• Spring MVC + Spring JS pour des applications web classiques avec un bonus ergonomique, comme expliqué dans mon précédent post, cela permet une migraiton "en douceur" depuis Struts.
  
• GWT pour des applications RIA de type « gestion », manipulant plus des données que des vidéos ou des effets 3D. Il faut cependant développer une culture "layout" des IHM.
  
• Flex pour les applications « flashy » (c’est le cas de le dire), avec l’aide inconditionnelle de FlexBuilder.

Depuis X mois, je tergiverse sur le framework web que je compte "pousser" pour remplacer le vieillissant Struts 1.x.

Suite à SpringOne08 où j'ai suivi la session de Keith Donald sur Spring MVC 2.5 (rebaptise "@MVC"), WebFlow et spring JS, je penche nettement vers cette solution.

Certes, le produit n'est pas révolutionnaire - on reste dans du MVC classique. Mais ...

• Son principe général, comparable à Struts (MVC oblige), facilite l'apprentissage pour les développeurs Struts : on peut expliquer chaque notion en se référant à l'équivalent Struts, par exemple pour la librairie de tags.
• Les conventions et annotations permettent de réduire très sensiblement la configuration, ce qui est très appréciable
• Le mécanisme proposé par Web Flow est un très net avantage, permettant de faire des IHM robustes
• La documentation est de bonne qualité, avec de nombreux exemples
• La pérennité de l'outil ne fait pas de doute
• L'intégration Ajax et le support des widgets Dojo permettent de faire une appli raisonnablement sympathique, sans nécessiter des développeurs JavaScript / web 2.0.

Pour des besoins plus "sexy", je pencherais pour GWT, ou Flex, mais pour mon appli actuelle, plus que classique dans son approche, mais destinée à durer (...), je préfère miser sur un cheval fiable et qui sera toujours d'actualité dans X années.

L'équipe chargée de la promotion de Firefox 3 propose de créer un record du logiciel le plus téléchargé en 24h.

Ca commence ce soir, alors jetez vous sur votre connexion ASDL préférée, en espérant que l'équipe de Mozilla à préparé une infrastructure réseau digne de ce challenge !

update :
C'est parti... et le site est difficilement joignable pour l'instant ... mais je réussi tout de même à lancer le download (7ko/s) - côté infrastructure, le pari est donc apparemment bien relevé.

A quoi sert cette opération ?

• A attirer de nouveaux utilisateurs ? La grande majorité des "téléchargeurs" sont déjà utilisateurs de Firefox 2, voir d'une beta de la v3.
• A faire parler de Firefox ... peut être, mais dans ce cas le sujet est mal posé. La comparaison avec les autres navigateurs n'est pas mise en avant par cette technique de vendeur de lessive

Alors ? A mon humble avis, le but est de faire parler de Firefox dans des médias qui n'ont rien a voir avec le sujet, genre "l'image du jour" à la fin de la météo, on le dernier titre du 20h qui aborde des sujets insolites. En effet, de très nombreux utilisateurs de Windows n'y connaissent vraiment rien en informatique et se contente de IE, sans même savoir qu'il existe autre chose. En faisant passer le nom "FireFox" dans des médias très grand public, on peut espérer pénétrer ce "marché".

C'est un peu comme le succès de MSN chez les jeunes. Un moins de 16 ans n'a aucune idée de ce qu'est une messagerie instantanée, par contre il se connecte tous les soirs sur MSN ...

Je vais consigner mes notes concernant la conférence SpringOne sur google docs

J'espère que cela servira à ceux qui n'ont pas pu s'y rendre pour X raison, et que ça donnera envie à ceux qui ne connaissent pas.

Je vais essayer de transcrire l'atmosphère à la fois chaleureuse et studieuse de ces conférences. Pour ma part j'y ai appris beaucoup de choses lors des précédentes éditions, bien plus que des formations "encadrées" si on sait suivre les pointeurs proposés par les intervenants.

Encore deux jour avant l'édition 2008 de SpringOne.

Mes deux sujets cible : AOP et OSGi

AOP parce que je suis convaincu qu'on peut faire de grande chose avec les principes de programmation par aspects, mais qu'on en sous-estime la puissance au profit d'une approche plus procédurale.

OSGi parce que c'est un ovni pour moi : j'ai du mal à voir ce qu'il peut m'apporter, par contre je vois bien les contraintes qui l'accompagnent (gestion des "bundles", librairies qui ne marche plus à cause d'un Class.forName(x)...). Peut être des débuts de réponse au cours de ces deux jours.

Mon programme - sauf modification au fil de l'annimation locale :

day 1:
Spring 2.5 on the Way to 3.0
OSGi Programming Model
Spring Dynamic Modules for OSGi
Five Aspects You Don't Know About
dernière session ?

day 2:
Open Forum with Rod Johnson
Applying the Spring Frameworks for Model-Driven Architecture ou What's new in Spring MVC 2.5 and beyond
Inside SpringSource Application Platform
Making Sense of AOP Choices ou Classloading in OSGi - mince, c'est en même temps :-/
Spring Architecture and Best Practices ou Spring Web Flow 2.0 Deep Dive

Je me suis rapidement rendu compte qu'il fallait choisir sa session en fonction de l'interlocuteur : mon niveau d'anglais assez pittoyable m'oblige à sélectionner les "BBC-english-compliant-speakers". Un sujet apparement allèchant, si on ne comprend pas grand chose, n'apporte rien. Et pusi le but de ces conférences c'est aussi de voir autre chose. En fin de journée, quand le cerveau commence à fumer, on a parfois envie d'un sujet un peu différent, pourquoi pas RESTful Web Services in Spring ?

Si l'un de vous est également présent à cette édition, fait moi signe - je serais reconnaissable à mon joli sac Spring-one ... comment ça tout le monde en a un ? Bon alors, un petit mail et on partagera nos avis autour d'une barguette de frites ?

Les applications "web 2.0" utilisent de grandes quantités de JavaScript. Les librairies écrites dans ce langage font preuve de beaucoup d'effort pour obtenir les meilleurs résultats sans sacrifier une bonne structuration, mais les performances reposent toujours sur l'interpréteur JS du navigateur.

Si sur un PC "moderne" cela pose relativement peu de problème, c'est loin d'être le cas pour le marché du web mobile. Il est hors de question de faire ingurgiter des centaines de ko de script à un navigateur mobile en espérant des performances de haut niveau.

Or c'est le marché le plus porteur du web de demain ! Certains site orientés mobiles observent déjà une avalanche de requêtes "iPhone". Non pas qu'il y ait des millions d'utilisateurs du joujou d'Apple, mais plutôt que ceux-ci utilisent leur mobile comme station web, connectée en permanence, et donc ont un comportement très différent de l'utilisateur classique qui garde un oeil sur son forfait WAP 1h ;-)

Les développeurs de WebKit (le moteur commun des navigateurs KDE et Safari) annoncent leur projet SquirrelFish - comment peut on trouver des noms pareils ;-)
Il s'agit d'un moteur JavaScript utilisant un mode "compilé" des scripts sous forme de bytecode, ce qui permet d'excellentes performances.

Ils proposent également un benchmark qui permet de se faire sa propre opinion
http://webkit.org/perf/sunspider-0.9/sunspider-driver.html

Pour moi, ça donne sur mon PC (windows XP) :

IE7 : 46 172 ms
IE8 beta : ne s'installe pas chez moi, problème d'update invalide :-( il faut une version US ?
Firefox 2 : 34 946 ms
Firefox 3 rc1 : 5 256 ms
Safari 3 : 6 690ms
Safari + Webkit "nightly build" : 4 859ms -- soit presque 10fois mieux que IE7 !!

Bien sur, comme toujours, ce bench est probablement discutable et les résultats sur un seul PC ne sont pas représentatifs ...

OK, donc il suffit d'attendre la mise à jour du navigateur de mon mobile préféré pour lancer mon application "web 2.0" basé sur XYZ.js avec plein de plugins et qui en jette un max ?

Ce serait aller un peu vite... les ressources mémoire, bande passante et autres spécificités de l'Internet mobile sont peu considérées par les développeurs, peut être un peu trop habitués aux centaines de Mo d'un PC et au GHz de son processeur.

On trouve par exemple les recommandations de Yahoo sur le sujet. Une grande partie du temps de réponse apparent d'une application est imputable à l'ordre de chargement des fichiers qui composent la page web. En regroupant les scripts, images et les CSS, en les ordonnant et en comprenant le chargement d'une page on peu nettement améliorer sa réactivité.

Les premiers à bien mettre en pratique le web mobile occuperont le terrain ! Rien de tel qu'une application qui rame pour jeter le doute sur une technologie.