Microsoft annonce les différentes éditions de Windows 8.

La très bonne équipe de JetBrains livre la version beta de dotPeek (leur décompilateur).

Autre décompilateur; ILSpy est disponible en V 2.

A propos de l’actualité technique, InfoQ nous présente les changements apportés par MEF 2 (présent dans le framework .net 4.5)

MEF 2 qui est également l’objet d’un article sur CodeProject.

Doug Holland nous précise la version de la CLR incorporée à SQL Server 2012.

Toujours à propos de SQL Server 2012, Microsoft livre un Best Practices Analyzer spécifique.

Channel9 propose une vidéo issue de l’évènement Lang.NEXT montrant un exemple d’utilisation du projet Roslyn.

L’équipe de All-In-One Code propose une nouvelle version de la librairie d’exemples de codes sources avec un nouveau browser particulièrement réussi

Du côté de l’actualité française, Guillaume Lacasa débute une série d’articles sur le développement d’applications WinRT avec HTML/JS.

Et enfin pour terminer sur une note “plus légère” Channel9 propose son application Windows 8 qui est plutôt pratique et agréable à utiliser.

Du côté des langages, Stephen Toub a débuté une série de posts sur la gestion de l’asynchronisme proposée par le framework .net 4.5. Il propose entre autres une FAQ sur Async/Await, et un post sur la pertinence de proposer des wrappers synchrones de méthodes asynchrones.

Toujours à propos d’asynchronisme, Kavya Kotacherry nous montre comment elle résolu un problème de réactivité d’une application WPF grâce à Async et Await.

James Michael nous donne quelques informations sur les méthodes Take et Skip et consors.

Du côté des outils, Brian Harry nous présente l’intégration de Preemptive Analytics dans TFS 11.

Et enfin côté produits, l’équipe de WCF Data Services annonce la disponibilité de la version 5 en RTM avec entre autres le support d’un plus grand nombre d’opérateurs, des types spaciaux, etc.

La confirmation officielle se trouve dans la MSDN avec une explication bateau qui tire plus du marketing que de la véritable explication technique : http://msdn.microsoft.com/en-us/library/cc656912(v=vs.110).aspx

Ce profil permettait de disposer d’un profil de framework très légèrement plus léger destiné au développements d’applicatifs clients (exit donc ASP.net, la couche serveur WCF, etc.).

Un des principaux avantages étant que cette version du framework .net était préinstallé sur les OS les plus récents, ou inclus dans des mises à jour via Windows Update.

Il ne reste plus qu’à espérer que le framework 4.5 soit installé d’office sur les prochains OS de Microsoft à commencer par Windows 8.

L’analyse du code a pris 3h30. Le temps d’analyse pour un aussi gros volume de code est certes important mais ne me choque pas plus que cela. Je suis plutôt surpris par le fait que la machine ne soit pas “à genoux” durant l’analyse mais ne soit occupé qu’à  20% au niveau du CPU sachant qu’il ne semble pas y avoir d’autres goulots d’étranglements (mémoire, disque).

Les résultats sont classés en 4 catégories : exact match, strong match, medium match, weak match.

L’analyseur indique que 25% du code semble être du doublon (et peut donc être quasi-supprimé suite à du refactoring) soit dans mon cas plus de 150 000 lignes de code. Je sais que le code est très loin d’être optimisé et qu’il y a beaucoup de redondance de code mais ce résultat est pour le moins plutôt étrange…

J’ai vite été conforté dans mon impression en analysant la qualité des résultats. J’ai commencé l’étude par l’analyse des weak match.

Je n’ai pas réussi à trouver un résultat à peu près pertinent dans les weak match.

Un des exemples typiques concerne ce type de code :

Le moteur d’analyse prend en compte uniquement le texte et non pas le vocabulaire en lui-même et trouve donc des clones qui ne sont pas du tout pertinents.

Autre exemple avec l’initialisation “en masse” d’objets, l’affichage de ce type de résultat n’est pas forcément pertinent :

Les bonnes nouvelles se retrouvent plutôt au niveau des correspondances exact ou très voisines :

J’ai été ainsi surpris de découvrir qu’un même bloc de code a été repris 58 fois ( ! ) au sein de l’applicatif.

Une séance de refactoring va donc pouvoir être planifié afin d’éliminer cette redondance ainsi que les suivantes.

En résumé, cette nouvelle fonctionnalité est plus proche de l’analyseur de texte que de l’analyseur de code car le vocabulaire n’est pas pris en compte de manière pertinente. Et il ne faut pas se fier au grand nombre de résultats potentiels affiché mais faire un filtre et une analyse de ceux-ci afin de décider des actions à mener pour améliorer la qualité du code.

Si l’on prend un exemple simple :

