## Inspiration

Our inspiration came from the famous subreddit r/place.

## What it does

Git-place is an interactive pixel art page on a GitHub repository. Anyone with a GitHub account can create pixel art on our projects README file.

## How we built it

The application was built using JavaScript, node, GitHub actions, GitHub issues, and GitHub itself.

## Challenges we ran into

Since we were utilizing GitHub actions as our main source of change within the repo itself, a challenge we faced was to test our code after pushing to our main branch. That made it difficult for us to predict the errors that would come with the changes, and made it so thorough testing was required.
We also faced some issues with learning about the differences between server-side java script and client-side JavaScript, which made it so some packages had to be utilized in different ways to be used properly.

## Accomplishments that we're proud of

We are very proud to have correctly utilized GitHub actions, as well as integrate automated repository changes as a main part of the flow of our system. Making a project that anybody on GitHub can use also made us feel good about our work at Hack Western, since it pushed us to learn more about sides of tech we did not know much about.

## What we learned

Working on this project taught we learned all kinds of things that we didn't know GitHub was capable of. Before starting this project neither of us had ever even created a GitHub issue. To make the project update and commit by itself we had to learn to create GitHub actions. We needed to learn how to control a Github action using yml.

## What's next for Git-place

Some future steps for Git-place are adding more colours that can be added to the canvas as well as making the program faster and able to handle more requests simultaneously.
## Inspiration

We thought it would be nice if, for example, while working in the Computer Science building, you could send out a little post asking for help from people around you.

Also, it would also enable greater interconnectivity between people at an event without needing to subscribe to anything.

## What it does

Users create posts that are then attached to their location, complete with a picture and a description. Other people can then view it two ways.

**1)** On a map, with markers indicating the location of the post that can be tapped on for more detail.

**2)** As a live feed, with the details of all the posts that are in your current location.

The posts don't last long, however, and only posts within a certain radius are visible to you.

## How we built it

Individual pages were built using HTML, CSS and JS, which would then interact with a server built using Node.js and Express.js. The database, which used cockroachDB, was hosted with Amazon Web Services. We used PHP to upload images onto a separate private server. Finally, the app was packaged using Apache Cordova to be runnable on the phone. Heroku allowed us to upload the Node.js portion on the cloud.

## Challenges we ran into

Setting up and using CockroachDB was difficult because we were unfamiliar with it. We were also not used to using so many technologies at once.
## Inspiration

We wanted to learn about machine learning. There are thousands of sliding doors made by Black & Decker and they're all capable of sending data about the door. With this much data, the natural thing to consider is a machine learning algorithm that can figure out ahead of time when a door is broken, and how it can be fixed. This way, we can use an app to send a technician a notification when a door is predicted to be broken. Since technicians are very expensive for large corporations, something like this can save a lot of time, and money that would otherwise be spent with the technician figuring out if a door is broken, and what's wrong with it.

## What it does

DoorHero takes attributes (eg. motor speed) from sliding doors and determines if there is a problem with the door. If it detects a problem, DoorHero will suggest a fix for the problem.

## How we built it

DoorHero uses a Tensorflow Classification Neural Network to determine fixes for doors. Since we didn't have actual sliding doors at the hackathon, we simulated data and fixes. For example, we'd assign high motor speed to one row of data, and label it as a door with a problem with the motor, or we'd assign normal attributes for a row of data and label it as a working door.

The server is built using Flask and runs on [Floydhub](https://floydhub.com). It has a Tensorflow Neural Network that was trained with the simulated data. The data is simulated in an Android app. The app generates the mock data, then sends it to the server. The server evaluates the data based on what it was trained with, adds the new data to its logs and training data, then responds with the fix it has predicted.

The android app takes the response, and displays it, along with the mock data it sent.

In short, an Android app simulates the opening and closing of a door and generates mock data about the door, which is sends everytime the door "opens", to a server using a Flask REST API. The server has a trained Tensorflow Neural Network, which evaluates the data and responds with either "No Problems" if it finds the data to be normal, or a fix suggestion if it finds that the door has an issue with it.

## Challenges we ran into

The hardest parts were:

* Simulating data (with no background in sliding doors, the concept of sliding doors sending data was pretty abstract).
* Learning how to use machine learning (turns out this isn't so easy) and implement tensorflow
* Running tensorflow on a live server.

## Accomplishments that we're proud of

## What we learned

* A lot about modern day sliding doors
* The basics of machine learning with tensorflow
* Discovered floydhub

## What we could have improve on

There are several things we could've done (and wanted to do) but either didn't have time or didn't have enough data to. ie:

* Instead of predicting a fix and returning it, the server can predict a set of potential fixes in order of likelihood, then send them to the technician who can look into each suggestion, and select the suggestion that worked. This way, the neural network could've learned a lot faster over time. (Currently, it adds the predicted fix to its training data, which would make for bad results
* Instead of having a fixed set of door "problems" for the door, we could have built the app so that in the beginning, when the neural network hasn't learned yet, it asks the technician for input after everytime the fix the door (So it can learn without data we simulated as this is what would have to happen in the normal environment)
* We could have made a much better interface for the app
* We could have added support for a wider variety of doors (eg. different models of sliding doors)
* We could have had a more secure (encrypted) data transfer method
* We could have had a larger set of attributes for the door
* We could have factored more into decisions (for example, detecting a problem if a door opens, but never closes).