MLB Stats Lookup Ruby Program. In my flatiron school program we were…
By: Riley Iverson
Tags: Database, API, Activerecord, Software Engineering, Ruby

In my Flatiron school bootcamp we were assigned to do a pair project. Me and my partner decided to make a program that takes baseball data, inputs it into a local database, and returns relevant data to the user with a user input. This program would be written in Ruby, and it would use ActiveRecord, sqlite3, require_all, rake, and pry gems.

Starting out the project, we were actually considering using CSV files from a MLB databank. We had some concerns with using this since the data went back all the way to the 1800’s. It was a lot of data. It would have been a tedious and lengthy process to go through all the available data and to record the necessary stuff into our database.

After searching for a new solution to our data, we found an API that includes all the necessary data we need. With the API we could get the data we needed faster and easier to get than if we used an API. The CSV would have worked, and in some places may have been better, but the API ended up being much more convenient.

Get class utilizing open-uri, net/http, and json

To use the API we needed a way to get and parse that information. This was done by using ‘open-uri’, ‘net/http’, and ‘json’. You can get these by requiring them in a file. Altogether they make it possible to retrieve data through the internet, In our case the MLB API. OpenURI makes it possible to open http, https, and ftp urls. The net/http lets us get back an object that is close to the actual structure of the http response. Finally json allows us to parse json formatted data into an array or hash that we can use.

Database showing tables and columns

After we had a way to get and parse the data from our API, we could start on creating methods and setting up our database migrations. For our database we created three migrations that made us the three tables that our data would record. The tables were a players, teams, and a contract table. We wanted to have a many to many relationship between our players and our teams. To do that we needed a bridge that would connect the two, which would be a contract.

The models would match our database, being a player, a team, and a contract model. Our major methods that would be in these classes were our add methods. The tricky part about this was that we needed these methods to not only add a new player to our database, but also adding their team, and creating a contract to connect them in our database. All the while taking the correct information from our API and using that without duplicating data in our database.

A snippet of the player class showing the add player method

The way we were able to make our add methods work was by using the find_or_create_by() Active Record method. This allowed us to avoid creating duplicates in our database. Using this we made add methods to player, team, and contract. With these methods in place we could run add_player and it would take that player’s name, put it into our database, add the team it belongs to, and create a contract between them connecting them in the database.

Now we needed some methods that would display information about our players and our teams. Using the add methods for player and team, we made methods that display and compare information about our players or teams. In our players, there were also methods to display batting averages and pitching averages for specific players. In team there was also a method to display all the players of a specific team. Finally there were methods for all models that deleted a team, player, or contract.

Team class snippet showing methods that display team data

Now we had all of our methods working how they should with fail safes, in case something went wrong like the user inputted an invalid input. The last thing that was needed was a way for the user to interact with our program. To do this we made a run file that would get the user input and depending on what that was, it would loop through if statements to run certain methods.

In conclusion, this project was a fun way to experiment using an API. The program could have much more functionality and methods if we had the time to add them. It would be just a case of adding more API gets, and returning the information from them. The API was very versatile and had plenty of MLB data available through it. You can find the API here. The project I worked on can also be found here.