Since the phone is now the window to the soul, here’s my current home screen:
Things of possible interest (or more likely imminent boredom):
30 Seconds is a system shortcut I made that starts a thirty-second timer, which I use for my physical therapy exercises morning and night (I used to use a third-party app until I realized I didn’t need one)
Projectile (an app version of my project tracker), Bookshelf (reading tracker), Slash (blog engine), Storybook (writing app), Momentum (time tracker), and Liszt (to-do list) are all PWAs I’ve built
While it’s kind of weird (they’re the same exact app), I love that Marvin SxS is on the App Store alongside Marvin; I use the dark-background Marvin for fiction and the white-background Marvin for nonfiction
From left, the three bottom apps in the dock are Codex (notes app), Saturn (launcher), and Gate (Drafts clone), which are also PWAs I’ve built, and clearly I have a problem
I currently have 136 tabs open in mobile Safari, and clearly I have two problems
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).
Joel Hooks on blogs and digital gardens — this makes me want to finish my revamp of Slash so I can more easily add an actual digital garden to this site (and at some point I’ll write about that revamp since I don’t think I’ve gone into any detail on it)
Amy Hoy on how blogs broke the web — it’s not quite as bad as the headline sounds, but still some good food for thought (you could say this is another way of looking at stock vs. flow)
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.
I recently came across Maggie Appleton’s article on digital gardens. Oh my goodness, this is delightful. I’m sure some small part of it is just nostalgia for the old days of the web, but the idea seems good and solid nonetheless. I love digital gardens. (See Mike Caulfield’s The Garden and the Stream and Swyx’s Digital Garden Terms of Service for more in this vein.)
Exploring some of these gardens led me to the idea of learning in public (also see Gift Egwuenu’s Learning in Public talk). Very closely related to digital gardens, of course, but a different angle to look at it from. It also nicely parallels the working in public idea I posted about recently.
I’m looking forward to adopting more of these practices myself. Not sure yet exactly what form that will take, but at the moment I’m thinking it’ll probably be the notes system I mentioned. While that would be doable with the website engine I have now, it wouldn’t be very ergonomic, so I’m probably going to retool. (And by probably I mean almost certainly, because I am an inveterate toolmaker at heart. I’ve written out plans for a new version of Slash, my blog engine, that will easily support notes as well as blog posts and web pages. More on that soon.)
Nine months later, I’m merging my blogs back into one. (Apparently this is going to be a regular back-and-forth thing here, so you may want to get used to it.)
Long story short, I think I’m more prone to blog if I don’t have to worry about categorizing my posts. Tagging is fine for some reason, but categories seem to add cognitive friction, so I’ve gotten rid of them. We’ll see how it goes.
Of minor technical note is that I’ve turned Slash into a pure web service backend, and the blog frontend is now hosted on the same domain as the rest of my site. This is the first time I’ve split the frontend off from the backend, but already I really like it — division of concerns, loose coupling, etc. At some point I’m planning to look into doing the same split with the rest of the site. (To clarify: at the moment, the site and the blog run on two different backends. With the site, the backend and frontend are currently unified.)
The pruning and splitting of the blogs is now complete. From 2,600 posts down to 400, and from one blog to (cough) fifteen. In my defense, these blogs are basically like categories, albeit with a bit more separation (tags don’t cross blog boundaries).
There is of course a feed for each blog (see the subscribe page for the list), and I decided to do a consolidated feed as well. I also added exclusion parameters to the consolidated feed, so if you really don’t care about my type design and art posts, for example, you can use this URL: https://blogs.bencrowder.net/feed/?exclude=type-design,art
The blogs are running on Slash, a Django app I wrote. It’s fairly simple, and writing it hardly took any time at all. (What took the most time was going through the 2,600 posts and deciding which to keep and which blog to put them in.) Also, I’m trying out Disqus for comments. Still not completely sold on it, but it was faster than adding comments to Slash.
