Development
CLI Data Gem
My latest lab project on learn.co required writing a command-line Ruby gem that either uses an API or scrapes HTML to retrieve data and display it to the user. I thought it would be fun to use the GitHub API to retrieve a list of a GitHub user’s pull requests since this would fulfill the requirements of the project. The previous data labs I had completed used Nokogiri to scrape HTML files so this would give me a good opportunity to learn how to use Ruby to interpret the JSON output of API requests.
After several days of research and coding the initial version of my project is finally complete! There were moments of confusion and frustration but it was satisfying to figure out solutions and create a working product. I even published my project on rubygems to make it easy for anyone to install and run my application!
After going through the whole process I am amazed to see how easy it is to publish and share working code with Ruby.
Starting the Gem
After watching Avi’s video tutorial and some experimenting I started my project by using bundler to create a rubygem skeleton:
bundle gem list_pull_requests
Then I had to decide on how I wanted to structure my application. I wanted my command-line code to mimic Avi’s daily_deal code so I needed to create a ListPullRequests::CLI class and require it in list_pull_requests.rb.
It occurred to me that instead of listing a user’s pull requests my application could also list a repository’s pull requests. In order to make that functionality easier to add later down the road I wrote most of my API request parsing code in the ListPullRequests::User class. This way I could name the code for repository pull requests ListPullRequests::Repo.
I also needed a way to store information about each individual pull request. Since there were several different attributes I wanted my application to display I decided to create the ListPullRequests::Pr class that would store each pull request as an instance of the object and the attributes of the pull request as respective instance variables.
Next I needed my application to actually output instructions to the command-line and retrieve user input. Following Avi’s daily_deal structure made this pretty quick and easy. My program still didn’t do anything because I needed to convert the user input into an API request and parse the data. After playing around in irb I knew the commands I needed to get the details and I added code to list the data. The output was hard to read because the elements weren’t distinct so I added the colorize dependency and colored my output. I proceeded to write code to retrieve and list details for a pull request and add more functionality, making git commits along the way.
I ran into a good bit of trouble after trying to install my gem on my system. At first I thought it was because I was somehow not installing my gem correctly but after installing the daily_deal gem on my system I realized it was because I needed to fill out my gemspec file. I encountered my next problem when I tried to publish my gem to rubygems. I still had code in the gemspec for a push host whitelist and after removing it my code was successfully published!
I promptly uninstalled the locally installed gem of my application and tried grabbing the gem via gem install list-pull-requests. My gem was downloaded and installed from rubygems and I could run it from any directory in my command line! I was suddenly amazed that everything had worked and my application was available for anyone to quickly try and improve upon.
All I had left to do to finish my project was write this blog post and make a video walkthrough of how a user would interact with my application.
I’m excited to learn whatever’s next, particularly how to turn our ruby command line applications into working interactive web sites!
Other Posts About Ruby
Gandhi Anderson BLOG
ruby