Project Prometheus/Journey

• TestCase 통과 위주 ZeroPageServer 에서 TestCase 돌려봄
  
  

• 검색 관련 에러메세지 출력.
  
• ZeroPage 에 Release. 관련 Ant Build 화일 작성
  
• 패키지 분리, 디렉토리 정리.
  
  
• 패키지 분리를 하고, 관련 경로 화일들을 수정을 하면서, 중복이 없는 코드가 얼마나 강력한지가 보인다. 정말정말 고칠 부분이 많이 줄어든다. (사람이건 툴이건 덜 고생하게 된다.)
  
  
• 윈도우에서 작업한 Java 화일이 의외로 한방에 Ant 로 빌드하고, ZeroPage 의 Resin 서버에서 동작하는 것을 보며, 다시금 자바의 위력이 실감난다.
  
• 메인 코드를 작성하고 있을때에는 '화일로 빼야 할 거리' 들이 안보인다. 하지만, 이미 컴파일 되고 굳어져버린 제품을 쓸때에는 '화일로 뺐어야 하는 거리' 들이 보인다. 데이터주도적기법의마법 이였던가. 뭐, 미리 머리 스팀내며 해두는 것은 YAGNI 이겠지만, 눈에 빤히 보일때에는. 뭐, 앞으로 해줄거리. (Property class 가 좀 더 확장될 수 있을듯.)
  
  
• 원래라면 방학중 한번 Release 하고 지금 두번째 이상은 Release 가 되어야 겠지만. Chaos (?)의 영향도 있고. -_-; 암튼 두달간 장정에서 이제 뭔가 한번 한 느낌이 든다. 초반에는 달아오르는 열정이되, 후반은 끈기이다. 중간에 느슨해질 거리들이 많음에도 불구하고 천천히나마 지속적일 수 있었음이 기쁘다.
  
  
• Pair 라는 것은 꼭 프로그래밍이 아니다 하더라도 여러가지 시너지를 발휘할 수 있다. 혼자서 생각하는 것보다 빠른 피드백을 받을 수 있기에. 오늘 떡볶이 먹으면서 아이디어 궁리할때의 아이디어들이 모이고 상대방에게서 반응을 들어보고 덧붙여지고 의외로 새로운 아이디어가 창출될때의 그 느낌이란. --1002
  
  
  

• Advanced Search
  
• Mypage 에서의 Best Point 순위.
  
• 검색 결과 리스트에 대해 페이지 나누기
  
  

오늘은 일의 진행이 정말 일사천리로 이루어졌다. 모이고 처음 일을 시작할때 상민이와 이전에 했던 일들과 오늘 해야 할일에 대해 간단하게 정리를 한 점이 주효한것 같다. 간단한 일이긴 하지만, 그날의 할 일에 대해 미리 머릿속에 그림을 그려둔다는 점에서 5분 Stand Up Meeting 은 의외로 효과를 주는것 같다. 그리고 Pair 를 하는중 디버깅이나 기타 일을 할때 미리 자신이 어떠한 일을 하려고 하는지 짧으면서도 자주 대화가 오고 갔던 점, 프로그래밍때 자주 체인지 한것도 오늘 일이 잘 진행되는데 도움이 컸다고 생각. --1002

• 정규표현식 파싱 부분 일부 수정.
  
• UI 디자인 궁리.
  
  

• Test 깨진 것 마저 수정. 테스트들 추가.
  
  • UnitTest 들이 드디어 다시 녹색바. 그리고 서블릿에 있던 로직 부분을 Extract, 테스트들을 붙여줌.
    
    
• Test 마저 고치는 중, 내가 당연하다고 생각되었던 Test 가 깨진 문제 분석이 실제로 틀렸음을 알게 되었다. 상민이 덕택에 의외로 30분 내로 간단히 해결되었다. 오랜만에 AcceptanceTest 포함 80여개 테스트가 녹색불을 켜게 되었다.
  
  
• 한동안 PairProgramming 할때 주로 관찰자 입장에 있어서인지. (이상하게도. 창준이형이랑 할때나 상민이랑 할때나. 그나마 저번 르네상스 클럽때는 아무도 주도적으로 안잡아서 그냥 내가 잡긴 했지만, 다른 사람들이 적극적으로 나서지 않을때엔 웬지 그 사람들과 같이 해야 한다는 강박관념이 있어서.)
  
  

그동안의 Pair 경험에 의하면, 가장 Pair 가 잘 되기 어려운 때는, 의외로 너무 서로를 잘 알고 Pair를 잘 알고 있는 사람들인 경우인것 같다는. -_-; (Pair 가 잘 안되고 있다고 할때 소위 '이벤트성 처방전'을 써먹기가 뭐하니까. 5분 Pair를 하자고 하면 그 의도를 너무 쉽게 알고 있기에.) 잘 아는 사람들과는 주로 관찰자 입장이 되는데, 잘 아는 사람일수록 오히려 개인적으로 생각하는 룰들을 잘 적용하지 않게 된다. (하는 일들에 대한 Tracking 이라던지, 다른 사람이 먼저 Coding 을 하는중 이해 못할때 질문을 한다던지 등등. 차라리 그냥 '저사람 코딩 잘 되가나본데..'. 오히려 예전에 '문제'라고 생각하지 않았던 부분이 요새 '문제' 로 다가 온다.)
그렇다고 이 상황을 다른 사람에게 말로 하면 당연히 '응. 그래. 다음번에는 주도적으로 잡아' 라고 하지만. 한동안 손가락이 쉽게 가지 않을 것 같다. 개인적인 문제일까. 아직 현상에 대한 분석이 잘 안되는중이다.

• 서블릿 레이어부분에 대해서 Controller 에 Logic 이 붙는 경우 어떻게 Test 를 붙일까. (FacadePattern 을 생각하고, 웹 Tier 를 따로 분리하는 생각을 해보게 된다.) --1002
  
  

• Test 깨진 것 수정하기.
  
  

1002 개인적으로 진행. 뭐 진행이라기 보다는, 오랜만에 Solo Programming 을 해봤다. 장점으로는 느긋하게 소스를 리뷰하고 대처할 시간을 천천히 생각해볼 수 있던점. (보통은 상민이가 이해를 빨리 하기 때문에 먼저 키보드를 잡는다.) 단점으로는 해결책에 대한 Feedback 을 구할 곳이 없다는 점이 있다. (평소 물어보고 둘이 괜찮겠다 했을때 구현을 하면 되었는데, 이경우에는 책임 소재랄까.. 웬지 혼자서 생각한 것은 의외의 틀린 답이 있을 것 같은 불안감이 생긴다. 테스트 중독증 이후 이젠 페어 중독증이려나..)

