Passwordless Login with SSH

우선 OpenSSL 과 OpenSSH 가 설치되어 있어야 합니다. 윈도우즈에서는 cygwin 버전을 사용하세요. 로컬 머신에서 다음을 실행합니다:

ssh-keygen -t rsa -b <비트수 (2048)>

Private key 에 대한 passphrase 를 묻게 되는데 입력하지 않습니다.

생성이 완료 되면 ~/.ssh/id_rsa (private key) 와 id_rsa.pub (public key) 파일이 생성된 것을 알 수 있습니다.

마지막으로 권한을 설정합니다 (윈도우즈에서도 반드시 하셔야 합니다):

chmod 600 ~/.ssh/id_rsa*

이제 원격지 시스템에 로그인하여 ~/.ssh 디렉토리에 들어가서 (없다면 만드세요) authorized_keys 파일을 엽니다. (역시 없다면 만드세요) 파일의 마지막 부분에 id_rsa.pub 파일의 내용을 추가하고 저장한 뒤, 권한을 설정합니다:

chmod 644 authorized_keys

이제 비밀번호 없이 SSH 를 통해 로그인하실 수 있습니다. 다음 명령으로 키를 생성한 로컬 머신에서 테스트해 볼 수 있습니다:

ssh <사용자명>@<호스트명> ‘echo Hello, World!’

아무 에러 없이 종료되면 성공입니다.

만약 작업하는 머신이 여러개라면 각각의 머신에서 동일한 작업을 수행해 주셔야 합니다. 또, 원격지 머신에 OpenSSH 가 아닌 다른 SSH 가 설치되어 있다면 (e.g. Solaris), 여기에서 더 자세한 정보를 얻으십시오.

PS: 여전에 작성했던 ‘Maven 에서 Password 없이 Deploy 하기’에서 Passwordless login 부분만 뽑아 다시 작성한 글입니다.

블로그 이전중입니다.

수작업으로 이전중이므로 시간이 조금 걸릴 것 같습니다. 양해 부탁드리겠습니다.

아래 보이는 글들은 아주 오래전에 쓴 것들입니다. 하나씩 손으로 이전하다 보니 훑어보게 되는데, 그땐 내가 이랬구나 돌이켜 보게 되네요. 비록 유치하고 서투른 글들이지만 글이 모두 이전될 때까지 재미삼아 봐 주세요.

나이를 먹는다는 것

나이를 들면 나쁜 점과 좋은 점이 있다. 나쁜 점부터 말하면 머리가 나빠진다. 기억력, 순발력, 새로운 지식의 습득 능력이 떨어지는 것이다. 좋은 점이라면 경험이 많아진다는 것이다. 많은 것들을 놀라지 않고 받아들일 수 있기 때문에 좀 더 행복에 가까워질 수 있을 것 같다.

하지만 나이가 들어 고지식하다는 소리를 듣는 것은 참 불쾌한 일일 것이다. 보통 고지식한 사고나 행동은 자신이 쌓은 경험의 틀 안에서 모든 것을 해석하려고 할 때 생긴다. 시간이 흐르면서 최신의 경향과 나의 경험 사이의 간극이 벌어지기 때문이다. 따라서 우리는 나이를 먹어 갈 수록 새로운 것을 경험의 틀에 가두기보다는 그 틀이 새로운 것을 포용해 새로운 모습으로 단장할 수 있도록 노력해야 한다. (물론 그게 가능하다면)

스리랑카로 떠나다

곧 스리랑카에서 있을 ApacheCon Asia 2006 발표를 위해 내일 스리랑카로 떠난다. 규모는 유럽이나 미국에 비해 작지만 ApacheCon 최초의 아시아 컨퍼런스에 발표자로 참석한다는 사실이 기쁘다. 최초라는 건 정말 멋지다. 모든 좋은 일의 최초가 되고 싶다.

