Je développe un logiciel de gestion de budget basé sur le système des enveloppes

Mais pourquoi donc ?

#

Hey there, 👋

Ma femme étant une fan du système de gestion de budget basé sur le système des enveloppes et étant moi-même un informaticien un peu perfectionniste qui déteste quand les choses ne fonctionnent pas comme je le veux, il était for probable que tôt ou tard je me retrouve à réimplémenter mon propre système de gestion de budget.

Nous avons d’abord utilisé denaro et poussé au maximum (voir détourné) certaines de ses fonctionnalités pour créer des “allocations mensuelles”. Malgré quelques soucis d’ergonomie et autres bugs, ce système semblait être satisfaisant de prime abbord.

Mais ensuite je me suis rendu compte qu’il est actuellement impossible d’éditer sans problème une transaction répétée (ex : celle de la facture d’internet ou d’électricité, qui est la même tous les mois). L’édition d’une transaction était gérée de la pire façon qui soit. Supposons que la facture de téléphone passe de 10,99 à 12,99, je devais :

• Fixer une date de fin à la transaction répétée
• Cela créerait une nouvelle transaction répétée avec les bonnes dates de début et de fin, mais cela laisserait également les ancienes transactions créees par la transaction répétée, sans qu’ils soient liés à une quelconque transaction répétée.
• Supprimer ensuite manuellement toutes les transactions orphelines ainsi créées.
• Créer ensuite une nouvelle transaction répétée avec la nouvelle valeur et espérer que la facture de téléphone ne changera pas de sitôt sinon il fuadra tout recommencer :/

Du coup qu’est-ce qu’on fait ?

#

Je me suis donc lancé sur ce projet sans aucune connaissance du developpement d’applications (en particulier d’applications client lourd). Et comme ce n’était pas assez galère fun, j’ai décidé d’utiliser un framework assez niche/assez nouveau appelé tauri. Voici un bref aperçu de ma stack technique, dans le désordre :

• Tauri
• Vite
• Svelte (donc typescript)
• Rust (pour l’instant presque rien puisque tout est côté client)

J’ai compris beaucoup de choses en cours de route, et ai atteint le stade du MVP où mon application gère :

• Les catégories
• Les transactions (ajout, édition, suppression)
• les transactions répétées (ajout, édition, suppression, découpage en deux)
• L’établissement de budgets mensuels pour les catégories Elle est actuellement à la version 0.0.10, et je n’ai aucune idée de quand elle atteindra une version stable 😅

Je suis déjà assez heureux du résultat et utilise actuellement l’application, mais il reste beaucoup de choses à faire :

• Concevoir quelque chose de beau (étant plus du type terminal que cliquodrôme Material 3 Expressive, inutile de spécifier que ce n’était pas une priorité pour moi)
• Build l’application pour tout le monde (pour l’instant je n’ai qu’une AppImage nécessitant GLIBC_2.39 donc le PC sous Ubuntu 22 de ma femme m’a gentiment envoyé bouller quand elle a essayé d’utiliser l’application)
• Écrire des meilleurs tests (pour l’instant, environ 30% des fonctionnalités sont couvertes par les tests. Je sais, c’est pas bien, bouhhh)
• Ajouter plus d’ingestors (pour l’instant je n’ai écrit qu’un script rapide (et pas très propre) pour créer une base de données à partir de la base de données de denaro, ce pourrait être mieux)
• Rendre tout possible côté serveur et utiliser une base de données sqlite plutôt qu’un fichier json sur le disque (oui jusqu’à présent c’est ce stockage qui sert pour les données 🤐)

Quelques Screenshots

#

Previous Nextsads