First time doing CLI ruby gem
It’s been three weeks of an amazing journey at Flatiron Bootcamp. We started with ruby and all of my previous coding experience was a month of self-paced learning javascript in Bootcamp prep class. The first impression was like “Really? It’s that straightforward?”, it was like communicating with a computer in the English language without semicolons in every line and brackets all over the place. Really pleasant experience learning the basics of ruby and highlighting all that is Object Orientation. For me it was mind-blowing to be introduced to such a concept and object relationships made it even spicier.
After finishing up the whole module on ruby it was time to put some thoughts into my CLI project but still being under the impression of what is ruby is actually capable of I felt a little lost a first simply because I couldn’t choose what to do. It’s like all you can think of is “I can do literally anything” and it doesn’t help. Have you ever been in a situation when you are in a supermarket looking for a bag of chips and you can’t really decide what do you want cause it’s way too many options? Well, that was it, fortunately for me, I had to choose if I want to get some data into my CLI with API keys or do some website scraping and sure enough I saw the idea of API more appealing to me, with the only negative aspect of it that there is not a whole a lot of good APIs out there for free, what a bummer.
Spending a few hours looking for a perfect key was exhausting, you gotta play around with output and see if and how you can manipulate with gathered data and make it more interactive. I got lucky on https://rapidapi.com/ which turns out to be a great source for API keys. So I got my keys so what’s next? Yes! It is time to start building the gem.
Building a gem:
Building a gem frame itself was pretty easy mostly because there is a bundler gem that will do that for you with one simple command being in the directory you want to create your gem: $ bundle gem [your gem’s name] and that will build up the frame for you with bin, lib and spec directories, read me file as well as Gemfile, Gemspecs and other stuff you need for your gem to be legit.
Creating repository :
Before you dive into coding I would recommend doing one more step — create a git repository for your gem. https://www.geeksforgeeks.org/what-is-a-git-repository/ here is a great resource for you to get introduced to a git concept. After that, you can store your gem on GitHub’s cloud so you can access it any time, make changes, or share it.
Developing a strategy:
Not gonna lie I was too excited to begin coding so I just went for it and found myself being confused very quickly. Lack of strategy just threw me off and after a while, my code was such a mess. I’ve deleted all of my code and opened up a blank page in the graphic editor so I can materialize my thoughts on how it should be working. Slowly after asking myself the right questions I made a little drawing with classes and how they communicate with each other, no codes just concepts. I came back with my second attempt this time having a game plan and everything went pretty smoothly till the very end, so point is that having s strategy before you get to coding is a must! doesn’t matter how good you think you are it just helps to think thru entire project and open up different perspectives for you.
It’s Time to code:
At this step, you should be fully prepared to code and showcase all that knowledge you’ve gained. Everybody has a different coding style and the way they envision it so there are no direct guidelines on how your code should look like but what is most important that it should get the job done. When I finished coding and tested gem in the terminal, I was thrilled it worked just fine, no crashing no bugs working just the way it should be (of course there was lot’s of bugs that I had to fix before it worked) so even though the show was amazing, but what happened behind the scene looked pretty messy.
Making code ‘DRY’:
My CLI is working the way I planned it and it’s time to reformat my code. It’s pretty cool when you see the whole picture you know the way how can you make your code more “DRY”, consolidate it customizing methods so they can accommodate different requests. Getting rid of Syntax Vinegar and reformatting that code so it reads clear and anyone who reads it can understand it. And of course, the structures should make sense as well.
Creating and publishing gem:
After you’re done with your code you gotta work on your gem spec file providing it with all of the necessary information about your gem. Luckily Bundler has created that document for us and all we need is just make some adjustments. Also, we need to update other files such as README, License, and CODE_OF_CONDUCT. After you are done with all of that it’s time to push your final changes to GitHub, we’ll need it to publish our gem.
The first step to make your gem official is to register it as a gem. https://guides.rubygems.org/make-your-own-gem/ Here is a link with a description on how to do that. After that create an account at rubygems.org to publish it, and a description on how to do that I will leave right here https://guides.rubygems.org/publishing/.
This is the way I’ve done and hope you’ll find this information useful. Thank you for reading.
