We need to be tracking our Test coverage with a tool like SimpleCov on our project. We have not done this yet.

• Add SimpleCov gem
• Add require simplecov and SimpleCov.start 'rails' to rails_helper.rb

Currently, the Integer fields on the Card objects do not have a default value. This will cause issues when Frontend is trying to render cards, as they are expecting 0's in the following attributes if they do not have that value, instead of null:

• Victory Points
• Spending Power
• Buying Power
• Actions Provided
• Cards to Draw

We will need to update the migrations and schema for these attributes on Card.

As a user when I receive a POST to api/v1/endturn. In the format

{
gameId: 123,
playerId: 234
deck: [ ordered array cards ids], 
bought: [array ids ]
discard: [ordered array card ids]
}

Successfully returns a 200

A POST request to /api/v1/game_state/:game_id
Also returns in the response the following key:value pairs:

{
activePlayerName: "Bob"
activePlayerID: "2"
... 
}

We need a collapsable section in our README about the Base Set of cards we are implementing, and their rules and interaction patterns. This can be copied and pasted from the Dominion rulebook to ensure parity.

Creating Git hooks will allow all contributors to follow the same style and ensure passing tests. These will differ between BE and FE because of the languages, but this is something we should establish between the teams so we can be held to the same standards.

Player class has a deck and is in charge of its hand, inplay, deck, discard, buys, coins, actions.

-Include logic to draw
-To shuffle deck
-To discard
-To end turn
-To play card

Currently, the endturn endpoint does not return any information for the Frontend on a successful Game Update. Following general convention, we should return a 200 or 204 status code.
200:

render json: { "message": "Player 1 turn successfully processed" }, status: 200

204:

head :no_content

Define The Relationship:
We will outline our processes, needs and wants for the project, and what we envision our schedule looking like at this time.
Following this template

Kevin from the Frontend team reported this morning that the documentation for the Game State endpoint was not full accurate:

note: there is a discrepancy in the docs for game_state endpoint
docs:
"currentPlayerName": "Player_1_Name",
"currentPlayerId": 1
actual:
"activePlayerName": "Player_1_Name",
"activePlayerId": 1

He also noticed that the documentation has nulls in some spots for attributes, instead of 0s like they should be.

For us to be able to accurately QA our application, and for the Frontend team to be able to run against a local/staging environment, we need to have actual data in our DB. Currently, we have been testing using Factories, but we should set up a Seeds file for Rails to create Cards resources that match the final Base Set of Cards that we plan on implementing.

Card images are currently served through local storage on the frontend, we would like to change to use our backend to serve said images.

• Add image resources to the rails application
• Add production URL paths to seed file for the card table

Using the previously determined Wireframes, the team will write fleshed out User Stories that will determine interaction and experiences while playing the game.

This can be done as a whole group but this tends to lead to some people doing all of the work while others might just be sitting and watching. Probably best done in pairs while the others work on design and branding.

• Suggestion: 1 FE and 2 BE work on this, other FE and BE focus on another meeting

We need to add the rack-cors gem to our project to allow the Frontend to both:

• Request to localhost
• Request to Heroku
  We'll need to make sure we restrict our origins to localhost:3001, and whatever URL the Frontend chooses for their UI.

We should add documentation for the fact that we are using Postgres, and how to:

• Create
• Migrate
• Seed (if applicable)

Since we did not add Documentation for the buy_card endpoint with our implementation PR, we should add it in later. We will need to add:

• Usage
• Required information in request
• Response example

Following the Architecture and Schema Brainstorming, the team will decide on what ideas were most appropriate, and what can be performed in the limited time frame. While this is the game plan, it is expected things will change over the course of the project, and that's fine. This is a map of where we want things to go with the knowledge we have at this time.

Time limit: 30-60 minutes

Assigned Roles:

• Time Enforcer:
• Notetaker:
• Facilitator:

One way to quickly exhaust a group is to allow debates to go on too long. Have the team vote if any decision takes more than 10 minutes. If the team can’t decide bring in an instructor and they’ll be the deciding vote.

