Parallélisation de QuickSort

Posted on 10/01/2012 by JP Gouigoux

J’ai récemment lu un article très intéressant sur les performances du tri QuickSort implémenté dans .NET, que vous pouvez retrouver ici.

Je pense que le tri est un bon moyen de faire comprendre à un non-développeur la réalité de notre métier, et pourquoi des applications sans bogues ne sont qu’un doux rêve de politicien (dont on n’entend heureusement plus parler) : sachant qu’il a fallu une dizaine d’années aux chercheurs en informatique pour optimiser le tri dans la plupart des conditions et que l’algorithme final ne prend que quelques dizaines de lignes, comment peut-on s’attendre à la perfection lorsqu’un progiciel en contient 100 000 ?

L’article cité ci-dessus montre d’ailleurs que nous ne sommes pas au bout de la quête. Je me permettrais de rajouter mon grain de sel, d’ailleurs, sur la parallélisation des algorithmes. Je me demandai si l’implémentation de Sort dans .NET parallélisait proprement. Un petit bout de code comme ceci va nous permettre de voir ce qu’il se passe :

using System;
using System.Collections.Generic;
using System.Diagnostics;

namespace ConsoleApplication4
{
    class Program
    {
        static void Main(string[] args)
        {
            int n = 40 * 1000 * 1000;

            List<double> nombres = new List<double>();
            Random r = new Random();
            for (inti = 0; i < n; i++)
                nombres.Add(r.NextDouble());

            Stopwatch chrono = Stopwatch.StartNew();
            nombres.Sort();
            chrono.Stop();
            Console.WriteLine(chrono.Elapsed);
        }
    }
}

Visiblement, il n’y a pas de parallélisme :

image

Devoirs du week-end : imaginer un algorithme de tri fortement parallélisable, tout en restant performant sur un seul thread.

Et juste pour montrer qu’un Xeon, ça pousse :

SNAGHTMLa03046

Pour 40 millions d’entrées, ce n’est pas mal !

Posted in Parallélisation | Tagged | 2 Comments

Mon livre sur PowerPivot est paru

Posted on 09/01/2012 by JP Gouigoux

Juste à temps pour les TechDays, voici mon deuxième livre avec les Editions ENI, à savoir Excel et PowerPivot 2010 : l’analyse de données simple et efficace.

image

Comme pour chaque gros projet, je suis assez fier de le voir arriver. Même si c’était beaucoup moins long et complexe que le premier sur la performance en .NET, ça représente tout de même plusieurs mois de travail qui aboutissent…

Approche

La collection Objectif Solution dans laquelle est sorti ce livre a pour but de donner une approche pratique à des problèmes de tous les jours. Vous trouverez donc bien sûr dans ce livre des descriptions très détaillées, pas par pas, de comment utiliser telle ou telle fonctionnalité de PowerPivot.

A la fin, vous serez en mesure des créer des analyses complexes avec graphiques et tableaux croisés dynamiques mis en relation les uns avec les autres, avec filtrages complexes, le tout sur des ensembles de plusieurs millions de ligne, et surtout avec la réactivité incroyable de PowerPivot.

image

OpenData

J’ai également fait l’effort d’éviter le plus possible de donner des exemples académiques, mais je me suis au contraire basé sur des ensembles de données réels. Vu que le but de PowerPivot est de manipuler des gros volumes, il fallait bien trouver quelque chose de massif, et c’était justement l’occasion de montrer également ce qu’on peut faire avec des ensembles OpenData.

image

Du coup, vous verrez des usages effectifs de données en provenance d’Azure Data Market. Rien en provenance de http://data.gouv.fr, parce que le site a été ouvert un peu après l’écriture du livre, mais ça sera pour une prochaine édition Sourire.

L’idée était également de mettre un petit coup de projecteur, à mon humble niveau, sur le principe des données publiques ouvertes, et sur le protocole OData. Si ce livre peut en plus encourager les citoyens à s’approprier la donnée qui les concerne, ainsi que pousser nos politiques à continuer sur la voie de l’ouverture, et ce avec des formats adaptés comme OData au lieu de CSV ou XLS, ça serait parfait !

