The first assessment from Learn.co had me build my own CLI gem using everything I had learned up to that point. I teamed up with another student, Raycent Tan, who had an idea for a gem that would gather stock market information from the top industries, as well as be able to access individual companies. Although relatively simple, the main usage for the gem would be to be able to display useful information to aid researching possible investments.

The whole process took us about 3 days and we hit our share of roadblocks while trying to build this project. Nothing came easy, and there were plenty of learning moments. The following are my personal takeaways from going through it all.

Using Gems to Build Gems

I thought building a simple gem would require little effort and that we would be able to accomplish the task by writing all of the code ourselves. However, we came across  some useful gems that simplified and sped up our work.

We needed a solution to deal with JSON data, both for making the request, as well as returning the information in the right format. That’s when I came across HTTParty. This gem makes it extremely simple to make a request to an API and working with JSON all at once.

Another gem that proved extremely useful was Command Line Reporter. This made it almost trivial to display our output as we wanted in a structured table format. In addition, it has support for adding colors to your tables, which was a nice extra feature. We took advantage of this by displaying positive changes in industries in a green color while using red for negative numbers.

Git and GitHub – Learn the Flow

Even though I make use of Github every day while going through the Learn.co labs, it wasn’t until collaborating on this project that I really began to see the beauty that is Git.

During our coding sessions, we pushed a few times a day and made sure our work was always backed up. The feature that I came to enjoy the most while using Git was branching. After the first day, we already had a working version of the gem, albeit a very barebones version. From that point on, I started creating branches to work on things like formatting the output and debugging issues.

Branching always seemed like such a simple concept to understand, but it wasn’t until I made use of it that I finally see the flexibility it allows.

Merging branches, however, is another topic. We did not feel confident with the merging process and we were apprehensive about trying to merge our features and debugging branches into our master. The solution was for me to create a test-merge branch to merge Raycent’s code and my code into, and if all went well, then we’d simply merge that into the master. We ended up with some merge conflicts which I cleaned up on the text editor and then was able to seamlessly merge into the master branch.

Lesson learned here: more practice with branching and merging is required!

Using an API versus Scraping

Before getting the project underway, my pair and I debated whether we should use .csv’s downloaded from Yahoo! Finance, scrape for the information, or just use an API. We decided against scrapping because working with Nokogiri elements can get overly confusing. I’m not sure if it’s just me, but working with Nokogiri elements feels rather counter-intuitive. Or maybe I just need more practice with it…

The other option, using .csv files had us wondering where we would store the data downloaded, and how we would handle reading from .csv’s. We thought we’d have to make use of Ruby’s File class. It wasn’t until we were finished with the project that we found out there’s an actual class in Ruby to handle CSV’s.

In the end, we opted to go with using an API. I had some prior experience of working with one and suggested we go that route because of how simple it is to work with JSON data.

Big mistake!

Finding a financial API was much more difficult than we’d originally thought it would be. It turned out that Google Finance had shut down their API a long time ago, and Yahoo! Finance wasn’t officially supporting their own anymore. The API we were using via the YQL (Yahoo! Query Language) was unstable. This caused all sorts of headaches and issues while trying even the simplest requests from it.

There were times when the API would work flawlessly, and return all the data we asked from it; Othertimes it would become unresponsive and had us going through our code with a fine-tooth comb as if that was the problem.

We dealt with the issue to the best of our ability by making multiple successive requests every time any of the fields we were targeting returned with a value of nil.

Conclusion

Thanks to this project, I have learned my lesson, as I’m sure my partner did as well – never willingly work with an unsupported, unstable API if we can avoid it! I believe if we had to do the project over, we’d rather deal with Nokogiri.

At least it would be consistent in returning XML objects that sort of behave like arrays, but aren’t really arrays – yet still, accept array methods…