- What should the schema look like?
- What will your architecture look like? (background workers, caching, websockets, JavaScript)
- What tasks need cards created in your project management tool? Who will add these? Label these tasks as chores. Note: migrations should be run in the context of the user stories that need them and shouldn’t have cards associated with them. An example of a chore might be is more for setting things up like Redis on Heroku.

Notes linked here:

This will be a meeting to determine the outline of the three most important MVP features, determined through prior meetings.

Time limit: 30 minutes

Assigned Roles:

• Time Enforcer:
• Notetaker (builds the wireframes):
• Facilitator:

One way to quickly exhaust a group is to allow debates to go on too long. Have the team vote if any decision takes more than 10 minutes. If the team can’t decide bring in an instructor and they’ll be the deciding vote.

Using the previously determined Wireframes, this meeting will be decisions on color scheme, fonts, logo, etc. HTML/CSS, if relevant, can be used to sketch out basic ideas and concepts.

This can be done as a whole group but this tends to lead to some people doing all of the work while others might just be sitting and watching. Probably best done in pairs while the others work on writing stories.

• Suggestion: 1 FE and 1 BE handle this, while the rest of the team focuses on a different meeting

After all other meetings, come to a final conclusion about the first steps for the project. This should take context from both a developer view and a customer standpoint. This is the time to determine User Story weight and priority, keeping in mind delivery deadlines and time management.

Time limit: 30-60 minutes

Assigned Roles:

• Product Representative (probably someone who was writing the user stories):
• Technical Representative:
• Time Enforcer: Everyone
• Notetaker:
• Facilitator:

One way to quickly exhaust a group is to allow debates to go on too long. Have the team vote if any decision takes more than 10 minutes. If the team can’t decide bring in an instructor and they’ll be the deciding vote.

If there is a time for adding final thoughts into cards/stories with the full understanding of the team, it is now.

Notes linked here:

We will be pivoting and using Rails for this project. We need to do our initial Rails commit, bringing in the framework, and whatever base tools we will need.

• Rspec
• FactoryBot

To maintain parity between the Frontend and the Backend with a Players GameCards, we will need to implement logic to send and receive the order of a given Players deck of GameCards.
The flow for this looks like:

• GET Player State endpoint contains an array of GameCard objects in the order they should be drawn
• Frontend draws cards in this determined order for players
• Frontend sends POST at end of turn dictating which cards are discarded (and in what order)
• Backend finds new cards/existing cards to mark as Discarded

Edge Cases

• Frontend shuffles Discard into Deck, Frontend sends us an updated Deck Order during the End Turn phase
• We update GameCard deck_order number to reflect this change

Add card class with attributes: name, cost, vp, gold

My bad.
When we try to access the ENV[HEROKU_STAGING], the HEROKU_STAGING needs to be wrapped in quotes, otherwise Ruby reads it as a constant variable.
I misremembered.

Since this documentation was not added initially, we should add information for the Player State endpoint.

• How to format request
• Example Response

UPDATE

This should now also include information about how the Deck cards will be returned in the determined deck_index order.

The endpoint /api/v1/join_game needs the following edge cases considered:

• The connection should reject the player if the game is full (currently 2 players)
• The player should be able to rejoin a game if they are disconnected without creating another player object on the game.
• The game start script should only run if all players have joined and the game is already started.

UPDATE

We can implement this for only 2 players initially.

As a user
I should be able to visit the TSDBCG Lobby website
And put my name in to join the queue
And once a Game with enough Players is started
I will be a part of that Game in the main App

This will be built out on another repo.

If a Player joins an existing Game, and is not the last required Player (out of 4), the Game will not be started, and the Player will be put into a Lobby of other waiting Players in that Game.

A Game needs to be started to initialize the state of the Game, and state of the Players in the Game.

• All Players start with 7 Copper and 3 Estates in their deck (collection of GameCards)
• All Games start with an additional 60 Copper and 8 Estates

This facet is required for #27 to function, as Player State is not established until the Game is started.

After confirming with the Frontend what Serialized Card objects should look like for the Game State, the same update needs to be applied to the Player State endpoint as well.
The final serialized Card Object should look like this:

{
      name: "Copper",
      category: "Money",
      cost: 0,
      victoryPoints: 0,
      spendingPower: 1,
      buyingPower: 0,
      actionsProvided: 0,
      cardsToDraw: 0,
      image: "copper.jpg",
      desc: "",
      tags: []
    }

Brainstorming session to decide collaboratively the MVP of the project. This will include the main features that both FE and BE are interesting in developing.

Time limit: 30 minutes

Assigned Roles

• Time Enforcer:
• Notetaker:
• Facilitator:

Make sure this session isn’t used to make decisions. That comes later. Allow everyone’s voice to be heard and make sure no one is dominating the discussion.

Encourage your team to be creative. Encourage people to share bad ideas as well as good. Sometimes bad ideas lead to good ones.

If you need questions guiding the discussion:

- What would an MVP (minimum viable product) look like? If your team needed to ship features every evening to prove value to an investor, what would you work on and in what order?
- What would set you apart during demo night?
- What intimidates you but would be amazing to pull off?
- How should your users experience the app? Desktop, mobile, native app?
- What features or technology choices would spark interesting discussions during job interviews?
- Would you use this product? If not, what is it missing?

If debating a single idea goes longer than 5 minutes point it out. There’s no need to make a decision now and allowing one idea to dominate the discussion can hinder creativity and cause frustration.

Notes linked here:

A Game needs to be started to initialize the state of the Game, and state of the Players in the Game.

• This method needs to create and add all cards in the game.
• This method needs to assign the initial player hands and deck.

Tie In to issue #33

Currently, the README has some typos, and the order of the Endpoints is not in the correct order to facilitate gameplay.
The order should be as follows:

• Game Start
• Game Join
• Game State
• Player State
• Player End Turn

There are typos in the:

• Player State
• • Deck and Discard are Card objects inside of an array, not inside of an object
• Rails setup
• • It's rails server not rails start

For the Frontend, to handle Single or Multiple categories, the Card attribute of category should be an Array of categorical (Action, Money, Victory) identifier strings.
We should store these in the DB as a String of comma separated values, which we then can serialize as an Array.

UPDATE

This has been set up correctly on the Player State endpoint, will need to be implemented on the Game State endpoint.

A meeting to make a final decision on the MVP of the project. This will be done after the Brainstorming Product Vision meeting.

Time limit: 15-30 minutes

Assigned Roles:

• Time Enforcer:
• Notetaker:
• Facilitator:

One way to quickly exhaust a group is to allow debates to go on too long. Have the team vote if any decision takes more than 10 minutes. If the team can’t decide bring in an instructor and they’ll be the deciding vote.

What are the three most important features?
How would you prioritize them?

Endpoint tentatively returns

