I’ve been experimenting. I’ve been concocting a recipe for vegan kugel, and rediscovering little features and edges of my website I’d forgotten I baked in. Like chocolate chips hidden in an oatmeal raisin cookie.

One chip most recently re-discovered: support for per-page custom styles?! All I gotta do is include an optional bit of meta data, bespoke-css, that points to a style sheet. I may play with this feature more. I do love myself some css. I can tell exactly when in my life I added this feature because these days I’d never call such a thing “bespoke-css” — it would get a much more boring, terse label, like “css” or “styles.”

The kids have been home on school break this week. We’ve been having a lot of fun reading The Wind in the Willows aloud, and playing a bit of No Man’s Sky on creative mode. You wouldn’t think it, but each carry a really similar vibe. Cosmic-pastoral-localism?

In the last week notes I made mention of potty training; at first that was harrowing and seemed like it would never happen. Then, all at once, it did!

I continue to expand the newly formed wiki. My plan isn’t to catalogue everything and anything — outboard brain style — but to really only document stuff I find useful and that I want to keep track of for myself…that maybe will be useful for other folks, too? The acme page is probably most inline with what I’m going for.

For good times, check out ratfactor’s rad presentation on forth!

I’ve also been playing with babashka, reading it’s excellent companion book, babooka. Babashka is a wicked fast way to use clojure when you’d normally reach for bash.

In accessibility and the product person I said

we need to make accessibility a core part of our processes

Here, I want to talk about that in more detail. I want to briefly explore what making accessibility a part of core processes looks like, and how that is different from centering accessibility as a priority.

RICE is a scoring model many organizations use to prioritize what to focus on. If you aren’t familiar with it, RICE is an acronym that stands for reach, impact, confidence, and effort. The idea is that you assign a point value to each facet, and use the sum of those points to help determine priority between a few competing ideas.

If accessibility isn’t part of your core processes and baked into the culture of your work it will show up as one of many competing ideas all placed against each other in the RICE model. When pitted against other ideas, and when using tools like RICE, accessibility, and equity concerns writ-large, are gonna loose. They’ll be considered, discussed, added to the backlog, but, almost never prioritized. They won’t be prioritized because, across the software development landscape, accessibility isn’t a profit center, it is a cost driver.

But this is a solvable problem.

Stop using RICE and tools like it that don’t include accessibility and equity as facets of their model.

Add it if it isn’t there.

By adding them as a facet, RICE+Equity, you make accessibility a key part of all your decisions. You can still put the accessibility projects up against other ideas, but no matter what, by baking accessibility (and equity, generally) into the frameworks used to determine priority we can begin to ensure accessibility is a core consideration helping to guide all product decisions, and not left as a project on the backlog.

I recently re-read Peter Naur’s “Programming as theory building”. Afterwards I set out to write my own text editor. The paper posits that it’s really hard, if not impossible, to fully communicate about a program and sort of gestures at the futility of documentation…what spun around inside my head as I read was that our primary programming medium — text files — is silly. Like, some folks would totally 100% scoff at my writing forth but, at the end of the day, forth and javascript both produce executable text files despite being lightyears apart. What if a text editor let us have something more than just text files as artifact?

So, like many before me, I started to write my own text editor. And it sucked. What I made sucked, and the process itself sucked…or, at least, it didn’t lead to anything particularly different from the vast array of existing text editors. I wanted to be able to support a different paradigm of writing code, I didn’t wanna just produce vim with worse ergonomics. I didn’t make much progress, even leveraging web technologies that gave me a lot “for free,” because before I could begin to reinvent any particular wheel I had to crawl out of the primordial ooze…

Then I realized I didn’t actually want to implement my own text editor! I’m not a fanatic about what editor I use; I’m pretty evenly split between sublime text, emacs, text edit, vim, acme, and mg. I bounce between them depending on what I’m doing, and for how long I’ll be doing it. What I wanted was to be able to support a slightly different mental model of what a “file” is using any existing editor!

That was an easier technical nut to crack. It took about 2 hours after the kids went to bed with a little bit of help from the inimitable llimllib on mastodon…and all I did was write a shell script!?

So, my personal solution to the cutting edge of programming being just text files is to add even more text files!…at the end of the day, they’re a really really hard thing to leave behind, especially if you’d like to preserve compatibility with any existing programming system.

I wrote a shell script called Moon Maker. Moon maker, or mm, lets you attach orbiting moon files to central planet files. A planet file is the one you really actually care about — its probably a file in a project. A project can have any number of planet files, and a planet file can have any number of moons in orbit of it. Moons are files that orbit a planet, they’re places to take notes, a scratch space, somewhere to try things out, or add layers of information about the planet. A moon file can have any file extension, and references the planet by it’s name. Moon files live in a directory of their own, .moons, and each can be referenced by a unique id, or, collectively by the name of the planet they orbit.

    Moon Maker

    ⋆｡°✩ ☾

    mm is a small program that lets you add orbiting moons to existing planets.

    A planet file is the one you care about -- probably a file in an actual project.
    Moon files orbit planets, they are disposable scratch spaces connected to planets.

    usage: ./mm
                    -i(nit)....initialize a directory to store moon files
                    -o(pen)....open a planet file and all of its moon files
                    -l(ist)....list all moons for a given planet file
                    -a(dd).....create a new moon file for a given planet file
                    -d(elete)..remove a moon file by its id
                    -c(lear)...remove all moon files for a given planet file
                    -u(pdate)..rename a planet file and all of its moon files

The idea is you use mm sort of like you’d use git — you initialize it at the project level, and then add moons to planets as needed within the context of a project.

By default, moons open in your EDITOR of choice, but I’m thinking of adding support for editor overrides so you can easily open planets in one tool, and moons in another.

I don’t honestly expect many or any folks to use this thing, but I’m excited too. It matches my mental model, and, my process: usually, when I’m working on a project, I end up creating a bunch of temporary or scratch files to document little corners of something, and experiment. This enables that in a consistent way across my projects while maintaining compatibility with all of my existing tools. If this works out, and doesn’t have any toothy gotchyas I’d like to support adding moons, satellites maybe, to specific lines, or regions of a planet file, too. My first attempt at this thing was more elaborate — rather than bash and saving to the file system, I tried to do something with sqlite, and having a database backing each file of a project.

The idea was to support using any convergence of row and column number of a text file as an id, and then generate a connected moon from that. This was a cool idea, but so fragile as to be untenable. Plaintext doesn’t offer a great way to reference specific points in a file if that file is changing.