Dur Comme Faire

Microsoft a finalement décidé d'attendre que le bureau Américain des brevets et marques déposées se prononce sur la validité du brevet d'Eolas avant de modifier Internet Explorer.

Peut être est-ce l'impossibilité que la firme de Redmond semble avoir à mettre à jour son navigateur qui en est la cause. En effet depuis quelques temps les déclarations fantaisistes se multiplient laissant entendre que l'équipe de développement d'Internet Explorer ne sait plus comment se dépatouiller de son logiciel.

Alexandre Lokchine a écrit pour le site Developpez.com un excellent article sur les brevets logiciels. Loin d'alimenter la polémique, l'auteur s'en tient aux faits et tord le cou à pas mal d'idées reçues comme notamment celle qui veux faire croire que l'enjeu est le droit ou non de déposer des brevets logiciels.

En effet depuis 1986 il est possible de faire breveter un logiciel en Europe mais avec certaines restrictions tout de même : Un produit programme d'ordinateur n'est pas exclu de la brevetabilité (...) si sa mise en œuvre sur un ordinateur produit un effet technique supplémentaire, allant au-delà des interactions physiques normales entre programme (logiciel) et ordinateur..

La question ne se trouve pas là comme beaucoup le pense. Le vrai enjeu est celui de savoir si l'on veux étendre cette brévetabilité à tous les logiciels sans restriction.

Beaucoup de blogs en ont déjà parlé mais après avoir lu l'excellent article d'Etienne Lavanant sur les enjeux humains et sociaux du logiciel libre, je ne peux m'empêcher d'écrire ce billet afin que les derniers qui l'auraient manqué puisse réparer leur erreur.

Les principaux points fondamentaux du logiciel libre sont abordés et surtout le niveau technique requis est faible, mettant cet article à la porté de tout un chacun ce qui est précisément le but. Bravo !

Décidément c'est la période des anniversaires !

Alors je profite de cette tribune pour souhaiter un joyeux anniversaire à Olivier, Robin et surtout à ma dulciné.
Tu n'as plus 20 ans à présent mais tu restes mon trésor.

Voilà que ce blog atteint le chiffre symbolique de 100 billets. Je crois que c'est le moment de faire un petit bilan des derniers mois.

Pour être franc je n'avais pas d'ambition précise en créant ce blog. Je ne savais pas précisément où j'allais. L'envie était plus instinctive que réfléchie. C'est au fil des billets que l'orientation de ce blog s'est forgée. Au départ je devais vraiment chercher les sujets que j'allais développer ici même puis avec le temps les idées me viennent plus facilement. A présent c'est plus de temps que d'idées dont je manque.

Bien sûr je jette également un oeil critique sur mon discours. J'ai de gros progrès à faire au niveau du style et aussi au niveau de l'orthographe qui parfois laisse à désirer. J'aimerais également mieux construire ma réflexion et éviter certains billets qui ne reflète qu'une partie de ma pensée et pas nécessairement la plus interessante.

Tout cela représente une somme de travail non négligeable, surtout par rapport au temps libre dont je dispose mais ça vaux le coup. J'essaie de ne pas devenir moi aussi accro aux statistiques de fréquentation de mon blog mais je dois avouer être agréablement surpris par le nombre de visiteurs quand je les consulte. C'est une source de motivation importante surtout depuis que ces visites se traduisent par des commentaires et donc un dialogue avec mes lecteurs.

Car au fond je pense que ce que je cherchais de manière inconsciente c'était cette communication avec des gens intéressants sur des sujets qui m'intéressent vraiment alors merci à vous lecteurs pour lire ma modeste prose et faire avancer ma reflexion par vos remarques, critiques et encouragements.

Lors de ma lecture quotidienne du StandBlog, qu'apprend-je ? L'excellent Tristant Nito donne une conférence à Lille sur Mozilla, les standards et l'accessibilité, dans le cadre de la licence professionnelle DA2I.

Dire que j'ai obtenu cette licence à l'université de St Quentin il y a 1 an et demi et que je vis à présent à Lille. Vous comprendrez ma frustration je pense. Non pas que je remette en cause la qualité des intervenants que j'ai eu la chance de rencontrer mais j'aurais vraiment adoré entendre Tristan de vive voix.