Conclusion

Bref, si vous êtes intéressés par l’analyse de données volumineuses dans Excel, rendez-vous sur le site de l’ENI, qui fait une remise de lancement de 5% sur la version imprimée.

Posted in Uncategorized | Tagged , | 9 Comments

Documents SharePoint de TFS : répertoire bloqué par une croix rouge

Posted on 09/01/2012 by JP Gouigoux

Si vous utilisez Team Foundation Services avec SharePoint pour les portails de projets, vous vous êtes peut-être déjà retrouvé avec une icone comme ceci sur les documents, et dans l’impossibilité de faire quoi que ce soit sur ceux-ci :

image

Le problème vient qu’il vous manque des droits, mais pas ceux de TFS : c’est bien sur le site SharePoint qu’il faut les rajouter ! Vous devez donc aller, en tant qu’administrateur, dans les Paramètres du site, et trouver l’entrée Personnes et groupes, qui vous permettra de vous rajouter dans la liste des personnes autorisées à contribuer au site portail de projet :

image

N’oubliez pas de cliquer sur l’icone d’actualisation dans Visual Studio pour que le menu contextuel apparaisse enfin sur le répertoire des documents.

Posted in ALM | Tagged | Leave a comment

Pourquoi C# plutôt que Java

Posted on 09/01/2012 by JP Gouigoux

Ceux qui me lisent régulièrement savent que je suis plutôt orienté C# / .NET plutôt que plateforme Java. Ce qui ne veut pas dire que je rejette toute JVM en bloc. J’ai utilisé du Java pour mon job d’architecte lorsque cela s’est avéré plus intéressant, et j’ai bossé un bout de temps sur le client Java de mon ancien employeur. J’ai encore récemment choisi Java pour animer une de mes conférences sur la prévalence.

Mais personnellement, j’ai une préférence pour C#. J’ai eu l’an passé le plaisir de présenter une session “Java compareTo .NET” avec Nicolas De Loof lors du BreizhCamp, et (en toute malhonnêteté), j’ai été gentil de ne pas trop insister là où ça faisait mal : Linq, prise en main par Oracle, retard dans les versions, etc. Sourire

Toutefois, un sain émolument nécessite deux bons concurrents, et je suis content de voir que Java reprend – un peu – de poil de la bête avec les nouvelles versions. Mon esprit pinailleur (ainsi que le désir irrépressible de taquiner Nicolas) m’amène toutefois à formuler deux-trois remarques, à partir de ce que j’ai lu ici.

Diamond

L’écriture ci-dessous est un peu lourde, c’est vrai :

Map<String, List<String>> myMap = new HashMap<String, List<String>>();

Java en version 7 propose de la raccourcir sous cette forme :

Map<String, List<String>> myMap = new HashMap<>();

C# a une autre approche, à savoir :

var myMap = new Map<String, List<String>>();

Et bien, vous ne serez peut-être pas surpris outre mesure, mais je pense sincèrement que la grammaire C# est plus logique. Lorsqu’on crée une instance, on a toujours besoin de connaitre le type de ce qui va être créé, tandis que le type de la variable qui va pointer dessus est moins important. Dans la plupart des cas, il reprend simplement le type de la classe, mais les quelques pourcents qui restent sont utilisés typiquement avec une classe de plus haut niveau dans la hiérarchie d’héritage ou une interface que la classe instanciée implémente.

Du coup, n’est-ce pas plus dans le sens du polymorphisme d’écrire ceci :

// Même chose
Chien c = new Chien();
var d = new Chien();

// Polymorphisme
Animal a = new Chien();

En effet, dans tous les cas, c’est bien une instance de Chien qu’on crée, mais dans un cas, on reste sur une variable de référence qui est par défaut, et dans l’autre, on utilise une classe plus haute. A côté, Java parait moins logique, car le type de la variable peut changer, mais aussi la façon d’écrire le type à instancier.

En plus, le mot clé var de C# fonctionne dans tous les cas, et pas seulement les génériques, mais n’importe quelle classe, y compris les classes anonymes.

Catch multiple