Un clic sur le menu Analyze, Analyze Solution for Code Clones permet de lancer une analyse sur le code source de l’intégralité de la solution et d’afficher un nouveau panneau :

Il est ensuite possible de naviguer dans les blocs de code détectés afin de refactorer et donc d’améliorer la qualité du code.

A noter que l’outil ne permet pas d’uniquement trouver les blocs de code strictement identique mais permet de faire des analyses légèrement plus poussées. Le nommage des variables n’est par exemple pas pris en compte, si la structure du code est voisine avec des noms de variables différents, la fonctionnalité sera capable de trouver des résultats pertinents.

Point qui peut être intéressant, l’analyse se fait bien sur le code source et non sur l’IL, il n’est donc pas nécessaire que le code compile pour lancer la détection (oui, je sais; c’est tordu mais c’est toujours bon à savoir ).

Inconvénient, l’analyse se faisant sur la structure du code source, l’outil n’est pas capable de détecter du code identique  fonctionnellement mais pas syntaxiquement.

Par exemple le code suivant ne renvoie aucun résultat :

A noter que la fonctionnalité ne se concentre que sur des blocs d’une 10 de lignes de code uniquement, les blocs plus petits ne sont pas détectés.

De plus; il est possible de lancer une analyser afin de rechercher des clones d’un bloc de code en particulier. Il suffit pour cela de le sélectionner et de sélectionner le bon élément dans le menu contextuel pour y parvenir.

Et sur du vrai code ? J’ai lancé l’analyse sur l’application sur laquelle je travaille (plusieurs centaines de milliers de lignes de code) et j’attends le résultat depuis 2 heures !

Grosse déception, le moteur d’analyse ne semble à priori pas multithreadé. Sur mon quad-coeur, le process de VS 11 tourne en moyenne à 20%, la consommation mémoire reste à peu près stable, et les accès disque sont faibles. Le CPU semble donc être le goulot d”étranglement…

Après 2 heures d’analyse, cela progresse lentement… mais surement… Je mettrais à jour ce post si cela se termine un jour !

Je vous propose donc aujourd’hui 3 bonnes raisons d’utiliser différents frameworks de tests :

• La possibilité de réutiliser, sans migrer, des tests existants tout en switchant (pour tout ou partie) les nouveaux tests sur un nouveau framework. Vous appréciez l’intégration de MS Test mais ne supportez pas le non respect du pattern AAA pour les tests liés à la gestion d’exception ? Continuez d’utiliser MS Test, et utilisez un autre framework comme xUnit qui vous permettra d’avoir des tests de meilleure qualité.
• Le support de frameworks de tests ciblants différents langages. Exemple : Je développe un site web ASP.net et je souhaite créer et exécuter des tests unitaires et d’intégration pour mon code VB ou C# mais également pour du code javascript. Je peux donc utiliser à présent MS Test, xUnit, nUnit ou autres pour le code managé, mais également Chutzpah pour les tests du code JS.
• Le support de frameworks de tests proposant différents types de tests. On utilise en effet généralement un seul et même framework pour développer tests unitaires et tests d”intégration, mais il existe d’autres types de framework permettant d’écrire des tests se rapprochant au plus près de la définition des spécifications (comme MSpec), ou proposant une syntaxe naturelle pour les assertions. Il est donc possible de les utiliser de manière complémentaire avec les frameworks plus “traditionnels” avec Shoudly par exemple.

Il est à présent possible d’exécuter les tests présents dans votre solution de manière automatique juste après une simple compilation.

Un petit Ctrl+Shift+B et une fois la compilation réussie l’exécution de tests se lance :

A noter qu’une sélection des tests à exécuter est réalisée par Visual Studio. Contrairement à mon screenshot qui présente un cas simple, Visual Studio 11 décide quels tests sont à exécuter en priorité. Ceux qui ne sont pas exécutés se retrouvent avec une icône légèrement grisée afin d’indiquer qu’ils n’ont pas été ré-exécutés.

Une des nouveautés les plus intéressantes concerne le support de différents frameworks de test directement dans Visual Studio 11.

Il était bien évidemment possible de développer des tests unitaires et d’intégration en utilisant d’autres framework que MS Test, mais l’utilisation de ces frameworks nécessitaient jusqu’à présent l’utilisation de tests runners dédiés ou génériques plus ou moins bien intégrés avec Visual Studio. Une des références dans le domaine est le test runner de ReSharper qui permet d’exécuter des tests MS Test mais aussi des tests nUnit.

Visual Studio 11 propose à présent d’intégrer simplement n’importe quel framework de tests via une API qui permet de développer des adapters.

En autres mots, le test runner de Visual Studio 11 est à présent totalement découplé de MS Test.

Prenons comme premier exemple, une classe bateau :

