2021.10.25
오늘은 백엔드에서 사용해야할 라이브러리를 조금 선택하고 선택 할 때 이 라이브러리를 사용하는 이유와 비교할만한 라이브러리가 있는지, 라이브러리가 있다면 왜 다른 라이브러리가 아닌 이 라이브러리를 선택했는지를 결정했다.
또한 TDD(Test Driven Develop)로 개발을 진행해보려고 했다. 아직은 TDD에 대해 많이 익숙하지 않아서 기본적인 유닛테스트만 진행해보고 기능을 구현해보자고 의견을 나누었다.
DB 구조에서 외래키에대한 source key가 변경될 때 cascade로 변경되는 것과 join을 통해서 계속해서 다른값을 불러오는 것 중 어느것이 효율이 좋지않냐고 물어봤을 때 source key를 변경하는것은 굉장히 효율이 좋지 않다. 서버에 부하가 많이 걸린다라고 답변을 받아 db구조를 다 바꿨다.
db를 다 짜고 모델을 만들어서 팀원들과 공유하여 서로 맞게 짯는지 확인했다.
2021.10.26
튜터로부터 받은 피드백
피드백을 하루 지연이 되서 디테일하게 봐준다고 하여 나온 피드백인데... 퀄리티가 별로 좋지는 않다고 생각한다. 너무 백엔드적으로 피드백이 온것 같기도 하고 다른조들과 너무 비슷한 피드백을 받은것도 없지않아 있고, 전체적인 프로젝트에대한 피드백을 원했는데 안에 들어가서 본 것 같지도 않아서 퀄리티가 별로였다.
이부분에 대해서는 다른사람들도 동의한 바라서 댓글에 피드백에 대한 불만을 토로했으나 그 불만에 대한 답변도 썩 맘에 들지는 않았다...
원했던 대답은 재피드백이나 좋은 방향으로 다시 나아가는 것이었는데 받은 대답은 원했던 대답이 아닌 이번에는 이렇게 한다! 라고 하는 듯한 피드백이라서 별로 좋지 않았다.
그 후 팀장멘토링에서 좋은 피드백을 받아 조금 누그러지긴 했으나 아직도 좋은 피드백은 아니었다고 생각이 계속해서 들어서 기분이 좋지않다.
정규표현식에서 문제가 생긴것 같다.
분명 .과 /는 정규표현식에서 허용하지 않는 문자인데 통과가 되서 정규표현식을 조금 알아봤다.
pw: Joi.string()
.required()
.min(8)
.max(16)
.pattern(/^(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{8,16}$/),https://regexr.com/689d6
이 사이트를 이용해서 regex를 테스트 해봤는데 regex 테스트에서는 허용이 되서 필수조건과 선택조건에 대해서 조금 알아봤다.
저 마지막 .{8,16}에서 .이 만약 앞에 필수조건을 다 채우면 .(모든것을 매칭가능하게 한다) 라고 받아들여져서 허용이 되는것 같아 수정을했다.
pw: Joi.string()
.required()
.min(8)
.max(16)
.pattern(/^(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-])[a-z0-9!@#$%^&*?-]{8,16}$/),바꾼코드
이 코드의 경우에 처음에는 ?- 부분을 -?로 고쳐서 -? 형태가 되어서 테스트 통과가 안되었었는데, 이부분을 다시 ?-로 고쳤다.
프로젝트에서 TDD로 개발을 하다보니 궁금한 점이 생겼다. 테스트코드를 먼저 짜고 그것에 맞춰서 비즈니스 로직을 구현하고 있는데, joi로 스키마 벨리데이션을 하다보니 joi도 유효성을 검사해야하나?에 대한 의문이 생겼다. 애시당초 양이 너무 많기도하고 노가다이다보니 이걸 해야되나 라는 느낌이 강하게 들었던 것 같다. 회원가입의 경우 들어와야되는 값이 strict하게 들어와야 되서 joi 또한 test코드를 해야 되는 것이 맞다고 생각이 들지만(실제로 테스트코드를 통해서 joi의 허점을 찾아냈다) 이 외의 데이터타입만 검증하는 코드에서는 굳이 해야되나 라는 생각이 들어 멘토님께 질문을 드렸다.
답변에서는 joi를 비즈니스 로직에서 완전히 분리하는게 좋다고 답변이 왔다. joi의 경우
답변을 받은 내용은
2021.10.27
오늘 커다란 문제가 생겼다. sequelize에서 정제하는 기능인 sequelize.fn을 쓰다보니 처음써보는 기능이다보니 조금 힘들었던 점이 많았다.
일단 sequelize.fn과 쿼리문을 쓰는것에 대해서 굉장히 많은 토론이 오갔는데, 일단은 sequelize로 간단한 crud는 모두 하기로 했고, 복잡하고 뎁스가 많이들어가는 부분은 프론트에게 정제없이 뎁스가 좀 얇게줄 수 있도록 쿼리를 쓸 것 같다.
현업기획자로 일하고있는 누나한테 피드백을 받았다.
피드백내용은 아래와 같다.
다른 회원가입/로그인 페이지를 참고
중복체크가 자동으로 되거나 회원가입 버튼을 눌렀을때 validation check를 해야지
오류메시지 각각 다 기획/디자인 필요
닉네임은 랜더마이즈해서 000개미 이렇게 자동생성
ex. 빨간머리개미
'궁금' 검색 결과를 찾아봤어요 (2123개)
객관식 상세페이지 -> 뷰에서 나타나게하고, 댓글 버튼 누르면 동일 페이지 유지하며 댓글 리스트만 샥 위로 올라와서 해당 카드를 덮게 보여지게 함
ox나 객관식이나 글 작성하는거는 상세페이지로 안하고 팝업으로 처리 (훨씬 간편한 UX)
+개미 이모티콘이 좋다고 랜덤하게 이동하거나 이스터에그처럼 넣어놓으면 좋을 것 같음
+가벼운 페이지인 만큼 재미요소를 많이 넣어두면 좋을 것 같음.
아무래도 가볍게 접근할 수 있는 사이트인 만큼 사이트 뎁스와 네이게이션에 초점을 맞춰서 본 것 같다. 그래서 프론트분들한테 조금 피드백이 많이 갔다. 이 중 내가 정말 필요하다고 생각한 부분은 객관식 상세페이지의 뎁스를 적게 만드는 것과 작성페이지 뎁스를 적게만드는 것은 정말 우리의 UX를 많이 좋게 만들어 줄 것 같다고 생각이 든다. 아무래도 새로 만드는 사이트이다보니 기존의 다른 사이트들에 비해 훨씬 유저 친화적으로 다가가야 장점이 있을거라는 생각이 들기 때문에 저런 UX적인 요소들이 재미적인 요소들 보다는 일단 먼저 눈에 들어오게 된다.
하지만 어제 프론트분들 중 한분의 이야기를 들어봤을때 이렇게 되면 컴포넌트를 갈아엎어야 될수도 있다는 이야기를 들어서 얼마나 받아들여질 지는 아직 모르겠지만 내 생각에는 그래도 할수 있다면 무조건 해야 된다고 생각이 든다.
2021.10.29
로그인 속도 문제
await 여러개
디자이너가 또다시 나갔다... 애초에 시간투자도 하루에 2~3시간 할 수 있다더니 시간도 별로 없고(애초에 사이드 프로젝트를 이거 제외하고 3개나 한다는데 시간이 있을리가..)기획도 별로 맘에 들지 않다고 하면서 말도없이 나가버렸다.
오늘 전체 팀 멘토링이 있었다. 피드백에 관련한 내용은 아래 사진으로 대체하겠다.
2021.10.30
nginx와 https 인증서를 받는 과정에서 좀 많이 어려운 부분이 있다. 일단 welcome to nginx가 떠야 되는 부분에서 안되고 curl localhost로는 그 html 파일이 보이는 문제점이 있었는데 이부분은 아마 포트포워딩이 되어 있어서 80번 포트를 보여주지않고 3000번으로 바로 보내줘서 안보이는것 같다.
ec2 서버 운영하시던 분의 서버가 갑자기 터져버려서 내 서버로 진행하고있다. 일단 aws에서 인증서도 받고 이제 nginx를 통해서 https서비스에 접근하려고 했는데 잘 되지 않고 있다. 계속 502 Bad Gateway라는 문구와 함께 오류가 나서 찾아보는 중이다.
2021.10.31
502 bad gateway를 해결하는 도중 로드밸런서가 요금을 청구할 수 있다는 말을 듣고 현재 무료로 사용가능한 lets encrypt를 사용하려고 한다.
분노가 느껴집니다...