Claude au pays des 4J

Changement de fil

2010-05-08T05:02:00.001-07:00

C'est la fin de ce blog sous Blogspot.

Il ne s'arrête pas vraiment puisqu'il continue sous Wordpress à cette adresse http://cfalguiere.wordpress.com/.

Mon nouvel article est là. Tous les agrégateurs n'ayant pas encore été mis à jour, je continue à poster les liens ici.

Pourquoi j'ai changé ?

Je n'ai pas de grief particulier contre Blogspot.

C'est simple à prendre en main donc pratique quand on se lance. Un inconvénient majeur pour moi est que les reformatages automatiques de texte ne permettent pas de mettre du code dans les posts, en particulier dès qu'il y du XML. Or vu la nature du blog, c'est un peu pénible. J'ai contourné le problème avec des images et puis au bout d'un moment j'ai cherché autre chose.

Une autre raison de passer sous Wordpress est que je participe aussi à deux autre blogs, Valtech et Duchess France et ces blogs sont sous Wordpress. C'est plus cohérent, et ça passe mieux dans les agrégateurs.

Wordpress est un peu plus compliqué à prendre en main au départ, mais plus puissant.

18 mois, le temps d'apprendre à marcher ...

Ce blog a duré environ 18 mois ici de Juin 2008 à début 2010 avec 14 articles, et presque autant de brouillons que je n'ai jamais eu le temps de finaliser.

Je continue ailleurs et j'espère que ceux (et celles) qui ont apprécié mes articles me suivront en adaptant leurs bookmarks et leurs flux.

J'ai repris l'essentiel du contenu dans le nouveau blog.
http://cfalguiere.wordpress.com/ pour la suite de cette aventure ...

Sonar against a non-maven multi-modules project

2010-01-31T07:35:00.000-08:00

I’ve explained a few monthes ago how to run Sonar against a non-maven project.

The workaround is to create a POM with an explicit source directory and set the Sonar property sonar.dynamicAnalysis to false.

What if the project has many source folders ?

The article is posted here

.

Retour d'expérience YSlow et Page Speed

2010-01-17T11:26:00.001-08:00

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.

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

R

2009-12-20T11:30:00.000-08:00

I discovered R a few month ago, and it's exactly the tool I was looking for to perform Exploratory Data Analysis on IT data (analyse of monitoring data, logs, performance tests results, workload analysis, code checks).

I used to do all that computation with Excell or ad hoc Java programs. Excell is great for small amounts of data, but when it comes to analyse 300000 lines of result, they won't fit in Excell (at least before Excell 2007).

R let me write scripts to compute statistics that I can run on data every day or when the test session ends with a minimum of manipulations. They are also easy to adapt when need be.

The rabbit is done with R as an illustration of 3D capabilities. I've found it at the R Graph Gallery. This site worth visiting to discover R graphic capabilities. I like R graphics. They are really neat and configurable. R comes with plots and histograms, very handly functions to convert data to graphics and advanced visualization features.

When I decided to write a post on R I balanced between a brief "WoW!" and a long run tutorial with all the nice things in R. As I'm to lazy to write a definitive tutorial on R, I decided to write a mind map and organize things I know about R up to now. I've also set up a pageflake with usefull links and blogs feeds.

R mind map

R pageflake

Please feel free to comment the mind map or pageflake as comments to that blogs. I'am new to R and may have make mistakes or ignored usefull resources.

.

Appeler Curl depuis un program Python 3.1

2009-07-25T06:30:00.000-07:00

Curl (un client HTTP en ligne de commande) est très pratique à utiliser pour tester manuellement les requêtes Rest. Il permet en particulier de manipuler les headers ou les méthodes HTTP.

Par exemple :

# envoi des données en JSON en paramétrant le header
curl -i -H 'Content-Type: application/json'
-d '{"items":[{"title": "AAA AAA", "description": "aaa aaa aaa",
"link": "http:AAA.com"}]}'  http://${SERVER}/rest/messages

# suppression du message avec la methode DELETE
curl -X DELETE http://${SERVER}/rest/messages/1

