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.
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.
