new Blog( perso );

Quand on manipule des services web, des schémas XSD et des louches entières de XML, on rencontre des développeurs qui sont complètement perdus dans les concepts de namespaces. Une idée trop largement répandue est que le namespace donne l'emplacement du schéma considéré, idée basée sur l'utilisation courante d'URL pour définir ces namespaces, lesquelles pointent effectivement assez souvent sur le schéma considéré.

Petit rappel donc.

En XML, les namespaces permettent de mixer plusieurs grammaires dans un même document, on associe donc un identifie chaque grammaire (schéma XSD) un namespace, auquel on associe un préfixe utilisé dans les balises du document XML.

Le namespace est un identifiant de la grammaire XSD. Techniquement parlant, c'est une URI, soit un identifiant unique répondant à des contraintes assez simple, mais en aucun cas un lien pour la consulter.

Une URI (Uniform Resource Identifier [FR]) est juste un formalisme commun pour l'écriture d'identifiants portables. La principale chose à en retenir est qu'elle commencent pas "préfixe:", ce que la norme appelle le 'scheme" -- "programme" , ou "plan", d'après google translate, parfois traduit par nom de shéma, mais alors on peut confondre avec le schéma XSD ...

Les URL (Uniform Resource Locator) sont une forme particulière d'URI qui permettent de définir une localisation pour une ressource (les fameux liens hypertexte du web). On PEUT donc les utiliser comme identifiant pour les namespace XML, et c'est d'ailleurs pratique pour faciliter la vie des développeurs si ce lien pointe en effet vers le schéma XSD, seulement rien ne l'impose.

Une autre option, ce sont les URN (Uniform Resource Name), une autre variante des URI qui permettent de définir un nom, et non un emplacement, qui par définition peut changer.

Que choisir ?

L'intérêt apparent des URL comme namespace introduit une incompréhension qui n'est pas bénéfique. Par ailleurs, le risque de voir l'URL ne plus pointer vers le schéma pour X raison (changement d'hébergement, changement de nom de domaine ...) est perturbant.

Les URN sont a priori plus adaptées, mais pas très courantes. Il est pourtant plus sain de définir un schéma comme
  urn:schema:monprojet.org:Domaine/1.0
que comme
  http://monhebergementpourlemoment.free.fr/xsd/Domaine_1.0.xsd

Pour aider le développeur (via son éditeur XML préféré) il suffit d'exploiter le mécanisme de localisation des schémas lui aussi prévu par la norme :


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:schema:monprojet.org:Domaine/1.0
                    http://qqpart.org/xsd/Domaine_1.0.xsd"

Vous noterez en passant que les namespaces choisis pour les normes XML sont des URL, ce qui participe très activement à la confusion...


Pas convaincu ? lisez cette (traduction de la) note officielle du W3C : http://www.yoyodesign.org/doc/w3c/uri-clarification/

Java 5 apporte son lot de nouveautés, entre autre l'autoBoxing. Sauf qu'il ne s'agit pas d'une évolution au sein de la JVM mais uniquement au niveau de la syntaxe et du compilateur, donc écrire :

Double d = ...;
truc.setValue( d ); // signature : public void setValue( double );

se traduit (en pseudo-code) dans le .class compilé par

Double d = ...;
truc.setValue( d.doubleValue() );

Je serais le 11 mai au ParisJug pour présenter en compagnie de mon Arnaud Héritier préféré une synthèse rapide des nouveautés de Maven 3. Rapide parce que le ParisJug ne nous laisse que 30 minutes, aussi nous avons choisi pour notre sujet une formule ... inhabituelle.

Si vous avez aimé le bouquin, le ton que nous allons (essayer de) donner à cette intervention devrait vous plaire. Et pour ceux qui ne peuvent se contenter de 30 minutes, un petit détour par la troisième mi-temps devra combler ce manque.

Infos, inscriptions, et toute ce genre de choses sur ParisJug.org.

Depuis quelques années, je travaille à mettre en place des outils de "forge logicielle", mutualisés ou dédiés à un projet; voici les outils que j'aimerai assembler pour fournir un environnement clé en main sur projet :

