Offre d’essai pour le micro-crédit Kiva

Un billet non technique pour une fois, mais vu que ce blog commence à avoir un peu d’audience, je m’en voudrais de ne pas faire un minimum de publicité pour une TRES bonne cause Sourire

J’ai la chance d’avoir un bon boulot, et d’épargner un peu d’argent chaque mois. Mais comme il est hors de question pour moi d’acheter des actions (pas envie de me faire plumer par les gros épargnants, de perdre 20% de la valeur de mon travail du jour au lendemain parce qu’un émir s’est levé du mauvais pied, de savoir que mon argent est utilisé pour des opérations que je n’approuve pas, les raisons sont nombreuses…), je prête par le biais du micro-crédit, en utilisant Kiva.

image

Ca ne rapporte rien (ce sont des prêts à 0%)… à part un grand bonheur de donner un petit coup de main à des gens qui le méritent ! J’ai failli dire de la fierté, mais je ne me sens pas “fier” de gagner dix fois plus que certains à l’autre bout du monde. Heureux, en tout cas, d’avoir trouvé ce moyen de faire quelque chose d’utile, et qui prouve que nous pouvons apporter quelque chose à quelqu’un. Même si on est tout petit dans le village mondial, et malgré que les nouvelles chaque jour nous martèlent que nous n’y pouvons rien… Là, je sais que mon argent sert à quelque chose, à mon humble niveau.

Le fait de prêter à une personne, de savoir pour quel projet, me rend vraiment heureux. Et ne croyez surtout pas que vous avez l’impression de “donner à vos pauvres” comme des grands bourgeois du vieux siècle : tous les emprunteurs de Kiva sont des entrepreneurs. De vrais entrepreneurs. Pas du genre à manipuler de l’argent derrière un bureau, mais plutôt à se retrousser les manches et à donner de leur travail pour améliorer leur vie et celle de leur famille. Il n’y a qu’à voir le taux de remboursement : j’ai réalisé une petite cinquantaine de prêts depuis 2008, et je n’ai jamais eu un seul défaut de paiement.

La raison pour laquelle je fais cet article de blog aujourd’hui est pour relayer une offre de Kiva, sponsorisée par Reid Hoffman : j’ai donc le plaisir de vous offrir de leur part votre premier prêt de 25$ sur Kiva ! Vous pouvez sélectionner un entrepreneur qui a un projet qui vous plait, dans une région du monde que vous aimez, et ajouter sans frais pour vous 25$ sur son micro-crédit… Pour cela, tout simple : http://www.kiva.org/invitedby/esvrt1910

image

Merci à toutes les personnes de Kiva de nous permettre de participer, et de faire le relai sur le terrain ! Ils donnent beaucoup plus que ce que je fais en prêtant simplement de l’argent, et si par hasard certains me lisent, qu’ils sachent qu’ils sont les héros de ces temps modernes Sourire

Posted in Uncategorized | Leave a comment

Message UTA004

Si vous obtenez le message suivant de Visual Studio, attention : la correction n’est pas nécessairement celle à laquelle on pense immédiatement en lisant le message.

Utilisation non conforme d’attribut sur [Nom de la classe]. TestMethodAttribute peut être défini uniquement dans une classe qui est marquée avec l’attribut TestClass.

Le réflexe est bien sûr de regarder la présence de l’attribut sur la classe :

image

Le problème est qu’il est possible de recevoir ce message même si l’attribut [TestClass] est présent, tout simplement parce que la classe n’est pas marquée public. La solution est donc simplement la suivante :

image

Posted in Uncategorized | Leave a comment

Wébinaire sur le profilage de performance en .NET

Mardi 3 Avril, de 17h00 à 18h00 heure française, je donne un séminaire web sur le profilage de performance d’une application .NET. A l’occasion de la sortie de la version anglaise de mon livre sur le sujet, RedGate m’a invité à partager quelques-uns des patterns de profilage, en utilisant leur produit ANTS Performance Profiler.

image

Je vous donnerai donc quelques trucs et astuces de base pour trouver rapidement les goulets d’étranglements dans une application .NET, et les résoudre. La partie Questions / Réponses sera animée par Chris Allen (10 ans d’expérience dans le support Red Gate, donc n’hésitez pas à sortir les questions dures : il a réponse à tout…).

Pour vous inscrire : https://www3.gotomeeting.com/register/829014934

J’espère vous voir nombreux Sourire

Posted in .NET, Performance | Leave a comment

Construire des applications LOB en HTML5 ?

Vu le battage qu’il y a autour d’HTML5 (et j’ai déjà écrit là-dessus dans ce blog), je voulais savoir ce qu’on pouvait réellement faire avec. Je vous avoue que je partais avec un gros a priori, du principalement à cet engouement forcené qu’on entend autour d’HTML5, alors que ça reste un langage de structuration de pages web (en fait, pas tout à fait, car il faut comprendre HTML5 comme HTML5 + CSS3 + JavaScript + toutes les nouvelles API qui vont faire qu’HTML5 pourra se rapprocher d’un langage de programmation d’application).

Mes sources (supplémentaires)

Du coup, j’ai continué à me documenter plus en profondeur avec les deux livres suivants :

image

HTML5, Une référence pour le développeur web, de Rodolphe Rimelé, mérite bien son titre : c’est un pavé de 600 pages avec absolument tout le contenu de HTML5 et des APIs associées. Excellent bouquin, comme souvent chez Eyrolles.

image

Savoir tout faire pour le web CSS3, HTLM5 et jQuery, de Julien Debove, peut paraître maigre à côté avec ses 230 pages et ses super-héros en couverture, mais il est intéressant en complément, car contenant uniquement des petits bouts d’HTML5 appliqués à des situations diverses et variées. Il ne s’agit pas toutefois d’une simple liste d’astuces, car les différents extraits sont reliés par groupes pour obtenir une fonctionnalité plus complexe. Pas du tout la même approche que le précédent, donc, car il n’y a aucune théorie, mais complémentaire.

La méthode

