최근에 오라클에서 갑자기 함수 오버로딩에 관한 이야기를 접했습니다.
한번도 사용해 본 적이 없었지만 왠지 쉽게 될 것 같아 만들어 보려했지만 생각처럼 되지는 않더군요
예를 들어 다음과 같이 사용하고 싶은 거였죠

SELECT UserFunction() FROM DUAL;
SELECT UserFunction('ERITAKA') FROM DUAL;
SELECT UserFunction('ERITAKA', '.NET') FROM DUAL;

그런데 이게 함수만 만들어 바로 사용하는 건 불가능했습니다.
즉, Package 로 감싸지 않는 이상은 오버로딩이 불가능했습니다.
그래서 다음과 같이 Package를 만들고 함수를 추가했습니다.

CREATE OR REPLACE PACKAGE Eritaka AS

  FUNCTION UserFunction RETURN VARCHAR2;
  FUNCTION UserFunction(p_field IN VARCHAR2) RETURN VARCHAR2;
  FUNCTION UserFunction(p_field IN VARCHAR2, p_field2 IN VARCHAR2) RETURN VARCHAR2;
  FUNCTION UserFunction(p_field IN NUMBER) RETURN VARCHAR2;
  
END;

그런 후에 아래와 같이 Package의 Body를 만들어 줍니다.

CREATE OR REPLACE PACKAGE BODY Eritaka AS

  FUNCTION UserFunction RETURN VARCHAR2
  IS 
  BEGIN
    RETURN 'Eritaka';
  END;
  
  FUNCTION UserFunction(p_field IN VARCHAR2) RETURN VARCHAR2
  IS
  BEGIN
    RETURN to_char(p_field);
  END;
  
  FUNCTION UserFunction(p_field IN VARCHAR2, p_field2 IN VARCHAR2) RETURN VARCHAR2
  IS
  BEGIN
    RETURN to_char(p_field || p_field2);
  END;
  
  FUNCTION UserFunction(p_field IN NUMBER) RETURN VARCHAR2
  IS
  BEGIN 
    RETURN UserFunction() || to_char(p_field);
  END;
END;
 
그러면 이제 다음과 같이 사용할 수 있게 됩니다.

SELECT Eritaka.UserFunction() FROM dual;
SELECT Eritaka.UserFunction('eritaka') FROM dual;
SELECT Eritaka.UserFunction('eritaka', '.net') FROM dual;
SELECT Eritaka.UserFunction(3) FROM dual;

결과는 뭐 아래와 같습니다.

Eritaka
eritaka
eritaka.net
Eritaka3

그러면 이제 처음 목적과는 조금 다르게 Package를 꼭 서두에 붙여야 사용가능하다는게 문제입니다.
사실 이 부분을 해결하기 위해서는 Synonym 을 생성하면 되겠다. 라고 간단히 생각했는데... 안되더군요.  oTL
즉, 아래처럼 하면 될거라고 무심코 생각해버렸었다는.. ㅠ.ㅠ

Create Public Synonym UserFunction for Eritaka.UserFunction;

아참 MS-SQL 의 T-SQL 에서는 오버로딩이 안되는 것 같습니다.
요새 느끼는 거지만 오라클을 사용하다 씨퀄을 사용하면 왜 이렇게 불편한 점이 많은지...
Posted by eritaka

최근에 64bit 환경의 Windows7 에서 다음과 같은 프로그램 오류가 난다는 보고를 받았습니다.


보통 80040154 오류는 COM 클래스를 레지스트리에 등록하지 않아 발생하는 경우이나 이 경우는 등록 후에도 해당 증상이 발생했습니다. 

결국 문제는 64비트 환경이기 때문에 일어나는 현상으로 주소 공간이 맞지 않기 때문에 발생합니다.
.net 은 Any CPU로 빌드되어 실행 시에 각 환경에 맞도록 64비트로 컴파일되어 실행되지만 해당 COM 개체는 처음부터 32비트로 컴파일되어 있습니다. 여기서 문제가 발생합니다.
즉 64비트 .net 응용 어플리케이션은 64비트 주소공간을 가지고 있는데 in-process 방식의 COM DLL 은 32비트 주소공간을 가지고 있기 때문에 해당 dll 을 메모리로 로드할 수 없어서 생기는 일이죠.

