달력

112017  이전 다음

  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  

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도 익숙해져보자 (제발~~~)




저작자 표시 비영리
신고
Posted by 오산돌구

여섯째 날

전기장판 2단으로 켜놓고 잤더니 '침대 밖은 위험하다'는 생각이 절로 들어서 이 날은 늦게 일어났다. (7시 거의 다 되서)
조식으로 팬 케이크 먹고 다시 숙소로 들어왔는데 창문 밖으로 보이는 풍경이 너무나 이쁜거다.
창문 밖을 바라보며 이를 닦고 있자니 영화 이끼의 이장 모습이 생각나서 피식피식 웃었다.

조식으로는 나의 굶주린 배를 채울수가 없어서 커피랑 간단히 배채울 요량으로 20만 동을 주머니에 넣고 광장으로 갔다.
사파 마지막 날이라 새로운걸 먹어 보려고 Moment Romantic 레스토랑을 지나쳤다. 걷다보니 호수까지 도착해서
돼지 바베큐를 구경하다 나도 모르게 가게 안으로 들어 갔다.

음식 이름만 있고 가격이 안 적혀 있어서 가장 만만한 롤을 주문하고 가격을 물었다. 12만동이라 한다.(어렴풋한 기억으로...)
'응? 이 돈이면 어제 점심같이 먹을 수 있는데 뭔가 대단한건가 보다' 라며 기대했는데, 정말 12만동어치 평범한 롤이었다.
친절하게도 밥도 주셔서 정말 배터지게 먹었다.


하노이 가는 버스는 4시 였는데 checkout 시간 때문에 11시에 나와 사파 여기저기를 걸어 다녔다.
아래 사진은 방문객이 지켜야할 규칙

11시 넘어가니 배 고파서 눈에 보이는 반미 집에서 먹었는데 오!! 여기는 주문하면 그때 오븐에 빵을 굽는다!!
멋도 모르고 한입 크게 물었다가 많이 뜨거웠다. 사파에서 반미는 여기 추천!!!

아래 사진에 보이는 Inter 버스 건물 기준으로 왼쪽 길로 조금 걷다 보면 건물안에 반미 집이 있다. 만동이었던걸로 기억!!
남자 분이 장사를 하고 여자분이 건물 안에서 재료랑 빵 세팅을 한다.

12시가 되니 더위지기 시작했다. 더위도 식히고 버스 탈 곳/예약 확인 할겸 Inter 버스 건물에 들어갔다.
아하~ 예약 잘 되었고, 건물안에 들어가니 시원했다. 
조금만 쉬다가도 되는지 물어보고 의자에 앉아 있었는데, 갑자기 와보라고 한다. '1시 버스를 탈수 있는데 탈래?'
와우!!! 고마움을 표시하고 다시 기다리고 있는데 배고팠다. (이땐 몰랐지 맨 뒤에 탈줄은...)
시간이 조금 있어서 근처 밥집 들어가서  일반적인 밥을 먹었다. 와... 밥 양 보고 깜놀

버스 중간 어딘가에 앉았는데, 너의 자리는 그곳이 아니라며 따라 오란다. 으악!! 세상에나!! 하노이에서 사파 올때는
천국이었구나...느낄 정도로 세상 불편했다. 다리는 사진 처럼 약간 구부려야 되고, 천장은 눈 앞에서 아른 거렸다.
그~~나마 다행인건(그래도 버스 회사에서 양심은 있나보다) 자리는 5개인데 4명만 태웠다;;;
승객이 몇 명 안 왔는지 출발도 늦어져서 2시에 사파를 떠났다. 
늦은 사람들이 미웠는데, 너무 불편하니까 출발한 지 얼마 안 돼서 미운 마음이 사그라들었다.

하노이 숙소에 짐 풀고 바로 쌀국수 먹으러 갔다.

이젠 익숙하겠지만 국수로는 부족해서 반미와 맥주 사서 숙소에서 먹었다.



일곱째 날

베트남의 마지막 날이다. 조식은 간단히 먹고 반미를 먹으러 가려고 했다. 하지만!! 가는 길에  사람들이 거리에서 무언가를
맛나게 먹고 있길래 바로 앉았다. 죽에 공갈빵(?)을 잘라서 준다. 보기에는 별거 아닌것 같은데, 생각보다 맛있고
"가벼운" 아침으로 괜찮다. 

죽 먹으니 어느정도 배가 차서(잠시나마) 다시 숙소에 왔다. 
온 김에 숙소에서 사진을 찍었다. "Hanoi Sky View Hotel"
입구에 찍은 사진

문을 열면 바로 도로와 하늘이 보인다. 나름 sky view!!!

사파 방갈로 숙소 머물때 쌀국수를 먹고있는데 옆 테이블에 있던 여행객들이 하노이의 오바마 분짜에 대해 얘기하는걸
엿들었다. (엿들었다기보다는 소리가 원체 커서 뭐...)
먹으러 고고~ 생각보다 숙소에서 멀었다. 공원에서 한 타임 쉬었음 ㅋㅋ

마치 포켓몬 고 하듯이 근처까지 잘 찾아갔는데...아뿔싸! 분짜 가게 옆에 있던 쌀국수 가게로 들어갔다.
메뉴는 하나인 듯 하다. 뭐 정신 차려보니 내 눈앞에는 쌀국수와 공갈빵이 있었다.(공깔빵은 슬슬 질렸다. 안 먹는다는 표시를
했으면 됐는데 마지막 날이라는 환상 때문에 클리어!!)

배 불러서 동네 한바퀴 돌고 오바마 분짜로 들어갔다!! :) 아...여기 진짜 맛있다!!!! 쌀국수를 먹어 배부른 상태였는데도
맛있으면 뭐 말 다했지...ㅋㅋ
만약 하노이를 또 가게되면 여긴 꼭 갈듯!!

숙소 가는길에 콩카페 들러서 커피 한잔 때리고~!!

다시 공원으로 와서 바람 맞으며 멍때리기!!

