Whiteship's Note

워드프레스로 옮겼습니다.

기선 — Sat, 04 Sep 2010 00:28:43 +0900

오시던 주소로 오시면 됩니다.

http://whiteship.me

가산동 LG CNS에서 '스프링 3.0 이해와 선택' 강의 수강하신 분들 안녕하세요/

기선 — Wed, 01 Sep 2010 10:19:37 +0900

https://spreadsheets.google.com/viewform?formkey=dElvckJLdzU0WnhKTDRnMl9fWFZJTVE6MQ

이 링크에서 강의 평가 부탁드려요.

이미 한분은 해주셨답니다.

대충 앞자리에 계시던 분들 중 한 분이 아닐까 생각됩니다.ㅋㅋ 감사합니다.

1등 평가자에겐 원래 책을 선물로 드리려고 했는데 이미 사셨다니까... 패스...

아파치 Click이 No Framework??

기선 — Tue, 31 Aug 2010 10:35:36 +0900

http://www.likejazz.com/archives/2247

여기서 likejazz님은 아파치 Click을 노 프레임워크라고 소개하고 계신데요.

1. 기사 원문에도 그런 단어가 없을 뿐더러.

2. 기사 번역문도 애매하게 번역한 부분이 없잖아 있지만 직접적으로 노 페임워크라고 업급하지 않았습니다.

3. 충격적으로 아파치 Click 홈페이지에 가보시면 자신이 웹 애플리케이션 프레임워크라고 정의했습니다.

그런데 No Framework 라니요.. 전 소개글 읽다가 "이게 뭐지?" 라고 깜짝 놀라서 하던 일 멈추고 읽게 됐습니다. 그런데.. 지금은.. 그야말로 낚였다는 생각밖에 안 들더군요.

No Framework 가 경량(lightweight) Framework랑 같은 말인건가요? 그건 아닌것 같습니다.

Apache Click은 프레임워크 대신 HTML 템플릿과 POJO(Plain Old Java Object)만으로 프레임워크의 역할을 대신하는 No-Framework의 일종이다.

likejazz님의 설명입니다.

그런데.. 기사에 올라온 코드만 보셨더라도 Click 프레임워크가 제공하는 클래스(Page)를 상속해서 WelcomPage라는 걸 만드고 있습니다. Page같은 프레임워크 코드를 쓰는데..이게 어떻게 No Framework라고 할 수 있을까요.

Click이 경량 프레임워크라는 데는 동의할 수 있습니다. 스프링처럼 방대한 기능을 제공하지 않는 대신 스프링의 방대항 확장성을 포기하고 Click이 제공하는 간편한 방법. 딱 그 방법으로만 개발을 할 수 있게 해주니까 가벼운 프레임워크라고 볼 수 있습니다. 하지만 그렇다고 해서 그게 프레이워크 없이 POJO로만 개발이 가능하다고 하는 No Framework 랑은 좀 다른게 아닌가 싶습니다. 실제 코드도 안 그렇구요. @_@;

'스프링 3.0 이해와 선택' 강의 후기

기선 — Sat, 28 Aug 2010 23:50:30 +0900

'토비의 스프링 3'을 간추린 내용으로 강의를 세 번 했다. 두번은 한빛ENI에서 4회에 걸쳐서 진행했고 한번은 절반의 내용만 가지고 이동국님 소개로 NHN의 어느 한 팀을 대상으로 진행했다. 6월 말부터 강의를 시작해서 오늘 8월 말까지 거의 쉬지 않고 달려왔다. 하지만 아직도 끝나지 않았다. 앞으로 진행하기로 구두로 계획한 강의가 두개. 최종 합의가 끝난 강의가 하나. 현재 하고 있는 강의가 하나 있다.

강의를 처음 해보는 거라 얼떨떨 하던차에 갑자기 여기 저기서 강의 요청이 들어오는 바람에 더 얼떨떨하고 몸도 약간 피곤하다. 하지만 매우 즐겁고 새로운 아이디어가 많이 떠올라서 좋다.

