I finally “finished” my first major Python application the other day. It’s an RSS reader you can use to parse large lists of RSS feeds, filter for keywords, and save the results to an HTML file for viewing in a browser.

After spending easily a month building a console-based text command user interface for this thing, it just dawned on me, “I bet there’s already a module for this.” Yep, Cmd. So two things about that.

First, it’s a great example of a major failure for Google and a major success for ChatGPT. Initially, I thought what I needed was a “command line interface,” so I did some extensive googling for that and all I came up with was stuff like argparse, which allows you to run Python programs from the command line with custom arguments (home:~$ python3 myscript.py [my_command]). Not finding anything useful, I went on to build what I actually needed, which is a “line-oriented command interpreter.”

The problem with Google is it’s hard to find things when you can describe them, but don’t know what they’re called, especially in technical fields with very specific jargon. However, once I had my epiphany that this thing probably already exists somewhere, I was able to describe what I wanted to do to ChatGPT and it immediately informed me of the very nifty Cmd class.

Second, I’m not mad that I spent a month building a thing that already exists. Really. I learned so much going through the absurd process of building my own line-oriented command interpreter:

• Loops, baby, wow do I know some loops. Nested loops, infinite loops, breaking a loop, etc. For, while, you name it. Loops are my jam;
• If-else logic, my brain is mashed into a horrible, spidery decision tree. And by extension, boolean logic. Fucking hell, that was trial by fire. For example, I did not know None evaluates to False because in Python, it is “falsy.” I spent way too many hours trying to debug this, but now I will never forget it;
• I learned some Pytest and wrote a ton of unit tests for my command interpreter. I’m not going to say I’m good at writing unit tests yet, because I’m not, but I understand the concepts and the importance of unit testing, and I have a few tools to work with.
• I know what I want from a command interpreter. OK, I built a dumb one, but when I refactor my code to replace it with Cmd, I already know what features to look for and how I want to deploy it.

I’m going to put DonkeyFeed down for a bit now. I have to finish up some actual classes (SQL lol) for a degree I’m working on as the term comes to an end, and I have a couple other Python projects I want to pursue.

When I pick it up again, yeah, I’ll probably refactor the user interface to make it more robust and stable, with better error handling and help functions. And then I need to find a better way to package it (yikes) for distribution.

I guess the main thing I’m learning as I shelve this one for a bit is you never really finish a piece of software, you just kind of get it to a point where it’s not completely broken. Maybe you’ll have time to fix it more later!

https://www.peterkrupa.lol/2024/03/28/all-done-now-redo-it/

#Cmd #DonkeyFeed #Pytest #Python

I just finished my first Python app, so of course now I have to re-write it. The app is called DonkeyFeed, it’s a simple little dingus that is supposed to filter RSS feeds for certain keywords: Users save a list of RSS feed links with their associated keywords, then run the searches anytime and save any results in an easy-to-read HTML file.

My original idea was to use a GUI, but then I figured out that Tkinter is janky as hell and pretty bad for doing anything dynamic. So I switched to a command line user interface, and that went pretty OK! I’ve actually got a working product now that works.

But now I’m realizing I designed the user interface as rigid if-then flowchart of options, when what I really should be doing is an input() loop where users can enter commands with arguments to run, add, remove, or modify filters right from the cursor, instead of poking around with menu options.

Fortunately, I focused this project on using a class-based structure, with all the moving parts put into separate objects. There’s a class for handling the .JSON file with the RSS roster, a class for parsing the RSS feeds, a class for handling configurations, a class for the user menus, etc., all with their various associated methods. So changing the UI won’t mean untangling a bunch of stuff, more like reassembling existing parts into different loops and logic.

In general, I’m starting to feel like that’s what most of coding is: take a thing and plug it into, get it to talk to, or wrap it in another thing. You build your code as a series of things that can be made to work with other things, then take it home, throw it in a pot, add some broth, a potato… baby you got a stew going! Eh, I digress.

https://www.peterkrupa.lol/2024/02/13/done-not-done/

#DonkeyFeed #Python

I’m working on coding a desktop RSS reader with a GUI and the process is going like this: (1) design a feature, (2) work on the feature on one end, (3) find out it doesn’t work or I need to learn some new library to make it work on the other end, (4) mostly finish the feature but now I have to completely change the other end, (5) also, I’ve thought about it more and changed the parameters for the features I want, so (6) start over at (1).

It’s frustrating, but I realized I’m not just learning coding with this process, I’m learning design and project management, and even though I am the client, the designer, the developer, and the project manager, I’m still having communication issues haha lol lmao. OK, but I have been learning-by-doing and some of the early lessons are as follows:1

• Define the features you want from the beginning. I imagine this is kind of a moving target in many cases depending on the client, but as much as possible, I should nail down the stuff that is nail-down-able.
• Do the back end first. Break the work down into as many pieces (classes/methods) as possible that return discrete objects that can be manipulated and used in whatever way the front-end designer (future me) decides.
• GUIs suck, use a browser if you need to display a lot of content. Tkinter has been really interesting and I’ve enjoyed the learning process, but using it to display articles for reading is a terrible idea. The GUI should be used for interacting with the functions in my program and getting user input, and that’s it.

Attending to the first bullet point on my little list here, and in response to some comments from a friend, I’m going to pivot (!!) away from a desktop RSS feed reader and toward a desktop RSS feed parser that searches for keywords and saves the entries that hit into an HTML document that can be opened in a browser for review. This means I can focus on building the logic of the parser, plus a mechanism for managing a database of saved RSS feeds and search terms. That’s probably a lot for now, so I’ll leave the front-end GUI for later, when I have everything running correctly from the terminal. OK? OK.

https://www.peterkrupa.lol/2024/01/22/team-communication-issues-and-a-pivot/

#DonkeyFeed #GUI #Python #RSS #Tkinter

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.

https://www.peterkrupa.lol/2024/01/12/parsing-an-rss-feed-and-the-risks-of-a-sycophantic-coding-assistant/

#DonkeyFeed #feedparser #LLMs #Python #RSS #Tkinter