포스트

2022-02-08-TIL

TIL
게시 수정 작성자 August
좋아요 조회 6 분 읽는 시간
  1. docs(posts): write every reference entry as title, then publisher +7 −7
  2. docs(til): drop the ai keyword sections from tils up to 2023 +0 −6
  3. docs(til): fill out the thin 2022 tils +53 −10
  4. 처음 게시

Today I Learned

모든 for와 if는 스트림으로 변환이 가능한가?

대부분의 “컬렉션을 돌면서 조건에 맞는 것을 골라 변환하고 모으는” 반복문은 filter, map, collect로 옮길 수 있다. 하지만 모든 반복문이 그대로 옮겨지지는 않는다.

  • 람다 안에서는 바깥의 지역 변수를 바꿀 수 없다. 람다가 참조하는 지역 변수는 final이거나 사실상 final(effectively final)이어야 한다(JLS 15.27.2). 루프 안에서 합계나 플래그를 갱신하던 코드는 reduce, collect로 구조를 바꿔야 한다.
  • break, continue, return으로 흐름을 끊던 코드는 anyMatch, findFirst, limit 같은 short-circuit 연산으로 바꿀 수 있을 때만 옮겨진다.
  • 람다 안에서 checked exception을 던지는 메서드를 부르면 감싸서 처리해야 한다.
  • java.util.stream 패키지 문서는 스트림 연산에 넘기는 동작(behavioral parameter)의 부수 효과를 일반적으로 권장하지 않는다. 외부 상태를 바꾸는 것이 목적인 루프는 스트림보다 for문이 의도를 더 잘 드러낸다.

그래서 질문의 답은 “기술적으로는 대부분 가능하지만, 바꿨을 때 더 읽기 쉬운 경우에만 바꾼다”에 가깝다.

데이터를 주고받는 방법

시스템끼리 데이터를 주고받는 방법은 크게 세 가지로 정리했다.

  • message broker: 중간에 브로커를 두고 메시지를 비동기로 전달한다. 보내는 쪽과 받는 쪽이 동시에 살아 있지 않아도 된다.
  • REST API: HTTP 요청과 응답으로 주고받는다. 호출한 쪽이 응답을 기다리는 동기 방식이 기본이다.
  • 소켓 통신: 연결을 열어 둔 채 양방향으로 데이터를 주고받는다. 실시간 알림이나 채팅처럼 서버가 먼저 보내야 하는 경우에 쓴다.

RabbitMQ

RabbitMQ 메시지 전송이 제대로 가는지 디버깅하는 방법?

Spring 가이드 Messaging with RabbitMQ는 메시지를 받는 Receiver에 CountDownLatch를 두고, 메시지를 받으면 countDown()을 호출하게 만든다. 보내는 쪽은 latch를 기다리므로 메시지가 실제로 도착했는지 코드에서 확인할 수 있다. 테스트 코드에서 수신 여부를 검증할 때도 같은 방식을 쓸 수 있다.

브로커 쪽에서 보는 방법도 있다.

  • Management Plugin은 브라우저 UI와 HTTP API를 제공한다. exchange, queue, binding 상태와 큐에 쌓인 메시지 수를 보면서 메시지가 어디서 멈췄는지 좁혀 갈 수 있다.
  • Firehose Tracer는 개발이나 디버깅 중에 발행되는 모든 메시지와 전달되는 모든 메시지를 보고 싶을 때 쓰는 기능이다. 노드와 vhost 단위로 켜면 발행, 전달 알림이 amq.rabbitmq.trace exchange로 복사된다. 운영에서 계속 켜 두는 기능은 아니고, 다 쓰면 끄고 추적용 큐도 정리해야 한다.
1
2

rabbitmqctl trace_on -p /
rabbitmqctl trace_off -p /
  • https://spring.io/guides/gs/messaging-rabbitmq/
  • https://spring.io/guides/gs/messaging-rabbitmq/#scratch
  • https://www.rabbitmq.com/tutorials/tutorial-one-java.html

Loudness Normalization vs Loudness Equalization

둘 다 소리 크기를 맞추는 방식이지만 무엇을 맞추느냐가 다르다. 아래 글은 보청기 피팅 공식에서 두 접근을 비교한다. 라우드니스 정규화(normalization)는 정상 청력인 사람에게 작게, 보통으로, 크게 들리는 소리가 청력 손실이 있는 사람에게도 각각 작게, 보통으로, 크게 들리도록 맞춘다. 라우드니스 평준화(equalization)는 모든 말소리가 같은 크기로 들리게 만든다. 글은 정규화가 저주파 이득을 상대적으로 키워 명료도에 문제를 줄 수 있다고 설명하고, 두 접근을 상황에 따라 섞는 알고리즘을 소개한다.

방송과 스트리밍에서 말하는 라우드니스 정규화도 같은 발상이다. EBU R 128은 프로그램 평균 라우드니스를 -23 LUFS로 맞추도록 권고한다. 프로그램 라우드니스와 true-peak 레벨을 재는 알고리즘은 ITU-R BS.1770이 정의한다. 프로그램마다 체감 음량이 들쭉날쭉하지 않게 하려는 목적이다.

  • https://www.audiologyonline.com/articles/beltone-s-adaptive-fitting-algorithm-1206
참고한 자료외부 출처 7

외부 출처

TIL, 2022-TIL
TIL
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다