Nick Parfene over in the Indie Microblogging Slack asked me to write about my posting workflow and since I haven’t written about how I blog for over three years it could do with an update.
Why change?
First, why change the previous workflow? I got confused. Simple as that. My blogging schedule is erratic at best. And the old run and gun style workflow, while working, always left me scratching my head when I hadn’t touched it for a few months. I know, months is a sad amount of idle time between posts. But it is what it is.
So to keep myself in the loop what happened to my blog I decided to adopt Git for keeping a publishing history. Not only does it allow me to tinker with the blog’s templates and CSS without messing up, it also serves as a nice automatic history what I did when and for what reason. I just need to read the commit log to job my memory.
The in-between workflow
The last workflow I wrote about three years ago relied on a desktop machine running. While I have a server machine running 24/7 I did experience too many hiccups with that approach to feel reliable. So I switched it to a two pronged process that worked pretty well. On the go I was posting with Workflow and Transmit and on the desktop I was using Hazel with a custom Python script.
This tended to work pretty well. Especially the on the go version. Write stuff in whatever text editor suits you best (I use Ulysses), send over to Workflow for processing and upload to blog with Transmit. For images the procedure is similar only I use ImageOptim or Kraken for image optimization before uploading. I use both at the moment and have not decided which one I like better.
Micro.blog and Git
Now, beginning of this year Manton Reece created a Kickstarter project about Microblogging (Kickstarter is over, but you can enter your details on a mailing list if you are interested in it). I found the idea enticing and so I joined the project. This basically got me fired up to tinker with my blog again, which led to the adoption of Git since I couldn’t make heads or tails of whatever my latest changes to it had been.
The idea is really quite simple. Git has the ability to run scripts, so called Hooks, when certain events happen. In my case I use the post-receive hook to check out the newest version of my site whenever I push something to my server’s repository. There are a number of guides available, but the one I found most helpful was Nicolas Gallagher’s.
Once that is set up the writing pipeline is really pretty similar to what I had above.
Write stuff in whatever text editor suits you best (I still use Ulysses), send over to Workflow for processing, which then sends the article to Working Copy, an iOS Git client. In Working Copy I can check and if necessary correct the post or snippet and then commit and push the changes to my Git repository on the server. There is gets immediately checked out to the live site. For images I still use ImageOptim or Kraken.
The desktop version is almost the same really. I also use Ulysses for my desktop writing. From there I go via a custom Alfred workflow that preps the article and then I push the changes up to my Git repository with Tower, but I could just as easily fire off a simple git push from Terminal.