달력

4

« 2024/4 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
2009. 7. 31. 23:04

GTD 따라잡기 #5 - 단계 2 : 처리 (Process) 관리2009. 7. 31. 23:04

http://futureshaper.tistory.com/219

GTD의 기본원리
"해야할 일이 무엇인지 기록" -> "각각 어떻게 처리할지 결정" -> "알아보기 쉽게 정리" -> "때가 되면 실행". 
추가로 "틈틈히 들여다 본다."

처리 플로우차트
처리는 inbox 비우기를 의미


처리단계에서 가장 중요한 것인 판단(Decision)이다. 수집단계에서 기록한 '무엇(Stuff)'을 어떻게 처리할 것인지 결정하는 것.
버리거나, 철해두거나, 위임하거나, 나중을 위해 기록해 두는것을 의미.
처리단계의 초점은 '일을 처리'하는 것이 아니라, 어떻게 처리해야하는가를 결정하고 그에 따라 분류하는 작업을 하는 것.

처리의 원칙
1) 위에서부터 아래로 한번에 하나씩
2) 수집함에서 빼낸 것은 절대로 다시 넣지 않기. 

행동할 거리가 없는 경우
- 버린다.
  . 필요없다 판단되는 경우
- 철해둔다.
  . 버리면 나중에 후회할 것 같은 생각이 드는 경우
  . 참조항목 보관 공간에 보관
- Someday
  . 당장은 아니지만 시간이 좀 흐른 이후에 행동을 해야할 경우
  . 예) 두달 후에 관심있는 세미나가 열린다. 그때 상황이 어떨지 모르기에 참석을 결정할 수 없다. 하지만 한달 후에는 계획이 잡힐 것이기에 한달 뒤에 보자고 하고, 이를 보관해 둔다.
  . 이때 사용할 수 있는 것은 두가지: '어느날/어쩌면(Someday/Maybe)' 목록 or Tickler file

행동할 거리가 있는 경우
- 해야할 일이 무엇인지 생각한다.
  . 행동은 '구체적면서 가시적 성과가 나타나는' 행동이여야함.
  . 예) '핸드폰을 바꾼다'라는 행동은 구체적이 아니다. 
    '퇴근길에 핸드폰 가게에 들러 구경한다' 혹은 
    '남친에게 전화해 어떤 모델이 좋은지 물어본다' 혹은 
    '김태희가 선전하는 핸드폰이 살만한 가격인지 인터넷에서 조사한다'와 같이 
    행동을 하면 다음 단계로 넘어갈 수 있을 정도로 구체적이여야 한다.

- 프로젝트 분류
  . 어떤 경우는 하나의 행동으로 끝나지 않을 때가 있다. 
  . 하나 이상의 행동이 필요한 경우 프로젝트로 분류.
  . 프로젝트의 목표를 달성하기 위해 해야할 일이 뭔지 처음부터 끝까지 생각할 필요는 없다.
  . 이 단계에서 필요한 것은 가장 처음의 일. 프로젝트에 뭔가 진전이 있기 위해 가장 먼저 해야할 일을 생각해내는 것이다.

- 2분이 걸리지 않는 '구체적인' 행동
  . 온라인 상점에서 핸드폰 가격 알아보는 건 인터넷만 되면 30초면 된다. 
  . 이런 경우 목록에 적어놓을 필요도 없이 바로 해버리는 것이 낫다(2분은 하나의 기준이다. 시간 여유가 있으면 5분, 바쁘면 30초로 제한해야 할 때도 있다). 

- 2분 이상 걸리는 일 - delegate or defer

- delegate
  . 다른 사람에게 넘길 때는 넘기고 잊어버려도 되는 경우와 그 결과를 챙겨야하는 경우가 있다.
  . 전자의 경우는 넘기는 것으로 머리 속에서 지우면 되고, 후자의 경우는 '기다림(Waiting For)' 목록을 만들어 관리. 

- defer
  . defer의 의미는 '처리' 단계에서 행동하지 않는다는 것이지 시간 상으로 뒤로 미룬다는 것은 아님.
  . 미루는 경우는 달력 아니면 '다음 행동 목록'으로 이동.
  . 이 작업은 '정돈(Organize)' 단계와 많이 겹칩.

