Blog Objet Direct

Le ParisJUG du 13 mars 2012 présentait les prochaines évolutions de Java en commençant par le classique retour sur l’historique de Java et en particulier Java 7.

Java 7 sorte de version intermédiaire avant la version 8 de Java contenait l’ensemble des améliorations visibles ici : http://openjdk.java.net/projects/jdk7/features/

Pour faire un rapide tour :

• JSR 334 “project coin” : String dans les switch, Multi-catch, Try-with-ressources (AutoCloseable), Diamond operator pour éviter de repeater le type d’un generic, Simplified varargs, Binary literals and underscores in numeric literals
• JSR 203 « NIO2 » : Un design facilitant les extensions, accès au metadata des fichiers, des méthodes utilitaires comme move ou copy, une abstraction de plus haut niveau (java.nio.file.Path), une gestion des exceptions consistante
• JSR 166y Fork/Join et Parallel Array pour encore faciliter la programmation parallèle.
• JSR 292 InvokeDynamic pour améliorer les performances des langages dynamiques (type Groovy) sur la JVM.

Mais la présentation s’attachait surtout à présenter JDK 8 prévu pour l’été 2013 dont la liste des améliorations contient le projet Jigsaw, le projet lambda, une nouvelle API Date (le retour de la vengeance), une convergence entre les VM JRockit et Hotspot ou encore JavaFX 3.0. Il est possible de suivre les évolutions sur le site d’OpenJDK : http://openjdk.java.net/projects/jdk8/

C’est sur ce premier projet Jigsaw qu’est revenu Alexis Moussine-Pouchkine.

Il y a déjà eu de nombreux essais pour améliorer la modularisation de Java : JSR 277 Java module, OSGi, JSR 294 et maintenant JigSaw

Le problème actuel est que la construction, le packaging et la publication d’une application tombe souvent dans l’enfer des JAR. Il faut donc trouver une meilleure solution pour améliorer la scalabilité par rapport à la plateforme en particulier pour les petits périphériques et améliorer les performances surtout les temps de téléchargement et de démarrage.

Le but est donc de créer un système de modules statiques et simples, assez performant pour modulariser le JDK lui-même, améliorer les performances et utilisable par n’importe quel développeur java.

Les conséquences sont plus de classpath, plus de rt.jar. L’idée est de résoudre les problèmes de dépendances en amont !

La mise en place des modules Jigsaw offrira différentes possibilités : Grouping, Versioning, Encapsultation avec le mot clé permits, splitting, aggregation avec le mot clé provides.

Voila un exemple de modularisation avec Jigsaw :

module com.greetings @ 0.1 {
	requires jdk.base; // default to the highest available version
	requires org.astro @ 1.2;
	class com.greetings.Hello;
}

Vous trouverez tous les détails sur cette page : http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html

Avec Jigsaw, le fichier jmod remplace le jar mais il sera toujours possible d’utiliser des repositories : librairies mis en ligne au bout d’une url. Il est prévu une intéropérabilité avec OSGi. La compatibilité sera toujours existante par on pourra rajouter des informations au jar existant pour les rendre compatible jigsaw.

Le deuxième présentateur Remi Forax qui est venu nous présenter les lambdas ou l’arche d’alliance de java ;)

Pourquoi les lambdas ? L’idée est de se rapprocher des langages fonctionnels et de simplifier l’utilisation des « closures » ou méthodes anonymes dans Java même si une partie du fonctionnement est déjà réalisable avec les Inner Class.

La grosse question est de connaître quel est le type d’une lambda et la solution a été trouvée dans les Single Abstract Method qui sont des interfaces qui contiennent une seule déclaration de méthode. On peut même les nommer interfaces fonctionnelles et Java en possède déjà tel que Runnable ou ActionListener.

Voila des exemples du futur code utilisant les lambdas :

	(int x, int y) -> x + y

	FileFilter java = (File f) -> f.getName().endsWith(".java");

	new Thread(() -> {
		connectToService();
		sendNotification();
	}).start();

Contrairement au Inner class, une lambda peut capturer les valeurs des variables du scope : le this ne référence pas la pseudo inner class mais l’englobant. Pour clarifier les choses, les inner class sont des classes, les lambdas sont des fonctions anonymes.

Les lambdas ajoutent beaucoup d’expressivité au langage Java mais l’idée est aussi d’ajouter les librairies pouvant en tirer partie. Ajouter des nouvelles fonctionnalités aux librairies existantes est quelque chose  de très difficile en Java actuellement si on veut garder la compatibilité. Il a donc fallu trouver une solution et celle-ci a été de mettre en place les « Default methods »

Par exemple :

interface Iterable<E> {
	public  Interable<E> filter(Predicate<E> predicate) default {
		//code
	}
}

Les defaults methods sont en fait des traits (Scala) ou mixins (Ruby) simplifiés.

Les defaults methods et les lambdas sont bien sur faits pour fonctionner ensemble. Actuellement si on veut écrire du code qui trie les personnes par leur nom on va écrire :

