David Delassus a écrit 747 commentaires

Alors, sur un screenshot on le voit pas, mais les lignes sont "animées" ce qui aide à la visualisation :)

Après, c'est surtout que je voulais faire tenir l'ensemble de la pipeline sur la capture d'écran. De toute façon, il y a plein de choses à améliorer sur le design.

React Flow offre la possibilité d'agencer les noeuds automatiquement, mais non, ici c'est bien moi qui ait fait ça ^{^}

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Sisi, l'outil stocke bien les données.

Mon choix s'est porté sur BadgerDB car c'est une base de données clés/valeurs très solide et distribuée sous forme de librairie Go.

Une base de données SQL implique d'avoir un schéma, ou de s'en servir comme une base de donnée clé/valeur.

Pour ce qui est de la structure de données sous jacente, BadgerDB utilise un LSM Tree ( https://en.wikipedia.org/wiki/Log-structured_merge-tree ) ce qui se prête très bien aux données que je désire stocker.

De plus BadgerDB supporte les transactions ACID (la plupart des base de données SQL aussi cela dit), donc il n'y a aucun inconvénient à l'utiliser.

En utilisant une base de données clés/valeurs, j'ai aussi un meilleur contrôle sur la structure de données pour les indexes.

Je t'invite à lire ce document : https://github.com/link-society/flowg/blob/main/docs/design/storage.md
Il est peut être incomplet, donc tout retours dessus est bienvenu :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Effectivement, pour le travail je communique principalement en Anglais (notre équipe est composés de personnes de plusieurs pays d'Europe différents, l'Anglais est le dénominateur commun). J'en oubli souvent mon Français.

J'ai fait des efforts ici pour essayer de traduire au mieux, mais j'ai du mal :)

on a un opinion défavorable de ELK pour aucune raison valable si ce n'est qu'on aime pas.

C'est le sentiment que je voulais partager ^{^}

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Un binaire qui embarque les fichiers statiques, ainsi que l'interpréteur VRL.

Dans ton PATH, tes binaires sont compilés dynamiquement, et n'embarquent pas de code JS, CSS, d'images, de fonts, …

Comparons ce qui est comparable. Ici l'empreinte totale de FlowG sur le disque après installation, c'est 40Mo.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

The year of the Windows Desktop!

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

La guerre c'est pas un sujet politique ?

Sinon, c'est quoi le lien avec Linux et le Logiciel Libre ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Déjà que je suis douteux de la pertinence des sujets politiques non directement liés à Linux ou à l'OpenSource (mais bon, on me dit souvent que le libre c'est de la politique…), là c'est clairement un sujet va attiser les conflits et tensions entre les membres et ne risque pas d'apporter quoi que ce soit de bien ou d'intéressant au site.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

1) Anglicisme c'est un emprunt à l'anglais, ici c'est un mot anglais re-traduit en français, donc bien une francisation et non un anglicisme. Quitte à être chiant, autant l'être jusqu'au bout non ?

2) Je suis pas le seul a utiliser ce mot dans ce sens, pourquoi me reprendre moi et pas les autres ?

3) Tu as ton avis, une bibliothèque c'est à propos de livres (bibli), ici on n'a pas de lives. On a parfaitement le droit de ne pas adhérer aux traductions classiques de LinuxFR

4) En fait, je n'adhère même pas à cette manie de tout vouloir traduire. cadriciel ? sérieusement ?

le cuisinier, c'est quel meuble — à des fins d'équité ? /o\

Ce genre d'équité à la mord-moi-le-noeud, je m'en contre fiche.

---

Bref, t'as eu envie d'être chiant et trolleur alors qu'on n'est pas Vendredi. C'est triste de voir les traditions se perdre.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Une librairie c'est aussi la francisation du terme anglais "library" qui veut dire bibliothèque, contrairement à "book shop".

Donc, ne pas confondre librairie et librairie. Tout comme il ne faut pas confondre cuisinière (la machine) et cuisinière (la personne).

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

pire 2 librairies peuvent dépendre de JQuery mais de versions différentes

La faute à celui qui audit pas ses dépendances ;)

mais les développeurs continue a l'utiliser alors qu'il n'apporte plus grand chose

Il y a d'abord l'argument subjectif : l'API de jQuery est plus sexy/concise/lisible que l'API vanilla.

Et ensuite, il y a l'argument un peu moins subjectif : jQuery apporte encore beaucoup, notamment tout un écosystème de plugin :

• des carousels
• des date/time pickers
• des flowcharts
• …

Quand tu as un site majoritairement statique, avec quelques petits endroit ou un widget interactif peu être sympa, ne pas avoir à utiliser React/Vue/Angular qui est bien plus intrusif, c'est pas déconnant.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Non c'est 2 librairies :

