Press "Enter" to skip to content

[twenty twenty-four day eighty-three]: ghosts of san francisco

centaur 0

I really like this shot, and reserve the right to re-use it for a longer post later, yneh. But it captures the mood at the near-end of my trip to the Game Developers Conference: San Francisco, both vibrant and alive, and somehow at the same time a vaporous ghost of its former self.

Here's hoping she comes back, we miss her.

-the Centaur

[drawing every day 2024 post eighty-three]: joints of the hand

centaur 0

The transfer is poor because I took this picture in low light - since my smaller notebooks don't like to lay flat, and I didn't pack a scanner in my suitcase, I've been taking photographs rather than scanning my Drawing Every Day pieces, and cleaning them up as best as I can - and the source drawing itself is this kind of weird stack of overlapping images. But I think this drawing shows, more or less, the gist.

Drawing every day.

-the Centaur

[drawing every day 2024 post eighty-two]: the buffer is vindicated

centaur 0

SO! Apparently yesterday I went through the last of my Drawing Every Day 2024 buffer ... but I had time during a break between panels to do one drawing this week, and I've booked time for drawing tomorrow morning, so we will NOT be having a break in coverage today! More hands, by the way.

Drawing on average every day, posting every day that I can.

-the Centaur

[twenty twenty-four day eighty-two]: your abstractions are leaking

centaur 0

SO! My Facebook AND my credit card were both hacked within the last few months, so I was understandably freaked when I logged into the Library the other day and got a security warning. This SSL warning sometimes shows up when your network configuration changes - or when someone is trying to hack you - so I got off the conference network and used my phone's mobile hotspot. Unfortunately both the Library's WordPress control panel AND the main page showed the error, and I got a sinking feeling. Credit card got hacked a few months back, remember? And when I checked the certificate ... it had just expired.

Assuming that whatever service I use for SSL had expired due to that credit card issue, I tried to track it down in the WordPress control panel, but pretty quickly decided that digging through notes, credit cards and passwords in a public conference hall was one lapse in opsec too far. Later that night, I tried resolving the SSL issue, but found that something was wrong with the configuration and it couldn't update itself. Exhausted after a long day at the convention, I decided to get up early and attack the problem fresh.

The next morning, I found I had apparently set up WordPress to use an SSL tool which didn't play nice with my hosting provider. (I'm being deliberately vague as y'all don't need to know all the details of how my website is set up). Working through the tool's wizard didn't help, but their documentation suggested that I probably needed to go straight to the provider, which I did. After digging through those control panels, I finally found the SSL configuration ... which was properly set up, and paid through 2025.

WAT?

I re-logged into the control panel. No SSL warning. I re-opened the website. No SSL warning. I doublechecked on both another browser and another device. Both listed the site as secure.

As best as I can figure, yesterday afternoon, I hit the website in the tiny sliver of time between the old certificate expiring and the new one being installed. If I was running such a system, I'd have installed it an hour early to prevent such overlaps, but perhaps there's a technical or business reason not to do that.

Regardless, the implementation details of the "website is secure" abstraction had leaked. This is a pervasive but deceptively uncommon problem in all software development. Outside the laws of physics proper, there are no true abstractions in reality - and our notions of those laws are themselves approximations, as we found out with Einstein's tweaks to Newton's gravity - so even those laws leak.

Even a supposedly universal law, like the second law of thermodynamics that Isaac Asimov was fond of going on about, is actually far subtler than it first looks, and actually it's even subtler than that, and no wait, it's even subtler than that. Perhaps the only truly universal law is Murphy's - or mathematical ones.

Which brings us to the abstractions we have in software. In one sense, they're an attempt to overcome the universal growth of entropy, in which case they're doomed to ultimately fail; and they create that order with a set of rules which must be either incomplete or incorrect according to Godel's Incompleteness Theorem, which means they'll ultimately either fall short or get it wrong.

When developing and maintaining software - or deploying it and managing it in production - we always need to be on the lookout for leaky abstractions. We may think the system we're working with is actually obeying a set of rules, but at any time those rules may fail us - sometimes spectacularly, as in when my backup hard drive and internet gateway were struck by lightning, and sometimes almost invisibly, as in when a computer gets in a cruftly state with never-before-seen symptoms that cannot be debugged and can only be dismissed by a restart.

So my whole debugging of the SSL certificate today and yesterday was an attempt to plug a leak in an abstraction, a leak of errors that created the APPEARANCE of a long-term failure, but which was ACTUALLY a transient blip as an expired certificate was swapped out for its valid replacement.

What's particularly hard about leaky abstractions, transient failures and heisenbugs is that they train us into expecting that voodoo will work - and consciously trying to avoid the voodoo doesn't work either. On almost every Macintosh laptop I've used that has had wireless networking, it can take anywhere from a few seconds to a minute for a laptop to join a network - but once, I had the unpleasant experience of watching a senior Google leader flail for several minutes trying to get onto the network when I had to loan him my laptop to present in a meeting, as he kept switching from network to network because he was convinced that "if the network we're trying to join is working, it should immediately connect." Well, no, that would be nice, but you're sending bits over the fucking air like it was a wire, and connection failures are common. This was a decade and a half ago, but as I recall I eventually convinced him - or he got frustrated enough - to stop for a moment, after which the laptop finally had a chance to authenticate and join the network.

