Discussion :

[Flackou]

Bonjour,

Sur la page d'accueil de mon site, je voudrais donner une 'astuce du jour'. Pour cela, j'ai constitué une petite base d'astuces, et je voudrais que chaque jour, une de ces astuces soit affichée.

Je vois pas comment je peux faire un truc pareil. Je vois en fait deux problèmes :

1. Je suppose qu'il me faut en premier lieu un script quotidien (que je ferais tourner par exemple tous les jours à minuit) qui choisirait aléatoirement l'astuce du jour. Et ca j'ai aucune idée de comment faire ça avec Ror... Y a moyen de planifier des actions? Que ferait ce script?

2. Il me faut également une "variable globale" qui récupérerait l'id de l'astuce choisi par le script. Là encore, je vois pas trop comment m'en sortir...

Est-ce que vous auriez des idées?

Merci d'avance pour votre aide (j'en ai bien besoin!)

[Zfred]

une "variable globale"

Beurk !

Piste : Tu peux faire une table qui aurait :
- Un champ "astuce_id" qui contient l'id de l'astuce du jour
- Le champ "updated_at"
Rails regarderait le champ "updated_at", si ça date de hier, il change l'astuce...

[Flackou]

Ca serait donc une table à une seule entrée? Y a pas un moyen de faire plus "simple"? Non pas que ta solution serait complexe à mettre en oeuvre, mais on doit pouvoir s'en sortir sans créer une table dédiée au stockage de la variable, non??

Et pourquoi

Beurk !

pour la variable gobale?

Ta solution marcherait, certes, mais pourquoi une variable globale ne serait pas bon?

[Taum]

2. Il me faut également une "variable globale" qui récupérerait l'id de l'astuce choisi par le script. Là encore, je vois pas trop comment m'en sortir...

mais on doit pouvoir s'en sortir sans créer une table dédiée au stockage de la variable

Donc tu veux bien taper dans la base de données pour récuperer le texte de l'astuce, mais pas l'id de l'astuce du jour ... tu peux développer ?

Et pourquoi "Beurk" pour la variable gobale?
Ta solution marcherait, certes, mais pourquoi une variable globale ne serait pas bon?

Bin, tout simplement parce que ta "simple variable globale" ... ça ne marche pas. Outre le fait de devoir exécuter un script à intervalle régulier, ce qui n'est pas géré par Rails mais que tu peux facilement faire avec cron, j'ai l'impression qu'il y a pas mal de problèmes dont tu ne te rends pas compte.

Une variable "globale" ne l'est que dans le contexte de ton interpréteur. Si tu lances deux scripts Ruby différents, ils ont chacun leur version de cette variable. D'autre part, quand ton appli web tourne elle utilise généralement plusieurs processus qui tournent en parallèle, il faut donc faire attention aux problématiques de synchronisation qui sont loin d'être triviales. Utiliser la base de données résout ces deux problèmes : elle est partagée entre tout les process, et elle gère les accès concurrents.

[Zfred]

tu veux bien taper dans la base de données pour récuperer le texte de l'astuce, mais pas l'id de l'astuce du jour

Merci Taum pour cette remarque !
Autrement dit, ca ne semble pas incohérent si le texte de l'astuce est dans la bdd, d'utiliser cette meme bdd pour stoker l'id de l'astuce...

Sinon il y a d'autres solutions, comme écrire l'astuce du jour dans un fichier, et demander à Rails de lire le fichier...
Mais bon, je pense que niveau performance, c'est moins bon.
Et puis ça oblige à recopier un texte qui existe déja dans la bdd et que Rails est parfaitement capable de lire et d'afficher...

La variable globale, ça marche aussi...
C'est un peu long d'expliquer pourquoi les globales c'est pas un choix terrible...
- Déja au point de vue sécurité, ça craint.
- Ensuite, pour le debug ça devient vite mission impossible.
- Apres, si tu utilises Mongrel avec le loadbalancing, tu n'auras pas la meme valeur de la globale pour chaque Mongrel (quoi que dans ce cas, c'est pas forcément génant)
- Dans tous les cas, il faut penser objet. (Ruby)
L'utilisation d'une variable globale c'est contraire au principe, qui preferera encapsuler les objets avec leurs propres variables locales...

[pada51]

Pour aller plus loin tu pourrais mettre les astuces en bdd, et en cookie(ou en bdd a toi de voir) les astuces deja "vues" pour chaque user. Ainsi pas besoin d'avoir des milliers d'astuce, chaque user ne verrait que les astuces qu'il n'a pas déjà vu ...

[Zfred]

