Je serai présent les jeudi 12 et vendredi 13 novembre prochains au Forum PHP, qui est une importante manifestation organisée par l’AFUP (Association Française des Utilisateurs de PHP). J’y présenterai FineFS, le système de fichiers redondé sous licence libre que je développe au sein de mon entreprise, et dont j’ai…
Pensées sur le vif : les enseignements du milieu hospitalier
Vous avez remarqué que je n’ai pas posté de nouveaux billets sur ce blog depuis quelque temps. L’explication simple : ma femme a accouché il y a 2 semaines d’une petite fille prématurée (elle s’appelle Ania et c’est le plus beau bébé du monde), ce qui chamboule beaucoup de choses. L’explication longue : j’ai plusieurs billets en cours d’écriture, mais avec cette naissance je n’ai pas trouvé le temps de continuer leur rédaction.
Le monde hospitalier
Il n’empêche que la situation m’a fait remarquer certaines choses. La première, c’est que le personnel hospitalier est vraiment en sous-effectif. Quand une sage-femme vous explique qu’elle aurait dû terminer son service à 15h00, et que son mari ne va pas être content parce qu’elle reste jusqu’à 21h00 pour la troisième fois de la semaine, on relativise beaucoup ce que les informaticiens subissent en période de rush (je rappelle au passage que la plupart des informaticiens ont le statut de cadre et trouvent ça normal ; pensez-vous que les sage-femmes aient ce statut ?).
Ensuite, la rétention d’information est une vieille habitude qui est toujours bien vivace. Mais le plus étonnant, c’est que tout le monde ne la pratique pas. Pour être clair, tant que ma femme était hospitalisée et qu’elle subissait des examens, il était impossible d’avoir la moindre information. Qu’est-ce qui cloche exactement ? Pourquoi une nouvelle prise de sang, qu’est-ce qui a été trouvé dans la précédente ? Quels sont les risques ?
Chaque nouveau médecin n’apportait aucune information, à part le fait qu’il faille faire de nouveaux examens. Le top du top, c’est le soir où un médecin est venu, a pris une feuille de résultats, nous a dit « Je vais chercher les autres résultats et je reviens » ; 45 minutes après, une infirmière nous a rapporté la feuille de résultats, en nous disant que le médecin était parti.
Choisir un nom d’entreprise, de produit, de projet
Choisir un nom est souvent une étape bizarre. On a envie de trouver le bon nom, celui qui reflétera au mieux l’énergie et l’ambition qu’on place dans notre nouveau « bébé », qui sera le plus attractif, qui sonne le mieux à l’oreille…
Oui mais voilà, des fois on a beau se creuser la tête, il n’y a rien qui nous vient à l’esprit naturellement. Et pendant qu’on passe du temps à chercher, on risque de bloquer l’avancée du projet ; comme le nom apparaît partout, il est difficile de démarrer sans. Alors parfois on finit par prendre un nom à la va-vite, le moins mauvais qu’on avait trouvé, au risque de se le trainer pendant un bon bout de temps.
Dans le titre de ce billet, j’ai listé trois types de noms : celui qu’on veut donner à une entreprise, à un produit ou à un projet. Il y a de subtiles nuances entre chaque.
Entreprises
Un nom d’entreprise doit être à la fois parlant et facile à retenir, tout en étant assez générique pour ne pas limiter le champ d’activité. Idéalement, il faut prévoir un nom qui sonne agréablement dans toutes les langues, ou tout au moins les marchés qu’on souhaite attaquer (et l’anglais désormais incontournable).
Prenons l’exemple de Motobecane, dont le nom est quand même très connoté « 2 roues » et « franchouillard » ; ils ont fini par changer pour un nom plus neutre (MBK). Par contre, Peugeot produit aussi bien des voitures que des scooters, des vélos et des perceuses.
Une marque pourra être connue et reconnue comme telle, mais cela pourra prendre du temps. Si elle réussit à se faire connaître, son nom facilement identifiable lui permettra de se démarquer des autres. Consécration suprême − et dangereuse ! − il pourrait être utilisé comme nom commun (comme Frigidaire ou Kleenex).
Produits
Un nom de produit peut avoir de multiples facettes.
Et si Gordon Ramsay était informaticien ?
Depuis quelques temps je ne rate pas un épisode de l’émission Cauchemar en cuisine, qui est diffusée sur plusieurs chaînes télévisées françaises de la TNT ou du câble.
Le concept de cette émission est assez simple : Gordon Ramsay, un chef cuisinier écossais renommé, vient en aide à des restaurateurs au bord de la faillite. Là où ça devient amusant, c’est que Gordon n’a vraiment pas sa langue dans sa poche ; il n’hésite pas à s’énerver très fort quand il le faut, pour faire prendre conscience aux gens qu’il sont sur la mauvaise voie.
Bon, la traduction française a tendance à édulcorer son langage. Ainsi, la phrase «I will smash this plate on your fuking head» est devenu «Je vais casser cette assiette sur ta tête de bois»…
Au fil des épisode, on peut voir des cuisiniers sans talent, des gérants à l’égo stratosphérique, des restaurants complètement vides, des engueulades à côté des clients, …
Gordon goûte les plats, regarde comment fonctionne l’organisation du personnel, étudie les comptes financiers. Il met ensuite les responsables − le propriétaire, le gérant de salle, le chef cuisinier − face à leurs lacunes, leurs faiblesses, leur fainéantise, leur désorganisation. Quand les problèmes ont été compris (au bout de quelques bonnes engueulades hautes en couleur), il met en place un plan de bataille qui permet de remonter les résultats du restaurant.
Il utilise souvent les mêmes recettes (au sens figuré du terme, désolé je n’ai pas pu m’en empêcher) d’un restaurant à l’autre, mais à chaque fois avec des résultats différents. Ce qui est vraiment intéressant, c’est qu’il met en application des principes qui tiennent plus de l’entrepreneuriat que de la restauration. Il y a beaucoup d’inspiration à trouver là pour une équipe technique.
L’étude de marché
À chaque fois, Gordon fait un petit tour dans la ville où il est tombé. Il fait attention aux autres restaurants existants, et essaye de trouver le type de restauration qui n’est pas représenté. Il regarde aussi la clientèle existante (ou ce qu’il en reste), et à partir de tout ça il invente un nouveau visage au restaurant pour lui faire trouver une nouvelle clientèle.
Cette nouvelle identité est souvent mal vécue par les patrons qui voient leurs habitudes remises en question. Le menu est complètement revu (je vais y revenir), le restaurant est redécoré, parfois même renommé. Mais ce nouveau positionnement est gagnant, et l’augmentation des bénéfices lui donne toujours raison.
Pas de productivité miracle
Il existe un grand nombre de soit-disant « méthodes », qui sont censées nous enseigner tout ce que nous avons besoin de savoir pour augmenter notre productivité de manière incroyable. Qu’ils s’agisse de livres ou de sites web, vous les trouverez sous des noms plus tentants les uns que les autres : « 101…
Ne pas faire confiance à sa mémoire
Je vais le marteler une nouvelle fois : les listes sont la base de toute organisation, qu’elle soit personnelle ou d’équipe. L’une des erreurs qu’on voit le plus souvent, que ce soit que les juniors que chez les gens désorganisés, est de faire confiance à sa mémoire. Par exemple, un jeune…
Simple GTD
Je vous ai déjà fait une introduction à la méthode GTD (Getting Things Done) de David Allen. C’est une méthode d’organisation personnelle très efficace, mais qui réclame une discipline et une rigueur constantes, qui peuvent être usantes à la longue.
Je suis tombé il y a quelques temps sur un article très intéressant du site WebWorkerDaily, qui présente une alternative simplifiée. Cette alternative ne concerne que la partie de « tri » des tâches. Il semblerait qu’elle soit extraite du livre Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent de Stephen R. Covey.
Le tri de tâches GTD
Souvenez-vous, voici les étapes imposées par le GTD, pour trier les informations entrantes (et j’ai déjà pas mal simplifié les choses) : 
Le tri de tâches simplifié
Maintenant, l’alternative évoquée sur WebWorkerDaily propose de trier les tâches suivant 4 possibilités simples :
- UI : Urgent – Important
- NUI : Non Urgent – Important
- UNI : Urgent – Non Important
- NUNI : Non Urgent – Non Important
La R&D : pour ne pas confondre développement et veille techno
Il y a quelques temps, je vous ai parlé de la veille technologique. Je vous ai expliqué en quoi c’est un élément important de nos vies professionnelles.
Je voudrais cette fois-ci vous mettre en garde contre une dérive finalement assez commune chez les jeunes développeurs, qui est d’utiliser les projets professionnels comme un terrain de jeu pour réaliser leurs expérimentations. Ensuite nous réfléchirons aux moyens de canaliser la fougue qui conduit à ces dérapages.
Les expérimentations au boulot
Il y a quelques années, alors que j’étais chef de projet, un de mes développeurs – un prestataire externe, en fait – avait demandé une demi-journée de congé pour assister à une conférence organisée par Google France. J’étais content de voir qu’il prenait à coeur sa veille technologique.
À son retour, je lui ai évidemment demandé de me faire une présentation rapide de ce qu’il avait vu. Il s’agissait des premières versions des toolkits de Google, et ça avait l’air vraiment intéressant.
Nous étions alors en train de démarrer un nouveau projet, et ce développeur était en charge de certaines spécifications techniques. Quand j’ai vu dans ses specs qu’il envisageait d’utiliser les technologies Google qu’il venait d’entrapercevoir, j’ai eu une petite discussion avec lui.
Le message tient en 2 points :
- Bien qu’absolument nécessaire, la veille technologie est une démarche personnelle. C’est à chacun de se trouver ses propres petits projets qui lui permettront de tester de nouvelles technos ou de nouveaux outils.
- Un projet mené au sein de l’entreprise répond à des contraintes contractuelles et financières. Vouloir y glisser des technologies qui ne sont encore qu’à l’état de bêta, ou qu’on ne maîtrise absolument pas, est une erreur assez grave.
Canaliser et organiser
Il n’empêche qu’il n’est pas logique d’inciter à la veille tout en la réprimant dans le cadre de l’entreprise. L’entreprise a certains devoirs de formation vis-à-vis de ses employés, il faut s’en occuper de manière raisonnée et planifiée.
La refactorisation
La refactorisation est un exercice qui devrait être maîtrisé par tous les développeurs, encadré par tous les chefs de projets et encouragé par tous les directeurs techniques.
Le refactoring, qu’est-ce que c’est ?
Derrière cet affreux anglicisme se cache le fait de réécrire du code qui a déjà été développé. Le but n’est donc pas d’ajouter de nouvelles fonctionnalités, mais plutôt d’assurer un suivi de l’existant, de faire un ménage qui en facilitera la maintenance.
Nous nous sommes tous retrouvés un jour ou l’autre devant des bouts de code sans queue ni tête, manifestement écrits à la va-vite, ne respectant aucune norme, avec une documentation périmée, sans commentaire, ou truffés de code mort. À chaque fois, nous sommes horrifiés. Dans le meilleur des cas, on se souvient des raisons historiques qui ont conduit à cela (« Ah oui, ça date du projet X, qu’on avait dû faire à toute vitesse il y a 2 ans ») ; dans le pire des cas, on va retrouver le responsable de cette horreur pour lui passer un savon.
Mais la bonne attitude, c’est d’organiser l’amélioration de ce code. Il faut garder en tête qu’on ne travaille pas continuellement sur les mêmes fichiers. Ce qu’on est en train de développer un jour sera utilisé pendant des mois voire des années sans qu’on revienne dessus. Mais au fil du temps, le code ancien devient « friable » : chaque correction de bug devient plus délicate et sujette aux bugs de régression ; chaque ajout de fonctionnalité prend de plus en plus de temps et devient plus difficile.
Je vais faire un parallèle avec la construction immobilière. Quand on construit une maison, on commence par faire les fondations, puis on monte les murs extérieurs, puis le toit et enfin les cloisons intérieures. Quand on développe un logiciel, c’est un peu la même chose ; chaque développement, chaque ajout de fonctionnalité, s’appuie sur des objets ou des librairies qui doivent rester fiables dans le temps. Il faut donc pouvoir revenir à tout moment sur n’importe quel bout de code, accéder à sa documentation, lui ajouter de nouvelles capacités, voire résoudre des bugs qui ne s’étaient encore jamais déclarés.
Parce que le jour où vous faites tomber des cloisons, vous ne devez pas devoir refaire les murs extérieurs ; et si vous ajoutez une étage à votre maison, vous devez pouvoir faire confiance à la chape de béton de vos fondations.
Comment s’y prendre
On peut découper un refactoring en 4 étapes précises. Les trois premières sont importantes et nécessaires, alors que la dernière est à mettre en oeuvre si le besoin s’en fait sentir uniquement.
FineFS, système de fichiers redondé
J’ai lancé depuis quelques temps un projet dans mon entreprise, que nous venons de publier sous licence libre. Il s’agit d’un système de fichiers répliqué du nom de FineFS.
Je vais en parler ici parce qu’il s’agit d’un projet intéressant d’un point de vue technique, sur lequel les esprits imaginatifs peuvent venir s’éclater avec nous. Mais aussi parce qu’à travers ce projet, je veux vous présenter l’univers des systèmes répartis/distribués/redondés et des bases de données à très haute disponibilité – que tout directeur technique doit connaître un minimum.
Présentation du projet
Le but de ce projet est de faciliter la création de cluster-disque. Lorsque vous avez plusieurs serveurs qui doivent accéder aux mêmes fichiers, il est toujours délicat de mettre en place une architecture satisfaisante sans dépenser des sommes folles. Et pourtant, la moindre infrastructure Web présente plusieurs serveurs frontaux, qui doivent délivrer des contenus (images, vidéos, musiques) communs. Sans compter que ces différents serveurs doivent aussi pouvoir enregistrer de nouveaux fichiers, qui doivent être accessibles à toutes les autres machines.
Il existe plusieurs moyens de mettre des fichiers à dispositions de plusieurs serveurs :
- Installer un NAS, c’est-à-dire un serveur de fichiers. Mais si ce serveur tombe en panne, plus aucun fichier n’est accessible.
- Installer un SAN, qui prend souvent la forme d’une baie de stockage redondée. Mais les prix de ce genre d’installation grimpent très vite.
- Utiliser un service externe, comme Amazon S3, qui prend en charge les aspects complexes de la gestion des fichiers. C’est souvent une solution satisfaisante pour du Web, mais qui peut induire des latences dans les accès aux fichiers, et des coûts inutiles.
- Mettre en place un système de fichiers réparti, redondé et/ou distribué.
C’est dans cette dernière catégorie que se place FineFS. Il existe déjà des solutions qui s’emploient à résoudre ce besoin, qu’on peut répartir en 5 groupes :