조급하지말고 천천히

렌트 2일째

어느 유명한 공원을 갔는데 지금 기억이 안 난다.... 지도로 잠깐 살펴보다가 아몰랑 모드 ㅋㅋ

폐가 정화되는 느낌이 들 정도로 공기가 굉장히 신선했고 나무들 또한 아름다웠다.
너무나 고요하고 평화로웠다.  곰 조심 하라는 주의 표지판을 보기전까진...ㅋㅋㅋㅋ

집안의 특정 구역이 생각나는 색깔의 물, 깊은것도 아닌데 굉장히 푸르둥둥했다.

다리 위에 있는 사람들의 걸음걸이가 온전히 느껴질 정도로 굉장한 스릴을 줬던 흔들 다리 위에서...

이름은 기억 안 나는데 커피랑 잘 어울리는 디저트(?)도 먹었다. 

렌트 3일째 휘슬러 고고~
운전하면서 보이는 풍경이 너무 멋있었다. 동화에 나올법한...그냥 지나치기엔 아까워서 차를 세우고 찰칵!!

같이 간 형은 먼저 한국으로 돌아갔다. 이후부터 혼자 15일 지내기가 시작되었다.
이 15일은 밴쿠버 동네 백수처럼 느즈막히 일어나 아점 먹고 도보나 대중교통으로 갈수 있는 곳으로 슬슬 바람 쐬기,
그러다가 공원 벤치에 앉아 멍 때리기의 반복이다 ㅋㅋㅋㅋ

한번쯤은 먹고 싶었던 러시아가 생각나는 그 음식, 푸틴을 시켰다. (자파도그에서)
시키고 양을 보니...와 이거 실수했다 싶었는데 더 안타까웠던건 푸틴 중간이 차가웠다...ㅜㅜ
아...처음 맛보는 푸틴이었는데 대 실망!!

개스타운 쪽에 있는 타코피노, 집이랑 가까워서 간단히 끼니 때우고 싶다면 이곳을 갔다.
왜 한입을 먹어야만 사진을 찍어야겠다는 생각이 들까...
기본 보다는 무언가 추가된것을 시키는 것이 좋은것 같다. 가격차이도 많이 나지 않는데 맛 차이가 좀 있다...
(엇!! 노린건가? ㅋㅋㅋ)  후딱 먹고 걷기 시작!!

CRAB 파크 앳 포트사이드에서 나는 뭘 잘하나...멍 좀 때리다가

코울 하버에서 비행기 이/착륙 하는거 구경 좀 하다

잉글리시 베이에서 지는 해를 바라보며 과거의 나를 되짚어 보는 시간을 가졌다.
공기 좋고 풍경도 좋으니 마냥 좋았다

집에 갈때는 힘들어서 버스 탔다 ㅋㅋ

한 일주일 동안은

도서관의 시설 이용 문의나 공원에서 심심해 보이는(?) 사람들에게 대화를 시도했다.
아....어학연수 간다고 무조건 영어가 느는건 아니구나~~ 라는걸 느꼈다. 상대방은 대화를 이어나갈 명분이 없고
만약 어렵사리 호의적인 사람을 만나 대화를 이어간다고 해도 내가 가진 어휘가 얼마 없으니 이어지지 않아 툭툭 끊긴다

이후부턴 할 말만 하고 억지로 대화를 이어나가려고 하지 않았다. (상대방에게 실례인것 같아서)
한국에 가서 어떻게 연습할지를 나름의 계획을 세웠다. (현재 1/3 정도는 지키는것 같다 ㅎㅎ)

※ 2019년 현재, 작년에 마음 먹었던 영어 학습 의지가 많이 누그러진 것 같다. 이번 기회에 다시 한번 마음을 다잡아 본다.

시간은 흘러...

Lunar New Year~ 설날이 다가왔다. 아는 사람 한명 없는 벤쿠버에서 맞는 설이란....
그래도 차이나 타운이라 설 비슷한 느낌은 있어 위로 삼았다.

아점을 먹고 슬슬 나왔는데 도로를 막고 이벤트(?)를 하고 있었다.
비록 혼자였지만 나도 모르게 웃음이 나왔던 좋은 시간이었다.

한참 보는데 귤나무가 지나간다. 중국에선 선호하는 새해 선물 중에 귤이 있다는걸 이때 알았다. 요런 경험 너무 좋아~

JapaDog에서 된통 당했지만 한번은 제대로 된걸 먹고 싶어서 다시 찾은 푸틴.

Fritz에서 샀다.....두입 먹어보고 도저히 그냥 먹기엔 아쉬워서 캔맥을 깠다. (음식이 '마~!! 이게 푸틴이다!!' 외치는것 같다)

개인적으로 데이비 거리의 음식점들이 맛난것 같다.(4군데 밖에 안 갔지만..ㅋㅋ)

내 몸 깊숙한 곳에서 '이렇게 설을 끝낼순 없지...'라고 느꼈는지 닭 한마리를 샀다.
(지금 생각해보니 추수감사절 느낌 내려고 했나 보다 ㅋㅋㅋㅋㅋㅋㅋ)

다리랑 날개를 굉장히 맛있게 먹고 몸통(뻑뻑살)을 먹으려는데
와~~~ 굉장히 뻑뻑했다. 남은 닭은 나중에 스파케티의 재료가 된다...

이번 설에 빈둥대다가 갑자기 '아!! 작년 설은 벤쿠버에서 지냈는데...'라는 생각이 들었다.
아직도 마무리하지 못한 나의 추진력에 박수를.... ;;;
1년이 지난 지금 쓰고 보니 그때의 결심을 다시 상기하는 효과도 있네...ㅎㅎ

막상 작년을 생각하면 거진 기억이 나지 않는데 사진을 보니 그때 먹었던 음식의 맛과 감정들이 새록새록 떠올랐다.
맛있는 음식, 아름다운 풍경,  반복으로 들었던 음악, 그리고 사진 요런 게 추억이고 행복 아닌가 싶다.

버스를 타고 쿠퍼스 공원을 갔다. (혼자 있을때는 도보로 자주 갔다. 마~ 내가 벤쿠버 뚜벅이다!!)

두 가족이 간단한 먹거리를 가지고 요트 타는 모습을 봤는데 굉~~~~~~장히 부러웠다.

커피 한잔 하면서 이런저런 얘기하다가 유료 수목원으로 고고!!!
이름이 기억은 안 나는데 미로랑 다양한 식물들이 있으니 마치 물향기 수목원에 온듯 했다.

다음날은 늦게 일어나 점저를 먹고 스탠리 파크 주변에서 놀았다.

"A-maze-ing Laughter" 뭔가 하하하 웃어서 긍정의 기운을 불어주려고 만든 것 같은데
진격의 거인이 생각난 건 내가 꼬여서 그런 거겠지... 생각되어 입 밖으로 꺼내지 않았다.

스탠리 파크 근처에 있는 버라드 거리 다리에서...
폰 떨어질까 봐 오들오들 떨며 찍었다. (안 찍으면 되잖아??)

세이프웨이 랍슨 에서 구매한 일용한 식량으로 하루를 마무리 지었다.
아...블루베리, 바나나 가격이 아른거린다...실컷 먹을껄...

대망의 렌트카를 빌린 날이었다!!! 단 3일!!

역시 이동 수단이 있으니 너무너무 좋았다. 좀 더 길게 렌트 할걸... 하는 아쉬움이 있었다. 

휘발유라 승차감도 괜찮았다. 큰 도로가 아니라면 좌회전은 눈치껏 가야 하는 게 초반엔 어려웠다.

벤쿠버 공항 근처에 있는 아울렛가서 대~충 보다가 올푸드 마켓에서 도시락(?) 같은걸 샀다.
다양한 먹을거리가 있는데(고기, 튀김, 샐러드 등...) 종류 묻지도 따지지도 않고 무게를 가격을 매긴다는 게 재밌었다.

"Rocky Point Spray Park"로 고고~ 

하늘에 깨 뿌려진 것 같지만 새들이다. 길게 늘어진 모습이 장관이라 한참을 봤다.

https://www.dremio.com/tuning-parquet/

Parquet 파일 하나는 1개 이상의 Row group이 있고 Row group은 column 별로 저장 되어있다.

Row Group 크기를 크게하면 column의 데이터가 연속적으로 저장이 되는 부분이 커져 연산 속도나 압축 효율이 좋아진다.

하지만 disk block 크기까지 고려한다면….

A: 커다란 Parquet file에 커다란 row group
앞에서도 얘기한것 처럼 연산 속도나 압축 효율은 증가하겠지만,
하나의 Parquet 파일/Row group이 두개 disk block에 걸쳐 있을 확률이 높기 때문에 추가적인 disk I/O가 발생한다.

B: 그렇다고 작은 Parquet file과 작은 Row group 한다면...
두개의 disk block에 걸칠 경우는 적겠지만 Parquet columnar storage 의 장점이 줄어든다. (row-based 저장하는것과 비슷해질듯)

