Let’s start of with this…How do you pronounce Amiibo?
Ok, now that we are done with that, let’s move to the project.
This project was a Ruby CLI Project or Ruby Command Line Interface Project in which I would have to scrape data from a website or pull the data from a JSON of an API. Here is the API for reference — https://www.amiiboapi.com/.
We can start with the api_manager.rb class or APIManager class. This portion of the project is the shortest of all the classes but the the most important in my opinion. It’s the literal back bone of all the data coming into the the other classes and application itself. The rest of the classes (amiibo.rb & cli.rb) manipulate the data coming in from the APIManager. If the APIManager isn’t importing that data correctly then the classes will not work as designed. It’s like an onion, it has layers.
In the api_manager, I created a separate instance variable to contain the “BASE_URL” of the API JSON. The rest is handled by the gem HTTParty. I take the url and then I add on the correct string I want of the API JSON that would provide the results I want. I used “amiibo” as that imports ALL the data of the API and I found it to be easier to manipulate the data I wanted for the CLI by just using the key/value pairs in the JSON that I wanted instead of have having several different imports.
Next I have the amiibo.rb class or the Amiibo class. I designed this class primarily to create the Amiibo objects and store them into the class array to easily use them in other classes if/when they were created like the CLI class itself. The @@all variable is a class variable. The scope in which is used for the entire class. So it can be called in multiple instance methods throughout the class when you are needing to use the array of objects that has been created and stored by self.all and save methods. The initialize method and create method work together by first instantiating an amiibo object and then creating those objects to be used at a later date and stored into the @@all array for manipulation and use. Why do I need to do this? Well, I have the data coming in from the APIManager and that is GREAT, but where is it going? No where. When it’s called, it just shows up, displays, and disappears in the background. By instantiating the object, creating it, then storing it. I can use it later for different things I want. However, I need classes or methods to utilize those objects and methods. The create method can’t do anything without being called and I need something to call it, create, and manipulate to what I want.
That’s where the CLI class comes in. Many things are going on with this class, first I started with just a simple method called “start”. This is simply the method that is called when running the application and it runs all the other necessary methods to make it interactive. I have several instructional methods that put out text and instructions to help out with navigating this application. An rather important method is the “gather_amiibos” method. This is what calls both the get_amiibo method from the APIManager class and the create method from the Amiibo class. It utilizes name-spacing to inherit and utilize the methods from other classes. Without the name-spacing, those classes’ scopes are only within itself and by using inheritance and name-spacing it allows us to use those methods in other classes as long as the class is called correctly i.e. Amiiboproject::APIManager.
I think I need to take a step back and explain that AmiiboProject is a module and helps us interact with environment.rb. The environment.rb file includes all of our require and require_relatives to import and inherit the other classes, and gems that we use through out the project. It helps us seamlessly call each class without explicitly having require/require_relative in each class that is necessary. That can get messy and by putting it all in one file and then just using name-spacing to call those classes that can clean up our code and also decreased muddled code or less complicate code.
Now back to the CLI class, and since we have gather_all of our Amiibos now we can search for the ones we want! There are several methods that select lists of different types of categories or keys of the Amiibo. I used keys as my “categories” and what I wanted to search and output. The cleanest solution I liked was using the character names, their Amiibo secondary names, what game series they came from, what Amiibo series they came from, and lastly what type of Amiibo they were. I didn’t realize that the Amiibos were just figures so I thought anyone using this CLI would want to know what kind of Amiibo this was if they decided to collect them. The CLI is interactive because of the “browse_amiibos” method. It creates a searchable loop with and calls other methods within the class to present the data the person selected. It also uses validation methods to ensure the correct input is being put in, and then finally it exits the application with the correct input.
All in all, this was a fascinating project, I had a really hard time starting the project. However, when I got a good handle on how this worked and sat down and planned it out I was able to pull this off. I had like-minded friends of the cohort give it a look over and give me suggestions of what they would add, then I had my cohort lead give his suggestions, and finally I had non-programmers/regular users like my daughter look it over and ask what she would like to have in something like this if she was using. With all of that feedback, I put this together. It was a fun and eye opening experience.