썰렁한 엔지니어

vim 뒤에 파일명이 압축 확장자(.gz, .Z, .bz2)로 되어 있다면, $ vim maillog.1.gz 바로 읽을 수 있다. /usr/local/share/vim/vim60/plugin/gzip.vim 이라는 플러그인이 확장자를 알아서 인식하여 전처리를 해주기 때문이다. 물론, 저장할 때 후처리로 다시 압축하여 저장하는 센스도 발휘 해준다. 로그가 압축되어 있을 때, 그 얼마나 편리한 기능인가!

다음과 같은 시나리오를 살펴 보자. "소스 디렉토리 A 의 a.c의 내용을 복사하여 소스 디렉토리 B의 b.c 로 사용해야할 일이 생겼다. 제품이 늘어 나고 있거든!" (물론 코드는 되도록 복사해서 사용해서는 안되지만 우리는 그런 완벽한 세상에서 살지 않으므로...) 이 경우. $ pwd /work/project_x/src/agent $ cp a.c ../log $ cd ../log $ svn add a.c $ svn commit $ svn log a.c위와 같이 하면, 중대한 것을 잃게 된다. a.c 의 지금까지의 변경기록이다. 다음과 같이 해야 정석이다. $ pwd /work/project_x/src/agent $ svn cp a.c ../log $ cd ../log $ svn commit $ svn..

http://en.wikipedia.org/wiki/Bleeding_edge 위키피디아에서 설명한 내용을 보면, 컴퓨터 세계에서 최전방 기술을 의미하며, Leading 보다 더 앞에서 처절한 사투를 하고 있는 영역을 의미한다고 되어 있다. 그 설명의 마지막에 이렇게 씌어 있다. "But when you’re living on the bleeding edge, you should not be surprised when you do, in fact, bleed." 그런 영역에서 살고 있다면, 당신이 피흘릴지라도 놀라지 말아야한다. 모험을 즐기는 사람이라면, 한번 쯤 피흘려가면서 일해야 할텐데...

내가 하는 번역중 가장 활발하게 일하는 것이 TortoiseSVN이다. 비록 번역이긴하지만 Open Source에 기여하고 있고, 나름 대로 feedback을 받으며, 내 활동의 일부를 도움받는다. feedback은 딱 한 사람으로부터 오는데, tdkim 씨이다. 이 자리를 빌어 꾸준히 피드백해주고 있어 감사하다는 말을 하고 싶다. 이 분은, 시간날 때마다 TortoiseSVN의 nightly build를 받아다가 버그리포트도 활발히 하는 분인데, 재미를 가지고 있는 소프트웨어에 그런 열정을 들이는 것이 이런일하는 재미아니겠는가. Tdkim! 제게 번역 교정 리포트하시는 것에 미안하게 생각하지 말아주시라. 맞닥드리지 않은 상황을 번역하는 것이 어려운것이 사실이고, 가끔 자동 번역 결과를 확인도 안하고 커..

봄이다. 일주일 동안 밤에 집에서 "다모"를 다 보고... 우연히 주말에 "내 사랑 ssㅏ가지"를 보고... 난생처음 연예인에게 마음뺐길정도로 싱숭생숭한 느낌까지 들고 있다. 며칠 가다 말겠지만, 애 둘 가진 아빠가 요즘 왜 이러냐... 집안일이 힘든가? 회사일이 미안한가? 이은주씨, 일주일 뒤 집에 오면 파티 합시다. 넷이서 알콩하게 삽시다.

ctrl 키를 두 번빨리 눌러보시라... 검색을 빨리 할 수 있는 창이 중앙에 나온다.

도메인이 바뀐지 일주일이 됐다. 그전에는 꾸준히 180명이 방문했었는데 요즘은 25명으로 줄었다. 1/7이라... 과연 어떤 사람들이 내 홈을 방문했었을까? 아직 구글에서 이 도메인으로 검색이 되고 있지 않은걸 보면, 구글의 로봇 방문이 안이루어졌기 때문아닐까? 재밌는 통계가 될 것 같다. 도메인을 바꾸었을 때, 원래의 트래픽을 찾기까지 변화되는 referrer를 분석해봐야겠다.

어쩌다가 이번주부터 14부짜리 다모를 보기 시작하였는데, 하루에 세 편씩 소화(?) 해내고 있다. 평균 취침시간 새벽 3시 반. 급기야 오늘 출근하다 졸아 세 정거장을 지나치는 폐인조짐을 보였으니... 몸에 안좋은 드라마는 빨리 봐서 없애야겠다. 이게 왠 때 늦은 다모폐인이란 말이냐... 다모의 링크: http://www.imbc.com/broad/tv/drama/damo/

어떤 분야의 설계든 철학은 같으리라고 본다. 전체를 적당한 개념으로 나누고, 용어를 아는 사람이 보았을 때 같은 것을 만들어 낼 수 있도록 하는 것이 그것이다. 따라서 설계할 때 가져야할 자세는 세부 사항을 만들어 갈 때, 비슷한 교육을 받은 남이 봐도 알 수 있는가라는 것이다. 내가 볼 때, 설계를 처음 시작하는 사람이 가장 어려운 것은, 그 "남"이라는 사람의 지식 수준을 결정하지 못하는 것이고, 따라서 기술하는 내용의 깊이가 들쑥 날쑥하게 된다. 또, 설계할 때 가져야할 자세는 설계를 구현할 때, 구현자들이 대화를 많이 하지 않아도 또한 다른 구현자들의 구현 정도와 상관없이 부분부분을 독립적으로 구현해서 나중에 조립할 때, 적절하게 붙을 수 있도록 하는 것이다. 개발기간이 늘어나는 이유 중 하나는 ..

전략 시뮬레이션 게임들을 하다보면 자주 듣는 말이.. "정찰이 중요해." "정찰을 못해서 게임에서 졌어." "정찰을 잘한덕에 신속한 방어를 했어." 이런 것들이다. 게임이란 상대와 닫힌 규칙안에서 노는 것이고, 세상을 사는 것이란 게임과 비교해서는 상당히 열린 규칙안에서 노는 것이다. (물론, 집단의 전쟁이나 암살 등에서는 완전 열린 규칙에서 노는 것이겠지만..) 난 요즘 세상을 살기 위한 정찰을 게을리 하지 않나... 늘 고민된다. 강박관념처럼 정보를 수집하는 것에 예민해져있다. 아니, 정보를 수집하지 못하는 느낌 때문에 예민해져있는지도 모른다. 정작, 정보다운 정보는 없는 것 일지도...