자바에서 날짜를 millisec 단위로 다룰 때, 주의 사항이 있다. Sun에서 인정하지 않는 관련 버그(?) (→ "견해 차" 정도가 좋겠다)가 있다는 것. 0.1 초는 분명 100 millisec인데, 1 millisec으로 취급하는 경우가 있다. 아래의 예를 보고 Bug Report를 참고해 보시길...

 밀리초 단위를 다룰 일이 없어, 전혀 몰랐는데. 같이 일하는 후배를 통해 우연히 발견했다.
이미 2001년도에 Sun에 버그리포팅 된 내용인데, "Not a defect"로 분류가 되어 있다.

 내용은 다음의 테스트 케이스를 통해 확인해 볼 수 있다. 10.4 초 부분을 SimpleDateFormat을 이용해 millisec을 3자리로 바꾸어 표현하고 확인하는 내용이다. 즉, 10.400 초를 기대하고 테스트 한다.

 public static void testSimpleDateFormat() throws Exception {
        
        String timeString = "2009-08-14 10:10:10.4";
        
        /*
         * 주어진 문자열을 SimpleDateFormat으로 Date 형식으로 변환
         */
        Date time = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.S").parse(timeString);
        
        /*
         * 밀리초 단위를 세자리로 설정
         * 10.4 초 = 10.400 초 이여야 한다.
         */
        assertEquals(
                "2009-08-14 10:10:10.400" ,
                new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(time));
 }



결과는 다음과 같다.


이건 아무리 봐도 수정되야 할 것 같은데... 암튼 이 자리를 빌어 유용한 정보를 알려준 후배에게 감사!



+ 2009-08-16 내용 추가
 
 Sun 이 이유 없이 "Not a Defect"로 분리하였을 리는 없다. Sun 이 주장하는 내용에 대한 이야기를 요약하고, 그에 반하는 이유를 좀 더 구체적으로 적어  봤다.

 Sun 이 제시하는 관점은 new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.S")  에서 S는 숫자일 뿐이라는 것이다. 이 말은 더욱 근본적이고 중요한 가정을 하나 포함하고 있는데,  "." 또한 문자열일 뿐이라는 가정이 그 것이다. 다음의 예를 보면 이 말이 더욱 와 닿을 것이다.

  new SimpleDateFormat("yyyy-MM-dd HH 시 mm 분 ss 초 S 밀리초")

 위 경우 S를 통해 4가 전달되었다면 이를 멋대로 400 밀리초라고 해석하거나 해선 곤란할 것이다.

 이 쯤 되면 "뭐야 Sun 말이 맞네!" 라고 돌을 던질 수(저... 연약합니다! )도 있지만. 문제는 밀리초는 애당초 날짜를 나타내는 다른 숫자들과는 성격이 다르다는 사실이다. 연/월/일/분/초 의 경우는 일단 특정 숫자가 정해지면 그 숫자는 죽어도 그 값을 나타낸다. 8월은 죽었다 깨어나도 8월이다.10초는 죽었다 깨어나도 10초이다. 즉 숫자 표기와 그 의미가 1:1로 정확하게 떨어진다. 그러나, 시(h)와 밀리초(ms)는 좀 다르다. "1시"라는 표기는 우리가 늘 사용하지만, 상황에 따라서 오후 1시 일 수도 있고 오전 1시 일 수도 있다. 그렇기 때문에 이를 정확하게 표현하기 위한 방법인 24시 표기법이나 AM/PM 표기 등을 SimpleDateFormat에서 지원하는 것을 익히 알고 있을 것이다. 밀리초도 표기와 의미가 1:1 관계가 아니라는 점에서는 시(h)와 같다. 앞서 본 경우처럼 4라는 밀리초 단위의 숫자는 초와 연동되어 0.4초 의 의미일 수도 있다. 또는 간혹 (사실 밀리초 표기 관례 상 드문 경우일 것 같지만...) 말 그대로 4밀리초일 수도 있다.

 생각해보면, 애당초 밀리초(millisec)라는 단어 자체가 작은 초 단위라는 의미이지 아닌가! 초를 떼어놓기 생각하기 힘든게 당연하다. 본인이 생각하는 문제는 "시"에 대한 표기와는 달리 우리의 표기 관례 대로 밀리초를 다룰 방법에 대한 지원이 이루어지지 않는다는 것이다. 초 단위가 소수점 이하로 다루어질 수 있는 것도 아니고, 밀리초 표기에 다른 방법도 없다. Sun이 Not a Defect로 분류한 이 내용은 본인에게는 마치 다음과 같이 들린다.
