Ah, yes, we got there!! I finished the course! My estimate to finish was a little off but there is good reason for this; I redid my originally planned project around three times. The main requirements for the final project is that you need 3 functions, have unit tests per function, and take a bit more time than problem sets. With only these parameters, that leaves a wide breadth of ideas you can think of to implement. In the last year, I had a personal goal to read more, a book a month at least, and used the platform Goodreads to track what I wanted to read and when I finished books. I had wanted to use their API to create something but turns out they stopped giving out new developer keys to connect to the API back in 2020, so I had to rework my idea a little bit. I wanted to create a sort of copycat application that simulated the platform on a much smaller scale and thought it’d be humorous to call it “Average Reads,” thus began the project.
For those in the course who had already started their final project, there was mention of using a GUI (graphical user interface) toolkit called Tkinter. I did a bit of searching to see what other toolkits there were and this one seemed to fit what I needed to use. I sketched out a few designs on paper to get an idea of a layout with Tkinter and picked out a database I’ve used in the past, Google’s Firestore. For a brief version iteration, I thought I could use Google’s Library API to create a list of books, but for the sake of time and effort for what I wanted to completed, I scrapped it too.
The very basic function of this project was a CRUD (create, read, update, and delete) app where the base level functions had stayed the same through each iteration of this project. Through exhaustive Googling and searching for implementation examples and answers to connect Tkinkter functions to Firestore, the first database design consisted of three collection “lists” titled “to read”, “reading”, and “read.” Using Tkinter, running the program would open a window on my computer with entry fields for the book titles, a dropdown for which list to add it to, and be able to display the most recent list of books for each list. I did run into quite a few bugs and functionality roadblocks when trying to refresh the database lists repeatedly and deleting the book titles. The next large roadblock had cinched the switch to move away from Tkinter, and a growing impatience, was additional research how to unit test a GUI program; it’s a bit different from the functional scripts we’ve done in the past.
The next iteration of the project showed me how database design is important to review before implementation. Luckily, the documentation to connect and use Firestore is pretty straight forward, but I had still run into a couple bumps. Initially, the top level collection was the main “shelf” with three documents of “to read”,”reading”, and “read” and the title were listed as fields in these documents. Usually these fields are meant to describe the document such as name, type, and timestamp, rather than just having the book title. After reading over Firestore’s documentation a bit more and testing out the add and delete title functionality on a smaller scale, I rearranged my shelves and data in the database. Now, the three documents of “to read”,”reading” and “read” became three collections with the book titles as the documents that matched a corresponding title field that would be used to add and delete the titles.
For the next step, I had to choose another way to display the program to a user rather than a visual interface with Tkinter, and looked back on previous problem sets we had done. From a couple of the weeks, I had chosen to use command line arguments to power the program using user typed input in the terminal and command line data text formatter the library called tabulate. From the course’s problem sets, I had wanted to emulate different types of user input that may cause an error or success and try to account for a few different combinations, such as, too many arguments, too few, title casing the book title, or misspelling something0. The one part of the program that had not changed at all throughout these iterations was to download all lists and book titles to a downloadable CSV file. There was still a little bit of tweaking to do with this to specify looping of the data to format the output to the command line with tabulate was different than the output structure of the three column CSV rather than in rows.
In the end, there is much I’d like to continue to learn with Python scripting and planning out projects. It’s always good practice to make a barebones sketch of a project before diving in, but sometimes there are still things you will miss or mess up later on. This may be my preference of “style” of programming, but I find most of my first iterations are pretty ‘wordy’ and scripts are a big longer so I can break down each piece to understand what is happening or later on need to find and fix a bug. This doesn’t seem to be the “usual” style of other programmers and especially the “pythonic” way. This project specifically, I’m not sure if it was the implementation or working with Firestore, but a lot of the functions and checks were quite repetitive and seemed unnecessary, but it had to be set up in a certain way for it to work properly. Maybe someday I’ll get back to working with a GUI 😉
The very last portion of the project was new to me as well; we needed to record a walk through or screenshots where I have had minimal video recording or editing experience. I had downloaded OBS (Open Broadcasting Software) to do a screen capture and tested out a couple editors. It ended up being a video of screenshots, adding some text explanation, and put it all together with Hitfilm; a learning curve but it turned out! I won’t be posting the video here, but see below for some screenshots of the program.
