Denis Dollfus' Blog

Microsoft rend .Net open-source

Bon ok juste une petite partie puisqu'il s'agit de .Net Micro Framework, le sous ensemble dédié aux systèmes embarqués. Mais c'est loin d'être anodin puisque la licence choisie n'est pas une variante à la sauce Microsoft, mais une licence Apache 2.0.

Un pas de plus vers l'open-source authentique, à l'image du mea culpa de Peter Galli, le monsieur open-source de Microsoft, pour une affaire de licence GPL bafouée ?

L'annonce sur port25 : http://port25.technet.com/archive/2009/11/16/microsoft-to-open-source-the-net-micro-framework.aspx

Un nuage d'oiseaux en Silverlight

Je suis fasciné par le comportement des oiseaux qui volent en nuage. Je suis capable de contempler béatement ce genre de méta-créature pendant de longues minutes :

Du coup je me suis amusé à développer en Silverlight une simulation (stricto sensu, c'est plus une animation qu'une simulation -- il faut bien ergoter de temps en temps pour justifier 'ergotinfo') d'un nuage de 300 oiseaux et à l'ajouter à la bannière de ce blog. Si vous n'avez pas Silverlight, cette vidéo peut vous donner une idée de l'animation :

L'animation consomme goulument du processeur, j'ai donc ajouté un bouton marche/arrêt en bas à gauche de la bannière :

Ca marche bien sous Firefox, Internet Explorer et Opera. Chrome a un bug connu de gestion de la transparence qui pose quelques problèmes d'affichage (fond noir au démarrage, titre partiellement caché) mais bon ça passe.

La prochaine fois, je tente de simuler une autre merveille de la nature, un réseau de vers annelés qui se comporte comme un organisme doté de muscles, de nerfs, de capteurs de niveau d'eau, etc. La nature peut nous surprendre jusque dans les égouts. C'est juste un peu moins photogénique.

Facebook : sortie de Microsoft Facebook SDK

Si certains n'y croient plus, Facebook reste la plate-forme sociale la plus bruyante du moment, au point que même les présidents de la République communiquent sur Facebook.

Pour se joindre au mouvement et développer des applications Facebook, il existe une nouvelle solution dévoilée hier par Microsoft, le Facebook SDK, qui vient compléter les autres API existantes :

"Le point d'entré principal est la classe 'API' (Facebook.Rest.Api) de l'assemblée Facebook.dll. Cette classe encapsule les API REST de Facebook et fournit une interface simple d'emploi pour invoquer les différentes méthodes actuellement exposées par les API Facebook. Nous avons aussi fourni des exemples et des outils pour aider au développement d'applications Facebook pour les diverses plate-formes .Net, notament ASP.NET, Silverlight, WPF et Winforms."

Liens :

• Microsoft Facebook SDK
• L'annonce sur le blog de l'équipe Silverlight

Cloud computing : comparatif Amazon-Google-Microsoft

Marc Bojoly vient de publier sur le blog d'OCTO un comparatif des trois principaux acteurs du cloud computing, On y trouve donc Amazon Web Services, Google App Engine et Microsoft Azure résumés par un schéma très clair structuré en couche d'infrastructure, de services, de développement et couche applicative :

• AWS, le Cloud d'Amazon
• GAE, le Cloud de Google
• Azure, le Cloud de Microsoft
• Comparatif des tarifs

Autres billets intéressants (et récents) sur le blog d'OCTO :

• Un démontage soigneux de la métaphore de l'usine logicielle par Yannick Martel
• Un comparatif Flex/Silverlight par David Rousselie
• Une étude d'un cache objet distribué, Memcached, par Olivier Mallassi.

(Grosse parenthèse)

En fait dans le domaine de l'architecture et dans le monde francophone, je trouve le blog d'OCTO incontournable compte tenu de la diversité des sujets abordés et du ton calme et réfléchi qui contraste avec l'enthousiasme geek si répandu dans les blogs high-tech.

Mais je suis loin d'être expert blogologue, je suis certainement passé à côté d'autres bons blogs à lire. Quels blogs conseilleriez-vous ?

