|
|
Google l’avait annoncé et le voici : le système d’exploitation basé sur son navigateur open-source chrome. Plutôt destiné aux netbooks, il est pensé pour les utilisateurs qui n’allument leur ordinateur que pour lire leurs mail et trainer sur facebook, c’est-à-dire qui n’ont souvent besoin que d’un navigateur ouvert en plein écran. Google Chrome OS leur propose un délai de quelques secondes seulement entre le bouton marche et le navigateur sur internet. Il fonctionne sans stocker de données sur l’appareil : applications et données sont manipulées directement sur internet. Par exemple, il s’agit d’utiliser un document en ligne google docs au lieu d’utiliser traitement de texte et document stockés par l’appareil. On pourrait dire que google pousse la molette de réglage local<->cloud à 11.
Jamais sans mon disque dur
J’imagine l’intérêt pour les utilisateurs ainsi que pour les vendeurs de logiciel (qui verront enfin leur vieux rêve de location de leurs logiciels – donc zéro piratage – enfin réalisé). L’erreur, à mon humble avis, serait dans l’approche « Toutes vos données sont sur le cloud. Toutes ? Toutes ! ». Je veux bien que les données soient hébergées en ligne mais il faut quand même un disque dur ou un quelconque moyen de conserver une copie personnelle (ou d’entreprise) des données. C’est l’exacte symétrique de la recommandation de faire un backup en ligne à ceux qui gardent tout sur leur disque dur… Je n’écris pas ça par conservatisme, je n’ai pas peur du cloud, tout comme on peut être fana d’escalade et recommander le mousqueton.
Pourquoi conserver une copie sur disque dur ?
- Pour avoir une copie de sauvegarde, à un prix comparable aux services de sauvegarde les plus abordables. Avec un avantage colossal : le temps d’accès. C’est en essayant de m’imaginer en train d’essayer de retélécharger 18Go d’album photo (eh oui, vive le reflex numérique) depuis mozy.com -l’envoi de DVD est un service lourdement facturé- que j’ai décidé de conserver un miroir sur disque dur à la cave.
- Pour conserver la propriété et la jouissance de mes œuvres. Si l’on est dans un système de location, le loueur peut disparaitre, faire faillite, changer ses tarifs, ses prestations, vous mettre sur la liste des pays subissant l’embargo américain, effacer vos données à distance (comme amazon sur son lecteur d’ebooks), la liste des ennuis potentiels est infinie… Quand je prends une photo, développe un logiciel ou rédige un document, je veux pouvoir y avoir accès indéfiniment. Cela veut également dire qu’il faut être vigilant quant au format d’exportation que proposent les suites logicielles en “cloud” : il faut pouvoir obtenir un backup lisible sur le long terme (dans un format ouvert et de préférence non-propriétaire).
- Pour avoir accès à mes documents sans réseau. Quel que soit votre FAI, vous aurez des coupures ; vous partirez peut-être en congés sans clé 3G ; vous serez peut-être victime des dommages collatéraux de l’HADOPI… Bref, sans réseau point de données. L’idéal est de disposer d’un mécanisme de synchronisation capable de gérer efficacement les connexions intermittentes. La technologie Google Gears (tiens donc) permet d’ores et déjà de le faire pour certaines applications. HTML5 promet de généraliser cette fonction entre autres capacités utiles au cloudapps.
La CloudBackupBox
Je vous propose donc la CloudBackupBox : un boitier silencieux autour d’un gros disque dur et d’une connexion réseau, qui se connecte régulièrement à tous les services cloud que j’utilise et qui synchronise toutes mes données sans intervention manuelle. On peut imaginer une prise USB qui permet de se brancher physiquement pour configurer l’appareil ou bien travailler sur les données stockées sur le disque dur : mode hors-ligne ou restauration de sauvegarde. Ajoutez à cela un mode sécurité qui demande un code PIN pour s’allumer et crypte toutes les données sur le disque dur, afin qu’un cambrioleur ou autre indélicat ne puisse pas lire le contenu du disque. Il ne me reste plus qu’à déposer le brevet. Ah flûte, trop tard ! Je n’aurais pas dû en décrire le principe ici, ça doit compter comme prior art…
—
Crédit photo : purplemattfish - Certains droits réservés (licence Creative Commons)
Je suis allé au 17ème BarCamp parisien, sur le thème « OpenWeb + Cloud + Geo + Social ». C’était à la fois un sujet que je suis de près et l’occasion de découvrir un BarCamp…
Pour résumer, je dirais que la philosophie est qu’un BarCamp est à une conférence ce qu’un wiki est à un site web. Comparons avec une conférence traditionnelle : liste d’orateurs et sujets déterminée, auditoire attentif, mais dont la participation se limite aux questions-réponses de clôture après chaque présentation. Le BarCamp se veut participatif : chacun se présente rapidement, lance des mots-clés, et on essaie sur tableau blanc de constituer des groupes de travail ad-hoc autour d’un thème (démo, présentation, atelier, session de programmation).
Bon, ce que je constate c’est que même si la conférence s’auto-organise librement, ce sont les têtes d’affiche (évangélistes auprès des développeurs pour les APIs de google et de Mozilla par exemple), dont la présence avait attiré les foules, qui ont fait leurs présentations… certes de façon informelle, sans transparents, en face à face. Je suis un peu resté sur ma faim, car en allant à une conférence sur un sujet que l’on suit de près, eh bien on risque de s’ennuyer… Les sessions d’introduction à GWT ce n’était pas la peine, et la séance d’autocongratulation autour de FireFox son XUL m’a lassé. Je n’ai pas vu la suite, j’ai préféré passer ma soirée en famille qu’à partager des pizzas avec des hackeurs fous. Allez savoir, j’ai peut-être raté le meilleur moment… Il s’agit effectivement d’un évènement principalement social.
Le passage qui m’a intéressé était une table ronde autour d’un sujet que je ne connaissais pas : FOAF+SSL. Ça m’a rappelé l’époque ou je starteupais dans le web-sémantique… Habile transition : ma conclusion perso est que ce genre d’évènements est intéressant quand on est entrepreneur et que l’on veut réseauter, ou bien un développeur qui veut s’initier simplement à des nouvelles technologies. Sinon… je garde un faible pour les conférences avec de sympathiques papiers à lire et relire. Par exemple, tout de même, les PLoP, c’est quand même du bon stimulant neuronal !
Du management…
Un collègue m’a récemment envoyé un papier de Steven Kerr »On the folly of rewarding A, while hoping for B« . Il montre que très souvent le discours officiel d’une organisation est de vouloir un comportement, tout en mettant en place un système de récompense/punition qui dans les faits pousse les gens à un comportement tout autre, voire opposé.  Par exemple on demande à un joueur de sport collectif d’avoir « l’esprit d’équipe » et pourtant on ne félicite que les actions individuelles. D’ailleurs, on ne résume un match de football que par les noms des buteurs. Ainsi, agacé qu’un joueur fasse trop de passes à l’adversaire, un entraineur sanctionne chaque passe ratée ; au match suivant personne ne fait plus aucune passe et le jeu est bloqué. 
Exemple parfait de contre-productivité : une clinique veut réduire le nombre de décès. On met donc en place une prime qui doit récompenser le chirurgien qui a moins de X décès dans le mois sur le billard. Que va-t-il se passer ? On peut parier que dans les mois suivants tous les chirurgiens vont toucher la prime… En effet, dès qu’ils s’approchent du quota fatidique, ils repoussent toutes leurs opérations délicates au mois suivant ! Du coup les gens décèdent dans leur lit en attendant l’opération, mais ça n’est pas le problème du médecin. Tout le monde touche sa prime, cependant le nombre de décès global de la clinique augmente…
Cette théorie semble être un grand classique du management (le papier remonte à 1975) mais je n’en avais jamais entendu parler. Et quand je l’ai lu j’ai eu une illumination. Tenez, imaginez que vous vous tenez sur une grande étendue de sable, une sorte de drap rouge à la main ; vous le secouez un peu en vous demandant pourquoi vous avez ça à la main , quand vous entendez un bruit de sabots tagadam-tagadam dans votre dos  et *vlan*
… au génie logiciel.
J’ai compris beaucoup de choses sur le projet de développement en lisant cela. Finalement, qu’est-ce que l’on demande aux développeurs ? Comportement ‘A’ : « Produire du code de qualité, maintenable par autrui ». Qu’est-ce que l’on récompense ? Les délais de livraison : comportement ‘B’. Je n’ai jamais vu un développeur se faire sanctionner pour du code mal écrit, non commenté ou conçu de traviole. Par contre, prenez du retard sur le développement, vous allez vous faire enguirlander et vous devrez rester tard tous les soirs pour faire bonne figure. Donc, si vous avez envie d’une vie de famille ou de loisirs : bâclez votre code.  Ne commentez surtout pas, et ne testez que si l’on vous le demande. De toute façon c’est votre successeur qui sera pénalisé par le code non-maintenable ; c’est lui qui ratera ses deadlines  *niark niak niak niak* (<- rire façon méchant dans James Bond).
Rendre ‘A’ inévitable, récompenser ‘B’
On va pas chasser le naturel, alors on va biaiser un peu. Continuez à récompenser les délais (‘B’), mais considérez ‘A’ comme acquis. Il faut intégrer le contrôle qualité continu et automatisé à tout environement de développement. Il doit être impossible de réussir un « build » (et donc de livrer) si l’artefact en question ne respecte pas tous les standards en vigueur. J’ajouterai même une revue obligatoire de tout code, du stagiaire au chef de projet, avant de pouvoir placer le post-it dans la colonne « fait » du tableau blanc. Passez par la colonne « en revue », ne touchez pas vingt-mille francs. Enfin pas tout de suite… Soyons fous, récompensons la qualité  .
PS: merci à Majirus pour l’article
Si l’on regarde l’ensemble des projets open-source, on trouve en moyenne près d’une ligne sur cinq de commentaires, selon un papier de Dirk Riehle (voir également sur son blog).
On y lit que les projets étudiés restent tous très proches de ce taux. Un peu plus surprenant, on découvre que cette densité de très exactement 18,7% de commentaires est la même quelles que soient la taille du projet et la taille de l’équipe  . L’article propose l’explication que c’est dû à une grande auto-discipline de développeurs, très probablement motivée par l’exposition publique du code source à conjointement au nom de son contributeur.
Autre information de cette étude : ce qui influe sur le taux de commentaires est l’âge du projet. Quand un projet avance en maturité son taux de commentaires baisse (enfin d’un chouïa, à 18%). Je suppose que lorsque l’on maintient un code depuis plusieurs années, certaines choses deviennent tellement comprises, partagées et habituelles qu’elles en deviennent implicites, du coup on aurait l’impression d’écrire des évidences dans les commentaires en détaillant trop…
Ces statistiques soulèvent quelques petites questions… Par exemple, peut-on considérer ce taux comme idéal ? En effet, c’est le taux auquel des développeurs volontaires et auto-organisés aboutissent à moyen terme, quel que soit le projet. Moins de commentaires c’est pas assez, mais plus de commentaires c’est inutile, voire c’est introduire du bruit. Si l’on admet ce taux comme “idéal”, le taux de commentaires de mes développements s’éloigne-t-il significativement de ce chiffre ? Quelle conclusion en tirer ? Ainsi, vous est-il déjà arrivé comme à moi, de vous dire qu’avant de diffuser tel ou tel de vos composants en open-source, il faudrait faire un petit effort de packaging et de documentation ? 
Question, en guise de conclusion : si vous imposez de préciser dans les commentaires le ou les auteur(s) de toute classe et méthode par exemple (c’est-à-dire en Java : @author partout), est-ce que vous obtiendrez un code globalement mieux commenté et/ou plus lisible ?
|
