Julien Carnelos Blog – Archives

 Ce post traine depuis trop longtemps dans mes brouillons, alors je publie avant qu’il ne soit complètement périmé…

Silverlight a été récemment annoncé par Microsoft au MIX07.

C’est une annonce intéressante car le produit est annoncé comme un Flash-Killer. Il faut oser aller sur ce marché où l’on considère aujourd’hui que le lecteur Flash d’Adobe est installé sur 95% des postes, ce qui représente une part de marché assez conséquente.

Silverlight est donc le nom officiel d’un produit en gestation depuis quelques temps. Son nom de code était « WPF-E ». Il empruntait son nom à la technologie WPF qui permet de réaliser des interfaces graphiques vectorielles puissantes en .NET 3.0. Un truc sympa et classique en WPF est qu’une vidéo est considérée comme une texture. On peut donc associer notre vidéo à un bouton ou la coller sur un cube en 3D assez simplement. Le WPF utilise également une sémantique de balises pour décrire l’interface. Il s’agit simplement d’un fichier XML et le langage du XAML.

Microsoft a donc repris les bonnes idées de son WPF (le XAML, la simplicité d’utilisation,…) et en a réalisé une version « Everywhere ». La version WPF faisant partie du framework .NET 3.0, elle est limitée à l’environnement Window…

Silverlight est donc une runtime qui s’installe sur le poste client qui est aujourd’hui disponible pour Windows et pour Mac (une version Linux sera proposé, implémentée en Mono).

Ce qui est amusant avec cette annonce est de voir à quelle point le mouvement est cyclique dans les inventions informatiques. En effet, depuis un bon moment maintenant on voulait alléger le client au maximum et utiliser le navigateur comme interface universelle. Les applets Java sont déclarés mortes et le succès des technologies AJAX ne sont pas là pour démentir.

Aujourd’hui, il parait aberrant de proposer à un client une solution où il faudrait installer une runtime sur le poste de l’utilisateur et pourtant c’est exactement ce que Microsoft nous propose.

Alors quelle est la pérennité d’une telle offre ?

A l’heure actuellle, Silverlight n’est pas prêt de remplacer toute le savoir que l’on commence à maîtriser sur les technos AJAX. Là où Silverlight peut séduire c’est par sa simplicité : pour une partie d’un projet ASP.NET où le besoin ergonomique est fort, on implémente une partie sous la forme d’un projet .NET Silverlight. Résultat, on ne change pas de technologie et on se retrouve avec une interface jolie. Si beaucoup de projets ouvrent cette voie, le cercle vertueux de l’adoption pourra démarrer. Car avec 10 ans de différences, j’espère que Microsoft aura prévu de contrer les arguments qui ont fait l' »échec » des applets Java.

Et oui, cela fait 5 mois que j’ai installé Windows Vista Edition Professionnelle et Office 2007.

Je me sers quotidiennement de ces outils. Les commentaires suivants sont donc l’expression de mon ressenti journalier…

Avant-propos : Tester les nouveaux produits fait partie intégrante de mon métier et de ma veille technologique, j’ai donc parfaitement conscience d’essuyer les plâtres quelquefois… Cette note a été écrite à destination des personnes qui ne veulent justement pas prendre de risques.

Windows Vista

J’avais décidé de migrer mon poste sous Vista car je voyais à l’époque trop de personnes s’extasier des nouveautés. J’avais moi aussi envie de participer à cette aventure ! J’avais évidemment pris mes précautions en réalisant un backup complet de la machine au cas où (Heureusement ce backup n’est jamais ressorti de son tiroir).

La première approche n’a pas été évidente avec une installation par mise à jour de l’OS qui a pris plus de 3H !

D’ailleurs, je pense avec le recul que 3/4 de mes problèmes de plantage sous Vista sont dûs au choix d’une mise à jour et non d’une installation « from scratch« .

Au jour le jour, l’interface de Vista est très agréable et on s’habitue vite aux petites améliorations ergonomiques et outils ajoutés sur l’interface.

Par exemple quand je me retrouve sous XP, je cherche instinctivement la fonction de tri rapide en haut à droite de l’explorateur. Cela montre que toutes ces améliorations qui peuvent passer pour frivoles sont un plus pour l’utilisation.

Le passage à une nouvelle version d’un système d’exploitation a également des implications sur les logiciels installés : un outil qui fonctionnait sous XP se doit (à un patch près) de fonctionner sous Vista. Sur ce sujet là, vous connaissez mon ressenti et il est loin d’être idyllique.

En effet, même si depuis la publication de mon billet, tous les patchs « finaux » pour Visual Studio sont sortis, certains développeurs se plaignent encore d’incompatibilité.

