Julien Carnelos Blog – Archives

Avez vous remarqué cette tendance ?

Plus la quantité de travail augmente, moins on dispose de temps pour « blogger » 🙂

Je ne vais pas me plaindre de faire des choses intéressantes, alors en attendant je vous propose mon TOP3 des blogs que je consulte même lorsque je suis déconnecté comme en ce moment et que mon bloglines affiche un nombre affolant d’articles (+ de 800) en attente de lecture…

On commence avec un découvert récemment :

http://lifehacker.com/ avec son fabuleux slogan : « Don’t live to geek; geek to live.« . Ce blog présente des méthodes parfois originales mais toujours intéressantes pour organiser son temps et sa productivité .

Pour vous donner quelques exemples :

• Geek to Live: Eight killer Thunderbird extensions : Des extensions obligatoire pour rendre Thunderbird efficace !
• Lifehacker Code: Texter (Windows) : Un outil de remplacement de texte, tres utile pour rédiger les emails.
• Geek to Live: Empty your inbox with the Trusted Trio : Mon préféré du moment : Comment arriver à gérer le flux d’emails et à redonner de la sérenité à sa boite de réception…

Ceux qui me conaissent apprécieront la référence à mon cher « Zero Inbox ». Pour les autres, ne vous inquiétez pas , j’écrirai un article sur le sujet quand j’aurais suffisamment de recul.

Deuxième du top : http://www.codinghorror.com/

De loin, c’est un énième blog traitant du développement mais de près, l’auteur traite avec brio de sujets toujours passionnants.

Echantillon :

• Is Amazon’s Mechanical Turk a Failure?
• Recommended reading for developers
• Why Does Vista Use All My Memory?

Et puis quand je vois son bureau de travail, je ne peux qu’admirer sa config 3 écrans : :-O

Dernier blog : Technologies du langage

Ce blog n’est PAS un blog informatique. C’est suffisament important pour le souligner. L’auteur est professeur de linguistique et profite de ses conaissances informatiques pour décortiquer les discours politiques, analyser les mots et leur sens et nous faire découvrir toute la subtilité de la langue francaise. Son dernier article en date est caractéristique justement de son travail : 2007: Discours recyclés.

Si vous aussi, avez des sites dont vous ne pouvez pas vous passer, n’hésitez pas à partager !

Les projets de maintenance sur de l’existant ou le « legacy code » sont fréquents.

Le « legacy code » possède une définition simple : « C’est du code si vieux/mal fait qu’on a peur d’y toucher« . Malheureusement, il faut tout de même y toucher à un moment pour le maintenir ou ajouter des évolutions (et combattre le statu-quo!). C’est à ce moment là que quelques bonnes pratiques peuvent sauver le développeur de la démence…

Je vous recommande la lecture d’un excellent article de Jeremy Miller, Removing the « Legacy » from your Code qui décrit sa stratégie générale.

Les points essentiels que j’ai retenu et déjà appliqué :

1. Gérer ses ressources : Inutile de partir bille en tête dans une refonte totale du projet. Cela sera sûrement une perte de temps. On ne touche aux morceaux de l’appli que lorsque l’on veut ajouter une valeur métier. A ce moment là, il faudra en profiter pour améliorer le design de l’application.

2. Automatiser le build : C’est souvent un point critique sur les anciennes applications. Une procédure de compilation / déploiement en 15 étapes à la main est source d’erreur et de problèmes de configuration. C’est ici que les outils de build comme ANT/NANT (Maven, Rake,…) peuvent être utilisés à bon escient.

3.  Avoir une vision globale de où l’on souhaite aller : On peut mettre en place au sein de l’équipe une vision du projet à long terme. Par exemple, se fixer comme objectif de remplacer l’ancienne couche DAO par le framework ORM Hibernate/NHibernate. Un wiki collaboratif interne conviendra très bien à ce genre d’informations.

4. Visible du management : Dans l’idéal, il faut que l’idée de cette amélioration du projet par à coups et en douceur soit acceptée par la direction. Avec son support, les modifications majeures seront plus faciles à porter. Par expérience, malheureusement ça sera rarement le cas. Dans ce cas il suffit d’adopter la technique du sous-marin : J’intègre dans mon chiffrage le temps d’effectuer les mises à jour techniques nécessaires. Attention, cette technique doit avoir l’aval de l’équipe technique sous peine de se retrouver isolé…

