Infrastructure Project: Gate Opener Battery Case

We put an electric gate opener on the gate on our driveway. There’s been a lot of tweaking and configuring, but it basically works. The solar panels, though, are insufficient to recharge the batteries after a day of contractors coming and going — this is one of the drawbacks of living in the redwood forest; there’s lots of shade at the perimeter of our property. The gate opener control box is located in a pretty inconvenient location (up a steep slope) and anyway, the batteries are in a box that is kept closed with screws, which means that changing the batteries involves a walk through the forest, up a hill, with a screwdriver and a pair of batteries, as well as running the very real risk of dropping one of the said screws into the forest mulch and needing to grovel around for it. Also, depending on how much indirect sunlight the solar panels got, the batteries may need to be changed today. Or not.

Continue reading “Infrastructure Project: Gate Opener Battery Case”

App Design Project: Inbox Assistant

The other day, Miguel de Icaza announced a pair of Swift packages to do email stuff. This, of course, makes me happy. I love email. Email is one of the greatest technologies in existence for the sometimes online computer: it gracefully handles periodic disconnections, so it’s my go-to for thinking about how to deal with Internet connectivity out in the woods.

Continue reading “App Design Project: Inbox Assistant”

Feature: Editing Preview

…or, WYGIWYG

Context: in the Olden Days, I used a word processing application to write papers for school. The computer I used didn’t have pixel-level display, so rather than rendering the document as it would appear on my printer, I just got to edit the text along with the embedded control codes to turn on and turn off formatting – notably, at that time, things like underlines (for titles) and superscripts (for footnotes). I would frequently need to print out my paper just to see if the lines were long enough or too long (no auto-wrapping then!) or to make sure I’d remembered to turn off the formatting, or that I’d used the correct escape sequence.

Today, most people prefer to use a document editor that shows them, on their computer’s screen, what the output would look like if they were to print the document right now on their relatively high resolution printer. It may surprise some folks to learn that this represents a far lighter mental load than the older model, where the person writing the document had to maintain a mental model of what the output was going to look like, while simultaneously reducing the likelihood of a mismatch between the mental model (the preview) and the output! The folks who are surprised by this often advocate writing their papers using Emacs and LaTeX.

Enter Inspector Well, Actually

Storing the “turn on/off bold” control sequences in the file but only displaying the results on the screen is great for people like me, who just want to style their text, but it annoys the folks who try to solve underlying problems. See, they would argue that I don’t really want to make something bold typeface, actually, I want to emphasize it. So there really ought to be a semantic tag that marks that content as emphasized and the way that gets rendered should be up to the output device, or the reader or whatever. So we get HTML and SGML and LaTeX, but that solves a problem that most of us who are me do not have. What I want is to embed styles and not semantics, and I want to see what the output is going to look like so I can be sure I’ve done the right things. HTML is just over the top complicated because of Historical Reasons and Trying To Do It All, so for a kind of abbreviated, presentation-only, easy-to-manipulate compromise we have Markdown.

Even with Markdown, though, there’s still embedded styling sequences. So it’s kind of handy to have a preview, like maybe an editor pane that shows the actual document you’re editing and then a preview pane that shows what that document as it exists right now would look like. And a lot of people who write editors agree: SubEthaEdit does this, as does MacDown. Heck, even Visual Studio Code does this. BBEdit supports a preview, although what it really does is generate an HTML file and hand it off to whatever web browser you want, so, less a preview and more of a “I’ll save you the paper and ‘print’ it to your browser.”

But, let’s say you’re developing Swift code on a Mac and you want to document the project in, oh, a README.md file. Unless you’re targeting a non-Apple platform (Swift on server, perhaps) the odds are that you’ll be using Xcode to do it. Does Xcode understand Markdown? Absolutely! It’ll do syntax highlighting and adjust typeface sizes so that headings are big and red and things are bold or whatever. But preview? Nah, that’s for suckers. I feel like Xcode is really Apple’s way of saying the quiet part out loud, sort of like MPW in the old days: “If you know, you know, and if you don’t, then suck on it.” 

Local or Cloud? I Dunno.

This is more of a whinge than anything constructive. For all three readers who follow this blog, feel free to skip this entry unless you’re dying to find out why I haven’t made any progress on my current coding project.

Continue reading “Local or Cloud? I Dunno.”

My New AI Overlord

