okay uhh that part was easy? II

eeheeheehah hah hah!

A week or so ago I wrote that I had automated sending webmentions but wasn't happy with my execution. I have been, evidently, unhappy enough to keep thinking about it, and now I dare say it is Good!

I started thinking about my workflow, and how what I had configured in my last post meant that if I adjusted a typo or added a build file or changed my CSS or whatever, I'll automatically send out a webmention attempt. Normally, that shouldn't be a huge problem because I currently don't link to many other blogs, but if there's a time the top RSS post includes a link... I'll keep webmentioning them every time I update until a new post takes the top spot in my rss feed! That led me to look into what that means. Best I can figure, the receiving server will just respond with a "yeah I got that one already, dude", so unless I do a lot of pushes directly to main in short order, it shouldn't be a problem, but. It was one more reason to go :/ over my method. But! in researching, I stumbled onto localghost's blog post outlining her method and it locked several things into place via providing context and provided a way forward.

Context, I've found, is super important to me when learning a new thing in the codingsphere. I have a lot of difficulty with the abstractions relied on when providing instruction--the foos and quxes and i iis scramble my head not a little till I can get grounded with relating what I'm reading with what I'm trying to accomplish. I'd like to think I'm getting better, but I still clearly miss a lot: as Sophie points out in the post above, the answer to my problems trying to bridge the gap between using npm to run the webmention and integrating it fully within my build files was staring me right in the face on webmentions.app's section about the commandline. I can put remy/webmentions as a dependancy in my site's package.json and then set the webmention command as a postbuild action. I just couldn't ken what Remy was recommending I do because I hadn't connected all the dots yet.

That's only the first thing tho--Sophie's post also shows a fun method to only call the webmention command sometimes: in her case, only when there is a recent commit and she commits with a message that includes "post". This lets her schedule a regular website build refresh without sending any webmentions. I studied what she had (and learned a bit more bash syntax, which is nice for my lifetime slow build to Understanding linux) and made my own version that follows the same principle of "keep a file that holds a string, check that string against the current status of the files" but checks the most recently touched file in my posts folder instead of against commit hashes. It took some trial and error to get this sorta running, and even then I ran into a Critical Error: letting the workflow write to the file is fine, but making it actually commit to the repo so it persists for next time is a different level entirely.

I spent some time researching github actions permissions and looking at the localghost.dev source--which Sophie kindly has as a public github repo--and. I couldn't figure out how her file that tracks commits gets saved! Either: I am missing something, Sophie is updating that locally and pushing to the repo along with her post, or that particular check is not working. I have no idea which it is--probably the "I missed something"--but it got me thinking about other things I have that I can check against that wouldn't require the github action to commit a change on the repo^[1]. I ended up flopped on my bed staring at nothing for a long while, but I came away with a nice solution: I could publish a page on my site that holds the latest post title, curl that, and compare against the same contents of the fresh website build before it is pushed to the website.

Right about then, at that point where I had the idea sketched but none of the blocks to actually get there, the weekend ended. I don't get to work on the coding aspect of my blog much during the week--I spend enough time on the computer at work to not feel up to sitting at a desk more after^[2]--but I had this idea stuck between two teeth in my brain that I really wanted out. This started, as it does, some new thoughts to get stuck in the brainteeth. Reader: it is not rough to write a markdown-formatted post on a phone and upload it to github to update my website. It is hard to do any sort of coding on a touch screen keyboard. I do not have a laptop, nor would I want to bring one to work (I'd totally do that on a wfh day tho lol). I semi-regularly think about the Concept of Cyberdecks, and boyy was this a week for that: a raspberry pi 4 or 5 would be just the ticket: a linux environment. Give it a little screen. A physical keyboard. Tempting!! but. I. do. not. need. another. project. to. not. finish. Plus--the more I thought about it, I came away with two things that I really wanted out of it that I could... already achieve with the computer in my pocket.

My current pain points were: 1) no easy access linux terminal to test bash scripting and 2) no device larger than my phone keyboard to twiddle on during workbreaks. These are... addressable without any undo complication. I can get a keyboard to attach to my phone wired or wireless. I can get a linux terminal through the Power of Termux. I ah. Fell Down Yet Another Rabbit Hole re: physical keyboard,^[3] but I did fix problem 1 immediately. Termux is neat! I can install node.js and git and pull my website repo and wiggle it well enough for my purposes with nano. Once I pick one, a keyboard will solve problem 2, and then I'll basically be cyberdeckin' it without spending hours designing a case and crying about powersupplies and without buying a ton of new stuff. (Altho, speaking of new stuff, if I really want a bigger screen I could also,,, get a touch enabled usb-c powered mini monitor,,,) So. Linux dev environment in the palm of my hands, yesterday and today I've cracked apart the problem, solved it, realized a critical flaw, and solved that too. Don't tell my boss.

With the power of Being Able To Easily Try It Locally I got a nice bash script working, along with a Very Silly page orphaned on my site that snags the 11ty collections.post list and outputs the newest one's title^[4]. The script curls the title into a variable, compares it to another variable that cats the file in the new website build, and if they match, no automatic webmention is sent. It was working real nice! Until. i noticed a critical flaw in my order of operations. My github workflow performs a single job in this order:

1. build the site. 1a. at end of build, compare what is published to what will be published, send webmention if needed.
2. publish site to neocities. The problem is this: if I send a webmention before I actually publish my site, the webmention is going to fail. A webmention is a webmention only when the sending server actually has the link mentioned on the site, and verifying that is part of the protocol! If I send a webmention before the link is actually available on the web version of my site, I'll get an error 400: a mistake on the sender's side.

This means the correct order of operations is build>check for webmention eligibility>publish site>send webmention if needed. In order to do that with my hard-earned bash script, I had to learn more about github workflow syntax and how it handles passing info between steps in a job. That took some doing--the whole abstraction thing again--but I was on a roll at that point and found enough examples to piece together what I misunderstood in the documentation^[5] and make it work. It's smooth! it's pretty! it only sends webmentions when it is supposed to^[6]! And it should Just Work for now until the webmentions.app node.js repository ceases to be! That's the kinda reliability I Like.

Before it was easy and worked. Now it is "Well That Was Rather Hard To Do" but also It Works Way Better. And I did all the biggest lifts from my phone?? Maybe I'm getting this webmention thing down! Maybe next I'll have to organize snippets of my code, draw some diagrams, and become one of the many guys posting "here's how I did webmentions"... but maybe after I get a keyboard, lol.