In reading my journals this morning, I realized that what future journal readers — my grandchildren, etc. — would probably benefit from is a dramatis personae, an index to the people in my life.
I imagine it as a simple flat list with each person’s name along with a short note on how I know them and any other relevant information — whether they’re a mortal enemy, for example. Or, more seriously, the years I knew the person, any name changes or transliterations, etc.
Building the index will mean skimming through all 10,000ish days of my journal. Whew. Names are easy to spot, though, which will hopefully help it go quickly.
Another entry in the neverending series talking about my personal productivity tools.
Momentum is my daily goal app, for keeping a goal chain/streak going. It’s a Python app running Django. The name comes from the momentum that a long streak gives.
Overview
Goals can be either binary flags (whether I did it that day or not) or timed (in which case Momentum keeps track of the time spent). The default mode is focus mode, which shows only the top unfinished goal at a time and looks like this (with dummy data):
The thin red line along the top is a progress bar showing how close I am to finishing my Momentum goals for the day. The red boxes show the last few weeks of the streak, the green box at the right is the button for saying I’ve completed that goal for the day, and the blue text under the goal name shows how long the total streak is.
When focus mode is off, it looks like this:
You can see a partially completed timed goal along with a binary goal. Momentum also supports ignoring goals for Saturdays and/or Sundays (the gray boxes among the red), which I use for things I don’t usually do on the weekends.
When the timer on a goal is running, the favicon changes and the page looks like this, with the pink box at right showing the elapsed time for the current session:
(The idea with the timer is that it may take multiple sessions spread throughout the day to meet the daily goal, by the way — if I wanted to make sure I spend an hour writing each day but don’t usually have time to do it all in one block, for example.)
How I use Momentum
On my laptop, I have Momentum open in Firefox as a pinned tab. On my phone, I have it saved to my homescreen as a PWA.
I use Momentum every day for my morning routine, primarily on my phone. The goals I put into it (as opposed to just adding things to my to-do list in Liszt) are things I want to do each day and, to some degree, are things I might not do if I didn’t have a streak pushing me forward (thus “Momentum”).
The future
I’m happy with the app as it is, but I’ve been thinking about merging it into Liszt, since goals like these are fundamentally to-do items. (Every morning Liszt already automatically adds all the items in my ::streak list to my ::today list, so that I can work off my to-do list without necessarily having to go back to Momentum as much.)
Giving Liszt items the ability to be timed is already in place with belt mode, so I’d just need to add the ability to keep track of both partially finished goals and total streaks. Seems worthwhile.
A Gentle Intro to Assembly with Rust — really liked this (I’m a sucker for assembly, even though I never actually use it) (though I need to find a way to change that)
WindowSwap — see the view out people’s windows around the world
Another entry in the eternally long series talking about my personal productivity tools.
Quill is a quick entry app for macOS and is effectively a desktop version of Gate. It’s an Electron app for now. The name comes from quills being used to write.
Overview
Not much to show here, actually. It looks like this (and the minimalism is very much intended):
There’s a textbox for writing and a word counter at top.
Once a payload is written, all the subsequent functionality is controlled via keyboard shortcuts: an app-wide prefix (ctrl+l — that’s an L) followed by the destination. v goes to Vinci, l goes to Liszt, j goes to my journal in Vinci, and b goes to my blog in Slash. (On my laptop, I prefer this to the buttons I used in Gate.)
The payload and action are then sent to an API in Gate, which does the actual sending to the destination systems.
How I use Quill
I leave it open all the time and use a global keyboard shortcut (configured in Hammerspoon) to bring it to the front.
Beyond the integration with my other systems, I often use Quill as a temporary scratchpad for drafting documents — emails, Slack chats, etc. — usually because the type size is larger. I also use it as a scratchpad for copy-pasting rich text into plain text.
The future
I’d like to move off Electron at some point, probably to a native Swift app.
Gate is a small quick entry app for my phone. It’s a Go web app, and the name comes from it being a gateway to my other apps. I used to use Drafts, but when it switched to a subscription model I decided to do my own thing (which worked out well for me, since I was able to make other customizations I’d long been wanting to make).
Overview
The main screen looks like this:
Just a textbox and some basic controls at the bottom. When I tap the Submit button, it opens up a dialog with options for where to send the contents of the textbox (the payload):
Red buttons go to Liszt, blue to Vinci, green to Slash. And this is why I have the text-based payloads in all those apps.
How I use Gate
I have it saved as a PWA to the homescreen on my phone, nestled safely in my dock. I use it all the time. (I suppose I could use it from my laptop web browser as well, but I have Quill for that use case, so I never do.)
The future
I’m happy with the app itself. There are, however, some recent bugs with text controls in PWAs in iOS Safari where the keyboard either won’t come up or can’t be dismissed, but that’s out of my control. Hoping those get fixed soon (they didn’t crop up until sometime in the last year or so, I think).
An update on the novel: I’m at around 226 pages on this first draft, which translates to roughly 87% done, based on my wholly arbitrary target goal. I also wrote out a brief sentence or paragraph about each of the remaining chapters, so that I have some semblance of a plan (which will almost certainly change).
Barring any serious life events, I should finish by the end of next week. Next week! After so, so many failed novel starts, it’s a wonderfully mind-blowing to finally approach this end of a full draft.
My current plan is to let the book sit for a month before I start editing. During that time, I’ll write short stories and plan my next novel (so that I have a rough outline when I start writing).
Also, once fall semester starts — the final semester of my master’s, here at last! — I’m planning to drop my daily word count goal from 1,000 to 200 or 300, to keep from overburdening myself. My hope, though, is that schoolwork ends up being manageable enough that I can still write more.
Brief backstory: when I’m doing my minimalist religious art, I usually sketch an idea out first by hand or in Paper on my phone, then mock them up in Illustrator to iterate on the concept. Once it’s satisfactory, I move to execution, either painting the piece in Procreate or using some of the brushes in Illustrator to get a more organic look. And finally I texture the image in Photoshop.
A couple months ago I got interested in exploring alternatives to Illustrator and Photoshop for both execution and texturing processes. And me being me, I wanted to try doing it in code, just to see what it was like. (Some things are easier in code, though I don’t know how often that would actually be the case with these.)
Note: this is still very much a WIP, and who knows if I’ll end up using any of it or not. But here’s the current state of things.
SVG
After reading somewhere that SVG has turbulence and displacement filters, I realized I could potentially use those for the execution part of the process, to distress the edges enough to make things more interesting. (And hopefully to be less repetitious than the Illustrator brushes I use.)
I put together an initial test using a few different settings, and it turned out a bit better than I expected. A sample of the code:
The background rectangle, the red figure, and the white figure all have different turbulence and displacement values. The red figure uses two sets of turbulence and displacement filters, which worked out fairly well, I think.
I used Inkscape render it out to a high-res PNG, since Illustrator wasn’t able to handle the filters. Eventually, if I keep going down this path, I’d hopefully be able to find a command-line tool that can do the rendering. (Maybe Inkscape has a headless option.)
Overall, this path seems promising. I don’t know that I’d use it all the time, but for certain things it may be handy. I still need to look into sane ways to round corners, and it seems that the other filters (dilation/erosion, convolution, etc.) may be helpful, too.
Grain
I’ve begun writing a Python script called Grain for texturing the final art image. The goal here is to see if I can streamline the process at all, and to see if this idea even works. Grain takes as input a text-based input file that looks like this:
Each block is a layer. Grain starts with the bottom layer (the executed base image) and goes up from there, adding each layer on top with the specified blending mode and opacity.
The :pattern roughdots command would generate procedural dots (not implemented yet), and the textures# bit in the :image command calls is a shortcut to my folder with texture photos.
So far, the results are disappointing. While the layering does currently work, it isn’t yet producing anything remotely publishable. I think there might be some discrepancies between blending modes in pyvips and in Photoshop. Hard to tell.
And, less importantly, it’s a little slow — partially from using high-res images, partially from Python. If the idea ends up working, I’ll most likely port this to Rust or Go, and probably also have scale things down for the exploration phase of texturing (with a final high-res export at the end).
I’ll keep tinkering with it from time to time and we’ll see how it goes.
I’m going to try batching links into groups of five from now on, since solitary links often feel a little too insubstantial for a post. Links often won’t be related.
Links #1:
Nadia Eghbal’s notes — rough, chronological, posted monthly, I’m intrigued by the format
Slash is the engine that runs this blog. It’s just a Python app running Django, but calling it an engine is too satisfying for me to stop anytime soon. The name comes from the ubiquitous forward slash in URLs.
Overview
Slash has an internal frontend with some post management pages (see below) along with a small API which is used by Blackbullet (my current website engine, separate from the blog) to pull posts into my site template. The API also publishes the RSS and JSON feeds, which Blackbullet passes right through.
The dashboard lists current drafts and, lower on the page where you can’t see it in this screenshot, recently published posts:
Disclaimer: there’s no guarantee that these particular post drafts will ever see the light of day. I often put ideas in and then decide later that they’re not worth blogging about.
Here’s the post edit page, which is very much a work in progress (last week I added the visual tag controls, since adding tags via the metadata textbox made it impossible to tell whether I’d used a tag before or not):
It’s spartan but works for me.
Payload syntax
Other than the notebook specifier, the syntax is pretty much the same as Vinci’s. Posts are written in Markdown. Metadata is specified with the initial-colon syntax.
One thing I realize I forgot to mention in the Vinci post is that in both apps I have a shortcut syntax for including images that looks like this:
I have a page for uploading images to a date-named folder — year and month — and this syntax relies on the image being in the matching folder for the post. A small bit of convention to make things simpler.
How I use Slash
On my laptop, I open Slash when needed. On my phone, I have it saved to my homescreen as a PWA.
Other than that, I use it the way you’d expect — I write blog posts (usually directly in Slash, but occasionally in Gate or Quill), I edit them, I publish them. Months later I finally notice the typos. It’s not too exciting.
The future
As of now, the plan is to replace both Blackbullet and Slash with a new, simpler, consolidated Slash, using plain text for the backend and probably moving to FastAPI. Since I’m in the middle of planning the rewrite right now (and since I’m now working in public), you’ll see posts about it soon.
While not all of these are actually one-liners, Una Kravets’s Ten modern layouts in one line of CSS has some neat tricks I hadn’t seen before. (I’m realizing I really need to brush up on modern CSS. It’s been a few years and lots of things have changed in that time.)