Afin de voir s’il était possible de construire une application Line Of Business avec HTML5, je suis parti d’une application métier que je connais bien, puisque c’est celle sur laquelle je travaille depuis maintenant une dizaine d’années pour mon employeur.

J’ai relevé une liste de points saillants de cet applicatif, dans le but de voir comment je pouvais les mettre en œuvre en HTML5, à savoir :

  • Authentification sécurisée
  • Modularité de l’interface, adaptable aux différents clients (et pas seulement les couleurs, mais bien le contenu)
  • Cryptage partiel des transferts entre le client lourd (WinForms) et le serveur de services (ASP.NET ASMX)
  • Validation des entrées en amont en plus du serveur
  • Appel de services web par des stubs générés depuis des WSDL
  • Délégation de certains traitements au client
  • Stockage de fichiers temporaires
  • Lancement d’applications externes pour interopérabilité ou pilotage
  • Formulaires avancés avec layout composite complexe
  • Possibilité d’inclure des contenus dans d’autres
  • Affichages de graphiques avec possibilité d’interaction sur les points d’inflexion des courbes

Ensuite, toute l’idée a consisté, à partir de ces deux bouquins et des deux précédent (voir lien au début), à créer des petits bouts de code HTML5 pour voir si je pouvais réaliser dans cette technologie (et avec mon niveau de débutant en HTML5, mais à l’aise avec les technos web en général) les différents points de la liste.

Le verdict (le mien, en tout cas…)

La première remarque est que je n’ai pas pu mettre en œuvre tous les points de la liste, loin de là. C’est le cas du cryptage partiel, de la délégation de traitements métiers sur le client, du lancement d’applications externes, des appels de WS par stubs, et des layouts complexes.

Attention, je ne dis pas que ces points sont impossibles. Je sais bien en particulier qu’il y a tout ce qu’il faut en HTML pour faire des layouts. Simplement, par rapport à faire un GridLayout / FlowLayout équivalent en WPF, je n’ai pas trouvé le moyen de réaliser ce que je voulais en HTML5 / CSS3 dans un temps que je trouvais raisonnable. Il y a bien sûr le fait que je connais bien WPF, et peu HTML5, mais je parle d’une fenêtre réalisée en 3 minutes environ en Visual Studio, et impossible à faire adopter un comportement tel que voulu au bout de plusieurs heures de manipulation en HTML5. Le seul moyen que j’ai trouvé à la fin était de retomber sur un <table>, mais ce n’est pas ce qui est promis par les nouvelles balises de HTML5, censées éliminer les besoins les plus habituels de <div> pour le layout…

De la même manière, il aurait certainement été possible de créer à grand renfort de JavaScript des stubs de consommation des services web, mais avec plus de difficulté qu’un simple ajout de référence web en .NET. En client léger, la logique est plus de déporter les commandes sur le serveur web et d’appeler depuis là les services web. Il y a toutefois des cas AJAX où on souhaite appeler les services web. Dans ce cas, on peut mapper des entités sur le contenu JSON, mais il n’y a alors pas de typage. En soi, ce n’est pas très gênant, mais on revient au problème de temps de mise au point.

Au final, dans tous les cas, et même ceux où j’ai réussi à trouver un équivalent HTML5 à mes points de fonctionnalité requis, on tombe toujours sur le problème du temps de programmation, démesuré par rapport à .NET. Je sais qu’il y a une part qui vient du fait que je connais bien C# et peu HTML5, mais ça ne suffit pas à expliquer une telle différence. Je ne connais rien à PHP et peu à Python, et pourtant je peux réaliser tous les points de ma liste avec eux en moins d’une heure pour chacun…

Et je n’ai même pas parlé des outils de développement. HTML5 n’est pas encore fini en tant que norme, donc il est logique que les outils de développement ne soient pas encore sorti, mais même dans les outils de type SDK qui sont censées être au moins autant au point que les API, je n’ai rien trouvé du niveau d’un Visual Studio. En particulier, pour le débogage, le plus simple a encore été de s’en remettre au débogueur intégré des navigateurs pour le contenu de la page, et à celui justement de Visual Studio pour toutes les parties en JavaScript…

Conclusion

J’estime avoir fait tous les efforts intellectuels nécessaires pour pouvoir dire en toute connaissance de cause qu’il est possible d’écrire des applications LOB en HTML5, mais pas de manière plus simple qu’en HTML4. Les quelques points qui apportent un réel plus dans ce sens sont à mon avis les suivants :

  • Le support de la validation des entrées dans les formulaires
  • Les types plus nombreux pour les formulaires (dates, etc.)
  • Un mode de stockage local qui permettra un cache client et des fichiers temporaires
  • Le canvas, qui va autoriser la mise au point de comportements graphiques pointus, même s’il faudra des API spécialisées pour l’exploiter pleinement (mais ceci n’est pas différent de .NET)

Malheureusement, ces quelques points ne représentent que le dixième de ce qu’il est nécessaire pour une vraie application LOB. Je pense que c’est là que se pose le problème de démesure des attentes sur HTML5. Les personnes le poussant venant du design web ne voient peut-être pas tout ce qu’il faut pour une application lourde… De coup, les efforts qui ont été faits dans le sens LOB leur paraissent énormes, alors qu’ils sont loin de suffire.

Quelque chose qui me parait représentatif de cet état d’esprit : cet article sur Clubic présentant comme admirable la mise au point d’un jeu en HTML5. Je suis d’accord que c’est une performance de programmation, et que ça montre des progrès énormes par rapport à HTML4, mais il s’agit tout de même d’un jeu vieux d’une dizaine d’années et absolument incomparable avec ce qui se fait aujourd’hui en application lourde. Encore une fois, il ne s’agit pas de rabaisser cette performance et les apports importants de HTML5 aux applications web, mais il ne faut pas non plus se faire d’illusion sur leur capacité à remplacer les applications lourdes. Pour moi, nous allons encore rester longtemps dans le schéma suivant :

image

HTML5 a effectivement barré le chemin à un développement de Silverlight ou de Flash, mais il est loin de pouvoir créer des applications du même niveau de richesse que des applications natives.