• https://www.npmjs.com/package/is-even
• https://www.npmjs.com/package/is-odd

Heureusement, il existe des libs permettant de les différencier :

• https://www.npmjs.com/package/is-is-even
• https://www.npmjs.com/package/is-is-odd

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Si on se mets à écrire : […] C'est que l'on n'a rien compris à HTMX.

Pour information, c'est ce que j'avais tendance à faire à mes débuts avec HTMX.

Je venais de passer 5 ans à splitter un backend monolithe en architecture micro service. Et j'étais hypé par la notion de "micro frontend", et je comprenais pas qu'on parlait de "micro frontend" pour des applications React/Vue, qui me semblaient être des monolithes modulaires (je n'ai rien contre cette architecture).

Ma première impression de HTMX fut donc de fournir des bouts de frontend en provenance de serveurs distincts.

Je vous dis pas la monstruosité d'over-enginering que j'avais pondu à l'époque (circa 2021, bien avant la hype récente de HTMX). Les bugs d'affichage impossible à debugguer car j'avais foutu un <body hx-boost="true">.

En gros, j'essayais de faire une SPA (Single Page Application) avec HTMX, et c'est clairement pas le but du projet.

Bref, j'avais rien compris à HTMX.

---

Ensuite j'ai pris du recul, j'ai refait du Django sans API REST/JSON, template côté serveur, et tout le tralala.

Et puis les rares moments ou je me suis dit "tiens, ça serait bien que le serveur puisse m'envoyer un peu de HTML à rajouter ici", c'est là que HTMX est venu à mon aide.

Un cas d'usage que j'apprécie tout particulièrement désormais : Un système de notification.

Faites un endpoint SSE (Server Sent Event) côté serveur, qui envoit le contenu suivant :

event: notify
data: <p>some HTML for a notification</p>

Côté client :

<div class="notification-container" hx-ext="sse" sse-connect="/path/to/sse/endpoint" sse-swap="notify"></div>

De la même manière, on peut créer un système de chat assez simplement :

<div class="chat-container" hx-ext="sse" sse-connect="/path/to/sse">
  <div class="history" sse-swap="message"></div>
  <form hx-post="/send_message" hx-trigger="submit">
    <input name="message">
    <button type="submit">Send</button>
  </form>
</div>

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Netbox utilise HTMX pour charger les formulaires des fenêtres modales.

En fait, il y a tellement de gens qui présentent HTMX comme un remplaçant de React que ça donne une mauvaise image de la chose.

Comparer HTMX et React c'est stupide.

Pour comprendre l'intérêt de HTMX, il faut faire un peu le point sur l'histoire du web dev :

• On commence avec du contenu statique, HTML / CSS servi par un serveur HTTP
• On génère ce HTML dynamiquement côté serveur (CGI Perl, CGI PHP, framework Python/Ruby/…, …) à chaque requête
• On a besoin d'interactivité côté client (fenêtres modales, formulaires dynamique, notifications, …), c'est là ou on introduit Javascript
• La compatibilité entre navigateurs est un problème, d'où jQuery
• C'est galère à organiser le code, du coup on créé des frameworks JS
• Ce qu'on veut en fait, c'est faire nos propres composants HTML, d'ou React/Vue/WebComponents/…
• Il s'avère qu'autant de JS côté client c'est lent, alors on veut du SSR (rendu côté serveur)

Et on est revenu au point de départ, un serveur qui retourne du HTML. A ce moment là, a-t-on besoin d'un framework JS ?

On a désormais les WebComponents pour créer de l'intéractivité côté client uniquement là ou il y en a besoin, HTMX 2.0 améliore sa compatibilité avec ces derniers justement (un meilleur support du shadow DOM).

HTML5 se dote d'éléments comme <summary> ou <dialog> rendant certains patterns en JS (comme la fenêtre modale) obsolète.

La proposition d'HTMX c'est de continuer à faire évoluer le HTML pour devenir le langage du web, au lieu que cela soit JS (ils sont d'ailleurs en discussion informelle avec des développeurs de navigateurs ainsi que le W3C pour incorporer certaines fonctionnalités de HTMX dans le standard, et donc implémenté par le navigateur). Il faut donc l'utiliser là ou ça fait sens. Si on se mets à écrire :

<div hx-get="/mycomponent" hx-trigger="load"></div>

C'est que l'on n'a rien compris à HTMX.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

procfusion est plus pour des services qui sont regroupés (ce qui aujourd'hui est plutôt géré par la notion de pod)

Dans 95% des cas, recourir à supervisord/procfusion dans un conteneur Docker, c'est un anti-pattern et un symptôme d'un conteneur qui devrait être splitté.

Je suis pas sûr de ce que tu entend par "pod" (mon cerveau influencé par kubernetes entend: un ensemble de conteneur), si on a la même définition alors on est d'accord : plusieurs services = plusieurs conteneurs.

Cependant, un service != un processus. Dans 95% des cas oui, mais dans les 5% restant, pas forcément. Comme par exemple un petit processus qui surveille un point de montage de volume avec inotify pour appeler nginx -s reload quand un certificat TLS est renouvelé.

procfusion, c'est pour ce cas là précisément.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Merci pour le retour :)

écrire de manière aussi élégante et concise!

Oh malheureux, si tu avais vu mes premiers drafts :)

Rust async est un peu ma bête noire, car c'est fondamentalement différent de Rust sync. Petit exemple :

Avec Rust sync, j'ai tendance a vouloir passer mes données par référence, pour éviter de consommer inutilement de la mémoire.
Parfois, cela veut dire d'utiliser RefCell<_> comme type pour un champ d'une structure et donc de déléguer au runtime (au lieu du compile time) la vérification des invariants (aka: oui, je suis bien le seul a vouloir modifier cette valeur à l'instant t).

L'équivalent async, c'est Arc<Mutex<_>> qui arrive avec son lot de problèmes. La mutex possède un lock, et je me suis retrouvé dans une situation ou j'avais une tâche asynchrone (tokio::spawn) qui avait besoin de lock la mutexe durant toute sa durée de vie, rendant la resource derrière inutilisable par toute autre tâches asynchrone. Aïe, aïe, aïe.

Du coup, au lieu d'essayer de partager une donnée entre plusieurs tâches asynchrone via des références, j'ai mis en place un système de canaux pour échanger les informations nécessaire pour que chaque tâche puisse faire son travail. Cela a voulu dire transformer certaines fonctions en tâche asynchrone, et cloner des mpsc::Sender<_> à droite à gauche, au lieu d'essayer de partager un Arc<Mutex<_>> correctement.

A et aussi rendre une structure clonable et la dupliquer plus que nécessaire, par flemme.

Au final, quand je code en "Rust sync", mon cerveau est en mode "fonctionnel à la C/C++".

Quand je fais du code en "Rust async", je dois passer mon cerveau en mode "Erlang/Elixir".

Je suis loin d'être un expert, et ce code est loin d'être le mieux qui soit, plein d'axe d'amélioration. Heureusement, ce cas d'usage n'est pas critique concernant la performance en temps CPU et en RAM utilisée. Le léger overhead que j'introduis devrait être négligeable (bien que optimisable).

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Lua ne suit pas le semantic versioning

Oui, c'est pour ça que j'ai dit "comme".

les versions sortent à dates aléatoires

Rien de choquant la dedans. En fait, très peu de logiciels ont un rythme de sortie de version.

la dernière version rend la précédente obsolète.

Rien de choquant la dedans. Très peu de logiciels ont des "LTS" (long term support).

Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.

Oui, on a bien compris que tu n'aimes pas Lua et que tu le déconseille pour de la production. Mais ici, c'est un projet pour le fun, donc on s'en fou. Celui qui va partir en production avec ça mérites tout ce qui lui arrive.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Un essai a déjà été fait chez NetBSD et ça mène à rien.

Ici c'est pas un projet officiel, et ça a l'air d'avoir été fait principalement pour le fun.

Lua est un mauvais langage […]

Opinion totalement subjectif.

[…] fait par trois développeurs qui s'intéressent qu'à eux […]

C'est pas parce que le développement se fait de manière privée, sans accepter de contributions, que les devs ne s'intéressent qu'à eux même.

Et quand bien même, cela n'a aucun rapport avec la qualité du dit projet.

faisant chaque version un cassage de l'API C et l'API Lua

Entre chaque version majeure oui (si on oubli le 5. devant). Effectivement 5.4 a des incompatibilités avec 5.3, 5.3 avec 5.2, etc… Elles sont toutes documentées. Mais entre 5.4.0 et 5.4.1, jusque 5.4.6, pas de changement cassant.

C'est tout comme en Semantic Versionning, changement cassant -> nouvelle version majeure. Ce sont des choses qui arrivent dans absolument tout les projets.

Si vous voulez perdre du temps, foncez.

Personne n'a dit "allez utiliser ça en prod", surtout quand le cas d'usage est bien mieux répondu par eBPF.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

faire croire aux managers que la technique rebute

En tant que personne technique, je peux t'assurer que moins j'écris de code, et moins j'ai de choses techniques non automatisées à faire, mieux je me porte.

Et en tant qu'entrepreneur, j'ai appris à la dure que la technique/technologie, ça ne se vend pas.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

certains messages laissent entendre que Vaxry, parce qu'il serait transphobe (j'ai encore rien vu qui confirme ou qui infirme ce point) […]

Cela remonte à 1 an ou 2, quand une personne sur le Discord a changer son pseudonyme pour inclure ses pronoms. Ce dernier a édité le pseudonyme pour les remplacer par "who/cares" et a bloqué la fonction d'édition des pseudonymes sur son serveur.

Car apparemment, vu qu'il s'en fous, il est obligé de réagir à ça ;)

Il se serait excusé en disant "pardon, j'aurais du ban cette personne à la place".

Car apparemment, vu qu'il s'en fous, il est obligé d'exclure la personne ;)

Après, la-dite personne a annoncé faire exprès de changer son pseudonyme de cette manière car elle savait que cela mettrait des gens en colère sur le Discord.

Bref : lancé de fion au lieu de coder.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

C'est con, car Netlify est gratuit pour les projets OpenSource (après, ça reste une entreprise privée capable de retirer cette offre gratuite, certes). Donc regarder la page Pricing, c'est pas déconnant.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Parce qu'on a pas le droit de vendre du libre c'est ça ?

-_-"

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Plus tu fais de la relation publique, moins tu fais du code.

Avoir une communauté ok. Mais un Discord, salon IRC, subreddits, etc… en plus de juste un bug tracker ? Tu augmentes les chances d'attirer des connards (ou de montrer à tout le monde que c'est toi le connard).