1시는 죽어도 한시이다. 그러니까 오후 1시를 표기하기 위해서는 반드시 13시라고 표시해라.
 그 외에도 SimpleDateFormat은 Thread관련 문제를 안고 있으면서도 무겁다. 이에 관해서는  다음에 적어보겠다. (이는 누군가가 다루었을 것 같아 일단 다른 분들의 글 좀 검색하고...)

 잠깐 프로젝트가 딴 데로 샜더니 이런 상황이 되어 버렸다. JIRA를 사용하여 진행 사항 등이 관리되는 것은 아주 좋은데, 상황이 이렇게 되고 보니 너무 적나라하게 보인다는 생각이 든다. (오른쪽 Task List에 보이는 뻘건 항목이 다 지연된 것이다. -_-;)

 Thread 클래스의 start()를 살펴보면 다음과 같다

소스 코드

/**
* Causes this thread to begin execution; the Java Virtual Machine
* calls the run method of this thread.
*

* The result is that two threads are running concurrently: the
* current thread (which returns from the call to the
* start method) and the other thread (which executes its
* run method).
*

* It is never legal to start a thread more than once.
* In particular, a thread may not be restarted once it has completed
* execution.
*
* @exception IllegalThreadStateException if the thread was already
* started.
* @see java.lang.Thread#run()
* @see java.lang.Thread#stop()
*/
public synchronized void start() {
if (started)
throw new IllegalThreadStateException();
started = true;
group.add(this);
start0();
}

private native void start0();

 예전에도 한 번 고민했던 기억이 있는 쓰레드에 관한 의문의 다시 나를 덮친다. 딴 일 많은데.. -_-;

왜 한 Thread는 한 번만 실행할 수 있는 걸까?

 물론 Runnable을 구현해서  Thread를 새로 만들어가며 작업하면 문제없이 프로그래밍을 할 수 있다. 하지만 IllegalThreadStateException을 피하는 방법(어라? 비?...)을 알고 픈게 아니라. 왜 한 번 사용한 Thread를 버려야하는지에 대한 이유가 궁금하다. (잠시 검색해봤지만 원하는 답은 아직 안나오네...)

JIRA를 이용한 이슈관리