J'ai fait un petit programme Python pour faciliter la construction des différentes requêtes Rest. Le programme Python permet de sélectionner le server GAE local/remote, le type d'opération, le variant pour l'input, l'output demandé et saisir les données à envoyer.

Appeler Curl m'a posé quelques problèmes.
Pycurl (une intégration curl/python) n'existe pas pour python 3.1. J'ai donc implémenté les appels de commande externes directement en Python. Mais j'ai eu un peu de mal à trouver les informations car les I/O Python ont pas mal changées au cours du temps. Voici le code qui permet d'appeler une commande et récupérer la sortie standard en Python 3.1.

On utilise Popen du module subprocess. La méthode communicate() crée un tableau où 0 contient la sortie standard et 1 la sortie erreur.
Si vous voulez rediriger la sortie erreur sur la sortie standard, utilisez stderr=STDOUT.
Pour une raison qui m'échappe le passage de la commande en tableau a cessé de fonctionner, mais la concaténation de chaînes à résolu ce problème.

Sur Velocity 2009

2009-07-05T06:34:00.001-07:00

Enfin des choses qui bougent sur le thème performance ...

La conférence Velocity "Web Performance and Operations Conference" s'est tenue du 22 au 24 juin à San Jose, CA.

On y trouvait des représentants des plus gros sites Web (Facebook, Google, Microsoft, Twitter, Yahoo, etc) réunis pour discuter des problématiques d'exploitation et souvent de performance de leurs sites.

Je n'y étais malheureusement pas mais fort heureusement beaucoup de présentations et même des vidéos de sessions sont en ligne.

Brooks Elliott

Qu'est ce qui ressort ?

Tout d'abord, ces sites sont tous des sites commerciaux, très fréquentés où les performances sont nécessairement un enjeu. D'ailleurs Performance n'a pas toujours le même sens selon les interventions : il peut signifier ROI, expérience de l'utilisateur ou efficacité technique.

D'une manière générale, les participants constatent que dans les applications "Web 2.0"/AJAX les problèmes de performance perçue proviennent pour une bonne part de la restitution dans le navigateur (environ 50% du temps total). La plupart des outils cités sont des outils d'analyse du comportement sur le poste client et d'optimisation du Web design.

Je ne pense pas qu'ils aient ignoré la partie serveur (on voit passer par ci par là des outils plus classiques), mais il existe déjà des outils pour la partie réseau/serveur et le sujet est peu à même de déplacer les foules. Ils sont inclus dans le mantra le mantra "mesurer, mesurer, mesurer, visualiser et analyser les données pour comprendre le problème" que l'on retrouve un peu partout. Juste pour préciser au cas où, mesurer la production.

Bien qu'Agile cela n'apparaisse pas directement, on sent que le développement de la plupart de ces application est Agile (résolutions itératives des problèmes, rythme rapide des mises à jour en particulier). On voit donc l'envers du décor, quand les projets sont livrés pour être exploités et ne marchent pas forcément aussi bien que l'on souhaiterait. Les solutions sont souvent différentes de celles qu'on rencontre dans des secteurs plus classiques. En particulier ce sont plus souvent des solutions mixant l'infrastructure et le développement de l'application (travail sur les caches et les proxies à différent niveaux de l'infrastructure par exemple).

Darren Hester

Mesurer, mesurer, mesurer et comprendre

Tout d'abord une session avec un titre interminable
The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search de Eric Schurman (Microsoft) et Jake Brutlag (Google) qui présentent les résultats de tests utilisateurs qu'ils ont menés sur leurs moteurs de recherche. C'est intéressant et assez abordable. Prenez le temps de regarder la vidéos car les slides seuls sont assez laconiques.

Ils ont dans les deux cas appliqués la méthodologie A/B Testing (ou Split A/B Testing) utilisée habituellement en marketing pour choisir entre différents designs. L'A/B Testing utilise dans l'arrière boutique des méthodes statistiques de tests d'hypothèses basées sur des comparaisons de séries (variante de test de Khi2 type GTest, ZTest). Il nécessite une infrastructure qui permet de servir différentes versions du site à différents utilisateurs et de collecter les mesures.

