Loser du logiciel libre
licence anti gad elmaleh: fait ce que tu veux de ce livre excepté dire
que tu l’as écrit
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.
Dans les choses que j’ai eu faites avec mes complices (r4f, tpi, antoine) il y a eu la direction de thèmes aux RMLL (Rencontres Mondiales du Logiciel Libres), lieux où RMS (Richard Maximus Stallman) himself m’a eu traité de démon pour avoir dit que je faisais du logiciel libre non par « convictions idéologiques » mais pour le fun.
Notre thème était « le libre au delà du logiciel ». Si vous cherchez mon nom il a été effacé sans citation après que j’ai eu déplaît à quelques obscures associations du libre. Il paraît que j’étais pour certains un « stalinien » pour d’autre « une petite bite ». Pour des gens qui respectent la propriété intellectuelle, j’eus aimé qu’ils respectent à minima le droit de paternité.
Mais, je ne maudirais pas ma déchéance de ce milieu. L’extraversion nécessaire à l’exercice n’étant pas quelque chose qui forcément m’aidait à montrer le meilleur de moi même.
Parlons des bons cotés.
Mis à part les confs où l’on était invité en Savoie, à Bourges, Metz et ailleurs (ce qui était chouette), il y avait aussi des rencontres sympa.
J’ai eu l’occasion de boire des verres avec framasoft et de rencontrer des devs du libre, comme ceux de Spip sur lequel tournait libroscope ou Aymeric Moizard (ANTISIP).
Aymeric m’a dit un truc qui m’a marqué, et m’a changé : le logiciel libre il y a ceux qui en parle, et ceux qui en font, et c’est pas les mêmes.
Je devais ma situation de « privilégié » à avoir fait parti des premiers codeurs à investir les boîtes du libres de l’époque et j’étais au centre de l’intelligentsia, là où l’influence se construisait.
Mais du point de vue développeur, même si j’avais quelques projets sous le coude pour télécharger des images de nudes sur NNTP ou d’aide à la drague sur meetic, disons que mon code était de qualité professionnel. Je n’avais pas encore franchi l’étape de devenir un « vrai dev libre ».
Une autre rencontre qui m’a marqué quand j’avais 10 ans était monsieur Souillot, qui nous a appris à faire du cyclotourisme. Il était officier de police judiciaire, mais soupirait que notre société ne nous permettait pas d’avoir plus d’une vie dans une vie.
De tout reprendre à zéro pour tenter de voir le chemin qui nous plairait.
Et consultant, vendeur de boniments était pas le truc qui me plaisait le plus. En plus j’aimais pas trop les gens que ça obligeait à fréquenter n’étant pas très versé en politique et diplomatie.
J’avais envie d’aller faire ce que je respectais : faire du logiciel libre et non plus en parler.
C’est comme ça que sur le tard, j’ai décidé d’arrêter les projets potaches, voire malaisants pour me mettre à coder sérieusement comme je pensais que ce serait bien de le faire. Un peu comme mon grand père tailleur de pierre qui n’était pas fier de son métier, mais de montrer des photos de ses « œuvres ». J’avais envie comme lui de montrer « mon art », une manière de faire différente « de la norme d’entreprise » qui me semblait plus inspirante.
Et, soyons honnête, malgré les galères, je ne le regrette pas.
Depuis 2012, date où j’ai commencé à me mettre sérieusement à faire des paquets python il y a de l’eau qui coulé sous les ponts.
Et l’on peut se demander pourquoi j’ai pris une semaine de ma vie pour faire un tunnel à finaliser un vieux projet.
J’avais des tas de vieux projets sur lesquels j’aurai pu investir du temps :
En fait, mon projet préféré c’est archery. L’utilisation de trait pour surcharger les opérateurs +, -, *, / pour les dict en python et en faire des vecteurs de fait. Ça livre de base les cosinus similarités et la notion de norme pour les dict.
Et il se trouve que yahi était une preuve de concept de l’idée.
Si j’avais mieux testé il y a 12 ans j’aurais vu qu’il manquait un fichier pour l’installer avec pip, trolololol.
Le « troll » dans yahi est que l’agrégation tient en UNE ligne qui utilise archery :
Quand j’additionne deux dictionnaires l’un à l’autre, évitant en python de vérifier que la clé éxiste, la créer et SI elle existe additionner pour chaque clés les résultats. Je suis fier d’archery, et yahi est un écrin autour d’une bête ligne de ce code.
Et ça c’est archery à l’œuvre. Les 300 lignes autour, c’est de la doc, du sucre, des « helpers » (aides) et de l’enrobage.
C’est la différence entre du code d’entreprise où finalement on valorise LA ligne de code, et le code libre où l’enrobage, la documentation, les tests importent.
Après 13 ans, j’ai vu le problème à dépendre de librairies externes ; les librairies javascript hors de celle de google pour la cartographie ne marchaient plus. Un peu comme libroscope avait disparu, mais dépendances avaient disparu aussi, et je me suis dit « crotte », t’avais même pas besoin de les mettre à jour, si seulement t’avais gardé une version figée de l’époque t’aurait pas eu ce problème.
Et puis il y avait flask aussi qui était à la mode à l’époque et dont heureusement je n’utilisais pas de module car la plupart d’entre eux n’ont pas été mis à jour, et je me suis dit, si seulement tu dépendais pas de flask tu prendrais encore moins de risques.
J’ai eu du flair pour une chose, le mode de format de journaux « Apache log combined » est devenu le standard de fait, Common Log Format pour apache et nginx les deux serveurs de page web les plus courant laissant la partie agrégateur de démo (speed_shoot) toujours fonctionnelle à ma grande surprise.
Mon ancien moi avait été sympa, me laissant un framework de test, un de doc et suffisamment de doc pour reprendre le code là où je l’avais laissé sans avoir à ni réinventer la roue, ni me replonger dans le code source.
À partir de là, j’avais mon approche dite « top down » (du haut vers le bas), la grosse image qui me permettait de conduire les petites modifications du bas vers le haut (« bottom up »). Et qui allait guider un projet que j’évaluais en temps entreprise à un mois homme et qui m’a pris pour l’instant une semaine homme en négligeant tout le reste.
Sans fin, sans budget, il n’y a pas de mode projet qui tienne. Et même en tant qu’amateur on est limité. Il est important de cadrer et estimer (en hésitant pas à sur-évaluer la charge) le temps que l’on investit et la durée que l’on a. Sinon, on court vers le cycle « burn-in » (phase maniaque), « burn out » (phase dépressive).
Il est encore plus important quand on est responsable de soi et qu’on développe solo de faire attention à sa santé mentale, et de bien se cadrer.
Le gestionnaire de version de code, est le meilleur allié du codeur.
En l’occurrence, j’ai honte j’utilise github, et non un outil moins problématique comme sourcehut.
Mis à part que microsoft travaille pour l’immigration américaine qui a des relents fascisant ou pour la défense, j’ai vécu l’épisode traumatisant en logiciel libre de l’épisode sourceforge.
Loin dans le temps, une entreprise qui se voulait bienveillante offrit les premières forges intégrées de développement. L’ancêtre de gitlab et github.
La vie y était merveilleuse, et dans notre inconscience à l’époque nous miment nos projets comme un seul homme sur cette plateforme. Quelques grognons prévinrent (GNU/savannah) que ça allait nous péter à la yeule cette mono culture, et qu’on se trouverait bien con le jour où la forge changera de licence ou de business model. Surtout, que nos projets à héberger représentaient pour ceux qui avaient comme profession l’hébergement un montant substantiel en entretien des serveurs et achat de bande passante.
Nous ne les écoutâmes pas, et l’hiver venu fûrent forts dépourvus.
La morale de cette histoire, c’est que la monoculture des outils et plate-formes surtout est fort périlleuse et est comme une épée de Damoclès au dessus de nos têtes. Souvenons nous que les iraniens et russes sont bannis de github … ce qui est fort problématique.
En une semaine de temps, je n’ai pas vu la fenêtre d’effort disponible pour migrer. Par contre, je me suis fait un serveur de backup git où je double commite mes modifications, et aussi je partage préférentiellement le lien non vers github mais pypi qui est le lieu où l’on stocke nos modules pythons finis et qui sert de base à pip.
J’ai juste un doigt d’intégration hors git pur avec github : la file de ticket.
Quand je commit avec le message fix #numéro, le commit dans github pointe vers le ticket et le ticket est fermé.
C’est la fonctionnalité que j’utilise le plus.
À chaque fois que je code ou vois un problème qui n’est pas mon tunnel de concentration actuel, je m’ouvre un ticket avec juste assez pour que ma mémoire sache de quoi ils s’agissent. Et c’est ma méthode de bourrinage dans l’approche « bottom up » bourrin : écrire des tickets et les fermer jusqu’à disparition des tickets.
Ensuite, je peux lire ce que j’ai mis dans les tickets pour faire le journal de modifications (changelog) et liés aux étiquette de versions qui correspondent (à peu près lol) aux versions que je pousse sur pypi.
C’est une approche « rinse et repeat » (répète jusqu’à plus soif) qui a fait ses preuves.
Vous pouvez voir sur les tickets que j’ai pointé qu’ils sont volontairement concis même quand ils résultent dans des gros changements.
Alors distinguons une preuve de concept (PoC) d’une preuve de concept.
Il y a la bonne PoC et la mauvaise PoC.
Il y a celle d’entreprise qui est une façade front pour un produit fini, mais en fait derrière il y a rien, c’est une PoC façade, et la PoC de codeur qui au contraire en terme de rendu est à chier mais illustre la mécanique derrière pour résoudre une tâche de conception.
Dans le cadre de yahi, à partir du moment où je me suis fixé arbitrairement pour le fun de servir tout ce qui était nécessaire en une page, il me fallait un routeur virtuel.
Évidemment, pour ça je me suis pas mis de tickets, ça aurait été trop facile pour démontrer ma cohérence.
Par contre j’ai bien commencé par faire une PoC pour le routage de niveau 1 puis une Poc pour le routage de niveau 2 à partir de là seulement une fois en confiance que j’avais shooté le chemin critique, j’ai fait un billet de blog pour (me l’) expliquer le principe du routage virtuel en javascript, pour le mettre dans un commit que j’ai mal documenté.
Pauvre moi.
Pour virer l’API google jsapi, j’ai aussi commencé par une PoC avant de faire le chantier.
L’erreur est humaine la perfection diabolique selon l’ancien proverbe.
Certes, je fais de multiples erreurs, je souffre de syndrome de gros doigts, dans ma précipitation j’étiquette mal des commit, mais à chaque incrément, même en local, je putain de test que les résultats sont conformes aux attentes avec un
pip install .. ; speed_shoot test/*log* > data.js ; yahi_all_in_one_maker data.js ; firefox aio.htmlEt je vérifie manuellement que les pages sont conformes à mes attentes.
Pourquoi, parce que pour les tests visuels à part selenium je sais pas faire. Et là encore, quand on est solo en temps limité, on investit son capital temps judicieusement ; hors de question de faire des tests des rendus visuels tant qu’à minima :
Deux conditions qui ne sont pas encore remplies.
La définition de terminé avant de se lancer dans l’évangélisation est importante.
Tout bon chef de projet vous dira qu’un projet pour être « terminé » doit avoir une définition rigoureuse de « fini ».
Lol, et ça doit aussi tenir dans une enveloppe de budget.
Néanmoins, on peut aventurer une définition de fini : un projet est proche d’être fini quand on arrive à convaincre des relations ou des inconnus de l’utiliser.
Je parle même pas de l’étape post évangélisation, je parle d’avant même tenter d’évangéliser.
D’écumer des réseaux sociaux, et d’amis, d’expliquer son idée à des oreilles heureusement plus attentives que la moyenne, de rôder son discours et fignoler son « montrable » jusqu’à ce que des gens disent « hum, ça pourrait peut être éventuellement m’intéresser ».
Avant de considérer mon projet comme fini, j’ai trouvé deux amis pour l’installer, ben et tuck.
Quand cet évènement heureux est arrivé, j’ai fait une note mentale que c’était l’alpha et je me suis mis mentalement dans la peau d’être aux petits ognons et rapides quand ils rapportaient des bugs.
Faire du logiciel est loin d’être un exercice solitaire, un logiciel sans utilisateur n’est pas un logiciel, c’est une œuvre d’art sous cloche.
Une fois qu’on atteint ce stade, on a pas vraiment fini. Il faut prendre tout les retours, les intégrer et les raffiner en la doc la plus concise possible.
C’est le moment où tu DOIS chiader ton README
Il faut impérativement tenter de décrire un usage le plus concret du projet, et en prenant l’utilisateur par la main pour lui expliquer comment et pourquoi arriver au résultat que fourni le paquet.
Il ne faut pas chercher à être didactique, expliquer, développer. Au contraire, il faut réduire au maximum, vérifier chaque lignes factoriser. Tant pis si l’utilisateur ne voit pas l’idée générale (l’agrégation générique de journaux système basé sur les regexp), il faut être concret quitte à perdre de l’intérêt du logiciel.
Où se trouvent les sources ? Où se trouve la doc détaillées ? Où ouvrir un ticket.
Je le mets en premier.
Maintenant que tu as ouvert l’appétit du lecteur/utilisateur, ouvre une porte sur les possibilités, mais ne l’assomme pas.
Si ici tu te précipites : t’es mort. T’as sûrement oublié quelque chose. Laisse au moins un jour entre ta définition de « fini » et l’évangélisation, et après 24h fait manuellement le tour de tout ce que tu peux : relis tes docs, refait tourner les tests automatiques (que j’ai fourbement mis dans le setup.py), les manuels, revérifie TOUT.
Maintenant on respire, car on va passer de l’introspection protectrice à prendre la foudre d’internet sur le coin de la tronche.
Si tu es pas sûr d’être intellgient dis le en latin
C’est sensé vouloir dire soit prêt à tout.
Ci suit ma liste d’arguments préparés face aux trolls :
Si yahi utilisant une licence reconnue par le clergé du libre est « reconnu » libre, c’est pas le cas de ce livre.
La riposte est d’invoquer les 4 libertés du libres selon St Richard Maximus Stallman :
Pour que le logiciel soit libre tu fournis le lien vers le gestionnaire de version. Pour le livre, lol, c’est plus compliqué.
Dans le genre stérile cette guéguerre des éditeurs de texte me casse les couilles.
Ancien utilisateur d’emacs, actuel utilisateur de vim, je réponds que mon éditeur de code est indifféremment kate, ultraedit, notepad pour faire chier.
Fuck you all, j’ai pas le temps de tout apprendre, je le pourrais mon code serait en RPN (reverse polish notation) de la HP48.
Je sais c’est mal, je suis pas un saint, je suis un humain. J’aimerais bien te dire d’aller te faire voire, mais en tant qu’évangéliste je suis calme et reconnais ôh combien tu as raison.
J’ai ouvert un ticket et si je ne l’ai pas fait, je t’encourage à le faire. C’est l’équivalent corporate de cause toujours tu m’intéresses. Le logiciel a une intention et il suit un formalisme.
Ce n’est pas de suivre un formalisme qui le fait fonctionner mais une intention.
La forme est secondaire.
Actuellement, c’est important. Il faut guider l’utilisateur à trouver le jeu minimal de condition pour reproduire la dysfonction.
C’est probablement un bug, et ça mérite toute l’attention du développeur.
Ceci n’est pas un troll.
Pourvu que ton logiciel soit fait à centrale (VLC), ou dans une boîte connue (genre IBM) tu n’auras pas la même audience que le quidam.
Pas que.
Si tu es bègue, chemo, en fauteuil roulant, squidjie, une femme de la téci … tu l’auras dur comme un godemichet dans le uque.
Bref, nombre de problèmes que je n’ai pas, et pourtant JE VAIS ME PLAINDRE.
Oh !
Qu’on le veuille ou non, le logiciel libre reste une course entre les possesseurs de 486DX266 sur les pentium qui prime sur ceux qui n’ont même pas d’ordi.
Alors, oui, le coût des ordis en francs constant a baissé. Au point même qu’on parle plus de francs ou de CPC 464 mais de PC de raspberrie pi et d’euros.
Et autre chose un invariant est le « capital social » genre, si t’as fait X que tu soit né prolo ou pas on t’écouteras plus qu’un autre même si tu racontes de la merde.
Il faut aussi comprendre que la tradition tout à son honneur des rencontres libres (RMLL, pycon, et autres) se fait non plus par le bidouillage avec une unif et le crous, mais avec un protocole de reconnaissance du volontariat … qui nécessite des commanditaires (sponsors en français de Paris), commanditaires qui se voient -et c’est oh combien normal- octroyer des créneaux de conférence.
De fait, l’accès aux conférences est devenu sauf exception (kof kof FOSDEM) plus dur pour le quidam que par le passé.
Pour brûler son égo, voici ma classification des endroits ou publier par ordre de toxicité et d’audience (le plus toxique le plus d’audience) :
Le reste c’est des humains. Nan je déconne, mais ces deux là vous apporteront comparés aux brûlures engendrées relativement peu de retour.
Les endroits que je recommande :
Il vaut mieux parfois une audience plus solide locale et bienveillante qu’une mondiale qui crame les ailes.
J’ai un peu testé les anciens résals socials (fb & co) et les très nouveaux (bluesky) ; on est au niveau des stats proche de pisser dans un violon.
Bonne question.
Là je suis en attente de modération de la dépêche de l’annonce de mon paquet sur linuxfr par benoit (un gars bien).
Il y a 30 dépêches devant dont de personnes morales plus importantes, j’ai largement le temps de commencer et terminer un livre.
Imaginons, juste imaginons que je remporte la timbale.
Est-ce que cela fera disparaître magiquement les cris de ma fille que j’ignore, de la chienne que je déteste, de ma femme qui me force à des coûts inutiles et me reproche de ne pas avoir un boulot mieux payé que chômeur dans un pays qui manque de job (surtout pour les vieux qui ont perdu l’usage musculaire d’un bras) ?
Pour survivre, j’ai été déménageur, je crois pas que je vais pouvoir l’être à nouveau. Lol.
Est-ce que le logiciel libre peut me permettre comme un gagnant à la loterie de gagner un ticket pour une job, je ne dis pas bien payé, juste payé mieux qu’au SMIC ?
Nan.
Le logiciel libre n’est pas plus une méritocratie que la vraie vie. Il ne se passera rien de magique.
C’est pour ça que je n’ai investit qu’une semaine de ma vie dans, de mes vacances dans le logiciel libre comme ce beau graph github le montre
Faire du logiciel libre, excepté sur un plan de satisfaction personnel à moins que vous soyez déjà blindé de capital social (grandes école, famille connue, vu à la télé ou autre terrain de concours de grosse bite) ne vous apportera rien de plus que de la perte d’énergie.
Par contre, si je remporte la timbale, je serais en paix avec moi même, ayant comme Dr Jeckyll d’un coté du code libre fait selon mes standards et de l’autre le savoir faire du code «qualité entreprise» comme Mr Hyde.
Sur un coin d’internet paumé, qui s’efface plus vite que la mort quand les serveurs tombent, il y aura un morceau de code qui défendra mes valeurs vaniteuses et personnelles de « qualité » du code. Une partie de moi qui refuse la fatalité de la production en entreprise selon ses standards claqués au sol.
Et c’est ça être un loser. Refuser l’ordre des choses, quitte à en payer le prix, quitte à se faire rétamer, mais garder en soi la volonté de se battre, même pour des broutilles…
Donc, oui, je suis un loser, un loser du libre, mais je m’en fous.