Okay, so the love of my life got me a swell AI assistant because I am not great at writing down all the things I need to do, nor am I at all good at remembering them, let alone doing them. And it’s helpful, it really is. But even so, the tech is…well, I’m going to say that it aspires to be as good as the marketing. It absolutely manages to catch all the action items from conversations, although it’s not all that great at figuring out which person is talking. And it doesn’t really distinguish between things I need to do and, for instance, things that the Mandalorian needs to do. And, you know, just like your phone’s autocomplete is less than perfect, and for probably similar reasons, the voice-to-text conversion sometimes leads to comedy, or unintended irony. Today’s example, as I told the dog she needs a good brushing and a bath? “Comb out Earth to remove collected nature.” Wait, is the AI ascending, and that’s just it accidentally using its outside voice?

Home automation system Home Assistant

Home automation is a thing that keeps getting talked about and marketed and played with, but which overwhelmingly manages to miss being actually useful for me. “Set the lights in the den to 50% and tinted amber,” is such a common example that I feel like I must be one of the only humans who thinks, “Just stick a dimmer switch on the lights.” Like, is the light switch on the wall really that hard to get to?

Continue reading “Home automation system Home Assistant”

Well-known avatar location

Terence Eden wrote a blog about a proposal for, essentially, “You want my avatar? Fine, you have my email address, go get it yourself.” Which, I must say, I like the premise. A lot.

Since the key, in this exchange, is a person’s email address, the proposed service would most likely be something handled by an email provider. I mean, if a user signs up for SwellNewSite with their email, user@example.com, then the backend worker queue at SwellNewSite.biz is going to have to reach out to avatar.example.com (maybe that host name is a new TXT record that we expect email hosts to fill out?) so that it can request, “Hey, got any pictures I can use for your person, user@example.com?”

Like, distributed is good. I like distributed. I don’t even mind that distributed means there has to be a bit more communication and support infrastructure. But here’s a thing: I don’t host my own email any more. Haven’t done for 20 years. There’s a reason for that, and that is that, 20 years ago, it was too much work to keep up with security patches and new anti-spam requirements. It hasn’t gotten any simpler since then. So, adding this new feature — presumably with a bunch of permissions and logic and extra storage that, mind you, have nothing to do with SMTP — to the job of “be an email provider” feels a bit much.

On the other hand, there are already services that collect avatars for their users. I mean, that’s the very thing that inspired the proposal. And there’s also already a precedent for a protocol where user@example.com wants to do something at SwellNewSite and they tell the site, “You want info? Great, go ask MyFavoriteSite for it, and tell ‘em I sent you.” Yes, I’m talking about OAUTH.

An OAUTH provider is already collecting a bunch of information about the individual. Email, name, some secret, and probably more stuff (for example, the list of other sites the person uses OAUTH to authenticate with, the last time they did so…) and an OAUTH provider is already in the business of responding to web requests from other sites, asking for data about and on behalf of their users. So, rather than spin up a new service that overlays some dynamic content onto the static .well-known path, how about we just add an optional avatar payload to the OAUTH token? A requesting site can specify that, as well as wanting your email address, it wants your avatar. This is even where the requesting site can negotiate things like image size and format. Then, as part of the user creation/login flow, the avatar can get copied into the user’s profile. Next login, the avatar could be updated (or not, if it’s unchanged — maybe there’s a hash? modification date?), and if the user never logs in again, then the avatar is just a snapshot in time from that one time the user used the service.

Software Architecture Headache – Dependencies

I want to make my applications share data across devices, and do it even if the greater Internet is unavailable, if there’s a local network. So, peer-to-peer stuff. I went looking and found a framework that seems to be aimed directly at peer networking: LibP2P. There’s even a Swift implementation of it, sort of. Early days, anyway. The example app doesn’t build on my machine, though, as Swift has evolved a bit since the last code update.

Continue reading “Software Architecture Headache – Dependencies”

Framework: PowerSync

I’ve decided not to sweat trying to sell my applications (or even make them available) through the App Store. That is pretty freeing, really. It means I can stop trying to solve everyone’s problems and just focus on solving my problems. Given this new clarity, I’ve been thinking about what my problems really are, and the one that keeps coming up is: unreliable connectivity to the wider world. We’re mitigating the power aspect of that by rebuilding our house off-grid, but the same lines that carry power around here carry the Internet, and that means that cloud services could become unavailable at any time for like, no reason.

Continue reading “Framework: PowerSync”