Date Archives → January 2007

위장을 튼튼하게 하고 싶다.

지난 주에 감기 몸살로 고생하다가 이내 회복해 참 흐뭇했는데, 몸살이 같이 데려온 장염은 쉽게 낫지를 않는다. 며칠 전 갑자기 악화되면서 순식간에 수척해지고 몸무게가 줄었다. 참다 못해 병원에서 주사를 맞아 부모님 댁에서 회복중이다. 다른 데보다 위장이 아프면 더 고생스럽다. 예전에 복막염을 앓던 날이 떠오르기 때문이다. 약한 나의 위장을 튼튼하게 할 좋은 방법이 없을까?

Spring Framework의 열기를 느끼며

나는 Spring framework의 장점을 UNIX의 장점에 비유하곤 한다. POJO에 대한 메타 모델을 정의하고 이를 바탕으로 POJO의 Factory 및 Registry 역할을 한다는 아주 기본적인 생각으로, 그 역할 정의를 훼손하지 않고 다양한 확장을 통해 수많은 기능을 제공하기 때문이다. 이러한 확고한 디자인 철학은 UNIX와 마찬가지로 감동을 가져다 준다.

그러나 이런 구조적 아름다움은 UNIX의 단점 (또는 단점 아닌 단점) 또한 그대로 보여주고 있다. 즉 그 구조가 훤히 들여다 보인다는 점이다. 거기에다 오픈소스이기까지 하니, 내가 아는 만큼 모든 것을 다 이해하고 시험할 수 있다. 쓰이지 않는 것을 가차 없이 빼 버릴 수도 있고, 언제든 추가할 수 있다. 아는게 별로 없다면? 아무리 간단한 일이라도 원하는 대로 할 수가 없다. 어쩌면 초심자들에게 Spring framework는 옛날 리눅스에서 X 서버 한 번 띄워 보겠다고 시커먼 콘솔 앞에서 몇 시간을 보내던 그 심정과 다를 바 없는 느낌으로 다가오고 있지는 않을까?

가장 대중적인 UNIX 계열 운영체제인 Linux를 사용하는 나지만, 일반인에게 Linux를 권하기가 망설여지는 것이 사실이다. 같은 UNIX 계열이지만 놀라울 정도로 잘 포장된 MaxOS X나 그저 무난한 MS Windows를 추천할 것이다. 나 스스로는 UNIX를 꽤 잘 안다고 생각 (또는 자만) 하고 있으므로 항상 Linux를 선호할 지라도 말이다. 그것은 Linux가 나빠서가 아니다. 단지 Linux가 잘 맞는 경우와 그렇지 않은 경우가 있기 때문이다.

같은 맥락에서, 모든 개발자들이 Spring framework을 자유 자재로 사용할 수는 없을 것이며, 따라서 쉽사리 추천하거나 강요할 수 없을 것이다.

UNIX든 Windows든, 운영체제가 앞으로 갈 길은 아주 많이 남았다. Spring framework도 마찬가지다. Spring framework 덕택에 개발이 많이 편리해졌다고는 하지만, 나는 그 편리함의 정도가 우리가 꿈꾸는 수준의 발 끝에도 미치지 못하는 수준이라고 생각한다. 누구에게나 망설임 없이 추천할 수 있는 쉽고 강력한 프레임워크가 등장한다면 Spring에 대한 열기는 여느 다른 프레임워크가 한 때 누렸던 영광과 마찬가지로 순식간에 사그러들 것이다. 그날이 영원히 오지 않지 않겠느냐 묻는다면, 그만큼 암울한 질문은 이 세상에 없지 않냐고 반문하고 싶다.

역시나 결론은 ‘the best is yet to come!‘

A Few Tips on JavaDoc

JavaDoc에 대한 몇 가지 팁

It’s another Java 5-ish post which might not attract people, yet is very important. I find a lot of wrong or out-of-date JavaDoc due to lack of understandings on useful JavaDoc tags. Bad JavaDoc affects the quality of in-house softwares seriously, so knowing and using the following tips will improve the quality of your projects significantly.

사람들한테 별로 흥미가 없을, 하지만 아주 중요한 또 하나의 Java 5 스러운 이야기입니다. JavaDoc 태그에 대한 이해 부족으로 잘못되거나 철지난 내용을 담고 있는 JavaDoc을 많이 보아 왔습니다. 잘못된 JavaDoc은 사내 소프트웨어의 품질에 심각한 영향을 주므로, 다음의 팁을 이해하고 사용한다면 여러분 프로젝트의 질을 놀랍게 향상시킬 것입니다.

@link and @linkplain tags

@link tag creates a link to an other type. I always prefer to use @link tag rather than not using it because it’s robust to refactoring (i.e. renaming classes also changes JavaDoc). @linkplain is also useful when you prefer a text link with a variable width font.

@link 태그는 다른 타임으로의 링크를 만듭니다. 저는 항상 @link 태그를 쓰지 않는 것 보다는 쓰는 것을 선호하는데요, 리팩터링할 때 JavaDoc에 적어 놓은 클래스 이름이 깨지지 않아서입니다. @linkplain 또한 고정폭 텍스트 링크보다는 가변폭 텍스트 링크를 쓰고 싶을 때 유용합니다.