Avoir tout ces medias en plus pour ta communauté te force à faire de la "politique", de la modération, etc…

C'est doublement con de la part de l'auteur ici. Il semble s'offusquer de certaines choses inhérentes à ces réseaux sociaux.

Si je suis volontairement sur un réseau qui permet aux gens de changer leurs pronoms, à quel moment c'est logique d'être offensé par les gens qui utilisent cette fonctionnalité ?

En plus, il répète souvent sur son blog "don't be an asshole, or don't be on the internet". Il me semble que du coup, si il arrive pas à supporter que des gens utilisent des fonctionnalités d'un réseau, peut être qu'il ne devrait pas être sur ce réseau.

Donc oui, pour moi c'est bien des gens qui se lancent des fions au lieu de coder, car ils se sont mis dans une situation propice à cela, sans forcément que cela soit si utile que ça.

Bien sûr, cela n'excuse pas le comportement de ces personnes, en aucun cas.

Après, dire "la communauté est toxique", je sais même pas ce que ça veut dire. C'est quoi "la communauté" ? 3 connards sur Discord ? Si j'utilise le logiciel sans jamais parler a qui que ce soit sur Reddit/Discord/Github/… je fais parti de la communauté ou pas ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

ils doivent convaincre les non techniciens en fait, qui eux savent déjà faire la même chose, mais sans Netlify.