La page Wikipedia sur A/B testing est un peu jargon. Vous trouverez sur ces deux pages des explications destinées au marketing plus faciles à appréhender dans le contexte :

Test AB (AB Testing) (en français)
An Introduction to A/B Testing (un peu plus détaillée mais en anglais)
et un exemple chez Google Google Website Optimizer; un service de A/B testing gratuit

En l'occurrence, ils ont soumis les utilisateurs a des versions de site plus ou moins lentes, ou dont les pages ont été refactorées selon diverses techniques pour mesurer l'impact sur l'usage et donc les revenus du site. Les constats sont que les utilisateurs commencent à percevoir l'attente à partir de 500ms mais aussi qu'ils ne sont pas impactés de la même manière selon la façon dont s'affiche la page.

On trouve un peu plus de détails l'utilisation de l'A/B Testing et d'autres moyens utilisés dans la présentation Performance-Based Design - Linking Performance to Business Metrics de Aladdin Nassar (Microsoft - Hotmail) et une moisson de sigles aussi : PBD Performance Based Design, RPI Relative Performance Index, PLT (ah non celui là c'est juste Page Load Time). C'est aussi en vidéo.

Philip Dixon (Shopzilla) dans Shopzilla's Site Redo - You Get What You Measure fait un retour d'expérience sur la refonte complète de leur site. Peu technique mais intéressant quand même pour les problématiques et le vécu. C'est aussi en vidéo.

aussiegall

Les outils

Pas de bon artisan sans de bons outils.
Plusieurs présentations ont été consacrées à des outils d'analyse dans le client :

Performance Tools par Eric Goldsmith (AOL), Simon Perkins (Simtec Limited), Stoyan Stefanov (Yahoo! Inc), Jim Pierson (Microsoft), Jan Odvarko (Freelance). Attention il y a deux présentations attachées :

Performance Tools Presentation [ZIP] sur Page Test d'AOL
Performance Tools Presentation 1 [PPTX] sur VRTA de Microsoft

Page Speed par Bryan McQuade (Google), Richard Rabbat (Google, Inc.) sur Google Page Speed.

Jiffy, une extension Firefox pour analyser le temps de réponse dans la partie client par Scott Ruthfield de Rooster Park Consulting.

geishaboy500

Optimiser le Web Design

Maintenant qu'on a compris d'où vient le problème, il faut lui trouver une solution.

Julien Lecomte (Yahoo!) présente dans High-performance Ajax Applications diverses techniques pour améliorer les temps de réponse du JavaScript. Attention c'est très technique et nécessite une bonne connaissance du développement JavaScript.

Si vous n'êtes pas un expert JavaScript vous préfèrerez probablement la présentation plus pédagogique de Douglas Crockford (Yahoo!) Ajax Performance.

Si vous n'en avez pas assez :

Une autre présentation d'optimisations JavaScript Writing Efficient JavaScript de Nicholas Zakas (Yahoo!),
ou Steve Souders (Google) présente ses 14 règles et analyse l'impact de plusieurs techniques en JavaScript et CSS dans Website Performance Analysis,
ou Dave Artz (AOL) The Secret Weapons of the AOL Optimization Team,
ou Frontend Performance Engineering in Facebook par David Wei (Facebook Inc.), Changhao Jiang (Facebook Inc.).

Go with the Reflow de Lindsey Simon (Google) est une présentation très spécifiquement sur le reflow en Javascript, c'est à dire le repositionnement des objects graphiques dans la page. Ce comportement du navigateur est cause d'un certain nombre de ralentissement dans le client.

Une très belle présentation sur CSS de Nicole Sullivan (Consultant) The Fast and the Fabulous: 9 ways engineering and design come together to make your site slow.

Et pour finir avec le Web design, Stoyan Stefanov (Yahoo!) présente dans Image Optimization: How Many of These 7 Mistakes Are You Making divers outils et techniques qui permettent d'améliorer le poids des images dans les pages Web.

ecstaticist

Rails

