Ephemeral tweets. Running “cron” on cloud. Fly.io machines.
Part I: Why I want ephemeral tweets
Some months ago I decided to lower my twitter dosage.
I’m not moving to mastodon and I’m not even blaming Twitter’s new owner for the all the shitty experience with the social network. We build our own timelines. We decide which tweets we reply, who we retweet or — the start of so many shitty interactions — what we quote-tweet.
We — collectively — have made twitter the shitty place it can be. If an alternative network emerges with similar enough rules, we’ll make it shitty as well. I believe the shit is mainly the by-product of what we do in a place like that.
It’s addictive shit, though. Which is why it’s self-reinforcing.
The app has been gone from my phone for over a year. Notifications were not driving my usage of twitter. But still, I came back to it and engaged on shitty stuff. And created my share of new shitty stuff, of course.
Then it struck me that “my twitter” is not the app I removed nor the site I keep visiting. It’s the value we assign to the “content” we create and see there. When people thought that Twitter could collapse, some of us went and downloaded our archives. That’s what we wanted to salvage.
I guess some of us come back to twitter not (just) chasing notifications, but because we feel it’s the place where we also build — over time — a corpus of useful content. Micro-blogging, as we called it when it all begun.
That’s naive. We rarely reference past tweets. Not in a constructive way, at least. The most common use cases I see on my timeline to resurface past tweets: blaming others for being wrong in the past, blaming others for changing their opinions, assert how right we were in the past. I have done it as well, of course.
So, in my slow quest to use twitter less, I deleted my archive (as much as Twitter’s API let me). And I’ll be constantly deleting anything older than 7 days. Twitter for me will just be a place to have small ephemeral interchanges.
Part II: Cron jobs in the cloud?
The cloud is expensive.
It’s also a no brainer for anybody who doesn’t need tons of computing/storage/etc resources. Only at certain scale it makes sense to own and operate computing resources. Constantly deleting tweets older than 7 days is obviously not above the threshold. Renting the small amount of resources you need is the way to go.
A decade ago I would have used Heroku as a cron-on-the-cloud. As most Heroku users, I have been burned by the way the service was neglected. So I had to figure out how to run a process one a day.
I guessed it would mean building a docker image and then something will run that image daily. The something was my own machine at first, while I looked for the Heroku-replacement which was hopefully going to make this easier for me.
Part III: Fly.io machines
Fly seems to me like the spiritual Heroku-successor. It’s not just a replacement (in fact Render might be a better replacement for all the things Heroku provided, like a managed PostgreSQL service).
What I mean when I say Fly is a sort of evolution is that they give you useful abstractions so you can focus on the dev side and delegate the ops work to them.
One of those abstractions are fly machines. Here is how I used them form my ephemeral-tweets-via-cloud-cron project:
1. Create an app to hold machines
Assuming you have Fly’s CLI installed
fly apps create --machines --name ephemeral-tweets
(You should pick your own app name if you want to do the same as me)
2. Create a Dockerfile with the thing you want to run.
For my use case it was super easy as the author of twitter-cleaner also publishes docker images (and I might even avoid creating my own Dockerfile, but I wanted to learn the generic case):
ENTRYPOINT ["/usr/local/bin/twitter-cleaner", "--max-age=168h", "--twitter-consumer-key=XYZ", "--twitter-consumer-secret=XYZ", "--twitter-access-token=XYZ", "--twitter-access-token-secret=XYZ"]
3. Setup a fly machine to run the image daily
fly machine run . -r iad --schedule daily -a ephemeral-tweets
And that’s it. Fly has its own scheduler and it works fine for my use cases. Here are the times it is running according to the machine details in Fly’s dashboard:
On the dashboard you can take a look at what goes on when your machine run, on the Monitoring section. Looks like I’m consuming about 5 seconds of CPU per day:
And that’s it. Besides having my ephemeral tweets (as long as Twitter API permits it), now I know how run small cron jobs like I would have done via Heroku in the past.
As a bonus, Fly uses firecracker under the hood, booting up machines really quickly. And you can control those machines using Fly’s API. Pretty handy if you have to build an app which might run user’s code.
PS: Maybe github actions could also be (ab)used to run small personal cron jobs like this one? I still think using a proper cloud