Puisque j'y suis je te lance un appel Tristan. Si un jour tu reviens à Lille serais tu intéressé par un Apero PHP ? Je suis sûr que la demi-douzaine de convives que nous sommes serait ravie de te rencontrer.

Apparemment certains députés prennent en compte les récriminations de leurs électeurs. Ainsi Pascale a reçu un mail de son député suite à la pétition qu'elle a signé sur le site Odebi.org concernant la LEN. Même si le ton est très démagogue, laissons à ce politicien le bénéfice du doute. Lui au moins a pris la peine de répondre.

Moi qui ai également interpellé mon député, je n'ai obtenu aucune réponse. Dans le même temps Jacques Mutez est peut être trop occupé à faire le tour des plateaux de télévision afin d'expliquer sa carte de voeux pour la nouvelle année.

Le récent billet de Greut concernant la distraction engendrée par différentes formes de communication dont les mailing-lists et les messageries instantanées m'a fait repenser à un excellent article, du non moins excellent Joël Spolsky, que m'avait fait lire Perrick il y a quelques mois.

Cet article présente 12 points pour évaluer la qualité du code que vous produisez. L'intérêt est que cette méthode est très simple à comprendre et à mettre en oeuvre. C'est plus un receuil de bonnes pratiques et de bon sens que des trouvailles révolutionnaires. Cependant comme disait un de mes professeurs de faculté: Ca va sans dire mais ça va mieux en le disant.

Si la pertinence de certains points dépend de la structure et de la taille de votre société, globalement ça ne fait pas de mal de jetter un coup d'oeil à cette liste afin d'éventuellement remettre en cause certaines pratiques ancestrales mais peu efficaces.

Mon ami YoGi, non pas l'ours, le vilain métalleux au grand coeur, vient de publier un billet où il narre sa migration d'Outlook Express vers ThunderBird. C'est très interessant, didactique et pourrait décider ceux qui hésitent encore à faire le grand saut.

Personnellement je l'ai fait dès la sortie de la version 0.1 car j'avais été très satisfait de FireBird et que j'en avais marre des limitations d'Outlook Express. Plus de 6 mois après, je ne regrette absolument pas cette migration.

Le Logiciel Libre prend chaque jour plus de poids dans le secteur de l'édition de logiciels. On peut mettre cela au crédit des dérives des logiciels propriétaires (Bugs et failles de sécurité à répétition de Microsoft, marges dignes des pires usuriers etc.), de la prise en considération des bénéfices de l'interopérabilité et aussi à la crise économique qui pousse à réduire les coûts. Ce constat est plutôt agréable à entendre car il signifie que les utilisateurs gagnent du pouvoir au détriment des grosses firmes multinationales. Seulement il pose un problème que peu semble voir venir.

Danger du positionnement actuel du Logiciel Libre

Il ne faudrait pas laisser s'installer dans l'esprit de tout un chacun que le Logiciel Libre est un logiciel venu de nulle part et qui répond miraculeusement aux besoins.
Le Logiciel Libre ne peut continuer à vivre que par la participation des utilisateurs à son évolution. En effet contrairement aux logiciels propriétaires, l'investissement mis dans son développement n'est pas directement proportionnel au nombre d'installations. Ainsi on peut installer 100 000 copies d'Apache sans que l'équipe de développement n'en tire le moindre bénéfice. C'est clairement le résultat des règles du Logiciel Libre qu'ont accepté les auteurs, cependant il faut voir un peu plus loin que le bout de son nez.

Pour être pérenne, le Logiciel Libre doit être soutenu par ceux là même qui en vivent aussi je pense qu'il est important de mettre en avant lors de sa promotion qu'outre le fait qu'il est possible d'avoir accès aux sources il est fort souhaitable de participer à son développement. Pour paraphraser John Fitzgerald Kennedy Ne vous demandez pas ce que le Logiciel Libre peut faire pour vous. Demandez vous ce que vous pouvez faire pour le Logiciel Libre.

Quelques pistes pour parer à ce risque

Admettons que cela soit acquit, encore faut-il trouver un moyen de contribuer avec ses modestes moyens à l'élaboration du Logiciel libre car tout le monde ne possède pas les ressources de Sun ou IBM.
Je vais me permettre de lancer quelques pistes, tout en attendant vos commentaires pour compléter car les possibilités sont immenses.