첫 강의를 준비할 때는 많이 긴장했다. 처음 해보는 강의인데 준비된 자료는 아무것도 없었다. 하지만 난 든든했다. 나에겐 '토비의 스프링 3'이 있었다. 그 책에 있는 내용이 워낙에 좋았다. 강의 할때마다 말하지만 내가 말하고 전달한 내용은 전부 이 책에 들어있다. 난 그거 그것을 최대한 쉽게 이해하고 학습하기 편한 형태로 요약하고 편집해서 준비한 것을 효율적으로 전달하려고 노력하는 것 뿐이다. 그게 나의 '스프링 3.0 이해와 선택'이라는 강의다.

그래서 준비한 것이 우선 소스 코드다. 난 PPT 부터 만들지 않았다. 책 내용 중에 꼭 전달하고 싶은 내용과 꼭 이해해야 할 내용을 소스 코드로 만들었다. 그것도 단계적인 학습 단계에 맞게 또 그걸 편하게 다룰 수 있도록 각 패키지에 번호를 붙여놨고 패키지 순서가 흐트러지지 않게 test00, test01 이런식으로 두가지 숫자를 패키지 명 뒤에 붙여줬다. 그 다음에 준비한 것이 PPT다. 소스 코드만 가지고 이해하기 어려운 내용을 PPT로 보강했다. 이 소스에서 저 소스로 넘어갈 때 무엇 때문에 그렇게 넘어가는 것인지 그 결과는 어떤지에 초점을 맞춰 PPT를 작성했다. 마지막으로 소스코드가 변화하는 과정을 보여주려고 코딩 동영상을 녹화했다. 라이브코딩은 생각보다 시간이 많이들고 리스크가 높다. 라이브코딩의 묘미는 발표자의 실수라지만 이제 그런 시절은 갔다. 라이브코딩의 목적이 재미라면 모르겠지만 그게 아니라면 수강생을 불안에 떨게 하면 안된다고 판단했다.

나름대로 열심히 준비한 발표이다보니 자연스래 별로 긴장하진 않는다. 그래도 새로운 장소에서 강의하게 될 때는 항상 약간은 설레이고 약간은 긴장된다. 그래서 항상 첫강의때 1시간정도 일찍 강의장에 도착해서 노트북을 빔에 연결하고 인터넷을 잡고 이클립스를 띄우고 PPT를 띄워서 마음을 가라앉힌다. 그러고 나면 금새 마음이 편해져서 긴장이라는 말은 금방 잊게 된다. 그 뒤에는 수강생의 반응에 신경을 곤두세운다.

강의가 시작되면 나는 수강생들의 반응을 살피기 시작한다. 얼굴은 반응을 살피기 가장 좋은 표적이다. 나는 설명을 하고 수강생들은 화면을 본다. 나는 수강생들의 얼굴을 본다. 그 얼굴 중에는 '네. 이해가 됩니다.', '그래 알겠어.', '이미 아는거자나', '아. 졸려..', '앗 모르곘는데', '멍...', '앗 머라고?', '어려운걸! 이거 뭐지', '멀라 뭐야 이거 먹는거?' 라는 표정이 들어있다. 그걸 보면서 질문을 던지고 좀 더 내 추측이 확실해지면 그에 따라 부연설명을 하거나 속도를 조절한다.

하지만 아직 뭔가 많이 부족하다. 지난주 금요일 수원형 TDD 강의 때 많은 걸 배울 수 있었는데 TDD 보다는 강의 방식. 즉 교수법을 배울 수 있었다. 강의 내용은 분명 TDD 였지만 현재 나에게는 TDD 보다 수원형의 강의 진행 방식과 사소한 유머과 PPT에 더 관심이 갔다. 3시간이 어떻게 갔는지 모를정도로 순식간에 지나갔다. 그리고 하나도 지치지 않았다. 매우 재미있었다. 학습은 그렇게 재밌어야 한다. 배우는 맛이 있어야 한다. 그런데 과연 내 강의를 수강하는 학생들도 그만큼 재미있고 유익하게 학습하고 있는지 어떤지.. 그것 조차도 잘 모르고 있다. 그저 추축만 할 뿐..

