• 스크럼 양식
  • 어제 한 일
  • 오늘 할 일
  • 컨디션
  • 고민되는 점

예보 화면

• 전반적인 예보 문구
• 지역별 등급
• PM10 예보 이미지 위에 올라갈.............@@

• 대기질 예보 정보를 활용해서 PM10 예보 이미지들을 표시한다.
• API에서 받은 전반적인 예보 문구를 표시한다.
• API에서 받은 지역별 등급을 표시한다.
• 재생 버튼 누르면 대기질 예보 이미지를 일정 간격으로 반복 재생
• 진행바를 이용해 원하는 시점의 예보 이미지를 움직여서 확인 가능

이번주도 개발을 열심히 한 흔적이 보이네요.
PR도 분야별로 열심히 하신거 같고요. 업데이트 하기가 애매할텐데 issues를 활용하려고 한 것도 좋습니다.
👍
마무리도 멋지게 하시고요.
주말에는 팀으로 어떻게 더 잘 할 수 있을지? 고민도 해보시면 좋겠네요.

• 스크럼 양식
  • 어제 한 일
  • 오늘 할 일
  • 컨디션
  • 고민되는 점

• 예외처리
  • dust-status (미세먼지 정보)
    • GPS x, y 입력 값은 @notblank 를 만족해야합니다
  • transferCoordinationType (좌표변환)
    • Kakao API 에서 x, y 가 NaN 으로 오는 경우 에러 처리

ㅁㄴㅇㄹ

• GPS 정보를 TM 정보로 전환하기
• TM 정보를 기반으로 측정소 정보 가져오기

Master 피드백

Honux

readme

• 리드미 페이지는 대문이니까 조금 더 신경써서 깔끔하게 만들면 좋겠다.
• 리드미 페이지는 대문이니까 조금 더 신경써서 깔끔하게 만들면 좋겠다.중간에 브랜치 테이블에 local, origin으로 구분해 놨는데 구분의 의미를 모르겠다. origin은 git에서 사용하는 별칭이라 어색하고, 테이블의 쌍도 맞지 않다. 그냥 블릿으로 적어놓는 게 좋았을 듯
• 리드미 페이지는 대문이니까 조금 더 신경써서 깔끔하게 만들면 좋겠다.API 문서의 포스트맨을 한글로 적어 놓은 것도 매우 어색

프로젝트 동작

• 회원가입은 엄청 잘 만들었다.
• 아이디 중복체크를 포커스를 벗어날때 하는데 그것보다는 한글자 입력할 때마다 하는게 더 일반적인 듯. 다 입력하고 다음칸 넘어갔는데 경고 문구가 나오니까 다시 돌아가야 해서 어색
• 관심사에 같은 관심사를 3 개 입력해도 정상 동작(?) 코딩, 코딩, 코딩

프로젝트 관리

• 브랜치는 적절하게 잘 사용하는 듯
• 간혹 이슈에 제목만 짧게 있는 경우가 있는데 가능하면 한 두줄이라도 설명을 추가하면 좋을 것 같습니다.

Crong

• 409상태로 응답하는 것 좋아보이네요.
• 커밋메시지 간결하고 가이드 좋음. 한글로 적는것도.
• 스크럼은 관리이슈는 아니라서 wiki를 활용하는 건어떨가 생각됩니다.
• PR을 기능별로 잘 날리고 있어서 좋아요.
• task 들의 subtask 관리까지 자세하게 해서 좋네요.귀찮은 일일텐데.
• 스크럼내용이나 기타 기술정보는 github의 wiki를사용하는 것도 좋죠.
• 커밋할때 대문자로 시작하는 거 보면 좀어색해보여요. 대문자,소문자 막 섞여 있음 ㅎ
• 브랜치를 잘 나눠서 진행하시는거 같아서 좋음
• 진행사항 관리가 projects 에서 잘 되고 있네요.금요일이라 그런지 TODO도 몇개 없군요
• 배포준비를 잘 하고 있겠지만, 다음주에는 좀더미리미리 준비 하도록 해보세요.
• issue에서 스크럼을 하면서 서로 이야기하는 모습아주 좋네요. 칭찬 격려 이런게 제일 중요해요.

개선해야 된다고 생각하는 점

아래 내용은 합의되지 않은 저의 의견이며, 월요일 전까지 지속적으로 추가될 수 있습니다.

