일부 라우터와 방화벽이 애플리케이션에 아무런 신호도 주지 않고 유휴 TCP 연결을 조용히 끊어버리는 경우가 있음, HTTP 클라이언트 라이브러리나 데이터베이스 클라이언트와 같이 TCP 커넥션 풀을 유지하는 코드는 이로 인해 연결이 아무 경고 없이 무효화되는 문제를 경험함, 이를 해결하려면 시스템 TCP keepalive를 설정하거나 HTTP라면 Connection: keep-alive, Keep-Alive: timeout=30, max=1000 헤더를 사용할 수 있음, TCP 커넥션이 한번 연결되면 중간 라우터에는 상태가 남지 않음, 문제는 방화벽이나 NAT 세션 타임아웃임, 이때 RST 패킷도 오지 않음, K8s 환경에서는 conntrack 모듈 설정이 너무 낮았던 문제를 겪었음, HTTP Keep-Alive를 써봐도 연결 재사용에만 효과 있고 네트워크 상의 연결을 유지하진 않음(설명 링크), HTTP Keep-Alive는 실제로 패킷을 발생하지 않고 단지 종료를 미룰 뿐임, 반면 TCP Keep-Alive는 패킷을 주기적으로 발생시켜 타이머를 리셋해줌
TCP Keep-Alive는 모바일 기기와 잘 동작하지 않을 수 있음, 모바일 OS는 애플리케이션 수준에서 발생하는 keep-alive 패킷만 개별적으로 추적하거나 관리할 수 있음, 하지만 TCP Keep-Alive는 애플리케이션 레벨 아래에서 동작하므로 때에 따라 비활성화될 수 있고, 이 와중에도 앱은 여전히 접근 가능함
Optional<T>를 반환하는 메서드가 null을 반환할 수 있음, 이런 관행은 너무 혼란스러움, 감정적으로 여유가 있다면 @java.lang.NonNullReference 같은 애노테이션을 도입하는 JEP를 냈을 것임, 이 애노테이션으로 타입을 선언하면 컴파일러가 null 할당을 에러 처리하도록 만들고 싶음, 예를 들어 Alpha는 null 할당이 가능하지만 Beta는 에러 남, javac에서도 dead code elimination이 실제로 어떻게 되는지 명세를 들여다봐야 할 것 같음, 예를 들어 if (true)에서 b = null 하는 부분은 실제로는 elided 되고, 법적으로는 허용되는 코드일 수도 있음
Kotlin에서는 이미 이런 경우가 컴파일 에러됨, 굳이 애노테이션이 없어도 됨
null이 있는 언어에서 Optional<T>를 굳이 쓸 필요가 있는지 의문임, Python에서 함수 반환값이 Optional 객체가 아닌 그냥 T | None으로 쓰는 것처럼 체크를 해야 한다면 프레임워크의 차별성이 애매함, 특별한 모나드 스타일을 쓰지 않는다면 결국 체크는 동일함
Java, C#, JS가 인메모리 스트링을 UTF-16류로 인코딩한다고 했는데 Java에는 틀림, C#, JS도 마찬가지일 수 있음, 어떤 언어든 스트링 타입이 충분히 불투명하다면 인메모리 표현 방식은 구현 세부임, Java는 9버전 이후부터 그것이 명확해짐(관련 JEP 링크), FFI가 있는 경우 구현 세부 사항 변경이 어렵기도 한 이유임, 또 JS의 수에 대해 max accurate integer가 2^53−1이라고 하는데 사실 2^100 같이 더 큰 정수도 정확히 표현할 수 있음, 2^53−1이란 건 n-1, n, n+1이 모두 IEEE double에서 정확하게 표현된다는 의미임, 따라서 n == n-1, n == n+1이 다 false로 나옴
C#은 인메모리 표현이 매우 고정되어 있음, ReadOnlySpan<char>나 raw char*로 버퍼에 직접 접근하는 경우가 많으므로 char는 UTF-16 코드포인트 타입임, JS는 어떻게든 회피할 수 있을지도 모르겠음
max accurate integer라는 표현보다는 max safe integer라는 말을 쓰고 싶음
(베이스64 인코딩 관련) Java, C#, JS의 인메모리 문자열이 UTF-16류가 아닌 것에 대해서, 기술적으로 맞을지 몰라도 만약 UTF-8 기반 언어에서 문자열을 베이스64 인코딩 후 Java에서 디코딩하면 Java의 UTF-16 표현 때문에 문제가 발생하는 사례가 있음
매뉴얼 형식의 팁이나 정보는 이미 알고 있거나 거의 알던 것만 더 이해가 빠르게 되는 것 같음, 대부분의 매뉴얼이 배움 자체보다는 정리와 복습에 효과적인데, 완전 모르는 사람들에게 가르치기엔 비효율적임
매뉴얼이란 본질적으로 기억에만 의존하지 않고 기록을 남기기 위해 존재하는 것임, 대부분의 유닉스 매뉴얼이 이런 형태임, 어떤 소프트웨어가 무엇을 하는지 이미 알지만 구체적인 사용법이 가물할 때 매뉴얼을 찾게 됨, 반면 완전 초보자가 개념을 익히려면 튜토리얼이나 가이드가 필요함, 매뉴얼은 질문을 더 잘하기 위한 준비물 같은 역할임
“Traceroute Isn’t Real” (트레이스루트는 사실이 아니다)라는 글을 정말 흥미롭게 읽었음, 그동안 트레이스루트 데이터가 매우 부정확하거나 의미 없어 보인다는 걸 체감해왔는데 그 이유를 알게 되어 도움이 됨(원문 링크), 혹시 최신 정보가 있으면 알려주면 좋겠음
이 글은 실제 함정이나 트랩이라기보다는 글쓴이가 경험적으로 배운 작은 팁들을 모아놓은 목록임, 많은 내용이 특정 좁은 맥락에만 적용될 때가 있는데 맥락이 명확하지 않고, 일부는 틀린 정보처럼 보이기도 함, 그래서 글 전체를 너무 곧이곧대로 받아들일 필요 없이 일종의 생각의 흐름이나 메모 정도로 보면 좋겠음
Python에서 기본 인자값이 매 호출 시마다 새로 생성되는 값이 아니고 저장된 값이라는 얘기, datetime 변수 쓸 때 꼭 알아둬야 할 포인트임
파이썬을 늘 쓰던 개발자는 아니었는데 이번 주에 기본 인자값이 저장된다는 이유로 고생을 참 많이 했음, set을 인자로 안 주면 빈 set을 할당하려 했는데 set이 재사용되어 버그가 났음, 이유를 파악하기까지 한참 걸림
페이지 첫 번째 “트랩”에서 min-width: auto가 콘텐츠에 따라 최소 너비가 결정된다고 했는데 flex/grid 아닌 경우엔 사실이 아님, MDN에 따르면 block, inline, table 등에서는 auto가 0으로 보정됨(공식 문서 링크)
진짜 첫 번째 트랩은 “어떤 CSS 속성이든 격리해서 읽지 못한다”임, 속성명 그대로 cascading(계단식 상속)이라는 이름처럼 기본값과 여러 규칙의 결과가 어디에선가 합쳐지니까 문서 전체 맥락이 중요함
CSS 텍스트 속성 쪽 cascade(상속)는 그나마 이해가 됨, 하지만 CSS 레이아웃은 페이지 디자이너, 구현자, 사용자, 어떤 관점에서도 이해가 너무 어려움, 도대체 누구를 위한 디자인인지 공감이 안 됨
전반적으로 괜찮은 리스트글임, 몇 가지 의견 있음.
유니코드 통합 관련해서, 여러 언어에서 같은 의미의 글자가 같은 코드포인트를 쓰고, 글꼴에 따라 다르게 표시된다는 건 트랩이 아님, 주어진 예시 같은 한자는 중일 양쪽에서 거의 동일하게 쓰이고, 두 언어 사용자 모두 다른 변형도 같은 개념의 글자로 인식함, 글쓴이는 ‘A’ 철자를 영어와 프랑스어에서 각각 다르게 정의해야 하는 것처럼 말하고 있음, 실제로는 그렇지 않음, Han unification 항목 참고
-0.0과 +0.0(음수 0, 양수 0)은 플로팅 포인트 비교에서 같게 취급되지만 구분하는 방법이 있음, 각각 비트 패턴이나 1.0/-0.0 = -무한대, 1.0/0.0 = +무한대인 결과로 확인 가능함
서버 타임존 추천을 UTC로 맞추라는 조언 매우 공감됨, 서버, 로그, 사진 저장 등 보존 가치가 있거나 정확한 타임스탬프가 필요한 모든 곳에 UTC 사용, 로컬타임은 대화에만 쓸 것임
정수에서 (low + high) / 2는 오버플로우 위험이 있으니 low + (high - low) / 2를 쓰라고 했는데, low나 high가 음수일 수 있으면 오버플로우 범위를 옮기는 것일 수 있음, 일반적인 이진 탐색에서 중요한 이슈임
rebase가 history를 바꿀 수 있다고 했는데, rebase란 그 자체로 history를 rewrite하는 command임
두 언어 사용자 모두 개념적으로는 같은 글자를 인식하지만, 단순히 “폰트 변형” 정도로 치부하면 안 됨, 유니코드 코드포인트가 같다고 안전하게 문자 치환이 되지는 않음, 일본 사용자 입장에서는 이런 치환이 제품 사용 거부 원인이 될 수도 있음
사실 영어 A, 프랑스어 A는 구분하지 않지만, А(키릴 문자)와 A(라틴 문자) 같이 겉모습이 같아도 실제 다른 코드포인트로 존재함, Han 통합도 외형이 꽤 다른 글자를 하나로 묶는 경우가 많아서 일본어나 중국어 학습자라면 실제로 혼란을 겪을 수 있음, 예를 들어 '喝'(drink) 글자는 링크처럼 보기에 따라 상당히 다르게 나옴, 복사해보면 심지어 바로바로 형태가 바뀔 정도로 처리 방식이 복잡함, Han unification은 현실적으로 상당히 골치아픈 주제임
numpy와 pytorch 사이에 미묘한 차이가 있다고 언급했지만, 구체적인 사례 설명 없이는 별로 유용하지 않고 정보도 부족해서 현실적인 함정이라고 느껴지지 않음
Hacker News 의견
일부 라우터와 방화벽이 애플리케이션에 아무런 신호도 주지 않고 유휴 TCP 연결을 조용히 끊어버리는 경우가 있음, HTTP 클라이언트 라이브러리나 데이터베이스 클라이언트와 같이 TCP 커넥션 풀을 유지하는 코드는 이로 인해 연결이 아무 경고 없이 무효화되는 문제를 경험함, 이를 해결하려면 시스템 TCP keepalive를 설정하거나 HTTP라면 Connection: keep-alive, Keep-Alive: timeout=30, max=1000 헤더를 사용할 수 있음, TCP 커넥션이 한번 연결되면 중간 라우터에는 상태가 남지 않음, 문제는 방화벽이나 NAT 세션 타임아웃임, 이때 RST 패킷도 오지 않음, K8s 환경에서는 conntrack 모듈 설정이 너무 낮았던 문제를 겪었음, HTTP Keep-Alive를 써봐도 연결 재사용에만 효과 있고 네트워크 상의 연결을 유지하진 않음(설명 링크), HTTP Keep-Alive는 실제로 패킷을 발생하지 않고 단지 종료를 미룰 뿐임, 반면 TCP Keep-Alive는 패킷을 주기적으로 발생시켜 타이머를 리셋해줌
Optional<T>를 반환하는 메서드가 null을 반환할 수 있음, 이런 관행은 너무 혼란스러움, 감정적으로 여유가 있다면 @java.lang.NonNullReference 같은 애노테이션을 도입하는 JEP를 냈을 것임, 이 애노테이션으로 타입을 선언하면 컴파일러가 null 할당을 에러 처리하도록 만들고 싶음, 예를 들어 Alpha는 null 할당이 가능하지만 Beta는 에러 남, javac에서도 dead code elimination이 실제로 어떻게 되는지 명세를 들여다봐야 할 것 같음, 예를 들어 if (true)에서 b = null 하는 부분은 실제로는 elided 되고, 법적으로는 허용되는 코드일 수도 있음
Kotlin에서는 이미 이런 경우가 컴파일 에러됨, 굳이 애노테이션이 없어도 됨
null이 있는 언어에서 Optional<T>를 굳이 쓸 필요가 있는지 의문임, Python에서 함수 반환값이 Optional 객체가 아닌 그냥 T | None으로 쓰는 것처럼 체크를 해야 한다면 프레임워크의 차별성이 애매함, 특별한 모나드 스타일을 쓰지 않는다면 결국 체크는 동일함
Java, C#, JS가 인메모리 스트링을 UTF-16류로 인코딩한다고 했는데 Java에는 틀림, C#, JS도 마찬가지일 수 있음, 어떤 언어든 스트링 타입이 충분히 불투명하다면 인메모리 표현 방식은 구현 세부임, Java는 9버전 이후부터 그것이 명확해짐(관련 JEP 링크), FFI가 있는 경우 구현 세부 사항 변경이 어렵기도 한 이유임, 또 JS의 수에 대해 max accurate integer가 2^53−1이라고 하는데 사실 2^100 같이 더 큰 정수도 정확히 표현할 수 있음, 2^53−1이란 건 n-1, n, n+1이 모두 IEEE double에서 정확하게 표현된다는 의미임, 따라서 n == n-1, n == n+1이 다 false로 나옴
C#은 인메모리 표현이 매우 고정되어 있음, ReadOnlySpan<char>나 raw char*로 버퍼에 직접 접근하는 경우가 많으므로 char는 UTF-16 코드포인트 타입임, JS는 어떻게든 회피할 수 있을지도 모르겠음
max accurate integer라는 표현보다는 max safe integer라는 말을 쓰고 싶음
(베이스64 인코딩 관련) Java, C#, JS의 인메모리 문자열이 UTF-16류가 아닌 것에 대해서, 기술적으로 맞을지 몰라도 만약 UTF-8 기반 언어에서 문자열을 베이스64 인코딩 후 Java에서 디코딩하면 Java의 UTF-16 표현 때문에 문제가 발생하는 사례가 있음
매뉴얼 형식의 팁이나 정보는 이미 알고 있거나 거의 알던 것만 더 이해가 빠르게 되는 것 같음, 대부분의 매뉴얼이 배움 자체보다는 정리와 복습에 효과적인데, 완전 모르는 사람들에게 가르치기엔 비효율적임
“Traceroute Isn’t Real” (트레이스루트는 사실이 아니다)라는 글을 정말 흥미롭게 읽었음, 그동안 트레이스루트 데이터가 매우 부정확하거나 의미 없어 보인다는 걸 체감해왔는데 그 이유를 알게 되어 도움이 됨(원문 링크), 혹시 최신 정보가 있으면 알려주면 좋겠음
이 글은 실제 함정이나 트랩이라기보다는 글쓴이가 경험적으로 배운 작은 팁들을 모아놓은 목록임, 많은 내용이 특정 좁은 맥락에만 적용될 때가 있는데 맥락이 명확하지 않고, 일부는 틀린 정보처럼 보이기도 함, 그래서 글 전체를 너무 곧이곧대로 받아들일 필요 없이 일종의 생각의 흐름이나 메모 정도로 보면 좋겠음
Python에서 기본 인자값이 매 호출 시마다 새로 생성되는 값이 아니고 저장된 값이라는 얘기, datetime 변수 쓸 때 꼭 알아둬야 할 포인트임
페이지 첫 번째 “트랩”에서 min-width: auto가 콘텐츠에 따라 최소 너비가 결정된다고 했는데 flex/grid 아닌 경우엔 사실이 아님, MDN에 따르면 block, inline, table 등에서는 auto가 0으로 보정됨(공식 문서 링크)
진짜 첫 번째 트랩은 “어떤 CSS 속성이든 격리해서 읽지 못한다”임, 속성명 그대로 cascading(계단식 상속)이라는 이름처럼 기본값과 여러 규칙의 결과가 어디에선가 합쳐지니까 문서 전체 맥락이 중요함
CSS 텍스트 속성 쪽 cascade(상속)는 그나마 이해가 됨, 하지만 CSS 레이아웃은 페이지 디자이너, 구현자, 사용자, 어떤 관점에서도 이해가 너무 어려움, 도대체 누구를 위한 디자인인지 공감이 안 됨
전반적으로 괜찮은 리스트글임, 몇 가지 의견 있음.
두 언어 사용자 모두 개념적으로는 같은 글자를 인식하지만, 단순히 “폰트 변형” 정도로 치부하면 안 됨, 유니코드 코드포인트가 같다고 안전하게 문자 치환이 되지는 않음, 일본 사용자 입장에서는 이런 치환이 제품 사용 거부 원인이 될 수도 있음
사실 영어 A, 프랑스어 A는 구분하지 않지만, А(키릴 문자)와 A(라틴 문자) 같이 겉모습이 같아도 실제 다른 코드포인트로 존재함, Han 통합도 외형이 꽤 다른 글자를 하나로 묶는 경우가 많아서 일본어나 중국어 학습자라면 실제로 혼란을 겪을 수 있음, 예를 들어 '喝'(drink) 글자는 링크처럼 보기에 따라 상당히 다르게 나옴, 복사해보면 심지어 바로바로 형태가 바뀔 정도로 처리 방식이 복잡함, Han unification은 현실적으로 상당히 골치아픈 주제임
numpy와 pytorch 사이에 미묘한 차이가 있다고 언급했지만, 구체적인 사례 설명 없이는 별로 유용하지 않고 정보도 부족해서 현실적인 함정이라고 느껴지지 않음