La présentation sur Twitter est particulièrement intéressante pour ceux qui s'intéressent à Rails. Fixing Twitter: Improving the Performance and Scalability of the World's Most Popular Micro-blogging Site par John Adams (Twitter) présente l'architecture, le reporting et le process de déploiement mis en place, les techniques de cache mises en oeuvre. C'est aussi en vidéo.

hounddiggity

Deployer

Passons un peu du coté de nos amis (si, si) de la production.

Une présentation très sympa sur les rapports devs/ops de John Allspaw & Paul Hammond (Yahoo!) 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr et la nécessité d'un respect mutuel pour faciliter les déploiements fréquents et rapides.

Pourquoi il ne faut pas compter sur l'administrateur Apache pour vous améliorer tout ça d'un coup de zip : Beyond Gzipping de Tony Gentilcore (Google) montre que la compression des flux n'est pas une panacée car 15% des utilisateurs ont quand même des réponses non compressées. Le problème est dû aux firewalls et proxies qui altèrent les headers HTTP.

Scalable Internet Architectures par Theo Schlossnagle (OmniTI) présente quelques slides intéressants sur les pratiques de cache et de partitionnement/sharding de base de données.

Introduction to Managed Infrastructure with Puppet présente l'outil de configuration management Puppet pour le déploiement d'application distribuées.

Chocolate Tools par JanneM

Les outils cités

J'ai regroupé ici divers outils cités dans ces présentations ou d'autres que je n'ai pas reportées.

JavaScript/DOM

HttpWatch analyse/profilage poste client, adon IE et Firefox (commercial)
PageTest analyse/profilage poste client, addon IE (AOL, opensource)
Jiffy analyse/profilage poste client, addon Firefox
Visual Round Trip Analyzer analyse/profilage poste client, add on IE (Microsoft, free)
Page Speed analyse/profilage/suggestions sur poste client, add-on Firebug (Google, opensource)
YSlow analyse de page Web - addon Firebug (Yahoo!, gratuit)
Firebug analyse/debug poste client - addon Firefox (opensource)
MSFast analyse/debug addon IE (opensource)
JSLint.com service en ligne d'analyse de code JavaScript
Cuzillion générateur de pages de test contenant diverses techniques JavaScript

Images

Smush.it service en ligne d'optimisation d'image
CSS Sprite Generator service en ligne de génération de CSS sprite à partir de plusieurs images dans le but de limiter le nombre de requêtes HTTP
SpriteMe idem
d'autres outils en ligne de commande sont cités dans la présentation Image Optimization

Réseau / HTTP

Fiddler analyse/debug http - addon IE (Microsoft, gratuit)
Charles HTTP proxy (commercial)
nExpert simulation de connexion réseau de différentes qualités (Windows)
WANSim simulation de connexion réseau de différentes qualités (Linux)
HTTP Analyzer sniffer HTTP Windows
Varnish cache HTTP

Surveillance

NetMon monitoring réseau Windows (commercial)
Ganglia surveillance de systèmes distribués Linux (opensource)
KITE service en ligne de mesure de performance sur les postes clients Web et RIA (Keynote, commercial avec un mode gratuit)

Configuration Management

Puppet configuration management (commercial)

J'en ai probablement ratés quelques uns et je n'ai pas systématiquement noté les outils connus (Squid ou Nagios par exemple) ou les outils système)

A suivre ...

Google et Yahoo! ont lancé chacun leur site pour regrouper les initiatives :

Google Let's make the web faster
Yahoo! Exceptional Performance

Running Sonar against a GAE Java project

2009-06-27T01:01:00.000-07:00

The GAE SDK generates a project that is not Maven enabled. Namely, source and target directories does not follow Maven conventions.

Sonar may be run against such a project by using Sonar light mode configuration.

We will write a minimal POM project and instruct Sonar to run only static analysis (code violations, complexity).
For the time being, we will put dynamic analysis (unit test results and code coverage) aside as it requires code to be executed, therefore dependencies configuration. Sonar may actually report dynamic analysis if surefire and cobertura reports are available.

