study 프로젝트 첫 회의!회원가입, 로그인 / 메인 페이지 / 스터디 정보 디테일 / 스터디 리스트 / 스터디 추가 및 수정첫 설계 시 user 관련 기능과 필수 기능의 생성 / 수정 / 삭제부터 정한 뒤 그 외 추가 기능은 나중에 추가하도록 한다.추가 정보 입력을
이번 프로젝트에서 상태 관리 시 redux와 context Api 중 어떤 것을 써야 할지 고민을 하다가 둘의 차이점에 대해서 알아보았다.비동기 작업을 더욱 체계적으로 관리 가능하다.context에 관한 여러 가지 설정과 hooks를 직접 만들지 않아도 된다.conne
페이지 주소에 유동적인 값을 전달할 경우 파라미터와 쿼리로 나눠질수 있다.파라미터: /profiles/velopert (정해진 특정 데이터를 조회할 때)쿼리: /about?details=true (다양한 옵션을 줘서 조회할 때)match값을 받아와서 사용
학원에서 프로젝트를 할 때에는 빌드한 파일들을 github에 올리면 백엔드 개발자가 파일을 가져다가 배포하는 방식으로 배포가 진행되었다. 작은 프로젝트라면 이렇게 해도 되지만 이번에는 좀 더 규모있는 프로젝트를 진행하기 때문에 프론트엔드와 백엔드를 각각 빌드하는 방식으
지난 포스팅에 이어 이번에는 CloudFront 서비스를 이요하는 방법에 대해 알아보겠습니다.콘솔에 로그인 클릭 후 CloudFront를 검색하여 페이지에 들어갑니다. Create Distribution 버튼을 클릭합니다.우리는 Web이기 때문에 Web에서 Get St
메인페이지에 들어갈 컨텐츠개설할 때 어떤 데이터를 받을 지서비스 이름작업 방식로그인 페이지는 slack으로 연동 버튼 한 개만 존재할 텐데 의미가 있을까? 하는 의문이 든다. 또한 페이지 이동은 사용자의 경험이 끊길 수 있기 때문에 간단한 페이지는 모달로 띄우는 게 더
아젠다슬랙 연동할 때 반드시 워크 스페이스가 먼저 생성되어야 한다는 문제를 해결해보자!토론했던 내용들회원 가입소셜 로그인 없이 이메일 회원가입 - 추후에 슬랙 초대 메일을 보낼 주소와 동일함.스터디 개설 프로세스🚀 스터디 개설할 때 슬랙 연동 시나리오 서버에서 필요한
기존에 있던 이슈들의 스프린트 중간에 스토리 포인트가 변경되며 이슈의 범위가 과하게 높아졌음. (미완료된 이슈를 보면 스토리포인트가 13 → 19로 늘어남. 이는 에스티메이션을 제대로 하지 못했다는 의미.)진행중(파란색)의 범위가 점점 넓어지고 있으며, 그럼에도 불구하
|아쉬웠던 것| 좋았던 것| |:----------:|:----------:| |- 팀원들이 어떤 작업을 언제 시작할 지 모르는 것이 불편했다.| 좋았던 것|
앞선 두 스프린트에 비해 퍼포먼스가 반 이하로 떨어짐 (해낸 스토리포인트: 16 → 5)이에 대한 원인 파악과 액션 아이템 마련이 시급함이전 스프린트들은 처음에 이슈를 스프린트에 등록한 후 스토리포인트 변경 등을 통해, 처음 등록한 이슈보다 많은 양을 처리했지만, 이번
스프린트 내에 있는 이슈를 처리한 맥락만 보면 스프린트 3에 비해서는 괜찮은 퍼포먼스를 냈다. 👍중간에 스토리포인트의 변경도 없었음 (중간에 그래프가 위로 튄 건 서브태스크들의 스토리포인트를 부모 이슈에 합산하면서 발생한 것) 👍그러나 스프린트3에서 못 끝낸 미완료
7-11일 까지 어떤 이슈도 해결하지 못했다. > sol) 하루에 조금이라도 시간을 투자하는 습관을 들여야할 듯 (조금씩 처리하여 자주 공유하기)이슈를 세부적으로 쪼개기, 이슈와 백로그 잘 구분하기 (자신이 대략 몇정도 해결할 수 있는지 명확하게 파악해야 함)수정사항이
스프린트 분석드디어 100% 달성!스프린트6은 제출과 완료가 동일! (제출이 조금 더 높은 건 중간에 삭제된 이슈 때문이다)api 문서 자동화를 하고싶다일정 공유가 미리 되었으면 좋겠다 (예상치못한 스케줄 변동)처음으로 100% 달성했다는것매일 조금씩 시간을 투자해서