아기곰푸우

WebSocket을 기본적으로 지원하는 메시지 큐(Message Queue) 시스템은 많지 않지만, WebSocket과 쉽게 통합할 수 있는 몇 가지 메시지 브로커와 솔루션이 있습니다

1. NATS

• WebSocket 지원: 기본적으로 WebSocket 지원 추가됨 (공식 문서)
• 사용 방법:
  • WebSocket을 직접 사용하여 메시지를 송수신 가능

2. EMQX (MQTT Broker)

• WebSocket 지원: 기본적으로 WebSocket을 지원
• 사용 방법:
  • MQTT 프로토콜을 WebSocket과 함께 사용하여 메시지 큐 기능 구현 가능

3. Mosquitto (MQTT Broker)

• WebSocket 지원: 직접 지원
• 사용 방법:
  • mosquitto.conf에서 WebSocket 리스너 설정 후 사용 가능

https://kakaoentertainment-tech.tistory.com/110

인증(authentication) 사용자가 누구인지 식별

인가(authorization) 사용자가 무엇을 할수 있는지를 결정

암호화(encryption)  누설과 위조로 부터 데이터를 보호

감사(auditing) 사용자가 무엇을 했는지,하려했는지를 추척

쿼터(quotas) 자원을 얼마나 많이 사용할수 있는지 조절

--------------

클라이언트 진정성 - 클라이언트 인증

서버 진정성 - 실제 브로커 연결인지 검즘

기밀성 - 메시지 전달간 암호화

무결성 - 내용물 변조여부

접근제어 - 권한확인

감사가능성 - 감사용 기록

가용성 - 몇몇사용자의 대역폭 독차지을 막기위한 쿼터와 제한

yona 설치시 java sdk는 oracle을 사용할것

아니면 설치시 bat 파일을 수정할것

https://yona.io/

100명이하 일 경우 유용할듯

스크럼

• 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
• 개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
  (설명:너무 짧으면 개발(분석/설계/개발/테스트) 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로 적용해보면서 필요시 조율 필요)
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
  (설명:해당 주기의 Goal을 작성하지 않으면 목적을 잃은 기능 목록이 될 수 있음)
• 매일 15분 정도의 Scrum meeting 회의를 가져라.
  (설명:공유이지 보고하는 자리가 아니다. 교과서적으로 Scrum meeting은 개발팀원만 참여해야하고, 팀원이 아닌 사람은 발언기회는 없다고 한다. 개인적인 생각으로는 수평문화가 되어 있는 Agile Culture의팀이라면 PO 및 관리자가 함께 참석하여 공유하면 좋다고 생각한다. 이들도 참석한다면 이 프로젝트와 관련되어 한일/할일/이슈를 공유해야 한다. 안그러면 한팀이 아닌 관리자 모드로 돌아선다.)
• 항상 팀을 우선으로 생각하라.
  (설명:자신의 task보다 주변 이슈가 더 급하면 도와줘야 한다. 마치 배에 구멍이 나면 그 문제 해결이 1순위이다.)
• 원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지하라.

분석, 설계, 개발, 테스트 반복

폭포수 모델중 일부를 반복

1. 소프트웨어 요구사항 기술
2. 소프트웨어 설계
3. 소프트웨어 구현 (또는 코딩)
4. 시험과 디버깅
5. 설치
6. 소프트웨어 유지보수

• 제품 백로그(Product Backlog) : 개발할 제품의 요구사항인 사용자 스토리 집합이며, 우선순위로 관리

• 사용자 스토리(User Story) : 과거 요구사항 명세처럼 업무 범위를 구체화하기 위한 개발자 입장이 아닌, User Story는 사용자가 사용하는 관점에서 어떤 가치를 제공할 것인지를 설명
  (해설 : PO는 이 기능이 누구에게 무슨 value를 제공하는지를 설명하고, 향후 개발자는 그 기능의 Value를 제공하기 위한 기술적인 역할과 책임을 가짐)

• 완료 기준(Definition of Done), 인수 기준(Acceptance Criteria) : 사용자 스토리를 완료시키기 위한 조건 명세(Given, When, Then)

• 스프린트(Sprint) : 계획,개발,리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위에서 선택

• 잠재적 출시 가능 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP) : 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품

• 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 회의(4주 스프린트 기준 8시간 정도 수행)

• 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록

https://datalust.co/

온보딩 - 신입개발자

직무교육

인프라교육 : 구글 클라우드, 사내 서버

핵심가치 : 익스트림 프로그랭밍 중 차용
용기: 문서로 변명하기 보단 진실되고 용기있게 개발
존중: 개발자의 역량을 존중하고 충분한 권한과 권리 부여
의사소통: 이해관계자 모두가 팀원이라는 생각으로 모든 사항 공유
피드백: 의사소통에 따른 즉각적인 피드백
단순성: 필요한 것은 하지만 더이상은 하지 않음



Fine scale feedback
Pair Programming: 하나의 작업을 2명의 프로그래머가 코딩·리뷰 공동 수행
: 하나의 작업을 멘토와 진행하고 소스는 모두 공유하고 주기적인 코딩리뷰


Planning Game: 게임처럼 선수와 규칙, 목표를 두고 기획 수행
: 개발 계획


Test Driven Development: 선 단위 테스트후 실제 코드 작성
: 코드작성

Whole Team: 개발 효율을 위해 고객을 프로젝트 팀원으로 상주
: 한나의 개발팀으로 묶음 , 기획,클라이언트프로그래머,서버프로그래머

Continuous process
Continuous Integration: 상시 빌드 및 배포가 가능한 상태로 유지
: CI 툴 활용 jenkins 누구나 빌드, 배포가 가능하도록

Design Improvement: 코드 개선 작업 수행(가시성, 성능 등), 불필요한 기능 제거 및 리팩토링
: 

Small Releases: 짧고 잦은 릴리즈로 고객이 변경사항을 볼 수 있게 함 → 잦은 피드백
: 지속적인 내부 테스트 가능하도록

Shared understanding
Coding Standards: 표준화된 관례에 따라 코드 작성
: 표준 코딩 인벤션 사용, 디자인패턴 관련 용어 

Collective Code Ownership: 시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정 가능



Simple Design: 가능한 가장 간결한 디자인 상태 유지



System Metaphor: 최종적으로 개발 되어야 할 시스템의 구조를 조망
: 전체 개발의 목표 , 조망


Programmer welfare
Sustainable Pace: 오버타임 지양
능률 우선, 시간 절약 방밥

agora.io 사용시 방리스트 구현이 안되어 있음

1. 웹서버로 구션 : db 는 메모리, redis, mongodb

우선 몽고 db로 구현후 속도 여하에 따라 redis 구현할것

2. 소켓서버로 구현 : 별도 서버 필요, 수평확장이 용이하도록 구현하기 위해선 여러가지 필요

3. agora.io 로 방 리스트 구현 방식 고민

별도 채널을 방리스트 구현가능하나 최대 인원수 문제로 제약이 심함

간단한 채팅일 경우 구현 가능할듯

4. redis cloud 로 구현

동시 접속 30 제한으로 별도 서버로 구현해야함

1. c# 초간단 멀티 스케일아웃 서버

최소 서버 기능 

스케일 아웃 기능

패킷 정의는 클라에서

서버는 중계 역화

zeromq xpub, xsub 로 처리