I don’t like the idea of a coding project that’s just you typing out what someone in a YouTube video tells you to type. That’s like doing a crossword puzzle with someone telling you what letters to put in each square. First, it’s boring. You don’t get the satisfaction of solving it on your own. Second, you can’t possibly learn much. There is no “right” way to code something, there are only better ways and worse ways, and part of learning is doing something in the stupidest way possible and then finding out first-hand why you shouldn’t do it that way.
Anyway, I’m coding this desktop RSS reader I’ll call DonkeyFeed, for no particular reason. The GitHub repository is here, and apologies in advance, I still have no fucking idea how Git works, so I hope I didn’t accidentally expose my ass. I selected a desktop RSS reader with a GUI as a project because I need one, and it seems like the kind of thing I can iterate gradually as I learn how the pieces work.
So far, that’s what is happening!
It is turning out to be a great project for working with a number of different libraries and moving parts. Using a GUI means working on a front end and user experience and learning Tkinter. For RSS parsing on the back end, I have to learn to use feedparser and figure out how to get the parts of the RSS feed that I need, put them into some kind of array, and put that array into an object to be placed in a window. Then I’ll also need to manage a database, add user-initiated functionality, put in some testing modules, and maybe even write a readme.txt, who knows.
So far, I have mostly worked on the GUI and the RSS parsing. For the former, I’m building a “Window” class with methods for all the different widgets (buttons, input fields, letterboxes, etc.), although I’m still not super clear on what the most extensible/useable way to do that will be. I’ve made more progress on the RSS parsing: I’m building a class that can be instantiated for a single RSS feed, with methods that return the separate parts of the feed so I can place them in the window how I want later.
I worked with ChatGPT quite a bit in building this part, everything from very basic debugging (I’m still occasionally forgetting parentheses lol) to back-and-forth about how some feature will work. I’m finding ChatGPT can be dangerous because it WILL GIVE YOU WHAT YOU ASK FOR. This is a known problem with LLMs, sycophancy bias. Basically, the LLM tells you want you want to hear. My coding skills are so incipient at the moment that for now, I’m mostly getting “actually”ed by ChatGPT. Like here. Ooof. Big L.
But as my queries get more sophisticated, it is happy to help me hang myself. For example, to parse an RSS feed, I built a method that uses feedparser to send the title, link, and summary of each entry to a list, and those items could then be retrieved for display. That is: three separate lists. Maybe you can see where this is going. ChatGPT was happy to assist me with this. It was later that I realized keeping three separate lists for items that need to be synched up with each other was… problematic. ChatGPT cheerfully agreed:
It’s a great reminder that coding assistants are ASSISTANTS. You have to catch this stuff, they will not stop you from showing your ass, on the contrary, they will 100% help you pull your pants down and then tell you “good job, sir!!” Indeed, note that I’m the one who suggested using a dictionary here instead. I may actually be showing my ass in a new and exciting way.
Anyway, the next thing I have to change in this code is to send the feed elements to a dictionary instead of three separate lists, and then I will be ready to test. I haven’t built any testing modules yet, but it’s on my mental list of things to do. Another functionality I need to add soon is some kind of database management, so a user can save a list of RSS feeds and query them whenever they open the program. Off to code.
Leave a Reply