Si vous avez installé xUnit, vous pouvez à présent installer le runner de xUnit compatible avec Visual Studio 11. Ce test runner n’est pas un test runner indépendant, il s’agit en réalité d’un simple adapter qui permet de se plugger au test runner de Visual Studio 11 :

Il est évidemment possible de créer un test en suivant les principes de ce framework :

Et lorsque l’on exécute le test, on retrouve ensuite le résultat de ce test directement l’explorateur de tests de VS 11.

Ce qui rend encore plus intéressant avec cette ouverture vers d’autres frameworks de tests, est qu’il est tout à fait possible de créer des tests en utilisant d’autres frameworks de test tout en restant dans le même projet !

Ainsi l’ajout d’un test basé sur MS Test :

permet d’avoir directement le résultat de ce test intégré avec les autres tests :

Fini donc les frustrations d’utiliser tel ou tel framework de test, ou les potentielles difficultés de switcher vers tel ou tel framework de test, il est possible d’utiliser simultanément ceux qui vous conviennent le mieux !

Et bien évidemment, l’outil de couverture de code de Visual Studio 11 prend en compte l’intégralité des tests :

Vous pouvez consulter la liste des adapters déjà disponibles sur ce lien, à savoir que d’autres adapters pour d’autres framework devraient arriver très prochainement.

C’est donc avec grand plaisir que j’ai découvert la “Siren Of Shame”.

Ce gadget est en réalité constitué de deux parties :

• L’élément visible qui est le gyrophare USB qui s’installe en 1 clic de souris
• Un outil de monitoring qui est capable de se connecter aux principaux serveur d’intégration continue du marché (TFS, Team City, Cruise Control.net, etc.)

L’objectif est simple : alerter de manière visuelle et sonore dès qu’une build est cassé pour la réparer au plus vite.

L’installation du logiciel se fait de manière très simple et la configuration est également aisée. En 5 minutes, le système est fonctionnel et nous sommes capables de tester les différents styles de lumière (gyrophare tournant, fondu de lumière, etc.) et de définir jusqu’à quand nous souhaitons avoir les signaux sonores et lumineux (signal pendant un laps de temps défini ou jusqu’à ce que la build soit réparé, etc.).

L’outil propose de plus 3 fonctionnalités intéressantes :

• Un tableau de bord permettant de voir l’état de toutes les builds
• Un outil de réputation qui permet d’avoir une liste triée des développeurs selon un ratio nb de buils/nb de builds échouées
• Un graphique simple d’analyse de l’état d’une build

Un outil donc fort simple, qui fait uniquement ce qu’on lui demande sans trop de fioritures.

Avant de vous décrire mon retour d’expérience du système (cela fait un mois que nous l’avons à présent adopté), je vais vous retracer l’historique de la mise en place du serveur de build dans le service afin de bien décrire l’intérêt d’utiliser ce type de gadget et l’effet obtenu.

Pourquoi un serveur de build ?

Une de mes premières actions lors de mon arrivée à Log’in Space il y a maintenant 1 an a été d’analyser l’environnement de développement pour voir comment il était possible de rendre l’équipe plus efficace.

Le service développement fait très fréquemment des releases des différents produits, la création d’une version prenait alors environ 1h lorsqu’il n’y avait de problèmes, et durait beaucoup plus lorsque un problème de compilation non détecté avait lieu.

Les développeurs avaient l’habitude d’effectuer leur checkin après avoir terminé sans forcément faire de getlatest réguliers. Le code présent sur le source control était différent de celui présent sur les postes de développement et de temps en temps il arrivait que le responsable de la release ait une surprise en essayant de compiler le résultat final…

Afin de résoudre ce problème et être beaucoup plus réactif en cas de problème (ie. ne plus être devant le fait accompli mais réagir dès qu’il y a un problème) un serveur de build sous Team Build a été mis en place.

La première étape a été de simplement automatiser la création d’une version, puis de mettre en place de l’intégration continue (plus proche actuellement de la compilation continue). Ainsi chaque développeur est abonné aux alertes proposées par TFS, et est ainsi notifié de la réussite ou de l’échec de la build déclenché par son check-in. De plus l’automatisation a permis de réduire le temps de création d’une version à 15min.

Il s’agit d’un progrès dans le sens où l’on est beaucoup plus réactif mais il me restait à arriver à sensibiliser l’équipe sur le fait de vraiment prêter attention à avoir un code correct et fonctionnel dans le source control, afin d’avoir le plus rarement possible un code invalide.

Et cet objectif a été atteint grâce à la sirène. Les membres de l’équipe souhaitant éviter que la sirène ne s’allume, ils pensent à présent bien aux risques apportés par leur check-in avant de faire leur commit ! La sirène est en effet mise en avant et bien visible de tous, il n’est donc pas nécessaire qu’elle s’allume pour que tout le monde ait conscience de sa présence.

