4.27일 팀프로젝트 진행상황
notion으로 개발 계획 설계 및 업무 분장
Table 설계 및 column 정의

page 관계 설정

어려웠던 점
DB연결을 할 때 원격 pc에서 방화벽 설정을 풀어줘야 하는 부분이 있었다.
또한, 오랜만에 연결 test를 하려고 해서 기억이 잘 안났다.
방화벽은 원격pc의 인스턴스 설정에서 외부로의 연결을 허용해주면서 해결하였다.
column명 생성 규칙 통일
- colum명 규칙 : table명(소문자,2~4글자)_(언더바 사용)영어뜻(소문자사용)
- colum명 예시 : user_name , rc_tag 등
+협업 repository에 커밋을 했지만 잔디가 심어지지 않는 현상 발생
merge가 되면 이전에 커밋한 날의 기록까지 전부 잔디가 심어진다고 함.
'레시피 등록페이지'는 chef,admin 권한이 있는 사용자만 들어갈 수 있어야 한다.
따라서 권한이 없는 사용자인지 판별하여 로그인 페이지로 이동시켜야 한다.
그런데 권한 판별의 과정을 '레시피 등록'버튼을 누를 때 할 것인지, 혹은 '레시피 등록' 페이지 내부에서 할 것인지에 대해 의견이 갈렸다.
'레시피 등록'페이지에서 판별을 할 경우 페이지 진입 후 제일먼저 권한에 대한 판별 과정이 들어갈 것이므로 큰 차이는 없겠지만 성능면에서 느려지지 않을까라는 생각이 들었다.
물론 '레시피 등록'버튼을 눌렀을 때 판별하는 기능을 쓸 때도 같은 판별을 할 것이다. 하지만 이는 버튼을 눌렀을 때만 하는 것이므로 판별이 필요한 경우가 더 적을 수 있다.
그러나 이는 '레시피 등록' 페이지에 이 버튼을 누르고 들어갔을 경우만 생각했을 때이다.
만약 로그인한 사용자가 페이지에 들어갔다가. 로그아웃 한다면? 레시피 등록 페이지에서 나가져야 할 것이다. 따라서 등록 페이지에서 판별하는 것이 맞지 않을까 생각된다.
'레시피'라는 table에 여러가지 column이 들어간다. 나중에 종류별, 재료별, 테마별 등등의 조건으로 필터링하여 조회할 예정이다. 레시피를 등록할 때 역시 각각의 해당 내용들을 선택해야 한다. 그래서 나는 column의 수가 많아지긴 하지만 하나의 table에 들어가는 것이 맞다고 생각했다. 그래야 나중에 조회 query문을 만들 때 수월할 것이라 생각했다. 그러나 팀원은 필터링에 사용될 category를 하나의 table로 만들어 그 안에 종류별, 재료별, 테마별 등의 column을 넣고 table이 참조될 수 있게 짜야하지 않을까 의견을 제시하기도 하였다. 여러 시뮬레이션을 돌려본 결과 좀 더 효율적이라 생각했던 부분은 하나의 레시피 table에 모든 column을 넣는 것으로 결정하였다.
대부분의 page에 메인화면,(검색창 위치 미정)으로 가는 버튼이 보여야 한다.
따라서 header 및 footer를 먼저 만들고 각자 독립적인 작업을 하는 것이 좋아 보인다.
그래서 내일은 header와 footer 부분을 완성하는 것이 목표다.