하루 평가 : 5점 만점중 2점. (중요하고 긴급한 일들을 잘 처리 못함)
할일 목록중

• 도서관에서 류군 TPOCP 찾아주기 - O
  
• 사람수대로 retrofitting 인쇄하기 -> 6부 인쇄하기 - O
  
• Retrofitting UT 발표준비
  
  • 내용설명 관련 -> 1차적으로 이해를 위한 TOC 작성. - O
    
    -> 살을 붙여서 이해하기 -> restatement 필요 & 대강 무질서한 방법으로 넘어가버림.
    
  • 경험 내 적용 거리
    
• dotplot 작성궁리
  
  • normalization
    
  • dot plotting
    
• index card 내용 정리하기
  
• 1시 30분. 한양대쪽으로 이동하기 - o
  
• 10시 30분까지 학교 도착하기 - o
  
• 프로젝트 관련 소스 인쇄 - o
  
• 프로젝트 관련 소스 분석하기 -> restatement 필요.
  

'요새 느슨하게 살고 있다' 라는 10글자에 대한 약간의 구체화 & 재진술.

~cpp 
3 : 30 ~ 9 : 00 잠
 ~ 9 : 13 식사
 ~ 9 : 33 머리감기 & 양치질 & 옷입기 & 가방정리
 ~ 9 : 46 강변 도착
 ~ 9 : 50 건대입구 도착
 ~ 10 : 38 피시실 7층 도착
 ~ 11 : 14 프로젝트 관련 소스 인쇄
 ~ 11 : 20 retrofitting 인쇄
 ~ 11 : 30 internet 돌아다니기
 ~ 1 : 06 retrofitting 공부 & 이해
 ~ 1 : 31 PC 7 문 잠그기 위해 경비아저씨께 전화 & 기다리기
 ~ 1 : 47 점심식사 (빵 & 우유. 800원)
 ~ 2 : 03 지하철 역 도착
 ~ 2 : 16 (지하철) using singleton wisely 읽고 이해
 ~ 2 : 42 (지하철) retrofitting 읽기 & 이해
 ~ 2 : 57 HIT 도착
 ~ 6 : 14 XP Study Group
 ~ 6 : 42 강변역 도착
 ~ 7 : 00 집에 도착
 ~ 7 : 35 인터넷 싸돌아다니기.
 ~ 9 : 35 저녁식사. Four Boxes 2차 시도 진행
 ~ 10 : 00 완료
 ~ 10 : 32 웹서핑. 이것저것
 ~ 12 : 03 휴식 (집안사람들과 대화)
 ~ 2 : 07 아는 사람과 메신저에서 대화관련.

이중 웹서핑으로 32분을 쓰고, 휴식으로 1시간 30분을 또 쉬고, 중간중간 인터넷에 별 목적없이 돌아다니는 시간이 많았다는 점이 문제.
아직은 다른 개념에 대한 재추상화에 대해선 별로 궁리하고 있지 않은중. 일단은 바보인 상태를 진행중. 관찰중이긴 할까?

• 규영이형이 Working Effectivly With Legacy Code 발표할때를 보면서 그 격에 있어 현격함을 느낌.
  
  • 스토리 텔링이 가능하다는 점. (나는 앞 뒤의 이야기가 끊어진다.)
    
  • 전체 책 내용에 대한 Summary 가 TOC 로 조직적이라는 점. (이번에 TOC 를 준비 안했다.)
    
  • 구현 경험이 풍부하다는 점. 해당 책 내용에 대해 코드로 예를 들어달라면 들어줄 수 있을정도. (나는 해석부분에 대한 1차 해석에서부터 잘 하지 못함)
    


• 구체적인 action plan 에 대해서는 추후 궁리.
  
• 다른사람들이 '나'로부터 뭔가 유용한점을 얻기가 쉽지 않겠다는 생각이 들게 되다. 뭐, 의외의 오해로 가능할지도. 해당 말에 대한 가치는 듣는 사람들이 만들어내니까.
  
• 사실을 사실 그대로 담담해져보기 궁리중. 참 쉽지 않은중.
  
• 땅은 척박하고. 씨뿌리는 농부는 많으매 싹이 나질 않네.
  
  
  

공개 위키에서의 Journal.
장점 : 개인 감정에 치부될 판단을 잘 하지 않게 된다.
다른 사람들을 의식하여, 좀 더 자세히 논리적인 글을 쓰게 된다.
다른 사람들을 의식하여, 좀 더 자주 글을 쓰게 된다.
단점 :
솔직하지 못하게 될 수 있다. 자신의 일을 미화할 수도 있다. TunnelVision에 빠진 사람은 '보고싶은 것만' 보이게 된다. YouSeeWhatYouWantToSee
자신이 좀 창피하거나 소위 '쪽팔리는' 일에 대해서 해당 내용을 안써버릴 수도 있다.

• 내가 쓰는 상당양의 단어들을 볼때 누구의 영향을 얼마만큼 받았는지가 느껴진다. 비록 훌륭한 학생이 아니긴 하지만.
  

25, 26 - 평가. 계획. 책 충동구매.;
1년 평가라는 것은 중간 3개월 평가가 없으면 어려운 일이다. 데이터가 남아있질 않군.
책을 8권 정도 샀다. Input 대비 Output 비율이 이전보다 조금이나마 높았으면 한다.
13 (금), 14 (토), 15(일) - RT
금 :

• 영어 읽기 준비
  

읽기 준비 전 ThePsychologyOfComputerProgramming이 어려울 것이라는 생각이 먼저 들어서, 일단 영어에 익숙해져야겠다는 생각이 들어서 Alice in wonderland 의 chapter 3,4 를 들었다. 단어들이 하나하나 들리는 정도. 아직 전체의 문장이 머릿속으로 만들어지진 않는 것 같다. 단어 단위 받아쓰기는 가능하지만, 문장단위 받아쓰기는 힘든중.
도서관에서 이전에 절반정도 읽은 적이 있는 Learning, Creating, and Using Knowledge 의 일부를 읽어보고, HowToReadaBook원서를 찾아보았다. 대강 읽어봤는데, 전에 한글용어로는 약간 어색하게 느껴졌던 용어들이 머릿속에 제대로 들어왔다. (또는, 내가 영어로 된 책을 읽을때엔 전공책의 그 어투를 떠올려서일런지도 모르겠다. 즉, 영어로 된 책은 약간 더 무겁게 읽는다고 할까. 그림이 그려져 있는 책 (ex : AreYourLightsOn, 캘빈 & 홉스) 는 예외)
일단, 좀 쉬운 책들에 대해 어느정도 Input 이 좀 들어왔으니 괜찮겠지 하고 책을 읽었다.

• TPOCP 읽기
  
  • 어려움 : 요약을 어떻게 할 것인가?
    한글 책을 읽을때엔 한글로 요약한다. 영어책을 읽는 중 한글로 요약하려니 내가 읽을때 가급적 한글로 해석 안하려고 하는 연습중이다. 그러하기엔 또 지금 영어 작문능력이 뛰어나지 않다.
    
  • 잘못된 습관 : 대충 읽기
    책을 읽으면서 '해석이 안되는 문장' 을 그냥 넘어가버렸다. 즉, HowToReadaBook에서의 첫번째 단계를 아직 제대로 못하고 있는 것이다. 그러한 상황에서는 Analyicial Reading 을 할 수가 없다.
    
  • 왜 이런식으로 읽을까 하는 생각을 해보았는데, 영어로 된 책을 읽을때는 주로 문제해결을 위해 읽을때가 많아서 그런것 같다. (속칭 고등학교 영어시험용 읽기) 빨리 읽으려고 개인적인 의역을 너무 오용하는것 같기도 하다. 그리고, 단어를 습득하는데 좀 더 민감해질 필요가 있을 것 같다. (여러번 읽기 등) Chapter 7,8 읽는데 모르거나 뜻을 대강만 알고있어서 이뜻인지 저뜻인지 애매해했던 단어들 합쳐보니 230개정도 된다. 현재 영어수준은 중학교 1학년 수준정도인것 같다.
    
  • GOF 번역을 할때엔? - 번역을 할때엔 애매한 단어들에 대해 전부 사전을 찾아보게 된다. (완전히 직역을 하므로) 시간이 많이 걸리지만, 영어학습 초기엔 자주 해보는게 좋지 않을까 생각한다. (꼭 한글 번역이 아닌, 어려운 영어에 대한 쉬운 영어로의 해설. 이게 좀 더 어려우려나..)
    


• 그렇다면, 어떻게 HowToReadaBook이나 'Learning, Creating, and Using Knowledge' 은 읽기 쉬웠을까?
  
  • 사전지식이 이미 있었기 때문이라고 판단한다. HowToReadaBook는 한글 서적을 이미 읽었었고, 'Learning, Creating, and Using Knowledge' 의 경우 Concept Map 에 대한 이해가 있었다. PowerReading 의 경우 원래 표현 자체가 쉽다.
    
  • 반면, TPOCP 의 경우 사전지식을 가지고 있지 않았고, 한편 '새로 읽는 책에 대해서 사전지식으로 해석하기'를 조심하고 있었다. (이건 좀 다행인듯 하다.) 그리고 RT 이후의 다른 사람들 의견을 들어보면, 쉬운 영어는 아닌 것 같다.
    
• 정리
  
  • 현재 내 영어수준을 보건데, 컴퓨터 관련 서적 이외에 쉽고 일상적인 책들에 대한 Input 이 확실히 부족하다. 영어로 된 책들에 대해서는 좀 더 쉬운 책들을 Elementary Reading 단계부터 해봐야겠다.
    
  • 지금 현재 상황에서 적절한 속도는 약 70 WPM 인것 같다. 모르는 단어 하나하나 전부 사전에서 찾아보는 속도 기준. 어느정도 어휘들에 익숙해지고 난 뒤.
    


• ReadershipTraining
  
  • 중요 목표중 하나가 RT 가 어떻게 이루어지고, ZeroPage 에서 RT 실행시 어떻게 할까에 대한 궁리.
    
  • 진행방법 (일단 이날 했었던 방법)
    
    • 발제한 사람들 중심으로 발제자가 해당 내용 정리.
      
    • Facilitator 나 발제자, 또는 읽는 사람들이 질문제기 & 사람들 의견 자유토론
      
    • 걸린 시간 : 6시 30분 ~ 2시. (중간 휴식시간 1시간 정도) Chapter 12개 기준.
      


• 기본적으로 발제하고 발표할 수 있으려면 챕터 당 4-5번 정도 정독을 해야 할 것 같다.
  
  • 이번에 발제를 상당히 잘했다고 생각되는 사람들을 보니, 한명은 적어도 일주일전부터 준비했고, 한명은 해당 챕터를 3-4번정도 읽었다고 한다. 그리고 그 사람들이 이야기할 수 있을 정도가 어느정도이냐면, 해당 예제상황에 대해 적절하게 자신의 예로 말할 수 있을정도이거나, 또는 요약한 내용을 거의 보지 않고도 이야기할 수 있는 수준이였다. 두명의 경우 외부 자료를 찾아보기도 했다.
    
  • 한명은 해당 주제어를 이야기하고, 이 주제어 뜻이 무엇인지를 이야기하고, 그에 연결되는 이야기를 해주는 식.
    
    • 이러한 사람들이 책을 읽을때 5분간 읽으면서 어떤 과정을 어느정도 수준으로까지 거치는지에 대해 구경해볼 수 있어도 좋을것 같다. 그러한 점에서는 RT 때 Chapter 단위로 Pair-Reading 을 해봐도 재미있을 듯 하다. '읽는 방법'을 생각하며 좀 더 의식적으로 읽을 수 있지 않을까.
      
  • 다른 사람들이 나에 비해 해당 어휘에 대한 재정의(Restatement) 단계가 하나나 두단계정도 더 높았던걸로 기억한다. 내가 책을 읽을때 질문을 잘 못만들어내는 것도 한 몫하는것 같다.
    


