I love static sites, but doing a blog as a static site (as this one is) has long come with the pitfall that I don't actually use it much, because of how all the content files are in the code repo, and that means either needing to do all my content entry directly into the repo, or going out to the repo on Github and manually adding files, or whatever. If only there was a way to manage the content as if it were a unique part of the system…
Enter Static CMS! Which is actually a fork of Netlify CMS, a project which I knew about but which I'd never looked into, as I'd mistakenly assumed it was some kind of premium database-driven back-end thing, which it turns out it is not, nor is Static CMS: instead, these are basically basic web apps that present an admin interface for manipulating the content files in the repo, directly, no database or whatever system required.
And…it's pretty slick. I have some things I want to try upgrading, but as a concept—as a way to make “content entry” feel like actual content entry—it's all there. Hopefully the project keeps its momentum going (and hopefully I find some blogging momentum in using it).
First, I've been thinking about how I should figure out a way to post to this blog without needing to open up the repo locally; I really like the way I have this set up and all, but that's been kind of a blocker. Then I got to wondering if I could just duplicate a file on the Github website and edit it directly. Which lead me to the fact that they put VS Code in the browser, which is ridiculous, but, okay, here we are. This might work.
Second, I just dropped a new Link of Note for the first time in forever, which immediately reminded me that I broke the templates for Link of Note and Today I Learned posts, when I was last messing with the design of this site. So those look weird. Maybe I'll find some time in the next year to fix them. I think there was more I wanted to do with them. Maybe. I don't know!
For me, it's really easy to remember that one rem is sixteen pixels. It's then really easy to do the math based on that: half a rem is eight pixels. A quarter, or 0.25, is four. An eighth, or 0.125, is two. Sure, it took me a couple minutes to commit the full range to memory, but now I know without having to think about it what 0.625rem's going to give me (five-eighths of a rem, or ten pixels (a mere eighth less of a rem than 0.75rem, which is twelve pixels (itself a mere eight-of-a-rem step away from 0.825rem, or fourteen pixels))). These are fixed values. They're in my brain now and I keep them on the tip of my fingers and rattle off anywhere I need when I'm concerned about spacing or sizing in a design context. It's kind of a superpower.
Trying to keep track of wht an em is in any context gives me a headache. I like the idea of "let me give this a little more of whatever or a little less of something depending on the local context" but in practice if I'm going to say "give me half of something" I want to know what the something is. Like, definitively. Half of something in one place might be way more than I want. In another place it might be too little. It can also completely change depending on the local context of my local context. I don't have time for that. I'm a busy man. I have children to make dinner for.
It's like, if you told me that I can measure everything in inches (or centimeters, or cubits, or whatever) but that I'd get a different result for what an "inch" is based on whether I'm measuring it on my desk or in my garage or on top of a ladder in my neighbor's backyard...I don't want to carry that many tape measures around with me. I want one tape measure. That measures in inches. Neatly dividable into half inches and quarter inches and eighth-inches...
Over on my CWGBM site, I have a section devoted to what I call "coding sketchbooks." I don't dive into them as often as I'd like or as deeply as I should, but they're nice to have around for scratching the occasional itch, clearing my head, and developing loose libraries of ideas and code for reference and use elsewhere.
Lately I've been dipping back into my SVG sketchbook because an article on Frontend Horse pointed me toward the SVG.js library, which I've decided to take for a spin. It definitely makes working with SVGs a bit easier, though certain weird learning curve moments still come along for the ride.
Under the hood, these sketchbooks are mostly all instances of Fractal. Though it's primarily intended for component or pattern library development, somewhere along the line I got the idea that, with a little massaging, Fractal would also make a great base for a kind of iterative code sketchbook. I like keeping track of ideas as they develop and having running records of stuff I'm working through, with easily accessible fall-back points that I can always branch off from as needed.
So like on the SVG site you'll see something like a Grid concept take on a series of forms (a la one through five), as I decide I've made something I actually like and I want to hang on to it, or I decide I just want to try something different without overwriting whatever progress I've made in the previous iteration.
What makes this fun and less painful to do is, I've put together a node script in the code repo, which lets me, from the command line, point at any directory in the sketchbook, clone it, and rename it—including updating a sort of "id" inside the directory, so that all my scripts and styles become "unique" to each individual iteration. That way I can change or destroy whatever I want in an iteration without worry that I'm burning the bridge I've built behind me getting to that point.
Mostly. If you root around these things you'll find I also play with developing utility libraries and the like that multiple iterations pick up and use...hopefully without iteration 1 of an idea breaking when I change something seemingly innocuous in the common code when I'm hacking away on iteration 10. It's a bit messy but I've made it work for me.
I'm sure this could all be done on Codepen or in some other way but I like owning my own stuff when I can, I really like Fractal a lot, and I like having all my stuff for a given library or technology or whatever all in one big (messy, yes!) codebase for later reference and reuse from directly within my code editor. This isn't the perfect set-up, but I'm fond of it.
In the SVG sketchbook I've been playing with generative grids full of shapes, always a good place to jump in and start tinkering. I find myself continuously turning toward a funky pastelly/acidic pink/green type of palette, which is maybe one of my favorite things in the world, for some reason? I have also been using the JS library as an excuse to finally start learning a bit about how to write my own SVG path code in a generative fashion, which is less scary than I expected. A couple sessions of this kind of thing does wonders in terms of refreshing my interest and pushing my knowledge and understanding, I believe.
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.