Apropos of that, I’ve started writing another feed reader. This time I am sharing, insofar as you can go play with it on Glitch and remix if tinkering with it strikes your fancy.

In fact, you have to remix it, if you’d like it to use your own set of feed subscriptions. The web interface is read-only and all the data management happens at the command line. Very lazy, very Hackerman, but it scratches my own itch so far.

Here’s the thing I’m remembering: Feed readers work best for me when they’re rivers, not inboxes. Dave Winer has been writing about Rivers of News for years. My interpretation goes like so:

• No read / unread flags. There is no “Select All, Mark as Read“.
• No queue to be processed. “Your RSS reader is not your task master.“
• Reverse chronological order everywhere – new stuff first.
• Easy-to-skim capsules of content, grouped into relevance by feed.
• Navigate by paddling down the river. Spacebar, page down, mouse wheel, finger drag – but, crucially, this isn’t item-by-item navigation.
• Open new tabs in the background or push into Pocket whenever something looks worth reading.
• Take occasional breaks to read tabs.
• Continue on to the end of the river or until things look familiar.

Before my new DIY effort, my last reader was Tiny Tiny RSS. It’s a good feed reader, not entirely unlike ye olde Google Reader. The thing that kept kind of driving me away from it is that it’s too inboxy. I mean, you don’t have to interact with it like that, but it invites that usage and that I’m tempted by it. It feels like work and I avoid it often.

Actually, even it’s not strictly a feed reader, Google Discover has been my most-used news stream over the past couple of years. I’d roll out of bed, swipe over to it from my phone’s home screen, thumb through it, and start loading up tabs. I’m pretty much done with that thing now, though.

So, rough & ugly as it is, I’m finding it a lot easier & more enjoyable to paddle down my new river. I even got it working acceptably on my phone. I’ve been catching a lot more news than I have been in probably years. It’s not like this is my first River of News reader – it’s just that I seem to have forgotten how I used to read news from, like, ten years ago.

Here’s another weird thing: It re-occurred to me that Facebook and Twitter and Mastodon are all basically Rivers of News. I mean, quirky rivers with occasional algorithmic rapids – but still, they’re not inboxes. I say re-occurred, because I’ve had these thoughts before. Somehow I just forgot and have been trying to engage with feeds via an inbox again. I wonder why?

Anyway, this was in my head. Now it’s not. Hopefully I’ll do more of that here.

But, little paper cuts have finally hit my annoyance threshold – in particular:

1. Quite often, the feed offers items that are months or years old
2. Nearly every item links to a site using AMP
3. Nearly every site using AMP does it badly

The first issue would be kind of forgivable, but I feel like a dummy every time I run into it without realizing it partway into an article. So, I guess, fool me once shame on you, fool me twice – you can’t get fooled again. Call me a curmudgeon, but I’m getting really worn out on non-chronological feed algorithms.

That second issue, though. As a web developer, I’ve been kind of grumbly about the general concept of AMP. But, as a user who reads news, Google’s AMP has felt like garbage.

It took me awhile to put it together, but things seemed weird about pages I visited from the Discover feed. I’m not sure if it was a recent decision for Google’s Discovery feed to link mostly to AMP content, but I’ve been noticing it more lately. And what I’ve noticed is what’s missing: Videos, tweets, comments, and other random bits of content.

Case in point:

Yes, that Tweet is mostly blank white space. It’s what a lot of articles published as AMP look like to me. It feels like no site publishing in AMP has made any effort to actually use AMP.

It just seems like they run their existing pages through a dumb filter and never observe the result. Page elements are just omitted, the content rarely (if ever) adapted to the format. Occasionally, a page will have partial text with a “Read full article” button – and a click of that button leads to a non-AMP page.

In fact, I can often just delete “/amp” or “?amp” from the URL – and like magic, all the missing content appears. It’s almost like the only incentive to use AMP is to check off a box for search rankings.

So anyway, in closing: I’ve been tinkering with my own feed reader again. With a few CSS tweaks, it works on my phone. It’s been plenty relevant so far. Thus, I think I’m done with Google’s feed for now and will try to avoid AMP pages wherever possible as a user.

That sounds like the start of a toothpaste commercial, but bear with me. The thing about Glitch is it’s not very weird. The general vibe and decor of the place reminds me of my favorite BASIC programming books from the early 80s. But, behind that is some dead boring technology.

