[vert.x] Hello Vert.x Module

Vert.x는 Verticle이라는 클래스를 상속한 .Java 파일을 실행할 수도 있고 프로젝트를 모듈화한 모듈을 실행할 수도 있습니다.

http://vertx.io/manual.html#interacting-with-vertx

자세한 내용은 위 링크를 참조하시구요. .java를 실행하는 예제는 쉽기 때문에 별다른 설명은 필요없을 것 같고, 저는 모듈을 실행하는 방법을 설명하겠습니다.

그러려면 모듈 프로젝트를 만들어야 하는게 이게 좀 일이죠. 그래서 제가 기본 골격을 만들어 두었습니다.

https://github.com/keesun/mod-sample

이 프로젝트를 받아서 각자 자신의 모듈을 만드실 때 사용하시면 됩니다.

git clone git://github.com/keesun/mod-sample.git

Git 지우기

받으신 다음에 mod-sample 디렉토리로 이동해서 .git/ 디렉토리를 지워주시면 깔끔합니다. 요즘은 svn도 이렇게 한곳에만 파일을 둔다는데 이전에는 굉장히 지져분하게 디렉토리별로 .svn이 생겼었죠. 그래서 그걸 전부 지우는 스크립트도 사용하고 그랬었는데.. git은 안그래도 됩니다.

빌드하기

빌드툴은 gradle을 사용합니다. 이유는 잘 모르겠고, 아마 스프링소스에서 그루비를 밀어주려고 그래들을 사용하는게 아닐까 싶기도 하고 메이븐이 너무 복잡하니까 그래들을 사용하는 것 같기도 하고 여러가지 추정은 가지만 뭐.. 팀 폭스가 그래들을 쓰니깐.. 저도 그래들.

유닉스/리눅스 계열 유저는 ./mk 를 사용하시면 되고 윈도 유저는 ./wmk를 사용하시면 됩니다.

./mk tasks라고 입력하신 다음에 커피를 한잔 드세요. 처음 빌드 하신 분들은 인터넷과 컴터 사양에 따라 대략 10분 ~ 15분 정도 걸립니다.

사용하는 IDE 파일 생성하기

이클립스나 IDEA 유저가 대부분일텐데요. 그러한 IDE 관련 파일은 절대로 버전 관리에 넣으시면 안 되는거 아시죠? 그거 개인 마다 다 달라지는 파일이라서 보통 버전 관리에 넣지 않아요. 그거 넣으면 뭔가… 이 사람 협업을 많이 안 해 봤나… 아님 초본가… 하는 생각이 드니까 조심하시기 바랍니다.

그래서 보통 로컬에서 생성해서 사용합니다. 그걸 직접할리는 없고 그래들 빌드를 돌리면 생성됩니다.

IDEA 유저는 ./mk idea 이클립스 유저는 ./mk eclipse 라고 하면 IDE 관련 파일들이 생겨서 IDE에서 프로젝트를 열거나 import 하실 수 있습니다.

IDE로 보면 대략 이런 모습인데요. 여기서 중요한 파일이 src/main/mod.json입니다. 이 파일이 모듈 설정 파일인데, 저도 정확히 어떤 속성들이 존재하는지 모르겠습니다.

아마도 Vert.x 코드를 까보면 보일텐데;; 제가 지금 아는 수준은 매뉴얼에서 설정하는 수준 뿐입니다.

http://vertx.io/mods_manual.html

모듈을 크게 둘로 나눠서 실행 가능한 모듈(실행 모듈)과 그렇지 않은 모듈(비실행 모듈)이 있는데 지금 제가 샘플로 제공하는 것은 실행 가능한 모듈입니다. 물론 이걸 조금 수정해서 비실행 모듈로 만들 수도 있습니다. 구분은 main이라는 속성으로 합니다.

{
“main”: “me.whiteship.HelloVertxModule”
}

지금 mod.json을 보면 이렇게 main 이라는 속성에 Verticle을 상속받은 클래스 전체 경로를 적어둔 것을 볼 수 있습니다.

