Skip to content
fuzzyassassin edited this page Apr 9, 2015 · 5 revisions

Fun Runs 2K15 Technical Wiki

Introduction

Our team thus far has enjoyed creating the web app and working together to make a functional website with an organized user interface. The topic itself is interesting and has an enormous amount of related media, making this project inherently entertaining. The most frustrating parts of this project have been mainly configuration and dependency issues - not the implementation itself. Therefore, having a VM to work on with a working state has been a good method to avoid a scenario where TA’s have to set up environments just to look through and execute any files we provide. Our team’s Read Me for the GitHub better describes the files we have in our repository and how to run the web app, if interested (we will keep our web app running, however). The freedom to choose what tools we want to use has been a great way to explore web-app development, while this project itself has pushed us to implement, tinker, and create to the best of our ability.

The Objective

Races and running are not for everyone. The pain can be too overwhelming, the sun can be too harsh, and the intensity can just be too much. Those who are serious about their running train to attend marathons and walk away from the race with a sense of accomplishment. However, those who do not want to partake in miles of fatigue, have not trained, or do not find pure running of any interest are at a loss - how can they enjoy the benefits of exercise when it does not naturally please them?

America has shown an upswing of silly races popping up all over the country called “fun runs.” These fun runs are not your common marathon - they find ways to be quirky, different, and entertaining to the average Jane. These crazy competitions span in their ideas: running in your favorite costume, running then eating as fast as you can, running up the stairs of the Empire State Building, and even running nude. We found these races to be an amazing way for die hard athletes and casuals alike to exercise and enjoy together in ways never experienced before, and therefore, made it the topic of our project.

Use Case

This site’s intended audience is for hardcore athletes, casual runners, families, and children alike. Our group tried to design intuitively by including obvious navigation bars, highlighting the current position whenever possible, and remaining clutter-free. By picking a bootstrap that is able to handle a lot of content, we were not inhibited by the design and were free to include information we felt was pertinent. In many instances, the bootstrap’s features were even helpful in displaying information without adding clutter - like slideshows and carousels.

Fun runs are great events to encourage those looking to be active but wanting alternatives to the core long-distance run; therefore, our design has to persuade such people to check out some runs by displaying information in an understandable, frustration-free hierarchy. The site sorts by our three pillars: the runs themselves, the types of challenges that one will face in these sorts of runs, and the common themes that these runs take on. By building this database, our team provides useful, entertaining information on these hilarious fun runs in a way that is convenient, user-friendly, and informative.

Workload Separation

A large part of working on a sizable development project is learning how to work with a team in an efficient and peaceful manner. Our difficulties were mainly in sharing a common codebase amongst so many contributors, but by utilizing GitHub, our team was able to resolve the occasional merge issues quickly because of our constant communication.

File Structure

Our repository exhibits natural hierarchy with app/ containing all of the relevant files to run our website. The templates folder includes the html files, static/ includes css/javascript/imgs/angular, and the app itself is funruns.py. We have models.py as a mock up of our future Flask Models; we did not implement a database this phase - instead we have json in api_helpers.py and our RESTful API calls in , but thought it would be a good exercise to think ahead.