Out front, there’s a no-frills web-based IDE – not as complex as something like Cloud9, but plenty powerful for most tinkerings. In back, there’s a tiny Linux machine with a sliver of RAM and a dollop of storage – not entirely unlike a Raspberry Pi. Along with basic editing, the IDE offers access to console log output and a web-based terminal where you can engage in command line shenanigans.

Every project gets its own *.glitch.me subdomain with an SSL-enabled web server all ready to go. And, though you can store assets like images and such alongside source code, there’s also a separate CDN that accepts uploads via drag and drop.

For version control, you get an easy-to-grok rewindable timeline. The neat thing, though, is that this is backed by a git repository. Every ten minutes or so, the system commits your changes and you can roll back with a file-by-file preview of changes right in the editor.

I recently discovered that the Glitch API opened up direct access to the underlying git repository. So, with plain old git tools, you can back up or transfer your projects away from Glitch. You can even work through GitHub if that strikes your fancy. Ironically, these sorts of clearly marked exits make me more comfortable with sticking around.

I’ve read that other languages work on Glitch, but my main thing around there there is working with JavaScript in Node.js and the browser. The happy path is well-trodden: On edits, web pages auto-refresh and servers auto-restart. Tweaks to dependencies in package.json are automatically applied from a fast pnpm cache. And, if you don’t quite like the auto-restarts, you can customize with a watch.json file.

To circle back, it might sound like I accused Glitch of being boring like that’s a bad thing. But, I know that the infrastructure keeping things boring must be anything but. And the effort to support what’s common clears the way for more exciting things folks can do when they don’t have to focus on the setup and knob tweaking that so much of modern web development seems to require.

When I start a new bit of tinkering on Glitch, I don’t have to go through a boilerplate dance of git init and npm init and npm install and trying to remember what I did last time to configure Webpack and yadda yadda yadda. I just start a remix of one of the many starter projects on Glitch and commence tinkering.

Then I can tweet or toot or do whatever to share with the *.glitch.me URL and show off what I’ve got so far. I can even embed my projects on my own pages. In starting to explore the API, I added a list of recent projects to my home page. And if you want to play, it’s just a click or two to remix my work as your own.

And then, if or when I do want to get into some knob tweaking – Glitch gets out of the way. I can replace and configure the built-in auto-restarts and file watchers. I can run npm scripts from the command line for linting and formatting and whatever else I feel like doing. I can set up a fancy Webpack dev server complete with hot module replacement or whatever ends up being the latest hotness.

So, I guess to sum up: Glitch is pretty cool. I’m probably going to be using it a whole bunch in the near future.

“Heaven & Hell are real”, you said.

I think of this while I clean my knives. A body cools at my feet. Blood flows with the grade of the pavement to the nearest storm drain.

“Heaven & Hell are real,” you said, “I pushed it all to production this afternoon.”

I don’t know who this was. It doesn’t matter. It’s not you.

“There’s this sequence where your soul gets weighed.”  You smirked, proud. “It’s really cool.”

The alley is just a glance away from passersby on the street. But, no one does.

“A deep memory scan, criminal records, credit reports. Hell, even browser history. It all goes in.”

In a dive bar down the block, I leave another body in the grimy bathroom. I don’t make more of a mess than was already there.

“But”, you whispered (and I shuddered), “the rules are different for us.”

I push a dog walker into the river. The dog tags along with me until I hand the leash to a bewildered someone stepping off a bus.

“I slipped a bias into the algorithm”, you said, stroking my hair. “We’d have to be monsters not to make it in.”

On the bus, it’s a poisoning between stops. I slip a needle into a passed-out drunk.

“We’ll be together forever”, you sighed.

I drop a brick off a bridge: it smashes through the windshield of a passing auto-cab. I don’t think I hurt anyone – the cab looked empty.

“I never asked for that”, I said to no one. You were already asleep.

You died in a car wreck, last week. You were driving. Who even does that anymore?

The next day, I donated everything to charity. I did it in your name. Every bit counts while you’re still in the processing queue.

There’s still work ahead for me, though. I’ll kill everyone in this city if it means I’ll never see your face again.

Up until today, I was thinking that we’d need to do this with server-side code like an AWS Lambda function. But, with more due diligence, I realized all the pieces exist to make this happen completely in the browser.

