## Inspiration

During the day, universities around the world feature the brightest minds, most challenging ideas, and greatest opportunities to grow as both a person and an intellectual. At night, however, such campuses can feel nearly foreign or frightening as the streets lack the normal bustle of students and the light grows dim. Universities attempt to alleviate students' anxiety and worries of safety by offering a variety of services; at Cal, we have our system of Night Safety Shuttles and BearWalk staff that accompany students. Yet, these services tend to have extraordinary wait times, sometimes exceeding two hours. Enter GetHome.

## What it does

GetHome connects verified students with one another such that no user has to walk home alone. By utilizing the pathing and geolocation of Google Maps, as well as the information gathering and communication offered by Cisco Meraki and Spark respectively, GetHome quickly pairs two users headed in a similar direction and provides a path such that they both get to their desired location with a minimal amount of safety risk. In addition, GetHome uses Cisco applications for data analysis and tracking to virtually accompany pairs as they make their way home: access points can ensure that users are on the correct path, and a chat-bot can double-check users have successfully gotten home.

## How we built it

As a webapp, we utilized HTML5 and CSS3 to create a clean and precise landing page, with one redirect included for when a user lines up in queue. The basis of our working code is Javascript, which we used to interface with the various APIs allowing for accurate tracking and pathing of paired users.
Using Google Graphs and Maps, we generated formulas to calculate and accurately map distances between all users as well as the distances between their respective destinations, while simultaneously displaying such information in easy-to-read graphical elements. A combined integration of Cisco Spark and Cisco Meraki, done via creation of Spark bots and information gathering with AWS Lambda, generates the heatmap for users to find their partner as well as open an avenue of communication between the two. Obscured from the user, we also rely on Meraki's Real Time Location Services (RTLS) to track whether individuals are following the anticipated path home; deviations are viewed as hazardous and can be handled by our companion-bot, which checks in with users to see if they're okay.

## Challenges we ran into

Utilizing the REST API efficiently was difficult, seeing as how none of our team members had previous experience working with HTTP POST requests. In addition, working with the servers provided for accessing real-time data of our immediate location proved difficult, as some connection errors and faulty permissions prevented us from dedicating our full effort towards completely understanding the use cases of the functions and services provided alongside the data.

## Accomplishments that we're proud of

As a team, we are proud of creating our first ever Spark bot and formulating conclusions based on real-time data via Meraki's Dashboard. Meshing together multiple APIs can become messy at times, so we are extremely proud of our clean implementations that serve to precisely and efficiently merge the varied applications we delved into.

## What we learned

Throughout this hacking process, we learned a great deal about how to work with Node-RED for Cisco Meraki and Spark queries, as well as how to integrate such applications with services like AWS Lambda to properly retrieve points of interest, such as MAC addresses for tracking. The less-experienced of our team also learned how to utilize APIs in a very general sense within HTML and Javascript; as a whole, we built upon past experiences to further increase our efficiency and teamwork in regards to formulating ideas and bringing them to manifestation through research and dedicated work.

## What's next for GetHome

Meraki's ability to precisely locate devices through triangulation by access points as well as the flexibility of heatmaps allows for the possibility of creating paths that avoid high-risk areas; this would be a further step in preventative safety, reaching beyond what our application currently utilizes Meraki's location services for. Combined, having Meraki anticipate the next access point the user should be pinged at as well as formulating the path so it is not only the shortest path, but also the safest, would be extremely beneficial for GetHome and its users.
## Inspiration

We hear stories about crimes happening around us everyday. It's especially terrifying since we're students and we just want to enjoy our college experience. While discussing ideas to hack, we realized this problem **resonated with all of us**. We immediately realized that we need to work on this.

## What it does

It gives you and your loved ones a chance to take your safety into your own hands. By using our application, you are taking control of the most important thing you have, your life. It generates the safest and shortest path from Location A to Location B.

## How we built it

We analyzed large data sets of crime over the past 10 years, picked up representative points after weighing them based on relevance and severity of crime. We then created a data anaytics flow (that can be easily repeated with new data) to glean more useful insights from the raw data. To help analyze the data further we plotted the data on Virtual Reality to look at data spreads and densities. This processed data was than pushed into our MongoDB database hosted on MLab. We then used these generalized clusters to see which areas we should avoid while routing using the Wrld and OSRM API's. From here our app generates a single route off of all the information based on what our algorithm devises to be the "safest route" for the user. This route is then plotted and displayed for the users convenience.