그래서 보완할 방법을 마련했다.

하나는 수원형 TDD 강의때 본 즉석 피드백 수집 방법을 사용하는 것이다. 보통 강의가 끝나면 교육을 받은 업체에서 피드백을 받는다. 그러나 그 내용이 나에게 잘 전달되진 않는다. NHN에서 했던 강의 피드백은 동국님께서 전달해 주셔서 잘 볼 수 있었고 굉장히 유용했다. 하지만 한빛ENI에서 했던 교육의 피드백은 내가 받지 못해서 따로 요청해둔 상태이다. 이제는 방법을 바꿔서 나도 수원형처럼 즉석에서 피드백을 받으려고 한다. 그것도 편한 방법으로 말이다. 구글 양식을 이용하는 방법인데 자세한건 나중에 설명하기로 하고, 일단 오늘 받은 피드백은 이렇다.

이상하게 이름을 안적었는데도 읽어보면 어느게 누구 것인지 쉽게 알 수 있을 만큼 익명성이 철저히 보장된다. ㅋㅋㅋ 대부분 실습 위주의 강의에 매우 긍정적이고 시간이 부족하다는 것을 아쉬워했다. 사실 실습 시간이 부족한 것은 내가 너무 많은 내용을 전달하려고 하는 욕심 때문이기도 하고.. 실습한 내용이 한번에 익혀지는 만만한 내용도 아니라서 그럴 것이다. 이 부분은 앞으로 조금 강의 내용을 개선해서 고쳐나가야 할 부분이다.

ps: 오랜만에 썼더니 굉장히 장문으로 써진다. (사실 이보다 더 많은 내용을 썼다가 지웠다.) 앞으로는 좀 더 자주 토해내야겠다.

[인텔리J] 메이븐 프로파일 선택하기

기선 — Thu, 19 Aug 2010 11:48:34 +0900

뭐 이런 간단한 것을 올리나 하겠지만.. 윤석군이 이클립스에서 프로파일 옵션 줘서 빌드해도 잘 안 바뀐다길래 인텔리J의 우수함을 뽐내 주기 위해 스크린 샷 한장을 올립니다.

윤석군 보아라..

WEB-INF 밑에 classes에 배포된 calendar.properties에 들어있는 내용인데 분명히 production이래자나.. 난 잘 된다고..

하지만 안타깝게도 넌 선택권이 없어.. 이클립스를 잘 써... 현업 나가면 어차피 다 이클립스 쓸텐데 인텔리J에 맛들이면 큰일나.. 다른거 못써. ㅋㅋ

이클립스로 어떻게든 빌드 잘 하고 메이븐 플젝 잘 써먹게 되면 그때 넘어오셩.. 그래야 인텔리J 쓰고 놀다가도 후딱 이클립스에서 프로젝트 하지. 안 그럼 난감해ㅋ

[메이븐 프로파일] 운영시 배포할 설정 파일과 개발시 배포할 설정 파일 샤샥

기선 — Thu, 19 Aug 2010 11:02:05 +0900

운영시에 사용할 설정과 배포할 때 사용할 설정이 다르다. 어떻게 해야할까요? 예전에도 이 고민을 한적이 있었는데 마침 윤석군이랑 봄싹에 구글 캐린더 연동 서비스를 구현했는데 이런 상황이 또 발생했습니다.

개발 할때 사용할 구글 캘린더와 실제 운영시 사용할 구글 캘린더는 달라야 합니다. 혹은 개발 할 때는 캘린더 서비스를 무시할 수도 있어야 하는데 이 경우는 일단 제외하고 우선은 설정을 환경에 따라 구분해야 한다는 것에 초점을 맞췄습니다.