Themes in Firefox have gone through many iterations and changes. But, for present purposes, consider the recent addition of static themes. A static theme is a .zip archive, containing a manifest.json with the properties of the theme, accompanied by whatever images are used.

With that in mind, producing a static theme from the Color web app looks roughly like this:

// store is Firefox Color's Redux store
const state = store.getState();

// selectors.theme() extracts the current theme from the store
const themeData = selectors.theme(state);

// convertToBrowserTheme translates our Redux data into a Firefox theme
const theme = convertToBrowserTheme(themeData);

// Find JSZip at http://stuk.github.io/jszip/
const zip = new JSZip();

// This is a very minimal manifest for a theme
const manifest = {
  manifest_version: 2,
  version: "1.0",
  name: "My New Theme",
  theme
};

// Add a pretty-printed JSON string as manifest.json to the zip
zip.file("manifest.json", JSON.stringify(manifest, null, "  "));

// Generate the .zip as a base64 and reformat it as a data: URI
return zip
  .generateAsync({ type: "base64" })
  .then(data => "data:application/x-xpinstall;base64," + data);

Firefox Color uses its own internal representation of a theme to make things easier to manage in the React / Redux code that drives our UI. But, when the theme is applied to the browser by the Color add-on, this representation is converted to the Theme schema expected by dynamic theme API in Firefox.

Conveniently, this conversion code can be extracted & generalized to produce the theme property of manifest.json in a static theme. That’s what convertToBrowserTheme() does.

From there, Stuart Knightley’s JSZip module forms the keystone of the whole thing. To create a manifest.json file in an archive, I just have to generate the contents as a string with JSON.stringify() and feed that into zip.file().

Then, I can generate the .zip archive and encode it as a Base64 string. Again, this all works in a browser! With a small tweak, I can use that as a data: URL in a download link:

<a download="theme.xpi" href={exportedTheme}>theme.xpi</a>

Thanks to the HTML5 download attribute, clicking on this link in Firefox results in an Open / Save dialog to download the data:

Oh, but I mentioned images. That complicates things. In Firefox Color, there are two ways to get an image into your theme:

1. Use one of the predefined background patterns – these are stored internally as file paths to images bundled with the Color add-on
   
2. Import up to three images of your own – these are encoded as data: URLs from the imported image data
   

For producing a static theme, I need to convert each of these cases into both an image file in the archive and a file path in manifest.json. That leads me to two variations for handling image data:

function addImage(zip, data) {
  if (data.startsWith("data:")) {
    // Convert data: URL into binary file entry in zip
    const [meta, b64data] = data.split(",", 2);
    const [type] = meta.substr(5).split(/;/, 1);
    const filename = `images/${genId()}${extensions[type]}`;
    zip.file(filename, base64ToUint8array(b64data));
    return filename;
  }

  if (data.startsWith("images/")) {
    // Convert file path into pending image fetch.
    const filename = data;
    pendingImages.push(
      fetch(filename)
        .then(response => response.blob())
        .then(data => zip.file(filename, data))
    );
    return filename;
  }
}

For user-imported images, I have the data immediately available as data: URLs in the Redux store. After some hacky parsing of a data: URL, I can invent a unique filename and convert Base64 to binary before adding to the .zip archive. The genId() function helps with the former, and the base64ToUint8array() function helps with the latter. (I’m leaving out some details like these functions, but you can find them on GitHub.)

The built-in images, though, are only represented as file paths in Redux. Luckily, these paths correspond directly to images deployed with the web site. So, I can use fetch() to grab these via HTTP and add each to the archive as binary blobs. This is an asynchronous operation – so I assemble a pendingImages array collecting Promises that need resolution before we’re done.

Putting it all together slightly complicates my earlier code sample:

const zip = new JSZip();
const state = store.getState();
const themeData = selectors.theme(state);
const customBackgrounds = selectors.themeCustomImages(state);

// bgImages and customBackgrounds are sources of image data
const theme =
  convertToBrowserTheme(themeData, bgImages, customBackgrounds);

reset();

if (theme.images) {
  const { images } = theme;
  const { additional_backgrounds } = images;
  if (images.headerURL) {
    images.headerURL = addImage(zip, images.headerURL);
  }
  if (additional_backgrounds) {
    for (let idx = 0; idx < additional_backgrounds.length; idx++) {
      additional_backgrounds[idx] = addImage(
        zip,
        additional_backgrounds[idx]
      );
    }
  }
}