그런데, 우리 나라 뉴스에서는 언급이 되고 있지 않은 듯 하지만 현재 스리랑카 정부와 타밀 반군과의 휴전이 깨질 기미를 보이고 있어 정국이 매우 불안한 상태라 한다. 혹시 테러나 당하지 않을까 걱정스럽다. 하지만 가야 한다면 가는 수 밖에는 없다. 단 이틀만 머무니까 큰 위험은 아닐 것 같다.

1 Comment

  1. 영회 said,

    August 14, 2006 at 12:35 pm

    축하드립니다.

소프트웨어의 복잡도가 증가하는 이유

복잡도를 다루기 위해 복잡도를 추가하는 오류는 세상 곳곳에서 행해지고 있는 문제입니다. 이는 대부분 탄성을 자아내는 무지와 게으름, 아집에서 옵니다.

제가 일하던 팀에서는 이런 일이 있었습니다.

당시 C3P0 커넥션 풀을 사용하고 있었는데, 풀 스레드 덤프를 떴을 때 디비 부하로 인해 커넥션을 획득하는 부분에서 대기상태로 있는 스레드들이 아주 많았습니다. 그도 아니면 만에 하나 스레드 풀이 데드락에 걸렸었을 수도 있죠.

팀장은 저에게 커넥션 풀 100줄이면 짤 것을 갖다 써가지고 이런 일이 생긴다고 저를 나무랐고 저는 말도 안되는 이야기 하지 말라고 맞받아 쳤습니다.

커넥션 풀, 100줄이면 짤 수 있습니다. 하지만 javax.sql.DataSource 인터페이스 준수하고 앞으로 있을 몇 가지 기능 추가하다 보면 결국엔 남들이 힘들게 걸어온 길을 별 의미도 없이 다시 걷는 셈이 됩니다. 물론 100줄 짜리 풀을 이야기하는 사람이 그런 표준 인터페이스가 안중에 있겠습니까. 결국 자가당착에 이르러 vendor lock-in 도 아닌 쪽팔린 self lock-in 에 빠질 수 있습니다. 100줄짜리 커넥션 풀에는 버그가 없답니까? 시간이 흐르면서 결국에는 남들이 겪었던 버그를 다시 겪을 수 밖에 없습니다.

사실 이런 일이 세상 여기 저기서 끊임없이 일어나고 있습니다. Logging API부터 시작해서 각종 라이브러리, 그리고 프레임워크까지. 사람들은 사용하는 외부 구성 요소의 내부를 잘 모르기 때문에 그 안에서 문제가 발생했을 때의 어려움을 두려워합니다.

그 두려움을 이해하지 못하는 것은 아닙니다. 또 그 프레임워크를 선택하지 않는 것이 현명할 수도 있습니다. 하지만 그 판단히 단순한 두려움이나 무지에 의한 것이라면 가던 길을 멈추고 ‘생각’을 할 필요가 있습니다.

가끔은 생각보다 많은 사람들이 ‘생각’을 하지 않고 경험을 통한 직관을 가장한 아집으로 문제를 해결하는 모습을 봅니다. 씁쓸하지 않을 수 없습니다. 이런 아집이 관철될 수록 조직은 경직되고 소프트웨어의 복잡도는 끊임없이 증가합니다. 이런 조직에서 잘 나오는 말이, ‘이 소프트웨어는 낡아서 처음부터 다시 짜는게 낫다’ 죠. 한마디로 웃기는 이야깁니다.

물론 우리가 처한 업무 환경이 그런 깊은 생각을 할 만한 시간적 여유를 주지 않고 있는 것도 사실입니다. 그 부분에 대해서는 각자가 현명하게 판단하고 선택해야 겠죠.

4 Comments

  1. 짱가 said,

    August 11, 2006 at 5:40 pm

    현명한 분석입니다. ^^
    가슴 깊이 공감이 가네요.

  2. 영회 said,

    August 11, 2006 at 6:10 pm

    오랜만에 올라온 글이네요.
    낮에 있던 일로 더욱 공감할만한 글입니다.
    후배 녀석이 프로그램을 잘 짜놓고도…
    처음부터 다시 짜려고 하더군요.
    그 이유는 코드가 허접하다는.. ^^

    스스로도 자주 기존 코드를 버리고 새로 짜왔으니 충분히 이해 하죠.
    하지만, 스스로에 대한 믿음도 없이 하루 하루 살아가는 모습에서 비롯된게 아닌가 하여… 반성하게 되었죠.
    진정한 리팩토링이란 자신과 자신의 일에 대한 믿음에서 한발씩 나아가는 것이 아닌가 생각됩니다.
    그것이 타인에 대한 믿음으로 확장되었을 때, 희승씨가 지적하신 것처럼 중복 코드를 만들어내지 않고, 진정한 협업을 할 수 있겠죠.

  3. charlz said,

    August 11, 2006 at 9:12 pm

    소 프트웨어로 한 목표지점에 가는 방법은 여러가지일 겁니다. 그래서 다양한 라이브러리나 프레임웍등이 계속 나오는 것이겠죠. 새로 짜는 것이 일반적으로 나쁘다는 것과 새로 짜면 100줄이면 된다는 것은 다른 목표지점으로 가는 용도와 상황을 따져서 타협점을 찾아야 하는 것이지 한쪽을 고수하는 것은 답이 나오지 않는 이데올로기의 싸움같은 것이라고 생각합니다. 새로 짜더라도 엔지니어링 프랙티스로 어느정도 타임투퀄리티를 줄일 수 있고, 표준이 용도에 맞지 않은 (목표로 가는 방향과는 좀 다른 방향)일 수도 있을 것입니다. “Been there done that”도 위험하고, context를 따지지않는 말씀하신 lock-in도 위험한 것이겠죠.

    갖다 쓴 것이 문제라는 말은 당연히 맞지 않는 말이겠지만, 새로 짜면 이미 다른 사람들이 겪은 것을 다시 겪어 좋지 않다는 것도 단순하게 참인 명제는 아니라고 생각합니다.

    그 일로 화가 나셨나봅니다. 글이 무섭군요.^^

  4. ricky said,

    August 22, 2006 at 5:38 pm

    하지만, 100줄 짜리 코드로도 완벽한 컨넥션 풀이 나오면 어쩌죠?

하늘나라로 간 재롱이

지난 몇 주 동안 재롱이는 물 외에는 아무 것도 먹지 않고 누워 있었다. 물을 먹을 기력조차 잃어버린 재롱이는 오늘 하늘나라로 떠났다. 회사에서 돌아왔을 때는 이미 재롱이의 마지막 얼굴을 볼 기회를 놓치고 만 뒤였다. 아침에 지각 걱정에 서두르느라 재롱이를 제대로 예뻐해 주지 못한 것이 정말 후회가 된다.

재롱이는 개 치고는 긴 16년이라는 시간을 살았다. 하지만 그 시간이라는 것이 어떤 의미가 있을까. 백일몽의 한 가운데서 떠오르는 공상 과학 영화의 한 장면처럼, 사랑하는 누군가를 다시금 살려내고 싶은 마음은 16년이라는 시간을 상대적으로보다는 절대적으로 인식하게 한다. 아마 백 년도 천 년도 모자랄 것이다. 그렇기에 우리는 신의 존재에 의문을 던지면서도 언젠가 다시 만나기를, 다음 세상을 상상하고 기약한다.

인생의 절반 이상을 함께한 누군가를 영영 다시 볼 수 없다는 느낌, 그것이 바로 죽음이 우리를 눈물짓게 하는 이유일 것이다. 숨막힐 정도로 아프고 텅 빈 가슴의 한 켠을 채우려면 얼마나 오랜 시간이 흘러야 할까.