Au final, l’approche WinRT permettra de supporter à la fois du natif et du HTML5, avec un mode de type “graceful degradation”. A l’inverse, HTML5 ne pourra pas se hisser vers un équivalent. Peut-être pour HTML6, mais au rythme où la norme évolue, ce ne sera pas avant 2020 au mieux.

Posted in Uncategorized | Tagged | Leave a comment

Article sur GreenIT.fr

La republication de mon article “Cloud, Big Data et traitement asynchrone : danger pour l’environnement” sur leur plateforme est l’occasion de faire un brin de publicité à GreenIT.fr.

image

J’avais eu l’occasion de rencontrer Olivier Philippot au BreizhCamp, et du coup pu mettre un visage sur un des meneurs de ce site que j’avais déjà repéré depuis longtemps, m’intéressant à GreenIT de longue date.

Le site est très fourni en termes d’articles, mais avec des rubriques plus orientées “pratiques”. Surtout, il est l’un des rares sites dédiés à GreenIT, et où ce sujet fondamental n’est pas abordé juste par le bout de la lorgnette Sourire

image

Posted in Retours | Tagged | Leave a comment

Data = connaissance ?

L’énigme

Le titre reste à l’état de question, parce qu’honnêtement, je n’ai pas de réponse intelligente à fournir, mais seulement quelques pistes de réflexion. Pour moi, cette réflexion a commencé lorsqu’en préparant un cours sur le futur de la BI (ou plutôt son absence de futur dans son état actuel), je suis tombé sur la déclaration suivante :

image

Je dois avouer que la première fois que j’ai lu ceci, mon premier réflexe a été de rejeter complètement cette analyse : comment pouvait-on (un scientifique, de surcroit) confondre la donnée avec la connaissance. Prétendre que Google était meilleur non pas par une supériorité de ses algorithmes, donc de son intelligence de fonctionnement, mais par un stupide empilement de données plus haut que celui de ses concurrents me paraissait le comble de l’absurdité. C’était pour moi comme dire qu’un cerveau avait plus besoin de neurones que de synapses…

Dans le même temps, j’étais en train d’expliquer à mes étudiants que l’approche centralisatrice de la Business Intelligence avait échoué suite à la course au volume de données, les entreprises se gargarisant de leur data warehouses de plusieurs centaines de téraoctets alors que les bénéfices retirés ne s’élevaient au mieux qu’au dixième des sommes investies… Dès lors, comment expliquer cette phrase ?

Un début de réponse

En m’informant sur le mouvement Big Data, je crois que j’ai compris ce que Norvig voulait dire. Lorsqu’on cherche une information sans connaitre à l’avance les caractéristiques précises de son apparition, la recherche de ces “signaux faibles” se fera d’autant mieux que l’échantillon qu’on recherche est le plus grand possible.

Si l’on prend l’exemple d’une recherche d’intrusion dans des logs de serveurs web, il s’agit de trouver des connexions qui ne se comportent pas comme les autres. Une approche “brute” est de regarder les connexions la nuit, par exemple, mais ceci peut se faire sans approche de cluster, il suffirait d’un cube. Si on cherche à trouver des comportements suspects non pas par une explication rationnelle, mais par la simple répartition statistique anormale qu’ils montrent, il nous faut évidemment beaucoup plus de données, et surtout une méthode de recherche moins orientée, mais balayant tous les critères.

On peut extrapoler ceci à une recherche d’association de mots-clés comme ce que Google fait avec son moteur de recherche et surtout les sources multiples dont il dispose pour analyser les traces laissées par chacun de nous sur ce même moteur. Dans ce cas, je comprends effectivement qu’une masse plus grande de données puisse conférer une qualité finale de traitement meilleure.

Mais il manque un truc

Il manque quand même quelque chose : déjà, qui dit plus de données dit également des méthodes plus performantes pour les traiter dans un laps de temps aussi réduit que les autres. Et là, nous parlons bien d’algorithmique. De la même manière, la mise en place et l’exploitation de systèmes Big Data a nécessité une activité de recherche qui n’a rien à voir avec la taille de données à traiter. Il est donc vrai que c’est la masse de données qui fait la pertinence de l’indexation de Google, mais je trouve faux de présenter cette masse de données comme la seule raison de l’avance de Google. C’est peut-être de la modestie de la part de Norvig, mais toute ces données ne serviraient à rien s’il n’y avait pas une énorme intelligence de gestion derrière.

Une autre remarque : l’approche Big Data est peut-être efficace, mais d’une certaine manière, elle apparait comme une sorte de pis-aller par rapport à l’algorithmique : on cherche des signaux faibles car on est incapable de mettre au point des traitements et algorithmes permettant d’obtenir le même résultat de manière directe.

Il ne manque pourtant pas de pistes pour améliorer l’intelligibilité de la donnée sur le web : MicroData, web sémantique, utilisation des RDF ou des micro-formats, etc. Tim Berners-Lee pousse cette approche. Au lieu de faire tourner des clusters énormes pour déduire à partir d’un mot-clé et de l’ensemble d’une base de connaissance qu’il s’agit d’une personne et qu’elle habite en France, ne serait-il pas plus logique de faire l’effort de rajouter une identité FOAF sur la citation du nom de la personne ? On en revient toujours à l’optimisation des processus nécessaires au GreenIT : un petit effort sur le développement pour gagner énormément de ressources…

Pour finir

Une conclusion à la normande, ce coup-ci : peut-être bien que Norvig a raison, mais peut-être bien aussi que Berners-Lee est plus visionnaire… Je crois avoir compris ce que sous-entendait le propos de Norvig, mais personnellement, je reste convaincu qu’un traitement plus intelligent des données nous amènera plus loin que l’application de méthodes très gourmandes pour des résultats similaires. Maintenant, je ne prétends pas à avoir la même vision que le “Chief Scientist” de Google : ceci est juste l’état de ma réflexion à ce jour…

Posted in Uncategorized | Tagged | Leave a comment

BreizhCamp 2012 !