C: 가장 이상적인 방식은 1개의 Parquet file에 1개의 Row group가 1개의 disk block에 있으면 가장 좋다. (이상적!!)

But how does the block size of the disk come into play?

"come into play"

This mitigates the number of block crossings, but reduces the efficacy of Parquet’s columnar storage format.

mitigates, efficacy

https://blog.usejournal.com/sorting-and-parquet-3a382893cde5

SELECT * FROM Customers WHERE Country=’Mexico’;

위 쿼리를 실행하기 위해서는 모든 데이터를 읽으면서 Country가 Mexico인 데이터를 추출하는 작업을 해야한다.
만약 Country가 Mexico인 고객이 전체 고객 중 1 %밖에 되지 않는다고 하더라도 전체 데이터를 읽어야 한다. OMG!!

Predicate pushdown이란 query engine에서 storage layer에 조건을 적용하여 읽어들일 양을 줄이는것을 의미한다.

Parquet은 Row group의 메타데이터를 이용하여 predicate pushdown이 동작한다.

Eg: integer column의 경우 min/max 값을 메타데이터에 저장한다.
string column의 경우 Row group 내의 distinct 값을 메타데이터에 저장한다.
(아래에도 나오지만 40,000개가 한계라고 한다. vcnc에서 관련 작업을 어떻게 해결했는지 나온다.)

근데 어떤 column을 정렬해야하나요?
각자 환경에 따라 다르므로 실행되는 쿼리들을 모두 기록하여 자주 사용되는 필터(where)가 어떤건지 파악 후
해당 column을 sort해서 저장하는것을 권고한다.

Predicate pushdown means that the query engine is able to push the condition right into the storage layer and thus reduce the amount of data that is read.

and thus. and then 하고 비슷하면서도 뭔가 다른것 같다.

Another idea is to keep a record of all the queries that are run into a log and then analyze the queries to understand which column is filtered on the most.
"column is filtered on the most"

https://blog.cloudera.com/blog/2017/12/faster-performance-for-selective-queries/

적절한 파티션 분리는 조회시 꽤나 유용하게 사용된다.
예로 일별로 파티션 된 데이터가 2년정도 쌓였는데 이때 최근 7일 데이터를 조회하고 싶다면 730개 파티션 중에서 7개만 조회하면 된다. 100x 효율 개이득!!

하지만 파티션이 너무 많으면 메타 데이터 관리가 부담이 될수 있으므로 적절하게 지정해야한다.

그리고 모든 것을 파티션으로 해결하는것은 불가능하므로 몇가지 유용한 분할 스키마 방식이 있다.

각 Parquet 파일에는 최대/최소 같은 정보가 담긴 메타 데이터가 있다.
Impala 2.9 부터는 각 필드의 min_value, max_value 필드를 읽어 조회시 파일 읽을 때 건너뛴다.
Hive / Spark로 파일을 쓴 경우에 Impala는 deprecated 된min, max 필드만 읽는다. (현재 회사에서 사용하는건 Impala 2.11)

※ Parquet row group 과 dictionary filter에 대해 이해를 돕기 위한 친절한 그림..꼭 보세요!!

Parquet Row Group Skipping via Min/Max Statistics 테이블 생성시 Sort BY를 했을때와 안 했을때의 차이를 보여줌

Parquet Row Group Skipping via Dictionary Filtering 
Impala는 자동으로 dictionary filtering을 적용한다.
하나의 parquet 파일의 한 column distinct value 갯수가 40,000개를 넘으면 예외

Min/Max 범위가 매우 커서 그다지 효과적이지 않을때 dictionary filtering을 이용하여 해당값이 존재하는 파일인지 체크하여
읽어드릴 파일 갯수를 줄일수 있다.

앞에 설명이 잘 되어있어서

쌩짜로 만들어진 테이블과 partition 으로 만든 테이블, partition과 clustering으로 만든 테이블의 비교한 표는 재미지게 볼 수 있다.

This approach significantly speeds up selective queries by further eliminating data beyond what static partitioning alone can do

This means that when the min/max skipping may not be effective due to the min/max range being too large, dictionary filtering can check for the existence of values without reading any of the rows in the file.

VCNC 기술 블로그 글을 보고 호기심이 생겨 찾아보았습니다.

http://engineering.vcnc.co.kr/2018/05/parquet-and-spark/

현재 Spark로 parquet 파일 쓰고 Hive, Impala로 조회하는 부분이 있는데 테스트 하면서 현재 상황에 맞게 수정 해봐야겠다.

다음 날은 오후 2시에 집을 나섰다.

캐나다 플레이스 가는길에 개스타운에 들려서 커피 홀짝홀짝 마시며 증기를 이용한 신명나는 음악을 들었다. 

기대가 컸던걸까....'이게 끝이야?' 라는 생각이 들었다. 하지만 시계탑을 주변으로 괜찮은 가게들이 있는것을 보고
나도 시계탑 같은 사람이 되야지..라는 개똥같은 생각을 해봤다.

밴쿠버에 있는 한달 동안 참 많이 갔던 캐나다 플레이스, 바다와 (강인가?;;) 산, 구름 그리고 그 사이에 있는 집들이 평화로워 보인다.

집으로 가는길에 랍슨 거리에 있는 한인 식당에서 순두부 찌개와 LA 갈비를 먹었다.

다음날 원데이 패스를 끊고 그랜빌 섬을 갔다.

이날도 비가 내려 아쉽게도 멋진 풍경은 보진 못했지만 한산해서 좋았다.

public market 돌아다녔는데 신기한 음식, 식료품들로 가득했다.
마치 예전 불량식품에 봤을법한 꿀을 빨대에 담아 파는게 있어서 샀는데, 다음 목적지였던 Craft Beer market에 두고 왔다ㅋㅋㅋㅋ

피자 먹다가 '아!!! 사진...' 하면서 찍은 음식ㅋㅋ 양심은 있어서 베어물은 자국 가림 ㅋㅋㅋㅋ

원래는 그린 아일랜드 안에 있는 맥주집을 가려했지만 문을 닫아서 근처에 위치한 Craft Beer market 가서 수제 맥주를 먹었다.

으악!!! 내 꿀 빨대...(꿀빨았다는 말을 표현하는 너무 적절한 아이템이라 써먹으려고 산건데 아쉬웠다.)

엘리자배스 퀸즈 공원도 갔다. 동네도 참 조용하고 공원도 조용해서 이런저런 얘기하며 공원 한바퀴 돌았다.

무사히 이동할 수 있게 해 준 구글맵에게 감사하며 하루를 마무리했다.

Vancouver public library에 들려 책도 좀 구경하고 가져간 킨들도 좀 읽었다.

스탠리 파크 걷다가 쌀국수로 마무리!!  이날도 하루 종일 이슬비와 함께 했다. 피부는 건조할 틈이 없어 좋은 듯

집에 도착해서 씻고 누웠는데 잠이 오지 않아 새벽 4시에 자서 일어 나보니 오전 11시,

이 날은 꿀잠 잤다.

작년 퇴사를 하면서 어학연수를 생각했지만 보름 만에 접고 무작정 밴쿠버를 갔다 온지도 6개월이 지났다.
밴쿠버에 있을 때 영어로 대화할 기회가 정말 중요하다고 생각되어 한국 가면 바로 전화영어 해야지... 한지도 6개월이 지났다;;

다행스럽게도 추석 지나니 해야겠다는 마음이 들어 전화영어를 알아보게 되었고 그 경험을 기록해보려고 한다.

전화영어 관련 검색하여 나온 후기들을 보면  '나는 돈을 받지 않았다, 개인돈 쓰고 개인 경험을 썼다' 라는 글을 많이 보았다.

나도 그렇다.

이 글은 업무를 하는데 영어가 너무나 필요해서 잘하고 싶은 사람이 전화 영어를 알아보면서 느낀점을 쓴 포스트이고
개인 돈으로 결제했습니다. ;)

우선 전화영어 업체를 간추리고 간추렸더니 유폰과 민트영어로 좁혀졌고 두 업체 레벨 테스트를 하기로 했다.

결과는 아래에....간단한 문장들은 곧 잘 알아듣지만 본인이 말할때는 4단어 넘어가면 엉망...ㅜ

굳이 결과를 올린 이유는 기록 차원과 좀 더 열심히 하자는 마음에 올렸다. ㅋㅋㅋㅋㅋ

유폰 영어 레벨 테스트

민트 영어 레벨 테스트

최종적으론 유폰 전화 영어로 결정하였다.

이유는

이제는 인도나 동남 아시아 영어 억양에 익숙해져야 한다는것에 완전 동의한다.
하지만 영어를 못해서 공부하는건데 좀 더 익숙한 억양으로 하는게 좋다고 생각되었다. 그런면에서 유폰이 괜찮았다.
민트영어에 후기나 강사님에게 달린 댓글에는 괜찮다고 써져있는걸 보니
케바케 인것 같기도 하고 그냥 내가 익숙해진 억양이 유폰인것 같다. (다행히 유폰 '첫'수업도 익숙한 억양이였다.)

