
객체지향(Object Oriented) 자체가 가진 복잡성의 원인은 뭘까? 그 원인을 찾아보고 해결할 수 있는 다른 모델을 제시한다. 발표자는 리치 히키(Rich Hickey). Clojure를 만든 사람이다.
명확하게 정의하지 않아 괴롭히는 개념이 하나 있다. 바로 시간. 객체 지향(Object Oriented)에는 시간이란 개념이 없다. 이 발표에서 가장 인상적이었다. 이 개념에 대한 설명이 주제이기도 하고.
vim과 함께 한지 1년이 넘었다. vi 그래프에 나오는 절벽을 기어올랐다.
정보 많다. 당연하다. 장수 프로그램이니깐. 내부 도움말도 있고 인터넷 정보도 넘친다. 하지만 처음 시작하고 왠지 겁이 좀 날 때는 신호 대 잡음비가 가장 적은 책이 효과가 좋다. 그래서 고른 책이 손에 잡히는 Vim. 한 권 보고 나니 익숙해짐 가속도가 생겼다.
페리 수열(Farey sequence) from Jongbin Oh
프로젝트 오일러(Project Euler) 문제를 풀다가 알게 됐다. 바보 셈(freshman sum)을 한 원소가 다음에 등장하는 재미있는 수열.
페리 수열 길이를 바로 구할 때, 사용하는 Euler's totient function. 증명을 공부하다 보니 Chinese Remainder Theorem (중국인의 나머지 정리)를 알아야 해. 이걸 또 증명하다보니 Extended Euclidean algorithm (확장된 유클리드 호제법)을 공부해야 한다. 휴 더 깊어졌으면 위험할 뻔했어. 이해하느라 꽤 시간을 썼다. 하나씩 블로그에 올릴 예정.
나머지를 구하는 연산이다. 즉,
일 때,
이 된다.
bool is_odd(int n) {
return n % 2 == 1;
}
제대로 구현한 걸까?
새로운 언어를 배우고 있다. 바로 클로저(clojure). 2년 정도 꾸준히 공부해 볼 생각이다. 일 년에 새로운 언어 하나는 아무리 생각해봐도 무리. 그렇게 말한 아자씨들은 지금 실천하고 있을까?
그래서 대충 보고 묵혀놨던 프로그래밍 클로저를 최근에 다 봤다. 물론 최대한 코드를 많이 짜면서 책을 읽었다. github에 hello-clojure 프로젝트를 만들고 책에 나온 내용에 대한 unit test 코드를 짰다. 이제 조그만 장난감 프로젝트를 시작할 차례다. 현업에서 사용 안 하는 언어기 때문에 필수.
장난감 프로젝트를 하기 전 예열이 필요했다. 아직 클로저가 많이 낯설기도 하고. 심시티를 하려고 점심시간을 비워놨건만 서버가 개판이라서 점심시간에 할 놀이도 필요했고. 그래. 이럴 땐, 프로젝트 오일러 문제가 딱이지. 그러던 차에 4clojure 사이트를 알게 됐다.

Building an army of robots by Kyle Neath. github 내부 툴을 소개한 발표자료. github 아저씨들은 발표자료 참 잘 만든다.
hubot, janky, play, ... 공개한 내부 툴도 많은데, 다 이유가 있었다. 바로 내부 툴은 문화이고 더 나아가 DNA라는 철학을 가지고 있기 때문.

컴퓨터 프로그램의 구조와 해석(SICP), 해커와 화가 책을 통해 Lisp에 대한 빠심을 계속 충전해왔다. 이제 그 막연한 빠심을 실체화해야 할 시기.
표현력이 강한 언어를 배우고 싶었다. 그래서 찍어 놨던 언어가 바로 Lisp. 제대로 공부하고 싶었으나 실용성 때문에 망설였다. 분명 언어와 그 철학을 배우면서 얻는 것도 많겠지만, 무엇보다 필요할 때 적극 활용할 수 있는 언어를 원했다. 그러던 중에 발견한 클로저. JVM 기반 언어다. Lisp dialect다. 이쯤 되면 망설일 이유가 없다.
4개월간 아이패드 스터디에 참여했다. 아꿈사가 아닌 다른 스터디 모임에. 다른 스터디는 어떻게 진행되나 궁금했기 때문이다. iOS 쪽 스터디 모임을 찾아보니 생각보다 없었다.
모두가 노트북을 들고 와서 실습 위주로 공부했다. 안 그래도 바랬던 방식인데, Xcode가 익숙하지 않았기 때문. 직접 타이핑하면서 공부하니 확실히 이해는 잘 됐다. 몰랐던 Xcode 기능도 많이 알게 됐고. 하지만 너무 오래 걸린다. 3주 정도 한 챕터만 한때도 있었다. 이렇게 너무 오래 걸리니깐 결국 문서로 코드를 전달하고 copy & paste로 진행하게 된다.
아침에 출근하면 가장 먼저 하는 일. 전날 커밋된 코드를 읽는다. 물론 읽는 건 내 코드가 아니라 동료가 커밋한 코드.
처음에는 코드를 읽을 때, 2~3시간을 썼다. 코드를 읽는 것도 중요하지만 이렇게 시간을 써버리면 곤란하다. 왜냐하면, 아직 내 역할은 코드 품질 유지보다는 생산 쪽이기 때문이다. 물론 모든 프로그래머는 둘 다 신경을 써야 한다. 하지만 역할이 한쪽으로 더 치우쳐 있기 마련이다. 현재 나는 생산 쪽에 더 치우쳐 있다. 그래서 원칙을 세웠다. 길어야 40분. 초과하면 커밋 코멘트만 보거나 내 업무와 연관된 코드만 읽는다.

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