(Fin de la grosse parenthèse, et déjà la fin du billet arrive qui me laisse juste le temps de déconseiller en passant aux blogueurs débutants (réservé aux pros) de traiter de plusieurs sujets dans un même billet, c'est pire que d'abuser des parenthèses (personnellement je raffole de parenthèses imbriquées ça me rappelle vaguement le LISP (dont j'ai tout oublié)))

WPF : les nouveautés de .Net 4.0

Illustration. C'était ça ou un screenshot de DataGrid.
CC Chaval Brasil.

Scott Guthrie vient de détailler sur son blog les nouveautés WPF qui viennent avec .Net 4.0. Condensé de son billet.

Nouveaux contrôles : 

• DataGrid, DatePicker, Calendar. Ces contrôles sont API-compatibles (à 99% précise-t-il) avec leurs équivalents Silverlight. 
• D'autres contrôles vont être distribués hors .Net, notamment les ColorPicker, InfoTextBox, ListPager, etc., ainsi qu'un ruban skinable à la Office 2007.

Graphiques :

• Les performances du rendu devraient être améliorées avec un cache de composition qui allège le travail du CPU et GPU. A tester.
• Effets graphiques sophistiqués via le support de Pixel Shaders 3.
• Désactivation possible de l'antialiasing de l'UI via la propriété UseLayoutRounding. Devrait supprimer cette sensation de flou qui caractérise les applications WPF. Voir aussi plus bas pour le rendu des textes.
• Début et fin d'animation prédéfinies ("easing functions"). On s'attend à des abus de rebonds élastiques, exponentiels, circulaires, etc.

Textes :

• Il suffisait d'être patient : les applications WPF ne pourront plus se faire chambrer à propos de l'apparence floue de leurs textes. La propriété attachée TextFormattingMode est la bienvenue :

 

• Les documents textes (les Run des FlowDocument) deviennent bindable.
• La correction automatique (soulignement rouge) accepte des dictionnaires personnalisés.

Windows 7 

• Support du multitouch (en français polypalpitude).
• Support des spécificités du shell de window7 : jump list, icon overlays, barre d'outils des vignettes.

Fondements de WPF

• Refonte du parser XAML et du chargement BAML (XAML compilé).
• Support des types dynamiques lors du data binding.
• Ajout du Visual State Manager déjà inclus dans Silverlight.
• Accès au DOM HTML depuis une application XBAP.
• Support des contrôles virtualisés pour l'automatisation de l'interface graphique

Déploiement

• Support d'une version allégée de .Net pour les applications WPF -- .Net Client Profile.
• .Net Client Profile supporte tous les OS cibles

Plus d'infos sur le billet original de Scott Guthrie : http://weblogs.asp.net/scottgu/archive/2009/10/26/wpf-4-vs-2010-and-net-4-0-series.aspx

Les mythes de l'ingénierie logicielle disséqués

Parfois la raison des informaticiens, d'ordinaire patiente et affutée, s'évanouit quand le problème à résoudre s'éloigne de la routine booléenne pour s'aventurer dans les pièges de la rhétorique, la manipulation marketing et l'enthousiasme geek. 

Ainsi sent-on l'hystérie poindre quand les discussions abordent des points chauds comme :

• Y gagne-t-on vraiment à développer en TDD ?
• Les cheveux poussent-ils plus vite quand on les coupe ?
• Faut-il tout tester pour que ce soit utile ?
• L'intelligence est-elle innée ou acquise ?
• Un développeur expérimenté vaut-il deux développeurs débutants ?
• Faut-il, pour préserver la planète, préférer les mugs aux gobelets jetables ?
• Quel est l'impact des "assert" sur la qualité du soft ?
• Les fabriquants d'OGM ont-ils un intérêt à infléchir dans leur intérêt les études de toxicité qu'ils ont obligation de mener ?
• Peut-on faire du bon logiciel avec des équipes réparties aux quatre coins de la planète ?

Sûrement, chacune de ces questions réveillera vos déjeuners d'équipe malgré les rhumes de saison. D'ailleurs si vous en connaissez d'autres, n'hésitez pas à commenter. Mais ne pourrait-on pas aborder ces débats sous un angle rigoureux, scientifique, avec mesures et analyses, hypothèses et déductions ?

C'est justement le sujet de recherche des chercheurs de l'ESM (Empirical Software Engineering and Measurement Research Group) de Microsoft, qui curieusement s'en tiennent aux questions d'ingénierie informatique.

Ci-dessous quelques résultats de leurs travaux qui mettent les points sur les ı (ou les suppriment des ï, c'est selon -- notez en passant que le caractère unicode 305 a été inventé juste pour pouvoir écrire "mettre les points sur les ı").

To unit-test or not to unit-test ?

Le taux de couverture des tests est moins déterminant vis-à-vis de la qualité du produit (mesurée en nombre de bugs découverts après livraison) que le niveau de complexité du code testé et le niveau d'utilisation de ce code par le client.

Les équipes qui travaillent en TDD produisent du code supérieur (en termes de densité de bugs) de 60 à 90% au code produit par du développement non TDD. En contrepartie les projets TDD durent de 15 à 35% plus longtemps. Cf.http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

To assert or not to assert ?

L'usage intensif d'assertions réduit le nombre de bugs.

L'impact des assertions sur la qualité du produit est d'autant plus grand  que les développeurs sont expérimentés.

To fragment or not to fragment ?

Le degré de morcellement de la R&D est un facteur de bugs plus important que le niveau de "churn" du code, sa complexité ou son taux de couverture. Cf. The Influence of Organizational Structure on Software Quality: An Empirical Case Study.

L'éloignement des équipes impacte peu la qualité. Cf. Does distributed development affect software quality? An empirical case study of Windows Vista.

Source : Exploding Software-Engineering Myths. (exploding or exploring ?)

Microsoft participe au middleware orienté messages de la fondation Apache

Jusqu'il y a peu les middleware orientés messages (ou MOM pour Message Oriented Middleware) qui répondaient aux besoins des entreprises étaient pour l'essentiel développés et commercialisés par des grands éditeurs : IBM avec WebSphere MQ, Microsoft avec MSMQ et Oracle avec AQ.

Le projet Apache Qpid vise à remédier au manque d'ouverture de chacune de ces solutions propriétaires en proposant une implémentation open-source du standard ouvert AMQP (Advance Messaging Queuing Protocol) :

Apache Qpid implements the latest AMQP specification, providing transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support and a lot more. And Apache Qpid is extremely fast. Apache Qpid aims to be 100% AMQP Compliant.

Du côté des contributeurs d'AMQP, on trouve des noms comme Barclays Bank, Credit Suisse, Deutsche Börse Systems, Goldman Sachs, JPMorgan Chase. C'est du sérieux.

Microsoft, qui a compris l'intérêt de l'open-source depuis quelques mois déjà, participe au projet pour permettre aux développeurs .Net d'exploiter facilement Qpid, notamment via WCF (Windows Communication Foundation). Sandy Gupta, responsable de ce projet chez Microsoft :

What we've done is a Windows Communication Foundation (WCF) Channel for AMQP. Our goal is to provide a first class AMQP experience for the .NET developer. And, since this is an Apache project we're talking about, all our code is obviously open source.

Pour en savoir plus : http://port25.technet.com/archive/2009/09/29/contribution-without-a-thud.aspx

Google Chrome Frame fissure l'unité d'HTML

Jusqu'il y a deux jours, les fondements du Web étaient simples. Le HTML était un standard normalisé par le W3C et les éditeurs proposaient des navigateurs qui géraient au mieux les différentes générations du standard.

Les responsabilités respectives du développeur et de l'utilisateur étaient claires. Le développeur travaillait à rendre le HTML et le JavaScript le plus indépendant possible des déclinaisons HTML des éditeurs, et l'utilisateur choisissait librement son navigateur.

Aujourd'hui ça n'est plus le cas, le webmaster peut suggérer au navigateur une méthode pour traiter et afficher son contenu. Plus même qu'une suggestion, le développeur choisit pour l'utilisateur. Le prétexte technique provient de l'introduction par Microsoft d'une balise <meta> destinée à faciliter la gestion de la compatibilité d'Internet Explorer (IE) 7 et 8 :

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Google l'a rapidement détourné en publiant Google Chrome Frame, extension d'IE qui remplace le moteur de rendu d'IE par celui, plus rapide et plus fidèle à HTML 5, de Chrome. Les développeurs deviennent prescripteurs du moteur de rendu de Chrome en ajoutant la ligne suivante à leurs pages Web :

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Avec Chrome Frame installé, toute page Web chargée par IE et qui contient cette ligne est en réalité traitée par Chrome au sein d'IE. Chrome dans IE c'est plutôt une bonne chose pour les internautes. Moi qui suis plutôt familier des outils Microsoft, j'ai adopté Chrome sans tergiverser tant Chrome apparaît rapide et léger comparé à IE. Google Chrome Frame va donc donner un coup de jeune à IE -- qui peut même y gagner. 

Ce qui est gênant c'est que cet évènement sonne la fin du HTML et le début des HTML. Pour la première fois le HTML quitte la voie "a-navigateur" et peut prendre parti pour un dispositif de rendu. La guerre entre éditeurs se diffuse côté serveur et affecte le HTML.

Va-t-on, par cette astuce technique, assister à une explosion de jargons HTML visant chacun une version de navigateur ? Faudra-t-il installer tous les navigateurs du marchés pour tout voir du Web ?

Mise à jour du 30 septembre. Mitchell Baker, président de la Mozilla Foundation, va dans le même sens. Il voit dans Google Chrome Frame un danger de fragmentation des technologies du Web et de perte de contrôle des utilisateurs : 

Imagine having the Google browser-within-a-browser for some sites, the Facebook browser-within-a-browser for Facebook Connect sites, the Apple variant for iTunes, the mobile-carrier variant for your mobile sites — all injected into a single piece of software the user thinks of as his or her “browser”. Each browser-within-a-browser variant will have its own feature set, its own quirks, and its own security problems.

L'Agile Tour 2009 commence le 1er octobre

Les experts des méthodes Agiles partageront leur vision de l'agilité et répondront à vos questions durant tout le mois d'octobre et dans toute la France.

Pardon, dans le monde entier ! Cette année l'Agile Tour s'étend à la Chine, les Etats-Unis, la Suisse, le Canada, le Luxembourg...

Il est grand temps de réserver vos dates. Pour en savoir plus, cliquez sur l'image.

DotWeb : commémoration du premier anniversaire de la disparition de Volta

Il y a un an jour pour jour le projet Volta s'arrêtait brutalement malgré un accueil enthousiaste. Volta proposait (très) ambitieusement des outils pour faciliter le codage et le déploiement des applications Web n-tier. Dans une approche très "write once run anywhere", le même code C# aurait pu être déployé sur le serveur ou sur le client, la même IHM aurait pu se matérialiser en Ajax ou en Silverlight.

Dans la série "On Trouve Tout Sur le Web" : le tombstone generator

Je suis plutôt circonspect sur le côté "write once run anywhere" tant les problématiques de performance et de cache, pour ne citer que celles-là, diffèrent suivant l'endroit où le code s'éxécute. 

En revanche le fait de pouvoir écrire en C# ce qui tournera en Javascript promettait confort et productivité. Non pas que le Javascript soit une ignominie, mais simplement que les outils d'assistance au développeur sont bien plus élaborés en C# qu'en Javascript de par le simple typage fort de C#. L'auto-completion, le refactoring semi-automatique et l'orientation objet structurante (i.e. getter et setter ) suffisent à faire la différence. 

Aborder une grosse application Ajax en C# plutôt qu'en Javascript rassure. En C# "si ça ne compile pas, ça ne marchera pas" dit le dicton. En JavaScript puisqu'il n'y a pas de compilation, il reste "ça ne marchera pas". J'ironise mais tous les développeurs qui parcourent le Web en mode "debug" savent au nombre d'erreurs de script rencontrés combien le JavaScript fait souffrir le Web. 

Bref. Y a-t-il une vie après Volta ?

Oui :

1. Il y a mieux que Volta, il y a Script#, bien supérieur à Volta parce que lui n'est pas mort. Script# a servi en interne chez Microsoft au développement d'Office 14 version Web, de Live Messenger et de Live Mesh. Script# marche bien, les contributions (ExtJS#, jQuery#) en témoignent. Un avantage de Script# est que le Javascript généré est parfaitement lisible. En revanche pas moyen de poser un point d'arrêt au sein du C#, il faut débugger en JavaScript. Néanmoins cette approche permet déjà de concevoir Javascript comme le langage assembleur du Web : un truc réservé aux experts, bien compris des machines mais peu des humains, qu'on a vu à l'école et qu'on oublie sans remord (pas .
2. Il y a mieux que Script#, il y a Google Web Toolkit (GWT). Avec un succès grandissant, GWT est de plus en plus utilisés dans les applications de taille respectable. Google Wave notamment repose sur GWT. Pour fixer les idées concernant sa popularité, d'après Google Trends GWT est presque aussi populaire que Linq. Au fait : au lieu de C#, GWT s'appuie sur Java. Gros avantage par rapport à Script#, GWT permet de debugger directement dans le code Java, plus besoin de visualiser le JavaScript, qui n'a désormais plus vocation à être lu et a fortiori édité.
3. Pour info le précurseur de ses outils s'appelle Morfik, toujours commercialisé. Je ne le connais pas.
4. Encore plus fort, pendant que je préparais ce billet qui aurait du être un simple hommage à feu Volta, Franck Laub annonce sur le forum Alt.Net l'existence de son projet de clone .Net de GWT, DotWeb. DotWeb est le seul environnement dans l'esprit "JavaScript est l'assembleur du Web" qui dispose d'un debugger C#. A suivre de très très près ! Franck recherche des contributeurs, c'est une opportunité pour des développeurs intéressés. Les sources de DotWeb, pour en avoir le coeur net,  sont disponibles ici.

Excellent timing !