WEEK 5:
Anyway, so I've been trying to rack my brain on any deep insights I received on Week 5, and yes I did learn so much so fast as always, but I think it really just boiled down to two things:
1. Now that we have completed our first week of projects, boy am I damn glad we had that 4-day long pair programming exercise building a movie ratings app from start to finish. It really did give a strong backbone template to my project's data model structure and solidify my knowledge in where to even just begin.
2. I am so glad that afternoon lectures have more morphed into project time. Not just because we really do need those extra hours for working on our project because working at night at home is exponentially harder, but because I was really starting to feel the fatigue break through in the afternoon lectures. I struggled hard on two to three occasions to stay awake during afternoon lectures on Week 5 and got really frustrated at myself for it. My body and mind are just at two different paces, and the gap really started to widen on Week 5.
WEEK 6:
So thoughts on our first week of project time:
You know when your parents tell you something and you don't really believe them until it happens and you realize that they've been around longer and of course they have more wisdom so you think to yourself, "Why didn't I just believe them in the first place"?
Well yes, this is exactly what happened when I realized our cohort manager Leslie was right to tell us that everything you think will take a long time for your project most likely will not, and everything you think will be a piece of cake most likely will not. I don't know if it's a bad thing because either way you win some and you also lose some.
So in my case, here was what I thought would take a long time: 1. data modeling 2. creating requests to the Spoonacular API.
My initial data model was not hard to create, but it did go through several modifications in which every time a schema of a table is changed and I have to: drop my database, recreate the database, recreate the tables, create a dummy login account, add data to this dummy account............and my feelings can be aptly summed up by the lovely Ali Wong:
Creating requests on the other hand, was done in just a pinch. I thought it would take me ages to fill in the key-value pairs of a GET request but as it turns out the Python requests library had me going like:
Who knew making requests could be this easy? Now, I know this is because the Spoonacular API is all nicely laid out and some of my cohortmates definitely did not have this experience with getting their data, so I got really lucky with what my project needed in terms of data and the available options of APIs that would cater to my project.
On the other spectrum of things, what I thought would be easy, however, sadly was anything but. On the second day of projects I made my first successfully GET request and had to do everything in my power not to scream with joy at seeing the JSON file print in my terminal. I thought this was it! But noo, the joy was fleeting. Not soon after I was making these requests and getting responses was I elbows deep in sorting through deeply, deeply nested data. Dictionaries nested in lists nested in dictionaries nested in lists nested in youknowhowitgoes. Again, not an entirely unsolvable problem, just tedious.
So when I was finally able to parse into the nests and retrieve what I needed, I came to the realization that my "be all end all" endpoint was not doing its job correctly. To give some context, in a nutshell my app is about finding recipes. Recipes have ingredients. You can tell by the title of some recipes the immediate ingredients you will need. For example, a Grilled Steak with Mushrooms and Gravy will no doubt have steak and mushrooms as key ingredients. It will never, for instance, only require garlic as its one and only ingredient, which is what the Spoonacular data, and hence, my app was returning.
I was almost at the brink of being all, "Screw this!" and telling the world, this data is telling you that you can cook a steak with mushroom meal with just garlic?! Then WHY YES, THAT IS WHAT YOU WILL HAVE TO DO BECAUSE DATA DON'T LIE. But then the logical, chef-y side of me decided to wade through the kitchen fire and test out another endpoint in the API to see what it can get me.
Long story short, I found a roundabout solution to my problem, was able to recycle at least a good chunk of my first nested-data-retrieval code for this second endpoint, and all is good in the world for now.....until I break my code once again by trying to add more features and fix more bugs.
Sometimes, I feel like I'm just slapping a scotch tape on my broken code as a [temporary] solution to see if it will stick. I'm not sure if what I've fixed will dismantle and come to haunt me later down the road or if it's even a conventional way to solve an annoying bug. Only time (and my mentors) will tell.
Here we go.
No comments:
Post a Comment