The best teacher I ever had on how to write and how to code was a complete charlatan hack who conned his way into Duke’s English department. No wait, hear me out: the prof (let’s call him Matt, because I’m not even entirely sure he gave us his real name) was an awful professor in most respects. He didn’t grade anything, I’m dubious he had any teaching credentials in the first place, he often didn’t even bother showing up to class at all, and, while I’m about 95% sure he had some college degree, I’m extremely skeptical it was in English, or that it came from Harvard.
I realized the other day that, while I do almost all of my development “in *nix”, I don’t actually meaningfully program in what I traditionally have thought of as “*nix” anymore. And, if things like Hacker News, Lobsters, and random dotfiles I come across on GitHub are any indication, then there are many developers like me. “I work on *nix” can mean a lot of very different things, depending on who you ask.
Let’s zoom back to early April. We’re several weeks into the COVID-19 epidemic. I’m not sleeping well. In fact, a “good night” for me is just a few hours. I’ve realized a couple days ago I’m averaging about 30 to 40 hours of sleep per week. The talking heads on Fox have already begun their drumbeat about how we should reopen businesses to save the economy, despite zero economists arguing for that.
As much as I love exploring and using weird tech for personal projects, I’m actually very conservative when it comes to using new tech in production. Yet I was an immediate, strong proponent of React Hooks the second they came out. Before Hooks, React really had two fundamentally different ways to write components: class-based, with arbitrary amounts of state; or pure components, done as simple functions, with zero state. That could be fine, but the absolutely rigid split between the two was a problem: even an almost entirely pure component that had merely one little tiny bit of persistent state—you know, rare stuff like a checkbox—meant you had to use the heavyweight class-based component paradigm.
Inspired by Falsehoods Programmers Believe About Dogs, I thought it would be great to offer you falsehoods programmers believe about mankind’s other best friend. But since I don’t know what that is, here’s instead a version about cats. Cats would never eat your face. Cats would never eat your face while you were alive.1 Okay, cats would sometimes eat your face while you’re alive, but my cat absolutely would not.
Edge is dead. Yes, its shell will continue, but its rendering engine is dead, which throws Edge into the also-ran pile of WebKit/Blink wrappers. And no, I’m not thrilled. Ignoring anything else, I think EdgeHTML was a solid rendering engine, and I wish it had survived because I do believe diversity is good for the web. But I’m not nearly as upset as lots of other pundits I’m seeing, and I was trying to figure out why.
Google is about to try, yet again, to compete with iMessages, this time by supporting RCS (the successor to SMS/MMS) in their native texting app. As in their previous attempts, their solution isn’t end-to-end encrypted—because honestly, with their business model, how could it be? And as with Google’s previous attempts to unseat a proprietary Apple technology, I’m sure they’ll tout openness: they’ll say that this is a carrier standard while iMessages isn’t, and attempt to use that to put pressure on Apple to support it—never mind the inferior security and privacy that make the open standard a woefully…erm, substandard choice.
For reasons that I’ll save for another blog post, I decided recently to ditch pretty much the entire Apple ecosystem I’d been using for the last decade. That’s meant gradually transitioning from macOS to Ubuntu, and from iOS to Android. Of course, to ditch iOS for Android required a new phone; after some research, I opted for a Google Pixel 2. The Pixel 2’s been a great phone and has lots of interesting features, but one of the more esoteric features is called Moving Images.
I’ve been going through a pile of old bitquabit posts. While many of them hold up over time, the more technical ones frequently don’t: even when I was lucky and happened to get every technical detail right, and every technical recommendation I threw out held up over time (hint: this basically never happens), they were written for a time that, usually, has passed. Best practices for Mercurial in 2008 are very much not best practices now.