[SW 정글 121일차] 나만의 무기 29일차 (완성도를 높이자)

내일은 운영진님들에게 우리의 프로젝트를 선보이는 공식적인 마지막 발표자리를 가진다.

내일 발표 때는 최종발표(12월 11일) 때 보여주는 것과 같은 발표 플로우와 서비스 데모를 해야한다.

이를 위해서는 우리가 만든 서비스가 완성품이여야하고 이를 위해서는 우리가 지금까지 만든 프로젝트에서 무언가 기능적인 것을 더 추가하는 것이 아니라 서비스의 완성도에서 부족하고 디테일한 부분을 생각하고 채워야할 시간을 가져야한다.

그리고 발표 준비를 해야한다.

발표는 조장님이 하지만 우리가 5주동안 얼마나 노력을 했고 어떠한 고민들을 했는지를 잘 녹여내어 말하기 위해서는 조원으로서 의견과 피드백을 해줘야한다고 생각한다.

 

오후 3시에 멘토링을 1시간 정도하고 회의시간을 가졌다.

회의 정리는 아래와 같다.

 

지금 우리의 서비스에서 기술적으로 빠진 것을 정리하고 발표, 시연에서 우리가 보여주고 싶은 것을 정리했다.

그리고 각자가 할 수 있는(할 수 있다는 것은 오늘 주어진 짧은 시간 내에 완벽하게 처리해낼 수 있는 것)것을 맡았다.

나는 main page에서 보여주는 생명체 데이터 api 수정작업을 맡았다.

 

기존에는 인증 누적 횟수가 가장 높은 50마리의 생명체에 대한 데이터를 보내주는 방식이였다.

하지만 조금 더 다양한 챌린지를 참여하는 생명체를 메인 페이지에 보여주자는 기획변경이 생기면서 보내줘야하는 생명체 데이터도 변경됐다.

 

 

변경된 사항은 각 챌린지 중에 인증 누적 횟수가 가장 높은 생명체를 보내는 것이고 보내는 생명체는 50마리, 즉 챌린지가 50개로 제한된다.

이를 위해서 쿼리문을 수정했다.

let columns = `T.id AS id, challenge_id, T.created_date AS created_date, alien_name, color,
               accumulated_count, T.image_url AS image_url, practice_status, end_date,
               alien_status, times_per_week, sun, mon, tue, wed, thu, fri, sat,user_info_id,
               email, nickname AS user_nickname, challenge_name, description, maximum_number,
               participant_number, challenge.created_date AS challenge_created_date`;
      
let alien_table_columns = `id, challenge_id, created_date, user_info_id, alien_name, color,
     accumulated_count, image_url, practice_status, end_date,
     alien_status, sun, mon, tue, wed, thu, fri, sat,
     ROW_NUMBER() OVER (PARTITION BY challenge_id ORDER BY accumulated_count DESC) AS RankNo`;
      

let sql = `SELECT ${columns} FROM (SELECT ${alien_table_columns} FROM alien) T
           JOIN user_info ON T.user_info_id = user_info.id
           JOIN challenge ON T.challenge_id = challenge.id
           WHERE RankNo = 1 AND alien_status = 0 LIMIT 50;`;

<참고자료: https://spaghetti-code.tistory.com/25>

이 쿼리를 짜면서 새롭게 안 것은 PARTITION BY와 OVER이다.

지금은 deep하게 알아볼 시간을 가지지 못하지만 프로젝트를 마무리하면 알아보고 싶은 것 중 하나이다.

 

api를 만들면서 다양한 쿼리문을 작성했는데 다양한 쿼리들이 어떻게 동작하는지를 알아보지 못한 것이 아쉽다.

프로젝트를 진행하면서 DB를 보는 일과 쿼리를 짜는 일이 대부분이여서 DB에 대해 더 많은 관심과 궁금증이 생긴다.

 

 

이외에도 짜잘짜잘한 수정작업이 들어갔다.

생명체 생성 시에 사용자가 선택할 수 있는 생명체가 추가되면서 생명체 생성 api도 수정되었다.

 

그리고 채팅 기능에 이모티콘을 추가하면서 RDS 설정과 테이블 column에 charset 옵션을 변경하는 작업을 했다.

특수문자이다보니 해당 문자가 들어갈 수 있도록 추가적인 옵션을 설정하는 작업이 필요했고 구글링을 통해 빠르게 해결할 수 있었다.

<참고 자료: https://artiiicy.tistory.com/31>

SHOW GLOBAL VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';
테이블 컬럼 TEXT, charset-> 'utf8mb4'


utf8과 utf8mb4의 차이점?
이모지와 같은 글자들은 글자당 최대 4bytes가 필요
하지만 utf8은 글자당 최대 3bytes까지 지원하는 가변 자료형
따라서 가변 4bytes의 문자열을 저장할 수 있는 utf8mb4를 사용하면 이모지를 저장할 수 있음.

 

 

어제 새벽까지 진행한 socket.io와 redis를 연결하여 소켓서버 scale out을 구현하는 것을 해내지 못해서 자신감이 낮아졌지만 오늘은 빠르게 해야할 일을 처리해내서 새롭게 안 것들이 생겨서 좋았고 다시 redis socket 연결도 반드시 해내고 싶다는 마음이 불타올랐다.

지금 우리의 서비스에서는 scale out까지 할 트래픽을 받지는 않겠지만 '트래픽이 높아지면 소켓서버를 scale out하고 각 소켓 서버끼리 통신을 하기 위해서 매개체로 redis를 쓰는 것을 고민해봤어요'로 끝내는 것보다는 직접 해보고 싶은 마음도 있다.

 

 

 

 

<해야 할 일>

드디어 동시성에 의한 문제가 발생한 것일까?

챌린저 참여자 수에 -2라는 값이 저장되어 있다...

lock에 대해 알아보고 적재적소에 사용해야 할 필요성이 느껴졌다.

해야할 일은 산더미처럼 쌓이는 중이다.

이 부분은 반드시 잡아야하는 부분이다.

프로젝트가 끝나도 해보지 못한 것이 있으면 시간을 내서 해봐야겠다.

 

 

- 갑자기 발생한 이슈...

새벽 4시 30분. 발표 때 보여 줄 시연을 위해 최종적으로 git merge를 하고 배포를 하려고 했는데 react를 build하던 중에 error(js heap out of memory)가 발생했다...

현재도 배포를 담당하고 있는 조장님이 열심히 잡고 있는 중이다.

내가 해줄 수 있는 일이 있을까?라는 마음에 남아있지만 도움이 되지는 못하고 있다..