const manifest = {
  manifest_version: 2,
  version: "1.0",
  name,
  theme
};
zip.file("manifest.json", JSON.stringify(manifest, null, "  "));

return Promise.all(pendingImages)
  .then(() => zip.generateAsync({ type: "base64" }))
  .then(data => "data:application/x-xpinstall;base64," + data);
}

So here, I add the code necessary to walk through any images in the theme and convert them to paths in manifest.json and accompanying image files in the archive. And then, at the end of the function, I use Promise.all() to resolve downloading images as necessary before generating the data: URL for the .zip archive.

By the way, to keep this entry short(er), I’m skipping the details on how all the above is used within our React & Redux web app.

TL;DR: It’s a pretty nondescript async React & Redux flow.

The export code lives in a function named performThemeExport(), used as input to an action creator. A button click kicks off the process by dispatching the action. Since the action’s payload begins as an unresolved promise, the redux-promise middleware handles resolving the payload before updating the Redux store (and thus the UI) when the export is finished.

All-in-all, getting this stuff to work was a surprise. Finding JSZip and figuring out how to do the various Base64 / binary conversions were the pieces that really made it all fit together. While I’d seen those things before, they just hadn’t all slotted together in my head until just this afternoon.

Anyway, to wrap up: If you want to see all of this stuff in working form, you can follow along with the pull request I submitted to Firefox Color today. It’s still rough, UX-wise, and will see further tweaks before we consider it done.

I’ve also had “ActivityPub Lambda” on my maybe do list for awhile now. All the pieces are there in Amazon Web Services for a decent, low-maintenance ActivityPub node:

CloudFront can do SSL, caching, and use my own subdomain. An API gateway can handle all the inbox & outbox parts of ActivityPub via Lambda functions. SQS can take care of the delivery work queue by feeding jobs to functions. CloudWatch alarms can trigger periodic scheduled functions. And then, there’s DynamoDB and S3 for storing & publishing data.

While not as neglect-able as a fully static web site, AWS seems to be cheap at hobby scale and easy to let lie fallow when I get bored with the project. By speaking ActivityPub directly, I don’t need to maintain a fediverse server like Mastodon or Pleroma. I don’t need to rely or impose on anyone else’s community server. It’s very light. I’ll be watching to see how the bill on this thing shakes out, but I expect it to cost pennies per year.

I’m also hoping to refine this thing to be more generic. Push the ActivityPub machinery into the background. Support a simple local API for implementing future bots. Maybe reduce per-project code down to a single file with hooks for events and helpers for interacting with the fediverse.

This could even make it easier to stand up a single-user (or few-user) ActivityPub node. That’s also problem space at which Picodon is aimed: Lowering the trouble & cost of fediverse participation. The main difference with Picodon is living on Glitch. Being there should mean that it’s easier (and more fun?) to remix your own version of it. Conversely, AWS is kind of a slog for tinkering. I mean, Ironically, AWS felt more fun this weekend–but I chalk that up to novelty vs fatigue.

I’ve also got some notions to see how much of this thing I can push into static hosting. Not the inbox / outbox endpoints that expect POST requests, of course. But, the ActivityStream objects and collections can be served up from a static S3 bucket or similar. Since everything in the ActivityPub protocol is generally addressable via arbitrary URLs like a good REST service, I should be able to gin up a somewhat generic service that could be dropped into an otherwise static site not unlike Disqus for comments.

Anyway, I could delve into more technical specifics here, but I think I’ll wrap up for now. If you’re interested, come follow along at my GitHub repo.

And if you’re up for a dumb insult, drop a mention to @Insultron2000@insultron.lmorchard.com on the fediverse!

I switched from WordPress to Jekyll. But, since then, staring down a pile of Markdown files has felt like a limiter on my already diminished writing output. I thought using my favorite text editor would be comfortable & fun. I’ve realized that coding-me and writing-me are different. Many affordances for programming are death-by-paper-cut for prosing.

Lately, I’ve done one of three things with ideas for writing:

• Spew the raw idea directly onto Twitter
• Write it down in my paper journal and keep it to myself
• Promise myself to wrestle with Vim and blog machinery to refine the idea into a Proper Article
  

