A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. – R.W. Emerson, “Self-Reliance”, 1841.
Optimism is the occupational hazard of programming. Feedback is the treatment. – K. Beck, XP Explained, 2000

In this lab, you’ll work with issue trackers and coding standards, and you’ll roll out your team prototype.

The Emerson quote given above is discussed at length in the PEP 8 — Style Guide for Python Code. Consistency can be taken too far, but is, generally, valuable on team projects.

Tracking Defects

We’ll use GitHub’s issue tracker to record and process external issues, in particular, issues that arise in the upcoming user tests.

Exercise 11.1

Create a test issue on your team’s client repo named with your user ID. Give it an appropriate label, assign it to yourself, and enter a list of changes you need to make (e.g., the integration of code standard checks in the next lab exercise) as the comment.

We’ll check for an issue under your name for grading. You can close it when you’ve completed the code standardization started in the next exercise.

It’s interesting to consider how to integrate issues with our current use of Trello. The CS 262 course materials provide: a sample GitHub issue and a corresponding Trello task.

Following Coding Standards and Recommendations

We’ll use ESLint to enforce coding standards and GitHub actions, workflows, and branch protection to integrate them into the development process.

Exercise 11.2

Integrate ESLint into both your team’s client and server applications using CI workflow as follows. Have one team member do the following, starting with the client.

  1. Pull the latest version of your client repo and then do the following locally.

    1. Create a feature/eslint branch.
    2. Install ESLint, using this https://eslint.org/docs/latest/use/getting-started#quick-start command.
      Answer the sequence of install wizard questions appropriately, choosing find-fix-enforce and the AirBNB standard (which works well with ReactJS).
    3. Install Microsoft’s VSCode ESLint extension.
    4. Add a “lint” script to package.json that runs “eslint .”.
    5. Run the lint script (npm run lint). It will likely generate numerous syntax errors, which your team will fix below.
    6. Add a GitHub workflow specification by copying the Monopoly client’s .github/workflows/eslint.yml work flow specification into your repo in the appropriate place.
    7. Commit/Push your new branch.

    See the Monopoly Client repo for examples of all of this code.

  2. Do the following on GitHub.

    1. Create a PR for this new (lint-error-laden) branch, but do not merge it into main (yet).
    2. Add GitHub branch protection rule for your main branch by going to Settings→Branches and requiring “approvals” (if that’s not already set) and a “status check” based on the eslint workflow you created.
    3. At this point, your PR should be blocked by the ESLint errors that appear throughout your code base. Each team member should pull the new branch and edit/commit/push at least one (different!) module so that it passes the lint tests.

    Feel free to edit the lint configuration to allow/disallow certain syntactic patterns as your team chooses.

For this lab, you may not have time to fix up all the lint errors, but we’ll check that each team member has committed/pushed one module of fixed code to the new branch for the PR.

Your team will need to finish the client repo and then do the same for your service repo for this sprint.

Working with your Team

Rolling Out Your Test Prototype

To prepare your construction deliverable prototype for testing, do the following:

  1. Run a pilot user test — Conduct a thinking-aloud study of your main prototype with me as your first test subject. This will give you a chance to practice and to modify your test protocol as necessary before running actual subjects. Your whole team doesn’t necessarily need to be there during your test sessions (with me or anyone else), but it’s recommended that at least two of you be there to conduct/monitor every test.
  2. Schedule tests — Schedule test times with each of your team’s stakeholders and a list of other students whose contact information I will give you. This set of tests will serve has your team’s usability test deliverable.
Exercise 11.3

Run your pilot usability test with me before Thanksgiving break and before you run any other students (particularly students from outside this course).

Create GitHub issues for significant incidents (i.e., observed, potential failures that must be investigated) that occur during this or the other user tests.

Contact your assigned test subjects, complete the tests, and report the results by the beginning of the next lab period. We expect you to take reasonable steps to connect with your subjects: email them up to two times if necessary to schedule a testing time; if they miss the time twice and it’s difficult to reschedule, then give up on them.

Release Planning

Here, we make plans for the next (last!) sprint.

Exercise 11.4

Participate in your team meeting. Important topics include:

Checking in