lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- 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>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

141
hpr_transcripts/hpr4457.txt Normal file
View File

@@ -0,0 +1,141 @@
Episode: 4457
Title: HPR4457: doodoo deuce
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4457/hpr4457.mp3
Transcribed: 2025-10-26 00:53:10
---
This is Hacker Public Radio Episode 4,457.
For Tuesday, the 2nd of September 2025, today's show is entitled Dudu Juice.
It is hosted by Jezra and is about 12 minutes long.
It carries a clean flag.
The summary is Episode 2 of creating Dudu, a to-do app to get done done.
Hello HPR listeners, my name is Jezra and I'm sipping some coffee.
Today's episode of Hacker Public Radio is Dudu Number 2 and it is the third in a series
of developing a small to-do app called Dudu.
As the application currently stands, it is crud complete at the API level.
That means that the API can handle creating, reading, updating and destroying the two types
of elements that make up the Dudu app.
There are items, those are the things to do and there are collections and a collection
is a grouping of items.
I really should have just called it groups.
Aside from the API, the UI is just about 100% complete.
I'm not completely sold on each element in the interface, having its own button for
deleting that element or editing that element, but it works.
This is supposed to be a simple application and simple applications should just work.
In episode one, I spoke about creating the interface using tabs to sort the collections
of items and I didn't do that.
I don't like tabs in web browsers.
Tabs are not a native element in HTML, which means for a tab to behave as tabs should,
there needs to be some JavaScript applied to them.
In a desktop application, whether it is on Linux Mac Windows, there is an expectation
of how tabs are going to behave and that is the exact expectation a user should have when
interacting with tabs in the web browser and tabs tend not to do that.
It is, in a sense, an accessibility question and an accessibility issue.
Do these tabs behave the way tabs should and are expected to behave and I did not want
to have to create and add the complexity of making tabs that behave the way tabs should.
The UI for DoDo is really basic HTML, divs, spans and buttons comprise the majority of
the interface code.
There were a few neat things I learned while creating the interface, specifically in the
form of some CSS that be cascading style sheets to do styling for the interface.
Normally during the creation of a small application, there will come a point where I put a button
onto the HTML and I want to style that button and align that button and have that button
do and be where I want it to be, instead of focusing on making sure that my map button
is clicked, the button does what it is supposed to do.
And I will spend hours, hours, it is the bane of my development existence, I will spend
hours trying to get the alignment and the placement of something perfect in CSS when really
I should be focused on just getting it done and working.
What was very surprising is that in this instance, I didn't do that, I got things to work
exactly how I wanted them to.
During that process, I learned about CSS custom properties.
A CSS custom property is a CSS tag that one can create with a custom name and then that custom
name can be used throughout the rest of the CSS file.
The way it was utilized for DoDo was for creating a custom property named Primary Color.
And that Primary Color variable was set to a color, I believe it was purple, Octo-thorpe
FF00FF, if you will.
Then later on in the CSS file, I could access that Primary Color variable, for example setting
the background color equal to the Primary Color.
And by doing that, I would have this Primary Color in the CSS file that I could change at
will and then everywhere else in the file because it's a variable, it would just get replaced
and then I wouldn't have to worry about keeping track of all the different colors.
The second CSS feature that I learned about is Mix Color and that is what allows me to mix
one color with another color and come up with a new color.
Combined with the custom property, I managed to create a Primary Color with custom property.
Then another custom property called Primary Color Darker in which I use Color Mix to mix
in some black to the Primary Color.
I also made Primary Lighter which mixes in white and then Primary Darkest and Primary
Lightest which mixed in even increasingly higher levels of black and whites.
And again, because these are custom properties, I could use the Primary Color Darker and
Primary Color Darkest later on in the CSS file.
So now I have five variables holding color data all based on a single variable holding
color data in CSS and all I would need to do is change that first color and then I would
get a matching set of four different colors based on that initial color.
And it really was nice to be able to do that and just experiment with changing the color
around very easily everywhere in the CSS file by changing one line of CSS code.
This UI was not started from scratch.
This UI was based on code that was previously written for a ESP32 system that has a small
web browser in it and there was a need for accessing that device and having a web interface
and it's really that web interface that is the basis of Dudu's interface.
I took the entire HTML directory, the HTML file CSS and styling from this other project
copied it wholesale and then started editing it to meet my needs.
And that is how a lot of the interface for what I do is created.
It is all based on something I have created previously where I take the previous project,
copy it, modify it to make it work the way I want it to.
And usually during that process, there is an improvement.
And then spanning off into the future, there will be more changes, more projects, more
improvements to the code until I get to the point where I think, oh, I should start merging
some of this improvements backwards into these older projects.
And I never do because I always want to make something new and rarely do I go back and
fix up some old stuff.
And also there is old stuff that does need to get fixed and it does get fixed when it needs
to be.
The key there being need if it is flat out broken, it needs to be fixed.
Now that Dudu is fully functioning locally, it is time for me to put Dudu out there so
that I can access it wherever I am from my phone as long as I've got some sort of internet
connection and also be able to access it from my desktop computer.
Again, as long as I have an internet connection.
In order to do that, I need some sort of authentication to ensure that the person accessing the data
in Dudu is me and no one else.
And there are multiple ways to do that.
If, and this is a big if, if this application was being written for multiple users, aside
from having all the data in a database, there would probably be something along the lines
of JSON web token being used for authentication.
That is where someone signs in to a web application.
And they receive back, or I should say the client, the browser receives back a token.
And then that token is included with every web request.
It would be included in the header.
And by doing that, the server on the backend can check that header data to see, yes, it
is this person accessing the data.
We know who it is.
But that's not what Dudu is going to do.
What will most likely happen with Dudu is at the server level, there will be a configuration
file that contains a hash of a passphrase.
The passphrase could be anything, preferably a bit more complicated than hello world,
something like yellow bananas speckled with black dots.
That's a great passphrase.
So the hash of that phrase gets stored in a configuration file.
At the UI level, the first time the application is opened, the first time that web interface
is accessed, there will be a check.
Is there stored in local storage the passphrase?
And if not, then the application will show the interface, please enter the passphrase.
And there will just be a text input field where the user, in this case me, the single
user, will enter yellow bananas speckled with black dots enter.
And upon hitting enter, that passphrase will be stored in local storage through JavaScript.
And it will be included in the header of every request to the API.
At the server level, there will be a check to make sure that there is that data coming
in from the header that passphrase that is pulled from the header will be hashed.
Will that hash match the hash in the config file?
If it does, everything is good.
If not, there is an error and no data is returned.
That to me is simple.
The other option, of course, as I said previously, for a multi-user system would be to add something
like Java, web tokens.
And even that can be done fairly simply, but it's not simple enough.
And on that note, I have episode one of Dudu to upload, as well as some music to play.
So I've got to go do stuff.
Have a great day and keep on hacking.
You have been listening to Hacker Public Radio at Hacker Public Radio does work.
Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording a podcast, you click on our contribute link to find out how easy it really is.
Hosting for HBR has been kindly provided by an honesthost.com, the internet archive and our syncs.net.
On the Sadois status, today's show is released under Creative Commons, Attribution 4.0 International License.