내가 보려고 만듬

현업에서는 이런 다이어그램들을 통해서 프론트와 소통해서 프로젝트를 진행하겠지만, 애초에 이런게 있었는지도 나중에 알았기 때문에 프로젝트는 끝났지만 오히려 지금이라도 한 번 구성해보고자 한다. 해보니까 백 마디 서로 오고가는 것보다 하나의 그림이 훨씬 간결하고 정확한 것 같다. 시퀀스 다이어그램에 대해 공부하는데, 시퀀스 다이어그램을 공부하는 것이 곧 전반적인 개발의 프로세스를 공부하는 것과 같아서 하길 잘했다는 생각이 들었다. 나중에 보면 정말 초라하겠지만, 기본적으로 시퀀스 다이어그램은 api별로 구성해야 하지만 만드는 이유 자체가 한눈에 프로세스를 살피기 위함이기 때문에 전체 프로세스부터 구성해보았다. 아직 미완성이긴 하지만, 노란색을 프론트, 초록색을 백으로 생각하고 만들었는데, 이건 내 마음대로 ..

두 정수 a, d와 길이가 n인 boolean 배열 included가 주어집니다. 첫째항이 a, 공차가 d인 등차수열에서 included[i]가 i + 1항을 의미할 때, 이 등차수열의 1항부터 n항까지 included가 true인 항들만 더한 값을 return 하는 solution 함수를 작성해 주세요. a d included result 3 4 [true, false, false, true, true] 37 7 1 [false, false, false, true, false, false, false] 10 function solution(a, d, included) { let answer = 0; let inc = [] for(let i = a; i

어떻게 해결했는지는 가장 아래에 적었습니다. 프로젝트를 하면서 mysql을 처음 접하게 되었는데, sql문에 익숙하지 않다보니 저런 형식의 오류를 정말 많이 접했다. 구글링도 하고, gpt도 쓰면서 대부분의 오류들은 솔루션이 있었던지라 포스팅을 생각해본 적이 없었는데, 아무래도 오류 메세지만 봐서는 db문제라고 생각했는데 전혀 다른 곳에서 오류를 해결하게 되어서 포스팅하게 되었다. 문제의 시작은 이렇다. 회원정보를 조회하는데, 프론트에서 불러오지 못한다고 듣게 되어서 오류메세지를 봤더니, 계속해서 접했던 메세지기도 했고, db에 맞닿는 부분이라 백엔드 오류임을 바로 알았다. 오류가 있었던 코드를 살펴보자. const [rows] = await db.execute('SELECT * FROM user WH..

https://github.com/expressjs/multer/blob/master/doc/README-ko.md GitHub - expressjs/multer: Node.js middleware for handling `multipart/form-data`. Node.js middleware for handling `multipart/form-data`. - GitHub - expressjs/multer: Node.js middleware for handling `multipart/form-data`. github.com 발단 게시글 api를 만들면서 이미지를 업로드 부분을 구현하면서 multer을 미들웨어로 사용했는데, multer는 이미지를 먼저 서버에서 지정한 디렉토리에 업로드한 후, 상황에 맞..

ㅁㅇㄹㄴ

토큰 보안 이슈 처음에 유저가 로그인 시 서버에서 accessToken과 refreshToken을 생성해서 aceessToken은 json 형식으로, refreshToken은 쿠키에 담아서 보내려고 했다. const refreshToken = jwt.sign({ userId: 'user123' }, 'refresh_token_secret'); const accessToken = jwt.sign({ userId: 'user123' }, 'access_token_secret'); // 리프레시 토큰을 쿠키에 담아 클라이언트로 전송 res.cookie('refreshToken', refreshToken ) // 엑세스 토큰을 JSON으로 응답 res.json({ accessToken }); → aceessTo..

ANIMAL_INS 테이블은 동물 보호소에 들어온 동물의 정보를 담은 테이블입니다. ANIMAL_INS 테이블 구조는 다음과 같으며, ANIMAL_ID, ANIMAL_TYPE, DATETIME, INTAKE_CONDITION, NAME, SEX_UPON_INTAKE는 각각 동물의 아이디, 생물 종, 보호 시작일, 보호 시작 시 상태, 이름, 성별 및 중성화 여부를 나타냅니다. NAME TYPE NULLABLE ANIMAL_ID VARCHAR(N) FALSE ANIMAL_TYPE VARCHAR(N) FALSE DATETIME DATETIME FALSE INTAKE_CONDITION VARCHAR(N) FALSE NAME VARCHAR(N) TRUE SEX_UPON_INTAKE VARCHAR(N) FALSE..

미리 포스팅을 저장해놨기에 지금은 사실 6월 29일이지만 그 때의 기억을 되살려서 그 과정들을 회고하려 한다. 포스팅보다 정말 밥먹는 시간만 빼고 나머지 모든 시간을 다 프로젝트에 쏟았다. 돌아보며.. 프로젝트 1주차때 1차적으로 이미 기본으로 구상해놓은 api는 다 구현했다. 그래서 이미 2주차때 1차적으로 코드리뷰 받은 내용들을 살펴보며 리팩토링 아닌 리팩토링을 진행하고 있었는데, 돌이켜보면 맨 처음 시작할 때 프론트와 더 자세하게 회의를 했어야 했다. 아쉬운 부분 1차프로젝트보다 빠르고 정교했던 것은 맞지만, 여전히 부족했던 점은 어떤 부분을 구현하고, db로 저장하고 보내주는 내용들이 설계된대로 진행되어야 하는데 물론 그렇게 진행했지만, 반대로 설계가 많이 부실했다. 그렇게 생각한 이유는 백엔드는..

이제 sql에 적응을 해가고, 기본적인 테스트도 끝났다. 코치님께서 토요일에 코드리뷰를 해주셨는데...ㅠㅠㅠ 너무 감동이다.. 진지하게 감동받긴 했는데 정말 고칠 점들이 너무 많다...ㅎㅎ 물론 새벽에 팀원과 기본 react 앱으로 배포까지는 잘 테스트했고, 백엔드 코드에 돌리는데는 문제는 없는데, 대체적으로 피드백해주신 부분을 살펴보면 db를 관리하는 부분에 있어서 현업으로 이어지는 부분인 것 같다. db 관련된 값은 카멜케이스가 아닌 스네이크케이스로 대부분 쓴다고 해서 고쳤다. 그리고 고유 id 값을 컬럼에 맞게 적용했는데, ex) comment_id, plan_id ... 이 부분을 id로 바꾸면 어떻겠냐고 피드백 주셨는데, diary에 comment가 연결되어 있어서 그 부분들까지 id로 바꾸게 ..

- API 명세서 작성 - ER Diagram - API 개발 이번주 동안은 크게 간추리면 이렇게 진행했다. 이제 내일 코치님께서 코드리뷰해주실 예정이고, 기능구현은 대부분 완성되었다. 사실 기능구현이라고 해도 여행일정을 기록, 공유하는 서비스에서 개발할 api는 회원가입 및 사용자 관련, 여행기 관련, 일정 관련, 댓글 관련 api 로 1차적으로 구성했다. 고도화되다보면 추가되겠지만, 일단은 회원가입 및 사용자, 여행기, 일정관련해서는 1차적으로 완료되긴 했다. req, res 다 잘 확인되고 있고, 다만 코치님께 피드백받기 전에 이미 알고 있는 아쉬움은 있다. 이제 관계형 데이터베이스를 접한지 일주일이다보니, 아직 구조가 머릿속에 바로 그려지지는 않는다. 여행기를 구현할 때, 테이블에 들어가는 컬럼들..