민트영어의 장점 중 하나가 열심히 활동하면 포인트를 얻을 수 있고 이를 포인트를 모아 무료 수업이 가능하다는 점인데,
주중에 이 포인트를 얻기에는 무리라고 판단했다. 나에겐 장점이 아니게 되었다.

12개월 결제를 하면 40%라는 어마어마한 할인을 해주지만 첫 전화영어라 부담이 있었고 6개월 결제 비교했을때
유폰과 크게 다르지 않았다.

※ 제 글만 보고 유폰만 레벨 테스트하기보다는 여러 업체 레벨 테스트한 후 결정하는 게 좋다고 생각합니다.

그래서 지금은 유폰 3개월 결제를 한 상태고 이번주 월요일부터 시작하였다.

첫 수업이라 뭐라 얘기하기엔 성급한 것 같고, 확실한 건 20분 선택은 참 잘한 것 같다.

p.s 혹시 이 글을 보고 유폰 영어 레벨 테스트에 관심이 생겼다면 비밀 댓글이나 메일을 보내주세요. 추천 링크 보내겠습니다.
첫 레벨 테스트, 수강하신적이 없는 경우 각각 3만원 유폰 쿠폰을 준다고 하네요. (이 포스트의 목적? ㅋㅋㅋ)

한 달 밴쿠버 여행(?) 다녀온 지 벌써 6개월이 지났다.

한 달 동안 본 것도, 느낀 것도 많아서 한국 돌아가면 정리하기로 다짐했는데... 응? 벌써 8월?

4월에는 취업준비한다고 패스, 5월에는 회사 적응도 하고 자취도 해서 패스!!  

6월에는 직장도 자취도 적응해서 술로 지내서 패스!!  7, 8월에는 덥다고 패스!! ㅋㅋㅋㅋ 

이것도 능력이라면 능력이다....

천 번의 이상적인 생각보다 불안한 실행 한 번이 낫다는걸 몸소 깨달은 여행이라 사진을 보면서 감정들을 정리해보려고 한다.

정말 신기하고 좋았던 점은 6개월이 지났는데도, 밴쿠버에서 찍은 사진 한 장 한 장을 보면 주변의 상황, 

나의 생각들이 떠올랐다.

아이들 학예회나 콘서트같이 특별한 날에 직접 보지 않고 카메라 찍는 모습을 비판하는 의견도 많은데... 모르겠다. 사진이 좋다.
If you really want to remember a moment try not to take a photo

인천공항 체크인 부터 고생길 열리기 시작~~

내 여권번호로 eTA 등록이 되어있지 않아 체크인을 할수 없다고 했다.

한 달전에 분명히 했는데 안 되어있다고 해서 메일을 확인 했는데....세상에!! ㅋㅋㅋㅋ 

여권번호 앞에 'M'을 빼고 등록 했다.

등록 당시의 나는 주민번호 가운데 1, 2, 3, 4 처럼 성별인 줄 알았나보다;;;

터덜터덜 의자로 돌아가서 핸드폰으로 등록을 했다. 한번 삽질 해서 그런지 금방 했다.

'홈페이지 개발할 때 여권번호 validation 체크 해야하는거 아니야?' 라는 동종 업계인으로서 아쉬웠다.

이땐 몰랐지....더 큰 validation 체크의 위험이 있을줄...

인천공항에서 창 밖으로 비행기 보는 순간은 항상 들뜨고 앞으로 벌어질 모든것을 긍정적으로 생각하는것 같다

인천공항에서 비행기 타기 전까지를 여행 패키지로 만드는건 어떨까? -_-;;

밴쿠버 도착하니 비가 부슬부슬 내리고 있었다. 습한 만큼 자연은 굉장히 생생해보였다.

스카이 트레인, 버스를 타고 숙소로 가는데 처음 맡아본 마리화나 냄새에 나도 모르게 가방을 꼭 쥐게 되었다.

한달 동안 묶을 airbnb 도착!!

기본 4인용이라 그런지 굉장히 넓직하고 좋았다.

숙소근처에 있는 식당에서 쌀국수를 먹었다. 입에 맞아서 틈나면 간듯...ㅋㅋㅋ

캐나다 플레이스를 시작으로

스탠리 파크

랍슨 거리

숙소 도착

우산 쓰기도 뭐하고 그냥 걷기도 뭐한 잔잔한 비가 하루 종일 왔다. 마치 나를 따라다니면서 분무기로 계속 쏘는 느낌???

이날 이동한 거리를 구글맵으로 얼추 해보니 12km였는데 요건 가벼운 워밍업 정도였다.

밴쿠버에 있는동안 정말 많이 걸었다.

숙소 바로 옆이 왕복 4차선 도로였는데 목재 건물이여서 그런지 마치 차도 옆에서 잔다고 생각할 정도로 방음이 하나도 안됐다.

하지만 사람은 참 대단한 게 일주일 정도 지나니 차 소음은 무시하고 꿀잠 잤다.

첫날은 이렇게 마무리한듯? ㅋㅋㅋㅋㅋ

야탑에 온 지 3달이 다 되어간다.

집 적응은 거의 됐고, 시간 날 때마다 동네 탐방하면서 보내고 있는데 '어? 여기에 이런 곳이?' 라는 생각 드는 가게가 은근히 있다.

그중 한 곳이 스윗 봉쥬르다. 입간판이 아니었다면 그냥 지나쳤을 정도로 의외 장소에 있다.
주변이 나무로 우거져 있으니 입간판을 잘 봐야한다.

언제 한번 먹어야지... 벼르고 있다가 저번주 목요일에 동료들이랑 같이 먹으려고 가게로 들어갔다.

20개 사려고 했는데 시식한 마카롱이 너무 맛있어서 3개 더 샀다. (1개는 서비스로 주심)

기분 좋게 나가려는데 갑자기 비가 왔다.
머뭇머뭇 하니 우산도 주셨다. 크흐~~~ 감동, 이 글을 보실진 모르겠지만 잘 쓰겠습니다 ;)

회사 냉장고 넣기 전 찍은 보냉 포장 사진 ㅋㅋㅋ 포스트잇이 아련하게 붙어있네

마카롱 맛은 아래 팀 단톡방으로 대체한다. 참고로 모두 남성이다. 이 정도로 맛있습니돠!!!!

마카롱 한 개에 2200원이라고 하면 비싸다는 생각이 들지만 충분히 값어치 하는 맛이라고 생각한다.

몸이 쉬면서 입안도 쉬고 싶을 때 한 두 개 사서 먹으면 좋을 것 같다.

2017년 11월 16일 4번째 회사를 퇴사 했다.

원대한 목표가 있어서도 다른 회사를 구해서도 아니었다.

여러 이유가 있었지만 비중이 컸던건 개발자로 일하면서 영어에 대한 욕심이 항상 있었는데 더 늦기전에 제대로 하고 싶어서 2018년 어학연수를 가겠다는 계획을 갖고 나는 퇴사를 했다.

연말이기도 해서 술약속을 대차게 잡았고 한주에 3~4번의 술약속을 잡게 되었다.

퇴사는 했지만 여전히 강남 가는 버스를 타고 돌아오는 내 모습을 보며 헛웃음이 났다.

3주를 술로 지내다가 어학 연수 준비를 하기로 했다.

어학연수 관련 후기나 프로그램들 찾아보다가 괜찮게 느껴진 프로그램을 알게 되었는데,

단순하게 어학원 소개 해주는게 아닌 어학연수를 효율적으로 할수 있는 방법을 알려주는 프로그램이었다.

굉장히 현실적이고 공감되는 내용들이 많아서 3만원 내고 상담 신청을 했다.

12월 11일, 강남 가는 버스에 몸을 실었다. 

꽤나 추운 날씨였지만 어학연수에 도움이 될거라는 기대때문인지 괜찮았다.

하지만 결과는....실망(내 입장에서...)

내가 어학연수 상담 받는걸 아는 사람들에게 결과 얘기 하다가 아는 형과의 전화가 시작됐다.

이 전화가 여행의 시작이었다.

본인도 기분 전환 할겸 새로운것을 보고 싶으니 함께 밴쿠버에서 한달 지내보는건 어떻겠느냐 얘기를 했고 

나도 어학연수 준비에 대한 정보도 얻고 싶고 만약 내가 외국에 산다면 어떤 느낌일지 알고 싶어서 동의 했다.

(자세한 내막이 있지만 여기선 패스!! ㅋㅋㅋ)

바로 다음날 2.2 ~ 3.5 비행기 예약과 airbnb 숙소 예약을 했다.

밴쿠버 출발 전, 목요일부터 짐싸기 시작했다.

작년 베트남 여행때도 느낀건데 출발전 준비하는 시간이 여행에서 가장 설레는것 같다.

같이 가는 형이 밴쿠버를 한번 갔다온 적이 있어서 어디어디가 좋다!! 정도만 있었지 아무런 계획도 없었다.