해결 방법은 크게 2가지로 나눌 수 있습니다.
첫번째로는 32비트 버전이든 64비트 버전이든 둘 다 일치시켜주는 방법입니다.
아주 쉽죠?
즉 아래와 같이 각 대상 플랫폼의 환경이 서로 다른데 이걸 맞춰주셔야 합니다.

관리 코드의 경우


비관리 코드의 경우


그런데 이 경우는 생각보다 까다롭습니다. 일단 제 경우처럼 해당 COM DLL 을 외부에서 제공받은 경우이며 해당 업체에서 64bit 버전을 제공할 수 없는 경우가 있을 수 있고 그 경우 .net 을 모두 32bit 로 고정시켜 빌드해야 하므로 CI 환경을 갖추지 않은 경우 빌드 스크립트를 수정하지 않고 일일이 테스트 해야 하므로 까다롭죠.
게다가 .NET 이 64bit 로 실행가능함에도 다운그레이드 해야하므로 뭔가 기분이 좋지 않죠.
마지막으로 빌드된 버전이 2가지 버전으로 나뉘는 것도 꺼림칙 합니다.

그래서 두번째 방법이 나옵니다.
두번째 방법은 out of proc 방식으로 COM을 별도의 실행 프로세스로 만들어 참조하는 방법입니다. 즉 COM+ 응용 서비스를 사용하여 32bit 프로세스로 Wrapping 하는 방법입니다. 이렇게 되면 닷넷 응용 어플리케이션의 주소 공간으로 해당 dll을 로드할 필요가 없게 되니 당연히 문제도 사라집니다.
즉 관리도구의 구성요소 서비스에서 COM+ 응용 어플리케이션을 선택하고 빈 응용 어플리케이션을 하나 만듭니다.
COM+ 응용 프로그램은 하나 이상의 COM 구성 요소로 구성됩니다. 그러니 해당 DLL을 COM 구성요소로 등록시킵니다.
성공하면 아래와 같은 화면을 보게 됩니다.

등록이 된 후에는?
잘 되는지 커피 한잔 마시며 테스트 하면 됩니다.
Posted by eritaka
TAG 64bit, COM+

2009년 연구실 신년회 기억이 아직도 생생한데 벌써 2010 연구실 신년회입니다.
항상 다른 연구실과 다른 신년회를 가졌던 것 같은데 올해는 더욱 특이한 신년회였습니다.

저녁식사야 매년 같았지만 올해는 2010년 1월 29일 강남 토즈 2호점에서 각자 자유주제로 페차쿠차 형식으로 발표하는 시간이 추가되었습니다.
페차쿠차 형식으로 짧은 시간으로 발표하진 못했으나 다들 새로운 시도로 페차쿠차 형식이 지향하는 바에 대해 공감했으리라 생각합니다.
아래는 제가 발표한 내용입니다.

2010 Dblab신년회 안명환
View more presentations from 동균 이.

무엇보다 변화를 받아들이고 실천하는데 있어서 학생들을 따라갈 수가 없는 나이가 되었나 싶어서 슬픈 신년회이기도 했습니다.
역시 아이폰이 대세더군요
10년을 써온 핸드폰 번호 바꾸는 것이 싫기도 하고 사람들과 즐겁게 얘기하는 것이 더욱 좋다며 애써 외면했으나 아이폰 4G가 나올 때 쯤이면 안드로이드폰이든 아이폰이든 바꾸지 않을까 예상합니다.
내년 신년회에는 저도 지지 않겠습니다. (부러우면 지는거다?)
Posted by eritaka
요새 가장 크게 영감을 얻고 있는 부분은 '실생활을 관찰하기' 입니다.
주변에서 관찰하고 흔한 것들에서 의미를 부여합니다.
흔하게 지나쳤던 것들을 관찰하다 보면 큰 영감을 받을 때가 있기 때문이죠

