Assignment 7

Release 1.4

Links to Submitted Files

• Frontend repository
• Backend repository
• Updated use cases as per discussion between Tony and teaching team

Progress and Contents Summary

In this release, our team has made significant progress in . . . literally everything. This submission includes:

• The Dashboard UI, implemented and dynamic (interacts with backend, fully wired)
• The Reading Karaoke flow, imported and providing real feedback (interacts with backend, fully wired)
• A settings page (which doesn't interact with the backend but allows users to change the language they're using on the frontend for demo purposes)

Summaries of Issues Addressed

In the time since A5 was due, many many issues were addressed spanning all parts of our application. You can see them through this link to Jira

Changes to the Roadmap, Architecture, or Use Cases

Use Case Updates

• Certain items were moved out of scope, after discussion with the teaching team. For details, see #41.
• Note that "Button to go to aggregated feedback" is actually more like "button to go to sentence overview page".

Additional Notes

Code Quality

We enforce code quality across both our backend and frontend codebases by integrating linting tools into our CI workflow.

On the backend, we use Ruff, a fast and modern Python linter. Ruff is significantly faster than traditional Python linters like Flake8 or pylint, which allows it to be seamlessly integrated into our CI without slowing down the pipeline. It enforces a wide set of style and correctness rules, helping us catch issues such as unused imports, undefined variables, and stylistic inconsistencies early in the development cycle. Ruff's zero-dependency design and compatibility with common configurations (like Black or isort) make it an ideal choice for maintaining clean, maintainable Python code.

On the frontend, we use ESLint with a custom configuration tailored to our team’s coding standards. Our ESLint setup includes rules for both stylistic consistency and best practices in React and modern JavaScript/TypeScript development. For example, it enforces consistent hooks usage and prevents dangerous patterns like direct DOM manipulation. Our custom rules are designed to promote readability and consistency, reduce bugs, and maintain a high standard of code across the team.

Both tools are tightly integrated into our GitHub Actions CI pipeline. Every pull request runs linting checks automatically, and code cannot be merged unless it passes. This ensures continuous enforcement of our code quality standards. Note that we have three separate workflows that are run on every push to a branch with an active pull request. For the sake of illustration, consider PR #25 on the frontend repository.

1. Build and Lint. This is how we ensure our entire frontend codebase is properly formatted, as this workflow fails if npm run lint produces any issues.
2. Playwright Tests. This ensures that the PR does not introduce breaking changes that would affect core flows within the application.
3. Enforce our PR title naming conventions. This maintains a standard naming scheme and allows us to easily trace which PRs correspond to which Jira tickets.
   Once all of the above is complete and one other developer ensures any issues they've seen are resolved and approves the PR, we then automatically deploy the newly-merged code.

The backend pipeline behaves similarly. For example, with PR #20 on the backend, we have:

1. Build, Test, and Lint building the backend, running our PyTest unit tests, and then running Ruff to ensure our code is properly linted. Notice that one of the actions includes a generating a code coverage report and uploading to CodeCov. As shown in this report, we have 65%+ test coverage. For the purposes of this submission, this is our chosen CI example run.
2. Enforce our PR title naming conventions.

We track maintainability through Code Climate:

• Frontend: Currently rated D for maintainability. We recognize this as an area that needs improvement, and have started identifying high-complexity files and refactoring opportunities as part of ongoing cleanup efforts (e.g. the page.tsx for the Reading Karaoke is very large, and should be broken down similar to the page.tsx for the Dashboard).
• Backend: Currently rated B for maintainability. This is acceptable for now, though we continue to monitor and address hotspots as they arise.

Our current linting and test coverage are satisfactory on the backend and somewhat satisfactory on the frontend for the team at present. We will continue to improve our code's quality and reduce our technical debt as the codebase evolves in our pursuit of making Pera a world-class pronunciation trainer.

Accessing the application

