Ceci est un post invité de foxmask posté sous licence creative common 3.0 unported.
“C’est l’histoire d’un mec qu’est su’l’pont de l’Alma et regarde dans” … le python, et comme il débute, se demande mais putain de bordel, des projets à la con à pondre pour se lancer à l’assaut d’un langage, c’est toujours les mêmes trucs chiants que plus personne n’a envie de voir tels : forum, blog, wiki, cms. Alors comment être novateur un poil plus que ces projets sans (plus aucun) défit technique ?
A cette question je me suis dit, pourquoi ne pas produire “simplement” (toute proportion gardée) un équivalent libre au célébrissime IFTTT ?
Mais qu’est-ce ?
IFTTT est un service qui vous permet de brancher entre eux, les services internet où vous possédez un compte, comme Twitter, Facebook pour ne citer qu’eux (parce que la liste est longue comme un python au moins;) Et donc quand un évènement défini se produit sur votre compte twitter, genre un tweet de votre poto tombe, le service réagit au quart de tour pour rebalancer les données ailleurs, sur Facebook, un blog et n’importe quoi qui vous chante.
Hé bien cet équivalent libre est Trigger Happy, et ce “principe” décrit ci-dessus défini un ESB (Entreprise Service Bus, très connu du monde Java), un BUS qui récupère des données de droite et vous les expédie à gauche.
Wikipedia le défini ainsi :
L’enterprise service bus (ESB) est une technique informatique intergicielle. Son but est avant tout de permettre la communication des applications qui n’ont pas été conçues pour fonctionner ensemble
Pourquoi un tel projet ?
3 aspects :
- Avec ce projet je me suis lancé le défit d’arriver à cerner au mieux Django et abordé au mieux Python.
- Comme tout ce que j’entreprends, se produit par pur réaction allergique à un truc qui m’a gonflé, explications les zamis :
Au début on fait (plus ou moins) comme tout le monde, sa veille techno à partir de flux RSS de sites web choisis, avec un lecteur de flux RSS moins bien choisi comme iGoogle à une certaine époque ou encore … Google Reader.
Là le truc qui m’a pris le chou, ce fut d’avoir dans Evernote, le résultats des flux RSS de mes sites favoris complètement atrophiés.
Du genre “il a été à l’école” devenait “il a t l’cole”. Or le problème ne vient pas d’Evernote qui affiche parfaitement nos chers caractères latins, mais de IFTTT qui les bouffait au passage. Outre IFTTT il existe des versions payantes de services mais qui sont vite très vite limitées dans le nombre de triggers déclenchés que sont Zapier et CloudWork. -
Le dernier aspect concerne sa chère vie privé.
Oui en effet, pour que IFTTT puisse récupérer des donnés d’un service à l’autre, il faut que vous ayez un compte sur chaque service comme Twitter et Facebook. Pourquoi IFTTT en a besoin ? Pour que, “en votre nom”, avec les accréditations que vous leur octroyez, puisse lire/écrire les informations de part et d’autre.
Mais pourquoi faire confiance à IFTTT / Cloudwork / Zapier ? Pourquoi leur offrir NOS accréditations les yeux fermés ?
Trigger Happy repond à la question puisque l’application vous appartient, les accréditations obtenues de Twitter, Facebook etc, sont stockées dans VOTRE application Trigger Happy. Et personne n’ira les exploiter pour voir ce que vous faites sur vos comptes.
Comment fonctionne le projet ?
Dans la version simplifiée ceci donne :
Image tirée de ma main “gauche” gauche, enfin la gauche pas adroite
De part et d’autres (dans les nuages) on a les services qui nous intéressent
Les éclairs oranges sont les connecteurs qui permettent de dialoguer avec les services
Au milieu .. (non ne coule pas une rivière) le moteur Trigger Happy qui gère, via les connecteurs, l’échange des données.
Dans la version complète ceci donne :
Trigger Happy Micro ESB
On a au milieu un “tube” (pipeline) qui va permettre, via des “command” & settings & url & service provider, d’identifier les services “django th 1, 2, 3, 4″.
A un moment donné, à l’entrée du tube, arrive un “flux” de donnés identifié pour admettons “django th 1″ aka un flux RSS (au pif) puis on identifie une destination, admettons “django th 2″ aka “twitter”, et les données collectées repartent donc du tube vers twitter, comme le service s’attend à les recevoir.
Dans la vraie vie comment ça se passe ?
Ça se passe bien mon zami : je m’en va (la fote est volontaire tout comme l’reste;) vous montrer la création d’un trigger, permettant d’extraire les billets du flux de mon blog et de les renvoyer sur Twitter en 5 étapes :
Ici en premier lieu vous pouvez voir la liste des services que Trigger Happy gere pour l’utilisateur courant (mézigues)
Trigger Happy : services activés
Puis l’accueil de l’appli où on remarquera que je suis radin en nombre de trigger affichés par page parce que … je me sers de l’appli via un browser sur mon smartphone m’sieur ‘dames :
Trigger Happy : Accueil
Etape 1:
Choix du service fournissant les données
Etape 2:
nommage du service et fourniture de l’origine des données
Etape 3:
Choix du service accueillant les données
Etape 4:
Trigger Happy : Etape 4 de la création d’un trigger
Ensuite le moment venu, se déclenche ce trigger, et pour en voir le résultat, on peut consulter le billet que j’avais préparé le mois dernier pour une présentation Django Paris. Et qui au moment de la publication du billet, à 19h15 pétantes, est tombé sur twitter directement et Evernote dans la foulée.
Voilà !
Le défit est parti et n’attend plus qu’à ce que le nombre de services croissent. Pour cela rien de plus simple, j’ai fait une doc expliquant comment pondre un module django qui exploite le service de votre choix tel Buffer, Trello, Dropbox et j’en passe et des meilleurs. Tout ce dont on a besoin : l’API du service visé en python, créer un compte pour avoir accès au service et suivre le howto sur readthedoc
Last but not least aux dev : ca tourne avec django 1.7 / Python 2.7 et 3.4
Dernier détail: comme je suis sûr que vous vous demandez pourquoi ce nom de projet ? C’est un perso de la franchise Skylander auquel joue mon fils et comme le projet “trigger” à tirelarigot sur l’net, ca collait pile poil :)
Apprendre un truc aujourd’hui : check ! Merci !
Vu dans la doc :
Other majors features will be :
Using Autobahn or anything else like that. This would speed up the handling process : in other words : being multiprocess/async with no blocking process.
Cool, je garde un oeil sur le repo !
Je trépigne de pouvoir utiliser l’un avec l’autre, mais je me heurte à des problèmes aussi bien avec autobahn (la doc est déphasée par rapport aux sources d’exemple existants dans les dépots du porjet par exemple) que django, que je compte conserver pour au moins la partie front. Je suis loin des perf de wamp, mais j’ai divisé par 4 à 5 le temps de traitement en passant d’une RPi, où le projet tournait parfaitement, à un VPS. Donc pour le moment je préfère que tout à chacun (ceux qui savent;) s’installe le projet et le fasse tourner chez eux (genre un pote adepte des solutions alternatives aux solutions de gros sites web, se l’est installé et a jetté IFTTT aux oubliettes ;), et quand j’aurai pu mettre wamp en branle, j’ouvrirai un SaaS sur trigger-happy.eu qui ne demande plus que ça ;)
Le besoin d’un bridge HTTP se fait de plus en plus sentir. J’ai jeté les bases ce matin, mais vu le taff que c’est pfiou…