ohyecloudy programming notesohyecloudy programming notes

[리뷰] Are We There Yet? - Rich Hickey - OO는 시간 개념 없네.

ohyecloudy — Sun, 16 Jun 2013 23:00:14 +0000

객체지향(Object Oriented) 자체가 가진 복잡성의 원인은 뭘까? 그 원인을 찾아보고 해결할 수 있는 다른 모델을 제시한다. 발표자는 리치 히키(Rich Hickey). Clojure를 만든 사람이다.

명확하게 정의하지 않아 괴롭히는 개념이 하나 있다. 바로 시간. 객체 지향(Object Oriented)에는 시간이란 개념이 없다. 이 발표에서 가장 인상적이었다. 이 개념에 대한 설명이 주제이기도 하고.

진짜 없을까? 아예 없는 걸까? 그건 아니다. 명확한 개념 정의를 안 했을 뿐이다. 프로그램에서 공통으로 사용하는 보편적인 시간대가 있다. 바로 메인 스레드(thread)의 타임라인이다.

병행 프로그래밍(concurrent programming)에서 이 시간대가 깨진다. 시간을 구성하는 건 인과 관계를 맺은 값들. 즉 변화가 시간대를 구성하는 재료가 된다. 스레드마다 변화를 각기 주도하기 때문에 보편적인 시간대가 깨지게 된다. 계산은 상관없으나 리소스에 접근하는 게 문제다. 시간대를 맞춰줘야 한다. 하나의 시간대로 복귀하는 건 어떻게 하나? 바로 Lock 메커니즘. 시간대를 맞추는 데 사용한다.

시각을 넓힐 수 있는 좋은 발표자료. clojure 관심 여부를 떠나서 추천하고 싶다. 약점을 알게 되면 이해가 더 깊어진다. 이 발표가 객체지향이 가진 약점을 내게 알려줬다. 명확히 정의하면 주변이 명료해지는 시간이란 개념도 배웠다.

참고

주요 슬라이드와 간단한 코멘트.

OO에는 시간이란 개념이 존재하지 않는다.

실제 entity와 identity를 결합했다.

미래는 과거로부터 만들어진다. 이런 과정을 process라고 부른다. 시간은 연속된 process 이벤트들로 만들어진다.

identity는 상상의 entity이다. 인과 관계를 맺은 값들의 시리즈를 결합해서 만든다.

CAS (compare and swap)와 agent를 시간 건축물 관점에서 본다.

타임 라인이 여러 개 있을 때, STM (Software transactional memory)

vim과 함께한 1년 - 절벽을 기어오른 보람이 있다. 만족한다.

ohyecloudy — Wed, 12 Jun 2013 23:00:42 +0000

vim과 함께 한지 1년이 넘었다. vi 그래프에 나오는 절벽을 기어올랐다.

정보 많다. 당연하다. 장수 프로그램이니깐. 내부 도움말도 있고 인터넷 정보도 넘친다. 하지만 처음 시작하고 왠지 겁이 좀 날 때는 신호 대 잡음비가 가장 적은 책이 효과가 좋다. 그래서 고른 책이 손에 잡히는 Vim. 한 권 보고 나니 익숙해짐 가속도가 생겼다.

맥 에어. vim을 익히는 게 된 결정적인 원인이다. 만약 집에서 데스크톱을 더 많이 사용했다면 vim 없이도 편하게 잘살고 있을 것이다. 더 콕 찍어 말하자면 화살표 키. 오른쪽 밑이라 손목이 꺾이고 크기도 참 소심해 불편하다. 나도 몰랐는데, 화살표 키를 많이 사용하더라. 누를 때마다 짜증이 나서 적어도 문서 편집을 할 때는 사용을 안 하는 방법을 찾게 됐다. 그때 걸린 게 vim.

