Grace's Tech Blog

1) 이슈카드는 큰 덩어리로 분류하고, 각 덩어리 안에서는 기능 flow를 고려하여서 세분화 및 순서 부여를 시키는게 좋다. 저번주만 하더라도 Client 쪽 issue card는 컴포넌트(솔직히 말하면 우린 SPA인데도 불구하고 페이지 기준)만을 기준으로 되어있었다. 그런데 리다이렉트가 빈번한 서비스이다보니 컴포넌트 간 구현 순서 역시 중요했다. 그래서 해당하는 것들을 더욱 세분화 하여서 순서대로 issue카드를 수정하게 되었다. 그래서, 이렇게 하나로 퉁쳤던 issue 카드(login 기능 구현 으로 퉁쳤던 걸 ) -----------------------------------→ 이렇게 세분화! 2) API 문서 작성을 할 때는 팀내 논의를 확실학게 한 후 정말정말정말 꼼꼼하게 작성 해야한다. 아래 ..

우리 서비스(SAFU)는 '깃헙으로 로그인하기(간편 로그인 기능)'을 제공한다. HJ님과 나를 아주 맘고생시켰던 깃헙 소셜로그인..ㅎㅎ 특히 client가 사용하는 주소(port:3000)와 server가 사용하는 주소(port:4000)이 달라서 리다이렉트 로직이 너무 헷갈려서 힘들었다. 예전에 OAuth2와 소셜로그인에 대해서 블로그에 정리한 적이 있었지만 백지상태에서 처음부터 구현하려고 하니 결국 내가 아무것도 모르고 있는 상태였구나를 깨달았다. 그 포스팅과 이번에 구현해본 코드를 통해 여기에 내가 이해한 바를 다시 한번 자세히 정리해보기로 했다. 1. OAuth2의 이해 libertegrace.tistory.com/entry/40-Authentication-OAuth-20 40. Authentic..

점점 SAFU 웹페이지가 예뻐지고 있다! SH님께서 CSS를 전적으로 담당해주셔서 시간이 갈 수록 점점 예뻐지고 있다. 회원가입, 로그인, 로그아웃, 아이디 비번 찾기, 리뷰 카드 랜더링, 로그인 전/후 메인 페이지 까지 구현이 완료 되었다. 로그인 후 Mypage 버튼을 누르면 이 페이지로 이동하며 Mypage는 컴포넌트는 회원 정보 출력과 컴포넌트로 구성되어 있다. 들어가자마자 자신의 회원 정보와 자신이 작성한 리뷰카드들이 보여야 하며 컴포넌트의 '회원정보수정' 버튼을 누르면 비밀번호와 githubID를 수정할 수 있는 /Editinfo 페이지로 넘어간다. 그리고 컴포넌트의 각 카드인 컴포넌트에서 바로 리뷰 수정을 할 수도 있다. 여기서 Oct 26, 2020 ~ Oct 30, 2020 동안 구현한 ..

Oct 24, 2020에 Main 페이지(이 때도 아직까지 page와 컴포넌트의 경계를 헷갈리고 있었다.)에서 Login컴포넌트, Mypage컴포넌트, Signup컴포넌트 가 아래에 누적되어 나타난다는 피드백을 받았다. 문제는 각각으로 라우팅을 해주지 않고, 그냥 바로 Main 컴포넌트 내에 Login컴포넌트, Mypage컴포넌트, Signup컴포넌트를 직접 작성해주었기 때문이었다. 그래서 Oct 24, 2020에 대대적인(ㅋㅋ) 라우팅 작업을 진행해주었다. github.com/codestates/SAFU-client/pull/51 그런데 큰 그림을 보지 않고 한 탓인지 계속해서 라우팅 시마다 고려해줘야 할 것들이 생겨났고, 라우팅이 정리가 되지 않고 복잡하다보니 리다이렉트 시에도 꼬이는 문제가 발생했다..

벌써 Bare Minimum을 마무리 하기로 한 31일이 일주일도 채 남지 않았다. 제목은 통일성있게 맞추려하다보니 이라고 지었지만 저것만 한 것은 아니다. Client와 Server의 통신이 바로바로 확인 되고 두 파트 모두 마무리가 되는 것을 확인해봐야 다음 기능 구현으로 넘어가기에도 수월하다는 것을 프로젝트 초반부터 깨달았고, 그러다보니 양 쪽 파트의 PR사항을 그날그날 코드 리뷰하느라 여기에도 코드 작업하는 시간 만큼 쓰이는 것 같다. 양 쪽 파트를 모두 코드리뷰하는 것은 정말 좋다. Client 파트를 맡아서 Server구현을 프로젝트가 진행되는 한 달간 못(?) 하게 되어 잊어버리면 어떡하지? 라는 걱정이 있었는데 코드리뷰를 통해 이 걱정은 할 필요가 없게 되었다. 또 블로그를 통해 각 기능에..

10/17~10/20까지 Signup 컴포넌트 구현과 Server API를 코드리뷰 하면서 일단 1차로 마무리를 시켰다. 여기서 회원가입이 완료되면 Login 컴포넌트로 Redirect가 되어야하는데 아직 Login 컴포넌트가 완성이 되지 않아서 이를 새로운 이슈카드로 빼놓고 일단 PR & upstream-client로 merge 까지 해 놓은 상태였다. 10/21~ 부터 Login/Logout 컴포넌트 기능 구현 작업에 들어갔다. 의 해야 할 것은 login 컴포넌트 틀 잡기 일반 로그인 구현 log in 버튼 누르면 -> redirect -> (logged) main 페이지 회원이 아니신가요? Sign up 버튼 누르면 -> redirect -> Sign up 페이지 findId 버튼 누르면 -> r..

처음 맡게 된 기능 구현 이슈카드는 였다. 해야할 것은 회원가입 컴포넌트 틀 구성 아이디, 이메일 유효성 검사 제출하기 버튼 -> redirect -> login 페이지 1. 회원가입 컴포넌트 틀 구성 - (Oct 17~18, 2020) 회고 회원가입 컴포넌트 틀을 짜는 것은 거의 HTML 같으니까 뭐... 라고 생각했지만 와 그리고 만 쓰고 있는 나 자신을 발견했다. 시멘틱 마크업이 뭐길래? 아무튼 배우고 싶고 배워야 할 건 너어무 많다. - 라는 강의가 있는데, 수강하고 싶다. 더보기 youtu.be/jOzR83vixsE 아무튼 예전에 HTML 태그 복습 해놓은게 있어서 그나마 다행이었다. 2. 아이디, 이메일 유효성 검사 - (Oct 18~19, 2020) 회고 아이디는 2개, 비밀번호는 1개의 유..

이번 Project에서 새롭게 배운 개념 - Upstream Upstream의 Master Branch: 제품으로 출시될 수 있는 branch. Upstream의 Dev Branch: 개발 작업이 진행되는 branch 배포(Release) 이력을 관리하기 위해 사용. 즉, 배포 가능한 상태만을 관리한다. 💡배포는 언제 하는게 적절한가? ⇒ 서버에서 Hello world 찍자마자 배포해야한다. 왜? 예상치 못한 상황이 많기 때문이다. 너무 많이 진행 된 후에 그걸 확인하고, 문제를 찾을려고 하면 너무 막막하다. (ex. '아 제 컴퓨터에서는 되는데...') 그래서 이때 처음 배포하고, 주기적으로 배포, 검사 해주지 않으면 문제를 겉잡을 수 없다. Project Git Workflow 1. upstream ..

보호되어 있는 글입니다.