Je viens de faire un petit tour sur http://www.breizhcamp.org/ par acquit de conscience, et c’est reparti en 2012, avec deux journées au programme ! Yes Sourire

Pour ceux qui ne connaissent pas, il s’agit de la meilleure conférence informatique de tout l’Ouest. (Français… pas le Far West, quand même) : tous les langages sont représentés, toutes les méthodologies, avec des sujets super pointus, des intervenants au top…

Bref, il me tarde déjà les 14 et 15 juin !

Posted in Veille | Leave a comment

GreenIT et Cloud / Programmation asynchrone / Big Data

Disclaimer (comme disent les juristes)

Avant de commencer, je pense utile de préciser que je parle de GreenIT en connaissance de cause, parce que tellement de sociétés informatique ont mis le terme à toutes les sauces qu’il est malheureusement devenu galvaudé. Je tiens à vous rassurer sur le sérieux de mon intérêt pour l’écologie appliquée à l’informatique…

  1. Une des principales motivations de mon livre sur la performance en .NET était de diffuser des bonnes pratiques pour réduire le gaspillage de ressources, et au moment de proposer à un gourou d’écrire la préface, je n’ai proposé qu’à deux personnes, dont Eric Mittelette précisément parce qu’il est en charge de GreenIT chez Microsoft.
  2. Je suis, je pense, plus attentif que la moyenne à consommer le moins possible et de façon responsable : je vais au boulot à vélo 6 mois par an sauf tendinite, je n’ai changé d’ordinateur qu’une fois en 10 ans, j’use mes polaires jusqu’à la corde (mes collègues peuvent témoigner), je roule en hybride, et je fais même mon potager.
  3. Ma thèse de Master était sur la conception en vue du recyclage et de la fin de vie des produits, et c’était il y a plus de 15 ans, à l’époque où ce n’était pas vraiment à la mode…

C’est quoi, mon souci ?

Le disclaimer étant posé, voici mon souci : je pense que trois des pistes majeures qui nous sont aujourd’hui proposées en tant qu’innovations informatiques peuvent avoir un impact négatif sur la consommation de ressources.

  1. Le Cloud : le fait de disposer ponctuellement d’énormément de ressources pour un coût équivalent à la possession de moins de machines a bien sûr un intérêt en termes de réduction de parc des sociétés utilisatrices, mais peut également pousser à une surconsommation, par déresponsabilisation (pas d’acte d’achat).
  2. La programmation asynchrone : le temps de traitement synchrone possède une force de signal pour un utilisateur, en termes de ressources nécessaires à un traitement. L’asynchronisme supprime ce retour.
  3. Big Data : si vous donnez la possibilité à un analyse de réaliser, en mettant des machines en cluster, des simulations ou des requêtes qui étaient auparavant inutiles car trop longues, il est évident que ces activités vont être de plus en plus sollicitées par celui-ci.

Mais ce qui m’embête le plus, c’est l’effet suivant qu’induit le mélange de ces technologies :

La boucle de rétroaction liant la quantité de ressources à la difficulté perçue du traitement risque à terme de disparaitre. Or, il s’agit d’un des seuls garde-fous sur la consommation de ressources informatiques.

Une image vaut mille mots

Je mesure qu’en mode texte, ce n’est peut-être pas très clair. Du coup, j’ai fait l’effort de faire une petite série de diagrammes. Quand on dit que PowerPoint rend bête, je ne suis pas d’accord… Les bullet points rendent bête. Les transitions graphiques sublimes sur un contenu inexistant rendent bête. Les titres accrocheurs sans explication rationnelle rendent bête. Mais pas l’outil, ni la facilité qu’il procure pour créer un diagramme.

Voici en gros comment se passe la boucle de rétroaction dans une architecture “traditionnelle”, avec un client envoyant une requête à un serveur :

image

Dans la boucle intérieure, une requête simple provoque une retour rapide. Dans la boucle extérieure, une requête plus complexe provoque un retour plus lent. L’utilisateur reçoit un signal en retour concernant la complexité de ce qu’il demande au serveur, et sera donc vaguement conscient du niveau de ressources nécessaires.

On passe en mode Cloud, avec un cluster de machines dédiées à votre système Big Data :

image

Vous voyez le problème ? On n’a plus de retour sur la complexité du traitement, car le lissage va se faire sur le nombre de machines. Que le traitement mobilise toutes les ressources du cluster ou une seule table de référence pour répondre, le traitement ne prendra pas fondamentalement plus de temps. L’utilisateur n’a plus de retour intuitif sur la quantité de ressources que son interaction lui a fait consommer.

Et si on va plus loin avec un traitement asynchrone, c’est encore pire :

image

Là, il se peut carrément que l’utilisateur ne reçoive aucune retour, en fonction du comportement de son logiciel et des notifications associées.

Pourquoi c’est gênant

Dans un monde idéal avec des développements performants et des niveaux de consommation rationnels, l’absence de la boucle de rétroaction (l’utilisateur utilise moins de ressources, car il se rend compte que les actions sont lentes et tend à les économiser) ne serait pas si gênante.

Mais à part dans des cas très particuliers, les développements sont rarement optimaux du point de vue de l’utilisation des ressources (avez-vous déjà discuté plus d’une heure avec un utilisateur sans qu’il se plaigne de la performance de votre application ?).

De plus, le manque de retour favorise une consommation surélevée de la ressource. Prenons l’exemple du courrier électronique. J’avoue le premier ne pas faire attention aux nombre de mails que j’expédie. Le fait que l’envoi soit quasi-immédiat et que nous n’ayons aucun retour sur la complexité de faire transiter cette donnée de l’autre côté de la planète y est pour quelque chose. Si les mails avaient un coût direct, et pas seulement un coût indirect par l’abonnement, même très léger, nous n’en enverrions certainement pas autant. Imaginez que vous payiez un forfait à EDF… seriez-vous aussi attentifs à ne pas laisser les lumières derrière vous ?

