이상욱

2020년 회고

2021-01-01T00:00:01+09:00

2020년 1년을 돌아보며.
2020년은 평생 잊지 못할 것 같다.
- COVID-19 때문에 생활이 크게 변했다.
- 내년 회고에는 해결되어 있겠지?
경제적 자유를 달성했다는 확신이 생겼다.
- 몇 년 동안 운인가? 괜찮나? 를 고민했는데.
- 이제는 확실해졌다.
- 좀 더 일찍 확신이 들었다면 좋았겠지만, 운명이다.
- 이후로 세계관이 많이 바뀌었는데.
- 가장 좋은 것은 이기적인 타인에게도 관대해질 수 있다는 점이다.
월세로 전환하기로 했고, 실행했다.
- 나는 엉덩이가 아주 무거운 성격인데.
- 그런 나도 움직이게 하는 압도적인 장점이 보여서 실행했다.
- 그래서 연말에 이사했고, 매우 만족하고 있다.
  - 진작 실행했으면 좋았을걸, 나는 고민이 너무 많다.
배워서 쓸모있는 것이 무엇이었을까?
- 라는 생각을 많이 해보고, 이건 자주 바뀌는데.
- 요즘의 생각은. 통계, 프로그래밍, 영어, 운전 순서로 쓸모있는 것 같다.
회사.
- COVID-19 pandemic 때문에 거의 1년 내내 재택근무를 했다.
  - 정확히는 2월말부터.
- 회사에서 했던 일을 요약하자면.
- 클라우드 플랫폼을 만드는 일을 했다.
- 구름 너머에는 k8s, golang, knative, istio, helm, envoy 같은 것들이 있는데.
- 공개적으로는 정확히 쓸 수 없을 것 같아서 이만 생략. (사실 귀찮다)
운전.
- 월평균 1172km 를 운전했다.
- 출퇴근도 안 했는데 왜 이렇게 많이 운전한 걸까.
건강.
- 몸무게가 15년 최고치를 경신했다.
- 재택근무는 살이 찌기 좋은 환경이다.
본 것.
- 영화 드라마 중에 생각나는 것들은.
  - 1917, 나이브스 아웃, 테넷, 소리도 없이, 콰이어트 플레이스, 나르코스, 나르코스 멕시코, 런, 800, 21
  - 가장 재밌게 본건 1917.
- 웹툰 중에 생각나는 것은.
  - 후기, 별종, 헬58, 도망자, 행성인간, 초인의 시대, 호랑이형님, 더 복서, 고수, 체크포인트, 헌팅, 피와 살, 수평선, 라스트 서브미션
  - 가장 생각나는 건 수평선.
- 인터넷 방송 중에 재밌게 본 것은
  - 침착맨 삼국지 https://www.youtube.com/watch?v=4k48gvdAsFY
  - 배도라지 25시간 MT https://www.youtube.com/watch?v=TtnGyAayM2Y
  - 풍월량님의 데이 바이 데이라이트 방송 이었던 것 같다.
  - 주로 침착맨님 또는 풍월량님의 방송을 많이 봤던 것 같고.
  - 특히 침착맨 삼국지는 어렸을 때 삼국지 영걸전을 밤새 하고 책을 몇 번씩 읽었던 비슷한 세대라 공감 시너지가 났다.
요즘 많이 생각하는 것은, 거의 모든 것은 취향이라는 점이다.
- 휴지를 앞으로 놓는 것도, 뒤로 놓는 것도.
- 글에 ㅋㅋㅋ 를 쓰는 것도, !!! 를 쓰는 것도.
- 대답에 네, 예, 넵, 넹을 쓰는 것도.
- 어떤 종교를 믿는 것도, 믿지 않는 것도.
- 정치 성향이 좌파인 것도 우파인 것도.
- 아침형 인간도, 저녁형 인간도.
- 담배나 술을 좋아하는 것도, 누구를 지지하거나, 누구를 좋아하는 것도.
- space를 쓰는 것도 tab을 쓰는 것도.
- 좋은 코드라고 하는 것도, 코드 리뷰를 하는 것도 사실은 대부분.
- 모두가 취향이다.
- 사람들은 자기 취향이 옳고 남의 취향은 틀렸다고 생각한다.
- 그렇게 죽을 때까지 자신이 옳고 남은 틀렸다고 생각하면서 살아간다.
- 타인의 취향을 존중해 주는 자세로 대화를 한다면.
- 화 내는 일도, 싸움도, 자살 테러도, 전쟁도 줄지 않을까.
- 남에게 화 낼 일이 사실은 거의 없다.
- 왜냐하면 대부분은 취향의 문제니까.
2021년에는 COVID-19 시국이 해결되고, 일상생활을 할 수 있기를.
2022년 1월에 계속.

2019년 회고

2020-01-01T00:00:01+09:00

2019년.
시장이 아주 좋았다.
벤치마크가 16% 정도 올랐다.
세계 자본주의 자산시장이 이정도 팽창했다는 의미고,
사놓고 가만히 있어도 이정도 수익률을 평균적으로 달성했다는 의미다.
BM과 유사한 패시브로 8억 넣고 2억을 번 A님을 보며 허탈감이 들기도 했다.
그만큼 2019년은 시장이 좋았다.
올해 읽은 책들과 논문을 돌아봤다.
논문을 읽는데 많은 시간을 보냈다고 생각했지만.
사실 1개의 논문을 수십번 이상. 어쩌면 수백번? 읽은 것 같다.
올해 읽은 논문과 책을 세면 한 손으로 셀 수 있겠지.
아직 알고 싶은게 많다.
모르는게 너무 많다.
시간이 얼마나 지나야 운인지 아닌지 확신이 들고, 더이상 공부할게 없다는 생각이 들까.
부동산은 이번 주기에는 기다릴 생각이다.
나를 두고 버스가 떠날것 같은 기분은 고점 신호일 확률이 높다.
자본주의는 인간은 이기적이다 라는 axiom을 기반으로 만들어진 시스템이다.
인간 본성을 기반으로 한 시스템은 장기간 유효하다.
SNS/뉴스를 보지 않기로 정한 후로 시간이 많아졌다.
의미 있다고 생각하는 일에 시간을 쓰려고 노력했다.
노동수익을 자본수익으로 전환하는 문제에 시간을 쓰는게 의미가 있다.
사람들은 의미없어 보이는 일에 에너지를 쓴다는 생각이 들었다.
올해 가장 재밌게 본 영화도 기생충인데.
사람들은 같은 계급의 사람들과 싸우고.
지하철 타는 사람들끼리 싸우고.
버스가 늦게 온다며 버스 기사에게 폭언을 한다.
- https://news.v.daum.net/v/20191213210813280
회사에서는 직원들끼리 (자본가를 대신해) 자발적으로 서로를 견제하고.
- 최소한의 임금으로 최대한의 노동을 시키기 위해 연구한 제도가 HR이고.
- 출퇴근, 직급, 평가 등의 다양한 시스템이 자본가를 위해 만들어졌다.
- 이 또한 본성을 기반으로 하기에 영원하겠지.
악플은 흔히 볼 수 있고.
악플과 동일한 심리에서 나오는 특정 대상을 향한 비난도 SNS에서 흔하다.
악플을 비난하는 이 문장도 일종의 악플이고 악플러와 같은 심리인가? 이런!
여기까지 가면 다 의미 없구나 하는 결론에 이른다.
사람들은 자신의 상황이 안 좋아서, 마음이 좁아져 있고, 그래서 남에게 엄격한 걸까.
빈부격차가 좁아지면 남에게 관대한 사람이 다수가 될까.
덴마는 실망스럽게 완결이 될 것 같다.
- https://comic.naver.com/webtoon/list.nhn?titleId=119874
영원한 빛은 완결을 했다.
- http://webtoon.daum.net/webtoon/view/eternallight2
- 첫 화가 나왔을 때 부터 재밌게 봤는데 아쉽다.
- 내가 본 최고의 웹툰 중 하나로 남을 것 같다.
회사에서는 kubernetes 업무를 했고, 내년에는 여전히 k8s 관련 일 이긴 하지만 조금은 다른 일을 할 예정이다.
- 이건 2020년 회고에서 뭘 했는지 요약해 보는 걸로.
그럼 2021년 1월에 다시. 그때는 확신이 들었길.

