I seem to have forgotten how to blog. (Actual blogging, as opposed to merely linking to new art.) In an attempt to get back on the saddle again:
Outside of art, my project time lately has primarily been swallowed up by some internal tooling changes. I alluded to this back in June, though the plan changed along the way. Rather than merging all those apps into one behemoth conglomerate, I decided it would be better (along at least a few axes) to follow the Unix philosophy and stick with smaller tools that do one thing well. Which conveniently lines up with the set of tools I’ve already built. Fancy that.
Arc is (was) my notes app, written using FastAPI. I wanted an app that felt more a wiki, and I wanted to move it to Django (easier to maintain, considering most of my other tools are also in Django). And I didn’t really like the name anymore. Thus Codex was born. Heretically, I built it using hardly any JavaScript — just a bit for keyboard shortcuts and another bit for the autosuggest when linking to another page. Everything else uses plain old HTML forms.
In fact, it was so liberating and fun that I plowed onward and decided to ditch Vinci (my internal blog/notebook app) and build a new app, Leaf, using the same technique; the only JS it uses is for keyboard shortcuts. It’s simpler, easier to maintain (I think? it’s still early on), and in a way it feels more in line with the grain of the web.
One other thing I did differently with both apps was to wait to write any CSS until after the functionality was all in place. It was disconcerting and delightful, building something with bare browser styles, and it certainly helped me focus on functionality first rather than getting distracted by layout.
Conclusion: while I doubt I would ever build apps at work this way, this old-school mode was invigorating and absolutely worth it for these personal projects.
Brief and no doubt boring update on internal tooling:
As of a few days ago, I’m planning to take Vinci (logs), Arc (notes), Storybook (fiction writing), and possibly Slash (blog) and smush them all together into a new, streamlined Django app called Writ. (Fundamentally, they’re all tools for writing, and there’s enough overlap among them that keeping them split out isn’t worth it to me.) Still in the initial design/planning stage. Looking forward to simplifying things a bit.
I’m no longer intent on using plain text as the data store for my apps. The main reasons I wanted to do this in the first place: a) archival durability and b) rampant minimalism. For the first, I’ll instead have all my apps export everything to plain text whenever there’s a change. It won’t be canonical, but it will be a redundant copy of the data so it’s even more archivally durable. As for the minimalism, well, sometimes one can go too far.
Lastly, I’m looking into hosting my site statically via Linode Object Storage (ala S3). Still exploring ramifications — redirects, etc. Main goal with this is to make my site more resilient, and even if the object storage part doesn’t work out, I’ll still move the site over to a new static engine (which I’m naming Cast, and I plan to write it in Go).
This is almost certainly not novel, but the idea came up when I was talking with my friend James the other day and I figured I’d write it up in case it helps someone somewhere.
The idea is this: you set up a new email address (or use filters with your existing email, whatever works for you) and then make a shortcut on your phone so you can easily add to your journal by emailing that address. A private email blog, basically.
It’s low effort in that you don’t have to open, say, a Google Doc and find the right spot to start to write. The corresponding disadvantage is that you can’t see what you’ve already written that day. (That said, this method would also work fairly well as a lightweight way to take notes during the day, to be written up into a full journal entry later somewhere else and then archived.)
I made a sample shortcut for doing this in iOS (and I’m sure there’s a way to do something similar in Android):
From left: the shortcut (using the Text and Send Email blocks), the running shortcut, and the resulting email. The shortcut can be saved to the home screen or used on an Apple Watch or put in a widget.
With this setup, I’d recommend regularly downloading your mail to your computer, through a local mail app or something like offlineimap, so that you have your own copy you can use for exporting or printing or whatever.
Note that I don’t use this myself because I already have a homegrown journaling solution (with Gate and Vinci), but I’m planning to use a variant of this shortcut for emailing notes to myself from my watch.
Anyway, if you try this out, or if you have an interesting system for journaling, let me know and I may do a followup post.
Another entry in the snore-inducing series talking about my personal productivity tools.
Vinci is my journal/log app, a private blog of sorts. It’s a Python app running in Django.
Overview
Vinci has notebooks which contain entries. Like most blogs, entries are displayed in reverse chronological order. It looks like this, except I usually write in English, har har:
Editing an entry is a modal fullscreen panel, with the main textbox at top, the metadata textbox under that, and some controls at the bottom.
On save, Vinci splices the metadata and the text together and runs it through the payload processor.
Payload syntax
Vinci uses the text-based payload idea like Liszt. Its payload syntax looks like this:
/projects
:tags foo, bar
Worked on the [foo project](/leaf/3290) for a while. Ran into a few issues.
The first line is the notebook specifier. The second line (and this could have been anywhere, didn’t have to be at the top) has a command with some parameters. And the rest is Markdown.
There’s also a variant syntax where the first line can look like this: /projects/tag/tag2/tag3. I’ve started using that a little more often.
Because of how I like to write in my journal, I’ve also set up a special case for my /journal notebook, where adding an entry will either create a new entry for the day (if there isn’t one yet) or append to the existing entry, so there’s just one entry for each day. (I use Gate or Quill to jot down a paragraph and then append it quickly and easily.)
How I use Vinci
I use Vinci a lot. I maintain my personal journal in it, along with logs for most areas of my life — work, school, writing, projects, church, etc. Sometimes I create notebooks for specific projects, other times I use a higher-level notebook (like /projects) and use tags instead. At some point I’ll probably consolidate.
I have a /thinking notebook where once each morning I think through my current tasks/projects and write out what I need to do for each. Writing things down makes a world of difference for me, across the board.
Each morning I also spend a few minutes reading one of my past journal entries, as mentioned earlier today. (A while back I scanned all my paper journals and I’ve been slowly transcribing them — we’ll get to Ditto soon — and importing them into Vinci.) Lately I’ve been reading through my 2004 college entries. My undergraduate years were great, but I am very, very glad I’m not in that phase of life anymore.
Lastly, I reference these notebooks fairly frequently. (When did we replace our dishwasher, what did I last work on for that project I haven’t worked on in months, etc.)
The future
Vinci currently uses Whoosh for full-text indexing, but it’s unsupported and hasn’t been working as well for me lately. Several months ago I realized that if all my notebook entries are stored in plain text files, I can just use ripgrep or ag for fast and accurate searching, with the further benefit that in the event of my untimely demise, everything would be fairly easy for my family to copy out and preserve. (I really like plain text, can you tell?)
To that end, I started writing a new, smaller app in Go called Leaf. It’s going well, but I’m tempted to switch to FastAPI. Not sure yet if I will or not. (I’ve enjoyed learning Go and have used it on several small projects now, but I’m also thinking more about long-term maintenance across all these apps, and using a single stack would simplify things for me.)
I’m also thinking about adding a small CLI (in the web interface) that would make entry management easier — moving all entries with a specific tag to their own notebook, for example. Truth be told, I don’t know that entry management happens frequently enough to warrant a CLI, but I’m intrigued by the idea of putting a CLI in the interface, and if it goes as well as I hope it will, I see myself doing that in more of my tools. (Right now I see it as an extension of the search interface. Where right now I type dishwasher to search for that keyword, I’d eventually also be able to type something like :move /projects#cardiff /cardiff.)
As with Liszt, I’m also looking forward to moving to a lighter, simpler codebase. Vinci has a moderate amount of vestigial functionality that needs to go.
