I'm not sure middleware is the right term for a server that responds to webhooks.
Either way, I think this is a good introduction for someone who is looking to do very simple things with an IFTTT integration. I don't think a node.js server running a python script inside of a docker container is the best way to go about it. Anyone who is trying to learn how to write integrations to services (such as IFTTT) will get the wrong impression if they try to dissect this code.
Yeah. I made something similar with a raspberry pi I had around the house. Hosted a simple HTTP Server using 10 lines of Flask, and used IFTTT's Maker service to glue it all together.
There are many ways of getting this setup, whatever you're most comfortable with. The key here is that this Maker service exists that let's you do basic REST input/output
Zapier has this built in. Granted you can only really write scripts that run directly on their platform in JavaScript, but within that scope you can do basically anything you want.
You can also write your own private apps that execute on your own infrastructure in whatever language you want.
There is this website, donorschoose.org, that allows you to donate to schools within the United States. Teachers are able to post projects that are open to funding - art supplies, music, books, etc - and their projects would be posted in a public space and open to funding from individuals or organizations.
Donors Choose also has an API that one can use to programmatically list projects. I paired that API with Zapier to notify me about projects that I cared about - namely, classrooms that were filled with lower income students who had trouble getting fed at home.
Now I get a notification whenever a new project is created that fits the profile of what I want to donate to. Doing the same with IFTTT, from what I can tell, is kind of impossible. I looked into writing a shim API that would enable that type of notification but I couldn't get keys for the IFTTT service.
I dunno. Zapier seemed to offer better functionality and I didn't even have to pay for it.
Slightly OT: I signed up for the IFTTT newsletter a long time ago, in hopes to find out what people use the thing for. Turns out it's impossible to unsubscribe from that newsletter, which disqualified the whole service in my eyes.
Mark them as spam. Train your provider's filters and let the problem solve itself. Get enough people on board and suddenly poof unsubscribe links will appear like magic!
1. Logged to a google spreadsheet when I enter and leave a radius around my work. I have to log hours worked, so this gives me a starting point at the end of the week for when I was physically here.
2. I get a stock price emailed to me when the market closes. I own a few shares of a single company (lowers my auto insurance premium, and keeps my engaged in the market), so this helps me see day-to-day changes.
3. I get the weather pushed to my phone at 6am every morning, so it is there on my lock screen as I'm getting up.
4. I get an email every time someone goes into space. SPACE.
Not OP, but from googling around, it seems like that there are many stocks which offer stockholder discounts/rewards. For example, it appears that stockholders of BRK.B can get an 8% discount on Geico insurance.
I've noticed a very scummy technique in newsletters that I've been signed up for lately. They are making the messages a certain length so that all the information they want to present is there but the legally required unsubscribe link is hidden behind gmail's automatic truncation of long emails.
This makes it so you have to click the view whole email button.
That is not an unsubscribe link. Unsub links remove you from the list without having to log in
One of my more annoying frequent inbox flyers is a newsletter from some website or other that says I need to log in to change my preferences.. only my account there must have been purged as they have no record of my email address (the exact email being sent the newsletters)
Sites - just provide easy one-click unsubscribe links, chances are it'll improve your open/click rate as you're letting people who aren't interested sift themselves out.
Perhaps that link did something for me, I have no idea. Why do you not have an unsubscribe link in your e-mails? Where I live, this is a legal requirement.
Also in the UK, but the last list I tried to request an unsubscription from (and with references suggest they include an 'unsubscribe' link) bounced the email. What really are you going to do...
I've started using stringify with IFTTT to get a lot of my home automation working now.
I'd use stringify exclusively but IFTTT has a lot more integrations, so I end up using IFTTT as both a trigger and action in stringify. Ugly, but it works.
Python2 is still what comes installed as stock on many distros. I know Fedora/CentOS ship with it, in part because the package manager Yum/DNF is based in Python2.
On Fedora, Python comes pre-installed with first class support for
Python virtual environments. It is ready for use straight out of the
box. No guessing package names, no installation, just dive in and go.
Look:
[fedora]$ python3 -m venv env
[fedora]$ . env/bin/activate
(env) [fedora]$ python ...
Note the python3 ...
EDIT: wow, 4 downvotes for stating a fact that Fedora developers themselves are shouting from rooftoops. The Python3 hate is strong today.
Yup, and it will be reviewed and likely changed at some point:
This recommendation will be periodically reviewed over
the next few years, and updated when the core development
team judges it appropriate.
So it's likely that at some point between here and 2020, or in 2020 at worst, the recommendation will change.
IMHO Python 3 has now reached a level of maturity and backward-compatibility where it can safely take over as system python. It's now shipped by Fedora, which means the next RHEL will also ship it. Updating old scripts should mostly be a matter of grepping and shebanging from python to python2, and there is now no point in procrastinating further with this move.
Out of curiosity, how recently have you touched on that?
I was one of them until the last couple of months. I think moving to 3 now makes sense, and it's pain-free in my experience.
In 2016 I hadn't made the move yet. And as recently as a couple of months ago, sometimes py2 was still the choice (for instance, Amazon Lambda didn't support 3 yet).
This is still anecdotical, but most python developers I know would chose py2 if given the choice. It's what they know, and they don't want to change semantics even if it's just changing how you write prints.
Counter-anecdote: Not a single developer I know wants to touch Python 2 after trying to get Django to work reliably with Unicode.
Then again, if your language is completely representable with US-ASCII, you might not have experienced the pain caused by having to unit test pretty much all string operations in your code.
I've re-written sample script in pure shell code :P
The idea is that I'd like to write little to make little things work with IFTTT. Py2 is just enough to do a lot while keeping things casual and of fun. Py3 is too serious to me and shell script just awful...
Either way, I think this is a good introduction for someone who is looking to do very simple things with an IFTTT integration. I don't think a node.js server running a python script inside of a docker container is the best way to go about it. Anyone who is trying to learn how to write integrations to services (such as IFTTT) will get the wrong impression if they try to dissect this code.