But let's start with some simple configuration.
You will need Sonar (1.8 minimum) and Maven 2.

Write a POM

Open the Eclipse project generated by GAE SDK and create a pom.xml file at the project's root.

Add your project's information (replace cirrus in the snapshot below by your project's information)

Add GAE build information. You should not have to change these lines.

Add some Sonar configuration to skip dynamic analysis. You should not have to change these lines.

Depending on your repository and mirror, you may have to download sonar jars from the Codehaus repository.

Run Sonar

Now run sonar from the shell command line or configure an Eclipse launcher. As the Sonar maven plugin will send out data to Sonar during the build, the Sonar server must be running.

It may take a while the first time, as maven will download tons of libraries and plugins.

When it's done, Sonar's analysis report is available at http://localhost:9000.

You may find usefull information about Sonar configuration including "Non-Maven" projects in Analyzing Java Projects

Le ballet et l'agilité

2009-06-21T03:05:00.000-07:00

J'ai regardé un peu par hasard ce matin en déjeunant un documentaire sur l'expérience d'un groupe de jeunes Berlinois pour monter un spectacle de danse sur le Sacre du printemps de Stravinski accompagnés par le philharmonique de Berlin. Le documentaire couvre tout le projet, des répétitions et jusqu'à la représentation, et montre toutes les difficultés qu'il rencontre.

En particulier, il y a au bout d'un moment un fossé qui se creuse entre 5 ou 6 des élèves qui se débrouillent bien et le reste des élèves qui freinent la progression. La danse est une activité difficile. C'est fatiguant et parfois douloureux. C'est ennuyeux quand il faut recommencer des dizaines de fois le même enchaînement jusqu'à ce que tout le groupe le mémorise et le réalise en rythme avec la musique et en coordination avec les autres dans ses déplacements. Et au delà de ça, c'est un art. Il faut que les danseurs expriment l'argument du ballet. Et le thème du Sacre du printemps n'est pas facile. C'est un rituel pour le retour du printemps qui se termine par le sacrifice d'un élu pour que le printemps revienne. Donc des sentiments probablement assez perturbants.

En première approche le problème semble être imputable à ceux qui sont à la traîne. Ils ont leurs raisons : ils n'aiment pas la musique classique, ils n'ont aucune idée de ce que signifie faire des efforts, ils se contentent de faire le job parce qu'ils estiment que c'est suffisant. Certains sans forcément le reconnaître ont peur d'échouer et préfèrent échouer parce qu'ils n'ont pas fait ce qu'il faut qu'en ayant fait le maximum.

Le chorégraphe britannique Royston Maldoom dans son approche pédagogique se montre très exigeant. Il leur explique qu'il pense qu'ils peuvent faire mieux (alors que l'encadrement local pense qu'ils sont à leur maximum). Il exprime aussi la frustration que ressentent ceux qui ont déjà compris à devoir refaire encore à cause de ceux qui ne sont pas concentrés. Je ne suis pas sûre que cela ait eu beaucoup d'effet puisqu'ils envisagent quelques temps plus tard de déplacer les meilleurs dans un autre groupe pour qu'ils puissent avancer à leur rythme. Mais il fallait qu'il le fasse pour être cohérent avec lui même.

Ce qui est assez amusant, c'est que lorsqu'ils sont interrogés individuellement, Royston Maldoom le chorégraphe et Simon Rattle le chef d'orchestre reconnaissent que ce sont eux qui sont différents. Qu'ils ont une exigence d'aller toujours plus haut et de ne pas se contenter d'atteindre l'objectif qu'ils ne peuvent partager qu'avec très peu de gens. C'est un discours de passionné plus que d'artiste d'ailleurs. Les élèves qui sortent du lot énoncent aussi cette différence d'une manière moins rationalisée. Ils ont rencontré une personnalité, une activité, une perspective qui leur a donné la motivation de se dépasser.

Finalement le spectacle a lieu. Probablement pas aussi parfait que ce qu'il aurait pu être, mais le but de l'expérience était plus je pense de faire vivre quelque chose à ceux qui ont su en profiter. Certains de ceux qui n'aiment pas la musique classique ont trouvé que certains passages du Sacre du printemps étaient intéressants à sampler. D'autres ont pris confiance en leur capacité à réussir quelque chose.