그렇게 실생활을 관찰하다 최근들어 가장 절감하는 것이 바로 '구조를 먼저 개선하자' 입니다.
우리는 보통 기술적 맹신에 빠지기 쉽습니다.
'누가 이런 걸 했더니 좋다더라. 우리도 도입하자!' 는 식이죠
그러나 그 이전에 '왜 우리가 먼저 도입 못했을까. 도입한 사람들과 우리와의 차이점은 무엇인가?' 에 집중해야 합니다.
그리고 나서 도입하기 쉬운 문화를 먼저 만들어야 합니다.
그러면 일이 쉬워집니다.
그렇지 않고 기술만을 도입하려 한다면 실패할 확률이 매우 높습니다.
기술 이전에 구조 혹은 문화를 바꾸어야 합니다.

이전 아파트에 살 때 꿈꾸던 것이 있었습니다.
'아 나른한 오후에 나가서 책을 읽고 사람들과 대화를 할 수 있는 그런 아파트 문화를 만들고 싶다'...
그렇게 10년을 넘게 살고 이사를 했습니다.
그런데 평생 나가서 하지 않던 저도 그렇고 다른 사람들도 갑자기 집 밖 벤치에 나와서 책을 읽는 사람들이 생기기 시작했습니다.
그럼 왜 이런 변화가 생겼을까요
이전 아파트 단지에는 벤치 주변에 차가 있는 경우가 많았습니다. 또한 차들이 주변에 지나가서 시끄럽죠.
또한, 설치된 벤치의 수도 적었지만 일자형 벤치만이 주를 이루었습니다.
새로 이사한 아파트 단지에는 사람들이 앉고 걸어다니는 공간과 차들이 움직이는 공간을 완전하게 분리했습니다.
그렇게 조용한 공간을 만들고 벤치만이 아니라 테이블도 설치하고 멋진 정원도 조성했습니다.

그렇게 아파트 디자인을 변경했더니 사람들이 갑자기 나와서 책을 읽기 시작한 겁니다.
누가 뭐라고 하지 않아도 자연스럽게 움직입니다.

새로운 문화를 도입하고 싶으세요?
먼저 구조를 변경하세요 문화가 자연스럽게 스며들 수 있도록 환경을 구축하면 문화가 자연스레 변경됩니다.
저작자 표시
Posted by eritaka
TAG DESIGN

최근에 거장들이 방한하고 있습니다.
며칠 전 GoF의 디자인 패턴으로 유명한 Ralph Johnson과 Erich Gamma 가 방한하더니 이번엔 XP로 유명한 Kent Beck이 방한합니다.

방한 중 세미나와 워크샵이 열리는데 'Being Agile(애자일이 되기)'란 주제인 워크샵은 비용이 180만원(VAT제외시) 정도 됩니다. oTL

어쨌든 다행히 세미나는 8만8천원(VAT포함)이며 냉큼 등록했습니다.
세미나의 주제는 'Responsive Design: When, How, and What (반응적 설계 : 언제, 어떻게, 무엇을)' 입니다.
2009년 9월 4일 강남역 과학기술회관에서 열립니다.
재미있는 것은 세미나 일정 중 사인회가 있습니다!
'13:00-13:20 저자, 역자 사인회 (인사이트 제공) 및 휴식'

기대됩니다. 현재 제가 가진 Kent Beck 책으로는 TDD(번역서), XP(번역서), Implementation Patterns(원서) 이 있습니다. 20분 동안 다 받을 수 있을지 모르겠네요!

그러고보니 사인회 말고 기념촬영 시간은 없는데 추가 되면 좋겠군요!
흑흑 뭐 혼자 등록했기 때문에 찍어달라고 할 사람도 없지만...



Kent Beck 의 TDD는 개발자를 인간답게 만들어주는 방법론입니다.
그것은 이론일 뿐이며 Real World 에서는 그렇게 진행할 수 없다는 사람은 다음의 그래프를 보시기 바랍니다.