근황 (2018년 회고)

2019-03-23T22:28:55+09:00

2018년이 끝났고, 2019년이 왔다.
- 원래는 2018년 회고를 남기고 싶었다.
- 작년에 스페인에 다녀온 이야기나.
- 생각의 큰 변화에 대해 남겨놓고 싶었다.
- 하지만 결국 생각만으로 끝났다.
돌아보니 1년 전, 2년 전에는 지금을 상상할 수 없었다.
- 지금도 1년 후, 2년 후의 나를 상상할 수 없겠지.
- 1년에 한 번이라도 큰 사건이나 감정을 남기는 것이 미래의 나에게 도움이 되는 것 같다.
- 너무 귀찮지만 1년에 한번정도는 할 수 있을 것 같다.
새해 다짐으로 월 단위로 결산을 하고 있다.
- 가볍게 아래 블로그에 남기고 있다.
  - https://blog.naver.com/yiisw
- 남기고 보니 여러가지 장점이 있다.
- 귀찮아 질때까진 최대한 써봐야지.
지금 이 글도 부담가지지 않고 생각나는데로 한번에 쭉 써야지.
- 생각나는 근황은 일단.
- SNS를 안 하기로 했다.
- 뉴스도 잘 안 보고 있다.
  - (물론 특정 분야의 뉴스는 많이 읽는다.)
- 어느날 갑자기 SNS와 뉴스에 시간을 쓰는것이 무의미하다는 생각이 들었다.
- ‘이게 나에게 의미가 있나?’ 하는 질문을 많이 하게 된것 같다.
- 뉴스는 잘 안 보게 됐지만.
최근에 있었던 FOMC회의 같은건 휴가도 내고 관련 글들을 읽을 정도로 관심이 많다.
- 아주 중요한 신호가 나왔는데.
- 한국 채권시장과, 미국 채권시장은 이것을 미리 반영했다고 생각했지만.
- 발표 이후 더 급하게 움직였다.
- 그리고 올해 9월이 아주 중요한 시점이 됐다.
몇년동안은 특정 분야의 페이퍼를 많이 읽었다.
- 내 전공이 아니기 때문에 하나의 글을 읽기위한 사전지식이 계속 필요했다.
- 어렵게 끝까지 읽고 이해하게 되면 결론은 단순한 경우가 많다.
생각해보면 내가 지금 하고 있는 일이
- 무언가를 계속해서 단순하게 만들고
- 신호를 증폭하고
- 잡음을 줄이는 일
- 로 요약할 수 있는 것 같다.
느낀점 하나는 수학적인 기반에서 오는 심리적인 안정감이 매우 크다는 점.
그리고 이 분야, 아니 모든 분야에서
- 편견을 제거하고 남탓 또는 상황탓을 안 하는게 중요한 것 같다.
- 그래야 더 고민할 수 있게 되고 합리화로 고민을 중단시키는 일이 없어진다.
- 편견과 남탓은 인간의 본능이고 흔히 볼 수 있다.
- 당연하다.
- 그것이 있기 때문에 인간은 멘탈을 유지하고 살아갈 수 있는 거겠지.
매년 년초가 되면 내 멘탈을 흔드는 일이 있는데.
- 매번 처음엔 멍한 상태로 있다가 시간이 지나면 회복되어 왔다.
- 올해는 아직까지 회복이 안 될정도로 상처가 크다.
- 좀 더 시간이 필요한 것 같다.
아버지가 아프셨고, 개인사가 있었다.
- 지금 아버지는 퇴원하셨고 큰 일이 다행히 지나가고 있는 것 같다.
- 건강은 가장 중요한 일이다.
2019년에 글을 썼으니 이제 1년뒤에.. 그럼 20000 =3=3=3

쿠버네티스 코드 읽기

2018-06-19T22:26:00+09:00

요즘은 kubernetes(이하 k8s) 소스 코드를 읽고 있다.
디자인이 단순하기 때문에 비교적 읽기 어렵지 않다.
그래서 이렇게 인기를 얻는 것이겠지.
디자인이 단순해진 것은 etcd의 기능 덕분이라고 생각한다.
- k8s는 etcd를 task-queue처럼 사용한다.
- mesos는 zookeeper를 사용하는데, 이 선택이 큰 차이를 만드는게 아닐까.
오래전에 분석할땐 “미니언”이라는 용어를 사용하더니 “노드”로 변경했다.
- “노드”로 선택한 덕분에 미니언이 뭐하는 것인지 추가 설명이 필요없다.
- 변경한 시점에 나온 이름 후보들을 보니(Koupi, Rower, Krew)
  - https://github.com/kubernetes/kubernetes/issues/1111
- “항해”에 비유하고 싶은 욕망이 강했나 보다.
- 하지만 비유나 추상화 보단, 구체적인 용어가 좋다.

쿠버네티스를 소스에서 빌드

나는 내가 쓰는 솔루션은 직접 빌드해서 쓰는걸 좋아한다.
- (물론 내 개발용도에만)
예를 들면, mysql을 많이 쓰니 (코드 수정을 해서) 직접 빌드해서 쓰는 식이다.
그리고 문서를 읽기 보다는
코드를 읽고, 로그를 찍고, 돌려본다.
그러면 아주 많은 장점이 있는데, 아마 해본 사람만 느끼리라.
- 리눅스 데스크탑을 운영체제로 쓰는 장점,
- vim을 사용하는 것의 장점이 매우 크다고 생각하는데
- 막상 이유를 설명해보라고 하면 어렵다.
- (사실 장점을 얻기 위해선 수많은 문제를 스스로 해결해야 하기도 하고)
나같은 이상한 사람을 아직 본적이 없었다.
회사에서 점심먹고 산책하다가 yan도 비슷한 (악)취미가 있다는 것을 알았다.
- vim 덕후로 수렴한 사람들은 비슷한 길을 걷는걸까
아무튼 k8s도 궁금한 부분에 대해 로깅을 추가해서 빌드하고
- 내가 빌드한 버전으로 하나씩 갈아끼우는 일을 하고있다.
우선 나같은 생각을 한 사람이라면 높은 확률로 kubectl수정을 시작할 것이다.