Alors pourquoi ce grand détour par la danse, alors qu'en gros je parle plutôt d'informatique ?

Parce qu'il y a une similitude avec ce qui se passe dans les projets informatiques, surtout lorsque l'on aborde de nouvelles technologies. On ne se rend pas toujours compte que les techniques que nous maîtrisons ne sont pas forcément maîtrisées par les gens avec qui nous travaillons et que cela a un coût pour eux de les acquérir, voire parfois de reconnaître qu'ils ne les maîtrisent pas. Cela entraîne souvent une certaine frustration chez nous parce qu'on voudrait que ça aille plus vite, qu'ils adoptent ce qu'on leur présente comme la meilleure solution. Pire encore que leur manque de maîtrise, ça ne les passionne pas plus que ça.

Ce documentaire m'a amenée à repenser à des discutions que nous avons eu cette semaine, en particulier avec Eric Le Merdy et Etienne Charignon à propos d'une question posée initialement par Eric sur les stratégies que l'on peut adopter pour amener les gens aux pratiques Agile : est il indispensable de commencer en respectant strictement tous les préceptes ou peut on amener les gens à l'Agile plus souplement par l'exemple ?

Comme le fait remarque Etienne, la première démarche relève encore souvent du projet pilote. On plonge le client en immersion dans un projet géré 100% SCRUM et on leur dit qu'on sait qu'ils peuvent le faire. Cela s'apparente à l'expérience de réalisation d'un spectacle avec des professionnels. L'avantage de ce processus est de permettre une évaluation rationnelle et scientifique d'un ROI. Encore faut-il que les gens suivent. Comme dans l'expérience de ballet plus haut il est probable que certains adhèreront sans réserve et d'autres pas. Je doute que l'on puisse maintenir des pratiques Agiles sur la seule base d'un ROI. L'implication demandée est trop forte pour que le processus fonctionne de manière imposée. C'est probablement pour cela qu'Etienne constate des retours-arrière vers des projets "pâte à modeler". Tout le monde n'a pas vu la lumière mais certaines pratiques ont plu.

D'un autre côté, la méthode souple revient à introduire par l'exemple certaines de bonnes pratiques comme faire des tests unitaires, ou du TDD. Mais est que ça revient à avoir un mode de pensée Agile ? Probablement pas. C'est un peu comme aller en cours de danse 1h par semaine. On fait quelques assouplissements et on se sent plus en forme, allez, on mange bio comme la prof de danse parce que ça à l'air de lui réussir. Mais je doute que l'on comprenne de cette manière ce que représente la préparation d'un spectacle de danse et l'accomplissement de le délivrer en public. C'est face à la difficulté que l'on comprend vraiment les enjeux d'une pratique.

ça n'est pas inutile pour autant. D'abord, faire un peu de sport ça n'est pas si mal. Ensuite, je crois que les technologies se diffusent beaucoup de manière virale. J'ai vu émerger Java, le Web, UML, XML, J2EE. Aucune de ces technologie n'a été adoptée facilement au départ parce qu'elles étaient rationnellement meilleures comme on peut le penser maintenant. Elles ont été portées par des gens passionnés, qui y ont compris les avantages, on expliqué encore et encore, on fait découvrir ces technologies alors qu'ils étaient venus pour tout autre chose. La passion des gens est communicative même si on ne partage pas toujours tous les arguments présentés. Au bout d'un moment, la nouveauté fait partie du paysage, elle ne fait plus peur et on peut poser le problème du choix plus rationnellement.

Je ne vois pas d'opposition entre les deux stratégies. C'est plus une question de timing. La méthode souple amènera certains au grand saut dans un pilote, et voire plus si affinité. Dans le pire des cas, elle facilitera les choses pour plus tard en ayant appris certaines pratiques nécessaires dans un projet Agile ce qui facilitera les pilotes. Il faut juste être conscient que le saupoudrage de pratiques Agile n'est pas un projet Agile, c'est seulement une distribution d'échantillons. C'est peut être difficile à faire comprendre aux gens avec qui on travaille et qui sont tentés par la mode Agile.

