Using the Spotify API To Generate Some Really Bizarre Playlists
As part of completing module 1 (Ruby) of Flatiron School’s Software Engineering Immersive Program, we were required to build a small command line application with a partner.
The parameters of the assignment were pretty open ended.
We needed:
- a minimum of three models including one join model
- to access a SQL database using ActiveRecord
- to seed that database either with an API or by scraping a website
- and to create a command line interface (CLI) to display our data in an interesting way
Enter Playlist Creator
My partner and I decided to work with Spotify’s API. While looking around the API we were drawn to some of the more obscure data points that were available and decided to create an application that could generate playlists from a library of songs based on characteristics like key signature, “danceability”, “acousticness”, mode (major or minor), time signature and a few others.
That Sounds Fun… Now What?
After settling on an idea, we began to make a plan. We started mapping out our models, deciding which data we wanted to use and figuring out what data belonged to what. We used draw.io to diagram how our program would work.
A Plan
Ok, we have a plan. Our next step was to define our models and their relationships. We created three classes: Song, Playlist, and SongPlaylist (which would join the two). We know that a Song needs to have a bunch of different data associated with it in order for our program to do what we want.
Database Time!
Next we needed to figure out the API and get our database up and running. We needed to access the “Audio Features” endpoint to get access to the data we were interested in. However, we quickly realized that the data we were getting back didn’t contain track titles, only Spotify’s ID for the track. We ended up having to access two different endpoints in our seed file and combine their information in order to get all of the data we wanted. We first accessed the Track object and used that to get the track’s title artist and Spotify ID and then with that information we accessed the audio-features object (the information we were interested in) and combined the two to create each instance of our song class.
Putting the I in CLI
With our data successfully acquired we began to build out our CLI. We started by returning to our draw.io file and mapping out flow chart of the users journey through the program.
As we worked through building the different screens we settled into a pattern where each menu screen became a method that captured the users input and routed them via an if statement to the correct branch which ran the methods for the next menu and or completed the required operation. After we had the basic structure created we began refactoring our code by pulling out repetitive tasks and turning them into helper methods and reorganizing the file to make it more readable.
Making it Pretty
With the basic functionality of the application completed we went back through and added some polish. To help clean up the user’s interaction with the menus by adding the ability to quit or return to previous menus throughout the app, allowing the ability to create multiple playlists without having to rerun the program.
We also decided to make it pretty! We used a gem to help style our menus and create a header for the interface. By creating a helper method that cleared the terminal screen and reprinted our header whenever new information was printed to the screen, we were able to make interacting with the terminal feel more like the type of interactions a user would be accustomed to.
In addition to this rudimentary animation, we used more gems to add color and table structure to our interface and to give the user the ability to open a song’s Spotify page in their browser directly from the terminal, increasing both functionality and legibility.
Conclusion
The two most important things I took away from this project was the importance of taking time to plan out a project and appreciating the power of pair programming. When starting a new project it’s very tempting to jump right in and start writing code, but slowing things down and talking them out with someone was invaluable. It allowed us to solve problems before we encountered them and to make informed choices when things we hadn’t planned for crept up.
