1주차 회의록
- 참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
- 시간
- 오전 10:00 ~ 오전 12:00 / 오후 02:30 ~ 오후 07:00
- 그라운드 룰 / 팀 목표 정하기
- 각자 프로젝트를 임하는 목표를 정했습니다.🙆♂️
- git, pr, issue convention을 정했습니다.
- git 전략을 정하는데 애를 먹었습니다... merge방식, main/dev/feat브랜치를 효율적으로 사용하는 법을 찾고 있습니다.
- 아이디어 브레인 스토밍 진행
- 각자 아이디어를 생각하고 그에 대한 의견을 나누었습니다.
- 기본 개발 규칙 정하기
- 파일/변수 이름 짓는 방식, 코드 작성 규칙(eslint, prettier)를 정했습니다.(수정 가능!)
- API 명세서 만들기
- Swagger 서비스를 이용해서 만들기로 정했습니다.
-
참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
- 성지현 멘토님
-
시간
- 오전 10:00 ~ 오후 12:00 / 오후 01:30 ~ 오후 07:00
-
안건
- 브랜치 전략, 주제 정하기, 기능 토의, 기능 명세서 구조
- 10/26(화) 멘토링
-
주제 정하기
- 아이디어 피칭 이후 부스트캠프 교육 내용을 얼마나 반영하는지, 프론트엔드와 백엔드를 모두 적정한 수준으로 포함하는지, 어느정도부터(e.g. 맨바닥에서부터) 시작해야 하는지 등을 고려하여 구루미 클론 VS 내 지역 후기로 의견을 좁혔습니다.
- 이후에 리뷰어님과의 이야기를 통해서 내 지역 후기를 선택하였고, 위치 정보를 효과적으로 처리하기 위한 기술을 찾아보기로 했습니다.
-
멘토님 미팅 회의록
- 동네 거주 후기 -> 위, 경도 최적화 db가 있으니 찾아보자, 지도 api, 위치 기반 데이터 헨들링(퍼포먼스), 위치를 어떻게 가져올것이냐, 데이터가 많이 쌓여있을 때 성능을 향상시킬 수 있는 단계적인 방법
- 지라 VS 깃허브 -> 깃허브를 주로 쓰는게 좋은것같다. 지라는 wiki를 많이 사용한다.
- 리뷰 -> 피처가 완성되면 한번씩 진행하는게 좋을것 같다.
- 경쟁력 -> 기본은 코딩테스트(많이 갈림), 면바면(cs우선? / 프로젝트(경험)우선? /)하지만, 제일 중요한건 깊은 기술적 고민 -> 기술적 고민이 제일 중요하다!
-
git branch 전략
- 1,2,3 전략 중 첫번째 전략으로 현업에서 멘토님꼐서 하고 계심
-
주제 관련 주요 기능
- 지역에 대한 전반적인 평점을 매겨보자
- 지도 축척 변경에 따라 시 - 군 - 구 레벨로 지도에서 색상 기반 구분 및 마커 표시(평점, 워드 클라우드 내용)
- 지도 위의 마커를 클릭하면 해당 후기들과 그 지역에 대한 사용자들의 반응 통계(텍스트, 평점 등)가 나옴
-
넣고싶은 기능 브레인스토밍
- 후기의 카테고리를 나누자
- 맛집, 여행, 카페, 공원 등
- 동네 랭킹
- 포함 관계를 생각하여 평점을 합산 -> 평점을 매기는 방식은? 가중치는?
- 랭킹 기준은 텍스트+평점
- 랭킹 카테고리가 있어서 맛집, 여행, 카페, 공원 등 적용
- 몇 명, 연령대 인구 공공 API
- 지역의 정보 표시
- 평점을 매기는 방식
- 시, 구, 동 단위로 세 번 매기는 것?
- 평점을 합산하는 방식?
- 치안점수, 교통점수, 문화점수, 공원점수, 교육점수 등으로 세분화해서 점수 매기는 방식이 재미있을 것 같다
- 소모임 채팅
- 동네는 내 위치 인증(중고나라처럼)
- 관심 리스트
- 장소 선정
- 후기를 내 관심 리스트 CRUD
- 번개 이벤트
- 내 근처 사람들에게 푸시알림 보내기
- 사용자 랭킹제
- 후기 많이 올리면 일반자 -> 백작 -> 공작 -> 왕 -> 태양신
- DM
- 중고거래처럼 개인 채팅 방을 개설할 수 있도록 만들기
- 영어버전 만들기
- 외국인을 위한 언어 변경
- 후기 적으면 바로 번역도 가능
- light, dark 버전 만들기
- 색상 변경하기
- 후기의 카테고리를 나누자
-
참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
-
시간
- 오전 10:00 ~ 오전 11:00 / 오후 02:30 ~ 오후 07:00
-
요약
- git 전략을 최종적으로 결정
- upstream을 제거하고 origin만 존재하는 형태로 다시 git 명령어 정리
- 기술 스택 정하기
- 간단히 정할 수 있는 기술 스택을 생각해서 나누기
- Backend / Frontend / Infra / CI/CD 등으로 나누어서 생각하기
- 기능 구체화
- 기술 스택을 세부적으로 진행하려고 해 보니, 기능을 좀 더 구체화하지 않으면 어려울 것 같으므로, 기능을 우선 구체화하자.
- 메인 기능 작성(사용자 거주지 작성 vs 사용자 위치 인증)
- 거주지 작성으로 하자. 임의로 위치에 따라 거주지 후기를 작성하는 것을 좀 더 번잡하게 적용
- 후기는 어떤식으로 작성할까?
- 잡플래닛에 나오는 것처럼 분야별로 평점을 매기고, 태그를 보여주는 형식이 좋을 것 같다.
- 이외 맛집, 여행 좋은 곳, 공공 시설 등에 대한 자연어 후기를 게시글 부분으로 빼자
- 기본 기능에 대한 의견
- Word cloud는 데이터가 많아야 하기 때문에 카테고리를 보여주는 것이 더 나을 것 같다.
- 유저 접속 시, 거주지는 무조건 입력하도록 하는 것이 편리할 것으로 보임
- 백로그 작성
- 핵심 기능(로그인, 맵, 동네 후기, 동네 게시글)에 대한 백로그 작성
- 추가적인 기능은 내일 더 작성하도록 하자
- git 전략을 최종적으로 결정
-
기술 스택
-
frontend
- TypeScript - React - Recoil vs Redux - Recoil 1표 - App 상태 봐서 1표 - styled component vs module CSS -> Styled Component - CRA vs webpack -> CRA - 사용자 위치 정보 받아오기 HTML5 Geolocation API http://dev.youngkyu.kr/31 https://lcw126.tistory.com/191 - 지도 API 카카오 VS 네이버 -
backend
- nginx - https - TypeScript - Node.js, Express - jwt - 위도, 경도 MySQL 저장 데이터 타입 https://blog.hajs.me/82 -
Infra
- nCloud - Frontend Server : nginx - Backend Server : express - docker -
CI/CD
- jest - github action
-
-
핵심 기능 구체화
-
회원가입 / 로그인
- OAuth 및 프로필 수정 기능
- 최초 OAuth 인증 후 회원등록시 프로필 정보(주소 등) 입력
- OAuth 및 프로필 수정 기능
-
맵 기능
- 웹 페이지 UI 컨셉 : 직방
- 지도 컨셉
- 지도 API 기반의 축척 변경 및 동네 구분, Marker 삽입(총 평점)
- Marker Mouse over 시, 잡플래닛과 유사한 항목 별 평점 표시
- 여유 만들어서 추가(Word cloud 또는 카테고리)
- Marker 클릭 시, 후기 내용 우측 화면 표시
- 400자 이내 후기 글(+사진 -> 쿠팡 처럼)
- 사용자 위치 획득 / 인증
- 사용자 로그인 무관 현재 사용자 위치 기반 지도 보여주기
- 사용자는 프로필에 등록한 주소(동) 기반으로 글 작성 가능
- 후기 동네 클러스터링
- 최소 단위 : 동
- 최대 단위 : 도(광역시 포함)
- 평점 매기는 방식? 평균
-
동네 후기 CRUD
- 동네에 대한 평점 매기기 (카테고리별 세부평점 매기기)
- 동네에 대한 후기 남기기 (평점 부여시 선택, 400자 제한)
- 프로필 작성 기준 글 권한 부여
- 최신순으로 보여주기
-
동네 관련 게시글 CRUD
- 맛집, 동네에 여행하기 좋은 곳, 공공시설 등
- 사진 업로드(object storage 사용)
- 분류 설정(맛집인지, 공공시설인지 등)
- 글 적는 부분
-
DB 설계
- User
- 이름, email(oauth), 거주지,
- User
-
-
git 전략(종우)
1. origin Repository : main / dev 브랜치 생성
2. 최초 1회 Local로 dev 브랜치 clone 후 directory 이동
- (local) git clone -b dev xxx.git
- cd REPO_NAME
3. 기능별 브랜치 생성(feat/{example})
4. 개인별 작업 브랜치로 이동
- git checkout feat/{example}
- git checkout -b {example}/#?
5. Local 작업 브랜치 코드 수정 및 commit 진행
- ({example/#??) git add && git commit
6. Local 기능 브랜치(feat/{example})에 단순 merge
- (feat/{example}) git merge {example}/#??
7. Local 작업 브랜치를 origin 대상 기능 브랜치에 push
- (feat/{example}) git push origin feat/{example}
- 이 때, Conflict 발생 시, rebase 후 conflict 해소 이후 push
- (feat/{example}) git pull --rebase origin feat/{example} 진행 후 conflict 해소, commit, rebase --continue
8. origin feat/{example} -> origin dev으로 PR
- PR 리뷰 및 Squash and Merge
- Conflict 발생 시 - (Local feat/{example}) git pull --rebase origin dev (conflict 해소 후 다시 Push && PR)
- Conflict 미 발생 시 - (Local feat/{example} -> origin feat/{example}) git push feat/{example} && PR
9. 배포판 구성 시, origin dev -> origin main 으로 PR
- create and merge의 경우 origin main -> origin develop으로 fetch 해주어야 함
10. Local 작업 브랜치 fetch and rebase
- (Local dev branch) git pull --rebase origin dev
11. 신규 기능, 3번 부터 반복
- 참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
- 시간
- 오전 10:00 ~ 오전 12:00 / 오후 01:30 ~ 오후 07:00
- 진행할 사항
- 금일 진행할 일 :
Git 전략 이해,Figma 그리기,기능 명세서 완성,기술 스택 완성,리더 정하기,기능 명세서 우선순위 선정 완료, ERD랑 인프라 구조 설계
- 금일 진행할 일 :
- 요약
-
Git 전략 관련 오전 회의 진행 및 Wiki 페이지 완성
-
지도 geoJson 및 시군구(행정구역) 폴리곤 만드는 방법 확인 필요
-
로그인 로직 관련 회의 진행
- 인증기관별(Google, Facebook, GitHub)로 애플리케이션 하나를 개설
- 로그인시, OAuth Callback URI는 프론트엔드 라우터로 처리
- 프론트엔드에서 Access Token을 발급받은 후 백엔드에 사용자 정보를 조회하는 fetch 요청
- (의문) 이미 access token을 발급받았던 사용자가 다시 발급요청을 보내면 github은 어떤 반응을 보일까 궁금합니다
- 권한 부여과정 없이 새로운 access token을 발급합니다
- 사용자 정보가 등록되어 있으면(이미 가입된 사용자)
- JWT 발급 후 메인페이지로 이동
- 사용자 정보가 등록되어 있지 않으면(가입 대상자)
- Access Token과 인증기관 uid를 담아서 주소지 입력 페이지로 이동
- 제출 후 Access Token으로 인증 기관에 사용자 정보 확인
- 인증되면 DB에 사용자 정보 저장, 회원가입 완료
- JWT 발급 후 메인페이지로 이동
-
Figma 작업 진행
-
App 메인 색상 :
- 현재 figma 색상 무시하고 아래 색상 기준으로 개발
-
로고 만들기
- 대회 : 로고 각자 만들어와서 투표를 통해 꼴찌가 1등에게 오프라인 모임 때 커피 사기!!
- 링크
-
기능 명세서(백로그) 핵심 기능 수정 완료
- 중요도 설정 완료 : 메인 기능들은 High, 애니메이션 등 Front 관련 내용 Middle, 기타 Low로 설정
-
ERD 설정
- 테이블
- User : 사용자 정보 저장
- Column: id(PK), oauth_platform_email(NN), 거주지(NN)
- Rate : 지역 평점 정보 저장 테이블
- Column: id(PK), user_id(FK), safety_rate(NN), traffic_rate(NN), food_rate(NN), enter_rate(NN), 거주지(동 단위)(NN), postscript
- Article: 게시글 정보 테이블
- Column: id(PK), user_id(FK), content(NN)
- Image: 게시글 이미지 테이블
- Column: id(PK), Article_id(FK), url(NN)
- Category: 게시글 카테고리 테이블
- Column: id(PK), Article_id(FK), category(NN)
- User : 사용자 정보 저장
- 기능 명세
- User는 oauth 기반 로그인을 할 수 있다.
- User는 거주지에 대한 평점을 매길 수 있다.(6개월 1회)
- User는 거주지에 대한 N개의 게시글을 남길 수 있다.
- 게시글에는 관련 이미지를 3개까지 첨부할 수 있다.
- 게시글은 관련 카테고리를 최대 3개까지 설정할 수 있다.
- Associations
- User - Rate (1:N)
- User - Article (1:N)
- Article - Image (1:N)
- Article - Category (1:N)
- 테이블
-
인프라 설계 구조
- 초기에는 1개 인스턴스에 Front / Back 서버 모두 구축, DB 서버는 별도 구축
- DB - MySQL 의 경우 replication 설정 직접 진행하여 Master - slave 구축하기
- 이미지의 경우 Object 스토리지 사용하여 통신
-
기술 스택
- FE
- React - Recoil vs Redux - TypeScript - styled component - CRA - HTML Geolocation API (사용자 위치 정보 받기) - 참고 - http://dev.youngkyu.kr/31 - https://lcw126.tistory.com/191 - 지도 API 네이버 / 카카오 - 행정구역 Clustering, geoJSON 설정 - 마커 표시, 마커 클릭 이벤트 - BE
- Express - TypeScript - HTTPS - NCloud - MySQL - Test
- Frontend : jest - Backend : postman - CI/CD
- github action - Infra
- nCloud - Frontend Server : nginx - Backend Server : express - Object Storage
- FE
-
참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우
-
시간
- 오전 10:00 ~ 오전 11:30, 오후 04:00 ~ 오후 05:00, 오후 06:00 ~ 오후 07:00
-
진행할 사항
- 금일 진행할 일 : PR/이슈 템플릿 만들고 테스트, README 업데이트(+기술적 도전 명세), 발표할 내용 정하기, API명세 작성, 그라운드 룰 수정
-
요약
- 템플릿 만들기 완성 및 README 예쁘게 다듬기 완료
- 발표 내용에 한 주동안의 과정(어떻게 회의하고, 어떤 과정에서, 무엇을 결정했는지 등)
- API 명세 일부 토의
- 스크럼 및 회의록 게시 당번 결정
- 10/29(금) 멘토링
-
발표 방식
- 기본적으로 readme 내용
- 프로젝트 개요 / 기술 스택 / 기술적 도전 / README에 정리한 내용
- figma
- 디자인 및 컨셉 설명
- 인프라
- 인프라 구조 초창기 설계 내용 및 추후 발전시킬 컨셉 대략 설명
- 어떻게 회의하고? 아침 10시부터 저녁 7시까지 풀 화상미팅+회의록 작성
- (1일차) groud rule 정하기
- (2일차) git 전략 회의(단계를 나눴던거)
- (3일차) 주제 정하고 기능 명세서 작성+멘토님 미팅 -> 주제를 늦게 정하게됬다
- (4일차) 백로그 작성 완료 및 figma 작성
- 협업 툴 : hackmd, google spreadsheet, figma
- 기본적으로 readme 내용
-
추가 의견
- SPA 그리고 SSR과 CSR
- CI/CD를 좀 더 Tool 기반 전문적으로 사용하기 (sourcedev, sourceComit, SourceBuild, SourceDeploy, SourcePipeline)
- 도커의 경우 CI/CD를 좀 더 잘할 수 있고, 배포판을 따로 관리한다면 좋다고 함
- 현재 인프라 구조로 구성을 한 뒤 나중에 전문적인 Tool과 docker를 사용해보기
- 다른 팀은 Socket.io, WebRTC 등의 기술을 많이 사용하려는 흔적이 보임. 우리 프로젝트에는 현재 적합하지는 않은 듯.
-
API 명세서 작성
-
회원가입(프론트엔드에서 access token 다 받은 후)
- request: GET /api/auth/sign-up
- response: 로그인 페이지로 redirect
-
로그인
- request: GET /api/auth/sign-in
- response: true/false
-
MAP
- request: GET /api/map?현재 한단계위 시/군/구
- response: 그 시/군/구에 있는 한단계 아래 모든 동네 총 별점, 카테고리별 별점, 상위 3개 태그
- 축적이 구 단위이면 가져오는 정보는 현재 구가 포함된시에 있는 모든 구 폴리곤 정보를 가져온다
- 축적 레벨에 따라서 가져오는 정보를 한 단계 위(지도 꽉 채우기)로 또는 한 단계 낮게(지도 여백 남기기) 둘 중 하나 정하기
-
사이드바(Map 클릭 시)
- 후기
- request: GET /api/postscripts?선택된 동네
- response: 현재 동네의 후기 정보 상위 5개
- 게시글
- request: GET /api/articles?선택된 동네
- response: 현재 동네의 게시글 정보 상위 5개
- 후기
-
후기 작성 Modal
- request: POST /api/postscripts
- Body : 선택 동네, 평점
- response: 후기 정보 DB 저장 결과
- request: POST /api/postscripts
-
-
swagger vs postman
- swagger 공부해보기
-
참고: ElasticSearch
- 유튜브 링크(기초 사용법)
- 개념 설명 블로그
- elastic maps
- ip정보로 위도/경도, 나라, 지역을 뽑아낼 수 있다.
- 한국도 지원을 시작했으며, 시/군/구까지 정보를 표시할 수 있다.
- 돈내는거 같다.
- http://kimjmin.net/2019/01/2019-01-korea-region-map/
- elastic stack
- elastic search + kibana + logstash
- 잘 모르겠다. 확장팩같은건가? 기능 추가되는거 같은데...
- elastic maps도 이렇게 묶음인것 같다.
- https://17billion.github.io/elastic/2017/06/30/elastic_stack_overview.html
- DB에서 유저를 빼고는 모두 elastic search에 저장해야할 것 같다.
- 그럼 이미지는 어떻게 처리할까...?
-
일요일 오전 10시 회의
- DB
- API
- 인프라 도커 적용
- 무중단 배포
-
그라운드 룰 추가
- 주차별로 스크럼, 회의록 위키에 올리는 것 담당하기
- 홍승용, 문혜현, 홍종우, 송명회