Balling out with my first CLI

The first step in setting up a Cli, or any project for that matter is making sure you get your environment set up correctly. It can be the most frustrating thing in the world when you can’t get your files to communicate with each other, especially when working with OO. I found out how important a concise and organized environment folder can be the hard way. I started out without prepping my workspace with the correct file structure. This oversight jumbled up my understanding of what was happening with the ‘requires’ and ‘require_relatives’ and threw a couple hour issue in my direction. Luckily with a little help I got an organized environment folder set up and I was back on track.

The next thing that I did (and I’m super glad I did!) was familiarize myself with using ‘pry’. Up until this point I never really got the hang of using pry, I honestly probably had a 50% success rate on if my bindings were in the correct spot or even worked at all. This project forced me to get used to pry and it has made my life sooo much easier! When using an API it’s very important to know what you’re dealing with every step of the way. Being able to see the data structure after you have gotten a response body using RestClient, and then taking another look after you have parsed that information with JSON is invaluable. It’s almost like taking a shot in the dark if you don’t know what keys to call on in order to get the info you want to pull from the nested hashes. This made me realize how useful and accurate binding can be.

After using the ‘RestClient ’and ‘JSON ’ gems to get the information I wanted all I needed to do was set up an ‘.each’ loop that traversed through an array of hashes to pull out individual hashes with their own keys and values. My method to load all my data in from the API looked like this:

def self.load_all
  current_page = 0
  until current_page == 50
  page_number = "?page=#{current_page}"
  response = RestClient.get(url+page_number)
  data = JSON.parse(response.body)
  data["data"].each do |player|
*   player = Ballers.new(player)
  end
current_page += 1
end
end
end

##side note, the API I am using is not set up for high traffic, that’s why I set a 50 page cap on the load ins. Unfortunately this means my program can’t get every player : ( ###

The line where I put the ‘*’ is key to creating objects within my own files. Upon initialization, ‘Ballers.new(player)’ will do the following:

def initialize(data)
  self.first_name = data["first_name"]
  self.last_name = data["last_name"]
  self.position = data["position"]
  self.full_name = "#{self.first_name} #{self.last_name}"
  @@all << self
end

First it creates a new instance within the ‘Ballers’ class. Then it attributes the information associated with each instance’s name and position to the appropriate reader/writers I created with ‘attr_accessor’. Lastly the new player is pushed into an array with every other player, the ‘@@all’ array. The ‘@@all’ array is a class variable, meaning it can be called on by the class itself, which would be the ‘Ballers’ class. After creating a class method:

def self.all
  @@all
end

you can call on all the player objects created by ‘Ballers.all’.

From there I created methods to find the individual ‘Ballers’ instances, from here on I’ll refer to them as players, by both full name and last name.

def self.find_player_by_name(name)
  @@all.find{|player| player.full_name.upcase == name.upcase}
end

Within the ‘Ballers’ class this method works by pulling the player by the player.name value. If we wanted to find Kobe Bryant (rest in peace) for instance we would input ‘Ballers.find_player_by_name(“Kobe Bryant”)’. This would pull each player’s instance id (the ones that look like this: <DGE300095000>) compare it’s ‘.name’ with “Kobe Bryant” and return the one that matched. Now that we can search players by name and return their id’s, accessing their position is as easy as adding a ‘.position’ to the returned id.

All that’s left is deciding what you would like your CLI to do and controlling the flow to make it user friendly. I opted for making a bunch of methods that were ‘menus’ and ‘options’. My ‘menus’ methods ‘puts’ options while my ‘options’ methods takes in a user input and takes you to the next appropriate menu based on what you decide to do. That made it much easier for me to see where user inputs would take you and made controlling flow more manageable.

skabe89/ballers

Making my Cli was a great experience. The feeling of watching something you’re building grow with the more you put in is the best to me. While it was challenging at times I feel like the previous modules and my incredible cohort lead, Enoch had me more than prepared for this project. The biggest problems I had were my own oversights and incomplete planning, which will be a priority from here on out. I’m excited to learn more and continue my journey with Flatiron!