Planet Valtech

Le Paris JUG fête ses deux ans avec une soirée spéciale ! Le Paris JUG est le groupe d’utilisateurs du langage Java qui se retrouve mensuellement à Paris. Cette soirée aura pour thème l’Open Source en France. Les représentants de Obeo, XWiki, Développons en Java, jCaptcha, eXo Platform, jax-doclets, Play! framework serons là pour vous présenter leur [...]

Lors de mon précédent billet, j’avais évoqué le framework Play en montrant comment réaliser un simple Hello World.

J’avais promis d’aller plus loin dans l’étude de ce framework, j’ai en fin de compte traduit l’intégralité du tutoriel présenté sur le site officiel. A travers ce tutoriel, vous pourrez découvrir plus de fonctionnalités de Play, d’apprendre la façon dont il gère la persistence, comment créer des pages complexes, d’ajouter de l’authentification, etc.

Vous pouvez lire ma prose sur mon site developpez.com !

Dr Alistair Cockburn animera une session certifiante ScrumMaster du 22 au 24 février à Paris. Pour les dernières places, le prix a été porté de 2 400 à 1 800 €. La CSM suivante se tiendra en octobre 2010 avec Craig Larman.

Suite à la lecture de Kaban & Scrum- making the most of both (version française),

j'aime bien le principe du diagramme de flux cumulé.





Cela ressemble au burn-up de produit. Appliqué au sprint, ça permet de faire la corrélation entre la vélocité et le temps de cycle.

Il devient très utile d'avoir cette information au niveau des sprints pour évaluer si la durée des sprints est efficace.

La plupart du temps, on définit la durée des sprints de manière très arbitraire en début de projet.
L'information de temps de cycle permettra d'ajuster au mieux cette durée au fil du temps.


A expérimenter !

Dans la suite de "Scrum and XP from the Trenches", aujourd'hui, InfoQ met à la disposition "gratuite" le guide écrit par Henrik Kniberg et Mattias Skarin : Kanban and Scrum - making the most of both

Version originale (.pdf)

Et préfacé par Mary Poppendieck & David Anderson.

Et pour nos amis Francophones, la version traduite par Claude Aubry, Frédéric Faure, Antoine Vernois & Fabrice Aimetti :

Version FR (.pdf)