Debugging software problems requires patience, perseverance - but also impatience, and a willingess to give up. You need to dig into systems to find the root cause, or just try things two or three times, or turn the damn thing off and on again - or, sometimes, to come back tomorrow, when it's mysteriously fixed.

-the Centaur

Pictured: a blurry shot of downtown San Francisco, where the abstraction of taking a photo is leaking because of camera movement, and the same intersection, with less leakage from motion.

[twenty twenty-four day eighty-one]: a quick thought on the game awards

centaur 0

The awards ceremony for the Independent Games Festival (IGF) and the Game Developers Choice Awards (GDCA) are held back to back on Wednesday nights at GDC, and I tend to think of them as "the Game Awards" (not to be confused with the other award ceremony of the same title).

The awards are always a mixture of the carefully scripted and the edgy and political, with plenty of participants calling out the industry layoffs, the war in Gaza, and discrimination in the industry and beyond. But one of those speakers said something very telling - and inspiring.

See that pillar on the right? Few people sit behind it willingly; you can't see the main stage, and can only watch the monitors. But this year's winner of the Ambassador award told the story of his first time in this hall, watching the awards from behind the pillar, wondering if he'd become a "real" game developer.

Well, he did. And won one of the highest awards in his industry.

Who knows, maybe you can too.

-the Centaur

Pictured: Top, the IGF awards. Bottom, the GDCA awards. I don't have a picture of the Ambassador Award winner because I was, like, listening to his speech and stuff.

[twenty twenty-four post eighty]: that gdc filler post

centaur 0

At the Game Developer's Conference. I hope to have more to say about it (other than it's the best place to learn about game development, and has the awesome AI Summit and AI Roundtable events where you can specifically learn about Game AI and meet Game AI experts) but for now, this blogpost is to say, (a) I'm here, and (b), I'm creating some buffer so tomorrow I can write more thoughtfully.

Yeah, there are a few people here. And this isn't the half of it: it gets really big Wednesday.

Blogging every day.

-the Centaur

[drawing every day 2024 post eighty]: sketches based on the wizzes

centaur 0

Still more sketches, this time based on Wizard: How to Draw. Being methodical sometimes leaves me feeling goofy, but the step-by-step approach is creating much more confidence once I go through it.

Drawing (on average) every day.

-the Centaur

[twenty twenty-four post seventy-nine]: aheadiness

centaur 0

When you need to solve a problem, it's generally too late to learn how to solve the problem.

Contra Iron Man's assertion "I learned that last night," it's simply not possible to become an expert in thermonuclear astrophysics overnight. (In all fairness to Tony Stark, he was being snarky back to someone mocking him, when he was the only one in the room who read the briefing packet). The superintelligence of characters like Tony Stark and Reed Richards are some of the most preposterous superpowers in the Marvel Universe, because they're simply impossible to achieve: even if you ignore the fact that we can only process like 100 bits per second - and remember around 1 bit per second - and learn things in the zone of proximal development near things we already know - there's too much information in a subject like astrophysics to absorb it in the few hours of effective concentration that one could muster for a single night. Take an area I know well: artificial intelligence. A popular treatment of AI, like Melanie Mitchell's Artificial Intelligence, a Guide for Thinking Humans, is a nine hour audiobook, and drilling into a subarea is fractally just as large (a popular overview of deep learning, 8 hours - The Deep Learning Revolution; a technical overview of robotics, 1600 pages - The Springer Handbook of Robotics; and so on). You just can't learn it overnight.

So how do you solve unprecedented problems when they arrive?

You learn ahead.

If you truly need to learn something esoteric to save the world, like thermonuclear astrophysics or the correct sequence of operators for the UNIX tar command, then it's too late and you're fucked. But if you have a hint of what your future problems might be - like knowing you may need to try a generative deep learning model to help solve a learning problem you're working on - then you can read ahead on that problem before it arises. You may or may not need any specific skill that you train ahead on, but if you've got a good idea of the possibilities, you may have time to cover the bases.

Case in point: I'm working on a cover design for The Neurodiversiverse, and we're going to have to dig into font choices soon. Even though I've been doing cover design for about ten years, graphic design for about thirty years, and art for about forty-five, this is calling for a level of expertise beyond my previous accomplishments, and I'm having to stretch. When we go into the Typographidome, it will be too late to learn the features that I need to pay attention to, so I'm reading ahead by working through the third edition of Thinking With Type, which is illuminating for me all sorts of design choices that previous books simply did not give me the tools to understand. I may not need all the information in that book, but it's already given me some tools that help me understand the differences between potential font choices.

Alternately, you can work ahead.

If learning it per se isn't the problem, you may be able to do pre-work that helps you solve it. Practice, if the problem is skill or conceptual variation; or contingency planning, if the problem is potential blockers. You can't practice or plan for everything, but, again, you can cover many of the bases.

The other case in point: this entire blog post is a sneaky way to extend my blog buffer, using an idea I've already thought of to give me one more day ahead in the queue, leaving me adequate time and effort set aside to work on the series of posts that I plan to run next week. I don't know what's going to happen as I go into this interesting week of events ... but I already know that I'm going to be crunched for time, and so if I complete my "blogging every day" series ahead of time, then I can focus next week on what I need to do, instead of scrambling every day to do a task that will detract from what I need to do in that day.

So: learn ahead, and work ahead. It can save you a lot of time and effort - and avert failures - later.

-the Centaur

Pictured: a bit of Thinking with Type, Third Edition.