Moules,
Après avoir cherché longtemps un logiciel qui permettrait de répondre à mon besoin détaillé il y a quelques jours ici-même - sans succès - j'ai décidé de prendre ça pour une bonne raison de me mettre un peu à niveau sur Symfony. Je fais du Magento au quotidien pour manger, le changement pique un peu.
Quel était ce besoin jeune padawan qui n'a pas suivi le lien ? Je te le présente.
Afin de faire face à l'accumulation des livres de recettes et la difficulté croissante d'y retrouver "cette recette tu sais, avec du Maroilles et du pain d'épices, on en avait fait au nouvel an y'a 2 ans, zut elle était où". Bref.
Afin de faciliter la recherche et l'organisation de ces recettes, quoi de mieux que l'informatique pour nous y aider ? (c'est une question rhétorique)L'idée était donc d'avoir un logiciel qui permet d'indexer rapidement des recettes existantes avec les informations principales (nom, ingrédients principaux, et surtout emplacement où la retrouver) de sorte qu'une recherche permette de ressortir facilement et rapidement un ensemble de recettes par mot-clé ou ingrédient.
Non sans mal, je suis arrivé à un stade où l'application est utilisable, et utilisée.
Comme il m'a été encouragé à faire un retour sur la solution que j'aurais trouvée, hop, voici.
Reciphpes!
Le dépôt est sur Github : https://github.com/nanawel/reciphpes
et j'ai même poussé jusqu'à faire une image Docker : https://hub.docker.com/r/nanawel/reciphpes (ok forcément j'en avais besoin de toute façon)
Actuellement les fonctionnalités principales sont :
- la gestion (CRUD) de recettes avec les champs suivants 1 :
- nom
- tags
- emplacement
- détails de l'emplacement
- saison
- ingrédients
- instructions
- la gestion (CRUD) des ingrédients
- la gestion (CRUD) des emplacements
- la saisie "en masse" de recettes via un formulaire simplifié
- l'import de recettes via CSV
- la recherche via mot-clé, tag ou ingrédient
Il reste plusieurs autres fonctionnalités que je souhaite mettre en place mais la base est là, donc la partie "moins fun" de la saisie a commencé de mon côté et je fais une pause sur le dev.
Comme je suis noob sur Symfony, n'hésitez pas à me remonter bugs et autres optimisations possibles. De même, les issues Github sont dispo pour toute idée de nouvelle fonctionnalité.
-
Il manque encore des champs évidents comme le temps de préparation, de cuisson, le nombre de personnes, le budget, etc. Ils arriveront dans un second temps. ↩
# cool
Posté par ckiller . Évalué à 2. Dernière modification le 13 juin 2020 à 17:01.
hello,
ca m'intéresse, j'ai ma maman qui m'envoie un fichier word de ces meilleurs recettes depuis des années.
Par contre, la page de screenshoopt renvoi un 404 https://hub.docker.com/r/nanawel/docs/screenshots/
bizarre quand même
[^] # Re: cool
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 2.
Ah oui, le chemin résolu quand on est sur Docker Hub ne fonctionne pas, je regarderai.
En attendant tu peux passer par Github directement : https://github.com/nanawel/reciphpes/tree/master/docs/screenshots
[^] # Re: cool
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 2.
Oui j'ai été surpris aussi mais c'est une limitation de Symfony si on veut que l'application soit bien portable facilement. Sinon les URL générées pour les assets (CSS/JS) et les liens internes sont foireuses.
Je ne dis pas qu'il n'y a pas de solution, mais seulement que les solutions qui existent et que j'ai lues sont toutes des bidouillages qui ne me satisfaisaient pas.
# En plus il y a des nimages !
Posté par jnanar (site web personnel) . Évalué à 6. Dernière modification le 13 juin 2020 à 17:10.
Comme c'est toujours chouette de voir à quoi ressemble une application sans l'installer et que tu t'es donné la peine de prendre des captures d'écran, je me permet de les montrer après ma question.
Sur le forum, tu as largement décris le besoin de ta compagne afin d'organiser ses recettes de cuisines. Tu as eu plusieurs retours et suggestions et tu as pris la peine d'y répondre. J'avais proposé gourmet qui a l'air cool même si je ne l'ai jamais testé et il avait l'air de te tenter. Du coup, quels sont les obstacles qui t'on déplu chez lui et qui t'ont encouragé à développer ta propre solution ?
Encore merci pour ton journal de retour, c'est toujours utile et pertinent.
[^] # Re: En plus il y a des nimages !
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 5.
Oh merci, j'ai totalement zappé de mettre des nimages pour accompagner.
Pour te répondre concernant Gourmet, j'ai testé et hésité pas mal je t'avoue. Mais au final les points qui m'ont fait abandonner sont :
[^] # Re: En plus il y a des nimages !
Posté par pled . Évalué à 1.
Salut,
Pour info, il y a un fork de Gourmet en cours pour le porter sur Python 3 :
https://github.com/kirienko/gourmet
Peut-être y ajouteront-ils plus tard l'import CSV ?
Mais je ne comprends pas vraiment ce besoin : quelle utilisation ? qui propose des recettes au format CSV que tu puisses ainsi importer ? Si tu peux m'éclairer…
Perso j'utilise Gourmet sur le PC, j'exporte le contenu au format MCB, et je l'importe dans l'application "Mes recettes" sur Android. Il y a bien sûr le besoin de synchro, mais sinon la solution me convient.
[^] # Re: En plus il y a des nimages !
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 1.
Le besoin de l'import CSV était dans l'optique où aucune interface sur un logiciel existant, de par le besoin de base (à savoir "indexer des recettes" et non "rédiger des recettes") ne permettrait d'avoir l'efficacité souhaitée, et qu'une saisie dans un tableur serait plus rapide et plus confortable.
Avec Reciphpes, ce besoin est désormais anecdotique puisque l'interface de saisie en masse est prévue précisément pour répondre à ce besoin, avec tout le nécessaire pour être le plus efficace possible (navigation au clavier, auto-complétion, etc.).
Dans tous les cas, mes compétences et mes préférences me font souvent largement préférer l'utilisation d'une application web à un logiciel lourd, ne serait-ce que par la portabilité (multi-OS et multi-device) et la facilité de collaboration. J'ai serveur maison qui sert à ça donc il est très facile d'y déployer de nouveaux applicatifs (surtout quand ils sont dockerisés).
# Curiosité
Posté par barmic 🦦 . Évalué à 3.
Je n'est jamais touché à Symphony et je ne connais pas du tout Magento et je n'ai pas l'intention de faire de PHP ces prochaines années, mais je serais intéressé d'en savoir plus :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Curiosité
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 1.
Ah si tu ne connais aucun des deux cela va m'être difficile de te répondre :)
Disons que ce sont 2 frameworks très différents, avec chacun leurs concepts à appréhender ce qui conduit souvent à se demander "mais pourquoi ce que j'ai fait ne fonctionne pas ?" parce qu'on réfléchit involontairement au problème par le "mauvais" prisme.
Symfony a la force de la doc. Très complète, mais toujours un peu abstraite, c'est une doc.
Magento a la force des dizaines de modules standards qui sont autant d'exemples qu'il est possible d'analyser en détail et dont il est possible de s'inspirer (voire de copier).
Après, la debugbar de Symfony est un petit bijou, et elle m'a sorti d'affaires plus d'une fois. Mais j'ai quand même passé beaucoup de temps dans le debugger et sur StackOverflow.
# Fonctionnement
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 13 juin 2020 à 18:14.
Ça c'est vraiment cool comme fonctionnalité :)
L'interface est-elle responsive ? Généralement dans ma cuisine j'utilise plutôt mon téléphone ou une tablette pour suivre les recettes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Fonctionnement
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 2.
Oui il faut que j'ajoute un screenshot d'ailleurs.
Cette fonctionnalité est issue de mes premières séances de saisie. La saisie unitaire était chronophage et frustrante, avec beaucoup de valeurs qui ne variaient pas d'une recette à l'autre (quand on indexe un livre page par page notamment). Après discussion avec ma co-auteur, on a considéré que c'était un bon compromis.
Pour l'accès par mobile, oui je me suis appliqué à m'assurer que toute l'interface est bien responsive (merci Boostrap). Il peut rester certaines zones à améliorer mais l'ensemble devrait être totalement utilisable depuis mobile, puisque c'était un besoin à la base.
# Tout déçu :(
Posté par _kaos_ . Évalué à 4.
Salut,
Non, en vrai, bravo !
C'est chouette de voir un projet naître parce qu'il n'y a rien de satisfaisant ;)
On avait discuté un peu lors du post "cherche logiciel", d'elasticsearch pour tes besoins. J'ai survolé vite fait le code, mais je suis pas inspecteur des travaux finis donc j'ai peut-être raté le bon fichier, pour voir si ça t'avais inspiré.
Un petit retour ? ;)
Matricule 23415
[^] # Re: Tout déçu :(
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 3.
Alors je n'ai pas nettoyé mon historique Git donc tu pourras y retrouver les premières pistes que j'avais suivies (et qui ne pas passées par ES mais par MongoDB) mais d'une manière générale j'en suis arrivé à la conclusion que les données que je cherchais à modéliser sont relationnelles. Donc utiliser autre chose qu'un SGBD pour ça était simplement un anti-pattern.
Cela m'a quand même permis d'explorer un peu les possibilités offertes par Doctrine avec MongoDB, et très franchement, c'est vraiment à réserver à des utilisations qui s'y prêtent car les limitations arrivent vite.
Je conserve par contre la possibilité d'utiliser un jour ES ou MongoDB comme moteurs de recherche (à plat donc), qui sont beaucoup plus efficaces que les SGBD évidemment. Là pour le moment ma recherche est un bête
LIKE…[^] # Re: Tout déçu :(
Posté par _kaos_ . Évalué à 2.
Salut,
Ok, aucun problème, c'est toi le cuisinier et t'as une chef :)
Tant que la recette marche, c'est ce qui compte ! :)
Matricule 23415
[^] # Re: Tout déçu :(
Posté par Nonolapéro . Évalué à 3.
Avant de sortir l’artillerie lourde d’un Elastic Search qui va ajouter de la complexité au projet, tu as le full text search de postgresql : https://docs.postgresql.fr/12/textsearch.html
Reste à voir ce que doctrine est capable de faire avec par contre.
[^] # Re: Tout déçu :(
Posté par wismerhill . Évalué à 3.
En SQL natif, tu fais ce que tu veux.
Ce n'est pas supporté en DQL de base, mais c'est relativement facile d'ajouter une fonction DQL sur mesure pour ça.
# Un nom parfait
Posté par Glandos . Évalué à 6.
Bon déjà, j'encourage toujours les gens à créer une solution à leur besoin, tant qu'ils ne réinventent pas la roue. Et à par Grocy, qui fait plein d'autres choses, et Gourmet, qui n'est pas collaboratif, y a pas grand-chose.
Mais le nom me semble tellement bien. Il évoque :
Rien que pour le dernier point, je vote pour.
[^] # Re: Un nom parfait
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 1.
Merci, merci et merci.
Je suis pas allé cherché loin, mais si ça plaît alors tant mieux :D
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.