12 Comments

  1. 전기양 said,

    July 8, 2006 at 11:17 am

    재롱이 좋은데로 갔을거에요 ㅠ.ㅠ

  2. 영희 said,

    July 10, 2006 at 1:03 pm

    희승씨 재롱이때문에 맘이 많이 아프구나..나도 재롱이가 죽었다는 얘기를 듣고 가슴이 시리던데..오죽했을까.. 어제 위로도 많이 못해주고 ..미안해..

  3. lono said,

    July 10, 2006 at 3:28 pm

    키우던 햄돌이가 떠날 때도 많이 씁쓸하던데,
    강아지는 훨씬 더 슬플 듯, 안타까운 ;_;

  4. 아휘 said,

    July 11, 2006 at 12:27 am

    나도 작년에.. 10여년을 같이 지내온 예삐라는 강아지와 이별했는데..
    그런데 예삐가 나쁜 기운을 몰고 나갔나봐..
    그 후 바로 취직이 되더라구,,
    16년 동안 잘 키워줬다면, 재롱이도 기쁘게 갔을 듯 하다 ^^

  5. Ryon said,

    July 14, 2006 at 11:51 am

    그 강아지가 운명을 했구나….

    전에 봤을때도 실명했었던거 같은데…..

  6. ricky said,

    July 21, 2006 at 4:23 am

    T_T 희승이 아저씨 힘내!!!

  7. Trustin Lee said,

    August 2, 2006 at 10:03 am

    네…ㅜㅜ

  8. Trustin Lee said,

    August 2, 2006 at 10:03 am

    울자기 요즘 전화도 뜸하고~ 잘지내는감? ㅋㅋ

  9. Trustin Lee said,

    August 2, 2006 at 10:04 am

    그 햄돌이가 죽어버린거야? 명복을 빌겠소 ㅠㅠ

  10. Trustin Lee said,

    August 2, 2006 at 10:04 am

    그래버렸다.

  11. Trustin Lee said,

    August 2, 2006 at 10:04 am

    홧팅!!!

  12. Trustin Lee said,

    August 2, 2006 at 10:06 am

    저는 별로 좋은 일은 없지만 형은 취직 축하드려욧!

코드 중복이 인류에게 미치는 해악

나이를 먹어 가는 만큼 완결된 형태의 글을 쓰는데 걸리는 시간이 길어진다. 시간이 흐르면서 남들의 시선도 의식하게 되고 삶이라는 것에는 단정짓기에는 너무나 많은 뒷 이야기들이 존재함을 알아버렸다.

누군가를 비난하기보다 이해하려고 애쓰는 자세야말로 많은 사람들과 일을 진행하는 데 있어 중요한 자질이 아닌가 싶다. 모두가 인격적으로 충분히 성숙할 수는 없다. 하지만 그 자질 하나만 있다면 우리는 서로의 멘터(mentor)가 될 수 있지 않을까?

그럼에도 나에게는 한 치도 물러날 수 없는 원칙이 있다. 우리는 이 세계를 발전시키기 위해 존재한다는 것이다. 우리가 우리의 행동이 세상 사람들에게 혜택을 주어야 할 만큼 노력하지 않는 것만한 불행도 없다. 나는 그런 모든 시도 앞에서 결코 물러나고 싶지 않다. 그런 사람들이 있었기에 세상은 그나마 이 정도 약진해 왔다.

우리는 소프트웨어를 만들 때 어떻게 만들고 있는지 이 관점에서 진지하게 생각해 볼 필요가 있다.

