Retour sur l’Agile Tour Nantes 2011

Bon, OK, c’est avec 15 jours de retard, mais voici quand même un retour sur l’Agile Tour Nantes du 13 Octobre 2011.

image

Organisation : au top !

Avant tout, un grand coup de chapeau aux organisateurs : tout était parfait. Et le plus incroyable était l’impression de facilité… C’est la marque des très bons ! Il fallait voir les organisateurs prendre le temps de discuter avec chacun. On voit souvent des conférences où les organisateurs courent dans tous les sens pour régler les problèmes. Là, pas d’affolement : tout était organisé nickel en amont, la journée coulait peinard. Bravo, vraiment !

Keynote de Rémy Génin

Avec les suicides au sein d’Orange l’an passé, parler de l’utilisation des méthodes agiles pour remettre de l’humain au coeur du processus de développement était quelque chose de très délicat, et Rémy Génin l’a réussi avec une sensibilité et une franchise que j’ai trouvées extrêmement dignes.

On passe souvent beaucoup de temps sur les techniques lorsqu’on parle d’agilité, alors merci à lui de nous remettre bien en tête que l’humain reste la principale valeur de l’agilité.

Scrum, la fabrique de l’engagement, de Thierry Monthulé

Bon, ça va virer au panégyrique, mais vous m’accorderez que je ne parle pas de toutes les conférences que j’ai suivies, mais seulement de celles qui m’ont vraiment marquées. Et là encore, on a eu quelque chose de grandiose.

Evidemment, comparer les méthodes agiles avec les techniques de manipulation psychologique, ça peut paraitre osé à l’Agile Tour. Et dans un premier temps, je ne cache pas avoir eu un mouvement de refus instinctif de ces idées. L’agilité a été développée pour remettre l’humain au centre du processus de développement, pour qu’il reprenne la main sur des processus déshumanisés.

Mais, sans aucune agressivité ou malice, l’orateur présentait un à un des arguments qui se trouvaient être difficilement réfutable, et au bout de quelques temps, on se pose des questions graves… Comme par exemple : suis-je moins même manipulé lorsque j’essaie de “vendre” l’agilité à mes collègues ? Suis-je un salaud parce que des techniques de manipulation sont présentes dans les concepts que je supporte, même si je n’en étais pas conscient.

Je peux vous garantir que cette conférence a fait un sacré effet de douche froide dans la salle, et les questions étaient nombreuses. Et pas du tout dans un sens de justification : je pense que tout le monde présent avait compris que les arguments se tenaient, et que le temps n’était pas au déni, mais plutôt à l’adaptation de nos méthodes. En tout cas, personnellement, ça m’a fait pas mal réfléchir.

De l’importance du doute

Au repas du soir que j’ai eu le plaisir de partager avec l’équipe Agile Nantes, la discussion a pas mal dérivé vers la philosophie. Et je dois dire qu’après la conférence de Thierry Monthulé, ça m’a vraiment mis du baume au coeur de voir que tous les spécialistes de l’agile autour de la table était aussi fortement imprégnés de sujets non techniques. C’était un plaisir de discuter de l’importance du doute dans la récente histoire des neutrinos plus rapides que la lumière, des théories de Frédéric Lordon, etc.

Chapeau encore une fois aux organisateurs d’avoir eu l’idée de programmer une conférence s’attaquant de manière aussi frontale à un possible ronronnement placide de nos pratiques. Ca fait du bien… De la même manière que Frédéric Lordon donne une explication du capitalisme en expliquant que “à l’os”, il s’agit d’amener d’autres personnes à réaliser un projet que l’on ne peut pas mener seul, le risque derrière nos méthodes agiles est de tenter d’utiliser les affects de la même manière dans nos projets.

Il faut donc que nous redoublions d’attention sur le fait que l’humain au centre à la place des processus ne doit pas être uniquement un moyen d’obtenir la participation de l’équipe à un but externe, mais bien à un but qui bénéficie à chacun. Pour certains, cela peut être le fait de garder une équipe compétente dans une petite ville. Pour d’autres, de développer la soif de connaissances. En tout cas, il est essentiel de garder cette culture du doute…

Ma femme, dont la connaissance de l’agilité se limitait à quelques minutes de discussion avec moi quelques semaines auparavant, avait eu l’incroyable intuition, un soir que je rentrais d’une réunion Agile Vannes, de me saluer d’un terrible “alors, tu es revenu de ta secte ?”. Je suis persuadé que ses capteurs avait détecté dans ma foi du converti, dans la mise en avant des valeurs, une véritable dérive sectaire possible, même si elle le disait de manière humoristique. La conférence de Thierry Monthulé m’a fait me souvenir de cet épisode sous un jour nouveau, potentiellement effrayant.