Etienne pense que pour la stratégie en douceur, il faudra de la persévérance et de la pugnacité. A mon avis, il en faudra pour les deux stratégies de toute manière. Et peut être encore plus pour transformer les projets "pâte à modeler" en projets vraiment Agile. Ce qui compte c'est de rester passionnés et à l'écoute.

J'avais prévu au départ quelque chose plus lié à la musique suite à d'autres discussions. ça sera pour une autre fois.

La photo Modern Dance est de Kevin Eddy

Générer un rapport PDF Sonar

2009-05-06T10:21:00.000-07:00

Depuis Sonar 1.8, il existe un plugin de génération de rapport PDF.

La mise en oeuvre est très très simple.
Lancez la commande ci-dessous depuis un shell de commande ou l'IDE :

>mvn org.codehaus.sonar-plugins:pdf-report:0.1:generate -Dsonar.base.url=http://nommachine:9000

L'option -Dsonar.base.url n'est pas obligatoire, mais il se trouve que je ne peux pas faire tourner Sonar sur le port standard 9000. Attention, pas de / à la fin de l'url sinon l'url générée contient un // au début du path et il ne parviendra pas à lire les données.

Il n'est pas nécessaire de télécharger le plugin, il automatiquement téléchargé et mis en place via maven.

Le rapport en PDF est généré dans le répertoire target du projet maven racine.
Il contient pour le projet et chaque module, les ratios du dashboard (voir image ci-dessous), les valeurs du radar par catégorie (Efficiency, Maintainability, Portability, Reliability, Usability) et les hotspots Most violated rules et Most violated files.

La page du plugin se trouve là Sonar PDF Plugin.

Sonar 1.8 et la Sonar Plugin Library

2009-04-19T10:50:00.000-07:00

SonarSource vient de rendre disponible la version 1.8 de Sonar et un espace pour les Sonar plugins réalisés par la communauté Sonar.

Pour ceux qui auraient raté les épisodes précédents, Sonar est un produit open source de qualimétrie pour le monde Java.

Cet outil pilote l'exécution des outils d'analyse de code (PMD, Checkstyle, Findbugs) et de test unitaire sous Maven, historise et fait la synthèse de toutes ces informations. Il peut être étendu par plugins (par exemple PL/SQL ou l'intégration Hudson).

Il se montre particulièrement indispensable sur des projets multi-modules où il est difficile d'avoir une vue d'ensemble de la qualité en utilisant chacun de ces outils et Maven Dashboard.
Sonar agrège ces informations selon les catégories ISO (Efficiency, Maintenability, Portability, Reliablity, Usability) et permet une identification rapide du type d'impact sur un radar. La navigation projet / module / package permet d'avoir ces informations à différentes granularités.

Plusieurs systèmes permettent de localiser facilement la classe et la portion de code où il faut agir en priorité pour améliorer la qualité :
- un pavage qui permet de visualiser à chaque niveau l'importance des éléments et leur niveau de qualité
- un nuage qui met en évidence les classes qu'il est facile d'améliorer et celles qui présentent le plus de risque
- depuis la version 1.8, Sonar a ajouté les hotspots, des top5 des classes les plus indisciplinées, les plus longues à tester, les plus complexes, les moins testées ...

En plus des hotSpots, la version 1.8 ajoute en particulier le paramétrage de Findbugs, l'affichage des duplications sur le code source et le support de maven 2.1.

Vous cherchez encore des excuses pour ne pas évaluer la qualité de votre code ?
Allez le voir fonctionner sur Nemo et on en rediscute après.

2009-02-12T02:58:00.000-08:00

Deux articles intéressants sur le développement des jeux multijoueurs dans le numéro de Novembre/Décembre du magazine Queue!.
ça se trouve là :
http://mags.acm.org/queue/20081112

Ksar

2008-10-28T01:12:00.000-07:00

Ksar est un utilitaire open source écrit en Java qui permet de représenter graphiquement l'ensemble des métriques d'un rapport sar. Pratique et efficace.

L'outil possède également différentes fonctions pour générer les rapports à distance en ssh, générer un rapport pdf, modifier la période affichée, etc.

On peut consulter la présentation de l'outil et le télécharger
via source forge http://sourceforge.net/projects/ksar
ou directement par le site Ksar http://ksar.atomique.net/.

Utiliser Redmine pour gérer les tests

2008-10-23T01:37:00.000-07:00

Redmine serait il devenu aussi un outil de test ? Et non ;-)

