I don't actually like writing about BCN on BCN very much1, but there've been enough significant backend and frontend changes that I thought it was worth doing anyway.
There've been a lot of updates on the backend platform and in the front ends - yes, front ends, plural.
Front End Changes
BCN was originally deployed with three endpoints for users to use, plus the backend API endpoint. It uses OpenAPI, so the front ends had a consistent set of services to work with; there was a NextJS front end contributed by Andrew Lombardi, a plain front end, and a reference front end, mostly written to prove out the "one backend, many front ends" design I pulled from an idea for TheServerSide.com, as I wrote about on my personal blog shortly after moving on from the site.
It worked! The NextJS version became the "live front end," pointed to by https://bytecode.news as well as https://nextjs.bytecode.news, and it remains live and maintained at that latter address.
But then Paul Parks released PUDL - as a distribution and a specification - and I wondered if it would work as an alternative paradigm for accessing the site. Generating a UI with PUDL turned out to be pretty easy, although it has had some fits and starts in design2, and what it did was present BCN as an application rather than a consumer site. Since I use the site pretty heavily to administer it, I find that I use the pudl implementation of the UI, at https://pudl.bytecode.news, pretty consistently.
But that left the NextJS implementation, and while NextJS is capable enough, it's heavy. It works, which is the important part, but I didn't like how slow it felt, and the rendering cycle from the page was outside of my expertise to fix, and there are other UI frameworks out there... so I decided to write yet another UI, using Primate. Primate turns out to be much lighter on the wire than NextJS, and it's quite capable as well for my purposes, and it is now not only at https://primate.bytecode.news but it's also the main landing page for https://bytecode.news itself, with tests asserting full feature completeness.
The front ends still aren't exactly blazing fast but that's because they all use the common backend. They're layers; if the bottom layer involves an HTTP call (and it does) then the transfer of data between layers will always factor in, and that's just the cost of the distribution of responsibilities.
Between the UIs: Primate is actually really nice for the "user-facing" part of the site... and PUDL turns out to be super-nice for the administration. I think of BCN as an application (which it is: it's not a website, per se) so PUDL fits my paradigm well, while external users will probably be happiest with the Primate interface3. I'm going to keep the NextJS interface maintained, and I'm thinking of other frameworks as well, to create more user concepts, but as I've said, UI is not my strength4.
I also created a masthead project to create funny or interesting animations for the BCN mastheads - they're not mandatory for a BCN front end, but they're easy to insert, they're intentionally small and load on demand (and cacheable, so they don't endlessly create burdens on a client), and they have features like the ability to create events in the animations (for some of them!) and have date ranges, so during the month of October, you're able to get "spooky" animations.
Editorial Policy
Now that I mention "spooky animations" in quotes, that leads me to an explicit editorial policy. The mastheads are "barely-PG-spooky" - like, if it wouldn't fit on a Charlie Brown TV special, I won't allow it, because BCN is explicitly designed to be positive.
I don't want to use BCN like an axe. I don't accept "this person said this dumb thing" - a negative post better have a distinct and limited-to-process observation, if it's critical, or else it's just not appropriate5.
So that policy goes across the entire platform: it has content from external sources that is unvetted (logs, RSS content, even factoids are externally sourced and uncontrolled) but where the content is vetted, there's intended to be a relentless positivity where possible6.
And that means the summaries are affected, too: I don't use clickbait-y titles. Deks (the summaries) are expected to tell the readers what they are reading - I don't like clickbait, I figure other people learn to resent it or should, and thus if you're reading an article based on a BCN summary, you know coming in what you're going to get and you're looking for more detail or, well, my awful jokes.
The Server
BCN is actually a demonstration of a project I thought of decades ago with Alan Williamson and Jase Bell, from Java Developer Journal: an application that took information from as many streams as it could, filtering all of that data into coherent presentable form. I built an infobot (for IRC) along that line, using OSGi, but it never really went anywhere... but a year and a half ago, I decided to revive the idea, and thus "streampack" was born7.
It's been a lot of fun to create. It has a ton of features, some appropriate for interaction models like Slack or IRC (or Discord, or Mattermost, all of which it supports), and others appropriate for request/response models like HTTP, like BCN itself.
It has logs for channels (on discord, slack, IRC, etc.), with visibility controls so not every user can see every logged channel, an RSS reader, factoid management, article submission in multiple ways (like that "Submit" button at the top of the page, but you can also construct an article in an IRC channel, using the channel logs as contributing material)... it's pretty flexible.
Recent changes include support for pingback/webmention, as well as autosubscription to mentioned websites (within reason!) - the idea is that streampack becomes an emergent ontology, and it's pretty close to that.
I hope the site is useful to readers, and it represents an effort I've been thinking about since 2005 or so, and I'm rather pleased with what it's become... and what it's still becoming.
-
Actually, I don't like writing about BCN very much at all. There's a proverb (Proverbs 27:2) about letting praise come from the mouths of strangers, and not one's own lips8, and I'm rather proud of what BCN represents, so writing about it feels... off, and always will. "Look how well I'm doing at this!" is the resultant vibe, and I find that distasteful. But even so... features!
↩ -
The PUDL implementation's design issues were totally on me, for what it's worth: I am not a "UI person," or even remotely a "UX person." I threw it together, used it, decided what I didn't like and did like according to my own preferences, asked others to kick the tires and pondered their input, and... well... what I have is a mish-mash of all of that put together: my incompetence at UI plus others' input. Yay!
↩ -
No-one would be happy with using the API directly, but if you're really strange, well, you probably could.
↩ -
I'd actually like people who were fantastic with specific frameworks and UI to design something themselves, using only the API to work with the backend data. The OpenAPI spec is available for this purpose, and the idea was always to allow the frameworks to show off what they were good at doing, with the caveat being that they should never get direct database access and no live deployment on BCN would allow it.
↩ -
This is not to say that BCN has never criticized technology: it has, and will, when the technology has actual flaws, but such criticism is technical and not emotional. It doesn't matter if I don't like something; that's not a license to be negative about it.
↩ -
One of the most important aphorisms for me personally is in Pirkei Avos, 1:6: "Find yourself a teacher, make yourself a friend, and judge all to the side of merit," meaning that if you can weigh something with your finger on the scale, you do it. That doesn't mean things don't fail to measure up, but it means that you try as hard as you can to find merit.
↩ -
Streampack is not a great name. I do not like naming things, and I do it almost as poorly as I do user interfaces; I actually wanted to use strings of digits from π (the irrational number), converted to Roman numerals so they look all dignified and such, but somehow referring to a project as LIVID or MILD or something like that ... nah.
↩ -
One of the great failures of social media and the attention economy is that people online are almost terminally afraid to say "look at this guy over here" except to create negative impressions. They're unafraid to say "get a load of this guy, he's the worst" but something done well is expected to promote itself. I don't like self-promotion, so even content that seems to be done well gets crickets in response, which... either means it's not done well (a possibility) or that social media is afraid to compliment. I prefer the latter interpretation, obviously. :D
↩
Comments (0)
No comments yet.
Log in to comment