kubernetes
- https://github.com 이 kubernetes 위에서 100% 돌아가도록 이전했다고 한다.
- 정확히는 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 보다 관대하다는 인상을 받았다.
- python3.6 부터 숫자에 밑줄을 넣을 수 있다.
- ruby는 linter에서
1000000 대신 1_000_000 을 쓰라고 가이드한다.
1000000 은 읽기 어렵고,1_000_000 은 읽기 쉽다.
- python은 이게 안 되서 불편함을 참아왔다.
- 최근 도저히 참기 힘든 코드를 보게 되어 혹시나 하고 찾아봤다.
- pep-515로 제안되었고 python3.6 부터 반영 되었다는 사실을 발견했다.
- 그런데 이 pep문서를 읽다가 java도 가능한 문법이라는 사실을 알았다. (그것도 오래전부터)
- python을 만든 Guido 형이 2009년에 쓴 “파이썬 함수형 기능의 기원”이라는 글을 읽었다.
- “파이썬이 함수형 언어에서 크게 영향을 받았다고 생각한 적이 없다” 로 시작하는 재밌는 글이었다.
- 파이썬 함수형 스타일에 대해서 약간 어색하게 느껴진 부분이 있었는데
- 이 글을 읽고 이해했다.
- python3.6 에서 추가된 syntax 중에 f-string을 좋아한다.
- 그런데 vim 기본 syntax file 에서는 이 문법이 제대로 지원되지 않는다.
- 숫자에 underscore 같은것도 제대로 표시 되지 않는다.
- 새로운 syntax 파일을 설치하니 잘 표시된다.
- python3.4에 추가된 pathlib가 너무 좋아서 기존 코드들을 변경했다.
os.path 보다 좋다.- 특히 좋은 점이라면 예를들면 아래와 같이
parent 같은것.
import pathlib
pathlib.Path('/home/sangwook/tmp/vim').parent.parent.joinpath('.vimrc').exists()
vim
- ale에 java를 위한 checkstyle 지원 기능이 추가되었다.
- checkstyle 설정 파일을 수정하다가
- google의 자바 스타일가이드에는 들여쓰기가 2-spaces 라는 사실을 발견했다.
- (디폴트 파일을 쓰려고 했는데) 4-spaces 로 설정을 변경해야 했다.
- 왜 구글은 자바 표준을 따르지 않을까.
- 난 4-spaces 를 좋아하지 않지만 표준은 따라야 한다고 생각한다.
- 아니면 표준이 아니고 “사실상 표준”인가?
- 공개된 장소에 글을 쓰려면 이런것 하나에도 사실 여부를 확인하고 근거 링크를 달아야 하지만.
- 그런 부담을 놓기로 했기 때문에 그냥 넘어가기로 한다.
- vim에서
_spec.rb과 같은 rspec파일을 편집하다가
- 현재 라인이 포함된 테스트만 실행하고 싶어서 찾아봤다.
- 단순히
rspec path/to/a_spec.rb:37 이렇게 :줄번호를 붙이면 되는걸 확인하고 vimrc를 수정했다.
- 테스트 속도가 아주 빨라졌다!
- vim을 종료하는 방법을 물어보는 stackoverflow 질문/답변 페이지가 조회수 1백만을 돌파했다고 한다.
- 2016년 전체 PV의 0.005%
- 평일 피크시 80명/시간
- top 5국가:
- 우크라이나
- 터키
- 인도네시아
- 파키스탄
- 베트남
- 이것은 어떤 의미 일까?
- 새로운 프로그래머가 많이 생기고 있는 국가?
- 최근 vim 업데이트는
:terminal 관련이 대부분이라.
- 판올림하고 사용해봤다.
- 신기하긴 한데 tmux가 편하기 때문에 안 쓰기로 했다.
kafka, hbase, rabbitmq
- kafka, hbase, rabbitmq에 대한 성능테스트를 했다.
- 자세히는
- kafka 메시지를 소비하고,
- hbase에 쓰고,
- rabbitmq에 메시지를 생산하는 것
- 을 하나의 트랜잭션으로 묶고, 유실이 없고, 초당 최대 5만개 메시지를 처리해야하는게 요구사항이다.
- 유실이 없어야 하니 물론 at-least-once 구성이다.
- 이론적으로 중복이 발생할 수 있는 구조인데
- 아주 많은 양을 오랫동안 테스트 했고
- 몇 주간 실제 데이터로 운영도 하며 검사했지만 한번도 발생하지 않았다.
- 성능 테스트에는 빨리 많은 테스트 데이터를 생성하는게 핵심인것 같다.
- 변수를 변경하면서 많은 실험을 해야 하기 때문이다.
- 나에게 익숙한 것은 ruby이니 ruby-kafka 를 사용했다.
- 스레드 수와, flush 하는 버퍼의 크기를 조정하면서 초당 20_000 개 정도를 produce했다.
- 그런데. kafka 에서 느리게라도 produce해놓고,
- offset을 earliest으로 가져오면 매번 테스트 데이터를 만들필요가 없다는 사실을 회사에서 eric이 알려줬다.
- 이 작업을 하면서 hbase에 대해서도, kafka에 대해서도 배운게 많은데 언젠가 글로 정리할 날이 있겠지.
기타
- 덩케르크
- 재밌게봤다.
- 전쟁에 승자는 없다.
- 전쟁에 존재하는 것은 과부와 고아 뿐이다.
- 프로세스와 규칙이 많아 질수록 안정성을 얻을 수 있을지 모르지만, 혁신은 줄어든다고 생각한다.
- 촘촘한 규칙이 균일한 맛의 맥도날드 햄버거를 보장할지도 모른다.
- 하지만 맥도날드에서 일하는 사람은 자신을 요리사라고 생각하지 않는다.
- 좋은 요리사는 맥도날드로 모이지 않는다.
- telegram API를 써서 개인적인 메시지를 받고 있는데.
- 정말 좋다.
- 내가 필요한것 이상의 모든것이 구현되어 있다.
- bot을 만드는 것도 쉽다.
- 텔레그램 짱.
- markdown형식으로 메시지를 보낼 수도 있고,
- 고정폭글꼴로 표시되게 만들수 있다는 사실을 발견하고 좋아하는 중이다.
- SNS에서 정적 기록자(static logger) 관련 토론을 보고
- logger를
- static으로 했을 때의 단점
- 또는
- static으로 하지 않을 때의 장점을 (생성자에 logger를 넘기는 방식?)
- 각각 샘플 코드를 통해 주장해 주신다면 읽기 좋을텐데… 하고 생각했다.
- 하지만 이런들 어떠하고 저런들 어떠하리.
- 나에겐 별로 중요한 관심사가 아니니 패스.
- 박성철님의 글.
- 동의한다.
- 싸고 좋은 사람을 채용하려는 노력이 회사에 이익이라고 생각하겠지만.
- 그것은 보통 더 많은 규칙, 더 많은 프로세스, 문제를 조금 덜 발생시키는 기술을 고민하는 것으로 이어진다.
- 책을 모두 버렸다.
- 정확히는 회사 도서관에 기증했다.
- 다시는 책을 안 사야 겠다고 생각했다.
- 몇년전 부터 컨퍼런스는 안 가야겠다고 생각한 것과 비슷하다.
- 회사에서 대략 2년 x개월 만에 다시 mesos, marathon, 컨테이너 등의 클라우드 컴퓨팅 인프라를 개발하는 부서로 돌아왔다.