Sémantique mon amour

Il y a des jours où les conversations sereines avec des arguments posés, opérées dans le respect des intervenants, semblent être d’une autre dimension. Mais pas aujourd’hui.

Mon moulin à vent du jour ? Éviter les accumulations d’anglicismes dans une phrase technique. Une exclamation du genre « C’est bon ! J’ai pushé le commit dans ton repo, tu peux merger le fetch, mais n’oublie pas de vérifier le diff ! » est simplement du miel à mes oreilles. Les poètes peuvent se rhabiller : les techniciens prennent la relève. Et puis, j’aurais fière allure lorsque le soir, fort d’une journée harassante de travail, je me retrouverai au New Pip’s à narrer cette belle anecdote. Alors, la vertu des femmes s’effondrera, un vieux cousin Togolais viendra m’apporter en personne les millions de dollar qu’il m’a promis sur internet, et alors je n’aurai nul besoin d’utiliser « les trois questions qui les font toutes craquer » pour finir ma soirée en beauté.

Non mais sincèrement.

On est sûr, nous, informaticiens, de rester toujours en-deça de la côte de popularité des assistants expert-comptable avec un jargon aussi sexy. J’admet que tous les gens « du métier » auront compris. C’est bien le but d’un jargon. Ce n’est d’ailleurs pas en traduisant les concepts en français qu’on se fera mieux comprendre du quidam, ça reste un jargon : il faut avoir des notions de gestion de version pour comprendre. Non, c’est l’esthète qui s’exprime : cette phrase est ultra moche, bancale, on ne dirait même pas de l’Espéranto. Les juristes avaient eu le courage, en leur temps, de parler tous français dans les documents officiels lorsque la France était la référence en terme de justice. Alors, que diable, parlons tous anglais au travail. Reconnaissons cette victoire des bretons et rendons-leur hommage, plutôt que de bricoler des phrases sans queue ni tête.

Le problème que me pose, au fond, ce genre de phrase, c’est de faire croire que l’on maîtrise ce que l’on dit alors que l’on n’a pas cherché à faire l’effort de transposer les concepts manipulés dans la langue qui nous est familière, c’est-à-dire, a priori, votre langue maternelle, fut-ce le français ou le viêtnamien, ou que sais-je encore. La traduction, c’est l’appropriation. Si celle-ci s’avère difficile ou peu satisfaisante, alors il ne faut pas s’y attacher et préférer le terme original. « thread » et « pool » en font partie à mon sens. Mais il n’y a pas lieu de dire « commit » plutôt qu’ »altération », ou « pushé » plutôt que « publié ».

Dans le cadre littéraire, réaliser une bonne traduction d’une œuvre n’est pas chose aisée, mais peut valoir le coup. Je ne vois pas pourquoi il faudrait systématiquement renoncer à traduire les concepts informatiques pour lesquels la transposition du concept initial est pleinement satisfaisante. Il faut bien entendu connaître le terme original pour pouvoir continuer de progresser et comprendre les publications techniques. Je parle juste d’essayer de traduire, même pas forcément d’adopter le terme francisé en toute circonstance. De faire un effort de compréhension.

Sinon, on fini par arriver à des bijoux de sémantique comme le panneau suivant : « ACCES INTERDIT A TOUTE PERSONNE NON AUTORISEE ». Cette lapalissade me laisse sans voix, et je ne parle même pas de l’accentuation partie pisser. Mais c’est tellement plus informatif que « ACCÈS RESTREINT » ! L’industrie du pétrole a de beaux jours devant elle tant que les facteurs de panneaux continueront de sortir d’HEC (ou seront d’anciens ingénieurs système reconvertis)

Cent fois sur le métier remettre son ouvrage

Un pas en avant, et un pas en arrière, c’est toujours de sous dépensés pour rien.

Le Régent a une certaine vision du développement logiciel. Dans cette vision, submergée de papillons et de cornes d’abondance, la logique a fait place à la magie.