:
Posted by codetemplate
2009. 7. 31. 22:19

GTD 따라잡기 #4 - 단계 1 : 수집 (Collect) 관리2009. 7. 31. 22:19

http://futureshaper.tistory.com/218

수집은 "제 자리에 있지 않은" 모든 것을 한곳으로 모으는 작업.

대상은 "열린고리(Open Loop)"라고 한다. 정리되지 않은 편지와 같은 물리적인 것, 답장해야 하는 메일, 해야하는 운동 등이 열린고리에 속한다.

수집 대상에 대해서는 먼저 물리적인 수집하고 전자적인 수집, 그리고 정신적인 수집을 하는 순서

1. 물리적 수집
회사와 집에 큰 서랍(inbox)을 하나 준비하고 눈에 보이는 책상위부터 시작해서 구석구석 뒤지며 "제자리 있지 않은"물건들을 모읍니다(서류, CD, 예전 프로젝트 계획표 등).
너무 크거나 움직일 수 없는 경우 이름을 써서 inbox에 넣는다(예. "안쓰는 모니터").
이때 수집만 하지 처리는 하지 않는다는 중요한 원칙이 있습니다.

2. 전자적 수집
별다른 것이 없음.

3. 정신적 수집(머리 비우기 - Mindsweeping)
몇년동안 마음에 담고 있는 장기계획부터 오늘 써야할 상황보고서까지 다 수집. 목적은 말 그대로 머리를 싹 비우게 빗자루질을 하는 것.


위 항목별로 수집

4. 주간 수집(Weekly Collect)
3까지는 최초 수집
검토 단계에서 주간검토가 필요.
주간검토는 검토만 하는 것이 아니라 수집-처리-검토의 모든 단계를 거치는게 효과적
:
Posted by codetemplate
2009. 7. 31. 18:14

GTD 따라잡기 #2 - GTD 준비하기 관리2009. 7. 31. 18:14

http://futureshaper.tistory.com/211

우선 저장 장치가 필요하다. 저장 장치는 서류등 물리적으로 존재하는 것을 보관하는 것과, 다음에 해야할 일 등 비물리적인 것을 저장하는 것이 있습니다. 이메일이나 음성 사서함등도 다 저장장치라 할 수 있습니다.

Inbox
- GTD읠 출발점
- 빠짐없이 수집을 하기 위해서는 자신이 생활하는 영역을 파악하고, 각 영역에 맞는 inbox를 만들어야 함.
- 물리적인 존재를 담을 바구니가 필요
  . 회사와 집에 하나씩 큰 서랍 하나를 골라서 INBOX라고 레이블을 붙인다.
    . 가족들도 다 알고 있기에, 편지가 오면 바로 이 박스에 넣는다.
    . 제자리에 있지 않다 생각되는 물건들도 일단 여기에 넣는다.
- 머리속에 있는 열린고리를 기록할 Inxbox
  . 종이에 적는 것(예. 플래너)
  . 전자적으로 적는 것(예. 아웃룩)

정돈결과 저장장치
- 처리단계에서 크게 분류되고, 정돈 단계에서 더 세분화됨.
- 처리단계에서 생길 수 있는 결과
  . 쓰레기통, 참조파일(reference), Someday, 위임(Delegate), 달력, Next 
- 정돈단계를 거치고 나면
  . 위임된 항목들은 처리 결과를 기다리는 "Waiting For" 카테고리로 분류
  . Next목록은 상황에 따라 여러개의 카테고리로 나뉘어서 관리
- 이를 종합하면 크게 다음의 세가지 저장장치가 필요하다.
  . 이후 참조를 위한 것들을 저장할 수 있는 공간 (예. 서류함) 
  . 날자가 중요한 항목들을 기입할 달력 
  . 카테고리로 목록을 분리해서 관리할 수 있는 도구 

1. 참조항목 보관 공간
- 당장 무언가 행동을 해야할 필요는 없지만 나중에 참고로 사용할 것들을 보관하는 곳.
- 디스크에 폴더를 만들어서 처리

