Nal,
Je me décide enfin à libérer et présenter une appli que je développe plus ou moins activement depuis 8 ans à présent, j'ai nommé : Geeftlist.
Parce que "geek" et "gift" et "list", tout ça, tu saisis l'astuce.
C'est une application web, à peu près mobile-friendly, qui permet de créer des listes d'idées cadeaux pour ses proches, mais également de les partager et de coordonner leur achat.
J'ai fait une présentation en long en large et en travers sur mon blog donc je vais essayer de ne pas faire (trop) de redite ici. Si les détails et l'historique du projet vous intéressent, vous aurez de quoi étancher votre soif via le lien précédent.
L'idée est partie comme souvent/toujours d'un besoin personnel afin de simplifier les achats de cadeaux au sein de la famille, particulièrement avant les fêtes de fin d'année. On a commencé à gérer ça par téléphone, puis par email, mais franchement il n'y avait rien de vraiment adapté. Comme le principe m'intéressait et qu'il ne semblait pas exister d'appli libre pour répondre à ce besoin, je me suis dit pas du tout modestement "pourquoi pas moi ?".
Les objectifs identifiés étaient assez simples :
- s'assurer de faire plaisir à celui ou celle qui reçoit
- éviter les doublons
- limiter les communications laborieuses (souvent via des intermédiaires)
En 2016 j'ai donc commencé à concevoir et coder une appli qui permet de gérer des "idées cadeaux" (gifts) que l'on peut créer et affecter à un ou plusieurs "destinataires" (geeftees). Chacun peut suivre les cadeaux proposés pour les personnes de son entourage, les réserver, et laisser des commentaires si besoin ("C'est quelle édition qu'elle veut de l'intégrale de Bourdieu ?" 😜)
La notion d'"entourage" est liée à l'appartenance à des familles communes, le nom utilisé pour désigner les groupes d'utilisateurs sur un même serveur. De cette manière, Un serveur peut parfaitement héberger des personnes ou groupes de personnes n'ayant aucun lien sans qu'elles n'interagissent entre elles et donc ne se gênent.
Une famille est gérée par son créateur, qui peut accepter des nouveaux membres et en retirer certains (les ruptures, ça arrive).
Les idées cadeaux sont gérées par leur créateur qui peut la modifier à tout moment, préciser le prix estimé (ou un objectif de montant pour une cagnotte), une description, une image, et une règle de partage.
Pour ce dernier point, la règle par défaut est "toute personne de l'entourage du destinataire/geeftee", c'est-à-dire toute personne partageant au moins une famille avec lui/elle. Mais il est possible d'être plus précis et de ne partager une idée cadeau qu'avec une ou plusieurs familles, voire un ou plusieurs geefters. Il est même possible de créer une idée "privée" qui n'est donc visible que par son créateur. La visibilité pouvant évoluer au gré des besoins bien entendu.
À plus de cette règle de partage, il est également possible de créer un idée dite "à découvert", que le destinataire pourra voir. Quand le cadeau n'est pas une surprise, cela permet de pouvoir discuter de cette idée avec le geeftee pour être sûr de taper juste.
Afin que les membres d'une famille soient bien informés de l'activité de celle-ci (création de gifts, réservations, commentaires), des notifications par email sont envoyées régulièrement à toutes les personnes concernées. Même si les notifications sont regroupées par lot, il est possible de choisir la fréquence d'envoi afin d'éviter l'effet "spam" au mois de décembre.
Tout proche qui peut voir un gift peut le réserver, c'est-à-dire poser une option dessus (réservation simple "je prévois de prendre ça") ou signaler directement son achat ("j'ai pris ça, ne le prenez pas"), avec éventuellement à chaque fois un montant optionnel. Les autres membres sont immédiatement informés et peuvent ainsi agir en connaissance de cause.
Une fois le cadeau offert, un gift peut être archivé par son créateur, ou supprimé. L'effet est globalement le même pour les proches : il n'apparaît plus dans les listes des idées disponibles pour le ou les geeftees concernés. Pour le créateur en revanche il reste possible de "désarchiver" un gift si besoin (mais pas de le "désupprimer").
Il y a plein d'autres petites features complémentaires à droite à gauche que je ne vais pas mentionner ici, vous pourrez les découvrir à l'usage si le principe vous intéresse.
Pour la partie "administration" à présent… eh bien il n'y en a pas. Oui, pas d'interface d'admin ni rien, le gestionnaire de l'instance a à peu près les mêmes droits que n'importe quel autre utilisateur (sauf à aller consulter la BDD directement, évidemment). Ce n'est pas vraiment un choix, j'ai des idées très précises sur ce que j'aimerais obtenir mais je manque de temps pour m'y consacrer. En 7 ans d'utilisation, je n'ai eu à corriger de données en base qu'exceptionnellement, et à chaque fois cela a conduit à la création d'un patch correctif afin que le cas ne se reproduise plus.
Si vous voulez déployer une instance privée, c'est très simple à présent : il suffit d'utiliser la stack Docker Compose fournie dans les sources.
Je vous le conseille d'ailleurs fortement plutôt que d'utiliser l'instance publique car celle-ci n'a pas vocation à grandir indéfiniment et les inscriptions pourront être limitées selon le volume et l'impact que l'activité a sur l'hébergement (je n'affiche pas de publicité, je n'ai aucun tracking, et je propose seulement une participation aux frais via LiberaPay).
J'ai encore plein d'idées de fonctionnalités à implémenter mais les choix d'architecture faits initialement rendent les évolutions complexes. D'autant que mon temps est limité et ma motivation aussi. Comme tout marche très bien depuis déjà plusieurs versions et que les besoins sont couverts par l'existant, la maintenance consiste principalement à garder la stack applicative à jour, nettoyer le code et l'archi afin de tendre vers une simplification de l'évolutivité, et compléter les tests automatisés afin de couvrir le plus de cas possibles pour limiter les régressions.
Petit rappel des liens :
- Sources : https://codeberg.org/nanawel/geeftlist
- Présentation et historique du projet : https://lanterne-rouge.info/2024/05/geeftlist-gestion-collaborative-d-idees-cadeaux
- Repo Docker : https://hub.docker.com/r/nanawel/geeftlist
- L'instance publique : https://www.geeftlist.com
# Yay !
Posté par Epy . Évalué à 6 (+4/-0).
Bravo et merci pour ce projet libre :)
As-tu des infos (même un brouillon) pour l'auto-héberger sans Docker ? Sinon je tâtonnerai et ferai une doc si possible.
Encore un projet en attente que je peux mettre à la corbeille \o/, je n'aurais peut-être jamais pu arriver au bout n'étant pas assez expérimenté de toutes façons.
J'avais une feature dans ma liste, que je n'ai pas vue dans la rapide roadmap (et je n'ai pas encore lu entièrement ton long post sur l'historique de cette appli): la fédération entre serveurs. Cela permettrait de partager les listes de personnes sur des instances différentes.
Mais c'est une fonction loin d'être simple pour y avoir jeté un œil.
Chapeau encore !
[^] # Re: Yay !
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
Salut, et merci 🤗
Non je manque cruellement de docs j'avoue. Après l'avantage du Docker (quand on le parle un peu) c'est qu'il est "auto-explicatif". Cela étant, une grosse partie du boulot est réalisée en amont par mon process de build, donc si tu dois tout refaire tu risques de bien te prendre la tête (surtout sans doc, on y revient).
Qu'est-ce qui te freine dans l'utilisation de Docker ? Peut-être qu'on peut trouver un compromis.
Effectivement j'avais pensé aussi mais déjà c'est méga-complexe, et puis en y réfléchissant je me suis posé la question de la pertinence pour l'usage et les implications pour la confidentialité. Cela dit je comprends le besoin, mais je me demande comment le système pourrait fonctionner avec les règles de partage et la complexité du modèle de données que ça implique 😵💫
[^] # Re: Yay !
Posté par Epy . Évalué à 7 (+5/-0).
Je risque de me faire lyncher mais j'aime pas Docker, l'impression de ne pas gérer grand-chose, ça rajoute une couche inutile (j'utilise déjà LXC dans un proxmox), un réseau à part.. j'accède à toutes mes machines par leur nom sur le DNS, avec Docker la machine ne sera jamais connue du serveur de noms sauf à la saisir à la main. etc.
Et tout ça dépend d'une entreprise qui est là pour faire de l'argent… donc on a les expériences passées de comment ça se termine en général.
Je regrette surtout que cela devienne la seule méthode d'installation proposée sur de nombreuses applis auto-hébergeables avec du coup zéro doc pour faire autrement. Dommage aussi de perdre les quelques utilisateurs professionnels qui n'auraient pas le droit à Docker pour des raisons de sécurité/maitrise complète dans un environnement sensible.
Même si le fichier Docker est un texte lisible ce n'est pas toujours reproductible à la main notemment lorsqu'il y a des dépendances à d'autres images dont on a pas la configuration.
Je suis probablement aussi un "vieux qui ne veut pas changer ses habitudes" (sic) ?
A ne pas prendre mal, je comprends très bien pourquoi tu la publie sous cette forme surtout pour une première publication générale.
A mon avis c'est un super outil pour les développeurs, pour la reproductibilité, pas les admins. Mais c'est un avis qui n'est pas partagé par toutes et tous, comme l'attestent les longs débats à ce sujet sur le salon Matrix Auto-hébergement.
Pardon pour cette longue réponse, j'espère que ça ne va pas se transformer en débat là dessus plutôt que de parler de ton application.
Pour la fédération, je ferais un parallèle avec les messages privés entre instances micro-blog du fedivers (pour généraliser sans nommer de logiciel en particulier):
Niveau confidentialité, c'est similaire: les admins de chaque instance pourraient voir les listes/messages dans la base de données c'est une question de confiance à leur donner ou non. Le reste des instances et utilisateurs ne voient rien.
L'abonnement entre utilisateurs-trices permettant de voir toutes les futures listes peut être sur validation uniquement (comme un compte totalement privé, qui accepte ou refuse les demandes d'abonnement)
Sur la gestion des droits cela peut se faire avec les groupes public/abonné-e-s seulement/privé et peut-être qu'il peut y avoir des groupes nommés et abonnés pour les familles et groupes d'amis. Je réfléchis probablement trop avec le modèle des échanges textes en tête, ça mériterait de s'y pencher plus longuement.
Bref, l'adoption des instances multiples reste long (cf. les micro-blogs) mais la pratique devient plus grand public depuis quelques années, au moins pour comprendre les différences avec les services "gratuits" d'une seule entreprise fermée sur elle-même.
Je vais essayer de contribuer à ton appli autant que je peux, avec de la doc et pourquoi pas des réflexions sur une possible fédération si tu acceptes l'idée. Il y a un livre O'Reilly en cours de rédaction sur ActivityPub par Evan Prodromou, je l'attend de pied ferme :) https://evanp.me/
[^] # Re: Yay !
Posté par Letho . Évalué à 3 (+2/-0).
Après, il existe des alternatives à Docker : pour ma part, j'utilise Podman pour développer, ainsi que sur certains environnements de production. Et je lui trouve pas mal d'avantages, comme le rootless, le mapping des UID/GID, les pods, l'intégration avec SystemD, etc…
Après, je comprends également que le fait d'avoir une couche supplémentaire puisse être rédhibitoire. Perso, je ne saurais plus m'en passer ;)
[^] # Re: Yay !
Posté par Epy . Évalué à 2 (+0/-0).
Podman était sur ma liste "à tester/creuser" mais je n'ai pas assez de temps pour chercher et découvrir tout seul.
Si professionnellement je tombe sur une infra déjà faite avec cet outil et quelqu'un en mesure de m'y faire débuter ça sera volontiers; et bien plus facile pour comprendre.
[^] # Re: Yay !
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Ça prend à peu près 5 minutes de passer de docker à podman vu que le second projet a eu la bonne idée de reprendre les noms des options et paramètres:
par exemple,
podman runprend les mêmes paramètres quedocker runmais a juste des options en plus:Pour 99% des cas, ils sont interchangeables sans autre modification que le nom de la commande et ça fonctionnerait avec un alias.
[^] # Re: Yay !
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Docker compagnie a fais un travail très conséquent pour contractualisé quasiment tout ce qui peut ressembler à une API. C'est ce qui permet d'avoir des outils alternatifs pour construire des images, pour les exécuter, pour avoir des dépôts d'images, etc. Ces APIs ne sont même plus sous leur girons mais sous celui d'un projet de la fondation Linux (OpenContainer).
Docker a ces défauts, mais dire "docker est une compagnie donc ça va mal finir" me semble quand même très réducteur, tu ne trouve pas ?
Aujourd'hui les technologies docker me paraissent plus ouvertes, mieux maîtrisées, avec un écosystème plus divers et ayant tout ce qu'il faut pour échanger avec le reste de l'écosystème linux que LXC.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Yay !
Posté par Epy . Évalué à 2 (+0/-0).
Forcément, n'aimant pas cette surcouche je ne l'utilise pas et ne connait pas tout. Au temps pour moi sur cette API ouverte, et tant mieux.
Merci pour cette correction.
À l'époque où j'y avais jeté un œil, une majorité des images étaient sur leurs serveurs uniquement (un gros silo, comme d'autres services)
[^] # Re: Yay !
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Le docker hub n'est différent de images.linuxcontainers.org qu'à la marge. Il a plus d'images que de template sur l'autre, mais c'est une question de succès. Il y a des alternatives existantes et tu peux installer la tienne ou utiliser celle que tu as avec gitlab. Il me semble que tu as moins de choix avec les templates registries.
D'ailleurs on voit que ce n'est pas parce que c'est directement géré par une entreprise que le projet est hors des contraintes financières. Les utilisateurs de LXD se font dégager du dépôt de linuxcontainers parce que Canonical arrête de payer
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Yay !
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
Oui, de la même manière que tu fais confiance à un admin d'une instance de Geeftlist aussi, puisque le contenu de la base n'est pas chiffré.
J'imagine qu'une "famille" sur Geeftlist pourrait être un groupe sur AcivityPub mais est-ce que ce concept existe et permet la même chose ? Dans l'idéal il faudrait pouvoir coder une "extension optionnelle" à l'appli qui permettrait de s'interfacer avec ce protocole, sans devoir tout réécrire.
Oui je n'ai malheureusement pas la connaissance sur ce sujet, et je manque de temps pour m'y investir. Mais je serais très intéressé si quelqu'un s'y penchait dessus et je pourrais apporter mon aide.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.