체크아웃 하고 나오는데 앞에서 결혼식을 하고있었다. 색다른 모습에 두리번 두리번 하다가
폭죽을 거하게 쏘았는지 길거리 난리난거 보고 피식 웃으며 반미 가게로 걸음을 옮겼다.

둘째날 갔던 반미가게 다시 갔다. Chic&Be Bread - Banh Mi
이 날은 가장 저렴한걸 먹었는데 아쉽다!! 그냥 고기 들어간거 먹을껄...

한국 가면 콩카페가 그리울것 같아서 처음으로 성당 앞에 있는 콩카페를 가봤다. (가까워서...)
개인적으로는 지금까지 갔던 2층짜리 콩카페가 괜찮은것 같다.

콩카페 들고 공원가서 또 멍때리기 ㅋㅋㅋㅋ

집에 가려는데 또 사람들이 맛있게 먹는거 보고 사 먹었다.. 이름은 모르겠는데 달짝 지근하니 맛있다.

오거리를 바라보며 먹는 커피도 그리울것 같아 aha 커피를 갔다. 바닥에 깔린 연유....그립다 ㅜ

시간도 많이 남아서 4시 즈음에 E3.3에 가서 17번 시내 버스 탑승!!
내 상상으로는 버스가 하노이 시내를 거쳐 공항으로 가는걸로 알고 있었는데, 롱빈(?) 으로 가서 초반엔 살짝 겁 먹었다.
하지만 표 끊는 아저씨한테 재차 확인을 하고 안심하며 고고!!

버스에 내리면 바로 보이는 공항 모습[나는 여기서 비행기 타면 되는줄 알았다...)

베트남의 마지막 쌀국수.jpg 아...여긴 공항 쌀국수도 맛있구나 ㅜ,ㅜ

국내선 공항에서 아무리 찾아도 내가 인천에서 하노이 올때 봤던 풍경을 볼수 없어 살짝 당황했다. 하지만
내릴때랑 탈때랑은 다른건가보다며 자기 최면을 걸고 오후 6시까지 의자에 앉아 있었다. 
아무리 봐도 이상해서 Info에 물어보니 국제선은 여기서 검은 버스를 타고 가야 한다고 한다. 공짜!!!
(길 모르거나 이상하다 싶으면 바로바로 물어봐야지 괜히 참고 있다가 비행기 놓친다;;)

국제선 공항에 도착하니 하노이 어디 가냐며 호객을 시작한다. 한국으로 돌아간다고 하니 더는 말 걸지 않고 제 갈 길 간다.
공항에서 호객 방어용으로 써 먹으면 좋을 듯 ㅎㅎ 남은 베트남 돈을 다 쓰려고 파파이스도 가고 카페도 가고 마지막으로
편의점(?) 올인!!! ;0  10동도 안 남기고 다 썼다

원래는 새벽 1시 비행기 였지만 1시간 지연 되서 2시에 출발~ 인천 도착해서 구충약 사먹고
짐제로에 맡겼던 잠바 찾아서 집에 가는 버스를 탔다. 이상 베트남 여행기 턴을 마친다.


생각했던 것들 몇개 정리

한계라고 생각했던 것들을 몸을 책상에 묶던 다른건 할수 없는 장소에 가던 해서 끝까지 해보기.
지금 가지고 있는 자원들을 최대한 내것으로 익히기, 지금까지는 흥미/호기심 있는 글이 있으면 훑어보고 
언젠간 읽겠지 하며 notepad나 evernote에 클립했다. 이젠 최대한 줄이고 지금까지 모아놓은 글들을 내것으로 만들기
건강하기. 나만의 칼 갖기. 필요한 곳에 나를 사용하는것이 아니라 나를 필요로 하게 만들기

저작자 표시 비영리
신고
Posted by 오산돌구

다섯째 날

깔끔하게 일어나서 숙소 앞에 있는 자그마한 가든을 산책했다. 하나하나 잘 가꾼 모습이었다.
조식으로 라면을 선택 했는데 계란 후라이를 라면에 올려 주었다. 골탕먹이는건가? 했는데 의외로 맛있었다.
한국에서 한번 해먹어야지... 생각 했지만 지금까지 한적 없다 ㅋㅋ

전날 빨았던 빨래가 덜 말라서 야외에 말리는 동안 가든에서 책을 읽었다. 

11시 즈음 체크아웃을 하고 30분을 걸어 Lao cai 마을을 벗어나 오르막길을 오르려는 그때!!!
바람막이를 입고 있다가 더워서 벗으려는데 한쪽 주머니가 묵직했다....
아....내 주머니가 묵직할리가 없는데...라며 슬며시 주머니에 손을 넣었더니 방갈로 숙소 키가 있었다. 와 쉣!!!!!!!!
30분을 터덜터덜 걸어 숙소에 도착해 'Sorry, it's my fault!' 라는 말과 함께 숙소키를 건네주고
30분을 무념 무상으로 걸어 그 자리에 왔다. 더 생각 없던건 체크아웃 할때 1.5L 물을 사서 1.5L물 들고 다녔다.

Lao cai 마을을 벗어나 큰 길 삼거리에 오면 슈퍼 하나가 보인다.
이대로 가다가는 탈진 할것 같아서 과자랑 해바라기 씨(?)를 샀다. 과자 두개 먹고 출발~~~ 하는데 택시가 내 옆에 서더니
사파 가냐고 묻는다. 가격을 물어보니 10만동을 보여준다.
첫날 눈탱이 택시도 생각났고 돈도 아깝긴 했지만
이번 택시를 놓치면 나는 1시간을, 아니 더 걸릴지도 모른다고 생각하니 아찔했다.
더 생각할것도 없이 10만동 맞냐고 다시 한번 물어보고 나한테 10만동이 잔돈으로 있는지 확인하고 바로 탔다
오토바이를 추월할 때 그 쾌감이란 ㅋㅋㅋㅋㅋㅋㅋ

비록 택시타고 오긴 했지만 어제 오늘 개고생한 나를 위해 푸짐하게 시켰다. 분짜, 토마토 샐러드 그리고 맥주!!
바나나를 서비스로 주셨다.
Moment Romantic 레스토랑 (여긴 사랑입니다)

