#100DaysOfCode CLI Data App Project
This is the first project that we get to work on as part of the Flatiron School Online Web Developer Program. I was finally here, at the CLI Data Gem Project, it took me a lot longer to get to this point than I had anticipated.
Goal for project
The goal for this project is to create a command line interface application that provides data from a website. During one of the study group sessions when this project was being talked about it was brought up that we had the option to extract the data trough an application program interface (API) versus scrapping. At that time I still had a couple of weeks to go before getting to the project, but it caused me to be curious about what an API was. I had heard of the word and thought I had a general idea of what it was.
What I choose
I choose to explore the #100DaysOfCode hashtag a bit more. This hashtag was created by @ka11away, as a way to challenge others to expand their knowledge in the world of code. For more information on this challenge you can find that information here.
One of the rules of this challenge is to tweet about your progress everyday using the corresponding hashtag. As I started to participate in this challenge I began to be curious on how many people has started the challenge this year 2017, how many people were actually tweeting daily,
after how many days are the people starting no longer tweet about their progress, etc.
The direction I took
I could do the project by scrapping the data, just like some of the labs, but I already knew I had to pick the one that would push me a bit more.
And it did.
Oh, my… what did I get myself into? This was what was going through my head once I read through the first page of the Twitter API Developer Documentation.
This is just like reading a research paper, reading a lot of words that seem to be written in a foreign language. I know I just read a paragraph and I didn’t understand what I was reading, so breathe and pause for a couple of minutes. Let’s go back to read this again, and again.
After reading this REST APIs document a couple of times I felt that I was no where near to being able to do this for the project. But as I read on I came across the Search API. Which led to Working with Timelines. I know these are documents that I will keep on referencing back to from now on.
After saying to myself “one thing at a time, one thing at a time” multiple times I was able to slowly process all of the information that I was reading. This was also a lot easier to understand and I have to thank one of the classes I took a while ago for giving me some of the background to understanding what security keys were.
Fortunate for me that the Twitter Developer Documentation has examples and it explains how to build queries when you are watching to fetch the data. From here on out creating the classes was the next step and being able to connect to Twitter.
It did take a long time to get them to work, but once a connection was made. I knew I could slowly get through this.
2 things I had to force myself to not continuously do:
ONE – Is to focus so the task at hand that I was dealing with. Is it a method that I am trying to look for online, or how to search for the word that was somewhere covered in one of the lessons. The googling endless rabbit hole as I like to call it, kept me going from one link to another and reading different ways that the same requests were being done.
TWO – What caused my interest in this #100DaysOfCode was to see if there were people that were successful at tweeting & coding everyday. Since I started the challenge I have stopped 3 times, so I have re-set my count to 0 that many times. I am also curious about when people start to drop off. Is it the 21 days, as it is commonly know the time that it takes to create a habit? Or more days?
These were things that I kept having to get my mind to not go back to. Getting the methods to work required me to put many entries into the IRB to see if they were doing what I thought they were doing. Most of the time the methods were not. There was an error here, some undefined method there, missing arguments, etc.
So, more patience and trial and errors to get the methods to work.
Learning where to place the methods and what classes to learn to use is certainly an art of its own. I hope that in the future the time that it takes for me to write a method will decrease.
This was perhaps one of the most challenging things, mentally, that I have done in a while. It is requiring for me to think in tiny steps and know that things that were created in the beginning will end up being changed as the program develops. I also ended up referencing back to the labs which had lessons on arrays a lot more then I expected.
The assignment mentioned that extra points are given if you create a gem. This is something that I will have to come back to achieve since the current application does not have what that feature and it is what I want it to do before making into a gem.
I have been learning, create something that works and continue to iterate on it, but I have to eventually stop and turn something in that meets the requirements even if it is not the way I imagined the application to be.
What do you think. Do programmers ever get to a point that they feel their program totally complete? Where they can no longer fix or improve things in their current code?