Posted 2008.07.01 18:06

 약간 뒷북인데, 프로젝트에서 JIRA 테스트 버전을 깔아서 ISSUE관리를 하고 있다.

 아직 JIRA의 기능을 구석구석 아는 것은 아니지만, Eclipse와 Issue를 연동하는 기본 기능만으로도 매우 강력한 무언가를 느끼게 해준다.

 나와 또 다른 아키텍트가 번갈아가며 Open Source인 Bugzilla를 Linux서버에 설치하는 작업을 tlfvo하고 (버그질라는 소문대로 너무나도 설치가 번거로왔다.) 임시로라도 JIRA 한 번 써보자하여 Test버전을 설치했다. 그런데, 깔끔함과 편리함에 완전 반해서 다음 프로젝트부터라도 PM에게 사달라고 조를까 생각 중이다.

 진행 상황 보고 등의 거창한 기능은 둘째치고, 일단 Issue가 어딘가에 저장된다는 것 자체가 "단기기억상실증"에 시달리고 있는 나와 같은 이들에게는 매우 좋은 기능이다. 이 기회에 고백하건데, 이 글을 쓰고 있는 본인은 업무 진행에 관하여 잘 까먹을 뿐만아니라 산만하기까지 하다. (결과가 짐작되는가?) 이 문제를 해결하다 보면 다른 문제에 대한 실마리가 보이기도 하고, 또 다른 문제를 풀다 보면 원래의 문제에 대한 호기심이 발동되는 등 거대한 산만함을 주체하기가 힘든 것이 사실이다.

 이럴 때 일단 JIRA에 프로젝트를 등록하고, 프로젝트의 구성요소인 component (가장 큰 대분류의 프로젝트의 하위 분류 정도로 생각하면 되겠다)를 만들어 놓으면 안도감마저 든다.

 위의 그림에서 보이듯이 Eclipse의 Task Manager라고 할 수 있는 Mylyn과도 연동된다.(참고로, Eclipse 3.3에서는 Mylyn이 디폴트로 깔려 있다. 3.2에서도 버전에 맞는 Mylyn을 설치하면 된다.) 더군다나, 작업을 하다보면 해당 이슈에 context가 자연스럽게 등록된다. (우호!!) Context란 해당 issue와 관련있는 여러 주변 환경이라고 보면 되는데, 관련 패키지, 클래스 등이 포함된다. 지금 위 그림에 오른쪽에 보이는 클래스는 현재 활성화 되어 있는 issue와 관련된 것들이 filtering 되어서 보이고 있다.

 핵심은 위에 보이는 Package Explorer의 "Focus on Activate Task"버튼. 해당 버튼을 누르면 현재 선택된 issue와 관련된 context를 메서드 단위까지 등록할 수 있다. 어떤가? 이만하면 지병(건망증+산만함)을 극복하고 Project를 열심히 할 수 있다는 희망이 보이지 않는가?

 개인적인 견해이지만, Project에 형상관리시스템(CVS)과 Issue관리시스템(혹은 Bug Tracking System)은 필수 요소 중에서도 필수 요소라고 생각한다. 사실 그 동안 버그질라는 널리 사용됨에도 불구하고 설치와 운용의 측면에서 애로 사항이 상당히 있었으나, JIRA의 경우 WAR파일 배포로 끝나는 초간단 설치에서 여러가지 깔끔하고 편리한 기능에 이르기까지 사용하면 반할만한 요소가 많다. 실제로 상당한 가격(평균 120만원 정도. 참고로 Open Source Project에서는 무료로 사용할 수 있다.)을 지불해야 함에도 이러한 편의성 때문에 굉장히 많은 프로젝트에서 구입해서 쓰고 있다고 한다.
 
 궁금하다면 클릭(http://www.atlassian.com/software/jira)해 보길...

UML - Activity Diagram 소개

Posted 2008.06.30 14:04

 Appication의 설계를 하거나 프로젝트 멤버끼리 의사 소통을 하다 보면 꼭 필요한 UML 다이어그램이 있기는 하지만, 본인의 지론이 '형식을 위한 형식은 안된다'이기에 코딩에 앞서 UML만을 열심히 그리는 것이 바람직하다고 생각하지는 않는다. 그렇다 보니 Version-up 된 UML 2.0에서 더욱 복잡해지고 정교해진 다이어그램들에 대해 질색하는 것이 사실이다. 그렇다, 솔직히 말해 본인의 지론은 본인의 성격, 즉 귀차니즘에 근거한다.

 누군가가 "UML 꼭 익혀야 하나요?" 라고 묻는다면 간단하게 "상황이 허락한다면 아니요" 하겠지만, 예외가 몇 개 있다. 오늘 소개할 액티비티 다이어그램(Activity Diagram)은 그러한 예외 중 하나이다. 실제 코드의 작성과 문서화에 도움이 되는 UML 다이어그램 중 프로젝트에서 상대적으로 잘 안 보이는 것이 Activity Diagram인데, 국내 프로젝트에서는 안보이다가도 외국 문서를 보면 Activity Diagram을 심심치 않게 접할 수 있다. 예를 들어, 아래는 일본 NTT Data의 Framework 문서에 등장하는 Activity Diagram을 필자가 번역한 것이다.

사용자 삽입 이미지

 거의 업무 흐름도를 대체하여 사용하고 있음을 알 수 있다. (참고로 동그란 놈은 프로세스를, 각진 사각형은 전달되는 데이터를 나타낸다.) 이렇게, Acitivity Diagram은 객체 지향 모델링이라는 본연(?)의 업무 이외에도 처리 순서나 Workflow를 나타내기 위해서라면 장소를 가리지 않고 등장할 수 있다. 한마디로 구현에서부터 비지니스를 표현하는 영역에 이르기까지 상태나 순서의 흐름을 나타내기 위해서라면 폭넓게 활용될 수 있다는 것! UML 2.0에서는 statechart로 분류되던 상황에서 벗어나 독립적인 Diagram이 되었다는 사실은 이를 잘 말해준다. 앞으로도 Activity Diagram은 다양한 분야에서 폭넓게 쓰이지 않을까 조심스레 예측해본다. DSL(Domain Specific Language)등에서, 다시금 "UML은 부족합니다" 의 건전한 비판이 나오는 것은 아주 바람직하다고 본다. UML은 사실어떤 이유에서건 B2B의 SI 영역에서 절대불가침의 권위를 세워 온 것은 사실이다. 하지만 UML은 RUP 프로세스 자체는 아니며, 표현 도구로서 매우 유용한 면이 있는 것도 사실이다.

 자주 그려보게 되는 업무 흐름도나 자신이 작성한 component의 흐름도 등을 표현할 때, 보통 ppt장표를 활용하여 자신만의 기호로 표시하는 경우가 많은데 객체 지향 설계를 하고 있다면 이럴 때 Acitivity Diagram을 활용해 준다면 좋을 듯 싶다.
 

티스토리 툴바