이것은 최근에 임성현 기술사님을 통해 알게된 자료입니다.
IBM과 MS에서 각 프로젝트 별로 TDD를 하는 팀과 그렇지 않은 팀으로 진행된 연구결과이며 TDD 진행 팀이 그렇지 않은 팀에 비해 15~35%의 개발지연이 발생했지만 39~81%의 오류가 극적으로 감소한 것으로 보고되었습니다. 

이번 그래프는 오류가 발생하는 시점이 코딩 시점에 80% 가 집중되어 있으며 그 때의 처리비용이 극히 낮다는 것을 보여줍니다. QA 조직 혹은 통합 테스트 시에 오류를 발견하고 수정하는데에는 비용이 급격하게 증가합니다. 이미 배포된 후에 발견된 버그를 수정할 경우 또 다른 버그가 생기는 일도 흔하게 발생합니다. 이것을 모두 테스트하는 것은 인간적인 일이 아닙니다. 이것이 가장 중요합니다. 인간주도형 회귀테스트는 인간적이지 않습니다.

그럼에도 불구하고 TDD는 정말 어렵습니다. 유닛 테스트를 도입하는 것도 정말 어렵습니다. Real World 의 프로젝트는 수많은 난관이 존재합니다. 혼자 작업하는 코드에는 고려하지 않았던 수많은 변수가 있습니다.

이 모든 것을 도입하는데에는 고통이 따릅니다. 용기도 필요합니다. Dependency가 극도로 증가되어 있는 프로젝트에 섣불리 도입했을 때엔 그 Side Effect로 인해 프로젝트가 좌초될 수도 있습니다. 그래서 저는 요새 Legacy 프로젝트에 큰 영향을 미치지 않으면서도 조심스럽게 도입하는데 큰 관심을 가지고 있으며 어느 정도 성과도 거두고 있습니다. 약 5년 정도 된 프로젝트이며 이전 Legacy 코드들 까지 합하면 8년, 아니 그 이상된 코드들입니다.

TDD! 힘들어도 지금 당장 아주 간단한 것에서부터 시작하세요. 새로운 프로젝트만이 가능한게 아닙니다. 이미 배포된 프로젝트에서 문제가 발생된 경우도 가능합니다.
버그가 보고되면 테스트 코드를 작성하여 해당 버그를 재현하며 그 테스트를 통과하기 위해 코드를 수정합니다. 여러 테스트 코드를 추가하여 다시 테스트를 통과시키기 위해 코드를 수정합니다. 무엇보다 테스트가 모두 통과하면 안심이 됩니다. 그리고 나중에 해당 코드를 수정하게 되면 다시 이전에 작성해놓은 테스트 코드를 돌려 회귀 테스트를 수행합니다.
그리고 가장 중요한 것! 개발하는 것이 즐겁게 됩니다. 당신은 기계에서 인간이 되는 느낌을 받습니다. 

Real World 에는 수많은 암초가 있는 것 같습니다. 기술적 문제만이 아닌 거지요. ROI도 고려해야 하며 역량 문제도 있습니다. 사람들의 마음, 관계, 정치적 문제까지...
그런 문제를 제외한 채 기술적 문제만을 보아도 상황이 쉬워보이지 않습니다. TDD를 하려고 보면 설계부터 문제가 되는 거지요. 따라서 '프로그램은 왜 실패하는가?(원제: Why Programs Fail?)'에서는 처음부터 디버깅을 염두에 둔 설계가 중요하다고 역설합니다. 모든 것은 부메랑처럼 돌아오게 되어 있습니다. 유닛 테스트 혹은 TDD 도 만능이 아닙니다. 무수히 자라 밀림이 되어버린 정원을 마법처럼 가위손의 정원으로 되돌려줄 은탄환은 존재하지 않습니다.

그럼에도 불구하고 지금이라도 조금씩 정원을 가꾸는 좋은 기술들을 익혀나가는 겁니다.
그러면 언젠가 정원일에 익숙해져서 좋은 기회가 왔을 때 그 기회를 놓치지 않을 수 있을 겁니다.
밀림을 가꾸려는 조그만 발버둥질. 그 움직임이 당신을 인간답게 만들어 갑니다.

