Julien Carnelos Blog – Archives

Il est étonnant et même navrant de voir à quel point le CEO de 6th sense a pu se méprendre dans l’intérêt que prend aujourd’hui les softwares factories.

the software factory is as outdated as Henry Ford’s Model T assembly line … crush the flexibility and creativity needed to build software and meet constantly changing requirements.

L’usine logicielle est aussi périmé que le fordisme…. elle abolit la flexibilité et la créativité nécéssaire au développement et au changement permanent

developers get plugged into an assembly line and are treated like battery chickens expected to squeeze our code.

Là c’est trop gros, je ne traduis même plus :-).

On peut constater que l’auteur n’a vraiment rien compris au principe de l’usine logicielle.

Pour rétablir un peu de vérité, l’intérêt de mettre en place une software factory c’est justement de libérer le développeur de certains tâches répétitives et contraignantes et donc de lui laisser plus de temps à la réflexion et à la créativité sur ses solutions.

On a vraiment l’impression que l’auteur s’est contenté de traduire littéralement le terme software factory et a pris peur tout seul 😉 .

vu sur serverside.

Dans le livre Peopleware, le chapitre « Making change possible » parle de la difficulté à faire changer les choses dans un projet (aspect aussi bien technique que méthdologique).

J’ai à plusieurs reprises travaillé avec des équipes ayant un niveau de technicité différent.Par exemple, des équipes travaillant sans un gestionnaire de sources.

Ma première réaction est l’étonnement :

Mais comment pouvez vous travailler avec des conditions pareilles ?

(Si l’on y réfléchit, on peut très bien travailler sans gestionnaire de conf, il suffit de faire plus attention c’est tout 😉 ).

Passé cette réaction, la prochaine étape est de montrer à l’équipe l’intérêt de cet outil et leur faire intégrer dans leur process de développement.

Pour cela, j’avais tendance à donner l’ensemble des avantages, dire que tout sera plus beau et bien mieux. Ce qu’on peut représenter par le schéma suivant :

 ANCIENNE FACON ==> NOUVELLE FACON

Et bien, cette technique en pratique donne de mauvais résultats (incroyable c’est le sujet de ce post)…

Par exemple, la mise en place des projets sur le gestionnaire est difficile au début, des nouveaux mots sont à maitriser pour comprendre. La syntaxe n’est pas évidente non plus et les erreurs sont fréquentes. Résultat, on passe beaucoup plus de temps à gérer ses sources, temps qui était disponible auparavant pour d’autre chose…

Au final, la réalité s’approche plutôt du schéma suivant :

 ANCIENNE FACON ==> CHAOS ==> APPRENTISSAGE ==> NOUVELLE FACON

Le passage obligé mais souvent oublié c’est l’étape chaotique où les développeurs râlent car cette nouvelle complexité ne leur apporte aucun avantage. Ils ne voient que les défauts et aucun intérêt… Cette étape difficile est souvent le moment où se repose la question cruciale :

Est-ce que vraiment ca valait le coup, parce qu’on peut encore revenir en arrière sinon !

Finalement avec un peu de volonté et de la pratique, tout le monde finit par piger le truc et cette nouvelle façon de travailler plaît !

La leçon à retenir c’est que lors d’un changement, il faut être très clair sur plusieurs points :

• Oui ça sera mieux (on y croit)

MAIS

• Il y aura une période incertaine et plus difficile dont il ne faut pas avoir peur
• Il faut accepter de sortir de notre sécurité actuelle pour tenter de nouvelles choses
• Le changement ne doit pas être un couteau sous la gorge et il faut avoir le droit à l’erreur

Je travaille avec beaucoup de développeurs qui ont commencé sur la version 1.0 ou 1.1 du framework ASP.NET.

La version 2.0 étant rétro-compatible, il n’est pas forcément évident de saisir les subtiles différences qui existent.

J’ai trouvé récemment un guide sur le site des développeurs ASP.NET qui présente justement ASP.NET 2.0 pour les développeurs qui ont connu la première version.

Je vous incite donc à le lire si vous êtes passés en .NET 2.0 !

• ASP.NET 2.0 Internals (article en anglais)

remarque : c’est encore une nouvelle catégorie : dotnet 🙂 .