• Rapports de bugs: C'est un moyen simple et qui permet un retour sur investissement direct qui est donc facilement justifiable aux yeux des décideurs
• Soumission de patchs: Rapporter des bugs est utile mais si il n'y a personne pour rechercher la cause du problème et sa solution, l'utilité est nettement réduite. Il est souvent aisé et bienvenu de la part des développeurs principaux de soumettre un patch pour corriger un bug voire pour apporter une nouvelle fonctionnalité. La communauté du Logiciel Libre est ouverte d'esprit car c'est la base même de son existence. N'ayez donc pas peur de soumettre vos patchs comme l'a fait votre serviteur pour quelques packages PEAR. Là encore le retour sur investissement est immédiat et les ressources consacrées faibles : j'utilisais des packages qui avaient des comportements anormaux, j'ai recherché la cause du problème, j'ai modifié le code en conséquence et au lieu de garder mes modifications pour moi, je l'ai ai soumises aux auteurs des packages qui les ont incorporées avec plaisir, non sans les avoir testées et critiquées voire rejettées (et à raison) pour certains d'entre eux.
• Mise à disposition de documentations: Parfois il vous arrive peut être de rédiger une documentation concernant l'utilisation d'un Logiciel Libre à destination d'utilisateurs extérieurs au service informatique (secétaires, agent de productions, dirigeants etc.). Partager ces documentations peut être très utile car par manque de ressources, la documentation est souvent le parent pauvre de la communauté du Logiciel Libre.

Ce ne sont que quelques pistes mais comme vous pouvez le voir, elles sont relativement simples à mettre en oeuvre et finalement assez peu coûteuses en terme de ressources pour vous et votre entreprise mais elle sont très utiles à la communauté. Bien évidemment le foisonnement de l'offre du Logiciel Libre ne permet pas de généraliser cette pratique à tous les logiciels que vous pouvez utiliser mais en choisir quelques uns, de préférence ceux manquant de retour de la part des utilisateurs, est déjà faire un pas dans la bonne direction afin d'assurer la pérénité du Logiciel Libre.

Suite aux commentaires qui ont suivi un de mes billets récents sur les Etats Unis, je me suis pas mal interrogé. Je me suis demandé si j'étais allé trop loin. Si je n'avais pas exprimé trop brutalement mes idées.

Je reconnais que sur certains sujet, dont les Etats Unis, je perds assez vite ma retenue habituelle mais très vite j'en suis venu à la conclusion que tant que mes propos restaient corrects il n'y avait aucune raison de m'auto-censurer. En effet il faut garder à l'esprit qu'un blog par définition est subjectif. Celui-ci a été dès le début défini comme une tribune publique où je pourrais exprimer mes idées.

Après mes idées valent ce qu'elles valent. Je n'ai pas la prétention de détenir une quelconque vérité, concept auquel je ne crois d'ailleurs pas. Je laisse à chacun le droit, et même le devoir, d'accorder le crédit qu'il pensera approprié à mes propos.

Enfin je voudrais attirer votre attention sur un excellent billet de Asterisk* qui rappelle que face au développement des moyens alternatifs de diffusion de l'information, il convient de redoubler de vigilance et de sens critique pour ne pas se laisser tromper par des opinions forcément subjectives voire par de la désinformation volontaire.

Ce soir j'ai découvert par hasard qu'il était possible, et même ultra simple, d'ajouter des moteurs de recherche à la fonctionnalité Recherche de la barre d'outils de FireBird. Il suffit de cliquer sur l'icone et de choisir Add engines .... Vous allez arriver sur une page où vous trouverez des dizaines de nouveaux moteurs que vous pouvez installer d'un simple clic. Qui a dit que le logiciel libre était réservé aux geeks prêts à braver les défauts d'ergonomie les plus manifestes ?

Parmi la pléthore de moteurs de recherches disponibles voici ceux qui m'ont marqué :

• Google France
• UBL (Annuaire de sites musicaux)
• Altavista
• Yahoo!
• IMDB French (Informations sur les films)

De plus il est possible d'obtenir d'autres services par ce biais comme la traduction par Babel Fish. Au passage je vous signale que la recherche parmi les packages PEAR est également possible.

Voilà encore une excellente raison d'adopter FireBird.

