2021.10.18
클론코딩 주차가 시작됐다. 어느정도 이제는 사람들을 두루두루 알다보니 잘하시는분들과 클론코딩을 하게 되었다는 소리를 듣고 기분이 좋았다.
팀장은 어째서인지 모르겠지만 내가 맡았는데(부담..) 그래도 다들 잘 의견내주시고 하셔서 좋았다.
우리조는 처음에 당근마켓, 넷플릭스 등을 선택을 했었는데 당근마켓은 앱에서만 제대로된 기능을 한다는 것, 넷플릭스는 결제를 한 사람만 들어가서 뷰를 볼 수 있다는 점에서 걸려서 다른걸 알아보다가 좀 하드코어 하지만 핀터레스트로 결정했다.
보기만 해도 어려워보인다
기능을 모두 다 5일만에 구현한다는 것은 불가능하다는 것을 알기에 조금 시간이 오래걸리는 어려운 작업들은 일단은 추가기능으로 넣었고, 기본적인 crud(이것만 해도 5일이 빠듯 할 것 같다)를 mvp로 삼았다.
https://hanghae99clone9.notion.site/9-de04875486c24c6383d239aaab35ba70
위의 문서를 멘토님이 체크를 했을때 
이런 피드백이 왔다.
이미지 crud가 생각보다 어려운 것 같아 1차 서버배포를 핀 등록, 로그인 기능 구현이 되면 하기로 했다.
validation은 1주차때 프론트에서만 validation을 한 것을 보고 back에서는 안하냐고 하셔서 일단 프론트도 하고 백도 하는 대신 백에서는 joi로 기본적인 정규표현식, 길이 등을 체크하고 아이디를 포함하는지에 대한 validation에 대해서는 따로 함수를 만들어서 하기로 했다.
code convension은 프리티어를 통일해서 정했고, 깃 또한 commit convension을 정해놨다. review 규칙은 아직 정하지는 않았지만 중간점검, 최종점검으로 리뷰를 한번씩 할 예정이고 정확하게 날짜까지는 정하진 않았지만 하겠다고 말씀드렸다.
2021-10-19
일단 내가 맡은 부분까지는 api통신 준비를 완료했다. 포스트맨으로 통신이 잘 되는 것 도 확인했고, 에러가 없는것도 확인했다. 어제 저녁부터 최종프로젝트 조를 정하는데 좀 많이 스트레스를 받아서 코딩이 눈에 잘 안들어오는 것 같다. 백엔드 서버는 미리 배포해서 프론트분들 통신 할 수 있도록 해놨다.
최종프로젝트가 자율선택이라는 말에 꽤 자신감을 가지고있었는데 자신감이 아닌 자만심이었던 것 같다. 우리조를 픽해주는 프론트는 아무도 없었고 다들 거절의 연속이었다. 솔직히 아직도 이유를 모르겠다. 나름 프론트, 백엔드에서 성장속도도 빠르시고 협업도 잘하시는분들이 모였다고 생각이 들었는데 이렇게 안모일줄 몰랐다. 프론트분들 요구하시는걸 다 공부해서 구현해낼수 있을거 같은데 프론트 3분이 모이질 않으면 5명이여도 조가 폭파될 수 있다는 생각에 좀 정신적으로 힘든것 같다.
2021-10-20
통신작업을 대부분 해결했다. 로그인, 댓글,좋아요, 메인 뷰 등 거의 대부분을 했는데 문제가 되는 부분은 핀을 등록할 때 폼데이터를 받아오는부분에서 문제가 생겼다.
일단 첫 문제는
이 문제였는데, 이부분은 프론트에서 폼데이터에 content-type을 application/json으로 해서 보냈기 때문에 일어난 문제였다. 찾아보니 multipart/form-data 로 지정해서 보내야 한다고 해서 그렇게 수정했더니 이번에는 
위와 같은 문제가 생겼다. 이부분은 boundary를 지정해주지 않아서 생긴 문제인데 보통은 크롬에서 지정해주는데 이번에는 따로 지정해 줘야 되는것 같았다. 그래서 content-type도 크롬에게 맡기는 길을 선택했더니 객체는 들어오지만 내용물이 들어오지 않는 일이 발생했다..
현재 postman을 사용한 핀 등록하기 기능은 되지만 클라이언트와의 통신에서는 읽어오지 못해 이부분에서 문제가 뭔지 찾아보고 있다. 내생각에는 form데이터를 주는 과정에서 어떤 문제가 발생해서 제대로 담기지 않고 오는것 같다는 생각이 든다.
멘토링을 했을때 일단 칭찬부터 받았다. 속도도 굉장히 빠르고 디테일도 잘 잡았다고 했다. 아직 스코프에서 못한 것들과 추가기능을 말씀 드렸더니 우선순위를 pin등록과 검색기능을 1순위로 말씀하셨고, 마이페이지와 찜기능을 2순위로 말씀하셨지만 아마 마이페이지는 현재 구현하고 있는 도중이라서 검색기능보다 먼저 완성이 되지 않을까 싶다.
formData 관련해서는 리액트에서는 react-hook-form이라는 라이브러리를 사용하는 것을 추천했고 백엔드에서는 리퀘스트 자체를 console.log로 찍어보면서 뭐가 내려오고 내려오지 않는지를 말해주는 것이 좋다고 하였다.
request를 찍어봤을때 일단 body로 빈 객체가 내려오고, content-type도 application/json으로 나오는것으로 확인했다. 그래서 multipar/form-data를 수동으로 지정해주고 했더니 다시 boundary에러가 떳고, 이 에러에 대해서 수정하다 보니 boundary=----WebKitFormBoundaryyrV7KO0BoCBuDbTL라고 설정하면 된다는 글을 봤다.
그리고나서 확인해 봤더니
이렇게 body에 뭔가가 담아서 오기 시작했고,
객체로 둘러싸여져있는것을 확인하고 프론트분께서 formdata를 {formdata}로 보내던걸 풀고 formdata 자체로 보내줬더니 제대로 파일 전송이 되고 실행이 되었다.
그리고 오늘 아침에 S3에 객체를 저장할때 객체의 content type을 안정해주었더니 다운로드가 되는 기능이 있어서 불필요한 부분이라서 content-type을 지정해주고 있었는데, 프론트에서 다운로드 기능을 넣는다고 하여 지정하던 부분을 없애고 서버를 다시 실행시켰고 다행히 다운로드도 잘 되고있다.
2021-10-21
오늘은 조금 집중이 되지 않는 날이다....
그래서 그냥 프로그래머스에서 알고리즘을 풀고 거의 공부를 안한것 같다..
문제 설명
배열 array의 i번째 숫자부터 j번째 숫자까지 자르고 정렬했을 때, k번째에 있는 수를 구하려 합니다.
예를 들어 array가 [1, 5, 2, 6, 3, 7, 4], i = 2, j = 5, k = 3이라면
array의 2번째부터 5번째까지 자르면 [5, 2, 6, 3]입니다.
1에서 나온 배열을 정렬하면 [2, 3, 5, 6]입니다.
2에서 나온 배열의 3번째 숫자는 5입니다.
배열 array, [i, j, k]를 원소로 가진 2차원 배열 commands가 매개변수로 주어질 때, commands의 모든 원소에 대해 앞서 설명한 연산을 적용했을 때 나온 결과를 배열에 담아 return 하도록 solution 함수를 작성해주세요.
제한사항
array의 길이는 1 이상 100 이하입니다.
array의 각 원소는 1 이상 100 이하입니다.
commands의 길이는 1 이상 50 이하입니다.
commands의 각 원소는 길이가 3입니다.
입출력 예
array commands return
[1, 5, 2, 6, 3, 7, 4][2, 5, 3], [4, 4, 1], [1, 7, 3]] [5, 6, 3]
입출력 예 설명
[1, 5, 2, 6, 3, 7, 4]를 2번째부터 5번째까지 자른 후 정렬합니다. [2, 3, 5, 6]의 세 번째 숫자는 5입니다.
[1, 5, 2, 6, 3, 7, 4]를 4번째부터 4번째까지 자른 후 정렬합니다. [6]의 첫 번째 숫자는 6입니다.
[1, 5, 2, 6, 3, 7, 4]를 1번째부터 7번째까지 자릅니다. [1, 2, 3, 4, 5, 6, 7]의 세 번째 숫자는 3입니다.
이번에 알고리즘 스터디에서 처음으로 정답을 보지않고 풀었던 것 같다.
const array = [1, 5, 2, 6, 3, 7, 4];
const commands = [
[2, 5, 3],
[4, 4, 1],
[1, 7, 3],
];
function solution(array, commands) {
var answer = [];
for (let i = 0; i < commands.length; i++) {
const sliceArr = array.slice(commands[i][0] - 1, commands[i][1]);
// console.log(sliceArr);
const sortedArr = sliceArr.sort((a, b) => a - b);
// console.log(sortedArr);
answer.push(sortedArr[commands[i][2] - 1]);
}
return answer;
}
console.log(solution(array, commands));위와 같이 풀었는데, 문제에 나온순서대로 작성했더니 다행히 됐었다. 처음에 sort안에 콜백을 넣지않고 그냥 sort를 했을때 테스트 케이스 하나가 걸려서 되지 않아서 아참! 하면서 (a,b)=>a-b를 넣어줬다. 넣지 않았을 경우 특수케이스에서는 크기순 정렬이 되지 않아서 그렇다.
프론트 서버가 배포되고나서
해당 사진은 인터넷에서 퍼온사진.. 우리 사이트 에러사진은 해결이 되어서 캡처를 하지 못했다.
위와 같은 에러가 떴는데, 처음에는 백엔드에서 S3 권한설정을 잘못 한 줄 알고 버킷정책이나 이것저것 건들여보곤 했다.
이것저것 건들여보고도 안되었을때 마침 리액트 멘토님들이 들어와계셔서 잠깐 물어봤떠니 프론트에서 index.html을 호스팅에서 라우팅해주지 않아 생긴 문제인 것 같다고 하여 생각난 블로그가
https://algoisanswer.tistory.com/11 이 사이트인데 이사이트에서 인덱스 문서와 오류 문서를 라우팅해주는 것을 해주면 404에러가 해결된다라는 글을 봤던 것을 깨닫고 프론트 서버를 담당하고 계신분한테 저걸 말했고
위와같이 설정해주셨더니 해결이 되었다.
기본적인 인덱스 문서 라우팅과 오류문서 라우팅을 해주지 않아 생긴 문제였지만 왜 처음부터 404가 뜨지않고 새로고침을 했을때 뜨는지는 아직은 잘 모르겠다.
2021.10.22
프론트분들이 디테일한 수정작업을 하고 있고 나는 그 수정작업에 맞춰서 통신작업을 하고있던 중에 갑자기 서버가 죽어버리는 현상이 일어났다.
갑자기 10분정도동안 미친듯이 cpu사용량이 올라가는것이 확인되었는데 로그가 지워져서 어떤 요청때문에 죽어버린지는 아직 명확하지 않다.. 일단은 해결을 위해서 서버를 재부팅 했고, 서버 재부팅 시 기존에 해놨던 포트포워딩이 날라간다는 사실을 새로 알았다.
완성!
12시 기한이었는데 오히려 영상찍고 gif만드는데 시간이 너무 소요돼서 기간내에 못하는줄 알았다. 다행히 거의 끝날때 쯤에 유튜브 인코딩이 다 되서 기간내에 제출했다.
2021.10.24
어제는 이것저것 한다고 까먹어서 못썻다.
오늘 디자이너분들이 와이어프레임을 대략적으로 짜오셔서 거기서 스코프에대해서 이야기 나누고 프론트분들께서 워낙 넓은 스코프라서 컴포넌트를 재활용할 게 없어서 스코프가 조금 넓다고 했다. 그래서 줄일 수 있는 걸 최대한 줄여보고 추가기능으로 한다고 했다.
생각보다 조율 할 때 의견이 다른 경우가 많아서 토론할 경우가 많이 생겼고, 토론한 내용을 바탕으로 결과를 도출했다. 서로 의견을 먼저 제시하고 이유를 말하면서 자신의 의견에 대한 근거를 제시했다.
실전프로젝트 이름은 아무래도 경제쪽으로 가벼운 느낌의 문답 커뮤니티여서 B급 감성으로 갔는데, 개(미들의)곡소리로 했다. '미들의'는 약간 조그맣게 표현해서 개곡소리라고 했다. 좋은사람들과 열심히 하는사람들을 만나서 오늘 와이어프레임 다 짜고 api문서도 다 짜고 db도 조금 짜고 잘 것 같다.