저작자 표시
Posted by eritaka

서양과 동양의 차이점을 이야기할 때 흔히 말하는 것 중에 포크와 젓가락이란게 있다.

나이프와 포크를 사용하는 서양 문화는 칼로 고기를 썰고 포크로 음식을 찔러 입으로 넣는 모습에서 공격적인 문화로 비춰진다.
음식을 자르는 나이프와 찌르는 포크에서 흡사 사자나 독수리가 발톱으로 먹이를 찢고 날카로운 이빨로 먹이를 뜯어먹는 모습이 연상되기 때문이다.
이에 반해 우아하게 음식을 집어드는 젓가락 문화는 자연을 이용하기보다 함께 하는 대상으로 비춰졌던 동양 문화에서도 백미라 불릴 만하다.

공격적인 포크문화의 서양과 부드러운 젓가락문화의 동양문화.

나는 젓가락 문화에서 사람을 배려하고 가장 소중히 여기는 마음을 느낀다.

이렇듯 옛부터 우리 문화에는 따뜻한 인본주의 문화가 잘 스며들어 있다.
예를 들어 위험에 처했을 때 한국인이 본능적으로 소리치는 '사람 살려'는 한국인의 의식을 단적으로 보여준다.

 어떤 한국인이 영국 여행중에 인적이 드문 산길을 가다가 도둑을 만났다.
도둑이 칼을 들이대고 물건을 빼앗으려 하자 나그네는 '사람 살려'라고 비명을 질렀다.
이때 영국인 신사가 옆을 지나다가 그 장면을 보고 고민에 빠졌다.
'둘 다 사람인데, 저 한국인 나그네는 도둑이 목에 칼을 대고 있는데도 사람 살리라고 하는 걸 보니 대단히 훌륭한 동양의 성자와 같은 사람이다.
그러나 흉악한 도둑을 살려줄 수는 없으니 어떻게 하나'하고 고민했다는 이야기가 있다.
그 영국인은 '사람 살려'라고 소리친 사람이 '나'를 살려달라고 하지 않았으니, 거기서 '나(소리친 사람)'를 빼면 사람은 도둑뿐이라고 생각했다는 것이다.
재미로 꾸며낸 이야기이겠지만, 서양 사람들에게 있어 나, 즉 개인의 자아의식과 한국인의 사람에 대한 인간주의 의식의 차이를 나타내는 이 이야기에서 우리는 한국인의 마음을 읽을 수 있다.
영국인이나 프랑스인 같으면, '헬프 미(Help me)', '에데 므와 (Aidezd Moi)'라고 소리친다. '나 좀 도와줘'하는 것이다. 그들의 의식 저변에는 '나'라는 존재가 무엇보다 앞선 중요한 존재인 것이다.
- 한국인 답게 사는 길 -


'너'와 '나'를 분리된 개인적 존재로 인식하지 않고 '우리'를 '나'로 생각했던 그 문화.

그러나 그 옛날 '대지'의 작가인 펄벅을 감동시켰던 자랑스런 우리의 젓가락 문화는 요새 어디서도 찾아보기 힘들다.
배려하는 문화, 사람을 중시했던 문화는 가고...

윽박지르는 문화.
안되면 될 때까지 하는 문화.
그 누구도 '아니오'라고 하기 힘든 문화.
상처주는 문화.

끓는 물에 살아있는 채로 문어를 조리하는 그 모습에서 나는 포크를 본다.
내가 가능한 시간 대에 답변할 수 있는 이메일을 버려두고 '어서 대답해', '어서 해결해' 울리는 맹렬한 전화 벨소리를 들을 때 나는 포크에 찔린다.
강제로 납기일을 정해놓고 돼지들을 몰아 부치는 닭들을 볼 때 나는 포크를 본다.
업무는 그에 할당된 시간만큼 늘어지는 경향이 있다는 파킨슨의 법칙을 믿는 사람들을 볼 때 나는 포크를 본다.
인간적인 모욕과 함께 상대방을 배려하지 않고 윽박지르는 상사를 볼 때 나는 포크를 본다.
내가 기계를 조종하는 또 다른 기계로 생각될 때 나는 또 포크를 본다.