Après la version Virtual Serveur, déjà offerte depuis un petit moment, la version « normale » devient gratuite à son tour.

La virtualisation devient plus que jamais une commodité et l’on peut constater que tous les acteurs ont maintenant leur version gratuite (Microsoft, VMWare…)

Pour Microsoft, c’est une stratégie intéressante qui leur permettra de vendre des licences serveur sur lesquels seront installé les machines virtuelles. Puisque évidemment, Virtual PC et Virtual Server ne fonctionnent tous deux que sur un OS Windows.

De plus, si l’OS hôte est un Windows, cela pourra encourager les administrateurs système à installer également des windows dans les machines virtuelles. Conclusion, je pense qu’ils ont refléchi à deux fois avant d’offrir gratuitement cet outil 🙂

En dehors de cet aspect serveur, il est plus que jamais interessant pour les développeurs d’avoir également des machines virtuelles afin de tester différents environnements. Par exemple, un environnement dotNET, un Java, un Ruby 😉 … ou pour tester différents OS/navigateurs web…

Lien pour télécharger Virtual PC 2004.

Eclipse Callisto est une initiative de la fondation Eclipse visant à sortir simultanément 10 projets le 30 juin. L’intérêt est de montrer aux DSI qu’Eclipse est un produit prévisible puisqu’il est prévu d’avoir des sorties régulières (1 par an).

Cela augmente la confiance dans la pérénnité du projet. Effectivement, c’est une chose qui manque souvent sur les projets OpenSource…

Liste des projets :

   *  Business Intelligence and Reporting Tools (BIRT) Project    * C/C++ IDE    * Data Tools Platform    *    * GEF - Graphical Editor Framework (3 inclus)    *    * Eclipse Project    * Eclipse Test and Performance Tools Platform Project    * Eclipse Web Tools Platform Project    * VE - Visual Editor

La page du projet montrait un compteur qui en était à moins d’1H au moment de ce post mais il a disparu et se retrouve remplacé par un laconique « Coming Soon ».

J’espère juste qu’ils ne vont pas se louper la date de sortie. Quand on voit l’emballement qui suit cette sortie simultanée Eclipse « Callisto » an Agile Success Story (vu sur infoQ.com), il serait dommage de voir retomber le soufflé 😉 .

Aujourd’hui à 10h sort le nouveau portail de cartographie d’IGN. Celui-ci est normalement accessible sur www.geoportail.fr. La particularité de ce site par rapport aux concurrents (google maps, mappy, … ) est d’afficher des images satellite d’une grande précision ainsi qu’une vue 3D.

 Je dis bien normalement, car l’ouverture d’un site avec une grande notoriété provoque quasi systématiquement des bouchons à l’entrée 😉 Si j’avais eu juste un conseil à donner, c’était de prévoir une simple page statique HTML en frontal avec un message « Désolé, notre site est trop bien et donc surchargé, merci de votre patience 😉 »

Update : vu sur developpez.com/blog, il existe un message mais je n’y accède même pas…

Cette fois-ci pas d’équipe francaise en jeu mais un super article écrit sur sitepoint.com.

L’auteur compare les 4 frameworks Javascript/AJAX suivants :

• Dojo
• Prototype
• Mochikit
• Yahoo UI Library

Je vous incite donc à aller lire l’article pour découvrir le gagnant 😉

Pour casser le suspense, évidemment, il n’y a pas UN gagnant mais un outil pour un besoin… Dans tous les cas, je partage l’avis de l’auteur concernant l’affectation de ces libraries :

• Prototype pour les petits projets et pour les developpements en Rails (déjà intégré)
• Yahoo UI pour une application ou l’on veut ajouter un widget AJAX
• Dojo la grosse bibliothèque bien complète avec un temps d’apprentissage important. A réserver aux projets importants.

Concernant Mochikit, l’auteur nous invite à s’y pencher car il est très bien pensé. Ne connaissant pas du tout, je me garde de tout commentaire.

Oreilly a déposé un droit d’exploitation sur le nom web 2.0.

Résultat, un courrier de cessation (le fameux cease-and-desist) a été envoyé au forum IT@CORK qui utilisait, comme tout le monde, ce terme tant à la mode !

