merge from datagenerator branch

.dockerignore

@@ -0,0 +1,9 @@
+node_modules
+npm-debug.log
+channels_subscribers.csv
+notes.txt
+users.csv
+videoids.csv
+videos.csv
+psqlHelp.txt
+dump.rdb

.editorconfig

@@ -0,0 +1,21 @@
+# EditorConfig helps developers define and maintain consistent
+# coding styles between different editors and IDEs
+# editorconfig.org
+
+root = true
+
+
+[*]
+
+# Change these settings to your own preference
+indent_style = space
+indent_size = 2
+
+# We recommend you to keep these unchanged
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.md]
+trim_trailing_whitespace = false

.eslintrc.js

@@ -0,0 +1,45 @@
+/**
+ * These rules enforce Hack Reactor's style guide.
+ * Visit this repo for more information:
+ *   https://github.com/reactorcore/eslint-config-hackreactor
+ */
+
+module.exports = {
+  env: {
+    'es6': true
+  },
+  parserOptions: {
+    ecmaVersion: 6,
+    sourceType: "module",
+    ecmaFeatures: {
+      'jsx': true
+    }
+  },
+  rules: {
+    /* Indentation */
+    'no-mixed-spaces-and-tabs': 2,
+    'indent': [2, 2],
+    /* Language constructs */
+    'curly': 2,
+    'eqeqeq': [2, 'smart'],
+    'func-style': [2, 'expression'],
+    /* Semicolons */
+    'semi': 2,
+    'no-extra-semi': 2,
+    /* Padding & additional whitespace (perferred but optional) */
+    'brace-style': [2, '1tbs', { 'allowSingleLine': true }],
+    'semi-spacing': 1,
+    'key-spacing': 1,
+    'block-spacing': 1,
+    'comma-spacing': 1,
+    'no-multi-spaces': 1,
+    'space-before-blocks': 1,
+    'keyword-spacing': [1, { 'before': true, 'after': true }],
+    'space-infix-ops': 1,
+    /* Variable declaration */
+    'one-var': [1, { 'uninitialized': 'always', 'initialized': 'never' }],
+    /* Minuta */
+    'comma-style': [2, 'last'],
+    'quotes': [1, 'single']
+  }
+};

.gitignore

@@ -0,0 +1,39 @@
+# Project specific
+config/development.json
+config/production.json
+config/staging.json
+config/test.json
+psqlHelp.txt
+notes.txt
+
+# OS X
+.DS_Store
+
+# Logs
+logs
+*.log
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.rdb
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+
+# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Compiled Dirs (http://nodejs.org/api/addons.html)
+build/
+dist/
+
+# Dependency directorys
+# Deployed apps should consider commenting these lines out:
+# see https://npmjs.org/doc/faq.html#Should-I-check-my-node_modules-folder-into-git
+node_modules/
+bower_components/

CONTRIBUTING.md

