Fun Facts about SQLite

 SQLite is wild.

thumbs way up

When you enjoy thinking about UI/UX, it's fun and instructive to see evolutions in products you use every day, and think about what their designers were trying to accomplish, and what you might think they could do better.

So in FB Messenger, they recently changed the "send message" button - I believe that previously it was inactive until you typed some message content. Now it's a "thumbs up" button when the message body is empty, which sends a big thumbs up (btw, isn't that a rude gesture in some cultures? I was just googling to see if FB uses anything different elsewhere...)

So I noticed this on accident, when I see I had sent a big thumbs up between 2 of my own messages... (I quote "The Tao of Programming": "A program should follow the 'Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.")

So, on the one hand, I could see that an easy general "OK" response is potentially useful, and a little easier to get to here than the usual "reaction" picker for previous messages. On the other hand... it seems weird to just make that the default message - especially to ones own messages. When you accidentally send one against your own message, it seems weirdly insecure or self-aggrandizing.

I wonder if they considered changing the "just send a thumbs up" function to activate only after the other person has written something back? That seems like a more useful scenario. But I guess would make the UI even more chaotic and unpredictable.

whither redux? wither redux?

State of JS 2024  - The one thing I noticed about earlier renditions continues - weirdly silent on Redux, unless I'm not looking in the right place. Which is an older tool to be sure (it gives strong 2019 vibes, having been largely supplanted by useContext hooks) but two separate gigs I had in 2024 leaned on it heavily.

spaghetti, lasagna, onions

From a post 12 years ago, but I think still relevant, Larry on The Daily WTF:

Back when I was your age, spaghetti code was the curse of the industry. Random gotos pointing anywhere. Branching into the middle of subroutines, or out.

Then came lasagna apps. Layer upon layer of abstraction so deep nobody knew how it really worked -- if it did. Before you could dig down to the meat you had to scrape aside tons of moldy cheese.

Now we have onion corporations. No one really does anything. They just contract with someone else to do it. And if you peel away that shell (tearfully) you find another contact handing off responsibility but skimming some of the dollars.

It's turtles all the way down! Recursion FTW!

buildless evergreen

How One Programmer Broke the Internet By Deleting a Tiny Piece of Code - an article on the history that led to the trivial "left-pad" module being removed and causing all those problems by the removal a while back. Obviously raising the question, how much is too much when it comes to depending on modules and additional libraries to do all the heavy lifting?

I'm getting better at framing the divide between my work for Enterprise, and my personal project work. That rift of technologies used has grown wider over the years, though my personal project stuff - having to take on the full stack and the complete UX/UI experience - is still a huge boon to what I bring to the table for "real jobs"

Two buzzwords for one-person-shop, long term side project works that don't apply to most enterprise efforts: "buildless" and "evergreen". Sticking with tech that is likely to stay well-supported, you minimize dependencies on third parties. For me, that means - HTML/CSS/JS that the browser supports natively (browsers are truly impressive in advancing in power at a stately pace while maintaining brilliant backwards compatibility), often it means static HTML or PHP - while some people scoff, sticking with core PHP allows me to keep just one business relationship for deploying my code and maintaining my legacy sites, and the scripting paradigm PHP uses - a clean start every time - is very amenable to thinking in terms of functional programming, despite the ugliness of its APIs.

Again, Enterprise usually finds it better to invest in good toolkits and libraries and build systems, they can take on the cost of hiring people to make a code base an ongoing concern, and it's generally worth the complexity to make sure developers are meeting the company's needs by answering the basic problems in idiomatic ways. But when I want to write code that just works for my needs reliably over years and is usually pretty easy to edit when it some functionality needs to be added, the rules of "KISS" really apply.

bugs bugs bugs

Fun, fast pasted overview of some infamous software bugs, going into details as to the logic that caused the error when possible.

SPOILER for the video's ending joke:

"There are two ways to write error-free programs; only the third one works."

--Alan J. Perlis

That reminds me of how there is a divide on how much emphasis should be put on units-in-isolation testing vs holistic, parts-communicating-in-their-contexts. Both are needed. The former is usually cheaper to put into automated systems, but the "test all hundred trees and have confidence that the forest is sound" alone idea misses the concept of emergent properties of interconnected systems...

on buildless testing

On Buildless Testing - so i don't know if "buildless" will ever make a lot of waves in enterprise - but for hobbyist coding, or any time when you need to have some thing last for years but may need to come back to it later - it has real merit. Very interesting piece on how to get testing going under that (along with another seeimingly unpopular view I share, that sometimes too much emphasis is placed on unit testing, which so often is just a redundant test of implementation (or of mocks!) rather than of functionality in a meaningful context...)