2.2 ~ 3.5  짧다면 짧고 길다면 긴 기간이다.

이번 여행 동안 인생에 대해서 계획하고 돌아보는 시간을 많이 가졌으면 좋겠다는 생각과 함께 비행기에 탔다.

Go에 관심을 갖은건 2012년 정도로 생각된다. 하지만!! 지금까지 Go 관련 글을 Evernote나 workflowy에 저장만 하고

딱히 Go를 이용해서 뭘 만들어 보지도 않을 뿐더러 문법도 애매하게 안다...

지금까지 행동 없이 관심만 가지고 지내면서 너무나 무뎌진 나의 개발 능력을 체감했고, 날카롭게 만들고 싶었다.

(물론 무뎌짐을 느낀게 처음은 아니지만 이번엔 세게 왔다. 결심은 큰 의미 없으니 어느정도 생각이 잡히면 바로 행동)

우선 내가 날카롭게 만들고 싶은게 무엇인지 적어보면 

다양한 데이터를 손쉽게 수집하기,

수집한 데이터와 사용 용도에 적합한 DB solution을 찾을 줄 알고, 장/단 점 파악 및 설정 값들이 어떤 의미가 있는 정도, 

마지막으로 저장된 데이터를 쉽게 관리 할수있는 시스템 만들기다. 

우선 Go의 장점/단점이 어떤게 있는지 알아보고, 명분을 찾아보자.

Why go is Not Good  http://yager.io/programming/go.html

Generic, Type overloading 이 없다

immutable data type, pattern matching, option이 없다

대부분 multiple return의 두번째 값을 통해 오류처리를 하는데 잊어버리기 쉽다.

embedded programming에는 overhead가 없는 Rust 가 짱짱맨

Why we switched from Python to Go https://getstream.io/blog/switched-python-go/

C++, Java와 비슷한 성능

직관적인 코드로 생산성 괜춘

goroutine과 channel을 이용한 쉬운 동시성 코딩 (1977년에 시작된 CSP를 새로운 접근 방식으로 구현)

부족한 (CRUD API 지원되는) Framework과 패키지 관리 시스템

부족한 Error Handling

Python 과 Go를 비교

코딩 시간은 Python이 조금 더 짧았지만 최적화 하는데 시간이 오래 걸렸다.

Go는 최적화가 필요하지 않을정도로 괜찮은 성능이 나왔다.

Why Go and Rust are not competitors https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors

Rust는 C/C++ 호출이 overhead 없이 가능, Go엔 cgo라는게 있지만 성능 이슈가 있다.

Rust는 극강의 성능을 지향, Go는 단순함을 유지 하기 위해 성능을 희생

Go는 단순함이나 직교성을 해치는것을 막는것에 초점을 잡았고

Rust는 unsafe하거나 오버헤드, 즉 성능에 영향을 끼치는것을 막는데 초점이 잡았다.

Rust는 성능을 요구하는 C++, D 같은 언어와 경쟁한다. ex) 게임 엔진, 웹 렌더링 엔진

Go는 인터넷 2.0세대 이후 생긴 Ruby, Python, Node.js 그리고 배포에 오랜 시간이 걸리는 JVM 기반 언어와 경쟁한다.

Why Go? https://dave.cheney.net/2017/03/20/why-go

메모리 관리에 대해서 안전하다.

개발 생산시간이 컴파일 시간보다 비싸진건 오래전부터다. Go는 컴파일 시간이 짧고, 코드에 모호성이 없다.

코드를 읽는것이 작성 하는것보다 우선 순위가 높다는 기조로 만들어졌다. 그리고 다양한 분석 도구들이 생기고 있다.

하드웨어의 발전만으로 성능을 이끌어냈던 공짜 점심은 끝났다. 

goroutine, channel를 이용해 동시성을 지원하는 코드를 손쉽게 작성할수 있다.

How to convince Your company to Go with Golang  https://sendgrid.com/blog/convince-company-go-golang/

Go를 좋아하면 새로운걸 배우는걸 좋아하는 사람들이고 이런 사람들은 우리 회사가 원하는 개발자였다. 채용 개이득!! ㅋㅋ

마음에 드는말

기술로 무언가를 할수 있다는것이 가장 좋은 방법은 아니라는 것을 사람들에게 이해시키는데 도움이 되었던 말 

“Perl로도 계속 개발할 수 있다."

“We can keep doing it in Perl,” which usually helped people to understand that just because you can do something with a technology doesn’t mean its the best way to do it.

Ten Reasons Why I Don’t Like Golang  https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html

public, private을 대소문자로 구분하는것, scope이 어디까지인지 알기 어렵다

error handling이 어렵다

“convention over configuration” 기조가 작은 프로젝트에선 괜찮지만 커다란 프로젝트에선 너의 발목을 물것이다!!

사용하지 않는 variable이나 import가 있으면 경고가 아니라 컴파일이 안된다.

ternary 연산자가 없어서 불편하다.

generic이 없어서 interface{}를 사용하고 있다.

db 혹은 web 과의 통신이 잦은 프로그램에서는 추천하지 않는다.

Why rust? https://pingcap.github.io/blog/2017/09/26/whyrust/

SQL 계층은 Go의 장점을 십분 활용해 구현했지만, 성능이 중요한 저장 계층에선 Go가 단점이 되었다.

저장소로 RockDB를 사용하기로 했는데 cgo의 오버헤드 무시 못함 

Why Go? http://www.mikeperham.com/2014/10/08/why-go/

https://github.com/golang/go/wiki/FromXToGo

지금까지 tutorial 수준으로 해왔던 경험과 위 링크를 읽은 후 Go에 대한 나의 생각

문법이나 생태계 측면으로는 정말 생존에 필요한 도구만 챙기고 바로 캠핑을 떠나는 모험가 같다. 

좀 더 편안하고 쉬운 캠핑을 위해 더 챙겨가면 좋은데 가볍고 빠른 행동(?)을 위함이다.

하지만 단체로 캠핑을 갈 경우 함께 가는 사람들이 모두 모험가형이 아니라면 좀 더 많은 것들을 챙겨가야 할것이다. 

(Go가 큰 프로젝트에 사용할때 불편하다는 말에 어느정도 공감한다. 물론 크다는 기준이 굉장히 주관적이지만...)

사용성이나 성능면으로는 어떠한 분야를 특출나게 잘하진 않지만 다양한 분야를 어느정도 잘하는 사람 같다.

[학교 성적/회사 성과]도 상위권이고 친구와의 관계도 그리 나쁘지 않고, 이성에게 인기도 어느정도 있는 그런 사람.

Go를 나쁘게 보면 어중간하다고 할수 있지만 두루두루 잘 한다고 볼 수도 있다.

정말 극강의 성능을 필요로 한다면 C/C++나 Rust로, 외부 데이터와의 연동이 많다면 Java로 하고 

그외에는 Go!!, Python의 라이브러리가 좋은게 있으면 Python을 이용하자

(현재 데이터 분석 및 관리하는건 Python이 최고!!!)

우선 Go부터 시작하고 어느정도 익숙해지면 Python도 익숙해져보자 (제발~~~)

셋째 날

7시에 온다는 픽업 버스는 오지 않는다. 호스텔 카운터 분에게 물어보니 늘상 있는 일이라며 곧 온다고 해서 기다리니 
7시 40분에 도착! 픽업 버스를 타고 Inter 버스를 타니 8시가 되었다.
너무 불편한건 아닌데 뭔가 불편했다. 사파에서 하노이 돌아올땐 맨뒤에 탔는데 이때가 좋았구나...싶다.

휴게소다

버스에 내리고 첫샷, 버스에 내리면 다낭족이 물건을 팔기 위해 온다고 들었는데, 혼자 온 동양 남자한테는 안 그런것 같다.

구글맵을 키고 두번째 숙소를 향해 걸었다. 고지대라 그런지 구름이 굉장히 빨리 움직이고 공기도 좋았다. 내 스타일!!!

숙소 가는길에 길거리에서 파는 반미를 하나 먹었다. 고기는 없고 실타래(?)같은게 들어있는데 적당히 달고 맛났다. 반미는 진리!

숙소다. 하노이에서 첫 숙소가 너무 강렬했던 탓일까? 둘째 날에 Booking.com으로 $26짜리로 덜컥 예약했다.
역시....돈이 좋구먼~ ㅋㅋㅋㅋ 싱글에는 짐을 풀고 더불에서 대각선으로 잤다.
Sapa Centre Hotel이다. Center와 헷갈릴수 있으니 조심!!

1층 식당에서 간단히 먹고 함롱산으로 출발!! 이때 처음 셀카봉을 사용했다.

캬~~~ 정말 멋있다. 갑자기 안개가 지나가는것도 멋있고, 구름 흘러가는것도 멋있고, 멀리 동네길 보이는것도 멋있다

갑자기!! 마을에 안개가 낀다. 함롱산에서 사진을 가장 많이 찍었다.

함롱산 내려가는길

