(파란별) Index

(파란별) Date

의 회의록 마스터 : 이하령

(파란별) Participants

TEAM FIRE (고주형 윤영기 이하령) + Jinho Choi

(파란별) Discussion topics

현재 멘토링 시간

  • 핵심만 집중하고 짧게 끝내는걸로!

  • 좋다!

모델링 관련

주형님의 Q. 소켓.io를 사용하고 있는데 error 처리는 어떻게 하나요?, 정상적인 연결이 된 상태에서 인증정보가 유효하지 않다는 정보를 클라한테 어떻게 돌려주나요?

flow chart를 만들자.

  • 로그인

    • 토큰

      • 토큰을 가지고 권한을 가져야 함

      • 토큰을 가지고 방 리스트를 가져옴(restful)

        • 방에 무엇이 있는지 정보

        • page 기능(테마별)

  • 룸에 대한 시그널링

    • 그 전에 이 룸에 대해 미리 예약하는게 필요

      • try 개념을 넣어주자

      • 룸 참여자들 다 가져와야 함

      • 룸 참여자들 다 찔러줘야 함

      • join 된 사람으로 등록

      • 들어가서 채팅 주면 소켓이 broadcasting

      • webRTC(시그널링) 안돼도 채팅 되면 들어갈 수 있어야 함

  • 현재 restful 정보들이 너무 적다

    • mesh여서 누가 누구랑 연결되었는지 등의 정보가 있어야 함

  • master model 정보가 rdb에 있을지 redis에 있을지?

    • 속도면에서는 redis가 좋고

    • 구조적에서는 몽고가 좋고

    • redis가 hierarchy구조가 아니라 어려우면 mongo db 쓸수도?

    • 어떤 분은 웹소켓 안쓰고 firebase 씀

      • connectivity도 reliable하게 맺어줌

    • db가 빠른 변화에 sync 맞춰야 함

  • flow 제대로 설계하는 것도 힘들다..

    • 우선 flow 차트를 그리자

    • 어떤 것을 rest로 할지, socket으로 할지

    • 이 모델에서 빠져아 할 것은 무엇일지

    • 등등 고민

  • 품질 생각하려면 미디어 서버 두는게 좋을 듯

    • 현재는 4명까지는 괜찮을거 같다

  • socket으로 주고받는 데이터들이 누구와 받는 시그널링 데이터라는 것을 알아야 한다.

  • 현재 시현 하는건 별로 의미가 없다

    • 설계 어느정도 되고 해야 할듯

주형님의 Q. redis가 hierarchy구조가 아니라고 하셨는데 key로 만드시는 건가요?

  • 멘토님은 보통 그렇게 많이 하셨음

  • 완전히 계층이 없는건 아님

  • 쓰레기 데이터가 있으면 처리해야 함

  • pouch db도 좋다

  • 새로운 기술 있으면 써보는 것도 좋을 듯

배권한 멘토님 멘토링

Giggle-Forest 한번 참조해보는것 좋아보임 -> 기술이 유사

Redis : key 이름부터 막힘? 애매&답답 -> 스터디로 풀어볼게요

: 펍섭..? 클러스터링떄 힘들텐데, 일단 삽질좀 해보세요

: 라인은 6개 달려있음 -> 멋있지? 

: 강제로 fail-over 시켜봐야 알 수 있음

프로젝트 관련 - TODO

  • 방이 여러개가 아님

  • 내보내기 기능은 되어야함

    • 그러면 권한이 필요하므로 방장이 필요함

  • 룸 리스트 API 를 하드코딩 말고 다이나믹으로 할것

  • 음성쪽 테스트가 많이 필요함

  • 음성쪽 마이크 선택이나 화면 공유등

  • 화면 공유용 버튼이 필요함

  • 화면사이즈 큰것 대응하기 ( 미디어 쿼리 )

  • 스프린트에 이슈는 모두 스토리포인트를 적어서 나중에 회고할것

프로젝트 외

  • 진행중 -> 해야 할 일로 빼야됨 (scope 를 줄이는 역할이 필요함) : visualize 잘 하자

  • story-point estimate 하나도 안맞음 ㅋㅋ 당연히 안맞음 : 경력이 딸려서 그럼

-> 그럼에도 불구하고 잘 맞춰 나가야됨. jira plugin 쓰거나, 

ex) webRTC조사 이런 이슈가 들어가야됨 : 그러고 나서 시간 estimate 필요 -> 이게 빠져서 시간 제대로 체크가 안되는것임 : 지금부터 연습 ㄱ

  • 스프린트 시작 시에 모든 issue 에 대해서 story estimation 잡고, time tracking 특정 해야됨 : 끝났을 때 이걸 회고하면서 얼마나 차이가 있었는지 자아 비판을 해야됨

  • 이슈는 차라리 많은것이 좋다. 이슈별로 estimate 하고, 할일에 쭉 들어가고 이번 스프린트에 할 수 있는지 검사 -> 한번 스프린트 돌리고 회고하면 됨

    • ex) 이번 estimate 10점 이상은 쪼개자! 처럼 애자일스럽게 회고를 해야된다

  • Jira를 잘 쓰자 [보드랑 이슈에 업데이트 좀 해라]

다음 스프린트는 estimation 잘 하고 다음주에 회고를 같이 진행하자! 녹음이나 녹화하고 보내줘도 OK