Naming Things is Hard

Microblog Set-up

I recently deleted my Twitter account and then quickly started looking at alternative networks. One thing I’m trying out is Micro.blog; I’ve had my account since the Kickstarter days, but for various reasons, I’ve never committed any energy to it.

In the interest of trying it out for real, I figured it was time to set up an actual microblog feed, something for short, title-free posts. This would double as an opportunity to use it as a learning project, and of course to see if I could have a little fun with it, too.

I’ve been playing with Eleventy for a while now; I have my own basic starter project that I tinker with now and then which lets me get basic HTML, CSS, and JS projects up and running fairly easily. It’s behind stuff like, well, this blog, and also Chickenwing Gingerbread Man, my “here’s a bunch of nonsense from me” site.

So far, I’ve got the basic flow working---you can see the currently unthemed output here. (My next step, clearly, is to actually design the thing.) The RSS feed is picked up by my Micro.blog account for syndication to the network. This all feels pretty nice! Now that I have it generally working, at least, for what amounts to a huge functional proof of concept.

Getting the starter blog up and running was pretty easy, given that I’ve been through the basic process already. I set up a folder in the repo for markdown files, which I group into a collection called “posts.” I installed the Eleventy RSS Plugin and got the feed running, and confirmed it didn’t implode when I left out titles. There’s probably tricky bits at this set-up level that I’m blanking out on, if you want to ping me with questions (like, say, over on Micro.blog...).

The glaring shortcoming of this set-up, though, is that it requires manually adding specifically formatted markdown files to a directory directly within my code repo, followed by a push up to GitHub to trigger a rebuild on Netlify, which, I forgot to mention, is where the actual site is built and hosted. Fine enough when I’m sitting at my laptop, though it does mean extra manual effort that goes against the grain of the whole micro-post concept, and it means I can’t post on the fly from my phone.

Enter Airtable. If you’re unfamiliar with Airtable, think Excel with a nice UI and a bunch of cool tricks up its sleeves. I’m hardly an Airtable power user, but I use it enough during my day job to know my way around it, and the UI, for being, again, essentially one for manipulating steroidal spreadsheets, is really super pleasant to work with. (And, oh yeah, it means I don’t have to create my own custom log-in system, too, which is a wheel I’m not much interested in reinventing for myself, yet.) So my idea here was to see if I could use it as an easily manipulated database for at least some of my content, parallel to the markdown files in the repo, which would stay in place, in case I wanted to add longer posts with titles directly to the microblog feed (which Micro.blog is super cool with).

Joy of joys, getting a dataset from Airtable into an Eleventy site via the Airtable API using the official client was actually delightfully nice. (I think I found this post from Dana Byerly quite helpful.) Conveniently, I also recently spent some time learning about data files and pagination in Eleventy, as I started working on converting an old Tumblr site of mine into a static Eleventy site; going through that process gave me a lot of insight into how the data pulled in from Airtable would work once I got it into Eleventy. Very similar idea, but instead of feeding a single hand-edited static json file into Eleventy, I used an API call to pull in data at build-time from the Airtable table of my choosing. Fun!

Of course, I couldn’t leave it alone. At that point, I essentially had two “collections” inside the Eleventy site, one for the markdown files and one for the posts coming in from Airtable. What I actually wanted to do was funnel both of those sets into a single collection, because it shouldn’t really matter on the front side of things where the posts actually come from. This was actually the biggest pain point of the whole process, in large part because of dates---my markdown files picked up a front-matter date I injected into the files on creation, while the Airtable posts used a created or modified date field in the table itself, and getting those two things to play nicely together was...not fun. Or, well, it was interesting, I should say. (Spoiler alert---all the Airtable posts were actually getting a page date applied to them by one of the files I was using to create them inside Eleventy, which played hell with my ability to sort the output and put the right date into the right place in the feed. Good news: there’s a hack for that!) After bouncing my head off the wall more times than I care to admit, I think I’ve actually got everything synced up (or brute forced) into place. Hopefully my feed will stay nice and stable.

About the actual Airtable base: super basic at the moment, basically just a text field and the created date field, but, the flexibility of Airtable means I can extend it on the fly to meet my needs. So like I set up an additional field to keep an eye on the character length of the post, which is fun. I also added a “Published” checkbox field, and then I filtered my output table---the one the Eleventy site checks---to include only posts that are checked: instant basic draft system!

Oh, and: I’m using Zapier to check for those new posts, which in turn triggers a new build of the site on Eleventy, without me having to manually update the code repo. This part is fine, but, I feel like I’m possibly eventually going to outgrow it, without actually wanting to pay for a pro plan, so I might have to figure out a way to handle this bit myself. I’m thinking...something, I don’t know what yet.

Right now the code repo behind the microblog is private but eventually I’ll open it up, once I clean it up a little bit and feel a little more confident that it isn’t completely embarrassing.

tags

Home & About & Micro.blog & Feed (Atom)