네번째 숙소 Black H'mong View Hotel
여기도 침대는 두개, 싱글에는 짐풀고 더블에서 잤다. 생긴지 얼마 안 된것 같다. $16불이었는데 가성비 대만족!!!
지금까지 숙소에는 없었던 전기장판이 있어서 간만에 몸 지지며 잤다. 조금 아쉬웠던건 주변이 허허벌판이라 바람이 불면
소리가 굉장히 크게 났다. 잘 때는 머리 대자마자 잠이 들어 큰 문제는 아니었다.

숙소에서 볼수 있는 멋진 풍경

숙소 옆에서 찍은 좋은 풍경 :)

숙소에서 본 풍경, 내가 생각하는 귀농 했을때의 위치라서 사진 계속 찍었다 ㅋㅋ

2시에 체크인 하고 silver waterfall을 걸어갔다 오려고 했다.
구글맵에 3시간 걸린다고 해서 금방 갔다올 줄 알았다.(지금도 왜 이런 생각을 했는지는 모르겠다)
전날까지 선선한 날씨였는데 이날 따라 너~~~무 화창했다.


차가 쌩쌩 달리는 도로 옆을 1시간 정도 걷고 있는데 이게 지금 뭔가 싶어서 다시 숙소 쪽으로 돌아갔다.
패배감이란...그냥 숙소에서 잠이나 잘껄...
(이날 정신 없이 겁다보니 정신없이 탔음, 당일 샤워하는데 목이 따끔해서 봤더니 빨개져 있었다...시무룩)
cat cat 마을 초입이랑 사파 슬렁슬렁 산책하다 숙소로 돌아갔다.

사파에는 오토바이를 빌려 돌아다니는게 좋은것 같다!!!! 다음에 올때는 운전 면허증 가지고 가야지~
(다음날 사파 떠나는데 이런 생각을 했다. 장하다 장해)

호기롭게 3시간 걷는걸 포기하고 돌아가는길에 발견한 캡슐 호텔, 2층을 보면 마치 세탁기가 모여있는것처럼 캡슐이 있다.

커피 마시고 쌀국수 간단하게 한그릇 하고 숙소로 돌아왔다. 

이날따라 건강을 생각해 맥주는 마시지 않고 콜라와 과자 한 봉지!!


저작자 표시 비영리
신고
Posted by 오산돌구

셋째 날


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시간의 행군은 방갈로에서 마쳤다.


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


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

저작자 표시 비영리
신고
Posted by 오산돌구

인천공항에서 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캔과 함께...ㅋㅋㅋㅋㅋ




저작자 표시 비영리
신고
Posted by 오산돌구

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

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

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


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



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

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

1월 25일에 비행기 왕복 구매
2월 14일에 직장 동료에게 비행기 티켓만 산 후 아무것도 안 하고 있다니까 노숙하기 딱이라며,  
                도착해서 하루 잘 숙소는 예약하는게 좋다고 해서 집에서 숙소 예약했다.
2월 17일에 여행자 보험 가입 http://www.travelover.co.kr/
2월 18일 새벽에 여행 가방 싸기


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


자 이젠 출발!!

저작자 표시 비영리
신고
Posted by 오산돌구

평소 데이터 저장소 관련해서 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  ***** 별 다섯개!!


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

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


우리가 RethinkDB shutdown 발표했을 때 저는 여기서 얻은 교훈을 쓰겠다고 약속했었습니다. 

경험들을 정리할 시간이 필요했고 이젠 명확하게 써보려고 합니다.

Hacker News에 RethinkDB shutdown글에 달린 댓글 들을 종합해봤는데 대부분은 실패한 원인이 아니라 증상이었습니다.


나중에 생각해보니 두가지 를 잘못했습니다. 하나는 최악의 시장을 선택한 것이고 다른 하나는 제품 측정의 잘못된 최적화를 한 것입니다. 하나하나 실수는 RethinkDB 가치를 반 토막 냈습니다. 의미 없는 얘기지만 앞에 두가지 중 한가지라도 했다면 우리는 MongoDB 정도 크기의 회사가 됐을 것이고, 두 가지 모두를 잘했다면 RedHat 정도의 회사가 되었을 것입니다.


Terrible Market

신생 기업은 Oracle 기반으로 세워지지 않기 때문에 새로운 인프라 회사로 돈 벌 기회가 있을 거라 생각했고, 
특히
DB 시장은 아주 큰데 이 시장에 맞는 제품을 만들면 우리는 성공한 회사를 만들 거라고 생각했습니다.


불행하게도 우리는 우리가 생각한 시장에 있지 않았고, 우리는 사용자가 생각한 시장에 있었습니다.

RethinkDB 사용자들은 우리를 오픈소스 개발자 도구 회사로 생각하고 있었습니다. 

오픈 소스 시장은 최악의 시장이 소지가 다분합니다. 천 명의 사용자가 RehinkDB 실제 상업적으로 사용하고 있었는데

이들 대부분은 실제 사용한 시간보다 적은 스타벅스 커피 한 잔 값보다 못한 가격을 지불하려고 했습니다. (말하자면 내기 싫었다는 것입니다.)


사용자들이 지원금을 보내지 않을 정도로 제품이 훌륭한것도 아니고, 개발자들이 예산관리를 안 해서도
자본주의가 무너진것도 아니었습니다. 답은 미시 경제학입니다. 
개발자들은 공짜 개발자 도구를 좋아해서 엄청난 수요가 있는데 공급은 그 수요를 훨씬 뛰어 넘습니다.

대체 가능한 도구들이 많다는 것을 뜻하고 그래서 가격은 0으로 수렴한다. 

내용이 어떻게 적용되는지 보기 위해서 $1.6B 가치와 700명의 직원이 있는 MongoDB $1B 가치와 300명의 직원이 있는 Docke 살펴보겠습니다.
회사는 각자의 시장을 완벽하게 지배했습니다. 연봉도 엄청나고 가치도 급성장하고 있습니다. 


굉장히 좋아 보입니다. 개발자 도구 회사가 아닌 시장의 회사들을 보기 전까진….(SalesForce, Palantir 그리고 Box)