• 2학년, 3학년들에 대해 좀 더 실용적인 RT로 한다면, 해당 프로그래밍 언어에 대한 RT를 할 수 있을것도 같다. (노트북 2대정도 이용, 사람들이 다같이 둘러서 보는..)
  
• 처음 프로그래밍을 접하는 사람에게는 전체 프로젝트 과정을 이해할 수 있는 하루를, (이건 RT 보단 밤새기 프로젝트 하루짜리를 같이 해보는게 좋을 것 같다.) 2-3학년때는 중요 논문이나 소프트웨어 페러다임 또는 양서라 불리는 책들 (How To Read a Book, 이성의 기능, Mind Map 이나 Concept Map 등)을 같이 읽고 적용해보는 것도 좋을것 같다.
  
  
  


• ReadershipTraining Afterwords
  
  • 쓰다보니 책 자체에 대한 내용이 빠졌군.
    
    • 심리학 서적이 어떠한 스타일인지는 모르겠지만, 소프트웨어 개발의 각 과정들에 대해 정말로 'Human Performance' 라는 관점으로 서술한다.
      
    • 생각나는 부분 :
      
      • 코드를 읽는 것.
        
      • 콘웨이 법칙
        
      • Blank Error 의 에러율 변화에 대한 통계 - 이론으로 Dead Lock 을 아는 것과, 실제 Multi Thread 프로그래밍을 하는 중 Dead Lock 상황을 자주 접하는것. 어느것이 더 학습효과가 높을까 하는 생각. 동의에 의한 교육에서 그 동기부여차원에서도 학습진행 스타일이 다르리란 생각이 듬.
        
      • Efficiency : Effectivily - 내가 발표했었던 7장의 그 예제가 가장 중요한 예제중 하나였다고 Comment 에 써있었던걸로 기억하는데.. 생각해보면 내가 발제할 부분 내용 참 재미있는 부분이였는데, 제대로 발제 못한게 참 사람들에게 죄송스럽다.
        


• Post Script.
  
  • 현재 내가 죽어가고 있는중이긴 한가 보다. 어제와 그제, 잠시 스스로 죽음을 목격한 것 같고, 다른 사람이 내 죽음을 구경한 것 같다. (이미 몇일전부터 목격했었던 사람도 있는것 같다.)
    
  • 쌓아나가야 할 부분이 상당히 많아보이는데.. Refactoring 에서의 경험을 어설프게 가로질러본다면. ReFactoring 을 할때 나쁜 클래스들을 그 안에서 계속 고쳐나가는 것 보단, 새 클래스나 메소드들을 중간에 만든뒤, 나쁜 클래스들을 삭제하는게 더 빠른 방법이다. 좋은 습관을 만들어내는 것이 나쁜 습관을 고쳐내려고 하는것보다 최종적으로 볼땐 더 접근하기 쉽지 않을까 하는 생각을 해본다. 나쁜 점이라 생각하는것은, 의식화해서 고치는 것 보단 좋은 습관으로 대체하고 나쁜 습관을 아에 잊어버리게끔 하는것이 더 나은것 같다.
    
    • 아직은. 머릿속의 '말' 일 뿐인중.
      

12 (목): 책상정리
비어있어야만 유용한것들이 있으니. 빨리 정리되어버려야 할 것들.
10 (화): Prometheus 리팩토링 (계속진행중. 일주일째 진행중이던가. -_-a)
연습장에 전체 클래스들 구조를 그려봤다. CRC 를 쓸까 하다가 늘어놓을 자리가 없어서..;
상단의 클래스들은 하단의 클래스들을 이용하는 식이다.

그림을 보고 나니, Inheritance 나 Delegation 이 필요없이 이루어진 부분이 있다는 점 (KeywordGenerator 클래스나 BookSearcher, HttpSpider 등) Information Hiding 이 제대로 지켜지지 않은것 같다는 점, (Book 과 관련된 데이터를 얻고, 검색하여 리스트를 만들어내는 것은 BookMapper 에서 통일되게 이루어져야 한다.) 레이어를 침범한것 (각각의 Service 클래스들이 해당 로직객체를 직접 이용하는것은 그리 보기 좋은 모양새가 아닌듯 하다. 클래스 관계가 복잡해지니까. 그리고 지금 Service 가 서블릿에 비종속적인 Command Pattern 은 아니다. 그리고 AdvancedSearchService 와 SimpleSearchService 가 BookMapper 에 촛점을 맞추지 않고 Searcher 클래스들을 이용한 것은 현명한 선택이 아니다.)
구조를 살피면서 리팩토링, KeywordGenerator 클래스와 HttpSpider 등의 클래스들을 삭제했다. 테스트 96개는 아직 잘 돌아가는중. 리팩토링중 inline class 나 inline method , extract method 나 extract class 를 할때, 일단 해당 소스를 복사해서 새 클래스를 만들거나 메소드를 만들고, 이를 이용한뒤, 기존의 메소드들은 Find Usage 기능을 이용하면서 이용하는 부분이 없을때까지 replace 하는 식으로 했는데, 테스트 코드도 계속 녹색바를 유지하면서, 작은 리듬을 유지할 수 있어서 기분이 좋았다.
어느정도 다시 정리된 뒤, 크게 그리는 것이 낫겠다고 판단, 화이트보드에 그림. (마침 보드 마카 없어서 전지에 매직으로.;)

내일 좀 더 작업을 할 궁리. CVS 에서 버전을 따로 둘까도 궁리중. (구조가 좀 많이 바뀔 것 같다. 원하는 디자인으로 가려면 저 점선 부분으로 가야 하리라 생각.)

• 더도말고 덜도말고 '테스트 통과만큼만' 이라는 사고방식은 개발속도를 상당히 향상시킨다.;; 리팩토링중 재차 배움.
  

8 (일):
실제 Database 를 이용하는 테스트에 대해 하나만 실행했을때는 잘 되더니, Suite 에 묶으니까 테스트에서 이용하는 Connection 이 NULL 이 되어버린다. Connection POOL 의 문제인듯. 필요없는 곳에 Connection 열어놓은 것을 하나만 이용했더니 해결.
7 (토): Prometheus Test Code 추가 대장정
Prometheus 리팩토링중. 기간을 잡지 않고 하니 엄청나게 늘어지는 것 같다. 다시 할일 목록을 구체적으로 잡고 해야겠다.
기존의 AcceptanceTest 들이 작동을 못한다. (Python 에서 정규표현식 이용. 데이터 파싱 & 추출. Prometheus UI 가 바뀌면 다시 바뀜) 전에 구경한 것처럼 XPath 를 이용하는 방법을 궁리해보거나, Prometheus 쪽에서 XML + XSLT 를 이용하는 방법을 궁리했다. 하지만, 그러기엔 현재 Prometheus 의 JSP 부분을 전부 바꾸는데 부담이 크리라 판단, Servlet Controller 중 Service 클래스 부분에 대해 테스트 코드를 붙이는 방법을 생각해 냈다. 하지만, 막상 작성해보고 나니 그 또한 테스트 코드의 크기가 크긴 하다.
Service 와 Controller 가 거의 Composition 이고, 그로 인해 Controller 는 Mapper, Recommender 들이 줄줄히 의존성을 가졌다. 각각의 Mapper, Recommender 들이 DB 를 쓰므로 이를 Mock Object 를 쓸까 하다가, 어차피 현재 작성하는 부분이 AcceptanceTest 의 일부이므로 실제 객체를 그냥 이용해도 좋겠다고 판단, 그대로 이용하고 작성.
----
지금 생각해보면, 이미 테스트가 있는 코드들을 먼저 가능한한 단순하게 리팩토링하고 그 다음 Service 쪽 리팩토링을 했다면 어떠했을까.
----
테스트 코드 작성을 위한 일부 코드 복사 & 메소드 추가 & 클래스 추가.
----
Test 통과하는 만큼만이 내가 만든것이니. 더도말고 덜도말고. 걱정말자 걱정말자 걱정말자. -_-;
이번에 리팩토링을 하려고 할때 Legacy Code Refactoring 이라고 상정해서 그럴까. Coverage Test를 완벽하게 작성하는 것에 대해 부담감을 느꼈다. 예전에 유용했었던 '아아. 이미 다 되어있어요.~' 를 다시 적용해볼까.
----
Refactoring Catalog 정독. 왜 리팩토링 책의 절반이 리팩토링의 절차인지에 대해 혼자서 감동중.; 왜 Extract Method 를 할때 '메소드를 새로 만든다' 가 먼저인지. Extract Class 를 할때 '새 클래스를 정의한다'가 먼저인지. (절대로 '소스 일부를 잘라낸다'나 '소스 일부를 comment out 한다' 가 먼저가 아니라는 것.)
5 (목):
힘을 주는 말.

• Instead of being tentative, begin learning concretely as quickly as possible.
  
• Instead of clamming up, communicate more clearly.
  
• Instead of avoding feedback, search out helpful, concrete feedback.
  

from TestDrivenDevelopmentByExample
3 (화): DDD 책 표지 궁리하기
책 표지를 궁리할때도 일종의 디자인이랄까. 하지만, 시각디자인쪽에 대해서는 아는 바 없으므로, 그냥 개인적인 연상작용대로 진행했다.
DDD 하니까 XP 방법론과 잘 맞는다는 말이 생각이 났었고, 그러다가 TDD 생각이 나고, 그러다가 Calvin & Hobbes 가 생각이 나고 (여기까지 한줄기)
DDD 하니까 JuNe 형이 '전화기 심볼있으면 좋겠네~' 라고 한말이 생각나고 (DDD 니 -_-) 그래서 전화 이미지가 필요할 것이라 생각이 들어 전화기 클립아트를 검색하고, 그러다가 전화기 클립아트중 캘빈이 전화받는 이미지가 하나 있었고 (여기까지 한줄기)
두개를 교차시키다가 갈등하다가 결국 다음과 같은 식이 되었다는. -_-; (원래는 그냥 캘빈이 전화받는 이미지만 있었던거랑, 캘빈이 전화선 뽑는거, 캘빈이랑 홉스가 이웃집 근처에 눈으로 열심히 담쌓아놓고 '아 우리의 담은 튼튼해~' 이런식으로 좋아하는 동안 이웃집 아저씨가 '이놈의 자식들;' 하는거 등등 - 마치 프로그래머 : 고객 의 관계의 매타포 같다는 생각이 들어서 - 많았는데. 갈수록 배가 산으로 가는것 같다는. -_-;)
ProjectPrometheus Refactoring 궁리하기
Refactoring 을 하기전 Todo 리스트를 정리하는데만 1시간정도를 쓰고 실제 작업을 들어가지 못했다. 왜 오래걸렸을까 생각해보면 Refactoring 을 하기에 충분히 Coverage Test 코드가 없다 라는 점이다. 현재의 UnitTest 85개들은 제대로 돌아가지만, AcceptanceTest 의 경우 함부로 돌릴 수가 없다. 왜냐하면 현재 Release 되어있는 이전 버전에 영향을 끼치기 때문이다. 이 부분을 보면서 왜 JuNe 이 DB 에 대해 세 부분으로 관리가 필요하다고 이야기했는지 깨닫게 되었다. 즉, DB 와 관련하여 개인 UnitTest 를 위한 개발자 컴퓨터 내 로컬 DB, 그리고 Integration Test 를 위한 DB, 그리고 릴리즈 된 제품을 위한 DB 가 필요하다. ("버전업을 위해 기존에 작성한 데이터들을 날립니다" 라고 서비스 업체가 이야기 한다면 얼마나 황당한가.; 버전 패치를 위한, 통합 테스트를 위한 DB 는 따로 필요하다.)
그리고, 각각의 테스트들을 위한 DB Property 설정이 자유로우려면 Server Property 화일은 스크립트 화일로 빠져나와야 한다. (테스트 돌릴때마다 프로그램 재컴파일 한다는건, 추후 프로그램 커졌을때 효율적인 방법이 아니다.)
그리고, 이전에 ProjectPrometheus 작업할때엔 서블릿 테스팅 방법을 몰랐다. 그래서 지금 ProjectPrometheus 코드를 보면 서블릿 부분에 대해 테스트가 없다. WEB Tier 에 대한 테스팅을 전적으로 AT 에 의존한다. 이번에 기사를 쓸때 마틴 파울러의 글을 인용, "WIMP Application 에 대해서 WIMP 코드를 한줄도 복사하지 않고 Console Application 을 만들수 있어야 한다" 라고 이야기했지만, 이는 WEB 에서도 다를 바가 없다고 생각한다.
가야 할 길은 언제나 멀게만 느껴진다.
2 (월): ProjectPrometheus 소스 리뷰 & 리팩토링. audio book MP3 뜨기
Prometheus 를 보면 테스트가 통과했다 안했다를 반복한다. 학교 도서관 시스템의 안정성이 그리 뛰어나지 않기 때문이다. (바꾸고 난 뒤 오히려 맨날 문제를 일으킨다. 똑같은 조건식에서 한번은 검색이 되고 한번은 검색이 안되니.. 쩝)
이전에 TDD 할때 초기 Library 클래스에 대해 Mock 클래스 만들었다가 없애버렸는데, 다시 Library Mock 클래스를 만들어야 할 것 같다. 리팩토링 할때 Fail 난 테스트로 리팩토링을 할 수는 없을테니.
Composition 의 문제점
이전에 Delegation 하는 클래스를 해당 클래스 내에 멤버로 두었는데. 예를 들면 이런식으로