Pour le Cloud et Big Data, c’est la même problématique : une interaction métier avec un serveur peut très bien mobiliser un cluster de 64 machines sans que vous en soyez conscient. Peut-être imaginerez-vous même qu’il ne s’agit que d’une requête à une base de données. De la même manière qu’un développeur appelle souvent de bonne fois une méthode dans une boucle sans s’être rendu compte que cette méthode appelait un service web… Et l’asynchronisme achève de rendre ceci transparent.

Conclusion

Pour autant, tout n’est pas noir. Il ne faut pas nier non plus que le fait de grouper des traitements dans des sites spécialisés, avec un refroidissement unifié ou encore mieux réalisé de manière passive (comme le fait OVH, ou avec des datacenters en environnements polaires) permet de réduire le coût énergétique global, et d’optimiser les ressources de construction des matériels.

L’approche Big Data, quant à elle, peut permettre d’avoir accès à des analyses qui auraient sinon été réalisées de toute manière à grand renfort de CPU sur plusieurs heures, voire plusieurs journées de traitement.

Enfin, l’asynchronisme est une des méthodes possibles pour favoriser le parallélisme et donc une meilleure utilisation des ressources.

Mais il ne faut pas oublier que, au delà de tous les efforts qui sont réalisés sur la réduction de la consommation sur une base fixe de traitements à réaliser, le mieux est encore de réduire au maximum les traitements à la source. Monsieur Ourghanlian, j’adore vos analyses, votre capacité à les expliquer et surtout votre ouverture sur des domaines autre que l’informatique, mais dans cet article, vous ne parlez à aucun moment du code, alors que c’est la racine du GreenIT !

Coder pour la performance dès le début est extraordinairement important, car cela influe sur tous les niveaux de la chaîne :

image

Il en va de même pour ces nouvelles approches architecturelles : avant de déployer des solutions qui empêchent toute conscience par un utilisateur de l’impact de ses actions, il convient de se poser la question si des approches plus légères ne seraient pas suffisantes, quitte à ce que l’utilisateur final patiente un peu, affine ses analyses avant de les faire tourner. Bref, l’aider à avoir un comportement plus écologiquement responsable.

Sur ce… je mets en veille j’éteins mon ordi Sourire

Posted in Performance, Retours, Uncategorized | Tagged | Leave a comment

Fier d’être développeur

Un article pas technique pour deux sous, ce soir, à propos du site http://fierdetredeveloppeur.org/. Il s’agit d’un mouvement lancé par Daniel Cohen-Zardi, Eric Mittelette et Eric Vernié, et qui a connu une présentation remarquée aux Tech Days cette année, lors de la plénière du premier jour.

image

Les principes sont les suivants (copie du blog) :

  1. Promouvoir le métier de développeur de logiciels,
  2. Expliquer la valeur de ce métier alliant rigueur scientifique et force de créativité,
  3. Communiquer la noblesse du choix de faire carrière en tant que développeur,
  4. Valoriser l’impact de l’expérience sur l’équation économique des développements logiciels,
  5. Encourager le respect mutuel entre les développeurs indépendamment des plates-formes et technologies utilisées.

“Fier”, vraiment ?

Bon, j’avoue avoir une réaction initiale un peu méfiante de tout ce qui commence par “fier de …”. De la même manière que je ne suis pas “fier d’être Picard d’origine”, je ne suis pas non plus “fier d’être Breton d’adoption”. Tiens, d’ailleurs, c’est la première proposition de Google quand on tape “fier de” :

image

Maintenant, quand j’y réfléchis, ce qui me gêne surtout dans cette expression est lorsqu’elle est utilisée dans un cas sur lequel un individu n’a pas prise. On n’a pas à être “fiers” d’être Breton / Picard / Corse / Français, pour la bonne et simple raison qu’on ne l’a pas choisi… C’est Brassens qui disait “Il n’y a que les cons qui sont fiers de venir de quelque part”. On peut bien sûr aimer sa région (bon, pour la Picardie, c’est un peu plus dur que pour la Bretagne Sourire), être contents d’y vivre, mais fiers… je ne pense pas.

Du coup, fier d’être développeur, pourquoi pas ? Là, au moins, on a prise dessus : je connais peu de gens qui se trouvent être devenus développeurs par hasard. Des étudiants arrivés sans grande conviction en IUT Informatique, oui… Mais en général, ils se rendent vite compte si ce n’est pas pour eux.

Donc, va pour la fierté, mais il faut encore savoir de quoi on peut être fier. Il est vrai que le métier n’est pas très reconnu. En même temps, je pense n’avoir jamais assisté à une réelle stigmatisation du métier, mais c’est peut-être juste parce que les gens à qui je parlais de mon job avaient un ordinateur à dépanner et ne voulaient pas me fâcher Sourire.

Valeur de l’expérience

Comment peut-on penser une minute qu’un développeur de plus de 35 ans est grillé ou nul ? A l’inverse, c’est à peine à cet âge qu’on commence à devenir un vrai développeur, à savoir quelqu’un capable de penser à tous les aspects d’un code. Coder un algorithme dans tel ou tel langage, c’est bien, mais il faut une expérience énorme pour le faire de manière professionnelle. Pour vous donner une idée de la chose, voici ce que veut dire “coder” pour un non-développeur :

  • Comprendre le problème
  • Taper du code
  • Compiler, tester
  • Envoyer chez le client

Mais pour un “vrai” développeur, en plus de ces activités de base, chaque ligne de code embarque une série de réflexions sur :

  • La robustesse du code : quels sont les cas dans lesquels il peut émettre une exception et comment ?
  • La performance : le code nécessite-t-il aussi peu de ressources pour s’exécuter qu’il est raisonnable ?
  • La sécurité : le code présente-t-il des failles connues (injections, attaques par canonicalisation, validation des entrants, etc.) ?
  • Le code est-il suffisamment couvert par des tests unitaires ?
  • Le code suit-il les bonnes pratiques SOLID ?