`kubectl` 빌드

빌드 스크립트를 따라가 보면 cmd/kubectl을 빌드하는 것을 알 수 있다.
빌드를 아무생각 없이 일단 해보면, 1시간 정도 걸린다.

결과는 아래의 바이너리들이 만들어진다.

-rwxr-xr-x 1 sangwook sangwook 201M  6월 11 22:39 kube-apiserver
-rwxr-xr-x 1 sangwook sangwook  65M  6월 11 22:40 kubectl
-rwxr-xr-x 1 sangwook sangwook 141M  6월 11 22:39 kubelet
...

코드를 고칠때마다 빌드에 1시간을 기다렸다.
- 나는 쿠알못이기 때문에 모르면 이정도는 참아야 한다.
- 빌드 스크립트를 파는게 목적이 아니니.
그러다가 도저히 참지 못하고
- 시간을 내서 빌드 스크립트를 읽었다.
- 결과적으로 빌드에 9분-10분 정도 걸리도록 시간을 줄였다.
- 이것도 느려서 못참겠지만, 더 빠르게 하는건 다음에 시간이 남을때 하자.
하지만 또 10분씩 기다리는걸 참지 못하고.
- 빌드 스크립트를 좀 더 자세히 봤다.
- 테스트 코드를 돌리지 않도록 하는 옵션이 예전에 있었던것 같은데.
- 지금은 그 옵션이 동작하지 않는다.
- 일단 10분 기다리는걸 참는걸로..
kubespray에서 kubectl, kubelet의 업데이트는.
- hyperkube이미지의 kubectl과 호스트의 kubectl을 바이트 비교후
- 다르면 복사한다.
- https://github.com/sangwook/kubespray/blob/3d6fd491795adb8a38493afe6c2968a46051d5ff/roles/kubernetes/master/tasks/main.yml#L32
내가 빌드한 kubectl을 사용하도록 바이너리 경로를 변경하고.
- 클러스터의 config를 ~/.kube/sangwook-cluster.conf 로 복사하고.
- KUBECONFIG 에 config 경로를 지정하고
- kubectl 명령을 하면서 테스트하면 된다.

`apiserver` 빌드

별거 없다.
apiserver는 다커 이미지만 만들어서, 이미지 주소를 변경만 하면.
- (apiserver는 static-pod로 정의되어 있기 때문에)
- manifest가 즉시 적용된다.
다커 이미지를 만드는 것은 수 초 밖에 안 걸린다. (hyperkube 하나만 하면 10초 정도)

자주 수정하고 빌드하고 다커 이미지 만들고 하다보면

내가 방금 빌드한 버전으로 돌아가고 있는지 궁금할때가 있는데. (제대로 배포했나?)

빌드한 서버에서 docker images --digests 를 해서 digest sha256 값을 확인하고.

REPOSITORY               TAG                    DIGEST                                                                  IMAGE ID     CREATED        SIZE
sangwook/hyperkube-amd64 v1.9.5-sangwook-custom sha256:71d332a5b8cdb21329b9ca75c5aae454fa3d60c8a87b6088aaeee1720a8850f4 944446664a2b 32 minutes ago 619MB

apiserver를 배포한 서버에서 나오는 digest sha256이 일치하는지 확인하면 된다. (IMAGE ID가 아니라는게 핵심)

CONTAINER ID IMAGE                                                                                             COMMAND               CREATED        STATUS
0b11ac196ea3 sangwook/hyperkube-amd64@sha256:71d332a5b8cdb21329b9ca75c5aae454fa3d60c8a87b6088aaeee1720a8850f4 "/hyperkube apiser..." 13 minutes ago Up 13 minutes

`etcd`에 업데이트

etcd와 통신하는 로직이 궁금하여 따라가다 보면.
코드를 따라가다가 스택을 자주 확인해야 하고,
- 스택에 해당하는 코드로 쉽게 이동해야 한다.
- 그것 때문에 아래와 같은 vim 플러그인을 만들어서 쓰고 있다.

처음엔 kubectl get pods 같은 get 로직을 따라 갔었는데.
- 기억에 남을만한 특별한 로직이 없었다.
etcd 변경이 필요한. 예를 들면, service의 nodePort를 kubectl로 변경하면.
- 변경한 spec의 셀렉터와 변경후의 값만 request body로 해서
- PATCH 메소드의 요청을 한다. (apiserver에)
- apiserver가 요청을 받아서, etcd에 업데이트 한다.
코드를 보다보면 etcd를 덤프해서 전후를 diff 하는 일을 반복적으로 하게된다.
- 덤프하는 올바른 방법을 몰라서
- key목록을 가져오고 하나씩 get하는 스크립트를 만들어야 했다.
- (하지만 분명 더 좋은 방법이 있겠지.)
- [EDIT] 지금은 etcd 값이 변경되면 메시지를 받도록 k8s를 변경했는데, 이게 훨씬 편했다.

etcd로 저장하는 로직에서 재밌게 본 코드들.
- https://github.com/sangwook/kubernetes/blob/f01a2bf98249a4db383560443a59bed0c13575df/staging/src/k8s.io/apiserver/pkg/endpoints/handlers/update.go#L101-L107
  - 리소스 업데이트는 모두 이 거대한 메소드 안으로 들어온다.
- https://github.com/sangwook/kubernetes/blob/f01a2bf98249a4db383560443a59bed0c13575df/staging/src/k8s.io/apiserver/pkg/endpoints/handlers/rest.go#L182-L186
- https://github.com/sangwook/kubernetes/blob/f01a2bf98249a4db383560443a59bed0c13575df/staging/src/k8s.io/apiserver/pkg/storage/etcd3/store.go#L263
  - etcd 업데이트를 끝까지 따라가면 여기까지 온다.
사실 저장하는 것 보다는, notify/watch 하는 부분이 핵심이다.
그리고 apiserver와 scheduler 사이의 통신하는 로직이나
apiserver와 kubelet 사이의 통신하는 로직이나
kubectl create -f xxx.yaml 로 Service를 nodePort로 생성할때.
- services, endpoints 각각 총 2번의 POST를 날리고.
- iptables를 변경하는 로직
등등등의 로직이 재밌었는데.
이걸 다 여기다 정리하려니 힘들고, 나같은 마이너 취향이 없을거 같아서.
일단 여기까지.

스탠딩 데스크

2018-01-03T23:55:00+09:00

스탠딩 데스크, 정확히는 일룸 데스커에서 만든 모션 데스크 [1] 를 샀다.
이제 한 달 넘게 사용했다.
정창훈님의 유튜브 리뷰[2] 를 재밌게 봤고, 너무 무거울까 싶어 망설였다.
그러다가 우연히 김재현님을 만났는데, 재현님이 강력히 추천하셔서 주문했다.
- 당근마켓은 모두 스탠딩 데스크를 사용하는 것 같다. [3]
지금 내가 일하는 회사는 이사할 때 불편하다는 이유로 전동 스탠딩 데스크는 사용하지 않는다.
- 대신 회사에서는 베리데스크를 사용하고 있다.
베리데스크의 단점은
- 높이를 미세하게 조정할 수 없다.
- 내 눈높이에 맞춰, 베리데스크를 가장 높게 조절하면
- 키보드의 높이는 너무 낮게 위치한다.
- 그래서 오래 사용하니 손목이 아파 병원에 다녀왔다.
- 원인은 베리데스크였고, 서서 일할땐 키보드/마우스 밑에 받침을 두고 해야 아프지 않았다.
일룸데스커 모션데스크는 대만족 중이다.
- 책상 높이를 미세하게 조절할 수 있다.
- 어차피 나 혼자 쓰니까 일정한 위치에서 쓰고 있겠지만.
- 나는 40분 앉아있고, 20분 서 있는 것을 반복한다.
- 이렇게 자주 오르 내릴때는 버튼을 누르고 있으면서 높이를 조절하는게 약간 불편하기도 하다.
- 7만원을 더 내면 앱으로 높이를 기억해서 조정해주는 기능이 있는 것 같다. (스마트컨트롤 옵션)
  - 아주 편할것 같긴 한데, 7만원이나…?
40분 앉고, 20분 서는 타이머를 위해 아래의 스크립트를 만들어 쓰고 있다.

#!/usr/bin/env ruby
raise unless /linux/ =~ RUBY_PLATFORM
require 'libnotify'
require 'timers'
raise if ARGV.empty?
timeout_min = ARGV[0].to_i
timers = Timers::Group.new
min = 0
timers.now_and_every(60) do
  min += 1
  puts "#{Time.now.strftime('%Y-%m-%d %H:%M')} #{min}"
  system "tmux rename-window -t${TMUX_PANE} '#{min}'" if ENV.key? 'TMUX'
  if min > timeout_min
    Libnotify.show summary: 'timeout'
    exit 0
  end
end
loop { timers.wait }

shell에서 40 을 입력하면 40분 후에 timeout 알림창이 뜨고
20 을 입력하면 20분 후에 timeout 알림창이 뜨도록 설정했다.
다른 tmux window를 보고 있다가 남은 시간을 알기위해 tmux rename-window 도 한다.
(위의 스크린캐스트는 3 을 입력하고 3초 후에 알림창이 뜨는 시연이지만)
그런데, 책상 다리가 약간 벌어져있는것 같아서 줄자로 재보니.
- 앞은 너비가 115 cm 이고,
- 뒤는 너비가 113 cm 였다.
- 문제는 아닌걸까. (동작에 문제는 없는것 같긴 하다)

kubernetes, python, kafka 메모

2017-08-27T11:00:00+09:00

kubernetes

https://github.com 이 kubernetes 위에서 100% 돌아가도록 이전했다고 한다. [1]
- 정확히는 rails 웹앱을 모두 kubernetes 클러스터의 컨테이너에 올렸다고 한다.
- 일단 kubernetes 성공사례라서 좋았고.
- 실용적인 이야기들이 많아서 좋았다. (추상적인 이야기가 아니라)
- 예를 들면,
  - 커널 패닉에 대한 실패 테스트를 만들기 위해
  - echo c > /proc/sysrq-trigger 명령을 사용했다는 사례 같은것들.

python

최근에는 python을 많이 사용했다.
- ruby로는 불가능한 상황이었다.
- python을 피할 수 없는 상황을 여러번 겪었고,
- python3.6 이 나쁘지 않았기 때문에
- “만약 평생 하나의 프로그래밍 언어만 배워야 한다면 python이 맞는게 아닐까?”
  - 하는 이야기를 나도 하게 되었다.
python이 ruby보다 확실히 좋다고 생각하는 점은.
- built-in logging 모듈이 더 좋았고.
- argparse 모듈도 ruby의 optparse 보다 엄청나게 더 좋았다.
','.join(['1','2']) # => '1,2' 은 여전히 햇갈린다.
- ['1','2'].join(',') # => '1,2' 처럼 Array에 join 메소드가 있는 ruby가 나에겐 더 자연스럽다.
python은 int('1') 처럼 함수로 감싸는 형태로 코드를 작성하는 경향이 있는것 같다.
- ruby처럼 '1'.to_i 가 커서 이동도 적고 나에겐 직관적이다.
python linter는(autopep8, flake8) ruby 보다 관대하다는 인상을 받았다.
- ruby가 과도하게 엄격한걸까?
python3.6 부터 숫자에 밑줄을 넣을 수 있다.
- ruby는 linter에서 1000000 대신 1_000_000 을 쓰라고 가이드한다. [2]
  - 1000000 은 읽기 어렵고,
  - 1_000_000 은 읽기 쉽다.
- python은 이게 안 되서 불편함을 참아왔다.
  - 최근 도저히 참기 힘든 코드를 보게 되어 혹시나 하고 찾아봤다.
  - pep-515로 제안되었고 python3.6 부터 반영 되었다는 사실을 발견했다. [3]
- 그런데 이 pep문서를 읽다가 java도 가능한 문법이라는 사실을 알았다. (그것도 오래전부터) [4]
python을 만든 Guido 형이 2009년에 쓴 “파이썬 함수형 기능의 기원”이라는 글을 읽었다. [5]
- “파이썬이 함수형 언어에서 크게 영향을 받았다고 생각한 적이 없다” 로 시작하는 재밌는 글이었다.
- 파이썬 함수형 스타일에 대해서 약간 어색하게 느껴진 부분이 있었는데
- 이 글을 읽고 이해했다.
python3.6 에서 추가된 syntax 중에 f-string을 좋아한다.
- 그런데 vim 기본 syntax file 에서는 이 문법이 제대로 지원되지 않는다.
- 숫자에 underscore 같은것도 제대로 표시 되지 않는다.
- 새로운 syntax 파일을 설치하니 잘 표시된다. [6]
python3.4에 추가된 pathlib가 너무 좋아서 기존 코드들을 변경했다. [7]
- os.path 보다 좋다.
- 특히 좋은 점이라면 예를들면 아래와 같이 parent 같은것.

import pathlib
pathlib.Path('/home/sangwook/tmp/vim').parent.parent.joinpath('.vimrc').exists()

vim

ale에 java를 위한 checkstyle 지원 기능이 추가되었다. [8]
- checkstyle 설정 파일을 수정하다가
- google의 자바 스타일가이드에는 들여쓰기가 2-spaces 라는 사실을 발견했다. [9]
- (디폴트 파일을 쓰려고 했는데) 4-spaces 로 설정을 변경해야 했다.
- 왜 구글은 자바 표준을 따르지 않을까.
- 난 4-spaces 를 좋아하지 않지만 표준은 따라야 한다고 생각한다.
- 아니면 표준이 아니고 “사실상 표준”인가?
  - 공개된 장소에 글을 쓰려면 이런것 하나에도 사실 여부를 확인하고 근거 링크를 달아야 하지만.
  - 그런 부담을 놓기로 했기 때문에 그냥 넘어가기로 한다.
vim에서 _spec.rb과 같은 rspec파일을 편집하다가
- 현재 라인이 포함된 테스트만 실행하고 싶어서 찾아봤다.
- 단순히 rspec path/to/a_spec.rb:37 이렇게 :줄번호를 붙이면 되는걸 확인하고 vimrc를 수정했다.
- 테스트 속도가 아주 빨라졌다!
vim을 종료하는 방법을 물어보는 stackoverflow 질문/답변 페이지가 조회수 1백만을 돌파했다고 한다. [10]
- 2016년 전체 PV의 0.005%
- 평일 피크시 80명/시간
- top 5국가:
  1. 우크라이나
  2. 터키
  3. 인도네시아
  4. 파키스탄
  5. 베트남
- 이것은 어떤 의미 일까?
- 새로운 프로그래머가 많이 생기고 있는 국가?
최근 vim 업데이트는 :terminal 관련이 대부분이라. [11]
- 판올림하고 사용해봤다.
- 신기하긴 한데 tmux가 편하기 때문에 안 쓰기로 했다.

kafka, hbase, rabbitmq

kafka, hbase, rabbitmq에 대한 성능테스트를 했다.
자세히는
- kafka 메시지를 소비하고,
- hbase에 쓰고,
- rabbitmq에 메시지를 생산하는 것
을 하나의 트랜잭션으로 묶고, 유실이 없고, 초당 최대 5만개 메시지를 처리해야하는게 요구사항이다.
유실이 없어야 하니 물론 at-least-once 구성이다.
- 이론적으로 중복이 발생할 수 있는 구조인데
- 아주 많은 양을 오랫동안 테스트 했고
- 몇 주간 실제 데이터로 운영도 하며 검사했지만 한번도 발생하지 않았다.
성능 테스트에는 빨리 많은 테스트 데이터를 생성하는게 핵심인것 같다.
- 변수를 변경하면서 많은 실험을 해야 하기 때문이다.
- 나에게 익숙한 것은 ruby이니 ruby-kafka 를 사용했다. [12]
  - 스레드 수와, flush 하는 버퍼의 크기를 조정하면서 초당 20_000 개 정도를 produce했다.
  - 그런데. kafka 에서 느리게라도 produce해놓고,
  - offset을 earliest으로 가져오면 매번 테스트 데이터를 만들필요가 없다는 사실을 회사에서 eric이 알려줬다.
    - 난 왜 일찍 그것을 생각하지 못했을까…
이 작업을 하면서 hbase에 대해서도, kafka에 대해서도 배운게 많은데 언젠가 글로 정리할 날이 있겠지.

기타

덩케르크
- 재밌게봤다.
- 전쟁에 승자는 없다.
- 전쟁에 존재하는 것은 과부와 고아 뿐이다.
프로세스와 규칙이 많아 질수록 안정성을 얻을 수 있을지 모르지만, 혁신은 줄어든다고 생각한다.
- 촘촘한 규칙이 균일한 맛의 맥도날드 햄버거를 보장할지도 모른다.
- 하지만 맥도날드에서 일하는 사람은 자신을 요리사라고 생각하지 않는다.
- 좋은 요리사는 맥도날드로 모이지 않는다.
telegram API를 써서 개인적인 메시지를 받고 있는데.
- 정말 좋다.
- 내가 필요한것 이상의 모든것이 구현되어 있다.
- bot을 만드는 것도 쉽다.
- 텔레그램 짱.
  - markdown형식으로 메시지를 보낼 수도 있고,
  - 고정폭글꼴로 표시되게 만들수 있다는 사실을 발견하고 좋아하는 중이다.
SNS에서 정적 기록자(static logger) 관련 토론을 보고 [13] [14]
- logger를
  - static으로 했을 때의 단점
  - 또는
  - static으로 하지 않을 때의 장점을 (생성자에 logger를 넘기는 방식?)
  - 각각 샘플 코드를 통해 주장해 주신다면 읽기 좋을텐데… 하고 생각했다.
- 하지만 이런들 어떠하고 저런들 어떠하리.
- 나에겐 별로 중요한 관심사가 아니니 패스.
박성철님의 글. [15]
- 동의한다.
- 싸고 좋은 사람을 채용하려는 노력이 회사에 이익이라고 생각하겠지만.
- 그것은 보통 더 많은 규칙, 더 많은 프로세스, 문제를 조금 덜 발생시키는 기술을 고민하는 것으로 이어진다.
책을 모두 버렸다.
- 정확히는 회사 도서관에 기증했다.
- 다시는 책을 안 사야 겠다고 생각했다.
- 몇년전 부터 컨퍼런스는 안 가야겠다고 생각한 것과 비슷하다.
회사에서 대략 2년 x개월 만에 다시 mesos, marathon, 컨테이너 등의 클라우드 컴퓨팅 인프라를 개발하는 부서로 돌아왔다.

2017년 Rails, JavaScript에 대한 DHH의 생각

2017-02-21T21:51:00+09:00

DHH의 생각(을 읽은 후 내 생각)

(Rails를 만든 것으로 유명한) DHH가 Quora에서 질문을 받는 세션을 가졌다. [1]
재밌는 질문들이 많았다.
예를 들면
- “2017년에 Rails 프레임워크를 배울 가치가 뭐야?”
- “JavaScript 프레임워크가 Rails를 먹게될까?”
- “왜 Python이 아니라 Ruby로 Rails를 만들었니?”
- 등
질문만 봐도 막 읽고 싶어진다.
게다가 DHH는 글을 잘 쓴다.
전부 읽은 후, 내 생각과 비슷하다고 느꼈다.
- 오래전부터 내가 DHH에게 영향을 많이 받았다는 증거겠지.

While we’ve seen a lot a progress in the JavaScript world, we’ve also seen a regression to the complexity-laden world that Rails offered refuge from in the early days. Back then the complexity merchant of choice was J2EE, but the complaints are uncannily similar to those leveled against JavaScript today. That people spent hours, if not days, just setting up the skeletons. The basic build configurations. Assembling and cherry-picking from lots of little libraries and frameworks to put together their own snowflake house variety.

13년 전 J2EE와 비교할 정도로 현재의 JavaScript world를 복잡하다고 DHH는 생각하고 있다.
나도 현재 JavaScript world에서 만들어지는 것들을 좋아하지 않는다.
- 만약 spreadsheet 정도의 SPA를 만들어야 한다면 redux 등은 어쩔 수 없는 선택지다.
- 하지만 선택하기 전에, 오버엔지니어링이 아닌지 일단 의심해봐야 한다.
  - 오버엔지니어링, 이른 최적화는 모든 악의 근원이다.
- JavaScript world는 앞으로 크게 변할 것이다.
- 아마 몇년 뒤에는 지금과 많이 달라지고, 그 때는 나도 생각이 달라질 수 있겠지.
  - hibernate를 처음 봤을 때의 생각과, 지금의 생각이 다른 것 처럼.

That by formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application, we can make dramatic strides of productivity. … The vast majority of activity today is for yet another option on the a la carte menu. Yet another build system, yet another view library, yet another ORM. Very little activity in integrated solutions.

Rails는 full-stack framework를 목표로 하고 있다.
- conventions을 formalizing
- 가치없는 선택지 제거
- 디폴트 제공
- 등으로 높은 생산성을 만든다.
즉, Rails는 integrated solutions 를 지향한다.
이 목표의 프레임워크는 Rails가 독보적이다.
Rails 이외의 대다수 프레임워크는 그 반대편에 있고, 아래의 방향으로 개발된다.
- 또 다른 option을 만든다.
- 또 다른 빌드 시스템을 만든다.
- 또 다른 view library를 만든다.
- 또 다른 ORM을 만든다.

You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter. Just look at some code. I dare you not to fall in love.

Ruby는 함수형 언어의 장점이 재발견된 이 시대에 와서도 DHH가 본 언어중 가장 아름다운 언어라고.
동의 한다.
사실 난 python과 ruby의 선택 시점에서 ruby를 선택했던 이유는 처음엔 단순했다.
- string interpolation이 ruby에선 되고, python은 안 되는게 가장 컸다. [2]
  - 최근 python3.6 부터 python도 가능하게 됐다. [3]
  - 하지만 앞에 f를 붙이는 것을 보니, 역시 python과 ruby는 보는 길이 다르다.
- 나는 4-spaces 보다 2-spaces가 좋다. (사소하다.)
- python 코드도 가끔 읽을 때가 있는데,
  - 매일 python을 쓰는게 아닌 나에겐 python의 list comprehensions는 익숙해 지지가 않는다.
    - e.g. [x**2 for x in range(10)]
  - 그보다 ruby의 블록이 나에게는 훨씬 쉽고, 코딩도 생각의 속도로 가능하고, 읽는 것도 자연스럽다.
    - e.g. (0..9).map{|x|x**2}

Ruby 2.4