## Challenges we ran into

We started out with millions of cells of data, which made it really hard to work with. We had to filter out the most relevant data first and convert the data into a completely new format to optimize it for our path finding algorithm. In addition, we had to optimize our MongoDB to work well with our data as we made frequent queries to a database with originally over a million elements. In, addition, we constantly had issues mixing up latitude and longitude values as well as making HTTP requests for many APIs.

## Accomplishments that we're proud of

We are happy that we were able to create a minimum viable product in this short duration. We're especially glad it's not just a "weekend-only" idea and it is something we can continue to make better. This idea is something we hope in the future can be something that truly has a social impact and can actually make the world a safer place.

## What we learned

* Wrld/OSRM API
* Node/Express/MongoDB
-HTTP Requests/Callback functions
-Unity VR sdk
-Pandas/Numpy
* Coordinating team efforts in different parts of the Application

## What's next for SafeWorld

Using real time data to better predictions for real life incidents (protests). In addition, having more global data sets would be a optimal next step to get it working in more cities. This would be expedited by our adaptable framework for data generation and pathing.
## Inspiration

While we were doing preliminary research, we had found overwhelming amounts of evidence of mental health deterioration as a consequence of life-altering lockdown restrictions. Academic research has shown that adolescents depend on friendship to maintain a sense of self-worth and to manage anxiety and depression. Intimate exchanges and self-esteem support significantly increased long-term self worth and decreased depression.

While people do have virtual classes and social media, some still had trouble feeling close with anyone. This is because conventional forums and social media did not provide a safe space for conversation beyond the superficial. User research also revealed that friendships formed by physical proximity don't necessarily make people feel understood and resulted in feelings of loneliness anyway. Proximity friendships formed in virtual classes also felt shallow in the sense that it only lasted for the duration of the online class.

With this in mind, we wanted to create a platform that encouraged users to talk about their true feelings, and maximize the chance that the user would get heartfelt and intimate replies.

## What it does

Reach is an anonymous forum that is focused on providing a safe space for people to talk about their personal struggles. The anonymity encourages people to speak from the heart. Users can talk about their struggles and categorize them, making it easy for others in similar positions to find these posts and build a sense of closeness with the poster. People with similar struggles have a higher chance of truly understanding each other. Since ill-mannered users can exploit anonymity, there is a tone analyzer that will block posts and replies that contain mean-spirited content from being published while still letting posts of a venting nature through. There is also ReCAPTCHA to block bot spamming.

## How we built it

* Wireframing and Prototyping: Figma
* Backend: Java 11 with Spring Boot
* Database: PostgresSQL
* Frontend: Bootstrap
* External Integration: Recaptcha v3 and IBM Watson - Tone Analyzer
* Cloud: Heroku

## Challenges we ran into

We initially found it a bit difficult to come up with ideas for a solution to the problem of helping people communicate. A plan for a VR space for 'physical' chatting was also scrapped due to time constraints, as we didn't have enough time left to do it by the time we came up with the idea. We knew that forums were already common enough on the internet, so it took time to come up with a product strategy that differentiated us. (Also, time zone issues. The UXer is Australian. They took caffeine pills and still fell asleep.)

## Accomplishments that we're proud of

Finishing it on time, for starters. It felt like we had a bit of a scope problem at the start when deciding to make a functional forum with all these extra features, but I think we pulled it off. The UXer also iterated about 30 screens in total. The Figma file is *messy.*

## What we learned

As our first virtual hackathon, this has been a learning experience for remote collaborative work.
UXer: I feel like i've gotten better at speedrunning the UX process even quicker than before. It usually takes a while for me to get started on things. I'm also not quite familiar with code (I only know python), so watching the dev work and finding out what kind of things people can code was exciting to see.

# What's next for Reach

If this was a real project, we'd work on implementing VR features for those who missed certain physical spaces. We'd also try to work out improvements to moderation, and perhaps a voice chat for users who want to call.