5. Interdiction d’abîmer le code : Le code source du projet est déjà suffisament ancien, toute modification de celui-ci doit respecter la qualité attendue. Aucune verrue supplémentaire ne doit être tolérée.

Un phénomène fréquent que l’on peut rencontrer en maintenance de projet est ce que j’appelle le statu quo.

Imaginons un applicatif en production depuis quelque temps. Cette application complexe réalise entre autre une insertion en base de données d’éléments dans l’ordre croissant. Malheureusement, il arrive de temps en temps (environ 1 fois par semaine) qu’une insertion échoue en insérant un numéro incorrect. Le moteur s’arrête donc et l’applicationest bloquée.

Le statu quo, c’est intervenir sur la base de données pour effacer la ligne erronée et laisser le programme repartir tout seul… C’est la solution facile. On voit que le programme stoppé, hop, je vais sur la base de prod et je supprime la ligne incriminée.

Mais il existe une autre solution à ce problème : corriger le bug. Evidemment c’est une solution qui sera plus longue à mettre en oeuvre car cela implique de se creuser la tête. Logiquement, je passerai plus de temps à corriger ce bug difficile qu’à me connecter sur la base une fois par semaine.

Pourtant la règle est simple : moins de bug en production = moins d’exploitation = moins de stress ! Donc corrigez sans merci les bugs qui traînent, même ceux qui n’apparaissent que de temps en temps.

Combattre le statu quo est une activité difficile. Il faut lutter contre sa propre envie de céder à la facilité. En revanche, le jeu en vaudra toujours la chandelle sur le long terme !

Pour faire suite à mon premier article qui servait d’introduction, je souhaitais revenir sur la notion de centralisation du serveur d’authentification.
OpenId étant un protocole ouvert, quiconque peut implémenter le mécanisme serveur d’authentification sur son domaine. J’avais cité en exemple verisignmais il en existe beaucoup d’autres comme http://getopenid.com/.

Cette dépendance envers un serveur est forte et imaginons qu’un jour, un provider comme getopenid décide de faire payer son accès, nous nous retrouvons lié sans autre choix que d’accepter ou perdre son accès.

Et bien la solution à ce problème s’appele la délégation.

Si vous avez bien suivi, pour le moment notre identité openid est une url. Par exemple pour mon id verisign, c’est juliencarnelos.pip.verisignlabs.com.

Cette url n’est pas seulement une clé unique comme peut l’être un identifiant nom ou un email, car elle permet également de certifier la validité de l’id.
Ainsi, si je m’authentifie chez Ebay (en théorie, car Ebay ne fait pas encore d’openid 😉 ), Ebay va interroger le nom de domaine « verisignlabs.com » pour avoir les infos me concernant.

Nous en arrivons donc au principe de délégation. Mon ID étant une URL accessible, je vais pouvoir utiliser n’importe quelle url qui contiendra une délégation vers un vrai provider d’openid.

Concrètement, grâce à mon nouveau nom de domaine, je vais pouvoir utiliser comme Open ID «  ». Il me suffira de modifier le fichier index.php et de rajouter à l’intérieur du head les 2 lignes de délégation :

   <link rel="openid.server" href="http://pip.verisignlabs.com/server" />
   <link rel="openid.delegate" href="http://juliencarnelos.pip.verisignlabs.com" />

De ce fait la dépendance sera uniquement vers mon domaine (qui m’appartient). Ainsi je peux changer de fournisseur quand je le décide en changeant simplement ces deux lignes…

Ce blog passe désormais sous son propre nom de domaine .

J’en ai profité pour carrément changer de plateforme de blog. Exit dotclear et bienvenue à WordPress.
Plusieurs raisons m’ont poussé à ce choix. Les principales sont la vieillesse relative de Dotclear 1 et la tonne de plugins disponibles pour WordPress.

Je remercie mon nouvel hébergeur pour son support et sa dispo sous la contrainte 🙂

J’ai essayé de rendre le changement le plus transparent possible.
Pour cela, les lecteurs RSS ne devraient voir aucun changement grâce à la magie Feedburner.
Et concernant mes hits sur le site de Free, j’ai appliqué des redirect permanents de masse afin de rediriger le google juice vers le nouveau nom de domaine…