지난 크리스마스, (2016-12-25)
ruby2.3 이후 1년만에 ruby2.4가 나왔다. [4] [5]
반올림 함수(Float#round)의 디폴트 동작이 even-half가 뒤는 무시무시한 이야기가 있었다.
- 실제 preview3 까지 2.5.round의 결과가 2 였다.
- 많은 논란 끝에 결과적으로는 even-half로 동작하는 옵션이 추가되는 걸로 끝났다.
- even-half 옵션을 내가 쓸 일이 있을까.
rails의 ActiveSupport에 있던 Hash#transform_values가 core에 포함되었다.
pry의 binding.pry와 동일한 기능이 irb에도 binding.irb로 추가됐다고 한다.
- 하지만 pry대신 irb를 쓸 이유는 딱히 없어보인다.
true/false만 리턴하는 Regexp#match? 가 추가되었다.
- Regexp#match 보다 (당연히) 빠르다고 한다.
MatchData#named_captures가 추가되었다.
- 아래처럼 이름있는 captures를 Hash로 리턴하는 메소드인데, 아주 편하겠다.
```
/(?<fname>.+) (?<lname>.+)/.match('Ned Stark').named_captures
#=> {"fname"=>"Ned", "lname"=>"Stark"}
```

Uber의 Message Queue, Akka, Vim, Java

2016-12-14T21:59:00+09:00

Uber가 만든 MQ 디자인. (task-queue 용도)

uber가 며칠전(12/6) 아래의 제목으로 글을 썼다.
- “Cherami: Uber Engineering’s Durable and Scalable Task Queue in Go - Uber Engineering Blog”
- https://eng.uber.com/cherami/
uber는 microservice-architecture(이하 MSA)로 운영하는 것으로 유명하다.
- 이 글로 MSA에 필수인 queue를 uber는 어떤 디자인으로 만들었는지 알 수 있다.
- 또 어떤 디자인이 실제로 어떻게 구현되고 무슨 고민이 있는지도 알 수 있다.
- 남이 만든 디자인을 관찰하는건 재밌는 일이다.
- 나는 주로 가용성과 확장성에 주목한다.
  - (나에게) 처리량은 확장성에 포함되고.
  - (나에게) fault-tolerance는 가용성에 포함된다.
  - (물론 엄격히 말하면 다르다.)
- uber는 1억개/일 메시지가 오간다고 한다.
  - 계산해보면 평균 1,157개/초 메시지로 추정할 수 있다.
- 이 메시지가 uber에서 사용되는 사례로 밝힌 것:
  - post-trip processing
  - fraud detection
  - user notification
  - incentive campaigns
  - 등
주요 디자인 선택.
- 가용성을 위한 선택.
  - competing consumers.
  - replicating messages.
  - eventual consistency.
    - 이 선택은 아마도 순서를 보장하지 않는단 얘기.
- 확장성을 위한 선택.
  - competing consumers.
  - write 처리량을 관찰하다가 확장하는 역할도 미들웨어에서 하는 듯 하다.
나는 새로운 솔루션을 사용 하는 일에는 보수적이다.
- 새로운 솔루션을 선택하는 일은 많은 단점이 있다.
  - (논증 생략.)
- 나는 둘 중 하나의 길을 선호한다.
  1. 새로운 솔루션의 “디자인”만 이해하고, 기존 기술로 요구사항에 맞춰 구현한다.
  2. 아래 조건을 만족한 경우 새로운 솔루션을 사용한다.
    - 솔루션을 아주 깊이 이해했다.
    - 동시에 전파하기 쉬운 솔루션이다.
- 보통은 디자인을 제대로 이해하지 못하고, 유행을 쫓아 도입하는 경우가 많다.
- 그 중 queue 시스템은 다양한 장단점의 솔루션이 있다.
  - 각 회사마다 각 팀마다 저마다의 queue를 만드는 경향도 있다.
- 고가용성, 고확장성을 가지고.
  - 보장옵션을 선택하게 하면 좋을텐데.
  - 현재는 Amazon SQS 가 그것에 가장 가까웠다.

Akka

최근에 Akka와 Actor model의 디자인도 잠깐 검토할 일이 있었다.
Akka는 해주는게 거의 없는 틀 이었다.
나는 이런 프레임워크를 좋아한다.
보통은 X를 보장하면 Y가 떨어진다.
- 풍선을 누르면 다른 부분이 올라가는 것 처럼.
- 세상의 일은 대부분 tradeoff 다.
- 어떤 프레임워크가 X를 보장한다고 주장한다고 해도.
  - 사실은 그 보장의 경계를 증명하기 위해 많은 비용을 써야한다.
Akka는 오버헤드가 없는 틀만 있고 대부분을 개발자에게 위임한다.
- 그리고 actor model이 구조적으로 살을 붙이기 좋아 보였다.

vim

vim 관련 링크들.
2016 NYC Vim talk에서 있었던 “vim 플러그인이 하는 일의 90% 를 플러그인 없이 하는 방법” 이라는 제목의 발표.
- 영상 [1], 슬라이드 [2]
- 재밌게 보긴 했지만, 남는건 별로 없었다.
- 다른 내용은 좀 억지스럽고 부자연스럽게 문제를 해결하려는것 같았다.
  - 플러그인으로 하면 쉬운데 왜 이렇게까지? 하는 기분.
- file browser는 나도 nerdtree 보다 netrw 계열을 쓰는데 동의한다.
- 하지만 nerdtree 를 여전히 사용은 하고 있다.
- 그리고 내장된 순수 netrw 는 문제가 좀 있다.
vim 스크립트 칫싯. [3]
- 스니핏으로 저장해두고 쓰기 좋다.
파이콘2016 에서 vim과 gnome-desktop을 사용하시는 분이 있었다. [4]
- ruby의 byebug 같은 역할을 python에서는 pudb로 하는것 같다.
  - gdb와 매핑되는 네이밍으로 보인다.
  - 근데 저렇게 UI까지 제공하는건 좋은 선택일까?
- nautilus 를 터미널에서 입력하시는거 보니 오래된 gnome-desktop 유저 분이시구나 하는 생각이 들었다.
- vim에서 python 자동완성을 위해 jedi-vim [5] 을 사용하신다.
redis를 만든 antirez가 vim을 어떻게 사용하는지 쓴 글을 읽었다. [6]
- antirez가 쓰는 전체 vimrc 는 이것인듯. [7]
- 특별한건 없고, vim을 최소한의 설정으로 사용한다.
  - vim을 많이 사용하는 유저는 아닌것 같다.
- 실수방지를 위해 map 4 $ 을 한건 귀요미.
  - 나도 설정해봤는데.
  - 너무 불편하여 며칠후에 관뒀다.
- r!date 는 나도 설정해서 쓰는데, 나같은 사람을 또 만나다니!

java

java 생태계는 unix철학을 따르지 않고, 내가 쓰기엔 불편한 점이 많다.
- (나와는 정말 안 맞는것 같ㄷ…)
예를 들어.
- 현재 프로젝트의 dependency 목록을 보여주는 shell 함수를 만들고 싶었다.
  - 당연히 mvn help:effective-pom | xml2json | jq '...생략...' 이런식으로 간단히 되겠지. 라고 생각했다.
  - 하지만 mvn help:effective-pom 결과는 xml 외에도 info log정보를 (verbose하게) stdout에 뿌린다.
  - xml만 출력하려면 파일에 쓰고, 그 파일을 읽으면서 작업해야한다.
  - 불편하다.
  - verbose 옵션이 디폴트라니.
  - quite 옵션도 없다니.
- remote 의존성을 shell에서 검색하고 싶었다.
  - 만약 ruby라면 gem search kafka
    - (덧, ruby kafka 라이브러리가 옛날 버전만 지원하는 것을 보고 좀 우울해졌다.)
  - 만약 python이라면 pip search kafka
  - 만약 docker라면 docker search kafka
  - 만약 apt라면 apt search kafka
  - 를 했는데. java에서는 도대체 왜 mvn search kafka 같은게 없는걸까.
  - 라고 생각했는데
    - mvn-search kafka 식으로 만들 수 있게, 누군가 savant [8] 라는 도구를 만드셨다.
- 모든 dependency의 문자열 검색을 ag 같은 외부 툴로 하고 싶었다.
  - ruby라면 ag ~/.rvm/gems/ruby-2.3.1/gems/으로 검색하면 된다.
    - 실제로 이런 검색을 하는 vim 커맨드를 만들고, 키 하나로 찾아간다.
  - java에서도 이걸 해볼까 해서 시도했는데.
    - 일단 maven repository 에 소스를 올리지 않는 라이브러리가 많다.
    - 그리고 모두 jar로 압축된 형태로 ~/.m2/repository 아래에 저장된다.
  - jar를 풀고 class 를 decompile 해서 저장해야.
    - ag 같은 외부 툴로 검색하는 기능을 만들 수 있다.
  - 악.
  - 안 한다 안 해!
java에도 타입추론이 제안되었다. [9]
- 자바커뮤니티는 세계 최고의 보수적인 프로그래머 집단이기 때문에
  - 스칼라와 코틀린의 기능들을 아주 천천히 흡수하고 있다.
    - neovim 의 핵심기능을 vim8 이 흡수하면서 neovim을 죽이고.
    - coffeescript 같은 언어도 결국 흡수되면서 죽는 것 처럼.
    - kotlin 같은 언어는 (너무!) 좋지만 언젠가 죽을 운명의 기술이라 생각한다.
  - 타입추론의 문법은 아래 중 하나로 결정될 것 같다.
    - var x = expr only (like C#)
    - var, plus val for immutable locals (like Scala, Kotlin)
    - var, plus let for immutable locals (like Swift)
    - auto x = expr (like C++)
    - const x = expr (already a reserved word)
    - final x = expr (already a reserved word)
    - let x = expr
    - def x = expr (like Groovy)
    - x := expr (like Go)
  - 나는 Go 스타일의 x := expr 으로 선택되면 좋겠는데.
    - 자바스럽지 않다며 기각되었다.
      - The Go syntax (a different kind of assignment operator) seems pretty un-Javaish.
    - 자바스럽지 않다니! (하.)

우분투16과 KDE

2016-10-11T21:36:00+09:00

오랫동안 Ubuntu 14.04 LTS 를 사용하고 있었다.
- Unity 도 불편했지만 적응했고 익숙해졌다.
- 하지만 다음 OS는 Unity 를 사용하지 않기로 다짐했다.
- 왜?
  - 라고 묻는다면 명확한 답을 못하겠다.
  - 살짝 느린 느낌? 이라는 (내가 싫어하는) 비과학적인 답을 해야한다.
- 아무튼 다음에는 archlinux 또는 debian 처럼 rolling update 가 가능한 OS를 쓰고 싶었다.
처음에는 archlinux 기반에 tiling WM을 검토했다.
- 다른 hdd 파티션에 archlinux 와 WM 으로 i3wm 을 설치했다.
- i3wm 을 선택한 이유는 가장 많이 쓰이기 때문이다. [1] [2] [3]
- 결과적으로 i3wm 은 사용하길 포기했다.
  - 많은 문제가 있었고, 하나씩 문제를 해결했지만.
  - 아래의 문제를 해결하다가 너무 시간을 쓰는 것 같아서 현재 미룬 상태이다.
    - [문제1] wine 기반에 kakaotalk 을 설치하면 tiling 이 제대로 동작하지 않았다.
      - wine만 예외로 tiling 을 disable 했지만. 그래도 이상하게 동작했다.
    - [문제2] chrome 이 느리다.
      - 정확히는 url 입력 bar 에서 키 입력에 지연이 있다.
      - 또 탭 이동, 페이지 로딩 등에서 약간의 지연이 있다.
      - 아마도 ubuntu 패키지 등에서 자동으로 해결해주던 그래픽 드라이버가 i3wm 에서는 수동으로 설정을 해줘야 하는 것으로 추측함.
2016-03-13 알파고 vs. 이세돌 경기를 매일 재밌게 보는데 발견한 사실.
- 알파고는 Ubuntu14, Unity에서 돌아가는 것으로 보인다.
- 근거1.
- 근거2.
2016-04-21 Ubuntu 16.04 가 릴리즈 되었다. [4] [5]
- 바로 업그레이드 하려고 했으나, 일이 바빠서 미뤘다.
- 역시 LTS는 16.04.1 이 나오고 업그레이드를 해야한다.
2016-07-22 Ubuntu 16.04.1 이 릴리즈 되었다. [6]
회사에 KDE를 좋아하는 쿠퍼에게 설득되서 KDE를 사용해보기로 했다.
- KDE의 가장 큰 장점은 file manager인 dolphin 매우 좋다는 점이다.
- 나는 원래 주로 shell에서 파일관리를 하는 편이라
- Ubuntu14에서 사용하던 GNOME Files(=Nautilus) 에도 딱히 불만이 없었다.
- Dolphin 을 몇 주 사용해본 결과 아주 만족하고 있는데, 아래의 장점이 있다.
  - split 이 된다는 점.
  - 아래에 shell이 나온다는 점.
  - directory 변경 시 아래의 shell 에 자동으로 cd가 된다는 점.
- 적어도 macOS의 그지같은 Finder 보다는 훨씬 좋다.
- multiple rename 이 혹시 regex 를 지원할까 기대했는데 그건 되지 않는다.
  - 이거야 shell 에서 하면 되니까.
다른 HDD 파티션에 kubuntu 16.04.1 를 설치했다.
- USB로 부팅.
  - sudo dd if=./kubuntu-16.04.1-desktop-amd64.iso of=/dev/sdb
- GRUB:
- start kubuntu > install kubuntu 로 설치 진행.
- 네트워크 잡고.
- git, curl, tmux, zsh, vim, dropbox, fcitx 설치.
- system ruby, python, nodejs 를 사용하지 않도록.
  - rvm, pyenv, nvm 을 설치했다.
  - system ruby, python 을 사용하지 않도록 /usr/bin/python* 을 rename 했는데.
    - 이렇게하면 terminator 가 실행하면서 오류가 발생해서 되돌렸다.
- wine, kakaotalk 설치.
- 여기까지 설치하는게 내 필수 환경이라고 생각한다.
Ubuntu14 를 메인으로 계속 사용하면서 하루에 10-30분씩 Kubuntu16으로 부팅하여 문제/해결을 했다.
- 3개월정도의 트러블슈팅 끝에 마침내 Kubuntu16 을 메인으로 사용하기 시작했다.

Ubuntu14 Unity 에서 -> Ubuntu16 KDE 로 넘어오면서 생긴 문제/해결

[문제] 부팅했을 때 fcitx가 자동실행되지 않음.
- [해결] ~/.config/autostart/fcitx-autostart.desktop 파일을 만들었음.
[문제] zshrc 안에서 DE가 KDE 인지 여부에 따라 분기하는 로직이 필요하다.
- [해결] $DESKTOP_SESSION 을 쓸까 고민하다가, $XDG_CURRENT_DESKTOP을 사용함.
[문제] KDE가 ~/.xprofile 을 읽지 않는다.
- [해결] /etc/X11/Xsession.d/ 아래에 파일을 생성함.
[문제] 나눔고딕코딩 글꼴 설치가 안 된다.
- 공식 사이트의 설치 가이드 [7] 처럼 하면 오류가 난다.
- [해결] 패키지 설치.
  - sudo apt install fonts-nanum fonts-nanum-extra fonts-nanum-coding fonts-baekmuk fonts-unfonts-core fonts-unfonts-extra
[문제] KDE 기본 터미널인 konsole 에서 NanumGothicCoding 폰트를 선택할 수 없다.
- [해결] konsole 대신 다른 터미널을 쓰기로 함.
  - 처음에는 top-down terminal 을 써보다가.
    - top-down terminal: 게임 Quake의 채팅창 처럼 F12를 누르면 위에서 터미널이 (언제나) 내려오는 스타일
    - e.g. Guake, Yakuake, Tilda
  - 여기서도 설정 문제가 있어서. terminator 에 적응했다.
[문제] app launcher 를 meta 키 하나로 실행하고 싶다.
- [해결?] KDE config 전체적으로 mod 키 만으로는 shortcut 을 지정할 수 없다.
  - 할 수 없이 meta+z 로 shortcut을 지정했다.
[문제] 특정 키를 누르면 -> 특정 앱이 실행 되거나 focus가 되는 shortcut을 지정하고 싶다.
- [해결] KDE는 command를 global shortcut으로 지정할 수 있고.
  - 아래와 같이 focus 하거나 실행할 수 있다.
    - wmctrl -xa terminator.Terminator || terminator
[문제] R_ALT 를 한/영 키로 설정했는데, 빠르게 한영전환이 안 됨.
- [해결?] right alt 만 전체적으로 disable 하고 싶은데.
  - 불가능한 것 같다.
  - 사용하지 않는 ALT로 조합되는 shortcut 을 보이는데로 제거했다.
[문제] proxy 설정을 shell 에서 하고 싶다.
- Ubuntu14 Unity 에서는 gsettings 명령으로 설정했었다.
- [해결] KDE에서는 아래의 파일과 명령으로 가능한 것 같은데. 필요할 때 적용하는 걸로…
  - ~/.kde/share/config/kioslaverc
  - kreadconfig --file kioslaverc --group "Proxy Settings" --key httpproxy
[문제] vim을 소스에서 직접 빌드가 제대로 안 됨.
- --enable-gui=auto 옵션으로 빌드하면.
- checking --enable-gui argument... no GUI support 이런 에러가 남.
- [해결] /etc/apt/sources.list 가 디폴트로 deb만 활성화 되어 있는데 deb-src 를 주석 해제하고 build-dep을 하면 된다.
[문제] headphone으로 음악을 듣다가, headphone을 뽑으면 speaker를 음소거 상태로 만들고 싶다.
- Ubuntu14 Unity 에서는 자동으로 headphone, speaker 별로 내가 조정한 소리 크기를 기억했다.
- 그래서 자동으로 내가 원하는대로 동작했다.
- KDE는 내 선택을 기억하지 않았고. 해결책을 시간 있을 때 찾아봐야겠다.

Uber가 PostgreSQL을 MySQL로 바꾼 이유

2016-09-13T19:05:00+09:00

https://eng.uber.com/mysql-migration/
Postgres의 단점을 매우 잘 정리한 글.
사실 이 글은 아래 그림 하나로 요약할 수 있다.
읽은 후 쓴 내 메모를 최대한 짧게 요약:

항목	PostgreSQL	MySQL (InnoDB)
secondary index	directly	indirectly
secondary key lookup	유리	불리 (index 2개를 찾아야 하니)
row update 시	모든 index 업데이트	해당 row의 index만 업데이트
replication	WAL을 보냄	commands를 보냄
MVCC	row를 항상 씀	변경전 row를 rollback segment에 복사.
cache	OS의 page cache	buffer pool
connection	conn 당 process 생성	conn 당 thread 생성
upgrade	downtime 필요.	downtime 없이 가능.

덧,

사실 이 글을 보면 pg의 단점만 썼는데.
- pg가 tuple 방식의 디자인을 선택한건 tradeoff.
- 장점도 많다.
- 그래도 conn 당 process 를 생성하는건 어떤 장점이 있는지 아직 이해가 안 됨.
  - 내가 모르는 이유가 있을지 모르지만.
  - 어떤 기술을 비판하는 일은, 무지가 원인인 경우가 많아 조심.

이상욱