설정 정보가 구체적으로 어떻냐에 따라 방법도 달라질 수 있는데 이전에 봄싹에 적용한 방법은 다음과 같습.. 흠... 아닙니다.. 귀찮군요. 그냥 생략하고 메이븐 프로파일이나 정리하겠습니다. 어쨋든 이전에 사용한 방법은 메이븐을 사용하지 않은 방법이었는데.. 그게 다 장,단점이 있습니다.

이번에 사용할 방법은 메이븐 프로파일을 사용합니다.

일단 폴더를 저런식으로 구분했는데 뭐 저런 구조야 맘대로 정하시면 되겠죠. 중요한건 개발시 사용할 설정파일이 담겨있는 폴더와 운영시 사용할 설정파일이 담겨있는 폴더를 구분했다는 것 정도..

이제 pom.xml에서 <build> 부분에 개발시 사용할 설정이 담겨있는 폴더를 소스 리소스 폴더로 인식하도록 설정해 줍니다.

<build>

...

...

<directory>${project.basedir}/resources/development</directory>

</excludes>

</resource>

</resources>

...

</build>

이렇게 말이죠. 대충 엘리먼트 이름만 봐도 아실테니 설명은 패스.

다음은 운영 환경에서는 저 폴더가 아니라 다른 폴더를 리소스 폴더로 등록해줘야 합니다. 따라서 pom.xml에 프로파일을 추가해 주고 그 안에서 재정의할 설정을 넣어주면 됩니다.

<id>production</id>

<build>

...

<directory>${project.basedir}/resources/production</directory>

</excludes>

</resource>

</resources>

</build>

</profile>

</profiles>

자 요렇게 해주면 더 프로파일을 가지고 빌드 할때는 운영시 사용할 설정 파일이 담겨있는 폴더를 소스 리소스 폴더로 인식해서 그 안에 있는 .java 파일을 제외한 모든 파일을 배포해줍니다.

마지막으로.. 그럼 저 프로파일을 가지고 빌드 하는 방법은?

mvn clean install -Pproduction -X

요런식으로 mvn을 실행할 때 -P프로파일명 을 주시면 됩니다. 저기서 사용한 -X는 디버깅용 출력에 사용하는 옵션이구요. 나머진 아시겠죠.

좋은점

- 빌드 담당자가 아닌 개발자들은 이전과 동일하게 계속 개발하면 된다.

- 저 설정들을 버전관리에 포함시킬 수 있다.

- 운영 서버에서 빌드 스크립트 설정만 한번 바꿔주면 된다. 그 이후로는 간편하다.

불편한점

- 빌드 담당자(SI에 이런 롤이 있는지 몰겠지만)가 메이븐을 쬐끔 알아야 한다.

사실 위에 적은 좋은점 불편한점은 위에서 생략하고 넘어간 이전 방식과 비교를 했을 때 더 분명한데.. 일단은 그 방법을 적기가 다소 귀찮고 본 글의 주제에도 맞지 않으니 그냥 생략합니다. 대충 세가지 방법을 고민해 뒀는데 나중에 정 한가하고 정 심심해지면 정리해봐야겠습니다.

토비의 스프링 3 북 오픈 기념샷

기선 — Tue, 17 Aug 2010 21:31:27 +0900

음하핫.. 드디어 받았군요. 제가 마지막에 쿨하지 못해서 넣게된 추천사까지 볼 수 있고 알파리딩 때는 보지 못했던 토비님의 감사의 인사도 볼 수 있어서 감회가 새로웠습니다. 길게 쓰고 싶지만 운동갈 시간이라.. 짧게 남겨도 이해해 주세요.

책에는 이클립스 기준으로 소스코드 실행하는 방법이 있지만 전 인텔리J로 돌리렵니다. 메이븐 프로젝트도 아니니까 이클립스로 돌려도 무난하겠지만... 메이븐 프로젝트는 인텔리J가 백배 좋습니다.

