Initial Project Files from HR

Author: codydaig

.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

.gitignore

@@ -0,0 +1,31 @@
+### node etc ###
+
+# Logs
+logs
+*.log
+
+# Runtime data
+pids
+*.pid
+*.seed
+
+# 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/
+
+.DS_STORE

.jshintrc

@@ -0,0 +1,21 @@
+{
+    "node": true,
+    "esnext": true,
+    "bitwise": true,
+    "camelcase": true,
+    "curly": true,
+    "eqeqeq": true,
+    "immed": true,
+    "indent": 2,
+    "latedef": true,
+    "newcap": true,
+    "noarg": true,
+    "quotmark": "single",
+    "regexp": true,
+    "undef": true,
+    "unused": true,
+    "strict": true,
+    "trailing": true,
+    "smarttabs": true,
+    "white": true
+}

.travis_yml

@@ -0,0 +1,6 @@
+language: node_js
+node_js:
+  - '0.8'
+  - '0.10'
+  - '0.12'
+  - 'iojs'

CONTRIBUTING.md

@@ -0,0 +1,181 @@
+# Contributing
+
+## General Workflow
+
+1. Fork the repo
+1. Cut a namespaced feature branch from master
+  - bug/...
+  - feat/...
+  - test/...
+  - doc/...
+  - refactor/...
+1. Make commits to your feature branch. Prefix each commit like so:
+  - (feat) Added a new feature
+  - (fix) Fixed inconsistent tests [Fixes #0]
+  - (refactor) ...
+  - (cleanup) ...
+  - (test) ...
+  - (doc) ...
+1. When you've finished with your fix or feature, Rebase upstream changes 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 maintainer. 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, it will be merged by another member of the team. Do not merge your own commits.
+
+## Detailed Workflow
+
+### Fork the repo
+
+Use github’s interface to make a fork of the repo, then add that repo as an upstream remote:
+
+```
+git remote add upstream https://github.com/hackreactor-labs/<NAME_OF_REPO>.git
+```
+
+### 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) Added a new feature
+  - (fix) Fixed 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 upstream changes into your branch
+
+Once you are done making changes, you can begin the process of getting
+your code merged into the main repo. Step 1 is to rebase upstream
+changes to the master branch into yours by running this command
+from your branch:
+
+```bash
+git pull --rebase upstream 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 upstream, 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 upstream changes 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 upstream 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 upstream. 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.
+1. Your pull request is comprised of a single ([squashed][]) commit.
+
+## 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 upstream 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/hackreactor-labs/style-guide
+[n-queens]: https://github.com/hackreactor-labs/n-queens
+[Underbar]: https://github.com/hackreactor-labs/underbar
+[curriculum workflow diagram]: http://i.imgur.com/p0e4tQK.png
+[cons of merge]: https://f.cloud.github.com/assets/1577682/1458274/1391ac28-435e-11e3-88b6-69c85029c978.png
+[Bookstrap]: https://github.com/hackreactor/bookstrap
+[Taser]: https://github.com/hackreactor/bookstrap
+[tools workflow diagram]: http://i.imgur.com/kzlrDj7.png
+[Git Flow]: http://nvie.com/posts/a-successful-git-branching-model/
+[GitHub Flow]: http://scottchacon.com/2011/08/31/github-flow.html
+[Squash]: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

PRESS-RELEASE.md

@@ -0,0 +1,44 @@
+# Project Name #
+
+<!-- 
+> This material was originally posted [here](http://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management). It is reproduced here for posterities sake.
+
+There is an approach called "working backwards" that is widely used at Amazon. They work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it. While working backwards can be applied to any specific product decision, using this approach is especially important when developing new products or features.
+
+For new initiatives a product manager typically starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product's customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.
+
+If the benefits listed don't sound very interesting or exciting to customers, then perhaps they're not (and shouldn't be built). Instead, the product manager should keep iterating on the press release until they've come up with benefits that actually sound like benefits. Iterating on a press release is a lot less expensive than iterating on the product itself (and quicker!).
+
+If the press release is more than a page and a half, it is probably too long. Keep it simple. 3-4 sentences for most paragraphs. Cut out the fat. Don't make it into a spec. You can accompany the press release with a FAQ that answers all of the other business or execution questions so the press release can stay focused on what the customer gets. My rule of thumb is that if the press release is hard to write, then the product is probably going to suck. Keep working at it until the outline for each paragraph flows. 
+
+Oh, and I also like to write press-releases in what I call "Oprah-speak" for mainstream consumer products. Imagine you're sitting on Oprah's couch and have just explained the product to her, and then you listen as she explains it to her audience. That's "Oprah-speak", not "Geek-speak".
+
+Once the project moves into development, the press release can be used as a touchstone; a guiding light. The product team can ask themselves, "Are we building what is in the press release?" If they find they're spending time building things that aren't in the press release (overbuilding), they need to ask themselves why. This keeps product development focused on achieving the customer benefits and not building extraneous stuff that takes longer to build, takes resources to maintain, and doesn't provide real customer benefit (at least not enough to warrant inclusion in the press release).
+ -->
+ 
+## Heading ##
+  > Name the product in a way the reader (i.e. your target customers) will understand.
+
+## Sub-Heading ##
+  > Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
+
+## Summary ##
+  > Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
+
+## Problem ##
+  > Describe the problem your product solves.
+
+## Solution ##
+  > Describe how your product elegantly solves the problem.
+
+## Quote from You ##
+  > A quote from a spokesperson in your company.
+
+## How to Get Started ##
+  > Describe how easy it is to get started.
+
+## Customer Quote ##
+  > Provide a quote from a hypothetical customer that describes how they experienced the benefit.
+
+## Closing and Call to Action ##
+  > Wrap it up and give pointers where the reader should go next.

README.md

@@ -1,12 +1,12 @@
-# Project Name
+# Reactor Overflow
 
-> Pithy project description
+> THe overflow of communication designed for Hack Reactor Students, Faculty, Alumni, and Precourse Students
 
 ## Team
 
   - __Product Owner__: @codydaig
   - __Scrum Master__: @linalu1
-  - __Development Team Members__: teamMember, teamMember
+  - __Development Team Members__: @andrewkishino @kevbyte
 
 ## Table of Contents
 
@@ -24,11 +24,11 @@
 
 ## Requirements
 
-- Node 0.10.x
-- Redis 2.6.x
-- Postgresql 9.1.x
-- etc
-- etc
+- Node 0.12.x
+- NPM 2.11+
+- Angular
+- rethinkDB
+- Express 4.x
 
 ## Development
 

STYLE-GUIDE.md

@@ -0,0 +1,380 @@
+### Indentation
+
+When writing any block of code that is logically subordinate to the line immediately before and after it, that block should be indented two spaces more than the surrounding lines
+
+* Do not put any tab characters anywhere in your code. You would do best to stop pressing the tab key entirely.
+* Increase the indent level for all blocks by two extra spaces
+    * When a line opens a block, the next line starts 2 spaces further in than the line that opened
+
+        ```javascript
+        // good:
+        if(condition){
+          action();
+        }
+
+        // bad:
+        if(condition){
+        action();
+        }
+        ```
+
+    * When a line closes a block, that line starts at the same level as the line that opened the block
+        ```javascript
+        // good:
+        if(condition){
+          action();
+        }
+
+        // bad:
+        if(condition){
+          action();
+          }
+        ```
+
+    * No two lines should ever have more or less than 2 spaces difference in their indentation. Any number of mistakes in the above rules could lead to this, but one example would be:
+
+        ```javascript
+        // bad:
+        transmogrify({
+          a: {
+            b: function(){
+            }
+        }});
+        ```
+
+    * use sublime's arrow collapsing as a guide. do the collapsing lines seem like they should be 'contained' by the line with an arrow on it?
+
+
+### Variable names
+
+* A single descriptive word is best.
+
+    ```javascript
+    // good:
+    var animals = ['cat', 'dog', 'fish'];
+
+    // bad:
+    var targetInputs = ['cat', 'dog', 'fish'];
+    ```
+
+* Collections such as arrays and maps should have plural noun variable names.
+
+    ```javascript
+    // good:
+    var animals = ['cat', 'dog', 'fish'];
+
+    // bad:
+    var animalList = ['cat', 'dog', 'fish'];
+
+    // bad:
+    var animal = ['cat', 'dog', 'fish'];
+    ```
+
+* Name your variables after their purpose, not their structure
+
+    ```javascript
+    // good:
+    var animals = ['cat', 'dog', 'fish'];
+
+    // bad:
+    var array = ['cat', 'dog', 'fish'];
+    ```
+
+
+### Language constructs
+
+* Do not use `for...in` statements with the intent of iterating over a list of numeric keys. Use a for-with-semicolons statement in stead.
+
+  ```javascript
+  // good:
+  var list = ['a', 'b', 'c']
+  for(var i = 0; i < list.length; i++){
+    alert(list[i]);
+  }
+
+  // bad:
+  var list = ['a', 'b', 'c']
+  for(var i in list){
+    alert(list[i]);
+  }
+  ```
+
+* Never omit braces for statement blocks (although they are technically optional).
+    ```javascript
+    // good:
+    for(key in object){
+      alert(key);
+    }
+
+    // bad:
+    for(key in object)
+      alert(key);
+    ```
+
+* Always use `===` and `!==`, since `==` and `!=` will automatically convert types in ways you're unlikely to expect.
+
+    ```javascript
+    // good:
+
+    // this comparison evaluates to false, because the number zero is not the same as the empty string.
+    if(0 === ''){
+      alert('looks like they\'re equal');
+    }
+
+    // bad:
+
+    // This comparison evaluates to true, because after type coercion, zero and the empty string are equal.
+    if(0 == ''){
+      alert('looks like they\'re equal');
+    }
+    ```
+
+* Don't use function statements for the entire first half of the course. They introduce a slew of subtle new rules to how the language behaves, and without a clear benefit. Once you and all your peers are expert level in the second half, you can start to use the more (needlessly) complicated option if you like.
+
+    ```javascript
+    // good:
+    var go = function(){...};
+
+    // bad:
+    function stop(){...};
+    ```
+
+
+### Semicolons
+
+* Don't forget semicolons at the end of lines
+
+  ```javascript
+  // good:
+  alert('hi');
+
+  // bad:
+  alert('hi')
+  ```
+
+* Semicolons are not required at the end of statements that include a block--i.e. `if`, `for`, `while`, etc.
+
+
+  ```javascript
+  // good:
+  if(condition){
+    response();
+  }
+
+  // bad:
+  if(condition){
+    response();
+  };
+  ```
+
+* Misleadingly, a function may be used at the end of a normal assignment statement, and would require a semicolon (even though it looks rather like the end of some statement block).
+
+  ```javascript
+  // good:
+  var greet = function(){
+    alert('hi');
+  };
+
+  // bad:
+  var greet = function(){
+    alert('hi');
+  }
+  ```
+
+# Supplemental reading
+
+### Code density
+
+* Conserve line quantity by minimizing the number lines you write in. The more concisely your code is written, the more context can be seen in one screen.
+* Conserve line length by minimizing the amount of complexity you put on each line. Long lines are difficult to read. Rather than a character count limit, I recommend limiting the amount of complexity you put on a single line. Try to make it easily read in one glance. This goal is in conflict with the line quantity goal, so you must do your best to balance them.
+
+### Comments
+
+* Provide comments any time you are confident it will make reading your code easier.
+* Be aware that comments come at some cost. They make a file longer and can drift out of sync with the code they annotate.
+* Comment on what code is attempting to do, not how it will achieve it.
+* A good comment is often less effective than a good variable name.
+
+
+### Padding & additional whitespace
+
+* Generally, we don't care where you put extra spaces, provided they are not distracting.
+* You may use it as padding for visual clarity. If you do though, make sure it's balanced on both sides.
+
+    ```javascript
+    // optional:
+    alert( "I chose to put visual padding around this string" );
+
+    // bad:
+    alert( "I only put visual padding on one side of this string");
+    ```
+
+* You may use it to align two similar lines, but it is not recommended. This pattern usually leads to unnecessary edits of many lines in your code every time you change a variable name.
+
+    ```javascript
+    // discouraged:
+    var firstItem  = getFirst ();
+    var secondItem = getSecond();
+    ```
+
+* Put `else` and `else if` statements on the same line as the ending curly brace for the preceding `if` block
+    ```javascript
+    // good:
+    if(condition){
+      response();
+    }else{
+      otherResponse();
+    }
+
+    // bad:
+    if(condition){
+      response();
+    }
+    else{
+      otherResponse();
+    }
+    ```
+
+
+
+### Working with files
+
+* Do not end a file with any character other than a newline.
+* Don't use the -a or -m flags for `git commit` for the first half of the class, since they conceal what is actually happening (and do slightly different things than most people expect).
+
+    ```shell
+    # good:
+    > git add .
+    > git commit
+    [save edits to the commit message file using the text editor that opens]
+
+    # bad:
+    > git commit -a
+    [save edits to the commit message file using the text editor that opens]
+
+    # bad:
+    > git add .
+    > git commit -m "updated algorithm"
+    ```
+
+
+### Opening or closing too many blocks at once
+
+* The more blocks you open on a single line, the more your reader needs to remember about the context of what they are reading. Try to resolve your blocks early, and refactor. A good rule is to avoid closing more than two blocks on a single line--three in a pinch.
+
+    ```javascript
+    // avoid:
+    _.ajax(url, {success: function(){
+      // ...
+    }});
+
+    // prefer:
+    _.ajax(url, {
+      success: function(){
+        // ...
+      }
+    });
+    ```
+
+
+### Variable declaration
+
+* Use a new var statement for each line you declare a variable on.
+* Do not break variable declarations onto mutiple lines.
+* Use a new line for each variable declaration.
+* See http://benalman.com/news/2012/05/multiple-var-statements-javascript/ for more details
+
+    ```javascript
+    // good:
+    var ape;
+    var bat;
+
+    // bad:
+    var cat,
+        dog
+
+    // use sparingly:
+    var eel, fly;
+    ```
+
+### Capital letters in variable names
+
+* Some people choose to use capitalization of the first letter in their variable names to indicate that they contain a [class](http://en.wikipedia.org/wiki/Class_(computer_science\)). This capitalized variable might contain a function, a prototype, or some other construct that acts as a representative for the whole class.
+* Optionally, some people use a capital letter only on functions that are written to be run with the keyword `new`.
+* Do not use all-caps for any variables. Some people use this pattern to indicate an intended "constant" variable, but the language does not offer true constants, only mutable variables.
+
+
+### Minutia
+
+* Don't rely on JavaScripts implicit global variables. If you are intending to write to the global scope, export things to `window.*` explicitly instead.
+
+    ```javascript
+    // good:
+    var overwriteNumber = function(){
+      window.exported = Math.random();
+    };
+
+    // bad:
+    var overwriteNumber = function(){
+      exported = Math.random();
+    };
+    ```
+
+* For lists, put commas at the end of each newline, not at the beginning of each item in a list
+
+    ```javascript
+    // good:
+    var animals = [
+      'ape',
+      'bat',
+      'cat'
+    ];
+
+    // bad:
+    var animals = [
+        'ape'
+      , 'bat'
+      , 'cat'
+    ];
+    ```
+
+* Avoid use of `switch` statements altogether. They are hard to outdent using the standard whitespace rules above, and are prone to error due to missing `break` statements. See [this article](http://ericleads.com/2012/12/switch-case-considered-harmful/) for more detail.
+
+* Prefer single quotes around JavaScript strings, rather than double quotes. Having a standard of any sort is preferable to a mix-and-match approach, and single quotes allow for easy embedding of HTML, which prefers double quotes around tag attributes.
+
+    ```javascript
+    // good:
+    var dog = 'dog';
+    var cat = 'cat';
+
+    // acceptable:
+    var dog = "dog";
+    var cat = "cat";
+
+    // bad:
+    var dog = 'dog';
+    var cat = "cat";
+    ```
+
+
+### HTML
+
+* Do not use ids for html elements. Use a class instead.
+
+    ```html
+    <!-- good -->
+    <img class="lucy" />
+
+    <!-- bad -->
+    <img id="lucy" />
+    ```
+
+* Do not include a `type=text/javascript"` attribute on script tags
+
+    ```html
+    <!-- good -->
+    <script src="a.js"></script>
+
+    <!-- bad -->
+    <script src="a.js" type="text/javascript"></script>
+    ```