Pour moi, le dernier exemple en date est l’impossibilité d’installer correctement Sql Server 2005 Reporting Services sur mon poste. Après avoir cherché pendant plus de 3 heures, j’ai préféré abandonner et revenir sur un poste XP pour faire fonctionner le service (impresionnant non !)

Parlons maintenant d’Office 2007

Sur ce produit, je n’aurais qu’un commentaire : « excellent« . Quand on passe la journée sur un document Word / Excel ou Powerpoint, on découvre toutes les petites améliorations apportés sur l’interface qui en font un produit plus facile à utiliser et plus rapide en terme de productivité.

On sent qu’un gros effort ergonomique a été effectué sur le produit et c’est une satisfaction quotidienne à l’utilisation.

Je vous ai réalisé une petite vidéo flash pour vous montrer un « gadget » que j’aime bien : La réalisation interactive de diagrammes (graphique SmartArt dans le texte).

Conclusion : Pour une utilisation dans l’entreprise, mon conseil est de rester sous XP SP2 en attendant que les tous les drivers intéressants soient adaptés, que les logiciels soient mises à jour et que le matériel ne fonctionnant plus disparaisse…

Preuve en est, Dell qui propose à nouveau d’installer XP sur ses machines.

Pour Office 2007, foncez quand vous pouvez ! 🙂
(A ce propos, je serais friand d’une comparaison OpenOffice / Office 2007 pour voir ce qu’il en est.)

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…

Je ne m’étais pas rendu compte à quel point les standards services web étaient devenu un si grand « monstre ».

Quand on voit que ces standards recouvrent une centaine de spécifications, on prend l’ampleur des dégats.

L’approche SOA est une avancée de l’industrie informatique. Je crois aux vertues d’une architecture pensée en termes de services plutôt qu’une architecture urbanisée figée. Néanmoins, j’ai l’impression que les éditeurs ont sauté sur l’occasion pour nous imposer un modèle qui les arrange.

Là où les DSI ont pris peur en voyant leur système d’informations aux mains d’un seul éditeur, SOA a permis un discours d’un genre nouveau :

Ne vous inquiétez pas, notre offre repose sur des services ouverts, vous êtes libre de changer de fournisseur

Le seul hic c’est la définition de ces services ouverts. Tant que cette ouverture était décrite dans une spécification implémentable sans trop de problèmes, tout allait bien et chaque éditeur pouvait proposer son produit ouvert aux autres.

Mais comme tout acteur majeur il chercher à tirer profit et augmenter sa part de marché. Comme les spécifications sont ouvertes, sa seule solution c’est d’être le premier à proposer une implémentation de la dernière norme (un peu comme J2EE dans une moindre mesure).

C’est exactement ce qui est en train de se passer. Chaque éditeur pousse les spécifications v1, v2, etc des composant dont il est responsable.  Il est évident alors qu’il devient difficile de suivre. On se retrouve donc dans une situation où chaque éditeur propose une implémentation partielle qui est différente de son voisin.

Le résultat de cette divergence vient à l’encontre des principes fondateurs de la démarche SOA.

Pour ceux qui ne saisissent pas l’analogie, on prononce WS-* en WS-star ou WS-étoile en français.

P.S.

Vous pouvez vous faire plaisir en imprimant l’image PDF et la placarder au mur. Attention à la syncope des néophytes qui rentreraient dans votre bureau 😉

Si comme moi vous recherchez régulièrement la signification ou un exemple d’utilisation d’une balise xhtml, ce site est fait pour vous : http://htmlplayground.com/

Un peu comme une javadoc, il présente pour chaque tag :

• la définition
• un exemple d’utilisation
• le code de l’exemple
• l’ensemble des modificateurs CSS applicables avec vision en temps réél de la modification

C’est pas mal du tout. A tester !

Les méthodes agiles ne sont pas récentes mais il reste difficile d’expliquer clairement et simplement ses concepts clé.

Scrum est aujourd’hui une méthodologie agile qui a le vent en poupe, alors comment expliquer son fonctionnement ?

Cette définition, vue sur le blog de Claude Aubry – Scrum – Méthodes agiles y répond exactement :

Scrum est un processus agile qui nous conduit à produire la plus grande valeur métier dans la durée la plus courte.

Scrum nous permet d’inspecter rapidement et régulièrement (toutes les 2 à 4 semaines) un produit (partiel) qui fonctionne.

Le métier identifie les exigences et définit leur priorité. Notre équipe s’organise elle-même pour déterminer la meilleure façon de produire les exigences les plus prioritaires.

Toutes les 2 à 4 semaines, tout le monde peut voir fonctionner le produit actuel et contribuer à prendre une décision : soit le livrer dans l’état, soit continuer à l’améliorer pendant 2 à 4 semaines supplémentaires avant de se reposer la question.

Après avoir répondu à la question .NET ou Java dans mon précédent post. Je reviens à la charge avec une autre question que l’on se pose beaucoup moins souvent.

