PM과 BD, Backend 그 어느 사이

project1- 2일차(3): 회원가입 기능 layered pattern project 1 복사 붙여놓기 복사본은 깃 반영 안 됨 ls- al 해서 .git 떠도 반영 안 된다. ls-al 해서 나오는 건 git 삭제 remote 연결 안 될 것 단방향에 따라서, 각 파일의 앞단에서 export로 내보낸거를 require pm-developer-justdoit.tistory.com Layered pattern 📍개요 🗣 특별한 구조 없이 한 파일에 모든 코드를 구현: 코드의 양이 많지 않을 때는 간단, but 코드의 양이 조금만 많아져도 오히려 코드 유지 보수가 어려워진다. 실제 기업의 시스템에서는 논리적으로 혹은 기능적으로 영역을 구분하여 코드를 관리하는 것이 좋다. 코드가 구성되어지는 아키텍처를 학..

Project 1- 5일차: 통신 완료! 마지막날 통신 하기 전에 실수 1. datasource 를 잘못 정의 했다. 2. 회원가입을 하고 나서, 토큰이 안 돼서 알고보니, 해쉬 함수가 로그인 함수에만 들어가는게 아니라, 회원가입 함수에서부터 해야 한다. 위 pm-developer-justdoit.tistory.com 위 포스팅에는 과정과 통신 직전 실수한 코드 리뷰가 있어서 Foundation Test를 성공했을 때와 마찬가지로, Foundation Test 제출 1. 서버 연결 Welcome to Y's server! 2. 회원가입 postman 통신 결과 userCreated! 3. 회원가입 mysql 데이터베이스에 잘 들어갔는지 4.로그인 postman 통신 결과 Login Success! 토큰까..

임시저장해놓고 프로젝트 끝나고 숨돌리며 올리는. 개선사항 회의 시작한다는 것 알리기. --> 회의를 하는 중인지 모르셔서 멘토님께서 중간에 계속 끊음. 회의록 작성 , 서기 정해서, 회의 내용 정리 --> 나는 개인적으로 적고 있었으나, 공식적인 내용 정리 (오해 방지) 이 티켓을 완료하는 것을 예상하는게 어렵다. 대표님도. 그러나, 대략적으로 말해두고, “오늘까지 하겠다” . 그리고 나서 다음날 아침 standup meeting에서, 다시 수정하는. 회의록의 목적: 지금은 1주 sprint라 기억에 의존할 수 있는데, 개별 진행상황 공유 사항 내가 뭘 했고 막혔던 것 공유 예상시간 (추후 맞춰보는거 계획 위해) 기획적 수정 Action item (누가 뭘 하기로 했다. ) 중간에 방향이 다른 거로 진행..

Project 1- 5일차: 통신 완료! 마지막날 통신 하기 전에 실수 1. datasource 를 잘못 정의 했다. 2. 회원가입을 하고 나서, 토큰이 안 돼서 알고보니, 해쉬 함수가 로그인 함수에만 들어가는게 아니라, 회원가입 함수에서부터 해야 한다. 위 pm-developer-justdoit.tistory.com 프로젝트 끝나고 일단 통신 과정에 대한 정리를 했다. 정리한 내용은, - 통신 전 수정한 코드 - 통신 과정 기록 - 통신 후 깃허브에 push, pull request review, merge 기록 그리고, 나의 개인 깃허브 repository 에 push 작업까지. 일단 부트캠프 repository remote 에 연결돼 있기에, remote 는 한개만 연결 될 수 있어서, 끊어야 한다..

통신 결과 프론트엔드 사진 / 프론트, 백엔드 화면 녹화 영상 Project 1 - 백엔드와 프론트엔드 통신 결과 Project 1- 5일차: 통신 완료! 마지막날 통신 하기 전에 실수 1. datasource 를 잘못 정의 했다. 2. 회원가입을 하고 나서, 토큰이 안 돼서 알고보니, 해쉬 함수가 로그인 함수에만 들어가는게 아니라, 회 pm-developer-justdoit.tistory.com 통신 하기 전에 실수 1. datasource 를 잘못 정의 했다. 2. 회원가입을 하고 나서, 토큰이 안 돼서 알고보니, 해쉬 함수가 로그인 함수에만 들어가는게 아니라, 회원가입 함수에서부터 해야 한다. 위치는 데이터베이스에 저장되기 전에. 회원가입할 때에도 비밀번호 암호화 돼서 넣어야 함. 데이터베이스에 넣..

