In deciding the direction to go with my CLI Data Scraper, I wanted to go with something that interested me and was data heavy. What better to fulfill those two requirements than sports? Once I decided on some kind of sports scraper, the name came to me immediately and I chose to go with Sportify. Ultimately, I wanted to make an application that provided rosters, statistics, schedules, etc for the four major American sports leagues(NFL, NBA, MLB, NHL). However, I quickly realized that this was overly ambitious and went well beyond the scope of the project requirements. I settled on just scraping the MLB site for data but did design my application to be flexible so that I can easily add to it in the future. In fact, in turned out that simply scraping the names of each MLB team along with the rosters and numbers for each player more than fulfilled the requirements. It turned out that sports are on the extreme end of data collection and there are almost endless possibilities to what could be added to my application.
The biggest struggle I had in understanding props in React was adapting to the uni-directional data flow. In the Rails framework, there are no parent objects/models/components that contain all the properties. In essence, Rails has a multi-directional data flow that takes a different programming mindset vs React. However, once you understand the flow, React can be used to quickly create fast and efficient applications. The key thing to remember with props is that they are immutable; meaning that they shouldn’t be changed within the child components.
API is an acronym for “Application Programming Interface”. It may sound daunting but API’s are, in fact, simple in theory and essential in a future of interactive applications. In essence, an API is a set of protocols that enables two applications to work with each other and provide functionality or data to one another. The benefit of this, is that it saves a programmer a great deal of time in writing code because they can pull functionality or vast amounts of data from already developed applications. One of the most common ways this interaction appears is in signing up for new applications. Most new applications will allow you to sign up via your Facebook account, Gmail account, Instagram account, etc. Another example would be when you go to a business website and see their address pulled up on Google maps. Typically, if an application provides an API, they will also provide documentation that explains what type of data and functionality can be accessed and how to access it through your application. Unlike data scraping, API’s are more reliable and less prone to errors. API’s typically follow the same pattern in that you make a call to the API and request information. Almost all API’s are free but some of them do place restrictions on the number of calls you can make within a certain period of time. While API’s are expensive for companies to establish and maintain, they can help their application proliferate as more third party applications become dependent upon them.
Today we will be walking through the RESTful Index Action Lab which is part of the Rails Intro to REST section. To begin, you will need to fork and clone the lab and run bundle install. Once all the dependencies have loaded. You will then run “rake db:create && rake db:migrate && rake db:seed”. Once that is done, run the test suite and there will be two failures.
The Model-View-Controller architecture was initially introduced in 1979, which was well before the proliferation of the internet and applications that are commonplace today. Despite its early introduction, MVC architecture remains the standard by which most programmers develop their applications today. Its continued use and adaptability to the ever-changing technology landscape is a result of its adherence to natural law. Life as whole follows an MVC pattern. Whether its a bartender taking a drink order or a person watching television, we can find MVC at work in almost anything. Even at the highest level, we have the earth and all the scientific laws that govern it. This is analogous to the model aspect of the MVC architecture. Then there would be the controller which is our brain. Or brain interprets the model and renders the view which is the abundance of life we see and encounter daily.