Redmine (http://www.redmine.org/) est un outil open source qui se présente lui même comme une application Web de gestion de projet.

Redmine est par défaut orienté développement.
Les demandes que l’on peut gérer sont des évolutions ou des anomalies. Mais il est très facile de créer de nouveaux trackers pour créer des demandes qui concernent des opérations à réaliser sur la plate-forme de test ou des épreuves de test afin d'adapter le vocabulaire et les attributs.

Un outil de rapport permet d’afficher les demandes en filtrant les données selon les trackers et les attributs et de décider des colonnes à afficher. Les demandes qui ont une date de début et de fin sont présentes dans des vues calendrier ou gantt. Il est aussi possible de faire une gestion du temps passé sur ces demandes et de faire des synthèses.

L’outil est bien adapté aux petits projets que sont les campagnes de tests de performance.

Redmine permet de partager via un site Web toutes les informations qui contribuent à un projet de test :
- les documents de spécification ou des rapports via l’onglet document
- des informations de statut au jour le jour via les annonces
- des informations plus permanences sur les tests réalisés, les informations techniques peuvent être notées dans le wiki
- les résultats de test générés sous forme de pages Web peuvent être déployés dans la partie Web statique et référencés dans le wiki

Redmine a aussi quelques fonctions d’intégration intéressantes.
- il permet de gérer une liste de participants et d’envoyer automatiquement des mails via les annonces, lorsque des demandes sont crées ou changent,
- il permet de s’interfacer avec des SCM tels que Subversion pour partager des sources d’utilitaires ou de script
- il existe des plug-ins qui permettent de s’interfacer avec des outils d’intégration continue qui peuvent être utilisés pour générer automatiquement certains documents

En fait j’ai décidé de tester Redmine après une campagne de test ou les participants étaient sur 5 sites en France et en Belgique et où je constatais que je passais une bonne partie de mon temps à renvoyer des informations de planning, des documents et des fichiers de suivi excel par mail à des gens nouvellement arrivés sur le projet ou remplaçant quelqu’un.

Ce qui m’avait arrêtée jusque là pour utiliser des outils comme Trac c’était le temps nécessaire pour installer l’outillage. Je fais des campagnes sur des sites différents à chaque fois et je préfère voyager léger.

Alors pourquoi Redmine ?

Parce que c’est du Rails. InstantRails s’installe (enfin se dézippe) dans le bon répertoire en quelques minutes. Une fois copié l’application rails Redmine dans le bon répertoire, on démarre InstantRails, on lance deux scripts pour créer la base et l’initialiser et l’application est accessible. C’est magique !

Il faut environ une demi journée pour avoir en place les utilisateurs, les sous projets, les trackers spécifiques et les tâches de base ... et beaucoup plus de tranquillité par la suite pour se concentrer sur les tests.

Crayon Physics

2008-08-19T02:13:00.000-07:00

Un jeu tout mignon basé sur les principes de la physique

Le but du jeu est de déplacer la balle rouge pour qu'elle attrape les étoiles. La balle est déplacée en dessinant des objets qui interagissent avec la balle.

http://www.kloonigames.com/blog/games/crayon

2008-06-18T11:01:00.000-07:00

C'est bien les feed RSS, mais ouvrir Google Reader et apprendre Ebsbjörn Svensson est mort, ça casse un peu le moral. Je suis triste et en vacances. ça me laisse plein de temps pour essayer des trucs. Pourquoi pas mon blog à moi, pour voir ?