Verticle을 상속받으면 start()라는 메서드를 구현해야 하는데 위와 같이 구현하면 아주 단순한 웹 서버를 만들 수 있습니다.

모듈 만들기

이제 다시 콘솔로 이동해서 이 프로젝트를 모듈로 빌드해보죠.

./mk clean dist

./mk dist라고만 해도 될듯한데 그냥 깨끗하게 빌드 하려고 저는 ./mk clean으로 빌드 디렉토리 다 지운담에 다시 dist로 빌드 하도록 ./mk clean dist를 주로 씁니다.

빌드가 되면 프로젝트홈/build/mod 라는 디렉토리에 모듈이 생깁니다.

아차;; 빌드 하기전에 build.gradle에서

compile “org.vert-x:vertx-core:$vertxVersion”
compile “org.vert-x:vertx-platform:$vertxVersion”

이걸

provided “org.vert-x:vertx-core:$vertxVersion”
provided “org.vert-x:vertx-platform:$vertxVersion”

이렇게 바꿔주세요. 코딩할 때 필요해서 compile 스코프로 넣어뒀는데 빌드하고 난 뒤에 실행할 때는 이 두개가 vert.x에서 제공해주는 라이브러리를 쓰도록 provided 스코프로 해주는게 맞습니다.

자 어쨌든 build/mod/로 가시면 모듈 디렉토리가 생긴걸 볼 수 있습니다.

/work/mod-sample/build/mod > ls
me.whiteship.mod-sample-v0.1

이렇게요.

모듈 실행하기

모듈 기본 디렉토리를 mods라는 디렉토리입니다. 즉 아까 생성된 모듈을 mods 라는 디렉토리 밑으로 옮겨야 하죠. 그런데 mods라는 디렉토리가 없죠? 프로젝트홈 디렉토리에 하나 마들어 주세요.

mkdir mods

그리고 그 밑으로 아까 생성된 모듈 디렉토리를 통쨰로 복사하거나 옮겨오세요.

/work/mod-sample/mods > ls
me.whiteship.mod-sample-v0.1

이렇게요.

이제 프로젝트홈에서 다음과 같이 모듈을 실행하시면 됩니다.

/work/mod-sample > vertx runmod me.whiteship.mod-sample-v0.1
server is running on http://localhost:9090/

브라우저에서 해보시거나 콘솔창을 하나 더 열고

~ > curl http://localhost:9090/
Hello Vert.x

끝.

[SpringOne 2011] 둘쨋날 후기

듣고 싶은 세션이 가장 많이 겹치는 둘쨋날이다. 뭐하나 놓치고 싶지 않은 세션이 많았다. 그래도 어쩌겠는가.. 내가 나루토도 아니고, 결국은 하번에 하나를 듣는데 만족해야지.

이 날 가장 눈에 확 들어온 건.. 나이 많은 개발자 분들이다. 이 글을 정리하고 있는 지금도 내 옆에는 백발의 개발자가 앉아서 바나나를 먹고 있다. 다행히도 한글을 모를테니 내가 뭐라고 적고 있는지 모르겠지만.. 백발의 개발자 또는 얼핏봐도 40은 되보이는 개발자가 전체의 80%정도다. 즉 대부분이 한국에서는 관리자를 맡을 나이에 아직도 자바 기술의 첨단을 달리는 백발의 노장들이 대부분이라는 것이다. 나는 이 사람들에 비하면 겉으로보나 속으로보나 학생에 불과하다. 나는 과연 저 나이가 될때까지 코딩을 하며 살 수 있을까? 내가 40~50대에도 개발자 컨퍼런스에 참여할 수 있을까… 고민을 하고 부러워 한 하루였다.

이 날은 주로 ‘웹’과 관련된 주제에 많이 참석했다. AMD를 비롯해서 여러 종류의 자바스크립트 라이브러리와 프레임워크의 특징과 역할에 대한 소개를 들었고, HTML5의 중요한 특징을 알게됐다. 많은 숙제를 떠앉은 셈이다. 스프링 MVC의 확장 기능은 Rossen이라는 개발자가 구현했는데, 스프링 MVC 확장성이 더 좋아졌다. 서블릿 3.0을 지원하고 HDIV라는 자바 웹 시큐리티 프레임워크를 지원하는 등, 사부님 책에 추가되어야 할 내용이 무엇인지 알 수 있었다. 변경하거나 추가할 내용이 많아서 아마도 조금 고생하실 것 같다.

