10.12 (토) ¶
- TestCase 통과 위주 ZeroPageServer 에서 TestCase 돌려봄
10.3 (목) ¶
- 검색 관련 에러메세지 출력.
- ZeroPage 에 Release. 관련 Ant Build 화일 작성
- 패키지 분리, 디렉토리 정리.
- 패키지 분리를 하고, 관련 경로 화일들을 수정을 하면서, 중복이 없는 코드가 얼마나 강력한지가 보인다. 정말정말 고칠 부분이 많이 줄어든다. (사람이건 툴이건 덜 고생하게 된다.)
- 윈도우에서 작업한 Java 화일이 의외로 한방에 Ant 로 빌드하고, ZeroPage 의 Resin 서버에서 동작하는 것을 보며, 다시금 자바의 위력이 실감난다.
- 메인 코드를 작성하고 있을때에는 '화일로 빼야 할 거리' 들이 안보인다. 하지만, 이미 컴파일 되고 굳어져버린 제품을 쓸때에는 '화일로 뺐어야 하는 거리' 들이 보인다. 데이터주도적기법의마법 이였던가. 뭐, 미리 머리 스팀내며 해두는 것은 YAGNI 이겠지만, 눈에 빤히 보일때에는. 뭐, 앞으로 해줄거리. (Property class 가 좀 더 확장될 수 있을듯.)
- 원래라면 방학중 한번 Release 하고 지금 두번째 이상은 Release 가 되어야 겠지만. Chaos (?)의 영향도 있고. -_-; 암튼 두달간 장정에서 이제 뭔가 한번 한 느낌이 든다. 초반에는 달아오르는 열정이되, 후반은 끈기이다. 중간에 느슨해질 거리들이 많음에도 불구하고 천천히나마 지속적일 수 있었음이 기쁘다.
- Pair 라는 것은 꼭 프로그래밍이 아니다 하더라도 여러가지 시너지를 발휘할 수 있다. 혼자서 생각하는 것보다 빠른 피드백을 받을 수 있기에. 오늘 떡볶이 먹으면서 아이디어 궁리할때의 아이디어들이 모이고 상대방에게서 반응을 들어보고 덧붙여지고 의외로 새로운 아이디어가 창출될때의 그 느낌이란. --1002
10.2 (수) ¶
- Advanced Search
- Mypage 에서의 Best Point 순위.
- 검색 결과 리스트에 대해 페이지 나누기
10.1 (화) ¶
- 정규표현식 파싱 부분 일부 수정.
- UI 디자인 궁리.
9.30 (월) ¶
- Test 깨진 것 마저 수정. 테스트들 추가.
- UnitTest 들이 드디어 다시 녹색바. 그리고 서블릿에 있던 로직 부분을 Extract, 테스트들을 붙여줌.
- UnitTest 들이 드디어 다시 녹색바. 그리고 서블릿에 있던 로직 부분을 Extract, 테스트들을 붙여줌.
- Test 마저 고치는 중, 내가 당연하다고 생각되었던 Test 가 깨진 문제 분석이 실제로 틀렸음을 알게 되었다. 상민이 덕택에 의외로 30분 내로 간단히 해결되었다. 오랜만에 AcceptanceTest 포함 80여개 테스트가 녹색불을 켜게 되었다.
- 한동안 PairProgramming 할때 주로 관찰자 입장에 있어서인지. (이상하게도. 창준이형이랑 할때나 상민이랑 할때나. 그나마 저번 르네상스 클럽때는 아무도 주도적으로 안잡아서 그냥 내가 잡긴 했지만, 다른 사람들이 적극적으로 나서지 않을때엔 웬지 그 사람들과 같이 해야 한다는 강박관념이 있어서.)
그렇다고 이 상황을 다른 사람에게 말로 하면 당연히 '응. 그래. 다음번에는 주도적으로 잡아' 라고 하지만. 한동안 손가락이 쉽게 가지 않을 것 같다. 개인적인 문제일까. 아직 현상에 대한 분석이 잘 안되는중이다.
- 서블릿 레이어부분에 대해서 Controller 에 Logic 이 붙는 경우 어떻게 Test 를 붙일까. (FacadePattern 을 생각하고, 웹 Tier 를 따로 분리하는 생각을 해보게 된다.) --1002
9.27 (금) ¶
- Test 깨진 것 수정하기.
Test 들이 있으면 확실히 좋은점은, 깨진 테스트들이 To Do List 가 된다는 점이다. 복구순서는? 깨진 테스트들중 가장 쉬워보이는 것이나, 그 문제를 확실하게 파악했다고 자부하는 테스트들을 먼저 잡고 나가면 된다.
- 근데, 해놓고 나서 커밋할 생각이.. 좀 안나긴 하다. 한편으로는 Test 들을 통과하니까 둘이 서로 정한 의도대로 한 것이니 상관없다는 생각. 하지만, 한편으로는 'Pair 로 한 것이 아닌데..' 하는 생각. 그냥 Spike 버전 정도로 생각해둘까나.
9.25 (수) ¶
9.3, 9.4 (화,수) ¶
- Recommender, lightView, heavyView service 작성. view 추가.
(그래서 수요일날에는 프로그램 작성전 Menual Test 방법을 먼저 생각해두고, 프로그래밍 작성을 하는 식으로 접근함)
- 대안을 생각중인데, 일종의 Facade 를 만들고, Controller 의 각 service 들은 Facade 만 이용하는 식으로 작성하면 어떨까. 그렇게 한다면 Facade 에 대해서 Test Code 를 작성할 수 있으리라 생각. 또는, Servlet 부분에 대해서는 AcceptanceTest 의 관점으로 접근하는 것을 생각. 또는, cactus 에 대해서 알아봐야 하려나.. --1002
- 문제에 부딪치고, 그 문제가 해결될꺼 같이 보이면서, 아슬아슬 버티면 내일 해결해야 한다. --상민
8.24(토) ¶
- Recommender 부분 완료 (연관된
~cpp BookMapper
,~cpp UserMapper
의 기능 작성 완료)
8.23(금) ¶
- Object-Database 연동을 위한
~cpp BookMapper
,~cpp UserMapper
작성
Object-RDB Mapping 에 대해서는 PatternsOfEnterpriseApplicationArchitecture 에 나온 방법들을 읽어보고 그중 Data Mapper 의 개념을 적용해보는중. Object 와 DB Layer 가 분리되는 느낌은 좋긴 한데, 처음 해보는것이여서 그런지 상당히 복잡하게 느껴졌다. 일단 처음엔 Data Gateway 정도의 가벼운 개념으로 접근한뒤, Data Mapper 로 꺼내가는게 나았을까 하는 생각.
DB 쯤 되고 나니, Test 들의 보폭을 줄이는게 힘들어지는것 같다. (그리고..; 사람들이 잘 안줄이려고 하는것 같다;) TDD 가 좀 더 활성화되러면 학교 컴퓨터들이 더 빨라져야 한다고 개인적으로 생각중 -_-;
DB 쯤 되고 나니, Test 들의 보폭을 줄이는게 힘들어지는것 같다. (그리고..; 사람들이 잘 안줄이려고 하는것 같다;) TDD 가 좀 더 활성화되러면 학교 컴퓨터들이 더 빨라져야 한다고 개인적으로 생각중 -_-;
8.21(수) ¶
- Recommender 구현중 User 클래스의 구현
~cpp UserTest
구현
~cpp RecommenderTest
의 테스트 수행중
- AcceptanceTest login , view page 테스트 추가
어차피 AcceptanceTest 관련 코드의 경우 Server 프로그램과 독립적으로 돌아가기에 그리 걱정하지 않아도 상관없을듯. 소스는 CVS에 올려놓고 있으니 시간있을때 확인하셔도 좋을듯. --1002
- 목소리를 키울때는 늘 민감함이 앞선다. 처음 목소리를 키우다가 다시 소극적으로 되려고 할때 의자 끌고 Pair 자리에 앉히는 상민이를 볼때 내가 어린아이같다는 생각도 해본다. 늘 실천보다 불평이 앞서는 1002이기에 -_-; 아쉬운점이라면, 소스의 Complexity 가 높아질수록 Test 의 보폭을 줄이는데 힘들다는점. 오늘 창준이형과 Pair를 하던중. Observer 의 역할일수록 전반적인 숲들을 잘 관찰하고 Driver 를 도와줘야 한다는 점을 되새기면서.
- 내가 잘못하면 직접 욕해줘 나 오래 살게 --상민
- 내가 잘못하면 직접 욕해줘 나 오래 살게 --상민
- Python 의 ClientCookie 모듈의 편리함에 즐거워하며. Redirect, cookie 지원. 이건 web browser AcceptanceTest를 위한 모듈이란 생각이 팍팍! --1002
8.13(화) ¶
- SimpleSearch -> ViewBook 으로의 구현
- SearchListExtractorRemoteTest 추가
- 발견된 문제나 사항 인상 깊은점
- 도서관은 303건 초과 리스트를 한꺼번에 요청시에는 자체적으로 검색리스트 데이터를 보내지 않는다. 과거 cgi분석시 maxdisp 인자에 많이 넣을수 있다고 들었던 선입견이 결과 예측에 작용한것 같다. 초기에는 local 서버의 Java JDK쪽에서 자료를 받는 버퍼상의 한계 문제인줄 알았는데, 테스트 작성, Web에서 수작업 테스트 결과 알게 되었다. 관련 클래스 SearchListExtractorRemoteTest )
- 목록검색에서 검색 이력이란 메뉴가 있는데, 도서관쪽에 해당 ip에 대한 캐싱 결과에 대하여 나와있다.
- 도서관은 303건 초과 리스트를 한꺼번에 요청시에는 자체적으로 검색리스트 데이터를 보내지 않는다. 과거 cgi분석시 maxdisp 인자에 많이 넣을수 있다고 들었던 선입견이 결과 예측에 작용한것 같다. 초기에는 local 서버의 Java JDK쪽에서 자료를 받는 버퍼상의 한계 문제인줄 알았는데, 테스트 작성, Web에서 수작업 테스트 결과 알게 되었다. 관련 클래스 SearchListExtractorRemoteTest )
8.10(토) ¶
- 마이너리티리포트 보러 가기~
- Server Refactoring
- Code Review 로서 Refactoring 이 이용된다고 했다시피, Refactoring을 해 나가면서 전체 프로그램의 그림이 좀 더 이해가 갔다. 한동안 해당 프로그램에 대해서 플밍 리듬을 놓쳤을때 Refactoring 을 시도하는것도 좋은 전략이라 생각.
- Task 를 작성할때 Refactoring 을 명시적으로 써 놔야 하겠다. Acceptance Test 처럼. 써놓지 않으니까 잊어먹고 자주 안해준 것 같다. 그리고 생각보다 시간이 걸리는 만큼. (이건 Refactoring 을 플밍 중에 자주 해주지 않아서인것 같다. 2시간정도 걸렸으니)
8. 8(목) ¶
- DB Schema 궁리 & Recommendation System 을 DB 버전으로 Integration 시도
- Pair 중간에 1002 는 목소리가 커질때가 있다. 하나는, 내가 놓치고 있을 경우에 대해 다른 사람이 이야기를 제대로 안해줬다고 생각되는 경우. 뭐 보통은 1002의 잘못을 다른 사람에게 떠넘기기 위한 방편인 경우가 많다 -_-; (찔린다; 나도 JuNe 형이랑 Pair 할때 무방비상태인 경우가 많아서;) 뭐, 같이 무방비였다가 못느끼고 넘어간 경우라면 아하~ 하면서 플밍하겠지만, 하나를 고치고 나서, 다른 사람이 당연한 듯이 좋은 방법으로 해결해낼때엔. ("왜 아까는 이야기안해?" "당연한거잖나."). 일종의 경쟁심리이려나. 에고 를 잊어야 하는게 PairProgramming 이지만, 사람 마음이 그렇기엔 또 다른것 같다. 코드 기여도에 대해서 보이지 않는 경쟁이 붙는다고 할까나.
- 내목소리가 커질경우에는 다른 사람이 위축이 된다. 그 사람이 잘하고 있다 하더라도. 한편으로는 '당신의 능력을 보여주세요'; 자신의 코드에 대해서 자기 이야기를 했으면 하는 생각. 목소리를 줄이거나, '한번 흘러갈대로 해봐라' 라는 식은 자신의 생각을 코드에 붙일 수 없게 되므로 좋지 않은 경우라고 생각.
- 리듬이 깨졌다라는 느낌이 들때. 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 의 경우를 이용할 수 있을것 같다.
- TestCase 만들어 둔것을 상속 받아서, 다시 다른 테스트를 수행 시키는 기법이 정말 흥미로웠다. 진짜 신기하다. 생각하면 할수록 신기하다.
- 문헌 정보 학과의 관련 자료를 석천이랑 가서 보았는데, 또 다른 지식의 세상이 있음을 알수 있었다. 수백년간 구축해온 진정한 KM을 느낄수 있었다.
8. 7(수) ¶
- test 관련 패키지 정리
- test
~cpp TestCase
- tests
~cpp TestSuite
모음
- 모든
~cpp TestCase TestSuite
는 독립적으로 실행할수 있다.
- test
~cpp AllLocalTests
내에
~cpp BookContainerLocalTest
( 테스트 작성 시작, DB연동 부분 생각해야 함 )
~cpp BookWebLinkerTest
(대상 서점 Amazon, Aladin, Wowbook)
~cpp ViewBookExtractorTest
(~cpp LendBookList
와 연계하여 테스트 추가 )
~cpp AboutLendBookTests
~cpp LendBookListTest
~cpp LendBookTest
8. 6(화) ¶
현재 요구사항에 따라
- UserStory 정리 & Engineering Task 재정의
정말로 학교가 우리를 안도와주기로 작정한것 같다. 도서관 서비스 개편된다고 했고 -_-(이는 곧 정규표현식 쓴 부분과 관련하여 재작성하라는 뜻이니;) 게다가 다음주부터 엘리베이터 수리 들어간단다. 경비아저씨에게 5층 신피 열어달라고 부탁하는것에 대해 더 눈치를 봐야 한다는 뜻이 된다; 으어;
8. 5(월) ¶
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에선) 그러면서 느끼는점이라면,
GJ가 도입되면 IBM의 Incremental Compile도 무용지물 아닐까. --상민
7. 25(목) ¶
- login 부분 작성
- Python Prototype 을 Java 로 바꾸기
- 예전에 일할때 잘못했었던 실수를 다시하고 있으니, 바로 기획자와의 대화이다. Iteration 이 끝날때마다 개발자가 먼저 기획자 또는 고객에게 진행상황을 이야기해야 한다. 특히 ExtremeProgramming 의 경우 Iteration 이 끝날때마다 Story 진행도에 대화를 해야 한다. Iteration 3 가 넘어가고 있지만 항상 먼저 전화를 한 사람이 누구인가라고 묻는다면 할말이 없어진다. 이번 Iteration 만큼은 먼저 전화하자;
- 'Iteration 3 에서 무엇은 되었고 무엇은 안되었는가?' 지금 Iteration 3 쪽 Task 가 아직도 정리 안되었다. Task 정리를 하지 않고 Iteration 3 를 진행한 점은 문제이긴 하다. (비록 구두로 개발자들끼리 이야기가 되었다 하더라도. 제대로 정리를 한다는 의미에서.) Iteration 3 Task 정리 필요. 그리고 나머지 Iteration 에 대한 Task 들에 대해서 예측할 수 있는것들 (슬슬 눈에 보이니)에 대해 추가 필요.
- 아이스크림 잘먹었어요. 감사감사
- 최근들어서 전혀 글을 쓰고 있지 않다. 아날로그든 디지털이든.. 책을 보면서도 저자와 교감을 얻을 만한 부분에서 벅차오르고, 머리속으로 해당 생각을 10~15분 가량 정리한 이후 그것으로 끝이다. 일종의 슬럼프일까.
- 내일까지 신피의 네트웍이 안될까 걱정이다. 오늘의 일은 도저히 예측할수 없었던 일종의 사고이다. 나비의 날개짓은 어디에서 시작되었을까 생각해 본다. MIB Programmer가 되고 싶지만 그마저 시간이 부족한것이 현실이다.
- 아이스크림은 ...
7. 22(월) ¶
- Iteration 2 에 대해 밀린 것 마저 진행.
- Iteration 3 에 대한 Planning
- 학교에서 PairProgramming 이 정착될 수 있을까. Pair 를 하는 중 대화가 좀 커져서 그런지 저 너머쪽의 선배가 주의를 주었다. 뭐.. 변명거리일지 모르겠지만, 자신의 바로 뒤에서 게임을 하고 있는 사람은 자신의 일에 방해가 되지 않고, 저 멀리서 개발하느냐고 '떠드는 넘들' 은 자신의 일에 방해가 된다.
- 한편으로 또 드는 생각은 아무리 우리가 공부를 하네 위키에 문서를 남기네 해도, 결국 저 사람에게는 '그저 저넘들 자기만족을 위한 행위' 그 이상이 아니라는 것. 피시실에서 게임을 하나 프로그램 개발을 하나 그저 '타인의 행동' 이상의 의미가 없다란 느낌이 들고 나니 서글퍼진다. 순간 울컥 하는 마음에 속으로 '차라리 자극 좀 받아보시고 거기 깔린 오락 좀 지워보시지. 젠장' 라고 읊어대었다. (갈수록 건방짐 높아져가는 1002. 솔직히 좀 화가 나서리..) 개인적으로 피시실이 사람들이 서로 개발이나 공부를 위해 시끌벅적한 작은 팀들이 많이 있고, 그 분위기에 다른 사람들이 조금이나마 휩쓸렸으면 하지만. 그러한 팀들은 늘 레포트가 나오던지 팀프로젝트가 나오던지 해야 만들어지려나.. 거참 엄청 재미도 나겠군. 역시 이상일 뿐이려나. (화이트보드 큼지막한 것이 있어도 우리가 알고리즘 구상하느냐고 써놓은 것들이 3-4일째 그대로이군.)
-- 1002
7. 20(토) ¶
- Iteration 2 에 대한 SpikeSolution 계속 진행
- 중간 알고리즘부분에 대해서 혼란상황이 생겼다. 처음 TDD로 알고리즘을 디자인할때 view / light view / heavy view 에 대한 point를 같은 개념으로 접근하지 않았다. 이를 같은 개념으로 접근하려니 기존의 알고리즘이 맞지 않았고, 이를 다시 알고리즘에 대해 검증을 하려니 우리의 알고리즘은 그 수학적 모델 & 증명이 명확하지 않았다. 우리의 알고리즘이 해당 책들간의 관계성을 표현해준다라고 우리가 주장을 하더라도, 그것을 증명하려니 할말이 생기질 않았다. 수학이라는 녀석이 언제 어떻게 등장해야 하는가에 대해 다시금 느낌이 오게 되었다.
- PyUnit 의 ok.
7. 19(금) ¶
- Iteration 2. Recommendation System 에 대한 SpikeSolution
알고리즘에 대한 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 를 맡는다.
7. 18(목) ¶
- Iteration 1 에서 못한 일들 마저 함. AcceptanceTest 작성.
어떤 한글 문제?
똑같은 코드를 Jython 으로 돌릴 경우 POST 로 넘긴 한글 keyword 가 제대로 넘어가질 않아요. 인코딩을 바꿔주면 될 것 같은데 못찾아서;--1002
- Jython은 기본적으로 모든 스트링을 유니코드로 처리함. 따라서, 해당 스트링을 euc-kr로 인코딩한 다음에 파라미터 전달을 하면 제대로 됨. 인코딩을 바꾸기 위해서는 파이썬 euc-kr 코덱(pure python 버젼)을 깔고,
~cpp '한글'.encode('euc-kr')
을 쓰거나, 아니면 자바의 String.getBytes나~cpp OutputStreamWriter
등을 쓰면 될 것임. --JuNe
- 돌아가는 환경의 기본 인코딩을 설정해주면 될 듯 함. Jython이 자바로된 클래스를 바로 쓴다니, Writer 객체를 얻을때 인코딩 설정을 해주면, 해당 Writer로 빠져나가는 내용은 설정된 인코딩을 적용받음. 받아들일때도 마찬가지로, POST로 넘어온 값을 매번 인코딩 할수도 있겠지만, 그보다는, 시스템에 직접 명시해줘서 일괄적으로 바뀌는 방식을 추천함. 예를들자면, contentType="text/html; charset=euc-kr" 하는식으로 설정할 경우, 얻어오는 값들은 euc-kr로 인코딩된 값을 얻어올 수 있음. --이선우
- Tare씨께서 작업하는 모습을 보고 싶다면서 오셨다. 작업하는 동안 우리가 거의 대화를 걸지 않고 우리끼리 계속 작업에만 몰두했음에도 불구하고, 뒤에서 작업하는 모습을 끝까지 지켜보시는 모습을 보면서 한편으로 신기했다. 다른 사람들이 어떠한 과정으로 작업하는가를 알기 위해 저렇게 관찰하는 사람이 있을까? 어떠한 얻음을 얻으셨을지 모르겠지만. 그의 자세는 참 인상적이였다.
- Iteration 1 에서의 결과를 오늘 보여드리고 Iteration 2 에 대한 회의를 해야 할때임에도 불구하고, 직접 오셨는데 별다른 결과물을 보여들이지 못해서 참 죄송했다. 이번주 MT 가 있었다 하더라도, 변명이란 없음. --1002
7. 12(금) ¶
- HTML 문서 가져오는 클래스 (Spider) 작성
- HTML Parsing
- 도서관 검색 결과 Object 로 추출, 다시 HTML 생성.
중간에 상민은 메모장을 열었고 ..... 부분에 대해 코드를 적었다.
그리고 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' 등 이고..' 등등)
CRC가 잘 추출되지 않을때는 차라리 UserStory를 따라가면서 클래스를 만들고, 거기에서 다시 CRC를 생각해 보는 방법이 시간 절약에 현명할 것이라고 생각된다. 객체 지향 의 프로그래밍을 추구해온 결과, Scenario나, UserStory를 따라가며 코딩하면서 수많은 클래스들이 책임에 따라서 생겨나는 것을 보면서 자연 스러움과, 약간 의아함 마져 들었다.
왜냐면, 데블스 캠프 금요일 시간이 끝나고 나서 7층에서 석천이와 UserStory를 따라가며 만들어진 RandomWalk2 CRC의 모습에서는 단 3개만의 클래스만이 존재하였다. 하지만, UserStory를 따라가면서 소스 수준의 코딩을 하면 더 많은 클래스로 분화할것을 기대한다. 즉, 코딩을 하면 어쩔수없이 Layer의 최 하위까지 내려갈수 밖에 없으리라고 본다. 자 그럼 문제는 레이어 일것이다. 다행히 현재 코딩된 부분은 전부 logic의 부분으로 취급하고 있지만, logic 내에서 다시 레이어로 나뉘어서 외부에서 접근할수 있는 인자와 없는 인자로 나뉘어 져야 할것이다. 여기서 잠시 기억되는 말
ObjectWorld 의 전 세미나에서 아키텍트 설계자는(Architector) 소스를 가지고 디자인을 생각하는 사람이 아니라, 디자인(스펙으로 제시된)을 보고 디자인(자신의 회사에 맞는)을 만들수 있는 능력을 가진 사람이라고 말하였다.
우리가 처음 망설이던 부분의 CRC가 그런 케이스라고 생각된다. 소스 까지 접근하지 않은체, Layer-Tier를 생각하면서 책임을 부여할때, 나가지 않는 진도에 답답해 하며 꺼낸 메모장이 재미있는 결과를 가져다 주었다. 다음 같은 상황이 되면 스트레스는 훨씬 줄어 들것으로 생각한다.
마지막으로 석천이의 의견이 먼저 올라오길 기다린 나는 나쁜넘이다. 흐흐흐
--상민
마지막으로 석천이의 의견이 먼저 올라오길 기다린 나는 나쁜넘이다. 흐흐흐
--상민
- UserStory 와 사용자 시나리오를 혼용해서 쓴 것 같은데, UserStory Page 를 참조.
- 소스 수준 코딩시 더 많은 클래스들이 분화되는 이유는 CRC 중 클래스와 클래스 간 대화를 할때 넘기는 객체를 따로 표시하지 않으니까. (우리가 7층에서의 RandomWalk2 보면 Class 와 Class 간 대화를 위한 클래스가 4개쯤 더 있음)
- 그리고 'Layer' 의 뜻이 모호하긴 하군. 'Abstract Layer', 디자인에 대한 추상화 정도를 이야기하시는것임? (문맥상 일단 그렇게 해석하는중)
- 같은 의도 --상민
- 그럼 고쳐. --1002
- 그럼 고쳐. --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
- 말로 걸러지고 글로 걸러지고 하루 지나서 기억력으로 걸러진 데이터는 '손실' 이겠지. 위의 '......' 부분은 그때 이야기했었던 자세한 대화내용이 기억이 안나서 그냥 저렇게 쓴 것일 뿐인데. 오해했다고 생각한다면 그 부족한 기억을 채워주면 안되나. --1002
- 아직도 내가 메모장을 핀걸 가지고 가진 생각을 오해하는거 같은데 이해가 안간다. 같은 이야기를 정말 많이 한거 같은데 절반 정도 의도 전달이 된듯 하다. 남은 절반은 여백의 미 --상민
7. 10(수) ¶
- CollaborativeFiltering 에 대한 알고리즘 논의
- Book Search Iteration 에 대한 구체적인 Task 설정.
- Python, webdebug 를 이용, ProjectPrometheus/LibraryCgiAnalysis Task
- HttpURLConnection 을 이용, HTML 문서 가져오기 Task
Python Interpreter 는 말 그대로 'shell' 이다.; command 대신 쓰고 살까.. Python 과 webdebug 을 이용, 도서관 웹 사이트에 GET/POST 으로 데이터를 보내는 부분에 대한 분석은 참 편했다. (단, Python shell 에서의 encoding 부분에 대해 충돌나는건 골치)
--1002
--1002
옆에서 파이썬으로 proxy돌리고, Web debug하는 것이 멋지게 보였다. 파이썬에서 느껴지는 즉시성은 언제나 나로 하여금 경탄을 자아내게 한다. 비록 내가 겉으로는 표현이 부족할지라도...
HTTP에서 문서를 가지고 오는 것에 관하여 딱히 결론을 내릴수가 없었다. 도서관측의 잘못이 아니었을까 하는 생각이 뿐이다. zp서버에서는 get과 post 가 잘되는데 반하여, 도서관이 이상하다. 현재는 11일이며, 석천이와 이야기 끝에 적절한 선에서 타협하기로 하였다. 더이상 시간을 쏟기에는 너무 아깝다. --상민
7. 9(화) ¶
1002 ¶
그러다가 나중에 '이전에 생각했었던 CRC 세션에서의 디자인과 다르다' 라 판단, 다시 CRC 세션을 가져서 디자인을 하게 되었다. 앞의 경우가 MVC Architecture에 대한 디자인이 나왔다 한다면, 후자의 경우는 실제 Logic 부분에 대해 더 구체화된 (하지만, Java Web Architecture 와는 상관없이 일단은 일반 어플리케이션과 같아보이는) 디자인이 나왔다.
즉, 앞의 디자인의 경우 JSP 페이지들의 네이밍에 Logic 디자인이 영향을 받았다고 할까. 뭐, 어차피 구현부분은 제대로 생각하지 않은 Conceptual Model 에 가까운 것이였지만, 후자의 경우 데이터 클래스와 그 책임을 맡은 클래스들이 더 명시적으로 드러났던것 같다. 전자의 경우도 '이 기능을 맡은 클래스야' 하면서 Responsibilty 식으로 접근하려고 노력했지만, 후자의 경우가 그 용어면에서 더 추상적이였다. (전자의 경우 그 이름이 시스템을 드러내려고 했다.)
neocoin ¶
~cpp MVC-WebProgramming
의 설계 접근을 하면서 OOP에서 느껴지는 책임에 따른 의인화가 암묵적으로 막아져 버린듯 하다.7. 8(월) ¶
- 한일 : 요구정의 정리, UserStory와 Scenario 혼용, 확인 부족한 스펙 부분 발견, 개발환경 정의
- neocoin: 마땅히 해야 할일을 했다고 느꼈다.
- 마땅히 해야 할 일. 그 일을 해야 할때 무엇을 해야 할지 한큐에 생각이 나지 않는다는 점, 그 일을 해야 할 때, 시기를 놓친다는 점이 아쉽다고 한다면 뒷북일까.(글 늦게 쓴 사람의 여유;) -- 1002
- 마땅히 해야 할 일. 그 일을 해야 할때 무엇을 해야 할지 한큐에 생각이 나지 않는다는 점, 그 일을 해야 할 때, 시기를 놓친다는 점이 아쉽다고 한다면 뒷북일까.(글 늦게 쓴 사람의 여유;) -- 1002
- 지난번에 받았던 요구사항정의된 글들을 (그때 글들을 미리 스캔해두었었다.) 다시 보면서 다시 정리를 하였다. 어떠한 순서로 할까 하다가 일단 사용자의 기준으로, 사용자들이 이용하는 기능(Functional)과 퍼포먼스 관련 (Non-Functional) 부분으로 생각했고, 주로 Functional 한 부분을 기준으로 사용자 시나리오를 작성하면서 요구사항들을 정리하였다. 그러면서 지난번 Requirement 를 받을때 수동적 자세로 있었음을 후회했다. 5일이 지난뒤 정리하니까 이렇게 머리가 안돌아가나;
"여기서 Recommendation System 이 작동해야 할 부분이 들어가면 안되겠는데... 본래 의도는 검색이 되고 난 뒤 책 관련 정보가 나올때 RS 가 작동하여 같이 표시가 되어야 해."
- 부족하다고 생각되어지는 점
- Engineering Task 가 아직 명확치 않다. Engineering Task 를 지금 일단 간단하게 생각하는게 나을까 아니면 Architecture Design 뒤에 더 구체화해서 쓰는게 나을까 궁리중. 일단은 전자를 먼저 간단하게나마 궁리.
- AcceptanceTest 방법에 대한 논의 부족 - 수요일 이전까지 궁리 예정; 흐..흐;
- Engineering Task 가 아직 명확치 않다. Engineering Task 를 지금 일단 간단하게 생각하는게 나을까 아니면 Architecture Design 뒤에 더 구체화해서 쓰는게 나을까 궁리중. 일단은 전자를 먼저 간단하게나마 궁리.
7. 3(수) ¶
1002 ¶
- Requirement 를 받았다. Requirement 를 받기전에 너무 준비를 소홀히 했다라고 생각한다. Requirement 를 받는대에도 미리 계획을 세웠어야 했는데. 차라리 전에 이용하던 UserStory 작성 -> 대강의 EngineeringTask 궁리 -> EngineeringTask 에서 공통으로 겹치는 부분 / 큰 부분 나누기 -> Estimate 결과 작성 이라도 시도해볼걸 이란 생각이 든다. Requirement Process 에 대해서 꼭 비격식적이더라도 구조적인 방법을 생각해볼 필요가 있단 생각이 들었다. (너무 허둥지둥했던 것을 생각하면.)
- Requirement 를 받을때 팁 - 이미 구현이 되었다고 상정해보기. 과거형말하기 (완료형으로 말하기)
- AnalyzeMary . 상민이와 내가 같이 있을때의 관찰되는 모습을 보면 재미있기도 하다. 내가 거의 구조를 잡지 않고 프리핸드로 Requirement 를 적어갔다면 상민이는 Mind Map 의 룰을 지켜서 필기해나간다.
또 하나 상민이에게 빼놓을 수 없는 것이라고 한다면 저번학기부터 쓰던 Letter 사이즈의 (맞나. 대강 크기가) 작업일지. 그리고 Post It. 집에서 IR 를 쓰긴 하지만, 주로 밖에서 작업하고 집에 늦게 오기때문에 곤란한 점이 있다. 들고 다니면서 간편한 정보관리도구에 대해 궁리해볼 일. (또는 PC7 에 IR을;)
neocoin ¶
EJB의 효용성에 관해서, EJB로 가야하는지 말아야 하는지 망설여질때 도움을 주는 체크 리스트, 그리고 IR은 아마도 http://no-smok.net/nsmk/InformationRadiator 일듯 --이선우
ProjectPrometheus/Journey