I set out to build my first application in Ruby this month. When I began to code, the blank slate of an empty command line seemed like an insurmountable obstacle. Questions dominated my internal monologue, and I found myself bouncing from idea to idea. I wasn’t able to nail down a plan until I could define the largest constraint, which was the integration of data through scraping or using an application programming interface (API). With the help of some friends, I found some great directories for free APIs. I have included my favorite free API directories below for those of you on a similar journey.

https://github.com/public-apis/public-apis

https://any-api.com/

Once I had an API in hand, I was able to begin designing the application in my head. I landed on a command line interface (CLI) application that would provide users with recipes and a shopping list based on an indicated preference. Before coming to this conclusion, I was in a constant cycle of dreaming — facing reality — dreaming — facing reality, which reminded me of a project that I took on last summer.

I am an aspiring software engineer (not a carpenter), but I chose to build a fence and a shed in my backyard with the help of my wife. I began with elaborate ideas, but after a few trips to the hardware store, and by a few I mean about twenty, I found plenty of obstacles. I realized that lumber is not sold in certain lengths, and my Corolla wasn’t going to be the right vehicle for transporting concrete and wood. Material cost, permitting hurdles, and the availability of material constrained my ideas and I was forced to design with those restrictions in mind. The cycle of dreaming and facing reality was exactly the same then as it is now. I say all of this to point out the valuable lesson that was reaffirmed during this project.

“Good design comes from an understanding of the constraints at hand. Creativity is the process of finding unique and elegant ways around those constraints.”

Okay, so my ideas weren’t all that elegant, but I threw a few tricks into my code. One of the more complex tricks was integrating an API into my application. For those of you scrolling through this blog to get to the code example, this one’s for you:

From API to a hash that you can work with:

Here is a sample of the JSON file (that’s JavaScript object notation) on my API.

By visiting https://www.themealdb.com/api/json/v1/1/lookup.php?i=52772, you can find the full version

How to get JSON data into ruby using HTTParty:

1. Require the HTTParty Gem in your environment file.
2. Use the syntax: HTTParty.get(‘https://www.themealdb.com/api/json/v1/1/lookup.php?i=52772’) to get a hash with multiple hashes and arrays embedded:
3. Use standard hash and array parsing techniques to sift through the data until you get what you want. For me, that meant iterating over specific parts of the data to return keys and values that matched the keyword argument that I passed into the iterator. Pick your poison here, there are a thousand ways to skin a JSON hash.

I can already see the multitude of applications for this technique. Any data in JSON form is available, and I can see why some API providers charge for that kind of access. Unless you have reporters on the ground, you can’t build an app without an API.

Anyone who has attempted to build an application can attest to the fact that ‘bugs’ occasionally find their way into our code. I had one that took me three days to find and had me pulling my hair out. Now, I’m sure I will regret this statement soon, but the thrill of finding a bug is starting to get fun. The longer it takes, the more rewarding it can be when you find it. This bug was interesting and very rewarding to find. Prior to finding the bug, my program would operate normally, most of the time. Occasionally, the wrong recipe would appear for no apparent reason. Further, the wrong recipe would correspond with the correct recipe for some other category. The problem, it turns out was that I was saving user choices in an array. Each time a user made a second choice, that array would be referenced as history of the first choice made. When users chose to reject a recipe and search for a second recipe, the original array was still full from the previous query. If users made more than one rejection, then the reference array was full of erroneous information and was no longer returning the proper values. I wasn’t clearing the array between uses. The takeaway, is that I didn’t understand objects well enough. I found the precise problem that objects were built to fix and in doing so, I discovered the value of objects. Objects exist so we can pass data through them rather than to them which makes them much more powerful and reusable than a hash or an array.

So I built my first application and it works. I can use an API now and I feel confident that I can integrate gems when necessary. But, I walk away from this experience feeling that I have a ton to learn about thinking in object oriented design. I think in procedural ruby and I refactor in the hopes that I am writing object-oriented conventional code. This is my challenge. Altering the way that I think so that I begin with the objects in mind will take lots of practice. I need to study well written code to wrap my mind around object orientation. It will come eventually, but for now I am proud to have taken my first step in that direction.