코드 중복이야말로 스스로의 시간을 세상과 단절시키는 최고의 방법이다. 스스로 질 떨어지는 커넥션 풀이나 ORM 프레임워크를 만들 시간에 왜 Jakarta Commons DBCP나 Hibernate에 공헌하지 않는가? 다른 부지런한 사람이 같은 일을 해서 보기 좋게 공개할 것이란 안이한 생각 덕택에 컴퓨터 공학의 역사는 얼마나 늦어졌는지 이젠 헤아릴 수조차 없다. 개인은 명성을 얻을 기회를 잃어버린다. 컨퍼런스에서 스포트라이트를 받았어야 할 시간에 술집에서 치킨 뜯으면서 무의미한 자기 과시에 시간을 허비해 인류의 존재 이유에 의문을 갖는 개체의 수를 증가시킨다.

혹자는 말한다. 인류에게 도움이 되는 소프트웨어를 어떻게든 빨리 제공하기만 하면 인류에 큰 도움이 될 수 있다고. 아쉽게도 기대와는 많이 다르다. 소프트웨어를 만들고 유지보수하는 과정에서 낭비되는 시간이 갖는 가능성의 유실은 인류가 받을 도움을 마이너스로 상쇄하고도 남는다. 또 소프트웨어 개발 과정에서 은연중에 수립된 불합리한 마인드가 커뮤니티에 뿌리박혀 오늘날 어떤 현실을 낳게 되었는지는 자명하다.

세상을 발전시키는 소프트웨어는 중요한 인류의 자산이다. 그러나 그 과정에서 인간이 세상을 향해 취해야 할 기본적인 자세를 파괴한다면 그것은 무가치를 넘어 해악이다.

8 Comments

  1. 영회 said,

    June 13, 2006 at 10:30 am

    좋은 글이 군요..

  2. 해빈 said,

    June 13, 2006 at 3:47 pm

    In a broad perspective, yes, I strongly agree with you. But you may be putting too much burden on all of us and our software. What if you only a need simple class to do whatever you wanted, do you still have to use that huge and enormous open source library? I acknowledge the fact that the simple class is bound to be more complicated and complex. Yet, for just now, if it suits its purpose well enough then I would have to say “job well done.” Reasons? First, avoids Yo-Yo effect for typical Object-Oriented programs. Second, much easier maintenance. Last but not least, no hassle with licenses.
    Yet, in a broad perspective, I do agree with you, but for narrow scope, you may go easy on us, pity hardworking laborers.

  3. Trustin Lee said,

    June 13, 2006 at 6:16 pm

    That’s a common pitfall. Why is a reusable component huge if we use only small part of it? If it is too complex for your simple scenario, then you’d better find a better replacement for it. There should be someone who tried to resolve that complexity. Otherwise, you’re the one to resolve it and share it with other people all over the world. It would be even better if we can improve the existing component become very thin and light when you use only small part of it by refactoring it.

    Can you assure the _one_ class will remain as a real one class in the future? That’s the waste we’re creating everyday. I bet it will not be compatible with any known standard interfaces so the cost of switching will overwhelm the initial merit of the home-grown solution significantly. Much easier maintanance? That’s the funniest joke I have ever heard this year.

    Regarding licenses, it’s absolutely OK if you’re using open source softwares with BSD-compatible licenses. It’s not a hassle but required knowledge for developers who is considering to adopt F/OSS.

    It’s a temporal burden which will go away as you get used with the discpline. You will get an eternal burden on your back while avoiding the temporal burden. I found that people who are against this idea are just not used to it. It’s just an excuse for a lazy being. You have to think again.

    And let me know if any softwares I wrote made you suffer. You never asked me about the problems you encountered recently, so I cannot understand why you’re saying ‘us’.

  4. 해빈 said,

    June 14, 2006 at 1:12 am

    well, i don’t exactly remember where i quoted ‘easier maintenance’, yet, there is a paper regarding that issue. what it said was that it is always much easier to debug a class than a library. ^^;; (because, there would be lesser yo-yo effect and lesser hassle to deal with when you run your debugger.)

    us means typical developer like myself without any architectural mind. he he…

    i do love your open source libraries. but when things go wrong, such as, oil, it is rather difficult to pinpoint the problem. (i would certainly face similar problem even though I use a simple class)

    but, as i mentioned previously, i strongly agree with you in a broad perspective. but, sometimes, you cannot really eliminate all the inefficiencies.

    🙂 i still respect you very much~ i am not trying to criticize your opinion. certainly, my one is also a mere opinion. ;-)

  5. Trustin Lee said,

    June 20, 2006 at 10:04 am

    Is a library a library if we use only a few part of it? I think it is a very controversial issue and usually a simple class evolves into a library as time goes by. That’s also why there’s a company like SpikeSource.

    My point is that the idea ‘Job well done’ can be very dangerous to our society. :)

  6. Trustin Lee said,

    June 20, 2006 at 10:04 am

    격려의 말씀 감사드립니다 ^^;;

  7. Max said,

    June 27, 2006 at 1:30 pm

    우리나라에 이런글을 쓸수 있는 사람이 있군여…

    – 감동구절 –
    ———————————-
    ‘누군가를 비난하기보다 이해하려고 애쓰는 자세야말로 많은 사람들과 일을 진행하는 데 있어 중요한 자질이 아닌가 싶다. 모두가 인격적으로 충분히 성숙할 수는 없다. 하지만 그 자질 하나만 있다면 우리는 서로의 멘터(mentor)가 될 수 있지 않을까?’

    제랄드 M. 와인버그 가 연상될 만큼 좋은 글이 였습니다.
    좋은글 읽으니 기분 좋쿤요… ^^

  8. Trustin Lee said,

    August 2, 2006 at 10:10 am

    과찬의 말씀이십니다. ^^;;;