Test 들이 있으면 확실히 좋은점은, 깨진 테스트들이 To Do List 가 된다는 점이다. 복구순서는? 깨진 테스트들중 가장 쉬워보이는 것이나, 그 문제를 확실하게 파악했다고 자부하는 테스트들을 먼저 잡고 나가면 된다.

• 근데, 해놓고 나서 커밋할 생각이.. 좀 안나긴 하다. 한편으로는 Test 들을 통과하니까 둘이 서로 정한 의도대로 한 것이니 상관없다는 생각. 하지만, 한편으로는 'Pair 로 한 것이 아닌데..' 하는 생각. 그냥 Spike 버전 정도로 생각해둘까나.
  
  

• 도서관 UI 변경과 관련, Test 깨진것 수정하기
  
  

학기중에는 시간을 맞추기가 쉽지 않음을 느끼며. 뜻하지 않는(뭐 한편으론 예상했지만) Requirement 의 변경이 일어났다. 도서관 UI & 시스템이 전면적으로 수정된 것이다.

다행히 모듈화가 잘 되어있었고, Test 들이 있었기에 neocoin 과 1002 는 주로 깨진 테스트들을 바로잡기로 했다. 일단 도서관들의 HTML 을 얻고, Local HTML 문서에 대해 데이터들을 잘 추출해내는지에 대한 테스트를 먼저 복구했다.

• Recommender, lightView, heavyView service 작성. view 추가.
  
  

속좁은 1002 이 상민쓰에게 신경질 부리던날로 기억 -_-; 일종의 Test 에 대한 압박을 받아서이긴 한데, 처음에는 'Model, Logic' 부분에 대해서만 Test 정도 붙이면 되겠지 라고 생각했는데, Servlet 으로 작성한 Controller 부분이 커지면서, 각각 Command 에 해당하는 (service 라고 이름지었음) 부분에 대해 로직이 붙었기 때문이다. 근데, Servlet 이여서 테스트를 못붙이고, 작업은 작업대로 진행되는데 테스트 붙일 방법을 생각하지 못하는데, 잘 진행되어간다고 보이는 작업 발묶는것 같아서 이야기 못하고 꿍해있다는.
(그래서 수요일날에는 프로그램 작성전 Menual Test 방법을 먼저 생각해두고, 프로그래밍 작성을 하는 식으로 접근함)

• 대안을 생각중인데, 일종의 Facade 를 만들고, Controller 의 각 service 들은 Facade 만 이용하는 식으로 작성하면 어떨까. 그렇게 한다면 Facade 에 대해서 Test Code 를 작성할 수 있으리라 생각. 또는, Servlet 부분에 대해서는 AcceptanceTest 의 관점으로 접근하는 것을 생각. 또는, cactus 에 대해서 알아봐야 하려나.. --1002
  
• 문제에 부딪치고, 그 문제가 해결될꺼 같이 보이면서, 아슬아슬 버티면 내일 해결해야 한다. --상민
  

• Recommender 부분 완료 (연관된 ~cpp BookMapper, ~cpp UserMapper의 기능 작성 완료)
  
  

어제 마지막 고민이 지하철을 타고가면서 해결되었다. 그리고 오늘 와서 생각대로 적용하니 이후 Test들에서는 아무런 문제가 발생하지 않아서 안도의 한숨을 내쉰다. 시스템들이 Test를 통과하자, 가장 큰 문제로 발생된 것이 Test의 작성과 확인이었다. 책 4권과 사용자 3명.. 정말 머리에서 피시식 연기가 나는 느낌을 받는다. 그나마 Pair이기에 한명이 코드를 보면서 생각하고, 한명은 종이를 보면서 생각하면서 동기화를 시키니 다행이지, 혼자였다면 후유.. 문뜩 온라인 게임들이 굉장히 긴 시간동안 베타 테스트를 하는 것이 이해가 간다. --상민

• Object-Database 연동을 위한 ~cpp BookMapper, ~cpp UserMapper 작성
  
  

이 부분도 일종의 Architecture 의 부분일것인데, 지금 작성한것이 웬지 화근이 된것 같다는. Architecture 부분에 대해서는 Spike Solution 을 해보던지, 아니면 TDD 를 한뒤, Data Persistence 부분에 대해서 내부적으로 Delegation 객체를 추출해 내고, 그녀석을 Mapper 로 빼내는 과정을 순차적으로 밟았어야 했는데 하는 생각이 든다.

Object-RDB Mapping 에 대해서는 PatternsOfEnterpriseApplicationArchitecture 에 나온 방법들을 읽어보고 그중 Data Mapper 의 개념을 적용해보는중. Object 와 DB Layer 가 분리되는 느낌은 좋긴 한데, 처음 해보는것이여서 그런지 상당히 복잡하게 느껴졌다. 일단 처음엔 Data Gateway 정도의 가벼운 개념으로 접근한뒤, Data Mapper 로 꺼내가는게 나았을까 하는 생각.
DB 쯤 되고 나니, Test 들의 보폭을 줄이는게 힘들어지는것 같다. (그리고..; 사람들이 잘 안줄이려고 하는것 같다;) TDD 가 좀 더 활성화되러면 학교 컴퓨터들이 더 빨라져야 한다고 개인적으로 생각중 -_-;

• Side Effect 는 Refactoring 의 적이라는 생각이 오늘처럼 든 적이 없었다. -_-; Extract Method 같은 일을 하는 경우 더더욱.! --1002
  
• 멋진 Side Effect 세상 문서를 만들어야 겠다. --상민
  
  

• Recommender 구현중 User 클래스의 구현
  
• ~cpp UserTest구현
  
• ~cpp RecommenderTest 의 테스트 수행중
  
• AcceptanceTest login , view page 테스트 추가
  
  

Spike Solution으로 만들어 두었던 것들이, 실제로 프로그래밍 소스로 전환되고 있는 과정 중이다. 이제 User내의 Spike Solution관련 코드들이 사라지면 Spike Solution의 Test들도 다 깨지면서 사라 질것이다. 내일이면 DB와의 연동이 마무리 되고, 웹에 인터페이스 노출이 이루어 질것 같다. 그렇게 되면 커다란 줄기는 완성되는 것이다. 역시나 감회가 새롭다. Acceptance Test에 관련한 코드들을 내가 너무 모르고 있다. 그쪽 코드를 보고 이해 해야 불안하고 들뜬 마음을 안정 시킬수 있을것 같다. 나는 즐거운거 맞는 걸까? 학교 더 일찍오면 확실히 즐거울꺼 같다. --상민