J’en connais un qui va être surpris en rentrant de vacances. Se passer du terme web2.0 sera dur ! 🙂

Dommage pour Oreilly et son patron Tim qui prennent un sacré coup d’image négative dans les dents, même si c’etait prévisible.

Je propose donc comme Zoli, de passer directement au web4.0 histoire d’être tranquille pour quelques temps 😉

En conclusion, citation de Michael Arrington (TechCrunch, CrunchNotes) :
Tim O’Reilly needs to muzzle his lawyers immediately and respond publicly, personally and immediately to the situation, because I sense that a lynching is about to occur in the blogosphere.

Update : Une réponse officielle de Oreilly mais pas de Tim et confirmant la démarche uniquement auprès des conférences utilisant le terme « web2.0 ». Le mal est fait mais Fred est sauvé !

Update 2: La vrai réponse de Tim Oreilly… Très long mais explique bien la situation.

Avec la sortie de Eclipse 3.2, il est intéressant de voir quelles sont les nouveautés proposées par cet IDE.

On retrouve sur le site d’eclipse un document de 91 pages ! présentant toutes ces nouveautés écrit par Chris Laffra. Très intéressant à lire car beaucoup de captures d’écran.

• Présentation au format PDF
• Présentation au format PPT

Histoire de mettre le nez dans ces nouveautés, je vous engage à aller télécharger la dernière version mise à la disposition sur le site de eclipse (page de download).

Il s’agit actuellement de la 3.2 M6 (sortie le 31 mars 06) qui est relativement stable et ne plante pas plus qu’un 3.1. De plus cette version est « feature complete ». C’est à dire que lorsque la version finale sortira, elle sera identique au point de vue fonctionnalités.

C’est donc un bon moyen de prendre de l’avance sur la prise en main de l’outil.

La sortie définitive d’eclipse 3.2 est prévue pour fin juin.

Plus les méthodologies agiles ou pragmatiques prennent de l’importance et plus elles replacent l’activité de construction au coeur du projet . Comme on dirait sous XP (Extreme Programming), la vérité est dans le code …

Néanmoins, le code est plus que jamais l’affaire de tous (comme la qualité) et le développeur doit l’écrire sans ego.

Les 10 commandements du développeur sans égo sont :

1. Comprendre et accepter que nous ferons des erreurs. En revanche, les résoudre est important !
2. Nous ne sommes pas le code. Ne jamais prendre personnellement les erreurs trouvées dans notre code
3. Quelle que soit notre niveau d’expertise, quelqu’un d’autre en saura toujours plus. Il faut juste savoir l’accepter et en tirer de nouvelles connaissances (même sur des sujets périphériques)
4. Ne pas reécrire le code de quelqu’un sans le consulter. Ne pas foncer tout seul dans son coin…(voir 9)
5. Traiter ceux qui en savent moins avec respect et patience. La réputation des informaticiens n’est plus à faire auprès des personnes non techniques. N’en ajoutons pas !
6. La seule constante au monde est le changement. Avoir l’esprit ouvert et garder le sourire 😉 C’est un challenge et non une lutte
7. La seule autorité acceptable vient de la connaissance et non du pouvoir. Si vous voulez du respect, engrangez de la connaissance
8. Il faut se battre pour ses idées mais accepter la défaite. Accepter que parfois, notre raisonnement ne sera pas suivi. Même si plus tard, il s’avère juste, il ne sert à rien de remettre sur le tapis le « Je te l’avais bien dit ».
9. Ne pas être « l’informaticien du bureau du fond ». Etre trop isolé nous fait perdre le contexte de notre travail, le contrôle sur ce qui se passe et mine la communication.
10. Critiquer le code plutôt que la personne. On peut être gentil avec la personne tout en commentant le code. Autant que possible, on peut tourner les phrases de facon positives et constructives. Par exemple, les arguments relatifs aux normes, standard, spécifications, performances sont toujours bien perçus.

Ces principes humains ne sont pas nouveaux et sont des vérités universelles et intemporelles… (1971 !)

Inspiré librement de :

• http://www.codinghorror.com/blog/archives/000584.html
• http://builder.com.com/5100-6404-1045782.html