Quelle est la plus grande différence entre le .NET et Java ?

Réponse : La culture.

Cette fois-ci, la réponse existe, elle est simple et concise. Merci d’avoir lu ce billet. Au revoir.

Vous en voulez plus ? OK.

La culture Java est largement plus complexe que celle que l’on retrouve en .NET. Pour démontrer ceci, je vais plutôt repartir à l’envers en énonçant qu’il est plus simple de partir avec du .NET. Prenons un exemple, imaginons que je doive ajouter une couche d’accès au données à mon application.

La majorité (75% ?) des développeurs .NET auront le réflexe suivant :

1. Je regarde l’aide locale sous Visual Studio en tapant des mots clés de recherche.
2. Un résultat sera trouvé à coup sûr avec un exemple de code.
3. Là, à nouveau la majorité s’arrête et commence à développer avec ce qu’il lit
4. Le reste va effectuer quelques recherches sur la MSDN pour obtenir des infos supplémentaires.
5. Avec tout ça, on attaque le dev.

Le pattern est simple : Ce que Microsoft dit, le développeur fait. Et MSDN est notre bible.

Malheureusement, cette culture coupe de nombreux développeurs de tout ce qui fait la richesse et la force du Java depuis des années. Par exemple, de nombreuses personnes ont découvert qu’avec Visual Studio Team System, un IDE pouvait nous aider à collaborer sur un référentiel projet contenant tests, docs, TU, etc…

Si l’on reprend ma petite liste du dessus, comment un développeur Java ferait ?

1. google.com : « data access java » ou « couche access donnees java »
2. pléthore de liens, de solutions d’articles techniques, de blogs…
3. Très vite, le développeur constatera que les meilleurs articles parleront ORM / Gestion des Transactions / Indépendance de la base
4. Puis il en viendra à se renseigner sur Hibernate / Spring 2 / etc… (Noms au hasard)

Clairement, la 2ème solution sera mieux architecturée et produira un logiciel mieux conçu (si le développeur n’est pas manchot 😉 )

Attention, je ne dis pas ici qu’un développeur Java est plus intelligent qu’un développeur .NET et je ne dis pas non plus que Java est mieux.

J’explique seulement que la différence entre le Java et le .NET est causé par la culture différente des deux ecosystèmes. Dans un cas on fait confiance à une seule autorité. Si Microsoft n’a jamais parlé des Mock Objects Dans son aide ou dans MSDN, les développeurs .NET ne sauront pas de quoi il s’agit… Pour les développeurs Java, il est évident qu’il n’existe pas une source fiable mais de nombreuses à lire et à comparer sur le web.

L’esprit critique est nécessaire quand on développe en Java et c’est une chose que devrait apprendre la communauté .NET.

Désolé pour ces deux semaines d’absence, je manque cruellement de temps ces derniers jours…

Très souvent lors des formations que j’anime vient la question fatale :

Alors c’est lequel le mieux, Java ou .NET ?

Sur mes quelques années d’expérience dans ces deux langages j’ai appris à formuler une réponse à laquelle je crois : ça depend.

Dis comme cela, on pourrait croire que j’évite la question mais au contraire l’expérience m’a montré que le choix d’une technologie ne doit jamais se faire à la simple comparaison d’un tableau de fonctionnalités.

Par exemple en Java, on peut utiliser des paramètres variables avec « … » alors qu’on ne peut pas en C#. Donc Java est mieux !

Ah mais en .NET, on dispose du système puissant des « delegates ».

Donc c’est .NET le mieux ? Il faut voir également que pour les frameworks d’accès aux bases de données, on retrouve en Java un excellent connecteur JDBC indépendant de la base alors qu’en .NET, ADO.NET 2 n’est pas encore au niveau…

Bref, sans rentrer dans les considérations techniques, on voit bien que cette comparaison est sans fin mais qu’elle est surtout inutile.

Car, par exemple, qui s’intéresse à une comparaison avancée sur la mobilité entre le compact .NET et J2ME si l’on développe une application client lourd windows ?

Ainsi, j’ai pris l’habitude de répondre à la question « .NET ou Java » en retournant la question. Pour cela, j’ai généralement une petite liste de questions qui sont autant d’indications qui me permettront de conseiller au mieux un choix technologique.

Exemple de liste des questions :

• Quelle est l’expérience de vos développeurs ?
• Quel est l’existant matériel/logiciel ?
• Quelles sont les directives de la DSI ?
• Quelles sont les types de projets ?

En cernant au mieux le profil de l’équipe, la réponse apparaitra d’elle-même.

Voici ma vision rationnelle du choix d’une technologie. Quand à imposer un langage auprès d’une équipe, le travail n’est jamais gagné car après tout, le développement est une religion 😉