Jesse's Blog

So today I learned that there's a -c parameter on the md5sum command:

md5sum -c checkfile.md5

This will use the output from a previous run of md5sum piped out to flat text to validate that the files defined in that file match. Sounds simple if you took the time to read the man page. I hadn't, and so now I have to laugh at myself for the oddball workarounds I've done after not having read it.

Same applies to a recent read of 'Learn PostgreSQL' by Ferrari and Pirozzi. I read about Window functions, but when I originally read about rank(), I stopped reading, when it turns out that first() did I wanted with less lines of code.

So what I really learned (for probably the ten thousandth time) is don't stop reading.

Interesting Read.

Ladies and gentlemen, I give you the Doom Scroller.

This is a Raspberry Pi Pico, a breadboard, a rotary encoder, a button, a suction cup, and an Altoid tin begging to be released from this mortal coil.

I got the idea from MaxMacSTN trolling for 3D prints. I've extended his code a bit such that it does this:

In my config for I3, F13 is the start for ncmpcpp, and Win-D is Rofi. You switch modes by holding down the knob for a second.
For now, the button on the side is a reset. If you hold the knob down while doing it, the Pico allows you to modify the code it runs. Mode 1 also functions well as an SDR tuner.

I have three more encoders, and I'm strongly considering adding some function before finally designing and printing something a little more permanent. I gotta tell you, doom scrolling this way is a dopamine well.

I reached this link from this link.

1. Understand the system: Read the manual, read everything in depth, know the fundamentals, know the road map, understand your tools, and look up the details.
2. Make it fail: Do it again, start at the beginning, stimulate the failure, don't simulate the failure, find the uncontrolled condition that makes it intermittent, record everything and find the signature of intermittent bugs, don't trust statistics too much, know that "that" can happen, and never throw away a debugging tool.
3. Quit thinking and look (get data first, don't just do complicated repairs based on guessing): See the failure, see the details, build instrumentation in, add instrumentation on, don't be afraid to dive in, watch out for Heisenberg, and guess only to focus the search.
4. Divide and conquer: Narrow the search with successive approximation, get the range, determine which side of the bug you're on, use easy-to-spot test patterns, start with the bad, fix the bugs you know about, and fix the noise first.
5. Change one thing at a time: Isolate the key factor, grab the brass bar with both hands (understand what's wrong before fixing), change one test at a time, compare it with a good one, and determine what you changed since the last time it worked.
6. Keep an audit trail: Write down what you did in what order and what happened as a result, understand that any detail could be the important one, correlate events, understand that audit trails for design are also good for testing, and write it down!
7. Check the plug: Question your assumptions, start at the beginning, and test the tool.
8. Get a fresh view: Ask for fresh insights (just explaining the problem to a mannequin may help!), tap expertise, listen to the voice of experience, know that help is all around you, don't be proud, report symptoms (not theories), and realize that you don't have to be sure.
9. If you didn't fix it, it ain't fixed: Check that it's really fixed, check that it's really your fix that fixed it, know that it never just goes away by itself, fix the cause, and fix the process.