📜 Week 4

목표 & 구현 계획

• 채점 방식을 socket 통신 요청 + API 요청 ⇒ socket 통신 한번에 저장하도록 반영

  • 소켓 전송 부분 refactoring (테스트 하나 끝나면 즉시 따로따로 보낼건 지 or 전체 테스트 결과만 한 번에 전달 할 것인지)

• 결과를 어떻게 보여줄 것인가

  • 별도의 페이지 생성? Modal로 처리?
  • 선택 - 결과 페이지 생성 땅땅
  • 뒤로가기 눌렀을때 코드 저장 가능하면 하기

• 사용자가 이 사이트가 어떤 사이트인지 알고 있다고 가정하고 진행했기 때문에 전체적인 문맥을 살펴볼 수 있는 페이지를 만들자 (대쉬보드 페이지 혹은 소개 페이지)

  • 백준 메인 페이지 처럼 웰컴 페이지 작성 (상단에 로고 이미지, 하단에 소개 및 서비스에 대한 통계[총 문제 수, 전체 제출 수, 많이 제출한 문제])
  • 노션에서 참고한다.

• PR날릴때 제목에 [매우중요!][별로] 이런거 넣을까?

  Conventional Commits

  Conventional Commits

• refactoring : 메시지를 변수화 하자 ⇒ ### 마크다운을 작성합시다. ← 이런거 (다음주 리팩토링 때에)

• 개인 통계 페이지???

• 문제 submitLog에 대한 Read API 개발(회원 별로)

• https certbot && websocket wss 적용

데모 시나리오

전체 데모 + 결과 페이지(실시간 채점 과정)+문제 풀이 페이지(코드 validation) 처리 + chai 가이드 라인 제시

1. 사용자가 URL에 접속하면 소개 페이지를 보여준다. (구현 못했을 경우에는 리스트 페이지 위에 소개 문구를 추가한다.)
2. 사용자가 로그인 버튼을 누르고, GIthub OAuth로 로그인한다.
3. 사용자가 문제 리스트 페이지로 이동하여 문제 하나를 선택한다.
4. 사용자가 선택한 문제의 문제 풀이 페이지로 이동하여 문제를 푼다.
5. 사용자가 문제 출제 버튼을 눌러 문제 출제 페이지로 이동한다.
6. 사용자가 문제를 출제하고, 테스트 케이스 가이드라인을 확인한 다음 테스트 케이스를 작성한다.
7. 사용자가 문제 리스트 페이지로 이동하여 출제한 문제를 선택한다.
8. 사용자가 문제 풀이 페이지로 이동하여 출제한 문제를 푼다.
9. (개인 프로필 페이지가 구현되었다면) 사용자가 개인 프로필 페이지로 이동하여 문제 풀이에 대한 사용자의 통계를 확인한다.

이번주 우선순위

1. 채점 방식을 socket 통신 요청 + API 요청 ⇒ socket 통신 한번에 저장하도록 반영
   • 소켓 전송 부분 refactoring (테스트 하나 끝나면 즉시 따로따로 보낼건 지 or 전체 테스트 결과만 한 번에 전달 할 것인지)
2. 결과를 어떻게 보여줄 것인가
   • 별도의 페이지 생성? Modal로 처리?
   • 선택 - 결과 페이지 생성 땅땅
   • 뒤로가기 눌렀을때 코드 저장 가능하면 하기(localStorage 이용)
3. 로그인 상태 전역에서 관리
4. validation(검증)
   • 문제 풀이 코드(채점 시) 코드가 문법적으로(Syntax Error) 올바른 코드인 지 validation
   • 프론트엔드의 검증 코드를 백엔드로 옮기는 것이 1차 적인 검증
   • 문제 출제 페이지에서 테스트 코드가 chai 문법에 맞는 지, 안 맞는 지 확인(validation)
   • chai 공식 문서 홈페이지 링크를 가이드라인으로 제시를 해야 할 듯
     • 별도의 API를 통해 chai api를 쉽게 호출할 수 있도록
     • ? 아이콘에 마우스를 올리면 간단하게 가이드라인이 나오도록 해도 괜찮을듯
5. 사용자가 이 사이트가 어떤 사이트인지 알고 있다고 가정하고 진행했기 때문에 전체적인 문맥을 살펴볼 수 있는 페이지를 만들자 (대쉬보드 페이지 혹은 소개 페이지)
   • 백준 메인 페이지 처럼 웰컴 페이지 작성 (상단에 로고 이미지, 하단에 소개 및 서비스에 대한 통계[총 문제 수, 전체 제출 수, 많이 제출한 문제])
   • 노션에서 참고한다.
6. https certbot && websocket wss 적용