To The Beat is a web application that will make the ideal playlist for your runs, workouts, or even jams.

The front-end of this website was made with Bootstrap, CSS, and Spotify logos provided by Font-Awesome. The logic is generated by python/flask and javascript.

When the user first enters the application, they will click to log-in to Spotify which prompts Spotify API calls to authorize that user's account to be used. Once the account has been authorized with OAuth, the backend will receive the access token and the ID for the Spotify user.

Once redirected to the next page, the user will be prompted to enter their selections for the name and tempo they want for their new playlist. The backend will then consistently update what the user has typed. There is also a sound button on the page which plays a single beat at the speed they have entered. This is done by calculating how many milliseconds would be between each beat, then playing a simple single beat mp3 file.

Once the user clicks submit to enter their choices, the backend of the code then grabs the information from the user. It then makes Spotify API calls to first get all of the user's faved songs. Using the Spotify ID of each of these songs, it then makes another Spotify API call to get the track info, which has the tempo of the song. This tempo is then compared against the user's requested tempo, and if it is within 3BPM of the request, it is added to a list of songs for the new playlist.

Once the user's songs have been analyzed to find the ones which match tempo, a Spotify API call is made to create a new playlist with the name the user chose. The list of songs is then added into this new playlist. Lastly, the user is redirected to a result page where details about their new playlist are listed, and the playlist itself is embedded into the page.

This webapp acts as a way to represent various data about San Francisco Dispatches. The data was received through csv files, then input into a MongoDB database through a python backend file. Bootstrap/Bootswatch was used throughout the webapp to assist in frontend styling.

When the user first comes upon the site, they will hit the homepage, made solely through static html/css files. From this homepage, the user can then get to any other page on the webapp.

The first page they can go to is the Statistics & Graphs page. On this page, the user can find various graphs and facts about the data. The page itself was created using html/css files, but also an integration of Chartist.js to represent the data graphically. The data is connected into these files by looking for and grabbing the necessary information from the database in the main python file.

Informational Maps is the second page a user can choose to go to. The user has the option to checkout 4 different maps on this page for more visual information about the dispatch data. The first graph shows the zipcodes within San Francisco which seem to take the longest time to dispatch. The Heat Map shows the user the frequency of dispatch calls across the city. The third map shows the user which are considered the safest neighborhoods in the city (in relation to crime and dispatch call frequency). The final map then shows the zipcodes which have the highest increasing rate of dispatch calls. All of the information for these maps was figured out algorithmically through a python backend along with get requests on the database. The maps were then represented by using the Google Maps API and GeoJSON files.

Thirdly, a user can look at the Most Likely Dispatch page, which will show them the dispatch that is most likely to occur based on a location and time. The time input was integrated using TimePicker for jQuery, while the map and the marker drop were integrated using the Google Maps API. After the user has clicked submit, an algorithm begins to discover what range of time and what areas to grab data from. From there, the new list is gone through to find which type of dispatch call will be most likely, and outputs this result to the user.

Check out the code & readme on github to find out more information about the logic for the backend!

Completed while taking the Software Engineering course at UT Austin.

NPOLink is a web application which allows users to attain information about various non-profit organizations. Using this website, users are able to find out about non-profits in their area, non-profits by category, and even find ways to volunteer for and help these non-profits. Our group noticed that websites often either just gave direct information about a non-profit's name and tax-exempt code/non-profit category, or simply listed events to volunteer for. We wanted users to be able to find non-profits that they could actively be passionate about based on either location, category, or both, and find out various information about it.

The web application itself was built using Python/Flask for the back-end and React for the front-end. We also developed our own RESTful API service. The website and all of our data was hosted on AWS.

This project was created for the Spring 2018 TAMU Hackathon at Texas A&M. It is a web application which helps users create the backend of a website through simple drag & drop functionality.

Users can begin building their site by first signing in using either Facebook or Twitter, implemented through each of these platform's Authentication. From here they are taken to a drag & drop screen, where they can add simple features such as login, API calls, and cookies. They can add multiple routes, to ensure their final product can include everything they need.

At the Hackathon, the project received 2 awards, Best Domain Name (MLH) and a Core Values Prize (GM).

DancerDB acts as a one-stop website for all the information someone could want about dancers, companies, or even performances. The website as a whole uses Bootstrap/Bootswatch and FontAwesome for assistance in front-end styling.

All the data for this webapp is held in MongoDB. This database is updated every time an admin uses the add person or add company admin pages. These pages are simple html forms that send the data to the database once the user clicks submit.

The user will first come upon the homepage which simply displays a carousel of some images from the webapp. The user can then use the navigation bar at the top of their screen to get into the depths of the webapp.

Under the companies tab, a user can find various dance company, and click links to find out more. On a specific company's page a user can find a description of the company, a link to each of its members & choreographers, a list of upcoming performances, and a few statistics over the company.

One can find the information about a specific dancer, choreographer, or director from the hyper links in their associated companies or from the people tab. On a person's page a user will find their biography, a headshot, stastics over the person, links to various social media and a video if available.

This webapp for mobile devices provides a Capital One user the ability to have a faster checkout experience at retail stores.

When the user opens the home page, and has already logged in, they have the option to add new items to purchase, look at their current cart, or view their transaction history. When they want to add a new item, they will go to the scan screen.

This scan screen recognizes the user's location, and initially gives the closest retail store. If this is not the location they are at, they can click to change through to other local retail stores until they find the correct one. This is all done using the Google Maps API to recognize a user's location and search for the top 10 closest retail stores. After the user has chosen a location, they place the barcode of their item under the camera. The program then scans the barcode, finds the product, and adds to the cart. The scanner itself was integrated using QuaggaJS, which will return the number of the barcode to the backend of the code. This barcode is then lookedup in the database to find the item that matches it. This item is then added into a list that represents the user's cart. Once the user is ready to complete their purchase, they can click checkout.

The checkout screen will then list all the items in the cart, also allowing the user to remove any unwanted items. Finally, they click submit purchase, and the total is automatically removed from their Capital One bank account using a call to the Capital One API.

Completed while taking a Introduction to Data Mining course at UT Austin. This project focused on analyzing data using the Darwin platform & tools. The group analyzed a large data set containing information on movies, and built models which would predict if a film would earn at least $100 million domestically.

Through the use of Jupyter Notebook, we were able to implement the entire project, from data collection, to the final modal & prediction. Our group began by collecting our data together and prepping it, removing any irrelevant columns. After this, we spent awhile simply exploring the data to get to know it a bit better. From here we were able to visually see binning based on domestic gross as well as a positive correlation between budget & domestic gross.

After exploring our data, we began to feature engineer our data, adding in new features based on pre-existing ones, such as combined income for actors, directors, and writers in a film. After this, we fed our data model to the Darwin SDK, which in turn created & trained our model for us. From here, we were able to get our feature importance listed as well as the final results of its prediction accuracy.

As this was a school project, no code is available to be seen. However, if you would like to find out more, please feel free to contact me by heading over to the 'Contact' page on this website.