Until a month ago I had never written a blog post.
My recent discovery of DEV has a lot to do with why I started, and indeed, I created my first post right here on DEV.
While educating myself on the art of writing for other people, I came across the term "POSSE", which I had never heard of before but is apparently kind of a big deal. It is a principle that is embraced by DEV itself, according to Ben.
The idea intrigued me, as do most things that involve "write once and reuse" concepts. I began to imagine how such a thing might be accomplished, and just like P.O.S.S.E. itself, the recipe for its implementation seemed simple on the surface:
- Create a "source of truth" for your writing.
- Know where you want to distribute, and how to do it.
- When your truths change, ensure a process is triggered to ferry your changes to the right places.
I don't know about you, but that sequence of steps strongly reminds me of the basic recipe for deploying software. And so I immediately re-imagined it as such:
- Create a
git repo for my writing.
- Decide on the platforms I want to distribute to, and write scripts to do so via public APIs.
- Setup
git hooks to run those scripts when changes are made.
Long story short (the "long story long" will come as a separate post), I took a week of evenings and a weekend, and made this:
a simple implementation of the POSSE content publishing model
syndicate
A simple implementation of the POSSE content publishing model, packaged as a Github Action.
Write your content, store it on Github, and use this action in a workflow to draft it to silo platforms like DEV.to. The action will keep the silos up to date with your latest changes here on Github.
Wherever possible, when content is syndicated to a silo for the first time, it is created in an unpublished/"draft" form. Any exceptions to this will be called out in the documentation for silos below.
The silos currently supported are:
A key assumption made by this project is that your content is written as Markdown, and includes a YAML frontmatter containing at least a title property. If this is not the case for you, this action sadly does not currently support your worflow. If you would like to see support for some other way of making…
As the README describes, it will let you write your content on Github, and distribute it automatically to DEV.to, keeping subsequent changes in the content on Github synced to DEV.
It is designed to be used as an action in a Github Workflow, but technically it is just a simple Python program that can be run with Docker if you want (I include a Dockerfile). To use it as intended, all you need to have is a Github repository, and all you need to do is create a Github workflow in that repository which uses dabrady/syndicate in one of its steps.
For now, it only recognizes one silo platform, DEV.to, because that's the only platform I currently publish on. But I made it simple to add plugins/adapters for other silo platforms, so if you'd like to contribute, that's a great way to do so!
Like my first blog post, this is my first project written with the intent to share with other people. It's also my first time using Python in almost a decade, so I used The Hitchhiker's Guide to Python as my main resource for project management and layout. Any and all feedback is greatly appreciated! 🙏 I hope it benefits us.
Hey, this is really on point, and we’ve been working on a lot of features to help people pull off POSSE in a simpler manner, while also trying to roadmap a future where trust is pretty clearly baked into our product.
Medium Was Never Meant to Be a Part of the Developer Ecosystem
Ben Halpern for The DEV Team ・ Jun 3 '19 ・ 5 min read
Project Benatar: Fending Off Data Black Holes
Ben Halpern for The DEV Team ・ Jun 17 '19 ・ 6 min read
I’m not sure if you’ve read those, and some of the other posts we’ve made on the subject, but let me know what you think!