Et au cas où vous voudriez quand même payer (pour l'imprimer):

Version payante

En voici 2 extraits évocateurs:
"Kanban ou Scrum n'est pas l'objectif final, c'est l'apprentissage continu
qui l'est."

"Le seul véritable échec est de ne pas réussir à apprendre de ses échecs."


J'en profite pour rappeler un excelent article sur le même théme, avec un cas pratique dans l'utilisation du développement logiciel de jeu:
Beyond Scrum: Lean and Kanban for Game Developers écrit par Clinton Keith, paru en nov 2008 et qui ne fait que 11 pages!

Il me reste 20 invitations Google Wave qui ne me servent pas. Si vous en voulez une vous pouvez me la demander sur mail [ at ] philippevoncken [ dot ] com

Suite au communiqué de presse annonçant la sortie de la formation et du séminaire Android publié il y a une semaine, Olivier Penhoat, consultant et formateur chez Valtech Training, a été contacté par l’équipe de BFM. Il a enregistré hier au soir une interview pour l’Atelier Numérique. Celle-ci sera diffusée samedi 30/01 de 16h à [...]

Issy-les-Moulineaux, dans les nouveaux locaux de Microsoft. Une réunion du French SCRUM User Group Le French SCRUM User Group organisait hier soir une conférence avec Ken Schwaber. C’est donc Luc Legardeur, fondateur du SUG français, qui a débuté la séance en remerciant Microsoft et le co-créateur de Scrum, Ken Schawber d’être passé. Il a annoncé que Ken va [...]

"Un atelier XP Game est programmé le mercredi 3 février, de 17h45 à 20h.
L'atelier sera animé par David Brocard et Thierry Cros.
Il reste des places.



XP Game est un atelier de simulation de quelques itérations eXtreme Programming. Cela permet surtout (mais pas seulement !) aux développeurs d'être sensibilisé vis-à-vis des coûts de développement, de leurs estimations et de mieux comprendre les droits et responsabilité de chacun (client/développeurs).

Tout cela se passe à la maison des associations, au premier étage.
Si vous rencontrez des difficultés avec la réservation Google Agenda, envoyer directement un mail :

* XP Game
"

Ca fait quelques semaines que j'ai installé, au travail, le navigateur Web Google Chrome sur ma distribution Linux Ubuntu.

Je l'utilise au quotidient, pour lire mes mails sur yahoo, pour rechercher des informations sur le net, pour tester mon application GWT. Ce navigateur est vraiment rapide à l'exécution de Javascript. Il gagne également du temps sur la recherche DNS avec un cache. J'adore son ergonomie, sobre et amélioration de l'expérience utilisateur, comme le fait de pouvoir augmenter la taille des TextArea d'un simple étirement de souris.

Le plugin Speed Tracer est vraiment sensationnel aussi. Il permet de visualiser le temps d'exécution des fragments de code d'une application Web.

Le seul reproche que je lui fait est de ne pas proposer les liens RSS d'une page à droite de la barre de navigation comme sur Firefox. Ca oblige à rechercher un lien html sur la page qui n'est pas toujours facile à trouver. Donc lorsque je souhaite aggrégé un site dans mon aggrégateur je lance firefox juste pour récupérer le lien RSS (ou atom) J'espère que ce petit "problème" sera corrigé dans les prochaines versions.

Je préfère également utiliser Firebug que l'inspecteur DOM sur Chrome car ce dernier se lance dans une fenêtre séparré. Je trouve ca mieux d'inspecter les élements directement dans la page comme avec Firebug.

Les deux sessions gratuites sur le développement d’application Android du 11 février à Paris étant complètes avec plus de 130 inscrits, nous avons décidé d’ouvrir 2 nouvelles sessions le 16 mars à Paris la Défense et également 2 sessions le 18 mars à Toulouse. Les points abordés dans ce séminaire seront : - Intérêt et positionnement d’Android - [...]

L'objet History permet de gérer les boutons précédent / suivant du navigateur Web.

Un exemple d'utilisation de cette objet consiste à y stocker les identifiants des écrans et des beans gérés dans vos pages.

Si vous avez suivi les principes de DDD (domain-driven design) votre architecture doit être orientée sur les beans principaux définissant les modules gérés par votre application. La simplification globale de l'application passe par le découpage de l'application en modules. Chaque module est conceptualisé par un bean.

A partir de ce découpage vous pouvez simplifiez les écrans, originellement définit par un MOA, en créant un écran de gestion du bean définissant chacun de vos modules. L'idée est d'obtenir un écran par bean, et donc par module.

Maintenant, à l'aide de l'objet History, vous allez stocker un jeton contenant l'ID de l'écran que vous souhaitez ouvrir et l'ID du bean qui sera géré par cet écran. Je vous conseille de définir un jetons bien spécifique à votre application que vous pourrez parser afin de vérifier qu'il ne s'agit pas d'un lien venant d'une autre page Web.

Utilisez votre moulinette sur tous les liens et boutons qui appellent un écran. Définissez un manager (singleton) qui contiendra une méthode unique qui sera appeler pour ouvrir un écran. Cette méthode prendra en paramètre l'identifiant de l'écran et du bean à gérer (voir également un troisième pour l'id de l'onglet s'il y a onglets). Elle se chargera d'afficher l'écran, et de stocker votre jeton dans l'historique via l'objet History. Et lorsque l'utilisateur appuiera sur le bouton back du navigateur, l'objet History appellera le manager, en lui donnant en argument les ID requis pour ouvrir l'écran adéquat.

Dans une application de gestion standard, un bean aura besoin d'un écran de création, un de mise à jour, un de consulation et un écran de recherche dans lequel on pourra les supprimer. Chacun de ces écrans aura un ID spécifique. Vous pouvez factoriser votre code de manière à réutiliser un maximum de code entre les écran de création, de mise à jour et de consultation, qui sont finalement très proche.

Créer des liens directs interne à votre application GWT

Avec ce mécanisme, lors du démarrage de l'application, dans l'EntryPoint, vous pouvez récupérer le jeton qui se trouverait dans l'URL d'appel à l'application. S'il y a un jeton, injectez-le dans le manager définit précédemment. Ceci permettra aux utilisateur de créer des liens hypertextes vers des écrans de votre application GWT.

J'ai beaucoup utilisé YSlow ces temps ci, en particulier parce pour la première fois j'ai reçu des exigences de performance incluant le grade YSlow.

Je ne reviendrai pas sur la présentation de ces deux outils. Il existe de nombreux commentaires listant la mise en oeuvre et décrivant les règles.

• Yahoo's YSlow
• Google's Page Speed
  

Je voudrais simplement faire un retour d'expérience sur YSlow et Page Speed. C'est un retour QA plus que développeur, car j'interviens sur un projet dans la phase d'optimisation juste avant les tests de performance.

Les deux sont des plugins Firebug et s'installent très facilement. Ils apparaissent ensuite comme onglets dans Firebug. Bien sûr, l'utilisation de Firebug implique que l'application tourne sur Firefox. Pour IE, il existe AOL Page Test, que je n'ai pas testé, vu qu'il a obstinément refusé de fonctionner.

Même s'ils apparaissent très similaires et sont basés en gros sur les mêmes Best Practices, les deux outils ne sont pas positionnés de la même manière.



YSlow

YSlow facilite la communication sur les performances :

• Le grade général permet d'avoir une appréciation globale du niveau de performance, et par conséquent de communiquer sur l'évolution de ce niveau
• Un rapport HTML peut être généré très facilement et diffusé
• Ces rapports peuvent aussi être stockés pour comparer les résultats dans le temps
  

YSlow a permis de déterminer rapidement le besoin de configurer les modules Apache mod_expires et mod_deflate.
Une fois cette opération faite YSlow a permis de vérifier facilement que les dates d'expiration de cache sont maintenant correctes et que les contenus sont compressés.

En revanche, YSlow est assez général sur les recommandations. La règle a appliquer est présentée de manière très claire mais elle n'est pas appliquée au cas particulier. La conséquence est qu'il faut plus d'effort pour estimer le gain que l'on peut espérer de la correction et donc motiver une correction rapide.

C'est là qu'intervient Page Speed.



Page Speed

Page Speed fourni un état très complet, des propositions de correction et une évaluation du gain. Je ne suis pas vraiment la cible car je ne développe pas les pages sur ce projet. Il m'a tout de même servi pour plusieurs choses :

• Evaluer la minification des JavaScripts : le gain de la minification des JavaScript est de 150Ko par page sur les pages testées et une action pour mettre en place Dojo's ShrinkSafe est "rentable". Or cet outil est disponible mais personne n'a jamais eu le temps d'insérer le script dans le build
• inspecter les headers facilement : Les pages sont en HTTPS et les headers ne sont pas disponibles dans Fiddler. L'onglet resources de Page Speed affiche les headers requête et réponse et le texte ou contenu de chaque resource.
  
• "Smusher" les images : YSlow fournit aussi ce service mais en passant les URLs des images au site smushit.com. Or le site en développement n'est pas accessible depuis Internet. Page Speed génère automatiquement la version "smushée" de chaque image. Cela a permis de traiter rapidement 5 images sur lesquelles il y avait un gain de plus de 1Ko.
  
• Evaluer le CSS : constater que certaines maladresses sur le CSS sont classées "très mauvais" et nécessitent une action.
  

Avant de conclure, quelques conseils tirés de mon expérience YSlow.



Les jeux de règles YSlow

YSlow permet de créer des jeux de règles spécifiques. C'est utile lorsque certaines règles ne sont pas applicables :

• Le support des navigateurs interdit la mise en oeuvre de certaines règles
• L'application n'est pas dans un environnement permettant l'évaluation de la règle. C'est le cas en particulier de la règle "Use a CDN"souvent difficile à vérifier en développement (un CDN est un Content Delivery Network, c'est à dire un service de cache tel qu'Akamaï ou Limelight)

Les jeux de règles sont accessibles via le bouton Edit à côté du nom de règle.

• Une fois définies les règles via les cases à cocher, sauvez le ruleset. Il apparaitra dans les Custom Sets sur la gauche
• Redémarrez Firefox ! : les mises à jour ne sont sauvées qu'au moment de l'arrêt de Firefox. J'ai refait le ruleset 2 ou 3 fois suite à des plantages Firefox ;-)
  

La gestion du cache

YSlow se base sur le comportement de Firefox. Il est important que tous les contenus soient rechargés pour que leur statut soit mis à jour.

C'est particulièrement visible sur les dates de cache :

• Juste après la mise en place des directives pour mod_expires, les données sont affichées à jour. La date est dans plus de 48h et satisfait la règles "Add expire headers".
  
• Le lendemain, la règle est violée car la date d'expiration n'étant pas atteinte Firefox n'a pas rechargé les contenus statiques. Et les contenus en cache sont maintenant valides pour moins de 48h.
• Forcer le rechargement marche dans une certaine mesure, mais n'agit pas sur toutes les ressources. Le plus fiable est de vider le cache pour avoir les fichiers à jour.
  

En conclusion

Les deux outils sont très utiles pour améliorer la qualité des pages Web.

• YSlow s'adresse plutôt aux personnes qui valident l'application et au suivi qualité
  
• Page Speed est plutôt destiné aux développeurs qui vont optimiser les pages.

Posts similaires :

• Velocity 2009