시골에서 한 농부가 소 두 마리를 데리고 농사일을 하고 있었다. 마침 황희 정승이 그 곳을 지나가다 농부에게 "저 두 소 가운데 어느 소가 더 일을 잘 합니까?"라고 물었다.
이 때 농부는 뜻밖에도 황희 정승에게 다가와서 "검은 색깔의 소가 일을 더 잘합니다."라고 귓속말로 말하는 것이었다. 이상하게 여긴 황희 정승이 "여보시오. 뭘 그런 걸 다 귓속말로 합니까?"하니 농부가 말하기를 "저들 짐승들도 일을 못한다고 하면 듣고 싫어합니다."했더란다. 미물도 저리 대할진대 하물며 사람인바에야...


글쎄, 나는 막 주차된 자동차의 본네트로 올라가는 고양이처럼 따뜻한 곳을 찾아나서고 싶다.
Posted by eritaka

변화.

Diary 2009/05/05 23:59

이쯤 나이가 들면 이상하게 무언가 새로 시작하는 일들이란 무뎌졌을만도 한데
가끔 너무 무서워서 우주 한가운데 아무도 없는 암흑 속에 던져진 기분이 난다.

자신이 없어서 어딘가 갑자기 도망치고 싶은 마음도 든다.
특히 아무도 없이 나 혼자만 있는 시간이 되면 나는 이상하게 자꾸 움츠려들게 된다.


이 불안의 근원은 어디에서 오는 것일까.


인간은 필연적으로 외로운 존재라지만 이 불안의 근원을 그 탓만으로 돌리기엔 무언가 미심쩍은 기분이 든다.
이건 나만의 문제인가 아닌가. 나는 할 수 있는 것일까. 아니, 꼭 해야하는 것인가.


중요한 것은 멈추지 않는 것이다.
아무것도 하지 않는 것보다는 실패한 인생이 되더라도 자꾸 시도하는게 더 낫다.


그러나 달구어진 돌이든 식은 돌이든 그림자에 드리워진 어둠만은 떨쳐내기 어렵다.
그림자는 자국을 남기지 않는다는데 내 그림자는 상처만을 남길까봐 그게 무섭다.
그게 항상 나를 힘들게 한다.

Posted by eritaka
TAG 변화

2009년이 시작된지 얼마되지 않은 것 같은데 어느새 봄날의 곰만큼 좋은 날씨가 되었습니다.
요즘처럼 따스한 날이면 창 밖을 바라보다 왠지 바깥으로 나가고 싶은 마음에 책 한 권과 커피 한 잔을 들고 바깥으로 나섭니다.
그렇게 조용히 걷다 아낌없이 주는 벚꽃 나무 아래 벤치에 앉아 고양이처럼 조용히 하루를 즐깁니다.
벤치에 앉아 나만의 시간을 즐기다보면 캠퍼스 시절에 가장 좋았던 바로 그 시간으로 돌아간 느낌이지만 안타까운 한 가지는 아는 사람 하나 없다는 것 뿐입니다.

4월도 벌써 여러 날이 지나고 봄과 여름의 중간이라고 할만큼 날씨가 따뜻합니다.
기업이라면 보통 1/4 분기의 실적을 보고 및 평가하여 연간 실적을 가늠하고 목표를 수정 및 보완합니다.
따라서 저도 잊어버리기 전에 2009년도 1/4 분기 자기 수련 평가를 해볼까 합니다.

가장 최근에 읽은 '실용주의 프로그래머'의 격언 중 하나인 '지식 포트폴리오'에서는 8가지 가이드라인을 제시합니다.
해당 가이드라인을 가지고 2009년 1/4 분기 평가를 해보겠습니다.

1. 매년 새로운 언어를 최소 하나는 배워라.
-> 아직 새로운 언어를 배우지 못했으나 배운다면 올해는 루비를 배우는 것이 좋겠군요.

