2 주차 작업일지

[gringrape]

201123

목표

• 2 주차 계획 세우기
• 디자인 구상하기

  디자인 구상

  전략

• 디자인 훈련이 부족하기 때문에, 무엇을 넣을 수록 조잡해진다. (상황)
• 기본적인 디자인 법칙을 참고할 수 있다. (배색, 폰트) 강의를 들을 수 있다. (조건)
• 최소한의 요소를 사용한다. 심미적인 이유로 요소를 추가하지 않는다 (어차피 못한다 ㅋㅋ) (방법)
• 폰트, 색상의 가짓수를 최대한 적게, 분명한 이유로 사용한다. (방법)
• 빌린다. -> 디자인 시스템? (방법)

  최소한의 요소 사용

• 잘은 모르겠지만, 설명하는 부분을 최대한 덜어내고 직관적으로 구성하면 어떨까 한다.
• 비슷한 게임에서는 어떻게 적용했는지 살펴보자.

[gringrape]

201124

목표

• CI 점검
• 제시문 검사

[gringrape]

201125

목표

• 사용자가 입력 상태를 알 수 있도록 하기 -> 달성
• 문장이 제시어를 포함하는지 검사 -> 파산

  사용자가 입력상태를 알 수 있도록

  구상 - 상태 설정

  입력 상태를 설정한다. 현재는 speaking 이라는 boolean 으로 되어있다. 입력중을 표시하려면 하나의 상태를 더 추가해야 한다. 이 상태를 'SPEAKING', 'MIC_ON', 'MIC_OFF', 세가지의 상태로 구분할 수 있겠다.
  상태에 따라서 마이크의 CSS 효과를 다르게 줄 수 있다. SPEAKING 일 경우는 마이크를 녹색으로 처리해 준다.

  할 일

• [x] speakStatus 를 상태로 설정한다. - 문자열
• [x] 초기상태는 MIC_OFF 이다.
• [x] setSpeakStatus 를 통해서 다른 문자열로 바꿀 수 있다.

  사용자 마이크 입력중

  사용자의 입력 이벤트가 일어날때 마다 상태를 바꾸는 코드가 실행되어야 한다. Promise 를 사용하면 한번 일어날때는 사용할 수 있다. '일어날때마다' 는 어떻게 할 수 있을까?

RxJS 에서는 Observable 이라는 구조를 제안한다. See also https://rxjs-dev.firebaseapp.com/guide/observable

이 구조가 이 상황에서 유용한 이유는

첫번째로 생산자 중심(Push)이라는 점이다. Promise 의 경우처럼 생산자(함수)는 단순히 호출되는 것이 아니라 소비자의 동작을 어떤 시점에서 해줄지 컨트롤 해줄 수 있게된다.

두번째로 스트림을 통한 일관된 자료 소비방법(프로토콜)을 갖고 있다. 자료가 어떤 것이든 스트림을 통해 소비할 수 있기 때문에, 지금 경우처럼 '~ 할 때 마다' (개념적으로 무한 스트림???) 를 처리하는데 굉장히 유용하다. 복수형의 비동기 처리에 있어서 Promise 가 잘못하는것 (내가 아는한....) 을 굉장히 잘 매우고 있다고 생각된다.

세번째로 테스트가 쉬워진다. '~ 할 때마다' 를 Promise 에서 보면 개념적으로 복잡하지만, Observable 관점에서 보면 스트림이라는 말로 단순하게 정리가 된다. 따라서 테스트를 위해 모킹할때는 단순하게 스트림 구조만 사용해주면 된다.

[gringrape]

201126

목표

• [ ] 테스트 100%
• [x] 인수 테스트
• [ ] 버그 수정
• [x] 제시어 포함 기능
• [ ] 음성 합성 예제 작성
• [x] 전실어증 환자를 위한 기능 구상

  테스트 100% - 서비스 테스트

  이벤트 리스너 테스트

  https://ilikekillnerds.com/2020/02/testing-event-listeners-in-jest-without-using-a-library/