2. 달력
- 날짜/시간이 중요한 일들을 기록하는 곳(신성한 곳으로 날짜와 시간이 중요한 항목만 적어라).
- 종이달력/전자달력(아웃룩)

3. 목록관리 장치
- 카테고리별로 목록을 관리할 수 있는 것.
- 예). "투자회사 찾기"프로젝트의 "아무개에게 자문 구하기" 항목
  . 처음엔 Call 카테고리.
  . 전화를 하고 나면 답이 올 때까지 "Waiting For"
  . 답을 받고 나면 내용을 "투자회사 어카운트 만들기"로 수정해서 "@OnLine" 카테고리로 보관
- 진행 상황에 따라 카테고리가 변경되어야 하는 경우가 있으므로 전자적인 툴이 좋다.
  . 예). Things, Agendus, RTM(Remember the Milk)

4. Tickler File(일명 43 폴더)
- 월별 12개와 일별 31개 폴더

:
Posted by codetemplate
2009. 7. 31. 15:10

GTD 따라잡기 #1 - 원리 그리고 프로세스 관리2009. 7. 31. 15:10

원본: http://futureshaper.tistory.com/209

위의 내용을 Things 사용을 고려하여 요약함.

사람의 머리는 기억하기 위한 것이 아니라 생각하기 위해 만들어진 것이기에 많은 것을 기억할수록, 생각할 수 있는 여유는 줄어들게 되어 있습니다. 전화번호를 듣고, 어딘가에 기록하기 전까지 잊어버리지 않기 위해 계속 되내어본 경험이 있는 분은 동감할 것입니다 ^^;;

"열린고리(Open Loop)"
- 해야하는데 하지 못한 일 by David Allen

GTD의 원칙
1. 모든 열린고리를 머리에서 꺼내 외부에 기록하는 것
  - 아래와 같은 2가지 목적
    . 기억에 힘을 쓰지 않게 하기 위해서.
    . 생각이 섞이지 않기 위해서.
2. 머리에서 꺼낸 열린고리들을 규칙적으로 검토하며 처리하는 것
  - 처리를 할 때 가장 중요한 것은 한번에 한가지 생각만 한다는 것. 이를 위해 열린고리를 외부에 기록함. 
  - 처리를 위해 GTD에서 제시하는 프로세스가 있음. 이 프로세스를 GTD라고 할 수 있음.

GTD는 처리방법이지 형식이 정해져 있는 시스템이 아니다. 종이 폴더와 A4 용지만으로 할 수 있고, 아웃룩 + 스마트폰으로도 할 수 있다.

GTD의 5가지 프로세스
1. 수집(Collect)
- 열린고리를 수집하는 것
  . 열린고리의 예) 카드청구서, 동창회 초청 이메일, 청첩장, 책상에 쌓여 있는 서류들 ..., 머리속을 맴도는 생각들 등
- 주의사항: 수집은 하되 처리는 하지 않는다. 단 보자마자 버려도 되겠다는 것이 있다면 버림- 이를 위해 수집함(Inbox)가 필요.
- 물리적 수집이 끝나면, 머리속에 있는 생각들을 쓸어 담는다(mind sweep). 삶의 전 영역(회사, 가족, 개인, 취미 등)에 걸쳐 점검하여 마음속에 "이거 해야하는데"하는 것이 있으면 다 적는다.
2. 처리(Process)
- inbox에 모여진 것들을 하나씩 처리.
- 2가지 지켜야 할 원칙
  . 위에서부터 한번에 하나씩
  . inbox에서 꺼낸 것은 다시 집어 넣지 않는다.
- 가장 먼저 할 질문: "이게 뭔가?", "뭔가 실행할 것이 있는가?"
- 실행할 것이 없는 아이템이 갈 수 있는 곳: 
  . 버린다.
  . 참고항목으로 모아둔다
  . 아직은 때가 아니고 incubation시켜야 할 경우 someday로 보낸다.