README

• 리드미 페이지를 어떻게 깔끔하게 할 것인가?
• Branch 항목에 대한 정리.
• README 보다는 WIKI 에 있어야 할 항목에 대한 분리.

Issue

• 크롱의 긍정적인 피드백 처럼 Task 에 대한 설명을 자세하게 기록하는 게 좋을 것 같습니다.
  • 저 같은 경우는 처음의 Issue 에는 할 기능을 적어놓고, PR 을 보내는 시점에는 실제로 구현한 세부 내용을 추가로 적곤 합니다.

Commit

• 커밋을 시작하는 문자가 섞여 있다고 합니다.
  • 저는 대문자 시작에 한표!
• Footer 에 이슈 번호 (# 이용) 를 담으로서 이슈와 PR, 커밋간에 관계를 가져갈 수 있습니다. 활용하면 좋겠습니다!

Deploy

• 다음 프로젝트는 AWS 를 기반으로 작업합니다. 주말간 AWS 를 올려보고 최소한 BE 끼리는 접근 권한을 공유할 수 있는 방법을 고민해보겠습니다.

문서 정리

• 문서 정리의 담당자 지정이 필요할듯 합니다.
  • 피드백 중 문서에 관련된 내용은 스크럼의 위키화, POSTMAN API 의 체계화 였습니다.
  • 프로젝트가 진행됨에 따라 문서 관리의 범위와 난이도는 커지지만 그 담당이 모호합니다.
  • ex) 요구사항분석+산출물: dan
    , postman : diane, taek
    , readme+scrum+wiki : delma

프로젝트 구조

• 이번 주는 프로젝트 Root 를 Repository 와 동일하게 갈 수 있습니다.
  • 가능하면 나누지 말고 가서 배포에 subtree 를 쓰는 불편함이 없었으면 좋겠습니다.

• /forecase/dust-status API 구현
  • testdata 로 구현

첫번째 셀 기반으로 상단에 데이터가 변경되는건 스크롤뷰가 움직이는 시점이므로
뷰가 로드되었을 때 맨 윗셀의 데이터를 가지고 와서 설정해주어야 함

아래 내용은 합의되지 않은 저의 의견이며, 월요일 전까지 지속적으로 추가될 수 있습니다.

# json 형태의 기상청 API 기반 key:value 를 그대로 사용합니다

BE 에서는 아래 API 의 정보를 재가공없이 응답합니다

• 측정소별 실시간 측정정보 조회
• 대기질 예보통보 조회

Dan

• 제일 좋은 건 필요한 정보만 선별하는 것이지만, 이 경우 분석에 너무 많은 리소스가 들 것으로 추정합니다.
• 필요한 정보만 선별하더라도 일관성을 유지하기 위해 기상청 API 의 key 를 그대로 쓰는 것이 좋음으로 Client 에서 선별을 하는 것이 좋다고 생각합니다.

# 서버로의 요청 좌표는 GPS 기반입니다

TM 좌표로 바꾸는 작업은 BE 에서 합니다

Dan
Client 에서 구현시 IOS, FE 이중으로 구현해야됨으로 BE 에서 해주는 게 좋다고 생각합니다.

Client 에서는 측정소에 대한 정보를 몰라도 BE 에서 적합한 측정소를 선정해 정보를 전달해줍니다

Dan
제안서에 보면 GPS 또는 주소에 대한 가장 가까운 측정소만을 조건으로 하고 있습니다.
따라서 Client 가 측정소에 대한 정보를 알 필요는 없는 것 같습니다.

• log 설정
• CORS 설정
• default message 설정
• default exception 설정
• default response 설정
• pid 파일 생성

화면에 포함될 라벨 등의 기본 뷰 구성하기

• title
• emoji
• status
• 𝜇g/m³ 측정값
• 가장 최근 측정 시간
• 가까운 측정소
• 지난 24시간 테이블뷰
• gradient 백그라운드

기능

[미세먼지 화면]

• 스크롤되지 않는 테이블 뷰 셀 선택시 상단에 정보 표시
• status view에 '오늘' 부분 현재 날짜와 측정 날짜 비교해서 어제 or 오늘로 변경

코드

