Merge pull request #32 from csc301-winter-2019/master

syncing master and qa

7 files changed, 217 insertions, 70 deletions

diff --git a/deliverables/README.md b/deliverables/README.md
new file mode 100644
index 0000000..753043f
--- /dev/null
+++ b/deliverables/README.md
@@ -0,0 +1,30 @@
+# README
+
+## High Level Description
+Help the Homeless is a web and mobile application that allows homeless shelters to see the locations of homeless people in need of help in real time. Our application consists of two components: a web application and a mobile application for iOS and Android. The web application displays a map that is updated with markers in real time. Each marker shows the location of a homeless person, along with identifying details such as (age, clothing, injured or not, etc.). Markers are displayed on the map whenever a user on the mobile application sends a request for help. The mobile application is intended to be used by the public. It contains a simple form that allows the user to describe the situation to help the outreach workers identify the person in need when responding for help.
+
+## Key Features
+* Users can send their location using the app to report where a homeless person is
+* Users can fill out details about the homeless person before reporting them
+* Users from Street To Homes can view a map and see point markers overlayed on the map which represent where users of the app have submitted locations of homeless people
+* Clicking on a point marker on the map brings up detailed information about the homeless person at that location
+* 'Drop Pin' was not implemented in this iteration, although the button was made and added to our app for future use. This button currently has no functionality, but once fully implemented will allow users to select a location on the map themselves and place a pin there indicating there is a homeless person who requires help.
+
+## Basic instructions
+### Web application
+1. To access the web application, go [here](https://helpthehome-qa.herokuapp.com/map).
+2. Click on a marker on the map to see the details of a homeless person in need.
+3. A detailed box will appear on the top left hand corner containing the person's age range, clothing description, injury status, and reason for help. You can close the box by clicking the close button in the bottom right corner of the details box.
+4. You can zoom in and out by clicking the `+` and `-` button at the top left corner of the map respectively. You can also zoom in and out by scrolling up and down on your mouse/trackpad respectively.
+
+### Mobile application
+1. Ensure your phone supports location services and it is turned on. To enable location services for iPhone see [here](https://support.apple.com/en-ca/HT207092) and Android see [here](https://support.google.com/accounts/answer/3467281?hl=en).
+3. Download the Expo APP [Android](https://play.google.com/store/apps/details?id=host.exp.exponent&hl=en), [iOS](https://itunes.apple.com/us/app/expo-client/id982107779).
+4. Scan the QR code below:
+![](https://i.imgur.com/yuHVrVH.png)
+
+2. When you open the mobile application the greeting page should show up on the screen. Click the `Use Current Location` button.
+> If you see a prompt asking for your location access, press "Allow".
+4. Fill in all the fields on the form with the appropriate information. Although you can leave any field blank, it is **strongly** recommended that you fill in all the fields, as it helps identify the person in need.
+5. When all the information is recorded, click submit. A popup should say that you are being redirected to the main page. When you dismiss the message, you should be redirected to the greeting page.
+6. You should now be able to see your report in the web application.
diff --git a/deliverables/iteration-02.plan.md b/deliverables/iteration-02.plan.md
index 80aa340..913f12e 100644
--- a/deliverables/iteration-02.plan.md
+++ b/deliverables/iteration-02.plan.md
@@ -1,9 +1,5 @@
 # Helpthehomeless by The Dream Team
 
- > _Note:_ This document is meant to be written during (or shortly after) your initial planning meeting.
- > It does not really make sense for you to edit this document much (if at all) while working on the project - Instead, at the end of the planning phase, you can refer back to this document and decide which parts of your plan you are happy with and which parts you would like to change.
-
-
 ## Iteration XX
 
  * Start date: February 15, 2019
@@ -13,13 +9,6 @@
 
 #### Roles & responsibilities
 
-Describe the different roles on the team and the responsibilities associated with each role.
- * Roles should reflect the structure of your team and be appropriate for your project. Not necessarily one role to one team member.
-
-List each team member and:
- * A description of their role(s) and responsibilities including the components they'll work on and non-software related work
- * 3 technical strengths and weaknesses each (e.g. languages, frameworks, libraries, development methodologies, etc.)
-
 
 | Name            | Responsibilities                       | Strengths                    | Weaknesses                     |
 |-----------------|----------------------------------------|------------------------------|--------------------------------|
@@ -28,75 +17,57 @@ List each team member and:
 | Kumar Damani    | Scrum master, server side, API         | web, sql, kanban             | React, graphic design, apps    |
 | Mohammed Ahmed  | "back end", database                   | Java, Kanban, Node.js        | React, Swift, Data Management  |
 | Samarth Agarwal | "back end", database                   | Java, Databases, HTML/CSS    | JavaScript, Node.js, React     |
+|Letian Zhao|"front end"   | Java, JavaScript, SQL  |React, Swift,  App Development  |
+|Xuhao Yu|"back end", integration|js, android, data management| memory, ios, react|
 
-#### Team Rules
+> Note: Letian Zhao and Xuhao Yu ended up dropping the course after this iteration began
 
-Describe your team's working culture.
+#### Team Rules
 
 Communications:
- * What is the expected frequency? What methods/channels are appropriate?
-> We have a slack channel "logistics" where we discuss anything related to scheduling, general communication.
-> Anything related to a task, is discussed in the comment section of the corresponding trello card.
-> Code reviews are discussed in the comment section of the pull request.
-> A github wiki is also maintained for documentation.
-> Frequency is ~3-5 hrs for each of them.
+* We have a slack channel "logistics" where we discuss anything related to scheduling, general communication.
+* Anything related to a task, is discussed in the comment section of the corresponding trello card.
+* Code reviews are discussed in the comment section of the pull request.
+* A github wiki is also maintained for documentation.
+* Frequency is ~3-5 hrs for each of them.
 
 Meetings:
- * How are people held accountable for attending meetings, completing action items? Is there a moderator or process?
-> We hold an in-person sprint meeting every Tuesday and everyone is expected to attend that meeting. We understand that sometimes other commitments might take priority and the person may not be able to attend in-person, so that person can also attend via video chat over Discord.
-> During the meetings, the scrum master goes over each item in the agenda (distributed beforehand). This will involve getting to know what each person has done over the last week, and are currently working on. Readying tasks for the upcoming sprint by ensuring the developer understands exactly what is expected from the task.
+* We hold an in-person sprint meeting every Tuesday and everyone is expected to attend that meeting. We understand that sometimes other commitments might take priority and the person may not be able to attend in-person, so that person can also attend via video chat over Discord.
+* During the meetings, the scrum master goes over each item in the agenda (distributed beforehand). This will involve getting to know what each person has done over the last week, and are currently working on. Readying tasks for the upcoming sprint by ensuring the developer understands exactly what is expected from the task.
 
 Conflict Resolution:
- * List at least three team scenarios/conflicts you discussed in lecture and how you decided you will resolve them. Indecisions? Non-responsive team members? Any other scenarios you can think of?
-> Same as iteration-01, see [here](https://github.com/csc301-winter-2019/project-team-02/blob/master/deliverables/iteration-01.planṃd#conflict-resolution).
+* Same as iteration-01, see [here](https://github.com/csc301-winter-2019/project-team-02/blob/master/deliverables/iteration-01.plan.md).
 
 #### Events
 
-Describe meetings (and other events) you are planning to have:
- * When and where? Recurring or ad hoc? In-person or online?
- > We have mandatory in-person meetings every Tuesday from 3-6 pm inside a booked study room at the Gerstein Library. We have an online meeting on Fridays from 4-6 pm if needed.
- * What's the purpose of each meeting?
- > The purpose of each meeting is to determine what everybody has done over the previous week and what tasks need to be worked on for the upcoming week.
+ * We have mandatory in-person meetings every Tuesday from 3-6 pm inside a booked study room at the Gerstein Library. We have an online meeting on Fridays from 4-6 pm if needed.
+ * The purpose of each meeting is to determine what everybody has done over the previous week and what tasks need to be worked on for the upcoming week.
  * Other events could be coding sessions, code reviews, quick weekly sync meeting online, etc.
 
-> Same as iteration-01, see [here](https://github.com/csc301-winter-2019/project-team-02/blob/master/deliverables/iteration-01.planṃd#conflict-resolution).
-
 #### Artifacts
 
-List/describe the artifacts you will produce in order to organize your team.
-
- * Artifacts can be To-Do lists, Task boards, schedule(s), etc.
-   * A snapshot of the Trello board to keep track of our tasks:
+* A snapshot of the Trello board to keep track of our tasks:
 ![snapshot of trello board](https://i.imgur.com/iFWRP3n.jpg)
 
-   * Link to the [wiki](https://github.com/csc301-winter-2019/project-team-02/wiki) home page. You can see the various pages we've added in the sidebar.
-   * A snapshot of the Slack channel "meetingnotes" where we post meeting agendas and notes from a meeting:
+* Link to the [wiki](https://github.com/csc301-winter-2019/project-team-02/wiki) home page. You can see the various pages we've added in the sidebar.
+* A snapshot of the Slack channel "meetingnotes" where we post meeting agendas and notes from a meeting:
 ![](https://i.imgur.com/kb0uqMJ.png)
 
- * We want to understand:
-   * How do you keep track of what needs to get done?
-     > We create a Trello card in the backlog column
-   * How do you prioritize tasks?
-     > Tasks at the top of the Backlog column are the highest priority. These are the tasks necessary to have a MVP. So fancy UI elements will get de-prioritized in place of business logic tasks.
-   * How do tasks get assigned to team members?
-      > We want everyone to contribute so those who did not contribute much the previous week will get priority at the upcoming tasks. They can pick whatever task they feel they can complete in that week from the Ready for Work column.
 
+To keep track of what needs to get done, we create a Trello card in the backlog column. Tasks at the top of the Backlog column are the highest priority. These are the tasks necessary to have a MVP. So fancy UI elements will get de-prioritized in place of business logic tasks.
 
-#### Deployment and Github Workflow
+We want everyone to contribute so those who did not contribute much the previous week will get priority at the upcoming tasks. They can pick whatever task they feel they can complete in that week from the Ready for Work column.
 
-Describe your Git / GitHub workflow. Essentially, we want to understand how your team members shares a codebase, avoid conflicts and deploys the application.
 
+#### Deployment and Github Workflow
 
- * Be concise, yet precise. For example, "we use pull-requests" is not a precise statement since it leaves too many open questions - Pull-requests from where to where? Who reviews the pull-requests? Who is responsible for merging them? etc.
 
 >You can view the detailed description in our repo wiki page [Development Workflow](https://github.com/csc301-winter-2019/project-team-02/wiki/Development-Worklfow) for how our Trello board connects to github and our "process".
 
 > We have a specific page for dealing with code conflicts in our wiki page [Resolving-Code-Conflicts](https://github.com/csc301-winter-2019/project-team-02/wiki/Resolving-Code-Conflicts)
 
- * If applicable, specify any naming conventions or standards you decide to adopt.
-> Naming of branches reflect the Trello card no. found in the url. Branches begin with either "feat" or "fix" depending on the Trello label, followed by the card no. For eg, feat/4.
+* Naming of branches reflect the Trello card no. found in the url. Branches begin with either "feat" or "fix" depending on the Trello label, followed by the card no. For eg, feat/4.
 
- * Describe your overall deployment process from writing code to viewing a live application
 >TL;DR
 
  1. Developer pushes a feature to their branch.
@@ -104,12 +75,14 @@ Describe your Git / GitHub workflow. Essentially, we want to understand how your
  3. Another team member will test it in the qa environment and decide if it is good enough. If good enough, the tester will move the trello card into "Ready for Release" column.
  4. The developer will then create the pull request from their branch into `master` without needing any reviewers, and complete the merge.
  5. They will then deploy it to a production environment and self test that everything is okay.
- * What deployment tool(s) are you using and why
-> Expo for deploying to mobile. It allows us to write the same code for android and ios.
-> Heroku for deploying to the web. It has a nice integration with git, and works well with our tech. stack.
- * Don't forget to **explain why** you chose this workflow or particular aspects of it!
-> We chose this workflow so that each feature/fix is separated into its own branch so that it is easier to apply filters in the future.
-> We deploy to `qa` first so that the `master` branch always has code that is ready to be deployed after it has been thoroughly tested in the `qa` branch among other developing features. This minimizes the likelihood that once we do merge to `master`, nothing *existing* will break.
+
+ * Deployment
+   * Expo for deploying to mobile. It allows us to write the same code for android and ios.
+   * Heroku for deploying to the web. It has a nice integration with git, and works well with our tech. stack.
+
+We chose this workflow so that each feature/fix is separated into its own branch so that it is easier to apply filters on GitHub in the future to find features.
+
+We deploy to `qa` first so that the `master` branch always has code that is ready to be deployed after it has been thoroughly tested in the `qa` branch among other developing features. This minimizes the likelihood that once we do merge to `master`, nothing *existing* will break.
 
 
 
@@ -117,22 +90,13 @@ Describe your Git / GitHub workflow. Essentially, we want to understand how your
 
 #### Goals and tasks
 
- * Describe your goals for this iteration and the tasks that you will have to complete in order to achieve these goals.
- * Order the items from most to least important.
- * Feel free (but not obligated) to specify some/all tasks as user stories.
-
- >1. Have the mobile send its location to the server.
- >2. Have a website display all locations ever sent on first page load on a map.
- >3. A new mobile request gets added to the website without a page reload.
+1. Have the mobile send its location to the server.
+2. Have a website display all locations ever sent on first page load on a map.
+3. A new mobile request gets added to the website without a page reload.
 
 #### Artifacts
 
 List/describe the artifacts you will produce in order to present your project idea.
 
- * Artifacts can be text, code, images, videos, interactive mock-ups and/or any other useful artifact you can think of.
- * Make sure to explain the purpose of each artifact (i.e. Why is it on your to-do list? Why is it useful for your team?)
- * Be concise, yet precise.
-   For example: "Build the website" is not precise at all, but "Build a static home page and upload it somewhere, so that it is publicly accessible" is much clearer.
-
- > A video/screencast of the mobile sending its location to the server.
- > A video/screencast of the website live updating by adding a new marker on the map based on the new request.
+* A video/screencast of the mobile sending its location to the server.
+* A video/screencast of the website live updating by adding a new marker on the map based on the new request.
diff --git a/deliverables/iteration-02.review.md b/deliverables/iteration-02.review.md
new file mode 100644
index 0000000..eb0d4c6
--- /dev/null
+++ b/deliverables/iteration-02.review.md
@@ -0,0 +1,56 @@
+# Helpthehomeless by The Dream Team
+
+## Iteration 2 - Review & Retrospect
+
+ * When: March 8, 2019
+ * Where: BA 3195
+
+## Process - Reflection
+
+#### Decisions that turned out well
+
+1. One process-related decision that turned out to be sucessful was our weekly meetings on Tuesday. These meetings allowed us to review what each member did the previous week and assign tasks for what each member had to do the coming week.
+
+
+2. Another process-related decision that turned out to be successful was using the Trello board to manage tasks. This allowed all the members to see the status of tasks so that people don't end up doing the same thing by mistake. Trello also allowed us to flesh out the details of what is expected from a task by defining an "Acceptance Criteria" (insert acceptance criteria sample from Trello).
+![](https://i.imgur.com/XrRxlji.png)
+
+3. Using Slack as our primary communication channel was a good decision as Slack makes several auxiliary tasks easier. With Slack we can easily create and keep track of communication channels that each serve a specific purpose, and record communications that we would need as artifacts (e.g. meetingnotes channel)
+![](https://i.imgur.com/Mor4nys.jpg)
+
+
+#### Decisions that did not turn out as well as we hoped
+
+1. Code reviews were expected to be thorough but ended up being blindly approved. Considering that none of us are fully familiar with all the tools we are using, people weren't equipped to thoroughly review code.
+2. A lot of the time we had conflicts when trying to merge our code because the master branch was too far behind where we were trying to merge. This is because the testing process was very arbitrary so a lot of tasks were sitting idle untested. This is important so that all of us can get to know how the entire app works, and get experience with all the tools.
+3. In the beginning, we decided to split into web and mobile sub teams. However, this resulted in a clear gap between people working on mobile vs. web. People from the web team were unaware of what was going on with what the mobile team was doing and vice versa. As a result, time was wasted during weekly meetings when discussing our weekly progress, as team members had to explain the work that they did to team members who were unfamiliar.
+
+#### Planned changes
+
+1. Since all the team members were not fully familiar with the code they were reviewing, we decided that only the team members who are actively involved in that particular part of development should review the code. For example, if a pull request was created that contained changes to the mobile application, then only Andrew and Fahim need to review it since they worked the most on mobile.
+2. Because the master branch was always behind the qa branch, we came up with the decision to reserve 30-45 minutes during our weekly Tuesday meeeting to test the qa branch and update the master branch. Another approach we are thinking of is to schedule a 1 hour meeting on another day and dedicate it to perform testing and update the master branch. We have a testing heroku application deployed just for testing. Our testing strategy will be to update the testing app with the qa branch and perform manual testing to see if the functionality is correct. Once we verify that the application works as expected, we will merge the qa branch into master.
+3. To address the issue of disconnect between sub teams, we plan on switching the roles for the next iteration, so the people who worked on mobile will now work on web, and vice versa. This will allow team members to better understand different parts of the application and save us time during our weekly updates, as it eliminates the confusion unfamiliar parts.
+
+## Product - Review
+
+#### Goals and/or tasks that were met/completed:
+
+1. Mobile app sends its location to the server.
+2. Website displays all locations ever sent on first page load on a map.
+3. A new mobile request gets added to the website without a page reload.
+
+![](https://i.imgur.com/xOUL71r.jpg)
+> Note the tasks in the "Done" column.
+
+#### Goals and/or tasks that were planned but not met/completed:
+
+ All planned tasks were completed (with minor bugs).
+
+## Meeting Highlights
+
+Going into the next iteration, our main insights are:
+
+1. For the most part, the status quo is fine as we did manage to meet all our goals from the plan.
+2. In our final meeting, we discovered a few minor bugs in features of the application that were completed some time ago. In the future, edge-cases should be tested before claiming that a feature is complete.
+3. Having a scheduled testing day or reserving a testing time during our weekly Tuesday meeting will be helpful in avoiding conflicts and keep the master up to date.
+4. We feel that our application is lacking documentation. We will focus more on writing more documentation on the features of our application and how to use our application.
diff --git a/mock_data/README.md b/mock_data/README.md
new file mode 100644
index 0000000..edd5445
--- /dev/null
+++ b/mock_data/README.md
@@ -0,0 +1,14 @@
+# This file contains information about how we populated the database with existing points for development and testing purposes.
+
+CSV file generated using https://www.mapdevelopers.com/geocode_tool.php and manually clicking various parts of the city to give us coordinates of those points.
+
+Then the python script `gen_geojson.py` created json objects and pushed it up to the database to populate the `dumbpointscollection`.
+
+Then the scripts also reads this from the database and dumps into a .json file. Cuz why not?
+
+> DO NOT RUN THIS FILE ON ACTUAL DATABASE WITHOUT CREATING A BACKUP FIRST. You can change the db used by un/commenting out the line where the uri is passed into the `MongoClient` on line 6 and 7.
+
+# Requirements to run the python script
+
+1. pymongo
+2. dnspython
diff --git a/mock_data/out/dumbdata.json b/mock_data/out/dumbdata.json
new file mode 100644
index 0000000..01ac9ba
--- /dev/null
+++ b/mock_data/out/dumbdata.json
@@ -0,0 +1 @@
+[{"_id": {"$oid": "5c723c241bc4ab6d80ee05be"}, "type": "Point", "coordinates": [-79.3787224, 43.7179786], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05bf"}, "type": "Point", "coordinates": [-79.3871596, 43.7213548], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c0"}, "type": "Point", "coordinates": [-79.3837533, 43.712758], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c1"}, "type": "Point", "coordinates": [-79.4209714, 43.7037593], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c2"}, "type": "Point", "coordinates": [-79.4505764, 43.6909183], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c3"}, "type": "Point", "coordinates": [-79.4286938, 43.6776278], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c4"}, "type": "Point", "coordinates": [-79.4258082, 43.6628024], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c5"}, "type": "Point", "coordinates": [-79.4166619, 43.6546241], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c6"}, "type": "Point", "coordinates": [-79.391236, 43.647069], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c7"}, "type": "Point", "coordinates": [-79.389838, 43.647169], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c8"}, "type": "Point", "coordinates": [-79.390199, 43.647322], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05c9"}, "type": "Point", "coordinates": [-79.3815339, 43.6486639], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05ca"}, "type": "Point", "coordinates": [-79.3815339, 43.6486639], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05cb"}, "type": "Point", "coordinates": [-79.3815339, 43.6486639], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05cc"}, "type": "Point", "coordinates": [-79.376619, 43.650907], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05cd"}, "type": "Point", "coordinates": [-79.381407, 43.659324], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05ce"}, "type": "Point", "coordinates": [-79.3808212, 43.6614691], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05cf"}, "type": "Point", "coordinates": [-79.38024, 43.663758], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05d0"}, "type": "Point", "coordinates": [-79.4103483, 43.6426436], "another": "random field"}, {"_id": {"$oid": "5c723c241bc4ab6d80ee05d1"}, "type": "Point", "coordinates": [-79.416122, 43.650337], "another": "random field"}]
\ No newline at end of file
diff --git a/mock_data/raw/dumb_coordinates.csv b/mock_data/raw/dumb_coordinates.csv
new file mode 100644
index 0000000..4bfad6b
--- /dev/null
+++ b/mock_data/raw/dumb_coordinates.csv
@@ -0,0 +1,21 @@
+lat,lon
+43.7179786, -79.3787224
+43.7213548, -79.3871596
+43.712758, -79.3837533
+43.7037593, -79.4209714
+43.6909183, -79.4505764
+43.6776278, -79.4286938
+43.6628024, -79.4258082
+43.6546241, -79.4166619
+43.647069, -79.391236
+43.647169, -79.389838
+43.647322, -79.390199
+43.6486639, -79.3815339
+43.6486639, -79.3815339
+43.6486639, -79.3815339
+43.650907, -79.376619
+43.659324, -79.381407
+43.6614691, -79.3808212
+43.663758, -79.38024
+43.6426436, -79.4103483
+43.650337, -79.416122
diff --git a/mock_data/scripts/gen_geojson.py b/mock_data/scripts/gen_geojson.py
new file mode 100644
index 0000000..33c5c98
--- /dev/null
+++ b/mock_data/scripts/gen_geojson.py
@@ -0,0 +1,61 @@
+from pymongo import MongoClient
+from bson.json_util import dumps
+import json
+import csv
+
+client = MongoClient('mongodb://localhost:27017/helpthehome')
+#client = MongoClient('mongodb+srv://development:dreamteam@cluster0-krnr4.mongodb.net/helpthehome?retryWrites=true')
+db = client.helpthehome
+
+def read_coords_csv():
+    points = []
+    with open("../raw/dumb_coordinates.csv") as csvfile:
+        reader = csv.reader(csvfile, delimiter=",")
+        line_number = 0
+        for row in reader:
+            if line_number == 0:
+                line_number += 1
+                continue
+
+            # build in accordance with geojson www.geojson.org
+            points.append({
+                    "type": "Point",
+                    "coordinates" : [ float(row[1]), float(row[0]) ],
+                    "another": "random field"
+            })
+            line_number += 1
+        return points
+
+# into db
+def insert_data(points):
+    print("WRITING to DB...")
+    for point in points:
+        result = db.dumbpointscollection.insert_one(point)
+
+# from the db - not necessary
+def find_data():
+    print("READING from DB...")
+    points = db.dumbpointscollection.find({})
+    return dumps(points)
+
+# not necessary
+def serialize(data, jfilepath):
+    jdata = find_data()
+    print("WRITING to FILE...")
+    with open("../out/dumbdata.json", "w+") as outfile:
+        outfile.write(jdata)
+
+# load serialized data - not necessary
+def read_data_json(jfilepath):
+    print("READING from FILE...")
+    with open(jfilepath, "r") as infile:
+        jdata = json.load(infile)
+        return jdata
+
+##### Execute functions here #####
+#points = read_coords_csv()
+#insert_data(points)
+jdata = find_data()
+serialize(jdata, '../out/dumbdata.json')
+
+#jdata = read_data_json('../out/dumbdata.json')