Flatiron School Presentation – Tempo / by Becca Barton

One of the things I appreciate the most about the program at the Flatiron School is the focus on not just teaching you to be a skilled programmer, but a skilled communicator as well. As part of this, we're required to do one presentation per semester presenting with another classmate on something we've learned. 

For our presentation, my classmate Elaina Polson and I decided to dive headfirst into Rails and create a playlist app (a bold choice, considering we'd only been Rails programmers for a few hours at that point). A brief overview of our first experience with Rails, below:

The Problem

We listen to playlists. A lot. And we often rely on websites or apps to curate these for us based on our tastes, mood, etc., especially when we're looking for mood-setting music to match our energy levels. When we're working out, we want consistently upbeat songs, whereas when we're studying, we want more low-key music that will blend into the background. The issue with many current app-based playlists is that they curate playlists consistently on genre, but not so consistently on the BPM (beats per minute), and energy level of the songs. This leads to playlists that ebb and flow in energy level— not ideal.

The Solution

Enter Tempo. Tempo works by taking in songs from Spotify’s API and sorting them into four different activity categories— sleep, study, party, and workout— based on their tempo. Choose your activity, and Tempo returns a playlist with songs organized by beat, creating a playlist that seamlessly flows in energy level from one song to the next. 


After brainstorming ideas and outlining a plan of attack, we began with the basic Rails framework, and set about creating our schema. We started with the basics, and decided each song would need an artist and tempo. Next, we worked on a way to sort a set of songs into various categories, using some Ruby case statements. After we had this working, we made a SongSorter class that, as the name would suggest, ultimately would be responsible for handling all of the sorting of songs. After making sure this worked with our own seeded data, we decided to start adding more impressive functionality. We started with using Spotify's API to seed our database with current songs, and iterated through JSON's song objects to fill our database with the information we were interested in— namely, title and artist. 

Next, we used this data to scrape Echonest's API. Their JSON returns one song at a time, with a lot of useful classification information like energy, duration, and tempo. For our purposes,  we were interested in the tempo, and added this information to each song in our database. After we had this working, we began working with the views and controllers to set up our routes and make sure the information we had gathered would show up appropriately on each page. Finally, we added a few design elements in CSS so it wasn't just a plain page, and then used Spotify's embedding features so the user can play the music straight from the page (although ultimately, we would love to get the playlist function working so each playlist's show page would have the embedded playlist right on the page.)


We faced a few challenges, mostly due to us being new to the Rails framework. Thankfully efficient Googling solved many of our problems, and persistence solved the rest. The most difficult adjustment was trying to navigate the the file structure of Rails, and making sure we were placing everything in the right folder. 

One of the most challenging issues was figuring out the scraping and how to circumvent API call limits. The site we were scraping only allows 150 calls per minute, and so we had to adjust our algorithm to ensure we wouldn't be calling more than this. As API call limits were something we had never encountered before (hell, API keys in general were a new concept) it was a bit difficult figuring out how to make the program functional and not overreaching our call limit. Ultimately we decided to cap our limit of song requests to the maximum, but ideally in the future we would like to instead cap each playlist at a certain amount of songs, which would allow the playlists to all be the same length while staying within the call limit. 

Future Plans

Ideally, we would love to create an option where the user could choose to run the app on their own music library to create an extremely personal playlist. After all, you're much more likely to like the songs if they're already in your library. We would also love to incorporate a couple more variables into the sorting algorithm. When scraping Echonest's API, we get a lot of information per song, including a calculated danceability score. This could help sort songs into certain categories and help make sure they stay out of others. 

The Experience

It is incredible to me how much we've learned in just six short weeks of coding. Even two weeks ago, I wouldn't have been able to build a web-based application in Rails scraping multiple websites. I also learned some valuable lessons. Although it was easy in the beginning to get carried away with the possibilities of functionality we could add, we needed to start super, super small and unimpressive, and then build up from there. This cemented in Avi's words of advice to make it functional first and foremost, and expand on it later. It ended up being helpful because we had a working app from beginning to end, allowing us to add functionality and test at every step of the process.