지금은 vim 마니아가 됐다. 가장 큰 장벽이었던 입력 모드(insert mode)와 명령 모드(command mode) 분리. 이것 때문에 vim 적응이 어려웠는데, 지금은 모드 분리는 vim을 이끈 최고의 결정이라 생각한다. 왜냐면 vim 문법(Vim Grammar)을 만든 토양이기 때문이다. Ctrl, Alt와 같은 키를 섞어서 입력하게 할 수 있겠지만 3d5w와 같은 걸 매번 같이 누르면서 입력한다 생각하면 끔찍하다. 편집을 위한 문법. vim을 사용하기 전까진 생각도 못해봤다. 익숙해지면 이것만큼 편한 것도 없다.

에디터는 버릴 수 있겠는데, vim 문법을 못 버리겠다. 이 개념에 익숙해지니 너무 편하다. 나만 이렇게 생각하는 게 아니다. vim 선배들 대부분이 이렇게 생각한다. 어떻게 알 수 있느냐면 vim 플러그인이 없는 환경을 찾아보기 힘들기 때문이다. 난 현재 visual studio에는 VsVim, Xcode에는 XVim, chrome에는 Vimium을 사용 중이다. 아 그리고 clojure 때문에 조금씩 쓰고 있는 Emacs에는 Evil을 사용하고 있다.

vim 설정 파일을 github 저장소에 관리한다. 목적은 뻔하지. 어떤 곳에서든 같은 설정을 사용하려고 만들었다. github를 사용 안 해봤다면 vimrc를 관리하면서 경험해보는 것도 괜찮다.

멀티 플랫폼을 지원하는 괜찮은 에디터가 많다. 그래서 다른 사람에게 추천하긴 망설여진다. 하지만 난 배우길 잘했단 생각이 든다. OS를 바꿔도 에디터 만큼은 겁나지 않고 과거보다 문서 편집 효율도 높아졌다. 최근에 아꿈사 스터디 위키를 정리했는데, 아마 vim이 아니었으면 더 오래 고통스럽게 작업을 했을 것이다. vim에 만족한다.

도움이 되는 자료들.

vimcasts - 엄청나게 잘 다루는 아저씨가 주제를 하나씩 설명한다. 재미있게 배울 수 있다.
SuperUser - StackExchange #vim - 최근 질문을 RSS로 구독 중. 답변에서도 배우는 기능이 많다.

:wq

[발표자료] 페리 수열 (Farey Sequence) - 바보 셈(freshman sum)을 한 원소가 다음에 등장하는 재미있는 수열

ohyecloudy — Sat, 08 Jun 2013 05:21:21 +0000

페리 수열(Farey sequence) from Jongbin Oh

프로젝트 오일러(Project Euler) 문제를 풀다가 알게 됐다. 바보 셈(freshman sum)을 한 원소가 다음에 등장하는 재미있는 수열.

페리 수열 길이를 바로 구할 때, 사용하는 Euler's totient function. 증명을 공부하다 보니 Chinese Remainder Theorem (중국인의 나머지 정리)를 알아야 해. 이걸 또 증명하다보니 Extended Euclidean algorithm (확장된 유클리드 호제법)을 공부해야 한다. 휴 더 깊어졌으면 위험할 뻔했어. 이해하느라 꽤 시간을 썼다. 하나씩 블로그에 올릴 예정.

부호가 다른 두 수를 모듈로 연산(modulo operation)할 때, 결과 값 부호는?

ohyecloudy — Thu, 23 May 2013 23:00:47 +0000

모듈로 연산, modulo(modulus) operation?

나머지를 구하는 연산이다. 즉, $a = n \times q + r$ 일 때, $a \bmod n = r$ 이 된다.

퀴즈

bool is_odd(int n) {
    return n % 2 == 1;
}

제대로 구현한 걸까?

n이 양수일 때는 문제가 없어 보인다. 1,3,5,... 다 1이 나오니깐. 그럼 n이 음수면 어떻게 될까? 즉, $-3\bmod2$ 는 -1일까? 1일까?