The mental drag of #3 converts every post into a Project. There’s little room for medium-sized things I might have published in the past. To counter this, I’d like to lower the friction between my head, the words, and the web.

So. WordPress. It’s been awhile. Gutenberg seems to jibe with how I’ve been thinking about web writing: Streams of components. Prose broken up with headings and images. A pull-quote or two. Some code samples and interactive widgets. Hell, maybe an embedded arcade game emulation from The Internet Archive.

In years past, trying WordPress & Gutenberg called for a weekend spent converting all the things I’ve written so far to use the New Shiny as the Sole Instantiation of my Online Presence.

I’ve done this several times: From Movable Type to WordPress to Blosxom to PyBlosxom to WordPress to Jekyll to WordPress to my own DIY thing that taught me how to use Gulp. (Remember Gulp? So 24 months ago.) I’ve managed to keep a decade of writing intact as I moved the corpus between each of those systems. Kind of an achievement, I guess.

Maybe it’s thanks to my career experience in the marketing side of web dev. It felt wrong to build anything but a cohesive monolith with a consistent brand identity and user experience. We were always refreshing and redesigning and never letting anything stay the way it was for long.

I kind of hate that I ever did it that way for my own stuff. It’s not like I’m paying myself or even really learning much this way. This time I’ve decided to just start a new publication. Leave the old stuff be until I feel like messing with it again.

And, it’s not like I don’t already have plenty of publications out here on the web, anyway.

That brings me to some criteria of how my publications should work, going forward:

• Offer cool URIs that don’t change!
• Live under a domain name that I control.
• Live on the cheapest, dumbest web hosting.
• Survive the obsolescence or disappearance of the authoring software.
• Endure decades of complete neglect.
  

Standardizing on static websites can satisfy all these things. A few of my publications could use a one-time URL-breaking change to my own domains. And then there are things like Mastodon, which require active web services to keep working. Still, ideally, these are the things to shoot for.

So, I’ve been playing with WordPress by installing it on the Synology NAS in my office. The thing you’re reading right now is a static website produced via the Simply Static plugin. I push the files out to Amazon S3 via some quick-and-dirty shell scripting. I’m thinking I’ll write more about this rig in a future post.

This place looks different than the publication where I wrote my last big thing. I’m telling myself this is okay. Maybe I’ll try something like Ghost for the next thing I write: Ghost does things with blocks & cards now, too, so that’s interesting. That would look different and live on its own sub-domain, too. I’m telling myself that this is also okay.

So, to sum up: By letting things I’ve made go static, I can shed encumbrances to try new things. And I want to try new things to see if I can remove limiters on my writing.

And why do I want to write more on the web? Well, that’s probably a notion for another post.

Also, I keep thinking that on one of these projects, I’ll pull together a “Les Orchard Standard Boilerplate” with all my favorite things configured for my next project. But, almost every time, I throw together a new mix of language, frameworks, and modules that seems about as valid as my choices on other previous projects. From a certain perspective, this seems wasteful.

Maybe I shouldn’t be so hard on myself. It’s not like I have nothing to show for this work. In fact, I think I’ve finally realized something obvious: This is my favorite way to stay current. That these side projects stop short of useful is beside the point. This is how I get experience applying recent frameworks and techniques, driven by scratching my own itches and following serial enthusiasms.

And though learning for its own sake is fun, I’ve found that my side projects end up being  leading indicators: The thing I played with a month ago comes in handy for next week’s work project. (And I do tend to finish my work projects, since I’ve got a team and a boss and a mission and a paycheck encouraging my focus.)

Of course, sometimes I worry that this is just an intersection of confirmation bias and Stockholm syndrome: I often decide what stack to use for my projects at work. So, I could just be picking the things I’ve found most recently shiny. You know, I have made regrettable technology choices over the years.

I’m aware of this trap, though. So, I guess there’s another reason why I shake up the stack on every side project: I’m trying to keep myself from getting stuck on any particular combination. I’m trying to keep an open mind for possible benefits in the alternatives.

That brings me to the phrase that got stuck in my head this week: Yak shaving is the point. It’s not a distraction or a waste of time. It’s the yak shaving that sharpens the saw.

Okay now I’m mixing metaphors or idioms or whatever, but it makes sense to me at least!