hpr-knowledge-base/hpr_transcripts/hpr3656.txt

Episode: 3656
Title: HPR3656: Importance of Small toy projects
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3656/hpr3656.mp3
Transcribed: 2025-10-25 02:55:24

---

This is Hacker Public Radio Episode 3656 from Monday the 8th of August 2022.
Today's show is entitled, Importance of Small Toy Projects.
It is hosted by Norrist and is about 19 minutes long.
It carries a clean flag.
The summary is, toy projects are a great way to learn
a new language and a project I did just for fun.
So I wanted to do a quick episode on toy projects
or maybe a programming exercise or project or something you want to do that
is it necessarily important or maybe not even usable about something else?
But it's something you want to do and a lot of times call them toy projects
because they're small, but a lot of times they're fun.
So it's something you want to do and something you would enjoy doing
just for the sake of working on the project.
Not necessarily, you know, a lot of times toy projects do solve a problem
but a lot of times they're more about the process and less about the problem they're actually solving.
So there's a couple podcasts that got me thinking about toy projects
and sort of why they're important.
I'm going to tell you what they are, but I'm going to tell them myself a little bit.
I've been thinking about doing this episode for a while
so that some of the, specifically this first one,
the first podcast is from the top Python.
It's an episode of the top Python podcast.
It's going to be about the time this comes out.
It's going to be over a year old.
So that's just sort of how long I've been making notes and thinking about this episode.
But anyway, if you haven't listened to the top Python podcast,
it's a really good podcast. I always have a lot of good guests.
And it's obviously about Python.
But it's a real easy listen.
I'm not a Python developer.
I'm just sort of a Python hobbyist, but I can always follow along with what they're saying.
And it's a lot of fun.
But anyway, in episode three, 27,
they had a panel of Python users.
And it was from Python professionals to other professionals who use Python on the side.
And they were just talking about how some small things they did in Python
just to sort of make their life easier.
So if you want a podcast recommendation, talk Python,
specifically episode three, 27.
And hacker public radio episode three, five, five, eight.
The host talks about learning Haskell and says something like,
don't get the quote exactly right.
But it's something like finishing a small project is better than starting a big project and not finishing it.
And also that you can't learn the code by watching videos or reading.
You need to practice.
My sort of recommendation for if you want to learn to program or if you want to pick up a new language,
if you want to pick up a new language, you probably already know this.
But one of the best ways to start is with a toy project.
So you start about it.
You start thinking about a small problem you have that you want to solve.
And then just start.
It's not going to be right at first or good at first.
But if you just start working on it and banging on it,
eventually you'll get something that works.
And then you can redo it.
And you can do it over and over again.
Every time you do it, you can think, well, I could have done that a whole better.
So you can go back and refactor bits and pieces here and there and make it a little better.
And then if you decide to take a project you've done and redo it,
you're practicing, you're learning the code, you're writing better code,
but it's also an opportunity to learn some new technologies.
So if there's a Python library or a different language or something you want to use,
that's a good opportunity to incorporate these new pieces of tech in a sort of a rewrite of a project
that you've already done.
So I'm going to tell you about a toy project of mine.
It's definitely something I've done and redone a few different times.
So I listen to a lot of podcasts, just like you probably listen to a lot of podcasts,
and I've been listening to podcasts for what I think is a long time.
It's primarily Linux and tech-related podcasts.
And I was sort of, I would think about, sometimes I would be reminded of a podcast episode
and I would go back and that either the podcast was gone or the website was gone
or the podcasts, you know, they stopped making episodes or on and on and on.
I'm sure you're familiar with the term podfated, and it's just where a podcast just ends.
Sometimes it's announced, typically when you say a podcast podfated,
that's usually, that was an unannounced sort of unintentional ending of a podcast.
But I thought it would be fun to look at the podcast that had podfated.
I just sort of see if I could track the release cadence of a bunch of different podcasts.
You know, the podcast that I was interested in, and then rate if they were podfated.
So in my head, I can decide, okay, if it's, you know, if they're a podcast that usually releases weekly
and they've missed one or two weeks, you know, they're sort of maybe they're getting a little danger
or something like that. That's the sort of things I was talking about.
And one of my original ideas was to be able to use some sort of search API
to find the podcast or the podcast, podcast that I would be interested in.
So using the Google API or something like that, search the web for RSS feeds.
So my plan to search the web didn't really pan out.
It was harder to do than I thought it would.
So then my second idea was to look at specific networks of podcasts.
So, you know, there will be a group of podcasts that we'll sort of join together into a network.
I'm sure you're all thinking of examples.
So my second idea was, okay, use Python to scrape the web pages of these networks
and then load all those RSS feeds into the database.
And then I can use the feeds that I found by scraping these network pages to determine
if the show had podpated or not.
So I was using a beautiful soup, which is a Python library for specifically for parsing HTML documents.
And it makes it really easy. You can sort of treat an HTML document.
I'm kind of like a database and just kind of step through the different tags and stuff that are in there.
From once I got the data using a beautiful soup, once I gathered all that data, I built a web page,
just sort of listing out all the different podcasts.
And then, you know, Bob, my own determination if they had podpated or not.
I would use the Genjo Timplating Engine and Bootstrap CSS.
And then based on some logic that I had written in Python, you know, if I said it,
if I determined that it hadn't podpated and everything was fine, it would be green.
And, you know, I'd have different roles for, you know, if it was a weekly podcast,
versus it was a monthly podcast or how long it had been, is it getting close?
It could be maybe able to color it as yellow.
And then finally, if it hadn't released an episode in six months,
or if it was a weekly podcast and it missed like five or six episodes or something like that,
then I could say it had podpated and then I would use the bootstrap colors to display that podcast as red.
So there were some problems with that method.
One was that I was using a beautiful soup and I'll scrape in each individual network.
Every network had different page layouts.
I had to write a custom script for every podcast network.
And that works fine until it doesn't.
So, you know, I can't control what some podcast network does with their page.
So any time it's a, you know, move something around or edit an advertisement or tweak their menus a little bit,
or whatever, it would break the script.
Sometimes it was easy to fix.
Sometimes it was hard to fix.
Sometimes I couldn't get a fix.
And sometimes I have a podcast network that I was watching for changes.
And they would change your website so much that I would just give up and stop monitoring them.
Another problem was it took a really long time to run.
And then, like I said, it was too much, it was way too much trouble.
Just trying to keep up with, you know, a few different podcasts network, all their webpage modifications.
That just became too.
So I decided I wanted to redo the project.
And really, basically, I was just going to have to start over.
And since I was starting over, I thought to myself, well, you know, now would be a great time to, you know, simplify it.
And also maybe learn some new tech.
So one of the things, one of the processes I wanted to learn is test driven development.
And I'm not, I'm not necessarily advocating for or against it.
But I at least wanted to work a project using test driven development.
And just a real quick overview of what that means is, you know, whenever you write code, you can have a test to make sure that test is, that code is working correctly.
So when test driven development, before you can write the code, you write the test.
And then, you know, you write your test, you write your code, and you work on it until the test passes, and then you write another test.
And then you write the code for that, and you work on it until the test passes.
And it kind of forces you to, you have to write your code a little differently.
And you have to think about your code a little differently.
And it's, you know, having code that's well tested, you know, one, it probably makes you write better code.
But it also, one of the primary reasons I like doing it is, I don't consider myself a very good developer.
So when I, if I have a project and I need to make some changes to it, I'm always scared to do it.
I'm a little nervous about doing it.
But if I have a, because if I, you know, if I have something that's working, that's always better than something that isn't working.
You know what I mean?
So having test, having a well developed test suite, sort of gave me the confidence to make a bunch of changes.
Because I could always, could make a small change, run the test, make another small change, and run the test.
And as long as my tests were working, then I knew I was going to be okay.
So another big change I wanted to make to the project is I just wanted one script.
Right? I wanted to simplify things that it won't, you know, one script for this network and one script for this network.
Trying to do it as simple as possible.
And then I also wanted to, something I hadn't done before is the embedded audio players.
I wanted to be sure that, you know, whenever I finally built HTML, there would be, you know, the ability to play podcasts from the web page.
So one thing I decided to do was instead of, you know, scraping a specific podcast network.
Or trying to search for the, search the internet for our sets feeds.
I just said, hey, there's curated lists out there that already have where people have put together a list of their Linux podcast or whatever.
So I said, I'm going to start with these lists.
I'm just going to, instead of making a custom scraper for that page, I'm just going to use, I'm still going to use a beautiful suite,
but all I'm going to do is find all the links on there.
And then I'm going to take off just every link I can find and test it.
Is it RSS feed or not?
Then if it is, throw that into the database to use later.
So instead of having a complex web scraper, I just throw everything I can add a RSS feed parser.
If it could parse it, great.
And if it can't, just throw it away at the garbage.
So the three places that I'm currently getting podcasts from are the Ubuntu Wiki.
It's got a podcast page.
Ubuntu Wiki has a podcast page.
The Linux link.net has got a page of just podcasts.
And then sort of a friend of HPR free, free culture podcast.org.
So those are three places for now.
I'm getting podcasts now.
I'm open to ideas about where to get more podcasts, but again, I'm trying to avoid automated lists.
So, you know, I'm specifically avoiding things like RSS podcast search sites or Apple podcast search or something like that.
But on other hand, if you know of a web page that lists just a list of or contains a list of Linux or tech related or hacker related podcast,
that would definitely be interested in finding that and adding it to this project.
Now, on a side note, I know the HPR show notes is probably a really good place to look.
So it's sort of in the back of my mind as a to do item just to figure out a way to look through all the show notes.
Because there's show notes out there that contain links to listeners, contributors, favorite podcasts.
So I think that's a really good idea just to something to having up.
So after we find all the RSS feeds, we test them and to see if they're actually actually an RSS feed and I just link to something random.
Then I've got a script called feed info that loops through all the feeds.
It uses the feed parser Python library.
And the feed parser Python library just kind of it's kind of like beautiful suit, but specifically for RSS feeds where you can sort of programmically look through an RSS feed and pull things out like titles and enclosures and things like that.
So I'll use that library after I find the RSS feeds.
I'll use the feed parser library to pull out the title.
So I'll take all that information and I'll build a web page and I'll still do a little bit of rating.
Whether or not I think the podcast has pod faded and I'll give it a color.
Regular green.
The logic isn't as complicated as it was the first time.
But there's a do keep a copy of the web page up on the public internet.
I'll have a link to it in the show notes.
It's podfated.norest.exe.
It's currently running on a free tier of one of the big cloud providers.
So I can't guarantee it's going to be there forever, but as long as the free tier is free, it will definitely be there.
So I'm definitely welcome to feedback.
I'll have a link to the get lab page where I host a code for this.
I'll have that link in the show notes.
I've got a couple of bugs.
I'll be working on where sometimes I will unfortunately I'll have to exclude some podcast links.
Because there's links that look like valid RSS feeds that it turns out they're just ads.
But sometimes those excluded podcasts will still show up on the page.
And there's other little bugs here and there and the HTML.
Like I said earlier, I'm looking for more places to pull podcasts from.
I don't necessarily want a podcast search site.
I'll definitely look into using HBR show notes.
But if you know of any other pages that just list out podcasts, especially if they're Linux or hacker related.
That's something I'd like to include if you know of any.
The HBR submissions page says it doesn't allow in mind HTML.
I thought it'd be nice if I could, since it's just HTML if I could put a little code snippet of HTML into the show notes and you can see what it's like.
But instead, I'll just grab a screenshot.
I think I'll work just as well.
Well, that's it. Short episode on why I think toy projects are important.
And an example of a toy project I worked on.
I think it's a good idea for if you want to contribute an episode but you're not sure what.
Think about a project like this that you can maybe walk a street, what it is, how it works.
Yeah, I'm glad to hear about it. See you guys next time.
You have been listening to Hacker Public Radio.
Today's show was contributed by a HBR listener like yourself.
For more information, click on our contribute link to find out how easy it leads.
Hosting for HBR has been kindly provided by an honesthost.com, Internet Archive and R-Sync.net.
On the Sadois status, today's show is released on our Creative Commons Attribution 4.0 International License.