Journal Mon projet : Feedspot

49
4
août
2013

Bonjour à tous,

Je viens vous parler d'un projet qui est l'aboutissement de plusieurs années de travail, et qui me semble être assez mature pour que je vous le présente.

Feedspot

Ce projet s'appelle Feedspot : il propose un ensemble de services de veille, basés sur l'actualité.
Mon serveur est abonné à des centaines de milliers de flux RSS, et j'ai fabriqué 3 services autour de cette formidable masse de données :

Radar à buzz

Le radar à buzz est une frise chronologique des mots clés qui font l'actualité.
Elle est entièrement interactive, et est générée automatiquement (donc les mots clés ne sont pas toujours ultra-précis, mais en cliquant dessus on peut facilement savoir à quoi ils se réfèrent).

C'est quelque chose que je n'ai jamais vu ailleurs, et que je trouve vraiment pratique pour s'informer rapidement des gros titres sur une période donnée.

Buzzomètre

Le buzzomètre est un petit outil qui propose une courbe interactive qui affiche l'évolution d'un ou plusieurs mots-clés (ou expressions) au cours du temps dans l'actualité.

C'est à dire qu'il propose une courbe avec le pourcentages d'articles qui contiennent l'expression cherchée dans le volume total, et ce au cours du temps.
On peut donc voir l'évolution de « buzz », ou leur corrélation…

Google Trends propose un service peu éloigné, mais basé sur les recherches, et qui semble au final assez différent.

Flux dynamique

Vous entrez une expression, et mon service de flux dynamique va se charger de vous générer un flux RSS, qui contiendra… tous les articles parus qui contiennent votre expression !

C'est pour ce service que j'ai à la base développé Feedspot, mais il est clair que c'est en fait le moins original : des systèmes similaires ont déjà été développés (Google alertes, Mention…). Je pense que ça peut toutefois être un complément correct, et surtout très simple.

La technique

À la base, je me suis émerveillé devant la masse d'information fraîche qu'on pourrait avoir en s'abonnant automatiquement à plein de flux RSS, et j'ai assez rapidement trouvé quelques applications sympa, qui sont présentées au dessus.

Derrière tout ça, se cache une base de données PostgreSQL qui stocke les flux RSS, les articles… ainsi qu'un démon en python qui se charge d'aller récupérer régulièrement chaque flux RSS (en fonction de sa fréquence de parution d'articles frais). Je ne vous montrerai pas le démon en python, qui est particulièrement sale, et ultra-spécifique.

Indexation

Un aspect important est la capacité de fouiller dans les articles qui correspondent à certains mots clés. J'ai rapidement touché les limites de l'indexation plein-texte de PostgreSQL, qui doit être très bien pour rechercher sur toute une table, mais pas pour faire le genre de choses spécifique dont j'ai besoin.

Plutôt que de partir sur un autre moteur d'indexation (lucene ?), j'ai préféré essayer d'en coder un moi-même (c'est fun, et puis je sais ce que je fais).

Après pas mal de boulot, j'ai réussi à indexer tout le Wikipédia Français, et à rechercher dedans, avec des performances équivalentes à une recherche sur Wikipédia : victoire \o/
Je l'ai ensuite adapté pour mes besoins spécifiques à Feedspot, et c'est désormais lui qui se charge de tout l'aspect « recherche » du service (dont le buzzomètre).

L'avantage, c'est que j'ai de super performances, et que je peux analyser mes mots-clés à la volée et les passer à mon « radar à buzz » si ils montent de manière anormale dans l'actualité.

J'ai aussi décidé de libérer le code de base, que vous trouverez sur GitHub.

Vous pourrez aussi trouver pas mal d'autres détails techniques sur cet article.

Et maintenant ?