그들이 보기에는 MongoDB Docker 굉장히 작아 보일 겁니다. 


회사를 세우는데 이미 파트너십도 존재하고, 유통 인프라, 미친듯이 성장하는 고객들을 보유 했다는것이
지금 시작하는 스타트업에겐 어떤 의미 일까요?


고집스러운 사용자를 모은다는 것을 의미했다. 괜찮은 B2B 시장으로 시작하는 스타트업은 100개의 기회중에 10개의 실제 판매를 한다면개발자 도구 스타트업은 이것의 10배의 기회가 있습니다.
개발자 도구 회사는 우수한 잠재 고객들을 확보 할수 있습니다. - 굉장히 많은 사람들이 당신의 제품을 다운로드 하는것을 의미.
그런데 실제 판매되는건 조롱받을 정도로 낮습니다.


이것은 도미노 효과를 일으켜 피해를 일으켰습니다.
팀의 사기를 떨어뜨렸고 투자 유치하는것과 유능한 인재들을 영입하는것이 어려워졌습니다.

결국 제품 유통에 효과적인 투자를 할 수 없도록 리소스가 제한되었습니다.
스타트업은 살고 죽는것은 한 순간인데, 초기 유통 문제는 대부분 망하는것으로 이어집니다.


Wrong metrics of goodness(잘못된 제품 측정?)

시장이 잘못된 건 알겠는데 다른 개발자 도구 회사들은  나갑니다. RethinkDB 된 걸까요?

시장은 우리가 어떻게 할수 있는 부분은 없지만 제품 결정은 우리가 할수 있었습니다.

우리는 우아하고 강력하고 아름다운 제품을 만들기로 했고 그래서 다음과 같은 측면에 힘쓰기로했습니다.

  • 정확성 : 굉장히 정확하도록 만들었습니다. (그래서 성능이 떨어진다…)
  • 인터페이스 단순화: 구현의 복잡성은 감수 했으므로 사용자가 간단하게 사용하는것에 초점을 맞췄습니다.
  • 일관성: 모든것을 query 만들려고 했습니다. client 드라이버, 설정, 문서 가능한건 모두!!

http://dreamsongs.com/RiseOfWorseIsBetter.html 에서는 3개가 
대부분의 사용자가 제품에게 바라는게 아니라고 말하고 있습니다.


대신 사용자가 원하는 3가지는

  • 원하는게 있을때 그걸 해결할수 있는 제품
  • 빠른 속도: 우리가 제시하는 실 생활의 부하가 아니라 테스트 가능한 범위에 부하 테스트를 견딜만큼 빠르길 원합니다.
    MongoDB는 슬기롭게 해결했지만 우리는 그렇지 못했습니다.
  • 실제 사용기(?): 우리는 괜찮은 DB 시스템을 만들었지만 사용자는 “X 하기 위한 좋은 방법 원했습니다.
    (hapi
    에서 JSON 문서를 저장하는 방법, 로그를 저장하고 분석하는 좋은 방법, 리포트를 만드는 좋은 방법)


3가지를 한건 아닙니다. 하지만....시장에 내놓기 까지 3년이 걸렸습니다.

3 뒤에 시장에 내놓았더니 대부분의 사용자가그래서 RethinkDB MongoDB 다른점이 뭔가요?” 질문을 했습니다.

위에서 나열한 것들의 중요성에 관 설명했지만, 사용자는 신경도 썼습니다.


솔직히 말하면 상처 받았습니다. 엄청 받았어요. 우리는 사용자들이 MongoDB 선택하는지 이해할수 없었습니다.

※ MongoDB 좋은 나열ㅋㅋㅋ


MonoDB 새로운 릴리즈를 출시하면 사용자들은 개선 사항을 보며 축하를 보냈는데, 저 분노를 느꼈습니다

A 수정했다고 했지만, B 성능을 떨어뜨린 거였고, C 기능을 추가했다고 했지만, D 기능을 줄인 것이었습니다.


하지만 시간이 지나자 MongoDB 일반 개발자를 영웅으로 만들었습니다.
저장은 굉장히 빨랐고, 제품 개발 속도도 빠르게 만들어 주었습니다
우리가 원했던 아름다운 제품은 아니었지만, 동작했습니다.


2014 중반이 되자 우리는 MongoDB 경쟁이 되었습니다, 그래서 MongoDB 차별성을 두어 일 했고 굉장히 멋진 방법으로

realtime push 기능을 만들었고 이를 이용해서 이전에는 만들 수 없었던 앱을 개발하기를 바랬습니다

하지만 갑자기 우리가 realtime push를 생각하고 개발하기 훨씬 전부터 realtime push에만 전념했던 

Meteor Firbase 회사가 등장했습니다.

우리는 다시 시장에서 3 뒤처졌고, 우리는 그들과 경쟁할 수 없다는 것을 깨달았습니다.


Cloud 어때?

종종 사람들이 cloud 서비스를 제공하는건 어떠냐는 제안을 했습니다.

우리같은 작은 database 기업이 클라우드를 이용 한다는것은 스트타업의 망하는 패턴과 비슷한 문제가 있습니다.

빌드, 배포, 관리는 매우 어려운데 모든것에 집중을 해야하기 때문입니다.

하지만 우리는 더이상 선택지가 없었고 클라우드를 어떤 형태로 할지 정하기로 했습니다.


datababase 클라우드로 제공하는 방법은 3가지 방법이 있는데, 호스팅 관리, database service형태로 제공, 

아예 플랫폼 형태로 제공 이렇게 있습니다.


호스팅 관리는 이미 AWS가 꽉잡고 있어 쉽지 않습니다. 

Compose.io와 mLab가 RethinkDB보다 두배나 많은 사용자를 지닌 MongoDB를 제공하는것을 고려할때 

호스팅관리는 우리와 맞지 않다고 생각했습니다. 

(※ 제 생각은 MongoDB를 제공하는데도 두 회사 규모가 작은것을 얘기하는것 같습니다.)