리더의 안티패턴

  • 무지
    • 잘못된 아키텍처에 대한 집착에 가까운 나르시즘
    • 전체를 바라보는 멍청하리만치 낮은 시각
    • 개체지향 디자인에 대해 전혀 모르거나 경험이 없음
    • 무지에 대한 무지
  • 이중성
    • 겉으로는 익스트림, 속으로는 제멋대로
    • 내 실수는 시행 착오를 통한 학습, 남의 실수는 시간 낭비
  • 독단
    • 팀원의 능력과 의욕의 개무시
    • 우리의 회의는 당신의 통보
    • 상대방을 지쳐서 말없이 따라오게 만드는 신통한 재주
    • 상대방의 경험을 무시한 직접 써 보지 않은 모든 것에 대한 불신
  • 성격 장애
    • 조급증에 의한 럭비공화
    • 가끔씩 들어오는 인신 공격

Improvements in JDBC 4.0

This is the summary of an article from JavaWorld.com.

Annotations and the generic DataSet

  • DataSet
  • extends java.util.List.
  • has a java.sql.ResultSet (when connected) or a javax.sql.rowset.CachedRowSet (when disconnected) in it.
  • Query
    • is instantiated by Connection.createQueryObject() or DataSource.createQueryObject()

    interface EmployeeQueries extends BaseQuery {
      @Select (sql=”SELECT employeeId, firstName, lastName FROM employee”)
      DataSet getAllEmployees ();

      @Update (sql=”delete from employee”)
      int deleteAllEmployees ();
    }

    Connection con = …
    EmployeeQueries empQueries = con.createQueryObject (EmployeeQueries.class);
    DataSet empData = empQueries.getAllEmployees ();
    for (Employee e: empData) {
      System.out.println(e.getFirstName());
    }

    Exception Handling Hierarchies

    • SQLException is now classified into multiplle sub-classes for better identification of the cause.
    • Support for chained exceptions and iterability

    catch(SQLException ex) {
      for(Throwable t : ex) {
        System.out.println(“exception:” + t);
      }
    }

    Leverage nonstandard vendor implemented resources

    java.sql.Wrapper supports non-standard vendor-dependent types safely

    PreparedStatement ps = …;
    if (ps.isWrappedFor(OraclePreparedStatement.class)) {
      OraclePreparedStatement ops = ps.unwrap(OraclePreparedStatement.class);
    }

    This is very similar to a simple downcasting pattern which uses instanceof keyword, but it is different and flexible in that isWrappedFor(…) and unwrap(…) can perform downcasting recursively and programmatically by its definition. To put simply, this is a safe downcasting pattern for the decorator pattern. This pattern will be also very useful for other use cases, not just for connection pool implementations.

    Miscellaneous

    • New types
    • SQLXML: created by calling Connection.createSQLXML()
    • RowId: represents vendor-independent value to reference a row in a database directly.
    • has a different life time: DatabaseMetadata.getRowIdLifetime()
  • Connection.isValid() and Connection.setClientInfo()
  • Use of Java SPI: No need to call Class.forName(…) anymore

  • JavaWorld에서 읽은 기사의 요약입니다.

    어노테이션과 DataSet

    • DataSet
    • java.util.List를 상속
    • 내부적으로 java.sql.ResultSet (접속되어 있을 때)나 javax.sql.rowset.CachedRowSet (접속이 끊어져 있을 때)를 갖고 있음
  • Query
    • Connection.createQueryObject()나 DataSource.createQueryObject()를 호출해 생성

    interface EmployeeQueries extends BaseQuery {
      @Select (sql=”SELECT employeeId, firstName, lastName FROM employee”)
      DataSet getAllEmployees ();

      @Update (sql=”delete from employee”)
      int deleteAllEmployees ();
    }

    Connection con = …
    EmployeeQueries empQueries = con.createQueryObject (EmployeeQueries.class);
    DataSet empData = empQueries.getAllEmployees ();
    for (Employee e: empData) {
      System.out.println(e.getFirstName());
    }

    예외 처리의 계층화

    • SQLException이 여러 하위 클래스로 구분되어 예외의 원인을 좀 더 자세히 알 수 있음.
    • Chained exception을 지원하고 간결한 for 루프를 쓸 수 있음.

    catch(SQLException ex) {
      for(Throwable t : ex) {
        System.out.println(“exception:” + t);
      }
    }

    벤더 종속적 자원의 활용

    java.sql.Wrapper는 벤더 종속적 타입을 안전하게 사용할 수 있는 방법을 제공

    PreparedStatement ps = …;
    if (ps.isWrappedFor(OraclePreparedStatement.class)) {
      OraclePreparedStatement ops = ps.unwrap(OraclePreparedStatement.class);
    }

    이것은 instanceof 키워드를 사용하는 기존의 단순한 다운캐스팅 패턴과 아주 비슷하지만, isWrappedFor(…)와 unwrap(…)가 다운캐스팅을 재귀적 및 프로그램적으로 수행할 수 있다는 점에서 다릅니다. 간단히 말해 데코레이터 패턴에서 쓸 수 있는 안전한 다운캐스팅 패턴인 셈입니다. 이 패턴은 커넥션 풀 구현 뿐만 아니라 다른 비슷한 곳에서도 유용하게 적용할 수 있을 것 같네요.

    기타

    • 새 타입
    • SQLXML: Connection.createSQLXML()을 호출해서 생성
    • RowId: 데이터베이스의 한 행을 직접적으로 참조할 수 있는 값을 나타내는 벤더 종속적 값
    • 라이프타임이 다를 수 있음: DatabaseMetadata.getRowIdLifetime()
  • Connection.isValid()와 Connection.setClientInfo()
  • Java SPI의 사용: Class.forName(…)을 더 이상 직접 호출할 필요가 없음
  • Beauty of Inaction

    멍하니 정류장의 줄 가운데 서서 오지 않는 버스를 기다리는 내내 원망했던 적이 있다. 나는 마음속으로 외쳤다. 나에게 주어진 시간을 왜 길바닥에서 낭비해야만 하느냐고.

    많은 시간이 지났고, 나의 태도도 바뀌었다. 이제는 격렬하게 살아가는 현대의 삶에서 무위(無爲)만큼 아름다운 것도 없다고 생각한다. 지키지 못할 스스로와의 약속에 고뇌하는 것보다는 길거리를 지나가는 사람들의 표정 하나 하나를 통해 나를 바라보는 것이 어쩌면 더 중요한 것은 아닐까?

    I had been complaining of a bus not coming on time in the middle of a line. I shouted at the world from inside of my heart; “why am I supposed to waste my given time on this damn street?”

    Time passed since then and my attitute also changed. Now, I think nothing is more beautiful than ‘inaction’ in a fierce modern life. Wouldn’t it be more important for us to looking into ourselves through the faces of the people on a street, rather than thinking of countless promises destined to be broken?

    10 Comments

    1. lono said,

      March 23, 2006 at 8:49 am

      now, drive for yourself~

    2. mylee said,

      March 24, 2006 at 1:59 pm

      예 전에는 약속으로 인해 기다리는 시간, 멀리 이동해야만 하는 시간 들이 낭비스럽다고 생각했었어요. 그런 시간들에 대해서 또 무지 민감했구요. 짜증도 많이냈죠.. 하지만 언젠가부터 그런 시간 조차도 내가 컨트롤 할 수 있다고 생각했어요.. 어디에 있던지에 상관없이 내가 할 수 있는 무언가를 계속 할 수 있다면.. 그렇게 연장선으로 생각하면 그만인 거였죠. 차안에서 필요한 테잎을 듣는다던가 책을 본다던가.. 내 몸은 그저 이동하고 있는 거였지만 난 항상 내가 할 수 있는 무언가를 찾아 함께 했고.. 그러다 보니 이젠 그런 것들에 자유로와 졌어요.. 성격도 좋아진거 같구 ^^

    3. Trustin Lee said,

      March 25, 2006 at 10:57 pm

      I think I’m too short-sighted and too old to get a driver’s license now. LoL!

    4. Trustin Lee said,

      March 25, 2006 at 10:58 pm

      동감이에요. 그래서 저는 하루에 두세시간씩 되는 출퇴근 시간이 그렇게 싫지가 않아요. 음악도 듣고 생각도 하면서 있으면 어느새 목적지에 도착한 나를 발견하게 되곤 하죠. 공감하는 사람이 있어 기쁘네요. ^^

    5. pcpenpal said,

      March 26, 2006 at 1:30 am

      저도 출퇴근을 매일 통합 3시간씩 하지만 별로 나쁘다고 생각하지 않아요. 다만 지각하는 출근길에서는 생각의 1/4는 지각 고민이라는 것이… -_-;

    6. Trustin Lee said,

      March 28, 2006 at 5:43 pm

      고민을 머릿속에서 지워버리3~

    7. 레이시 said,

      March 29, 2006 at 11:55 pm

      오랜만이어요 ^^
      나도 동감하는 부분인데
      언제나 나는 ‘심심하지 않다’를 만드는건
      항상 어딘가에서 재발견하는 능력이 있어서 일꺼에요.

    8. Trustin Lee said,

      March 30, 2006 at 8:42 am

      오랜만이야 윤진 ^^
      매일 하루를 원하는 만큼 다시 태어난 사람으로 살 수 있다면 좋을텐데 말이야… 홧팅~!

    9. 파탈 said,

      April 17, 2006 at 1:54 am

      봄햇살이 너무 따뜻해요. 보도블럭 틈바구니에서 피는 잡초들을 구경하며 통학을 하는 요즈음이에요.

    10. Trustin Lee said,

      April 17, 2006 at 2:50 am

      갑자기 쌀쌀해진 저녁에 잠시 봄이라는 것을 잊어버릴 뻔 했네요. 겨울이란 계절을 잊을 정도의 녹음에 흐뭇했었는데 말예요. 내일은 따뜻했으면 좋겠네요. ^^