There and Back Again

It's been a while since I've written here.

While a part of this absence has been caused by a ramp up in professional work, the only reason I could stand under on a rainy day is to not be on my computer when I don't have to be. The idea being it might be good to start reading a little more, playing some video games, or just enjoying the physical world for a bit as opposed to giving this machine more than the 50~ hours required by work and life responsibilies.

The break's been nice for sure, but as I take another look at the tech atmosphere, I realize that there are things in this space that I want to achieve, things I want to learn, and things I need this computer to do. One of those things is writing, and another branching out into the software community.

This post however isn't a "Hey, I'm back". Primarily because, besides crawlers, no one really reads this site, but also because what it took to get back to writing was much more involved than I expected. But why?

Namely, I have yet to set up a proper deployment pipeline, nor did I regularly commit my changes, but rather ad hocly pushed the gzip compressed articles up to the S3 bucket where this site lives.

One could call it negligence (it was totally negligence), but in the end, when I decided I wanted to write a post (it (was going to|will) be about Django Signals) I realized to do so would either require deepening the rabbit hole I lovingly dug for myself, or taking a step back and cleaning shop. Given my burst of motivation, I chose the latter.

First, context: this site is totally handwritten. I don't use any writing or publishing tools other than Emacs and a Makefile I created using the former.

Instead of spending time researching platforms, deciding which was best for me, and learning how to use it, I decided I was, and am, more interesting in writing. So I did just that. I wrote a few articles based on notes I'd kept around, saw patterns, and made a yasnippet template empowering me to type article\TAB to produce a skeleton article.

After a bit of this I got tired of manually dragging and dropping HTML files into S3, a Makefile was written (by me) with a task to sync the bucket and the directory. Then I got interested in writing automated optimizations for my site, instead of depending on Cloudflare to do them for me. Thus, the Makefile grew, resulting in a basic build process expressed in a few lines of commands that would minify the CSS and HTML to a public folder, copy assets over, gzip those files, and finally sync everything with AWS.

Perhaps for such a simple, small site, it was a bit of overkill; but overkill was the point. Peeling back the modern web developer's layers of tools and abstractions was the foundation of this site, so why not continue that in the build process.

Some more time passed, I figured that version control would be a good idea in case my current machine died, my bucket disappeared, or any other sort of potential disaster requiring me restore the site. This intention was good but not followed through, articles would go up without having been committed, but for my public of one, nothing was awry. Unfortunately, at some point my local copy, with uncommitted changes, was lost. Probably deleted in some del-happy file system cleansing, where I must've assumed that I had been responsibly versioning.

And there I was: without a extendable local version of my website, a git repository that was five articles and several style changes behind, and a S3 bucket containing the end product of my homegrown build steps.

Fortunately, with few commands in my terminal I was able to restore the uncommitted changes, mostly.

First I had to ungzip my articles in order to commit the original content. In this step I learned more about find and particularly about the -exec action which enables one to perform commands on the found files. The first action uses mv to append the gzip extension to each file so, in the second action, gzip could recognize which files to decompress and do so.

find puhrez.com/things/articles/ -type f -exec mv '{}' '{}.gz' \; -exec gzip -d '{}' \;

Once I had my decompressed articles, I only wanted to move those which were not already in my version controlled directory. Here I use a variety of tools, of which I was comfortable using diff, which outputs the difference between the folders, and grep, which filtered that output to those files only found in one of them (in this case the uncommitted articles). While I've used awk in the past, I'm definitely not adept in it yet, stackoverflow helped. A new command for me was xargs, which took the text piped into it, allowing me to reference it with {} and pass that to mv, copying the right files over to the repository.

diff -q puhrez.github.io/frontend/things/articles/ puhrez.com/things/articles | grep "^Only in" | awk '{print $4}' |  xargs -I {} cp puhrez.com/things/articles/{} puhrez.github.io/frontend/things/articles/{}

Now that the missing articles were decompressed in their corresponding folder, I looked them over to make sure that they were fine.

They were not.

Perhaps it was the aggressiveness of the decompression, but many attributes where missing quotations, moreover the minification made the content difficult to follow. Luckily, some Emacs replace-string and query-replace-regexp calls were enough to bring things back into shape. I decided recreate the style changes by hand so that I could update them as well.

Finally, I added basic git push command to my make public task, helping ensure that in the future, I'll be at least aware of uncommitted changed.

Needless to say (though I'll say it anyway), I've (re)learned a few things:

.back