. 뭔가 할 것이 있는 경우, 바로 "실제적으로"해야할 일이 무엇인가 생각한다.
. 하나 이상의 행동을 필요로 한다면 프로젝트로 등록한다.
. 만일 2분 내에 처리할 수 있다면 바로 해 버린다.
. 그렇지 않다면 내가 할일인가 묻고, 아니면 다른 사람에게 넘긴다.
. 특정한 날에 해야하는 행동이면 scheduled에 아니면 next에 기록한다.
3. 정리(Organize)
- 어떤 행동들은 처리단계에서 정리가 완료된다. scheduled/someday가 그러한 경우이다.
- 보통의 경우 정리안된 항목들이 남게된다. 이를 적절히 분류하고 리마인더를 설정한다.
- 다음 행동 목록을 분류할 때의 요령은 나중에 실행하기 쉽게 하는 것이다.
- 실행단계에서 목록을 보고 "아무 생각 없이" 선택해서 수행하면 되도록 만드는 것이 목표.
- 역할(가족/일/친구 등)이 아닌 상황(@Computer/@집/@교회/@OnLine/전화 등)에 따른 분류를 한다.
4. 검토(Review)
- 주기적으로 검토한다.
- 주간검토(weekly review) by David Allen
  . 금요일 점심 식사 후
  . 처음하는 대규모 수집 이후 주마다 수행하는 소규모 수집
5. 실행(DO)
- today가 가장 우선권이 높다. 다음으로는 next
- 무엇을 할까 선택하는 기준
  . 처리할 수 있는 상황인가 ?(집에서 할일을 회사에서 할 수는 없다. 운전 중이라면 전화 정도는 가능. 그러므로 상황을 가장 먼저 봐야 함)
  . 시간은 충분한가 ? 10분 뒤에 회의가 시작된다면 그 안에 처리할 수 있는 일 밖에 못함.
  . 힘이 드나 ? 피곤해 죽겠는데 장기 계획을 수립할 수는 없다. 현재 남아 있는 기력으로 할 수 있는 일을 고른다.
  . 무엇이 가장 중요한가? 우선순위가 가장 마지막이다.


:
Posted by codetemplate
2009. 7. 29. 15:04

Guidelines for Better Unit Tests TDD2009. 7. 29. 15:04

http://www.infoq.com/news/2009/07/Better-Unit-Tests


Jimmy Bogard “Getting value out of your unit tests” 라는 아티클에서 다음과 같은 3가지 규칙을 명시했다.

1. 테스트 이름은 사용자 입장에서 무엇/ 기술해야 한다. - 개발자가 테스트의 이름을 보면 의도된 행위가 무엇인지 이해할 있어야 한다.

2. 테스트도 코드이다. 테스트에도 사랑을 나눠주라. - 운영코드만 리팩토링해야 하는것이 아니다. 읽기 좋은 테스트는 유지보수하기 쉽고, 다른 사람이 이해하기 쉽다. 길고, 복잡한 테스트를 좋아하는 사람은 없다. 테스트에 30 라인이 넘는 셋업 코드가 있다면 해당 코드를 생성 메소드로 분리하라. 테스트 코드는 개발자를 당혹스럽게 한다. 운영코드에 메소드가 있으면 리팩토링하면서 테스트는 코드는 내버려두는가 ?

3. “Don’t settle on one fixture pattern/organizational style” – Sometimes the standard pattern of one class, one test fixture doesn’t work.


Lior Friedman 테스트의 첫번째 원칙은 내부 구조가 아니라 외부적인 행위를 테스트하는 이라고 한다. 달리 표현한다면 해당 클래스에 대한 현재 구조가 아니라 기대치를 테스트하라는 것이다.


Ravichandran Jv 아래와 같은 자신의 규칙을 언급했다.

1. 가능한 하나의 테스트에 하나의 Assert

2. test 메소드 내에 if/else 존재한다면 분기문을 다른 개별 테스트 메소드로 분리하라.

3. 테스트 대상 메소드에 if/else 존재한다면, 메소드도 리팩토링 대상이다.

4. 메소드의 이름은 어떤 테스트인지를 나타내야 한다. ex. TestMakeReservation TestMakeNoReservation 다르다.


NUnit 저자인 Charlie Poole도 하나의 테스트방 하나의 Assert를 언급했다. 