Non au contraire. La page d'accueil de Netlify ne s'adresse pas à un non technicien qui ne comprendra pas 90% des termes utilisés.

Elle s'adresse à des techniciens qui savent faire cela eux même, et elle tente de les convaincre que ne plus le faire eux même et passer par leur solution.

Le self-hosting c'est bien, mais c'est chiant, c'est de la maintenance. Une solution clé en main ou j'ai juste a donner l'URL de mon dépôt Git et qui est gratuit (sauf pour les dépôts privés) ? Sign me in.

Je suis utilisateur de Netlify depuis pas mal de temps, et je suis bien content de ne plus payer un serveur dédié pour faire tourner un nginx et gérer moi même le déploiement automatisé.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

De ce que j'ai compris :

La communauté de Hyprland est accusé d'avoir la mentalité d'une bande d'adolescent de 16 ans en plus d'être transphobe. L'auteur principal semble aimer la provocation, et part du principe que les "Code Of Conducts" dans les projets OpenSource sont du bullshit inutile dans la majorité des cas. Ce qui du coup clash avec beaucoup de gens lors des discutions ou la-dite personne ne garde pas sa langue dans sa poche.

Au final, le projet Freedesktop en a eu marre, et l'ont banni.

Bref, des gens qui se lancent des fions au lieu de coder :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Peu de physiciens vivent pour voir leurs théories prouvées.

Le boson de Higgs (ou plus correctement, boson de BEH, pour Robert Brout, François Englert et Peter Higgs) fut hypothétisé en 1964.

En 2012, il a été confirmé à la suite d'expérimentations au LHC du CERN.

Einstein n'a jamais vu la photo d'un trou noir lui.

Qu'il repose en paix, il a accompli beaucoup pour la physique et la science.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg