Loser du logiciel libre
$Version: preneurou $
licence anti gad elmaleh: fait ce que tu veux de ce livre excepté dire
que tu l’as écrit
$Version: preneurou $
licence anti gad elmaleh: fait ce que tu veux de ce livre excepté dire
que tu l’as écrit
Aujourd’hui, avec ma femme (surtout ma femme), on a payé les factures, la situation est pas bonne. Ma fille court après la chienne qu’elle a adopté ce qui me met en rogne car on a pas le pognon pour ça, mais elle heureuse.
Belle maman, parle polonais, avec ma femme, et je peux pas me concentrer, et c’est le quotidien que j’ai quand elle est pas en vacance. Justement, elle vient de partir une semaine en vacance, j’ai pu faire un logiciel libre, ou plutôt terminer un la finitions d’un logiciel commencé il y a 12 ans : yahi.
J’ai pas eu le temps de terminer cette phrase que ma femme est venu me voir pour me demander où était l’alimentation du dernier gadget inutile qu’elle avait jeté et qu’évidemment j’avais récupéré.
Pendant que le bruit et les stimuli négatifs m’entourent, j’essaie de pas taper du pied comme j’aime faire ou me pencher d’avant en arrière écoutez du rock fort ou tout ces autres tics qui me calment, car c’est ni familialement ni socialement acceptable. Et pourtant, sans je peux pas coder.
Faire du logiciel libre quand on vit dans la vraie vie c’est pas facile.
Mais pourquoi on en fait ?
Comment ?
Qu’est-ce qui nous motive ?
Tout ça sachant que si on a trouvé un bon truc un gros va arriver avec ses gros sabots pour s’approprier le logiciel et se faire du pognon avec sur notre dos sachant que le procès pour plagiat tu peux toujours te le carrer dans le cul quand t’as pas une tune. Je sais ça m’est arrivé avec pypi-stat qui a permis à un glorieux inconnu d’en tirer la gloire et les revenus.
Ce livre, c’est à propos de tout ça.
Avant de parler du développeur parlons du cycle de vie d’un projet logiciel libre fait sous python.
Voilà un rapide aperçu :
On commence par une idée qui pourrait intéresser des gens. Il faut trouver un angle d’attaque originale soit en apportant une solution nouvelle à un problème ancien, soit dans mon cas en proposant une solution ancienne à un problème nouveau.
Parfois, soyons honnête, l’envie me prend d’être polémique et ce paquet est polémique (je reviendrais plus tard sur les motivations à faire ce paquet et sur l’idée).
On code dans son coin et normalement, étant dans des conditions parfaites « ça marche pour moi », c’est l’équivalent du savant fou qui travaille sur un coin de paillasse. C’est soyons honnête le niveau où les éditeurs professionnels s’arrêtent souvent, leur valeur ajoutée étant dans le fait qu’il est difficile pour les concurrents de déployer leur logiciel.
C’est là où les non initiés pensent que le travail est fini. Que nenni, il faut passer de la phase « ça marche chez moi», à «ça marche partout».
En python on a un mécanisme de paquet qui permet d’installer les paquets de manière uniforme avec leurs dépendances grace à la commande pip qui sert à installer des paquets
Qu’on utilise une procédure manuelle (peu recommandée) ou automatique (recommandée) il faut quand un bug apparaît avoir un bout de code qui permet de vérifier que le bug a disparu.
Ce bug doit être préférentiellement lié à une entrée de bug (issue dans le jargon utilisé tel quel en français de Paris) qui permet à un utilisateur simplement de savoir en lisant dans la doc la partie changelog (journaux de modification) si il a disparu. Et à cette résolution de bug on fait correspondre un numéro de version.
Selon les conventions, on fait correspondre des incréments de numéros mineurs aux bugfix, intermédiaires aux « bris d’API », quand le code n’est plus totalement pareil en comportement, et on garde le dernier numéro pour les changements d’API majeurs.
Une API c’est le nom qu’on donne à l’interface avec le programme et ses différentes options.
« Good Enough »© correspond à une blague du joueur du grenier sur la finition logicielle qui en français se traduit par suffisamment bon.
Quand le paquet est stable, et qu’on a une documentation suffisamment bonne pour expliquer clairement en peu de ligne ce que le code peut faire, et qu’on a résolu la plupart des bugs bloquants on est «good enough».
Pourquoi «good enough» et pas parfait ? Car sans utilisateurs vous ne verrez pas tout les bugs, et vous préférez commencer avec le maximum de bugs shootés d’une balle dans la nuque, à tout le moins pour pas être ridicule.
En général, c’est la phase où vous recherchez des béta testeurs pour valider que ça marche un peu mieux que dans votre visions des tests que vous avez, et souvent « la vraie vie » vous fait découvrir des bugs.
Ça consiste à prendre son bâton de pèlerin, faire la tournée des sites qui parlent de logiciels libres et user son peu d’estime de soi à s’exposer à différents trolls dont ceux du « c’est pas PEP8 », « t’as passé le W3C validator » et autres personnes qui jugent un logiciel sur la forme et pas sur le fond.
J’admets que c’est la phase que je déteste, et je reviendrais plus tard sur pourquoi on s’inflige cette souffrance.
La gloire c’est de la vanité, ça sert à rien, mais si son projet est reconnu dans la vie d’un loser, ça donne l’impression d’avoir achever quelque chose. Pas grand chose, mais quelque chose.
Si vous avez « bien évangélisé » où que vous êtes doué dans le domaine, vous souhaitez que votre paquet soit intégré à une distribution. Le taf de mainteneur de paquet de distribution est une charge supplémentaire consistant à gérer la relation entre la distribution (debian, BSD, windows, conda…) et celui qui FAIT le paquet. On peut faire les deux. Mais c’est compliqué.
Maintenant, un quidam peut faire pkg install yahi et profiter des fonctionnalités annoncées par l’idée que vous avez eu. C’est la fin du chemin. Le logiciel est fini.
Entre la Qualité standard entreprise (j’ai forcé le trait en disant que les entreprises livrent à la va comme je te pousse, mais pas trop) et la qualité logiciel libre il y a 10 fois d’efforts en terme de temps et de travail. Le logiciel est la partie émergée de l’iceberg.
Voilà maintenant que j’ai présenté le cycle de vie d’un logiciel libre, je vais pouvoir parler de l’humain, le loser du libre qui en fait et les défis (challenge en français de Paris) que ça représente.
Si la partie ingénierie, empaquetage du logiciel est un acte de calme et de silence reposant où l’on peut se focaliser sur bâtir quelque chose, la phase évangélisation est une putain de plaie dans le cul pour les introvertis.
Comprenez bien que contrairement à une entreprise souvent le logiciel libre est développé en mode «one man army» où pour dire en français t’as pas d’amis tu fais tout (ou presque) tout seul.
Pour ce projet, il serait faux de dire que je suis seul, mais il serait menteux de dire que j’ai pas 99% des commits sur mon dos. Et je suis heureux d’avoir un ami qui m’aide (tuck que je remercie ici).
C’est le moment où l’on est forcé de prendre une pause car on est plus maître de l’horloge.
C’est le moment parfait pour écrire un livre, et c’est depuis cette phase que j’écris ce livre, dans ce moment où le doute nous étreint face aux critiques et que l’on se demande pourquoi on fait tout ça ?
Avant de revenir à comment on le fait, dans la vraie vie et les différentes catégories de sites où l’on peut poster en fonction de l’épaisseur de sa couenne, il m’est avis qu’on ne peut pas comprendre cette partie sans comprendre les motivations personnelles, et l’auteur.
Donc, expérience stressante, je vais comme parler de moi à la 3é personne.
La vie de codeur en entreprise n’est pas rose en tout cas, celle que j’ai connu.
Dire que l’on fait de la merde est un pléonasme, l’entreprise ne semble pas avoir pour but de produire, mais de fournir des positions sociales qui reflètent plus les travers de la société.
Comme certains disent, le code est politique, il reflète dans son organisation, son développement et même son ingénierie une vision sociale, sociétale dirons certains de nos communautés.
J’abuse de terme que ne connais pas en parlant de névrose. Pour moi une névrose c’est quand la main gauche fait quelque chose que la main droite réprouve. Genre, t’es pour aider les miséreux mais tu tournes le dos au squidjie qui te demande une pièce.
Je fais parti de la première génération d’«amateur» de l’informatique, celle qui a grandi en tapant sans comprendre les listing papiers en basic d’hebdogiciel (un magazine disparu sur l’informatique).
Je vais vous gâcher la fin : taper sans comprendre sert à rien.
Mes deux véritables ouvertures à la programmation ont été car à l’époque j’avais les moyens ma calculatrice programmable (une HP48) et quelques années plus tard linux (slackware).
Et j’ai découvert quelque chose de merveilleux : LA DOCUMENTATION.
En 1993 quand on installait encore linux à coup de disquette car les CDROMs étaient pas si courant, on pouvait acheter pour pas cher des ouvrages en papier bible avec tous les HOWTO linux. Et ça, ça m’a vraiment aidé.
La qualité de documentation qui m’a permis de devenir autonome, auto-didacte je dirais, est ce que je préfère. De nos jours, pour cette raison, je préfère installer freeBSD sur mon serveur car les pages de manuels sont bien écrites et suffisantes.
La qualité « logiciel libre » est devenu le standard que je voulais atteindre au moins une fois dans ma vie. Sur ce chemin, j’ai fait de nombreux essais et pour l’instant n’ai connu que des échecs.
Vous me direz pourquoi persévérer : t’es pas doué, t’es pas doué, lâche l’affaire et arrête de perdre du temps et des points de santé mentale que tu pourrais consacrer à ta famille. Et je suis d’accord.
Néanmoins, j’arrive pas à me laisser compter « KO ». J’aimerais toujours faire du « beau code » et « en vivre ».
Suite à mon dernier taf où je me suis fait harceler (et menacer physiquement (quelle nouveauté)) je suis en dépression, et il paraît que pour sortir d’une dépression, il faut avoir « un projet ».
Donc, sans mentir, je mets mes tripes dans mon code et aussi de la critique technique, des processus et de l’ingénierie.
Vous voyez-tu (oui, j’aime pratiquer le voutoiement), c’est comme le boxeur en train de se faire rincer sur le ring, qui a un genou à terre, qui est compté par l’arbitre, mais va pas jeter l’éponge, se relever et y retourner en visant quand même de gagner son combat. Pourquoi ? Parce que je suis un teigneux.
Comme par exemple, je peux pas saquer les scrums meetings et l’hypocrisie du développement agile. Coder sans est un vrai plaisir et violer le maximum de règle de l’agile (non je ne mettrais pas de lien vers cette daube dont on peut lui faire dire ce que l’on veut) est une volonté délibérée.
Pas de user-story, pas de planning, pas de rétro-planning, de toute façon, quand on est seul ça fait pas de bon sens.
La chose important dans « logiciel libre » n’est pas tant qu’il libère son utilisateur, qu’il libère celui qui code de normes étouffantes et inutiles. Pouvoir ne pas faire comme en entreprise et délivrer est une propagande par le code contre tout ce qui ne va pas en entreprise en ce qui me concerne.
C’est un moment cathartique pour moi pour oublier tout ce qui m’empêche de livrer avec la qualité qui me sied. Et c’est pour ça que je vise le graal du paquet de distribution, pour me prouver à moi même que je ne suis pas fou et que ma critique politique de l’entreprise donne bien un résultat pertinent et valide.
Je vise l’uppercut vicieux avec la propagande par le fait dans la mâchoire des pratiques d’entreprise.
En logiciel libre, on conseille de toujours partir pour écrire un logiciel de partir d’un problème que l’on a et pour lequel on cherche une solution. De gratter là ou ça démange (scratch an itch en anglais).
Bon, là, le problème a disparu il y a 12 ans quand j’ai émigré au Canada et où j’ai tellement avancé mon salaire à mon employeur avec l’aide d’un franco que je suis tombé dans la misère.
Faîtes moi confiance, une fois que l’on tombe dans la misère c’est dur de simplement redevenir pauvre.
Je distingue le pauvre celui qui ne manque de rien mais ne peut se payer le superflu, du miséreux dont le manque de caillasse fait que sa santé se détériore, l’empêchant d’utiliser son seul capital, son corps pour devenir salarié.
Donc, quand j’étais pauvre je faisais de l’auto-hébergement, ce que je considérais être mon portfolio de sysadmin établissant ma crédibilité à être sysadmin.
Mon serveur était un centrino pas péchu délibérément ; mon crédo a toujours été de faire le max que l’on peut avec le moins possible.
Il était une fois, un jeune moi à la fac de Paris VI qui suivait après moults échecs les conseils de sa grand mère : ne cherche pas à être bon, fait juste le minimum pour passer. Grâce à ses conseils, mes notes se sont améliorées, mais il y eût dans mon histoire académique une exception ; le cours d’assembleur.
Durant ce cours, j’avais un voisin, fils d’ingénieur, qui un jour m’a expliqué que je ne pouvais pas savoir coder car je ne possédais qu’un ordinateur d’il y a 2 générations ; un 486DX2 66Mhz avec bus VLB et lui un pentium PCI 90Mhz SMP. Et que quelque part, j’étais juste une daube.
Ça m’a eût énervé.
Et j’ai décidé dans cette matière d’investir un peu d’énergie. C’est d’ailleurs comme ça que je l’ai poutré en terminant le premier notamment grâce aux TPs, en prenant le même TP que lui (manipulation de bras de robot) et en le ridiculisant avec un code largement plus simple qui marchait le jour de la livraison.
Je peux pas vous dire comment ça m’a fait du bien. Et depuis, je regarde avec circonspection les tenants du « c’est pas grave de pas savoir bien coder, la machine peut compenser ».
À l’époque pour le fun j’ai développé une librairie qui donne des propriétés d’algèbre linéaire aux dictionnaires python
Et en pratiquant la librairie, je m’étais rendu compte qu’elle était pratique pour agréger les statistiques en utilisant moins de code.
J’avais aussi la pratique des regexps nommées qui transforme le résultat d’une regexp en dictionnaire.
M’est alors venu l’idée simple il y a 12 ans de faire une librairie de regexp de journaux de serveurs, pour en agréger les statistiques et j’ai jeté sur un coin de table un serveur flask pour servir les vues par pays sur une carte, les histogrammes et les séries temporelles.
Et j’étais fier que ça tournait sur mon intel celeron sans mémoire cache.
Puis récemment, mon ami tuck m’a dit, j’aimerais faire du logiciel libre, t’as pas un projet sympa qu’on pourrait livrer ?
Vu que je suis psychotique d’après 3 de mes anciens patrons, j’ai peut être entendu des voix, mais peu importe : un truc me chagrinait sur ce projet : LE SERVEUR FLASK.
Donc, je m’ai dit livre un agrégateur de statistique de serveurs (serveur que je n’ai plus, trololol, ça aide pas à développer) en … défi … roulement de tambour … en une page HTML qui contienne tout.
Si une chose me casse les bonbons en code moderne, c’est les dépendances inutiles.
En tant que sysadmin d’entreprise j’en ai déployé des solutions énergivores et complexe basées sur de multiples couches (grafana, qui terminent dans le cloud pour faire des stats webs par agrégations.
Yahi est littéralement ma réponse personnelle à ce délire de couches complexes qui s’empile pour au final un rendu qui ne sert que la vanité. Un truc qui transforme les journaux web de base en une série de visualisation « good enough »© en UNE seule page web hébergeable sans avoir besoin d’invoquer npm, react, vue, grafana et tutti quanti.
J’avais envie de revenir à un truc de base, simple en tentant en plus en tant que développeur de ce que l’on appelle le « back » (la partie arrière d’un site web qui concerne l’authentification, l’autorisation, le rendu des bases de données, les interactions serveurs) de faire un coup de pied de la mule aux développeurs « front » (la partie visible qui attire le regard) en faisant le plus possible de code moi même sans cadriciels.
En conclusion, l’idée en faisant ce code n’était pas tant de délivrer un résultat que d’interroger les pratiques modernes de code en entreprise qui veulent que tout devienne chancre de dépendances, énergivores. Parce qu’il faut pas se leurrer, un framework, une infra cloud en plus, c’est du CO2 inutile qui est inutilement généré, et quelque part, vu que c’est inutile : ça m’énerve. Donc, j’ai mis beaucoup d’effort à tenté de faire le moins de code possible.
Ce code ne parle pas de statistiques de serveur de page web, mais de la frustration intrinsèque à faire des usines à gaz qui sont tout le contraire de pour moi ce que devrait être la programmation : être le moins dispendieux en ressources (librairies, CPU, mémoire) pour être le plus accessible à tous possible.
C’est un cri du cœur face à ma névrose d’entreprise, je fais le contraire de ce que l’on nous incite à faire pour me libérer de cette croyance que je trouve aliénante et débile.
Heureux qui comme Ulysse quitte Nausicaa non en la maudissant, mais en la bénissant
– James Joyce
Il faut savoir dans la vie garder une attitude positive face à ses expérience pénibles dit James Joyce, et préférer les regrets aux remords.
En ceci, j’ai peut être oublié que fût un temps, ma vie fût faste, j’étais même invité à me bourrer la gueule gratis à la fête de l’Huma pour parler logiciel libre entre «happy few».
Je faisais parti des gens qui étaient invités à parler du logiciel libre et participait à une magazine libre à plusieurs mains « libroscope » qui a aujourd’hui disparu faute de tune pour payer l’hébergement.
C’est un des trucs de notre époque, nos mémoires ne restent contrairement au papier que le temps et l’argent que l’on peut mettre dans le jukebox des OPEXs (coûts d’opérations/hébergement).
Tu tombes dans la misère et les 48€/ans d’hébergement + 48€ de noms de domaines ne sont plus une priorité. Libroscope a disparu du web, son aventure aussi. C’est même impressionnant pour moi qui avait écrit des articles sur le sujet que le numérique était une menace pour la mémoire d’en être témoin de première bourre.
Au moins, les livres, je les imprimes, je les relies mal et je les stocke.