2. 기술 서적을 분기마다 한 권씩 읽어라. (습관이 들면, 한 달에 한 권씩 읽어라.)
3. 비 기술 서적도 읽어라.
-> 2009년도 4월 12일까지 읽은 책은 권수로는 총 10권입니다. 그 중 기술 서적은 6권, 비기술 서적은 4권입니다.
분기별 가장 훌륭한 기술 서적으로는 'Refactoring to Patterns'을 꼽고 싶습니다.
비기술서적은 교양서적으로 '만들어진 신', 소설부문으로 '그림자 자국'을 선정하고 싶군요.
모두 추천합니다.

4. 수업을 들어라.
-> 올해 열린 2009 JCO 컨퍼런스는 가지 못했지만 대신 4월 18일 개최되는 제1회 닷넷 커뮤니티 컨퍼런스에 등록했습니다.  http://www.devdcc.net/

5. 지역 사용자 모임에 참여하라.
-> 5월쯤에 개발자 모임에 등록하여 오프라인 상에서 정기적으로 교류할 계획을 가지고 있습니다. 가장 중요한 계획입니다.

6. 다른 환경에서 실험해보라.
-> 낙제점을 주고 싶군요.

7. 요즘 흐름을 놓치지 마라.
-> 온라인 잡지와 여러 구독지등을 읽는게 이전보다 뜸해졌습니다. 이것도 낙제에 가깝습니다.

8. 인터넷을 이용하라.
-> 요샌 다른 사람들 블로그를 읽는 일도 뜸하군요. 어쨌든 이것도 낮은 점수를 주겠습니다.

총평을 하자면 고양이처럼 즐기는 일에는 어느정도 선방했으나 강아지처럼 소리치지 못했습니다.
은둔형 개발자로 혼자 개발하고 혼자 탐독하고 혼자 평가합니다.
따라서 커뮤니케이션에 좀 더 신경을 써야한다고 하겠습니다.
즉 '나 자신을 드러내라' 정도가 되겠군요. 자신의 약점을 드러내고 평가받는 것이 아직도 두렵게 다가옵니다.
일단 현재 계획대로 된다면 점진적 개선을 이룰 수 있을 거라 가늠됩니다.

오늘의 이야기를 요약하면 제목과 같습니다.

강아지처럼 소리치고 고양이처럼 즐겨라!

Posted by eritaka

주중이면 나는 아침마다 수많은 사람들과 친구가 되기 위해 지하철을 탄다.

서로가 서로에게 극도의 친밀감을 나타내기 위해 애쓰는 이 공간 속에서
나도 함께 열심히 노력해보지만 아무도 나를 좋아해주지 않는다는 사실에 상처 입는다.

그렇게 상처입고 출근한 매일 매일의 일상.
나는 매일 이야기를 쓴다.
가끔은 나 자신이 만족할 만한 이야기를 쓸 때도 있지만
내 친구들도, 얼마후엔 나 조차도 이해할 수 없는 이야기를 쓸 때면 다시 상처 입는다.
오직 기계만이 친구가 되는 이야기를 쓸 때면
'상실의 시대에 공헌하는 사람들'을 위한 가입 신청서로 쓰면 좋겠다는 생각을 한다.

처음엔 상상도 하지 못했던 일을 이젠 매일 저지른다.
처음엔 그토록 고통스러웠던 죄의식도 이젠 흐릿해진다.

그래서 슬프다.
내가 슬프지 않다는 것이 슬프다.
내가 이런 일을 저지를 수 있다는 것을 납득하려 드는 자신이 슬프다.


그래서 나는 나 자신을 치유할 수 있는 레어를 만들었다.
이 레어가 나만의 마지막 방어선이자 치유되는 공간이다.

주말이면 나는 레어에 몸을 기댄다.
전장을 나가는 드래곤의 휴식처가 된다.

2008년 11월 17일 처음 마련했던 레어.


