Technique
Cette fois promis c’est l’album de la maturité.
Une suite ? #
Vous avez été nombreux (comprendre, environ deux) à me demander s’il y avait une suite à Minimalisme et esthétique puis Simplicité par défaut et comme les trilogies vont toujours mieux par trois, vous pouvez considérer ce qui suit comme mon cheminement personnel ces quatre dernières années.
L’état de l’art en matière de développement web n’a pas vraiment l’air d’être allé vers davantage de simplicité, de minimalisme et encore moins d’esthétisme au cours de cet intervalle. C’est peu de le dire, enfin l’écrire. Ce qui a changé par contre, c’est mon expérience — d’aucuns appelleraient ça vieillesse — et mon envie d’échapper à cela en fuyant les produits et donc équipes qui mettent la technique avant les utilisateur·ice·s.
Je vous divulgâche le résultat tout de suite : je me sens plus apaisé sur ce plan là. La présence de Ronan dans mon équipe actuelle n’est pas étrangère à ce sentiment mais le choix des technologies employées me donne aussi un sentiment de contrôle salutaire.
En guise d’introduction aussi, j’ai conscience d’être dans un environnement extrêmement privilégié me permettant d’avoir la liberté suffisante pour être en capacité de faire ces choix. C’est loin d’être anodin dans l’exploration qui suit.
Le problème #
Eventually, I settled on a list of questions I would ask myself for each problem as it arose. I found that asking these questions, in order, helped me make the best decision possible:
- Is this really a problem?
- Does the problem need to be solved?
- Does the problem need to be solved now?
- Does the problem need to be solved by me?
- Is there a simpler problem I can solve instead?
Each question is designed to reveal something about the problem that allows you to go to the next step, or if you’re lucky, just avoid the problem altogether.
C’est le principal fléau de notre industrie : tenter de résoudre des problèmes là où il n’y a pas de besoin. Le solutionnisme technologique ne devrait être que la dernière option mais cela serait mauvais pour le business. Alors on met des paillettes pour faire passer la pilule et encaisser le chèque en fin de mois.
Vous connaissez le fameux « Je vous écris une longue lettre parce que je n’ai pas le temps d’en écrire une courte » de Blaise Pascal, il se trouve que cela s’applique aussi à l’élaboration d’un produit. Les solutions frugales coûtent parfois autant (si ce n’est plus !) que les usines à gaz. Cela prend du temps de comprendre une problématique, cela prend du temps d’échanger avec des utilisateur·ice·s, cela prend du temps de déterminer quelles sont les fonctionnalités qui ne sont pas/plus utiles. Cela prend du temps de produire des choses im·pertinentes.
En contrepartie, elles permettent d’économiser sur le long terme en réduisant la maintenance, le périmètre de support et l’exploitation du produit. En se focalisant sur la pertinence, on conserve une application à échelle humaine. Autant dans l’usage que dans la conception.
Mon contentement est grand lorsque je suis surpris par la résilience du code auquel je contribue. J’ai soudain l’impression d’avoir pas trop mal fait les choses. C’est assez rare pour être célébré comme il se doit.
JavaScript #
The performance tradeoff isn’t about where the bottleneck is. It’s about who has to carry the burden. It’s one thing for a developer to push the burden onto a server they control. It’s another thing entirely to expect visitors to carry that load when connectivity and device performance isn’t a constant.
Developer productivity is a great metric, but it can’t be isolated from the larger ecosystem. With Ruby, the tradeoff works because nothing is externalized, and it’s barely even a tradeoff these days. But with large front-end JavaScript frameworks, things aren’t just slow. If that JavaScript isn’t able to be loaded for a variety of reasons, sites don’t just become a little slower. They break entirely.
Je ne peux pas parler de technique et de Web sans parler de JavaScript et de ce que l’on fait subir à chaque personne qui visite une page. Les compromis qui sont fait actuellement sont propres à un contexte qui donne une ascendance aux riches développeurs et développeuses qui peuvent se permettre avec leur matériel récent (cache) de faire des pages tout saufs réactives pour le reste du monde. Ma machine a bientôt cinq ans et se trouve être limite inutilisable pour du développement web, comment ose-t-on ?
Je trouve cela terrible, autant en terme de (non)empathie que de consommation de ressources si l’on considère les coûts de manière globale et transverse. Cela a de quoi m’empêcher de dormir aussi (cache), déporter une grande partie de la complexité et du calcul du côté du navigateur s’avère être contre-productif dans une majorité des cas.
HTTP 262 JAVASCRIPT UNNECESSARILY REQUIRED; the content is available but you’d better have a good CPU and 15 seconds of free time before the first pixel gets painted
Taudry Hepburn sur Twitter
On ne peut pas non plus parler de technologie sans son usage et ce n’est pas tant JavaScript que ce qui est fait avec qui m’importune. En tant que développeur, c’est mon quotidien d’apprendre à m’adapter et je sens bien que je pourrais devenir un peu moins incompétent sur le sujet mais c’est en tant qu’usager que je n’en peux plus. Manque de résilience, réduction des performances, tentative de prise de contrôle de mon navigateur et je n’évoque même pas tout ce qui essaye de consigner mes moindres clics.
Heureusement que les navigateurs implémentent un mode lecteur qui rend certains sites juste… lisibles. Je ne compte plus le nombre de fois où je suis carrément obligé d’aller supprimer un nœud du DOM à la main (!) pour pouvoir afficher une page web. Fâcheux.
Aujourd’hui, lorsque la vanille ne me suffit plus, j’utilise StimulusJS que je trouve être la moins mauvaise solution. On garde du HTML propre et interprétable ce qui facilite l’amélioration progressive. C’est relativement léger compte tenu de l’aide que ça m’apporte pour structurer mon code. Et c’est suffisamment limité pour me permettre de prendre conscience de mon erreur lorsque j’essaye de mettre trop de logique dans le navigateur.
Transmission #
Aucun code n’a changé ma vie.
via Mastodon, publication privée
On touche ici du doigt une chose qui me semble être essentielle, le fait de savoir écouter et aussi de prendre la parole pour accompagner et montrer avec une petite lanterne que d’autres voies sont possibles. Qu’il y a un autre niveau de plaisir à rendre disponibles des outils utiles et relativement frugaux.
Aucun code n’a changé ma vie mais le fait de partager mes réflexions dessus a eu des conséquences non négligeables. Que ce soit sur cet espace ou lors de conférences ou par courriel ou en échangeant avec des collègues ou autres. Chaque échange est une occasion de me faire changer et en même temps de faire changer mon interlocuteur·ice.
Sans l’imposer, raconter une voie qui pourrait résonner chez l’autre. Sans prétention autre que celle de dire que cela existe, que certaines utopies ne sont pas si inaccessibles.
L’avantage c’est qu’avec l’expérience, normalement, vous pouvez apporter plus que votre code. Le périmètre n’a aucune raison d’être identique avec les années.
Exactement, vous pouvez accompagner d’autres personnes, participer à la conception du produit, interviewer des utilisateur·ice·s, et pleins d’autres trucs auxquels je ne pense pas. Si ça se trouve, vous commencez à suffisamment vous connaître pour prendre du recul au bon moment afin de ne pas devenir un goulot d’étranglement ou tout simplement vous protéger.
Tout cela a de la valeur.
Tendance #
tiens, une question pour les vieux réacs : quelle est la dernière chose tendance que vous trouvez utile ?
via IRC
Alléger. Proposer un web de documents (cache) lorsqu’il est possible. Fuir ce qui ressemble à de l’hydratation (?!) (cache) ou toute autre fausse bonne idée réduisant l’accessibilité (et les performances mais c’est pour moi un pléonasme).
Prendre le temps d’expliquer pourquoi vous avez fait ces choix dans ce contexte particulier. Partager le fait que l’on peut faire des choses chouettes en utilisant des « boring technologies (cache) », que la valeur n’est pas forcément là. Se méfier aussi de ce qui semble boring mais n’est pas pour autant trivial (cache) ou bien toujours incompris par beaucoup (cache).
On peut courir après la technologie, c’est plaisant une heure par-ci par-là pour découvrir de nouveaux paysages. De temps en temps même un petit marathon pour rester en forme. Mais à force d’être focalisé sur les prochains pas, j’en étais arrivé à perdre de vue l’intérêt du chemin. Un périple au service de ma vision de l’utilité.
Je suis conscient que je me tire peut-être une balle dans le pied en énonçant toutes ces frustrations publiquement. Ou peut-être que cela me permettra au contraire d’entrer en contact avec des personnes qui partagent cette approche. On verra bien, n’hésitez pas à me contacter pour échanger là-dessus.
Docker #
Code must run behind at least three levels of virtualization now. Code that runs on bare metal is unnecessarily performant.
How is computer programming different today than 20 years ago? (cache)
La critique est acerbe et juste. J’en suis à refuser des projets car l’empilement de technologies me semble être trop bancal pour ne pas risquer de faire tout tomber sans comprendre ce qu’il s’est passé.
Et je ne parle même pas de la charge mentale associée à toute cette pile technique qui détourne de l’intérêt principal d’un produit. Ni du surcoût pour chaque nouvelle personne souhaitant participer (en dépit de la promesse inverse !). Ou du besoin d’avoir une machine récente pour que tout puisse tourner tellement il y a de couches accumulées.
So here’s the counterargument: Integrated systems are good. Integrated developers are good. Being able to wrap your mind around the whole application, and have developers who are able to make whole features, is good! The road to madness and despair lays in specialization and compartmentalization.
Je ne veux pas que ma connaissance soit « virtualisée », je ne veux pas que mon application devienne une boîte noire, je ne produis pas de l’électroménager. J’ai parfois l’impression de me battre contre ma propre prolétarisation. Suis-je un Luddite moderne de penser cela ?
Mudita #
What enough means for me, only concerns me, and should only be compared to myself: where I’m actually at versus where I’m working to get to. As in, am I presently happy or do I assume I’ll be happier in the future, and if so, why?
Enough is the antithesis of unchecked growth because growth encourages mindless consumption and enough requires constant questioning and awareness. Enough is when we reach the upper bound of what’s required.
Toutes ces réflexions sont très personnelles. Vous pouvez être à un niveau différent de prise de conscience — et c’est très sain. Vous pouvez aussi avoir des contraintes beaucoup plus fortes où d’autres choix seraient beaucoup plus valides. Pour ma part, je pense avoir assez d’outils pour continuer des expériences utiles où le facteur limitant n’est pas technique. Et si jamais il le devient, je serais ravi de savoir qu’il y a des personnes différentes qui sont prêtes à relever ces défis.
In Sanskrit, there’s a term called mudita, and there’s no equivalent word in English. Essentially, it means to have sympathetic or unselfish joy for others—regardless of where they’re at in their own lives. Really, if we spend less time envying or assuming that others think less of us because they’re in a different place than we are, then it becomes easier to focus on what’s important to ourselves.
Ibid.
Chacun sa route, chacun son chemin. Passe le flux RSS à ton voisin (ou ta voisine).