As part of my online part-time Software engineering course at Flatiron, I created a Ruby CLI, known as Latin Roots, which was built to educate and celebrate Latin Culture.
This was my first ever coding assignment and I *was* a total novice. I’d like to think that now I am just a novice.
I’ll break down my project as follows…
Creating the CLI gem was made easy using Bundlr’s ‘bundle gem’
This gem generates a directory named
GEM_NAME with a
GEM_NAME.gemspec, and other supporting files and directories that can be used to develop a rubygem with that name.
Highly recommend using it as a beginner! It makes life a lot easier and provides users, especially beginners, with the hierarchy and relative connections between the various files required to make the program run successfully.
Here are a few top tips from my studies and sufferings:
- Start by creating a file within bin that will serve as the file that runs your program. Make sure to copy and paste the shebang (#!/usr/bin/env ruby) then close your file and reopen.
- Don’t forget to change writing permissions for executable file by using the “Chmod + x insert filepath here” bash command. This gives you a clean executable line like “./bin/latin_roots” that starts your program when entered.
- New Objects require new files and don’t forget to require_relatives unless you gem “require_all”.
- Sometimes you need to get scrappy with where you require files despite using require_all. For example, I had to require such gems as ‘nokogiri’ and ‘open-uri’ in the version.rb file in order for them to run properly.
- Commit often. Commit Clearly.
- Ctrl+Shift+I then highlight desired object and copy selector path then paste into the .css(aka here) would have been a great ‘Nokogiri’ time saver had I known about that functionality.
These are just some of the bigger tips and tricks I learned during the creation and basic setup of my CLI gem.
Remember a lot of things will not work even if you are following the directions and that’s okay! Just make sure to always recheck your work and accept the fact that programs are constantly changing so there may be slight variations from that one example you saw on StackOverflow(#lifesaver).
The project structure was simple. It included three main objects and one program control object as follows:
- Country — this object was responsible for creating and managing our core country functionality. This would allow for new countries to be instantiated and their country attributes assigned. This collaborated with our Scraper object.
- Scraper — this object was responsible for the data scraping from our main source of truth, Encyclopedia Britannica. It accomplished this by using ‘Nokogiri’ and ‘Open-URI’. The majority of the code is scraping individual elements our Country class will need. At the very end, the two objects collaborate to create new instances of each country scraped.
- User — this was responsible for creating and logging a user instance so that the program could personalize the user feedback as they moved through the CLI program. Fun User classes such as #passport and #visits were created to stylistically recap the user’s journey. This object collaborated with our CLI object and was initialized when I asked the user for their name in the CLI #menu method.
- CLI — The core object that controls the overall flow of the project. The structure is centered around the core method #call. This is called in our bin file, as LatinRootsII::CLI.new.call, which starts the program. I wanted to keep #call as clean and DRY as possible so I limited myself to using methods only. The rest of the logic was built in other methods with the CLI class. These methods collaborated with every other object in some manner. A few examples include:
This structuring allowed for me to create a conversational interface and a personalized journey while attempting to maintaining DRY and some of the other Flatiron School coding principles.
Check out Latin Roots in action below…
Check it out on GitHub!