Programming Leftovers
-
Another attempt at a “unit test”
The reactions to my previous post were interesting—it wasn't a “unit test.” At best, it might have been an “integration test” but because it involved actual work (i.e. interaction with the outside world via nasty nasty side effects, aka I/O) it immediately disqualified it as a “unit test.” And to be honest, I was expecting that type of reaction—it appears to me that most unit test proponents tend to avoid such “entanglements” when writing their “battle tested” code (but I'm also willing to admit that's the cynical side of me talking). There were also comments about how 100% code coverage was “unrealistic.”
-
[Old] The Five Ws of a Git Commit
Your commit history is not for you, at least not for you of right now. You of right now are full of context and understanding that despite how much we may convince ourselves that we’ll remember with perfect clarity tomorrow, I rarely find that to be the case. To solve this problem it’s important to approach our commit history like a story.
-
[Repeat] CAP Theorem & UI Programming
If we call this API on the UI thread, we might block user interaction for two seconds. That’s probably long enough to cause "Application Not Responding" timeouts (crashes!) on some devices. And it's definitely long enough to annoy users.
It’s a shame that this logically static data is fetched from a general-purpose asynchronous API, backed by the manufacturer's hardware-abstraction-layer drivers, which could be arbitrary code.
-
Getting people to tell you you're wrong
When you communicate out an idea, you are eminently trustable. Usually you're right, and you have the bona fides to back that up. And you're also persuasive and somewhat naturally convince people that your idea is right.
This is a challenge. As a staff+ engineer, you are still human, so you will still *gasp* be wrong sometimes. But when you're wrong, you're less likely to get pushback. As a staff+ engineer, you have to be more careful with your ideas, and actively seek out checks on your own ideas. Pushback won't come as naturally and immediately as it did earlier in your career.
Here are a few of the things that I do to validate my ideas and elicit checks on them. Some are the same as when I was a senior software engineer, while others are unique to the leadership role of staff+ engineering.
-
Predicate Logic for Programmers: Status Report
Two years ago I started a new book: Predicate Logic for Programmers. In it I said
People often ask me what’s the best math to learn for formal methods, and my answer is always “predicate logic”. 1 It’s super useful to specifying properties, understanding requirements, and just modeling things in general. Then they ask me how to learn it and I falter.
[..]
I estimated it would be in early-access by June 2021. But then real life intervened, and then ADHD happened, and then I didn’t touch it for two years. In January of this year I picked it up again, with the goal of having the first draft done by the end of winter. Well, that’s not happening either, but I am 10k words in, so that’s progress! Let’s do a rundown of what the book is, what I have planned, and what I’m struggling with.
-
2023-03-05 0033: table sizing, bench harder, wasm frist steps, sycl vancouver, breathing for warriors, move your dna, the molecule of more, how to decide, slouching towards utopia
-
Canonical joins the Eclipse Foundation’s Software Defined Vehicle working group
Canonical is excited to announce it is now an official member of the Eclipse Software Defined Vehicle Working Group (SDV WG). Eclipse SDV focuses on software-defined vehicles (SDVs) and pushes innovations in automotive-grade solutions using open-source software.
-
Assembly Language 80’s Minicomputer Style
In the days before computers usually used off-the-shelf CPU chips, people who needed a CPU often used something called “bitslice.” The idea was to have a building block chip that needed some surrounding logic and could cascade with other identical building block chips to form a CPU of any bit width that could do whatever you wanted to do. It was still harder than using a CPU chip, but not as hard as rolling your own CPU from scratch. [Usagi Electric] has a Centurion, which is a 1980s-vintage minicomputer based on a bitslice processor. He wanted to use it to write assembly language programs targeting the same system (or an identical one). You can see the video below.
-
Testing multiple Python versions with nox and pyenv
Nox is an incredible tool, I use it for all my Python projects, highly recommend it. One of the best features of nox and tools like it is parameterization. Usually this is done for the test suite portion where you want to run your test suite on many different Python versions (and maybe other things like dependency versions): [...]