Comment être sûr de planter un projet :
- un Chef sans envergure incapable de toute décision ;
- un Régent qui trouve tout trop cher, et donc incapable de lâcher un centime ;
- des Esclaves tellement fouettés qu’ils font tout a minima ;
- un Client qui aurait pu être Chef s’il ne faisait pas partie d’une autre société tellement il ne sait pas ce qu’il veut.

Encore un exemple récent.

Le code est gelé depuis trois semaines, les documents finalisés commencent à sortir. Le Chef a l’excellente idée de se demander, si, finalement, tous ces petits problèmes mineurs le sont vraiment. En effet, il est bien temps ! Après tout, pourquoi les réunions hebdomadaires de trois heures tenues depuis deux mois devraient le rassurer (ou, accessoirement, servir à quelque chose) ?

Après quelques jours d’un effort titanesque, le Chef a retrouvé le nom du logiciel, le chemin d’accès à la base de faits techniques, et les gens du SI lui ont même rappelé ses identifiants, fournis quatorze mois plus tôt. Qui aurait pu deviner que tout cela ait pu servir un jour ? Le Chef peut enfin obtenir la liste des problèmes connus : pour cela, il envoit un mél à un Esclave pour qu’il la lui fournisse fissa.

Aïe ! quel malheur ! mais quelle est donc cet intitulé qu’il trouve sous Excel ? « FT AB13-22 (dit « pan dans ta face ») : problème flou qui fait peur ». Frôlant l’apoplexie, il trouve le temps d’émettre un ordre copieux demandant impérieusement une correction immédiate de ce problème extrêmement sensible. Il peut rentrer sereinement se reposer après ce dur labeur : nous sommes quand même mardi, il est déjà 15h31.

Un Esclave prend le relais. Ne comprenant rien à la description du problème, il peut bien entendu fournir une analyse pertinente sans rien connaître du contexte ni pouvoir rencontrer l’auteur, qui a été dégraissé deux jours plus tôt. Tirant à pile-ou-face-ou-bleu, il explique « il suffit de supprimer une fonction ». Non mais. Encore une victoire de canard : cinq heures de facturées sans coup férir.

Un autre Esclave poursuit. Il supprime la dite fonction, tente de retrouver les tests à passer, qui sont au mieux soit obsolètes, soit pas les bons. Par exemple, la validation des centrales inertielles consiste à vérifier si la température anale du chat de la voisine est bien inférieure à celle de l’ébullition de l’eau sur Jupiter. La réponse est bien évidemment « peut-être », la modification est livrée, le problème considéré corrigé.

Bon, c’est sûr, il faut reprendre une nouvelle fois les documents qui avaient failli ré-émerger du circuit de signature pour les amender, mais quelle satisfaction de savoir le travail bien fait !

Une semaine se passe, le Chef revient tout juste de son repos, mais tout n’est pas bel et bon : depuis que le problème FT AB13-22 a été corrigé, de nouveaux soucis se sont fait jour. D’aucuns diraient que c’est pire qu’avant. Sentant que le moment est idéal pour affirmer sa position en éblouissant ses collaborateurs de tout son savoir, sans omettre d’asseoir un peu plus son charisme animal, le Chef convoque en réunion tous les Esclaves et déclame :

« Bon, ben, tant pis. On revient en arrière. Euh. C’est balistique. Ha ! oui, au fait, bonjour. »

Fin de la réunion. Ça va être un peu compliqué. C’est un peu comme si vous achetiez une planche dans un magasin de bricolage pour monter une étagère, et qu’au moment de passer à la caisse, le responsable du magasin interrompait la vente pour vous annoncer : « désolé monsieur, nous ne pouvons vous vendre ce produit, car nous allons reconstituer l’arbre dont elle est issue afin de le replanter comme si de rien n’était. Les enfants aimaient y faire de la balançoire. »

Même avec la meilleure volonté du monde, on ne peut pas retirer en deux coups de cuiller à pot une vieille modification, d’autant plus si depuis d’autres strates d’améliorations/régressions se sont basées dessus. Faites livrer deux containers d’huile de coude. Paraîtrait qu’ils n’en ont pas au service logistique. Faudrait songer à les virer ceux-là aussi.

