Nanawel a écrit 281 commentaires

Oh OK merci :)

En effet ça semble logique. Mais où vois-tu cette valeur de ~75 IOPS dans les sorties des commandes ? Je suis curieux je n'y vois que des valeurs en ko/s.

Je ne sais pas comment faire pour augmenter la quantité de données lues à chaque "tour", je pensais que la commande blockdev --setra servait à ça, mais apparemment mdadm ne semble pas trop y voir de différence.

Si j'avais une solution qui impliquait d'augmenter sensiblement la RAM occupée pour ce travail (en travaillant sur de plus gros lots de données) ça ne me dérangerait pas, j'ai encore presque 3 Go libres, mais je ne trouve rien qui permette ça.

Et je plussoie également pour borg, avec tous les avantages décrits par les précédentes réponses.

Je suis également tombé sur un service de sauvegarde que j'ai failli prendre¹ et qui allie simplicité et faible coût : https://www.rsync.net/products/borg.html
En gros, il s'agit simplement d'un serveur de stockage utilisable avec rsync… et borg évidemment. Ça revient à $12.50 par mois pour 500 Go de stockage, ce qui me semble pas mal.

---

¹ Finalement j'en suis resté pour l'instant à de l'auto-hébergement à ce niveau, mais je n'exclue pas d'y souscrire à terme.

En effet, ça confirme mes doutes sur la faisabilité.

Je ne sais pas si tu as testé car tu ne le mentionnes pas, mais as-tu essayé la virtualisation ?
Pour une application 3D je n'aurais pas trop d'espoir malheureusement, mais il semble y avoir un peu de doc qui traîne et qui semble faire penser que c'est possible : https://all3dp.com/2/fusion-360-for-linux-how-to-install-it/

Idem quand je clique sur un lien extérieur à Twitter. Par contre une fois la page d'erreur affichée, forcer le rafraîchissement (Ctrl+Shift+R) permet d'accéder à la page voulu, alors qu'un simple rafraîchissement ne fait rien de plus.

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).

Currently the application cannot be accessed from a URL using a custom path

bizarre quand même

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.

Merci, merci et merci.

Je suis pas allé cherché loin, mais si ça plaît alors tant mieux :D

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…

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.

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.

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 :

• Trop complet/complexe pour l'usage. Gourmet permet vraiment d'aller dans des détails très précis, mais quand on ne les utilise pas cela rend le tout lourd à utiliser.
• Pas de support pour l'import CSV, alors que c'est le format qu'il était prévu d'utiliser pour saisir les recettes à indexer.
• Logiciel lourd. Assez critique quand la consultation va être faite dans 95% des cas sur mobile (eh oui, le mobile dans la cuisine, voire même à l'extérieur de la maison).
• Non-collaboratif. C'est quand même pratique de pouvoir se répartir les bouquins à indexer et pouvoir le faire en parallèle :)

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

Je viens d'en faire un journal : https://linuxfr.org/users/nanawel/journaux/reciphpes-gestion-et-indexation-de-recettes-sous-symfony

J'ai un Ellipse ECO 500 non pilotable et un Ellipse ECO 650 USB.

Le modèle USB fonctionne bien sous Debian/Ubuntu avec NUT ce qui permet d'éteindre la machine proprement si la coupure dure. Pour info qui vaut ce qu'elle vaut, 5 ans plus tard il tient encore 30mn environ avec une box SFR et un serveur HP Proliant MicroServer N40L reconverti en NAS.

Le premier fonctionne bien aussi, il faut juste que la coupure dure pas trop ! (mais heureusement, là où il est, les coupures sont rares)

Haha oui maintenant que tu le dis j'ai d'ailleurs dû étudier cet exemple en cours.

Mais non, on va pas faire du Prolog ;)

Gourmet est pas mal en effet ! On perd le côté générique que je cherchais initialement, mais au moins il est bien adapté au besoin.
Il possède notamment le champ "Source" qui permet justement de préciser où se trouve la recette si on ne met pas les instructions, ce qui permet de la retrouver.

Je suis tenté !

Notamment pour gérer le cas des données complexes (emplacements, ingrédients, etc.) et pour pouvoir gérer les filtres de types :
- "recettes avec X et Y sans Z"
- "recettes avec X mais sans Y"
- "recettes végétariennes dans l'emplacement E"

Mais peut-être que je n'ai pas une vision suffisamment large de ce qu'il est possible de faire sans SGBD, je suis un peu trop dedans au quotidien pour être objectif ;)

Oui je vois, effectivement c'est peut-être une méthode plus efficace. Faut que je me documente un peu plus sur ES à ce sujet.

Exactement, merci de la précision :)

Définitivement un soft intéressant que je vais garder sous le coude, mais pas assez structuré pour mon besoin très "database-oriented".

Merci quand même !

Oui je crois comprendre, mais je ne saisis malgré tout pas quelle GUI va me proposer - par exemple - la liste déroulante des ingrédients quand je crée une recette. À moins que je ne la code moi-même (ce que j'essayais d'éviter jusque-là puisque je supposais que ce genre de besoin générique existe bien quelque part).

Je l'ai vu passer mais j'avais deux problèmes avec ce soft : c'est du KDE (ok c'est réducteur, mais j'ai pas envie d'installer 36 libs KDE sur les PC), et c'est une appli lourde.

Merci quand même, je vais quand même y jeter un oeil plus précis !

Oui je vois ce que tu veux dire. Je ne sais malgré tout pas comment gérer la saisie dans ce cas, pour que par exemple l'ingrédient X d'un recette R1 fasse bien référence à une donnée précise (utilisée par un autre recette R2), qui pourrait éventuellement être enrichie plus tard (type, etc.).