Page de recherche dans les notes du jardin numérique de Stéphane Klein

En travaillant sur l'issue "Je souhaite arriver à afficher un { en svg entre les lignes du mois de juillet et décembre et d'y afficher un texte" #JaiDécouvert Rough.js.

#JeSouhaiteÉtudier Pijul (from).

Voici le résultat de mes recherches d'alternatives à Docusign.

YouSign est un service de signature électronique Français basé à Caen, lancé en 2013, en mode SaaS.

LibreSign, projet brésilien, lancé en 2020, disponible en mode SaaS. Le code source semble disponible sous licence AGPL. Ce projet est une application Nextcloud : https://apps.nextcloud.com/apps/libresign. Je trouve ce choix très judicieux 🙂. Le projet semble bien actif, développé principalement par Vitor Mattos.

Concord, service SaaS de signature électronique fondé en 2014 par des Français (CEO Matt Lhoumeau, CTO Florian Parain).

BulkSign, projet d'un Indie Hacker néerlandais, nommé John Fonesca. Le projet n'est pas open-source, mais propose une version OnPremise : https://bulksign.com/main/OnPremiseVersion.html.

Lex Persona, encore un service Français, un projet lancé par François Devoret en 2005 depuis Troyes à taille humaine (11 personnes).

Documenso, une Open Startup (https://documenso.com/open) lancée en 2023 par un allemand nommé Timur Ercan et un australien nommé Lucas Smith. Le code source est disponible sous licence AGPL. Le développement est plutôt actif avec 4 développeurs.

Cosuno est un service de signature électronique allemand en mode SaaS.

#JaiDécouvert la fonctionnalité Skew Protection de Vercel : Introducing Skew Protection.

#JaiLu aussi Version Skew.

#JeMeDemande comment implémenter le même système que la fonctionnalité Skew Protection de Vercel en self hosted, par exemple, avec SvelteKit 🤔.

J'ai lu cet article de Ploum : De la merdification des choses.

Je fais le même constat que Ploum 👌.

#JaiDécouvert le projet PrivateGPT (https://github.com/zylon-ai/private-gpt).

Cela fait plusieurs mois que je souhaite trouver une solution pour self hosted une alternative à ChatGPT. J'ai bien envie de tester ce projet.

#JaiDécouvert Gitbi, Evidence et Observable.

Je suis président du club de Tennis de Table d'Issy-les-Moulineaux depuis le début de l'année. Cette fonction me prend beaucoup plus de temps que je ne l'imaginais initialement, et j'ai du mal à quantifier précisément cette charge de travail. J'ai l'impression qu'elle est importante, mais j'hésite : représente-t-elle un jour par semaine ? Deux jours ? Ou est-ce simplement ma perception qui me trompe ?

J'ai l'intuition que cette mission est trop lourde pour quelqu'un qui exerce une activité professionnelle. Je pense qu'elle ne peut être remplie efficacement que par une personne à la retraite, disposant de suffisamment de temps et d'énergie pour gérer tous les aspects administratifs et organisationnels.

Si je dois prématurément démissionner, je souhaite pouvoir rationaliser ma décision. Je veux la fonder sur des mesures concrètes et précises, et non sur un simple sentiment.

Pour cela, #JaiDécidé d'essayer d'utiliser l'application quantified self de suivi du temps nommée Toggl Track pendant 1 mois, afin d'avoir des données précises pour analyser la répartition de mon temps sur différentes activités :

Tâches domestiques (préparation des repas, ménage, vaisselle) ;
Mon emploi en CDI ;
Lecture ;
Hobbie : coding, apprentissage, veille technologique ;
Sport (Footing, Tennis de Table) ;
Repas et restaurant ;
Transports ;
Tâches liées à mon rôle de président de club ;
Temps de sommeil.

Je me demande si je vais être assez discipliné pour faire ce suivi.
Je suis curieux de savoir ce que vont m'apprendre ces mesures !

#JaiLu l'article Don’t Build A General Purpose API To Power Your Own Front End.

TL;DR YAGNI, unless you’re working in a big company with federated front-ends or GraphQL.

It’s popular in web dev nowadays to build a backend that serves JSON, and a frontend that renders the app. This is fine. I’m not the biggest fan, but it’s really okay. Except it’s not okay if you think that your backend needs to be designed like a generic public API. This will not save you time.

Je partage à 100% cette opinion.

J'ai un peu exploré le sujet CRDT (Conflict-free Replicated Data Type), voici ce que j'ai trouvé et étudié :

Article Wikipedia : Conflict-free replicated data type
https://crdt.tech
Peritext: A CRDT for Rich-Text Collaboration
https://automerge.org/docs/hello/ (Automerge)
https://github.com/yjs/yjs (Yjs)
https://rxdb.info
https://syncedstore.org (SyncedStore basé sur Yjs)
Designing the Delta Format

Les librairies qui m'intéressent le plus sont Yjs et Automerge.

Pour accélérer un peu la vitesse de chargement de https://sklein.xyz et améliorer mon score Lighthouse, j'ai activé la compression Brotli dans nginx.

Voici le dépôt GitHub qui convient le Dockerfile de l'image Docker qui j'utilise : nginx-brotli-docker.

Cette image contient nginx + le module ngx_brotli.

J'en ai profité pour étudier un peu l'histoire de Brotli.

Je découvre que Brotli a été créé par un employé de Google pour accélérer le chargement fontes de caractères :

Google employees Jyrki Alakuijala and Zoltán Szabadka initially developed Brotli in 2013 to decrease the size of transmissions of WOFF web font.

source

Le support de Brotli semble avoir été ajouté à Firefox en janvier 2016 et à Chrome en avril 2016.

Au sujet de son nom :

Comme pour zopfli, un autre algorithme de compression de Google, Brotli porte le nom d'une viennoiserie suisse. C'est la transcription de Brötli (petit pain en suisse allemand).

source

Concernant les performances, je lis :

Compared to gzip compression, JavaScript files compressed with Brotli are roughly 15% smaller, HTML files are around 20% smaller, and CSS files are around 16% smaller.

source

Le changement n'est pas "exceptionnel", mais comment c'est simple à activer, autant en profiter 😉.

Voici ce que cela donne pour le téléchargement de la page https://sklein.xyz/fr/ :

$ curl -s -H "Accept-Encoding: gzip" -o /dev/null -w "%{size_download}\n" https://sklein.xyz/fr/
5566

$ curl -s -H "Accept-Encoding: br" -o /dev/null -w "%{size_download}\n" https://sklein.xyz/fr/
4846

5566 octets pour gzip
4846 octets pour Brotli

Je viens de commander un Thinkpad T14s AMD Gen 3 :

ThinkPad T14s Gen 3 (Notebookcheck review)
- Processeur AMD Ryzen 7 Pro 6850U (2,70 GHz jusqu’à 4,70 GHz)
- GPU : AMD Radeon 680M
- Memory - 32 Go LPDDR5 6400MHz Soudée
- Solid State Drive - 512 Go SSD M.2 2280 PCIe Gen4 TLC Opal
- 14" WUXGA (1 920 x 1 200), IPS, anti-reflets, non tactile, 72 % NTSC, 400 nits, panneau étroit, faible consommation
- Wireless - Qualcomm Wi-Fi 6E
- 1,22 kg
- « Battery life was great with Linux on the T14s. I was getting somewhere near 18 hours »
- 1740 € HT

#JaiDécouvert Linkding.

#JaiLu « On dit que l’amour dure trois ans : en entreprise, c’est le temps qu’il faut désormais pour faire le tour d’un poste », je me demande si cela pénalise la productivité en limitant la constitution d'une mémoire transactive] forte 🤔.

#JaiDécouvert la Mémoire transactive.

Quand je dis « j'aime travailler dans une équipe sur le long terme, tout devient fluide, elle a une culture commune… », #JeMeDemande si cela veut dire que j'aime la mémoire transactive 🤔.

#JeMeDemande si la mémoire transactive équivaut plus ou moins à une culture de travail ? 🤔.

Pour effectuer une rotation du layout de mes windows Neovim comme la commande ctrl-b space sous tmux, j'ai trouvé les combinaisons de raccourcis suivantes :

ctrl-w J
ctrl-w H

Attention, les majuscules sont importantes.

2025-01-27 : voir 2025-01-27_1051.

En lien avec la thématique Pets vs Cattle, #JaiLu

Je trouve que Best current practice est intéressant pour éviter de tomber dans la rigidité d'un process 🤔.

Je pense que je vais l'utiliser.

#JaiDécouvert le terme technique Best Current Practice (https://fr.wikipedia.org/wiki/Best_Current_Practice).

Voici une liste de communautés qui utilisent le concept de RFC :

Python : PEP
PHP : RFC
Go : Proposing Changes to Go
Kubernetes : Enhancements tracking repo for Kubernetes
Rust : RFCs for changes to Rust
Ember : RFCs for changes to Ember
Iced : https://github.com/iced-rs/rfcs

Une illustration des conséquences de la "Pensée magique" ou "Pensée désidérative" : L’accident de Tchernobyl expliqué par le Dr V. Legassov (Série Chernobyl (mini-série)).

#JaiLu ce thread Hacker News : Why our team cancelled our move to microservices.

There is no reason even a significantly larger org - say 40+ people in 8-10 teams cannot work effectively in a single repository and monolith architecture. Beyond that there are certain growing pains and if you don't effectively manage those then I could see how you end up going with micro-services.

source

Je partage cette opinion 👍️.

J'ai acheté un Serveur NUC i3 d'occasion pour 150 € sur LeBonCoin, avec pour objectif de l'utiliser comme serveur Homelab.

Je prévois d'y installer Proxmox pour déployer des Virtual Instances.

Je viens de déjeuner avec un ami qui m'a fait découvrir le livre Team Topologies.

Cela fait des mois que je me demande comment nommer le repository #Git « chapeau », « umbrella » qui est le starting point d'une boite ou d'un projet.

J'ai trouvé une réponse chez GitLab, {compagny_name}-development-kit : https://gitlab.com/gitlab-org/gitlab-development-kit.

Ce repository est un "development kit".

Ce mois de janvier est riche en article au sujet des Monorepo !

#JaiLu le contre pied du l'article "Monorepos: Please don’t" : Monorepo: please do! !

As a leader, I’ll pick the monorepo every time: because tools must reinforce the culture I want, and culture comes from the tiny decisions and behaviors of a team every day.

source

👌

Son thread Hacker News : 161 commentaires.

#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos and the Fallacy of Scale | Hacker News".

J'ai trouvé l'article très intéressant ainsi que les commentaires.

#JaiLu ce thread Hacker News au sujet des Monorepo : "Monorepos: Please don’t".

Il contient de très bons commentaires biens argumentés qui expliquent les avantages des Monorepo, j'ai trouvé cela passionnant 🙂.

Au début, j'avais une sorte de jouissance à créer des dépôts pour chaque service de mon projet (je précise que tout seuls, ils ne servent à rien), j'avais l'impression d'être un bon élève. Mais, que c'est pénible d'en maintenir une cohérence ! Je suis plus heureux en Monorepo.

-- Témoignage d'un ami

#JaiDécouvert le nom du Monorepo de DigitalOcean : Cthulhu 😉.

Confusion à ne pas faire « Monolith ≠ Monorepo :

Monolith

Monolith ≠ monorepo. Monolith is huge amount of coupled code of 1 application that is hell to maintain.

source

Un projet en microservice peut très bien être hébergé dans un Monorepo.

J'ajoute aussi Multirepos ≠ microservices.

Il est tout à fait possible — voire courant — d'héberger un Monolith dans plusieurs repositories, mais d'après mon expérience, cela s'avère peu pratique, je peux même dire, pénible !

#JaiDécouvert le site "Advantages of monorepos" (https://danluu.com/monorepo/).

Avantages :

« Simplified organization » 👌
« Simplified dependency management » 👌
« atomic changes » 👌
« Extensive code sharing and reuse » 👌
« Unified versioning, one source of truth » 👌
« Code visibility and clear tree structure providing implicit team namespacing » 👌
« Large-scale refactoring » 👌
« Collaboration across teams » 👌

Dans la vidéo ThinkerView "Blockchain, gouvernance et énergie ? Primavera De Filippi et Remy Bourganel", j'ai entendu Primavera De Filippi parler de l'article "La tyrannie de l’absence de structure" que j'ai trouvé extrêmement intéressant.

Je viens d'ajouter le contenu du Mail de Musk en 2010 « Les acronymes sont vraiment à éviter » dans la documentation guidelines du projet professionnel sur lequel je suis en train de travailler actuellement.

Pourquoi ?

Dans un souci d'efficacité, j'aime recevoir des informations le plus explicites possible, afin d'éviter des quiproquos, de minimiser mes risques d'erreurs, d'éviter de faire perdre du temps à mes collaborateurs en posant une multitude de questions.

Comme j'essaie de suivre la règle d'or, j'essaie moi-même de communiquer de la façon la plus explicite possible — je précise que ce n'est pas simple, même avec la meilleure volonté du monde !

C'est pour cela que j'évite au maximum de créer et d'utiliser des acronymes.

Voici quelques extraits du Mail de Musk 2010 « Acronyms Seriously Suck ».

L'utilisation excessive d'acronymes inventés est un obstacle important à la communication et il est extrêmement important de maintenir une bonne communication au fur et à mesure que nous nous développons.

👍️

Personne ne peut se souvenir de tous ces acronymes et les gens ne veulent pas avoir l'air stupides lors d'une réunion, alors ils restent assis dans l'ignorance. C'est particulièrement difficile pour les nouveaux employés.

Je suis tout à fait d'accord avec cette déclaration 👍️.
J'ai appris par expérience que la majorité des humains ne posent pas de question quand ils ne connaissent pas un mot ou un sujet.
J'essaie personnellement de mettre mon égo de coté et de poser la question, mais il m'arrive aussi de ne pas le faire.

D'autre part, ma mémoire est limitée, l'apprentissage des acronymes internes d'une organisation ou d'une équipe me demande trop de charge cognitive.

Un acronyme que la plupart des ingénieurs en dehors de SpaceX connaissent déjà, tel que GUI, peut être utilisé.

Je suis tout à fait aligné avec cette pratique👍️.

Personnellement, je suis la règle suivante : j'ai le droit d'utiliser un acronyme à condition qu'il soit référencé par une page Wikipedia et que la liste de ses homonymes sur sa page "disambiguation" soit très courte dans mon contexte d'utilisation (exemple pour FTP). Si ce n'est pas le cas, je n'utilise pas l'acronyme.

#JaiDécouvert direnv : Automating development environment set-up with Direnv.

J'ai été perturbé par le contenu des slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos (voir 2017-12-03_1217).

J'ai continué à étudier le sujet des Monorepo et j'ai commencé à migrer un side project vers ce pattern. Pour le moment, l'expérience est très agréable. Je pense que je vais continuer dans cette direction.

#JaiLu les slides « Monolithic repositories vs. Many repositories » de Fabien Potencier : https://speakerdeck.com/fabpot/a-monorepo-vs-manyrepos.

#JaiDécouvert l'outil Git Subtree Splitter (https://github.com/splitsh/lite).

Le chapitre Le boycott du bus de Montgomery - Comment naissent les mouvements de société ? du livre Le Pouvoir des Habitudes Changer un rien pour tout changer m'a profondément marqué.

#JeSouhaite creuser le sujet.

« Bye bye Mediapart, bonjour Brief.me »

C'est décidé, je vais me désabonner de Médiapart. Ce n'est pas du tout parce que je ne les aime pas, au contraire, j'adore. Mais, je souhaite m'abonner à https://www.brief.me/ qui correspond plus à mon besoin, une info rapide à lire, qui ne mise pas sur l'émotion (à la différence de TF1, BFM…). Et comme je ne souhaite pas multiplier mes abonnements en ligne, j'arrête Médiapart.

Posté sur Facebook : lien

http://polemarchakis.org/

https://www.has-sante.fr

Hasura est en autre un GraphQL engine, codé en Haskell et TypeScript.

The open-source Hasura GraphQL Engine makes your data instantly accessible over a GraphQL API, so you can build and ship modern, performant apps and APIs 10x faster.

-- from

Hasura est une alternative à PostGraphile et Supabase.

Site officiel : https://hasura.io/

Documentation officielle :