It started when I came across Karin Hendrikse’s article on building a static RSS reader (oh how I love static files), and then Terry Godier’s post on RSS and phantom obligations nudged me away from the idea that a feed reader has to be something like Feedly or Google Reader. At some point Feedly started adding more AI features (ugh) and I decided it was time to part ways and do my own thing.

Digest is a little command-line tool I built in Go that reads a list of feed URLs from a text file, fetches all of them in parallel, caches the responses, parses the feeds, and then compiles a list of all the posts from the day before into a static HTML file. That’s basically it. I run it manually on my laptop and rsync the HTML up to my server so I can get to it on my phone.

It’s been great so far. A few other thoughts and observations:

• Boundaries and edges feel good. It’s like a personal daily newspaper, where it’s very clear when I’ve finished for the day. Infinite rivers carry more stress, I think. Or maybe I just like checking things off lists.
• The slight time distancing also feels good — quiet and calm. Because it’s a daily digest from the day before, it feels like less of a dopamine slot machine. No more checking Feedly dozens of times a day.
• I originally had Digest run on my server via a cron job, but I moved back to running it manually on my laptop and I’ve found that I much prefer it this way. Fewer moving parts. (If I’m unable to generate the digest on any given day, by the way, I can pass the date as a command-line argument to the tool and it’ll compile posts for that date instead of yesterday’s.) A bit more resilient, too — I can just open the HTML file locally on my laptop if I want, no server needed.
• At first I included the contents of each post in the file, but I’ve since trimmed it down so each entry just has the post title and link plus the blog title and the author, and I open each link in a new tab. After decades of reading RSS feeds in homogenized typographic settings (all posts in the same font, etc.), I thought I wouldn’t care to read posts on their original sites, but I was wrong. I love it. Especially since most of what I read is on the small web.

As of now I have no plans to release Digest as open source, but maybe this description will inspire someone to build their own tool that meets their personal needs.

Reply via email

Back in 2017 I did end up re-architecting Press to use Low Ink as an intermediate page description language. In the process, Low Ink changed from a JSON-based idea to this:

:page 11x8.5in
:bleedbox x=0.125in y=0.125in w=5.75in h=8.75in
:fontmap family=helv weight=regular style=normal standard=Helvetica
:yinvert
:push
:translate x=72 y=72

# ascender
:push
:translate x=0 y=1040
:strokecolor hex=#999
:linewidth 0.25pt
:line x1=0 y1=0 x2=1080 y2=0
:stroke
:push
:fillcolor hex=#999
:font family=helv size=14pt
:text x=1085 y=-3 text="ascender"
:pop
:pop

# filled glyph
:push
:translate x=1320 y=240
:fillcolor hex=#000
:moveto x=0 y=0
:pathto x=400 y=300 cx1=120 cy1=300 cx2=140 cy2=300
:pathto x=320 y=200 cx1=540 cy1=300 cx2=320 cy2=180
:lineto x=350 y=350
:lineto x=450 y=250
:lineto x=150 y=0
:moveto x=200 y=200
:lineto x=200 y=250
:lineto x=250 y=250
:lineto x=250 y=200
:lineto x=200 y=200
:fill
:pop

It was intended to be a fairly low-level wrapper on the PDF format, with the idea being that other libraries/apps would provide more ergonomic abstractions on top of it.

I initially used Python because Press started out as a library, but with the pivot to a compiler model, I think Go or Rust would probably end up being a better choice (Rust would make integrating HarfBuzz a bit easier, at any rate).

Potential improvements

To my 2021 eyes, the language design isn’t particularly elegant. I like that the parameters are named (clarity), but for most of the commands there aren’t actually that many parameters, because many of the settings that would normally be parameters are separate commands. For parameters that are clearly unambiguous, the names hamper readability. For example, I think something like this might be better:

:line 0,0 to 1080,0
:fillcolor #345

I’ve also thought that push and pop could potentially be clearer as curly braces, and that the initial colons aren’t really necessary:

{
  translate 0,1040
  strokecolor #999
  linewidth 0.25pt
  line 0,0 to 1080,0
  stroke

  {
    fillcolor #999
    font 14pt helv
    text 1085,-3 "ascender"
  }
}

The future

My initial reason for building Press was to have an easy, programmable cross-platform way to create language chart PDFs (so I could move away from PlotDevice/DrawBot), and what I’ve realized (acknowledging that I haven’t really been making language charts in recent years) is that there are some other, better options now.

One that seems decent is SVG, converted to PDF by way of Inkscape. Initial tests here seem like it would probably work fine.

Another promising option that I admittedly haven’t looked into very much yet is Paged.js. HTML and CSS are already great for declarative typesetting, and the more I’ve thought about programmatic typesetting, the more this model seems to be the future I’d want to work with (and not just because of parity with web, though that makes it much more compelling).

tl;dr I don’t see myself continuing on with Press, so we may as well call a mortem on it.

Reply via email

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).

Reply via email

Tangential note that doesn’t completely relate but whatever, I’ll throw it in: every time I think back on embedding (which is not that often, thankfully), my brain gets all excited about compile-time execution in Jai and in Zig. (Both are languages I’ve only read about, to be clear. Might be time, though, to start building something in Zig.)

Reply via email

Riccardo Scalco’s Textures.js, SVG patterns for d3.js. Yum. I don’t even use d3 (at least not right now), but I’m tempted to do something with it just so I can use these.

Jason Kottke on the invention of a new pasta shape. Max sauceability as a concept will stick with me for a long time, I think.

Rytis Bieliunas on some of the darker corners of Go (the programming language). I’m writing a lot of Go at work now and this was helpful.

Austin Kleon on blogging as a forgiving medium. The idea of continually editing and refining posts after publishing them intrigues me. I fix typos if I find them, but that’s about it at the moment.

Reply via email

Reply via email

And some Rust, Go, and HTML:

These are certainly more soothing to my eyes, which was something I didn’t realize I needed. While these aren’t perfect in the least — with enough variation between languages to look almost like entirely different color themes, though I think I see that as a feature and not a bug — I’m happy with the tweaks for now and plan to stick with them.

Reply via email

Saturn is my launcher app for my phone. It’s a small Go web app. The name comes from the Saturn V rocket launcher, and I wrote it as a replacement for Launch Center Pro (when it switched to a subscription model, because apparently I am allergic to those).

Overview

This is what it looks like:

The blue buttons are direct links to pages. There’s a very hard to see dark textbox at the bottom, and if I type something in there, the green buttons take that and execute a search somewhere else. Finally, the pink buttons open secondary panels, like this Notebooks panel:

On this panel, the lighter rectangle above the buttons is a search box that allows filtering through Vinci notebooks.

How I use Saturn

On my phone, I have it saved to my dock. It’s not set to be a PWA, because then the links would open in the in-app Safari; I prefer having them open in normal Safari.

I use Saturn pretty much every day. I mainly use it to set reminders, search Amazon, Goodreads, and eReaderIQ, and get to my journal and my daily review list.

The future

I’m largely happy with it as-is. Maybe some more refactoring of the buttons (the Search button is largely obsolete now that I’ve moved all those buttons to the main screen, for example), and it could use a little design love to make things more consistent (search boxes, for example), but that’s it.

Reply via email

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).

Reply via email

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.

Reply via email