힘을 썼으니 배고프다. 함롱산 입구에서 냄새에 이끌려 찾아간 꼬치 구이. 어떤 고기인지 모를 꼬치를 선택하면 구워준다.
한 꼬치에 2만동

꼬치만 먹으니 배고파서 하이랜드 옆에있는 샌드위치 가게에서 사먹었는데....입맛에 안 맞았다. 아...진심으로 반미 먹고 싶었다.

광장에 좀 있다가 숙소에 들어왔다. 맥주 마시다가 괜찮은 카페를 가보자!! 해서 검색하고 출발했다.

cat cat 마을 가는 길에 위치한 카페였는데.....와..무서워서 닭살 돋은건 오랜만이었다.
중간쯤 가니 가로등도 없고 안개도 으스스하게 끼길래 
'그래 베트남 와서 커피 너무 마셨어 오늘은 카페인 먹지 말자, 난 겁쟁이가 아니야' 생각 하며 다시 숙소로 돌아왔다.

넷째 날

조식을 먹고 과자 한 봉지 사들고 광장에 갔다.
체크아웃 이후 cat cat 마을을 갔다가 Lao cai 마을에서 묶을 계획이었다. 아....이땐 몰랐지 내가 개고생 할 줄은...

광장에서 우걱우걱 과자를 다 먹고 그냥 들어가기 뭐해서 커피 한잔.

하노이에선 아메리카노를 찾기 힘들었는데 
사파에서는 블랙커피, 아메리카노는 심심치 않게 보이고 심지어 피자집, 이탈리아 맛집도 있음 ㅋㅋㅋㅋㅋ

체크아웃 하고 cat cat 출발~~

입장료를 두번 냈다. 양옆에 돼지들이 반겨준다. 개도 닭도 오리도 반겨준다.

1시간 30분 정도 걸었을까(?) 사람 사는 마을을 지나 다시 자연이고 점심때도 되서(가장 중요!!) 왔던길을 다시 돌아갔다.
돌아갈때 슬슬 지치기 시작했다.

어제 저녁에 가려고 했던 카페. 전망이 너~~무 좋다 :)  Zmong 카페

구름 사이로 햇빛 비취는 장면이 많이 보였다. 그분이 오실것 같은....ㅋㅋㅋ

Lao cai 마을 가기전에 요기 하러 들어간 곳. 가격도 비싸지도 않고 깔끔하게 잘 나온다.
체력 저질이어서 힘들었고 고기는 먹고 싶었는지 입 속을 두번이나 씹었다. 고기는 씹어야 맛이지라~!!

Moment Romantic 레스토랑

Moment Romantic 레스토랑에서 광장가는 길 방향 500m 정도 주변에 많은 공사가 이루어지고 있다.
두번째 숙소 Sapa centre Hotel 주위엔 공사 하지 않는데 그 위쪽으로 많은 공사를 하고 있다.
사파 "첫날 숙소만" 예약하고 도착 후 둘러보면서 다음날 숙소 예약하는 방법도 좋은 것 같다.

이런 경치 좋다 좋아~

마을이 보여 좋다고 찍은 사진. 숙소까지 남은 거리를 애써 외면하며 밝은척 한거다.

cat cat 마을과는 비슷하면서도 뭔가 달랐다. 

세번째 숙소는 방갈로다. ㅋㅋㅋㅋㅋ 대략 6시간의 행군은 방갈로에서 마쳤다.

힘들고 배고파서 더 맛있게 먹은 닭고기 쌀국수!!

이날은 맥주를 못 먹고 잠이 들었다.

인천공항에서 Viet Jet Air 타고 고고

노이바이 항공 도착, 베트남 시각으로 4시 정도에 떨어졌는데 긴 팔 입으면 약간 더운 정도였다.

공항 게이트 나오자마자 눈앞에 보이는 데서 유심이랑 환전을 했다.(파파이스 맞은편)
돈을 정리할 틈도 없이 어떤 아저씨가 어디 가냐고 물어보는것이었다. '아...이게 그 말로만 듣던 눈탱이 택시구나...' 생각이 들며
구글맵으로 나의 숙소를 보여주니 65만동에 숙소까지 가준다고 했다. 50만 동 생각하고 있었는데 큰 차이도 안 나서 탔다.
(배고플 때마다 이 돈을 아꼈으면....하고 두어번 후회했다, 10만 동이면 괜찮게 먹을수 있는데...ㅜㅜ)

출발하자마자 경적으로 시작했다. 자동차 동력원이 경적인 줄 ㅋㅋㅋㅋㅋ 큰 다리를 건너니 슬슬 오토바이가
보이기 시작했다. 경적 최고조에 달함!!
구글맵을 계속 확인하며 이 친구가 잘 가고 있나 확인하다 보니 어느새 도착했다!

그런데!!

환전 받은돈에는 5만동이 안 보여서 70만동을 줬더니 자기한테는 5만동이 없다고 한다.
하....내가 택시 탈때 니가 돈뭉치 들고 있는데 봤는데....뭔 소린가 싶었다.
그걸 설명할 방법은 없으니 다시 돈을 세고 있는데, 본인이 찾아준다며 세고 있는 돈을 가져가려고 하는것이다.
네이버 카페에서 거스름돈 찾는다고 가져가서 몰래 돈을 훔친다는 얘기를 봤다.
나도 모르게 순간 욱해서 'What are you doing? It's my money' 를 외쳤다. ㅋㅋ;;
선의일 수도 있었겠지만 내가 돈을 세고 있으면 손가락으로 가리키는 정도로 하는게 맞는거 아닌가?
(근데 하는 행동으로 봐서는 선의는 절대 아닌것 같다. 그냥 눈탱이)

70만동 주고 지금 나한테 보이고 있는 네 돈 다 달라고 하고 마무리를 지었다.
인생사 새옹지마라고 처음부터 이렇게 눈탱이를 맞으니 남은 일정동안 항상 조심 조심 해서 큰 문제 없이 지냈다 라며
자기 위안을 삼아봅니다;;

숙소 도착해서 체크인 하고 사파 가는 Inter 버스도 예약했다.

Express는 하루에 한대 씩 밖에 없다고 알고 있었는데 Inter는 하루에 두대 있다고 한다.
시간만 맞는다면 Express가 괜찮은것 같다. 가격 차이도 얼마 안나고 돌아올 때 임종체험 한것 생각하면 Express!!!

(Inter는 $12 x 2 왕복, Express는 생각은 나지 않지만 $30 안된던것 같다)

숙소에 짐풀고 샤워 하는데, 어허....물이 안 나온다. 다행히 머리는 안 감아서 끝나가긴 했다.
하루에 $12 개인용 호스텔이었다. 베개에 머리대면 자는 사람이라 숙소가 어지간히 안 좋아도 상관없는데, 어지간히 였다.
악취 안 나고, 냉/난방 잘 되고, 물 잘 나오는거 충족되면 숙소 오케이였는데 뭐 다 안 맞았다.
또 웃긴게 하룻밤 자니까 익숙해졌음 ㅋㅋㅋㅋㅋㅋㅋㅋ

베트남에서 먹은 첫 음식!! Pho 10 쌀국수가 아니라 사진에 보이는 음료수
눈탱이 맞을걸 대비해서 잔돈 만들려고 사먹었던것 같다.

Pho 10 맞은편에 2층 카페가 있어서 쏠랑 들어갔다. 계란커피 먹었는데...와 달다 웰컴 투 베트남 커피!!!

밥도 먹고 커피도 마셨겠다. 슬슬 돌아다녔다. 성당을 찾아서 간건 아닌데 근처에 있었음

면 하나 먹은걸로는 부족했다. 이번에는 길거리 쌀국수 먹음. 와....식기류와 음식 재료 보관상태를 보면 아하...Pho 10 갈껄...
후회 잠깐 했지만 다른 사람이 맛나게 먹은거 보고 홀린듯 먹었다.  
위생상태에 대한 생각은 잠시 접어두는것이 앞으로 일정을 위해 좋은것 같아 접기로 했다.

공원에서 멍도 때리고 산책도 했다. 날씨는 선선하니 좋았다 :)
삼삼오오 모여 제기(?) 차기 하는걸 보는데 소림축구가 생각났다. 

위에 2017 사진 기준 북서쪽으로 가면 카페가 있다.
원래는 콩카페 간판이 보여서 들어가려고 봤는데 입구를 찾지 못해 맞은편 하이랜드로 갔다.
낮에 다시 와서 보니 중고서점(?) 옆에 좁은 입구가 있다.

하이랜드 커피 한 모금 했는데 와!!!!!!!!!! 엄청 달다!!!

줄다리기도 하고 공연하는 것도 구경하고 벤치에 앉아서 내 인생도 생각하고 숙소로 돌아갔다.
몸에 물을 칠하고 머리에 물을 묻히고 후다닥 해서 샤워도 깔끔하게 하고 첫날을 마무리 지었다.

둘째 날