Pour finir sur une belle note, ce post est le 100ème. Vous me direz que c’est peu, mais c’est 100 posts de qualité 😉 !

Il est un temps où on est passionné. Où l’on teste chaque nouvelle version béta et où l’on essaye toutes les nouvelles technologies qui sortent.

Aujourd’hui je suis toujours un passionné mais je n’ai plus le temps  de « tout » tester.

Pourtant, la veille technique fait partie de mon travail et je met un point d’honneur à garder un oeil sur l’évolution du monde informatique. 

Ma technique consiste donc à suivre l’actu très régulièrement. Cela passe maintenant quasiment à 100% par les blogs. J’essaye d’avoir pour chaque technologie que je veux suivre, un ou plusieurs sites/blogs qui récapitulent les news.

Par exemple :

• JAVA/J2EE : Erik’s Linkblog
• .NET : Larkware News
• Web 2.0 : OriginalSignal.fr / TechCrunch

Cela me permet d’avoir un aperçu global, il faut alors juste faire travailler sa mémoire…

Pour chaque technologie majeure, comme le framework .NET 3.0, j’essaye de me documenter le minimum requis.

L’idée est d’arriver à raccrocher les nouveautés à ce que je connais déjà. De cette façon, je juge de l’intérêt ou non de cette technologie. Cela me permettra d’en parler ou même d’exprimer un avis général.

Quand à approfondir ou tester un bout de code, je ne le ferais qu’à partir du moment où je voudrais valider la pertinence du choix technologique. Par exemple, en amont d’un développement .NET, « le fait-on en .NET 2.5 et en .NET 2.0 » ?

Je fais vraiment la séparation entre modèle et détail d’implémentation. Et donc autant il est très important pour moi de comprendre tous les nouveaux « modèles » techniques, l’implémentation importe finalement peu…

Voilà c’est fait, Struts 2 vient de sortir en version finale.

Il s’agit plus exactement de la version 2.0.6 qui est estampillée Generally Available (GA) ce qui signifie validée pour l’environnement de production.

C’est donc une tâche en plus que vous pouvez ajouter dans votre veille technologique de début d’année (après avoir fait vos devoirs sur OpenID évidemment 😉 )

Un des premiers agacements que rencontre l’internaute est le fait d’avoir une paire identifiant/mot de passe pour chacun des sites qu’il visite.

C’est vite lourd et jusqu’à peu, il n’existait pas de solution intéressante à ce problème.

En théorie, cette problématique se nomme le SSO (Single Sign-On). Le SSO consiste à centraliser toutes les informations d’identification en un point unique. Les programmes, comme un Intranet par exemple, peuvent ensuite demander au serveur SSO d’authentifier la personne se connectant.

Les SSO sont aujourd’hui répandus dans les entreprises car c’est un plus pour les utilisateurs et surtout un gros plus pour l’opérationnel qui évitent les incidents « j’ai oublié mon mot de passe« …

Mais ce qui est applicable dans le contexte urbanisé d’une entreprise n’est pas forcément possible pour Internet. En effet, le point crucial d’un SSO est qu’il repose à un moment ou à un autre sur un serveur centralisant l’information de sécurité.

Il y a quelques années, aux alentours de la sortie de .NET, Microsoft a sorti sa technologie Passport .NET. Son idée était simple : proposer un système d’authentification centralisé vendu aux partenaires. L’echec fût retentissant. En effet, qui voudrait investir dans une technologie propriétaire dont toutes les informations stratégiques (comptes) seraient stockées sur les serveurs Microsoft ?

Résultat, les sites implémentant Passport se comptent sur les doigts de la main sauf Microsoft.com qui utilise à plein régime son système évidemment. (Si le sujet vous intéresse, vous pouvez lire Authentification Passport .NET en ASP .NET écrit il y a de nombreuses années 😉 )

Le besoin à combler étant toujours présent, des alternatives se sont développés et il semble aujourd’hui que le gagnant soit OpenID.

Qu’est-ce que OpenID

OpenID est donc la même chose, c’est à dire un système centralisé d’authentification. L’avantage de OpenID est que ses spécifications sont ouvertes et donc accessibles à tous. De fait, il est parfaitement possible pour quiconque de développer son serveur OpenID, et l’on retrouve déjà de nombreux services nous permettant de créer notre identifiant OpenID. Par exemple, Verisign propose ce service.