Ca fait plus d'un an que je cherchais à découvrir l'Extreme Programming. A l'époque j'étais tombé sur un article décrivant cette méthode et je dois avouer que les concepts de base (agilité, tests unitaires, cycles courts etc.) m'avaient pas mal plu. Faute de temps, j'avais remis ça à plus tard jusqu'à ce que Perrick me parle d'un livre qu'il venait de lire sur le sujet lors du dernier Apero PHP lillois. Il a d'ailleurs écrit un billet à ce sujet.

Alors voilà j'entame avec ce billet une série qui me permettra de relater au jour le jour mes impressions sur ce livre. Si je le fait sur ce blog et non sur une feuille de papier c'est pour que chacun puisse commenter ce que je vais tirer de ce livre et au besoin m'éclairer ou me détromper.

Ce soir je commence en douceur avec l'introduction. Fort logiquement elle démontre les limites des démarches par phases puis décrit les pratiques de l'Extreme Programming (que j'appellerai à présent XP pour plus de simplicité) avant d'en citer les valeurs. Mais avant de commencer les choses sérieuses faisont un rapide résumé de l'historique d'XP.

Historique

Initialement XP a été créé par Kent Beck dans le cadre du projet C3 de Chrysler avec l'aide de Ron Jeffries. Ward Cunningham les rejoindra plus tard et formera avec Kent Beck le noyau des instigateurs d'XP.

Pressentant que leur méthode était plus universellement applicable, ils affinèrent celle-ci à l'aide du site collaboratif Wiki Wiki Web avant que Kent Beck ne publie en octobre 2000 le livre Extreme programming explained.

Limites des démarches par phases

Si vous avez un tant soit peu de bouteille dans ce métier, vous avez sans nul doute déjà expérimenté avec la méthode du développement par phases les désagréments suivants:

• Spécifications changeant alors que le développement est déjà commencé : Ce qui entraîne soit une mécontentement du client car on ne change pas les spécifications soit une perte de temps et un surcoût si on modifie effectivement les spécifications et que l'ont fait les modifcations qui en découlent sur ce qui est déjà développé.
• Effet tunnel : Il se passe un temps non négligeable entre la rédaction des spécifications et la livraison du produit au client. Seulement pendant ce temps là, les besoins de celui-ci ont pû changer entre temps ou il a pû tout simplement affiner sa demande. Ca arrive relativement souvent car n'étant évidement pas du métier, le client imagine souvent mal ce qu'il peu demander et ce qu'il ne peut décemment pas envisager pour son produit.
• Démotivation des équipes : Si elle a du bon, la spécialisation des équipes tend à démotiver celles-ci car le travail à alors tendance à devenir répétitif et monotone.
• Code peu optimisé : Les équipes de développement n'ayant souvent pas une vision globale du projet, le code souffre de lourdeur et d'un manque d'optimisation. Il est évident qu'à force de toujours travailler sur son propre code, on lui voit plus les défauts que lui verrait un oeil extérieur.

Les pratiques d'XP

Dans ce livre, on trouve 13 pratiques alors que parfois on n'en compte que 12. C'est en fait parce qu'ici les tests unitaires et les tests de recette sont séparés.

Voici une liste exhaustive de ces pratiques avec leur description. Ces informations sont extraites du Wiki francophone sur XP que je vous encourage à consulter.

Les pratiques de programmation

• Conception Simple (Simple Design) : Le code doit passer tous les tests et répondre aux critères de maintenabilité : concision, modularité, cohérence, lisibilité.
• Remaniement Continu (Refactoring) : Modification du code par laquelle on améliore sa conception sans en modifier le comportement.
• Tests unitaires (Unit testing) : Des tests automatisés sont écrits pour chaque classe, chaque méthode, et pour tout "ce qui pourrait casser" en général. Ces tests doivent passer à 100% continuellement.
• Tests de recette (Acceptance Tests) : Retour d'information rapide sur le système, en général automatisé, constitué à partir de critères de test définis par le client.

Les pratiques de collaboration

• Programmation en binôme (Pair programming) : Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.
• Propriété Collective du Code (Collective code ownership) : Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir.
• Convention de codage (Coding Standard) : Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe.
• Métaphore (Metaphor) : Une analogie utilisée comme modèle conceptuel du système en cours de développement.
• Intégration continue (Continuous integration) : Le système est intégralement assemblé et testé une à plusieurs fois par jour.

Les pratiques de gestion de projet

• Livraisons fréquentes (Frequent releases) : Le rythme des livraisons est le plus soutenu possible.
• Séance de planification (Planning Game) : Le client définit les scénarios utilisateurs prioritaires. Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-jacentes, estiment ces tâches et y souscrivent.
• Client sur le site (On-site customer) : Pour une meilleure communication, le client et les développeurs travaillent dans le même espace autant que possible.
• Rythme soutenable(Forty-hour week) : L'équipe fait en sorte de maintenir sa capacité à développer efficacement en ne surchargeant pas outre mesure ses horaires de travail.

Globalement tout cela me semble plein de bon sens mais une question me turlupine: comment automatiser les tests de recette ? Si j'ai bien saisi, il s'agit de tests au niveau utilisabilité de l'application et non au niveau du code en lui même. Ce genre de test me semble difficile à automatiser. J'en apprendrais sans doute plus par la suite dans ce livre mais si quelqu'un a une explication rapide je suis preneur.

Les valeurs d'XP

Xp est composé de 4 valeurs qui définissent sa spécificité :

• Communication : L'accent est mis sur la communication en général et la communication orale en particulier car celle-ci améliore l'ambiance dans une équipe et l'implication de ses membres dans le projet.
• Simplicité : Il s'agit de toujours choisir la solution la plus simpel qui puisse marcher (The simpliest thing that could possibly work). De plus XP met particulièrement en garde contre les travers des développeurs qui cherchent souvent à créer des outils génériques alors que le besoin ne s'en fait pas sentir. Si cela s'avérait nécessaire alors il faudrait le faire mais il faut s'interdire de le faire à priori.
• Feedback : Le feedback, que l'ont pourrait traduire par retour en français, ne se situe pas seulement au niveau de l'adéquation du produit avec les demandes du client. Il aide également à affiner les spécifications en cours de développement si besoin est. Loin d'être inutile ce feedback est gage de qualité car il permet de recadrer en permanence le produit avec les besoins du client. Besoins qui peuvent évoluer avec le temps rappellons le.
• Courage : Cette valeur peut paraître étrange dans le contexte d'une méthode de développement d'un projet informatique mais il faut reconnaître qu'une bonne dose de courage est nécessaire pour se lancer dans un développement sans avoir de spécifications approfondies et définitivement fixées. Bien sûr il existe de multiples mécanismes destinés à parer aux problèmes qui surgiront inévitablement mais ce n'est tout de même pas forcément évident. Il faut également du courage pour faire accepter à des développeurs que leur code puisse être jetté s'il n'est plus en adéquation avec les besoins du client. C'est quelque chose que nous répugnons souvent à faire mais c'est un tort. Il vaux souvent mieux repartir sur des bases saines que de tenter de bricloer un code mal conçu ou mal adapté au contexte. Enfin le travail en binôme et l'appropriation collective du code oblige à dévoiler ses limites et ses lacunes aux autres membres de l'équipe ce qui demande une certaine modestie au niveau de l'égo.

Premières impressions

Je dois avouer que mes premières impressions sur XP sont bonnes. Cette méthode semble offrir ce que j'en attend. Espèrons que cela va continuer.

C'est avec un peu de retard pour cause de réveillon du nouvel an dans ma région natale que je vous souhaite une bonne année 2004.

Côté bonnes résolutions, voici pêle mêle ce que je compte faire pour l'année qui vient :

• Exprimer mes frustrations et mes problèmes au fur et à mesure au lieu d'encaisser sans broncher jusqu'au jour où je m'emporte aussi violemment que soudainement
• Lire le livre L'Extreme Programming
• Améliorer ma productivité si je veux venir à bout de tous mes projets avec le peu de temps libre que j'ai
• Partir en vacances pour la première fois depuis 7 ans
• Me sevrer de mon ordinateur (mais ça c'est pas gagné)
• Mieux façonner mes idées et mes arguments en les basant plus sur des faits et moins sur des opinions aléatoires
• Arrêter les blagues pourries ... non pour ça je déconne, c'est ma marque de fabrique

Ca peu paraître présompteux de vouloir modifier tant de choses mais comme on dit, c'est l'intention qui compte.