호스텔에서 제공하는 조식을 먹고 호아로 수용소를 가기로 했다.
우연히 앉게 된 카페였는데 너무 좋았다. 앞에 보이는 작은 의자에 앉아서 오거리를 지나가는 자동차, 오토바이 사람들의
무질서 속에 질서들을 바라보며 매연도 마시고 커피도 마시는 좋은 시간이었다. (정말 좋았다!!)
Aha 카페

연유를 퍼서 커피에 타 먹는다

Aha에서 오른쪽 골목으로 쭉~~ 내려가면 

반미가게가 있다. 하노이 맥주랑 쳐묵쳐묵 했는데 꿀맛. 반미 사랑해요~~~
책은 왜 있냐면 ㅋㅋㅋ 전에 한번 국내 2박 3일 혼자 다녀본다고 속초를 갔었는데 너~~~~무  심심해서
다음날 새벽 버스를 타고 집에 온적이 있었다. 이번에도 그럴것 같아 책 한권을 고민하다가 선택한 책이다.
이번엔 해외라 그런지 덜 심심하긴 했는데 생각만 너무 하거나 멍때리는것도 힘들때 사용했던 아이템이다.
(여행기간동안 완독했음!!!)

가는 길에 성당 다시 들리고~

성당에서 더 내려가면 공원(?)이 있어서 벤치에 앉아 쉬다가

호아로 수용소 도착했다. 우리와 비슷한 역사를 가긴것에 동병상련을 느꼈다.

수용소에서 다시 호수 공원!!

오토바이에 아이 4명을 태운다던지, 3인 가족이 탔을때 뒷 사람이 안고있던 아이가 자고 있는 모습은 익숙해 졌는데
새로운 모습을 보게되어 찍었다. 자전거 배달을 해야하는데 마땅한 운송수단이 없었나보다.

어제 못갔던 2층 콩카페!! 메뉴에 있는 그림보고 땡기는거 골랐는데....오 맛있다!!

뭔가 아쉬워서 사이공도 한잔!!

좀 괜찮은걸 먹으려고 가는길에 다시 호수

두 메뉴 모두 맛있었다. 새우튀김은 너무 바삭해서 입천장이 까진건 비밀!!

메뉴 설명에 Egg 써있어서 시키고, Shrimp 써있어서 시켰으니 어떻게 먹는지 당연히 모르지.

반쎄오를 따로 따로 먹고 있으니까 직원이 한번 보여준다며 다가왔다.

여기서 재미 포인트는 위생장갑을 한손만 착용했다. 위생장갑 낀 손으로 쌈을 잡고있고 
맨손으로 사진에 보여지는 야채(?)도 뜯고 쌈 싸다가 떨어진 재료도 다시 줍고 하는 모습 :)  
마지막에 쌈을 단단히 싸려고 주물럭주물럭하는데 너무 진지 했다.    이럴거면 아예 위생장갑을 끼지 말지!!! ㅋㅋㅋ

맛 없으면 빈정 상할뻔 했는데 너무 맛있어서 기분좋게 마지막까지 긁어먹었다.

다음날 사파 가는 픽업 버스가 7시에 호스텔 앞에 온다고 해서 이날은 11시도 안 되서 잤다.
물론 맥주 2캔과 함께...ㅋㅋㅋㅋㅋ

올 1월 갑자기 해외를 가고 싶어졌다. 그동안 나름 열심히만 달렸던 나에게 휴식을 주고 싶다랄까 ㅋㅋ

정말 혼자가 되어 생각도 많이 하고 싶었고,
알차게 꽉꽉 눌러담아 시간을 사용하는게 아니라 여유있게 좋은거 보고 먹으면서 지내고 싶었다.

작년에도 해외간다고 주변사람들에게 말하고 다녔는데, 나의 의지박약/결정 장애때문에 무산됐다.
올 초에도 해외여행 생각을 동생한테 얘기하니 '이번에도 말만하고 안가려고?' 하는 말에 욱한 마음에 지른것도 있다.
고마워 동생~ (간다고 했을때 많이 도와준것도 동생이다, 여벌 옷/속옷, 비자 제외하고는 모두 동생것 ㅋㅋㅋㅋㅋㅋ)

한국오면 바로 기록하려고 했는데 귀차니즘으로 일주일이나 지났다. 시간이 더 지나면 생각도 나지 않을것 같아
정신 차리고 적어본다. 시간순으로 먹고 본것 생각한것들 적고, 언젠간 보면서 흐믓한 표정으로 '아...그땐 그랬지...'
할 용도이다.    2월 18 ~ 2월 25일 6박 8일간의 생활이다

1월 21일 갑자기 해외 가고 싶어짐, 초심자가 혼자가기 나름 괜찮은 베트남으로 결정!!
             

1월 23일에 팀원과 얘기해서 휴가 5일에 대한 얘기

하노이, 사파 두곳만 바라보고 갔다

자 이젠 출발!!

평소 데이터 저장소 관련해서 CockroachDB, ArangoDB와 RethinkDB를 관심있게 보고 있었습니다.
CockroachDB는 확장성과 Consistency를 ArangoDB는 다양한 모델 지원(K-V, Doc, Graph), RethinkDB는 real time 을
무기로 본인들의 DB가 좋다고 내세웠다. (순전히 저의 생각이에요.)

어느날 RethinkDB가 shutdown 했다는 트윗을 보게 되었습니다. 기술적으로 꽤 괜찮았다고 생각했는데 
어떤 이유로 문을 닫는지 궁금해서 관련 글을 찾아보게 되었습니다.

부족한 영어지만 찾은 글들을 정리해보려고 합니다.

https://rethinkdb.com/blog/rethinkdb-shutdown/

공식 홈페이지 블로그에 올라온 shutdown 된다는 얘기, 기술력은 꽤 괜찮았지만 적당한 비지니스 모델을 못 찾아서

shutdown 했다는 얘기와 Stripe에 합류해서 오픈소스로서 RethinkDB를 진행한다는 얘기를 하고있다.

Why RethinkDB failed  ***** 별 다섯개!!

※ 원래는 읽어보고 기억에 남는것만 적으려고 했는데 읽다보니 한줄 한줄 정말 저에게 도움 되는 내용들이 많아서
안되는 영어지만 의역을 하였습니다. (뭐 반 이상은 구글 번역기가 해주었지만요...)

생략하기도 하고 제가 틀리게 해석한 부분이 있을수도 있으니 여기서는 느낌만 가졌으면 좋겠습니다.
오역이 있다면 알려주세요.

Summarizing RethinkDB why we failed  

Rethinkdb joins linux foundation

CNCF가 RethinkDB를 사면서 라이센스가 ASLv2로 변경됐다는 것과 기존 Github이나 웹페이지, SNS계정들은 계속 운영 됨을
얘기하고 있다. RethinkDB가 shutdown 되면서 RethinkDB 직원든이 Stripe에서 일하게 됐고, 그곳에서 RethinkDB
오픈소스 참여를 통해 지속적으로 발전 시킨다고 한다. 곧 2.4를 릴리즈 하는데 2.5에서는 개발자들이 좀 더 다가가기 쉽게 코드를 개선하는것을 최우선으로 하고 Legacy코드와 기술 부채 제거 하면서 성능 향상이 목표라고 얘기 한다.

https://www.joyent.com/blog/the-liberation-of-rethinkdb

함께 만들어가는 입장에서 AGPL의 문제점을 설명하고  CNCF에서 RethinkDB의 지적재산권(?)을 샀다는 얘기
그리고 Apache Public License 2.0. 로 변경했다는 얘기를 전한다.

RethinkDB meeting Note

라이센스에 관한 설명

RehinkDB is dead long live RethinkDB

Social Tables 서비스를 운영하면서 MySQL 적용했을때의 단점을 얘기하고 Rehink로 옮겼을때의 장/단점을 언급한다.

RethinkDB의 단점이 큰 문제가 아니라는 점을 언급하고 오픈소스가 주는 자유의 힘, 그리고 참여하고 싶다는 얘기로 마무리 한다.

RethinkDB vs Postgres

해당 포스트와 거리는 멀지만 RethinkDB를 잘 사용하다가 shutdown과 license로 인해 PostgreSQL로 전환한 얘기가 흥미로워 추가했다. (※ PostgreSQL에 notify, listen이 있는건 처음 알았네요.)

스타트업을 그만두며 깨달은 3 가지 (이 글도 관련있는 글이라 첨부해봅니다. ㅎ)

※ 내 생각

3년 전 부터인가? 기회가 된다면 1인 기술회사 운영을 막연하게 생각"만"하고,
주위 사람들에게 말하고 다녔습니다. (사회 초년생때 만난 송상욱 형님 영향이 크다고 생각되요.ㅎ)
위에서도 말했지만 저도 기술력만 뛰어나면 마케팅이나 투자 없이도 성공할수 있다고 생각했습니다. 

제프딘이나 더그 커팅, 존 카맥 정도는 되야 앞의 문장이 성립하고,
그게 아니라면 기술뿐 아니라 비즈니스도 뒷받침 되어야하는걸 이제야 알게되었습니다. (참 빨리도 알았네요;;)
(각자 생각하는 성공의 관점에 따라 다르겠지만 돈 많이 버는것, 생존 이후의 step)