코드를 완벽히 하기 위해. 셀프로 코드리뷰를 해보았다. 그리고 실수로 누르는 바람에 덕분에 또 알게 된 사실 timeline별로 수정 사항을 비교분석 가능 1. portNumber를 정의하기 전에 require("dotenv").config()를 호출해야 환경 변수를 로드한 후에 포트 번호를 설정해야 chatgpt openAI의 도움을 받은 것 1-2. portNumber와 같은 환경 변수를 .env 파일에 저장하고 Node.js에서 사용 1 )require('dotenv').config()를 사용하여 .env 파일을 로드 2) .env 파일에 PORT 환경 변수를 추가 PORT=3000 PORT 변수에 3000이라는 값을 할당한 것 3) Node.js 애플리케이션의 코드(app.js)에서 .env 파일..

수요일부터 해결하고자 하였다. 나이트 멘토님과의 고군분투 심화과정 rebase까지 나왔다. 목요일에 경래 멘토님과 문제 정리 수요일 새로 생긴 오류를 해결하기 위해서는, 월요일의 이전 오류부터 다 고려 해야 한다! 나의 상황들을 다 정리해놓았다. Project 1 - 4일차 문제해결 내가 거의 깃허브 관리 담당이였다. 제대로 말하자면, 깃허브 branch에 분리해서 코드를 올리는 사람. 즉, 코드도 치고 올리는 사람. 팀원들이 코드를 주긴 하는데, 틀린 코드도 있고 실행하는 사 pm-developer-justdoit.tistory.com 그런데 말로는 쉬운데 혼자 하다보니, 그 구체적 과정이 어려웠다. 어디에다가, 어디에 가서 하는지. branch! 폴더! 나의 현재 위치! 금요일에 승윤 멘토님과 다시,..

통신 전, 코드 리뷰를 할 때에 활용해 보았다. 2탄. 아는 게 많아지니, 더 잘 활용하고 잘 물어보고 내가 원하는 정보를 얻을 수 있었다. 정말 상생이 가능한. 멘토님께 merge 후 수정하기 위해 branch 새로 생성해서 거기에 pull 받아서 수정 후 push하라고 했는데 실제 해보려고 하니 구체적으로 알고 싶어서 그런데 나의 상황은, 이미 내가 로컬에 수정한 뒤이기에 나의 상황을 알려주었다. 그렇다면 이렇게 하면 된단 말이지? 하고 branch main으로 checkout 하려는데 에러가 떠서 commit을 해야 한다고 하니, 그럼 기왕 commit 할 거면 수정을 다 하고 해야 하니, 내친 김에 내가 수정해야 할 사항 jwt token sigature 까지 물어봄 jwt token의 signa..

내가 거의 깃허브 관리 담당이였다. 제대로 말하자면, 깃허브 branch에 분리해서 코드를 올리는 사람. 즉, 코드도 치고 올리는 사람. 팀원들이 코드를 주긴 하는데, 틀린 코드도 있고 실행하는 사람은 나이고 pr 후 commit 을 하는 사람은 나이고, merge 후 복잡한 문제를 안고, branch copy /생성 후에 새로운 branch를 생성할 사람은 나 이기에, 문제를 꼼꼼히 보는 사람은 나였고, 결국 내가 처음부터 끝까지 하는 양상이였다. 코드를 치는게 어려운 게 아니라, 수정하고 commit하고 merge, merge 이후 수정 하는 것이 어려웠다. 늘 말하지만, 깃허브는 개발자의 편의를 위해 만들어지는 것이라고 들었는데.. 개발자라면 push pull push 반복작업을 100번씩 하는 거..

const { DataSource } = require('typeorm') const dotenv = require('dotenv') const jwt = require('jsonwebtoken') dotenv.config() // const myDataSource = new DataSource({ type : process.env.DB_TYPE, host : process.env.DB_HOST, port : process.env.DB_PORT, username : process.env.DB_USER, password : process.env.DB_PASSWORD, database : process.env.DB_NAME }) myDataSource.initialize() .then(() => { cons..