• 받아온 데이터 디코딩시 JSONDecoder의 decode(type:from:) 메소드를 사용할때 분기처리 제거 후 파라미터로 받도록 수정
• 테이블뷰의 dataSource와 delegate 분리

예보 화면에 있는 기본 라벨 등의 항목 구성

• 제목
• PM10 예보 이미지
• 예보 문구
• 지역별 등급
• 재생버튼
• 재생 프로그레스 바?

• 하단 탭바 아이콘은 SF Symbols 에서 export 해서 Xcode 에셋으로 활용

아래 내용은 합의되지 않은 저의 의견이며, 월요일 전까지 지속적으로 추가될 수 있습니다.

코딩 컨벤션 맞추기

전문적으로 하기 위해서는 linter 를 사용할 수도 있지만, 그런 경우 사전에 협의해야되는 규칙이 너무 많아질 것 같아 합의된 사항에 대해서만 수동으로 지키도록 합니다.

참고자료 : Google Java Style Guide

• Tab size : 2, Indent : 2, Continuation Indent : 4
  

• Class 선언 이후 1줄을 띄웁니다.

• 3항 연산이 아닌 If 문과 For 문은 항상 괄호를 사용합니다.

• 무의미한 공백은 제거합니다.

프로그램 설계에 대해

이번 프로젝트에서는 MVC 모델 중 Model 에 대한 구현을 넓혀 DAO, DTO, Service 의 개념을 사용하고 싶습니다.

여유가 되면 배치 작업 구현 부터..

• Url 을 만들기 위한 String 연산을 StringBuilder 로 전환

아래 내용은 합의되지 않은 저의 의견이며, 월요일 전까지 지속적으로 추가될 수 있습니다.

# 내부 요구사항

배포 서버에 대한 관리

배포 전략과 script 작성, BE 간의 키 공유를 준비합니다.

Dan
AWS 를 사용하면 한대만 무료로 사용할 수 있기에 dev, master 를 각각 나눠 담당하면 좋겠습니다.

GPS 좌표를 TM 좌표로 전환합니다

근접측정소 목록 조회 에서 필요한 TM 좌표를 구합니다.

Dan
Client 에서 구현시 IOS, FE 이중으로 구현해야됨으로 BE 에서 해주는 게 좋다고 생각합니다.

Mockup 서버 구현

Dan
이전과 같이 PostMan 으로 하면 될 것 같습니다.

API KEY 관리 방법

Dan
서버에 하드코딩하지 않고 할 수 있는 방법이 있을까요?

# BE - 기상청 요구사항

미세먼지 API KEY 발급 완료

공공데이터 포털에서 발급 (https://www.data.go.kr)

• 측정소정보 조회 서비스 (한국환경공단_측정소정보)
• 대기오염정보 조회 서비스 (한국환경공단_대기오염정보)

미세먼지 앱 구현 (제안서의 3페이지)

• 변환된 TM 좌표를 기반으로 근접측정소 목록 조회 를 사용하여 적합한 측정소 정보를 가져옵니다

  • 측정소가 여러개 나오는 경우 첫번째 것을 사용합니다

• 측정소 정보를 기반으로 측정소별 실시간 측정정보 조회 를 사용하여 미세먼지 정보를 가져옵니다.

대기질 예보통보 조회 구현 (제안서의 4페이지)

대기질 예보통보 조회 를 사용합니다.

# BE - 기상청 배치작업

DB 구현이 들어갑니다.

Dan
아직 여기는 생각하고 싶지 않습니다..........

• 측정된 값에 따라 이모지 변경
• 측정된 값에 따라 배경색 변경
• 측정된 값에 따라 state 라벨 변경
• 측정된 값에 따라 숫자 단위값 변경
• 현재 시간 기준 가장 최근 측정된 시각 변경
• 가까운 측정소 기준으로 표시 ( gps permission)
• 스크롤시 가장 위에 표시한 항목 기준으로 상단 이모지, 배경, 측정치, 날짜 정보 변경
• 대기질 기록표시 바 그래프를 측정 값에 따라 채움(0~200)

미세먼지 화면

• 현재시간 기준, 가장 최근 측정 시각
• 현재시간 기준 가장 최근 측정 값
• 측정소 위치(로컬에서 gps로 거리 비교?)
• 대기질 마지막 24시간동안의 측정 값(현재시각으로 지난 24시간 말하는건가?)

• Apachi Tomcat 기동