Journal Tweeter le contenu de votre base de données - db2twitter - support des tweets avec image

Posté par (page perso) . Licence CC by-sa
Tags :
11
24
mai
2016

Salut,

Ce journal pour annoncer la disponibilité de db2twitter 0.6. Pour rappel, db2twitter déjà présenté dans cette dépêche sur LinuxFR.org, continue son bonhomme de chemin avec cette nouvelle version offrant principalement la possibilité d'associer des images à vos tweets.

Pour rappel, db2twitter se connecte à votre base de données (MySQL, PostgreSQL et tous les types de bases supportés par SQLAlchemy), se sert des données récupérées pour créer un tweet selon un format défini par l'utilisateur, puis poste le tweet sur Twitter.

Il permet également depuis la version 0.4 de renvoyer en boucle les n derniers tweets. Le but est de ne pas dépendre d'un flux RSS, de votre CMS, ni d'ailleurs d'une appli web ou autre pour émettre des tweets de façon automatisée.

db2twitter est codé en Python 3, principalement développé pour l'instant dans le cadre du site d'emploi pour la communauté du Logiciel Libre et opensource LinuxJobs.fr.

  • # Cool, on va pouvoir diffuser les bases de données de clients de banque sur twitter

    Posté par . Évalué à 2.

    Trop génial …

  • # Use Case

    Posté par . Évalué à 3.

    Je ne vois pas de use case ("cas d'utilisation" en Français ?) pour cet outil. Tu pourrais nous dire pour qui il est utile ?

    Merci :)

    • [^] # Re: Use Case

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

      Prenons un site web, par exemple LinuxFr.org. Tu développe le site et tu aimerais bien que quand il y a une nouvelle dépêche, elle apparaisse automatiquement sur Twitter. Avec db2twitter, il suffit de le configurer pour la DB correctement et il va automatiqument pousser les dernières dépêches parues sur Twitter.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Use Case

        Posté par . Évalué à 3.

        Mais voilà un exemple parfait !

        Merci :)

    • [^] # Re: Use Case

      Posté par . Évalué à 3. Dernière modification le 24/05/16 à 18:24.

      Tu as une réponse :

      Le but est de ne pas dépendre d'un flux RSS, de votre CMS, ni d'ailleurs d'une appli web ou autre pour émettre des tweets de façon automatisée.

      Je suppose que tu dois pouvoir générer des tweets en fonction de l'ajout de lignes dans une table par exemple (si j'ai bien compris, il est utilisé lorsqu'une offre de job est insérée dans une base : diffusion ensuite vers twitter).

      Après c'est ton imagination qui définit les use case.

      Celà dit, comme indiqué dans mon message plus haut, ça peut être dangereux. Je pense qu'on aura des problèmes de fuites de données sur twitter (si ça ne s'est pas déjà produit) si l'architecture en amont est mal définie.

      • [^] # Re: Use Case

        Posté par (page perso) . Évalué à 2. Dernière modification le 24/05/16 à 23:30.

        Celà dit, comme indiqué dans mon message plus haut, ça peut être dangereux.

        o_O ça voulait dire cela ?

        Je pense qu'on aura des problèmes de fuites de données sur twitter (si ça ne s'est pas déjà produit) si l'architecture en amont est mal définie.

        quand tu diffuses des messages : c'est toi qui définit tes cibles, les protocoles utilisés… la capacité à revenir en arrière peut faire partie des besoins :-)
        ce n'est pas que twitter qui est en cause, mais bien le choix de diffusion fait par l'auteur.

        Note : Toute ressemblance avec des événements récents dans les journaux de LinuxFr.org serait purement fortuite.

        • [^] # Re: Use Case

          Posté par . Évalué à 7.

          ce n'est pas que twitter qui est en cause, mais bien le choix de diffusion fait par l'auteur.

          C'est bien pour ça que je précise "si l'architecture en amont est mal définie". Personnellement, pour ce genre de diffusion, j'éviterais de plugger cet outil à une base contenant toutes les données de mon service, mais je ferais plutôt ça sur une réplication partielle (en ne répliquant que les champs qui peuvent être diffusés). Mais je suis convaincu que certains sont capables de mettre ça en direct sur une base contenant des données sensibles.

          • [^] # Re: Use Case

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

            Je t'ai plussé parce que ce que tu évoques est une bonne pratique générale.

            Mais en fait je vois pas quelle distinction tu fais entre "plugguer ce genre d'outil sur ta base", et "publier un flux RSS à partir de ta base" ou encore "publier les annonces sur ton propre site". A partir du moment où tu as accès à l'information, que ce soit pour la diffuser sur twitter, ou sur tes propres pages, le risque d'accès à des données confidentielles est bien réel.

            Par ailleurs, cet outil n'est a priori pas "paramétrique", donc pas d'injections SQL comme on peut le faire sur un (par exemple) le site web qui accède aux même données et propose des filtres, de la pagination, etc.

            Enfin, les bases de données relationnelles proposent des rôles utilisateur avec une gestion de droit d'accès sur les données à granularité plus ou moins fine permettant par exemple de déployer "db2twitter" avec une configuration "qui va bien" et qui n'aurait accès qu'aux données requises.

    • [^] # Re: Use Case

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

      Pour le cas typique d'utilisation,tu peux jeter un oeil au compte Twitter de LinuxJobs.fr : 99% des tweets sont envoyés automatiquement par db2twitter.

      D'une manière générale, j'essaie de pousser db2twitter vers une grande flexibilité dans sa récupération des données dans les bases de données ainsi que dans la possibilité de customiser le format des tweets à envoyer.

  • # DB = DataBase != SQL

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

    S'il n'est pas prévu d'ajouter du support pour des bases Not Only SQL (MongoDB, ElasticSearch, CouchDB, Cassandra, …), ou au moins de fournir la possibilité d'ajouter des "drivers", alors il faudrait peut être penser à renommer le projet sql2twitter.

    Je vois trop souvent cet amalgame, cela en devient frustrant.

    • [^] # Re: DB = DataBase != SQL

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

      On ne s'interdit rien à ce niveau même si le support de bases NoSQL n'est pas à ce jour prévu.

      C'est avant tout les besoins qui surgissent au quotidien qui définissent la roadmap des futures fonctionnalités de db2twitter. Le moteur de requêtes est pour l'instant SQLAlchemy qui, sauf erreur de ma part, gère uniquement des bases interrogeables via SQL. Mais si tu pousses le support pour MongoDB, ElasticSearch, CouchDB ou Cassandra ou encore mieux un ORM au-dessus de différentes bases NoSQL (je ne suis pas sur que ça existe vu le bordel que c'est au niveau des langages de requêtes NoSQL), je t'aiderais volontiers à l'intégrer à db2twitter.

      Donc on garde le nom db2twitter vu que nous ne sommes pas fermés à l'idée de gérer l'extraction des données depuis une base NoSQL :p

      • [^] # Re: DB = DataBase != SQL

        Posté par . Évalué à 1.

        Python étant turing complete, en effet tu ne t'interdis rien :)

        Donc on garde le nom db2twitter

        Cool, on pourra continuer à troller :)

      • [^] # Re: DB = DataBase != SQL

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

        Sans parler d'ORM, on a dans Canopsis depuis quelque temps un système de ce genre.

        On a une API "Storage" qui fournit les opérations de base que l'on réalise sur différents types de techno (default pour clé/valeur, graph, timed et periodical pour de la timeserie, etc…), et on code un driver qui implémente cette API (à ce jour on a du MongoDB 2 et InfluxDB).

        Après au niveau de la config, on spécifie l'URL du-dit Storage.

        Ça sera externalisé du projet sous peu et dispo sur PyPI ^

        Je te renvoi vers cet article qui parle justement de ça.

      • [^] # Re: DB = DataBase != SQL

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

        ou encore mieux un ORM au-dessus de différentes bases NoSQL (je ne suis pas sur que ça existe vu le bordel que c'est au niveau des langages de requêtes NoSQL)

        Il y a Ming notamment qui propose de "s'affranchir" de MongoDB en python. Mais bon…

        Le concept d'un ORM pour les bases "Not (Only) SQL" ça n'a pas vraiment de sens vu que la définition est la négative d'un modèle (le standard SQL) mais pas la définition d'un standard.

        Dire "existe-t-il un ORM pour les différentes bases NoSQL", c'est comme de dire : "existe-t-il un permis pour conduire ou piloter tout ce qui n'est pas une voiture". Non, ça n'existe pas, et c'est assez logique : piloter un avion, manoeuvrer un bateau ou conduire une moto, ça n'a tout simplement rien à voir.

    • [^] # Re: DB = DataBase != SQL

      Posté par . Évalué à 5.

      Même réaction.

      Un CMS qui utilise une base de données relationnelle doit faire des pirouettes pour construire le contenu.
      Taper directement dans la base de données de ce type de CMS veut dire reproduire les pirouettes.

      Dans tous les cas, il n'est pas recommandé d'attaquer directement la couche données d'un service. Le service doit être seul responsable de ses données. Il faut donc demander le contenu au service par sa couche API.

      dbtables=jobs,
      jobs_rows=companyname,jobtitle,id,logo
      jobs_image=true

      Ici, l'outil suppose qu'il existe une table, requêtable en SQL, qui a une colonne avec le contenu, une avec l'image. Ce n'est pas générique. Cela répond au besoin de l'auteur. Et c'est déjà bien.

      L'outil pourrait être nommé "tablerowcol2twitter".

      Je reste sur ma faim aussi sur l'absence de templating.

  • # [HS]

    Posté par . Évalué à 1. Dernière modification le 31/05/16 à 23:56.

    cela peut se faire par une BDD mais ne souhaitant pas écraser une mouche avec un marteau (tout en souhaiter l'écraser quand même) , connaissez-vous un outil pour tweeter une ligne de texte ?

Suivre le flux des commentaires

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