LEO Devlog LEO Devlog

4주 간의 코드스테이츠 파이널 프로젝트가 종료되었다. 프로젝트를 시작하며 SR 기획을 했던게 엊그제 같은데 시간이 참 빠르다. 팀장으로서 제대로 팀원들과 소통했는지, 올바른 방향으로 프로젝트를 이끌었는지 되돌아보게 되는 4주 간의 시간이었다. 처음 프로젝트 기획에서는 배달비를 더치페이하는 새로운 플랫폼을 만들자! 라는 아이디어로 나름 신박한 아이디어라고 다들 생각했고 프로젝트를 신나게 시작하게 되었는데, 진행하다보니 우리와 같은 서비스를 만든 팀이 전 기수, 전전 기수에도 있다는 것을 발견하고는... 역시 세상에 새로운 아이디어는 없는 것인가... 라는 살짝 힘빠지는 일도 있었다. 그래도 어쨌든 우리의 기획 방향은 정해졌고 우리 팀 더치킹은 그저 우리의 할 일을 묵묵히 해나가자는 마음으로 차곡차곡 로직을..

전체 4주의 기간 중 절반인 2주가 지났습니다. 프로젝트를 진행하느라 매일 정신없는 하루를 보내는 중이에요.. 나중에 이 기간 동안의 협업 내역과 감정을 잊고 싶지 않아서 주말동안 잠깐 짬을 내서 회고를 작성해봅니다. 잘하고 있는 점은 우선 각자 맡은 파트에 대해서 끊임없이 도전하고 노력해서 문제를 해결하려 한다는 점이 팀원들에게 고마웠고 매일 2번 꾸준히 미팅을 하며 서로의 진행 상황에 대해 공유하는 점이 느리지만 한 걸음씩 프로젝트를 완성하고 있다는 기분이 들어 건물을 쌓아 올리는 느낌이 들기 시작했습니다. 팀원의 건강 문제로 며칠간 진행이 안 되긴 했지만 그런 부분까지 감안해서 프로젝트 기간에 시간 분배를 잘 해야한다고 느꼈습니다. 그래서 저는 프로젝트가 시작한 2주 전부터 지금까지 평일에 꾸준히 ..

어제 저녁에 이어서 프로젝트에 관한 기획과 범위 설정을 진행하고, 위키 및 To-do 리스트에 관한 Requirements를 작성했어요. SR 기획에 관해서 여러 자료들을 찾고, 팀 규칙을 설정을 했습니다. 아침에 일어나는 것은 모두에게 힘들지만 그래도 팀이라는 체제가 이어지려면 9 to 6가 제일 올바른 방향이지 않을까 싶어서 그대로 스케줄을 유지했어요. 그리고 위키를 작성하고 to-do list를 작성하고 최종적으로 Requirements를 작성했고 추후에 수정될 수도 있다는 점 참고! Requirements 🟢 Bare Minimum 반응형 웹 모바일 환경 대응 유저 JWT를 이용한 회원가입, 로그인, 로그아웃, 회원탈퇴 마이페이지에서 개인정보 변경(프로필 사진, 닉네임, 회원탈퇴) 유효성 검사 관..

오늘 한 일 팀 선정을 하고 팀원분들을 만났는데 ㅌㅇ님과 ㅅㅎ님은 first project를 함께 해서 정말 반가웠고 ㅈㅇ님도 예전에 페어 프로그래밍을 같이 했던 적이 있어서 오랜만이었고 좋았습니다. 바로 인사를 하고 팀장을 정해야 했는데 아무도 나서지 않는 상황이 참 어색해서 내가 자원을 해서(..?) 팀장을 맡게 되었어요.. 이번 프로젝트의 이름은 BaedalDutch(배달더치)입니다! 이름만 들어도 어떤 서비스인지 감이 오지 않으세요ㅎㅎ 몇 달 전에 제 형이 요새 아파트 단톡방에서 치킨이나 다른 배달 음식들을 여러 사람끼리 같이 시켜서 배달비를 절약한다는 얘기를 하더라고요. 아마 주변에서 들어서 알고 있는 분들도 계실 거예요. 그래서 이게 비단 아파트 단톡방에서 그치지 않고 나와 내 주변 지인들도 ..

코드스테이츠에서 섹션3까지 마치고 드디어 프로젝트에 들어가게 되었고 2주간의 시간 동안 프로젝트를 마무리지었습니다. 깃헙의 회고 일지와 비슷하게 Keep(유지할 항목), Problem(문제라고 생각한 항목), Try(Action items)로 나눠서 진행해볼게요. Keep(유지할 항목) 1. 모르는 부분이 있을 때 바로 팀원들에게 물어보거나 포기하기보다는 구글링을 통해 테스트를 해보고 적절한 방법을 적용해 에러 해결하기 2. 혼자 문제를 해결하는 것도 좋지만 협업을 통해 같이 풀어나가면 내 장점과 팀원의 장점을 합해 개발 속도에 좋은 영향을 미친다. Problem(문제라고 생각한 항목) 1. 커뮤니케이션이 적다면 작업의 효율성이 떨어지고 나와 팀원 모두가 서로의 진척도에 대해 알지 못하기 때문에 "분업"..

사용하고자 하는 백엔드 폴더에(e.g. /server) sequelize를 설치했다는 가정 하에 진행한다. 초기화 작업 sequelize init 초기화를 진행하면 아래와 같은 폴더와 파일들이 생성된다. . |-- README.md |-- config | `-- config.json |-- migrations |-- models | `-- index.js |-- package.json |-- seeders `-- yarn.lock config : 데이터베이스 설정 파일, 사용자 이름, DB 이름, 비밀번호 등의 정보 migrations : git과 비슷하게, 데이터베이스 변화하는 과정들을 추적해나가는 정보로, 실제 데이터베이스에 반영할 수도 있고 변화를 취소할 수도 있다. models : 데이터베이스 각..

공부를 하고 스프린트를 진행하며 데이터베이스가 어떻게 흘러가는가에 대해 잘 알고 있다고 생각했는데 막연하게 알고 있어서 자세한 흐름을 파악하지 못하고 있다는 것을 깨달았다. 그래서 정리를 해볼까 한다. 팀원들간의 협업 시 데이터베이스를 세팅하고 사용하는 방법 (MYSQL) !!! 다른 팀원이 먼저 만들어둔 데이터베이스를 pull 받아오는 상황이다. 1. config.js 파일에서 env로 설정해야 하는 정보들을 확인 후 최상위 디렉토리에 .env 파일을 만들고(e.g. server/.env) 내용을 작성한다. 2. $ mysql -u root -p 로 mysql에 접속한다. 3. $ CREATE DATABASE ; (프로젝트에서 사용하는 데이터베이스 이름) 4. $ SHOW DATABASES; 로 데이터..

Git Workflow 모식도 1. 먼저 구조 이해하기 UpStream : 처음 fork 해오는 저장소 Origin : 다른 사람의 저장소를 fork 했을 때(UpStream을 fork했을 때)의 내 저장소. 즉 UpStream과 Origin은 상대적으로 결정되는 개념이며, 모두 원격(remote) 저장소다. Master : 배포 후 실제 사용을 위한 branch Dev : 개발을 위한 branch 2. 명령어 순서대로 정리하기 1) $ git clone 'UpStream의 저장소 주소' 먼저 팀장이 UpStream의 저장소를 본인의 local로 fork하지 않고 clone해온다. *fork는 단순 github상에서 구현되는 것으로, 내 github 계정에 원본 저장소를 그대로 복사해오는 것이다. 복사해..