busybee

Stuff I want to work on:

• Refactor
• Lewi and Unity
• Music in general
• Publ:
  • A post editor/submission system (particularly so that I can move my drawing group’s site off of Tumblr, and also so that I can enable public comic transcriptions again)
  • A native comment system
  • Also the rather large list of things I want to do to Publ itself
• Subl
• A game for Strawberry Jam

Stuff I need to work on:

• The day job
• Finding a better housing situation than my current condo

Stuff I have the energy to work on:

I wonder how many things are going to break on November 20, 2286.

Throughout my career, I’ve noticed that quality/test engineering is usually seen as a bottom-of-the-barrel discipline, something that someone should want to be promoted out of rather than someplace to end up. I find that really strange.

It takes a lot of skill to look at other peoples' code and write tests to exercise it and determine correctness, and to do it well. And to have exacting standards about code quality and testability of the code in the first place.

Nearly everywhere I’ve worked, though, test engineers have been incredibly junior and not particularly skilled. Which made it part of a self-fulfilling vicious cycle; test engineers do poor-quality work (and don’t seem to bring much value to the actual product development), so low-calibre programmers end up being put in those roles, and so then they continue to do poor-quality work. Test engineering seems to be treated as glorified QA in most places.

(This is a somewhat-edited version of a disconnected ramble I posted on Twitter/Mastodon while on the train home today. I feel like putting this somewhere that I own it, but am not in a good enough mental state to actually write it properly.)

Yesterday at IndieWeb Summit, someone – Aaron, I believe – mentioned that one of the big differences between IndieWeb initiatives and ActivityPub is that IndieWeb is made up of simple building blocks you can pick and choose while ActivityPub frontloads a lot of complex work. This is a sentiment I very much agree with and it’s unfortunate that the main reason Mastodon switched from OStatus (which is very IndieWeb-esque) is because it made it slightly less inconvenient to pretend to have private posts. Which aren’t even implemented that well.

Mastodon’s “private” posts really suck from a bunch of standpoints. There’s no ability to backfill or even view on web without being on the same instance, and Mastodon’s actual privacy controls go in the wrong direction, so it’s still necessary for a separate vent account. As usual I don’t know if this is a problem with ActivityPub itself, or an artifact of how Mastodon shoehorned its functionality into ActivityPub, but either way, the end result is that Mastodon’s post privacy isn’t really all that useful, nor is it really all that private.

So, right now ActivityPub is the darling of the fediverse, but I’m hoping that the current push toward AutoAuth and trying to use it as a basis for private webmentions and the obvious next steps of private feeds and private WebSub will change that. I do worry that IndieAuth/AutoAuth are kind of hard to do in piecemeal ways though (well, okay, IndieAuth becomes really easy using IndieLogin but I don’t want to see a single endpoint become what everyone on the Internet relies on). And of course once you get into an integration between auth stuff and content stuff you also need to worry a lot more about content management and how it integrates, as well as this seeming fundamentally incompatible with static site generation.

At the Summit there was definitely a lot of compromise that people were doing, such as using Javascript libraries to introduce externally-hosted dynamic IndieWeb stuff onto statically generated pages. I think in this world where SSGs can be supplemented with third-party endpoints that use client-side JavaScript there could be a world where some level of privacy can happen via clever use of client-side includes of data at non-public unguessable URLs. (Although the ideal solution for that is to use the third-party APIs to generate webhooks that then trigger a file change → git commit → commit hook → build/redeploy.)

Non-public unguessable URLs aren’t great for privacy in general (and I mean, Publ has had “privacy through obscurity” since day one and there’s several reasons why I rarely use it anyway) but it’s at least better than nothing.

One of the biggest bits of functionality I want to get in the next milestone for Publ is private posts. Doing private posts requires some way of determining the identity of the person who is reading the site. There are a lot of mechanisms to choose from. Most of them are largely incompatible with one another, and there isn’t any single mechanism that checks all my boxes. And of course the standards keep on shifting, and keep on getting a new unifying standard that will fix everything.

So, IndieLogin is a really great way to get started with IndieWeb authentication for people who are in the IndieWeb ecosystem. If you have your own website on your own domain name and an account on one of its connected RelMeAuth providers, it covers everything. But not everyone who I want to grant stuff to has their own website, or the ability to set one up. Siloed OAuth is still useful. And being able to log in via email address is also beneficial.

Okay so I like LÖVE for making games, and have used it for quite a few of them at this point.

I like that it gives me a bunch of useful primitives for making games, and then just gets out of my way. And I like that it has a simple build process where it isn’t too difficult to make a cross-platform build and continuous deployment system that also lets me do continuous deployment to itch.io or whatever.

And I also like that Lua is a fairly easy language to learn, with a simple syntax. But there’s a few things about it which are just baffling or annoying to me.

And I’m not talking about the 1-based arrays! (That’s annoying in a couple of situations but for the most part it doesn’t really matter, at least not to the extent that people make a big deal about it.)

When I was replacing peewee with PonyORM, I was evaluating a few options, including moving away from an ORM entirely and simply storing the metadata in indexed tables in memory. This would have also helped to solve a couple of minor annoying design issues (such as improper encapsulation of the actual content state into the application instance), but I ended up not doing this.

A big reason why is that there don’t actually seem to be any useful in-memory indexed table libraries for Python. Or many other languages.

Inspired by a conversation I had last night, and not all of these are covered by the more well-known lists.

This article was originally written for the Publ blog. I have reproduced a slightly modified version here so that it hopefully finds a wider audience.

Whenever I build a piece of software for the web, almost invariably somebody asks why I’m not using PHP to do it. While much has been written on this subject from a standpoint of what’s wrong with the language (and with which I agree quite a lot!), that isn’t, to me, the core of the problem with PHP on the web.

So, I want to talk a bit about some of the more fundamental issues with PHP, which actually goes back well before PHP even existed and is intractably linked with the way PHP applications themselves are installed and run.

(I will be glossing over a lot of details here.)

The problem

Let’s say you want to make a single-binary application that has embedded resources (images, GLSL shaders, etc.). Let’s say you want to automatically wrap your resources in a storage container to make it easier to deal with stuff. Let’s also say that you might even be using CMake as your build system.

CMake doesn’t provide a way of making a custom build rule, and using extern data is a little unwieldy. So here’s an easy-ish way to do both parts, making use of C++11 language features (and a scary preprocessor hack).

The C++11 bit is also useful on its own, even if you aren’t using CMake, although things will have to be adapted to your build system of choice.

Note: Back when I wrote this the general compiler ecosystem was different, especially on macOS. If you just want a library that does all this stuff for you in a platform-independent manner, check out this resource embedding script. Or you might be interested in a CMake-only approach for the resource generation and using that in conjunction with the rest of this article.