CLI Project for Flatiron School

Module 1 Project

As I have been working these past two months through the Flatiron Software Engineering program, I barely had time to consider anything else aside from the daily labs and instruction I was receiving. It seemed like everything was about getting a lab to run properly so there were no failures. That took trying to decipher what was being asked of me (which sometimes wasn't very clear).

As I have approached my Module 1 project, things changed when I was writing code. I was solving my own problems and it made me feel different about my code. It gave me the freedom to solve problems in my way, not necessarily the way a lab was asking me to. It was a good feeling.

Project Idea

When I was considering what I should do for my project I went through several ideas. I was watching videos showing projects being made and I was reading ideas about what a project might entail. The idea that I settled on is a Mad Lib Creator & Dictionary.

In my mind, this seemed like a fun idea but one that would challenge my limited coding knowledge.

Big Lesson

The first challenge I had to overcome was just getting started. The blank screen can be very intimidating. One thing that helped me was a video from Avi Flombaum, one of Flatiron's founders. In it he described how to create a Ruby Gem. In that video he said we wanted to "write the code I wish I had." He said this many times and I took that to heart.

I started with the file I wanted people to use to run my CLI program. ./bin/madlib started very basic with puts "Hello World".

From there I stepped through each part of the program and created things as I needed. I was always able to test things as I went because I started with the first thing a user would use. In this way my framework for my program was built from the ground up. It was able to support where I wanted to eventually get to with my program because I laid the groundwork for it in the beginning.

Overview

My program ended up with 5 classes of objects CLI, API, and a class for each of my Mad Libs. Each class was responsible for a different portion of my program. The CLI class is the menu that guides the user around my program. The API class was how my program interacted with the dictionary API that I used to find and validate words and the 3 Mad Lib classes are the individual Mad Libs that were created for users to interact with.

Other Big Lesson

The other big issue that I had to work through came when I was trying to interpret the data I was receiving from my API. The API was helpful in that it gave me Ruby code to help create my connection.

url = URI("https://wordsapiv1.p.rapidapi.com/words/word)

http = Net::HTTP.new(url.host, url.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE

request = Net::HTTP::Get.new(url)
request["x-rapidapi-key"] = API_KEY
request["x-rapidapi-host"] = 'wordsapiv1.p.rapidapi.com'

response = http.request(request)
puts response.read_body

The puts response.read_body looked like a hash but wouldn't work like a hash. It didn't click until I was looking through some notes and remembered that the API data came in as JSON and needed to be parsed by Ruby. Once that clicked, working with my API became much easier. Another big help with that was the Ruby gem Awesome Print. Making my objects more readable was a big step towards seeing the data that I needed to pull out from my API calls.

Favorite Feature

One of my favorite features of my program involves a validation I created for the words that users can type into the Mad Libs. I wanted to make sure if the program asked the user for a noun that the word the user typed in had to be a noun. It took several steps and versions but this is the code I created.

def valid_partofspeech?
    if @word.include? " "
        false
    else
        @url_combined = URI(URL + @word + "/definitions")
        self.connection(url_combined)

        part_array = []
        if @word_hash["success"] == false
            false
        else
            word_hash["definitions"].each do |def_hash|
                def_hash.each do |var1, var2|
                    if var1 == "partOfSpeech"
                    part_array << var2
                    end
                end
            end
        end
        part_array.include?(part_of_speech)
    end
end

The first part of the validation, if @word.include? " " checked if the user had a space in the word they typed. If that happened then the validation returned false. The next step took the users input (which is created in the Mad Lib class) and made sure the API call was successful, if @word_hash["success"] == false. If the user misspelled a word or typed in gibberish the API endpoint "success" would be false. If that happened then my the validation would return false. Finally if all the user's input worked past those validations the API would look up the user's word, take out the "partOfSpeech" endpoint and put it in an array, and then check that the part of speech the the Mad Lib needed was included in the array that held all the parts of speech.

In that way, I could be sure that one of the definitions of the the user's word matched the part of speech needed by the Mad Lib.

Conclusion

This whole project ended up as a big boost to my confidence when it came to coding. Doing the labs and the classwork always made me feel like I was behind or not understanding the topics we were going over. Having completed my Module 1 project though has shown me that the lessons have sunk in and that even if I do run into a problem I can do the research and figure out what I need to do. I am grateful to my instructor and the others that have helped me through this first section of my course.