Permalink
Browse files

Merge pull request #570 from ga-wdi-boston/017/master

Add more granular steps with milestones to schedule
  • Loading branch information...
payne-chris-r committed Aug 28, 2017
2 parents e155c11 + acb8340 commit be25dfe1229239a168f59cab48f4b56cf6917ff1
Showing with 112 additions and 83 deletions.
  1. +55 −67 requirements.md
  2. +37 −16 schedule.md
  3. +20 −0 tips.md
@@ -1,71 +1,59 @@
# Requirements

In order to get a satisfactory score, by the time you present your project, you
**must**:

- Present **working browser game, built by you**, hosted on GitHub Pages.
- Practice using version control by:

- Sharing your work through a **git repository hosted on Github**.
- Making **frequent, cohesive commits** dating back to the very beginning
of the project with **good commit messages**.

- Produce **documentation** in the form of a **README**, which must:

- **Link to your hosted game** in the **URL section** of your Github
repo.
- **List technologies used**.
- **Document your planning** and tell a story about your **development
process** and problem-solving strategy.
- **List unsolved problems** which would be fixed in future iterations.
- Link to **wireframes and user stories**.

Your app **must**:

- Be a **single-page** application.
- Use a custom game engine **written by you**.
- **Be deployed online**, where the rest of the world can access it.
- **Render a game board in the browser**.
- **Switch turns** between X and O (or whichever markers you select).
- **Visually display which side won** if a player gets three in a row or show
a draw/"cat’s game" if neither wins.
- Support playing **multiple games**, one at a time.
- Use **jQuery** for **DOM manipulation** and **event handling**.
- Use **AJAX** for interacting with a provided API. Specifically, your app
must:

- **Visually display** the results of retrieving game statistics, such as
total games won by a user. (READ)
- **Create** new games on the server. (CREATE)
- **Update** a game by storing new moves. (UPDATE)

- Have **login**, **logout**, and **change password** functionality.

**must** meet the following requirements:

### Deployment
Be deployed online, where the rest of the world can access it.
1. [ ] Present a working browser game, built by you, hosted and deployed on GitHub Pages.

### Version Control
Demonstrate using version control by:
1. [ ] Sharing your work through a git repository hosted on Github.
1. [ ] Making frequent, cohesive commits dating back to the **first day**
of the project week.

### Documentation
Produce documentation in the form of a **README**, which must:
1. [ ] Link to your hosted game in the URL section of your Github repo.
1. [ ] List technologies used
1. [ ] Document your planning and tell a story about your development process and problem-solving strategy.
1. [ ] List unsolved problems which would be fixed in future iterations.
1. [ ] Link to wireframes and user stories.

### Technical Specifications
1. [ ] Use a custom game engine written by you.
1. [ ] Be a single-page application, no browser refresh.
1. [ ] Render a game board in the browser.
1. [ ] Switch turns between X and O (or whichever markers you select). Tip: Assume player X is the first player to start the game.
1. [ ] Visually display which side won if a player gets three in a row or show a draw if neither wins.
1. [ ] Support playing multiple games, one at a time.
1. [ ] Use jQuery for DOM manipulation and event handling.
1. [ ] Use AJAX for interacting with a provided API.

### API Specifications
1. [ ] Create new games on the server. (CREATE)
1. [ ] Update a game by storing new moves. (UPDATE)
1. [ ] Visually display the results of retrieving game statistics, such as total games won by a user. (READ)
1. [ ] Give feedback to the user after each action.

### Auth Specifications
1. [ ] Signup with email, password, and password confirmation.
1. [ ] Login with email and password.
1. [ ] Logout when logged in.
1. [ ] Change password with current and new password.
1. [ ] Give feedback to the user after each action's success or failure.

### DO NOT!!
Your app **must not**:

- Rely on **refreshing the page** for **any** functionality.
- Display **non-functional** buttons, nor buttons that **do not successfully
complete** a task.
- Have **any** user-facing **bugs**.
- Be playable **after finishing a game**.
- Allow players to move in the same square **more than once**.
- Change players when an **invalid move** is made.

Additionally, you **should**:

- Use **semantic** HTML.
- Practice separation of concerns by:

- Using the [js-template](https://github.com/ga-wdi-boston/js-template) to
store HTML, CSS, and JavaScript in the appropriate places.
- Storing DOM manipulation code and network code in separate files.

- **KISS (Keep It Stupidly Simple)**.
- **DRY (Don't Repeat Yourself)**.
- **Assume player X is the first player to start the game**.

Finally, you **should not**:

- **Use alerts** for anything.
- **Display errors** or warnings in the console.
- **Display debugging** messages in the console.
1. [ ] Delete your repository at any time or start over.
1. [ ] Rely on refreshing the page for any functionality.
1. [ ] Have any user-facing bugs.
- [ ] Display non-functional buttons, nor buttons that do not successfully complete a task.
- [ ] Show actions at inappropriate times (example: sign out button when not signed in).
1. [ ] Allow the same game to be played after a player has won or tied.
1. [ ] Allow players to move in the same square more than once.
1. [ ] Change players when an invalid move is made.
1. [ ] Use alerts for anything.
1. [ ] Display errors or warnings in the console.
1. [ ] Display debugging messages in the console.
@@ -6,19 +6,40 @@ Always be commiting. Deploy early and often.

Here's a rough sketch of what you should do and in what order:

1. [ ] Sketch some rough wireframes for how the front end will look and act.
1. [ ] Write out some user stories for the app. User stories are short of how a
user interacts with your app, and follows the format "As a `<role>`, I want
to `<do something>`, so that `<some goal>`.
1. [ ] Model the entities in your app. Draw a diagram. Use your wireframes and
user stories to drive you modeling process by asking "What 'things' are a
user interacting with?"
1. [ ] Create a repo that your project will use, and add a README to it.
1. [ ] Create a simple front-end with HTML and CSS, and host the front end on
GitHub Pages. Use your wireframes to guide your layout.
1. [ ] Create the code to manage your game logic.
1. [ ] Write jQuery code to handle browser interaction.
1. [ ] Start communicating with the back-end using `curl`. Use this to begin
writing your AJAX code.
1. [ ] Add any additional features to your app.
1. [ ] Finish your documentation. Make it high-quality.
### Planning
1. [ ] Review [game-project-scope-study](https://git.generalassemb.ly/ga-wdi-boston/game-project-scope-study)
1. [ ] User Stories
1. [ ] Review [project-planning-wireframes-practice](https://git.generalassemb.ly/ga-wdi-boston/project-planning-wireframes-practice)
1. [ ] Wire Frames

### Set Up
1. [ ] [Download Browser Template](https://git.generalassemb.ly/ga-wdi-boston/browser-template)
1. [ ] Create a Github Repository
1. [ ] [Deploy to Github Pages](https://git.generalassemb.ly/ga-wdi-boston/gh-pages-deployment-guide)

### Game Engine
1. [ ] Create Empty Board
1. [ ] Add to Board
- [ ] Turn rotates between x and o
- [ ] Can not choose already occupied spots
1. [ ] Check Board for Winner

### Authentication
1. [ ] Review [api-token-auth](https://git.generalassemb.ly/ga-wdi-boston/api-token-auth)
1. [ ] Sign Up (curl then web app)
1. [ ] Sign In (curl then web app)
1. [ ] Change Password (curl then web app)
1. [ ] Sign Out (curl then web page)
1. [ ] All API calls have success or failure messages

### Game API
1. [ ] Review [query-ajax-post](https://github.com/ga-wdi-boston/jquery-ajax-post)
1. [ ] Create Game, start new game (curl then web app)
1. [ ] Update Game, play the game (curl then web app)
1. [ ] Get Games (curl then web app)
1. [ ] Get a Game (curl then web app)

### Final Touches
1. [ ] README
2. [ ] Troubleshoot/Debug
3. [ ] Style
20 tips.md
@@ -1,5 +1,13 @@
# Tips

You **should**:
- Use **semantic** HTML.
- Practice separation of concerns by:
- Using the [browser-template](https://git.generalassemb.ly/ga-wdi-boston/browser-template) to
store HTML, CSS, and JavaScript in the appropriate places.
- Storing DOM manipulation code and network code in separate files.
- **KISS (Keep It Stupidly Simple)**.
- **DRY (Don't Repeat Yourself)**.
- **Break the project down into different components** (data, presentation,
style, DOM manipulation) and brainstorm each component individually. Use
whiteboards!
@@ -17,3 +25,15 @@
if real data is not available. For example, if you’re trying to figure out
how to change some text when the game is over but you haven’t solved the
win/lose game logic, you can create a button to simulate that until then.

- _If your success/failure methods aren't working, it's likely that you're not getting to the point where you're making an ajax call._
1. Create my HTML element.
2. Create a click handler attached to that element.
2a. Have the click handpreler console.log('hello') AND DO NOTHING ELSE.
3. Verify that any data I want to pass to my api call is the data I expect it to be when I have it in the click handler. (`Using console.log()`)
4. Add an ajax call to my click handler.
5. Verify that the backend server is doing what I expect when I make the ajax call. Check the server log and/or the rails console.
6. Have the success function console.log('success!!') AND DO NOTHING ELSE.
7. Have the success function add "Hello" to the HTML using jQuery
8. Have the success function console.log the data I get back from the server.
9. Add that data to the HTML using jQuery or handlebars. (or do something else, as appropriate.)

0 comments on commit be25dfe

Please sign in to comment.