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>

hpr_transcripts/hpr2180.txt

@@ -0,0 +1,95 @@
+Episode: 2180
+Title: HPR2180: Mail to myself@myfirstemployment, Part 2 of 2
+Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2180/hpr2180.mp3
+Transcribed: 2025-10-18 15:23:40
+
+---
+
+This in HBR episode 2,180 entitled Male to Myself at My First Employment, Part 2 on 2.
+It is hosted by Clacket and in about 8 minutes long and carrying a clean flag.
+The summary is, I expand on a list of one line of advice to myself 20 years ago that I posted
+on pump.io, Part 2 on 2.
+This episode of HBR is brought to you by an honest host.com.
+At 15% discount on all shared hosting with the offer code HBR15, that's HBR15.
+Better web hosting that's honest and fair at An HonestHose.com.
+Hi everybody, this is Ken, just a special note we heard yesterday that Lord Dragonbloth has passed away.
+Clacket has sent in the following message to the mailing list and I just want to make sure that
+everybody has the opportunity to participate. Requesting Lord Dragonbloth's eulogies.
+Hi everybody, Nightwise just told me in IRC that Lord Dragonbloth, a long time friend of Hacker
+Public Radio and its many iterations and been rev well before that has lost his battle with cancer.
+Lord Dragonbloth was a good friend and it's just such a huge loss that he's gone.
+I'm going to record a few thoughts in his honour and post it as an episode but it would be cool if
+anyone else who knew Lord Dragonbloth wanted to do the same. I'm happy to collect and edit the
+recordings together and post them. I don't have a deadline but let's shoot for 14 days from now or so.
+Cheers, go go hug, I loved one, tattoo.
+And now we'll have a few moments of silence.
+So long Lordy.
+Hi, I'm Clacket and this is part two of my further elaboration of one-liner advice given
+from time traveling me to 20 years younger me, professional advice. I think we ended off with
+try it. No sorry, we ended off with there may be no good reason so I'll continue with try it.
+So the advice is try it but heat warning number one.
+And this of course means if you're in doubt if something is going to work or not or what's the
+best way to do something the best information you can get is by just doing it and then see what
+happens. Be careful though when showing your results to someone either it should be unusable
+in production I mean completely unusable or it should be more or less production ready.
+You shouldn't have to be scared of supporting it for the rest of your professional life at least
+at that company. Those who talk may also have something to say but it can take years to learn who
+these people are and what they're actually saying. When I say those who talk here it's a bit
+too straight of a translation from the original Swedish. Those who keep talking all the time
+is the intended meaning here. Those who keep talking all the time may also have something to say but
+it can take years to learn who these people are and what they're actually saying.
+So several of the layers within the software industry consist of people who go to meetings and
+present slides to other people who go to meetings and present slides and it's very easy to
+fall into the trap of believing that all these people are always talking garbage. They're not.
+A lot of them are and it seems like can be quite easy to get away with not really knowing what you're
+doing but some or even a lot of these people actually do know what they're doing and if you can
+parse enough of what they're saying and see what the technical reality behind the oh what's the name
+for that we call it a oh there's a catch your name market yes market texture that's the
+lie of an architecture that you show to the customer that's the market texture but even behind
+the market texture you can see what kind of thought has gone into this into a system existing
+system or potential system and with enough experience you can actually learn something from even
+quite shallow presentations you can suss out if there is something worth considering behind this
+stuff or not you need to be able to determine what slogans are just slogans and what slogans are
+useful labels for things actually thought through and it's not easy but if you can do it you can learn
+from from these people the good ones have a really great high level grasp of things
+and have been designing several systems on a high level and know what kind of trouble you're likely
+to run into an architect for that trouble so that the system can work in the long run
+so learn to identify these people and learn to parse what they're saying and you can learn a lot
+if you don't speak out you won't get the chance to get corrected
+don't be scared to voice your opinion or to ask questions worst thing that can happen
+someone will correct you correction worst thing that can happen is everyone ignores you
+and what may feel like the worst thing that could happen is someone corrects you
+but actually that's a good thing of course if you never learn anything and you always ask the same
+question so you ask questions that show that you haven't really understood the context that's one
+thing but you're probably smart enough to know when you're just not understanding some detail and
+when you're completely out of your depth if you're completely out of your depth then you probably
+shouldn't have gone to that meeting or been in that discussion in the first place so I think it's
+unlikely that it happens a lot if nobody sees your code you won't get the chance to correct it
+you won't get the chance to get corrected
+this is maybe even more important a really good way to learn how to program well is to read
+other people's code and an even better way to learn how to program is to write code and have
+good programmers read it and suggest improvements that's how you really
+get the craft of programming into your system and the last point finish quickly
+then improve but he'd warning number one so this is a rephrasing of
+Eric Rayman's release early release often get yourself out there
+perfection is the enemy of finishing if you're always going to
+add one more feature or remove this little quirk then you're never going to get this thing out
+there and you can't benefit from other people commenting on it maybe even just telling you maybe
+not even just telling you what should be improved but actually sending you patches
+code review is a great thing code review by thousands of people is awesome
+so get your stuff out there and benefit from the knowledge of all the people who may find it
+interesting same as with this podcast if you have something to say just say it if you're wrong
+someone else was in an episode and tell you you're wrong and then you'll learn something
+I hope that people are listening to these episodes these two episodes will provide their own
+comments or audio commentary or both so we can all learn how to become better programmers
+and how to teach others to become better programmers
+you
+you've been listening to hecka public radio at hecka public radio dot org
+we are a community podcast network that releases shows every weekday Monday through Friday
+today's show like all our shows was contributed by an hbr listener like yourself
+if you ever thought of recording a podcast then click on our contributing to find out
+how easy it really is hecka public radio was founded by the digital dog pound and the
+infonomican computer club and it's part of the binary revolution at binrev.com if you have
+comments on today's show please email the host directly leave a comment on the website or record
+a follow-up episode yourself unless otherwise stated today's show is released on the creative
+comments attribution share a light 3.0 license