I was reading about Phoenix today, looking at guides and documentation. It’s great to see in a guide when it’s easy to quickly set up a project, that makes it fun to get started and explore. The most exciting thing about Phoenix is that “reactivity”, or live updates, are a core part of the system, not an add-on. Nowadays I find any software without reactive updates frustrating and annoying to use.

There’s been a lot of restrospecting lately, lamenting the loss of the “indie web” and its subsumption by content platforms like Facebook, Instagram, Reddit and Twitter. (I’ve always wondered where Tumblr fit in - more indie than any of these, but still - owned by Yahoo!). A few casualties that fell by the wayside: blogs, web comics, and independent, topic specific forums.

All of these media still exist, much diminished and publishing social posts to route you to their sites, but they are still self-hosted, free of editorial control and in their author’s hands. To some degree, these forms will probably stay on the web until millenials die out.

I love squash merging. I think it’s the simplest way to maintain a legible commit history on main, a shared dev branch, etc. It’s easy for most people to follow, and it doesn’t require you to be too Big Brained about git. GitHub even provides a convenient interface for doing this, right in the pull request UI!

But GitHub’s squash merge workflow undermines the biggest benefits of squash merges: clear, simple, atomic commit messages that explain what each commit does.

Dan Luu tweeted about some great work interns that he has mentored accomplished at Twitter:

One intern did https://t.co/nsFW20j9Hm and another did interesting data analysis then built a working prototype for across the fleet profiling that others were able to use to find real inefficiencies.

Those are things that could go into a staff promo packet as a major project.

— Dan Luu (@danluu) August 31, 2022

OKRs are one of those business ideas that are just simple enough to be dangerous. You think you understand it in a day, and you can see where your company is falling short: lacking focus and underdelivering. You see how clear, measurable goals could improve the situation.

Here’s the one sentence version: You set objectives, and for each objective come up with several key results that you can measure to see if you met the objectives. There’s a whole book for implementing this process in large organizations, and a mystique because of its association with Google’s early and frightening effectiveness.¹

Every so often I’ll see a meme on Twitter like:

and it makes me so mad. For good reason! OSS project repositories that support merge commits to main are usually littered with useless comments like: “Merge change from $USER, $PR”. It makes the commit history on main utterly useless and you get to check the various feature branches in a never ending snake of commits to find out what the hell changed.

Every so often I wonder if I’m making trouble for myself by doing all of my typing in vim. Writing for this blog, writing engineering plans and design documents, and writing code. There are tools that are made especially for doing these jobs, and vim certainly doesn’t have any facility for making diagrams.

All vim can really do is edit a bunch of bytes, trying to represent them as formatted text. It doesn’t even really understand code, which is what most people use it for.

I’ve spent a lot of time the last 3 years watching Umberto Eco’s sign’s of Ur-Facism manifest, and manifest, and manifest. I’ve seen a lot of things that I was raised to believe wouldn’t couldn’t happen here happen in sequence, with frightening speed. Out-of-control (willfully so) police beating and gassing people in the street, night after night after night. Destruction of public schools, along with requiring states fund religious schools. A Justice Department hell-bent on revenge for the President. Open xenophobia, brazen racism by members of congress. I thought we left that behind when Strom Thurmond finally died.

TLDR;

I learned a bunch about rendering fonts and I thought it would be interesting to read about them from a programmer’s perspective. I gained a ton of empathy for type design and type-setting developers, as they work with a dizzying variety of screen resolutions, font styles, and a wide variety of device speeds to produce type that looks as good as it possibly can under harsh conditions.

Background

I’ve been working on a project involving a two-color e-ink screen. I’m drawing on the screen and that involves drawing text. The project is written in Go. There are common font-rendering librares like Cairo, which are written in C. I find compiling against C libraries like using cgo difficult and complex, so I was really interested in a Go-only solution.

I got an email from an old co-worker the other day:

I was thinking about you and how you are a person I see as not being particularly embroiled in office politics, but also as having a lot of influence and knowing how and where to leverage it. I was curious if you had any words of advice for how you got to that place.

Of course I was happy to hear that I come off this way, and as I thought about how to reply, I found myself writing an essay.