Tags: ,

Fedora – Déployer un dépôt git

ou comment j’ai déployé git avec mes ouatmille machines pour travailler tout seul sur mes projets.

Principe de fonctionnement

Vu que je suis le seul développeur, je vais à la fois être le développeur et l’intégrateur. Alors, on ne va pas s’embêter : un dépôt accessible en lecture écriture sur le serveur, et une foultitude de comptes autorisés.

Configuration du serveur

Comme l’explique très bien la documentation de git, deux protocoles de communication sont utilisés :

  • le protocole git:// pour les accès en lecture ;
  • le protocole ssh:// pour les accès en écriture.

La machine hôte de votre projet doit donc activer ces services, et autoriser les connections idoines. Ce qui revient à :

  • pour git:// : installer le paquet git-daemon, ouvrir le port 9418 et activer les services git et inetd dont il dépend ;
  • pour ssh:// : installer le paquet openssh-server, ouvrir le port 22 et activer le service sshd.

On va aussi créer un pseudo-utilisateur, qui hébergera les dépôts git sur son compte, qui, par un heureux hasard totalement fortuit, sera également le répertoire système tel que configuré dans /etc/xinet.d/git

# useradd -d /var/lib/git -N -M -s /usr/bin/git-shell git
# mkdir /var/lib/git/.ssh
# chown -R git /var/lib/git

Identification des participants

Chaque machine depuis laquelle je compte éditer le projet doit être identifiée (c’est surtout valable pour les accès en écriture). Le livre « Pro git » explique très bien comment générer une clef pour chaque participant.

host$ ssh-keygen
host$ scp ~/.ssh/id_rsa.pub server:/tmp/host.id_rsa.pub
server# cat /tmp/host.id_rsa.pub >> /var/lib/git/.ssh/authorized_keys

Initialisation du dépôt

Créons donc un projet, à partir de rien.

cd /var/lib/git
git init --bare MonProjet.git

Visibilité du dépôt

Le projet est donc accessible via deux URL :

  • git://server/MonProjet.git pour les accès publics en lecture uniquement (via git clone);
  • git@server:~/MonProjet.git pour les accès privés en lecture (toujours via git clone) et en écriture (via git push).

Tags: ,

De la qualité naît la satiété

Les techniques de néo-management en vogue depuis les années 80 cherchent à tout prix à faire du personnel une ressource comme les autres. C’est-à-dire que les travailleurs doivent être aussi souples et interchangeables qu’une gomme ou un boulon. Dans le domaine du développement logiciel, une méthode pour arriver à cet objectif discutable est de focaliser le travail des développeurs non plus sur le produit demandé par le client, mais sur l’outil de production qui permettra effectivement de satisfaire le client mais aussi les prochains, et à moins cher que si cet outil n’existait pas (mais facturé autant, bien entendu) Ainsi, on n’a besoin de moins en moins d’experts techniques et de plus en plus de travailleurs moins qualifiés pour un produit de qualité équivalente. C’est le progrès, et bien logique. Un compilateur ne fait ni plus ni moins que ça : il génère du code assembleur que peu maîtrisent à partir d’un langage plus facile d’accès, et donc pour lequel on trouvera plus de main d’oeuvre moins essentielle.

L’intéressant là-dedans, est de voir la communication associée du middle management (Petits Chefs en français) pour justifier des dépassements financiers ou le génie dont a su faire preuve l’entreprise. Enfin, plutôt dont ils ont su faire preuve, quand on les écoute. La métrique fondamentale, c’est le nombre de lignes de code générées.  Plus il y en a, mieux c’est. Forcément : l’investissement dans le coût de développement de l’outil de génération est d’autant mieux amorti qu’on s’en sert beaucoup. Et cela rend encore plus judicieux l’investissement initial. Toutes les lignes que l’on génère, c’est autant de lignes que l’on n’a pas à écrire à la main, donc de développeurs à payer. Générer des lignes, c’est améliorer la productivité des équipes.

