Les plus récentes en premier, les 3 premières sont dépliées et ensuite c’est à la demande, bonne exploration !
Composants (2021-11-03)
Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers. Remember how exciting it was every time we got new shiny HTML elements that actually do stuff? Remember how exciting it was to be able to do sliders, color pickers, dialogs, disclosure widgets straight in the HTML, without having to include any widget libraries?
The promise of Web Components was that we’d get this convenience, but for a much wider range of HTML elements, developed much faster, as nobody needs to wait for the full spec + implementation process. We’d just include a script, and boom, we have more elements at our disposal!
Le constat ne souffrait pas d’ambiguïté il y a un an. Qu’en est-il aujourd’hui ?
Il y a Simon Willison qui commente un Web Component tenant dans un seul fichier (cache). Et Dave Rupert qui parle de leurs super-pouvoirs (cache). Tout le monde espère pouvoir les utiliser nativement (cache).
En attendant, il y a des petits frameworks comme Tonic ou Lego. Des plus conséquents comme Lit.
Tout espoir n’est pas perdu. Juste une décennie.
API statique (2021-06-17)
Discussion avec les pyrates au sujet de blogs, d’articles, d’API et de minimalisme. J’imagine qu’un générateur d’API statique est possible, on est plutôt habitué·es à produire du HTML (qui est lui-même un format d’échange possible) mais on pourrait tout aussi bien générer un flux en JSON ou tout autres petits fichiers statiques pré-générés.
La dernière fois que j’ai essayé c’était pour tenter de créer un flux mastodon de manière statique ici-même mais la barre était trop haute pour ma maigre connaissance de cette combinaison de protocoles. Surtout que je n’avais pas vraiment d’autre intérêt que l’exploit technique en lui-même.
Il faudrait que je maintienne une page de tout ce que je n’ai pas réussi à faire pour compenser des chaînes plus reluisantes. Pour équilibrer. J’imagine que ça en dirait encore davantage sur mes compétences et ma capacité à me laisser échouer sur une page (web).
Et pendant ce temps là 🤩 :
They are little challenges I give myself, usually without too many stakes involved, and with small enough a scope so that I can ship it in a day or two, while keeping spare family time.
In·dépendance (2021-03-13)
I read a lot of other people’s code. I highly recommend it. One of my golden rules is that you shouldn’t blackbox things you don’t need to. I like to “use dependencies for efficiency, not ignorance.”
When I’m vendoring code - copying it into the project and making it pass my basic eslint & testing standards, I’ll do light rewrites and refactors of new code, allowing me to get a deeper understanding of how they work and where their limits lie.
[…]
And sometimes, sure - I’ll read through a dependency, start refactoring, and realize that it’s going to be simpler to write it myself, or I should find another option. It doesn’t matter if something is a dependency or my code: when you ship a product, it’s all your responsibility.
C’est l’une des raisons pour lesquelles j’essaye d’aller le plus loin possible avec un produit sans avoir de système de dépendances JS autre que la récupération du build qui est présent sur le dépôt source (s’il n’y en a pas, tant pis…). Le fait de copier manuellement ce fichier sur mon propre dépôt donne du poids à la dépendance, ce n’est pas une simple ligne dans un fichier. Un effet de bord que j’apprécie beaucoup aussi est de pouvoir identifier et corriger les bugs localement plus facilement.
Cela me rappelle les pistes que j’explorais déjà il y a 5 ans, notamment la partie sur les budgets.
Castors (2021-02-18)
Déplier pour lire le contenu de la publication
Construire soi-même sa maison, quand on n’est pas du métier, cela peut sembler mission impossible. Et pourtant, c’est ce qu’ont fait des milliers de Français dans les années 1950, avec le Mouvement des Castors. Des agriculteurs, des cheminots, des ouvriers… sont devenus des autoconstructeurs.
Ils sont même allés encore plus loin : plutôt que se concentrer sur leur maison individuelle, ils se sont regroupés pour construire ensemble des quartiers entiers. « Les gens qui travaillaient sur les maisons ne savaient pas si c’était la leur ou celle du voisin, une fois qu’elles étaient terminées, elles étaient tirées au sort », explique Eric Tortereau, co-président de l’association des autoconstructeurs Castors Rhône-Alpes.
Ils construisaient leurs maisons tous ensemble puis les tiraient au sort : l’histoire des Castors (cache)
Je me surprends parfois à rêver d’un tel avenir post-Covid. J’imagine que ça n’est pas (encore ?) suffisamment dévastateur pour que l’on en arrive à une telle solidarité. Peut-être à la prochaine marche de notre descente énergétique ?
Réparation (2021-02-05)
Déplier pour lire le contenu de la publication
A heavier and well-designed object feels different. You don’t have it always with you just in case. You don’t throw it in your bag without thinking about it. It is not there to relieve you from your boredom. Instead, moving the object is a commitment. A conscious act that you need it. You feel it in your hands, you feel the weight. You are telling the object: « I need you. You have a purpose. » When such a commitment is done, the purpose is rarely « scroll an endless stream of cat videos ». Having a purpose makes it harder to throw the object away because a shiny new version has been released. It also helps draw the line between the times where you are using the object and the times you are not.
Besides sturdiness, one main objective from the ForeverComputer would be to use as little electricity as possible. Batteries should be easily swappable.
Superbe initiative. Je suis en train de creuser le monde de la vidéo et (bien que chaque fabricant de matériel ait son propre format, batterie, stockage, etc.) je me demandais à quoi pourrait ressembler un ordinateur avec écran indépendant et alimenté par sa propre batterie comme ceux que l’on peut connecter à une caméra depuis son port HDMI. Je vois bien la contrainte mais je vois aussi la modularité et la possibilité de changer des pièces indépendamment les unes des autres.
Un petit bémol sur la partie chiffrement, je ne pense pas que ce soit un pré-requis pertinent pour limiter la consommation énergétique de ce ForeverComputer. À la limite, un hash pour vérifier l’intégrité des fichiers après leur copie et suivre leur évolution mais tout ce qui a trait à la cryptographie évolue trop au cours du temps à mon avis. Sans compter qu’en perdant la clé de déchiffrement, on perd les contenus qui vont avec, ce qui me semble à l’opposé de l’idée de pouvoir les conserver plusieurs décennies.
J’apprécie aussi l’approche qui consiste à commencer par faire un petit pas avec WriteOnly qui permettrait de tester la partie usage avant de passer à la suite.
To mend is to comprehend a human scale problem, and without this understanding our creations become strange creatures. We see this in the common examples of our time, from architecture to websites: Things used daily that, inexplicably, do not seem to be invented for human use. In the case of housing, bad architecture treats a human-scale environment as if it were a commodity-scale problem. The creators of some places see inhabitants not as humans but parameters. I do not need to spoil your view with visions of this architecture, I only wonder, what have their creators ever repaired?
Complexité (2021-02-02)
Déplier pour lire le contenu de la publication
As much as we talk about avoiding complexity in our programs, we seem to love the complexity of the tooling around our programs. As Ousterhout notes, every time you add a tool or configuration to a project, you’re adding an element that developers must learn, be aware of, or at minimum be exposed to. So while we think we’re lowering the bar of contributing and collaborating on a project — which may be true for some people — it’s possible we’re actually excluding people from contribution and collaboration because of the overwhelming complexity of our team of robots.
Suite de mes réflexions sur le sujet (et en fait il s’agit d’un truc autour duquel je tourne depuis pas mal de temps), je doute de plus en plus de la pertinence de ces enchaînements d’étapes à chaque commit/push. Ma difficulté actuelle est de faire la distinction entre les moments où c’est important et ceux où ça peut être facultatif (et potentiellement le rendre désactivable). On peut rapidement être nostalgique (cache) d’un temps où l’on n’avait pas tout ça mais je me rappelle aussi du renommage des fichiers en direct sur le serveur et des conflits ou des oublis lorsqu’on travaille à plusieurs dessus, etc. C’était l’enfer et c’est bien pour cela que l’on s’est outillé un minimum depuis.
Il y a probablement un entre-deux plus sain à trouver. Et en fait plusieurs en fonction du contexte. Je regrette parfois d’avoir lâché du lest sur certains aspects, j’en apprécie d’autres au quotidien. Une histoire de compromis.
The technology stack was not the limit we faced in this project over the years. It was rather the abstractions we created our own that got in our way.
Maintaining JavaScript applications in the long term (cache)