• 목소리를 키울때는 늘 민감함이 앞선다. 처음 목소리를 키우다가 다시 소극적으로 되려고 할때 의자 끌고 Pair 자리에 앉히는 상민이를 볼때 내가 어린아이같다는 생각도 해본다. 늘 실천보다 불평이 앞서는 1002이기에 -_-; 아쉬운점이라면, 소스의 Complexity 가 높아질수록 Test 의 보폭을 줄이는데 힘들다는점. 오늘 창준이형과 Pair를 하던중. Observer 의 역할일수록 전반적인 숲들을 잘 관찰하고 Driver 를 도와줘야 한다는 점을 되새기면서.
  
  • 내가 잘못하면 직접 욕해줘 나 오래 살게 --상민
    
• Python 의 ClientCookie 모듈의 편리함에 즐거워하며. Redirect, cookie 지원. 이건 web browser AcceptanceTest를 위한 모듈이란 생각이 팍팍! --1002
  
  

• SimpleSearch -> ViewBook 으로의 구현
  
• SearchListExtractorRemoteTest 추가
  
  
• 발견된 문제나 사항 인상 깊은점
  
  • 도서관은 303건 초과 리스트를 한꺼번에 요청시에는 자체적으로 검색리스트 데이터를 보내지 않는다. 과거 cgi분석시 maxdisp 인자에 많이 넣을수 있다고 들었던 선입견이 결과 예측에 작용한것 같다. 초기에는 local 서버의 Java JDK쪽에서 자료를 받는 버퍼상의 한계 문제인줄 알았는데, 테스트 작성, Web에서 수작업 테스트 결과 알게 되었다. 관련 클래스 SearchListExtractorRemoteTest )
    
  • 목록검색에서 검색 이력이란 메뉴가 있는데, 도서관쪽에 해당 ip에 대한 캐싱 결과에 대하여 나와있다.
    
    

결과물이 눈에 보인다는 것은 즐거운 것이다. 물론 구현중에 Test결과들이 눈에 보이는 것도 즐겁고 안정감 있는 코딩을 할수 있는 요인으로 제공되어서 좋왔지만, 이제 리스트가 보이고, 책을 보는 것까지 되니 여태까지의 결과들이 통합되는 것을 눈으로 확인 하는것 같아서 좋다. 통합시에 그리 큰문제는 현재까지 발생하지 않았다. --상민

• MPP 에 login, SimpleSearch 구성과 결과 출력
  

• 마이너리티리포트 보러 가기~
  
• Server Refactoring
  
  

서버쪽 클래스들에 대해서 Refactoring 을 시도 데이터클래스이면서 그 용도가 조금씩 달랐던 클래스들을 하나로 묶었다. (일단 모여해쳐 시도용으로) 그러면서 안쓰는 클래스들을 조금씩 지워나갔다. 패키지들중 Test 패키지와 메인 소스 패키지, 임시 코드 패키지들에 대해서 화일들을 옮기고 정리했다. 아직 완벽하게 정리된것 같진 않지만, 개인적으로는 이전에 비해 만족스러웠다. (이제 Target은 Resin 쪽과 임시소스들 디렉토리.)

• Code Review 로서 Refactoring 이 이용된다고 했다시피, Refactoring을 해 나가면서 전체 프로그램의 그림이 좀 더 이해가 갔다. 한동안 해당 프로그램에 대해서 플밍 리듬을 놓쳤을때 Refactoring 을 시도하는것도 좋은 전략이라 생각.
  
• Task 를 작성할때 Refactoring 을 명시적으로 써 놔야 하겠다. Acceptance Test 처럼. 써놓지 않으니까 잊어먹고 자주 안해준 것 같다. 그리고 생각보다 시간이 걸리는 만큼. (이건 Refactoring 을 플밍 중에 자주 해주지 않아서인것 같다. 2시간정도 걸렸으니)
  

--1002

• DB Schema 궁리 & Recommendation System 을 DB 버전으로 Integration 시도
  
  
• Pair 중간에 1002 는 목소리가 커질때가 있다. 하나는, 내가 놓치고 있을 경우에 대해 다른 사람이 이야기를 제대로 안해줬다고 생각되는 경우. 뭐 보통은 1002의 잘못을 다른 사람에게 떠넘기기 위한 방편인 경우가 많다 -_-; (찔린다; 나도 JuNe 형이랑 Pair 할때 무방비상태인 경우가 많아서;) 뭐, 같이 무방비였다가 못느끼고 넘어간 경우라면 아하~ 하면서 플밍하겠지만, 하나를 고치고 나서, 다른 사람이 당연한 듯이 좋은 방법으로 해결해낼때엔. ("왜 아까는 이야기안해?" "당연한거잖나."). 일종의 경쟁심리이려나. 에고 를 잊어야 하는게 PairProgramming 이지만, 사람 마음이 그렇기엔 또 다른것 같다. 코드 기여도에 대해서 보이지 않는 경쟁이 붙는다고 할까나.
  
  