아.. 스프링 3.1 최종 버전 배포는 12월로 예상하고 있다. 11월 중에는 RC2가 나올 것이고 12월에 최종 버전을 예상한단다. 이건 유겐의 생각이 아니라 키뜨 도널드의 말이라.. 왠지 조금은 더 신뢰가 가지만.. 그래도 개발은 유겐, 크리스, 로센이 하는거니깐 모를 일이다.ㅋ

이 날의 성과는 떠오르는 샛별 로센과의 사진이었다.

(사진은 나중에 업로드 예정)

로센하고는 Spring-Test-MVC 코드에 대해서 이야기를 나눴다. 컨트롤러 유닉 테스트가 목적이라는데, 여기서 말하는 “유닛”이 정확히 무슨 뜻인지 물어봤다. 컨트롤러 클래스 하나를 말하는 것인지.. URL요청 -> 컨트롤러 -> 서비스 -> DAO까지를 말하는 것인지? 그리고 스프링의 TestContext 와는 어떻게 통합할 계획인지 물어봤는데, 역으로 통합해서 어떤 것을 얻을 수 있을지 물어보길래, ApplicationContext 캐싱이 필요하다고 말했고, 로센도 거기에 동의하고 동료와 함께 구체적인 통합 방안을 모색한다고 했다. ContextLoader를 이용해서 확장할 수도 있고.. 어쩌구 저쩌구 여러 방법이 있는데 뭐가 좋을지 논의 해보겠다고 했다. 조금 더 개인적인 질문도 하고 싶었지만 시간이 벌써 밤 11시라서 그런건 이메일로 물어보기로 하고 다음을 기약했다.

오늘은 셋쨋날인데, 아직도 시차적응이 되지 않아서 힘들다….

[SpringOne 2011] 첫날 후기

출발, 도착, 이동, 시차적응

나는 한국 시간 25일 오전 11시에 인천에서 비행기를 탔다. 그런데 시카고에 25일 오전 9시 40분에 도착했다. 그러니까… 시간을 거슬러 온거다. 계속해서 이 방향으로 비행기만 타고가면 나는 나이를 먹지 않는건가.. 하는 생각이 들었다.

공항에서 전철타고 호텔까지 이동하는건 그리 어렵지 않았다. 제일 어려웠던건… 전철표를 넣는방법? 아직도 잘 기억나진 않는데.. 그림에 화살표 그려져있는 방향이 아니라 그걸 뒤집어서 넣어야 했었다. 그 그림은 남은 잔액을 확인하는 방향이었나보다.

문제는 그게 아니라;;

이미 한국 시간 기준으로는 자정을 넘은 시각에 새로운 아침을 맞이하느라 정신이 없었다. 결국 시카고 시간으로 3시에 뻗었고, 4시 반에 일어나서 접수하고 맥주와 먹거리를 조금 먹었더니;; 살아나기 시작했다.

맥주가 시차적응에 약이라니;;;

스폰서

맥주를 마시면서 몽롱해진 정신을 가다듬으며.. 누구에게 말을 붙혀볼까.. 어슬렁 어슬렁 돌아다니기 시작했는데, 마땅치 않았다. 다들 옹기종기 모여서 신나게 이야기하고 있는데, 불쑥 끼어들어서 어버버버거리는게 좀 실례같아서… 차라리 스폰서 부쓰에 가서 잠을 깨기로 맘먹고, 모든 부쓰를 돌면서 이것저것 질문하고 들으면서 잠을깼다.

CloudFoundry와 Heroku 부스에가서 “Socket.io 지원하느냐?”, “앞으론 할 계획인지?” 등등을 물어봤고, Neo4j 부스에서는 “이건 무슨 종류의 NoSQL이에요?” 라고 물어보고, Zing JVM만든 부스에서는 GC 알고리즘 관련 질문을 했다.