Bryan Cook 아래와 같은 고려할 만한 테스트 관련 목록을 만들었다:


DO: Name Fixtures consistently

DO: Mimic namespaces of Target Code

DO: Name Setup/TearDown methods consistently

CONSIDER: Separating your Tests from your Production Code

DO: Name Tests after Functionality

CONSIDER: Use "Cannot" Prefix for Expected Exceptions


그리고 이상과 같은 모든 이슈들은 Gerard Meszaros “xUnit Test Patterns: Refactoring Test Code”이라는 책에 집대성된다.

:
Posted by codetemplate
2009. 7. 29. 11:33

Roo Demo 프레임워크2009. 7. 29. 11:33

http://www.jroller.com/desmax/entry/roo

Roo Demo

1. 프로젝트 디렉토리 생성
msmac ~/tutorial/roo] mkdir pizza
msmac ~/tutorial/roo] cd pizza

2. roo 쉘 실행
msmac ~/tutorial/roo/pizza] roo
    ____  ____  ____  
   / __ \/ __ \/ __ \ 
  / /_/ / / / / / / / 
 / _, _/ /_/ / /_/ /  
/_/ |_|\____/\____/    1.0.0.RC1 [rev 198]


Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER.
roo>

3. 프로젝트 생성하기
roo> create project -topLevelPackage com.pizza
...

4. JPA 설치하기
roo> install jpa -provider HIBERNATE -database HYPERSONIC_PERSISTENT 
...

5. 도메인 클래스 생성하기
roo> new persistent class jpa -name ~.domain.Product
...

6. 도메인 클래스에 필드 추가하기
roo> add field string -fieldName name
...

roo> add field number -fieldName price -type java.lang.Double
...

roo> add field boolean -fieldName vegi
...

7. 도메인 클래스에 관계 추가하기
roo> new persistent class jpa -name ~.domain.PizzaOrder
...

roo> add field date jdk -fieldName orderDate -type java.util.Date
...

roo> add field set jpa -element ~.domain.Product -fieldName products
...

8. 컨트롤러와 뷰 추가하기
roo> new controller automatic -name ~.view.ProductController -formBackingObject ~.domain.Product
...

roo> new controller automatic -name ~.view.PizzaOrderController -formBackingObject ~.domain.PizzaOrder
...

9. 실행하기
roo> q
msmac ~/tutorial/roo/pizza] mvn tomcat:run

브라우저 주소창에 http://localhost:8080/pizza를 입력하고 테스트

10. 이클립스에서 프로젝트 불러오기
msmac ~/tutorial/roo/pizza] mvn eclipse:eclipse
eclipse에서 해당 프로젝트 import

Product.java를 열고 @RooToString 라인을 지우고, roo 쉘을 실행하면
msmac ~/tutorial/roo/pizza] roo
    ____  ____  ____  
   / __ \/ __ \/ __ \ 
  / /_/ / / / / / / / 
 / _, _/ /_/ / /_/ /  
/_/ |_|\____/\____/    1.0.0.RC1 [rev 198]


Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER.
Deleted SRC_MAIN_JAVA/com/pizza/domain/Product_Roo_ToString.aj

이처럼 JIT 방식의 code generation이 지원된다.
:
Posted by codetemplate
2009. 7. 28. 13:15

휴가 첫째날 !! 일상2009. 7. 28. 13:15

오늘부터 3년차 안식휴가가 시작되었다. 다음주 목요일까지다. 물론 어제와 다음주 금요일을 개인 휴가로 처리하면 꼬박 2주를 쉴수도 있었지만 뭐 별로 그럴 필요가 없을 듯 하다.
사는 곳이 제주이다 보니, 휴가 기간이라도 그리 갈곳이 만만치 않다. 또 학원 라이프로 바쁜 아이들 때문에라도 그러기 쉽지 않다.

이번주로 금연을 시작한지 꼭 2달이 된다. 그 동안 체중은 한 1kg 정도 증가한 듯 하다. 금연보다 체중 유지가 더 힘든 것 같다.

오늘 아침 운동 후 76.6이였는데... 2주 동안 잦은 운동으로 체중을 최대한 내려 보도록 해야 겠다.

