Phase_one, CLI project

Phase One in my Software engineering course at Flatiron is coming to an end. The final two weeks are scheduled for building the CLI project. To be perfectly honest I was behind with lessons and labs and project weeks started for me with two labs left undone. Luckily our cohort leader was very encouraging and point me in the right direction and that I can go back and finish those labs later on.

Missing my group lectures meant there was a lot of reading and watching to do. Search for free Apis' with no key required was a bit harder than I thought at first but again, our cohort leader helped us on this matter too. Finally, I got one that looked usable to me, Repl was the next stop. I was going through Api to see what info I could use for my project and how hard (complicated) would it be to extract the info I might need.
After the init-Repl phase, I had a list of all keys I could use in every object build from Api. Now it was time to make a story of my command-line interfaces (CLI) and this was where I made more than one misstep. Thinking that it would be too simple for my application to do "just that" I overcomplicated it which put me on a sidetrack and cost me a whole evening of work.

Story of my Cli application:

1. Welcome our new user, and offer him to take a look at our beer selection.
2. Ask the user would he/she like to know more about any beer from our list (here we would offer the option to "exit" the app).
3. If he chooses to know more about a certain beer we would confirm that we "heard" right and output a short description about the beer he desired.
4. We would offer him all other information about his/her selection if the user wishes to know more or to go back to the beer list.
5. Steps 3. and 4. could be repeated as many time user would like.
6. At the end before the user leaves our application we would output all his selections and greet him on the way out.

Application buildup

Test ground - Cli application would be built around 3 classes. Api class - would be responsible to fetch all data from open source and transform it into a usable hash.
Beer class - would receive a hash from Api class and create attributes.
Cli class - would communicate with the user by main #call method.
test.rb - the place where 3 classes would first see the "light of a day". The focus was on making it work without worrying about file communication.

Bundle install
$mkdir folder_name
=> create a new folder for your project
$cd folder_name
=> change the current working directory to folder build for your new project
$pwd
=> print Current Working Directory, just to check are you in the right one
$ bundle gem project_name
=> creates a whole structure with files and folders
=> naming your gem

bin folder - This would be the entering point of our program, this is where you will create your run file.
$touch beer_projet
=> this will create a new file in our bin folder
$ls -lah
=> list of all files (example: drwxr--r-- file_name), where we can see if it is executable or not
=>file that we made will not have "x" which means it doesn't have "executable permission".
$chmod +x beer_project
=> add "executable permission".
./bin/beer_project
line 1. #!/usr/bin/env ruby - this will tell our file in what environment he needs to run it (since there is no file extension this is needed).
line 5. the "run" file needs to "look" only at your environment file by "require_relative" it.

lib folder
Place of your environment.rb file (originally it was named beer_project.rb) and folder that will contain all our classes in separate files.

Api class
Is responsible to "fetch" data from provided url with help of httparty gem and convert it into a usable hash that will be forwarded to Beer class.

Beer class
Every time beer_hash is created in Api class it will instantiate Beer class to create a new instance with attributes provided by beer_hash.

Cli class
Creating a call method was something that gave me a lot of headaches. binding.pry was really helpful but in the end, I went back to Repl to build a skeleton for the main method. It was faster to test concepts and there was less distraction. Here I used and abused the idea of helper methods which gave me a better approach for debugging my call method.
Git
$git status => checking if we have a git already build if no then we can run:
$pwd => if we are in the right folder
$git init => create git
$git status => show us all altered files
$git add . => add all files to the staging area, where we can also go by folder name if we want to add only a specific file
$git commit -m "message" => commit files from staging area to our local git with a message of choice
Github
On my Github page, I create a new repository named "beer_project".
Back in terminal(all these commands will be offered on your Github):
$git remote and origin "github.com..."
$git branch -M main
$git push -u origin main

These were the main steps for my first CLI project after which fine-tuning came in place (resolving a few "bugs" along with typos which I am sure can be found here as well).
Anyway, for the very first time since starting the Flatiron software engineering course, I was in front of a whiteboard that needed to become a command-line interface application. It felt more than once overwhelming but going back to the lessons and videos provided by FI was big help. Our cohort leader and those open hours were great resources that helped me more than once to bring this phase and project to an end.