Les "deja vues" je les mettrais aussi en bdd.
Il suffit de faire une table supplémentaire, belongs_to user, belongs_to astuce.
Pourquoi ? Parceque si t'as déja tout le reste en bdd, alors pourquoi aller délocaliser une partie dans un cookie ?
Ensuite, le cookie est super limité en taille et le jour où il y en a vraiment besoin...

[pada51]

Je suis d'accord avec toi mieux vaux utiliser la bdd, une petite fonction dans le modèle retournant un tableau d'ids déja vu par l'utilisateur et un petit named_scope qui te renvoie une seul astuce order by "RAND()" et qui n'inclut pas la liste d'id reçue plus haut.
Il faudrait même en faire un plugin !

[Flackou]

Merci à tous pour votre aide.

Donc tu veux bien taper dans la base de données pour récuperer le texte de l'astuce, mais pas l'id de l'astuce du jour ... tu peux développer ?

Taum -> mon propos n'était pas incohérent. Je disais simplement, qu'à première vue, il me semblait un peu lourd de créer une table à une seule entrée dans ma BDD pour stocker un unique ID. Par définition, la BDD sert au "stockage de grandes quantités d'informations" (Wikipedia), et les tables des BDD en sont le support. Donc pour mes astuces, c'est tout à fait logique d'utiliser une table puisque j'en ai un grand nombre, avec différents paramètres pour chacune. En revance pour l'id de l'astuce courante, ca m'oblige à créer une table à une colonne et une ligne... Ce serait comme acheter un entrepôt pour stocker un seul carton. En soi c'est pas grave, puisque le nombre d'entrepôts est illimité, mais sur le principe, ca semble pas optimal. Voilà pourquoi j'essayais de chercher une autre solution plus adéquate, mais n'en trouvant pas, je vais utiliser celle là (que je vois plus comme une "astuce" que comme une solution bien propre).

Sinon il y a d'autres solutions, comme écrire l'astuce du jour dans un fichier, et demander à Rails de lire le fichier...
Mais bon, je pense que niveau performance, c'est moins bon.

Tu as raison, je vais plutôt utiliser la BDD.

pada51 -> ton idée est sympa, je vais faire au plus simple.

[Taum]

Oui dans ce sens tu as tout à fait raison.

Conceptuellement, si une table modélise des entitées, ça n'a pas vraiment de sens de faire ça. Je pense qu'une façon plus correcte de faire serait d'avoir un attribut supplémentaire "afficher", de façon à n'en avoir qu'un seul à 1 à la fois en le faisant changer par un script.

Mais je pense qu'en pratique le surcoût d'une table est minime. Je ne sais pas vraiment laquelle des 2 approches serait la plus performante, mais je suis à peu près sur que ça n'aura pas un impact énorme dans les 2 cas

[Zfred]

mon propos n'était pas incohérent. Je disais simplement, qu'à première vue, il me semblait un peu lourd de créer une table à une seule entrée dans ma BDD pour stocker un unique ID. Par définition, la BDD sert au "stockage de grandes quantités d'informations" (Wikipedia), et les tables des BDD en sont le support. Donc pour mes astuces, c'est tout à fait logique d'utiliser une table puisque j'en ai un grand nombre, avec différents paramètres pour chacune. En revance pour l'id de l'astuce courante, ca m'oblige à créer une table à une colonne et une ligne... Ce serait comme acheter un entrepôt pour stocker un seul carton. En soi c'est pas grave, puisque le nombre d'entrepôts est illimité, mais sur le principe, ca semble pas optimal.

Excellent !

que je vois plus comme une "astuce" que comme une solution bien propre

D'apres moi, au contraire, c'est trés propre, ça permet de ne pas mélanger les ressources.
La logique du model pousse à mettre 1 carton tout seul dans l'entrepot, si c'est sa place, et que c'est naturel de le trouver là.

- Pour ton besoin, tu peux aussi imaginer une "grosse" table de parametres, pour l'application. Dans cette table tu aurais un champ "id_astuce du jour".
(le carton ne serait pas tout seul dans l'entrepot)
- Tu peux imaginer 1 table "users" dans laquelle tu as un champ "id_astuce_vue_la_derniere_fois"
- Tu peux rajouter un champ date dans ta table "astuces", qui indiquerait la derniere fois qu'elle a été affichée.
...

[Flackou]

Mais je pense qu'en pratique le surcoût d'une table est minime.

Tout à fait d'accord, et c'est pourquoi je vais me tourner vers cette solution, plus simple et pragmatique que toutes les autres.

Merci beaucoup pour votre aide en tout cas. J'aurais surement pas pensé à cette solution sans vos conseils!