Python을 사용하는 사람이라면, virtualenv을 잘 알것이다. 각 프로그램마다 각자의 파이썬 환경을 구성할수 있는 도구이다. (Py3에 기본으로 추가되어 있다)

go tool은 개인적으로 불만이 많은 도구이다. 특히 go get은 여러가지 기능의 부족으로 당황스러움을 느끼게 한다.

가령 go get은 scm(git,hg…)에서 직접 가져온다. 하지만 언제나 master branch의 최신을 가져온다. 즉 버져닝(versioning)에 대한 부분이 없다.

사내에서 Docker 사용에 대한 이야기가 나와서 간단하게 조사해보았다. 매력적인 프로젝트인것은 확실하지만, 기존에 chef나 opsworks로 구성되어 있는 부분도 있고 현재 시스템 구조상 docker으로 이전해서의 이득이 생각외로 크지 않다는 것이 중평.

docker의 장점은 대개 두가지로 이야기 할수 있겠다.

• Portability (이식성)
• Repeatability (반복성)

이식성(Portability)은 가장 크게 얻는 이점은 개발환경과 실제 프로덕션 환경의 차이를 설정변수 몇개로 축소할수 있다는 점이라고 생각한다. 여러 환경(개발,테스트,프로덕션)을 일치시키기 위한 별다른 노력을 할 필요 없다는 점이 가장 큰 매력으로 생각한다. 물론 자바와 비슷하게 한번 작성하면 어디서든 동작한다는 것이 여러 Host 환경에서 동작할 수 있다는 점도 무시할수는 없겠다.

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다.

Go’s power is in emergent behavior

• http://www.onebigfluke.com/2014/04/gos-power-is-in-emergent-behavior.html
• golang의 interface의 특징을 두가지 예(http.HandlerFunc,opaque type)을 가지고 설명. 저번에 있었던 gophercon에서 들은 내용에 대한 글.

Go Parallel 1,2

• https://software.intel.com/en-us/blogs/2013/06/18/go-parallel
• https://software.intel.com/en-us/blogs/2014/04/13/go-parallel-2
• 고루틴에 대한 예제와 함께 짧게 고루틴을 알수 있는 글.

Go: Best Practices for Production Environments

• http://peter.bourgon.org/go-in-production/

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다. 이번달은 읽은 글들이 많지가 않다. T_T

Go and Package Versioning

• http://zduck.com/2014/go-and-package-versioning/

“My dream is for go get to support a version number component in the import path. So github.com/jpoehls/gophermail would fetch the HEAD of the repository as it does today. github.com/jpoehls/gophermail#v1 would fetch the v1 branch or tag.”

읽어야 할 글들을 Kindle에 던지는데,뭘 킨들에 던졌는지 기록해 두면 좋을 것 같아서 적어본다.

Why Atom Can’t Replace Vim : Learning the lesson of vi

Atom이 Emacs의 확장가능성은 가질수 있지만, Vi의 조합가능성에 대해서는 배운 바가 없다는 글.

조합가능성에 대한 글로는 http://blog.dahlia.kr/post/78940164278 홍민희님의 글과 함께 보면 좋다.

아직 서비스에 사용이 가능할지는 미지수이지만, Python으로 구성한 REST API Server을 이번에 D언어로 프로토타이핑을 하게 되었다.

우선 사용한 라이브러리는 vibe.d와 Backend Server와의 통신을 위해 thrift이다.

vibe.d은 기본적으로 redis와 mongodb을 지원하지만, Thrift에 대한 지원은 없다.

vibed의 Writing native database drivers - and a new MySQL driver port 을 참고하여 TSocket을 vibe.d의 TCPConnection을 사용하도록 만들어서 사용했다.

크롬북을 샀다.

크롬북의 가장 큰 장점은 가격이다. $199에 이정도 노트북을 살수 있다는 것은 분명 매력적. 정말로 크롬 웹 브라우저만 있다. 흠…

• 좋지 않은 디스플레이 (흐릿한 디스플레이는 C720의 가장 큰 하드웨어 단점이다)
• 8시간 사용 가능한 배터리 (하스웰 기반 CPU이 주는 혜택. 8시간이상 되니까 핸드폰처럼 충전기를 가지고 다니지 않게 되었다)
• 내 아이폰과 같은 용량인 16기가 SSD.

나의 개발환경을 기본적으로 한쪽 화면에 터미널(들),또 다른 화면에는 웹 브라우저(들)뿐이다. 크롬OS는 개발자 모드로 shell을 사용할수 있으므로, 코딩하는게 크게 문제는 없다.

C++ for C Programmers 코세라 수업이 끝났다.

코세라 코스는 끝나고 인증서를 주는데 (물론 코세라 강의를 잘 들었다 정도의 의미이다.) 저번에 Function programming In Scala 다음으로 힘들었다.

강의 자체는 C++0x까지 있어서 C++ 언어를 한번 정리하는 점으로는 좋았다. 하지만 숙제는 C/C++ 지식만 가지고는 풀수가 없었는데. 특히 알고리즘 기반의 숙제는 C++ 학습만 생각하고 시작했던 나에게는 조금 당혹스러워 했었다고 해야 하나.

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

Chef을 써보면서, 요리에 관련된 메타포를 사용하여 Chef 구성요소들의 이름들을 잘 지었다는 생각이 든다. Chef을 구성하는 요소에 대한 설명을 간단히 몇개 적어 보자면:

• Chef : 요리사,Server Configuration Project
• Recipe : 요리법,어떤 작업을 할지 서술하는 목록
• Cookbook: 요리책,Recipe의 모음집.
• Knife : 칼 요리도구,Chef의 CLI 도구
• Node : 구성 작업할 서버
• Workstation : 작업장, Knife등의 도구를 통해 Chef에 작업을 하는 머신.
• Data bag : Chef Server에 JSON기반으로 저장되는 데이터
• Run list : Node에 작업할 목록(Cookbook의 Recipe나 다른 Role을 포함할수 있다)
• Attribute : 노드의 속성. Node와 Cookbook,Role,Environment에서 정의될수 있고,순서규칙에 따라 overide가 된다.
• Role : Run list와 Attribute을 가지는 설정

물론 모든 단어가 요리에 관련된 단어는 아니다. 좀더 명확하게 설명할수 있는 요소는 굳이 사용하지 않은 듯 하다.