MoHugs is aimed at helping men form new social connections in an easy and practical way by using a physical device located in common local spaces (like coffee shops) and a website that allows men to engage with the service. It is a discrete service that informs men of other sympathetic individuals located in the shared space that are open to having a conversation and forming new social connection.
Our team consisted of Adam Smith, Conal McLaughlin, David Warren, Kyle Harrison, and Krzysztof Ignasiak. The implementation of our idea can be broken down into 3 components; UI, API, and IoT Device.
Implementing the UIIn a Hackathon using a framework can be a blessing and a curse; we decided to use Angular whilst opting to keep the directory structure simple. Making the conscious decision to avoid using unnecessary dependencies allowed us to avoid entering dependency hell. Ultimately, we only needed 4 HTML templates, Bootstrap, custom CSS, 2 images, and our app.j
containing all that MVC goodness to make our idea a reality!
├── Mustache.jpg
├── app.css
├── app.js
├── beans.jpg
├── bootstrap.css
├── index.html
├── locations.html
├── posts.html
└── select.html
We will be the first to admit our project is not a scalable solution, nor is it close to perfect however it was the optimum solution for the Hackathon and avoided unnecessary complexity.
The final piece of the ‘UI’ puzzle was hosting the UI during development and on the day. Setting up a complete web server (such as Apache) was overkill for our needs, time consuming, and simply not fast enough for rapid development and deployment. We opted to use a simple python HTTP server enabling the entire team to host our website locally whilst avoiding installation of a web server. A team member could jump on-board and test the UI easily using the following 4 commands.
git clone https://github.com/belfastcares/mo-hugs-ui
cd mo-hugs-ui
python -m SimpleHTTPServer 8000
open http://localhost:8000
Implementing the REST ServiceIdentifying several endpoints required by the application allowed us to rapidly develop the endpoints whilst the UI was being developed. Initially we mocked these endpoints via Mockable to return a predefined JSON response until we were ready to switch to the live Django service running on Heroku.
The prerequisites for deploying our Django REST service to Heroku were minimal. Once our code was hosted on Github, the only requirement was to add a Procfile to our repository, and provide the appropriate Github credentials to Heroku to allow it to poll the repository for commits to trigger a new build. This give us continuous deployment with minimal effort! To find our more on how to do this in your own project, check this out.
All locations consists of events, in which a user can check in/check out. Whilst checked into an event, a user can view the posts and add a post to that physical location.
The following endpoints provided all the functionality required by the application:
GET /GetLocations
GET /StartEvent/:location_id
GET /CheckIn/:location_id
GET /CheckOut/:location_id
GET /Posts/:location_id
POST /Posts/:location_id Body ={username: user, message: “Some Text Here”}
Of course, no project is ever without issues and the biggest issue we faced with that all too common CORS nightmare! To resolve this, we had to install the Django module via our requirements.txt
and configure it within settings.py
to allow CORS headers. Alternatively we could have used a simple chrome plugin that adds a CORS header to all requests. If the installation and deployment of a new dependency to our API hadn’t of been as simple as it was, the chrome plugin would have saved a large amount of time.
Equipped with the the Intel Edison board and the Grove starter kit (designed for rapid prototyping) we created a device what allowed a user to press a button to active a locate, and whilst it was active a light would stay active.
The schema for the device is pictured as follows:
This was implemented using a simple Python script that would POST a request to our API service and active the light. During the Hackathon, there was very little time to consider what the device causing would look like however we briefly discussed a box type design and displaying information on the casing explaining the cause and the usage of the device.
Developing the idea to fruition within 12 hours was a challenge however we believe it provided validation that the idea could work. The idea, source code, and little documentation that exists are all freely available on Github. The implementation from the Hackathon can be found unchanged on Github using the MoHack-Hackathon release tag at the following repositories:
Some screenshots of our application can be seen below but to experience it properly, check out the UI repo and try it out for yourself!
Comments