한국인

오예.. 그렇게 계속 돌아다니다가 드디어 한국인을 만났다. L사에서 오신 세분을 만났고, 표준프레임워크에서 오신 분을 만났다. 그리고 S사에서도 두분이 오셨다. 와오.. 나까지 포함해서 7명이다. 적진 않다.

키노트

그리고 오늘 가장 중요했던 키노트… 한마디로 이야기하자면 분위기가 좋치 않았다. 이전까지의 키노트라면 아드리안과 롭이 항상 웃음바다를 만들어줬겠지만… 오늘은 로드존슨이 다쳐서 그런지 약간 엄한 분위기에서 진행됐지만, 역시나.. “알찬 내용 + 신선한 데모”는 키노트에서 기대했던 내용 이상이었다.

오늘의 자랑거리

아드리안 콜리어와 살짝 대화(오늘은 왜 롭 해럽이랑 안했는지..)를 하고 사진을 찍었다.


하지만, 플래시를 꺼둬서, 선명하지 않다는건 안자랑거리…

키노트에 대해서는 다시 블로깅하겠다.

 

나는 이미 책을 쓰고 있었다.


old-book 폴더에 들어있는 폴더는 2010년 11월에 쓰다만 책이고, myBook 폴더 바로 밑에 들어있는 책이 요즘 다시 쓰고 있는 책이다. 책은 예전에 박재성님이 쓰신 스프링 책과 비슷한 컨셉이다.

초보자를 위한 스프링 기반의 자바 웹 개발

이게 핵심이다. 어떤 한 주제를 깊게 파는 책이 아니라, 이클립스, 메이븐, 스프링, iBatis, Hibernate, JSP, HTML, CSS, JavaScript를 활용해서 웹 애플리케이션을 구현하는 전체적인 흐름과 구조를 보여주기 위한 책이다. 따라서 초보자도 누구나 따라서 자바로 웹 개발을 해볼 수 있는 책을 써볼 계획이다.

혹시라도 내가 파일만 만들고 뻥을 치고 있다고 생각할까봐. 1장 파일을 찍어봤다. 6월 27일로 나온다. 이미 저 날짜보다 하루, 이틀 전에 쓰고 몇번 더 수정한 파일이지만 드랍박스라서 최종 일자만 나온다. 그 쯔음에 어떤 출판사에게서 내게 책을 쓰자고, 계약을 하자는 제안을 받았지만, 나는 적어도 초벌은 쓰고나서 계약할 심산이었기 때문에, 안쓰고 있다고 거짓말을 했다.

쓰고 있다고 말하면 어떻게해서든 계약을 해버릴 것 같았기 때문에 두려웠다. 거짓말을 한 것은 죄송하지만, 내가 잘못했다는 생각이 들진 않는다.(거짓말이 다 나쁜건 아니니까.) 내가 준비가 됐을때 계약을 해야지 출판사의 압박을 받아가면서 책을 쓰고 싶지도 않았고, 출판사의 기획의도에 나의 책을 끼워맞출수 있는 능력은 내게 없기 때문에, 계약이 무의미 하다고 생각했다.

그런데, 오늘 그 출판사에서 내가 잘 아는 어떤 분과 비슷한 컨셉의 책을 계약했다는 이야기를 들었다. 그 분이 내가 저 책을 쓰고 있는지 알고 있는지 어떤지는 말하지 않겠지만…

그게 중요한게 아니라.

나중에, 내 책이 비겁한 책으로 비춰질까봐 걱정됐다. 열심히 쓴 책인데, 마치 내가 저술 계획을 가로챈 모양이 될까봐 어떻게 해야되나..참 고민이 많았다. 오늘 계약 소식을 듣기 전부터 이미 그런 조짐을 알고 있었는데, 오늘에서야 그게 확정이 된 것이다.

이럴 때 가장 쉬운건, 때려치는 거다. 지금 쓰고 있던걸 버리는거다.