문제는, 1002 의 목소리가 화내는 톤이 될 경우이다. (의도하건 안하건. 보통 화내는 사람은 자신이 화내고 있다는 것을 의식하지 않은 경우가 많다. 이 경우의 문제는, 열심히 잘한 상대가 쓸데없이 들을 필요없는 소릴 듣는다. --; 아. 정신 수양이 필요하다. (지가 잘했으면 될거면서..;)

• 내목소리가 커질경우에는 다른 사람이 위축이 된다. 그 사람이 잘하고 있다 하더라도. 한편으로는 '당신의 능력을 보여주세요'; 자신의 코드에 대해서 자기 이야기를 했으면 하는 생각. 목소리를 줄이거나, '한번 흘러갈대로 해봐라' 라는 식은 자신의 생각을 코드에 붙일 수 없게 되므로 좋지 않은 경우라고 생각.
  
  
• 리듬이 깨졌다라는 느낌이 들때. Task 단위를 To Do List 단위로 다시 쪼개는 지혜 필요할 것 같다. 현재 Task 사이즈가 Pair 기준 1시간이긴 한데, 막상 작업할때에는 시간을 헤프게 쓴다란 생각이 듬.
  
  
• MockObjects 를 이용, Database 에 대해서 MockObjects Test 와 Real DB Test 를 같이 해 나가보았다. DB - Recommendation System 연결을 위해서는 RS 에서의 object 들과 DB 와의 Mapping 이 필요하다고 판단, DB Schema 를 같이 궁리한 뒤, Test 를 작성하였다. 이때 이전 기억을 떠올리면서 MockObjects Test 를 상속받아서 Real DB Test 를 작성하는 식으로 접근해봤는데 좋은 방법이라 생각.
  
  
• Martin Fowler 의 PatternsOfEnterpriseApplicationArchitecture 를 읽어보는중. 우리 시스템의 경우 DataMapper 의 개념과 Gateway 의 개념을 적용해볼 수 있을 것 같다. 전자는 Data Object 를 얻어내는데에 대해 일종의 MediatorPattern 을 적용함. DB 부분과 소켓으로부터 데이터를 얻어올 때 이용할 수 있을 것 같다. 후자의 경우는 일반적으로 Object - RDB Data Mapping (또는 다른 OO 개념이 아닌 데이터들) 인데, RowDataGateway, TableDataGateway 의 경우를 이용할 수 있을것 같다.
  
  

--1002

• TestCase 만들어 둔것을 상속 받아서, 다시 다른 테스트를 수행 시키는 기법이 정말 흥미로웠다. 진짜 신기하다. 생각하면 할수록 신기하다.
  
• 문헌 정보 학과의 관련 자료를 석천이랑 가서 보았는데, 또 다른 지식의 세상이 있음을 알수 있었다. 수백년간 구축해온 진정한 KM을 느낄수 있었다.
  

--상민

• test 관련 패키지 정리
  
  • test ~cpp TestCase
    
  • tests ~cpp TestSuite 모음
    
  • 모든 ~cpp TestCase TestSuite 는 독립적으로 실행할수 있다.
    
• ~cpp AllLocalTests 내에
  
  • ~cpp BookContainerLocalTest ( 테스트 작성 시작, DB연동 부분 생각해야 함 )
    
  • ~cpp BookWebLinkerTest (대상 서점 Amazon, Aladin, Wowbook)
    
  • ~cpp ViewBookExtractorTest ( ~cpp LendBookList 와 연계하여 테스트 추가 )
    
• ~cpp AboutLendBookTests
  
  • ~cpp LendBookListTest
    
  • ~cpp LendBookTest
    
    

머리가 잘안돌아 가는 느낌을 받기 시작한 것이 6시 즈음인데, 한시간은 괜히 잡고 있었던것 같다. DB스키마에 관해서 조금 생각해 보았고, 8일에는 DB연동 디자인이 들어가야 할것이다. Test 위주의 프로그래밍 작성은 아무리 생각해도 멋진거 같다. --상민

현재 요구사항에 따라

• UserStory 정리 & Engineering Task 재정의
  
  • ProjectPrometheus/UserStory
    
  • ProjectPrometheus/EngineeringTask
    
    

한동안 휴식을 제대로 안 취해서 일까. 일에 좀 지친듯 하다. (특히, 최근 그 3주간의 카오스계에 있다 보니;) 전체 일 대비 진행된 일을 정리하고, 다음에 해야 할 일을 정하고 하려고 했지만, 퍽 하고 서로 코딩에 손이 가지 않았다. 일단, 오늘은 일찍 쉬기로 했다.

정말로 학교가 우리를 안도와주기로 작정한것 같다. 도서관 서비스 개편된다고 했고 -_-(이는 곧 정규표현식 쓴 부분과 관련하여 재작성하라는 뜻이니;) 게다가 다음주부터 엘리베이터 수리 들어간단다. 경비아저씨에게 5층 신피 열어달라고 부탁하는것에 대해 더 눈치를 봐야 한다는 뜻이 된다; 으어;

• 수요일은 JuNe 형과 blashnet 쪽 관련 예제코드 마저 작성할 것 같고, 다시 목,금,토 가 화두가 되겠군. --1002
  
  

DB Mock Object ADO 예제 작성. (For XpWorkshop)

상민쓰와 함께 ADO 를 이용한 부분에 대해 DB Mock Object 예제를 작성했다. 전에 상민이가 DB Layer 를 두지 않고, ADO Framework를 거의 치환하게끔 작성했다고 판단, 이번에는 내부적으로 ADO를 쓰건 가짜 데이터를 쓰건 신경쓰지 않는 방향으로 같이 작성하였다. ADO 는 기존에 1002 가 작업했던 프로그램에서 일부 사용한 소스를 고쳐썼다.

5시간 정도 걸리긴 했지만. -_-; Mock Object 가 어떤 것이다에 대해 한걸음 더 이해할 수 있는 계기가 되었다고 생각.

• STL 을 쓰면 편리하긴 한데, 확실히 학교컴퓨터에선 컴파일이 느리긴 한것 같다는; (하긴, 우리가 map 에 vector 겹친 형태로 작성을 했으니 -_-..) 그래도 STL Container 만 어느정도 이용해도 기존의 순수 C++ 을 이용할 때보다 훨씬 편하다는 점이 즐겁다. 만일 mock object 를 STL 이나 MFC Collection 없이 구현한다고 생각한다면? 그리 상상하고 싶지 않을 정도이다. (특히 DB에선) 그러면서 느끼는점이라면,
  

'과연 사람들이 이 소스를 보고 나서 MockObjects 를 적극적으로 이용하려고 할까?' 라는 점. (STL 을 좀 많이 써서. ^^;)

GJ가 도입되면 IBM의 Incremental Compile도 무용지물 아닐까. --상민

XpWorkshop 보조.

• login 부분 작성
  
• Python Prototype 을 Java 로 바꾸기
  
  

아아. 방학 내내 MIB 와 Chaos 의 나날들; 오늘은 새로 들어온 컴퓨터 셋팅에 네트웍 문제까지. -_-;

• 예전에 일할때 잘못했었던 실수를 다시하고 있으니, 바로 기획자와의 대화이다. Iteration 이 끝날때마다 개발자가 먼저 기획자 또는 고객에게 진행상황을 이야기해야 한다. 특히 ExtremeProgramming 의 경우 Iteration 이 끝날때마다 Story 진행도에 대화를 해야 한다. Iteration 3 가 넘어가고 있지만 항상 먼저 전화를 한 사람이 누구인가라고 묻는다면 할말이 없어진다. 이번 Iteration 만큼은 먼저 전화하자;
  
• 'Iteration 3 에서 무엇은 되었고 무엇은 안되었는가?' 지금 Iteration 3 쪽 Task 가 아직도 정리 안되었다. Task 정리를 하지 않고 Iteration 3 를 진행한 점은 문제이긴 하다. (비록 구두로 개발자들끼리 이야기가 되었다 하더라도. 제대로 정리를 한다는 의미에서.) Iteration 3 Task 정리 필요. 그리고 나머지 Iteration 에 대한 Task 들에 대해서 예측할 수 있는것들 (슬슬 눈에 보이니)에 대해 추가 필요.
  
  
• 아이스크림 잘먹었어요. 감사감사
  
  

--1002

• 최근들어서 전혀 글을 쓰고 있지 않다. 아날로그든 디지털이든.. 책을 보면서도 저자와 교감을 얻을 만한 부분에서 벅차오르고, 머리속으로 해당 생각을 10~15분 가량 정리한 이후 그것으로 끝이다. 일종의 슬럼프일까.
  
• 내일까지 신피의 네트웍이 안될까 걱정이다. 오늘의 일은 도저히 예측할수 없었던 일종의 사고이다. 나비의 날개짓은 어디에서 시작되었을까 생각해 본다. MIB Programmer가 되고 싶지만 그마저 시간이 부족한것이 현실이다.
  
• 아이스크림은 ...
  
  

--neocoin

• Iteration 2 에 대해 밀린 것 마저 진행.
  
• Iteration 3 에 대한 Planning
  
  

Iteration 3 에서의 Login 을 위해 정말 오랜만에(!) Servlet 책과 JSP 책을 봤다. (빌리고서도 거의 1-2주간 안읽었다는. -_-;) 상민이가 옆에서 JSP 연습을 하는동안 나는 Servlet 연습을 했다. 후에 두개의 소스를 비교해보면서 공통점을 찾아내면서 스타일을 비교해 본 것이 재미있었다. (처음에 의도한건 아니지만;)

• 학교에서 PairProgramming 이 정착될 수 있을까. Pair 를 하는 중 대화가 좀 커져서 그런지 저 너머쪽의 선배가 주의를 주었다. 뭐.. 변명거리일지 모르겠지만, 자신의 바로 뒤에서 게임을 하고 있는 사람은 자신의 일에 방해가 되지 않고, 저 멀리서 개발하느냐고 '떠드는 넘들' 은 자신의 일에 방해가 된다.
  
• 한편으로 또 드는 생각은 아무리 우리가 공부를 하네 위키에 문서를 남기네 해도, 결국 저 사람에게는 '그저 저넘들 자기만족을 위한 행위' 그 이상이 아니라는 것. 피시실에서 게임을 하나 프로그램 개발을 하나 그저 '타인의 행동' 이상의 의미가 없다란 느낌이 들고 나니 서글퍼진다. 순간 울컥 하는 마음에 속으로 '차라리 자극 좀 받아보시고 거기 깔린 오락 좀 지워보시지. 젠장' 라고 읊어대었다. (갈수록 건방짐 높아져가는 1002. 솔직히 좀 화가 나서리..) 개인적으로 피시실이 사람들이 서로 개발이나 공부를 위해 시끌벅적한 작은 팀들이 많이 있고, 그 분위기에 다른 사람들이 조금이나마 휩쓸렸으면 하지만. 그러한 팀들은 늘 레포트가 나오던지 팀프로젝트가 나오던지 해야 만들어지려나.. 거참 엄청 재미도 나겠군. 역시 이상일 뿐이려나. (화이트보드 큼지막한 것이 있어도 우리가 알고리즘 구상하느냐고 써놓은 것들이 3-4일째 그대로이군.)
  
  

ZeroPageServer 의 게시판 소스가 JSP 이고 JSP/Servlet runner 가 Resin 이여서 환경설정 부분을 구경할 수 있었다. 그래서 Resin - JDBC 셋팅 부분을 구경하고 손쉽게 할 수 있었다. ZeroPageServer 의 첫 삽을 떠준 선우형에게 감사드리며. 현재 쓰고 있는 글들이 몇달 또는 몇년 뒤 ZeroPagers 또는 익명의 사람들에게 도움이 되었으면 한다.
-- 1002

• Iteration 2 에 대한 SpikeSolution 계속 진행
  
  

Iteration 1 에서 밀린 일들이 3 task 쯤 되는데, 계속 그정도의 일들이 밀린다. 하긴, 3 task 가 밀렸음에도 불구하고, Iteration 1 에서의 처음 Task 를 맡은 만큼 Iteration 2 에서 Task 로 실었으니까.

• 중간 알고리즘부분에 대해서 혼란상황이 생겼다. 처음 TDD로 알고리즘을 디자인할때 view / light view / heavy view 에 대한 point를 같은 개념으로 접근하지 않았다. 이를 같은 개념으로 접근하려니 기존의 알고리즘이 맞지 않았고, 이를 다시 알고리즘에 대해 검증을 하려니 우리의 알고리즘은 그 수학적 모델 & 증명이 명확하지 않았다. 우리의 알고리즘이 해당 책들간의 관계성을 표현해준다라고 우리가 주장을 하더라도, 그것을 증명하려니 할말이 생기질 않았다. 수학이라는 녀석이 언제 어떻게 등장해야 하는가에 대해 다시금 느낌이 오게 되었다.
  
• PyUnit 의 ok.
  
  

--1002

• Iteration 2. Recommendation System 에 대한 SpikeSolution
  
  

일단 알고리즘부분을 대강 생각한뒤 Python 으로 TDD 를 했다. (소스). CRC 세션을 먼저하여 시나리오를 시각화해두고 프로그래밍을 했었다면 좀 더 빨리 작성할 수 있지 않았을까 하는 생각을 해본다.

알고리즘에 대한 SpikeSolution 에 대해서는, 일단 연습장에 명확하게 알고리즘을 세운뒤 프로그래밍에 들어가는 것이 좋겠다고 생각함. 그리고 알고리즘 디자인시에 Matrix 와 Graph 등의 모델을 그려서 생각해보는 것이 효율적이겠다는 생각이 들었다.

• Iteration 1 에서 못한 일들을 Iteration 2 로 넘길때는 Iteration 1 에의 Task 를 Iteration 2로 넘겨줘야 한다. Iteration Planning 은 일종의 Time-Box 이다.
  
• AcceptanceTest 가 작성되고 나면서부터는 매일 AcceptanceTest 를 돌려서 연기가 나는지(?) 확인해본다. (M$에서의 테스팅처럼..) 매일 AcceptanceTest 를 돌려봄으로서 앞전의 작업에 대해서 그 결과에 대한 보장을 해둔다.
  
• AcceptanceTest 에 대해서는 Customer 가 이해할 수 있도록 코드를 작성한다. 가급적이면 High-Level 로. 간단한 스크립트언어를 작성하는것도 방법이 되겠다.
  
• Iteration 1 에서 9 Task points 를 완료했다면, Iteration 2 에서도 9 Task points 를 맡는다.
  

• Iteration 1 에서 못한 일들 마저 함. AcceptanceTest 작성.
  
  

Jython 의 편리함을 깨닫았다. Java 의 클래스들에 대해서 바로 Import 하여서 쓸 수 있다. 그리고 Python 에 있는 라이브러리들을 거의 그대로 이용할 수 있다. 단, 한글 문제로 걸림. AcceptanceTest 의 경우 Python 으로 작성함.

• Tare씨께서 작업하는 모습을 보고 싶다면서 오셨다. 작업하는 동안 우리가 거의 대화를 걸지 않고 우리끼리 계속 작업에만 몰두했음에도 불구하고, 뒤에서 작업하는 모습을 끝까지 지켜보시는 모습을 보면서 한편으로 신기했다. 다른 사람들이 어떠한 과정으로 작업하는가를 알기 위해 저렇게 관찰하는 사람이 있을까? 어떠한 얻음을 얻으셨을지 모르겠지만. 그의 자세는 참 인상적이였다.
  
• Iteration 1 에서의 결과를 오늘 보여드리고 Iteration 2 에 대한 회의를 해야 할때임에도 불구하고, 직접 오셨는데 별다른 결과물을 보여들이지 못해서 참 죄송했다. 이번주 MT 가 있었다 하더라도, 변명이란 없음. --1002
  
  

• HTML 문서 가져오는 클래스 (Spider) 작성
  
• HTML Parsing
  
• 도서관 검색 결과 Object 로 추출, 다시 HTML 생성.
  
  

오늘 무엇을 할 것인가 하며 ProjectPrometheus/Iteration 를 보고선 HTML Parsing 을 진행하기로 했다. 그 전에 1002 는 '아, 작업하기 전에 Book Search 에 대한 전반적인 그림을 그려 놓는게 좋겠군. 그리고 난 뒤 HTML Parsing 부분에 대해 구현해야지' 라고 생각을 했다. 한편 neocoin 은 수요일때와 마찬가지로 'HTML Parsing 부분에 대해 일단은 SpikeSolution 으로 만든뒤 모듈화 시켜나가야지' 라는 생각을 했다. 프로그래밍 스타일이 다른 두 사람이 진행 방법에 대한 언급없이 진행을 하려고 했다. 1002 는 '아 전체 그림' 하며 CRC 세션을 하려고 하는 중간. 한편 neocoin 은 같이 진행하고 있는 CRC 세션에 중간에 대해서 '지금 서로 무엇을 하고 있는거지?' 하며 혼란에 빠졌다. 똑같은 디자인 단계에 대해서 1002 는 전반적 Book Search 에 대해 생각을 하고 있었고, neocoin 은 모듈과 모듈간 연결고리에 대해 생각을 하였다.

중간에 상민은 메모장을 열었고 ..... 부분에 대해 코드를 적었다.

그리고 1002는 다음과 같이 Java Pseudo code 를 적었다.

~cpp 
BookSearcher bs = new BookSearcher();
bs.search(keyword);
bookList = bs.getSearchedBookList();

30-40분간의 서로간의 혼란과 싸움(?)끝에 서로 무엇을 위해 어떻게 일을 하려고 했는지에 대해서 이야기를 했고, 결국 서로 접근 스타일이 달랐으며, 서로 자기가 하려고 하는 일에 대한 의도를 밝히지 않고 '당연히 서로 알고 있는 듯' 일을 시작한 것임을 알게 되었다. 서로를 잘 알고 있다고 생각했기에 오히려 빠지기 쉬운 문제이라 생각된다.

암튼, 이후 다시 코드 구축 방법에 대해서 일단 이야기를 하였고, (여기서는 일단 서로 합의하에 1002 스타일 식으로 진행했다. 해당 클래스가 이용되어지는 모습을 먼저 생각하고, 시나리오에 따른 코드의 뼈대를 만들어가는 방식) 그 이후로는 오히려 진행이 빨라졌다.

• CRC 세션을 하는 중간에 혼란에 빠졌다. ResponsibilityDrivenDesign 을 잘 알고 있었다고 생각했는데 이때 잘 되지 않았다.
  
  

잘 되지 않은 부분은 다음에 대한 시나리오인데,

Client (클래스 이용자) 는 Library 에게 keyword 를 던지며 검색을 요청하면, Library는 그 keyword를 이용, 검색하여 Client 에게 돌려준다.

하지만, 실제로 Library 내부에서는 많은 일들이 작동한다. 즉, keyword 를 해당 HTTP에서 GET/POST 스타일로 바꿔줘야 하고 (일종의 Adapter), 이를 HttpSpider 에게 넘겨주고 그 결과를 파싱하여 객체로 만든 뒤 Client 에게 돌려줘야 한다.

즉, RDD 를 위한 CRC 세션중 계속 그 클래스들의 추상화 정도를 놓고 서로 클래스들을 추출해내는데 어려움을 겪었다. ('용어는 어느정도 추상화를 시켜야 할 것인가?', '내부 구현 시스템이 가급적이면 드러나지 않는 것이 일반적으로 좋은 디자인이라고 하는것 같은데 막상 우리가 BottomUp 을 하여 뽑아낸 디자인엔 이미 이름이 'HttpSpider' 등 이고..' 등등)

어떻게 보면 또 둘 간의 무의식적인 'Design Evaluation' 에 대한 강박관념이 아니였을까 하는 생각도 해본다. (일종의 PairPressure 일지도;) --1002

CRC가 잘 추출되지 않을때는 차라리 UserStory를 따라가면서 클래스를 만들고, 거기에서 다시 CRC를 생각해 보는 방법이 시간 절약에 현명할 것이라고 생각된다. 객체 지향 의 프로그래밍을 추구해온 결과, Scenario나, UserStory를 따라가며 코딩하면서 수많은 클래스들이 책임에 따라서 생겨나는 것을 보면서 자연 스러움과, 약간 의아함 마져 들었다.

왜냐면, 데블스 캠프 금요일 시간이 끝나고 나서 7층에서 석천이와 UserStory를 따라가며 만들어진 RandomWalk2 CRC의 모습에서는 단 3개만의 클래스만이 존재하였다. 하지만, UserStory를 따라가면서 소스 수준의 코딩을 하면 더 많은 클래스로 분화할것을 기대한다. 즉, 코딩을 하면 어쩔수없이 Layer의 최 하위까지 내려갈수 밖에 없으리라고 본다. 자 그럼 문제는 레이어 일것이다. 다행히 현재 코딩된 부분은 전부 logic의 부분으로 취급하고 있지만, logic 내에서 다시 레이어로 나뉘어서 외부에서 접근할수 있는 인자와 없는 인자로 나뉘어 져야 할것이다. 여기서 잠시 기억되는 말

ObjectWorld 의 전 세미나에서 아키텍트 설계자는(Architector) 소스를 가지고 디자인을 생각하는 사람이 아니라, 디자인(스펙으로 제시된)을 보고 디자인(자신의 회사에 맞는)을 만들수 있는 능력을 가진 사람이라고 말하였다.

우리가 처음 망설이던 부분의 CRC가 그런 케이스라고 생각된다. 소스 까지 접근하지 않은체, Layer-Tier를 생각하면서 책임을 부여할때, 나가지 않는 진도에 답답해 하며 꺼낸 메모장이 재미있는 결과를 가져다 주었다. 다음 같은 상황이 되면 스트레스는 훨씬 줄어 들것으로 생각한다.
마지막으로 석천이의 의견이 먼저 올라오길 기다린 나는 나쁜넘이다. 흐흐흐
--상민

• UserStory 와 사용자 시나리오를 혼용해서 쓴 것 같은데, UserStory Page 를 참조.
  
  • UserStory 와 Scenario 일부러 혼용해서 썼다. 실제로 우리는 둘다 이용했다고 생각하기 때문에 특별히 구분할 생각을 안했음 --상민
    
    • '일부러' 인가. 구현부분이 '무엇을 하고 있나' 에 대해 '이 Story를 하고 있다' 라고는 이야기할 수 있어도, 우리가 실제 coding 할때 이용한건 User Scenario 에 맞춘것임. UserStory 는 말 그대로 'Target' 일 뿐이라 생각하는데. 어떻게 '이용' 했지? --1002
      
• 소스 수준 코딩시 더 많은 클래스들이 분화되는 이유는 CRC 중 클래스와 클래스 간 대화를 할때 넘기는 객체를 따로 표시하지 않으니까. (우리가 7층에서의 RandomWalk2 보면 Class 와 Class 간 대화를 위한 클래스가 4개쯤 더 있음)
  
  • 4개를 어떻게 구현할지 생각 안한것으로도 이미 class의 추출은 3개라고 생각함. 그렇지 않고 소스 수준이라면 전부 다 추출하고 그렇지 않을건 다른 방식으로 했겠지. --상민
    
    • 그렇다면 3개의 클래스는 구현수준으로 까지 내려왔던가? 어차피 parameter 로 나온 클래스 4개나 우리가 '책임을 맡았다' 라고 하는 클래스 3개나 그 표현수준은 똑같다고 생각하는데. --1002
      
• 그리고 'Layer' 의 뜻이 모호하긴 하군. 'Abstract Layer', 디자인에 대한 추상화 정도를 이야기하시는것임? (문맥상 일단 그렇게 해석하는중)
  
  • 같은 의도 --상민
    
    • 그럼 고쳐. --1002
      
• 자칫 RDD 에서의 그 세부클래스들에 대해서 너무 많이 생각하면 BUFD(Big Up-Front Design) 이 되리라 생각한다. 차라리 Class 가 2개였을때 코딩 들어가고, 20-30분 정도 코딩뒤 Refactoring 을 의식적으로 하여 Big Class 에 대해 Extract Class 를 추구하는게 더 빠르지 않았을까.
  
• TestDrivenDevelopment 의 경우를 추구했다면 어떠했을까. TDD 의 특성상 꼭 필요한 메소드들만 있는 단순한 디자인을 유도한다라는 점에서. 이번의 경우도 Scenario 를 생각하여 프로그램 뼈대를 만들어서인지 주 Interface가 되는 메소드들외에 불필요한 메소드는 적었긴 한데, 그 대신, 신기하리만치 처음 짠 시나리오가 완벽하게 먹히었다란 생각도 든다;
  
  • 시나리오가 주요 한것에 동의, 신기하다는 느낌 비슷 -- 상민
    
• 박성운씨라면 SeparationOfConcerns 를 늘 언급하시는 분이니; 디자인 정책과 구현부분에 대한 분리에 대해선 저번 저 논문이 언급되었을때 장점에 대해 설명을 들었으니까. 이는 ResponsibilityDrivenDesign 과 해당 모듈 이름을 지을때의 추상화 정도가 지켜줄 수 있을 것이란 막연한 생각중.
  
• See KissPrinciple
  
• 나도 ps. 반문하기가 보통은 더 쉽다; (메모장에 글쓴거 이야기하는거 아님. '마지막으로' 를 'ps.' 대신 쓴 것일 뿐임) --1002
  
  • 아직도 내가 메모장을 핀걸 가지고 가진 생각을 오해하는거 같은데 이해가 안간다. 같은 이야기를 정말 많이 한거 같은데 절반 정도 의도 전달이 된듯 하다. 남은 절반은 여백의 미 --상민
    
    • 말로 걸러지고 글로 걸러지고 하루 지나서 기억력으로 걸러진 데이터는 '손실' 이겠지. 위의 '......' 부분은 그때 이야기했었던 자세한 대화내용이 기억이 안나서 그냥 저렇게 쓴 것일 뿐인데. 오해했다고 생각한다면 그 부족한 기억을 채워주면 안되나. --1002
      

• CollaborativeFiltering 에 대한 알고리즘 논의
  
• Book Search Iteration 에 대한 구체적인 Task 설정.
  
• Python, webdebug 를 이용, ProjectPrometheus/LibraryCgiAnalysis Task
  
• HttpURLConnection 을 이용, HTML 문서 가져오기 Task
  
  

CollaborativeFiltering 에 대한 논의. 논문 3개를 미리 읽어두었음에도 불구하고, 알고리즘 부분에 대해서 '실제 구현시 어떻게 할것인가?' 라는 질문에 대해 입을 열지 못했다. 으.. 논의에 무모하게(?) 껴들지 못하고 있는중인게 왜이리 억울한지. 공부 헛했다 헛했어..

Python Interpreter 는 말 그대로 'shell' 이다.; command 대신 쓰고 살까.. Python 과 webdebug 을 이용, 도서관 웹 사이트에 GET/POST 으로 데이터를 보내는 부분에 대한 분석은 참 편했다. (단, Python shell 에서의 encoding 부분에 대해 충돌나는건 골치)
--1002

옆에서 파이썬으로 proxy돌리고, Web debug하는 것이 멋지게 보였다. 파이썬에서 느껴지는 즉시성은 언제나 나로 하여금 경탄을 자아내게 한다. 비록 내가 겉으로는 표현이 부족할지라도...

HTTP에서 문서를 가지고 오는 것에 관하여 딱히 결론을 내릴수가 없었다. 도서관측의 잘못이 아니었을까 하는 생각이 뿐이다. zp서버에서는 get과 post 가 잘되는데 반하여, 도서관이 이상하다. 현재는 11일이며, 석천이와 이야기 끝에 적절한 선에서 타협하기로 하였다. 더이상 시간을 쏟기에는 너무 아깝다. --상민

1002 는 오늘 모임전 해당 프로그램이 Java Servlet & JSP 기반에서 돌아갈것이라 생각, Java Web Programming 에서의 MVC 패턴을 책들을 보면서 공부를 했다. 그래서 그런지, neocoin 과 전체 디자인 이야기를 할때 Java Web 에서의 MVC style 에 대해 먼저 언급하게 되었다. 그러면서 JSP Page - Servlet - Logic 객체들 로 나누고 Requirement 와 이전 수요일때 했었던 Iteration 등에서의 용어를 떠올리며 디자인을 생각하게 되었다.

그러다가 나중에 '이전에 생각했었던 CRC 세션에서의 디자인과 다르다' 라 판단, 다시 CRC 세션을 가져서 디자인을 하게 되었다. 앞의 경우가 MVC Architecture에 대한 디자인이 나왔다 한다면, 후자의 경우는 실제 Logic 부분에 대해 더 구체화된 (하지만, Java Web Architecture 와는 상관없이 일단은 일반 어플리케이션과 같아보이는) 디자인이 나왔다.

즉, 앞의 디자인의 경우 JSP 페이지들의 네이밍에 Logic 디자인이 영향을 받았다고 할까. 뭐, 어차피 구현부분은 제대로 생각하지 않은 Conceptual Model 에 가까운 것이였지만, 후자의 경우 데이터 클래스와 그 책임을 맡은 클래스들이 더 명시적으로 드러났던것 같다. 전자의 경우도 '이 기능을 맡은 클래스야' 하면서 Responsibilty 식으로 접근하려고 노력했지만, 후자의 경우가 그 용어면에서 더 추상적이였다. (전자의 경우 그 이름이 시스템을 드러내려고 했다.)

• ResponsibilityDrivenDesign.
  

후자의 경우이기 때문에 용어면에서 더 추상적이라는 것에 약간 의문이다. 왜 추상적일까? 추상적인 이유는 ~cpp MVC-WebProgramming의 설계 접근을 하면서 OOP에서 느껴지는 책임에 따른 의인화가 암묵적으로 막아져 버린듯 하다.

만약 MVC 설계에서 처음 시작할때 책의 객체화를 생각 했다면... 하는 아쉬움이 든다.

이번 경험이 주는 가장 큰 느낌은 시간이 많이 들더라도, 설계의 컨셉을 여러 각도로 해봐야 하는 느낌이 든다. 지쳐서, 시간이 부족해서 의견 제시를 못했지만 구조적 접근 방법으로 접근했다면 색다른 모습이 들었을 것이다.

둘다 공감하고 있지만, 디지탈 카메라가 없는 것이 너무 아쉽다.

CRC의 접근은 JSP-Servlet-Bean 상에서 구현하기 까탈스러운 면있을 것 같다. 하지만, MVC니 하는 말에 집중하지 않고, 오직 객체 상호간에 능력 배양에 힘쓰니, 빠진것이 없는것 같아서, 좋왔다.

• 한일 : 요구정의 정리, UserStory와 Scenario 혼용, 확인 부족한 스펙 부분 발견, 개발환경 정의
  
• neocoin: 마땅히 해야 할일을 했다고 느꼈다.
  
  • 마땅히 해야 할 일. 그 일을 해야 할때 무엇을 해야 할지 한큐에 생각이 나지 않는다는 점, 그 일을 해야 할 때, 시기를 놓친다는 점이 아쉽다고 한다면 뒷북일까.(글 늦게 쓴 사람의 여유;) -- 1002
    
    
• 지난번에 받았던 요구사항정의된 글들을 (그때 글들을 미리 스캔해두었었다.) 다시 보면서 다시 정리를 하였다. 어떠한 순서로 할까 하다가 일단 사용자의 기준으로, 사용자들이 이용하는 기능(Functional)과 퍼포먼스 관련 (Non-Functional) 부분으로 생각했고, 주로 Functional 한 부분을 기준으로 사용자 시나리오를 작성하면서 요구사항들을 정리하였다. 그러면서 지난번 Requirement 를 받을때 수동적 자세로 있었음을 후회했다. 5일이 지난뒤 정리하니까 이렇게 머리가 안돌아가나;
  
  "여기서 Recommendation System 이 작동해야 할 부분이 들어가면 안되겠는데... 본래 의도는 검색이 되고 난 뒤 책 관련 정보가 나올때 RS 가 작동하여 같이 표시가 되어야 해."
  
  
• 부족하다고 생각되어지는 점
  
  • Engineering Task 가 아직 명확치 않다. Engineering Task 를 지금 일단 간단하게 생각하는게 나을까 아니면 Architecture Design 뒤에 더 구체화해서 쓰는게 나을까 궁리중. 일단은 전자를 먼저 간단하게나마 궁리.
    
  • AcceptanceTest 방법에 대한 논의 부족 - 수요일 이전까지 궁리 예정; 흐..흐;
    
    

--1002

Req를 받는 작업은 중복이라 기록하지 않는다. 후회되는 부분도 준비 소흘을 비슷하게 생각한다.

그외 집에 와서, JSP + EJB를 테스트 하였는데, 아직 성공하지를 못했다. '자바 개발자를 위한 EJB 최신 입문서... 엔터프라이즈 자바 빈즈'에 수록된 JSP에 치명적인 문법적 잘못이 있었는데, JSP를 써보지 않았던 나로서는 책을 신뢰한 것이 잘못이었다. 새로 추정하기위하여 그제의 수순을 밟아가며 잘못을 찾는데, 역시 시간이 오래 걸렸다. 일단 JNDI의 string문제로만 귀결 짓는다. J2EE sdk + Tomcat이 아닌 JBoss+Tomcat 이라면 수월히 해결되지 않을까 예상을 해본다.

그리고 석천 IR이 뭐야 ?
EJB의 효용성에 관해서, EJB로 가야하는지 말아야 하는지 망설여질때 도움을 주는 체크 리스트, 그리고 IR은 아마도 http://no-smok.net/nsmk/InformationRadiator 일듯 --이선우

ProjectPrometheus/Journey