/**

 * Creates a new {@link Element} with the

 * specified name.

 */

package.html (or package-info.html)

javadoc detects an HTML file named as ‘package-info.html‘ in each package directory, and integrates its content into the generated JavaDoc. Here’s my template.

javadoc은 각 패키지 디렉토리의 ‘package-info.html‘ HTML 파일을 찾아 생성될 JavaDoc 내용에 통합시킵니다. 다음은 제가 쓰는 템플릿입니다.

<!DOCTYPE HTML PUBLIC

          "-//W3C//DTD HTML 3.2 Final//EN">

<html>

<head>

</head>

<body>

The first sentence is copied to the top of the

class list in the generated JavaDoc.  From here,

it's displayed after the generated class list.

...

</body>

</html>

package-info.java (New in Java 5)

Since Java 5, you can put package-info.java instead of package-info.html. What is the advantage BTW? It’s in that you can specify package annotation.

Java 5부터는 package-info.html 대신 package-info.java를 넣을 수 있습니다. 그런데 장점이 뭘까요? 장점은 패키지 애노테이션을 적어 줄 수 있다는 데 있습니다.

/**

 * The first sentence is copied to the top of the

 * class list in the generated JavaDoc.  From

 * here, it's displayed after the generated class

 * list.

 */

@Annotation1

@Annotation2 

...

package org.apache.mina.common;

That’s all. No class definition. It’s a bad idea to define a class here.

이게 답니다. 클래스 정의는 없습니다. 여기에 클래스를 정의하는 것은 좋지 않습니다.

@literal tag (New in Java 5)

No more unreadable &lt;s and &gt;s!

더이상 읽기 어려운 &lt;와 &gt;를 쓸 필요가 없습니다!

/**

 * Returns true when

 * {@literal the specified value < 3}.

 */

@code tag (New in Java 5)

@code tag is actually @literal + (<pre> or <code>).

@code 태그는 사실 @literal + (<pre> 또는 <code>) 입니다.

/**

 * Returns {@code true} when something cool

 * happened.  

 * {@code

 * multilined expression

 * is also fine.

 * }

 */

NOTE: JavaDoc doesn’t support multilined expression yet: Sun Bug Database.

NOTE: 아직 JavaDoc이 여러 줄로 나눠 쓰는 것을 지원하지 않네요: Sun Bug Database.

@value tag (Better in Java 5)

@value tag inlines the value of the specified static constant field.

@value 태그는 주어진 static 상수 필드의 값을 문서에 복사해 넣어 줍니다.

/**

 * Sets the property X.  If an invalid value is

 * specified, it's set to the default value,

 * {@value Constants#DEFAULT_X}).

 */

@deprecated tag and @Deprecated annotation

According to JavaDoc manual, it is a good practice to specify both a @deprecated tag (to specify a reason) and a @Deprecated annotation (for a compiler), though I don’t know why they had to introduce the annotation part.

JavaDoc 매뉴얼에 따르면 @deprecated 태그 (이유를 설명하기 위해)와 @Deprecated 애노테이션 (컴파일러를 위해)을 둘 다 쓰는 것이 좋다고 합니다. 왜 애노테이션을 만들어야 했었는지는 잘 모르겠지만요.

/**

 * @deprecated This method has been deprecated

 *             since 1.0 because it performs a

 *             unsafe operation that breaks data

 *             integrity.

 */

@Deprecated

2007 is now! What's my resolution?

이제 2007년이다! 나의 결의는?

Personal Stuff

지금까지 행복했던 것 보다 더 행복해진다. 영희씨와의 결혼 생활을 시작한다. 잘 먹고 잘 운동하여 건강해진다. 마음의 평정을 되찾는다.

Be happier then ever. Start to live in harness with Young-hee, my girl friend. Eat well, exercise well, and be healthier. Take my composure back again.

Open Source Activity

Apache MINA에 집중한다. 우선 1.x 버전에 대한 문서화를 마무리한 뒤, HTTP, SMTP, FTP 중 한 가지 이상의 프로토콜을 기본 제공하는 2.0 안정 버전을 릴리즈한다.

Focus on Apache MINA. Finish documentation on 1.x versions, and then release 2.0-GA with at least one out-of-the-box protocol implementation among HTTP, SMTP, and FTP.

NHN Corporation

NHN에서 사람들이 일하는 방식을 근본적으로 바꿔 놓는다. 소프트웨어 개발 및 의사 소통 과정을 적절한 도구를 통해 투명화한다. 사내 플랫폼 소프트웨어 개발의 촛점을 기능의 양적 만족에서 플랫폼 사용자의 질적 만족으로 옮겨, 서비스 개발의 품질과 생산성을 혁신한다. 이를 위해 오픈 소스 소프트웨어 프로젝트의 베스트 프랙티스를 도입하고, 팀 내외에 걸친 교육을 실시한다.

Change how people work in NHN essentially. Make software development and communication process transparent using proper tools. Move the focus of in-house platform software development from the quantitive satisfaction of features to the qualititive satisfaction of platform users, and hence, innovate the quality and productivity of portal service development. To support it, embrace the best practices of open source software projects, and provide training programs for both inside and outside the team.