Sami Jaber a publié une vidéo de démonstration du mode OOPHM de GWT 2.0.
OOPHM est l’acronyme de « Out Of Process Hosted Mode », ce mode va permettre d’exécuter le mode Hosted dans un navigateur classique simplement équipé d’un plugin pour communiquer avec la JVM.
En ce moment je travaille sur des tests de performance d’une application GWT.
Comme d’habitude au petit déjeuner je consulte mon newsreader et je tombe sur cette annonce de l’équipe Google.
Le Debug Panel permet d’analyser finement les performances d’une application GWT vu du client. A commencer par de lancement de l’application : temps passé à télécharger les scripts, temps passé dans le onModuleLoad.
Cet outil permet également de écomposer les appels de services RPC : temps de sérialisation , temps passé à poster les donnés vers le serveur, temps de receptin des données en retour, temps de désérialisation et durée de mise à jour de l’interface.
C’est reparti avec les articles qui ont retenu mon attention cette semaine.
Versioning des Services REST.
Sur le Blog Octo, Benjamin Magan nous propose une stratégie pour le versioning des Services REST.
La technique proposée est élégante et repose sur la négociation du contenu et l’entête « Content-Type ». Le client indique à l’aide cet entête, non seulement le format de représentation des données (XML, JSON, …) mais aussi la version du service qu’il utilise.
De cette manière, l’URL reste inchangée ce qui est important avec des services REST.
La vélocité des Bugs Alexandre Boutin nous explique sa vision au sujet de la comptabilisation des bugs et des story non fonctionnelles dans la vélocité de l’équipe.
Pour Alexandre, il faut compter les story non fonctionnelles car elles apportent de la valeur en terme de productivité, performance ou encore qualité. Par contre il considère que les corrections de bugs n’apportent pas de valeur et le les comptabilise donc pas. Dans les commentaires de l’article, Claude Aubry nuance cet avis dans les commentaires en proposant de comptabiliser les corrections de manière séparée.
Intégration GWT/Spring Simple
J’en ai rêvé, je m’étais promis de m’y intéresser, il l’a fait
Enfin une solution simpliste pour que Spring instancie les services RPC de GWT et puisse donc y injecter proprement les dépendances et y appliquer les aspects qui vont bient (gestion de transaction, sécurité, …). Merci ! (via onGwt)
Plus de projets en échec en 2008
Sur le blog de Pyxis, Martin Proulx nous présente les statistiques du Standish Group à propos des succès des projets logiciels. En résumé, les chiffres se dégradent avec seulement 32% de projets en succès (délai, couts, périmètre). Il est certain que les méthodes agiles à elles seules ne vont pas permettre de passer à 100% de succès, mais j’en suis convaincu, beaucoup d’entreprises gagneraient à changer une méthode qui perd, à remettre en cause leur organisation et à essayer les méthodes agiles.
Bob Vauter propose en effet un patch qui ajoute une option « -draftCompile » au compilateur GWT, cette option désactive les optimisations qui visent à réduire la taille du JavaScript généré. Bob annonce un gain de l’ordre de 50%, il me tarde de vérifier cela sur un de mes projets.
Cette option sera donc particulièrement adaptée aux tests de déploiement en mode web, le hosted mode restant bien sur à utiliser pour les développements de tous les jours.
Sur le projet que je suis en ce moment, j’ai mis en place trois types de déploiement :
Hosted mode : le plus utilisé pour les développements, il a un temps de démarrage court et permet de recharger les dernières versions des classes sans redémarrer. A moins de bricoler ce mode ne permet pas de tester les éventuelles JSP qui accompagnent les modules GWT.
Serveur léger Jetty : maven permet très facilement de lancer le serveur léger Jetty, cela permet de tester la version compilée et packagée sous forme de war de notre application.
Serveur cible : l’application est packagée sous forme de war et est déployée sur le serveur qui sera utilisé en production.
Je pense que le mode « draftCompile »pourrait nous être utile dans le mode « serveur léger » car dans ce cas les tests sont faits sur la machine locale et la taille du javascript importe peu.
Nouvelle structure de déploiement : les fichiers statiques ne seront plus dans le classpath, mais comme pour les applications classiques ils seront dans la partie « publique » du War.
Passage de Tomcat à Jetty : le serveur par défaut en hosted mode sera maintenant jetty un système de plugins permettra de changer de serveur. Le passage à Jetty accelerera très probablement le démarrage du hosted mode.
Nouvelle gestion d’évènements : La gestion des évènements sera revue et uniformisée entre les différents composants, les Listeners actuels seront dépréciés.
Intégration du DatePicker et du LazyPanel : Ces deux composants passent de l’incubateur au projet principal. Le DatePicker est un assistant à la saisie de date très bien conçu et internationalisé, le LazyPanel permet lui de différer l’initialisation d’un sous ensemble de votre application afin d’accélérer le temps de démarrage.
Optimisation du StringBuilder : l’implémentation actuelle est notamment peu efficace avec InternetExplorer, la prochaine aura des spécificités en fonction du navigateur.
Optimisation du compilateur : comme à chaque version, le compilateur est optimisé et le temps de compilation sera réduit.
Les évolutions suivantes seront intégrées dans les versions ultérieures :
Fragmentation du code généré : Cette fonctionnalité ne sera finalement pas intégrée à la version 1.6, c’est ma déception en ce qui concerne cette version, car avec le temps de compilation, la modularité des applications produites reste un problème important.
Story Of Your Compile (SOYC) : un rapport sur le processus de compilation qui va notamment permettre de savoir quelle quantité de JavaScript est générée par quelle classe.
Après les fragments de GWT 1.6, l’ami Sami nous présente le « Out Of Process Hosted Mode » qui permettra d’exécuter l’application dans le navigateur de votre choix en mode développement et non plus avec l’unique moteur de rendu supporté sur chaque plateforme (Win : IE, Linux : Mozilla, Mac : WebKit).
L’intégration dans les navigateurs se fera à l’aide de plugins qui communiqueron avec la JVM GWT via une socket TCP. A ce stade le javascript se sera pas encore généré et on gardera toujours la possibilité de rentrer en debug dans le code « client ».
Je pense que c’est une très bonne nouvelle pour l’industrialisation des projets GWT, tous les efforts d’outillage autour de maven porteront sur le même produit.
Agilité :Des priorités pour le père noel
Sur QualityStreet, JC applique une méthode agile pour construire la lettre au père noël de ses enfants.
Ca m’a bien fait rire et j’ai ensuite trouvé que l’exemple était très parlant et pouvait servir à expliquer l’intérêt des méthodes agiles.
Technique : GWT va enfin gérer les « grosses » applications
L’ami Sami explore le code source de GWT et y trouve une future fonctionnalité : la possibilité de scinder le javascript en plusieurs fichiers afin d’améliorer la modularité et de limiter le cout de chargement initial.
Un nouveau type d’article sur ce blog : mes lectures du jour. Je vais y présenter les articles qui ont retenu mon attention en essayant de donner mon point de vue si il y a lieu.
Agilité : Compte rendu de Sprint par Claude Aubry [fr] Claude nous parle du compte rendu des bilans de Sprint, afin de fournir l’information aux personnes qui n’étaient pas présentes lors du bilan.
En bonus, Claude fournit son modèle de présentation OpenOffice, merci Claude
Agilité : Explications que la réunion de planification [en]
Mike Cohn répond à la question : « Est il necessaire d’estimer les taches en heures ? »
Il y répond que l’estimation fine du temps necessaire pour chaque tache identifiée à partir des user story candidates est la seule manière d’obtenir un engagement sérieux de l’équipe sur les élements de la backlog qu’elle va réaliser pendant le Sprint.
Technique : mise en place de la réplication Subversion chez Atlassian [en]. Atlassian est l’éditeur d’outils très populaire comme JIRA, l’outil de gestion de taches, confluence un Wiki, Clover (couverture de tests) ou encore Fisheye le client web pour les gestionnaires de source.
Steve Smith nous décrit la mise en place de Subversion dans un contexte distribué, en effet Atlassian est constitué d’équipes réparties sur plusieurs continents et le coté centralisé de l’architecture subversion peut devenir pénalisant. Leur mise en place s’appuie sur la fonctionnalité write-through proxy qui est arrivée avec Subversion 1.5 et qui permet d’utiliser un serveur local comme serveur esclave, ce serveur permet d’accèlerer les opérations de lecture tout en délégant les opérations d’écriture (commit) vers le serveur maître, ce de manière transparente pour le client.
La particularité dans la mise en place effectuée chez Atlassian est que la synchronisation entre les esclaves et le maître est faite de manière asynchrone afin de ne pas trop pénaliser les opérations d’écriture.
Technique : Cuk.ch nous présente Versions : un client Subversion pour MacOS [fr].
Et en profitte pour expliquer clairement ce qu’est Subversion.
Pour ma part je trouve que le tarif de Versions est un peu élevé, j’utilise les plugins eclipse (Subversive ou Subclipse) pour mes taches de développement et la ligne de commande pour les manipulations sur plusieurs projets eclipse.
J’en profitte pour vous annoncer que je vais vous parler un peu plus d’outils Mac dès que mon employeur aura réceptioné mon MacBook Pro
Technique : Déployer une application GWT dans le SpringSource dm Server.
Dans cette série d’articles (N°1, N°2, N°3 à venir) Ben Corrie nous explique comment déployer l‘application exemple de GWT dans le nouveau serveur d’application SpringSource dm Server.
L’article est transposable aux applications qui ne s’appuient pas sur GWT et nous apprend notamment à transformer une dépendance en bundle OSGI et à déployer une application qui s’appuie sur cette dépendance au lieu de l’inclure dans son package.