Pera can be used at https://pera-dydhd2huhybjakgg.canadacentral-01.azurewebsites.net/.
To get started, you can login with the following (this account has some practice history):
Username: tony@gmail.com
Password: test

Alternatively, you can create an account here:
https://pera-dydhd2huhybjakgg.canadacentral-01.azurewebsites.net/sign-up

WCAG Checklist

Guideline	Summary	Description of how you accommodated this
1.1.1 – Non-text Content	Provide text alternatives for non-text content	All graphs on our dashboard have tooltips that summarize the content in text form when the user hovers over it. We also have alt text on some images.
1.2.1 – Audio-only and Video-only (Pre-recorded)	Provide an alternative to video-only and audio-only content	We do not have any pre-recorded audio or video content
1.2.2 – Captions (Pre-recorded)	Provide captions for videos with audio	We do not have any videos on our application.
1.2.3 – Audio Description or Media Alternative (Pre-recorded)	Video with audio has a second alternative	We do not have any videos on our application.
1.3.1 – Info and Relationships	Logical structure	Our website follows general standards used across most modern websites (e.g. Having a navbar in the top or left half of the screen).
1.3.2 – Meaningful Sequence	Present content in a meaningful order	Our website follows general standards used across most modern websites (e.g. Having a navbar in the top or left half of the screen).
1.3.3 – Sensory Characteristics	Use more than one sense for instructions	We do not have non-visual items to help with navigation or instruction at this time, but hope to create sample audio in the future
1.4.1 – Use of Colour	Don’t use presentation that relies solely on colour	Most graphs on the dashboard only have color as an aesthetic instead of a data source. Highlighted text on errors is only one color, for instance, and we use a dark color so it is very distinguishable regardless.
1.4.2 – Audio Control	Don’t play audio automatically	We do not have audio to play.
2.1.1 – Keyboard	Accessible by keyboard only	Users can use the tab and enter keys to navigate between buttons and click on them.
2.1.2 – No Keyboard Trap	Don’t trap keyboard users	We do not use the tab or escape keys for any purpose with our application, so users are not prevented from un-focusing UI elements (and so are not trapped).
2.2.1 – Timing Adjustable	Time limits have user controls	No time limits are used.
2.2.2 – Pause, Stop, Hide	Provide user controls for moving content	No content can be moved, except for a slider which can be selected by tabbing and then the value c...

Assignment 5

Release 1.3

Links to Submitted Files

• BE service.yml
• BE bootstrap script
• FE service.yml
• FE bootstrap script
• Dockerfile
• Deployment Dashboard image
• Sentry Dashboard image

Progress and Contents Summary

In this release, our team has made significant progress in setting up a basic development environment. This includes

• Updating our FE to include Sentry and Playwright for testing and logging
• Updating our BE to include Sentry and PyTest for testing and logging
• New scripts for setup and installation
• Deployment! (see here)

Summaries of Issues Addressed

The following issues were addressed since the last release:

1. DEV-41: Dockerize BE (dcsil/pera-be#2)
2. DEV-68: Add initial BE Test (dcsil/pera-be#3)
3. DEV-71: Integrate Playwright (dcsil/pera-fe#4)
4. DEV-72: Integrate Sentry FE (dcsil/pera-fe#3)
5. DEV-77: Integrate Sentry BE (dcsil/pera-be#4)
6. DEV-79: Enable and Build Test CI (dcsil/pera-be#5)
7. DEV-80: Add service.yml and bootstrap script (dcsil/pera-fe#5 and dcsil/pera-be#7)

Status

We are slightly behind schedule on our roadmap due to the extended time required to set up the base environment. However, we have made significant progress by adding testing, Dockerizing the backend, and establishing working deployments. No updates have been made to ADRs or use cases at this time. Overall, we are making steady progress and expect to catch up for upcoming milestones.

Assignment 4

Release 1.3

Links to Submitted Files

• Updated use cases
• Updated sketch for reading karaoke UI
• Use case 5: AI-powered reading passage generation sketch
• UX research report
• Backend API documentation ADR

Progress and Contents Summary

In this release, our team has made significant progress in conducting our first UX study and defining our MVP scope. This submission includes:

• Updating our use cases with MVP specifications #38 #39
• Report of our UX research #40
• ADR for our use of Azure's API Management #36

Summaries of Issues Addressed

The following issues were addressed since the last release:

1. DEV-3
   • Description: Create initial backend service
   • Resolution: Created Hello World Django app
2. DEV-35
   • Description: Add contributing guidelines
   • Resolution: Contributing guidelines document created in Confluence, team requested for review.
3. DEV-36
   • Description: Implement BE API documentation
   • Resolution: Setup automatic doc generation using drf-spectacular on our BE app.
4. DEV-39
   • Description: Research API management options
   • Resolution: We've decided to use Azure's API Management.
5. DCS-43
   • Description: Update use cases
   • Resolution: Updated the product_research/use_cases.md file with our MVP scope
6. DCS-38
   • Description: Update UX research script and slides
   • Resolution: Fixed a number of errors in our mockup slides and improved our script for performing UX studies
7. DCS-40
   • Description: Complete (remaining parts of) UX research report
   • Resolution: Report completed and included in the team repo as a PDF
8. DCS-41
   • Description: Change wording in use cases paragraph
   • Resolution: Fixed minor wording issue in speaking karaoke use case
9. DCS-33
   • Description: Write ADR for BE API documentation framework
   • Resolution: Use drf-spectacular as our API documentation tool for the backend

Changes to the Roadmap, Architecture, or Use Cases

Roadmap Updates

We have integrated feedback from the teaching team's review of our use cases into our roadmap.

In accordance with the teaching team's recommendation to drop some use cases, we decided to drop the long reading and convobot use cases from our MVP. The epics associated with these two use cases have been reordered to after the end of the course.

Based on our team's capacity and the wow-factor delivered, we chose to keep the reading karaoke use case over long reading. To faciliate faster delivery and greater technical clarity for the work related to the karaoke feature, we've split the work into multiple epics. Some of these epics are scheduled for the future (i.e. after the course) because we will not include them in our MVP. Furthermore, some tickets have been created or changed within these epics to reflect our decided MVP scope.

Based on the teaching team's feedback, we have also split the AI-generated text feature into its own use case and corresponding epic. Lastly, we rearranged some tickets concerning the dashboard use case to reflect our decided MVP scope.

Assignment 3

Release 1.2

Links to Submitted Files

• CI/CD ADR
• FE language ADR
• FE framework ADR
• FE + BE Telemetry ADR
• FE testing ADR
• Cloud provider ADR
• BE architecture ADR
• BE language + framework ADR
• BE testing ADR
• DB ADR
• Azure speech ADR
• Architecture diagram
• Use cases
• Use case 1: Reading karaoke UI sketch
• Use case 2: Long reading UI sketch
• Use case 3: Convobot UI sketch
• Use case 4: Dashboard UI sketch

Progress and Contents Summary

In this release, our team has made significant progress in designing the use cases and technical architecture for our solution. This submission includes:

• ADRs #26 #27 #28 #29 #30 #33 #34
• Use cases and related lo-fi sketches #31
• Architecture diagram #32
• Updating our ADR numbering convention #34

Summaries of Issues Addressed

The following issues were addressed since the last release:

1. DCS-1

   • Description: Write ADR for backend language and framework.
   • Resolution: Decided on Django as the backend framework, running on Azure App Services.

2. DCS-2

   • Description: Write ADRs for frontend language and framework.
   • Resolution: Selected React with Next.js for the frontend framework.

3. DCS-3

   • Description: Write ADR for database choice.
   • Resolution: Decided on PostgreSQL hosted on Azure for the database.

4. DCS-8

   • Description: Write ADR for hosting provider and infrastructure.
   • Resolution: Chose Azure App Services as the hosting platform.

5. DCS-9

   • Description: Write ADR for backend telemetry.
   • Resolution: Integrated Sentry for backend monitoring and telemetry, merged ADR write-up into the front-end telemetry ticket.

6. DCS-10

   • Description: Write ADR for frontend telemetry.
   • Resolution: Decided to use Sentry for frontend monitoring and telemetry.

7. DCS-11

   • Description: Write ADR for CI/CD solution.
   • Resolution: Implemented GitHub Actions for CI/CD pipelines.

8. DCS-6

   • Description: Create architecture diagram.
   • Resolution: Designed architecture diagram including all of the directly production-facing tools we currently plan to use.

9. DCS-17

   • Description: Write ADR for backend architecture.
   • Resolution: Decided on a monolithic architecture with Django as the server app.

10. DCS-21

    • Description: Write ADR for FE Testing.
    • Resolution: Chose Playwright as the frontend testing framework.

11. DCS-24

    • Description: Write ADR for BE Testing.
    • Resolution: Decided on Pytest as the backend testing framework.

12. DCS-18

    • Description: Add lo-fi sketches of use cases.
    • Resolution: Integrated into use cases descriptions

13. DCS-19

    • Description: Add use cases
    • Resolution: Wrote up preliminary use cases with descriptions and relationship to tech stack.

14. DCS-30

    • Description: Write ADR on cloud speech service utilities
    • Resolution: Decided on Azure Speech Services for our pronunciation-specific use cases.

15. DCS-25

    • Description: Update ADR README with our conventions
    • Resolution: Documented our new ADR naming conventions in the ADR README.

Changes to the Roadmap, Architecture, or Use Cases

Roadmap Updates

• Roadmap was made to provide our team a sense of direction.

Architecture Updates

• Included a new architecture diagram to indicate our initial direction as we commence development.
• Added ADRs reflecting our new architecture: Django as the backend framework, React with Next.js for the frontend, PostgreSQL for the database, Azure App Services for hosting, Sentry for backend and frontend telemetry, GitHub Actions for CI/CD, a monolithic architecture, Playwright for frontend testing, and Pytest for backend testing.

Use Case Updates

• Four proposed use cases have been added to the repository under the product_research folder, as per assignment guidelines. They will be discussed and approved / modified in consultation with the teaching team during / after Demo 1.

Additional Notes

None

Assignment 2

Release 1.1

Links to Submitted Files

• diversity.md

Progress and Contents Summary

In this release, our team has made significant progress in understanding each others' core competencies, strengths, and weaknesses. We have also isolated some subject matter experts to further our knowledge in the markets we plan to compete in. This submission includes:

• An updated diversity.md file

Summaries of Issues Addressed

The following issues were addressed since the last release:

1. Minor typos and grammar fixes throughout the team repository (Issue)
2. Revise meeting planning information in principles.md (Issue)
3. Completed diversity.md (Issue)

Additional Notes

diversity.md was updated in one pull request, but we all worked together to draft this document on a Google Doc prior to this, and divided the work for this assignment equally.

Assignment 1

Release 1.0

Links to Submitted Files

• Team Profiles
  • Krishna
    • Profile Markdown
    • Profile Picture
    • Resume
  • Wilson
    • Profile Markdown
    • Profile Picture
    • Resume
  • Tony
    • Profile Markdown
    • Profile Picture
    • Resume
  • Leonid
    • Profile Markdown
    • Profile Picture
    • Resume
  • Parth
    • Profile Markdown
    • Profile Picture
    • Resume
  • Team readme file
    • This file details the roles each member of our team will take on for this project
    • This also describes the team leader and why they were elected to lead our team
• Team principles
• Repository readme
  • Includes short description of company
• Company logo

Progress and Contents Summary

In this release, our team has made significant progress in understanding each other's core competencies and work styles. This submission includes:

• Completed team profiles and related assets
• Description of our team principles
• Company name and description

Additional Notes

Our team leader is Wilson Sy. You can learn more about him here and discover why we selected him to lead us here.