구글 Buzz API와 OAuth 관련 링크

기선 — Sat, 14 Aug 2010 22:42:11 +0900

구글 버즈

http://code.google.com/intl/ko-KR/apis/buzz/

http://code.google.com/intl/ko-KR/apis/buzz/docs/libraries.html

http://code.google.com/intl/ko-KR/apis/buzz/v1/using_rest.html#create-activity

OAuth

http://code.google.com/intl/ko-KR/apis/accounts/docs/OAuth_ref.html#GetAuth

http://code.google.com/intl/ko-KR/apis/accounts/docs/OAuth.html

http://googlecodesamples.com/oauth_playground/index.php

OAuth 토큰이 여러개인게 아니라 토큰 종류가 여러 가지인거 였구만... 어려워 어려워 @_@;;

이웃나라 (부동산) 이야기

기선 — Fri, 13 Aug 2010 17:27:29 +0900

이제 한국 차례..

템플릿-콜백 패턴으로 Try-Catch-Finally 블럭을 무찌르자.

기선 — Wed, 11 Aug 2010 18:40:19 +0900

어제부터 계속 정리하고 싶었는데 어젠 이상하게 시간을 쏟아 버리는 바람에.. 이제 정리한다. 자세한 내용은 토비의 스프링 3에 나오는데 이번에 구글 캘린더 API 코딩하다가 써먹을 기회가 와서.. 적용해 봤다. 문제는 내 강의를 들었던 학생은 그걸 하지 못했다는게 아쉽다. 어디 한술에 배부르랴.. 그래도 내가 코딩한 걸 보고 그게 그건지 알아차렸으니.. 그걸로 만족한다.

http://code.google.com/intl/ko-KR/apis/calendar/data/2.0/developers_guide_java.html

http://code.google.com/intl/ko-KR/apis/gdata/javadoc/index.html

구글 캘린더 API를 사용하려면 위에 있는 문서만 보면 된다. 친절하게 안내해주고 있어서 쓰기 편하다. 그런데 문제는 예외처리다.

public List<CalendarEntry> getMyCalendarList(){

URL feedUrl = makeUrl(OWN_CALENDAR_URL);

try {

CalendarFeed resultFeed = calendarService.getFeed(feedUrl, CalendarFeed.class);

return resultFeed.getEntries();

} catch (IOException e) {

throw new RuntimeException(e);

} catch (ServiceException e) {

throw new RuntimeException(e);

}

저기서 호출하고 있는 calendarService는 구글에서 제공해주는 API로 IOException과 ServiceException을 던지는 메서드들을 왕창 가지고 있다. 또 그녀석들을 자주 쓰게 된다.

따라서 어떤 호출을 하더라도 위와같은 예외 처리 코드가 생기기 마련이다. 이걸 어떻게 하면 좋을까? 스프링 개발자라면 이런 코드를 스프링과 잘 어울리는 형태로 처리할 수 있어야 한다.

어떻게 할것인가? 어떻게 하면 저 지져분한 Try-Catch(-Filnally) 문에서 벗어날 것인가? 한번 도전 해보자...

결과는..

public List<CalendarEntry> getMyCalendarList(){

return calendarServiceTemplate(new CalendarServiceCallBack<List<CalendarEntry>> () {

public List<CalendarEntry> queryForObject() throws IOException, ServiceException {

return calendarService.getFeed(makeUrl(OWN_CALENDAR_URL), CalendarFeed.class).getEntries();

}

});

}

이것과 비슷한 형태가 될 것이다. 물론 중요한건 결과가 아니라 저렇게 바꾸는 프로세스.. 그걸 이해하고 자신의 스킬로 만드는 것이 중요하겠다. 토비의 스프링 3에서 아주 잘 배울 수 있으니 꼭.. 3장 템플릿을 정독하도록 하자. 연습하고. 또 연습하고. 또 연습하고. try-catch 문이 반복해서 나올 떄 마다 적용해 보도록 하자.