Suite aux attaques en règle de Kevin et le drama qui s’en est suivi, j’ai beaucoup réfléchi car j’entendais une petite musique qui me gênait.
Dans mon enthousiasme, et même une forme de ferveur, de défendre une cause noble à mes yeux, le bonheur des développeurs, j’ai eu l’impression de franchir une ligne rouge.
Alors je me suis remis en question.
C’est une bonne question. Intéressant de voir comment les choses dérapent, un peu au début, beaucoup ensuite !
Tout commence avec un post un brin provocateur de Kevin sur linkedin :
https://www.linkedin.com/feed/update/urn:li:activity:6943520332855054336/
Aujourd’hui, j’ai du écrire un code affreux. 😭
Alors j’ai besoin d’écrire cet article pour m’excuser.
Non en fait j’assume. Et je pense que c’est important de t’expliquer ce qui s’est passé.
Continuer la lecture de « Software craftsmanship : une question de compromis »Cet article est rédigé en paire avec Hadrien. On s’est dit que c’était bien d’illustrer le concept par la pratique !
Photo de Tudor Baciu sur Unsplash
Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.
Tu trouveras ici un article assez complet sur le pair-programming dans lequel tu verras comment le pratiquer et le mettre en oeuvre. Si tu n’est pas au clair avec cette pratique, je te conseille de commencer par là !
“Un mob, c’est réunir toutes les personnes qui sont nécessaires au succès d’une tâche autour d’un seul poste de travail.”
Piqué par Hadrien à Woody Zuill
Bon, dit comme ça, c’est abstrait, mais concrètement, ça donne quoi ?
Si tu as connu les tasks forces, ça y ressemble !
Tu sais, le moment où c’est la m$#§e sur le projet, que la deadline arrive et qu’on met tout le monde dans une ‘war room’ pour sauver le monde (et le projet).
Ben c’est la même chose, mais avant que ce soit le bordel.
Concrètement, tu mets les développeurs du projet, et tous ceux qui sont utiles dans une même salle, en même temps, devant un seul écran.
La différence avec le pair-programming: ben c’est juste le nombre.
Au lieu d’être 2, tu peux être 3, 4, 5 ou plus si affinité.
Bon en vrai, au-delà de 6, ça va être compliqué à tenir dans le temps. Si tu as besoin de plus d’une pizza (format américain) pour nourrir ton équipe c’est qu’il est temps de la diviser.
Et finalement cette toute petite différence, tel un battement d’aile de papillon, engendre de grandes différences.
C’est ce qu’on va voir maintenant.
Continuer la lecture de « Pair Programming VS Mob Programming »Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.
Photo de Alvaro Reyes sur Unsplash
Cet article est encore en cours de rédaction. Si tu as des suggestions sur ce qui manque, te semble erroné ou si tu te poses encore des questions après avoir lu l’article, tu peux me contacter ici : https://www.linkedin.com/in/benoitgantaume/
Quelle drôle d’idée après tout : mettre deux personnes au travail sur une tâche, alors qu’une seule pourrait suffire.
Pourquoi diable y mettre autant d’énergie ?
Si on reste dans une logique productiviste fordienne, cela ne fait aucun sens.
Mais si on prend conscience qu’on est sur une activité complexe, développer un logiciel, qui nécessite des interactions hautement complexes, des humains qui bossent ensemble, on se rend compte que ce n’est pas si stupide.
Deux paires de bras qui travaillent ensemble vont apporter un gain linéaire : 1 + 1 = 2.
Hors, développer demande d’utiliser principalement son cerveau. Et quand deux cerveaux réfléchissent ensemble, le gain n’est plus linéaire.
Parfois 1 + 1 = 11.
Par moments 1 + 1 = 0.
Donc la première raison de travailler en pair programming est que les solutions apportées vont être beaucoup plus riches et le code de bien meilleure qualité.
La deuxième raison est de faire circuler la connaissance.
N’as-tu jamais été stressé à l’idée de partir, toi ou un collègue en vacances ?
Si tu veux pouvoir partir tranquille, il vaut mieux éviter d’être le seul détenteur d’une connaissance. Ça tombe bien, le pair programming est un formidable circulateur de connaissance.
Enfin, d’un point de vue humain, cela permet d’aller à la rencontre de ses collègues d’une manière plus profonde. Mais ce point peut être à double tranchant. On en parle plus bas.
Dans le pair programming des origines, les ordinateurs étaient encombrants, onéreux, et les outils de communication peu répandus. Donc on bossait à deux, l’un à côté de l’autre, sur le même ordinateur. Il n’y avait qu’un clavier/souris et une seule personne touchait le clavier pendant que l’autre réfléchissait avec lui.
Aujourd’hui, les ordinateurs portables sont répandus et les outils de communication beaucoup plus développés grâce aux connexions fibrées.
On peut donc élaborer d’autres manières de binômer.
Continuer la lecture de « Pair programming : le guide ultime »Le software craftsmanship, ou craft, est devenu tendance. Mais qu’est-ce qui se cache derrière ce concept ?
On peut définir l’artisanat logiciel, le software craftsmanship, comme un mouvement porté par des développeurs passionnés par leur métier.
On peut le décrire selon ses valeurs, son état d’esprit ou encore ses pratiques.
Difficile de parler de software craftsmanship sans parler d’agilité tellement les deux sont liés à leur origine, même si les choses ont bien évolué depuis.
On parlera aussi dans cet article de la relation des pratiquants avec les reste du monde et aussi comment s’y former.
C’est aujourd’hui le 18 Mai mon freedom day de freelance.
Qu’est-ce que le freedom day ?
C’est le jour de l’année où je n’ai plus besoin de travailler pour assurer le minimum vital de ma rémunération.
C’est le jour où je suis libre de décliner une affaire que je sens pas, sans me demander si je vais pouvoir mettre de la nourriture sur la table pour les prochains mois, sans me demander si je ne vais pas le regretter dans quelques semaines.
En tant qu’agence, notre freedom day, c’était plutôt vers le 18 Novembre : on faisait notre résultat sur les dernières semaines.
Maintenant que je suis freelance, j’ai raccourci cette date.
Et c’est devenu un objectif pour moi : amener cette date le plus tôt dans l’année.
A partir de ce jour, je peux passer beaucoup plus de temps à me former, renforcer mon expertise, passer du temps sur des projets persos et ainsi développer les outils qui me permettront de raccourcir cette date l’année prochaine.
Tu la sens la boucle vertueuse ?
Mieux je choisis mes clients sur les critères qui me conviennent, et plus je fais avancer mon projet.
Plus je me forme, et plus je peux être pointu et valoriser mon expertise.
Plus j’investis de mon énergie sur des produits et mieux je pourrai faire grandir mon activité sans travailler plus, voire même moins.
Pour y arriver, ça commence souvent par sortir de la logique de régie à temps plein.
D’ailleurs, si tu veux connaître les mécaniques qui te permettent toi aussi d’y arriver, viens voir la conf que j’ai donnée sur youtube à ce sujet.
Cette notion de freedom day, je l’ai empruntée à Pierre Ammeloot, un des experts qui intervient dans le cercle. Concrètement, avec les logiques d’engagement et de facturations d’acompte, j’ai simplifié le calcul en disant que c’est le jour où le facturé dépasse le point d’équilibre de ma structure. C’est -à -dire que je couvre mes frais prévus : mon salaire, mais aussi les factures des partenaires avec qui je travaille.
Remarque bien que j’ai choisi d’investir une partie de ce temps libre, mais c’est à toi de voir.
Certains vont préférer dédier ce temps à leur famille.
D’autres voyager.
D’autres encore faire du pro-bono.
C’est ce que j’aime avec le freelancing : tu as le choix de ton mode de vie.
Ce n’est pas facile.
Certains moments sont franchement désagréables.
Mais tu as le choix de définir tes propres règles du jeu.
Envie de bosser dur : just do it.
Envie de lever le pied : vas-y si tu peux te le permettre.
Et toi, c’est quand ton freedom day ?
Si tu as envie de rejoindre un groupe de développeurs freelance qui ont envie d’aller plus loin, viens jeter un oeil au cercle.
Benoit Gantaume
Artisan Développeur
Le cercle, c’est un parcours de formation pour les développeurs freelance qui t’apporte les compétences pour faire développer ton activité, gagner en sérénité et sortir de la routine de la régie.
En septembre 2021 démarrait le premier cercle, et si tu n’as pas pu nous rejoindre, écoute les experts qui sont venus nous former, ça sera un peu comme si tu y étais !
On ouvre un second cercle qui démarre le 15 Juin prochain. Donc si tu veux nous rejoindre, passe une tête !
La première fois que j’ai travaillé en équipe, ça a été le fiasco total !
Aucun des deux développeurs avec lesquels je travaillais n’a réussi à démarrer le projet que je réalisais.
Le hic, c’est que je partais en vacances et il fallait que mes collègues puissent le reprendre pour continuer sans moi.
De mon côté, c’était l’éternel :
« Je ne comprends pas, ça marche sur ma machine ! »
Que s’est il passé ?
C’était il y a quelques années, NPM, le gestionnaire de dépendances JavaScript venait de passer en version 5, et avec lui, l’ajout d’une fonctionnalité de marque : le fichier de verrouillage des dépendances (le fameux « package-lock.json »).
C’est une fonctionnalité qui permet de figer l’arbre des dépendances installées et de reproduire cette installation à l’identique autant de fois que nécessaire.
Comment ça marche ?
Supposons que vous souhaitez installer la dépendance « axios » (un client HTTP) dans votre super application.
Vous allez taper la commande suivante dans votre terminal :
npm install axios
Votre fichier « package.json » contiendra alors l’information suivante :
{
"name": "my-super-app",
"version": "1.0.0",
"license": "UNLICENSED",
"dependencies": {
"axios": "^0.21.1"
}
}
Et votre fichier « package-lock.json » contiendra quelque chose comme ça :
{
"name": "my-super-app",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"axios": {
"version": "0.21.1",
"resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
"integrity": "sha512-dKQiRHxGD9PPRIUNIWvZhPTPpl1rf/OxTYKsqKUDjBwYylTvV7SjSHJb9ratfyzM6wCdLCOYLzs73qpg5c4iGA==",
"requires": { "follow-redirects": "^1.10.0" }
},
"follow-redirects": {
"version": "1.14.1",
"resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
"integrity": "sha512-HWqDgT7ZEkqRzBvc2s64vSZ/hfOceEol3ac/7tKwzuvEyWx3/4UegXh5oBOIotkGsObyk3xznnSRVADBgWSQVg=="
}
}
}
Le fichier de verrouillage va stocker la version exacte installée à cet instant de axios (même si votre « package.json » autorise plusieurs versions) avec l’URL de téléchargement et la signature de la dépendance installée.
Et surtout, le plus important, il va faire la même chose avec les dépendances de vos dépendances (ce que l’on appelle les dépendances transitives).
Dans notre exemple, axios dépend du paquet « follow-redirects » (il en a besoin pour fonctionner), ce dernier va donc également se retrouver dans ce fameux « package-lock.json » avec une version figée, même si axios en accepte plusieurs dans son propre fichier « package.json ».
La prochaine fois que vous ferez un ‘npm install’, NPM utilisera le fichier de verrouillage pour reproduire la même installation (il suffira d’aller chercher les URL sauvegardées à l’intérieur).
NPM peut ensuite vérifier que c’est toujours exactement la même chose qui est installé en calculant la signature de la dépendance installée et en la comparant à celle du fichier de verrouillage.
Ce mécanisme permet de garantir que votre installation de dépendances est reproductible.
Sauf que, quand NPM s’est mis à jour sur ma machine, la seule chose que j’ai constaté, c’est qu’un nouveau fichier généré – que je n’avais pas demandé (le fameux package-lock.json) – était apparu et venait poluer mon beau projet.
Comme je ne comprenais pas ce package-lock.json, j’ai trouvé la configuration me permettant de m’en débarrasser et de retourner à mes petites habitudes bien rangées en deux temps trois mouvements (il suffit de créer un fichier « .npmrc » à la racine de votre répertoire de travail avec la configuration suivante).
package-lock=false
Le problème, c’est que certaines dépendances transitives avaient été mises à jour entre le moment où j’avais fait mon installation et celui où mes collègues l’ont effectué.
Et pas de bol, l’une d’entre elle avait introduit un changement cassant, autorisant notre dépendance directe à l’installer.
Sans le fichier de verrouillage pour figer la version qui marchait pour moi, mes collègues n’étaient pas en mesure de reproduire une installation identique, et dans ce cas particulier, ne pouvait même plus lancer le projet à cause du changement cassant (une fonction avait été renommée) !
Le fichier de verrouillage est donc de nos jours un élément indispensable pour tous les projets, que l’on travaille seul ou à plusieurs, au vu du nombre exponentiellement grandissant de bibliothèques utilisées (ce qui est d’ailleurs un problème, si le sujet de la performance et de la lourdeur des logiciels vous intéresse, je vous recommande la lecture de ma traduction de l’excellent article de Nikita Prokopov : https://blog.romainfallet.fr/desenchantement-logiciel).
Dans mon cas, si j’avais supprimé mon dossier node_modules, j’aurais rencontré exactement le même problème que mes collègues en essayant de réinstaller mes dépendances.
Pour profiter des bienfaits du fichier de verrouillage il faut donc bien l’ajouter dans vos commits et l’envoyer sur votre dépôt Git.
C’est donc après quelques heures de recherche et une petite remise en question que je suis parvenu à remettre en place une installation reproductible après avoir rétrogradé la version du paquet qui posait problème.
J’ai pu ensuite partir sereinement en vacances !
Mais mais mais, on ne peut pas se quitter là-dessus…
Si les mainteneurs du paquet incriminé avaient suivi la spécification de gestion sémantique des versions (Semantic Versionning ou SemVer en anglais), tout ceci ne serait pas arrivé !
Qu’est-ce que c’est ? Ce sera le sujet du prochain article !
Abonnez-vous sur https://compagnon.artisandeveloppeur.fr/veille et les numéros de version n’auront plus de secret pour vous (très utile si vous ne connaissez pas la signification des « ^ » et « ~ » dans votre package.json ;)).
Au plaisir d’échanger !
Salut,
En février de l’année prochaine, Artisan Développeur va fêter ses 4 ans.
C’est dingue d’y penser.
4 ans à publier régulièrement du contenu, que ce soit en email, en blog, en podcast ou en vidéo.
C’est plus de 300 épisodes de podcast, une cinquantaine de vidéos, des milliers d’écoutes tous les mois et autant de vues youtube.
Au moment d’écrire ces lignes et de prendre conscience de tout ça, j’ai un frisson.
J’en suis fier et j’aimerais partager ce moment avec toi.
Car c’est à la fois pour toi et grâce à toi que je fais tout ça.
Mais ça n’a pas été facile, loin de là.
Je ne vais pas te parler de la discipline que cela demande, mais plutôt du côté émotionnel du projet.
Car entreprendre des choses, c’est s’exposer.
S’exposer, c’est prendre le risque d’échouer.
Certes, se planter est le meilleur moyen d’apprendre.
Mais ça fait quand même mal.
Et ça fait peur.
J’ai une mauvaise nouvelle : je ne connais aucun moyen d’y échapper.
Le seul moyen de dépasser sa peur, c’est de la traverser.
Je vais te raconter quelque chose que je n’ai jamais dit à personne : comment j’ai vécu mes premières ventes en ligne.
J’espère que tu es bien assis•e, par-ce qu’on va monter sur des montagnes russes…
J’avais vu tous ces témoignages d’infopreneurs qui racontaient comment ils étaient stupéfaits de leurs premières ventes.
Ils avaient constitué avec le temps une liste de personnes intéressées par leur travail et il était temps de passer à l’étape d’après et vendre une première formation.
Ils insistaient sur ce moment magique d’appuyer sur le bouton ‘Send’ de leur outil d’email marketing et leur stupéfaction de voir les commandes tomber dans les minutes qui suivaient.
Leurs témoignages étaient émus, avec la bonne musique qui va bien en fond pour montrer à la fois le désespoir dans lequel ils étaient avant de devenir infopreneur, la tension au moment d’appuyer sur le bouton magique et l’allégresse qui suivait.
Je pense que naïvement, j’espérais vivre la même chose…
Je vais te raconter ma version.
Après des mois de travail à me manger le cerveau, après avoir produit une cinquantaine de podcast et collecté quelques centaines d’emails de gens intéressés, j’arrivais au moment fatidique et soi-disant magique d’appuyer sur le fameux bouton ‘Send’ de ma première campagne email.
Je ne peux pas dire que ce moment m’ait laissé un sentiment particulier.
Je sentais forcément de la tension : il y avait beaucoup d’enjeux pour moi.
J’ai cliqué sur ce bouton.
Et j’ai ouvert ma boite email, impatient de voir les commandes tomber.
Rien.
Mais comment ça ?
Elle est où la pluie de commandes promise ?
Une heure après, rien non plus.
J’ai même cru à un moment que ma boite email était plantée ou que le système de commande était buggé.
Mais non. Il n’y avait juste rien.
Et là j’aimerais te décrire les émotions que je vivais, mais je n’ai pas les bons mots.
Ils ne seraient pas assez puissants.
Mais dire que je me sentais nul était un doux euphémisme.
Ça se bousculait dans ma tête. Devais-je continuer ?
Si ce que je faisais n’intéressait personne, cela en valait-il la peine ?
Durant ces premières 24h, je sentais un mélange de honte et de nullité absolue.
Et puis la première commande est arrivée.
Et là c’était un feu d’artifice dans ma tête.
Je passais de l’état de pire merde du monde à celle de grand champion.
Les deux étaient autant ridicules l’un que l’autre, mais c’était comme ça que je le vivais.
Je commençais à négocier avec moi-même : est-ce qu’une commande était significative ?
Je me mangeais encore le cerveau quand une autre est arrivée quelques heures plus tard.
Au fil des jours de cette semaine, c’est au final 8 personnes qui m’ont fait confiance.
L’expérience était clairement validée et l’objectif rempli.
Mais quel arc-en-ciel émotionnel il m’a fallu vivre !
Autant être honnête : c’était trop pour moi.
Mais ce projet me tenait trop à cœur pour que je m’arrête à ça.
C’est mon message : si tu as un projet qui te tient à coeur, soit prêt•e à passer la tempête des émotions que cela va engendrer et fonce !
Juste fais-le.
Heureusement que j’ai pu traverser ces moments, sinon je ne serais pas en train d’écrire cet email.
Car depuis il y a eu du chemin.
J’ai appris, non pas à gérer, mais à accepter les émotions de chaque lancement.
Je suis encore passé par de sacrés ascenseurs émotionnels et je m’habitue un peu plus à chaque fois.
Avec le temps, je ressens plutôt de l’excitation quand je fais la promotion de mon travail comme aujourd’hui.
Je suis tellement heureux de partager ça avec toi, j’espère que ça t’inspirera pour entreprendre les projets importants pour toi.
Excité aussi de te parler de l’upgrade du cursus Artisan Développeur.
Après avoir aidé des centaines de développeurs à écrire du code durable, j’ai fait une (grosse) mise à jour qui est maintenant disponible ici :
https://artisandeveloppeur.systeme.io/cursus-artisan-developpeur
Pour marquer cette amélioration, le prix augmentera le 21 Novembre.
Alors si tu es intéressé, jette un oeil.
Aujourd’hui, Artisan Développeur, c’est devenu un petit business. Mais c’est surtout à la base une revendication et une vision.
Il me tarde de te raconter ça aussi. Car je crois n’en n’avoir jamais parlé non plus…
A bientôt !
Benoit Gantaume
Artisan Développeur.