Grails에도 ORM이 있군요. Object-Relational Mapping은 프로그래밍에서 자동화의 한축을 그은 기법입니다. 위키피디어의 정의를 참고하세요.

프로그래밍하면서 잡스러운 일들을 자동화시키려고 많은 프레임워크들과 라이브러리들이 나왔습니다. 그리고 CoC(Convention over Configuration)같은 개념들도 귀차니즘을 기반해서 나온 것들이죠. 똑똑한 프로그래머들은 자동화할 포인트를 찾으면 가차 없이 나옵니다.

GORM은 하이버네이트를 그루비(Groovy)로 살짝 덧씌운 것이다("Gibernate"가 "GORM"보다 발음하기가 어려워 쓰이지 않는 것으로 추측한다).
from:
dw: GORM: 재미있는 이름, 진지한 기술 (한글)

가이버네이트보다는 GORM이라는 이름이 더 낫다고 합니다. (맥가이버가 생각나는 저는 ^^;)


공부거리가 자꾸 생겨서 심통이 납니다. 언제 활용하라구요. ^^;
일상이 무료한 개발자는 따라가보셔도 좋을 듯 합니다.
http://www.ibm.com/developerworks/kr/library/j-grails02128/index.html?ca=drs-kr
^^b

어제 저녁 IBM developerWorks 리뷰 블로거 미팅이 있었습니다.
킹왕짱 동안이신 산골소년님을 비롯해서 권용호열이아빠서광열안영회배유미님을 뵙게 되었죠.
좋은 컨텐츠이 그득히 들어있는 developerWorks의 컨텐츠를 노출시키기 위해서 불철주야 노력하시는 IBM 이선진 과장님을 중심으로 한 팀과 엔진오일 역할을 잘 하시는 기묘 팀과 함께 모여서 킥오프급의 맛있는 저녁식사와 함께 얘기를 나눌 수 있었습니다.

어제 제가 너무 많은 말을 한 것 같아서 다른 분들 말할 기회를 뺏은 것은 아닌지 미안하기도 합니다. 다들 좋은 블로깅을 하고 계신 프로그래밍, 시스템 업계의 파워블로거들이신데, 함께 자리를 갖게 되어서 정말 즐거웠습니다. (ㅡㅡ; 혼자만 좋아했는지도 모릅니다.)

더 열심히 리뷰를 해드리고 싶다는 포부를 밝혀 봅니다. ^^;
사용자 삽입 이미지

자바를 좀 한다고 하는 사람들은 TDD를 들어봤을 것입니다. Test Driven Development, 즉 테스트로 주도하는 개발 방법입니다. 2003년인가 http://xper.org 에서 김창준님이 주최하는 XP 그 세번째 이야기 라고 기억되는 연극형 세미나에서 감명을 받은 이후로 계속해서 시도하고 있는 개발방법입니다. 6년째이지만 아직 잘 못하는 방법이기도 합니다.

방법이 기괴한데 먼저 테스트 코드를 짭니다. 테스트의 대상이 되는 코드를 짜기 전에 말이죠. 그래서 이런 형태가 됩니다.
assertEquals( 2, add(1, 1) );


1과 1을 인수로 하는 add() 메소드의 결과는 2와 같아야 된다는 뜻인데, 아직 add() 메소드가 만들어지지 않았지만 이렇게 먼저 선언, 또는 정의합니다. add() 메소드의 결과 동작을 먼저 만드는 것이죠. 에러 납니다. 컴파일도 안됩니다. 아직 없으니까요.

그 다음 동작은 add() 라는 메소드를 만드는 것입니다. 그럼 저 테스트 코드로 add() 메소드의 결과를 확인해 볼 수 있겠죠. 이렇게 개발을 하니 모든 메소드는 자동으로 실행할 수 있는 테스트 코드들을 갖고 있게 됩니다. 이게 모이게 되면 전체 애플리케이션을 테스트할 수 있는 집합체가 구성되는 것이죠.

