2019년 3월 22일 금요일

유니버설 랭귀지 - 박문호의 자연과학 세상

수학



함께 자라기 - 김창준

초록색 표지. 함께 잘하기가 아니라 함께 자라기.

지난 주에 읽은 후 아직도 생각나는 것은, 결국 모든 것은 사람에게서 시작한다는 것.


2019년 2월 8일 금요일

한겨울의 자전거 라이딩

잠시 사무실에 다녀올 일이 생겼다. 자전거를 타고 가보자며, 단단히 챙긴다. 마스크를 두 겹으로 쓰고, 장갑도 두 개를 끼고, 두꺼운 점퍼를 입고 나섰다. 사무실까지는 자전거로 15분 거리. 그리 멀지 않아서 봄 가을에는 분당까지 올라갔다가 돌아서 사무실에 가기도 한다.

달리다 보니, 다리가 춥다. 발도 춥다. 손은 조금 시리지만 견딜만 하다.

사무실에서 잠시 은행 일을 보고, 다시 집으로 출발하려는데, 샤오미 치 사이클 배터리가 30% 정도 밖에 없다. 사무실에 도착하고 바로 배터리를 연결해놨어야 하는데, 깜빡 잊었네. 10분 정도 충전을 하고, 배터리도 챙겨서 집으로 출발.

오후 5시 30분을 넘으니 아까 보다 더 춥다. 다리와 신발쪽만 좀더 보강하면 겨울에도 자전거로 사무실 왕복을 할 수 있을 것 같다. 갈 때와 달리 올 때는 계속 오르막이라 전기 자전거임에도 숨이 차고 덥다.

아침에 수영장에서도 약간 감기 기운이 있더니, 좀더 진행이 되는 것 같아서 얼른 생강차를 한 잔 마신다. 수영장에서의 감기 기운은 평소에도 가끔 생길 때가 있다. 뜨거운 탕에 몸을 한참 담그고 있으면 괜찮아 지는데, 오늘은 그러지 않고 집에 돌아 왔더니 감기 기운이 조금 남은데다, 찬 바람을 맞으며 자전거를 타고 다녀와서 그런가 보다.


2019년 2월 2일 토요일

퍼니셔 시즌 2

러시아 거물의 집 안에서 총소리가 나고
존이 아들 둘을 차에 태우고 운전석에 오르고
캐슬은 에이미를 데리고 떠나는
그 장면을 위해 봄부터 소쩍새는.

광풍(Whirlwind)은 캐슬의 그바닥 예명인가?

2019년 2월 1일 금요일

나도 사보는 QCY T1

지난 1월 12일에 주문을 해서 1월 30일에 도착했다.

첫인상은, 무척 가볍다는 것. 처음에는 귀에 끼우는 방향을 몰라서 좌우가 맞나 헷갈렸다.

음질은 역시나 그간 봐왔던 평가들처럼 저음이 많고 뭉게지는 경향이 있다. 폼팁으로 바꾸면 많이 나아진다고 해서 TB400을 주문하려고 한다.

문제는 오디오 딜레이.



공이 아래에 떨어져서 좌에서 우로 움직이는 막대에 닿는 시점에 소리가 나지 않고
대략 0.2초 정도의 딜레이가 있다.

에어팟과 오디오테크니카 블루투스 헤드폰으로 테스트를 해보면 공이 막대에 닿는 순간 소리가 들린다.

팟캐스트나 오디오 전용으로 사용한다면, 에어팟 가격의 10분의 1로 이정도 품질이면 쓸만하다는 결론.

2019년 1월 30일 수요일

Multiple server instance 환경에서 form double submit을 server에서 검출하기

Client쪽에서 form의 submit이 중복되지 않도록 막는 방법은 여러가지가 알려져 있다. 모두 JavaScript에서 처리하는 방법들이고, 다양한 질문과 답변들을 찾아보면 개념적으로는 몇가지로 수렴한다.

다중 Server에서 form의 중복 submit을 검출하는 방법은 별로 쓸만한 것을 찾지 못했다.

Server instance가 여러 개이기 때문에 상태를 저장하기 위해 DB 등 외부의 node를 사용해야 한다. Form에 uuid 등 중복되지 않는 키를 할당하고 해당 키에 대해서 트랜잭션이 이미 발생했는지 여부를 DB에 query를 해서 확인하는 방식이다. 그런데, 이 방법은 불필요한 DB transaction이 발생하고, 일정 시간이 지난 후 불필요한 레코드들을 정리해야 해서 귀찮다.

Form이 submit되었을 때 uuid를 키로 사용해서 redis 또는 memcached에 item을 하나 생성해 놓는 것은 좀더 가벼운 해결책이 될 것 같다. 일정 시간이 지나면 cache item은 자동 정리가 되기 때문에 귀찮게 정리해줘야 할 일도 없다.

문제는, cache에 기록하는 작업이 끝나기 전에 cache를 읽으려고 할 때 발생. 두번의 form submit이 발생하는 사이 동일한 시간 간격으로 cache에 접근하려고 할텐데, overlap이 발생하면 중복된 submit을 알아챌 수 없다. django-lock-tokens같은 프로젝트는 resource에 대한 lock을 하는 방식. 그런데, 마찬가지의 문제가 있을 것 같다.

좋은 방법이 없을까?

How to manage concurrency in Django models를 보면 select_for_update를 사용해서 transaction이 끝날 때까지 lock을 하는 (pessimistic) 방법이 나온다.

우리가 사용하는 cache backend는 Redis이니 Distributed locks with Redis에서 제공하는 방법도 좋을 것 같다.