@@ -0,0 +1,145 @@
+# Contributing
+
+## General Workflow
+
+1. Cut a namespaced feature branch from master
+1. Make commits to your feature branch.
+1. When you've finished with your fix or feature, Rebase changes from master into your branch. Submit a pull request directly to master. Include a description of your changes.
+1. Your pull request will be reviewed by another team member. The point of code reviews is to help keep the codebase clean and of high quality and, equally as important, to help you grow as a programmer. If your code reviewer requests you make a change you don't understand, ask them why.
+1. Fix any issues raised by your code reviwer, and push your fixes as a single new commit.
+1. Once the pull request has been reviewed, you may merge it.
+
+## Detailed Workflow
+
+### Cut a namespaced feature branch from master
+
+Your branch should follow this naming convention:
+  - bug/...
+  - feat/...
+  - test/...
+  - doc/...
+  - refactor/...
+
+These commands will help you do this:
+
+``` bash
+
+# Creates your branch and brings you there
+git checkout -b `your-branch-name`
+```
+
+### Make commits to your feature branch. 
+
+Prefix each commit like so
+  - (feat) Add a new feature
+  - (fix) Fix inconsistent tests [Fixes #0]
+  - (refactor) ...
+  - (cleanup) ...
+  - (test) ...
+  - (doc) ...
+
+Make changes and commits on your branch, and make sure that you
+only make changes that are relevant to this branch. If you find
+yourself making unrelated changes, make a new branch for those
+changes.
+
+#### Commit Message Guidelines
+
+- Commit messages should be written in the present tense; e.g. "Fix continuous integration script".
+- The first line of your commit message should be a brief summary of what the commit changes. Aim for about 70 characters max. Remember: This is a summary, not a detailed description of everything that changed.
+- If you want to explain the commit in more depth, following the first line should be a blank line and then a more detailed description of the commit. This can be as detailed as you want, so dig into details here and keep the first line short.
+
+### Rebase changes from master into your branch
+
+This is generally useful only if you are working on multiple features simulatenously. Since you are the primary (and only) commiter on your repo, you may be able to skip this step if you are working on features sequentially.
+
+Once you are done working on your feature, you can begin the process of getting
+your code merged into the master branch. Step 1 is to rebase
+changes from the master branch into your feature branch by running this command
+from your branch:
+
+```bash
+git rebase master
+```
+
+This will start the rebase process. You must commit all of your changes
+before doing this. If there are no conflicts, this should just roll all
+of your changes back on top of the changes from master, leading to a
+nice, clean, linear commit history.
+
+If there are conflicting changes, git will start yelling at you part way
+through the rebasing process. Git will pause rebasing to allow you to sort
+out the conflicts. You do this the same way you solve merge conflicts,
+by checking all of the files git says have been changed in both histories
+and picking the versions you want. Be aware that these changes will show
+up in your pull request, so try and incorporate changes from master as much
+as possible.
+
+You pick a file by `git add`ing it - you do not make commits during a
+rebase.
+
+Once you are done fixing conflicts for a specific commit, run:
+
+```bash
+git rebase --continue
+```
+
+This will continue the rebasing process. Once you are done fixing all
+conflicts you should run the existing tests to make sure you didn’t break
+anything, then run your new tests (there are new tests, right?) and
+make sure they work also.
+
+If rebasing broke anything, fix it, then repeat the above process until
+you get here again and nothing is broken and all the tests pass.
+
+### Make a pull request
+
+Make a clear pull request from your fork and branch to the master
+branch, detailing exactly what changes you made and what feature this
+should add. The clearer your pull request is the faster you can get
+your changes incorporated into this repo.
+
+At least one other person MUST give your changes a code review, and once
+they are satisfied they will merge your changes into master. Alternatively,
+they may have some requested changes. You should make more commits to your
+branch to fix these, then follow this process again from rebasing onwards.
+
+Once you get back here, make a comment requesting further review and
+someone will look at your code again. If they like it, it will get merged,
+else, just repeat again.
+
+Thanks for contributing!
+
+### Guidelines
+
+1. Uphold the current code standard:
+    - Keep your code [DRY][].
+    - Apply the [boy scout rule][].
+    - Follow [STYLE-GUIDE.md](_STYLE-GUIDE.md)
+1. Run the [tests][] before submitting a pull request.
+1. Tests are very, very important. Submit tests if your pull request contains
+   new, testable behavior.
+
+## Checklist:
+
+This is just to help you organize your process
+
+- [ ] Did I cut my work branch off of master (don't cut new branches from existing feature brances)?
+- [ ] Did I follow the correct naming convention for my branch?
+- [ ] Is my branch focused on a single main change?
+  - [ ] Do all of my changes directly relate to this change?
+- [ ] Did I rebase the master branch after I finished all my
+  work?
+- [ ] Did I write a clear pull request message detailing what changes I made?
+- [ ] Did I get a code review?
+  - [ ] Did I make any requested changes from that code review?
+
+If you follow all of these guidelines and make good changes, you should have
+no problem getting your changes merged in.
+
+
+<!-- Links -->
+[style guide]: https://github.com/reactorcore/style-guide
+[curriculum workflow diagram]: http://i.imgur.com/p0e4tQK.png
+[Git Flow]: http://nvie.com/posts/a-successful-git-branching-model/
+[GitHub Flow]: http://scottchacon.com/2011/08/31/github-flow.html

Dockerfile

@@ -0,0 +1,18 @@
+FROM node:alpine
+
+WORKDIR /usr/src/app
+
+COPY package*.json ./
+
+RUN apk add --no-cache --virtual .gyp \
+        python \
+        make \
+        g++ \
+    && npm install \
+    && apk del .gyp
+
+COPY . .
+
+EXPOSE 3000
+
+CMD [ "npm", "start" ]

README.md

@@ -1,2 +1,35 @@
-# tz-inventory
-TZ Services to CRUD video listings, subscriptions, and users.
+# Project Name
+
+The project description
+
+## Roadmap
+
+View the project roadmap [here](LINK_TO_DOC)
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for contribution guidelines.
+
+# Table of Contents
+
+1. [Usage](#Usage)
+1. [Requirements](#requirements)
+1. [Development](#development)
+    1. [Installing Dependencies](#installing-dependencies)
+    1. [Tasks](#tasks)
+
+## Usage
+
+> Some usage instructions
+
+## Requirements
+
+- Node 6.9.x
+- Redis 3.2.x
+- Postgresql 9.6.x
+- etc
+
+## Other Information
+
+(TODO: fill this out with details about your project. Suggested ideas: architecture diagram, schema, and any other details from your app plan that sound interesting.)
+