그런데 이런 방식에는 테스트라는 단어의 레거시가 너무 강했습니다. 일반적인 상식에서는 테스트라 함은 후에 위치한다는 것이 자연스럽기 때문입니다.

사용자 삽입 이미지

그래서 나온 것이 Behavior Driven Development(행위 주도 개발 BDD) 입니다. 자바에서는 JBehave 라는 xUnit과 비슷한 개념으로 나온 것이 있습니다. 이에 관한 developerWorks의 기사를 추천합니다. 사실 저도 Kenny군에게서 일,이 년 전부터 계속 듣기는 했는데, 솔직히 말장난한다는 느낌이 들어서 안 했거든요.

TDD를 하지 않는 이유 중 가장 흔한 것이 "테스팅할 시간이 없어요"와 "테스트하기에 너무 복잡하고 힘든 코드"라는 것이다. 테스트 우선 프로그래밍의 또 다른 장애물은 테스트 우선이라는 개념 그 자체다. 우리 대부분은 테스팅을 감촉적(tactile) 행위, 추상적이기보다는 구체적인 행위로 본다. 우리는 경험적으로 존재하지 않는 어떤 것을 테스트하는 것이 가능하지 않다고 생각한다. 이 개념적인 프레임이 머릿속에 이미 자리잡은 일부 개발자들에게는 '테스트 우선(testing first)'이라는 아이디어가 바보 같은 일로 여겨진다.

그러나 테스트를 작성하고 어떻게 테스트할 것인가 하는 관점이 아닌, 행위(behavior)에 대해 생각해 본다면 어떨까? 여기서 말하는 행위란 애플리케이션이 어떻게 동작'해야' 하는가, 즉 본질적으로 그것의 명세를 말하는 것이다.


국내에도 IDD라 하여 Intention Driven Development를 얘기합니다만 가장 빨리 만들어 내는 방법이라 하여 얘기한다면 BDD와 다르다고 할 수 밖에 없을 듯 합니다. TDD나 BDD의 장점은 Test Harness를 마련해서 기능 추가나 변경에 따른 영향도 감지가 부수적으로 오게 되는 것인데, 그것을 얘기하지 않는다면 유지보수하는 사람들의 고통이 필요하기 때문이죠.
오픈소스에 대한 얘기는 갈 수록 높아져 가고 있습니다. Freeware, Shareware 등으로 사용되는 애플리케이션과는 달리 소스까지 공개된 프로그램을 오픈소스라고 하지만, 오픈소스 제품은 공짜로서의 의미보다 기술의 공개라는 차원에서 더 가치가 있습니다.

developerWorks에 나온 "오픈 소스 입문"에 대한 글이 입문용으로 가볍게 읽을 만 합니다.

한 마디로 말해서, 오픈 소스는 협업(collaboration)이라고 할 수 있다. 보다 구체적으로 말하면, 소프트웨어 프로젝트에 대한 공개적 협업(public collaboration)이다.

Open Source Initiative 라는 단체가 만들어지고 오픈소스에 대한 라이센스와 가이드를 제시하고 있습니다.

오픈소스 제품이 시장에서 큰 역할을 하는 것을 예를 들면 리눅스, 아파치 웹 서버 등을 예로 들 수 있습니다.

오픈소스로 제품의 수준이 상용과 비길 수 있을 때 듀얼라이센스로 판매도 됩니다. 대표적인 것이 MySQL 같은 것이 되겠죠.


오픈 소스 작업을 위한 몇 가지 도구들이 있습니다.
Source Repository : CVS, SVN 같은 소스 버전관리 저장소입니다.
Mailing LIst : 사용자와 개발자 모두 메일을 통해서 의견 교환을 하는 경우가 많습니다. 종종 게시판이나 포럼도 사용되지만 대세는 메일링 리스트입니다.
Issue Tracker : Bugzilla, Trac, JIRA 와 같이 이슈, 버그 등을 등록해서 처리과정을 확인할 수 있는 시스템입니다.
Documentation Site : 오픈소스의 특성상 상용 제품보다 많이 부족하다고 느껴지는 부분입니다. 잘 나가는 오픈소스의 경우 매뉴얼 페이지가 잘 갱신되고 관리된다고 생각됩니다.


