Julien Carnelos Blog – Archives

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…