내가 작성한 코드의 개념정리

• 외부 클래스를 참조하여 객체를 생성한다.
• 해당 객체의 이벤트 리스너 메소드를 사용한다.
• 해당 객체의 start 메소드를 사용한다.

모킹이 필요한 부분

• 외부 클래스
• start 메소드
• addEventListener 메소드

참고 자료

• 글로벌 객체의 모킹 https://stackoverflow.com/a/41888736
• See also Class Mock - Jest https://jestjs.io/docs/en/es6-class-mocks

테스트의 의의

• 뭘 테스트 해야 하는지, 라이브러리를 테스트하는 건지 다시 한 번 생각해보자.

마이크의 볼륨에 따라서 Volume meter 와 같은 애니메이션 만드는 원리

https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API/Visualizations_with_Web_Audio_API

인수테스트

[gringrape]

201127

할 일

피드백

• 포함 X 일때 문구 넣기
• 마이크 애니메이션 간단하게 구현하기 -> 파산
• 효과음 넣고 느낌 보기
• 버그 수정

  장기기억 자극하기

• 화요일 맞추기 기능 구현 -> 파산

알게 된 것

클래스 모킹 방법

• 자바스크립트는 프로토타입 기반 이기 때문에, 특정 클래스에 대해서 모킹하려면, 프로토타입의 프로퍼티를 스텁으로 만드는 것도 방법이다.

[gringrape]

201128

목표

• redux-saga 학습, 예제 만들기
• 전실어증 환자를 위한 예/아니오 문제 시험버전 개발

redux-saga 를 지금 학습해서 적용할 이유가 있을까?

있다. 이전에는 아니라고 답했겠지만, 지금은 아니다. RxJs 를 적용하면서 개념적으로 어려운것은 별로 중요한 문제가 아니라는것을 알았다. RxJs 를 알기전에는 하루 종일 고민해도 어떻게 테스트하면 좋고 구현하면 좋을지 잘모르겠던 문제가 알고나서는 10분만에 답이 나왔다. 실질적으로 테스트하기 쉬운 개념과 구조는 개발상에 있어서 비즈니스 로직이외에 발생하는 소모적인 고민을 확줄여주기 때문에 좋은것 같다.

물론, 학습 비용은 있다. 하지만 이후에 발생할 고민들을 생각하면 지금 훌륭한 도구가 있다는 것에 감사하고 적극적으로 배우는것이 좋겠다. 게다가 현재는 비동기 액션 처리부분이 많지 않고 매우 단순하기 때문에 적용하기도 쉬울 것이다. dispatch 를 너무 많이 보는 것이 힘들어지기도 했다. 결론은 지금 적용가능한 정도로 배운다.

redux-saga

saga 는 무엇?

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj591569(v=pandp.10)?redirectedfrom=MSDN 위의 문서는 Process Manager 라는 개념을 사용하고 있다. Process Manager 는 여러개의 Aggregate 가 존재할때, 각 모듈의 작업을 중앙에서 조율하는 역할을 한다. Aggregate 들이 소통하는 방식은 크게 명령과 이벤트다. (이 명쾌한 분류가 굉장히 재미있다) 좌석모듈에게 '좌석을 예약해라' 하는 것은 명령이고, 그 결과로 좌석이 예약되었음을 알려주는 것이 이벤트다.

이벤트로 소통하는 대표적인 방식이 콜백, Promise, Observable 인 것 같다. 특히 Promise 와 Observable 이 재미있는데, 마치 커피를 기다릴때 나오는 진동벨같이 띵똥하고 울리면 해야할 일을 하면 되어서 재미있다.

프로세스 매니저 구조를 사용하면, 각 모듈은 작업순서를 알필요가 없어진다! 중앙에서 명령하기 때문에 각 모듈의 로직은 심플해지고, 명령을 받고 이벤트 토큰을 발행하거나 이벤트가 일어나면 뭔가를 하는 심플한 존재가 되어버린다.