C++11에선 -1이다. 피제수(dividend) 부호를 따라간다. C+11에서 표준으로 정해졌기 때문에 C++98에서는 컴파일러 마음이다. 난 VS2008에서 테스트했는데, -1이 나오더라.

그래서 저 구현은 잘못됐다. n이 -1, -3, ... 일 때, 모듈로 연산 값은 -1이 되고 false를 리턴한다.

bool is_odd(int n) {
    return n % 2 != 0;
}

모듈로 연산 값 부호가 n에 따라 결정되므로 n 부호를 보고 분기를 타서 결과를 계산하거나 0과 비교하면 된다.

truncated division, floored division

$a = n \times q + r$ 에서 $q$ 를 어떻게 구하느냐에 따라 부호가 피제수 혹은 제수(divisor)를 따라가게 된다.

truncated division은 $q = trunc(a / n)$ 로 구한다. 즉, 버린다. $q=trunc(-3/2)=-1$ 이 되고 계산하면 $r = -1$ 이 된다. 음수일 때, 소수점 이하를 버려서 나머지가 없는 해(solution)보다 큰 정수가 몫(quotient)이 된다. 그래서 나머지는 음수가 된다. 결국, 모듈로 연산 값 부호는 피제수를 따라간다.

floored division은 $q = \left\lfloor {a \over n} \right\rfloor$ 로 구한다. 버림과 다르게 내림이다. $q=\left\lfloor {-3 \over 2} \right\rfloor = -2$ 가 되고 계산하면 $r = 1$ 이 된다. truncated division과 다르게 해(solution)보다 더 작은 정수가 몫이 된다. 그래서 나머지는 양수. 결국, 부호는 제수를 따라간다. 참고로 Wolfram Alpha에서 이 방법을 사용.

이 두 방법 외에 나머지를 0 또는 양수로 만드는 Euclidean definition도 있다.

mod 정의를 봐야 한다.

$\begin{array}{lcl} \gcd(a,0) = a\\ \gcd(a,b) = \gcd(b, a \,\mathrm{mod}\, b) \\ where\, a\mathrm{mod}\, b = a - b \left\lfloor {a \over b} \right\rfloor\end{array}$

