프로그래밍 그루비 기욤 라포르쥬 외 지음, 박제권 옮김/인사이트
원서는 Groovy in Action. 이 책이 나온 것은 2006년. 나는 06년 12월 5일에 PDF 버전을 사서 읽었었고, 덕분에 그때 진행하던 프로젝트에 재미있게 적용했었다. 그때, 이런 책은 번역판 안나오나, 하는 생각을 했었다. 좋은 기술인데 국내에는 알려지지 않는게 안타까웠다.
그리고, 일년 뒤 겨울. 더 이상은 회사에 출퇴근하는 생활을 하지 않겠다, 는 결심을 하고 이것 저것 손대고 있었는데, 루비온레일즈라는 것을 만져보니 너무 재미있었다. 양재동 “DAUM”사무실에서 루비 사용자 모임 세미나를 한다길래 한번 나가봤다.
작년 겨울에 시작한 어느 기술 서적의 번역이 거의 끝났다.
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. 마지막 줄에 편리한 기능을 하나 더 추가했어. 버튼을 클릭하면, 같은 페이지에 있을 필요가 없잖아.
루비라는 프로그래밍 언어를 사용해서 용역을 하고 있다. 이걸 쓰는 사람들이 국내에도 있다고 하고, 게다가 세미나도 한다고 해서.. 몸상태는 안좋았지만, 참석해보았다.
오랜만에 개발자들의 살아있는 목소리를 듣고 있으려니, 회색파티션 속에서 살아가던 기억이 떠올랐다. 흐뭇했다. 살짝 얼굴이 가려졌지만, 옆자리에는 레일스레시피랑, 애자일레일즈번역하신 “김석준님”이 앉으셨다. 유명한 분이다. 흐..
전체적인 분위기는, 아직 개발자 수가 많지 않은 상태라서 “앞서가는 소수” 라는 공감대가 느껴지는 모임이었다. 플리커에 이날의 풍경이 올라와있다.
게다가, 스프링노트도 받고, 다음에서 주는 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 같은 것을 꼭 달고 다녀야한다는 점이 마음에 들지 않는다.
파이선으로 시작한 한동안의 방황은 결국 다시 자바로 돌아왔다.
자바서버쪽에 Spring, Hibernate 따위 복잡한 도구들이 있는데, 아무리 잘 써볼라고 해도, XML 로 귀찮게 하거나, SQL 대신 HQL 을 들이밀거나 해서 안쓰고 있었다.
Groovy and Grails 는 이런 복잡한 녀석들을 Groovy 라는 언어를 이용해서 간단하게 뛰어넘고 있다. Groovy는 상당히 유연한 언어인데, Groovy 가 없었다면, 당연히 Grails 도 없었을 것 같다.
국내에서는 Groovy 관련한 리소스가 별로없는데, 사실 세계적으로도 별로 없다. 다만, 자바기반이니까, 스크립트 언어니까, 이리저리 건드려보면 대강 돌아가게는 할 수 있었다.
아직 아니다. 루비가 느리기 때문이다.
동일한 기능을 하는 python cgi 보다 rails 가 더 느렸다. 게다가 메모리를 더 많이 먹었고, CPU 도 99% 먹는 것도 가능했다. 대단히 느리다. http request 한번에 CPU 18 % 를 기본적으로 차지하곤 한다.
yarv 가 있다지만, debian 쪽에서는 experimental 이다. ubunto에는 없다. 버그 많을꺼라고 경고하는 녀석을 채택할 수 는 없다.
dispatch.fcgi 가 좋다고 해서 써봤더니, 이번엔 이녀석이 cpu 를 먹는다. 또, 메모리도 차치해버린다. 이런.
문법이 좋긴 좋은데… 이만한 희생을 할만큼 좋은 걸까.
파이선을 배워보려고 몇번이나 시도했었지만, 잘 안됐었다. 지난주에야 실용적인 프로그램 몇가지를 만들어봤다. 그리고, 이 블로그에서도 몇가지 기능은 파이선으로 바꿔봤다.
프로그램을 하나 작성하는데 드는 비용은 지금까지 만난 어떤 언어보다도 저렴했다. 언어자체도 쓰면 쓸수록 손에 익어가는 재미가 있었다. 아래는 디렉토리 리스트를 돌면서 어떤 파일들을 지우는 스크립트다. 이런 종류의 프로그램을 만들때는 파이선만한 것이 없는 것 같다.
#!/usr/bin/python import os boardnames = \ ["mydir" ,"이름"],\ ["other" ,"이름"] def proc_board(board): for f in os.listdir(board): if f[-3:] == "jpg" and f[:2] == "fe": size= os.