• une machine dédiée (ou une VM) sous Ubuntu, système facile à installer, bien documenté. Le passage sur un Linux permet déjà de tester toutes les problématiques d'encodage de caractères et de séparateurs de fichiers;
• un SVN, un Git ou Mercurial, selon les goûts; 
• un Nexus pour la conservation des artefacts et l'économie de bande passante;
• un serveur Hudson, qui s'installe via un paquet DEB que c'est tellement simple que ça fait pleurer;
• un build Maven (sans blague ?);
• idéalement, une conf magique pour que le build n'ait pas accès au Net, par exemple via http.proxyHost. L'idée est d'empêcher le parser XML de récupérer les schémas XSD sur le Net - si, ça arrive !
• un serveur de démo/test/perfs, sur lequel la dernière version NIGHTLY est déployée automagiquement;
• un job dédié pour alimenter un Sonar en build nocturne; Je préfère prendre Sonar avec sa conf par défaut puis voir ce qui en émerge et comment ça évolue, pour voir là où l'équipe doit progresser et réduire la gravité des règles qu'elle considère inutiles APRES les avoir violées trop régulièrement (au moins, on s'est posé la question). En général, les indicateurs de complexité s'envolent rapidement ;)
• un wiki projet, j'aime bien xWiki qui est puissant et colle bien dans cette forge "tout java". Les plugins Eclipse et Office (pas testé) peuvent aussi aider à faire apprécier le principe du Wiki même aux plus classiques d'entre nous;
• un gestionnaire de tâches/bugs. Sauf à avoir un JIRA en centralisé, il peut être intéressant de le conserver sur la machine projet avec le reste et de gérer les sauvegardes d'ensemble de la forge. Je n'ai pas de préférence faute d'avoir pu tester autre chose que cette bouze de Quality Center;
• pourquoi pas un serveur iceScrum pour ceux qui pratiquent;
• un outil de revue de code, dans l'esprit de Crubicle, et dans l'idéal intégré à l'IDE... je n'ai pour l'instant rien trouvé;
• un environnement de dev prêt à installer. Pour l'instant je fais un gros ZIP d'Eclipse + JDK + Maven + Tomcat + ... mais c'est pas le top, surtout pour gérer les mises à jour.

Je suis sûr qu'il manque plein de briques intéressantes à rajouter à cette wishlist, j'attend vos suggestions ;)

La grande mode en ce moment en terme de gestionnaire de code c'est Git. La différence avec Subversion, la grande mode de juste avant, c'est que Git est distribué. Super, et alors ?

Prenons une journée type. Vous bossez sur un item qui vous fait modifier du code un peu partout et quelques refactorings bien sympatoches. Arrive alors une urgence bien trempée, un point fonctionnel pas clair qui oblige à temporiser, ou encore une soudaine envie de passer à autre chose parce que là, vraiment, ça n'avance pas.

Que faire ? Lancer un nouveau checkout pour partir sur autre chose et switcher entre deux workspaces Eclipse ? Idéalement, il aurait fallu travailler dans une branche, comme ça passer à autre chose se ferait sans perdre l'état en cours... sauf qu'il aurait fallu le prévoir à l'avance et que la manipulation ne dépende pas de votre réseau de %@! qui semble être basé sur des modems 56k.

Et bien c'est ce que propose Git ! 

Git gère un repository rien qu'à vous dans lequel vous pouvez brancher, switcher, commiter, comparer et tripatouiller tout ce que vous voulez. Etant 100% local, ces opérations sont extrêmement rapides, donc deviennent naturelles (alors que sous SVN elles sont méconnues)

Pour bosser, on commence par créer une branche pour la tâche considérée, et committer dessus à chaque fois qu'on le juge utile. A tout moment on peut changer de branche, tout annuler, revenir en arrière, etc.

Evidemment, à un moment il faut bien envoyer tout ça à ses petits camarades. Mais comme le repo Git est local, on peut remanier les commits effectués pour en faire quelque chose de plus cohérent, ce qui évite l'effet "fix" qu'on constate sur SVN : 1 gros commit suivi de quelques autres pour les fichiers "oubliés". Du coup la synchronisation entre repos Git est nettement plus atomique. Idem pour travailler à deux, on se synchronise entre binômes sans perturber le repository de référence (avec Git, personne ne fait particulièrement référence, mais dans la vraie vie il faut bien se mettre d'accord pour livrer !).

Bref, Git c'est une autre façon de bosser qui va rapidement devenir indispensable, comme à l'époque où on avait pas de SCM et où on partageait tous un montage réseau...

Les points faibles de Git ?

Outil en ligne de commande, il reste particulièrement obscur sur ces options. L'intégration dans les IDE est moyenne avec un retard notable d'Eclipse (quelle surprise). Enfin, le concept étant relativement nouveau il faut apprendre à l'apprivoiser.

Pourquoi se préoccuper de Git ?

Après tout, Subversion marche plutôt bien. Et bien, si le cas d'usage exposé ci-dessus vous laisse froid, sachez que la prochaine version suivante  de SVN (la N+2 quoi) incorporera un mécanisme de distribution, sans doute inspiré par le succès de Git et consorts. Ce n'est donc pas qu'un effet de Geekitude,  mais bien une évolution profonde des SCM, autant être dans les premiers à savoir en tirer partie.

Comment commencer avec Git ?


Pour faire mumuse, Google Code propose un hébergement Mercurial, assez comparable à Git mais qui a moins le vent en poupe ces temps ci (sans de raison évidente).
Le plus concret est d'utiliser Git au dessus de SVN. Le repo local Git peut en effet se synchroniser sur un SVN classique, ce qui permet d'en profiter sur son poste sans perturber l'organisation de l'équipe. Et une fois le pli pris...

Reste à apprendre les commandes assez obscures de Git et l'utilisation du GitBash sous Windows - plateforme qui n'est pas à l'honneur pour cet outil.

Une nouvelle licence vient de voir le jour, la plus restrictive jamais imaginée à ma connaissance (mais je peux me tromper)

Ce n'est pas de la GPL ou d'une de ses variantes, qualifiées de "virales" - terme qui semble taillé pour faire dresser les cheveux des DSI.

Ce n'est pas non plus d'une licence calculée au nombre de coeurs CPU, ce qui est pourtant un concept déjà assez étonnant qui oblige à acheter plusieurs machines là où une seule suffirait.

Non, je parle de la licence qui accompagne le lancement de l'iPhone de 4ème génération, licence qui dicte purement et simplement l'environnement de développement autorisé. Vous devez donc EXCLUSIVEMENT utiliser le SDK Apple et le langage de programmation ObectiveC pour avoir accès à l'AppleStore. Pas de traduction de langage, d'èmulateur ou d'interpréteur JIT, rien que du "made by Apple" et rien d'autre.

A ce rythme, la version 5 imposera de développer sur MacBook Pro 15" ou supérieur exclusivement, ou encore de disposer d'un abonnement internet d'un partenaire Apple pour uploader sur l'AppleStore, ou peut être de boire exclusivement de la Budweiser, qui sait.

Alors, oui, Apple dispose d'ergonomes de génie, d'un marketing à faire pâlir n'importe qui, mais faut pas pousser. Si c'est la seule arme de l'iPhone pour couper l'herbe sous le pied des développements compatibles iPhone + Android via un langage pivot, ça ne va pas dans le sens de belles applications innovantes et universelles à des prix accessibles.

Une grande majorité des projets basés sur Maven suit la convention de décomposer le projet en modules, selon l'architecture ou les domaines fonctionnels de l'application. Assez fréquemment on retrouve donc quelques modules bas niveau sur lesquels sont basés des module plus avancés, services web, batchs ou IHM web.

Un build "classique" enchaîne la construction de ces modules sans tirer parti du parallélisme de l'architecture de la machine. Si les I/O restent un élément important dans la vélocité du build (pour ma part, mon repository local est dans un RamDisk ce qui booste bien les choses), il est dommage de laisser nos quad-core dormir en attendant la prochaine compilation.

Depuis la semaine dernière, le trunk de Maven3 intègre une évolution qui était pour l'instant développée sur GitHub en pure expérimentation : il s'agit de la parallélisation du build. Pour expérimenter cette option, vous pouvez récupérer un nightly-build de maven 3 sur l'intégration continue du projet.

L'option -T permet de définir le nombre de threads qui vont supporter le build. Maven se charge de répartir la construction des modules du projet sur ces différents Threads et de réordonner le log pour qu'il reste lisible selon un ordre "classique".

Pour ma part, je n'ai pas réussi à le faire fonctionner sur des projets significatifs. Avec mon "gros" projet, je tombe sur une ConcurrentModificationException lors de la compilation AspectJ. Sur un build Archiva qui trainait sur mon disque (nostalgie...) c'est l'instrumentation JPox qui échoue.

Il est probable qu'aucun plugin maven ou outil impliqué dans le build n'ai prévu jusqu'ici d'être utilisé dans un cadre multi-threadé de ce type... il va donc y avoir une grosse campagne de test et d'évangélisation à prévoir. En attendant, Maven est à ma connaissance le seul outil de build a expérimenter cette voie, qui devrait prendre tout son sens sur les fermes d'intégration continue disposant de multi-coeurs et qui pourraient ainsi devenir très réactives.

Wait & See...

Les gars de Google se sont bien amusés avec Google GAG, mais l'idée était intéressante. Pour faire suite à mon billet sur le plugin Sonar de revue de code, passer directement par le code source sous SVN pour associer les commentaires de revue et le code considéré, c'est une solution pratique.

Je lance donc avec mes petits camarades du BreizhJUG une super top toute nouvelle librairie d'annotations : CRADoc. Les suggestions/contributions sont les bienvenues !

public class Sample
{
    /**
     * Moi y'en a faire du JavaDoc pour le fun qu'il décrit rien de
     * qu'est ce que dont ça fait la chose dessous là
     */
    @tesSouhaits( value = "t'as avalé un becherel de travers ?", 
                  reviewer = "jtoubon" )
    public void codeDeMerde()
    {
        @ttention( "il y a plus simple pour créer des double..." )
        double d = new Double( "1.0" ).doubleValue();

        @bracadabra( "fun, mais ça sert à quoi exactement ?" )
        double k = ( d + 2 - 2 );
    }
}

Koshuke Kawaguchi, développeur de génie a qui on doit (entre autre) le célèbre serveur d'intégration continue Hudson, annonce son départ de SUN/Oracle. Mauvaise nouvelle pour SNORCL, mais les utilisateurs d'Hudson n'ont pas de soucis à se faire car Koshuke se lance dans un nouveau projet visant à propulser son bébé à un autre niveau.

L'idée ne semble pas nouvelle, reste à savoir si ce pas aurait été franchi aussi rapidement sans le rachat de SUN... Il va y avoir quelques cadavres dans cette fusion.

Pour Pâques, méfiez vous des lapins-vampires.


Plus sérieusement (si on peut dire), et si la présence exceptionnelle d'Emmanuel Bernard ne suffit pas à vous motiver, le BreizhJUG va se transformer en chasse aux oeufs dans le grand amphi de Supélec. Contrairement à d'autres notre JUG a la chance de ne pas être limité en nombre de places, alors c'est l'occasion de le faire découvrir à vos collègues : passez le mot !

Ce week-end pascal est consacré à une longue réflexion pleine de conséquences. Dans ces cas là, j'ai une astuce : la tondeuse.

En plus d'entretenir le jardin, cet instrument possède un pilotage simple qui libère l'activité neuronale. Il m'arrive donc couramment d'avoir recours à cet ustensile - de jardinage a priori - pour réfléchir activement ou prendre des décisions.
J'ai trouvé une explication théorique à cette pratique : d'après cet article, le développement neuronal du jeune enfant est favorisé par le quatre-pattes et par les mouvements saccadés qu'il impose à la boîte crânienne. Ma théorie est donc qu'on peut extrapoler ce résultat à l'âge adulte, les vibrations d'un engin à moteur favorisant ainsi le bon fonctionnement de la matière grise et la résolution de problèmes qui paraissaient hors de portée.

Je propose donc qu'on équipe tous les bureaux d'études de grands espaces verts, en plus ça sera plus joli.

Vous avez été nombreux à colporter mon poisson d'avril 2010, ce qui a amené plus de 450 visiteurs à douter un court instant de la véracité de ma fausse page 01Net. Le pot aux roses était assez évident et je n'ai pas pris le temps de masquer un peu mieux l'URL pour laisser planer un peu le doute.


Une petite victoire tout de même, car parmi quelques collègues moins "geeks" que les habitués de ce blog, plusieurs se sont bien fait prendre au piège. Sans parler d'un client particulièrement réceptif qui a tellement plongé que personne n'a osé lui dire qu'il s'agissait d'un fake. Il faut tout de même qu'on lui dise la vérité, sans quoi la prochaine réponse à appel d'offre risque d'être comique.

De mon côté je me suis bien marré de voir l'inventivité des habitués de la bloggosphère, entre xebia qui nous invente des lunettes de réalité augmentée qui ajoutent des post-its partout, le touilleur qui se croit revenu en 1999 à l'aire des dot_com, et Google qui nous sort des librairies délirantes MAIS fonctionnelles - le poisson d'avril qui pourrait cacher une vraie bonne idée ? Je ne sais pas si quelqu'un a essayé Google Street View avec des lunettes 3D pour voir si ça marchait vraiment, mais on se demande si c'est un vrai pur gag ou une idée délirante qui deviendra notre quotidien dans 5 ans...

Quand au traducteur Français / Chien sur android, figurez vous que ça existe en vrai (mais pas sur android) - certes, pour les gogos fortunés qui n'ont plus que leur caniche comme amis.

Suite à l'action du gouvernement français pour sauver la langue française d'anglicisme honteux, Google se voit contraint de changer le nom de sa fonctionnalité Google Buzz dans la version française de gMail.


Reste à savoir si Google Ramdam connaîtra un meilleur accueil que son prédécesseur...

Avec la finalisation de Maven 3, Sonatype commence à sortir des outils autour de ce nouveau coeur, enfin extensible à souhait. MavenShell est un de ceux-ci, conçu pour les fans de la ligne de commande, mais qui veulent aussi un outil pointu et rapide.

Le secret de MvnShell c'est tout simplement qu'il conserve en cache les POM et la configuration des plugins déjà exécutés dans le shell. En pratique, une fois le premier build passé il permet de gagner un peu de temps sur les builds successifs.

Bien sûr, si la majorité du temps passé sur un build concerne le passage des tests ça ne va pas changer grand chose, mais c'est toujours ça de pris.

Autre bonus de ce shell, via l'intégration de JNA, il permet d'avoir une console colorée, agréable pour éplucher plus efficacement le log du build. Il faut dire qu'un log peut parfois être particulièrement inexploitable, avec un mix des divers plugins impliqués et de la sortie console des tests. Le log Maven3 dans le shell fait ainsi ressortir chaque plugin avec son exécution et le module maven considéré, ça aide bien.

Pas de quoi faire une révolution tout ça, mais tout de même un exemple de ce que va permettre Maven 3 : de nouveaux outils, de nouvelles extensions. Je pense au support dans les IDE bien sûr, mais aussi à l'intégration continue (plutôt que les hacks actuels pour scruter le build Maven2), à la manipulation des méta-données dans le repository, pouquoi pas aussi aux outils de Q&A, à une meilleure exploitation du parallélisme, etc.

Vous me direz, tout ça c'est pour les projets Maven3. Et bien détrompez-vous, je fais mes tests avec un projet qui utilise "officiellement" Maven 2 et je n'ai pour l'instant rencontré aucun problème de compatibilité, que ce soit avec ce shell ou avec la dernière mouture de m2eclipse.

Alors, c'est vrai, Maven 3 ce n'est pas encore pour tout de suite, mais ce n'est plus de la science fiction.

Je viens de lire cet excellent article qui compare le chemin parcouru par Spring et JBoss au travers de la normalisation de leurs technologies par le Java Community Process (JCP).

L'article sait garder un bon niveau de neutralité et expose très clairement ses arguments. Spring a toujours joué les pieds dans le plat et la critique - justifié dans de nombreux cas - alors que la ligne prise par JBoss a toujours été claire vers la normalisation d'Hibenate et de Seam par le JCP.

Si les deux protagonistes n'ont de toute façon pas toujours été très fair-play, il en sort :

• un Seam 3 basé sur les normes de JavaEE6, et une image de JBoss comme moteur sur ce sujet;
• un Hibernate, déjà standard de fait, sorti renforcé par la norme JPA (il y a encore des gens qui ne veulent pas entendre parler d'Hibernate, amusez vous bien les gars ...);
• un Spring 3 qui déçoit pour son peu de contenu (pour ceux qui n'ont que faire d'OSGi en tout cas);
• une norme @Inject qui a le mérite d'exister mais qui fait un peu court. Spring implémente bien cette norme mais elle ne suffit pas à bâtir une application;
• une image déplorable de Spring sur son intervention tardive et polémique dans le JCP. Autant la critique du modèle EJB était argumentée, autant la participation de SpringSource à la JSR JavaEE6 aurait pu être bien plus constructive. C'est bien de taper dans la fourmilière mais au bout d'un moment il faut aussi savoir reconstruire;

Sur l'adoption tardive des technologies par Spring je suis plus réservé. Les dates indiquées semblent montrer un retard à l'allumage de ~3 ans, je ne les met pas en doute, mais ces technologies nécessitent un temps d'appropriation et de maturation. Si Spring s'était jeté sur JSF 1.0 dès sa conception on aurait jamais eu SpringMVC. Le rôle que c'est donné Spring de ce point de vue est de proposer un regard critique et argumenté sur la mise en oeuvre de ces standards, je ne suis pas choqué que ça nécessite un peu de recul.

Quand on parle d'interface web sexy, on pense souvent à Flash. Il faut dire que les années IE6 (qui se prolongent pour certains) ont fait des dégâts pour la réputation de JavaScript et que Flash était la seule solution viable.
Aujourd'hui HTML5 est mature et bien supporté par les navigateurs récents. Le ralliement d' IE 9 est un signe des temps qui montre que c'est bien la plateforme du futur.

OK mais qu'en est-il de la productivité des développeurs ?

Personnellement je suis fan de GWT car il me permet de rester dans le même langage sur toute ma chaîne de développement. Mais ceux qui ont franchi le pas d'apprendre ActionScript et d'acheter FlexBuilder n'ont pas ce genre de considérations.

Je tombe via Ajaxian.com sur ce billet, qui décrit l'abandon de Flash pour HTML5 (canvas). L'intérêt de ce billet n'est pas la prouesse technologique de faire "aussi bien" que la référence Flash - quoi que c'est déjà intéressant pour ça - mais qu'il argumente le pourquoi et les avantages de cette migration.

• moins de code et un "livrable" plus compact. Une bonne baffe pour ceux qui voyaient dans le format binaire de Flash un argument de compacité;
• un meilleur support sous Linux (j'y ajouterais les plateformes mobiles, qui ne sont pas la cible ici);
• une chaîne de production plus simple, en l'absence de phase de compilation;
• une meilleure intégration avec le reste de la page web (événements clavier, gestion du curseur ...)

Cependant, le billet met aussi en évidence les points forts de Flash :

• support des polices de caractères embarquées;
• des manques dans HTML5 sur la manipulation de fragments HTML, le clipping et le rafraichissement

HTML5 n'est donc pas la solution miracle à tous les problèmes (chaque techno passe par une phase où tout le monde y voit le messie avant de comprendre qu'elle a ses limites et ses faiblesses). Par contre c'est une alternative viable et performantes à Flash pour de nombreuses utilisations. Dans certains cas, cela peut même être une solution plus universelle et plus performante (il n'y a toujours pas de lecteur Flash sur l'iPhone à ma connaissance)

Au premiers temps, j'ai géré un "maven_proxy", lequel s'est rapidement noyé sous une masse de jars hétéroclites. Il faut dire qu'à cet époque il n'y avait pas de consensus sur le référencement des apis Java, sans parler de la migration vers Maven2 qui s'est jouée pour nous à cette époque. Il en ressort un répertoire maven_repo avec des doublons, triplets, voir plus (6 versions de EJB2.jar).

Je cherche depuis un moment un outil pour accompagner la revue de code, autre chose que l'impression des listings et le stabilo. Il y a évidemment l'excellente suite Atlassian, mais bien sûr accompagnée de son tarif - sans doute justifié - qui limite sensiblement mes chances de le voir accepté dans la boite à outils standard.

Julien Viet m'a suggéré une évolution sur Fonzie : Utilise le processeur d'annotations (APT) de JavaC à la place du compilo AspectJ.

@Entity
public class User
{
public native void persist();
}

Pour un projet utilisant le JDK6 pour compiler, et sans rien faire sauf ajouter Fonzie-0.4-SNAPSHOT en dépendance, le fichier .class décompilé donne ceci :

@Entity
public class User
{
  public void persist()
  {
      Fonzie.instance();
  }
}

Pour ce premier jet, le code introduit dans la méthode n'est pas passionnant, mais au moins le squelette est en place. Reste à construire via l'AST le code d'invocation Fonzie qui va bien -- et ça, ça va être tout de suite plus toochy.

Microsoft publie le positionnement de IE9 sur le blog MSDN