삼성동 마이크로소프트 사무실에서 루비 사용자 모임이 있었슴.
사실 삼성동에 가도 코몰에서 밥먹거나, 전시회만 보고 왔을 뿐 그 너머에 가본 것이 꽤 오래된 듯. 그 동네에서 밤샘한거이 몇년인데…
집에서 코딩만하고 있으려니 날씨도 너무 좋고, 루비 개발자들이 뭐하고 지내는지, 다들 정말 잘쓰고있는지 궁금해서 가봤는데, 일단 재미있었고, 인사만 하고 말았지만, 꽃디앙님 얼굴도 봤다.
그런데, 개발자들하고 신나게 얘기하다가 나이를 물어보니… 띠동갑이었다.
사실 한국적 정서로는… 그냥 팀장님소리 듣고 사는게 더 정감가지 않을까. 잠시 고민했지만, 역시 보름씩 혼자 여행갈 수 있는 회사따위는 존재하지 않으니까.
Git에 대해 알고 싶다면 문서를 보면 될것이고.. 이 강연은 영어때문에 들어보곤 한다. 아직도 안들리는 부분이 있지만, 들리는 부분이 더 많아지고 있다.
토발즈가 잘난체 하는 대목이 꽤 많지만, 그다지 기분나쁘게 말하지 않는 스타일이다. (아니면 그 업적때문에 잘난체가 “체”가 아니라, 실제이기 때문일지도)
기억나는 발언들은..
“만약 CVS를 사용하시는 분이라면.. 여기 계시면 안됩니다. 저.. 정신.. 병원에 가보시던가….” (8분경)
“백업에 대한 제 생각은요. 음.. 백업을 안하는 겁니다. 저는 그냥 한 사이트에만 올리면 됩니다. 그럼 모두다 미러링해가거든요.
이런걸 갖고 공헌했다던가 하는 건 오바인것 같지만.. 나름 유명한 기욤 라포쥐님이 댓글을 달아주셨길래 기쁜마음에 글을 올린다.
기욤 라포쥐 아저씨는 내가 번역한 책의 원저자중 한명으로써, 그루비라는 언어의 대가다. (책 번역한 이야기: http://groovy-lang.tistory.com/30 )
그분이 구글 앱엔진에 그루비를 얹는 프로젝트를 진행중인데, 받아서 써보니 한글 표시에 문제가 있었다. 한 삼십분 이리저리 판 끝에 해결책을 발견, 버그 리포트와 해결방법을 함께 올렸다. (요기서 볼수있다. github)
올린지 열흘만인가.. 기욤아저씨가 답장을 주었다.
Thanks a lot for your contribution, this is very much welcome and appreciated!
루비 루비언어 자체는 “최소 놀람의 법칙” 덕분인지 그만의 색깔이 없는 것같다. 반면 파이썬은 누가봐도 ‘이건 파이썬이구나’라고 알아차릴 만큼 특징이 뚜렷한 언어였다.
최근에 들어오는 일감들은 무조건 루비온레일즈(ROR)로 진행하고 있다. 그루비를 쓸수있으면 좋겠지만 간단한 어플리케이션은 ROR로 만드는게 빠르다. 몇번 작업을 해보니 꽤 익숙해져서 간단한 넘은 정말 빠르게 만들수 있다.
헌데, 요 며칠 루비 참고서를 다시 들춰보면서, 내가 아직도 이런 종류의 언어들에서는 초보나 다름없다는 것을 깨달았다.
지금 진행중인 프로젝트에서도 루비의 yield를 쓰면 딱 좋은 상황이었는데, (그걸 쓰면 코드가 너무 간단해진다) 이상하게 코드가 길어졌다고 투덜대고 있었다.
프로젝트를 하다보면, 일정 딜레이라는 것이 일상다반사지요. 처음에 참여했던 아래아한글은 출시예정일보다 일년반쯤 뒤에 나왔었고, 그 뒤로 참여한 프로젝트들도 일정에 맞춰서 끝낸 적은 별로 없었습니다. (자랑은.. 아니지만 말입니다.)
대부분의 프로그래머들은 출시가 연기되거나, 혹은 프로젝트가 드롭되면, 내가 못나서 그런갑다. 라고 생각하게 됩니다. “작업방식의 실패”를 “개인적인 실패”로 받아들이기도 해서, 우울해집니다. 저도 그럽니다. 사실 돈은 받았는데 하기로 한일을 못했으니, 무슨 의미로든 실패는 실패죠.
왜 매번 그렇게 늦어지는지 처음엔 잘 몰랐더랬습니다만, 미국사람들이 “unknown issue” 때문이라고 답을 주더군요.
나이가 들수록, 프로젝트가 바쁠수록 게을러진다. 그래도 열심히 공부하는 동료들을 보면 나를 채찍질하게된다. 문제는 책값인데, 도서관을 이용하면 좋지만, 신간은 대출 경쟁에서 밀려 2주이상 기다려야 하는 일도있고, 서점까지 쫓아온 지름신께서 ‘이건 소장해야해’라고 속삭이기도 하신다.
결혼 후에는 집사람 눈치도 봐야하기 때문에, ‘한달에 얼마’ 라고 정해놓은 책값을 잊지 말아야 한다. 이래저래 책 읽기가 힘들다.
이런 형편이니, 공짜 책만큼 기분 좋은 선물이 없겠다. 그루비 프로그래밍으로 인연을 맺은 인사이트에서 책을 한권 보내주셨다. (그리고… 그루비 프로그래밍 좋은 책이다.
프로그래밍 그루비 기욤 라포르쥬 외 지음, 박제권 옮김/인사이트
원서는 Groovy in Action. 이 책이 나온 것은 2006년. 나는 06년 12월 5일에 PDF 버전을 사서 읽었었고, 덕분에 그때 진행하던 프로젝트에 재미있게 적용했었다. 그때, 이런 책은 번역판 안나오나, 하는 생각을 했었다. 좋은 기술인데 국내에는 알려지지 않는게 안타까웠다.
그리고, 일년 뒤 겨울. 더 이상은 회사에 출퇴근하는 생활을 하지 않겠다, 는 결심을 하고 이것 저것 손대고 있었는데, 루비온레일즈라는 것을 만져보니 너무 재미있었다. 양재동 “DAUM”사무실에서 루비 사용자 모임 세미나를 한다길래 한번 나가봤다.
Jas 10.4.8 이란 것으로 했다.
F8: -v -f -x -legacy platform=ACPI
“한글” 선택
디스크 유틸리티에서 새로 파티션 만들었음. (http://x86osx.com/bbs/view.php?id=osxtips&no=785)
어려운 일은 아니고, 그저 “3일동안 고생했어요” 정도. 아주 오래 전에 슬랙웨어를 설치할 때와 비슷했다.
그 다음에는 데비안, 우분투까지 설치해보고는 windows 2000을 설치했다. 다시 XP로 가기에는 뭔가 아쉬움이 남아서..
참고링크들 : 참고, 참고, 참고, 참고, 참고, 참고, 참고
이미 보안뉴스같은 곳에 떴을지도 모르고, 어쩌면 모두 모두 알고있는 얘기의 뒷북일지도 모르지만, 오늘 당했으니까, 다른 분들도 조심하라는 의미에서 알립니다.
데이콤의 SMS 전송 대행 서비스 중에 EMMA 라는 이름의 서비스가 있습니다. 데몬으로 떠서 동작하는 타입이구요. 웹 페이지쪽에서 사용자가 SMS 전송을 요청하면 지정된 데이터베이스 테이블에 넣어둡니다. 그러면 주기적으로 emma 데몬이 테이블을 검색해서 데이콤 서버쪽으로 전송하고, 데이콤쪽에서 이를 SMS로 수신자에게 보내주는 방식입니다.
제가 돌보고 있는 사이트에서도 이 emma라는 녀석을 쓰는데, 오늘 여기서 문제가 터졌네요.
작년 겨울에 시작한 어느 기술 서적의 번역이 거의 끝났다.
G: Good. You create the corresponding ‘Visit’ object and save it. Perfect. 좋군. Visit 객체를 만들고 저장한다. 완벽해.
D: And I added a convenience feature in the last line. After the button click, there is no point in staying on the same page. We go directly to the next one. 마지막 줄에 편리한 기능을 하나 더 추가했어. 버튼을 클릭하면, 같은 페이지에 있을 필요가 없잖아.
한동안 아마존의 AWS를 쳐다보면서 여기로 옮겨가면 서버 관리를 안해도 되니까, 정말좋겠네.. 라고 흥얼거렸다.
지금 사용하고 있는 호스팅회사에서는 30M dedicated 에 88만원을 내라는 고지서를 보내왔다.
그런데, AWS를 쓰면
CPU20개랑 하드 1690G를 한달 쓰는데 56만원이면 된다.
CPU2개에 7.5G메모리, 850G 하드를 쓰는데는 28만원. (AWS 계산기)
서버 임대료는 이거로 끝. (상면비, 보안서비스, 등등등 필요없다.)
트래픽은 잘 계산이 안되는데, 한달에 5000G 그러니까, 5 테라바이트 정도 전송하면 그때 과금이 80만원 정도 된다. (지금 우리가 쓰는 건 30M dedi 이지만, 실상 한달 총 전송량을 보면 3500G 즉, 3.
며칠전에 데비안의 OpenSSL에 보안 이슈가 발생했다는 뉴스가 떠서 서버들을 업그레이드 해줬었다. 역시 데비안이 제일 빠르다고 속으로 칭찬했었는데, 오늘 보니 이 문제는 “데비안의 문제”였다.
브루스님의 글을 보고 알았다. 원인은 valgrind 라는 툴로 OpenSSL의 소스를 검사한 메인테이너가
MD_Update(&m,buf,j); /* purify complains */
라는 코드에서 “buf”가 초기화 되지 않았다는 경고를 보고, 간단하게 주석처리 해버린 것.
하지만 이 코드는
#ifndef PURIFY MD_Update(&m,buf,j); /* purify complains */ #endif
라고 -DPURIFY를 주면 비켜갈 수 있었다.
이전의 사이트 튜닝 작업을 계속하고 있다. 일단 어제까지의 작업으로 지금 할 수 있는 거의 모든 튜닝은 끝났다.
어제 한 작업은, 두대의 DB 서버중에 과도하게 느린 쪽에 CPU 와 메모리를 하나 추가해주고, 방화벽도 요청하고, 그리고, mysql을 최신버전인 mysql 5.0.52a 로 버전업하기. 이전에 사용중이던 녀석은 무려 3.23 ! 한꺼번에 두계단을 뛰어올랐다. 게다가 replication 까지 다시 셋업!
겁먹고 한 일이었지만, 버전업이나 replication 설정이나 그렇게 어려운 일도 아니었다. 복잡해 보이지만, 안되는 건 아니다.
구글 앱 엔진(App Engine)을 뒤져보다가, 원래의 고민지점이었던 mysql 을 대신할만한 무언가, 로 돌아가서 다시한번 뒤져 봤다.
최종적으로는 “구글 빅테이블이 발표되길 기다려보자.” 는 것으로 끝냈지만, 거기까지 가는 과정도 적어둘만 하다.
아파치의 카우치는 아예 데이터베이스에서 REST를 지원해버리자는, 게다가 리턴하는 데이터도 JSON으로 해버리자는 프로젝트. AJAX를 쓰는 사이트라면 눈이 돌아가겠다.
카우치에서부터 시작한 탐색은 이리저리 흘러가다가, 아마존 EC2, S3 쪽으로도 갔었다.
EC2 는 자기네가 가진 몇 천대의 컴퓨터를 돈받고 빌려주는 서비스 S3 는 자기네가 가진 하드디스크를 돈받고 빌려주는 서비스 전에도 들어본 적은 있었지만, 내가 쓸일이 있을까 하는 마음에 그냥 지나쳤던 녀석들.
요 며칠 ….
아쿠아 웹사이트를 튜닝했다.
점심시간 쯤에 시간당 페이지뷰가 10000~20000 정도 되는 사이트였는데, 이상하게 느렸다.
캐시서버가 앞단에 붙어있고, DB 서버 두대를 붙여서 로드밸런싱을 하고 있었다. 그래도, 느린 거였다.
이 정도로 접속이 많은 웹사이트를 까보기는 처음이니까, 이게 맞는 걸까, 하드웨어를 더 늘려야 하는 걸까, 잘 모르는 일이었다.
호스팅회사에 자문을 구했더니, 그쪽에서는
DB 쿼리중에 10초이상 걸리는 것들이 있었다. DB와 웹서버 사이에 이상하게 트래픽이 많다. (DB와 웹사이가 100Mbps 정도.
가까운 사람에게 보내는 글이나, 나중에 혼자 보려고 쓰는 글에는 별로 사용하지 않는 문체다. 오로지 보고서 (그중에서도 갑에게 보내는 보고서) 에만 사용하는 문체다. 바로 이런 문체.
검수항목중 “3.3.3 OEM의 특수키 처리 기능” 을 구현하는 과정에서는 우선 일반적인 BREW 어플리케이션을 작성한 후, 검수문서에 나오는 것과 최대한 비슷한 UI 를 가지도록 하였다. UI 처리는 EVT_APP_START 와 EVT_APP_RESUME 이벤트에서 타이틀바와 메인화면을 그리는 함수를 호출하여서 구현했으며, 관련 함수는 COMMON.c 에서 확인할 수 있다. 세개의 어플리케이션 (XXXXX1, XXXXX2, XXXX3)은 공유하는 부분이 많은 어플리케이션들이므로 COMMON.
열심히 일하는 중에 정신을 차려보니, 뭔가 이상한 느낌이 들어, 번역한 것을 읽어보았다.
Inside the Java runtime, classes are managed by a classloader. When a Java classloader is asked for a certain class, it loads the class from the *.class file, stores it in a cache, and returns it.
자바 실행 환경에서 클래스는 클래스로더가 관리한다. 어떤 클래스를 요청하면, 자바 클래스로더는 *.class 파일을 찾아서 요청받은 클래스를 읽어 들인 후 캐시에 저장하고 리턴한다.
이런 문장을 번역할 일이 생겼다.
Fundamental progress has to do with the reinterpretation of basic ideas. -Alfred North Whitehead
처음에는
중요한 발전은 기본사상의 재해석이다. -알프레드 노드 화이트헤드
그리고는
중대한 발전은 기본적인 사상을 새롭게 번역하는 것이다. -알프레드 노스 화이트헤드
또는
발전이란 근본적으로 기본사상을 새롭게 해석하는 것과 관련이 있다. - 알프레드 노스 화이트헤드
한참 뒤져보고는
근본적인 발전은 기초적인 사상을 새롭게 해석하는 것과 관련이 있다.
루비라는 프로그래밍 언어를 사용해서 용역을 하고 있다. 이걸 쓰는 사람들이 국내에도 있다고 하고, 게다가 세미나도 한다고 해서.. 몸상태는 안좋았지만, 참석해보았다.
오랜만에 개발자들의 살아있는 목소리를 듣고 있으려니, 회색파티션 속에서 살아가던 기억이 떠올랐다. 흐뭇했다. 살짝 얼굴이 가려졌지만, 옆자리에는 레일스레시피랑, 애자일레일즈번역하신 “김석준님”이 앉으셨다. 유명한 분이다. 흐..
전체적인 분위기는, 아직 개발자 수가 많지 않은 상태라서 “앞서가는 소수” 라는 공감대가 느껴지는 모임이었다. 플리커에 이날의 풍경이 올라와있다.
게다가, 스프링노트도 받고, 다음에서 주는 UCC 망치도 받고, 책도받고, 가방도 받았다.
계속 쓰다보니, 편리한 것은 알겠는데… 사실
1. 나는 CRUD 로만 끝나는 사이트를 만들고 있지 않다. 세상에는 “데이터베이스입출력 + 사용자인증” 으로 끝나는 사이트 들이 엄청나게 많다. 하지만, 지금 만드는 사이트는 그정도로 끝날 것 같지는 않다. 어차피 내손으로 짜야하는 복잡한 부분들이 엄청나게 남아있다.
2. DB에 대한 추상화까지는 필요없다. (sql 문장 만드는게 그렇게 어렵지는 않아..) SQL 문장대신에 Model
class User { String loginid; String passwd; String toString() { loginid } static constraints = { loginid(unique:true) passwd(blank:false, password:true) } } 이런 클래스를 만들어두는것이 나쁜 생각은 아닌데, 그래도 나는 여전히 Hibernate 같은 것을 꼭 달고 다녀야한다는 점이 마음에 들지 않는다.