더군다나 최근에는 굉장히 멋있는 설계와 꽤 괜찮은 기술을 썼다고 성공 하는것도 아니고, 10년 전 기술을 사용하고
아슬아슬한 설계라고 해서 성공 못하는것도 아님을 깨닫고 있습니다. 

제가 생각했던 시장이 그다지 좋지 않다는것도 알게 되었구요. 단순한 지적 호기심과 인기에 따라 움직이지 않고

제가 잘하는건 무엇이고 지금 해야할 것들을 잘하는 것과 어떻게 연관시킬수 있을지 항상 고민하고 실행 해야겠습니다.

값진 경험을 잘 정리해준 RethinkDB 아끼고, 오픈소스 만세~~~~~

ps:
"Done is better than perfect. 수 백번의 이상적인 생각보다 한번의 실행이 변화의 시작이다."
다양한 요구사항을 손쉽게 수정할수 있고 멋진 설계를 하는게 당연히 좋지만
정해진 시간 안에 완성 하는게 최우선되어야합니다.
주어진 시간 안에 요구사항을 충족하는 동시에 나름 괜찮은 걸 만들수 있도록 많은 연습을 해야겠습니다.

X 같은 프로페셔널리즘 (이곳에서 말하는 프로란 허용할 수 있는 품질을 주어진 시간안에 만들수 있는 사람을 말한다.)

1. 바쁜 출근길에 생기는 커피 주문, 접수 그리고 만들기. 마지막으로 커피 마시기를 예를 들면서
역할과 책임 그리고 협력에 대해 설명한다.

선생님이라는 역할은 학생을 가르칠 책임, 경찰관이라는 역할은 범죄자를 검거할 책임 이런 느낌

각자의 역할과 책임이 명확한 상태에서 협력을 통해 사회를 이루듯, 객체도 역할과 책임이 "명확"하고 그 상황에서
메시지를 통해 다른 객체와 협력을 이룬다.

2. 엘리스가 문을 통과하기 위해 음료수 마시거나, 케익을 먹거나, 부채질을 하면서 키를 변경하는 예를 들면서
상태와 행동에 대해 설명한다. 

이때부터 '자율적인 객체'라는 말이 자주 나온다. 왕과 모자장수 얘기를 하면서도 객체의 자율성을 저해하게 되면(예를 들어
증언하라!! 가 아니라 '목격한 것을 떠올려라', '떠오르는 기억을 시간 순서대로 재구성하라'으로 자율을 제한)
결합도가 높아지고 재사용성, 유연성이 떨어진다. 모자 장수는 증언을 할 책임이 있는거지 목격한 것을 떠오를 책임,
기억을 재구성하는 책임이 있는게 아니다.

키포인트!! 객체가 현실세계를 반영한다고 대부분의 책들이 설명하는데 잘못 되었다고 얘기한다.
현실세계에서는 트럼프가 스스로 뒤집을 수 없고, 토끼가 뛰어다닐수 없다는것이다.
객체는 현실 세계를 바탕으로 한 '은유'를 통해 묘사한 것이라고 정의한다.

3. 지하철 노선도와 엘리스가 '기껏해야 트럼프에 불과해'라는 명대사를 예로 추상화를 얘기한다.
이때 golang의 duck typing이 떠올랐다.   어떤 것이든 꽥꽥이라고 울고 두발로 뒤뚱뒤뚱걸으면 오리로 판단하는것이다.

또한 추상화는 '증언하라'와 같은 수신자에게 최대한 자율을 존중하고 책임에 맞는 메시지를 만들기 좋다.

golang 으로 만나보는 duck typing

4. 객체를 만들때 객체에 초점을 맞추지 말고 어떤 메시지를 주고받으며 협력할지, 

그리고 각각의 메시지가 어떤 객체에 알맞은지 생각해서 해당 객체의 인터페이스로 만들어라!!  (What / Who)

이때 메시지는 너무 상세하면 안된다는 점!!  상세하면 객체의 자율성이 크게 줄어들고 그렇게 되면 객체 수정시 영향받는곳이 많아진다. 최대한 외부에 노출되는것을 적게하여 고객의 자주 수정되는 요구사항에 유연하게 대응한다.

기능 중심의 접근법이 아니라 안전한 구조 안에 기능을 입히는 방식으로 생각하는것을 추천한다.

마지막으로 "함께 모으기"는 도메인 모델 부터 인터페이스 정하기 그리고 실제 구현을 한다. 

지금까지 언급한것들을 하나하나 실제 적용해 간다. 

이때 꿀팁이 하나 나오는데 도메인 모델이나 인터페이스 계획에 너무 많은 시간을 쏟지 말고, 빨리 코드로 옮겨보고
계획한게 맞는지 검증하고 그렇지 않은 부분은 수정하는 방식으로 하라고 한다.

객체를 아직도 모르지만 새로운 관점으로 생각할수 있게 해준 고마운책이다. (정말 오랜만에 책 완독했는데 이 책이라 좋다!!)

1년전쯤(?) golang tip이라며 올라온 트윗글로 마무리를 한다.

전에 봤을 때와는 다르게 책을 읽고 다시 생각하니 확 닿는다.

간만에 쉬는 시간을 갖게되어 branch  전략이나 커밋 메시지, 코드 컨벤션에 대해 다른 사람들은 어떻게 했는지 

살펴보고 정리 하려 한다. (그동안 정말 구현하기에 급급...ㅜ,ㅜ)

우선 이런 마음가짐으로 팀원과 맞춰가자

빡빡하게 하나부터 열까지 규칙을 정하는게 아니라, 널널하게 하자. (말이 애매한데, '굵은것만 정하자...' 정도로 생각함) 실력이 있다면 조금 다른 규칙도 충분히 이해가 되기 때문에 그렇다. 조금 달라도 익숙해지도록 노력 하고, 정~~말 익숙하지 않으면 불편하다고 생각되면 같이 얘기해서 수정해 나갔으면 좋겠다. 상대방을 존중하고 각자 발전을 원하는 개발자들이니까!! 존중과 신뢰. 그리고 코드만 얘기해야지 사심이 들어가지 말자.

. 코드 리뷰

토스랩] 코드리뷰, 이렇게 하고 있습니다.

김포프] 올바른 코드리뷰 프로세스

김포프] 코드 몽키를 위한 코딩 스탠다드 

Realm] Codereview HowTo

Github] Using Pull Request

. 커밋 메세지

http://www.laurencegellert.com/2013/07/how-to-write-a-proper-commit-message/

https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message

http://chris.beams.io/posts/git-commit/

. JIRA 이슈단위로 움직이므로 HEAD에 이슈번호 붙이기

. SUBJECT는 50자, BODY는 72자 넘지 않도록 하기
    (SUBJECT에 '.'찍지말라는데 이유는 한자한자가 아까운데 그걸 왜 쓰냐 정도,
      50, 72숫자가 나온 이유는 git 만든 Linus가 권고 했다함 -_-;;)

. Github에 JIRA서비스 연동해서 full url을 적지 않아도 이슈 번호로만 JIRA 연동되도록 하기

. 상대방이 커밋 메시지를 읽은 후 코드 봤을때 이해가 쉽게 되도록 해야한다는 배려심

. 코드 규칙

. 현재 nodeJS, Java, Scala를 사용하고 있다. 많은 사람들이 인정한 코드 컨벤션을 따르기로 한다. IntelliJ config로 만드는 작업 필요
. NodeJS는 airbnb, Java는 Google, Scala는 Scala doc, databricks 

이 글을 작성하면서 다시 한번 느낀건 상대방 존중과 배려가 함께 해야한다는 점.

와~!!! 콘솔쉘 마무으리!!!

키보드, 인터럽트, 타이머에서 원하는 동작을 하기위해 해당 포트에 정의된 데이타를 주고 받는다.
디바이스 드라이버에 대해 자세히는 몰라도 대략적으로 어떻게 코드를 짜야되는지 맛을 봤던 좋은 시간이었다.

읽을때는 이해했는데 시간 지나고 다시 읽으려고하니 기억이 나질 않는다. 양도 많고, 기억력도 썩 좋질 않아서...
4부 가기전에 1, 2, 3부 정리 좀 하고 가야지

하나 아쉬운건 CS, DS와 실제 코드나 데이타가 메모리에 올라가는 관계에 대하여 명확하지가 않다...

써놓고도 뭔말인지...우선 직진이다!! ㅋㅋㅋㅋ

아~!! 드디어 IA-32e 모드로 넘어갔다.

의지가 약해서 듬성듬성 하다보니까 오래걸렸다. 이젠 놀만큼 놀았다고 생각해서 우직하게 준비해야되는데 동기부여가
아직 덜 됐나보다. ImageMaker때문에 이틀정도 걸렸다... WriteKernelInformation 함수에 lseek부분에서 오류가 발생!
이틀동안 삽질하다가 포기하는 마음으로 #include <unistd.h> 추가해줬더니 정상동작했다!! : )