Nous pourrions en ajouter encore sans forcer. Or, tout ceci nécessite énormément de temps pour être acquis. Personnellement, j’ai commencé la programmation à l’âge de 12 ans, en créant un driver d’imprimante Citizen 120-D pour mon Amstrad CPC 6128. C’était une époque où utiliser un ordinateur signifiait naturellement programmer. Le lancement même d’un programme était un ordre BASIC (par contre, l’ordi bootait en zéro secondes Sourire). Et après… hmmm… 25 ans donc, je considère que je suis seulement en train de devenir un développeur accompli depuis quelques années, encore que j’ai des manques criants dans de nombreux domaines. On va dire en tout cas qu’en C#, ça y est : je vois à peu près les tenants et les aboutissants de tout ce que je peux écrire. Mais ça m’a pris une dizaine d’années, et encore je ne compte pas les années sur les autres langages, qui étaient nécessaires. Au final, il m’a fallu vingt ans pour coder “propre”.

Bon, il me faut bien admettre que je suis plutôt du genre diesel, à la course comme en termes de programmation. A l’inverse, je passe une bonne partie de mes soirées à bloguer sur de la programmation, à tester des beta, écrire des petits bouts de code pour test, ou écrire des livres sur les technologies Microsoft. Au final, je dois donc être dans la moyenne quand je prétends qu’un développeur ne devient vraiment bon qu’au bout d’une dizaine d’années de pratique.

A nos managers

Une dernière chose sur la valorisation de l’expérience, et ce à l’attention des managers de développeurs (et c’est le point le plus important parmi ma logorrhée verbale de ce soir) :

Un bon développeur n’est pas 2 (DEUX) fois, mais 10 (DIX) fois plus productif qu’un codeur lambda.

Je sais, c’est difficile d’être pleinement conscient de ceci, et quand on y pose les conséquences d’un point de vue pratique sur l’organisation d’un service informatique ou d’une SSII, on peut avoir de nombreux questionnements. Dites-vous juste que des managers de très haut niveau sont en train de prendre la mesure de cette réalité, et que plus vite vous le ferez également, plus votre avenir sera brillant. Ce n’est pas pour rien que Michael Bloomberg a déclaré que son but de l’année était de devenir développeur. Des articles comme http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics/ montrent également la valeur considérable d’un développeur.

Rassurez-vous, toutefois, chers managers : nous ne souhaitons ni votre place (nous n’y serions ni à l’aise ni épanouis), et nous sommes relativement peu exigeants en termes de salaire. Tout ce que nous souhaitons est de pouvoir continuer à apprendre tous les jours dans notre travail. Sachez d’ailleurs que si vous cherchez ce genre de développeur, il faudra les nourrir intellectuellement pour les garder…

Architecte logiciel

Dans une première partie de ma carrière, j’ai fait du développement à l’international, et l’évolution naturelle était de devenir responsable d’équipe. C’est ce que j’ai accepté de faire en devenir manager pour l’équipe France de mon employeur anglais. Le peu que je suis resté dans ce poste (j’ai très peu de temps après émigré en Bretagne pour y rejoindre ma femme – vous ai-je dit que je suis maintenant Breton?) m’a convaincu que c’était plutôt une perte de temps : je faisais moins de développement, et la résolution de conflits ou de problèmes de contrats n’avait que peu de saveur par rapport à la stimulation intellectuelle apportée par la résolution de problématiques techniques…

Je suis reparti de zéro chez mon second employeur, en redevenant simple analyste. Etant un passionné de .NET, j’ai naturellement pris progressivement une position de développeur référent, qui s’est officialisée à terme en “architecte logiciel”, et responsable du pôle Architecture / Formation / Innovation. Je lis ici, et j’ai déjà entendu dans d’autres cas, que ce terme peut être associé à de l’architecture lourde, avec une activité uniquement basée sur des diagrammes UML. Personnellement, je n’ai jamais cru à une trop grande symbolisation de l’architecture, l’activité de développement étant déjà à un haut niveau d’abstraction. Ma définition de ce poste et mon travail réel consistent plutôt à créer les conditions (API, docs, bonnes pratiques, formation, etc.) pour que les développeurs des équipes qui m’entourent puissent être le plus productifs possible. En plus de ceci, je me dois de refactoriser le code à un niveau global, en trouvant les veines dans lesquelles je peux enfoncer les coins qui sont pour moi l’inversion de dépendances, la modularité, l’injection ou encore les mocks / stubs. Bref, je reste proche du code, et il est hors de question pour moi de repartir sur un poste de management.

Je serai encore développeur quand je partirai à la retraite. D’ici là, je serai peut-être “architecte en chef”, ou “responsable R&D” Sourire. Je travaillerai peut-être encore plus avec l’université dans le cadre de thèses. Mais hors des titres et des coopérations, dans la réalité, je serai toujours un développeur.

Bien sûr, il faut préparer le futur. C’est principalement pour cela que je donne des cours, que j’écris des livres, et que je profite de mon statut de MVP pour rester au cœur du changement : le but est aussi de garder un profil exigeant. Mais honnêtement, tout ça est un tel temps investi que je ne le ferais pas par pur orientation de carrière !

Respect mutuel

Je termine avec le dernier principe énoncé par le mouvement “Fier d’être développeur”, à savoir le respect entre développeurs sur des plateformes différentes.

C’est également un facteur pour devenir un bon développeur : lire beaucoup de code d’autres personnes, et surtout regarder ce qui se fait dans les autres technologies. Pour bien comprendre pourquoi F# est arrivé dans .NET, il faut avoir jeté un œil du côté d’Haskell ou d’OCAML. Pour bien utiliser MEF, discuter avec un expert de Java / Spring fait gagner énormément de temps. Quand on ne comprend pas l’API de MSMQ, le mieux est encore de fureter sur les forums Apache ActiveMQ…

A ce propos, je recommande ce très bon article sur Le Touilleur Express. Je me sens totalement en phase avec ce développeur Java qui est venu aux Tech Days, ayant moi-même présenté une comparaison Java / .NET dans un évènement où l’énorme majorité des développeurs étaient des Javamen. Ca a évidemment chambré un peu des deux côtés, Nicolas De Loof pouvant difficilement laisser passer l’aspect propriétaire et les faiblesses d’injection de .NET, et moi-même ne pouvant pas m’empêcher de souligner le manque d’un équivalent à Linq, la surabondance de solutions équivalentes, le retard de Java 7, etc. Mais au final, j’ai beaucoup appris, rien qu’en préparant cette présentation, et encore plus en discutant avec les Javamen en question en fin de conférence et durant le reste de la journée du BreizhCamp (je vous avais dit que je suis désormais Breton ?)

