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>
This commit is contained in:
95
hpr_transcripts/hpr4445.txt
Normal file
95
hpr_transcripts/hpr4445.txt
Normal file
@@ -0,0 +1,95 @@
|
||||
Episode: 4445
|
||||
Title: HPR4445: doodoo one
|
||||
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4445/hpr4445.mp3
|
||||
Transcribed: 2025-10-26 00:45:55
|
||||
|
||||
---
|
||||
|
||||
This is Hacker Public Radio Episode 4445, for Friday 15th of August 2025.
|
||||
Today's show is entitled Due to One.
|
||||
It is hosted by Jezre and is about 10 minutes long.
|
||||
It carries a clean flag.
|
||||
The summary is Episode 1 of a miniseries about creating it to do app.
|
||||
Hello, my name is Jezre and this is Episode 1 in a mini-series on software development
|
||||
where I am making an application called Due to a to-do list to help me get the Dung Dung
|
||||
that I need done or something along those lines.
|
||||
In Episode 0, I laid out the basic premise of why I needed to write this software and
|
||||
a few aspects of how I was going to create it as well as my goals in recording the audio
|
||||
for HPR and, of course, things never go the way I want them to go but they went the way
|
||||
they went and I am here now to talk about how they went when they were going.
|
||||
As soon as I stopped recording Episode 0, I started hacking on some code and got to the
|
||||
point that evening where I was ready to make a git commit and it wasn't anything spectacular.
|
||||
I had created an API that allowed me to create a collection and create a item and an item
|
||||
is something that needs to be done.
|
||||
A collection is a way to group all of the items.
|
||||
Originally, I had called them categories.
|
||||
I did not like categories because the plural of categories ends with IES and it's not
|
||||
something that one can pluralize by just adding an S to the end and I really didn't
|
||||
like that.
|
||||
The reason being, I found myself doing a lot of copy paste and then slight modify, modification
|
||||
of methods and functions so I would have the function to create a new item.
|
||||
I would copy that function, find all instances of item and replace it with category and
|
||||
anything where it was items would get replaced with categories but it would not be correctly
|
||||
plural.
|
||||
So that is why I changed category to collection because collection, collections, you just
|
||||
add the S on the end, oh man, so much easier, wow English, what a pain in the, took us.
|
||||
The next morning with Dudu still on my mind, I woke up, had some coffee and then I started
|
||||
refactoring and modifying the code and again, I found myself copying and pasting methods
|
||||
and functions for the editing of an item and changing it so that instead of just adding
|
||||
an item, I copy the paste code and then modify that new code so that it's not items but
|
||||
it's collections and that started to bother me because I was having this duplication of
|
||||
code with just very minor changes to it and at that point I decided that as a refactor
|
||||
I should make a single method to handle the creation of an item or category, single method
|
||||
to edit a item or a category, sorry, not categories, collections, wow, really confusing, I should
|
||||
have just used the word groups anyhow, I use an if statement and I pass in a data type
|
||||
is the data type and item, then handle this one line difference because that's all it
|
||||
really was just one line of difference and that really reduced the amount of code that
|
||||
I was writing, it made it a lot easier to find bugs and fix them in the code because there
|
||||
was only one method to check, so if I changed in the previous iteration where there was
|
||||
a separate method for editing a collection and a separate method for editing an item,
|
||||
if I made a mistake in one and copied and pasted that mistake into the other function, then
|
||||
I had to go fix that mistake twice, so by refactoring I managed to put all of my mistakes
|
||||
in one place, basically putting all of my eggs in one basket, there's only one place
|
||||
to look for where the bug could be and that made the process quite a bit easier.
|
||||
The way the code currently works, there is an API endpoint for the CRU of CRUD, create,
|
||||
read, update, destroy, I have not yet made the API endpoints for deleting or destroying
|
||||
an item from the list once I have completed the task and in the application I can say yes
|
||||
it's done, I haven't gotten that far yet, but I can create, I can read, and I can update,
|
||||
and what the API does, there's a class I made called a data manager, this would be sort
|
||||
of the data abstraction layer if you will, I am not using any sort of database, I'm not
|
||||
using my SQL, PostgreSQL, or even SQL Lite for this, I am storing the data in a flat file,
|
||||
the data is represented in the software as a dictionary, I'm using Python, so it's a
|
||||
Python dictionary, and there is a list of collections, and there is a list of items, and
|
||||
that's it, it's just, and that is stored in a JSON file, and every time a new item is added
|
||||
or edited, and same with a collection, once that's added or edited, then the data file itself
|
||||
is updated, and that means I am storing that entire amount of data in memory in this application,
|
||||
is that terrible? No, not really, it's not going to be a lot of things, maybe it won't scale well,
|
||||
perhaps at one point I will have a thousand items to do, wow, that would be absolutely terrible,
|
||||
shame on me for not getting that done, done. Anyway, that is currently where the application stands,
|
||||
what is next to do, the destroy part of crud in the API, and after that, really it's move on
|
||||
to the user interface. Because there is currently no interface for me to interact with the API,
|
||||
I have been using an add-on to Firefox called RESTID, R-E-S-T-E-D, that sends commands I can
|
||||
open the interface of the RESTID add-on, and say, oh, I'm going to make a JSON payload and send
|
||||
it to this API end point, and I will see right away whether or not I get a response of 200,
|
||||
and that response will also include the full JSON representation of what the data is like
|
||||
for the application. Basically, everything in the stored JSON file gets returned,
|
||||
any time an item is updated or added or a category is updated or added, sorry, a collection,
|
||||
not a category. Again, I should have just called them groups. Perhaps I will refactor everything
|
||||
after this recording has ended to change collections to groups, because if I don't keep it simple,
|
||||
then it is going to be difficult for me to explain what I am doing, and I'd like to keep
|
||||
things simple and easy to explain because I find that is the best way to share things,
|
||||
keeping them simple, keeping it small. Because the UI for DoDo is written in HTML JavaScript and CSS,
|
||||
or I should say, because the interface is expected to be deployed into a web browser,
|
||||
it has to be HTML JavaScript and CSS. It is going to be necessary for me to start writing JavaScript,
|
||||
so this project, although it is primarily Python, also includes JavaScript, and I am going to be
|
||||
using JavaScript to read the JSON data file and create tabs. I think I'm going to use tabs
|
||||
for the collections, and then within each collection, there will be a list of items,
|
||||
and all of that will be generated dynamically using JavaScript based on the content
|
||||
of the data.json file that represents all of the collections and items in the ToDo list.
|
||||
Well, that's all for now. I've got some sheep to attend to, some noise to make, and some code
|
||||
to hack. Have yourself an excellent day, and I will see you in the next episode.
|
||||
You have been listening to Hacker Public Radio, as Hacker Public Radio does work. Today's show was
|
||||
contributed by a HBR listener like yourself. If you ever thought of recording podcasts,
|
||||
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
|
||||
stages, today's show is released under Creative Commons, Attribution, 4.0 International License.
|
||||
Reference in New Issue
Block a user