DBaaS은 호스팅 관리보다 좀 더 복잡합니다. DB의 깊은 이해 없이도 사용 할수 있도록 추상화된 노드 관리 기능을 

사용자에게 제공 해야합니다. 이것은 사업적으로 굉장히 도전적이었는데, 

1. DynamoDB나 DocumentDB와 같은 거물급들과 경쟁해야 합니다.

2. 대체할 제품이 많이 있는데 사용자가 자신의 데이터를 스타트업에게 맡기는것을 꺼려합니다.
우리는 DBaaS도 제외 했습니다.


마지막 Paas가 우리의 길이라고 생각했는데, 왜냐하면 우리는 굉장한 기술적 우위를 가졌기 때문이었습니다. 

Firebase와 Meteor는 MongoDB위에서 어플리케이션 레벨에서 realtime 로직을 수행했는데, 

이는 대규모 실시간 query 처리량과 성능의 제한을 둡니다.

반대로 우리는 어플리케이션 레벨뿐 아니라 모든 부분을 다뤘기때문에 Firebase와 Meteor는 할수 없는 
특별한 이점을 제공할수 있었습니다.

그래서 우리는 Horizon과 함께 사용자가 Horizon Cloud에서 RethinkDB와 Horizon을 배포하고 

확장이 가능하도록 작업을 시작했습니다. 하지만 작은 팀들이 3개의 대형 프로젝트를 진행하면서 겪는 어려움은 우리를 붙잡았고, 돈이 떨어지기 전에 우리는 cloud로 제공하지 못했습니다. 하지만 엔지니어는 잘 해주었습니다. 거의 완성 단계였습니다.


근본적인 질문

우리는 나쁜 시장을 선택하고, 잘못된 제품 최적화를 했을까요?


어렸을 때 저는 나만의 라디오를 만들고 싶었습니다.
합판으로 박스를 만들고 안에 금속을 집어 넣고 전원선과 박스를 연결했습니다.

그때 집에 전자공학 책이 있었지만 책이 없어도 만들수 있다는 확신이 있었습니다.

마침내 라디오를 만들었습니다. 하지만 전자공학 기초를 배울 필요성을 깨닫는데 몇년이 걸렸습니다.


초기 RethinkDB 사례와 거의 흡사했습니다.
우리는 제품이나 시장에 대한 직관이 없었기 때문에 우리가 해야할지에 대한 정확한 이해 없이 회사를 세웠습니다. 

더군다나 우린 낙관주의자였습니다. 경제 법칙과 회계는 우리와 상관없다고 생각했지만 아니었습니다.


어렸을때 라디오를 만들었을때와 별반 다르지 않습니다. 우리는 사업적으로 서툴렀고, 이것을 깨닫는데 몇년이 걸렸다.


몇몇 사람들은 우리가 go-to-market 팀을 꾸렸다면 지금보다 훨씬 잘했을거라고 얘기합니다다.

초기에 우리는 go-to-marker 전문가의 필요성에 대해 알지 못했고, 그래서 재무팀을 포함해 찾을 생각을 안 했습니다.

우리가 현실을 깨달았을때는 이미 자금이 부족했고, 가뜩이나 어려운 시장에 나가는 경쟁자들,
그리고 우리의 제품이 3 정도 뒤쳐졌다는 것을 깨달았습니다.


세계에서 유능한 go-to-market 팀도 우리를 살릴수는 없었습니다.



맺으며

많은 사람들은 개발자 도구 시장에 대해서 굉장히 강한 인상을 가지고 있습니다. 

엔지니어는 개발자 도구를 만드는것을 굉장히 좋아해서 개발자 도구 회사가 번창하기를 원합니다.


나는 시장을 무시하는걸 망설이고 있습니다. 이유는 3가지인데

한번의 경험으로 이렇게 생각하는것을 바라지 않습니다.

그리고 나는할수 없다라는 말을 싫어합니다.

마지막으로 예외적으로 성공한 회사들이 있습니다. GitHub, MongoDB, Docker같이 나가는 회사도 있고,
GitLab, Unity 같이 해내는 회사 처럼 하는 회사들이 있습니다


만약에 여러분이 개발자 도구 회사를 만들기 시작했다면 신중하세요.  시장은 대체 가능한 제품들로 가득차있습니다.

사용자들은 높은 기대와 낮은 가격을 기대하고 있습니다. 사용자에게 어떤 가치를 제공해줄수 있는지 깊게 생각하세요.

기억하세요 - 세상이 특정 방향으로 흘러가길 바란다고 세상이 그렇게 만들어지지 않는다.


2009 YCombinator 데모데이때 우리는 투자자들에게 RethinkDB 초기 아이디어를 발표했었습니다.
슬라이드에서 기억해야할 3 가지를 얘기하고 발표를 마쳤습니다

“RethinkDB 대해 3가지만 기억해야 한다면”, “이것만 기억하세요라고 말했고, 효과가 있었습니다.

다른것은 기억 했지만, 마지막에 얘기한 3가지는 기억했습니다.


이글에서 기억해야할 3가지 포인트를 남기려고 합니다. 해당 글을 기억해야 한다면 이것만 기억하세요.


시장을 선택하세요. 하지만 특정 사용자를 위해 만드세요

당신이 무엇을 놓치고 있는지 깨닫는것을 배우고, 당신 팀이 얻기위해 지옥처럼 일하세요.

The Economist를 자세히 읽으세요. 이것은 더 빠르게 당신을 좋게 만들것입니다.



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

저작자 표시 비영리
신고
Posted by 오산돌구
구입한지는 1년이 넘었지만 저번주부터 새로운 마음으로 읽기 시작한 책
"객체지향의 사실과 오해"

동화책 읽듯이 쓱~~ 읽으면 객체에 대한 새로운 그리고 정확하게 정리해주는 아주 재밌는 책이다.


모든 내용이 다 괜찮지만 내 기억에 남은 것들을 정리해보려고 한다.

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

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

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


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

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

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


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

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


golang 으로 만나보는 duck typing



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

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

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


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


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

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

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



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


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

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

#golang top tip: name your packages for what they provide, not what they contain.


저작자 표시 비영리
신고
Posted by 오산돌구

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

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


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

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