유클리드 호제법(Euclid's algorithm)이다. floored division을 쓴다고 정의했다.

; clojure
(defn gcd [a b]
  (if (zero? a)
    b
    (recur (mod b a) a)))

그래 mod. 별 생각 없이 구현했다. 하지만 음수가 들어가니 나오는 gcd 값에 멘붕. 찾아보니 mod도 있고 rem도 있네. 그래 mod는 모듈로 연산. rem은 나머지를 구하는 연산. 엥? 둘이 갖지 않나? 뭐가 다른 거지? 아~ 두 가지 구현을 다 했고 그걸 구분하려고 이렇게 이름을 지었구나. mod는 피제수 부호를 따라가고 rem은 제수 부호를 따라간다. gcd를 구할 땐, floored division을 사용해야 하므로 rem을 사용해야 한다.

참고: Modulo operation - wikipedia

4clojure - 빈칸을 채우며 클로저(clojure)를 배우자.

ohyecloudy — Thu, 02 May 2013 23:00:28 +0000

새로운 언어를 배우고 있다. 바로 클로저(clojure). 2년 정도 꾸준히 공부해 볼 생각이다. 일 년에 새로운 언어 하나는 아무리 생각해봐도 무리. 그렇게 말한 아자씨들은 지금 실천하고 있을까?

그래서 대충 보고 묵혀놨던 프로그래밍 클로저를 최근에 다 봤다. 물론 최대한 코드를 많이 짜면서 책을 읽었다. github에 hello-clojure 프로젝트를 만들고 책에 나온 내용에 대한 unit test 코드를 짰다. 이제 조그만 장난감 프로젝트를 시작할 차례다. 현업에서 사용 안 하는 언어기 때문에 필수.

장난감 프로젝트를 하기 전 예열이 필요했다. 아직 클로저가 많이 낯설기도 하고. ~~심시티를 하려고 점심시간을 비워놨건만 서버가 개판이라서~~ 점심시간에 할 놀이도 필요했고. 그래. 이럴 땐, 프로젝트 오일러 문제가 딱이지. 그러던 차에 4clojure 사이트를 알게 됐다.

빈칸 채우기 문제. 테스트를 통과하는 함수를 짜면 된다. 짜서 제출하고 위에서부터 녹색불이 하나씩 켜지는 걸 보는 재미가 쏠쏠하다.

core-functions, destructuring, higher-order-functions, seqs, ... 꼭 알아야 하는 주제들로 구성했다. 여기에 알고리즘 문제까지. 난 특히 특정 함수 안 쓰고 풀어야 하는 문제가 재미있었다.

총 153문제. 현재 Easy까지 풀었다.

똑같은 문제를 다른 사람은 어떻게 풀었을까? 문제 풀이도 공부되지만 잘하는 사람 풀이를 보는 것도 정말 공부가 많이 된다. maximental 아저씨 추천. 이 사람 해답을 보며 배우는 재미가 쏠쏠했다. 클로져 소개 강의를 한 psk810님도 추천. 153문제 다 푼 사람이 별로 없는데, 이 분도 다 풀었다.

;; ohyecloudy solution to Trees into tables
;; https://4clojure.com/problem/146

(fn 1
  (reduce
    merge
    (map (fn [k v]
           (reduce
             merge
             {}
             (map #(assoc {} (vector k %1) %2) (keys v) (vals v))))
         (keys c)
         (vals c))))

; maximental solution:
; 아아. for 내부에서도 중복 바인딩이 가능하다.

#(into {} (for [[i j] % [k l] j] [[i k] l]))

위키에 풀 때마다 다른 해답을 보며 정리를 하는데, 내가 젤 어렵게 풀고 있어.

내부 툴은 소프트웨어 회사의 DNA이다 - Building an army of robots 발표자료에서

ohyecloudy — Tue, 09 Apr 2013 23:00:57 +0000

Building an army of robots by Kyle Neath. github 내부 툴을 소개한 발표자료. github 아저씨들은 발표자료 참 잘 만든다.

hubot, janky, play, ... 공개한 내부 툴도 많은데, 다 이유가 있었다. 바로 내부 툴은 문화이고 더 나아가 DNA라는 철학을 가지고 있기 때문.

매니저가 없고 재택근무가 많은 근무환경 때문이겠지. 처음에 이렇게 생각했다. 그런데 좀 더 생각해보니 아니다. 투자하는 내부 툴 기능이 달라질 뿐이지 내부 툴에 대한 투자 자체에 영향을 주는 건 아니다. 그래 근무 환경이 아니라 문화이고 DNA라는 철학이 내부 툴에 대한 투자로 이어진다.

그래서 그런지 이런 발표자료나 소스코드로 내부 툴 정보도 열심히 알린다. 문화이기 때문에 그리고 그런 문화는 좋은 인재를 빨아당기기 때문이다.

프로그래밍 클로저 (Programming Clojure) - 훌륭한 입문서. 1판이라 아쉽지만

ohyecloudy — Sun, 07 Apr 2013 23:00:19 +0000

컴퓨터 프로그램의 구조와 해석(SICP), 해커와 화가 책을 통해 Lisp에 대한 빠심을 계속 충전해왔다. 이제 그 막연한 빠심을 실체화해야 할 시기.

표현력이 강한 언어를 배우고 싶었다. 그래서 찍어 놨던 언어가 바로 Lisp. 제대로 공부하고 싶었으나 실용성 때문에 망설였다. 분명 언어와 그 철학을 배우면서 얻는 것도 많겠지만, 무엇보다 필요할 때 적극 활용할 수 있는 언어를 원했다. 그러던 중에 발견한 클로저. JVM 기반 언어다. Lisp dialect다. 이쯤 되면 망설일 이유가 없다.

클로저 입문서로 제격이다. 자바 호출, 데이터를 시퀀스로 다루기, 함수형 프로그래밍, 병행성, 매크로, 다중 메서드 등 알아야 할 요소를 쉽게 설명한다. 다만 2010년에 나온 책이라 clojure 1.0 기준으로 설명한다. 번역판이 없는 2판은 1.3 기준. 현재 버전은 1.5이다. 그래서 추가된 피처에 대한 공부(protocols, datatypes, ..)는 따로 해야 한다.

github에 hello-clojure 저장소를 만들고 테스트 코드를 만들면서 공부했다. 책을 보며 공부하는데 이 방법이 가장 효과적인 것 같다.

PS: 요즘은 4Clojure 문제를 풀고 있고 1.5까지 따라잡은 뒤, 개인 장난감 프로젝트를 시작할 예정이다.

iPad 프로그래밍 스터디 회고

ohyecloudy — Wed, 03 Apr 2013 23:00:21 +0000

4개월간 아이패드 스터디에 참여했다. 아꿈사가 아닌 다른 스터디 모임에. 다른 스터디는 어떻게 진행되나 궁금했기 때문이다. iOS 쪽 스터디 모임을 찾아보니 생각보다 없었다.

모두가 노트북을 들고 와서 실습 위주로 공부했다. 안 그래도 바랬던 방식인데, Xcode가 익숙하지 않았기 때문. 직접 타이핑하면서 공부하니 확실히 이해는 잘 됐다. 몰랐던 Xcode 기능도 많이 알게 됐고. 하지만 너무 오래 걸린다. 3주 정도 한 챕터만 한때도 있었다. 이렇게 너무 오래 걸리니깐 결국 문서로 코드를 전달하고 copy & paste로 진행하게 된다.

난 12장 발표. 거의 마지막 발표였는데, 코드를 직접 짜며 진행하는 스터디에선 버전 컨트롤 시스템을 활용하면 편할 것 같았다. Xcode에선 git을 지원해서 github에 만들었다. 그리고 챕터에서 설명하는 코드에만 집중할 수 있게 나머지를 구현하고 TODO 주석을 달고 커밋. 구현하고 DONE 주석으로 바꾼 뒤 커밋. 이런 식으로 구성했다. 그리고 간편하게 진행하려고 step0, step1, .. 식으로 브랜치를 만들었다. 각자 구현을 해보다가 어느 정도 시간이 지나면 구현된 브랜치를 checkout해서 확인해보면 되니깐. 그리고 대략적인 설명을 하는 문서가 필요했는데, 여기엔 markdown을 사용했다. 챕터 내용이 간단해서 저장소를 구성하는데 시간이 별로 안 걸렸다.

토즈만 가다가 이번에 처음으로 윙스터디, 제이알스터디에 가봤다. 싼 장소에서 하고 남는 돈을 스터디가 끝난 뒤 먹는 점심 식사비에 보탠다. 장소에 더 돈을 쓰는 것보다 낫네.

처음 온 사람을 챙기는 게 서툴더라. 하긴 생각해보니 나도 처음 온 사람을 잘 못 챙겼던 것 같다. 이거 은근히 어려워.

[프로그래머.훌륭한습관] 어제 동료가 커밋한 코드 읽기

ohyecloudy — Sun, 17 Feb 2013 23:00:38 +0000

아침에 출근하면 가장 먼저 하는 일. 전날 커밋된 코드를 읽는다. 물론 읽는 건 내 코드가 아니라 동료가 커밋한 코드.

처음에는 코드를 읽을 때, 2~3시간을 썼다. 코드를 읽는 것도 중요하지만 이렇게 시간을 써버리면 곤란하다. 왜냐하면, 아직 내 역할은 코드 품질 유지보다는 생산 쪽이기 때문이다. 물론 모든 프로그래머는 둘 다 신경을 써야 한다. 하지만 역할이 한쪽으로 더 치우쳐 있기 마련이다. 현재 나는 생산 쪽에 더 치우쳐 있다. 그래서 원칙을 세웠다. 길어야 40분. 초과하면 커밋 코멘트만 보거나 내 업무와 연관된 코드만 읽는다.

다른 사람이 짠 코드를 많이 읽어라. 참 많이 듣는 조언이다. 경력이 쌓이면 으레 이런 조언을 한다. 코드를 많이 읽는 프로그래머도 이런 조언을 하고 안 읽는 프로그래머도 이런 조언을 한다. 그래 왜 읽어야 하는지 설명을 안 해도 될 만큼 모두 중요성을 알고 있다. 자~ 이제 유명한 오픈 소스 프로젝트를 찾아보자. 하지만 가까운 데도 금광이 있다. 바로 나와 같이 일하는 동료가 짠 코드. 코드를 읽는 능력도 향상되고 업무에도 바로 도움이 된다. 우선 동료 코드를 읽는 것부터 시작하자.

이렇게 짜니깐 쉽게 읽을 수 있구나. 이런 문제를 나는 되게 어렵게 풀었는데, 이렇게 우아하게 해결할 수 있구나. 이건 처음 보는 단어다. 사전으로 찾아보니 이런 뜻이 있네. 이 단어 적절해 보인다. 등등을 나는 지난 1년간 동료 코드를 읽으면서 배웠다. 정말 읽기 힘든 코드가 있기도 한데, 자책을 안 해도 된다. 그 코드는 당사자도 1~2주 후면 읽는데 애를 먹을 것이기 때문에.

여기에 덧붙여 같이 일하는 동료 성향을 알 수도 있다. 빠르게 해결하고 반복하면서 품질을 높여가는 동료. 느리지만 견고하게 문제를 해결하는 동료. 속도 우선. 견고함 우선. 이후 막혔을 때, 성향을 파악하고 있으면 조언을 구하기도 좋다.

그리고 팀 퍼포먼스도 알 수 있다. 내가 읽을 수 없는 양이 커밋되는 게 맞는데, 읽을 만하다. 와! 내 실력이 좋아졌구나. 하지만 착각이다. 팀 퍼포먼스가 낮아질 때, 이런 현상을 겪는다.

이제 아침에 안 하면 너무 찝찝하다. 1년 전부터 했는데, 이제 습관이 만들어진 것 같다. 프로그래머 습관으로 곧 블로그에 포스팅할 예정.

— 오종빈(Jongbin Oh) (@ohyecloudy) 2013년 1월 30일

아침에 코드를 읽는데, 쓸 시간이 부족했다. 그래서 바로 업무를 시작하려고 했는데, 너무 찝찝하더라. 아~ 습관이 만들어졌구나. 2011년 말에 시작했으니 1년이 조금 넘었다.

이렇게 매일 보다 보면 왜 체크인 전에 diff를 떠야 하는지 알게 된다. [프로그래머.훌륭한습관] 코드 commit(submit, check-in) 전에 diff 에서 썼듯이 커밋 전에 diff를 떠보는 걸 강조하는 것도 코드를 읽는데, 너무 방해되기 때문이다.

Insomniac의 LunaServer - disk 접근과 undo/redo를 책임지는 로컬 서버

ohyecloudy — Sun, 27 Jan 2013 23:00:54 +0000

disk 접근과 undo/redo를 책임지는 로컬 서버를 만든다. 이게 핵심 아이디어다. 왜 이런 생각을 못했을까? 장점이 많아 보인다.

이런 로컬 서버는 단순해서 안정적이다. 다른 툴에 비해 나이도 많은 것도 안정화에 도움을 주는 편. undo/redo 스택을 LunaServer에 저장해 다른 툴에서 발생하는 크래시로부터 적어도 데이터는 지킬 수 있다. 확실히 생산성에 도움을 주겠구나.

전담하는 만큼 LunaServer 결함이 치명적으로 작용하지만 얻을 수 있는 장점이 더 많아 보인다.

참고: