본문 바로가기

분류 전체보기42

개발일지 - 20일차: 프론트 구성 및 연결 일단 프로젝트 내에서 코드 구현은 얼추 끝났기 때문에 유저 테스트를 위해 배포와 프론트 구성을 해야 했다. 우리 팀은 프런트 구현에 Vue를 사용하기로 했다. React와 Vue중 선택을 해야 했는데, 아무래도 백엔드에 집중을 해야 하다 보니 러닝커브가 상대적으로 적은 vue를 사용하기로 했다. 일단 vue-cli와 node.js를 다운받고 프론트를 구현중이다. 사실 프론트에 대해서는 아직까지는 크게 오류나 어려운 부분은 없었다. 대부분 러닝커브로 인해 새로 배우는 내용이고, 기본적인 것만 구현중에 있기 때문이다. 2024. 3. 20.
개발일지 - 19일차: 발표 및 프론트 작업 월요일날 중간발표를 맡게 되어 발표를 진행했다. 처음 발표하는건 아니다보니 이전보다 긴장되지는 않았던 것 같다. 오늘은 튜터님에게 질문받은 것을 정리해보겠다. 1. 레디스의 메모리 관리, 캐시 관리는 어떻게 할 예정인가? → 랭킹 정보는 10개의 데이터가 유지되기 때문에 데이터의 크기나 관리 측면에서는 문제 없을 것이라 판단했다. 다만 검색 내역을 캐싱하는 과정에서 적당한 캐싱 전략이 필요함을 느낀다. 2. 성능 개선을 위한 테스트는 해 봤나? → 아직 테스트는 못해봤다. 추후 nGrinder나 유저테스트를 통해 코드를 개선해 나갈 생각이다. 3. 예상 유저 수는 몇명으로 생각했나? → 이것 또한 자세하게 염두해 두지 않은 부분이다. 비슷한 서비스를 제공하는 타 사이트를 참고해 예상 유저수를 도출하고, .. 2024. 3. 20.
개발일지 - 16일차: 버그 해결 및 원인 분석(2) 2. JsonParseException 어떤 상황에서 발생한 버그인가? 이전 포스트에서 결정한 랭킹 조회 알고리즘을 코드로 작성하고 테스트를 해 보던 와중 발생한 버그이다. 일단 스케줄러를 이용해서 일정 시간마다 resolution 테이블에서 likeCount 내림차순으로 10개를 가져온다. 이 후 해당 값을 redis에 List 형으로 저장한 후, 랭킹 조회 api가 호출될 시 redis에서 랭킹 데이터를 가져오는 방식이였다. 조회 api는 오직 redis만 바라보고 있어야 하기 때문에(RDB에 접근하는 코드가 있어서는 안된다.) redis에 저장된 데이터의 value가 바로 Response로 반환할 수 있어야 하는 값이어야 한다고 생각했다. 따라서 스케쥴러를 이용해 redis에 데이터를 집어넣는 과정.. 2024. 3. 15.
개발일지 - 16일차: 버그 해결 및 원인 분석(1) 어제 작성했던 코드에서 버그가 발생해서 오늘은 그 버그를 해결하는 과정을 기록하겠다. 발생한 버그는 2가지이다. 1. Resolved [org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Unsupported field: HourOfDay] 어떤 상황에서 발생한 버그인가? 구현을 완료하고 테스트를 하던 도중 목표 페이지의 조회가 갑자기 조회되지 않는 버그가 발생했다. 버그 코드는 403 에러, 즉 인증 관련 예외처리가 발생했다. 아래는 오류가 발생한 API 코드이다. @Operation(summary = "목표 전체 조회(페이징)") @GetMapping fun getResolutionListPa.. 2024. 3. 15.

티스토리툴바