{
tableDeck: [
   { name: "Gold",
    category: ["Treasure"],
    cost: 6,
    image: "Gold.jpg",
    spendingPower: 3,
  },
  {
    name: "Estate",
    type: ["Victory"],
    cost: 2,
    image: "Estate.jpg",
    victoryPoints: 1,
    id: 6123
  }
  ],
  player_order: [player1, player2],
  player_info:  {
  player1: {
    deckSize: 13,
    topCardDiscard: "Village",
    handSize: 5
  },
   player2: {
    deckSize: 13,
    topCardDiscard: "Village",
    handSize: 5
}

UPDATE:

Travis needs a database setup, and needs to know it is using Postgres.

Setting up a Heroku Pipeline will allow our project to flourish and be testing in a Production environment consistently as we add features and functionality.
For BE this looks like a Staging environment where we can hit endpoints with real live variables, and then pushing to Production after passing our QA stage.
For FE this looks like:
Additionally, Travis CI or another CI tool will be another barrier to ensuring our code is functional alongside our tests.

Currently, the .map call when building deck and discard in the PlayerSerializer are formatted for a one-line syntax. This is not appropriate, because the block inside is building a hash that has multiple key value pairs.
This should instead be converted to a .map do |card| with an end.

We did not write validation specs for Models, only testing their Associations. At this moment in time, we do not plan on allowing User input, except for Player names. Otherwise, all of our resources should be hand built by us. This does not mean that we shouldn't cover our bases.

We need to set up our Database with the information that we understand at this time. This involves:

• Games
• • Have Many Cards
• • Have Many Players
• Cards
• • Have Many Games
• • name
• • type
• • cost
• • victory_points
• • spending_power
• GameCards
• • Belong to Game
• • Belong to Card
• • CAN belong to Player
• • trashed (boolean)
• • discarded (boolean)
• Players
• • Belong to Game
• • CAN Have Many GameCards
• • name

After determining Wireframes, the team will decide on the building blocks and database considerations to facilitate the project.

Time limit: 30-45 minutes

Assigned Roles:

• Time Enforcer:
• Notetaker:
• Facilitator:

Clarifying Questions:

- Are there parts of the app that would benefit from things happening in the background? (tasks that take a long time or need to run on a regular basis; nightly, hourly, etc.)
- Are there parts of the app that would benefit from breaking away from the request/response cycle by updating the page automatically? (websockets, AJAX, etc.)
- Should you cache data to improve page load times?
- Should this be one big Rails app?
- How might the schema look?
- Is there anything different you might need to try in your schema? (self-referential associations, serialized columns, etc.)

Notes linked here:

As a user
I should be able to POST request 'api/v1/join_game'
With a Body containing my Player Name, and the Game ID
Of the Game I would like to join
And I will receive a response with a 200 status code, the Player Name, Player ID, and the Game ID
And a successful message of Game Started

Request:
POST /api/v1/join_game
BODY: {player_name: "George", game_id: 1}
Response:
BODY: {player_name: "George", player_id: 2, game_id: 1, game_status: "Game Started"}

Game Started implies that all required players have joined this game, and the backend has run the Game.start method, building out decks and cards for the frontend to render to each Player.

Before a POST request to api/v1/end_turn

game = Game.find(id)
game.current_player == "Player One"

After a POST request to api/v1/end_turn

game = Game.find(id)
game.current_player == "Player Two"

As it turns out, setting up a Ruby environment and getting Rails fully set up on a vanilla machine is a pretty rough experience. We need to expand our documentation for the Setup section to really make it flawless to get up and running.

• Brew setup
• Rbenv setup
• Postgres setup
• Rails setup

To ensure proper code review, merging, and quality, we will want to create a Pull Request Template to follow for ALL PRs.
An outline could be:

# Pull Request Template

## Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

## Type of change

Please delete options that are not relevant.

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update

## How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

- [ ] Test A
- [ ] Test B

**Test Configuration**:
* Firmware version:
* Hardware:
* Toolchain:
* SDK:

## Checklist:

- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream modules

As a user
I should be able to POST to the Games endpoint with my 
- Name
And start a new Game
And receive a body containing:
- My Player Name
- Player ID
- Game ID

Request:
POST /api/v1/games
BODY: {player_name: "Ted"}
Response
BODY: {player_name: "Ted", player_id: 1, game_id: 1}

On the backend, we will need to first create a new Game object, and then the new Player object attached to that Game. The Game will not start yet, as it does not have all required players.

Since documentation for the Game State Endpoint was not added during the PR for the implementation of said endpoint, we should add it later.

This endpoint returns a players specific deck and discard info in the format

{
  playerId: 99,
  deck: [{
    name: "Gold",
    category: ["Treasure"],
    cost: 6,
    image: "Gold.jpg",
    spendingPower: 3,
    id: 1515
  },
    {
    name: "Gold",
    category: ["Treasure"],
    cost: 6,
    image: "Gold.jpg",
    spendingPower: 3,
    id: 1515
  },
{
    name: "Gold",
    category: ["Treasure"],
    cost: 6,
    image: "Gold.jpg",
    spendingPower: 3,
    id: 1515
  }],
  discard: [{
    name: "Estate",
    type: ["Victory"],
    cost: 2,
    image: "Estate.jpg",
    victoryPoints: 1,
    id: 6123
  },
{
    name: "Estate",
    type: ["Victory"],
    cost: 2,
    image: "Estate.jpg",
    victoryPoints: 1,
    id: 6123
  }
  ]}
}

Requires #33

We should add documentation for the fact we're using Rails, and what version.
This goes hand in hand with documentation for Ruby as well, and mentioning the version.

• Bundle installation