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

• The health issues I referred to in May are still largely unchanged, though I’ve come to terms with it enough that I should probably stop using it as an excuse for lower productivity. (I do need to rest more than I used to, but I also feel like I’m spending proportionally less time making things than is warranted. I’m now tracking my time using a completely rewritten version of Momentum, so I should hopefully have more actual data to work with soon.)
• We’ve also had a month of worrisome family medical issues (including two late-night ER visits) that have been weighing me down.
• On the plus side, I got some lab results that finally motivated me to start exercising more and make real changes to my diet. I’m three weeks in and the lifestyle adjustments seem to be sticking. Fingers crossed.
• The rising case counts and Delta situation certainly is discouraging. My faith in humanity in the aggregate has eroded significantly over the past year and a half.
• In spite of a spectacular lack of public results, I’m still writing, slowly. (Much more successful at avoiding it.) In the middle of figuring out a process that consistently gives me a) results that b) don’t make me cringe.
• I’ve been trying to keep artmaking to the weekends so I have more of a chance at making progress with my writing, but it doesn’t seem to be working as well as I’d hoped.
• Another thing I’ve been itching to do is get back into making web-based art tools like Cirque (which needs a lot of improvement). Several ideas here I’m excited to work on.

Reply via email

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.

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

(If/when I need to do motion graphics or video editing in place of After Effects and Premiere, by the way, I’m planning to use the free version of DaVinci Resolve.)

So far I’ve only actually used Affinity Photo, to texture the piece I released yesterday. Worked like a charm. The live split-screen preview when applying a filter is brilliant, and the file sizes are much smaller, too. (In Photoshop I’d regularly end up with a 1–2 GB PSB file. With Affinity Photo, it’s closer to 300 MB.)

As far as typesetting goes, I still expect to use TeX (Tectonic) on projects where it makes sense — it’s what I used on the wide margin study editions since typesetting each language individually would have taken much more time — but it’s nice to have Affinity Publisher for other projects. I’m planning to use it for the book of narrative poems I’m (slowly) working on. (I’ll be setting it with Hinte, a new typeface I’m designing in FontForge. More on that soon.)

With Figma doing most of what I used to use Illustrator for, I don’t expect to use Affinity Designer all that much initially. But the raster brush textures are intriguing. We’ll see.

Reply via email

Reply via email

Reply via email

Reply via email

Reply via email

Bookmaking tools

One of the areas in the project space is bookmaking tools: tools that help with making either print books or ebooks. What I’ve worked on in that area (and some of these are still in progress or in the future):

• Press — low-level typesetting (PDF compiler)
• Ink — higher-level typesetting
• Curves — programmatic type design
• Typlate — type design templates
• md2epub/Caxton — ebook compiler
• epubdiff — ebook differ
• Fledge — text processing shell
• Storybook — writing tool (covered under the productivity tools, yes, but I feel it fits in here)

Creativity tools

The next area, somewhat related, is creativity tools: tools for making art, music, etc. I do realize that there’s a bit of overlap between the two areas — art can be used in books, for example. This is not a rigorous taxonomy.

What I’ve worked on:

• Trill — music composition REPL
• Grain — command-line tool for texturing art

While I haven’t done much in this area so far, the intersection of software and art has been calling to me more lately. I expect creativity tools to become much more of a focus for me, probably even more so than the bookmaking tools.

Human-Computer Interaction

Last but not least, HCI. My master’s thesis is in this area, and much of my other work also touches on it in limited ways. (What I mean by that, I think, is that with projects like Trill, Curves, and Press, the parts that have most interested me are the interfaces. Also, those interfaces have been textual in these particular cases, but I’m also interested in other kinds of UIs.) So I plan to start building more proofs of concept and interface experiments — like the spatial interface ideas I mentioned several weeks ago.

Reply via email