Inspiration
I like trying to see how many hops it takes to get from one person to another through podcast appearances and wanted to automate that process.
What it does
- Pulls down rss feeds of podcasts.
- Uses a set of regex rules to extract guest appearances from the epsiode descriptions and titles.
- Adds this information to a sql database.
- Generates a graph using the sql database.
- Renders that graph using a popular JS library
How we built it
Reworked the rss feed code of anteneaPod a popular open source "podcatcher" for android. Used mariaDB because it's a popular choice to build sqlDBs for containers. Used sqlx(a rust lib) for building queiries and generating the JSON object that gets passed to a js library for rendering.
I got to expand on a project I did this summer where I learned how to get forgejo(a selfhosted version of github) to use runners(a way of running a bit of code whenever a condition inside of a repo is met) when forgejo is running in kubernetes and not docker(this is shockingly difficult because the only out of the box runners are built to be run on top of docker-in-docker and there is no documentation for using a runner with containerd at all).
This means I can now. Update my project and push it to my local repo. Have it run tests and build a new compiled version of my binaries. And then when I update my server have my front end container pull down the updated container along with other updates which lets me sync up working on my homelab and not have to worry about compiling breaking things.
Challenges we ran into
Don't underestimate the time it takes to build a working sql DB before you can test it(the relationship between rss both needing a decently complete draft of the sql table before I could start using it and being the thing that populates the sql tables was annoyingly slow)
Accomplishments that we're proud of
Mostly the build process.
What we learned
What's next for ReReMap Podcasts
A lot more filters, a front end admin page behind both an auth layer and an internal url because I really don't like the amount of attack surface something with this many moving layers provides as is but the interface is in and of itself a good exercise(a lot of the current api for taking in this information was built to be hooked into a front end and instead takes that information from a set of config files)
Log in or sign up for Devpost to join the conversation.