Je ne viens pas à vous seulement pour vous parler de technique, mais aussi d'un aspect avec lequel j'ai bien plus de mal (c'est même pas fun :/) : c'est cool, je me suis bien amusé. Et maintenant, je fais quoi ?

Déjà, pensez-vous que de tels services pourraient être susceptibles d'intéresser du monde ?
Même si j'ai du mal à trouver une vraie utilité concrète à mes services, je les trouve bien cool, et ils pourraient servir à des gens (en particulier dans les milieux de la veille).

Je me suis aussi dit qu'il serait possible d'en parler, pour avoir des avis, ou même faire de la pub… mais à qui ?

Bref, je ne sais pas du tout quoi faire, et ça me ferait mal au cœur que mon projet finisse comme beaucoup d'autres avant (dans /dev/null), alors qu'il pourrait peut-être avoir une once d'utilité.

Voilà, je suis ouvert à toute discussion sur l'aspect technique, mais aussi ce dernier aspect assez nouveau pour moi : je fais quoi maintenant ?

À vous la parole :)

  • # Observe le lapin blanc, Luke

    Posté par . Évalué à -10.

    Voilà, je suis ouvert à toute discussion sur l'aspect technique, mais aussi ce dernier aspect assez nouveau pour moi : je fais quoi maintenant ?

    Surtout, abstiens toi de trépigner pendant cette lecture. Il a déjà été rapporté des cas de luxation neuronale dans des circonstances similaires.

    Bref, je ne sais pas du tout quoi faire, et ça me ferait mal au cœur que mon projet finisse comme beaucoup d'autres avant (dans /dev/null), alors qu'il pourrait peut-être avoir une once d'utilité.

    Aucune chance que ton projet finisse aux oubliettes, il est désormais définitivement lié à l'histoire de Zino, au SEO pro-actif associé, au buzz intercontinental dont il a fait l'objet. Je ne doute pas un seul instant que tu aies souri de béatitude lors de tes tests avec tes outils sur les "buzzwords" The Node ou Zin|o|d] ou encore Zino/Zind. Quant à l'utilité de tes outils, tu comprends bien que tout ce qui peut contribuer à affiner l'intelligence {des outils d'assistance à la production de commentaire pertinent sur l'actualité ; des outils d'ingénierie sociale}, tout cela a de l'avenir dans la TheNode Sphere.

    Je me suis aussi dit qu'il serait possible d'en parler, pour avoir des avis, ou même faire de la pub… mais à qui ?

    Il est en effet possible d'en parler. Mon avis est que tu es sur une bonne piste, continue ! Tu as bien fait de publier ton code et de faire un journal. Rien n'est pire que de laisser les gars du marketing développer seuls de tels outils dans l'ombre des licences propriétaires.

    En un mot : félicitations !

  • # Génial !

    Posté par . Évalué à 8.

    Le radar a Buzz est vraiment super !

    Il pourrait être intéressant de classer les flux par catégorie. Par exemple, dans le radar a Buzz actuel je vois "ramadan". Que le ramadan soit discuté par des journaux "politique" ou des journaux "santé", cela n'a pas du tout le même implication.

    En poussant encore plus loin la catégorisation et en analysant les mots utilisés, tu pourrais en faire ressortir des avis pour chaque mots clés et chaque Buzz. En caricaturant, tu pourrais obtenir quelque chose du genre : l'actualité autour de "medef" est positive à 76% pour "journaux droite", 83% négative pour "journaux gauche" et neutre à 10% pour "journaux culinaire".

    La suite ? Gagner des millions en bourse : http://www.nature.com/srep/2013/130425/srep01684/full/srep01684.html . Dans ce papier ils utilisent Google Trends. Bien sure, toi il faudrait avoir plein de blogs (et compte twitter) d'economistes et un modèle un poil différent. Mais c'est la richesse assurée !

    • [^] # Re: Génial !

      Posté par (page perso) . Évalué à 2.

      Intéressant en effet !
      Par contre, j'ai décidé de faire un truc à grande échelle (150 000 flux RSS), et je vois vraiment pas comment je pourrais catégoriser chaque flux :/
      À plus petite échelle, avec quelques centaines de flux récupérés à la main, ça pourrait clairement se faire, par contre !

      Si vous avez d'autres idées dans le genre, ça m'intéresse :)

      • [^] # Re: Génial !

        Posté par . Évalué à 3.

        Tu pourrais regarder si leurs contenus sont proches. Il y a beaucoup de choses faites pour la catégorisation automatique, mais je crois que le domaine est assez compliqué. Tu peux peut-être comparer le vocabulaire en prenant un journal ou un ensemble de journaux comme référence. Essaye par exemple de calculer la corrélation entre le nombre de mots d'un journal à un autre, en éliminant les mots bateau.

        • [^] # Re: Génial !

          Posté par (page perso) . Évalué à 4.

          en éliminant les mots bateau

          voilier, sous-marin, chalutier… et après, -> O

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Génial !

        Posté par . Évalué à 3.

        Par contre, j'ai décidé de faire un truc à grande échelle (150 000 flux RSS), et je vois vraiment pas comment je pourrais catégoriser chaque flux :/

        Utilise des humains comme la NASA pour catégoriser les astres :)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Petites questions

    Posté par (page perso) . Évalué à 9.

    Déjà : bravo ! Très bon travail et l'outil est très intéressant.
    La partie indexation est sur GitHub, mais tu n'index que des mots (en enlevant les mots vide du genre "de","le", …) ?
    Comment fais tu pour afficher "Nelson Mandela" dans ton "Radar à buzz" ? C'est indexd qui identifie les entités complètes ou tu le fais dans un second temps à l'affichage ?
    Comment gères tu la mise en relation de 2 mots ? par exemple : "Edward Snowden" + "NSA"

    • [^] # Re: Petites questions

      Posté par (page perso) . Évalué à 5.

      Merci :)

      Le moteur d'indexation travaille uniquement avec des mots, oui.

      Donc il est juste capable de remonter à mon « radar à buzz » les mots (simples) qui montent.

      Ensuite, j'ai un algo qui passe dessus :
      - d'abord, il essaye d'éliminer le bruit (à l'échelle de la journée, j'ai pas mal de mots parasites qui apparaissent en masse dans un seul flux), en s'assurant que le mot apparaît dans suffisamment de flux RSS.
      - ensuite, il groupe les mots qui vont ensemble : si dans la plupart des articles, on retrouve toujours deux mots ensemble, alors on les met dans le même groupe.
      - et enfin, il essaie d'obtenir une expression compréhensible : à partir de juste la racine du mot, il effectue une recherche dans les articles, et trouve le plus grand dénominateur commun ou apparaît ce mot, dans tous les articles.

      Ah, et sinon j'ai décidé de ne pas enlever les « stop words » comme « le », etc : je ne trouve pas ça génant qu'ils soient là, et ça facilite la recherche d'expressions exactes.

  • # Indexation

    Posté par (page perso) . Évalué à 3. Dernière modification le 04/08/13 à 11:48.

    Pourrais-tu être plus précis sur les limitations que tu as rencontré en utilisant la recherche fulltext de postgres ?

    Autre question : j'ai lu que tu utilisais des fichiers pour le stockage de tes données. As-tu essayé de continuer d'utiliser postgres, mais sans la recherche fulltext bien entendu, histoire de comparer les temps d'indexation et d'interrogation dans chacun des cas, ainsi que la taille requise pour le stockage ?

    En tout cas, félicitation, projet très intéressant. Je pense que je vais y jeter un œil pour m'aider dans la veille technologique :)

    • [^] # Re: Indexation

      Posté par (page perso) . Évalué à 6.

      Pourrais-tu être plus précis sur les limitations que tu as rencontré en utilisant la recherche fulltext de postgres ?

      Quand j'utilisais la recherche fulltext de postgres, j'avais besoin de chercher uniquement parmi les articles parus après la dernière récupération du flux RSS de l'utilisateur.
      Du coup, j'avais à chercher parmi ~1% ou moins du total de mes articles, selon certains mots clés.

      Donc PostgreSQL avait deux choix :
      - chercher dans tous les articles avec son index FullText (ça retourne des tonnes d'articles), et garder uniquement ceux qui sont tout frais. Pas du tout efficace.
      - récupérer les articles tout frais (il peut y en avoir beaucoup…), et rechercher parmis eux ceux qui contiennent les mots clés (impossible d'utiliser l'index). Ça peut être accéléré en rajoutant une colonne avec un index inverté (de type « tsvector »), mais ça reste très bof.

      Du coup, c'était utilisable, mais relativement lent :/
      Le pire était le buzzomètre : j'avais fait une requête SQL capable de le générer, mais ça prenait facilement une dizaine de secondes.

      Et puis avec mon « radar à buzz », je ne voyais pas du tout comment j'aurais pu récupérer les mots clés qui montent (c'est un procédé assez lourd).

      Alors que maintenant, j'ai un algo spécifique pour mon buzzomètre, qui parcourt mes index à toute vitesse en comptant le nombre de résultats (il n'a même pas besoin de regarder la pertinence des résultats, c'est purement booléen).
      Et pour les flux RSS, j'ai aussi un algo spécifique qui fait une recherche, mais en commençant à lire les index uniquement quand on arrive aux résultats du mois précédent. C'est aussi ultra-rapide :)

      Autre question : j'ai lu que tu utilisais des fichiers pour le stockage de tes données. As-tu essayé de continuer d'utiliser postgres, mais sans la recherche fulltext bien entendu, histoire de comparer les temps d'indexation et d'interrogation dans chacun des cas, ainsi que la taille requise pour le stockage ?

      Je continue d'utiliser PostgreSQL pour tout ce qui est stockage, c'est juste que j'ai à côté mon petit moteur d'indexation (et il renvoie les ID des articles trouvés, quand je fais une recherche).

      Actuellement, ma BDD pour Feedspot fait 11 Go, et contient plus de 7 millions d'articles récupérés dans des flux RSS.
      À côté de ça, j'ai 30 Go d'utilisés sur ma partition qui contient l'index inversé (mais c'est du BTRFS et j'ai un snapshot qui traîne, en réalité ça doit être moins).

      • [^] # Re: Indexation

        Posté par (page perso) . Évalué à 2.

        Merci pour ces précisions :) Tu réponds parfaitement à ma question vis-à-vis des problèmes que tu as rencontré avec postgresql (ce qui est toujours intéressant à savoir).

        Je continue d'utiliser PostgreSQL pour tout ce qui est stockage, c'est juste que j'ai à côté mon petit moteur d'indexation (et il renvoie les ID des articles trouvés, quand je fais une recherche).

        Justement, qu'en serait-il si tu persistais tes informations d'indexation avec postgres ? Je pense que pour des recherches simples, la méthode actuellement utilisée est plus rapide. Utiliser postgres te permettrait de faire des requêtes plus complexe simplement directement en SQL. Je pense qu'il serait intéressant de voir la différence entre les deux modes de stockage.

        Ensuite, au niveau des données d'indexation, les 30 Go correspondent à la taille des fichiers ou la taille occupée sur le disque ? Car avec 50 millions de fichiers, cela peut avoir une grande influence. 30Go divisé par 50 millions, ça fait des fichiers d'une taille moyenne de 650 octets. Avec un système de fichiers ayant une taille de blocs de 4ko par exemple, les 30 Go de données occuperont facilement plus 100 Go sur le disque !

        Au passage, je précise un risque que tu peux avoir avec un système de fichier ext3/4 : une pénurie d'inode rendant impossible la création d'un nouveau fichier même si théoriquement, il reste de l'espace disponible sur la partition.

        Pour une utilisation à grande échelle (comme tu le fais), il est important de tenir compte du système de fichier sous-jacent ! Et cela explique également ma question vis-à-vis du stockage des données d'indexation via postgres pour s'abstraire de ces problèmes de système de fichiers ;)

        • [^] # Re: Indexation

          Posté par (page perso) . Évalué à 4.

          Justement, qu'en serait-il si tu persistais tes informations d'indexation avec postgres ? Je pense que pour des recherches simples, la méthode actuellement utilisée est plus rapide. Utiliser postgres te permettrait de faire des requêtes plus complexe simplement directement en SQL. Je pense qu'il serait intéressant de voir la différence entre les deux modes de stockage.

          Franchement, je pense que même si PostgreSQL est très bien fait niveau recherche plein-texte, les BDD SQL sont loin d'être idéales pour faire ça.
          Des projets comme lucene sont tellement plus puissants…
          Et puis je ne vois pas de choses que je ne peux pas faire avec mon petit index inversé, en fait :)

          Ensuite, au niveau des données d'indexation, les 30 Go correspondent à la taille des fichiers ou la taille occupée sur le disque ? Car avec 50 millions de fichiers, cela peut avoir une grande influence. 30Go divisé par 50 millions, ça fait des fichiers d'une taille moyenne de 650 octets. Avec un système de fichiers ayant une taille de blocs de 4ko par exemple, les 30 Go de données occuperont facilement plus 100 Go sur le disque !

          En effet, c'est la taille totale sur le disque. C'est pour ça que j'ai choisi BTRFS, qui est basé sur un arbre et semble gérer très bien les petits fichiers (après un début sous ReiserFS qui semblait fonctionner à merveille également).

          Par contre oui, ma méthode actuelle est ultra-simple, mais bon, c'est clairement pas idéal de stocker tout dans plein de petits fichiers.

          Après, ça me semble très dur d'arriver à trouver un système pour stocker mes index dans un ou quelques fichiers (j'ai l'impression que je vais devoir ré-implémenter un genre de système de fichier, et que je vais avoir plein de problème de fragmentation, etc…). Et je ne sais pas trop comment les BDD ou les autres systèmes font ça :(

          • [^] # Re: Indexation

            Posté par (page perso) . Évalué à 2.

            Franchement, je pense que même si PostgreSQL est très bien fait niveau recherche plein-texte, les BDD SQL sont loin d'être idéales pour faire ça.

            Une base de données relationnelle sert à faire des recherches relationnelles. Ce qui est bien à sa place dans la base, c'est une clef principale qui idientifie le texte. On a le droit de choisir autre chose que le texte lui-même comme clef principale, ce qui permet d'avoir le texte hors du monde SQL et d'utiliser un outil externe pour faire des choses moins relationnelles mais plus pertinentes dessus.

          • [^] # Re: Indexation

            Posté par (page perso) . Évalué à 1.

            Franchement, je pense que même si PostgreSQL est très bien fait niveau recherche plein-texte, les BDD SQL sont loin d'être idéales pour faire ça.

            Je ne suis pas sûr qu'on se soit compris. Ce que je voulais dire, c'est les informations que tu stockes actuellement dans tes fichiers d'indexation les stocker dans des tables. Nulle question ici d'utiliser la recherche plein texte de postgres.

            Si je pense que la méthode actuelle de stockage est plus rapide pour une requête sur un mot, voici un ensemble de requêtes qui pourrait gagner en performance (seul des tests permettront de le confirmer / infirmer) :
            - récupération de la liste des buzz (utile pour le radar à buzz)
            - en guise de requête complexe, je pensais à des trucs du genre "python -serpent" (i.e., je veux les articles qui parlent de python mais pas de serpent)
            - chercher des corrélations entre termes
            - réaliser des statistiques diverses et variées (exemple simple : nombre de termes indexés)

            Après, ça me semble très dur d'arriver à trouver un système pour stocker mes index dans un ou quelques fichiers

            D'où ma suggestion d'utiliser un SGBD pour ça. C'est lui qui s'en occupe et qui se débrouille :) Et puis surtout, les performances de ton système dépend fortement des performances du système de fichiers. ReiserFS est a priori un bon choix puisqu'il gère très bien de nombreux petits fichiers. Pour BTRFS, je ne le connais que de nom. Je ne peux donc rien dire la-dessus. Mais faire un comparatif de performance en fonction des systèmes de fichiers serait peut-être également une bonne chose :)

            • [^] # Re: Indexation

              Posté par (page perso) . Évalué à 2.

              Ah ok, je t'avais mal compris en effet.

              La liste des buzz est déjà stockée en BDD (par contre, c'est mon indexd qui remonte les mots clés qui buzzent dans la BDD).
              Et pour tout le reste, il y a mastercard mon index inversé est vraiment performant, mais il est clairement moins flexible (et il y a des choses qu'il ne pourra jamais faire). Après, ta requête « python -serpent » est déjà gérée par mon indexd, avec de super performances :)

              Il y a longtemps, j'avais justement codé un petit moteur de recherche jouet, qui utilisait la BDD pour tout stocker (testé avec du MySQL puis du Postgres), et il s'est avéré que c'était très efficace. MAIS, quand j'avais beaucoup de résultats, les performances s'écroulaient :/

          • [^] # Re: Indexation

            Posté par . Évalué à 2.

            Par contre oui, ma méthode actuelle est ultra-simple, mais bon, c'est clairement pas idéal de stocker tout dans plein de petits fichiers.

            Si les fichiers sont vraiments petits. ext4 ou btrfs (je ne sais plus le quel) est capable de les stocker au sein même de l'inode. Ce qui me semble optimal du point de vu performance.

            Après je n'ai pas regardé comment tu requête tes données peut être qu'une base clef-valeur serait ce qu'il te faut.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Indexation

              Posté par . Évalué à 2. Dernière modification le 04/08/13 à 22:27.

              ext4 ou btrfs (je ne sais plus le quel) est capable de les stocker au sein même de l'inode.

              Les deux :) Ils sont tout deux basé sur des B-arbres et stockent les petits fichiers dans les feuilles.

              Please do not feed the trolls

          • [^] # Re: Indexation

            Posté par (page perso) . Évalué à 4.

            Après, ça me semble très dur d'arriver à trouver un système pour stocker mes index dans un ou quelques fichiers

            Vu la taille de tes fichiers (qqes centaines d'octets), je pense que tu pourrais remplacer le système de fichiers par une base de données clé-valeur plus simpliste. D'expérience, leveldb est parfaitement taillé pour le job, extrêmement rapide et offre même une compression (snappy) à partir d'une certaine taille. J'imagine qu'il doit y avoir tout ce qu'il faut en python pour en profiter.

  • # Jean Veronis

    Posté par (page perso) . Évalué à 7.

    Est-ce que tu connais les travaux de Jean Veronis, chercheur en traitement automatique du langage ?
    Son blog est très instructif sur les possibilités modernes de ces outils, et il y a présenté par le passé quelques outils qui ressemblent au tien :
    http://blog.veronis.fr/
    Il y a longtemps, il était consultant pour wikio, et depuis il continue à développer ses outils pour vendre des services autour.

    • [^] # Re: Jean Veronis

      Posté par (page perso) . Évalué à 1.

      Je ne connaissait pas, et il a l'air bien intéressant, merci !

      • [^] # Re: Jean Veronis

        Posté par . Évalué à 2.

        Malheureusement, il est decede accidentellement tout recemment. Snif. :-(

  • # bibliothèque cliente

    Posté par (page perso) . Évalué à 1.

    Existe-t-il une bibliothèque cliente pour pouvoir communiquer avec le serveur afin de faciliter des tests ? Ou doit-on tout faire soi-même (se connecter au serveur, préparer et envoyer la requête, lire le résultat, etc…) ?

    • [^] # Re: bibliothèque cliente

      Posté par (page perso) . Évalué à 1.

      Si ça t'intéresse, je peux publier la bibliothèque que j'utilise (un petit module python).

      Par contre, tu devra recoder des petits bouts, puisque celle-là est faite pour mon indexd modifié pour feedspot, qui n'a pas exactement les mêmes commandes pour la recherche.

      Elle contient aussi un parseur fait maison qui est plutôt puissant, mais particulièrement inmaintenable :/

      • [^] # Re: bibliothèque cliente

        Posté par (page perso) . Évalué à 1.

        Effectivement, cela m'intéresse :)

        • [^] # Re: bibliothèque cliente

          Posté par (page perso) . Évalué à 3.

          Hop, je l'ai ajouté, et j'ai même modifié les sections spécifiques à feedspot : il devrait être fonctionnel !

          Tu as le code sur GitHub.

          Ah, et si tu veux utiliser la fonction pour ajouter des documents, sache que j'ai aussi libéré la bibliothèque qui se charge de parser des texte ou du HTML pour en faire une liste de mots :
          http://repo.palkeo.com/scripts/html_parser/.
          (tu notera la présence d'une fonction pour récupérer tous les flux d'une page web dans htmldocument.py, ça sent bon le Feedspot là-aussi :D)

        • [^] # Re: bibliothèque cliente

          Posté par (page perso) . Évalué à 3.

          Dans ma grande mansuétude, je te passe aussi un script d'indexation de wikipédia :
          http://pastebin.archlinux.fr/467782
          Et un pour faire des recherches dans le wikipédia indexé :
          http://pastebin.archlinux.fr/467781

          Bon, c'est surtout pour que tu aie un exemple d'utilisation complète (fait un peu à l'arrache :/). Si tu veux le faire tourner ça te demandera quelques modifs.

          Et si jamais tu arrivais à te servir de mon indexd, je serais curieux de voir ce que tu fais :)

  • # y pas là !

    Posté par . Évalué à 2. Dernière modification le 05/08/13 à 10:53.

    chouette
    Cela devrait servir en e-réputation si on met son nom ou celui de son entreprise non ?
    les hommes politiques et les entreprises devrait donc être intéressés pour suivre les résultats d'une campagne de désinformation Publicités

    Sinon sur github je n'ai pas vu de licence et en France par défaut c'est non libre ça ne passe pas encore automatiquement en WTFPL

    a moins qu'il n'y ai déjà une jurisprudence github !!!

    T.

    • [^] # Re: y pas là !

      Posté par (page perso) . Évalué à 4.

      Cela devrait servir en e-réputation si on met son nom ou celui de son entreprise non ?

      En effet :)

      Sinon sur github je n'ai pas vu de licence et en France par défaut c'est non libre ça ne passe pas encore automatiquement en WTFPL

      Voilà, j'ai ajouté une licence dans mon code (licence BSD).

  • # LinuxFR

    Posté par (page perso) . Évalué à 6.

    Ça pourrait être drôle d'avoir un radar à buzz, et un buzzomètre dédiés à linuxfr, non ?

  • # startups

    Posté par . Évalué à 2.

    Tu peux peut être essayer d'envoyer ton CV là bas par exemple : http://www.dictanova.com/ . Il y en a d'autres dans ce genre, je crois, mais je ne connais que celle là :)

  • # Bravo !

    Posté par . Évalué à 2.

    Je trouve l'outils "flux dynamique" vraiment intéressant ! Quand on est un vieux routard d'un domaine on connait les adresses qui vont bien (et encore, on en rate toujours) mais quand on débute on ne sait pas du tout où aller pour suivre l'actualité du domaine. Ce générateur de flux dynamique me semble vraiment un bon point de départ !
    Le seul défaut que j'ai vu c'est que ça ne semble pas gérer les caractères spéciaux comme le + (C++ à tout hasard).

    Donc pour le "je fais quoi maintenant ?" voila une première piste ;)
    Et finir dans /dev/null serait vraiment triste !

    Bonne continuation

  • # rapidement.

    Posté par . Évalué à 2.

    Mouarf, juste génial.

    J'avais eu une idée dans la même veine, j'avais cependant moins en tête d'utiliser les mots clés, mais plutôt la catégorisation des articles par les internautes en fonction des différents sujets aborder.
    Comme toi j'avais en tête d'utiliser une frise chronologique.
    Il me semble que de bons articles ont plusieurs aspects, et que seul un cerveau peut le trier.
    Aussi l'usage des mots clés, il me semble favorisent les articles copier coller au détriment de ceux qui sont dans la contradiction minoritaire.

    Fin voilà merci pour ce partage, j'espère pouvoir m'y pencher prochainement !

  • # The radar roxx, man!

    Posté par . Évalué à 3.

    Le radar me semble un outil vraiment pratique pour suivre l'info généraliste sans avoir à se taper les flux des quotidiens (avec tout le bruit et les duplications qu'ils comportent).

    Par contre il y a du bruit dans les résultats (mais j'imagine que c'est concomitant avec le fait d'avoir un tri purement automatique), par exemple les dates ("mercredi", "August 8", "août 2013").

    Une amélioration qui serait peu coûteuse en dév (je pense… une règle CSS pourrait suffir ?) mais pourrait améliorer un peu la lisibilité : trouver un moyen pas trop encombrant pour délimiter les expressions clés. En effet, lorsqu'elles sont regroupées avec d'autres expressions de même poids, la seule façon de les délimiter est de passer la souris dessus pour activer le soulignage du lien.
    Exemple : Palme d'or Festival de Cannes Léa Seydoux et Adèle Exarchopoulos et Léa, avec 3 expressions clés : Palme d'or Festival de Cannes Léa Seydoux et Adèle Exarchopoulos et Léa.

    Less is more

  • # Yipiii

    Posté par . Évalué à 2.

    Un grand merci !!!
    Dans le cadre de l'étude que je réalise, je dois tous les mois identifier les thèmes marquants de l'actualité du mois précédent.
    Mon boulot est d'analyser les ventes des magazines papier. L'actualité générale du mois (élections, catastrophes, mariages ou naissances princiers) a évidemment de gros impact sur les ventes. Savoir quels sont les expressions qui ont le plus buzzer est un vrai plus dans ce cadre.
    Je me suis servie du radar à buzz afin de trouver les thèmes marquants du net sur le mois de juillet, merci !
    Si je laissais mon esprit divaguer, je pourrais imaginer dans le futur un croisement entre les hits des flux rss et les thèmes des parutions des quotidiens et des magazines, afin de voir les événements qui buzz sur le net et/ou en version papier.

    Pour être sure d'avoir bien compris, que signifie l'ordonnée du radar à buzz ?
    ex : 0.8 pour "orages" du 26 au 30 juillet, cela signifie que 0.8% des flux RSS de cette période ont parlé de ce sujet ?

    • [^] # Re: Yipiii

      Posté par (page perso) . Évalué à 1.

      Pour être sure d'avoir bien compris, que signifie l'ordonnée du radar à buzz ?
      ex : 0.8 pour "orages" du 26 au 30 juillet, cela signifie que 0.8% des flux RSS de cette période ont parlé de ce sujet ?

      C'est exactement ça !

  • # Bien

    Posté par . Évalué à 0.

    Je me sert de t'est outils plus de le radar à buzz et aussi flux dynamique

    Cela semble prometteur pour ma veille par contre pour le radar a buzz , de filtré différente catégories (cuisine , nouvelle technologie etc)

  • # Super!

    Posté par (page perso) . Évalué à 1.

    Bravo pour ce boulot, c'est bluffant!

    Question : Si je veux déployer feedspot sur sur mon serveur local (intranet) et proposer à mes collègues cet outil, les sources du site web sont-elles également sous licence BSD et dispo?

  • # Feedspot et feedspot

    Posté par (page perso) . Évalué à 0.

    Hello,

    Petite question : il y a un lien entre feedspot et feedspot ?
    A vue de nez, je dirais non, mais on ne sait jamais…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.