Collections.sort(people, new Comparator<Person>() {
	public int compare(Person x, Person y) {
		return x.getLastName().compareTo(y.getLastName());
});

Demain avec les lambdas, de l’ajout de l’interface Mapper et de l’ajout de la default method comparing à Collections, il suffira d’écrire :

Collections.sort(people, comparing(p -> p.getLastName()));

La encore vous trouverez tous les détails sur le site d’OpenJDK : http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html

• 

Le Paris JUG du 10 janvier 2012 était consacré à DevOps.

Pour ceux qui ne connaîtraient pas, le terme « DevOps » a été donné au mouvement cherchant à améliorer la qualité des services fournis par les solutions informatiques ou encore aligner le SI sur les besoins de l’entreprise en rendant l’infrastructure plus agile. L’idée sous-jacente est de rapprocher les parties développement et opération du SI, deux fonctions qui se retrouvent en opposition. D’ailleurs DevOps est tout simplement la concaténation des deux mots.

Comme le dit très bien la définition de Wikipedia, le problème commun actuellement est que, si une équipe d’exploitation est primée sur la stabilité du système alors que l’équipe de développement est récompensée à chaque nouvelle fonctionnalité livrée, il est évident que ces 2 équipes vont se retrouver en conflit perpétuel.

Le but de DevOps est alors de promouvoir la coopération, industrialiser et motiver chacun individuellement sans noyer l’ensemble dans la masse. Le mouvement DevOps en plus de réfléchir à une nouvelle organisation de l’entreprise, vise à trouver des technique et des outils pour favoriser cette coopération.

C’est ce qu’est venu nous présenter Henri Gomez et Carlos Sanchez..

Henri Gomez a commencé par définir le packaging natif.

D’abord la définition d’un livrable : un livrable est un artefact utilisable par les équipes en aval, c’est-à-dire les équipes de production. Jar, War, Zip ne sont pas des livrables car ils ne sont pas directement utilisables.

Avant de créer un livrable, il faut se poser un certain nombre de questions :

• Gestion des pré-requis
• Cycle de vie (mise à jour, suppression)
• Quid du déploiement
• Localisation dans le FileSystem (FHS ? règles ?)
• Les droits d’exécution et accès dans le FileSystem

A coté de ça, le packaging natif est une sorte de livrable très souvent utilisé par les équipes de productions. C’est le cœur de la pile applicative des OS type Unix. Il permet la gestion des dépendances, la mise à jour automatique ou sélective. Les formats les plus connus sont RPM pour Redhat, DEB pour Debian et PKG pour Solaris.

Qu’est qu’un package ?

C’est un fichier avec des données (fichiers de configuration par exemple) et des programmes (Tomcat, code de l’application, etc). C’est du code exécuté lors de l’installation, la mise à jour ou la suppression du package

Il y a des points communs avec Maven :

• Construction par DSL connu par les Ops (simple, quelques macros, appuyé par le Shell)
• Gestion des dépendances pour la construction mais aussi pour l’exécution
• Dépôt de package (Nexus et Artifactory peuvent servir de dépôt)
• Mise à jour automatique ou contrôlée

Le package offre différentes possibilités qu’on peut établir lors de la construction du RPM avec hook de pre-install et post-install ou pre-uninstall et post-uninstall.

Le hook de post-install peut par exemple être utiliser, après déploiement, pour activer des services. Alors que le hook de pre-uninstall peut servir à arrêter correctement l’application et nettoyer le système.

Il permet la déclaration du contenu (droit d’accès, paramètre de la mise à jour des fichiers de config …) et offre un historique !

Le packaging natif offre une grosse autonomie car un package est auto-suffisant, il permet par exemple la mise en place des comptes utilisateurs d’éxecution et il permet un contrôle total sur le cycle de vie avec les hooks par exemple en effectuant le lancement automatique de programmes annexes comme l’analyse des logs !

C’est un système d’installation automatisé et déterministe donc réplicable (peut être utilisé par les logiciels Puppet ou chef)

Puppet était d’ailleurs le sujet de la 2^ème partie de la soirée présentée par Carlos Sanchez auquel je n’ai pu assisté.

Si cela vous a intéressé vous pouvez aller voir les videos des deux présentation ici http://www.parleys.com/#st=5&sl=0&id=2979 et la http://www.parleys.com/#st=5&sl=0&id=2980

Henri Gomez fourni une « forge » avec l’ensemble des packages nécessaires pour se mettre en mode DevOps : https://github.com/hgomez/devops-incubator

Quelques liens sur DevOps : Un twitter parodique excellent, http://devops.com/ ou encore Un article du Touilleur

• 

Cette présentation a été faite à Paris lors de la What’s Next 2011 par Jevgeni Kabanov qui est fondateur et directeur technique de ZeroTurnaround.

C’est aussi l’homme qui parle plus vite que son ombre ce qui rendait la présentation assez difficile à suivre

Derrière la JVM dans l’architecture même de nos ordinateurs, le problème vient des données et notamment de la mémoire. La gestion de la mémoire par la JVM est bien plus complexe que ce que le développeur voit. C’est pour cette raison que beaucoup de hacks intelligents ne fonctionne pas.

Il présente le cœur (core)  d’un processeur qui se partagerait la mémoire sous forme d’une classe Java. Un core est une boucle infinie qui prend les instructions, les executent et gére les interruptions. Il utilise de même une classe Java pour représenter un processeur i5, les registres et la mémoire. Les fonctions de cette dernière sont synchronisées.

Ceci veut dire qu’avec nos architectures multicoeurs actuelles tout est synchronisé.

Il présente aussi les caches qui sont associés à un coeur, bien plus performant que la mémoire mais aussi bien plus petit.

Comment le cache fonctionne s’il y a plusieurs coeurs ?

Si la récupération des données en cache est basique (le get), il faut se poser la question du set : doit on écrire directement en mémoire ou non ?

Soit le cache attend un ordre direct avant de reporter ses données en mémoire, soit il place les écritures en mémoire dans une liste d’attente. Il y a différents protocoles qui essayent de trouver la meilleur solution pour associer ce choix et la cohérence des caches.

Malgré ça, il n’est pas sur qu’un thread sur un cœur voit la même chose qu’un autre thread sur un autre cœur. De plus les accès en mémoire sont trop lents.

Au niveau du système d’opération, il y a le paging qui permet d’augmenter la mémoire en mettant une partie de celle-ci sur le disque en fonction de son utilisation. Cependant la lecture sur disque étant extrêmement lente et le garbage collector parcourant très régulièrement l’ensemble des données (heap) du programme, il est parfois préférable en terme de performance de désactiver ce paging système même si on doit être à court de mémoire vive.

Il explique le mot clé Volatile qui garantie la synchronisation d’une variable dans plusieurs threads.  En indiquant que la variable est volatile, on oblige la JVM à rafraîchir son contenu à chaque fois qu’elle est utilisée. Il garantit que les caches sont cohérents. Ainsi chaque thread a accès à la valeur la plus récente de la variable.

D’où la complexité de la mise en place de Volatile au niveau JVM.  La JVM génère la synchronisation par des barrières mémoires.

Il parle ensuite la gestion de la mémoire par la JVM (heap) dont le principal objectif est de gérer les objets vivants (accessible de la « racine ») des objets morts (qui ne sont plus référencés par aucun objet vivant). Les principaux problèmes sont la complexité O(heap) et le fait de devoir stopper l’application.

Il présente différents algorithmes ( Mark and Sweep, Mark Compact, Parallel MC, Concurrent MS ).

Avec Java 7 apparait Garbage First qui sépare la heap en régions ().

Il présente enfin l’algorithme de Garbage Collector encore plus novateur de Azul Zing qui est sans pause.

Une présentation clairement très technique

• 

D’abord toutes les videos sont disponible ici : http://www.frenchsug.org/display/FRSUG/Scrum+Day+France%2C+31+mars+2011

Le jeudi 31 mars, j’étais au centre de conférence de Microsoft à Issy Moulineaux pour assister aux Scrum Day 2011.

La journée a commencée par un bilan des actions du French Scrum User Group et un retour intermédiaire de l’enquête nationale sur l’adoption de l’Agilité. On y apprend qu’il y a un réel engouement au sein des organisations et une satisfaction des utilisateurs mais il reste des problèmes : interaction avec des entités non agiles, choix du bon product owner ou encore mauvaise interprétation des données.

Keynote d’ouverture par Harvey Wheaton,  Studio General Manager de  Supermassive Games.
Ayant un peu d’expérience dans le domaine du jeu vidéo, la présentation m’a tout de suite accrochée. Comment Harvey Wheaton avait-il pu mettre en place les pratiques Agiles dans un cadre aussi complexe, hétéroclite et changeant que le jeu ?
Tout est une histoire d’humains et du développement d’un jeu qui est par nature très “organique” est donc bien adapté à l’agilité. Quand il travaillait chez Electronic Arts, il a découvert que ceux ci utilisaient des méthodes proches de Scrum sans même le savoir. Avec Supermassive Game, Il a décidé de sceller les principes et cette culture de l’agilité d’où le titre de sa présentation “Embedding a scrum culture”.
Le plan de création d’un jeu se base sur 3 périodes différentes : pré-production, production et finalisation. Scrum a été adapté pour être utilisé lors de la production du jeu : des sprints de 2 semaines, des équipes de toutes les disciplines (développeur, graphiste, game designer …), il n’y a pas un seul product owner car tout le monde apporte ses idées, il n’y a qu’un planning physique (grand mur de post-its) et enfin le jeu doit toujours fonctionner !
La plus grosse difficulté est de construire et maintenir le backlog. Avoir un backlog complet, de la bonne taille, avec la bonne priorité est très difficile.
Pour que l’Agilité fonctionne il faut définir une vision, une culture et s’y attacher plutôt que de se reposer sur des processus.

• L’équipe.

Il n’y a pas d’individualité dans une équipe mais seulement l’Equipe. Il faut être flexible, être autonome et volontaire car il y a très peu de hiérarchie (studio executive, senior staff et enfin non senior staff). Les “scrum masters” émergent de l’équipe. Remarque intéressante, il ajoute qu’il y a très peu d’emails échangés au profit d’un dialogue direct et oral.

• Des itérations rapides.

Faire en sorte que les erreurs arrivent rapidement quand le coût est faible. La qualité vient  du nombre d’itérations. Les images valent mieux que le texte.

• Définir le “Done”

Il est difficile de déterminer qu’une tâche est finie dans le cadre d’un jeu video. Il préfère voir ça en terme de fidélité par rapport à l’ensemble des fonctionnalités imaginées. On part de l’étape de prototype pour atteindre l’alpha (pré-version de test du jeu finalisé). Utilisation d’un marqueur (vert ou rouge) de confiance sur l’avancement de chaque user story.

• Ce n’est que du logiciel.

Utilisation de l’intégration continue et mise en place de sprint review. Il y a beaucoup de méthodes empiriques. Il faut savoir écouter et s’adapter. Il y a beaucoup d’expérimentation (Kanban par exemple).

En conclusion, pour Harvey Wheaton, les principes et la culture sont plus importants que des processus rigides et autoritaires.

Pour le reste de la journée, il a fallu faire des choix difficiles parce qu’il y avait toujours au moins 2 conférences intéressantes en parallèle (et certaines se sont retrouvées même trop vite complètes dû à une trop petite salle).

“Quand mon produit est un SI”, Christophe Addinquy, Vidal
J’ai ainsi décidé de suivre la conférence de Christophe Addinquy autour de l’agilité et le SI, “Quand mon produit est un SI”. Il compare d’ailleurs la réalisation d’un produit et la réalisation d’un SI respectivement à gravir une montagne avec différentes étapes et à un jeu d’échecs. La stratégie d’entreprise est sous l’influence du contexte, du positionnement, du marché, des opportunités et de la concurrence. Les marchés et les lignes métiers représentent différents chantiers. L’ensemble des chantiers possibles représente le backlog de l’entreprise. Ils sont alors filtré en fonction de la stratégie de l’entreprise. On arrive alors à une cartographie de l’entreprise et une roadmap. Pourquoi parler de chantier ? Tout simplement parce que le système d’information n’est jamais fini.
Il y a deux types d’approches dans un SI : l’approche progiciel qui va avoir tendance à créer des silos et l’approche urbanisée qui va  s’appuyer sur des sous-systèmes ou des progiciels. C’est les chantiers qui guident les choix techniques pas l’infrastructure. Les briques du SI sont construites au gré des projets en utilisant une approche opportuniste (Yagni, commencer petit, spike/prototype).
On construit sur une urbanisation émergente : pas de plan quinquennal, pas de silos ni de balkanisation. Les composants d’un chantier sont les migrations, les nouvelles fonctionnalités,  l’iso fonctionnalité, l’intégration avec l’existant ou encore la conduite du changement. Il n’y a pas de projets feuilles blanches : on ne peut ignorer l’existant dans un SI.
Un chantier c’est aussi des hommes il faut protéger l’équipe. Il faut préparer le terrain avant un nouveau projet pour qu’il y ait du contenu dans le backlog. Christophe nous parle aussi du besoin de bâtisseurs pour la progression dans la durée et de mercenaires pour les opérations coup de poing.
En conclusion, le développement d’un SI peut être agile en le découpant pour être agile, en ayant une vue globale et en mettant en avant l’équipe.

ScrumMasters, devenez le coach de votre équipe agile, Véronique Messager.
Cette présentation met en avant les personnes et leur interaction dans le succès des projets. Le Scrum master, en particulier, est le garant du cadre mais aussi un leveur d’obstacle et un facilitateur. Il est au service de l’équipe et travaille à sa protection. L’équipe agile ce sont des valeurs et des pratiques collaboratives. L’équipe s’engage sur les résultats, le Scrum master s’engage sur les moyens. En tant que coach, il accompagne une personne ou une équipe en particulier pour trouver les réponses à ses propres questions : quelles soient de natures opérationnelles ou comportementales. Sa matière première est la qualité des relations.
Pour être un bon Scrum master, il faut d’abord avoir une bonne connaissance et gestion de soi avant de s’atteler à la connaissance de l’autre et la gestion des relations. Il faut d’abord se concentrer sur le savoir être.
Les outils du coach sont la synchronisation, l’empathie, l’écoute active, le questionnement ou encore la reformulation. L’ensemble du travail du coach se base sur la confiance.

En étendant la vision, l’objectif est aussi de coacher l’ensemble de l’organisation.

En conclusion, pour être un bon Scrum Master, il faut savoir mettre de coté la technique, (se) faire confiance et surtout développer l’aspect relationnel ainsi que le savoir être (écouter, écouter, écouter).

Le product owner proxy, l’agilité au PMU, Bertrand Dour, AgileGenius.
Pour rappel, le Product Owner a pour rôle de créer la vision du produit ou encore de préparer le backlog du produit. Le PMU étant une organisation complexe et avec peu de communication entre les différents métiers, l’idée a été de créer un product owner proxy afin d’avoir un interlocuteur unique et une gestion des priorités consolidée. Celui-ci avait pour rôle d’être un interlocuteur unique, une gestion des priorités consolidées et une planification de release cohérente. Cependant deux inconvénients apparaissent :
- le manque d’expertise métier qui a été résolu par une implication forte, des échanges directs et la création d’un vocabulaire commun (user story unifiée).
- gestion des priorités entre trois départements : paris hippique, sportif, poker. L’astuce pour résoudre cette difficulté a été de donner des jetons de poker à la stratégie afin de permettre fédération et collaboration (tiens c’était peut être le moment de mettre en pratique le service design).
Il y a eu aussi création d’évènements pour faire des démos aux products owners des différents métiers et à toutes personnes intéressées ainsi que des ateliers de gestion du changement ou de création de user stories.

Bilan sur le product owner proxy.
Avantages : gestion du besoin consolidée, interlocuteur unique
Difficulté : connaissance métier, légitimité, complexité du processus.

Au final, Bertrand Dour conclu qu’il aurait été plus simple de changer la culture de l’entreprise en amont et éviter le classique schéma  “je fais du marketing, je ne m’occupe pas de la réalisation”. Il manque un élément de MOA en dehors du marketing pure.L’agilité a fait ses preuves mais il reste encore beaucoup de sceptique. Il y a une grosse difficulté d’exprimer le besoin quand il y a 3 clients / métiers. Il faudrait que les managers s’intéressent au fonctionnement et pas seulement  aux bénéfices. Il serait intéressant d’avoir des tests d’acceptance plus que des spécifications. Il y a encore un gros travail d’évangélisation à faire en particulier en trouvant des sponsors.

Agile 10 ans après, Laurent Bossavit, Institut agile, référent neutre et indépendant.
Laurent Bossavit commence par un historique de la réalisation de projet informatique en évoquant le sommet autour de la crise du logiciel dans les années 70.
Seulement deux questions ont été réglées : Est-ce que les langages de haut niveau sont efficaces ? est-ce que la programmation doit être online (sur la machine du développeur) ou offline (déporté sur un serveur) ?
Mais par exemple les questions suivantes sont toujours d’actualité : Est ce que la personne qui manage les programmeurs doit aussi être un programmeur ? Comment organiser la séquence d’activité dans un projet ?
Il évoque la théorie de la rupture : risque de disparition d’acteurs dominants pris de vitesse par les nouveaux entrants (Christensen 1997). Il prend l’exemple de la photo numérique et de Polaroid.
L’Agilité serait ainsi une technologie de rupture par rapport au Génie logiciel. Ce dernier privilégie le contrôle et la tracabilité (approche CMMI) alors que le premier privilégie la réactivité et l’exploitation du talent. Il compare ainsi le génie logiciel à la musique classique et l’agilité au jazz.
Dans le mouvement Agile, il insiste sur l’apport de différents éléments comme la psychologie.
Il faut aussi différentier pratique et vision. Enfin il y a aussi une expansion des préoccupations du mouvement Agile .
Conclusion de cette présentation par Laurent Bossavit, il faut :
- enterré les certifications
- proposer une vrai alternative au contrat au forfait
- mieux expliquer le contenu et évacuer l’image d’Épinal
- plus de recherche empirique et de formation
- concurrencer le génie logiciel.

Avis personnel : je ne comprends pas la définition du génie logiciel en tant que vision qui s’oppose à l’agilité mais la discussion est ouverte.

Ken Schwaber qui a définit les versions initiales du processus de développement Scrum avec Jeff Sutherland nous offre la keynote de clôture de ce ScrumDay 2011.

Il revient sur l’agilité et sa nécessité du à une concurrence de plus en plus globale, des clients de plus en plus exigeant et des produits de plus en plus complexe.
L’agilité est plus basée sur l’empirisme que sur des prédictions. Scrum est proche d’un développement type Waterfall mais en beaucoup plus court avec des équipes qui s’auto organise avec des compétences fonctionnelles diverses et très efficace. Scrum est un framework pour adresser des problèmes complexes et développer des produits à haute valeur.

Utiliser Scrum ne fait pas de vous quelqu’un d’agile (ou une organisation).
Il met en avant la mise en place de Scrum(But) lorsqu’une organisation commence à utiliser Scrum et qu’elle ne peut mettre en place l’ensemble des pratiques Scrum. . Il utilise le terme de ScrumBut pour définir une zone entre l’application de Scrum et un développement réellement Agile.

Cependant l’introduction de Scrum(But) a un impact sur l’entreprise :

• le management empirique remplace la prédiction
• la transparence est une valeur qui finit par remplacer la politique
• l’autorité redescend dans l’organisation
• plus d’attention et de choix difficiles sont nécessaires.

Ken Schwaber parle ensuite de l’élaboration de tout un modèle pour faciliter la mise en place de l’agilité au sein de l’organisation construit autour de Scrum. Il en profite pour faire un peu de publicité sur des formations

• 

Avoir son service sur mobile est devenu presque obligatoire vu le nombre en constante augmentation de personnes ayant un smartphone.

Le premier réflexe est de se lancer dans une application native. Cependant vu la disparité des plateformes (Iphone, Android, BlackBerry, Windows Mobile …), ce choix est actuellement extrêmement coûteux si vous voulez atteindre le plus grand panel de clients.

Or je pense que la plupart des applications natives sont souvent un portage simple de services en ligne. Il existe d’ailleurs des moyens d’afficher une page web dans un simple conteneur natif (c’était la logique des tous premiers iPhone). A coté de ça, les navigateurs embarqués sur les smartphones sont souvent très avancés et gèrent aussi bien Javascript que le standard W3C qui monte, c’est à dire HTML 5 !

De nombreux projets commerciaux ou open source, se sont d’ailleurs lancés sur le sujet afin d’offrir des solutions portables sur n’importe quel navigateur embarqué.

Certains sont simplement une librairie Javascript permettant de gérer les évènements tactiles (http://xuijs.com/docs/event par exemple). D’autres se chargent de donner un large accès aux API natives du framework (http://www.phonegap.com/about par exemple).
Suivant la nature du besoin, vous ferez glisser votre choix entre ces deux types.

Pour le service que je comptais faire passer en version mobile, le choix s’est porté sur des frameworks situés au milieu en particulier Sencha Touch et JQuery Mobile. Tous les deux se basent sur HTML 5 pour faciliter la version mobile.

Sencha Touch est assez avancé dans ses possibilités (surtout qu’il est possible de le combiner avec PhoneGap) mais c’est un framework nécessitant une réelle prise en main. Au contraire, JQuery Mobile permet de facilement passer son site en version mobile. De plus la réputation de la librairie JQuery et sa connaissance répandue permettent de travailler rapidement avec JQuery Mobile.

Voila le résultat d’un prototype obtenu en quelques jours. Le design est encore perfectible mais nous avions le cœur du service largement utilisable sur un mobile.

Pour moi, c’est vraiment une solution efficace pour un coût tout à fait raisonnable afin de porter son service sur mobile.

Pleins d’autres exemples concrets sur ce site : http://www.jqmgallery.com/

• 

En ce lundi 28 février, j’étais avec quelques autres membres d’Objet Direct Paris au 3 ans du Paris Java User Group sur le thème « Siffler en travaillant ».

Personnellement cela fait maintenant plus d’un an que je vais assez régulièrement au Paris JUG qui par sa communauté et ses présentations m’ont déjà apporté beaucoup. J’étais donc parti sur le menu complet : les présentations entre 18h et 22h30 ainsi que l’after pour les personnes qui avaient réussi à s’inscrire.
J’arrive donc à la cité universitaire un peu après 17h30. Déjà on voit qu’ils ont fait les choses en grand vu la qualité de l’amphithéâtre avec deux ailes réservées pour les partenaires (Objet Direct y était bien sur représenté).

La soirée se lance vers 18h avec une intro complètement décalée par les organisateurs déguisé en blanche neige et les sept nains. Antonio Goncalves nous explique qu’il en est venu à ce thème de soirée en regardant Blanche Neige et se demande si nous aussi, développeur, nous venions au travail en sifflant et avec le sourire aux lèvres.

1ère présentation : Le télétravail par Nicole Turbé-Suetens
Pour ceux qui ne connaissent pas les conférences TED, Nicole Turbé-Suetens a déjà fait cette très intéressante présentation au TEDxParis 2011 (la vidéo ici : http://www.tedxparis.com/nicole-turbe-suetens-teletravailler-autrement).
Elle part du constat que la région parisienne (entre autre) arrive à saturation niveau transports. Or le travail d’un ingénieur (parmi tant d’autres) se passe principalement derrière un écran ce qui pourrait se faire de beaucoup d’endroits en dehors du lieu de travail. Le stress lié aux déplacements jusqu’au lieu de travail ont pour conséquence de nombreux jours d’absence, une forte consommation de psychotropes et des troubles psychosociologiques au travail.
Pour elle la vraie solution est, un autre mode d’organisation du travail, le télétravail. Elle présente alors les possibilités et surtout l’état des lieux. Mais il y a encore beaucoup de travail tant au niveau droit que du management direct (ou de proximité). Le manque de confiance, le besoin de contrôle et la pression qui s’exerce aussi sur ces manageurs représente souvent le plus gros frein.
Elle parle aussi des possibilités de Co-working comme à la Cantine qui offre les possibilités de rencontrer d’autres personnes, de partager !

2ème présentation : L’indépendance par Mathilde Lemée
http://www.parisjug.org/xwiki/bin/download/Meeting/20110228/freelance.pdf
Mathilde est une personne qu’on a l’habitude de croiser au paris jug avec son homme. Pour la petite histoire, je la connais depuis longtemps vu qu’elle a la même formation que moi (la FIIFO qu’elle n’a pas nommée !!! ). Elle vient ici nous parler de l’indépendance en tant que freelance. L’indépendance est pour Mathilde nécessite juste de faire un choix et offre de nombreuses possibilités : gagner plus bien sur mais aussi négocier plus facilement afin d’améliorer ses conditions de travail (télétravail par exemple ).
Elle insiste sur le fait que rien nous empêche de devenir freelance et qu’il n’est pas obligé d’attendre une grande expérience ou les bonnes conditions. C’est aussi la possibilité de vivre l’inter contrat différemment par exemple pour lancer des projets personnel ou encore partir autour du monde !

3ème présentation : Réinventer l’indépendance, donner du sens au collectif par Oliver Jouan
Membre de Port Parallèle, il est venu présenter cette coopérative de créateurs d’entreprise et tous avantages que cette structure peut représenter pour amorcer son entreprise. Pour lui c’est un excellent moyen de concilier l’indépendance et le collectif.
Bon j’avoue pas très concentré pour cette présentation, je pense que le mieux est d’aller voir le site : http://portparallele.com/

4ème présentation : Office code par Catherine Gall
Catherine Gall nous ramène sur les conditions de travail en entreprise notamment dans l’organisation de nos bureaux. L’ensemble de la présentation s’articule autour d’un décryptage des codes culturels liés à l’organisation suivant quatre éléments et deux extrêmes:
- La distance hiérarchique avec l’orientation autocratique ou consultative
- Le degré d’invidualisme ou de collectivisme
- La motivation basée sur la compétition ou la collaboration
- L’incertitude ou l’ambiguïté
Elle met ces quatres variables dans le contexte de différents pays (France, Anglosaxons, pays nordiques, Allemagne)
Elle parle aussi de la culture organisationnelle d’une entreprise (par exemple la différence entre les bureaux d’Intel et de Google) et son adaptation lors de la création d’une filiale à l’étranger.

5ème présentation : Getting Thing Done par Emmanuel Bernard
Bon vu que je connaissais déjà bien cette méthode je me suis permis de faire des commentaires sur twitter. C’est une méthode d’organisation pour gérer ces tâches journalières (au travail mais aussi en dehors). Le but principal est de ne pas se perdre dans une myriade de tâches qui vont venir parasiter notre concentration en mettant en place un « workflow ». C’est justement ce que je regrette dans cette méthode : la lourdeur du processus ne conviendra pas à la majorité des développeurs. Je pense que cette métode s’adresse plus à des managers. Il faut aussi trouver les bons outils numériques pour pouvoir la mettre en place.
Au final je conseille d’aller voir la méthode Zen To Done qui reprend GTD qui l’allège tout en gardant les idées fortes. http://zenhabits.net/zen-to-done-ztd-the-ultimate-simple-productivity-system/

6ème présentation : Réflexion sur le métier de développeur par Didier Girard
http://www.parisjug.org/xwiki/bin/download/Meeting/20110228/developpeurs.pdf
Ah enfin le show de Didier Girard arrive enfin. Comme à son habitude, sa présentation est entrainante et vivante ! Il nous pose la question de notre carrière et de notre avenir en tant que développeur. Pour lui, un développeur est en béta permanente. Pour progresser, il doit allier technicité, carrière et entrepreneuriat. Il doit aussi gérer son employabilité par rapport à une techno : ne pas se lancer trop tôt ni attendre la fin de la vague.
Il insiste qu’il n’y a aucune connaissance valable sans réelle pratique. Pour lui, un manager qui ne code pas, c’est l’opposé d’un chef d’un grand restaurant, c’est un manager chez MacDo
Il met aussi en parallèle 4 niveaux pour un développeur Junior, Confirmé, Sénior, Cadre avec respectivement 4 niveaux de compétence Candide, Autonome, Référent, Solide (sa réputation le précède).
Enfin il reprend un de ces slides favoris où il montre qu’actuellement un développeur peut communiquer directement avec le client en éliminant les intermédiaires (sysadmin, commercial, marketing et même manager)

7ème présentation : Devops par Patrick Debois
Cette 7ème présentation en anglais va un peu à l’opposé de celle de Didier Gérard en remettant en place le contexte du développeur dans l’entreprise et notamment leur relation avec les opérationnels.
Quelque soit le super framework, le super langage, le cloud, etc, il arrive souvent que ca ne marche pas. Les premiers en ligne sont alors les opérationnels (« the IT guys »). Il tient à remettre en question la mentalité de « rock star » de certains développeurs. Le développement n’a aucune valeur tant qu’il n’est pas en production. Il faut travailler en collaboration avec l’ensemble des équipes, faciliter le déploiement, fournir des métriques mais surtout utiliser les connaissances de tout le monde.
Mention spéciale sur la mise en forme de la présentation remplie d’humour et très bien choisie (la réalisation d’un projet informatique était comparé à un barbecue).

8ème présentation : Mettre une application sur Android Market avant la fin de la soirée par Stéphane Jacquemain
Deux jeunes viennent présenter leur belle histoire sur les téléphones Android. Un soir ils ont décidé de tester le développement Android et en profiter pour sortir leur première application Android. Résultat 3000 téléchargements ! Ils ont alors continué en développant d’autres petites applications (Tazer, corne de brume pour le mondial, briquet ..) . J’admire d’ailleurs cette pratique d’apprendre les fonctionnalités par la pratique et surtout en développant une vrai application à chaque fois !
Le nombre de téléchargement grandissant (des millions au total sur l’ensemble des applications) ils ont décidé d’y mettre de la pub et la encore le succès n’a pas manqué !
Bon juste un petit bémol, j’ai eu la chance de discuter avec eux et certaines de leurs applications leur ont pris beaucoup de temps de développement (oui un briquet en OpenGL ca ne se fait pas en une soirée )

9ème présentation : Du bancaire au Nabaztag par Julien Cheype
Julien Cheype, ancien développeur dans le domaine financier, a changé complètement de sujet pour remettre à jour l’architecture du Nabaztag, le lapin communiquant. Il explique son approche destinée à simplifier l’architecture logiciel au cas par cas et par itération tout en répondant aux besoins très spécifiques du projet !
Au final je trouve qu’il empile beaucoup de framework mais je pense que c’est inévitable
actuellement !

Ensuite pour ceux qui avaient pu réserver une place, la soirée c’est terminé par un tour de Paris dans un bus dansant, du champagne, une photo devant la tour Eiffel et le classique diner au Vavin.
Les irréductibles ont même passés la nuit au Falstaff (un membre émérite d’Objet Direct aurait même oublié de rentrer chez lui )

Voila pour ce retour accéléré des trois ans du Paris JUG !
Si vous voulez plus d’info cherchez le tag #parisjug2011 sur twitter !

• 

Le 11 novembre 2010, le Paris JUG mettait en avant les moteurs de règles.

Au programme quatre présentations sur un sujet qui ne me parlait pas !

La première présentation nommée « Business Rules Management System », présentée par Emmanuel Bonnet de Genigraph, me permet d’ailleurs de rentrer dans le sujet et comprendre l’intérêt .
Les moteurs de règles ou Business Rules Management System permettent d’écrire, d’exécuter et de gérer (cycle de vie, version …) un ensemble de règles métiers.
Une règle métier ressemble à cela : SI [condition] (ET|OU [autres condtions]) alors [faire telle action]. Par exemple : Si le conducteur n’a pas eu d’accident depuis 3 ans alors appliquer 15% de réduction.

Et la vous me lisez en vous demandant si c’est pas un trop une soirée sur des IF THEN ELSE .. je vous comprends moi aussi j’ai failli me poser la question.

En fait le problème n’est pas dans l’élément unique mais dans l’assemblage d’un très très grand nombre de ces règles ! Il y a un moteur d’inférence pour exécuter les règles métiers. Le BRMS permet d’externaliser, d’expliciter et de gérer ces règles.
Par exemple j’ai une application que je veux concevoir dont une partie que je veux externaliser ou déléguer à des experts du domaine ou pouvoir modifier régulièrement. Par exemple un métier avec de nombreuses offres commerciales régulières (par exemple fournisseur de services mobiles).
On peut alors utiliser un BRMS avec la logique technique de l’application qui englobe une logique métier que l’on veut extraire. L’intérêt est de pouvoir modifier les règles métiers sans refaire un cycle de livraison du socle technique.

Expliciter l’application permet de rendre le code :

• Compréhensible : métier visible et lisible (langage usuel + grammaire alors un traitement qui s’applique sur un concept)
• Modifiable sans avoir besoin à des informaticiens
• Traçable : on peut relire une séquence d’une décision (les conditions menant à une action)

On peut donc récupérer au mieux le savoir du client et l’impliquer dans le projet.

Un moteur de règle exécute les règles de fait, les optimiser et garantit la cohérence. Il est fait pour optimiser beaucoup de faits et beaucoup de règles (Voir algorithme de RETE). Il y a aussi la présence d’outil de monitoring de règles, d’un workflow pour les règles et ainsi mettre en place une logique de décisions.
Les règles peuvent être insérées suivant différents formats : texte, tableur type excel (2 parties : condition et action) ou directement Eclipse.

Les deux plus gros acteurs sont JRules et Drools.

La 2ème intervention de Laurent Magnin – In Fine présente un ensemble de cas concrets et met en avant la formalisation de l’expertise, le pilotage et les possibilité de prises de décisions. Il commence aussi à parler de système expert.

Pour la 3ème présentation, l’intervenant, Daniel Selman, nous vient directement d’IBM et nous présente donc l’outil ILOG JRules BRMS.
Il insiste sur le fait quand un projet Les besoins donc les spécifications changent. Il faut s’y attendre et donc désigner pour !
Un BRMS comme ILOG JRules permet justement cette gestion du changement : qui a demandé un changement ? qu’est ce qui a changé ? Qui a fait le changement ? qu’est ce qui valide le changement ?
ILOG permet aussi d’éxecuter différentes configurations de règles métier pour permettre, par exemple, de gérer en parallèle un serveur de production et de tests.
L’intervenant nous a fait une démo en direct du produit, par exemple du client web pour les experts métiers afin d’éditer les règles métiers.

La 4ème et dernière présentation par Geoffrey de Smet a été pour moi la plus intéressante car elle a mis en valeur l’intérêt des systèmes experts. Oui car l’intérêt des systèmes experts est remonté à ma mémoire (ahh les études ça commence à dater) résoudre ces problèmes si complexes qu’ils sont parfois classés dans le domaine de l’intelligence artificielle.
L’intervenant expose 3 problèmes de planning NP Complexe : un petit problème de rangement de colis dans une voiture dont la place est contrainte, un planning de travail dans un hôpital et la gestion des malades dans les lits d’hôpitaux. C’est sur ce dernier exemple qu’il insiste en montrant qu’à l’échelle d’un grand hôpital, l’algorithme qui donne la réponse parfaite n’existe pas ! Le nombre de combinaison est tout simplement infinie. La solution est donc de partir sur un algorithme déterministe (temps fixe, facile à implémenter) puis d’utiliser des méta-heuristique en « bougeant les éléments » petit à petit (plus on a du temps, meilleure est la solution). Il suffit de gérer les optimum locaux. C’est ce que fait Drools Planner !

Voila pour le compte rendu de la soirée.

Les présentations sont sur le bas de la page du Paris JUG.

• 

Une très longue discussion autour de la JVM et de l’open source anime actuellement la liste de diffusion des Cast Codeurs.

Suite au rachat de Sun par Oracle, il y a beaucoup de mouvements et parfois les directions sont sujettes à doute sur l’avenir de Java notamment dans sa composante Open Source.
Le procès d’Oracle contre Google a remis au premier plan un des éléments peu connus de Java : celui-ci est « presque » libre et surtout un gros flou de licence entoure la JVM.

Revenons en arrière.

Déjà il existe plusieurs Machine Virtuelle Java comme l’indique cette liste.
Les JVM commerciales les plus connues sont celle de Microsoft (stoppée en 2009), celle de Sun (rachetée par Oracle), celle d’IBM, celle de BEA (rachetée par Oracle).
On voit que le nombre d’acteurs a grandement diminué.

En mai 2005, la fondation Apache annonce le lancement du projet Harmony afin de créer une implémentation de Java libre donc une JVM libre.
Seul problème pour que cette implémentation soit valide il faut qu’elle passe le Technology Compatibility Kit ou TCK qui lui n’est pas libre. Voila vous avez touché le « presque » libre de Java
La fondation Apache lance principalement Harmony pour essayer de faire plier Sun.

Le 13 novembre 2006, Sun annonce le passage de Java, c’est-à-dire le JDK (JRE et outils de développement) et les environnements Java EE (déjà sous licence CDDL) et Java ME sous licence GPL. En mai 2007, Sun publie effectivement OpenJDK sous licence libre.

En 2009, Android débarque avec sa JVM très spécifique nommée Dalvik qui est basé en partie sur Harmony.
Et voila qu’on arrive en aout 2010 où Oracle (qui a mangé Sun pour les deux du fond qui ne suivent pas ) attaque Google pour violation de brevet sur cette JVM.
Déjà que le rachat de Sun par Oracle avait provoqué des doutes dans la communauté, c’est un très mauvais présage pour l’écosystème dit libre qu’est Java car sa fondation (la JVM) n’est pas libre !

Ensuite succession d’évènement :

• IBM quitte le projet Harmony
• IBM rejoint OpenJDK
• Apple décide de ne plus continuer sur sa JVM
• Apache fait la gueule et menace de quitter le JCP
• Apple rejoint OpenJDK

En quelques semaines, l’échiquier a tellement bougé que je ne vais pas faire de pronostic. Cependant la tendance semble être au soutien des gros acteurs commerciaux sur OpenJDK. Malheureusement le fait que la communauté pure du logiciel libre ne suive pas complètement laisse planer le doute.

Pour plus d’information à la fois politique et technique lisez les messages du groupe Cast Codeurs

Des liens en vrac :
http://www.theregister.co.uk/2010/10/25/doug_lea_oracle_jcp_stuffing/
http://www.theserverside.com/news/2240024154/The-Oracle-Lawsuit-Will-End-with-Google-Owning-Java
https://blogs.apache.org/foundation/entry/statement_by_the_asf_board1
http://www.apache.org/jcp/sunopenletter.html

MIS à JOUR :
Allez ca bouge :
http://www.jroller.com/scolebourne/entry/java_se_7_and_8
http://www.jroller.com/scolebourne/entry/oracle_replies_to_the_asf
http://www.zdnet.fr/actualites/java-dialogue-de-sourds-entre-oracle-et-la-fondation-apache-39756135.htm#xtor=RSS-8

• 

Ce compte-rendu ne contient que  la première partie. Je n’ai malheureusement pu assister qu’à celle-ci.

Présentée par Olivier Mallassi et Michael Figuière, elle nous a offerte une vision globale du mouvement N(ot)O(nly)SQL.

Ils ont commencé par répondre aux grandes questions :

• La fin du langage SQL ? non
• La fin des transactions (ACID) ? Oui et non on parle plus d’un relâchement
• La fin des SGBDR ? Non, ce n’est pas un remplacement

NoSQL est un domaine d’innovation, un écosystème riche et complexe.

L’idée est de répondre à des besoins émergents notamment chez les gros acteurs du web :

• plus de disponibilité (notamment au niveau de l’écriture)
• plus de souplesse des schémas/structures
• plus d’élasticité de l’infrastructure
• un volume de données croissant

Le cloud démocratise des solutions spécifiques de stockages capable de monter en puissance sans explosion des coûts.

Deux grands exemples :

• Google : big table et algorithme map/reduce : besoin massif en lecture, permet l’aggrégation de gros volumes de données
• Amazon : Dynamo : besoin de débits et d’une disponibilité important en écriture. Problématique différente en fonction des phases d’achat : (fill cart – checkout – payment) disponibilité en écriture, clé/valeur suffisant puis (process order – prepare – send) reporting, asynchrone

NoSQL est principalement un marché OpenSource : Cassandre, MongoDB, Riak, Neo4J …

On y retrouve plusieurs catégories :

• Clé/valeur – Voldemort, Riak
• Document – fichier XML avec id – MongoDB, CouchDB
• Orienté colonne – Cassandra
• Graphe – Neo4J (limite de la modélisation relationnelle)

NoSQL est surtout un changement de paradigme par rapport à SQL :

1. table de hachage distribuée afin d’assurer une répartition uniforme des objets dans les clusters
2. Relâchement d’ACID

Les technologies « NoSQL »  base leur consistance ou leur « consistance éventuelle » sur la formule :

Le nombre de réponses de lecture à attendre (R) ajouté au nombre de confirmation d’écriture à attendre (W) doit être supérieur au nombre de réplicas (ou serveur) (N).
En faisant varier R et W, on peut alors paramétrer si on cherche à optimiser la lecture ou l’écriture.

En ce qui concerne les propriétés ACID, les données ne sont plus co-localisées et globalement on perd l’atomicité.

Par contre les avantages sont bien présents !

• Performance, débit en écriture
• Stocker et manipuler de plus gros volumes de données
• Disponibilité
• Élasticité des infrastructure de stockage
• Souplesse de modélisation

Mais les problèmes aussi :

• faible modélisation et requetage de la donnée.
• Des problématiques qui remontent au niveau Applicatif (gestion des transaction par exemple)
• Changement au niveau de l’exploitation
• La sécurité pratiquement inexistante

Il faut aussi rappeler que toute la problématique NoSQL vs Base de données standards relationnelles tourne autour du théorème de CAP dont les propriétés sont :

• Cohérence forte: tous les clients voient le même point de vue, même en présence de mises à jour
• Haute disponibilité: tous les clients peuvent trouver une réplique des données, même en présence d’échecs
• Partage de tolérance: les propriétés du système tiennent même lorsque le système est partitionné

Il est uniquement possible d’avoir 2 de ces propriétés sur une même technologie.

L’avenir de NoSQL est bien sur incertain, aucun des présentateurs ne s’aventure à faire des pronostics pour dans 5 ans et insistent que ce sont des solutions très spécifiques adaptées à un besoin bien particulier.
De plus il existe aussi des solutions d’architecture type Event Sourcing ou CQRS qui permettent à une solution SQL standard de répondre mieux aux besoins en performance.

Pour rappel, Objet Direct avait déjà fait une petite introduction sur NoSQL.

• 

Si Google Web Toolkit est un excellent framework Web, il souffre d’un manque flagrant d’éléments graphiques et, bien qu’il existe des bibliothèques comme gwt-incubator, il est parfois très intéressant d’utiliser des frameworks bien plus complets se basant sur GWT. Suite au changement de licence de ExtJS et la fin de GWT Ext, on retrouve maintenant deux frameworks au dessus de GWT 2.0 : SmartGWT et GXT. SmartGWT est un wrapper de la librairie Javascript SmartClient vers GWT alors que GXT est une réelle surcouche à GWT.

La démo de GXT

La démo de SmartGWT

J’ai l’occasion en ce moment de travailler sur GXT qui a été choisi par le client pour la migration de son application de GWT 1.5 + GWT Ext (devenu donc obsolète et non maintenu) vers GWT 2.0 et GXT. J’ai donc pu découvrir le code et l’architecture de GXT. A coté de ça, je suis allé comment fonctionnait SmartGWT et parcouru les différentes discussions sur internet.

Le choix entre ces deux frameworks est une étape cruciale et assez difficile. Les deux ont leurs détracteurs et leurs défenseurs.

Certaines personnes défendent même l’utilisation seule de GWT 2. Ces deux frameworks se marient d’ailleurs très mal avec le nouveau UIBinder. Cependant, comme le fait remarquer très justement un des contributeurs de SmartGWT, il faudrait plusieurs mois pour recréer les widgets qu’ils offrent.

La principale différence entre ces deux framework GWT est que GXT est purement Java et donc rentre dans la logique complète de compilation java en javascript de GWT alors que SmartGWT est un wrapper. C’est d’ailleurs cet élément qui amène le plus de détracteurs à celui-ci : lenteur, lourdeur du chargement initial, quid d’un changement de licence chez SmartClient – la librairie Javascript encapsulée, difficulté à étendre les classes pour répondre à des besoins particuliers… Google Web Toolkit ne peut pas optimiser le code javascript. Les contributeurs de SmartGWT plutôt actifs se défendent avec vigueur sur ces points

GXT serait lui moins complet et moins configurable sur l’apparence. D’après ce que j’ai pu voir en parcourant leurs exemples, je pense que c’est configurable avec l’utilisation de Template ()voir un très bon exemple ici)qui est un mécanisme très intéressant. En parcourant les exemples j’ai vu qu’il était possible de « templater » le rendu par exemple une liste pour créer un browser d’image. Je trouve le principe simple et bien flexible ! GXT est écrit en Java/GWT contrairement aux nombreux wrapper Javascript (SmartGWT en tête). Ainsi la compilation n’inoculera que les ressources nécessaires, le débogage se fait en java y compris dans les composants, l’extension de composant est beaucoup plus naturelle et se fait en java.
Cependant tout n’est pas rose sur GXT. D’abord le framework souffre d’un énorme problème au niveau de sa documentation. Si rentrer dans la logique de l’architecture n’est pas d’une complexité insurmontable, il va falloir se débrouiller avec la Javadoc et les exemples finalement pas si nombreux et complets. Pour moi, c’est clairement le point noir de GXT. Ensuite il existe des bugs (JSONLoader dont le templating ne sert à rien) et petites choses à savoir (mettre une taille dans une ColumnConfig pour la voir réellement apparaître !) qui font parfois perdre beaucoup de temps.
Ensuite de façon plus idéologique, GXT ne suit pas entièrement la logique de GWT. GXT utilise une logique MVC et non MVP préconisé par les ingénieurs de Google ainsi que des listener et non des handlers qui sont la norme depuis GWT 1.6.
GXT propose comme GWT Ext un manager central des composants graphiques lorsqu’ils sont référencés par un ID. Cependant c’est parfois difficile à utiliser car ils ne sont réellement référencés dans le manager que lorsqu’ils ont été rendu graphiquement (et pas simplement ajouté dans le constructeur). Par exemple les tabs items ne sont rendus que lorsque l’utilisateur clique sur les onglets correspondant.

Il faut aussi évoquer les problèmes de licences. Si SmartGWT se base sur SmartClient est donc hérite d’une licence LGPL. GXT est lui sous licence GNU GPL V3. Il faudra payer une licence si vous voulez utilisez GXT pour vendre un produit propriétaire ou si vous voulez un support actif de Sencha (l’entreprise derrière GXT).

Dans tous les cas, ces deux frameworks sont impressionnants et confirme l’intérêt porté à GWT ainsi que ces possibilités. La logique programmation en fait des frameworks relativement facile à appréhender (widget, layout, event) et le full Java permet d’être très productif. C’est encore plus vrai pour une personne ayant déjà une bonne expérience des clients lourds type Swing.

N’ayant pu creuser SmartGWT, je ne ferais pas de conseils définitifs. Cependant GXT est sûrement le meilleur choix pour des projets étant toujours sur GWT Ext.

Remarques additionnelle :
- SmartGWT est développé par le développeur de feu GWT Ext
- Il existe une autre librairie très intéressante : gwt-mosaic. Elle aussi en full Gwt.
- Il existe aussi la librairie Vaadin, qui prend aussi en charge la partie serveur.

•