. 코드 리뷰


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

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

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

Realm] Codereview HowTo

Github] Using Pull Request


. master branch is always deployable
. Github 의 P/R을 적극 활용. @을 사용하거나 설정을 통해 리뷰어들에게 메일이 가도록 설정하기
. 제품의 품질 향상을 위해 하는거다. 커맨트를 할땐 권유? 형식으로 진행하기
. 기능은 feat/xxxx, 버그 수정은 fix/xxx 브랜치로 만들기
. 큰 기능 혹은 이해가 되지 않은 로직에 대해서는 직접 얘기하는게 좋을것 같다.


. 커밋 메세지


SUBJECT

\n

BODY

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 



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

저작자 표시 비영리
신고
Posted by 오산돌구

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



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


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


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

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

저작자 표시 비영리
신고
Posted by 오산돌구

아~!! 드디어 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은 세그먼터 셀렉터의 개념으로 

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

저작자 표시 비영리
신고
Posted by 오산돌구

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에서 다시 보자.

# For a fixed maximum size, use -5 through -1, meaning:

# -5: max size: 64 Kb  <-- not recommended for normal workloads

# -4: max size: 32 Kb  <-- not recommended

# -3: max size: 16 Kb  <-- probably not recommended

# -2: max size: 8 Kb   <-- good

# -1: max size: 4 Kb   <-- good

list-max-ziplist-size -2


# Lists may also be compressed.

# Compress depth is the number of quicklist ziplist nodes from *each* side of

# the list to *exclude* from compression.  The head and tail of the list

# are always uncompressed for fast push/pop operations.  Settings are:

# 0: disable all list compression

# 1: depth 1 means "don't start compressing until after 1 node into the list,

#    going from either the head or tail"

#    So: [head]->node->node->...->node->[tail]

#    [head], [tail] will always be uncompressed; inner nodes will compress.

# 2: [head]->[next]->node->node->...->node->[prev]->[tail]

#    2 here means: don't compress head or head->next or tail->prev or tail,

#    but compress all nodes between them.

# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]

# etc.

list-compress-depth 0



데이타 추가전에, _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가 활발하게 커뮤니케이션 하는거 처음봤다. 부러움이 넘쳤다, 재밌겠다 ㅜ,ㅜ.
영어로 내 의견 쓸 정도는 되야하는데...

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

저작자 표시 비영리
신고
Posted by 오산돌구
TAG redis

BootLoader test

개발하면서 2015.01.25 20:06

책산지는 거의 2년정도 된것같다. 혼자 커널을 공부하자니 막막해서 따라하기 식으로 하면 될것같아
덜컥 사버렸다. 1년전 시도했던것 같은데 환경 세팅하다가 흐지부지 됐던...으악!!! 진득하게 좀 하자!!
실습하면서 생긴 이슈나 깨달은것들을 남기기로 했다 나중을 위한것도 있지만 나 스스로에게 동기부여를 위해서?;;;


이번 포스트는 p.131까지 진행했다.


p.59에 binutils 빌드를 하는데 아래와 같은 오류가 발생했다.

intl이라는 라이브러리를 못찾겠다고 한다. 3년도 더 된 책이라 버젼이 많이 달라졌다.
뜨끔하면서 세월 더 지나가기전에 책 한번 봐야겠다는 의지가 생긴다.
binutils빌드는 책보다 http://jsandroidapp.cafe24.com/xe/3171 보면서 하고, intl라이브러리가 없다고 하는건
아래 그림과 같이 libintl-devel, libintl8 바이너리 설치를 해주면 된다.



qemu는 공식 사이트보다 http://kkamagui.tistory.com/attachment/cfile9.uf@113BF3354EA8233D2B1020.zip 로
하는게 좋은것같다.


부트로더 테스트 성공!



레지스터가 익숙하지 않아서 진행하다가 레지스터 얘기 나오면 3.2장을 펼쳐보게 된다.
짧은 호흡으로 계속 가서 좀 익숙해져야겠다.


====================== 2015/01/29 추가 ======================

@gnutel님 만나서 얻은 꿀팁  virtual box에서 설치한 리눅스 환경에서 64비트 멀티코어 OS원리와 구조 실습하기


1. 우선 Xming을 설치한다. http://sourceforge.net/projects/xming/

2. putty 설정을 수정한다.


3. apt-get, aptitude같은걸로 qemu, nasm 설치

4. windows에서 작업한 Disk.img 복사해서 테스트(이미지는 5장꺼...ㅋㅋㅋ)



작업한걸 옮기자니 그게 귀찮아서 윈도우로 실습 하고있는건 모순....ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ



저작자 표시 비영리
신고
Posted by 오산돌구

2014년 회고

살아가면서 2014.12.31 01:12

2013년 10월 1일 부터 2014년 11월 7일까지 회사를 다니고
2014년 12월 31일 현재 까지 백수로 지내고 있다.
아직 구직의지는 없다  다만 원래 계획은 퇴사를 하고 하고싶었던 공부를 하려고했는데 펑펑 놀고있다.

다행인건 이젠 슬슬 노는건 그만하고 공부에 관심이 쏠리고 있다는 정도?


6월 16일 춘천으로 와서 회사 숙소에 살다가 7월 20일 방 구해서 살고있다
춘천, 살기에는 굉장히 좋다. 종로에 직장을 구한다면 춘천에서 살아도 좋을것같다



2014년은 정말 잊지 못할 한해가 될것같다. 좋았던 기억보다는 아쉬움 투성이다
그래서 그런지 2015년이 기대가 크다


30일 그러니까 어제, 아버지께 전화드렸다 약주를 한잔하셨는지 목소리가 업되셨다. :)
아들이 걱정됐는지 이 얘기를 3번 하셨다  "뭘 되려고 하지말고 하고 싶은걸 해라"
지금부터 내가 하고싶은 일, 묵묵하게 단련하자. 회사가 그 일을 좋아라해서 지원해준다고 하면 완전 땡큐고~ ㅎㅎ


32살 하루전!!

저작자 표시 비영리
신고
Posted by 오산돌구

딱 6년전 직장을 가진 이후 지금까지
DB도 관심있고, 커널소스도 보고싶고, 언어도 많이 배우고 싶고, PS도 잘하고싶고
그저 관심만 충만해서 이곳저곳 기웃거리기에 바빴다.


지금 백수다. 하루종일 혼자 있으면서 생각하는 시간이 많다

내가 어떤걸 공부 해야되고 깊이는 어느 정도 할지, 앞으로 어떻게 살지 등   답도 안나오는 것들...ㅋㅋㅋ
뭘 할지는 아직도 정해진건 없지만 뭘 안 해야할지는 계속 나오고 있으니 화이팅!!!!



아무것도 가진게 없다고 생각하며 살았는데, 많이 있더라.
항상 감사하자.



대학교 졸업하고 내 나름대로는 참 열심히 살았다고 생각한다. 언제 또 이런 시간 올지 모르니 감사하며 살자


부모님께 효도하고 동생과 우애있게 살자. 가족이 최고더라
그리고 그동안 만난 인연들 소중하게 생각하자

저작자 표시 비영리
신고
Posted by 오산돌구

요새 좀 보고싶은 오픈 소스들이 죄다 C++로 되어있어서 학습하고있다

http://www.learncpp.com/  여기서 후다닥 보고있는데 집중력이 20분을 못가네....ㅋㅋㅋㅋㅋ;;;


Pointer 와 reference의 차이

레퍼런스가 syntactic sugar인건 알겠는데, 포인터와 차이점은 무엇인가?

  1. 포인터는 재할당이 되지만, 레퍼런스는 한번 초기화 하면 변경하지 못한다.
  2. 포인터는 null을 가리킬수 있지만, 레퍼런스는 꼭!어떤걸 참조 해야한다.
  3. 포인터 자체 주소값은 가져올수 있지만, 레퍼런스는 할수 없다.
  4. reference arithmetics가 없다.
http://yosefk.com/c++fqa/ref.html  (fqa가 갑이구나...)


Constructor initialization lists

composition 혹은 상속관계에 있는것들은 저렇게 초기화하는걸 강력하게 추천!!! 이라고 한다
(const, reference상관없이)


Derived class initialization


생성자를 호출하게 되면 5가지의 초기화가 발생하는데

  1. 메모리 할당
  2. 적합한 생성자 호출
  3. initialization list 실행
  4. 생성자 body 실행
  5. 호출한 곳으로 제어권 넘김
여기서 상속받은 클래스는 한가지가 더 추가된다
  1. 메모리 할당
  2. 적합한 생성자 호출
  3. 적합한 부모 생성자 호출로 부모 객체 생성
  4. initialization list 실행
  5. 생성자 body 실행
  6. 호출한 곳으로 제어권 넘김

자식 클래스에서 부모 클래스 변수를 초기화 하는 방법은?  initialization list로는 할 수 없다. initialization list는 
같은 클래스의 변수만 초기화 할수 있다
const, reference 변수때문. 그리고 제약을 함으로서 모든 변수의 초기화는 한번만 하는것을 보장해준다

부모 클래스의 변수는 다음과 같이 초기화 시킨다.

Inheritance and access specifiers

상속 타입, 멤버 변수 접근자 default는 private이다

멤버 변수 접근자 3개(public, private, protected) * 상속 타입 3개(public, private, protected) 총 9개의 조합이 생성된다.    미안하다 복붙한다...ㅜ,ㅜ

Public inheritance
Base access specifierDerived access specifierDerived class access?Public access?
PublicPublicYesYes
PrivatePrivateNoNo
ProtectedProtectedYesNo
Private inheritance
Base access specifierDerived access specifierDerived class access?Public access?
PublicPrivateYesNo
PrivatePrivateNoNo
ProtectedPrivateYesNo
Protected inheritance
Base access specifierDerived access specifierDerived class access?Public access?
PublicProtectedYesNo
PrivatePrivateNoNo
ProtectedProtectedYesNo


Virtual Base classes

다중 상속의 문제점중에 하나가 diamond problem이다. Base class가 두번 호출이 된다.  그때 virtual 사용
virtual function 사용할때 자식 클래스에는 안써도 문제 없지만, 씀으로서 상기시킨다는 의미로 virtual을 쓰는걸 추천한다.  
virtual function에서 파라미터나 리턴 타입이 다르면 의도한대로 동작하지 않는다.

예외적으로 리턴 타입이 자식,부모 관계의 포인터나 레퍼런스라면 동작한다. (value는 안되네요;;)


(실력 부족이 가장 큰 원인이겠지만 C++은 다른 언어보다 알아야할게 너무 많은것같다. 기본만 하고 프로젝트 보면서
하나하나 공부하는걸로~)

저작자 표시 비영리
신고
Posted by 오산돌구

CLOCKSYNC


1년전에 JM북에 나온대로 무식하게 풀기로 풀었는데 다른 풀이법을 보니 신기했었다

그걸 지금 정리해본다.  분명히 1년전에는 이해했었는데, 다시 이해하는데 꽤나 버벅거림...;;;


10개의 스위치중에 한개의 스위치로만 시침을 변경할수있는 시계가 존재한다

1번 스위치에 11번 시계가 그렇고, 4번 스위치에 8번 시계가 그렇다


1번이나 4번으로 각각의 시계를 12시로 맞춰놓는다

예를들어 4번 스위치로 8번시계를 12시로 맞춰놓았다고 하면 다음할건 4번 스위치를 제외한 9개의 스위치에서

한개의 스위치로만 변경되는 시계가 있는지 살핀다

2번의 10번 시계가 그렇다


icpc IRC에서 Being님이 설명해준걸 이해한 후에 충격과 공포!!





저작자 표시 비영리
신고
Posted by 오산돌구

http://en.wikipedia.org/wiki/Geohash

http://geohash.org/site/tips.html


어느 DB 프로젝트 issue를 보다가 GeoHash dataType 지원할 생각은 없냐는 글을 봤다.

GeoHash? 처음 들어보는 hash다...공부해보자.

