Files
hpr-knowledge-base/hpr_transcripts/hpr1367.txt
Lee Hanken 7c8efd2228 Initial commit: HPR Knowledge Base MCP Server
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-26 10:54:13 +00:00

129 lines
7.1 KiB
Plaintext

Episode: 1367
Title: HPR1367: I'm Sorry Dan
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1367/hpr1367.mp3
Transcribed: 2025-10-18 00:19:33
---
music
You're listening to HPR, hacker, public radio.
I'm your host for today, or tonight, depending on your time zone.
My name is Jezra.
Sit down, relax.
Be ready for a tail.
Actually, I was going to talk about a problem I had at work, and so I will expand a little
bit upon what I do at work.
I work for National Novel Writing Month, and we put on National Novel Writing Month.
And I work maintaining the website.
Typically, in November, we get between 400 and 500,000 people per day coming to our website.
This puts obviously a lot of stress on the server, and we need to make sure that the
code is running smoothly.
And we are developing our code.
We have three branches, beta, staging, and production.
Beta is where we add new features, and staging is where we fix bugs.
Along with the code, we maintain a system of tests that test the code, so that we're
not pushing code to the server without testing it first to make sure that it complies with
the tests and won't introduce bugs to the website.
I am notoriously sh-
Unicorn.
For forgetting to run the tests before I push my code to the sites.
Not production mind you, I'm just talking about staging, which still needs to be tested
rigorously because code will go from staging directly into production on the live site.
So it's imperative that I make sure to run the tests all the time.
On Friday last, I pushed some code that broke the tests.
I didn't run the tests, but I pushed the code.
My coworker Dan, Danimal, Danimalis, Dan the Man, Dano Rymo, the guy I got a cookie
for today because I felt bad about not passing the tests, was displeased that I did not
pass the tests, or run the tests.
So I did what any lazy coder would do.
I found a way to have the tests run, or at least get asked to run the tests frequently,
and for this I used Git.
All of our code is in Git for version control, and Git offers hooks that are scripts that
can be run before or after certain events happen.
If you are using Git for version control in a project, if you are in the main source
directory for that project, if you enter a hidden directory.get and look for a directory
in there named hooks, you will find examples of various hooks that you can use for your coding.
Now in this case, I used the pre-commit hook, meaning that I would edit some code.
I would add it to my Git commit, but I wouldn't do the commit yet.
Afterwards I would have to run Git commit, and I would commit the additions that I had
made to the code.
The pre-commit hook takes place before the final commit.
So I added some code, I added it, and then I would type git commit, and as soon as I
hit git commit, my hook runs.
What my hook does, in this case, it checks the name of the current working branch.
If I'm in beta, this script doesn't run.
If I am in production, or if I am in hotfixes, which is the staging for us, which is called
hotfixes, and if I am in one of those, then the script will run, and the script does
the following.
It asks me specifically, did you run the specs, why slash n asking for some user input?
I will type yes, and everything goes along according to plan.
But then I would be lying to the application, because what if I didn't run the script?
So then I will type n, because I did not run the script.
I did not run the, sorry, not the script, the test.
Did I run the test?
No.
So then I am asked the second question, would you like to run the test now?
And it's another, expects a y or n for input.
If I type an n for no, that's it.
And of the script, everything stops running.
git does not commit.
If I type y for yes, the script that I wrote, my pre-commit script, will run the spec
test, to make sure that everything is up to specification.
If the test passes, then it will continue with the git commit, and everything is all
nice and fine and dandy.
If the test fails, if for any reason one of the tests fails, the git commit fails, and
then I have to go and check and find what I screwed up, and then I fix it, and then I go
through the process all over again.
And that's fine.
I want to go through the process all over again, because I want to make sure that when I
am pressing, pushing code to the live site, it is nice and clean, and running the way
it should be.
When I was first writing this script, everything was nice and fine.
I was writing this little pre-hook script, testing it, sort of running it, and everything
seemed to be working appropriately.
As soon as I added this script, which is named pre-dash commit, into the hooks directory
of my dot git directory within my code repository, as soon as I added this script, the user input
started failing.
I couldn't get a hold of the input, because it would seem that standard in, which is where
I am typing, is not what my code was listening to for getting its data.
I don't know what my code was listening to.
But the git code, when I ran git commit, it ran the hook, and git was actually running
my script.
So the first part of my script is, I had to reset, standard in, to dev slash TTY, which
is my whatever text type, bit to bit.
Someone tell me what TTY is, because I don't feel like looking it up right now, and I don't
want to bother putting in the show notes, and I don't want to edit this piece of audio
out of my cast.
So you'll just have to listen to it and deal with it.
So go ahead and tell me what TTY is, text terminal, yeah, maybe, man, I don't know.
What I do know is that spending a few minutes to write this script has made me a better
worker, a more productive employee, and someone who's not as likely to make Dan angry.
And Dan, if you're listening, I'm sorry, buddy, I'm sorry.
Now everyone knows my shame.
So really, I think that's what this is.
This is a public shaming, because I messed up.
Luckily, it didn't happen during nano-rimo itself, because that could have been really bad.
Caught the error before it happened, found a solution to the problem, and enacted the
solution.
Huh, it works.
Maybe you have a problem.
Maybe you have a solution to the problem.
Maybe you want to share that with the rest of us.
Go ahead and shame yourself.
Get on hacker public radio and tell us your story.
Thank you.
To do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do, do.
You have been listening to Hacker Public Radio, or Tacker Public Radio does our, we are
a community podcast network that releases shows every weekday and one day through Friday.
Today's show, like all our shows, was contributed by a HPPM listener like yourself.
If you ever considered recording a podcast, then visit our website to find out how easy
it really is.
Hacker Public Radio was founded by the Digital Dark Pound and the Infonomicum Computer
Club.
HPR is funded by the Binary Revolution at binref.com.
All binref projects are proudly sponsored by Lunar Pages.
From shared hosting to custom private clouds, go to LunarPages.com for all your hosting
needs.
Onless otherwise stasis, today's show is released under a creative commons, attribution,
share a life, free-do-your-license.