Un identifiant OpenID est alors simplement une URI, voici la mienne générée par Verisign : JulienCarnelos.pip.verisignlabs.com.

Sur notre profil OpenID, on peut renseigner les éléments que l’on veut et on est libre de choisir quels seront les éléments partagés.

Le plus intéressant est que l’on peut se créer des profils « virtuels ». Par exemple, quand j’utilise mon OpenID sur les sites de e-commerce je partagerai ma véritable identité et mon adresse postale alors que quand je poste un commentaire sur un blog, mon surnom, mon email et l’url de mon blog suffit amplement…

Utilisation de OpenID

Je vais aller visiter un site lambda acceptant l’authentification OpenID : http://www.openidenabled.com/

Pour me connecter, je vois dans le cadre à gauche « OpenId », je saisis alors mon identifiant et je valide.

Je suis alors automatiquement redirigé vers Verisign qui me demande si je valide bien mon adhésion et quel profil je souhaite partager.

Après acceptation, je reviens sur le site original authentifié. Et voilà, la magie s’est operée !

Le futur

Ce qu’il y a de formidable pour OpenID, c’est que, bien qu’il ne soit pas unique (il existe de nombreux concurrents Yadis, LID, etc. ), il bénéficie d’un momentum important qui risque de le déclarer gagnant.

Plusieurs éléments peuvent nous laisser penser ça :

• Firefox 3 implémentera en natif la gestion des OpenID => il sera alors encore plus simple de se logger
• Microsoft et AOL ont annoncé le support de OpenID
• DIGG, Wikipedia et Yahoo vont implémenter OpenID

On voit bien que cette lame de fond risque de se transformer en tsunami, alors soyez les premiers et investissez dès aujourd’hui le terrain !

Quelques ressources pour attaquer le sujet :

• http://fr.wikipedia.org/wiki/OpenID
• http://openid.net/
• http://www.openidenabled.com

Je sais maintenant ce qu’il me reste à faire sur ce blog 😉

Une des grandes incompréhensions de l’informaticien est son caractère distant.

Grossièrement, le travail d’un développeur consiste à traduire des pensées en lignes de code.
il s’agit d’une activité de forte réflexion dont l’objectif est la transformation d’idées sous la forme d’un langage informatique.
Ce travail est difficile car il nécessite une concentration importante.

C’est cette concentration qui rendra le cerveau efficace sur sa tâche en donnant les moyens aux idées d’aller le plus vite possible sur le clavier. En un mot la productivité !

Une mesure courante est de considérer qu’il faut environ un quart d’heure pour atteindre cet état.
Une fois atteint, la concentration peut durer largement plus d’une heure.

Maintenant plaçons-nous dans une demi journée imaginaire (pas tant que ça) :

* 9H00 : Je commence le codage
* 9H15 : J’atteins mon plateau de productivité
* 9H20 : Le téléphone sonne, je suis coupé
* 9H30 : je reprend le codage avec la concentration à zéro
* 9H45 : plateau de productivité
* 10H00 : Quelqu’un vient me poser une question, je suis coupé
* 10H05 : je reprend le codage avec la concentration à zéro
* etc.

Résultat : 5 + 15 => 25 minutes d’efficacité totale.

La conclusion est claire, il suffit de seulement quelques événements dans la matinée pour casser la productivité.
Malheureusement cette attitude est courante et je suis le premier à ne pas me rendre compte quand je dérange les gens.

Quelles solutions peut-on trouver ?

• Plutôt que de systématiser le coup de téléphone, écrire un email dérange moins
• Certaines équipes utilisent un signe pour montrer qu’une personne ne souhaite pas être dérangée.
  Par exemple, un petit drapeau posé sur l’écran ou un signe posé sur la porte
• Eviter le zones de bruit, par exemple réunion improvisée de 2 personnes qui dérange tout le bureau.

Toutes ces idées ne sont que du bon sens et du savoir-vivre, donc à vous de jouer 😉

Pour référence, 3 posts utiles :

• Unified .NET Framework Troubleshooting Guide
• Visual Studio 2005 and .NET Framework 2.0 Setup Troubleshooting Guide
• Automated cleanup tool to remove the .NET Framework 2.0

A garder bien au chaud, c’est vraiment utile ! 😉