14 June 2020

Why I built the wrong blog publishing workflow

I used to find writing for a public audience to be a taxing process. I wasn't sure why, but I thought it might be because my workflow was bad. To tackle that, I built a small project. I hoped it'd be an end to my writing troubles.

This post goes over how I built that project (it is kind of a cool project). But it also goes over why it was the wrong solution.

Misdiagnosing the root issue

To decide what I "needed" to build, I started by comparing workflows: I looked at the way I wanted to write, and contrasted it to the way I did write.

My previous workflow had me spend a lot of time in my text editor. Which I thought was bad for writing, because when I'd start writing, I'd try live previewing my blog, and only an hour later realize I was knee deep in minor CSS changes.

So I thought it was the text editor that made it easy to get off-track. I wanted a simpler workflow. And I was actually so fed up with my previous workflow, I wanted to cut my laptop out entirely. I wanted to write and publish posts just using my phone.

What a mistaken conclusion. Looking back, _the text editor itself wasn't my problem_. I was just uncomfortable writing about something I was unsure of to a public audience. So changing how my blog looked was easy, but _writing carefully thought-out content and exposing it to public judgement_ was hard.

So, much like I'd procrastinate large projects in college, I wound up procrastinating writing by cleaning up my blog's styling.

Over-engineering the technical solution

On my laptop, after I wrote a post in Markdown, I would:

build my blog using Hugo
git push changes to Github
which then deployed the contents of the docs folder via Github Pages

I decided that to deploy from mobile, I would make a Lambda that did the same thing as my laptop. Meaning that after I wrote the post on my phone, I would:

send it to the AWS Lambda
which would then git clone my blog repo
then insert the post, build the repo using Hugo, commit the changes
and git push changes to Github
which would then deploy the contents of the docs folder via Github Pages

This meant that the Lambda would need to run Hugo and Git. Naturally, instead of adding a small amount of vendor lock-in with AWS Lambda Layers to manage binary dependencies, I opted for a mostly-academic seeming library to run Docker in a Lambda. I'm ashamed of how long it took me to get all this working.

(Note: There's also AWS's img2lambda, to convert Docker images to Lambda layers, but it didn't work in this case)

An interesting thing I noticed in retrospect: When I build projects for work, I tend to start with the absolute minimum, look for existing solutions before building them on my own, and use well-tested dependencies. But for side projects, I do the opposite.

I don't think this is a bad behavior, actually, because it lets me try out more risky decisions in a safe environment. But it does mean that I shouldn't expect the same results.

The architecture

So the architecture I built had three parts:

A text editing app of my choice, to draft the post
- This app was just for me to edit posts on. Any app would work, as long as it could export plain text. I chose iA writer because it had nice markdown preview support.
An AWS Lambda function, which published the post
- The most important part of this project. Source code is here.
- I wanted to use a serverless platform, because I felt the frequency of my posts didn't merit a full-time server.
An iOS shortcut, which took the post from the app and sent it to the Lambda
- I think iOS shortcuts are underrated, specifically for simple ETL tasks like this. Source code is here (only viewable on iOS).

The Results

And this is what my new workflow looked like, from start to finish. I could write a post, export it to the shortcut, which would send it to the Lambda function, which would publish it.

The full publishing workflow, with the Lambda doing a cold start

But while it looked nice, it didn't address my problems. Months went by before I felt I could publish this very post. When I finally edited it, I realized why it took so long to publish. And so I changed this post from a longer technical overview, to a shorter commentary on where I went wrong.

I still have a mobile post pipeline, but it doesn't look like this. It's just git app for iOS, and a Github action. I didn't write anything more complicated than a config file to use it.

But more importantly, I pushed myself to address the issues. I didn't like how my blog looked—-so I made it look clean and scale well on mobile. I was worried about presenting my opinion—-so I took time writing my opinions before subjecting them to judgement. I didn't have enough time to write—-so I set aside a full day for a post, instead of a couple hours.

So that's a start. Now, I'll have to keep writing to turn these behaviors into habits.