Là, on va peut-être me dire que je suis passé à côté de quelque chose, mais pourquoi écrire quelque chose comme ceci ?

catch (IOException|SQLException ex)
{
    logger.log(ex);
    throw ex;
}

Je ne dis pas que le fait de catcher plusieurs exceptions en même temps soit une mauvaise idée, mais ce qui m’embête vraiment dans cette grammaire, pour le coup, c’est qu’une variable ne soit pas précisément typée. Comment sait-on quel membre on peut lire sur ex ? Ceux de IOException ? Ceux de SQLException ? Ceux communs ? Et dans ce cas-là, à quel niveau de communauté dans la hiérarchie d’héritage ?

Il y a peut-être quelque chose que je ne comprends pas sur les exceptions Java, qui ne fonctionnent pas comme celles de C# où toutes doivent dériver de System.Exception, mais je ne vois pas comment des outils comme la validation de type statique ou la complétion automatique peuvent fonctionner sur ce genre de grammaire…

Linq

En voyant ceci, j’étais à deux doigts de féliciter Oracle pour avoir enfin reproduit Linq dans Java (ce qui à mon sens est un grand manque) :

double max = students.filter(#{Student s -> s.gradYear == 2010})
                     .map(#{Student s -> s.score})
                     .max();

Mais je viens de voir que ceci était planifié pour la version 8, prévue pour le deuxième semestre 2012. Dommage… Surtout si Oracle est aussi en retard que pour la version 7 (désolé, Nico, c’est du mauvais esprit Sourire)

Conclusion

J’espère que ce blog ne parait pas trop peu constructif : je taquine, mais le but n’est pas de polémiquer. J’aime bien le monde Java aussi, surtout pour le foisonnement de projets d’une grande richesse (je rêve en particulier d’avoir les fonctionnalités de Prevayler dans Bamboo), mais ces quelques points me confortent dans l’idée que l’approche de Microsoft est plus cohérente globalement (je n’ai pas dit meilleure, juste cohérente). C’est certainement bêtement dû au fait que Microsoft est seul à la barre du langage, mais je trouve ça appréciable.

Quelques dernières remarques (en espérant qu’elles réussiront à éloigner les trolls anti-Microsoft des commentaires) :

  • Je ne pense pas qu’Oracle ou Google abusent non plus de la philanthropie
  • Ce genre de ressource montre que Microsoft a compris que ses intérêts passaient aussi par un certain niveau d’ouverture, même s’ils restent bien sûr une entreprise commerciale
  • Le langage C# est normalisé ECMA
  • La CLI est normalisée ECMA
  • De la même manière que Java a son implémentation GNU, .NET a son implémentation libre, à savoir Mono, maintenant passé sous la bannière Xamarin.
  • Et pour finir, même les modules additionnels (c’était le dernier argument des acharnés) sont désormais également en Open Spec
Posted in .NET, Retours | 1 Comment

Développeur, un métier de masse ?

Posted on 07/01/2012 by JP Gouigoux

Un article intéressant sur le métier de développeur a été commenté dans L’Informaticien ces jours-ci. La thèse de Roy Bahat est que programmer pourrait devenir une commodité, et le métier associé une profession courante.

Bien que la thèse soit intellectuellement très attirante, je pense que c’est confondre deux choses : être capable de développer ne fait pas de quelqu’un un développeur, de la même manière que faire du jardinage le dimanche n’a jamais transformé une personne en agriculteur.

Bien sûr, coder est devenu plus facile, et il est effectivement possible de former des gens qui n’ont que peu de connaissances techniques à programmer en Java en quelques mois. Roy Bahat reconnait toutefois que l’expertise prend par contre beaucoup de temps, mais explique qu’on peut développer à peu de frais.

Je pense que ces deux dernières parties de sa thèse sont vraies, mais incomplètes…

Les développeurs sont de plus en plus experts

Il est tout à fait vrai qu’il est possible d’apprendre à coder en relativement peu de temps. Mais dans le même temps, l’industrie informatique s’oriente plus vite vers des besoins d’expertise. La programmation s’est simplifiée, mais cette simplification fait qu’on peut utiliser plus facilement des briques logicielles pré-existantes pour créer des surcouches plus complexes.

Il y a une dizaine d’années encore, il arrivait que des développeurs “pissent du code”, mais ce n’est plus le cas depuis pas mal de temps. Le vrai métier du développeur s’est fortement spécialisé, et aujourd’hui, il s’agit plus de connaitre les méthodes performantes et agiles de créer un code facilement maintenable, générique, évolutif. En plus de ceci viennent les problématiques de sécurité que les développeurs doivent de plus en plus prendre en compte.

Alors, effectivement, il est facile de faire une petite application mobile Android sur un coin de table, mais il ne faut pas considérer ceci comme le métier d’un développeur. Il y a un monde entre ce prototype et un passage en production, qui est au moins le triple de ce qui est nécessaire. L’application qui fonctionne doit être vue comme un prototype : il faut ensuite savoir la déployer, la sécuriser, la mettre à jour, la maintenir et la rendre robuste. C’est là qu’intervient le développeur, et honnêtement, je ne pense pas que quelqu’un soit capable de ceci avant plusieurs années d’expérience.

La thèse du prix

La notion de coût de développement est également sujette à caution. Roy Bahat parle du coût des outils de développements, et effectivement, avec un ordinateur d’entrée de gamme et des outils gratuits comme Eclipse ou Visual Studio Express, n’importe qui peut commencer à programmer.

Mais le coût d’un développement n’a rien à voir. Encore récemment, une étude est sortie (voir ici pour un résumé), dans laquelle la dette technique est estimée à 5,42 $ par ligne de code en Java. Or, justement, programmer des applications avec des développeurs débutants est le meilleur moyen d’avoir une dette technique élevée. Faites le calcul : sur une application de 100 000 lignes (ce qui n’est pas énorme : au travail, je suis au contact de progiciels avec un nombre de lignes de l’ordre du million), en imaginant même que 99% des lignes soient parfaitement écrites, il reste un coût, juste pour la correction de la dette technique, de 5420 $.

Beaucoup plus qu’un portable… Et c’est là la limite de cette comparaison : apprendre à développer ne coûte effectivement pas cher, mais laisser un non-expert coder coûte à l’inverse une fortune, et ce n’est pas par hasard que les éditeurs de logiciels préfèrent de beaucoup embaucher un expert plutôt que trois développeurs moyens.

Le coût de l’expertise

Au final, l’activité de développement n’a rien à avoir avec simplement savoir programmer. Pour prendre une autre comparaison, effectivement tout le monde sait ou peut apprendre facilement à faire du vélo. Mais faire son métier du cyclisme n’est pas donné à tout le monde. Il faut de l’entraînement, de la discipline, et un réel talent.

Je me rappelle qu’il y a une quinzaine d’années, lorsque les macros sont apparues dans Excel, les magazines informatiques fleurissaient de formules pour nous expliquer que nous allions tous programmer. Et au collège, les MO5 et TO7 allaient, grâce au BASIC, permettre à tout un chacun de savoir coder. Mais combien d’entre nous sommes réellement allés jusqu’au bout ? Des langages apparaissent chaque année, promettant de mettre à la portée du plus grand nombre la programmation. Force est de constater que malgré tout, ça ne décolle pas… et pour cause !

Pour finir

Mon opinion personnelle est que cet article suit une longue série autour de l’idée que les nouvelles approches informatiques (interfaces simples, utilisation ubiquitaire du web, réseau social, etc.) sont une nouvelle façon de réaliser du travail productif. Malheureusement, ce n’est pas le cas, et il ne s’agit que d’enrobage. Clairement, une belle interface est désormais essentielle, mais savoir l’utiliser n’a rien à voir avec la coder.

Encore aujourd’hui, j’ai fait une visite d’étudiants dans ma société, et le message que j’espère leur avoir fait passer est que, à la fin des fins, la seule chose qui compte est de connaître son client et de satisfaire ses besoins. Attention à ne pas se sentir l’âme trop conquérante avec des thèses comme celle de Roy Bahat, ou avec des articles comme celui-ci. Les nouveaux arrivants auront beau mieux maîtriser les nouvelles technologies, ils mettront toujours beaucoup de temps à apprendre à les créer. L’iPhone est un outil de jeunes, mais n’oublions pas qu’il a été conçu par des gens à la tête desquelles étaient un entrepreneur de 50 ans et un designer de 40…

En conclusion, doucement les jeunes ! Développer, c’est un métier Sourire (mais c’est peut-être le deuxième plus beau du monde…)

Posted in Retours | 2 Comments

Coffret ENI : deux livres sur le code performant et efficace en C#

Posted on 27/12/2011 by JP Gouigoux

Mon éditeur sort un bundle composé de C# 4 : Les fondamentaux du langage, de Thierry Groussard, et de mon livre Ecrire du code .NET performant.

image

Je trouve que c’est une excellente idée de joindre ces deux livres, alors j’en profite pour faire un peu de publicité. Vous pouvez vous procurer ces 1050 pages qui feront de vous un expert sur le site des Editions ENI.

Posted in .NET, Performance | Leave a comment

Quand plus de performance entraine des temps d’exécution plus longs…

Posted on 23/12/2011 by JP Gouigoux

Supposons que vous travailliez sur un problème de performance d’un scénario sur un serveur et que, suite à une première campagne de suppression des goulets d’étranglements, vous ayez réussi à abaisser le temps total d’exécution du scénario.

La plupart des temps unitaires d’exécution des requêtes ont baissé, le nombre de scénarios joués en parallèle dans le même temps augmente, etc. Tout se passe donc a priori dans le bon sens, mais vous vous rendez compte que certaines requêtes prennent plus de temps. Et pas seulement relativement au scénario dans son ensemble, mais en temps absolu. Les performances sont globalement meilleures, mais certains temps d’exécution s’allongent !

image

Surtout, vous vous rendez compte que ce n’est pas un effet de bord sur un temps unitaire, mais bien sur une moyenne pour une requête particulière. Comment est-ce possible ?

Une des raisons possibles est que l’augmentation des performances globales fait que plus de threads peuvent être menées en parallèle, et plus de jeux de scénarios peuvent être exécutés de manière rapprochée. Au final, des verrous qui, avec un flux faible étaient invisibles, peuvent devenir prépondérant, et ainsi ralentir les opérations associées.

Un petit graphe temporel pour expliquer ceci : avant optimisation, les instances se succèdent à un rythme faible, et le lock est pour ainsi dire nul.

image

Prenons maintenant le même graphe où le throughput a fortement augmenté, car les goulets d’étranglements principaux ont été supprimés. On peut alors se retrouver avec ce genre de graphique :

image

La période de recouvrement est alors beaucoup plus longue et que se passe-t-il alors ? Si vous avez malheureusement une contention sur une ressource unique, le second service devra attendre la fin du premier, ou en tout cas le moment où il relâche cette ressource, pour continuer, ralentissant ainsi son exécution. Si la période de recouvrement augmente, on peut arriver à des extrêmes comme ceci :

image

Les zones en rouge montrent l’exécution effective de la requête, en supposant une ressource unique partagée, et relâchée seulement en toute fin d’exécution. Les lignes bleues montrent alors le temps total d’exécution perçue pour une requête donnée. On voit bien que plus de throughtput (et donc des lancements plus rapprochés) peuvent dans certains cas provoquer une durée au final plus longue, alors que globalement, la performance reste meilleure, au sens où il est possible de tirer plus de scénarios dans le même temps, à machine équivalente…

En conclusion : attention à la façon dont on mesure la performance. En cas de doute, toujours revenir aux bases : comment est-ce que la performance est perçue par le client ?

Posted in Performance | Tagged | Leave a comment

Quizz : DataReader + yield + foreach + Dispose

Posted on 21/12/2011 by JP Gouigoux

Allez, un petit dernier pour la route… Dans le code ci-dessous, j’utilise le mot-clé yield pour boucler sur toutes les lignes d’un DataReader. Le mot-clé using permet de disposer le DataReader, mais seulement lorsqu’on atteint la fin du parcours du IEnumerable.

Question : que se passe-t-il si, à l’aide d’un index, on empêche le code de l’itérateur d’aller à la fin. Comment peut-on s’assurer que le Reader sera tout de même clos ? Et surtout, comment cela fonctionne-t-il dans le cas d’un foreach, sur lequel nous n’avons pas un accès à l’itérateur ?

namespace ConsoleApplication1
{
    public class Dossier
    {
        public string Code { get; set; }
        public string Libelle { get; set; }
 
        public static Dossier Create(IDataRecord entree)
        {
            return new Dossier()
            {
                Code = entree["idcompos"].ToString(),
                Libelle = entree["lbcompos"].ToString()
            };
        }
    }
 
    class Program
    {
        public static SqlConnection Connexion = null;
 
        public static IEnumerable<Dossier> GetDossiers()
        {
            using (var dr = GetReader())
                while (dr.Read())
                    yield return Dossier.Create(dr);
        }
 
        public static IDataReader GetReader()
        {
            Connexion = new SqlConnection(_ChaineConnexion);
            Connexion.Open();
            SqlCommand Commande = new SqlCommand("SELECT a, b FROM TEST", Connexion);
            return Commande.ExecuteReader(CommandBehavior.CloseConnection);
        }

        static void Main(string[] args)
        {
            int NombreLecturesMaxi = 5;
            foreach (Dossier dossier in GetDossiers())
            {
                Console.WriteLine(dossier.Libelle);
                if (NombreLecturesMaxi-- < 0) break;
            }
            Console.WriteLine("Etat de la connexion : {0}", Connexion.State);
 
            NombreLecturesMaxi = 5;
            IEnumerator<Dossier> Enumerateur = GetDossiers().GetEnumerator();
            while (Enumerateur.MoveNext())
            {
                Console.WriteLine(Enumerateur.Current.Libelle);
                if (NombreLecturesMaxi-- < 0) break;
            }
            Console.WriteLine("Etat de la connexion : {0}", Connexion.State);
            Enumerateur.Dispose();
            Console.WriteLine("Etat de la connexion : {0}", Connexion.State);
        }
    }
}

Réponse : si vous exécutez ce code, vous verrez que le Dispose sur l’énumérateur est bien propagé, et que cela clos le DataReader, et donc la connexion puisqu’on a utilisé le CommandBehaviour.CloseConnection. Du coup, l’état de la connexion est ouvert avant le Dispose et fermé après.

Mais dans le cas du foreach, il est directement fermé : le fait de sortir de la portée du foreach appelle le Dispose sur l’énumérateur.

Si on jette un oeil à l’IL, c’est bien ce qui est créé par le compilateur :

image

Je m’émerveille peut-être de quelque chose de tout à fait normal, mais avant de me poser la question de la clôture du DataReader sur un foreach simulé de manière incomplète, je ne suis pas sûr que j’aurai pensé à bien appeler le Dispose pour le propager…

Posted in .NET | Leave a comment

HTML5 rase gratis !

Posted on 21/12/2011 by JP Gouigoux

Qu’est-ce qu’HTML 5 ?

Bon, je ne suis pas du tout spécialiste du développement web. J’en ai fait un peu comme tout le monde, et je suis suffisamment au courant du modèle WebForms pour créer des contrôles, y compris avec une partie client. J’ai commencé le JavaScript il y a presque 15 ans, maintenant, à une époque où l’idée même d’outils pour aider à coder était risible…

J’ai suivi les développements de HTML 3, puis HTML 4, puis XHTML. Dans les quelques développements web auxquels j’ai participé, j’ai toujours soigneusement séparé HTML pour la structure de CSS pour la présentation. Et pour moi, HTML est simplement ça : un langage structuré de représentation d’information publiable. Cela n’empêche pas un certain degré d’interaction grâce à des frameworks clients ou bien des modèles d’aller-retour serveur intégré comme WebForms, mais fondamentalement, HTML représente une structure d’information.

Du coup, j’ai un peu de mal avec la façon dont HTML 5 est mis en avant comme langage pour créer des applications riches. Je ne vois pas en quoi une nouvelle version nous libèrerait des limitations fondamentales du langage, à moins qu’il s’agisse d’une toute nouvelle technologie qui rompe avec l’existant.

A entendre certains commentaires sur internet (http://www.techrepublic.com/blog/programming-and-development/why-html5-makes-justifying-native-applications-more-difficult/4903), HTML 5, dont les specs ne seront pas stabilisées avant 2014, est pourtant déjà le choix obligatoire pour les développements RIA, alors que des plugins font parfaitement le boulot aujourd’hui. D’autres articles parlent de “développer en HTML” (http://www.indexel.net/applications/html-5-est-ce-enfin-le-moment-de-l-adopter-3366.html), mais pour moi, le développement se fait avec JavaScript et ActionScript côté client, et .NET ou J2EE côté serveur.

Alors, c’est quoi, HTML 5 ? Une plateforme de développement ou un langage de description de pages ?

Back to reading

Du coup, je me suis dit qu’il fallait creuser un peu plus pour se faire une idée plus précise, et je me suis attelé à deux livres sur HTML 5 :

Product image

Le bouquin de Pearson (http://www.pearson.fr/livre/?GCOI=27440100108830) est très bien pour commencer : clair et précis, pas trop long, et expliquant bien l’historique des choix qui ont été faits, sans entrer trop dans la technique.

image

Celui de Manning, bien que pas encore terminé mais accessible en mode Early Access (http://www.manning.com/crowther/) est bien plus technique, tout en restant abordable, et en expliquant très bien les différences avec HTML 4.

Les avancées de HTML 5

Pour résumer, HTML 5 apporte des avancées intéressantes, mais qui représentent surtout une inclusion dans la norme de ce qui se faisait jusqu’à présent par d’autres moyens. Exemples :

  • HTML 5 définit des balises <header>, <footer>, <article>, etc. qui permettent de donner une bien meilleure sémantique à la structure de la page, plutôt que de laisser un tas de <div> imbriqués, avec seulement une classe CSS pour les différencier. C’est très bien, mais c’est surtout intéressant pour l’indexation, et n’a rien à voir avec l’utilisation d’e HTML 5 pour des applications de type Rich Internet Application.
  • HTML 5 embarque des éléments spécialisés pour le multimédia. Visiblement, l’idée est de ne plus avoir besoin de plugin Flash ou Silverlight. Outre le fait que ça ressemble surtout à une idée de puriste (tout le monde utilise des plugins), le problème n’est que déporté, vu que les codecs associés ne sont pas normalisés. Vous vous rappelez la guerre des navigateurs il y a dix ans ? Moi, oui… j’étais au milieu…
  • HTML 5 embarque des éléments pour effectuer de la validation côté client sur les éléments de formulaire. Bonne idée de mettre ça dans HTML lui-même. Ca arrive un peu tard, parce que beaucoup de frameworks JavaScript faisaient désormais ça très bien, mais vu que c’est quelque chose de très utilisé dans les RIA, c’est bien que ce soit inclus dans la norme.
  • HTML 5 permet le stockage local de données, un peu comme un IsolatedStorage en .NET. Attention, cela ne veut pas dire que vous avez accès au disque dur local, mais juste à une toute petite partie dédiée à votre application. Pour le coup, ça me parait difficile de conclure, comme le fait un des articles plus haut, qu’il n’y a plus besoin de code natif pour les applications ayant besoin d’accès I/O : on ne peut pas partager directement de fichiers entre les applications…
  • HTML 5 met l’accent sur les manipulations graphiques avec le composant Canvas, dans lequel on peut dessiner de manière simple. Les implémentations (IE9 en particulier) permettent d’après ce que j’ai compris une accélération graphique qui sera la bienvenue. Je me rappelle avoir fait du DHTML et avoir atteint des problèmes de performance dès le centième rectangle affiché.
  • HTML 5 permet le Drag & Drop. C’est quelque chose qui pourrait être mis au crédit du développement RIA. Pourtant, même chose : on pouvait faire ça depuis longtemps avec DHTML. Et surtout, si il n’y a pas la possibilité de faire du Drag & Drop entre applications multiples, c’est trop limité par rapport à ce qu’on fait avec Silverlight en mode Out Of Browser, par exemple.

Ce que HTML 5 ne sera pas

Pour résumer, HTML 5 regroupe très bien tout ce qui a été apporté de manière multiple sur HTML 4 et le place dans la norme. Certaines des fonctions peuvent en effet faire progresser HTML vers l’utilisation dans le cadre d’applications RIA simples, mais soyons sérieux : la validation des entrées et le drag & drop représentent quoi ? 10% peut-être des besoins techniques qu’on a pour faire du RIA ?

Il manque toute l’interopérabilité avec le système, une pile JSON, une pile SOAP éventuellement, des manipulations 3D possibles (les solutions existantes sont des plugins), un mode déconnecté qui ne soit pas uniquement porté par un IsolatedStorage, mais qui gère de manière générique la déconnexion.

Il manque évidemment l’accès aux disques, l’accès unifié aux périphériques, la possibilité de gérer la sécurité applicative, le chargement dynamique de parties d’applications… Bref, il manque énormément de choses pour rivaliser avec des applications à plugin. Et ce n’est pas les API unifiées pour la géolocalisation qui changeront quoi que ce soit à cet état de fait.

Conclusion

Pour moi, HTML 5 est bien resté une grammaire de structuration de contenu. Beaucoup de gens le poussent en avant comme une alternative aux plugins, mais ce n’est, à mon humble avis, pas du tout le cas. HTML 5 apporte des fonctionnalités intéressantes à HTML 4, et qui vont indubitablement dans le sens de la production plus facile de RIA. Mais HTML 5 n’est pas une technologie suffisante pour cela.

Après lecture de ces deux livres et applications sur quelques prototypes, c’est plutôt cet article dans lequel je me retrouve le plus : http://www.infodsi.com/articles/124553/html5-est-hallucination-collective-franck-wolff-fondateur-president-granite-data-services.html

Je pense que beaucoup de gens placent des espoirs beaucoup trop hauts dans HTML 5. On entend beaucoup parler en ce moment du manque de futur de Silverlight, mais c’est un peu comme Visual Basic 6 : quand la dernière version est sortie, il était clair qu’il n’y aurait pas de suivant, et pourtant c’est une version stable qui est resté en production encore longtemps après (Microsoft a d’ailleurs sorti un patch pour le faire fonctionner sur Windows 2003 Server, ce qui n’était pas supporté). Silverlight 5 est sorti et est arrivé dans une version extrêmement mature, avec des fonctionnalités débordantes. Je suis persuadé qu’il va être encore très utile jusqu’en 2014 au moins.

Quant à l’approche Metro de Windows 8, je ne pense pas qu’elle obère le positionnement de Silverlight : HTML 5 est en effet utilisé pour la structuration des tiles, mais le code de WinRT contient la plupart des classes de Silverlight…

EDIT : S’il fallait donner un exemple supplémentaire de l’engouement absolument irrationnel sur HTML 5, l’actualité des blogs vient de m’en fournir un autre sur http://www.techrepublic.com/blog/10things/10-reasons-why-this-is-a-great-time-to-be-a-developer/2915. Allez-le lire, vous verrez, c’est extraordinaire… Il ne fait aucun doute que, lancé sur un tel élan, HTML 5 finisse par guérir des maladies graves, combler le trou de la sécu, etc.

Posted in Retours | Tagged | 1 Comment

String.Join : nouvelles surcharges en .NET 4.0

Posted on 20/12/2011 by JP Gouigoux

Tant qu’on est dans les petites découvertes sur .NET 4.0 : il y a désormais une surcharge de String.Join prenant un IEnumerable<T> en paramètre. Auparavant, on était obligé d’écrire ce genre de code, avec un ToArray() pas très élégant :

List<string> Liste = new List<string>() { "coucou", "bidule" };
Console.WriteLine(string.Join("|", Liste.ToArray()));

En .NET 4.0, plus besoin, on peut écrire directement :

List<string> Liste = new List<string>() { "coucou", "bidule" };
Console.WriteLine(string.Join("|", Liste));

Encore une fois, ce n’est pas grand chose, mais ce genre de petites surcharges de confort est très agréable pour garder un code plus léger…

Posted in .NET | Leave a comment