Continuing from the previous post, we will put the credit card code in it’s own class to follow the pattern for the database interface. I’m excited about this one as one can get creative when refactoring.
Let’s start the class definition. I’ll be taking the codename of the card for the database, the string of the filepath and the company that the credit card belongs to. I currently have chase and amex
We’ve made some great progress in making an expense tracker. Now it’s time for some cleanup. Per the last post, I have removed the sub_category column from the database. I can run Group By queries to compile all the different categories and it makes it simpler without needing to regex all of that. For now, we’ll put the database in a class to clean up the file. We hacked a starting project and now need to organize it a bit now that we know it’s working.
We are back, recapping our previous post we had preprocessed an American Express CSV fjle and loaded it into DuckDB. Today we’ll do the same for Chase credit cards and I’ll share how to generate some fake data to properly demo this functionality.
I’ll bring back all the snippets I used and I put them into a function for easier use.
In my previous post I laid out the design for an expense tracker in Python. It’s time to start hacking and I’ll preprocess the CSV’s that Amex so graciously provides.
After initializing the repo with Git we’ll install the necessary packages. Always use a virtual environment! I one time broke my python version with unmanaged packages and it took a hot minute to get it back going.
One funny thing about me is that I love credit cards and no, not in the irresponsible way of racking them up. I like gathering as many points as I can for use of flights and hotels. Problem here is that now I have several credit cards amongst multiple companies. All of these companies have websites to navigate the data but it’s impractical to go through all the sites.