A notre tour à tous, dans notre pratique de l’agile, de nous poser la question de nos réelles motivations. Bref, retour à la philosophie du doute… Personnellement, et ça devient de plus en plus vrai avec le temps, rien ne me rebute plus que quelqu’un qui ne doute pas. C’est même devenu presque un réflexe de me questionner sur la compétence et les intérêts de quelqu’un qui n’a pas de doute sur son propre discours ou sa compétence. Ce genre de conférence ne fait que renforcer ce sentiment.

Architecture et Agilité

Bon, je ne vais pas faire un retour sur ma propre conférence, certains s’en sont déjà chargés (merci, Dominique, pour le suivi twitter en temps réel)… Je vous renvoie juste aux slides de toutes les conférences (dont celle-ci, que j’ai fait fortement évoluer depuis sa première présentation à Vannes l’an passé) : Les slides

Conclusion

Une conférence troublante, des présentations de très bon niveau, des discussions passionnantes (et passionnées : il faut que je me rappelle de ne plus répondre quand on m’attaque sur le traditionnel conflit Java / .NET), une organisation parfaite… Moi, je signe tout de suite pour l’an prochain Sourire

Posted in Agile, Retours | Tagged | Leave a comment

Providers ADO.NET par défaut absents du machine.config en .NET 4.0 !

Si vous utilisez le mode multi-providers dans ADO.NET depuis la version 2.0, vous saviez certainement que les providers devaient être déclarés dans le machine.config.

Du coup, on voyait traditionnellement ceci dans le machine.config :

image

Si vous jetez un œil dans le fichier machine.config de .NET en version 4.0, il n’y a presque plus rien :

image

Juste le provider pour SQL Server Compact !

Et pourtant, vous pouvez tout de même utiliser le provider de SQL Server, avec ce genre de chaine de connexion dans le fichier de configuration de votre application :

image

Et ça marche bien… Du coup, on se demande bien comment. La réponse est trouvée avec un coup d’ILSpy :

image

Et oui : en dur dans le code !

image