asm이나 간단한 C소스는 직접 입력했는데 ImageMaker, makefile, elf_xxx.x파일은 복붙했다.   앞으로 뭐가 있나 다시 봤는데...타이핑하는게 더 줄것같다ㅋㅋㅋㅋㅋ

10장에서 IA-32e 모드에 스택을 지정하는 부분이 있는데 Stack segment 를 0x10으로 설정하고 주석은 다음과 같았다.

; 스택을 0x600000~0x6FFFFF 영역에 1MB 크기로 생성

응!!  0x10이랑 0x600000 은 뭔 관계지? 했는데 딱맞는 글이!!  http://jsandroidapp.cafe24.com/xe/4588

즉 16비트 리얼모드만 하한선을 정하고 32/64에서는 의미없다. 0x10은 세그먼터 셀렉터의 개념으로 

세그먼트 디스크립터를 가리킨다.

2015년 1월 초에 unstable에 merge된 QuickList에 알아본다.

https://matt.sh/redis-quicklist 에서 나온 얘기를 조금 하고 코드를 보자

Redis에 List 자료구조는 일반적인 Linked list와 메모리를 절약을 위한 Ziplist두개가 있다.

포인터를 이용하여 리스트 구현한것과 배열을 이용하여 리스트를 구현한것이라고 생각하면 쉽다.

list-max-ziplist-entries 512
list-max-ziplist-value 64

(노드 갯수가 512개 이상 || 저장하려는 값의 길이가 64 byte 초과)면 Linked list로 저장이 되고

(노드 갯수가 512개 미만 && 저장하려는 값의 길이가 64 byte 이하)면 ziplist로 저장이 된다.

재미진건 ziplist -> Linked list변환은 되는데 Linked list -> ziplist 변환은 안된다.
(하긴 511개 노드였을때 넣다뺐다 하면 변환하다가 끝나겠네...그리고 추가전에만 타입 변환 검사 한다.삭제할때는
검사 안함)

http://dol9.tistory.com/187

Linked list의 장점은 추가/삭제가 쉽다는 점이고, 단점으로는 작은 값(예:4 byte)을 추가하는데 실제 값보다
더 많은 메타데이타?(예: prev, next 포인터, 8 byte)를 사용한다.

Ziplist의 장점은 내부적으로 포인터를 안써서 메모리 절약이 된다는 점이고, 단점으로는 리스트 중간에 노드를
추가/삭제를 하게되면 메모리 재할당, 복사/이동이 일어난다.

2014년 2월 3일에 봤을때 Redis에 리스트 자료구조는 QuickList만 사용한다.

https://github.com/antirez/redis/pull/2143 QuickList에 대해 정말 활발한 리뷰 오고가는걸 볼 수있다.
(재밌겠다~~~~~!!!!)

각 노드를 ziplist로 구성하고 적정 크기로 유지하면서 각각의 노드는 포인터로 연결하는 자료구조 그게 QuickList이다.

[ziplist 0] <-> [ziplist 1] <-> ... <-> [ziplist N]

데이타를 ziplist에 추가하다 조건이 충족되면 노드를 하나 더 생성해서 새로운 노드에 데이타를 저장하거나 노드를
split한후 데이타를 저장하고 Merge하는 작업을 한다.

재미진건 ziplist에서 더 아끼기위해 압축을 한다.

QuickList에 대해 대략 알아봤으니 궁금한 부분을 나열하고 그에 대해 알아보자

. 데이타 traverse

. 데이타 추가할때 동작

. Compression의 동작과 발생 조건

. Decompression의 동작과 발생 조건

. 노드 Merge 동작과 발생 조건

. 노드 Split 동작과 발생 조건

로 나눠서 하면 좀 간단하지 않을까 했지만 결국엔 주저리 떠드는걸로 됐음

. 데이타 traverse

pop이나 push명령이 아닌 중간에 있는 노드에 작업을 해야할때가 있다.

기존 ziplist, Linked list는 하나하나씩 노드 곱씹어가며 index 도달할때까지 이동하는데

QuickList는 quicklistNode->count에 ziplist의 데이타 갯수가 저장되있어서 마치 skiplist처럼 탐색을 한다.

. 데이타 추가할때 동작을 보기전에 관련 설정값을 알아보도록 하자

list-max-ziplist-size는 한 노드의 ziplist 최대 크기또는 최대 갯수를 정한다. -5~-1은 최대 크기(byte),
양수는 최대 갯수를 의미한다. 1로 해놓으면 성능 더 안 좋은 Linked list라고 보면 된다.

list-compress-depth는 head, tail부터 안쪽으로 이동하면서 압축 하지 않을 노드의 깊이를 정한것이다. 
compress에서 다시 보자.

데이타 추가전에, _quicklistNodeAllowInsert 함수로 해당 노드가 가득찬 상태인지 아닌지 판단한다. 

그리고 추가되는 위치가 ziplist의 처음이면서 정방향인지, ziplist의 마지막이면서 역방향인지도 판단한다. 

총 6개로 구분해서 추가 로직을 구현했는데 간단하게 알아보자

대부분의 분기문에서 해당 노드를 decompress하고 데이타 추가 작업후 compress를 한다. 

얼마나 안타까운 현실인가 LINSERT 명령어는 자제 해야겠다.
비즈니스상 꼭 필요한 거라면 list-compress-depth를 0으로 사용해서 압축을 안하던가...

. 노드 Merge 동작과 발생 조건

. 노드 Split 동작과 발생 조건

발생조건은 데이타 추가에서 알아본 6개의 분기문중 마지막 분기문에서 split과 Merge가 발생한다.

노드 Merge할지 말지 결정할때 사이즈를 구하는데 11을 빼는이유는 ziplist Header사이즈 제거
(두 노드중 한 노드는 header 필요없음)

[A]<->[B]<->[C]<->[D]<->[E]

Merge 는 기준이 되는 노드를 인자로 받아 A/B Merge , D/E Merge , B/C Merge , C/D Merge 가 발생한다.(쉽게 설명한 감이 있음, 사실 앞에서 Merge 가 발생되면 달라짐)

Split 은 동작이 단순 무식하다. split할 노드와 동일한 노드를 새로 만들어서, 

한 노드는 (offset+1)~끝까지 지우고 다른 하나는 0~offset까지 지운다.

. Compression의 동작과 발생 조건

ㄴ 노드 생성하고 기존 노드에 포인터 연결후 기존 노드 compress

ㄴ LSET 명령으로 값 수정 후 해당 노드 compress

ㄴ 노드 merge 할때 count가 큰 노드 compress (ziplist 합치는 작업시 작은 ziplist가 큰 ziplist에 merge된다.)

ㄴ iter 사용후 release할때 iter에서 가리키고 있는 노드 compress

ㄴ A <-> B 노드가 있고 iter가 A의 ziplist 마지막으로 가리키고 있을때 Next 실행 시 A 노드 compress
(iter가 B의 ziplist 처음을 가리키고 있고 Prev 실행시 B 노드 compress)

compress는 두가지 방법으로 한다. 하나는 인자로 들어온 노드만 compress하는 방법이 있고,

다른 하나는 list-compress-depth 변수를 이용하는 방법이 있는데 다음과 같다.

list-compress-depth=2, 인자로 들어온 노드=[E] 

[A]<->[B]<->[C]<->[D]<->[E]<->[F]<->[G]

바깥쪽에서 안쪽으로 list-compress-depth만큼은 compress 안하겠다는 말인데,[A], [B], [F], [G] 노드를 decompress하고 [E]를 compress한다
아...이건 설명하기 참 거시기 하다. compress 방식을 두개로 나눈 이유는 decompress 에서 알아본다.

. decompress의 동작과 발생 조건

ㄴ 노드 compress 작업할때 decompress

ㄴ 두 노드 Merge 할때 두 노드 decompress

ㄹ 데이타 삽입시 노드 decompress

ㄹ 데이타 삭제시 노드 decompress

ㄹ로 되어있는 발생조건이 ㄴ과 다른건 recompress값을 1로 대입하는것 말고는 없다.
차이는 해당 노드만 compress할것이냐, 아니면 compress 두번째 설명한 방식대로 할것이냐 차이다.
ㄹ조건을 보면 데이타 추가/수정/삭제인 경우이다. matt의 섬세함이 느껴졌다.
한번 decompress/compress 한 노드이니까 굳이 할 필요가 없는거지...

따라가기도 버거운걸 코드로 표현한 matt...참 대단하다 난 QuickList 자료구조만 알아본건데
aof, rdb등 전체적인 구조 다 수정 했을텐데...무서운사람....덜덜

antirez가 활발하게 커뮤니케이션 하는거 처음봤다. 부러움이 넘쳤다, 재밌겠다 ㅜ,ㅜ.
영어로 내 의견 쓸 정도는 되야하는데...

기승전 자기반성 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