Un sujet chaud, qu'est ce que c'est ?

J'ai parcouru ces articles (très intéressants au passage) et à vrai dire ils parlent plus de la tendance générale des sujets sur une "plateforme" (par exemple les hashtags en vogue sur twitter) que de la température d'un sujet en particulier.

Bonjour,

Ne serait-il pas pertinent de mettre également en valeur certains sujets n'ayant pas reçu beaucoup de +1, du genre les tutoriels en bêta ? Autrement dit, rajouter dans les sujets chauds les sujets "pour contribuer".

C'est pas le but ici Vayel.

Sauf si on définit un sujet chaud aussi comme "un sujet permettant au membre de contribuer au site". =)

du genre les tutoriels en bêta ?

On parle de sujets chauds, les tutoriels en bêta auront leur place plus bas dans la page d'accueil, mais les sujets chauds doivent, selon-moi, être des sujets en tant que tel, pas des tutoriels (ni les topics associés).

Je l'ignorais. Pardon. =)

On peut faire tourner un bout de code dans un coin et poster ici le résultat des sujets chauds (une fois par jour) ?

Faudrait peut-être commencer par ça. Du coup on fait évoluer l'algo sans passer par la page d'accueil.

Est-ce-que c'est réaliste de dire qu'on calcule les sujets chauds une fois par heure par exemple, qu'on les colle en cache et qu'on n'y touche plus après ?

(l'idée c'est que comme ça on peut faire le calcul le plus technique qui soit, qui balaye l'ensemble des messages etc. sans être embêté par c'est impossible à faire à chaque requête).

Si oui, c'est cool parce que tout ce qui a été évoqué à la page précédente, le log sur l'âge etc. peut rentrer en ligne de compte directement. Idem, si les +1/-1 évoluent sans arrêt, on ne recalcule le "score" du sujet qu'une fois par heure, sans mettre à jour à chaque +1/-1 ?

Est-ce-que ça vous paraît envisageable ? Ou vraiment inadapté / délirant ?

Si c'est le cas on peut se lâcher complètement sur la formule de calcul.

NB : En gros l'idée serait : Périodiquement (un cron, un thread en tâche de fond) on extrait 100 (par exemple) topics candidants à être des sujets chauds (i.e. dernier message posté récemment ou nbMessages > N ) pour chacun des topics on calcule son score à l'instant T avec une formule magique et compliquée, pouf on colle ça en cache et on n'y touche plus jusqu'à ce que le cron se réveille.

A partir de là y'a plus qu'à définir peu de trucs :

1. nombre de messages pré-filtrés (100 dans l'exemple)

2. critère de pré-filtrage (== condition sine qua non pour qu'un message soit "hot")

3. méthode de calcul du score d'un sujet chaud

Personnellement, je n'imagine pas la nouvelle page d'accueil sans cache. Elle va être beaucoup plus lourde que celle en place actuellement.

L'avantage c'est qu'on pourra mettre en cache tout ce qui est public (95% des choses de l'accueil).

@Javier, idem ca me parait une chose indispensable. Recalculer tout a chaque fois qu'une variable de la formule change ca va juste coucher le serveur

Apres reste toujours le problème de définir la/les meilleure métrique…

@Eskimon : pas forcément (hormis la date). Tu ajoutes une réponse à un topic => tu recalcules le score c'est pas complètement fou comme approche.

Si a chaque +/- 1 on recalcul ca sera monstrueux non ?

Ca dépend du poids d'un +1 / -1 dans la formule

Si tu sais que ça compte pour un point, t'as pas besoin de tout recalculer.

Autant pour les autres ZEP je suis de l'avis général (et de l'avis classique dans notre métier) de spécifier d'abord fonctionnellement avant de regarder les problèmes techniques, ici j'ai l'impression qu'il faut quand même quelques hypothèses techniques avant de se lancer sur la méthode de calcul

Je crois qui si ont arrive déjà a stabiliser les critères qui doivent rentrer en compte dans un sujet chaud on aura déjà avancé. Car tout ce qui est cité dans le premier topic n'est pas forcément utile.

Est-ce qu'on peut faire un dump de la BDD de la prod dans la préprod (au moins pour les forums), on pourrait alors faire les tests que l'on veut sur le côté de la préprod (indépendamment du code du core). On pourrait balancer un nouveau repo temporaire le temps de bien gérer tout ça non ?

Du coup ça vient de là

Je reposte ma réponse ici parce que ça me semble intéressant :

On ne peut peut-être pas tout automatiser, mais il est possible de s'éviter un job à plein temps. Un bouton permettant à chaque membre de dire "je voudrais bien voir ce topic en page d'accueil" permettrait de le faire facilement.

En lisant Stranger, je ne trouve pas déconnant l'idée d'avoir des sujets chaud sélectionnés par le staff. En fait je pense qu'on peut carrément mixer les deux principes. Tout ceci fonctionnerait comme une pile.

Supposons qu'on ait 10 topics. N1, N2, …, N10. Le système sera chargé de calculer X sujets (disons 5) chauds. Mais avant l'affichage, le système va consulter la "boite de selection" du staff. Si la boite est vide, on affiche le retour du système, si la boite a du contenu, on la fait rentrer en priorité sur la sélection du système.

ça permet d'avoir une mise en avant manuelle couplée aux mises en avant automatiques.

Sinon, j'ai un peu réfléchi au système automatique.

La modélisation

Voici comment je le modélise de mon coté.

Un sujet chaud ( en tout cas pour moi) se divise en deux catégories :