Y compris celui d’Oracle alors que le provider ADO.NET est marqué comme obsolète. Sur les forums de Microsoft (http://social.msdn.microsoft.com/Forums/en-ZA/adodotnetdataproviders/thread/d79129c4-ae05-4c45-8997-bd90f5765a3a), DbProviderFactories est supposé les charger dynamiquement. Mouais…

<citation mode=’Desproges’>Etonnant, non ?</citation>

Posted in .NET, Debogage | Leave a comment

MVP !

Je ne suis pas peu fier de vous annoncer mon accession au statut de MVP, dans la catégorie Connected Systems Developper ! Microsoft m’a fait cette excellente surprise au début du mois, et c’est avec beaucoup de plaisir que je la reçois.

o_MVP_hory

C’est sympa de voir que les articles, les conférences et les bouquins (je parle au pluriel, parce que le second est en route) amène à une reconnaissance de Microsoft. Et j’ai du coup une licence pour Ultimate ! Sourire

Le deuxième bouquin (ainsi que la traduction du premier en anglais) me prennent pas mal de mon temps en ce moment, d’où le peu d’articles récemment, mais à partir de Novembre, je vais enfin avoir du temps pour revenir à mes petits projets, et ça va reprendre à fond…

Posted in Uncategorized | Leave a comment

Pattern Request/Reply : ESB pour les nuls

Le problème

Ca me trottait dans la tête depuis un bout de temps : je n’ai jamais été à l’aise avec le pattern Request / Reply, car j’ai l’impression que ça allait à l’encontre de la notion d’asynchronisme. Dans un bus de message asynchrone, j’envoie le message et le middleware me donne la garantie qu’il sera testé, et je n’ai pas besoin d’attendre le retour du serveur qui l’aura utilisé.

Maintenant, que fait-on quand on met en place un pattern Request / Reply ? On ajoute un écouteur en retour, et on demande au serveur de nous envoyer un message asynchrone avec les résultats du traitement précédent. Je me demandais bien si ça ne suffisait pas à supprimer les avantages de l’asynchronisme. En effet, on se retrouve tout de même à attendre quelque chose.

La solution

En fait, le problème venait du fait que je raisonnais uniquement autour de ce message. Or, ce qui compte finalement n’est pas vraiment le tuyau ni le middleware. Ce qui compte est ce que le client fait pendant ce temps-là. Si effectivement on entre dans une boucle d’attente, on a effectivement transformé un comportement asynchrone en synchrone, ce qui annule tout le bénéfice. L’important est de bien se baser sur une attente d’un évènement de retour, et de traiter le message de réponse dans un autre thread. Après, du point de vue du client, ça peut prendre la forme d’un message “Toast” ou de n’importe quoi…

L’explication “pour les nuls”

Ce qui m’a vraiment fait faire tilt est quand je me suis mis à comparer le travail d’un SI basé sur un bus ESB véhiculant des documents avec un bon vieux bureau à l’ancienne où les gens s’échangeait des dossiers. Lorsque vous posiez un dossier sur le bureau de quelqu’un et que vous aviez besoin qu’il remplace une fiche avant de vous le repasser, vous étiez effectivement en mode asynchrone. En effet, lorsque vous retourniez à votre bureau, vous accomplissiez d’autres tâches, et vous n’attendiez pas en vous tournant les pouces que la personne vous ramène le dossier.

Le résumé

Le dossier = Le message sur le bus.

Vous et la personne = le client et le serveur.

La requête = le fait que vous demandiez un avis sur le dossier.

La réponse = le dossier qui revient avec un avis.

L’asynchronisme = si vous bossez pendant ce temps là.

Le traitement synchrone = si, après avoir posé le dossier sur le bureau de la personne, vous attendez bêtement devant en ne faisant rien qu’il se décide à y jeter un oeil.

La conclusion

Je crois qu’il n’y a pas besoin de sortir de Saint Cyr pour voir que la productivité sera meilleure dans l’avant dernier cas que dans le dernier.

Posted in Veille | Tagged | Leave a comment

Même en Belgique !

Je suis assez fier de vous faire part du lien ci-dessous, qui m’a appris que mon livre était lu jusqu’en Belgique ! Moi, j’étais déjà content qu’il sorte des portes de ma société Sourire

http://informaticien.be/articles_item-9948-Ecrire_du_code__NET_performant__profilage_et_bonnes_pratiques.html

Posted in .NET | Leave a comment

Agile Tour Vannes 2011 : appel à conférences

Ca y est : l’Agile Tour Vannes est annoncé pour le 17 novembre 2011, et l’appel à candidature est ouvert pour les conférences ! Le thème fort de l’année sera le retour d’expérience et la mise en oeuvre concrète de l’agilité.

Tous les détails sur http://at2011.agiletour.org/fr/at2011_vannes_orateurs.html

Happy AT !

Posted in Agile, Retours | Tagged | Leave a comment

Audits de sécurité : la règle des trois “Con…”

Ca fait un bout de temps que je voulais faire une entrée de blog avec ce concept, que j’ai affiné au fur et à mesure des différents audits de sécurité de code menés en interne, ainsi qu’en en parlant avec plusieurs personnes confrontés au même problème. Et ce encore récemment au BreizhCamp où j’ai eu le plaisir de présenter deux conférences : comparaison Java / .NET (dans un repaire de Javamen, il fallait l’oser Sourire) et Prévalence Objet dans une architecture DDD.

Le problème

Le problème est le suivant : comment s’assurer qu’un audit de sécurité est équitable ? En effet, s’il s’agit de retourner une application dans tous les sens, avec en plus un accès au code, et de déclarer non-conforme le logiciel dès qu’on trouve une faille, je ne connais aucun cas qui résisterait et l’actualité nous montre encore que personne n’est à l’abri. Pourtant, il faut bien s’assurer que les logiciels fournis ne sont pas des passoires. Comment faire pour positionner le curseur de façon à être sévère mais juste ?

Je propose de suivre ce que j’appelle la règle des trois “con”. Pas des trois cons, des trois “con…”, à savoir Confidentialité, Conformité et Complétude. Pour moi, un audit de code doit se plier à ces trois règles :

Confidentialité

Ca parait peut-être évident, mais la première chose à vérifier chez un auditeur de code pour la sécurité est qu’il applique les bons principes de confidentialité. Si vous livrez votre code pour inspection, comment s’assure-t-il qu’un stagiaire chez lui ne va pas l’embarquer sur une clé USB pour le regarder chez lui ? Si un ordinateur est volé, le code est-il sur une partition cryptée ? Etc.

Pour le résultat de l’audit, la confidentialité est également de mise : non seulement le demandeur de l’audit doit être informé de manière confidentielle, c’est-à-dire en minimisant au maximum les résultats de fuite, mais en plus, il faut respecter une éthique de diffusion à l’éditeur : hors de question de prévenir un utilisateur d’une faille et de ne pas avoir prévenu au préalable, ou au minimum en même temps, l’éditeur.

Conformité

L’application auditée doit être conforme à son utilisation réelle et effective. L’idée est de dire qu’une application ne peut pas être auditée en dehors de son environnement de déploiement en production. Le fait de monter un environnement d’analyse est dès le départ biaisé, car les sécurités ne seront pas les mêmes.

Exemple typique : tester un serveur de services web en dehors de son environnement de déploiement. Si les appels sont réalisés par une DMZ avec échanges HTTPS, il n’y a aucun sens, par exemple, à noter comme une faille de sécurité une authentification automatique. De nombreux mécanismes de SSO consiste en une authentification accordée par confiance complète à l’appelant, en mitigeant ce risque par la mise en place de sécurités additionnelles sur l’identité de cet appelant : pare-feu, résolution de challenge cryptographique, validation de certificat, etc. Si on teste le serveur en dehors de cet environnement sécurisé, l’authentification automatique est évidemment une faille.

Complétude

C’est le dernier des critères, et le moins évident. Il pourrait sembler proche du précédent, mais il est en fait son pendant dans un sens inverse de généralisation. Il s’agit de rendre obligatoire le test de la totalité de la chaine applicative. En effet, de la même manière qu’il serait injuste de tester une application ou un code en dehors de son environnement conforme de production, il est illogique de les tester de manière restreinte à cet environnement d’appelants.

Il apparait donc important de valider la ligne complète d’exploitation, sans parler uniquement de logiciel. Le cas typique est une application très bien sécurisée, mais sur des serveurs ouverts à l’extérieur avec un mot de passe faible, une cryptographie défaillante, des ports ouverts sans discernements, etc. Voire dans certains cas une sécurité physique défaillante. Je ne citerai pas de nom, mais les exemples sont nombreux d’entreprises dans lesquelles une simple visite physique permet d’accéder aux salles de serveurs. Il est évident que la solution applicative ne saurait être prise en défaut si l’accès physique n’est pas interdit.

Bref, il est essentiel de faire porter l’audit sur la chaine d’exploitation non seulement conforme, mais aussi complète.

Proposition

Voilà pour mon humble contribution à la définition des audits de sécurité sur le code. Je suis plus habitué à la technique qu’aux procédures, donc tous les commentaires sont, encore plus que d’habitude, les bienvenus.

Posted in Sécurité | Leave a comment

Elément final </feed> manquant

Le problème

Je viens de tomber sur un bug (?) en utilisant WCF Data Services, et je suis pourtant en SP1 de VS2010. Imaginons le code ci-dessous :

using System;
using System.Data.Services;
using System.Data.Services.Common;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Web;
using System.Xml;

namespace Test
{
    [DataServiceKey(&quot;ID&quot;)]
    public class Modification
    {
        public int ID { get; set; }
        public string Module { get; set; }
        public string CommitID { get; set; }
    }

    public class Historique
    {
        private static List&lt;Modification&gt; _Modifications = new List&lt;Modification&gt;();

        static Historique()
        {
            // Code pour remplir la liste de modifications avec des instances
        }

        public IQueryable&lt;Modification&gt; Modifications
        {
            get { return _Modifications.AsQueryable(); }
        }
    }

    public class HistoriqueCVS : DataService&lt;Historique&gt;
    {
        public static void InitializeService(DataServiceConfiguration config)
        {
            config.SetEntitySetAccessRule(&quot;*&quot;, EntitySetRights.AllRead);
            config.SetServiceOperationAccessRule(&quot;*&quot;, ServiceOperationRights.All);
            config.MaxResultsPerCollection = 100;
        }
    }
}

Si j’utilise le code tel quel, le résultat renvoyé par le service OData est du XML mal formé : il manque la toute dernière balise, à savoir la fermeture de la racine </feed> !

Solution temporaire

Visiblement, c’est le MaxResultsPerCollection qui pose problème, car si je remplace son affectation par le code ci-dessous, tout va bien :

config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
config.SetEntitySetPageSize(&quot;*&quot;, 100);

D’après différents forums et blogs, il est de toute façon recommandé d’utiliser SetEntitySetPageSize plutôt que MaxResultsPerCollection (et d’ailleurs ils ne peuvent pas être utilisés ensemble, d’après http://stackoverflow.com/questions/5682763/why-cant-we-use-setentitysetpagesize-and-maxresultspercollection-together), mais bon… aucune raison que le XML soit pourri en sortie.

Remarques

Quand on teste sur un navigateur, ça ne pose pas de problème : Firefox comme IE sont en fait extrêmement tolérants (trop…), et le fait que le XML ne soit pas bien formé ne les empêche pas d’afficher le contenu du fil ATOM.

Par contre, dès qu’on utilise un client un peu plus sophistiqué, comme par exemple le plugin PowerPivot Excel, ça plante….

Référence pour le suivi

Si vous avez besoin de suivre la résolution de ce bug, c’est sur http://social.msdn.microsoft.com/Forums/en/adodotnetdataservices/thread/b4f44fdc-ad9a-44fd-941b-4e36e4d5a2db

Réponse Microsoft

La réponse n’a pas tardé, et tenez-vous bien : c’est prévu comme ça ! Oui, WCF Data Services décide d’envoyer exprès un XML mal formé (je n’ai pas dit non valide, mais vraiment mal formé)…

L’explication étant qu’il faut à tout prix faire planter le client pour qu’il ne prenne pas en compte une donnée incomplète. Je ne dois pas avoir tout compris, parce que dans ce cas, pourquoi continuer à envoyer de la donnée, et ne pas simplement envoyer en plus un code HTTP en erreur ?

Et surtout, le but n’est pas du tout atteint, car IE 8 comme Firefox 4 sont justement extrêmement tolérants et affichent tout de même les données, sans montrer de trace d’une erreur…

A suivre sur le forum de Microsoft…

Posted in .NET, Debogage | Tagged | Leave a comment

Tous au Breizh C@mp !

Le BreizhCamp, c’est une journée de conférences multi-technologies à Rennes. Toutes les communautés interviennent :

image

Le programme est absolument superbe : http://www.breizhcamp.org/programme

Il y a quatre sessions en parallèle, et à part les horaires où j’interviens, et pour lesquels je n’ai donc pas à me poser la question (mais j’ai des regrets, par contre), j’hésite à chaque fois entre plusieurs conférences…

Je crois que mon programme va être :

  • Lean .NET architecture
  • Réalité augmentée dans Android
  • Green-IT : que peuvent faire les développeurs ?
  • NoSQL avec Ruby/Rails
  • Hibernate vs le Cloud Computing

Bref, je ne peux que vous encourager à venir à Rennes le 16 juin…

EDIT :

Oups, je viens de jeter un oeil à nouveau sur le site et il semble que…

image

Posted in Retours, Veille | Tagged | Leave a comment

Livre “Ecrire du code .NET performant – Profilage et bonnes pratiques”

Pourquoi ce livre

Pourquoi écrit-on un livre ? Chaque auteur aura sa réponse, la mienne est que je ressens le besoin de faire partager ce que j’apprends. Comme lorsque je fais des cours à l’université ou des formations internes à mes collègues, j’ai envie de faire comprendre aux autres.

Or, suite à de nombreux audits de code sur des problématiques de performance, je me suis rendu compte de quelque chose d’important, que dis-je… de fondamental : la performance d’une application n’est pas une affaire d’experts. Et j’ai eu envie de le faire savoir. D’où ce livre :

EIECR_max

Pour ceux qui savaient, j’enfonce une porte ouverte. J’ai failli écrire “c’est une tautologie”, mais on m’aurait encore reproché d’étaler ma littérature. Or, étaler sa science en écrivant un bouquin devrait déjà suffire à me classer dans la catégorie des fortes-chevilles. Mais revenons à nos moutons : personnellement, il y a quelques années à peine, la notion de performance de code me paraissait relever de l’expertise. Pour écrire du code rapide, il fallait faire du tuning applicatif, voire réécrire certains blocs en C, etc.

En fait, je me suis rendu compte au fur et à mesure d’audits de performance que dans l’énorme majorité des cas, l’utilisation d’un logiciel de profilage du code me désignait relativement vite le code coupable, et que sa lenteur relevait presque toujours d’une programmation correcte fonctionnellement, mais simplement lente. Sur plusieurs dizaines d’améliorations de performances, je n’ai fait que modifier légèrement du code pour le rendre plus rapide. Jamais je n’ai dégainé les armes du tuning : pas de codage de portions en C, pas de mise en place de caches complexes, pas de scale-out…

Déçus ?

Peut-être le serez-vous… Quand on recherche les blogs sur la performance, on trouve énormément d’articles sur des cas de tuning extrêmes, techniquement très complexes et qui nécessitent une énergie phénoménale pour aller chercher quelques derniers pourcents. Vous trouverez également des tas d’articles sur les architectures spéciales mises en place par Google et consorts pour supporter des charges énormes avec des temps d’accès très bas.

Désolé de vous décevoir, mais le quotidien d’un développeur spécialisé dans la performance est de régler les quelques 20% d’erreurs traditionnelles qui représentent 80% des lenteurs. Parce qu’en plus, ces erreurs sont bien connues, et vous les avez certainement tous déjà vues : des appels de requêtes SQL en boucle, des concaténations de chaines multiples au lieu d’utiliser un StringBuilder, etc. Rien de très sexy, pas de découverte extraordinaire ou de méthodes hautement intellectuelles. Vous ne trouverez dans ce livre aucune surprise…

Ce que vous trouverez, par contre, ce sont des méthodes pour profiler rapidement une application .NET, identifier au plus vite dans les résultats les indices de telle ou telle erreur, puis la façon la plus efficace de traiter.

Contenu

En plus de ces méthodes d’identification rapide et de résolution des problèmes traditionnels de performance (et une checklist pour les plus pressés), vous trouverez dans ce livre un exemple d’analyse pour chaque cas. J’ai créé une application sur mesure qui regroupe tous les “smells” (inverses de “patterns”) possibles, et les chapitres vous accompagneront dans le profilage et la correction progressive de cette application. Pas à pas, vous passerez d’un pot-pourri de toutes les erreurs de code en termes de performance à une application affûtée… et trois fois plus rapide en moyenne, avec des pointes à 100 fois plus rapide pour certains traitements !

Les premiers chapitres vous exposeront des principes de base de la gestion de la performance en général, ainsi qu’une étude avancée des fonctionnalités de .NET liées à la rapidité d’exécution. En toute immodestie, je pense que le chapitre sur la gestion de la mémoire est ce que vous pourrez trouver de plus complet à ce jour en langue française.

Enfin, je n’ai bien sûr pas pu résister à étendre le sujet au tuning et à la réarchitecture. Ce n’est pas parce que le profilage simple résout 95% des problèmes qu’il ne fallait pas parler des 5% restants. Scale-up ou scale-out, techniques de persistance innovantes, etc. Si le profilage ne suffit pas, vous aurez les pistes pour passer à l’échelon supérieur.

Référence

Bon, après tout ça, si je ne vous ai pas donné envie de lire ce livre, je ne vois pas ce que je peux dire de plus…

Si vous vous dites par contre que vos applications pourraient supporter de voir leur temps d’exécution divisé par deux en apprenant quelques méthodes simples et en investissant une somme absolument ridicule, c’est par ici : Editions ENI – Ecrire du code .NET performant.

Préface par notre dieu en personne !

Et pour les plus geeks d’entre vous : la préface a été écrite par Eric Mittelette ! Notre gourou à tous, celui qui a accompagné nos premiers Tech Days, qui nous a expliqué comment créer une classe en .NET, Monsieur “Mieux que des mots, démo !”, m’a fait l’honneur de supporter mon humble contribution à une bonne pratique de .NET.

Eric, évangéliste .NET de la première heure, responsable de l’équipe relation avec les développeurs, et surtout une des rares personnes à parler sérieusement d’écologie dans l’informatique, était le signataire de rêve pour cette préface : l’optimisation logicielle est, à notre avis, une prochaine étape du Green IT.

J’ai toujours eu des regrets sur ma thèse en écologie : elle a reçu le prix Cherry de Cranfield University, mais je n’ai pas su diffuser le logiciel EOLE qui en était le produit et participer ainsi à une conception plus écologique des produits manufacturés. J’espère que ce livre va montrer à de nombreux développeurs que quelques méthodes simples permettront d’acheter moins de machines, de consommer moins de CPU, d’électricité, de mémoire, de climatisation, etc.

Voila, voila… c’était la séquence “auto-promotion”. Maintenant, je compte sur vous pour filer l’acheter, et en faire la publicité à tous vos collègues et amis !

La planète vous remercie… et moi aussi Sourire

Posted in .NET, Veille | Leave a comment