1 minute read


blog

꼭 rdp 통하지 않고도 작업 가능한 모양이다. 다음에 추가 세팅 예정.

job

GOP-14151 분석 3

분명 관련 코드를 배포하는 곳이 있을 것이라 생각했는데, 따로 있진 않은거 같고, dev-util쪽에서 테스트 코드를 실행하는 것을 발견했다. 이걸 이용하고 실행해 보면 ㄱㅊ을수도.

마크님께 확인받은 결과 일단 다른것은 신경쓰지 않고 핵심 파싱/전송 부분만 만드는게 우선이기 때문에, 그 부분만 테스트 포함해서 만들면 될 것 같다.

정책

  • 구성
  • 업무별 형태, 개별부 내용
  • 호스트, 포트

구현

  • 소켓 접속
  • 비동기 전송, 파싱
  • ec2 리스너 서버
  • 람다 전송 서버
  • 로거
  • 연동되어야 하는 다른 부분

jest로 된 기존 테스트를 쓰고 싶은데, 전체 테스트를 돌리게 되어있어서 어떻게 해야 하나 했는데, 그냥 아래와 같이 하니 되었다. npm test -- <Test Name on 'describe' clause>

GOP-14151 작업 4

어떤 문서 구성에 대한 정보와 함께 문서 raw 데이터를 파서에 넘기면, 그 파서는 해석된 정보를 리턴한다. 또한, 해석된 정보를 언파서?에 넘기면, 언파서는 보내야 할 문서을 만든다. 근데, 이름이 맘에 안든다. 파서는 ㄱㅊ은데 언파서는 좀 그렇다. 차라리 인코더 디코더가 나을 듯.

싶지만 찾아본 의미상 그건 또 안맞는거같아서 일단 reader, writer로 함.

위에서 알아낸 jest 테스트 실행법에서, 테스트 이름에 띄어쓰기가 있는데도 되길래 괜찮은건가 했는데, 알고보니 그냥 그 이름의 앞부분만 들어간 것이었고 패턴 매칭해서 실행된 것이었다.

구조를 좀 생각해보자. 파서는 문서 구성에 대해 몰라야 한다. (테스트쪽에서 집어넣어서 실행) 그렇다고, 매 메시지 읽기마다 문서 구성을 읽어들이는 작업을 하는 것은 낭비다. 이부분에 대해 신경쓰면서 구현해보도록 하자.

고정값을 가지는경우/가지지 않는 경우는 어떻게 처리? 템플릿 넘겨받을 때, 실제 실행할 때에 따른 실행 책임이 다르다. 그정도는 덮어쓰는 정도로도 ㄱㅊ긴 할듯.

근데 이거 양식 그대로의 식별명같은 것들을 그대로 써도 보안/법률상 문제가 없을 지 궁금하다.

봤더니, 그 구현에서는 그런 영어 식별 이름이 없었다..

보안 프로그램 설치

설치 완료.


Comments