Encore un (tout petit pas) de franchi vers une meilleure qualité logicielle et vers moins de stress pour l’équipe !

Il reste bien évidemment de gros progrès à accomplir  comme l’intégration de l’exécution de tests automatisés par exemple, mais il s’agit d’une évolution qui va dans le bon sens.

Les + et les -

Les +

• Outil simple à mettre en œuvre, qui fait uniquement ce qu’on lui demande
• Une API est disponible pour piloter la sirène dans d’autres contextes que l’intégration continue

Les -

• Lorsque deux builds échouent “en même temps”, les signaux s’arrêtent lorsqu’une des builds a été réparé et non lorsque l’ensemble des builds ont été réparés
• Très légers bugs dans l’affichage des changesets liés aux builds lors de check-in très rapprochés

Les risques

J’ai pu identifier deux risques durant ce premier mois d’utilisation.

Le premier concerne les prestataires intervenants sur un de nos projets. L’un deux a eu la bonne idée de casser et de réparer la build entre midi et deux. L’équipe étant en train de déjeuner la sirène a été d’une totale inefficacité ! Il peut être intéressant de garder le système d’alertes afin d’avoir un réel suivi des builds.

Second risque : Si vous mettez Kool & The Gang au bureau afin de mettre un petit d’ambiance, il se peut qu’un membre de votre équipe vous propose d’allumer le gyrophare en cassant une build histoire d’avoir une ambiance son et lumière (oui, oui c’est du vécu…)

C’est avec une grande curiosité et avec impatience que je me suis inscris voilà il y a quelques semaines à la première édition d’un évènement TEDx à Toulouse.

Pour ceux d’entre vous qui ne connaissent pas TED (honte à vous, comme gage vous êtes obligé de passer les 3 prochains jours à regarder des TED Talks), l’objectif des conférences TED est de partager des idées intéressantes/intelligentes/pertinentes (“Ideas worth spreading”) au travers de courtes présentations très souvent de très haut vol. Ces conférences sont très peu accessibles car le ticket d’entrée est assez élevé et l’organisation effectue une sélection des participants en fonction de leur implication, de leur rôle dans la société.

Des conférences peu accessibles en IRL mais très facilement accessible grâce au site http://www.ted.com qui propose des vidéos de certaines de ces sessions.

Je vous propose par exemple une de mes vidéos préférées présenté par MONSIEUR Hans Rosling :

Ce site fournit un contenu d’une excellente qualité autour de sujets qui touchent aux sciences, aux technologies, et aux arts. C’est un must-have pour tous les curieux qui cherchent à comprendre le monde dans lequel on vit et qui ont l’esprit ouvert.

Depuis quelques années, TED propose d’organiser des conférences sous licence, des TEDx afin que tout un chacun puisse accéder à ces évènements qui ont donc tous le même objectif.

J’ai donc eu la chance de pouvoir participer aujourd’hui au TEDxPlaceDuCapitole qui avait lieu dans le magnifique cadre de l’hôtel dieu.

Je ne vais pas ici vous raconter l’ensemble des différentes sessions de très bon niveau auxquelles nous avons pu assisté mais plutôt citer très rapidement les sessions que j’ai préféré :

• Damien Jayat qui présentait son métier de médiateur scientifique. Le fond n’était pas forcément d’un remarquable intérêt mais il s’agit d’une des meilleures session d’un point de vue de la forme ce qui en a fait une présentation très plaisante à regarder, et une très bonne mise en bouche pour la suite de l’après-midi.
• Clément Blanchet avec une présentation qui traitait de l’impact de la modernité sur l’architecture. J’ai été très surpris d’être intéressé par ce type de sujet. Le speaker était vraiment très bon, et son parti pris pour le style de la présentation était efficace.
• Pierre Olivier Carles qui présentait une session sur la volonté d’entreprendre.
• Nicolas Lassabe et sa présentation sur les imprimantes 3D et sur les FabLabs.
• Daniele Di Michele et son excellente présentation sur la cuisine populaire. Rafraichissante et intéressante sur le fond, un vrai régal.

Je ne vous décrit pas plus ces présentations car elles seront prochainement disponibles online.

Cet évènement n’a pas répondu à mes attentes, il les a surpassé. La qualité de l’organisation était exceptionnelle pour une 1ère. Il n’y avait vraiment à redire, la qualité des sessions était généralement très bonne, et même le buffet était excellent !

Félicitations donc à l’équipe organisatrice, je vous souhaite bon courage pour trouver les axes d’amélioration, ce premier défi est pleinement réussi, le plus difficile vous attend à présent : arriver à confirmer via une 2de édition en proposant un nouvel évènement d’une aussi bonne qualité.

Pour en savoir plus sur TEDx Place Du Capitole :
Le site officiel
La page facebook
Le ScoopIt de l’évènement