Jesse's Blog

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.

Here's some things I'm looking to set up and try.

• Healthcheck - Dead Man's Switch to let you know if things stop working.
• UptimeRobot - Similar, but looks a bit more featured.

• What's Up Docker - Don't let your containers age out. .. I didn't use this one. I'm using watchtower; it's far more simple.

• Scrutiny - Monitor Drive Health .. Works exactly like I'd hoped.

An image hosting replacement for google photos and apple photos (immich) a web based note taking app (memos) an RSS feed reader (freshness) a notification system (ntfy) an IT Swiss army knife (IT-Tools) local dns ad blocking (adguard) YT downloader (pinch flat or metube) containerized browser (kasm) Home automation (home assistant) recipe hosting (mealie or tandor) personal blog (grav) media consumption (plex plus arrrr) a way to share text or images quickly (pastebin) privacy front end for reddit, YouTube, etc (redline, invidious, etc) coding/scripting tools (vscode) A front end for the entire system (cosmos cloud)

• Authentik - IDP

We stand on the shoulders of giants. Or at least, those who suffered that we might not, and so we should respect our elders. I do, and this is a list of places I'd prefer to lean on experience than relearn the hard way:

• Cunningham's Law: The best way to get the right answer on the Internet is to post the wrong answer and wait for people to correct you.
• LeBlanc's Law: Later == Never
• Brooke's Law: Adding developers to a late software project makes it later.
• Hyrum's Law: All observable behaviors of your system are depended on by someone.
• Parkinson's Law: Work expands to fill the time available for it's completion.
• Pareto Principle: For any phenomonon, 80% of the consequences stem from 20% of the causes.
• Hofstatter's Law: Everything takes longer than you think it will, even when accounting for Hofstatter's Law.
• Conway's Law: Any software reflects the organization that built it.
• Linus's Law: Given enough eyeballs, all bugs are shallow.
• Wirth's Law: Software gets slower faster than hardware gets faster.
• Zawinksi's Law: Every program expands until it can read email. Those which can't are replaced by those that can.
• Sturgeon's Revelation: 90% of everything is crud.
• Stein's Law: If it can't go on forever, it'll stop.
• Goodhart's Law: When a measure becomes a target, it ceases to be a good measure.
• Wiio's Law: Communication fails except by accident.
• Macnamara Fallacy: Making decisions based on both measurable data and ignoring unmeasurable data is suicidal.
• Trust but verify: (Russian: доверяй, но проверяй, tr. doveryay, no proveryay, IPA: dəvʲɪˈrʲæj no prəvʲɪˈrʲæj) is a Russian proverb, which is rhyming in Russian. The phrase became internationally known in English after Suzanne Massie, a scholar of Russian history, taught it to Ronald Reagan, then president of the United States, the latter of whom used it on several occasions in the context of nuclear disarmament discussions with the Soviet Union.
• Wright's Law: The more times a task has been performed, the less time is required on each subsequent iteration.
• Hyrum's Law: all observable behaviors of your system will be depended on by somebody.
• Layne’s Law – “A) Every debate is over the definition of a word, B) every debate eventually degenerates into debating the definition of a word, or C) once a debate degenerates into debating the definition of a word, the debate is debatably over.”
• Lamport's Law - If you’re thinking without writing, you only think you’re thinking.
• Mellon's Law - Everyone wants to host an API, but nobody wants to use one.
• Betteridge's Law of Headlines - Any headline ending with a question mark can be answered by the word no.

While it's not a law, it should be. Cunningham said: "If software is not periodically rewritten to communicate what we've learned, then the software will lack any sense at all eventually."

I was wrong.

Modern Hollywood is completely incapable of writing anything even remotely compelling, and throwing money at the problem, as The Acolyte is teaching us, still doesn't work, and I've been thinking a lot about why that could be. I've been following the Disney versus Nerdrotic and Critical Drinker debates, and the idea that Disney can't shut two Youtubers up makes me incredibly happy. Still, how have writing standards fallen so far?

It hit me that the core of the problem has to do with Hollywood's ultimate goal, and the human tools that they use to accomplish that goal. The object has always been, at least for as long as I've been around, to subvert the values of Christianity, not limited to the atomic family, sexual roles, faith, beauty, goodness, truth, and ultimately, Jesus Christ. However, in order to achieve that goal, one must first be able to understand the value of that which they wish to destroy. Modern writers, with their complete inability to even feign agreement with these values, cannot suspend disbelief among those with even an inkling of the beauty of those values.

I do not believe that writers with that upbringing do not exist, and I'm not suggesting we let our guards down. Clever subversion is in some mediums (looking at you, triple A gaming), alive and well. However, Hollywood has slammed the doors shut on letting such people into the writer's room, and their absurd inability to understand that this has resulted in their output being so universally despised, and their childish name calling of anyone who disturbs their illusions that we want what they're peddling, has proven to me to be far more entertaining than anything they could have written. The wonderful part of that joy is that I don't pay them one thin dime while doing it.