At one point I even had it listed under my projects, but I took it down. I am kinda ashamed of it in it's current state. When I first wrote it in 2021, I was quite proud. Now all I see are bugs and half-baked implementations.
I wanted Feedie to do 2 things:
It gets the job done. It provides a list of entries that are able to be opened, and provides a thumbnail, but that's it. It doesn't do those things particularly well, the thumbnail will be placed somewhere in the top right corner (sometimes covering text), the description is so horribly formatted that it is nearly incomprehensible, The highlighting on the selected item background bugs out depending on which feed is being read, it doesn't always select the correct link if the entry has multiple, and worst of all there's no way to refresh or fetch new entries after the program launches.
It wasn't always this bad though.
When I first switched to it as my rss feed reader it was in a better state. It cached previously downloaded feeds, making load times a lot quicker. This was done with a bad version of a csv file, except using tab characters instead of any other better delimiter. Being a gung-ho 19 year old know-it-all, I thought my version would be so much simpler, being purpose built for the application. It, of course, was not. It actually was quite problematic, each time the description was read from the cache, a leading "b'" was added. This was because instead of figuring out how to properly decode a byte array, I just casted it to be a string, giving the debugging view representation of it. It was always one of those "I'll go back and fix it later" type issues.
Inevitably some change in python broke my horrible caching scheme.
I opened the dusty code files again and couldn't tell what the hell was going on. The amount of coupling made the modules I had separated the project into purely nominal. After an hour of trying to find where the issue even was, I decided to cut my losses and just remove the caching functionality all together. This would buy me some time until the eventual rewrite.
The point at which I stopped the original development was not my intended final destination. I had wanted to give it some polish, make things a bit neater and squash the bugs. However, once I finally got it to it's minimal working state, I completely stopped developing it. The code was bad. It was the best I could do at the time, but it was bad. How was it bad?
Let me tell you:
If you have taken a introductory computer science class sometime in the past decade and a half (maybe before that too), the language they started you with was likely Java. Java is the epitome of Object Oriented Programming, for better or worse, everything is an object.
This means for a student programmer, every assignment starts with making a handful of classes.
So that's exactly what I did for Feedie. While not strictly necessary because Python is not Java and everything need not be an object, it's also not a bad place to start. What I did wrong was trying to cram all the functionality into those few objects I had already made. This resulted in one object in particular having its thumb in far too many pies: Feed Folders. It's responsible for both grouping feeds into categories for the GUI (think tags in every other rss feed reader), as well as constructing the feed and entry objects from cache, fetching new data during feed refreshes, and merging the two intelligently. It really should have been 2 separate objects, a "CacheManager" object of sorts, and a FeedFolder. Except I should have done what everybody else does and used tags because it is not possible to have a feed in 2 categories.
Whenever I got in the mood to work on the project, I wanted to implement a new feature. I'd tirelessly type away until I got something working, but then a problem would appear. Whether it be the aforementioned caching problem, the program being unusable while there was a running program, or a myriad of other issues, I just kept saying "I'll fix it later" and that later date never came. It's fun to make something work, it's less fun to iron out the edge cases where it doesn't.
As I've continued as a programmer, I've learned that hacky fixes aren't the foundation of stable programs.
Hearing others speak about their early days of development, It seems like a common pattern. You're passionate about programming and you've done a handful of smaller projects, why not just try to do everything yourself for the next one? You'll definitely make something better that way.
HA!!
Of course I relented fairly early on, but that attitude of thinking I knew better stuck with me the whole way through. I could've taken heed of the writing on the walls when things didn't work the way I expected, but I decided to trudge forth.
A couple years later I felt ready for the rewrite. I had a half dozen more programming classes and a new language under my belt. I was going to rewrite it in C++!!
Oh C++, what a language. I don't hate it, but it's so...
Old? No C is older and it doesn't come with the same pangs.
Ruled by committee, that's it.
It's like 5 people had their own good ideas and crammed them into the same language, without much thought in how it would all work together.
Yet the challenge intrigued me, so I pushed forward. I worked for a week to get the rss feed data into an object I could work with. That hubris was still somewhat around because I decided to write my own rss parser this time around. If I remember correctly, the cursory run-throughs of each available one didn't sit right with me. With the help of TinyXML2, I was able to get basic elements out of Atom and rss feeds like the author and links. However this was a lot more taxing work, spending hours chasing segmentation faults and coming out each session with so little to show for. After that week I probably touched the project a half dozen more times before accepting it was dead and moving onto other things.
Last December I was bored and alone. I needed to put my energy into something and decided to revive the dead project. This time I was making progress, little by little. I had forgotten the faulty reasoning that lead me to writing my own parser, remembering it as being the only reasonable option. Still, I stuck with it and was able to parse the more complex elements, ones in enclosures and handling dates. I got into a rhythm of working on it little by little, but in the back of my mind I knew my heart wasn't in it. I knew given some time I would be knocked out of that rhythm and the project would fall to the wayside again.
I started working on the Step, and all enthusiasm for the project died again.
Over the summer I wanted to learn a new language. I tried Rust and really didn't care for it. I liked zig but felt weary starting anything with it because of the lacking libraries. Then I remembered how much Roomie's dad bugged me about trying Go, so I did.
I FUCKING LOVE GO
With the exception of the syntax of enums, I struggle to find anything to complain about in the language. Great syntax, great standard library, great build system, everything is great.
A few weeks back I was staring at the nearly half-decade old rotting mess that was Feedie's first iteration and knew what I needed to do.
And so I did.
I remembered where I had slipped before, I learned my lessons and changed my approach. When something wasn't working I kept at it, though the challenges were far easier with an improved language. I broke it up into a server and client, another thing I should have done from the beginning.
I regularly check my email, If I don't respond quickly, send me a poke:
jasco.website@pm.me