Conclusion

Pas de conclusion. Si vous êtes arrivés au bout de ce post, vous avez déjà trop lu. Retournez coder !

image

Posted in Retours | 4 Comments

[TechDays2012] Conclusion

Voila, je suis dans le train, et c’est l’occasion de faire un bilan de ces TechDays. Avant, je me suis rapidement relu sur mon bilan de l’an passé (http://gouigoux.com/blog-fr/?p=117), histoire de lisser les mouvements d’humeur et de prendre un peu de recul. Malheureusement, je retrouve certains des points négatifs que j’avais déjà ressentis.

C’est l’effet démo…

S’il n’y avait qu’une expression pour résumer ces Tech Days, ça serait malheureusement “c’est l’effet démo”… Or, non, je ne suis pas d’accord, la plupart des cas étaient des erreurs qui auraient pu être prévues, ou dans lesquelles on voyait bien que la démo n’avait pas été bien préparée. Je sais d’expérience que des erreurs de connexion internet peuvent bloquer une démo, mais franchement, si je vais faire une démo d’une application sur mobile, il ne me viendrait pas à l’idée de dépendre de la 3G chez mon client : j’embarquerai le hotspot WiFi pour avoir une solution de secours.

Dans certains cas, des intervenants s’empressaient même d’accuser l’effet démo, alors que plusieurs personnes dans l’auditoire leur signalait une erreur grossière. Je comprends tout à fait que le trac lié au fait de démontrer une technologie dans un si grand évènement puisse faire réaliser des erreurs : c’est la vraie signification de l’effet démo. Mais il ne faut pas tout rejeter sur ça. Une session sur deux avec un “effet démo”, je n’y crois pas : il manque de la préparation, c’est clair…

L’inverse, c’est “magique”

Ca aussi, qu’est-ce qu’on l’a entendu… En gros, à chaque fois que ça ne plantait pas à cause de ce fameux “effet démo”, eh bien c’était “magique” ! Bon, il y a déjà l’aspect infantilisant pour l’audience qui est franchement désagréable (autant que l’accueil condescendant sur certains stands jusqu’à ce que l’interlocuteur se rende compte qu’on est MVP ou qu’on en connait finalement plus que lui). Mais surtout, ce que je trouve gênant dans ce vocabulaire est qu’il suppose que le fonctionnement de la technologie doit être caché par Microsoft. Ou bien parce que c’est tellement complexe qu’on ne pourrait pas comprendre, et qu’il vaut mieux qu’on croit que c’est la poudre de Perlin-Pinpin qui fait fonctionner le bouzin… Ou bien parce que c’est tellement simple qu’il ne vaut mieux pas nous expliquer le fonctionnement, ce qui serait gênant. J’ai tendance à pencher pour la seconde hypothèse, mais s’il vous plait, Messieurs les orateurs, ne nous prenez pas pour des idiots : on ne vous demande pas d’être révolutionnaire à chaque techno que vous inventez. Mais par contre, il faut nous expliquer comment ça fonctionne : c’est pour cela qu’on vient aux Tech Days, et nous avons la capacité, vous savez…

Orateur ou intervenant ?

Dans mes prises de notes rendues publiques sur ce blog, j’ai souvent utilisé de manière interchangeable les deux termes, mais j’aurais pu être plus strict et faire la différence entre les intervenants, qui présentent leur technologie sans faire attention à leur façon de parler, et les intervenants qui adaptent leur élocution au fait qu’ils ont un public avec une attente de clarté et de précision.

J’ai eu cette remarque en particulier sur l’élocution réellement pénible d’un intervenant, mais la remarque est d’ailleurs globale sur les Tech Days : certains orateurs sont à la limite de la vulgarité, et beaucoup ne font que peu d’efforts sur leur façon de parler. C’est certainement très bien pour “faire cool”, mais il ne faudrait pas oublier non plus que nous sommes entre professionnels. Détendu, OK, mais pas familier… Comme l’an passé, je regrette les capacités oratoires d’Eric Mittelette, Mitsuru Furuta, Bernard Ourghanlian. Presque tous les piliers de l’équipe d’évangélistes Microsoft sont très bons de ce point de vue. Ils seraient bon que ceux qui prétendent prendre la relève un jour en prennent de la graine et travaillent sérieusement leur élocution.

En même temps, je dis ça, mais je suis peut-être le seul à m’en soucier, de la même manière que j’ai l’impression de pinailler sur la grammaire française à chaque fois que je lis quelque chose de mal écrit.

Metro

Bon, fini de me plaindre, passons aux bonnes choses parce qu’il y en avait beaucoup à ces Tech Days. Et tout d’abord, chapeau à Microsoft pour l’approche globalisante entre Metro, HTML5, WPF 4.5 et Windows 8. Je me suis rendu compte au cours de ces sessions de l’approche très scientifique de Microsoft, qui a fait intervenir des ergonomes, des designers, des spécialistes de la cognition pour arriver à une nouvelle définition de l’interface visuelle basée sur les tuiles et des réactions rapides masquant des traitements asynchrones.

Je suis toujours dubitatif sur le fait qu’on va pouvoir faire du LOB avec du HTML5, mais bon, je comprends beaucoup mieux où Microsoft veut en venir avec ces technologies. En particulier, la mise en place de la Flexbox va permettre d’avoir une bonne convergence des applications web et natives, et c’est très bien. Surtout, ceci va se mettre en place de manière plus propre que par le passé, et le fait que Microsoft soit capable de changer de manière aussi radicale (plus de bouton démarrer, plus d’icones, etc.) est assez rassurant. S’ils arrivent à réussir Windows 8 et Windows Phone 8 et unifier l’expérience utilisateur, je pense qu’ils peuvent faire de l’ombre à Apple. D’ailleurs, même l’Apple-maniaque qui m’accompagnait (et qui s’obstine à utiliser son MacBook qui ne pose que des problèmes) convient que l’interface Metro est vraiment en avance sur iOS.

Bon, en même temps, c’est un peu logique, vu que Microsoft arrive trois ans après la bataille des mobiles. Mais personnellement, cette approche ne me gêne pas. Microsoft est arrivé 10 ans après Java, mais du coup, C# est vraiment un langage propre et fonctionnel, qui a su tirer parti de son arrivée tardive sur le marché. Pareil pour tout ce qui est internet et cloud, où Microsoft avait bien loupé le virage il y a dix ans. Amazon est toujours numéro 1, mais Azure est une très bonne plateforme, qui ne demande qu’à s’exprimer. Itou pour Windows Phone.

Au fur et à mesure que je tape, je me rends compte que ça fait beaucoup de technos qui sont très bonnes, mais toujours pas numéro 1 dans leur domaine. Je ne pense pas que ça soit un manque de marketing, et je suis convaincu que la valeur technique n’est pas en cause. Peut-être que Microsoft soufre encore de sa mauvaise image, alors qu’Apple a réussi à diffuser une image angélique sans aucun lien avec la réalité… Peut-être aussi qu’il faudrait encore plus aider les développeurs à réaliser la courroie de transmission ? Des programmes comme le support actif aux développeurs pour Windows Phone ou aux utilisateurs d’Azure vont assurément dans le bon sens. Et Microsoft a un excellent écosystème de partenaires, de certifications, etc. Il ne manque pas beaucoup de support pour une adoption beaucoup plus massive !

Microsoft et l’Open Source

Un autre point très appréciable dans l’approche de Microsoft (mais ça date déjà de bien avant ces Tech Days) est la prise en compte sérieuse de l’Open Source. Autant dans les premières années on pouvait douter, en se basant sur le passé, des bonnes intentions de Microsoft, autant maintenant les choses sont claires : Microsoft a reconnu que l’Open Source était une valeur, et qu’il n’y avait aucun intérêt à lutter frontalement contre.

Les récentes utilisations “officielles” de produit Open Source par Microsoft (JQuery dans Visual Studio et MVC, Hadoop dans Azure, etc.) ou leur apport à l’Open Source (CodePlex, OGDI, OData, Samba, etc.) montrent que Microsoft s’est réellement engagé dans une voie de la coopération. Bien sûr, ça s’est passé de manière forcée, mais au moins, Microsoft a l’honnêteté de ne pas se poser en “No Evil Company”, et leur engagement est effectif.

Sessions “fil rouge”

Un très bon point également pour les sessions “fil rouge”, à savoir pour ces Tech Days toutes les sessions sur la mise en place d’une application exemple sur la gestion d’une cave à vins, et qui partait de l’architecture pour montrer le code de persistance, les services, leur utilisation dans un mobile ou une application lourde. C’est une excellente idée d’avoir mis en place ce genre de sessions avec une progression, et qui au final font voir la totalité du processus de développement, mais aussi tout le code et les astuces à mettre en place pour arriver à un produit fini. Ca mériterait d’ailleurs d’être labellisé de manière un peu plus explicite sur le programme, car seul le titre ‘”de A à Z” permettait de relier les sessions. Ca vaudrait le coup de le poser en amont comme un “parcours recommandé”. Chapeau aux intervenants de ces sessions. Pour moi, c’était les plus complètes.

Liberté des déplacements

Un petit point qui n’a rien à voir avec la technique, mais qui est agréable : le caractère moins tendu des contrôles de badges. Les vigiles demandent plus sympatiquement de retourner les badges (si Microsoft n’imprime pas le code barre des deux côtés l’an prochain, je me fais une impression recto-verso), et on peut circuler plus librement. Bref, on respire mieux…

Conclusion sur le GreenIT

Malgré toutes ces bonnes notes, après les négatives, je finis quand même sur une touche de doute, voire de malaise. L’utilisation des approches de type Big Data et Azure sont très bien pour l’utilisateur, car elles permettent de moissonner des masses de données de manière très simple, ou de mettre en oeuvre des dizaines de machines de manière transparente.

Mais cela pose le problème des ressources. C’est un peu le problème en écologie : envoyer un mail, ce n’est rien ! On pousse juste un bouton, quelques machines traitent une donnée pendant quelques millisecondes, et c’est tout. Oui, mais il en circule des milliards par an, et à la fin, il y a quand même un impact environnemental fort. L’idée n’est pas de tout arrêter, mais d’être mieux conscient que, même si le coût est minime, il existe…

Et là, avez le Cloud et le Big Data, on risque de rendre des comportements potentiellement très consommateurs tellement transparents que l’utilisateur les appellera bientôt sans être conscient du coût environnemental. Si un analyste s’habitue à ce qu’un cluster Hadoop de 32 machines réponde en 15 minutes à des requêtes qui lui étaient inaccessibles auparavant, il va certainement demander de plus en plus de ces études. Quand une partie du traitement se faisait sur son PC, ou au moins sur des serveurs locaux aux ressources limitées, l’utilisateur se rendait un peu plus compte (ne serait-ce que par la lenteur) du coût de ses actions. Mais quand tout est déporté dans le Cloud, plus le nombre de ressources mobilisé est élevé, plus le retour est rapide, ce qui inverse cette perception ! Le risque, à terme, est que des actions simples consomment un nombre énorme de ressources. Or, comme le coût financier n’est à ce jour pas aligné sur le coût écologique, ceci se fera d’autant plus facilement que ce sera invisible. Je ne veux pas jouer les rabat-joie, mais à l’heure où on se pose la question de l’efficacité énergétique comparé de serveurs locaux ou de data centers, il faudra aussi se poser la question des comportements induits, qui peut peser lourd dans la balance. Autant, voire plus, que la qualité du code sous-jacent, qui est pourtant déjà énorme… mais méconnue.

Posted in Retours | 2 Comments