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

375
hpr_transcripts/hpr0254.txt Normal file
View File

@@ -0,0 +1,375 @@
Episode: 254
Title: HPR0254: Expressive Programming Ep 5
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0254/hpr0254.mp3
Transcribed: 2025-10-07 14:54:15
---
.
Welcome to this episode of Expressive Programming, an exploration into programming as an art.
Here I'll focus on programming, design, and development as an art form, especially as a form of self-expression.
We'll look at open-source projects, the projects that I'm working on, the code that others have written,
and focus on how that reflects what we feel, what we intend, and how we impact the world.
Special thanks for all episodes go to Pack-Up of the Radio for helping me get this podcast off the ground, especially in Nigma,
and also special thanks to HotBitchArson.
The band's website can be found at HotBitchArson.com for all their wonderful, inspiring, and moving creative comments,
and projects that they've allowed me to use.
They're the cure for the encounter and call you.
Now onto today's episode of Expressive Programming.
Enjoy!
Welcome to Expressive Programming, episode 5 for December 17, 2008.
I'm drawing and crossing the line.
Coles, plans, ideals, we all have them, it's what life's all about, hopes of what to accomplish,
plans of how to get there, and then of course the unforeseen things are getting away.
This goes with life and this goes with programming.
Do research, try to determine the best language, determine the need, determine the interface, the libraries, etc., etc.
We can plan and plan and plan.
We can get lost in planning.
In fact, there are organizations that are doubly do nothing but plan, such as the W3C.
I don't think anyone there's probably implemented the CSS, but they plan it,
and that gives browser manufacturers standards to start with, except for Microsoft,
and then developers get to actually use CSS to create interfaces that are accessible,
and much more elegant intuitive than they were before.
And don't blame me if you don't get CSS, it's not that hard, it's just a different way of thinking.
And so is the difference between planning something and doing it.
You can plan, work towards perfection, try to pick a library,
read about best practices.
You can get a four-year degree, you can get an eight-year degree, you can end up becoming a research.
Follow in computer science if you want to, you can get lost in planning, and then you never do.
There's an article that I recommend everyone reads.
It's called the second half of artist ship.
It's written by Paul Graham, it's on his website, p-a-u-l-g-r-a-p-h-am.com.
He also writes one of my favorite essays called Hackers and Painters.
His is in response to Guy Kawasaki's, by now, completely famous, artist ship.
And I think he makes some much more poignant points than Guy Kawasaki does.
But they're not the points I'm making here.
The points I'm making here are avoiding getting lost in the planning.
When you start planning a new project, I'm not talking about a small script.
I'm talking about a large scale project, a game, an office suite, a group or project,
a blogging platform, a podcasting platform, audio editing, you name it, anything big.
But when you start thinking about it, it still starts with you and your thoughts.
And it's very easy to get lost in those thoughts.
Get lost in the research, get overwhelmed.
Possibly even depressed and downtrodden and never do.
And that brings into line one of my favorite Buddhist sayings.
Be not afraid of going slowly.
Be only afraid of standing still.
And my point is, it doesn't matter how lofty the goal is for the project,
where you want to take it when you eventually get there.
We all want our projects to do everything we envision, but we have to be rational.
They're not going to do it all on release candidate one.
And to those of us, or to those of you, well, to those of us who are listening who are artists
when it comes to our programs, we want it to do it all the first time out.
We want to show our entire vision, because unless we can show the masterpiece,
we don't want to show any of it.
Unfortunately, when it comes to the art of software development and design,
it's not like a painting.
You can't wait until the canvas is finished before you show the first corner.
You have to show that outline.
You have to show the first draft and the rough drafts and the rough drafts.
You don't get to wait until it's perfect before you release it.
If we did, let's be honest, none of us would ever release anything.
I have been working on numerous projects, and one of them is an online media browser
that is called Alicast.
And anyone who follows me on Twitter knows I've been working on version two for a long time.
But I've also continued tweaking version one.
And I've been tweaking version one for the last year.
And when I started version one, I never even intended on anyone seeing it.
I started out as a little tiny T-C-S-H script.
It turned into a pro script.
It turned into a PHP script.
And it's now becoming either a clutter or a sold-runner application,
which will run on the desktop.
And it's a completely different application.
The only thing that shares in common with the original website
in corresponding scripts is its name.
And I recently had to face that I had to, again, draw a line.
I had to say, I'm done touching version one.
It said it's done. I'm not doing anything more on it.
If I think of a feature one implement, then start working on the code
to make sure that that's in version two.
And we'll be.
If I find a bug, then make sure that bug doesn't show up in version two.
But I'm not allowing myself to add any more code to version one.
And that's incredibly hard to do.
Especially now with the source control and revision control systems
we have available to us.
It's so incredible attempting to create another branch
and work on perfecting this, perfect, perfecting that.
And we can quickly lose ourselves and never really see our visions come true.
So we have to draw a line and stop perfecting the old.
And say, here's where the news starts and force ourselves often
to go forward with that.
Which also brings me to a related topic involving other projects
that I've been working on, actually involving all of the projects
that I've been working on.
There are artists, new program, there are programmers,
program, and there are engineers who program.
I've noticed the engineers tend to follow to the tea.
And I'm just using engineers because I need a category.
But they tend to be one town school.
They call best practices to a tea.
They think very much inside the box.
Make sure to use a module if it's available as opposed to
even a Australian understanding what the module does.
I may not even want to know what the library or module does.
And then there's the hackers or the artists.
Where I don't want to use an engine that does this
because I don't want to know how it's done.
I don't want to wait for the library to get better
to make that feature better.
That's one of the great things about open source.
You can use an open source module or library.
And if you want to make a feature of your program better
than you guys in that library, you can improve the library,
contribute back, and then get back to your major project.
But when it gets down to it, programming is about creating
the vision that you have in your mind.
And that includes how you create it.
Access practices, advice, how to's, books, coding centers,
coding practices, coding rules.
I don't care what arrogant SOB it comes from.
I don't care how intelligent they are or how inferior you
may feel towards them.
Program your project your way.
And if someone has something negative to say about your code,
who cares?
At one point, they wrote code just as ugly.
And just as are, there are areas in development
that they create things just as hard.
I hear programmers all day long spouting off on how this code
isn't object oriented enough or doesn't follow this
or that best practice.
But if I go and look at their CSS, it's a template they grab
from someone because they can't design themselves out of a box.
Am I faulting them for that?
No, but I'm faulting them for attacking other people's code.
If someone programs a website and it looks hacked together,
tossed together, whether it's in PHP, Pearl, Python,
whether it's in buggy C, I don't care.
I'm blissfully happy to see that someone has,
perhaps the passion of programming and started to do it,
has started to make the computer do what they want for themselves.
And PHP, for example, is a community where this happens a lot in.
Because it does give you the power to do things
in a very proper object oriented and even aspect oriented.
Programming approach.
However, it also allows you to write mangled scripts of include HTML
and well, the code's not beautiful.
At least not from a purely pragmatic perspective of program.
From the perspective that someone's created something new,
put something out in the world and shared their code,
attacking it for whatever reason,
it doesn't encourage the programmer,
it doesn't improve the community,
it reflects poorly on PHP.
I see it a lot in the Python community,
and it can quite frankly disgust me.
The only place I don't see it is in the Pearl and Sea communities,
is because it's quite often embraced that there are a million ways
to do anything the right or the wrong way.
And it's seen that doing something one way is beautiful
by a group of people,
but doing it in a completely different way,
is beautiful to a different group of people.
I don't write obfuscated code,
I write very verbose code to some,
and to others, it's overly tight and overly clean,
which was a problem I was having.
When I became disabled due to my neuromuscular disease,
I lost my job as a full-time programmer,
and neededless to say when I did so,
as firing someone for being disabled would have been illegal,
because they did what they had to
to make it appear that it wasn't my disability or firing me for.
Now, I'll be the first to admit my productivity had gone
to the point where I was no longer programming at a productive level,
but it was as a result, a direct result of my disease
and what it was and has continued to do to my body,
and how it limits my abilities.
I'll admit that, yes, I was not able to professionally program
then, and as a full-time professional programmer now,
no, I'm not able to.
I can do freelance projects and open-source programming,
some days being more productive than anyone ever met.
Other days, I'm in too much pain to even write a single
if and if in a C file or a header file.
I have an idea come to mind their days when I can't even write it to do,
to remind myself to do what it is I've just thought of.
But they can't fire you for that.
So, in the process of them finding a way to fire me,
well, things were done that shouldn't have been
and I came away poorly affected.
So when I got back in open-source development,
my core focus has been trying to make sure that my programming
would stand up to anyone's scrutiny.
And that's completely impossible.
It's cliche, but you can't please everyone all the time.
And it's true.
Just with any art, Jackson Pollock,
Da Vinci, Einstein, Sylvia Plath,
there are those that will say that's not art.
The books that Darwin wrote,
which are coming up on their 200th anniversary next year.
Is there art there?
I believe so.
Read Voyager The Beagle and tell me there's not art in those words.
There's not art in what he saw.
Was he an artist?
Yes, he was many other things, but he was an artist.
Did he impress and amaze people?
Yes.
Did he do so to everyone?
No.
God knows.
Did Galileo?
No.
Did Da Vinci know?
Because mine is Torval.
No.
Deserture's thought.
No.
Can you?
Can I?
No.
There's a time when I've had to face and we all have to face.
They have to stop looking at the canvas and planning and preparing.
You have to draw the line.
You have to write the line.
Whether it starts with less than question mark or less than question mark PHP,
an argument.
I would love to hear your comments on.
Whether it starts with int main, whether it starts with int end if,
and checks for header files.
Or whether it starts with a simple hash bane and the line to the interpreter of the script.
There comes a time.
No matter what you're doing, you have to stop getting ready for it.
You have to stop making it better.
You have to stop hoping it will be perfect.
There comes a time to draw the line.
Whatever you're planning on working on.
Whatever you're perfecting and editing.
Whatever you're creating in your mind.
Stop.
Right now.
Stop creating it in your mind.
Make it travel line.
Start creating.
Start releasing.
And do it because you know what it will become, what it can become.
And those that have things to contribute will do so by giving back code.
And that by tying you, you shouldn't have programmed it this way.
You shouldn't have done it this way.
Or your program's rotten.
The code's rotten.
That isn't a feedback worth listening to.
Anyone who can see your vision of what you want your program,
your project, your artwork to be.
They'll contribute the same way you did.
By drawing a line.
This was all inspired by my decision to make very big changes
in my biggest project, my game.
I've been working with an engine called Radium.
It's a very wonderful, easy to use engine.
Use a lot of open source libraries, platform independent.
But there's a lot of stuff it doesn't do.
For example, I spent five days trying to get it character to walk animated.
Not going to happen.
I already know how to do that in STL.
Simple direct media layer.
I can do it using Pearl.
Using C.
Or using Gombus.
And Gombus is the equivalent of visual basic for Linux.
Who knows?
I may write my game using that.
I also know how to do the same using the openGL
and the STL framework for mono.
Yes, mono using C sharp.
I know how to do 3D development.
My game is still being developed using Radium.
Because as I mentioned, I can contribute back to the libraries.
Contribute to Radium itself.
Which is what I'm doing.
But I had to stop planning.
I had to stop preparing for it to be ready.
And I had to start making my game.
And so I have.
I have a menu screen with five menu entries.
The exit and the credit screen both work.
What the other three are.
I'm not going to tell you.
But they don't quite work.
I'm working on a website with a hint at the storyline.
Which is far too complex to explain in this edition of expressive programming.
But I had to draw the line and just start making the game.
And so I have.
I've also had to do the same with expressive programming.
I've been working on trying to make it exactly what I want.
And every time I attempt to, I end up with something that's completely academic, boring, and loses all of its expression.
I will be producing expressive programming with a higher level of frequency.
I will also be releasing a second podcast focused on science and the scientific development.
This will be purely a hacker public radio series.
And again, special thanks to Enigma for your continued support in expressive programming.
And everything that goes on with hacker public radio.
Including the amazing community that's revolved around it.
Special thanks to the wonderful people involved with PHP women.
And to all my friends on Twitter.
Especially the podcasters and authors.
And to all the creatives I've met.
Even the doctors who are creative.
To those whose voices have contributed to this show.
But you haven't even heard them yet.
I've been trying to perfect it.
And I had to draw the line.
It's not going to be perfect.
But episode six.
Well, like I said, I had to draw the line.
I hope all are doing well in the season of snow and ice.
Or sun and shine.
Depending on your hemisphere.
I hope you're healthy, happy.
And I hope this finds you.
Ready to draw the line.
And then step over it and do it.
Make it out of your head into your IDE.
And make it happen.
Until next time.
Happy hacking.
I hope that you've enjoyed this episode of expressive programming.
If you'd like more information about me, my projects, my podcast or anything else.
Please feel free to visit my website at ubersheetgeekcheck.com.
If you have any questions, comments or feedback.
Please feel free to email me at feedback at ubersheetgeekcheck.com.
Warning.
I'm Flaky and I suck at email.
I'm also a member of the phpwomen.org community.
So wonderful place.
Any woman involved in development, please join us there.
Also another wonderful community that I'm involved in is devchicks.com.
All the development principles are welcome.
Please come along.
And lastly, I'm a proud member of both Linux Check.com.
That's check CHIC and Linuxchicks.org.
That's CHIX.
And there you'll find opinions and topics and anything you could want.
So any woman out there, please, you're not alone.
Come join us.
Lastly, I'm on Identica, Twitter and on IRC FreeNote Server.
I add UberChick.
Feel free to hop in, say hi, find me in a room,
PM me and I'm probably blocking.
Other than that, until next time, express yourself.
You're about to be happy, happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy, happy time.
You're about to be happy, happy time.