그럼 그 분은 열심히 자기 책 써서 또 대박이 나실테고, 나는 내가 쓰던거 그냥 버리고 영어 공부나 열심히 하면 된다. 그런데, 남자가 칼을 뽑았으면 무라도 썰라고 했는데, 중간에 포기한건 이미 한번으로 족하지 않을까 싶어서, 자존심이 좀 상했다.

요즘 이런 고민을 하느라, “무소의 뿔처럼 혼자서 가라.”라는 글을 외우고 또 외우고 있다

결론은, 그 분이 어떤 책을 쓰시던 나는 내가 가던대로 내 방식대로 계속해서 쓰고 원래 계획대로 초벌이 끝나면 출판사를 알아볼 생각이다.

쓰고 있다는 증거로, 1장 버전 0.1을 공개해 두겠다.
나는 비겁하지 않다.
그리고 난 내 책을 계속해서 쓰겠다.
올해 안에 내는 걸 목표로!

[자바 7] Fork/Join 프로그래밍

http://www.javacodegeeks.com/2011/02/java-forkjoin-parallel-programming.html

http://www.ibm.com/developerworks/java/library/j-jtp11137/index.html

http://www.ibm.com/developerworks/java/library/j-jtp03048/index.html

http://www.coopsoft.com/ar/ForkJoinArticle.html

자바의 Thread 프로그래밍을 조금 더 간편하게 도와줄 API가 추가된다. 조금 일정 영역에 특화된 API로 보인다. request-response 형태의 웹 요청 처리용으로는 어떨지 모르겠지만… 어떤 작업이 여러 독립적인 하위 작업으로 나뉘어 처리가 가능한 작업일때 Fork/Join을 적용할 수 있겠다. 가장 흔히 등장하는 예로, merge sorting과 배열에서 가장 큰 값을 찾아내는 작업이 있는데, 조금 더 실무에 가까운 예제가 언뜻 머리에 떠오르지 않는다. 이런건 어떨까… 1년간 거래된 상품 중에서 가장 많이 팔린 상품을 찾는 작업이라던지.. 가장 많은 댓글이 달린 볼르그 글을 찾는 작업은 어떨까..

거래 내역이 엄청나게 많을 테니까 월별로 쪼개서 가장 많이 팔린 상품 데이터를 찾아내고 각 월별로 찾아낸 상품 정보를 다시 합쳐서 그 안에서 다시 또 가장 많이 팔린 상품을 찾아내면 되겠다. 댓글 많이 달린 글 찾기도 마찬가지다.

갑자기 Map/Reduce가 떠오른다. Fork/Join 이라는 단어를 봤을 때 부터 떠올랐던 단어들이다. 하둡 책 1장에 Map/Reduce 설명이 잘 나와있는데, Fork/Join은 Map/Reduce와 거의 같아 보이지만, 그것 보다 더 많은 제어권을 개발자에게 주는 것처럼 보인다. 그렇게 차이를 보이는 핵심 개념이 Fork/Join에 예제에 자주 등장하는 Threshold라는 것인데, 이것을 기준으로 Fork 할지 말지를 결정하게 된다. Threshold 값 이하의 리소스는 단순 처리하며, 그 이상의 경우에만 병렬 처리를 하도록 설정한다. 물론 뭐 이것도 코딩하기 나름이겠지만 보통 저런식으로 하게 마련일텐데, 저 형태 자체를 템플릿-콜백 스타일로 만들어 볼 수 있지 않을까 싶다.

코딩하는 방법은 제일 위에 있는 링크에 잘 나와있어서 굳이 내가 다시 정리해야 할 필요는 못 느끼겠다. 그냥 한번 돌려본 스크린 캡춰로 대신한다.

맨 위에 있는 글이 가장 정리가 잘 되어 있고, 주요한 링크들이 많다. 그 아래 두개의 링크는 너무 오래된 글들이라서 API가 지금과는 다르지만, 주요 개념 파악하기는 좋다. 그보다 조금 더 근본적인 개념이 알고 싶다면 맨 마지막 링크를 보는게 좋다.