~cpp 
public class BookMapper {
.
.
.

 private Book getBookFromRemote(String aBookId)
            throws ProtocolException, IOException {
        Library library = new Library();
        Book book = library.view(aBookId);
        return book;
    }

이를 생성자에 넣어주는 방법으로 바꾸는 것이 더 올바른 디자인이라 생각된다. 다음처럼.

~cpp 
public class BookMapper {

 public BookMapper(ILibrary library) {
        this.library = library;
 }

 private Book getBookFromRemote(String aBookId)
            throws ProtocolException, IOException {
        .
        .
        Book book = library.view(aBookId);
        return book;
    }

해당 클래스 내에서 생성하는 디자인은 그 클래스를 교체해줄 수가 없으니 유연한 디자인이 아니다. 그렇다고 setter 를 두는 것도 좋은 디자인은 아닌것 같고. (프로그래밍 실행 중간에 Delegation 하는 객체를 교체할 일은 드물다. State Pattern 이나 Strategy Pattern 이 아닌이상.) 아마 처음에 Mock Object 를 이용하여 BookMapper 를 만들었었다면 Connection 을 직접 이용하거나, Library 객체를 내부적으로 직접 인스턴스를 생성하여 이용하는 디자인은 하지 않았을 것이란 생각이 든다.
----
사실 ~cpp LoD 관점에서 보면 자기가 만든 객체에는 메세지를 보내도 된다. 하지만 세밀한 테스트를 하려면 좀더 엄격한 룰을 적용해야할 필요를 느끼기도 한다. 니가 말하는 걸 Inversion of Control이라고 한다. 그런데 그렇게 Constructor에 parameter로 계속 전달해 주기를 하다보면 parameter list가 길어지기도 하고, 각 parameter간에 cohesion과 consistency가 떨어지기도 한다. 별 상관없어 보이는 리스트가 되는 것이지.
factory method를 사용해라.

~cpp 
public class BookMapper {
.
.
 private Book getBookFromRemote(String aBookId)
            throws ProtocolException, IOException {
        Book book=getLibrary().view(aBookId);
                .
                .
}
 protected Library getLibrary() {
        return new Library();
}

이걸 상속받아서 getLibrary를 override하고 MockObject로 연결해라.
--JuNe
----
audio book
어제 간만에 교보에 들려 Alice in wonderland 와 Dr.Jekyll & Mr.Hyde 오디오 북을 샀다. 교보쪽 외국어 분야쪽이 비교적 정리가 잘 되어있는 듯 하다. 다음에도 종종 들려야겠다.
Alice in wonderland 의 경우 여자성우가 읽어준다. 이전에 들었던 Sherlock Holmes 의 경우에 익숙해져여서인지, 발음속도가 느림에도 불구하고 이해도가 떨어졌다. 이전에는 그냥 듣고 머릿속에서 문장을 그린다음 이해하는 방식으로 했는데, 이번에는 받아쓰기 연습을 해봐야겠다.
카세트를 잘 안쓰기 때문에 테이프로는 잘 안들을까봐 Cool Edit 이용, MP3 로 녹음했다. 웨이브 화일도 결국은 데이터이기에, 마치 테이프 짤라서 이어붙이는 듯한 느낌으로 웨이브 화일 편집하는게 재미있었다. 이전에 르네상스 클럽때 웨이브 화일에 대해 텍스트화일로 변환 & 인덱싱하는 프로그램이 필요한 이유가 생겼다. 전체 녹음을 하고 난 뒤, Chapter 별로 짤라서 화일로 저장하려고하는데, 웨이브데이터에 대해 검색을 할수가 없다! 결국 '대강 몇분짜리 분량일 것이다' 또는 '대강 다음챕터로 넘어갈때 몇초정도 딜레이가 있으니까.. 소리 비트와 비트 사이가 대강 이정도 되면 맞겠지...' 식으로 찾아서 화일로 쪼개긴 했지만. 웨이브 데이터에 대한 text 검색이 일상화된다면 이러한 고생도 안하겠지 하는 생각이 든다.

29 (금): 영어 질문답변시간 참석. 르네상스 클럽. Work Queue, To Do List. 7막 7장.
Work Queue
앞으로 하고 싶은 막연한 일들에 대해 주욱 나열, 그리고 그중에 대강 당장 해야 할 일에 대해서 일들을 좀 더 세분화하여 나누어보았다. 당장 특별한 효과를 노리고 한건 아니고,.. 그냥 해볼만한 일들에 대해 적어보았다.
적고 나니까.. 몇달전에 '해야지 해야지' 했었던 것들, 몇년전에 '해야지 해야지' 했던 것들이 Work Queue 에서 기다리고 있다. 멀리로는 Smalltalk 코드 제대로 읽을 줄 안뒤 SBPP 공부한다고 했었던 것이랑, Functional Language 하나 익혀둔다고 했었던 것이랑, 가까운 것으로 치면 기존에 만들어놓은 소스들 리팩토링 하면서 라이브러리 추출한다고 했었던 것들 등등.
아직은 협상할 수는 있긴 하다. 시간을 허락해주신다면. 언제까지 허락해주실지는 모르겠지만.
7막 7장
현재 : http://www.savie.co.kr/SITE/data/html_dir/2002/10/01/200210010019.asp. 결혼도 하고 세살된 딸도 있단다. 현재의 사진을 보니 남궁원씨 닮아가는군. M&A 전문 회사 대표라고 한다.
꽤 오래되긴 했지만 (벌써 그게 9년전 이야기란다. 93년 이라니까) 홍정욱의 책을 다시 읽었다. 그당시에는 '아. 그냥 공부 잘하는 사람의 열심히 공부했다는 이야기구나' 로 그냥 한번 읽고 끝났던 것으로 기억한다. 그러다가 간만에 생각이 나서 책을 다시 꺼내 버스안에서 읽었었는데, 그의 표현력을 보면서 그가 얼마나 많은 시들을 읽었는지, 얼마나 많은 책들을 읽었는지 보인다. 중간중간 자신의 현재 심정을 표현하면서 인용하는 시들, 명언 구절들에 전부 그 인용한 사람들의 이름들과 출처가 나와있는 것을 보면서, 한편으로는 얼마나 학교에서 철저하게 가르치는지, 그가 얼마나 철저하게 공부했는지가 보이는 것 같다.
몇년만에 읽었던 그의 책이 '마침표 없는 책이다' 말고도 할 이야기거리가 많다는게 다행스럽게 느껴졌다. (책의 입장에서나 나의 입장에서나)
르네상스 클럽
그 중 조심스럽게 접근하는 것이 '가로질러 생각하기' 이다. 이는 아직 1002가 Good Reader / Good Listener 가 아니여서이기도 한데, 책을 한번 읽고 그 내용에 대해 제대로 이해를 하질 못한다. 그러한 상황에서 나의 주관이 먼저 개입되어버리면, 그 책에 대해 얻을 수 있는 것이 그만큼 왜곡되어버린다고 생각해버린다. 그림듣기의 유용함을 알긴 하지만.
글쌔. 하지만, '가로지르기'는 굉장히 중요한 사고 방식이라 생각한다. 유연한 사고가 가능하고, 또 뜻하지 않은 아이디어를 얻을 수 있을것이니까. (이전의 Metaphor 를 생각하면 더더욱.)
암튼, 두가지가 꼭 상대되는 일은 아니니까. 암튼. 그 전에 국어/영어 독해능력이 먼저군.;;
28 (목): 하드 소스 & 문서 정리. ProjectPrometheus 버그 수정
기존에 작성한 소스들은 골칫거리다. 이를 나중에도 이용하자니 낡은 소스일것이고, 그렇다고 버리기엔 해당 분야 공부하기에 가장 쉬운 소스이고.. (문서들도 마찬가지. 소위 팻감으로 불리는.)
이전에 1002/책상정리 가 생각이 나서, 하드 안에 있는 소스, 문서들에 대해 일종의 LRU 알고리즘을 생각해보기로 했다. 즉, Recent Readed 라는 디렉토리를 만들고, 최근에 한번이라도 건드린 코드, 문서들은 Recent Readed 쪽에 복사를 하는 것이다. 그리고, 읽었던 소스에 대해서는 라이브러리화하는 것이다. 이렇게 해서 한 6개월쯤 지난뒤, 정리해버리면 되겠지 하는 생각.
지금 이전 노래방 프로그램 만들때 이용했었던 Audio Compression Manager 부분 이용하라고 하면 아마 다시 어떻게 API를 이용하는지 회상하는데 2일쯤 걸릴것이다. DX Media SDK 부분을 다시 이용하라고 하면 아마 하루정도 Spike 가 다시 필요할 것이다. 즉, 이전에 만들어놓은 소스가 있다고 그 지식이 현재 나의 일부라고 하기엔 문제가 있다.
기존의 코드들이란 한편으로는 사람을 게으르게 하는 원동력인 것 같다는 생각이 든다. 어설픈 자만심을 만들어낼런지도 모른다. 그래도 여전히 지우지 못하는건.. 그때 이리저리 정신없이 자료 모으며 삽질하고 좌절했을때가 생각나서일까.
암튼. 언젠가 다시 내 일부가 되기를.
----
Prometheus 코드를 다시 checkout 하고 UnitTest 깨진 부분을 보면서 기존의 TDD 진행 보폭이 얼마나 컸는지가 보였다. (다시 Green Bar 를 보이게끔 하기에 진행해야 할일이 많았으니까. Extractor Remote Test 가 no matched (정규표현식에서 매칭 실패)로 깨졌을때 생각해야 할 일이 두가지이다. 하나는 HTML 이 제대로 받아졌는가(또는 HTML 이 도서관에서의 에러코드를 반환하는가), 하나는 extractor 가 그 구실을 제대로 하는가. 그런데, 테스트 코드를 보면 저 두가지가 묶여있다.
그리고 정규표현식을 이용한 extract 가 과연 'The Simplest Thing' 일까라는 생각을 하게 되었다. 올바른 정규표현식을 찾아내야 하고, 그러다보면 데이터 코드와 정규표현식이 일종의 Duplication 을 만들어낸다. (파싱하려는 문서의 일부가 정규표현식에 들어가므로) 그리고 RE 는 RE 문법을 아는 사람이라면 모르겠지만, 그렇지 않고 막연한 경우에 TDD 할 경우 Try and Error 식으로 접근해버릴 수 있다. (나의 경우는 이걸 점진적으로 하기 위해 표본이 되는 데이터를 작게 시작한다.) extract 의 'Simplest Thing' 는 find & substring 일것이란 생각을 해본다.
그리고, 도서관 UI 가 바뀌었을 경우에 대한 대처방안에 대해서 이리저리 아이디어를 궁리해 보았었는데, 정규표현식부분을 따로 떼어내어 외부화일로 두던지 (이렇게 하면 컴파일하지 않아도 정규표현식을 수정하면 된다) 또는 HTML 을 전부 Parsing 하여 DOM 트리를 만든뒤 해당 노드의 Position 들에 대해 따로 외부화일로 두던지 (이는 추후 일종의 extractor tool 로 빼낼 수 있을 것이므로) 하는 아이디어가 떠올랐다.
----
To Do List 의 중요성
Extract 부분에 대해 너무 테스트의 단위가 크다고 판단, 이 부분을 처음부터 다시 TDD로 작성하였다. Bottom Up 스타일로 작은 단위부터 차근차근 진행하였다. 그런데 To Do List 를 작성을 안하니까, 중간에 잠깐 집중도가 풀어졌을때 똑같은 일을 하는 다른 메소드들을 만들어버린 것이다.
Top Down 으로 접근하여 해당 메소드가 필요해지는 일을 빨리 만들어내거나, To Do List 를 작성, Bottom Up 으로 접근한다 하더라도 궁극적으로 구현하려는 목표지향점이 명확하면 길을 헤맬 일이 없다는 것을 다시금 재차 확인하게 되었다.
4 (월): 영어 공부, XP Installed 한서 읽기
요새 영어공부를 어떻게 할까 궁리중, 대강 다음의 간단한 프로세스를 만들고 진행해보기중.

• technetcast 중 관심있는것을 알아듣건 못알아듣건 한 30분을 듣고
  
• 504 absolutely essential words 를 굉장히 느린속도로 이용하고 (요 4일간, 하루 시간당 단어 4개씩 나간다. 거기 있는 단어 뜻 보고, 구문을 읽은뒤, 한번 슬쩍 보고 구문 내용을 떠올리면서 원문을 재현해보기식으로 진행하다보니 꽤 느리다. 머릿속에서 영어로 좀 다르게 표현되어 저장되기도 한다.)
  
• 원서 책 읽기.
  

일단 요 3일간 진행 & 관찰중. 일단 몸으로 느껴본 관찰에 의하면,

• 영어 듣기 이후 영어 단어 연습 & 구문적기일때는 진행이 매끄럽다. 책을 읽기 전에, 알아듣진 못하더라도 technetcast 을 듣고 나면, 책을 읽을 때 리듬이 잘 잡힌다.
  
• 이전의 고등학교식으로 할땐 거의 하루 나가는 단어가 20개가 넘어서.; 하지만, 지금 4개 나갈때엔 확실히 재미도 있고, 해당 상황에 대해 콩글리쉬라마 머릿속에 영어문장이 만들어진다. 이에 대해선 3일정도 더 관찰필요. 암튼 장점/단점은 이해도 : 속도. 일단은 난 전자를 택하려 한다. 어차피 잘 못하는 녀석이니까 뭘 하든 효율 떨어지는건 당연하다 생각하기 때문에.
  
• technetcast 를 왜 여지껏 제대로 안이용했을까. Ron 아저씨랑 Bob 아저씨, Martin Fowler 라는 사람의 목소리를 듣게 되었군. 내용은 듣고 난 뒤엔 제대로 기억나진 않지만. (영어로 들었는데 기억을 재생해서 요약하려니, 영어 요약을 해본적이 없는 관계로 머릿속에선 한글로의 번역작업이 필요하다. 영어로 사고가 가능하다면, 아마 머릿속에선 영어로 요약할거고..) 일단 마음을 비우고 일주일정도 들어볼까.
  

개선안 궁리

• 영어 듣기에 대한 받아쓰기 자체를 먼저 연습해보는것이 순서일 것 같다. technetcast 중 10분짜리 짧은 인터뷰에 대해 받아쓰기 연습을 해보는건 어떨까. (단, 맞는지를 확인할 스크립트가 없는게 단점이군)
  
  • 영어듣기 연습은 이전에 친구가 영어공부 도와줄때 했었던, 노래가사 받아적기를 하는게 틀렸는지 확인하기도 편하고 재미있을 것 같다.
    
• 나머지들은 일단 계속 실험 & 관찰.
  

XP Installed 를 한서로 다시 정독을 했다. 영어로 읽었을때 써먹으려는 부분에 대한 대강의 내용 파악위주로 읽어서 그런지, 이젠 추정 부분 같은 것도 눈에 들어오는. 이런.
암튼, 계속. 설익은 머리를 위해. (갈수록 일지 형식이 3FS 에 안맞는군)

31 (목): YoriJori Pair
VPP 로 진행. 한동안 손놓고 있어서 개인적으로 약간 걱정이 앞섰는데, 응주씨가 Pair 를 잘해주었다. 프로젝트 참여도가 가장 높아서 그런지 모르겠지만, 할 일에 대해 즉각적으로 해결책을 생각해내는 모습이 정말 대단했다. 2시간동안의 작업을 시간흐른지 모른채 즐겁게 진행했다.
Editplus 로 VPP 진행하는 한쪽창에 to do list 를 적었는데, VPP 인 경우 한사람이 todolist 를 적는 동안, 드라이버가 코드를 잡지 못한다는게 한편으론 단점이요, 한편으론 장점 같기도 하다. 일단은 궁리.
특정 팀원과의 토론이 필요한 Task 외엔 별다른 어려움 없이 잘 진행되었다. Virtual Pair Programming 에서도 VIM 단축키들을 배웠다.; ctrl + v, shift + v 몰라서 매번 할때 Help 뒤졌다 까먹고 그랬던것 같은데, 제대로 익힐듯 하다.
----
Conceptual Integrity 에 대해 찾아보던중 꼬리에 꼬리를 물고 논문을 보다가 의외의 글을 보게 되었다.
http://www.utdallas.edu/~chung/patterns/conceptual_integrity.doc - Design Patterns as a Path to Conceptual Integrity 라는 글과 그 글과 관련, Design Patterns As Litmus Paper To Test The Strength Of Object Oriented Methods 라는 글을 보게 되었는데, http://www.econ.kuleuven.ac.be/tew/academic/infosys/Members/Snoeck/litmus2.ps 이다. 디자인패턴의 생성성과 관련, RDD 와 EDD 가 언급이 되는 듯 하다.
29 (화): 화이트헤드과정철학의이해 읽기 관련.
공부라는 것에 대해 머릿속 생각을 정리 할땐 꼭 손에 잡히는 책이 이성의기능 과 화이트헤드과정철학의이해 이다. (같은 책만 잡으니까 위험한건지도 모르겠다.) 요 사이 뭔가 머릿속이 허전하다. 뭔가가. 함정이 있는 듯한.
21, 22, 23 (월, 화, 수): Freechal Album Grabber 작성중.
아는 사람으로부터 부탁을 받아서 작성중. 이미 프리첼 게시판 백업 프로그램은 제로보드나 이지보드, 드림위즈 등에서 만들어졌는데, 앨범/자료실 추출은 아직 이루어지지 않았나 보다. 뭐, 조금있으면 나올 것도 같은데.. 그냥 개인적으로 연습겸 만들어보게 되었다.
Python 이용. 적당히 TDD 와 중간 UP Front를 섞었다. (CRC와 UML을 이용) 거의 정규표현식이나 find 등을 이용한 스트링 파싱 노가다급이지만, 하루 작업치곤 생각보다 많이 나간 것 같다.
1차적으로 CRC 를 이용하여 간단한 Conceptual Model 을 만든뒤, TDD 로 개개 모듈을 작업했다.
중간 개개의 모듈을 통합할때쯤에 이전에 생각해둔 디자인이 제대로 기억이 나지 않았다.; 이때 Sequence Diagram 을 그리면서 프로그램의 흐름을 천천히 생각했다. 어느정도 진행된 바가 있고, 개발하면서 개개별 모듈에 대한 인터페이스들을 정확히 알고 있었기 때문에, Conceptual Model 보다 더 구체적인 Upfront 로 가도 별 무리가 없다고 판단했다. 내가 만든 모듈을 일종의 Spike Solution 처럼 접근하고, 다시 TDD를 들어가고 하니까 중간 망설임 없이 거의 일사천리로 작업하게 되었다.

• TDD의 테스트들은 마치 모래주머니 같다. 묵직한 느낌을 주면서 프로그래밍 한 것들을 이해하게 하니까. 그리고, 갈수록 느끼는 것이지만, 테스트 없는 리팩토링은 정말 상상하기 어렵다. 요새는 중간중간 테스트를 작성하지 않는 코드들도 이용하고 있다. 조심스럽긴 하지만, 모듈의 복잡도,중요도에 따라 적당히 골라쓸 수 있을 것 같다.
  
• 요새들어 다시금 느끼지만, vi 로 파이썬 프로그래밍 하는게 가장 편한것 같다. cygwin 을 쓰니까 윈도우건 ZP 계정이건 작업스타일이 똑같아서 좋다. 그리고, command 위주의 작업환경은 내가 하려는 일에 대해 명시적으로 생각하게끔 하는 효과를 주는것 같다. 단점에서오는장점이랄까.
  
• 3일 코드 생산량 691 라인. 테스트 코드 245라인인중.
  
• 예전 PHP 프로그래밍 할때 맨날 제로보드 소스보면서 욕했는데 -_-; (보고 배울 소스 아니다 둥둥, 왜 스킨제작하는 사람들이 소스 수정하여 기능들을 만들어내야 하는가 등등 -_-.. 디자인적으로 그리 보고 배울 것이 아니라고 생각했기 때문. 그냥 노가다 코드라고 생각.)
  

근데.. 자기 학교수업 들으면서 수많은 사람들의 사랑을 받는 버전 4.0 이상을 바라보는 프로그램 만드는게 어디 쉬운일일까. 디자인 훌륭하고 깔끔한 코드를 만드는 것 말고 할일은 많다. 더 중요한, 근본적인, 자기가 하려고 하는 일의 목적은 무엇인가. WorseIsBetter

• 약간 아쉬움: 펄매니아 (http://www.perlmania.or.kr/PDS/pds.pl?mode=view&num=38) 쪽 활동하시는 분이 먼저 겔러리 지원기능까지 만들었다; 스트링 처리에 대해 펄쪽 개발자가 손이 더 빠른건가.. 흑; (물론 좀 널럴하게 작업한것도 있지만. -_-)
  

17, 18 일 (목, 금): TDD 기사 진행.
MMM 에서의 '프로그래머의 낙관주의'가 떠오르는. -_-; 전날 기사쓰다가 졸려서 잤는데, 금요일 아침먹고 탈이 나서 아주 주금이다. 사람이 하는 일에 대해서 이유없는 낙관주의는 정당화 될 수 없다. -_-; 오늘 하루종일 토할 것 같은 느낌때문에 죽을 지경인중.;

• 이것도 병인지 모르겠다. --a 세미나 날짜 다가올때 밥먹다 죽겠는 지경이나, 기사 마감날짜 임박하니 죽겠는 지경이나. 어디 정신과 치료라도 받아야겠다. -_-a (무의식적으로 책임강박관념증이라던지, 스케줄관리미숙으로인한신경압박증 기타등등 군시렁군시렁)
  
• 스케줄 관리는 확실히 미숙했다. 지난번 기사 쓸때는 Pair 였었기 때문에 비슷한 시간을 할당해서는 곤란했다라는 생각중. 오히려 1.5배 이상을 잡고 재빠르게 진행했어야 했건만. 결단을 내리는 속도가 느리다. 빨리 얻을건 빨리 얻고, 빨리 버릴건 빨리 버려야 하겠건만.
  

16 일 (수): TDDBE 다시 정독. 기사 진행.
TDDBE를 PowerReading 에서의 방법을 적용해서 읽어보았다. 내가 필요로 하는 부분인 '왜 TDD를 하는가?' 와 'TDD Pattern' 부분에 대해서 했는데, 여전히 접근법은 이해를 위주로 했다. WPM 은 평균 60대. 이해도는 한번은 90% (책을 안보고 요약을 쓸때 대부분의 내용이 기억이 났다.), 한번은 이해도 40%(이때는 사전을 안찾았었다.) 이해도와 속도의 영향은 역시 외국어 실력부분인것 같다. 단어 자체를 모를때, 모르는 문법이 나왔을 경우의 문제는 읽기 방법의 문제가 아닌 것 같다.
요새 Summary 할때의 느낌이 참 좋다. 책을 씹어먹는다는 느낌이 드니까. 속도가 느리게 나오더라도. 한동안은 이 리듬으로. 조금씩 올리기 노력노력.
14 일 (월): TDD 기사작성 Start, 일주일 할일 설정.
어제 다이어리 셋팅한 것을 이용하고, XP 에서의 Story 정리방법을 약간 적용하였다. 아직 각 Story 에 대해서 Task 를 안나눴기 때문에, 일단 좀 더 할일들에 대해 구체적인 서술이 필요하다.
아침 기상시간 7시. To Do List 에서 작은 일들에 대해서는 깔끔하게 처리. 단, 약간 단위를 크게 잡은 일들에 대해서 제대로 처리를 못하였다. (2-3시간 걸릴 것이라 생각되는 일들) 차라리 이 일들을 1시간 단위 일들로 더 쪼갰었으면 어떠했을까 하는 아쉬움이 든다.
학교에 도착하고 난뒤 페이스를 제대로 유지못했다. 학교 도착 이후 5시간에 대해서 제대로 활용을 못했다. 일을 시작하기 전에 계속 망설였다. 망설임을 줄이려면 일을 좀더 명확하게 나누었어야 할건데. 암튼.
13 일 (일): 다이어리 셋팅, 컴퓨터고전스터디/20021013
다이어리 셋팅을 하면서 꼭 필요한 기능 & 빼도 상관없는 기능들 궁리중.

• To Do List 에 대해서 Layering 이 필요하다 - 전체지도 : 부분지도 랄까. XP 라면 UserStory : EngineeringTask 를 이야기할 수도 있겠지. EngineeringTask 수준의 경우 Index Card 가 더 편하긴 한데, 보관해야 할일이 생길때 문제다. (특히 2-3일로 나누어서 하는 작업의 경우) 이건 다이어리 중간중간에 껴놓는 방법으로 해결예정. (구멍 3개짜리 다이어리용 인덱스카드는 없을까. -_a 평소엔 보관하다 필요하면 뜯어서 쓰고; 포스트잇이 더 나을까.)
  
• 개인 사색을 쓸 공간 부족 - 버스에서 중간중간 떠오르는 단상이 아쉽다. (이는 요새 3 x 5 인덱스카드를 충전(?)하지 않은게 문제인듯 하다.)
  
• WPM 로그 작성 - 주로 연습장에 Summary 를 하는데, 측정데이터를 모으기가 어렵다. Summary 노트를 따로 만드는건 그리 원하지 않고. (Summary 내용을 보는 것보단 Summary 하면서 회상작용을 하는게 더 의미있다고 생각하기에) 이건 그래프를 그리는 게 더 쉬울 것 같다. 그래프는 처음 표만 만들어두면 표시하는데 1분도 안든다는 점에서. 그리고 그래프는 모눈속지 1개만 쓰면 되니까.
  

Uninstall & Install
현재 다이어리 내 인스톨된 시스템.

• 한달 할일 - 전체중 '일정이 정해진 행위' 에 대해 유효하므로 놔두기
  
• 하루 할일 - 매일 아침. 또는 그 전날 작성하기.
  
• 기상 시간 체크 그래프 - 하루 1분 이용. 아직 '개선' 단계까진 가지 못했지만, 일단 계속 체크용.
  
• 낙서장 - 이녀석은 필요없을듯. 아이디어 궁리할때는 차라리 연습장이 더 편하니까. 차라리 Index Card 나 포스트잇으로 쓰고 중간에 붙이는게 더 유연한 방법이라 생각한다.
  

데이터 중복되는 것 삭제하고, 이전 로그들 정리하고.. 이로서 다이어리 두께 2/3 으로 줄이는데 성공.
아직은 필요한 시스템만 Install 하는 목표에 충실하도록 노력하자. Refactoring. 필요한만큼만 .
----
컴퓨터고전스터디/20021013
발표준비할때 책을 3번정도 읽고, 두번을 노트요약정리했다. 나름대로 이해했다고 생각했는데, 중간에 대강 이해한부분에 대해 내 생각을 덧붙여서 이야기하는 우를 범했다. 일단은 텍스트에 충실해야 했는데, 텍스트에 충실하기 위해서는 글을 100% 완벽하게 해석해서 읽는게 첫 단계이리라. 이성의기능 에서의 김용옥의 자세를 다시 생각해야봐야겠다.
텍스트 해석을 제대로 안할수록 그 모자란 부분을 내 생각으로 채우려고 하는 성향이 보인다. 경계가 필요하다. 왜 PowerReading 에서, 모르는 단어에 대해서는 꼬박꼬박 반드시 사전을 찾아보라고 했는지, 저자 - 독자와의 대화하는 입장에서 일단 저자의 생각을 제대로 이해하는게 먼저인지, 오늘 다시 느꼈다. 느낌으로 끝나지 않아야겠다.

• '이해했다' 로 느끼는 것과 그걸 설명하기 위해 완성된 글로 정리하고, 그걸 말로 하기 위해서 해야할일은 다른 것 같다.
  
• Opening Question 이 부족했다. 개인적 경험과 결부시켜서 질문해볼 수 있었을건데. 아는 선배 (뭐 뻔하지만) 가 대화를 할때 정말 잘하는 기술중 하나가 적절한 질문법이다. 분석이 필요하다.
  

12 일 (토): PosterAreaBy1002 , 2번째 문제.
이번에는 TDD 로 하되, TDD쪽보다는 PBI 에 더 주안을 두고 했다. 이런 수학공식 구하기 스타일의 문제의 경우는 StepwiseRefinement 와도 같은 PBI가 굉장히 유용하다는 생각이 든다. 첫번째 문제 풀때 코드-테스트-재정의 식으로(중복보다는 재정의에 더 신경썼기 때문에) 넘어가는게 거의 1분을 넘어가지 않았다.
처음에는

~cpp 
int calculateVisiableBoxSize 
        (int x1,int y1, int x2,int y2, int x3, int y3, int x4, int y4) { 
         
        return 14; 
} 

void testCalculate () { 
        assert(calculateVisiableBoxSize(2,3,5,8,4,7,6,10) == 14); 
}

void test() { 
        testCalculate(); 
} 

로 시작하여.

~cpp 
        int boxSize=15; 
        int coverBoxSize=1; 
         
        return boxSize-coverBoxSize; 

~cpp 
        int boxSize=(5-2)*(8-3); 
        int coverBoxSize=1; 
} 

~cpp 
        int boxSize=(5-2)*(8-3); 
        int coverBoxSize=(5-4)*(8-7); 

~cpp 
int getCoverBoxSize     (int x1,int y1, int x2,int y2, int x3, int y3, int x4, int y4) { 
        return 1; 
} 
.
.
       int boxSize=(x2-x1)*(y2-y1); 
       int coverBoxSize=getCoverBoxSize(x1,y1,x2,y2,x3,y3,x4,y4); 

여기서 다시 문제를 나누었다. Cover Box. 즉 빼야 하는 값을 구하는 문제만으로 포커스를 좁혔다. 너무나도 명백하게 보이기에. 그리고 테스트 케이스를 증가시켜 나가면서 코드를 늘려가는 식으로 만들었다.

~cpp 
int getCoverBoxSize     (int x1,int y1, int x2,int y2, int x3, int y3, int x4, int y4) { 
        return 1; 
} 

void testGetCoverBoxSize() { 
        assert(getCoverBoxSize(2,3,5,8,4,7,6,10) ==1); 
} 

뭐. OO 로 할 수도 있었지만 (아마 Box Object 를 만들고 두개의 intersect box 를 create 한뒤, 각각의 box 에게 area 를 물어보는 식이 되었을듯.) 빠른 값이 나오는게 일단 촛점을 맞춰보았다.
단, OO Style 의 코드에 대해서 PBI 를 너무 강조하다보면 StructuredProgramming 에 더 가까운 OO 가 되지 않을까 한다. PBI는 TopDown 이므로.
두번째 문제에 대해서는 STL 에 익숙하지 않아서 시간이 1시간 18분이 걸렸다. -_-; 앞의 문제가 거의 20분 내에 끝난것에 비하면 꽤 오래걸린 셈인데. 처음 문제 이해는 굉장히 간단했고, 접근 방법도 문제 읽자 마다 2가지 정도가 보였다. 문제는 내가 permutation 을 구하는 알고리즘을 모른다는 것이였고, 직접 만들어야 했다. 뭐 그래도 별로 안어렵겠다 싶어서 TDD 식의 간단한 접근을 해 보았다. (헉, 소스를 학교에 두고 왔군. -_-;)
역시 접근은 TDD, PBI
대강 pseudo code 로 적으면

~cpp 
result = permutation("ab")
assertEquals(result[0], "ab")
assertEquals(result[1], "ba")

그리고 이에 대해서 구현하고 (가장 간단한건 바로 vector 에 ab,ba 를 넣는것) 테스트를 늘렸다. 한단계만 늘리고 바로 알고리즘이 나올 것 같았다.

~cpp 
result = permutation("abc")
assertEquals(result[0], "abc")

그리고 접근을 했는데, 너무 알고리즘적으로 접근하려고 했다. (재귀호출을 이용하는 식으로.. 거의 일반화식에 가깝게) 초반 10분정도를 그정도 써먹으니 너무 시간이 아까워서, 일단은 abc 자체만 통과하기 위해 노력을 했다.
그러면서 대강 다음의 코드 스타일이 나온 것 같다. (저 단계보다 더 작은 단계가 있었음. 선택이 a 하나만.)

~cpp 
permutation (str, selectable, position) {
   if (position == str.size() - 2) {
      vector<string> result
      result.push_back(selectable)
      reverse(selectable.begin(), selection.end())
      result.push_back(selectable)
      return result
   }
   for select in selectable:
      result.push_back(select)
      nextSelectable=removeFrom(selectable, select)
      subresults = permutation(str, nextSelectable, position+1)
      for subresult in subresults:
           .
           .
           .          
}

recursive 를 쓰는것일때 더 작은 단계를 밟는것은 여전히 편한 것 같다. (추후추가)
11 일 (금): TDD ClassifyByAnagram, 르네상스 클럽
아직은 나에겐 '~한 점에서 결국은 다 같다' 라는 말보다는 '~한 점에서 다르다' 란 말로 배울 수 있는게 더 많은 것 같다. 아는 선배는 '결국 SE 의 큰 틀 내에서의 범주로 놓고 보면 RUP나 XP나 같은게 아니냐' 식으로 이야기한다. 나는 XP의 다른점(지극하게 가벼운 곳부터 시작하여 필요할때 테스크나 스토리로서 추가하는)으로 장점을 얻고자 한다. 아는 선배는 TDD로 하건 뭘로 하건 결국 빠르게 좋은 프로그램을 만들면 된다고 한다. 나는 TDD를 끝까지 해봄(디버깅 툴로 돌리는 시간이 거의 0라는 점, 내가 제어할 수 있는 좋은 질문 & 좋은 답을 만들어내기)으로서 장점을 얻고자 한다. 아직까지는 守의 단계이라 생각하기때문에.
아직 守 를 해야 하는 단계 같은데, 섯부르게 離로 가기엔 아직 장점을 다 씹어먹어보지 못했다는 생각이 든다. 다만, 빨리 민감해져서 破와 離의 단계로 넘어갈 수 있기를 바라지만, 아직 나에겐 무식하게 공부해서 얻을 수 있는 장점이 더 많은 것 같다.

• 단, 離 의 단계에 있는 사람의 말은 'Target' 이다. 단, 같은 결론을 낼 필요는 없겠지.
  
• 하지만, 결국은 '내 이야기'를 해야 하겠지. 그리고, 터널 비전에 빠지지 말고 때가 될때엔 정확하게 문제를 인식할 수 있기를.
  
• 오늘 굉장히 빠른 속도로 XP를 흡수하려는 사람을 구경할 수 있는 기회가 되었다. 자기 생활 발전 계획에 대해 방법론을 적용한 것이다. 멋진 가로지르기라 생각.
  

----
여전히 守 의 단계를 못벗어나는것 같지만.
혹시 FakeIt & Refactoring 으로 진행이 가능할까 생각해보면서 처음에는 FakeIt & Refactoring 만으로 진행해보았다. 근데, FakeIt 을 하고 Refactoring 을 하려 할때 너무 재정의를 많이 하는 것 같아서 대강 넘어갔는데, 그랬더니 다음 테스트로 진행하기 너무 힘들었다. 알고리즘이 어느정도 보이려고 할때, 앞에서의 FakeIt 으로 유도된 코드들을 수정하는게 아니라 아에 뜯어야 할 것 같아서 망설여졌다.
결국 코드를 만들어가면서 '학습된' 코드 - 각 단어의 요소들 sort index 를 만들고 해쉬테이블을 이용하는 식으로 - 로 바로 팍 하고 진행했는데, 여전히 TDD 보폭이 크다는 생각이 드니 그리 기분이 좋지 않다. (단어들 요소 sort & hash 저장은 처음 개발할때부터 떠올랐던 아이디어여서..)

• 다시 시도한다면? 들어오는 값들을 근거로 일반화시키는 과정을 할 수 있을까..
  
  
  
• 개인적으로 드는 생각은, 중복을 줄이는 것 보다 의도, 의미가 분명하도록 코드를 짜는것이 순위가 더 높아야 될것 같다. (근데, 조금 겁이나는건, intention 의 우선순위를 높이다 보면 refinement 를 너무 깊게 들어가게 된다. 하지만 개인적으론 이것이 더 유용하다고 생각한다. 금방 중복되는 부분이 보이기 때문에.)
  
  PBI와 TDD를 잘 버무려서 적용해 보는 실험을 해보아라. 장점이 나름대로 있다. 단점은, 군더더기가 생기거나 완전히 포기하고 새로짜야 할 일이 종종 있다는 점. 내가 중요하다고 생각한 도메인 오브젝트가 사실은 필요없는 것인 경우가 많다. 시간이 나면 DDD도 공부해 보길. --JuNe
  


• HotShot을 돌려본 뒤, 가장 시간을 많이 잡아먹는 두 녀석에 대해서 군더더기가 되는 코드들을 삭제했다. 그러다보니, 퍽 하고 알고리즘을 더 향상 시킬 방법이 보였다. 뭐, 이것 고치고 난뒤 사람들 소스들을 보니 거의 비슷한 듯.
  
• Psyco 를 처음 설치하고 써보게 되었는데, 한 일에 비해 성능향상이 높아서 신기했다.
  
  psyco는 가장 바깥쪽 함수, 클래스만 바인딩해주면 해당 코드가 호출하는 다른 코드들은 직접 알아서 다 바인딩 해준다. 즉, main이라는 함수가 있다면 그것만 바인딩하면 프로그램 내의 모든 코드가 바인딩 되는 셈. --JuNe
  

----
요 일주일째 기상 시간 그래프 그리는중. 오늘 갑작스레 스코어가 높다.
요새 스케줄 관리에 실패하는 이유

• 아침시간을 잘 못 이용한다. 주로 밥먹고 신문을 보고 메일, 각 위키들 구경 이런식인데,
  
• 큰 일에 대해서 더 작은 일들로 To Do List 에 나누질 않았다. 요새는 스케줄 관련 정보를 통합관리하기위해 주로 다이어를 이용하는데, 셋팅을 다시해줄 필요가 있을듯.
  
  • To Do List 에 대해서 Layering 이 필요.
    
  • 아침에 반드시! 아침회의(?)가 필요. -_-;
    

개인적인 시간관리 툴과 책 읽기 방법에 대해서 아주아주 간단한 것 부터 시작중. 예전같으면 시간관리 책 종류나PowerReading 책을 완독을 한뒤 뭔가 시스템을 큼지막하게 만들려고 했을것이다. 지금은 책을 읽으면서 조금씩 조금씩 적용한다. 가장 간단한 것부터 해보고, 조금씩 조금씩 개인적 시스템을 키워나가기 노력중.
지금 일주일째 유지되는 아주아주 가벼운 시스템으로는

• To Do List - 이건 To Do List 에의 Layering 이 필요하다. 그리고 '시간에 구속되는 To Do' 에 대해서.
  
• 기상 시간 체크 - 그래프 꾸준히 그리는중. 이제는 분석 & 개선을 해볼 수 있을 것 같다.
  
• Reading - 따로 노트를 준비하진 않았고, WPM 수치가 지극히 낮긴 하지만. 20분정도 투자로 한번 진행 가능.
  

10 일 (목): SSH CVS Setting. MMM WPM 측정.
Tortorise 로 드디어 SSH 돌리기 성공!
MythicalManMonth 에 대해서 PowerReading 에서의 방법들을 적용해보았다. 일단은 이해 자체에 촛점을 맞추고, 손가락을 짚을때에도 이해를 가는 속도를 우선으로 해 보았다.
읽는시간 10분, 요약 5분, 요약보충 7분정도. WPM 속도 측정을 떠나서, 책을 읽는데 리듬이 생기는 느낌이 든다. (Chapter 하나에 대해선 네번에 걸치니 끝이 났다. 이해도도 꽤 만족하는중.)

• WPM 은 36.3 - 60%, 60 - 70%, 70 - 65%, 56 - 60%, 67 - 65% . 아직 100 을 안넘긴 하다 -_-; 하지만, 글에 대해 책을 안보고 정리를 할 수 있을정도의 리듬을 탄 것 같아서 나쁘진 않았다. 일단은 이해도가 더 중요하다고 생각하기에.
  
• 속도와 이해도가 꼭 반비례하는건 아닌것 같다. 영어의 리듬을 제대로 탈때 이해도 제대로 되었다.
  
• 모르는 단어의 경우 단어의 빈도를 봐서 사전을 찾을때와 나중에 사전을 찾을때를 구분하는것도 좋은 것 같다. 사전을 뒤적거리는데에 일종의 Context Switching 이 일어난다고 할까.
  

MMM 에서의 제목에 해당하는, 그리고 참으로 자주 인용되는 브룩스 법칙이 나왔다. Communication 비용, 분업화 되기 힘든 일에 대한 비용 문제. ExtremeProgramming 의 관점으로 다시 바라보고 비판하고 싶지만, 아직은 고민하고 얻어내야 할것이 더 많기에.
MMM 에서의 비유들은 참 멋지단 생각이 든다. 저번 Tar Pit 도 그렇지만, 이번 오믈렛의 비유 또한 정말;
8,9 일 (화, 수): 공연보러 가기. 개인정리.
봄여름가을겨울, 불독맨션, 허벅지밴드 등을 보다.
개인적으로 신기한 사람들은 베이스연주자이다. 리듬악기일까 멜로디 악기일까. 하지만, 그 둔탁하고 낮은 소리는 드럼소리만큼 몸을 울리고 지나간다.
봄여름가을겨울 마지막 부분 연주할때, 베이스와 드럼연주가 점점 속도를 올리더니 날라다니고, 그와 함께 기타가 같이 연주를 타고 무아지경으로 들어가는 모습을 보면서, 감동.감동;
공연장에서의 음악즐기는법과 평소시의 음악즐기는법은 다를 필요가 있는것 같다. 달려요~!
에너지가 넘친다. 사운드가 넘치는 곳, 사람이 넘치는 곳을 보면.
----
Y 로 중앙의 UBS 방송장과 입구쪽의 한총련 모임을 보면서 드는 묘한 생각이란.
----
개인적으로 '만일 내가 책을 쓴다면?' 하는 식으로 할매동산 올라가서 바람쐐며 글 정리 해보기.
글을 정리하면서 '실제 내 행동은 이정도로 질서정연하지 않는데' 하는 생각이 드니, 글을 쓰고 싶지가 않아진다. 한편으로는 글을 써 나가면서 행동을 할때엔, 내 행동을 천천히 관찰하고 행동을 하는 것 같은데.
보통 학습은 '책을 읽을때' 그때보단 '묵혀두었던 기억을 끄집어낼때' 이루어지는것 같다. 또는 '행동으로 끄집어낼때'.
----
슬슬, 다시 '가공된 기억'모으기 시작. 모든 것을 다 표시하는 아날로그보다는, 제어할 수 있는 디지털을 원한다.

• XP Workshop
  
• ProjectPrometheus
  
• 프로그래밍잔치
  
• Chaos, MIB;
  
• 르네상스클럽
  

7일 (일): 책상정리.
자주 느끼지만, Data, Information, Knowledge, Wisdom. 정보를 소비하고 재창출하지 않으면. 아 이넘의 데이터들 사람 피곤하게도 하는군;
6일 (토): 달리기.
집에서부터 종합운동장까지 25분 논스톱 뛰기.
뛰는 중간 속도를 유지하기 위해 거의 비슷한 속도로 달렸다. 단, 옆에 날 추월한 사람을 보니 경쟁의식이 생겨서 그사람 추월하느냐고 약간 오버한거 빼곤 뭐..;

• 배운점 : 중요한건 호흡의 리듬. 수영의 경우 리듬 못맞추면 숨도 못쉬지만. 속도를 낼때의 호흡리듬과 휴식을 위한 리듬이 다르다.
  
• 전날 집에 못들어가서 그런지 (어흑, 64-1 야간버스는 1시 이전에 끊긴다. 치사하게.. 916번은 2시되도록 10대도 넘게 지나다니건만 쩝) 되돌아올때는 논스톱으로 뛰지 못했다.
  

5일 (금): RenaissanceClub20020705 .
이전에 나에게서 술자리 등에서 Java 기술이 어쩌네 마소 기사가 어떠네, MT 가서 IMT 2000 이 어떠네 하는 이야기를 할 수 있던 곳은 ZP 밖에 없었다. 이번에 하나 더 생길것이라는 기대감.
4일 (목): ScheduledWalk/석천 완료작업.
처음 고려할때부터 글쓰기를 고려하고 작성한 문서는 아니여서; (그냥 소스만 주욱 변화과정을 보이려고 했다는.) 차라리 처음부터 프로그래밍할때마다 바뀐부분에 대해서만 과정을 적어나갔더라면.

• 위의 일에 너무 시간을 많이 끌어서 다른 일들을 할 시간이 적어져버렸다. 시간관리시간관리.
  
• 오늘따라 몸이 피곤함을 괭장히 많이 느꼈다. 파워프로그램이 필요하다;
  

3일 (수): ProjectPrometheus/Journey
1일 (월): ScheduledWalk/석천
StructuredProgramming 을 '의식적으로', '열심히', '끝까지' 해본 첫번째 예제가 아닐까. 전에 수치해석 숙제할때엔 StepwiseRefinement 스타일이 유용하긴 했지만, 지금처럼 의식적으로 하진 않은 것으로 기억한다.

• 만일 영어권에서 살았던 사람이라면 더 빨리 만들었을텐데. 일상 쓰는 단어나 프로그래밍때의 함수 이름이나 똑같이 지을테니. 흐음. 히구;
  

25 ~ 28일 (화~금): ObjectOrientedProgramming 세미나 준비기.
세미나 자료 준비전 창준이형으로부터 여러 조언들을 들었었다. 'Sub Type 과 Sub Class 에 대한 구분에 대해서 설명했으면 좋겠다', 'OOP 를 하면 왜 좋은지 느낄 수 있도록 세미나를 진행하면 좋겠다', '문제 해결에 대한 사고 과정을 보여줄 수 있으면 좋겠다' 등등. 구구 절절 생각해보면 참 일리있는 이야기들이였다. 개인적으로도 세미나 준비하는 가장 고학번이니 만큼 잘 하고 싶었고.
Sub Type 과 Sub Class 에 대해 자료를 뒤지던중 희상이와 메신저에서 대화하면서 '아.. 저런 점에서 설명을 하시란 뜻이였구나' 하며 앞의 조언들에 대한 중요성을 인지했다.
"세미나날 언제니? 나도 참석하도록 하지."

"헉; 하..하.."

"왜? 싫니?"

"아.. 아뇨. 하하하;"

"웃는것 보니 좋은가 보구나. ^^"

"아.. 우..웃음엔 많은 의미가 있곤 하죠. 하..하하;"

하..하하; 그냥 하던대로 준비했다간 깨지겠구나; 약간의 부담을 가지고. 음음. - -;
세미나 준비
음.. 그러고 보니 나는 왜 OOP를 하는거지? 개인적으로 처음 클래스를 구현하면서 찾아낸 장점은 다음이였다.

1. Global 변수를 쓰긴 싫고, 안쓰자니 불편하고, Global 변수급당 객체하나씩이면 편하겠다. 하는, 테크닉에 기반한.
   
2. Visual C++ 에서 클래스로 만들어쓰면 인텔리센스 기능 지원을 받아서 프로그래밍 하기 편하다는.
   

즉, OOP 식 사고에서의 장점이 아닌, 기존 개인스타일의 프로그래밍중에서의 장점이였다. 스스로 생각하기엔 OOP라 생각했던 것들도, 알고보면 OO의 언어를 쓸 뿐, OOP가 아니였었던 것이다. 세미나중 'OOP 로 하면 뭐가 좋아요?' 라고 질문할때 저렇게 답할 수는 없겠지.
다시 'OOP는 왜 하는가' 에 대한 질문을 하면서 내가 플밍하는 방법에 대해 생각하게 되었고, 내가 프로그래밍을 하면서 유용하게 이용했었던 사고습관(일련지는 모르겠다 정확하게는;) 에 대해 생각하며 OOP 세미나 스케줄 1차 초안을 만들어보기 시작했다.

1. 무엇을 할것인가 : 어떻게 할 것인가의 관점. 나는 초기에 학교 전공 중 Science 와 Engineeing 의 기준을 저것으로 나누었었다. 내가 '무엇을 공부할까?' 라고 질문을 할때는 앞의 분류를, '어떻게 할것인가?' 라는 질문을 할때는 뒤의 분류를. 바로 적용되진 않겠지만, "OOP 는 '프로그래밍을 어떻게 할것인가?' 라는 분류에 속한다" 라고 말해주면 머릿속에서 분류하기 편할것이란 생각을 했다.
   
2. 객체지향프로그래밍 과정 - OOP를 하면서 나는 기계로 만들어진 엔진을 떠올리곤 한다. 볼트, 너트, 실린더, 크랭크, 배기밸브... 저것들을 닦고 조이고 기름쳐가며 만들어가기. 이 부분을 어떻게 설명할까 하면서 '차라리 벡터 그래픽 툴을 만져보게 할까' 하는 생각도 해봤었다. 중간에 Python Interpreter 를 만져보게 하는것이 좋겠다는 생각을 했었고, 창준이형과의 전화중 더욱 더 확신을 가지게 되었다.
   
3. 프로그래밍에 대한 전반적 접근 - 문제를 Top Down 으로 나눈다는 관점. 2학년때 DirectX 로 슈팅 게임을 만들때 가끔 상상하던것이 석고로 만든 손을 조각하는 과정이였다. 조각을 할때엔 처음에 전체적 손 모양을 만들기 위해 크게 크게 깨 나간다. 그러다가 점점 세밀하게 조각칼로 파 나가면서 작품을 만들어나간다. 이런 식으로 설명할 수 있겠군 하며 추가.
   
4. Stepwise Refinement - 이번에 전과한 사람중에 수학과가 있었던것 같다. 그런 사람들에게 수학문제에 대한 전개과정과도 같아보이는 프로그래밍 방식을 보여주면 좋겠지 하는 생각에 하나 골라보았다. 개인적으로 수치해석 숙제를 할때 유용하게 써먹었던 방법이기도 해서.
   

그리고 중간 실습. '아.. 문제 골라야 할텐데...' 제일 멋져보이던것은 전에 기정이형이 예로 들었었고, 선우형이 문제로 만들었었던 스타크래프트였다. 사람들에게 가장 친숙한 게임이니 연관성을 찾기엔 좋으리라. 하지만, 그 계층도를 생각해보면 후배들이 만들 수 있을정도가 아니다. 폭을 줄여야지 했다가 문득, 파이썬 인터프리터로 객체 단위 작업을 하는 예로 써먹으면 좋겠다는 생각이 들었다. 오.. 우리는 매일 매일 객체를 가지고 노는구나; 문제풀기를 하려고 했다가 튜토리얼로 바꾸었다.
세미나때 걸릴 시간을 대강 잡아보니, 다음날 6시까지 거의 Full 로 뛰어야 했다. 우.. 내가 좀 너무했나 하는 생각이 들긴 했지만, 일단은 중요하다고 생각한 개념들을 빼먹기는 싫었다.
그리고 초안을 창준이형에게 보여드리고 조언을 구했다.
23 ~ 29 : 데블스캠프2002/진행상황
3,4,5,7 : ProjectZephyrus/ClientJourney
1일 (토):

• DesignPatterns 연습차 간단하게 그림판을 구현해봄. 처음 간단하게 전부 MainFrame class 에 다 구현하고, 그 다음 Delegation 으로 점차 다른 클래스들에게 역할을 이양해주는 방법을 써 보았다. 그러던 중 MFC에서의 WinApp 처럼 Application class 를 SingletonPattern 스타일로 밖으로 뺐었는데, 계속 Stack Overflow 에러가 나는 것이였다. '어라? 어딘가 계속 재귀호출이 되나?..'
  

문제는 다음과 같은 코드에 있었다.

~cpp 
Application.java
    public static Application getInstance () {
        if (theApp == null) {
            theApp = new Application ();
            theApp.init ();
        }

        return theApp;
    }

    public Application () {
        toolManager = new ToolManager ();
        mainFrame = new MainFrame ();
        mainFrame.setSize (640,480);
        mainFrame.show ();
    }

MainFrame.java
    public JMenu _makeToolMenu () {
        JMenu menuTool = new JMenu ("Tool");
        toolActionListener = new ToolActionListener ();
        Enumeration toolList = Application.getInstance().getToolsList();
        String toolName;
        JMenuItem toolMenuItem;

        while (toolList.hasMoreElements()) {
            toolName = toolList.nextElement().toString();
            toolMenuItem = new JMenuItem (toolName);
            toolMenuItem.addActionListener(toolActionListener);
            menuTool.add(toolMenuItem);
        }

        return menuTool;
    }

즉, Application Class 의 인스턴스가 만들어지기 위해선 MainFrame 클래스가 완성되어야 한다. 그런데, MainFrame 에서는 Application 의 인스턴스를 요구한다. 그렇기 때문에 Application의 getInstance를 호출하고, 아직 인스턴스가 만들어지지 않았으므로 또 getInstance 에선 Application 의 Class 를 새로 또 만들려고 하고 다시 MainFrame 클래스를 생성하려 하고.. 이를 반복하게 되는 것이였다.
결국 다음과 같은 코드로 해결을 했다.

~cpp 
   public static Application getInstance () {
        if (theApp == null) {
            theApp = new Application ();
            theApp.init ();
        }

        return theApp;
    }

    public Application () {

    }

    public void init () {
        toolManager = new ToolManager ();
        mainFrame = new MainFrame ();
        mainFrame.setSize (640,480);
        mainFrame.show ();
    }

Class 의 역할들을 Delegation 으로 다른 클래스들에게 위임시켜주면서 썼던 패턴이 대강 이랬던 것 같다.

• SingletonPattern - Application Instance를 Global 객체로. 근데, 이는 일장일단인것 같다. 잘못하면 Application 중앙집중체제가 된다. Application 내에서 Delegation하는 객체들이 많은데, 그 덕에 Application 이 너무 중간 메세지 전달역할로만 작용하는것 같다. 뭐, FacadePattern 인양 된다면 모르겠지만. 이건 코드 커지고 난 뒤 두고볼 일인것 같다.
  
• StatePattern - Tool 선택에서 이용. 현재 Tool을 추가하려면 1. Tool 상속. 2. interface 구현. 이다. 실질적인 기능을 하려면 현재 코드에선 CommandPattern 과 붙어야 할듯.
  

작업시간은 그리 빡빡하게 하지 않아서 5시간쯤 걸렸다. 하지만, 중간 무엇을 해야 할지 몰라서 망설인 시간은 별로 없었던 것 같다. (주로 중간 MP3 듣기, 웹서핑 등 다른짓들을 해서 오래걸렸다는;)

24일 (금), 27일 (월):

• ProjectZephyrus 모임. ProjectZephyrus/ClientJourney
  

19일 (일):

• 프로그래밍파티, ProgrammingPartyAfterwords
  

10일 (금):

• ProgrammingContest , IpscAfterwords
  

8일 (수):

• SE 시간에 CBD (CBD & Business 라는 측면. 3강 연속) 를 배울때마다 느끼는 점이 있다면, 다른 공학 (기계, 전자, 건축) 들의 개념들을 이용하여 Software 를 Hardware 화 시킨다는 느낌이 든다. 늘 '표준' 을 강조하시는 교수님. 컴포넌트쪽과 QA쪽에서 그 이름이 빠질 수 없는 교수님이시기에, 그리고 평소 수업때 자신의 나이만큼 연륜있으신 말씀을 하시기에 마음이 흔들리지 않을 수 없고, 결국 '톱니바퀴들 중 하나'라는 생각을 하고 나면 약간 한스럽다. 그래서 교수님께서는 늘 'Domain Expert' & 'Speciality' 를 강조하시지만.
  
  • 이때쯤 해야 할 질문이 '그 다음에 할일은?' 이건만. 잠시만 보류.
    
• Wiki 설명회때 느낀 JuNe 선배에 대한 분석 (AnalyzeMary) - 어떻게 하면 별 관심없어해보이는 사람들로부터 질문을 유도해내고 반응을 끌어올 수 있을까? 정말 신기한 경험이였다. 처음에는 그냥 별 생각없어 보이던 사람들도 설명의 Turn (설명 내용별로 약간약간 단락이. 중간 Feedback 을 살피고, 다시 새로운 설명을 하는 모습) 이 증가함에 따라 스스로 '질문' 을 하게 되었을까.
  
  • 목소리 톤 & 속도 - 이는 사람들의 집중도에 어느정도 영향을 끼친다고 생각. 또한 이것은 자신감의 척도인것 같다. 자신감없이는 적절한 속도조절을 못하고, 목소리 크기를 알맞게 조절할 수 없다.
    
  • 내용의 접근방법 - 질문을 던지고, 내용을 이야기하고, 또 질문을 던져보고... XP의 TDD를 보는 것 같은데, 이 또한 방법인 것 같다. Feedback 을 살핀다는 점에서.
    
  • 다양한 경험 - 내용을 만들어내려면, 그만큼 경험이 필요하기에. 성장계단이라던가, 자신이 '배운' 내용을 '적용' 해볼 수 있는 터로서 이용한다던가, Refactoring 과 프로그래밍 개발의 관점에서 설명한다던가 등등 (이것같은 경우 내용을 알고 있어도, 사람들의 레벨에 맞춰야 하기때문에 적절하게 꺼낼 타이밍을 맞춰야 할것 같은데. 이야기가 흘러가면서 페이지 구조조정, Refactoring 으로까지의 이야기흐름전개. 어떻게 흘러온걸까.)
    

4일 (토):

• 학교에서 레포트를 쓰기 위해 (ProgrammingLanguageClass/Report2002_2) 도서관에 들렸다. HowToReadIt 의 방법중 다독에 관한 방법을 떠올리면서 약간 비슷한 시도를 해봤다. (오. 방법들 자체가 Extreme~ 해보인다;) 1시간 30분 동안 Java 책 기초서 2권과 원서 1권, VB책 3권정도를 훑어읽었다. (10여권까지는 엄두가 안나서; 도서관이 3시까지밖에 안하는 관계로) 예전에 자바를 하긴 했었지만, 제대로 한 기억은 없다. 처음에는 원서와 고급서처럼 보이는 것을 읽으려니까 머리에 잘 안들어왔다. 그래서 가장 쉬워보이는 기초서 (알기쉬운 Java2, Java2 자바토피아 등 두께 얇은 한서들) 를 읽고선 읽어가니까 가속이 붙어서 읽기 쉬웠다. 3번째쯤 읽어나가니까 Event Listener 의 Delegation 의 의미를 제대로 이해한 것 같고 (예전에는 소스 따라치기만 했었다.) StatePattern으로의 진화 (진화보단 '추후적응' 이 더 맞으려나) 가 용이한 구조일 수 있겠다는 생각을 하게 되었다. (Event Listener 에서 작성했던 코드를 조금만 Refactoring 하면 바로 StatePattern 으로 적용을 시킬 수 있을 것 같다는 생각이 들었다. 아직 구현해보진 않았기 때문에 뭐라 할말은 아니지만.) 시간이 있었다면 하루종일 시도해보는건데 아쉽게도 학교에 늦게 도착해서;
  
  • 예전에 했었던 일이 MFC 책 한꺼번에 읽기였는데, 그때 이상엽씨 책 (bible, 2주완성, 5판 완벽가이드)이랑 Jeff Prosise 의 책 번역판을 같이 읽으면서 이상엽씨책의 장점과 Jeff 아저씨 (?) 책의 장점을 궁리했었었다. 한편은 실제 어느정도 VC++ Programming 을 하고 난뒤에의 Tip 들이라 한다면, 한편은 API Programming 을 섭렵하고 난 다음 MFC를 차근 차근 이해해나가는 과정을 설명한다고 해야 할까. MFC를 처음 하고 난뒤 '컴퓨터가했다 의 당혹감을 완벽가이드 앞부분 MFC Framework 설명과 Jeff 의 책으로 해결할 수 있었던 기억이 있다.
    

1일 (수):

• SE - UML. 미리 접한 내용이라 생각되어서인지 긴장감이 떨어졌다. 80-100 여장의 PPT를 1시간정도에 다 설명하시는 교수님을 보면 PL 시간과 천지차이다. (PL는 1시간에 6~12장;)
  
• Numerical Analysis Report 와 OS Report 를 하느냐고 거의 밤을 샜는데 ('거의' 인 이유는, 중간에 언제 잤는지 모르겠다는 점; OS 에 대한 Design 그린 종이가 있긴 한 것 보면 분명 OS Report 를 하는 중간이였던것 같은데; 이불도 잘 덮고 잔것 보면 신기하긴 하다;;) NA 숙제에 대한 Quality Management 에 대한 실패라고 해야 할까. 시간 조절을 하고 OS Report 에 시간을 더 투자할 방법이 있었음에도 불구하고 조금 아쉽다. 올해의 화두는 개인적 시간관리능력배양이 될것 같다. (99학번. 3학년이 되도록 이모양이니 부끄럽다;)
  
• Simple Design 에 대해서 내가 잘못 생각한 것 같다. Up-Front Design 자체를 구체적으로 들어갔을때 얼마나 복잡할 수 있는지도 모르면서 처음부터 Simple Design 을 논할수 있을까 하는 생각도 해본다. 생각해보니, 여태껏 내가 그린 전체 UML Class Design 은 거의 다 Simple Design 이겠군. -_-; (Interface 들 Method 이름도 결정 안했으니까.)
  
• 밀리는 To Read Later를 보면서 다시금 다짐을;
  

15일 (월):

• 수학공부 재개중. 극한 & 연속 & 미분 다시 보는중. 조금 급히 먹고 있어서 체할까봐 약간걱정됨. 수직선이 대수학과 기하학의 교차점이라는 말이 인상깊었다. (이 말이 나오기 전에 다른 사람들의 정리가 여러개 나왔다. 실수계와 수직선이 그 순서에 맞게 1:1매칭이 된다는 것부터. 아. 세계와 세계가 연결되기란 쉽지 않도다.)
  
• 내가 시간 계산에 그렇게 투철하지 못하다는 점 발견. 다른 사람 Pair 할때는 걸린 시간체크 열심히 했건만, 정작 내가 쓰고 있는 시간을 제대로 기록하지 못하였다. (지금 1시간정도를 계획에 없는 일로 오버중;;)
  
• 이성의 기능을 다시 읽음.
  
• SWEBOK Software Construction 부분 한번정리. Software Design Part는 그래도 마음에 들었었는데, Construction 은 분류 부분이 맘에 안들어하는중. SWEBOK 이 있는 이유가 해당 Knowledge Area 에 대해서 일종의 이해의 틀을 제공하는 것인데, 이번 챕터는 그 역할을 제대로 하지 못했다는 생각이 든다. 다른 책을 찾아보던지 일단 건너뛰던지 해야겠다. 그래도 일단 내일을 위해 한번더;
  

16일 (화):

• Operating System Concepts. Process 관련 전반적으로 훑어봄. 동기화 문제나 데드락 같은 용어들은 이전에 Client / Server Programming 할때 스레드 동기화 부분을 하면서 접해본지라 비교적 친숙하게 다가왔다. (Process 나 Thread 나 동기화 부분에 대해서는 거의 다를바 없어보인다.)
  
  • 좀 더 체계적으로 공부할 예상 진행 Chapter 를 적는 것이 더 목표가 명시적으로 보일것 같다. (이것은 '몰입의 즐거움' 에서의 몰입하기 쉬운 형태를 만들어 줄것이라 생각한다. 근데, 이미 이런거 다 계산하고 있다고 알고있는 상태에서도 몰입이 되려나;)
    
  • SWEBOK 에서는 MindMap 이 잘 적용되었었는데, OSC 에서는 오히려 ConceptMap 식 접근이 더 용이해보였다. 이것도 책의 스타일에 영향을 받을듯. (기존의 SWEBOK 식 타성에 젖은 Index-Hierarchy 스타일이 문제가 있긴 하다.)
    
• SWEBOK Construction 부분 한번 더 봄. 하지만 여전히 마음에 안들어하는중; (상민쓰 말처럼 '영어로 된 동화책 읽고 세익스피어 영문판 읽어야' 이해하는 내용이여서 그런가;) Code Construction 은 아무래도 Design 영역이나 Test 영역에 비해서 art (예술 또는 기술) 적인 측면이 커서 그러려나. 이건 다른 레퍼런스를 보는 것이 나을 것 같다. 한계를 생각하자.
  

17일 (수):

• 다치바나 다카시의 책 읽음. 버스 안에서 절반 (일반적인 책사이즈 기준 가벼운 내용기준으로 시간당 100페이지는 읽는 것 같다.)쯤 읽고, 집에서 1시간 10분정도 써서 나머지를 다 읽었다. (이번주내로 정리 & 글 올리기)
  
  • 인상 깊었던 내용 대강: '생,사, 신비 체험' 에서 의학용어중 '所在識' 이라는 것이 있다고 한다. 병원에서 환자의 의식수준이 점점 낮아지고 있을 때 그 수준을 검사하기위해 다음과 같은 질문을 한다.
    
'여기는 어디입니까?'

'당신은 누구입니까?'

'지금은 언제입니까?'

공간적, 시간적, 그리고 자기자신에 대한 본질적 질문들. 환자를 '진단' 하듯이 나를 '진단' 하는 저 질문에 대해 나는 어떤 답을 내릴까? 언제나 나는 질문에 대해 결론을 내리지 않는, 표현하지 않는 Read-Only User의 위치에 있는 경우가 많았다. 과연 나는 어떤 답을 내릴까? (저 글에서의 '나'와 지금 이 글을 쓰는 '나'가 같은 사람이 아니라는 느낌이 드는 이유는 뭘까.)

• OSC 전체적으로 훑어보기 2차 (훑어보기로 대략 2시간 이용). 책 자체가 잘 만들어졌다는 생각이 든다. 'Concept' 에 충실하다. 책에 대한 전반적인 시야는 잡힌 것 같다.
  
  • 전반적인 OS 작동원리가 1,2장에 걸쳐.
    
  • Process Management 가 3,4,5,6,7에 걸쳐. 시험범위는 Process Synchronization 까지.
    
  • Memory Management
    
  • I/O Management
    
• 문제 : 오후 황금시간에 4시간이나