Après la partie desktop de .Net, et au moment où l'adoption grand public de Silverlight devient bien visible dans les stats, c'est au tour de Silverlight 4 d'être livré par Microsoft.
Les nouveautés de Silverlight 4 sont nombreuses, et certaines probablement décisives pour l'adoption en entreprise :
Gestion de l'impression;
Nouveaux contrôles dont textboxes avec masque de saisie, datagrid avec colonnes redimensionnables et repositionnables;
La CLR autorise une même dll à tourner en mode desktop et en mode Silverlight sans recompilation
Amélioration de l'internationalisation -- écriture bidirectionelle, nouveaux langages tels qu'arabe et hébreux (plus 31 autres) -- entre nous, déjà géré par WPF 3.5 SP1;
Enrichissement des outils "point & click" avec Visual Studio 2010;
WCF RIA service inclus dans le package Silverlight;
Prise en charge des webcams et microphones;
Interopérabilité COM;
Support de la vidéo au format H 264
... et pas mal d'autres nouveautés intéressantes dont la plupart sont listées sur cette page que je vais arrêter de traduire -- évidement ça donne un net avantage à ceux qui lisent l'anglais, et une opportunité de commencer à apprendre pour les autres, of course, it goes of itself.
Une autre page de référence concernant les nouveautés se trouve sur le blog de Tim Heuer, ainsi du reste que l'annonce de la disponibilité de Silverlight 4.
A l'heure de la mise à disposition par Microsoft de Visual Studio 2010 et .Net 4, Peter Brown vient de publier sur son blog une synthèse des nouveautés de WPF 4 : WPF 4 Release: A guide to the new features
Enfin au cas où vous chercheriez l'exhaustivité à propos des nouveauté de .Net 4, mieux vaut aller lire à la source : What's New in the .NET Framework 4 sur MSDN.
Tous ceux qui touchent de près ou de loin aux arts numériques, et pas seulement les algoristes, connaissent bien Processing, langage open-source dédié à la manipulation d'éléments graphiques.
Processing jouit en effet d'un quasi monopole pour toute sortes de travaux autour de la visualisation, qu'il s'agisse de prototypes de visualisation de données scientifiques, d'ébauches artistiques abstraites, d'animations interactives (quoique dans le domaine de l'interactif Flash semble bien plus populaire) ou de tout ça en même temps.
La preuve en image pendant un petit entracte Processing (cliquez pour trouver l'auteur) :
La domination de Processing pourrait bien être prochainement challengée. Microsoft va en effet offrir une technologie concurrente à travers un nouveau langage, Vedea, tout juste sortie des labos (ce qui ira, comme prévu, incrémenter notre compteur de langages).
Processing et Vedea sont des langages dédiés à la définition, à l’animation et au contrôle d'éléments graphiques. En quelque sorte un DSL (Domain Specific Language) dont le domaine de pertinence est la visualisation. Le plus de Vedea c’est de permettre à l’artiste-développeur (mais tous les développeurs ne sont-ils pas des artistes ? Ah non) de composer, de tester et d’expérimenter avec le moins d’efforts possible.
Deuxième entracte...
Comparé à Processing, Vedea possède quelques points forts.
Rendu en mode "retenu" (retained mode).
Alors que le mode dit immédiat (immediate mode) de Processing impose de dessiner explicitement les éléments graphiques à chaque appel d'une méthode de type draw() -- comme avec le Canvas d'HTML 5, Vedea permet en plus de construire une scène et de confier le rendu au moteur -- comme avec WPF et Silverlight.
Un objet peut être parenté à autre objet. Dans ce cas la modification de certains propriétés du parent affectera ses descendants (transformations, coordonnées, etc.). Un peu comme une hiérarchie de Canvas sous Silverlight en somme.
Bon c'est le dernier hein :
Binding bi-dimensionnel trop fastoche
Vraiment bien. Voilà un binding mono-directionel, du slider vers la textbox :
textbox.Text := slider.Value;
Et en voilà un bi-directionnel qui fera donc bouger le slider quand la textbox sera éditée :
textbox.Text :=: slider.Value;
Joli non ?
Dernier de chez dernier :
Des données à portée de clavier
Beaucoup de formats d'import devraient être disponibles (csf, netCDF, HDF, SQL, Excel). La manipulation des données est annoncée comme facilitée par un mode "à la Linq" :
myData = DataSet(“mydata.csv”); currentYear := slider.Value + 1900; bubbles := from row in myData where row.Year :== currentYear select new Circle() { X = row.Latitude, Y = row.Longitude, Radius = row.Population * scalingFactor, Fill = BlackBodyPalette(1., 1., row.DeltaCarbon) }; Scene[“USMap”].Add(bubbles);
Pour résumer
Vedea est prometteur, il y a de bonnes trouvailles. J'attends de voir les performances, c'est pour bientôt, Vedea devrait être disponible durant le début de l'année 2010.
Question runtime, Vedea est dépendant de .Net 4 et du runtime dynamique (DLR), ce qui limitera sérieusement son utilisation en tant que plug-in de navigateur.
Vedea n'étant pas annoncé comme open-source, je ne suis pas certains que ces trouvailles puissent à elles seules déclencher une révolution. Processing a de beaux jours devant lui.
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 ?
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 ?
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.
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.
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 :
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 :
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.
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.
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 :
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 .
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é.
Pour info le précurseur de ses outils s'appelleMorfik, toujours commercialisé. Je ne le connais pas.
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.
Avec l'heure de machine virtuelle (VM) à 0,12$, le Go de bande passante à 0,10$ (entrant) et 0,15$ (sortant) et le Go stocké à 0,15$, les tarifs de la plate-forme de cloud computing de Microsoft sont dans le peloton des leaders du cloud computing.
Mais il reste deux régions brumeuses dans cette grille de tarification, toutes les deux liées au flou de la définition d'une heure de VM.
Quelle puissance de calcul ?
Le premier coin de brume intéresse ceux qui (comme moi) voient le cloud comme un moyen super pratique de faire des calculs à outrance en calculant en 40 heures sur cent machines virtuelles pour 480$ ce qu'ils pensaient devoir obtenir en une année sur les PCs de la famille confisqués aux enfants (ou aux parents pour les jeunes geeks).
40 heures sur cent machines, vous allez me dire, c'est beaucoup. Pas sûr : de quelle heure parle-t-on ?
S'agit-il d'une heure de vieux processeur mono-coeur à 1.2GHz, de Netbook tout juste capable de supporter Chrome comme celui sur lequel je tape ce texte, voire d'une GameBoy, ou bien au contraire d'un processeur qui traverse allègrement le plafond des 4GHz ? Sans cette précision on reste dans le brouillard, l'estimation d'un budget de calcul intensif est aussi réaliste que la pêche à la ligne dans Animal Crossing, best-seller Nintendo qui prouve formellement que les enfants peuvent se passer de PC (les jeunes geeks peuvent occuper leurs parents avec un bon bouquin sauf bien sûr s'ils ont des parents geeks).
En fait la brume se lève rapidement, et la réponse, bien qu'approximative car non contractuelle, est connue : une VM du cloud Azure équivaudrait à un processeur AuthenticAMD cadencé à 1.3-1.5GHz et équipé de 2Go de mémoire vive (1,7Go accessible à l'application). Avec ça on peu déjà estimer à la louche, et même comparer avec les concurrents. En ne prenant en compte que la fréquence du processeur -- moyennée à 1.4GHz, on montre qu'Azure a pour le calcul intensif un très léger handicap sur Google AppEngine (GAE) qui vend l'heure d'Intel 1.2GHz à 0,10$ car le coût de l'instruction Azure dépasse le coût de l'instruction GAE. En gros bien sûr, il y aurait d'autres points de comparaison à prendre en compte
Néanmoins les chiffres publiés restent du domaine du marketing, pour trancher une bonne mesure in situ s'impose. Donc cher lecteur si vous possédez vos propres benchmarks je pense qu'on serait nombreux à les apprécier, je les partagerai ici avec plaisir.
Voilà pour le calcul intensif.
Purée de pois sur les applications Web
C'est au tour des développeurs Web (comme moi) de se poser une autre question : "Combien me coûtera mon prototype en cours de développement ? Et quels frais aussi, palsembleu, pour mon petit site à faible trafic ?". Notez au passage le style geek typique de la question.
Question qui renvoie au coût de l'heure de VM à 0,12$. Mais quoi. Mon application, perdue dans l'immensité du Web et tout juste sollicitée par Googlebot et ses confrères, va-t-elle me coûter autant qu'une application qui tire sans discontinuer sur le CPU ? Est-ce qu'un serveur Web juste prêt à répondre à des requêtes http vaut aussi 0,12$ de l'heure ? Est-ce que, vu d'un processeur, être prêt à travailler, c'est déjà travailler ?
En termes de CO2 dégagé ça serait assez injuste.
Et au delà -- plutôt très en deçà -- des problèmes de la planète, il y a de quoi être inquiet pour la facture si l'on calcule qu'un mois de machine virtuelle destinée à servir des pages Web à moi et à mes amis (les bots) va me coûter 0,12$/h x 24 heures x 30 jours = 86,4$ par mois. Argh, plus cher que le moins compétitif des hébergeurs .Net. Pire, le prix minimum serait en réalité le double parce qu'une application minimale met en oeuvre deux "rôles" (Web + Worker), rôles facturés 24h/24.
190$ par mois minimum !
Si c'était le cas, Azure ne serait scalable qu'en multiple de VM, pas en fraction. Techniquement on peut le comprendre en considérant qu'Azure ne prévoit pas de partager les VM sous-utilisées. C'est ce qui fait dire à certains observateurs (Cf. Azure minimum hosting price??) qu'Azure, en l'état, ne s'adresse qu'aux besoins en calcul intensif des entreprises, pas aux développeurs.
"To everyone, we do hear the desire to have an inexpensive option for applications with small load (or for experiments). We definitely share this goal, and we'll continue working towards that in a variety of ways."
Vous connaissez déjà WPF (Windows Presentation Foundation), cette technologie innovante venue avec .Net 3.0, dédiée à l'écriture d'interfaces graphiques classiques (en gros grises et statiques) ou riches (design travaillé et éléments animés) , un peu comme Flash et Flex sauf que ceux-là visent les applications Web alors que WPF se destine aux applications desktop, d'ailleurs l'équivalent Microsoft de Flash/Flex c'est Silverlight, donc disons que WPF ressemble à Adobe AIR, avec toute la force et la maturité du framework .Net en plus, mais avec la cross-platformitude en moins.
WPF amène une telle rupture avec les frameworks IHM précédents qu'il faut repenser la façon de gérer l'internationalisation d'une application. D'où ce document de synthèse :
"These [localization] concepts are very similar for most client applications but the actual process of localizing the static user interface components tends to vary between environments and WPF introduces yet another approach to resource localization for XAML resources.
This whitepaper will start with a quick review of general localization considerations for completeness, discuss how the .NET Framework handles resources for all applications, and then focus specifically on localization scenarios for WPF explaining some of the trade-offs within each approach."
Le document au format PDF, écrit par Rick Strahl et Michèle Leroux Bustamante de Microsoft, est disponible ici : http://wpflocalization.codeplex.com/
Les commentaires récents