오픈소스 프로젝트를 호스팅하는 사이트들도 많이 있습니다. http://sourceforge.net, http://code.google.com/, http://kldp.net 등을 추천합니다.

제가 오픈해 놓은 소스 프로젝트도 있습니다.
http://code.google.com/p/daysago, http://code.google.com/p/shopgallery, http://code.google.com/p/unicodereader

작은 코드 조각(snippet)이지만 시작이 너무 크면 부담되거든요. ^^
2006년 javaone에 갔을 때 grailstrails에 관한 강의를 들었습니다.
Grails는 Groovy + Rails 프레임워크이고 Trails는 Tapestry를 중심으로한 Rails 프레임워크입니다.

Groovy의 발음이 Ruby와 얼마나 많이 닮았는지 아신다면 조금 더 재미있을 것입니다. 따라쟁이 자바 같으니라구요.

http://www.ibm.com/developerworks/kr/library/j-grails01158/ 에 Grails에 관한 좋은 기사가 올라왔습니다.

맘에 드는 구절이 있군요.
더 이상 getter와 setter를 짤 필요가 없다. 그루비가 자동으로 이를 제공하기 때문이다.
EJB를 비롯해서 많은 프레임워크들이 번잡스럽게 여겨지는 이유는 많은 코드양입니다. 자동으로 생성되는 Code Generator를 만들어 써도 관리에서 시간 잡아먹는 역할이기 때문에 정말 비즈니스에만 집중하기가 힘듭니다. 더구나 IDE가 없다면 더 힘들어집니다.

Convention over Configuration 이라는 좋은 사상으로 이러한 문제가 많이 해소되었습니다. Grails에서 얘기하는 Groovy의 역할도 코드의 양을 획기적으로 줄여준다고 합니다.

배움을 그치기에는 자바 세상은 너무도 넓은 것 같습니다.
Hello World 는 빙산의 일각인 것이죠.

제 IBM T42 노트북은 회사에서 제가 짤리지 않도록 제 역할을 다하고 있는 멋진 놈입니다.
작년 2월에 어댑터를 분실해서 용산에서 4만원 넘게 주고 산 어댑터를 쓰고 있는데, 대략 반년 전 부터 접속이 삐리리해졌습니다. 노트북에 전원 연결하는 부분이 미세한 튜닝을 해야 간신히 전원연결이 되기 때문에, 자리를 이동하는 것이 고역이었습니다. 지난 일요일 결심을 했죠.
너 죽고 나 죽자. 실패하면 하나 더 구해야지 뭐. 어차피 널 못 고치는 것이나, 새로운 것을 사는 것이나 크게 다르지 않기 때문에, 수술을 해보자 라고 결론을 내었습니다.

잘 보이던 도루X 드르륵 칼을 찾아 삼만리하고, 창고처럼 푹 쳐박힌 서랍을 뒤져서 인두기와 땜질용 납을 찾아 보았지만, 인두기는 포기했습니다. 납만 찾았습니다. 그래서 뻰지에 탈착용 드라이버 날을 물고 가스불로 가열해서 인두 대용을 했습니다.

노트북 연결부를 드르륵칼로 절개하고 문제가 생긴 부위를 찾았습니다.
인두질을 시도했지만 번번히 실패. 그냥 꽈배기로 돌리고, 절연테이프로 칭칭 감았습니다.
그 모습이 이것이죠.

여튼 잘 수리되었습니다. 시원하더군요.
어릴 적 라디오 키트 경진대회도 나가고 했는데, 잠자던 본능이 깨어나는 듯 했습니다.
역시 손에 연장을 드는 것은 즐겁습니다.

수술 받은 어댑터

수술 받은 어댑터

수술 부위 정면

수술 부위 정면


ps. 중국산은 각오하고 사야될 것 같네요. ㄷㄷㄷ

+ Recent posts