• Les sujets actifs : il s'agit des sujets sur lesquels on a le plus d'activités durant l'heure en cours. Si l'activité est la même dans deux topic, on devra se regarder l'activité de l'heure précédente, ainsi de suite.
• Les sujets à mettre en avant : on peut le voir comme étant un sujet qui n'a pas forcément beaucoup de posts, mais c'est un sujet dont le premier post est très apprécié, et dont le contenu est un minimum étoffé.

Les détails techniques

Maintenant en ce qui concerne l'implémentation, voici comment je traduis les deux définitions.

Les sujets les plus actifs

L'activité sur un sujet dépend des variables :

• messages postés : +2 points d'activité
• like du PO : +1 point d'activité
• dislike du PO : -1 point d'activité
• like d'un post : +0.5 point d'activité
• dislike d'un post : -0.5 point d'activité
• messages signalés dans le topic : -1 point d'activité
• suivi d'un topic (notif/email) : +1 point d'activité

Les topics à mettre en avant

Un topic est digne d'être mis en avant grâce aux variables suivantes :

• messages postés : -1 point de mise en avant
• like du PO : +2 points de mise en avant
• dislike du PO : -2 points de mise en avant
• utilisation d'une balise <h1> dans le PO : +1 point de mise en avant
• utilisation d'une balise <h2> dans le PO : +1 point de mise en avant
• nombre de paragraphes > 3 : +1 point de mise en avant
• suivi d'un topic (notif/email) : +1 point d'activité

Voila à peu près comment je vois le système. Les points d'un topic sont calculés à chaque fois qu'il y'a une action dans celui-ci (+1/-1, post, follow, etc.). Si le sujet doit renvoyer 10 sujets chauds, il lui suffit de récupérer les 5 sujets les plus actifs et les 5 sujets à mettre le plus en avant.

PS : j'ai essayé de donner des points en fonction de l'importance des critères, n'hésitez pas à me dire si c'est un peu farfelu.

Ça me paraît être une très bonne piste de réflexion.

Bon, évidemment, il va falloir ajuster les métriques sauf si t'as un pif extraordinaire, mais je suis d'avis de le faire empiriquement.

Petite question technique : est-ce-qu'on a les bons "intercepteurs" pour calculer les points ? Parce que "à chaque action qui…" ça risque de devenir fouillis non ? (et nid à bug :\ )

Il faudrait un seul et même point de coupe pour recalculer les points d'un sujet ( du style beforeUpdate ou truc du genre). T'es confiant là-dessus ? Perso c'est ce qui me ferait le plus peur dans la spécification d'un tel système. La trouille d'avoir des appels à calculateScore un peu partout dans le code et que ça devienne vite le bazar.

Pour ce qui est du côté fonctionnelle, je suis à 100% pour ce que tu as cité dans ton post. Sur un sujet comme celui-là tant qu'on n'essaie pas on n'aura vraiment qu'une vue partielle du sujet. Et je suis pour avancer POC par POC, voire aoir un système en bêta en prod et poster les updates dans ce topic par exemple. Donc feu !

Autant y'a des sujets où il faut spécifier en bêton armé, autant là je pense qu'au plus vite on a quelque chose à observer au mieux ce sera.

NB : je mettrais un peu plus de points aux notifs par email. C'est un acte fort selon moi.

Oui j'imagine. De toute façon les métriques ne doivent pas être en dur dans le code, elles doivent être des paramètres. Donc à la limite on peut décider des métriques finales après avoir codé le truc.

J'avoue que je n'ai pas encore regardé comment de manière élégante, on pourrait implémenter ça. Actuellement dans mon esprit je pensais à annoter les fonctions qui "créent de l'action" sur un topic avec un truc du style calculateScore. Mais je n'ai clairement pas encore réfléchi a comment mettre en place tout ça. Tout ce que je sais c'est que c'est faisable .

NB : je mettrais un peu plus de points aux notifs par email. C'est un acte fort selon moi.

Dans le cadre des sujets actifs ? dans le cadre des sujets à mettre en avant ? ou les deux ?

Les deux.

Pour ce que je connais (Java + AOP ou assimilé : Spring/Grails/RoR/whatever) :

Soit tu as un domaine sur lequel tu peux agir (en l'occurrence le topic) et là c'est simplissime :

1
2
3
4
5
6
7

class Topic {
    def scoreService // injecté automatiquement (injection de dépendances)
    // ...
    public def beforeUpdate(){
        scoreService.recalculateScore(this)
    }
}

Mais ça, ça ne va marcher uniquement si l'objet topic est modifié. Donc si tout est dénormalisé (i.e. un +1/-1 ne modifie pas le Topic), ça ne fonctionnera pas.

Dans ce cas là j'utiliserais l'AOP, deux possibilités :

Soit par annotations :

1
2
3
4
5
6
7
8

class LikeOnTopicService {


    @TriggerRecalculate(topic)
    public static likeTopic(User person, Topic topic, Integer likeOrDislike) {
         // ... save association
    }    
}

Soit via une approche déclarative :

1
2
3
4
5
6

<aop:config>

    <aop:pointcut id="scoreService"
        expression="execution(* fr.zestedesavoir.topics.(..))"/>

</aop:config>

Ce qui en gros signifie "Toutes les méthodes de toutes les classes du package topics entraîne un appel à ScoreService.

Ce sont les deux systèmes que j'ai trouvés les plus élégants pour gérer ce genre de trucs. Peut-être qu'il est possible de s'en inspirer.

Ah, merci pour cette analyse. Du coup, la méthode des annotations me semble être celle qui se rapproche le plus de Django, on partirai donc sur ce principe là. A savoir une sorte de @TriggerRecalculate(topic) qui annote toute les méthodes en question.

Essayez de faire en sorte que ça n'explose pas le serveur comme méthode de calcul.