The past couple of years, I’ve spent December working on the Advent of Code, mostly in Clojure. It’s a ton of fun, and I highly recommend it. However, inspired by Arne Brasseur, I decided that this year, I’d try to write a blog post a day instead.
The first problem: I didn’t really have a blog.
I figured I’d go the static-site route, because there is a wide range of good tools out there. I was very intrigued by Gatsby, which seems legitimately awesome. Because I’m a huge fan of Clojure, I was also intrigued by Cryogen. Both are nice, because they both let you write Markdown (among other things), and Markdown is itself a great tool.
But I’ve been thinking, since this whole blog idea has been percolating for a while, that I really just want to write straight-up HTML.
I’ve noticed a lot of times when writing Markdown that I really want to “break the rules” just a little bit and throw in some custom HTML. Now, I know that Markdown makes provision for this in its spec. That’s terrific: I think our leaky abstractions are usually made better with those sorts of release valves. But it always feels off to me in a way I can’t quite put a finger on, and I wonder why I just didn’t write HTML to begin with.
The other thing about eschewing the static-site generators for straight-up HTML authoring is that it’ll be easier to make bespoke entries. I write React-based SPAs on the regular at the ol’ day job; I think it’ll feel good to get my hands back in the soil of the web. There are a couple of things that give me pause about the HTML approach.
For one, I’m using Tachyons to style this, because I’ve been intrigued by the “functional” approach to CSS. I am worried about getting frustrated with frequent copying and pasting of common patterns. With the power of a programming language, or even a CSS processor like PostCSS, it’s easy to extract repeated “components” into named things for easy re-use. I don’t know how it’ll shake out here with my every-entry-is-an-island approach; maybe I’ll end up integrating something like PostCSS into the toolchain. That’s another nifty thing about rolling your own stuff: you get to solve these sorts of problems. While that can be a disconcerting waste of time at work, for a personal blog, it sounds like a series of entertaining rabbit holes—maybe even entry fodder!
The other thing I’m specifically worried about from a tooling perspective is code blocks.
I anticipate a lot of the entries in here will feature code in some way,
and from the little bit of playing around with it I’ve done so far,
there’s not a way to display code that doesn’t come with some problems.
I’m just gonna use a
and see how long it goes before it gets too painful.
I could easily see pulling in a library to help out here.
I also wanted an easy way to publish the entries. I have not historically been a very consistent blogger, so I figured making it dead simple to shove HTML onto the web would be a boon to my budding authorship. I already have a meager web presence in Amazon’s S3 and CloudFront services, so I just added a post-merge hook to git for syncing the folder:
- ❶ Converts git’s branch listing into a single branch name.
- ❷ Make sure we only do this when merging into the master branch.
- ❸ When a git hook is run, it’s run in the context of the git project, not the
- ❹ Don’t ship the git repo off to S3.
This works as-is because I’ve already got some AWS credentials configured at
.aws/credentials that look something like this:
aws_access_key_id=access key id
aws_secret_access_key=secret access key
This is almost laughably simple. It won’t handle invalidations or deletions, for starters. I figure those are not likely to be common, but if when I’m wrong, I can adjust my tooling.
Hey, it’s a start. I’m looking forward to future entries! Given the one-per-day nature of these advent activities, I expect these will mostly be short entries of a tip-like nature. Hopefully, if I stick with it, I can find my way to writing more substantial fare. One day at a time!
- aws-cli/1.16.250 Python/3.7.4 Darwin/19.0.0 botocore/1.12.240
- 3.2.57(1)-release (x86_64-apple-darwin19) (bundled with macOS)
- 10.15.1 (Catalina)
- text_cmds-101.40.1 (bundled with macOS)