참 아이폰은 언제 나오나 ? 지겹다. 블랙베리로 확 갈까보다...
:
Posted by codetemplate
2009. 7. 26. 21:59

Things, GTD tool 관리2009. 7. 26. 21:59

http://oojoo.tistory.com/209

김지현님의 Things에 대한 설명 요약.

Inbox: 해야 할 모든 일들을 기록.
Today: TO DO를 기록해 넣을 때에 당장 해야 할 일
Next: 최대한 빠른 시간 내에 처리해야 할 일
Someday: 마감이 정해지지 않은 시일 내에 해야 할 일
Scheduled: 일정이 정해진 일

ORGANIZE
    Projects: 프로젝트 리스트를 정리
    Projects를 만든 이후에 그 프로젝트에 하위의 TO DO List를 추가해 넣을 수 있다.
    Areas: 특정한 장소(영역)으로 TO DO를 구분할 때 사용(예. 종료)
:
Posted by codetemplate
2009. 7. 24. 16:06

AspectJ ITD를 이용한 ActiveRecord 구현 Java2009. 7. 24. 16:06

aspectj의 ITD(Inter-Type Declaration)은 roo로 인해 보다 유명해 진 기술로써 클래스에 존재하지 않는 메소드를 추가하거나 존재하지 않았던 관계(extends, implements 등)을 추가하여 클래스의 타입을 변경할 수 있는 기술이다.

이 글에서는 find 메소드를 POJO에 추가하는 것을 aspectj ITD를 이용해서 구현해 본다.  또 ITD로 find 메소드 정의시 generic을 사용해서 타입 캐스팅이 불필요하도록 한다.

1. Test

public class ArticleTest {

@Test

public void find() {

Article key = new Article();

Article a = (Article) new Article().find(key);

assertThat(a, is(key));


ArticleContent key2 = new ArticleContent();

ArticleContent a2 = (ArticleContent) new ArticleContent().find(key2);

assertThat(a2, is(key2));

}

}


위 테스트는 find 메소드를 호출하여 그 값이 key와 동일한지 비교하는 테스트이다.

Article, ArticleContent 클래스에는 find 메소드가 존재하지 않는다.


2. Aspect

privileged aspect ActiveRecordITD {

public interface ActiveRecord {};

declare parents : Article implements ActiveRecord;

declare parents : ArticleContent implements ActiveRecord;

@SuppressWarnings("unused")

private void ActiveRecord.log(String methodName) {

System.out.println(this.getClass().getSimpleName()+"#" + methodName +" called !!!");

}

public <T> T ActiveRecord.find(T key) {

log("find");

return key;

}

}

 

위 aspect에서 특이한 부분을 살펴보도록 하자.

privileged: weaving할 클래스의 private까지도 access 가능하도록 한다.

declare parents: 해당 클래스가 특정 인터페이스를 구현하도록 한다.

public <T> T ActiveRecord.find(T key): ActiveRecord를 구현하는 클래스들에 해당 메소드를 제공한다.


지금까지 간략하게 generic 메소드를 제공하는 ITD를 구현하는 방법을 간략하게 알아보았다. 실제의 경우라면 find 메소드가 보다 복잡해야겠지만서도...


:
Posted by codetemplate
2009. 7. 21. 11:14

Eclipse 3.5 Hidden Treasures 2009. 7. 21. 11:14

http://eclipse.dzone.com/articles/eclipse-35-hidden-treasures

1. Mac Cocoa Support
3.4까지는 Carbon만 지원했는데, 3.5부터는 carbon, cocoa, cocoa 64bit를 지원한다.

2. Block Selection
"Alt + Shift + A"나 "Option + Command + A"
toolbar 버튼으로도 사용 가능하다. 만일 아직 enable되지 않았다면 Customize Perspective 대화 상자를 열고, Editor Presentation라는 Command Group을 enable하면 된다.

3. Debug View as Breadcrumbs
주목할 만한 UI 변경이다.

- Debug Perspective에서 Debug View의 오른쪽 위의 작은 삼각형을 클릭
Layout -> Breadcrumb를 선택
:
Posted by codetemplate