fpzmfks 님의 블로그

오늘은 어제보다 더 정신없는 하루를 보냈다. 핵심이 되는 party_info 테이블을 삽입하는 로직이 어느 정도 완성되었기 때문에 이 데이터를 기반으로 여태껏 만들어둔 로직을 테스트하려니, supabase 세팅 관련으로 문제가 있다는 것을 깨달았다.  문제라고 해도 어떤 오류가 있었던 것은 아니고, 서버 컴포넌트와 클라이언트 컴포넌트에서 사용하는 supabase 세팅이 다르다는 것을 기존에 고려하지 못했던 것이었다. 이 점을 고려한다면 서버 컴포넌트와 클라이언트 컴포넌트에서 다 사용되는 로직들은 각각의 세팅을 기준으로 1개씩, 총 2개를 작성해야한다.  이렇게 서버 컴포넌트와 클라이언트 컴포넌트에서 모두 사용되는 로직으로는 대표적으로 getLoginUserId함수가 있고 이 함수를 총 2개 만들어서 공유..

오늘은 하루종일 기능 구현에 매달렸다. 오늘 구현한 기능은 재생 바와 파티 상태 처리 기능인데, 후자는 제대로 테스트를 할 수 없으니 당장에는 간단하게 넘어갔으나, 전자는 생각보다 까다로워서 시간을 많이 잡아먹었다.  어려웠던 것재생 바를 구현하는 데에 생각할 점은 현재시각을 불러온다고 해도 자정00:00을 넘으면 현재 시각이 초기화된다는 것이다. 때문에 나는 오전 8시를 기준으로 삼아서 if(현재시간이 오전 8시 이전이고 && 시작시간이 오전 8시 이전이 아닌 경우)에 현재 시각에 24시간을 더하기로 했다.  아래가 현재시각을 반환하는 함수이다. const getPlayTime = (startPlayTime: number) => { // 현재 시각 const nowTimeArr = [new Date..

오늘은 본격적으로 프로젝트를 진행하기 시작하며 프로젝트를 세팅하고, 각자 우선순위가 높은 순으로 기능을 구현하기 시작했고, 기능을 구현하기 시작하면서 눈에 들어온 ERD의 미흡한 부분을 수정하였다.  아래는 회의록인데 대부분 ERD 수정사항이다.  회의록team_user_profile과 party_info의 외래키 관계 수정ERD에서 필수적인 데이터(party_id) 누락 수정영상 id와 영상 종류가 있어야 데이터를 불러올 수 있으니까 party_info에 영상id와 영상 종류 열을 추가하면 좋을 것 같다type오류 때문에 날짜와 시간을 따로 관리하는 게 더 편할 것 같아서 날짜와 시간을 따로 관리하기로 하였다..prettierrc가 잘 안되었는데 아래 부분을 지우니까 잘 되었다."plugins": ["..

오늘은 와이어프레임을 구성하면서 프로젝트 구조를 약간 개선하고 그에 따라 역할 재분배를 했다. 또한 어제 작성한 ERD를 튜터님께 확인받으면서 ERD 구조도 조금 변화시켰다.  아래는 와이어프레임을 작성하면서 논의한 내용을 기록한 회의록으로 프로젝트 구조를 개선한 내역이라고 봐도 될 것 같다. 중요한 것은 두 가지로 상세페이지를 없애고 파티페이지만 운영과 파티정보 테이블 2개를 하나로 합침이다.  회의록팔로우 후 이웃에 대한 정보를 어떻게 제공할지 생각해보면 좋을것 같다 ex) 어떤 영상을 같이 봤는지최초 로그인 시 프로필 정보를 입력할 수 있도록 ERD 구성이때 선호 장르, 이용 플랫폼, 닉네임 작성기능이 비슷한 페이지 두 개를 하나로 합침상세페이지를 없애고 파티페이지만 운영초대하기 기능을 초대장 방식..

오늘은 다들 만족하는 기획 주제를 확정할 수 있었다. 원래 일요일에 모여서 기획 주제를 확정해보려고 했는데 마땅한 의견이 안 나와서 오늘 다시 회의를 해보고 최종 결정하게 되었다.  우리 팀의 기획은 이전에 '팀을 모아서 사이드 프로젝트를 제작하는 사이트'에서 '팀을 모아서 영상을 시청하고 그에 관한 채팅을 하는 사이트'로 최종확정하였다. 이전 기획에서 변형을 더한 기획인 만큼 페이지별로 프로젝트 구조를 잡고 기능들을 나누는 것에 그리 오래 걸리지는 않았다. 아래가 MVP(Minimum Viable Product) 를 개발하기 위해 필수 기능을 정리하고 우선순위를 나누어 역할까지 대충 정한 리스트이다. 나는 상세페이지를 맡았는데 쉬운 부분이라 내 파트를 끝내고 나서 다른 팀원들이 도움을 필요로 하지 않는..

오늘은 어제 생각한 아이디어를 바탕으로 주제를 정하고, 레퍼런스를 분석한 뒤, 페이지별 기능과 MVP를 작성하고, 유저 플로우 또한 작성해 보았다.  이러한 내용들을 피그마를 통해서 작성했는데, 하루만에 이만큼 많이 진행이 되어서 뿌듯했다. 하지만 막판에 판이 뒤집히고 말았는데...  우리가 진행하려고 한 프로젝트의 주제는 '사이드 프로젝트 팀 모으기 사이트'이다. 팀 단위의 사이드 프로젝트를 진행하기 위해서 팀을 모으려고 할 때 도움을 줄 수 있는 사이트로, 이러한 목적성 아래에 생각할 수 있는 기능이 많아서 좋다고 생각한 아이디어였다. 하지만 튜터님의 따끔한 말씀에 따르면 첫째, 팀원 4명이 진행하기에는 필수적인 기능이 너무 많다.둘째, 실용성이 떨어진다. 개발자들이 이러한 사이트를 통해 팀원을 모으..

오늘은 프로젝트를 종료하며(그리고 부족한 시간으로 인해 발표 직전까지 계속 코드를 고치며) 프로젝트를 회고하고 지적받은 점들을 기록해두려고 한다.  우선 아래는 팀에서 작성한 회고이다. Keep - 현재 만족하고 있는 부분필수 구현 사항을 기한 내에 구현해서 프로젝트를 잘 마무리할 수 있었다.팀 내에서 의논할 것이 있으면 의사소통을 통해 문제를 해결할 수 있었다.다양한 상황에 맞춰 유연하게 문제를 해결하고 대처할 수 있어서 좋았다.Problem - 불편하게 느끼는 부분의사소통 과정에서 이야기가 너무 길어지는 경우가 있었다.팀원들과의 기획 단계에서 어떤 기술을 사용할 것인지에 대한 내용을 미리 더 생각했으면 좋았을 것 같다.Try - Problem에 대한 해결책, 당장 실행 가능한 것되도록 사실 관계를 확..

오늘은 어제 얼추 마무리한 프로젝트를 최종 병합한 것을 붙들고 트러블 슈팅을 한 후에 배포를 했다.  여태껏 테스트가 충분하지 않아서 부족함을 느꼈던 부분이 이번에 확실히 드러났는데, 마이페이지에서 새로고침을 하면 zustand에서 받아오는 userId가 빈 문자열 ' ' 이 되었다가 제대로된 userId 'dfasofiasoeijfwoeif'로 받아와지는 현상이 있었다. 이로 인해userId로 불러와지는 post 데이터들이 리렌더링을 해주지 않으면 반드시 보이지 않는 상태가 되어버렸다.  이를 해결하기 위해서 나는 처음에 zustand에서 초기값 설정을 잘 해주면  userId가 빈 문자열 ' ' 이 되었다가 제대로된 userId 'dfasofiasoeijfwoeif'로 받아와지는 현상 이 일어나지 않..

오늘은 그동안 한 것들을 그러모으고 트러블 슈팅하면서 내가 맡은 모든 기능을 완성했다.  스크랩 기능(supabase 정책)먼저 지난번에 status:204는 뜨는데 실질적으로 supabase에는 반영되지 않던 오류는 예상대로 supabase 테이블 정책을 설정해주지 않았기 때문이었다.  스크랩 기능(ERD 구조 변경)이렇게 delete 정책을 설정해주니 CRUD가 잘 되는 것을 확인할 수 있었다. 또한 이렇게 스크랩 기능으로 고생하는 중에 로직을 단순화시키자 싶어서 ERD 구조를 바꾸었다. 북마크된 게시글을 배열varchar[]로 관리하려던 것을 1:1 관계를 가지도록 변경한 것이다. 아직 잘은 모르겠지만 튜터님은 이렇게 변경한 것을 보시더니 이게 정석적인 스크랩 기능 ERD 구조라고 하셨다.  필터 ..

주말 동안 잠깐잠깐씩 프로젝트를 진행하고, 오늘에 이르러 본격적으로 프로젝트를 시작했다. 좀 더 정확하게 말하자면 이전까지는 데이터를 받아와서 뿌려주는 것까지만 했고, 오늘부터 업데이트, 삭제, 필터링 기능을 구현하기 시작한 것이다.  그런데 본격적으로 '좋아요' 기능을 구현하려고 하니 자꾸만 state:204가 뜨면서도 supabase에는 반영이 되지 않는 오류가 생겼다. 튜터님께 문의해봐도 원인을 찾지 못해서 한참 이것저것 테스트를 해보다가 supabase 강의를 다시 보게 되었는데, 애초부터 supabase 세팅을 잘못했다는 것을 알게 되었다. next.js에서 supabase를 사용하려면 server컴포넌트와 client컴포넌트에서 각각 다른 supabase를 사용해야 하고, middleware ..