SPRINT3Summary

Return Home

Summary

• What Features were finished/unfinished

  • All features planned for the sprint were finished, and more:
  • Action Cable
    • Using Puma server instead of Webrick. Needed for multithreading (Action Cable requirement)
    • Auto notification of changes to any pile within the room.
      • On notification, force update page with new pile information without reloading page
      • Maintains state of popups, while potentially providing new info to those popups (such as transfer).
    • Managed sockets by room id and on page load
    • Updating page information uses partials and HTTPS requests to reload information
  • See list of cards
    • Center piles are fully viewable
    • Hands are viewable based on if other player has shown a card
  • Number of players in a game
    • limits number of players that can join a game now
    • dynamically create hands for players that join
  • AJAX card transfer
    • Transferring cards no longer reloads page
    • Popup to specify cards, source, and destination
    • Dropdown menus to select from available piles, with available piles filtered based on the user
  • AJAX card draw
    • Drawing cards no longer reloads page
    • Popup to specify number of random cards to take
    • Due to AJAX response, there is no flash to notify that you are taking too many cards
  • Show Hand
    • Allows users to make their hands available to other plays for viewing and transfer
  • Graphics for cards
    • Full image display for cards
    • Custom backside for call cards (static)

• Features not talked about during iteration meeting that were added

  • Flash has a fade and timer and hovers to not adjust page elements
  • Discard pile has a dedicated send-to button

• What Problems we encountered

  • Technical issues:
    • Action Cable some issues with page updates not triggering correctly. Likely an overlapping AJAX call issue. WNF
    • Rails-supported AJAX calls were finnicky and we had problems using them on multiple occasions
  • Perhaps not a true problem, but it can be harmful in similar situations. We did not have many Pull Requests midway through this sprint. All the work was done on time, but perhaps we could have broken components up better to have a better grasp of progress

• What we will be doing better going forward

  • While we will not be having another sprint, we can reflect on our time with this project when going forward.
  • More clear communication could be used. We should be as precise as possible when talking about issues
  • Pull Requests and features should be broken into smaller, independent components when possible. This way we require far less from each other's developments. For instance, rooms#show's page could have been far better broken up.
  • Writing better, more comprehensive tests would help us develop more efficiently by reducing the amount of time spent debugging issues and manually testing implementations

Testing

Coverage as provided by Simple Cov: 95.04%

Image of code coverage below:

• Tests were developed not just to cover code, but to exercise code paths and test functionality and expectations
  • Tests make a fantastic marker for regression testing
• Tests for base UI exist for pages in Cucumber
• Tests for major Javascript functions written in Jasmine
• Tests for Action Cable backend written in Mini-Test. No tests for JS side of Action Cable.

Lofi-Designs/Page Designs

Current Lofi-Designs

Finished Gameboard UI Design:

Gameboard

Draw popups

Transfer popups