공부라고 해봤자 wiki를 내 나름대로 정리하자는 거지 뭐...


GeoHash는 Gustavo Niemeyer가 geohash.org 웹서비스를 개발하면서 위도/경도를 표현하기 위해 
개발한 geocode라고 한다.


좌표 2개를 하나로 표현한다는 장점이 있고, 

가까운 두 점이라도 geohash값은 전혀 다른값이 나온다는 한계가 있다.

대충 비슷한값이 나온다.


latitude 위도, longitude 경도

위도는 적도를 기준으로 북 90, 남, 90이라 하고, 경도는 본초자오선(처음들어봄..)을 기준으로
동경 180, 서경 180라 한다.

Equator 적도, meridian 자오선


우선 어떻게 진행되는건지 알아보자


ezs42 라는 Geohash 값이 있다고 하면 아래 표의 의해서 

01101 11111 11000 00100 00010 로 표현이 된다.



그럼 가장 왼쪽에 있는 0을 기준으로 짝수에 해당하는건 경도, 홀수는 위도이다.

왼쪽 카드가 위도, 오른쪽 카드가 경도 요런느낌? ㅎㅎㅎ


출처:http://theknaveofclovers.tumblr.com/post/41608490725/card-shuffle


그럼 경도는 0111110000000, 위도는 101111001001 가 된다.

10진수로 변환하고 싶지만 여기선 아니다.

binary search Tree처럼 왼쪽에서 오른쪼으로 하나하나씩 위치를 좁혀가는 과정을 진행한다.

위도를 예를 들어보자.


위도는 -90 ~ +90이다. 비트값이 0이면 -90 ~ 0, 1이면 0 ~ +90인것이다.



오른쪽 마지막까지 가면 소숫점 둘째나 셋째에서 반올림해준다.


인코딩은 거꾸로 하면 되겄지?


https://github.com/lyokato/libgeohash

https://github.com/the42/cartconvert

Go, C로 구현한게 있는데...어렵다. 공부하자


참고로 서울 GeoHash는 wydm99uq이다.

http://geohash.org/wydm99uq

저작자 표시 비영리
신고
Posted by 오산돌구



빅데이터 승리의 과학

저자
고한석 지음
출판사
이지스퍼블리싱 | 2013-04-25 출간
카테고리
컴퓨터/IT
책소개
세계의 기업들이 오바마의 빅데이터 전략을 벤치마킹하고 있다.현재...
가격비교


오랜만에 재미있는 책을 읽었다.


빅데이타라는 기술을 오바마 선거캠프에서는 어떻게 활용했는지에 대해 얘기를 한다.

오바마 선거캠프를 꾸리기전에 사람들을 모으는 과정, 자원봉사자들이 어떻게 선거 운동을 했는가,

수집된 데이타를 이용해서 마이크로 타게팅이 가능하게 만들고 이를 다시 선거운동에 어떻게 활용하는가의 

흐름으로 책을 끌어나간다.


빅데이타라는건 이미 실생활에 적용되고있다는 점을 꾸준하게 전달한다.


어떠한 요구사항들이 있을때 이미 많은 경험과 많은 공부가 되어있는 오바마 선거캠프 엔지니어들이

테스트 결과에 따라서 바로바로 구현해준다는 얘기가 종종 나오는데 마냥 부러웠고 

나도 부던히 노력해서 

회사가 원하는 것들에 대해서는 약간의 공부와 경험을 통해 산출물을 내주는 사람이었으면...하는 생각을 하게됐다.

후다닥이 관건!!! ㅋㅋㅋ



그리고 07 빅데이타 전략을 사용하지못한 공화당 은 꼭 회사 대표님과 이사님한테 보여주고 싶다 ㅋㅋㅋ


아래는 책을 읽으면서 다시 찾아보게 된 키워드들이다. 

인터넷상에 올린 글들을 수집해서 감성을 파악하는 sentiment analysis

학계에는 쓸모있을지는 모르지만 실전에는 쓸데없는 하위그룹분석  data dredging


2016년에는 공화당과 민주당이 어떻게 활동하는지 궁금하다. : )

저작자 표시 비영리
신고
Posted by 오산돌구

Mac 에서 C/C++ 오픈소스를 좀 보려고 했는데 겪었던 문제들. 새삼 Ubuntu LTS의 소중함을 알았음



1 ArangoDB 컴파일 하는데 자꾸 V8에서 컴파일 에러가 발생했다


unused private field???  아래 설명한 대로 XCode 버젼도 바꿔봤는데 여전히 안되다가 gcc버젼을 4.7로 변경하니

v8 컴파일 성공 :)

https://github.com/cowboyd/libv8/issues/94


sudo port search gcc47, sudo port select --list gcc, sudo port select --set gcc mp-gcc47



2. Eclipse CDT에서 디버깅하면서 소스 좀 보려고 했는데 아래와 같은 메세지 발생


http://stackoverflow.com/questions/19877047/eclipse-gdb-macosx-mavericks

https://sourceware.org/gdb/wiki/BuildingOnDarwin


참고해서 gdb 인증 풀어서 해결. port로 gdb설치하면 ggdb로 실행파일이 생기는건 충격 뭐지...

brew는 /usr/local/Cellar/xxx   port 는 /opt/local/bin/xxx  에 설치가 된다.

인증서 생성방법은
keychain Access.app 실행 후 위쪽 메뉴에서 키체인 접근 -> 인증서 지원 -> 인증서 생성 누른다.
첫 화면에서 이름은 gdb-cert, 신원 유형은 자체 서명 루트, 인증서 유형은 코드서명 마지막으로 기본값 덮어쓰기 click 후
"인증서에 대한 위치 지정"이 나올때까지 계속을 누르고 인증서에 대한 위치 지정은 로그인이 아닌 시스템으로 한다




codesign 등록후 taskgated를 재시작 하라고 하는데 activity Monitor.app 실행 후 taskgated 검색해서 종료하면 재시작 된다.

codesign, keychain access가 있는지도 몰랐고, port, brew 사용법이 어눌해서 삽질했던 시간이었다.

저작자 표시 비영리
신고
Posted by 오산돌구