Tout ceci est complètement vrai, toutes choses étant égales par ailleurs. Ce qui n’est bien entendu pas le cas ici. On oublie (volontairement) au moins une chose : la qualité du code généré n’est pas la même. Pire, elle n’est pas contrôlée sur le long terme. L’architecte a prévu un schéma de génération, qui se défend totalement lors des premiers usages de l’outil. Plus le projet avance, plus il y a de choses à faire entrer dans le générateur, et donc il en sort de plus en plus de code. Peut-être que le schéma de génération initial ne s’applique plus quand on génère trois fois plus de code qu’initialement prévu ? Tout le monde s’en moque. Je dirais même qu’il ne vaudrait mieux pas que ça se sache. Ça fait déjà quatre mois qu’on dit générer 85% du code, on va pas faire s’effondrer cette métrique en dépensant des sous qui plus est ! Et l’équipe serait mécaniquement moins productive. Non, non et non, le schéma de génération, aussi mauvais soit-il devenu, ne doit pas être amélioré.

Aussi malhonnêtes soient-ils, je n’ai jamais vu aucun Petit Chef demander à ce que l’on dégrade encore plus le schéma de génération pour générer 200 lignes quand on en générait 100. Pourtant cette stratégie ferait clairement leur beurre. Mais sont-ils simplement capables d’avoir cette (une ?) idée ?

Tags:

Patience menée à bout se tourne en fureur

Ha ! la douce joie de l’informatique embarquée ! S’il est une chose qui constitue indéniablement un régal de fin gourmet, c’est bien la phase de test d’un projet d’informatique embarquée, comprenez ici « un logiciel approximatif qui tourne sur du matériel obsolète ». Le test est le moment d’assister à nouveau à une bonne pièce de théâtre, un classique parmi les classiques, dont vous connaissez tous les enchaînements, mais pour autant, on ne s’en lasse pas. Allez savoir ? Peut-être que cette fois, le jeu des acteurs sera légèrement différent, l’interprétation des didascalies plus libre ?

Plantons le décor pour ceux qui n’ont jamais vu la pièce : un gros projet industriel, avec au moins une soixantaine de développeurs. Le matériel est une boîte en laiton avec des circuits en graphène et un processeur quantique multicore de l’entre-deux guerres, on ne va pas pouvoir en acheter beaucoup. Comme il va falloir faire plein de tests mensongers rapidement, on ne va pas attendre que les soixante développeurs aient accès à ce Graal technologique. C’est parti pour faire des tests sur simulateur ! Il est bien entendu hors de question d’acheter autant de licences (hors de prix) du simulateur du matériel exotique sur lequel devra tourner ce nouveau projet. Le Régent fait l’aumône au Chef de quelques piècettes pour en installer cinq sur des postes dédiés. Cinq moyens de test non représentatifs, c’est toujours moins cher qu’un matériel cible de toute façon non encore stabilisé.

Acte I : Jusqu’ici, tout va bien

Par le jeu des indisponibilités synchronisées des documents de spécification, peu de développeurs avancent, et les rares qui ont réussi à coder quelque chose ne se bousculent pas pour tester. Il faut les comprendre : au début, il ne s’agit pas tant de tester leur code sur le simulateur que de déverminer l’environnement de test multi-paradigme ultra-bancal.

Cependant, doucement mais sûrement, chacun décide de cacher sa flemmardise derrière son impossibilité à avoir accès au moyen de test. C’est bien la seule raison valable pour ne corriger aucun des bogues détectés jusqu’ici (et comment, d’ailleurs ?)

Acte II : Organisons le chaos, ou l’explosion nucléaire