그리고 2009년 3월 29일 최근의 레어.
Posted by eritaka
DTO(DataTransferObject)는 아주 간단하면서도 인기있는 패턴입니다.
개발자라면 누구나 쓰고 있을 겁니다. 

Martin Fowler는 DTO 패턴을 다음과 같이 설명합니다.

An object that carries data between processes in order to reduce the number of method calls.




내용은 아주 간단합니다.
분산 환경에서는 한번의 호출에 많은 비용이 들기 때문에 호출 횟수를 줄이는 것이 중요합니다. 따라서 한번의 호출로 해당하는 데이터를 모두 가져와야 합니다. DTO를 사용하면 호출 시에 파라미터가 많아지는 것을 방지할 수 있으며 하나의 Return Value만을 허용하는 언어에서는 한번에 모든 데이터를 가져올 수 있습니다.

즉, 위의 그림처럼 Album title과 Artist name을 각각 호출해서 데이터를 가져오지 않고 AlbumDTO로 그 내용을 Wrapping 하여 한번의 호출로 데이터를 가져오거나 전송하는 패턴입니다.

.NET 개발자라면 누구나 무심코 DataTable을 이용하여 DTO를 사용합니다. 자바 개발자라면 ResultSet을 사용하여 DTO를 사용합니다. 이것을 저는 Common DTO라고 부르고 있습니다. (적당한 용어를 찾지 못했기 때문에)
어쨌든 보통은 SQL query로부터 생성되며 수많은 컨트롤과의 Data Binding이 쉽다는 장점 때문에 흔하게 사용합니다만 단점도 있습니다.
그 단점 중 하나는 DTO로부터 다시 Object와의 매핑을 하지 않을 경우 getter 혹은 setter 에 접근하기 위해서는 문자열로 이루어진 key를 통해 계속적으로 접근해야 한다는 것입니다. 
이것이 매우 유연하다는 장점이 있는 반면 잘못된 key에도 컴파일 시 에러를 내지 않는 단점이 있습니다. 또한, IntelliSense 기능을 제공하지 않기 때문에 로직 자체에서 ORM 변환 없이 빈번하게 접근해야할 경우 매우 불편할 뿐만 아니라 형변환으로 인한 Boxing과 Unboxing이 빈번하게 일어날 확률이 높습니다.
그 외에도 getter 시 'yyyyMMdd'와 같이 날짜로 표현된 문자열을 DateTime 형식으로 변환하여 돌려주고 싶을 경우 Common DTO를 사용하기엔 많은 제약이 따르며 setter 시 Validation 체크하기도 쉽지 않지요.

따라서, 저는 DTO를 직접 정의하여 DTO Assembler를 통해(이름과 다른 일을 하게 되버린) Common DTO로부터 한번 더 변환하도록 만드는 경우가 많습니다. 위의 그림처럼 AlbumDTO를 만드는 것이죠. 이것을 저는 Proprietary DTO라고 부릅니다.
특히나 저는 Utility 클래스를 통해 데이터를 여러 형태로 변환할 수 있도록 DTO를 만들곤 하는데 이 경우 유용합니다. 또한 IntelliSense 기능을 제공하여 DTO에 접근할 경우 매우 편하게 접근할 수 있으며 Boxing, Unboxing도 일어나지 않습니다.
그러나 현재 ORM Tool을 사용하지 않기 때문에 일일이 DTO를 만들어주는게 꽤 귀찮은 일입니다. 그래서 단순 조회하며 데이터를 변환할 필요가 없는 경우에는 Common DTO를 사용하여 View 컨트롤에 데이터를 바로 바인딩시켜 버립니다. 

이처럼 두 가지 DTO는 각각 장단점이 있기 때문에 항상 고민을 많이 하게 됩니다.
개발 초기에는 Common DTO만을 사용해도 될 것으로 생각했는데 나중에는 그 필요성이 증가하여 모두 변경해야될 경우가 많기 때문에 조심스럽습니다.


그렇게 고민만 하고 결론을 내리지 못하는 나를 볼 때마다 평범한 개발자로 살아가는 것이 참 어렵다는 생각을 합니다.
Posted by eritaka
TAG DTO