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

242
hpr_transcripts/hpr3773.txt Normal file
View File

@@ -0,0 +1,242 @@
Episode: 3773
Title: HPR3773: My Public Speaking Rules
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3773/hpr3773.mp3
Transcribed: 2025-10-25 05:13:02
---
This is Hacker Public Radio Episode 3773 for Wednesday the 18th of January 2023.
Today's show is entitled, My Public Speaking Rules.
It is hosted by Mike Ray and is about 18 minutes long.
It carries an explicit flag.
The summary is.
Some tips on public speaking for technical talks or lectures.
Hello and welcome to Hacker Public Radio.
My name is Mike Ray.
Hacker Public Radio is a crowdsourced podcast where you out there and me provide
the soundbites, the recordings which are played published every weekday, Monday to Friday.
So if you want to make a contribution, go to HackerPublicRadio.org to find out why.
It's gone 9 o'clock on Christmas Day.
It's been a noisy day.
Unlike yesterday when I recorded the talk about me, but a mine-off phenomenon.
I'm not one third drunk after a few bottles of beer, but it's been a noisy day.
My sister has now gone to work, so I'm alone in this big old farmhouse now.
And my niece has been here today for Christmas dinner, I've gone home with our letlands.
It's been noisy chaos, but I like to hear the squeals and delights of the letlands.
As they do things like trying to run over Uncle Michael's feet with their radio control cars, etc.
Very good fun.
Anyway, today I thought I would give you my view on the rules of public speaking.
Now public speaking for many people is a traumatic thing, whether it be recording a podcast like this
or giving a technical talk to a room full of people.
Perhaps that a Linux Fest or Linux conference of some kind.
Any other kind of conference or just giving a talk to a room full of people.
Perhaps a Linux user group or a classroom.
Or the other variety of public speaking.
Perhaps being the best man at somebody's wedding.
Or after dinner speaking, etc.
I highlighted in there two different kinds of public speaking really.
One is technical talks and lectures.
The other is the kind of casual or not casual.
But the other kind is what I touched on being a best man or after dinner speaking.
I've never seen myself as a raconter after dinner speaker.
But I have been best man at several weddings.
That demands a speech, of course, traditionally in UK anyway.
The rules I'm going to outline here don't really cover that kind of public speaking.
It's more the technical talk or lecture type of speaking that I'm talking about.
So what are my rules of public speaking?
Oh, I should tell you about my own experience of public speaking.
I've been doing it for a long, long time.
Since probably way back in the early 80s, I was fully sighted at that point.
I'm now totally blind as a lot of people will remember.
It's never really held any terror for me, especially now that I can't see.
Because I can't see what people are thinking.
I can't see a sea of eyes in front of me, which is what a lot of people find.
It's a terror of public speaking.
And I've given public talks at all kinds of different levels.
In the early days, amateur radio clubs and conferences on such diverse subjects as forward scatter,
forward meteor scatter propagation, a rural propagation,
the construction of very large EHT extra-high tension power supplies
and valve amplifiers for VHF for doing things like forward scatter meteor,
reflection propagation and aurora and earth moon earth, etc.
In the days when it was a big boys thing, we needed an aerial, the size of a barn door
and an amplifier to match.
You can do it with a one-yarge and a few watts, thanks to SDR.
Then I was sort of graduated up to talks about similar sorts of subjects at radio rallies and radio conferences.
And then later at Linux user groups, classrooms,
all kinds of environments about things to do with Linux and computing.
And programming in particular.
So rules.
Rule number one, and we're going to focus on that kind of public speaking,
not only talking as best man or after dinner speaking, racon terror, etc.
I think I might have already said that.
Rule number one, do not ever begin your talk with an apology for being a bad speaker.
This is an absolutely very, very strict rule.
And then why do I say that?
Well, if the first thing you do is you stand at the front and you say,
I'm not very good at this, well effectively, you might say,
I'm accustomed as I am to public speaking or something along those lines.
If you do that, you immediately plant in the minds of the people in front of you
that you're not very good at what you're doing.
And that they can have to sit through listening to a bumbling idiot talking about something
that he might not know very much about.
Because if you apologize for not being very good at public speaking,
you also immediately plant in their mind the fact that you might not be very good
or particularly strong authority on the subject you're about to talk about.
Rule number two, this is a three-part rule.
And this was first given to me many years ago by a member of a radio club
who was a retired lecturer from the London School of Economics.
And he said that any lecture or technical talk,
or any kind of talk we are in parting information,
should be divided into three parts.
And in very brief summary, these three parts are,
tell them what it is you're going to tell them,
tell them, and then summarize what it is you just told them.
So let's go over those three parts in a bit more detail.
At the beginning, you explain what it is you're going to talk about,
give them some outline of the subject matter, but very brief outline.
Part two is the actual meat of the target,
which is where you give the talk,
and part of the technical knowledge,
and part three, as a kind of reinforcement practice,
you summarize what it is you just told them,
and maybe go back over a few bullet points of what it is you just talked about.
And here is rule number three.
Always remember that the people out there in the audience wanted to be there.
If you're at some kind of conference or something,
chances are they had alternative venues, alternative streams, talks,
etc., they could have gone to,
but they specifically wanted to hear you talk.
So there is going to be little or no hostility in the room.
Well, there might be one or two very board partners,
but in the main, everybody that is there wanted to be there,
wanted to listen to what it is you have to say.
There will be a lot of empathy out there in the room.
We're not all narcissists like Donald Trump.
Sometimes we do have actually have empathy and want people to do well,
and they will be invested in you.
So don't assume that there is any hostility,
because there is probably not, well, almost definitely not.
Rule number four is don't rush.
If you're nervous, the tendency is to hurry and to rush along
and get towards the end as quickly as you possibly can.
Don't do that.
The main reason I say that is because if you become gabbled or garbled,
then the effectiveness of imparting what it is you want to say is diminished.
And also, it's a perilous feedback loop,
because the faster you go or the faster you try to go,
the more flustered you might become and the more flustered you become,
the more gabbled the message.
So try not to rush, pace yourself.
If you've been given a particular time slot in which to impart the information
you want to put across, then try to fill that slot,
but don't rush because you may find that you end
a long way before the end.
Obviously it's always a good idea to leave time before the end for any questions.
If that's the kind of venue you're at, but strictly do not rush
and do not become chaotic.
Real number five, do not be afraid of silence.
Don't be scared to leave pauses, not too long perhaps,
but pauses will provide you with a way of catching your breath,
consolidating your thoughts, organising your notes,
making a mental note of where you are in your talk,
whether you may be 30% of the way through, 60% of the way through,
whether you've forgotten anything, but very importantly,
don't be afraid of silence.
Real number six, don't be afraid of the kind of thing
you might call verbal ticks like ums and ahs.
Keep them to a minimum if you possibly can.
Silence is better than filling gaps while you gather your thoughts
with verbal ticks, etc.
So don't be scared of those kind of verbal ticks,
but try to keep them to an absolute minimum if you can.
Silence is better than unnecessary noise.
Real number seven is a dynamic rule really.
It depends largely on a quite complex number of factors.
What kind of talk it is, what kind of venue,
what kind of audience, the mode in the room,
which you will probably be able to gauge.
The seriousness of the subject, but the rule is,
keep humour to a minimum.
Now obviously this does not apply to the kind of public speaking
I was talking about, which falls under the category of after dinner speaking,
racon tour, a best man speech, a wedding,
that's, you know, being a best man is all about humour,
it's all about saying embarrassing things about the bridegroom, etc.
And I'm aware at this point that I'm talking to the world possibly,
but certainly in the UK, in the Western English-speaking world,
I guess, probably the same on the other side of the pond.
Being a best man is all about embarrassing the bridegroom,
coming up with a few jokes maybe.
And then there's a formalised structure to it, you know,
thanking the bridegroom, etc.
But in technical talks, serious talks and lectures,
keep the humour to an absolute minimum.
Don't let it pervade the whole thing,
because it will detract from the main function,
the main focus of the talk, which is the imparting of technical information.
My final rule, which is not really a rule,
it's just a statement, you don't need to pick out one particular audience member
to whom, to speak individually, shall we say.
You might find it as effective for you,
and if you have a partner in the audience,
unless he or she is sitting in the front row,
in which case it's probably very ineffective,
not very good to focus on somebody that's in the front row,
probably just as well, talking to the back wall.
So pick out, if you want to, pick out something
or somebody right at the back and speak to them,
but you don't have to do that.
If you let your eyes wander around the room,
well, you can, I can't.
But in that way, if you look at everybody
and you take in everybody individually,
one at a time, as you wander around the room,
then you can gauge the mood, engage the hell there
or receiving a talk, but don't let that body
you stay focused on doing what you came to do.
Don't allow any visual feedback from the audience
to upset you in your stride.
Just carry on at the sensible pace
that you have adopted.
So there we go.
I'm trying to think of as anything else I should add.
But as I said, I think at the beginning,
public speaking, to a lot of people,
is a very traumatic thing.
In fact, I think it's a sort of a list of the most traumatic things.
So full-surrest, getting married,
getting divorced, moving house, public speaking.
I think all of those things would be in, what's that?
Five, top five, most stressful things that can happen to it.
Most people would list as the top five,
most stressful things that can possibly do.
But public speaking, you get used to it.
And now, making a particular focus on podcasting,
don't be nervous about doing your first one.
And Hacker Public Radio is a good place to do that,
because it is a casual thing.
The people at Hacker Public Radio and the audience don't mind
if your podcast does not have the kind of BBC professional polish.
Reminds, certainly, don't.
If you are imparting interesting information,
they will listen.
Your audio might be a bit rough,
as long as you can be heard.
And you may be inexperienced, but just do it.
So there we go, rules of public speaking,
as I see them.
I have been Mike Ray.
You have been HPR.
Thank you.
And good night.
I'm not going to go and get another bottle of beer.
You have been listening to Hacker Public Radio
at Hacker Public Radio does work.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast,
click on our contribute link to find out how easy it really is.
Hosting for HPR 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.