Qu’à cela ne tienne, le processus-roi vient à notre rescousse ! Une bonne âme (autrement dénomée Couillon Sidéral par tout le reste de l’équipe) va être désignée volontaire pour produire une planification hebdomadaire. Chacun mél-bombera sa boîte à lettres de son besoin pour la semaine suivante, de préférence en huit exemplaires successifs contradictoires, et, grâce à un tableur de qualité (autrement appelé Boulier Numérique) le Couillon Sidéral tentera de répondre au mieux au besoin de tous.

Comme l’entreprise est ouverte de 8h du matin à 20h le soir, le Couillon Sidéral décide d’occuper toute cette plage horaire pour organiser l’accès aux moyens de test, et là, magie ! la demande de chacun est satisfaite. Tous les bogues vont pouvoir être corrigés rapidement, et le client satisfait. Le Chef est félicité, le Régent augmenté.

Acte III : Vers l’infini et au-delà, où la sonde anale est bien en place

De façon assez étonnante, et malgré cette planification exemplaire, le projet continue de prendre du retard, et les bogues ne sont toujours pas corrigés. Quelques voix se font entendre pour réclamer de travailler le samedi, ou en horaires étendus, comprendre à partir de 6h du matin et jusqu’à 22h le soir. La réponse est cinglante : « Tant que tous les créneaux bancs ne seront pas alloués, il est hors de question d’envisager de telles extrêmités ». Méphisto, le chef des sous-traitants, qui a tout à gagner à facturer du travail durant des horaires farfelus, car mieux rémunérés, adopte la stratégie du pire et réclame deux fois plus de créneaux banc qu’auparavant, sans consulter ses équipes.

Le Couillon Sidéral se trouve bien embêté : il doit faire correspondre une demande de dix bancs pour cinq disponibles. Profondément juste, il adopte une belle règle de trois, qui va pousser tous les développeurs à sur-évaluer leurs demandes pour espérer obtenir ce qu’ils auraient demandé en temps normal. Bientôt le Couillon Sidéral doit gérer quinze bancs virtuels, puis vingt, etc. Le Régent refuse obstinément d’acheter de nouvelles licences pour des moyens de test supplémentaires. Mais le projet n’avance toujours pas.

Le Chef adapte alors sa réponse aux demandes incessantes de travail en horaires étendus/décalés/esclavagistes : « Tant que tous les créneaux bancs ne seront pas occupés, il est hors de question d’envisager de telles extrêmités ». Car le Chef a bien constaté que les bancs de test ne sont occupés que de 10h à 11h30, après le café et avant le repas, puis de 14h30 à 16h. Il semblerait que les développeurs aient aussi d’autres problèmes, certains parlent même d’une hypothétique vie sociale, ce qui est regrettable, intolérable, et fort dommageable pour le projet. Le Chef est dé-félicité. Le Régent récupère son bureau pour y faire installer un buste à sa gloire offert par la Direction Financière.

Acte IV : La débâcle

Méphisto motive ses équipes en leur faisant miroiter des bons-cadeaux Régali et des perspectives d’évolution de carrière insoutenables. Les plus jeunes développeurs se font avoir, mais respectent leur engagement en arrivant à 9h45 et en repartant à 16h03 ; qui sait combien vaut leur âme en bons-cadeaux ?

Dénouement

La démotivation est patente, le projet est fichu, mais officiellement ce n’est la faute de personne :

  • Le Chef a alerté depuis longtemps sa hiérarchie sur l’inadéquation entre les 800 bancs de test nécessaires pour ses 60 développeurs et les 5 malheureuses licences qu’il avait à disposition. Les données collectées par le Couillon Sidéral sont sans appel ;
  • Le Régent a brillament réussi à tenir les coûts, il est donc bombardé auprès du Roi pour déployer plus largement tout l’éventail de ses compétences ;
  • Les développeurs ont montré leur bonne foi en proposant de s’immoler par le feu en offrande à Râ si ça pouvait faire avancer le projet.

Méphisto, lui, propose de nouvelles missions à ses développeurs à 250 km de là. Ils n’ont qu’à faire comme lui ; s’acheter une nouvelle voiture. Malheureusement, Régali n’en fait pas.

Tags: ,