Home
>

In CS, taught by Ms. Taricco, we cover the AP Computer Science A curriculum, as well as several other fundamental topics. The course started off with the development of a website (this one), we then moved on to learning Java, and we are going to start the Apps For Good competition, where we will be developing our own apps in groups to help our community. It is a fun class, and we are given different coding challenges about the topics we are learning each week.

Line Art

I found the Line Art program interesting and fun to work on. It was fascinating to discover that all the lines were straight, and even better to understand how to make the design, especially through all the math methods that I went through for different ways to make the design and then choosing the most feasible one. After that, I coded each section separately and I only had to change a couple of lines to fit the needs. Each section that I coded kept the excitement going and the joy of having a beautiful design being crafted piece by piece on the screen.

Static Array Exercises

Right after learning about static arrays, we were given homework challenges to do. I enjoyed working on the different challenges and checking my answers as I went through. The problems included a mean calculator, a mode calculator, a median calculator, creating a magic square, and other fun challenges. This assignment, like all others in Computer Science, not only incorporates topics about things we just learned about, but also most of everything else we learned previously. The use of the Java api is also encouraged if we are not sure how to use specific methods as it will be freely available if we become computer scientists one day.

Apps For Good

An integral part of Mass Academy’s Computer Science course is the Apps for Good project that we students get to complete. We were given 3 months to brainstorm, design, construct, test, and present an app to help solve a problem or inconvenience that could be found in our community. My team decided to explore running and music, and came up with a final app called TuneRunner!

Problem Statement

Running while listening to music is a popular practice because it can increase a runner’s performance and endurance. However, the tempo and energy of a song are significant factors for a runner to run comfortably and perform their best. Running with music that does not match the runner’s pace can hinder their rhythm, therefore making the runner perform worse.

Solution and Target Audience

To create an app that would adapt to a runner's pace as they run to better match their rhythm , thefore making the runner run more effiently. This app was created for runners, but could also be expanded to target any athletes who have difficulty finding a set playlist that adapts to their pace as it changes.

Minimum Viable Product

For now, TuneRunner allows users to choose predefined speed trends over the course of a run in the form of a graph. They then input their desired distance and average pace alongside this. Leveraging these details as well as a library of downloaded songs and their corresponding beats per minute, the application generates a playlist that aligns with the graph configured. This app targets an athletes who have difficulty finding a set playlist that adapts to their pace as it changes.

Process

The first step into creating this app (and probably the most complicated) was finding data. For this, we used various sources to look for things such as different running patterns, to non-copyright songs and their beats per minute (BPM). During this step, we also followed a tutorial to create a music player to be able to play the generated playlist for the users. After collecting the most preliminary information, we started working on the basic UI and the algorithm to adapt a certain graph to a desired speed and distance. Then, we constructed another algorithm to find the instantaneous BPM at different sections of the graph, and moved on to the selection and sorting algorithm to be able to select the songs from the database based on the BPM calculated at different points of a run.

Poster