'IT서평'에 해당되는 글 23건

  1. 2008.01.30 Head First Design Patterns
  2. 2008.01.27 유닉스 쉘 바이블
  3. 2008.01.23 아키텍트 이야기 1
  4. 2008.01.20 유닉스 리눅스 명령어사전 1
  5. 2008.01.13 Ruby on Rails : 초고속 웹 개발의 시작
  6. 2008.01.10 생각을 바꾸는 패턴 2
  7. 2008.01.03 엔터프라이즈 자바 애플리케이션 구축 : 아키텍처
  8. 2007.12.30 엔터프라이즈 솔루션 아키텍처 디자인 패턴
  9. 2007.12.28 쓰디쓴 자바 : 자바 안티패턴 이야기들(BITTER JAVA)
  10. 2007.12.18 Ajax 입문 : Asynchronous JavaScript + XML


Head First  시리즈는 읽기 쉽고 가볍고 날렵하다는 이야기를 많이 한다.
실제로  Head First java의 경우에는 나에게 있어 쉽고 재미있게 다가왔다.
하지만 이번에는 다른 녀석이 나타났다!
바로 Head First Design Patterns 이 바로 그녀석이다.

깔끔하고 재미있는 표지는 "어서 날 잡아들고 펼쳐봐" 라고 유혹하기에 충분했다.
디자인 패턴에 대한 다양한 경험도 점검해보고 싶은 터라 내가 주로 이용하는 패턴 이외에
것을 보고자 책을 펼쳐 들었다.
그것도 할일많은 프로젝트 기간에.. 그것도 한참 바쁜와중에 겁없이 말이다.

책은 Head First 시리즈가 다 그렇듯 매우 익살맞고 재미있게 내용이 전개 된다.
언급한 디자인 패튼 15가지에 대해 다양한 예를 들어 책을 읽는 독자의 머리속에 쏙쏙 들어갈줄 알고 설명하고 있다.
물론 예제들은 잘 이해가지만 역시나 UML을 보고 소스코드를 그려내는 과정에서는 과자먹듯 쉽지는 않다.

책에서 등장하는 패턴 (15개)
 - 스트래티지 패턴 : Duck라는 오리를 날려보고 , 모형오리를 만들어보고, 로켓 오리도 만듭니다.
 - 옵져버패턴 : 기상예보 시스템을 모바일에다 쏴주는 예를 들어줍니다.
 - 데코레이션 패턴 : 커피숍에서 커피에 올라갈 토핑을 놓고 패턴을 설명을 합니다.
 - 팩토리 패턴 (추상) : 피자를 굽는데요. 피자를 얼마나 효과적으로 토핑하는지 가지고 설명하네요
 - 팩토리 패턴 (팩토리매서드) : 피자가게가 번성해서 지역 채인망을 만들어냅니다.
 - 싱글턴 패턴 : 초콜릿 만드는 공장에서 500겔런이나 되는 시럽을 망친 이야기를 해주네요.
 - 커맨더 패턴 : 똑똑한 웨이트레이서가 등장합니다.
 - 어뎁터 패턴 : 역시나 모두가 예상하는 돼지코가지고 이야기를 하네요.
 - 퍼사드 패턴 : 어뎁터에 조금더 기능을 확장합니다.
 - 템플릿 메소드 패턴 : 커피만들기와 홍차만들기 차이가 뭐가 있다고!! 이걸 합해봅니다.
 - 이터레이터 패턴 : 훌륭한 웨이트레이서가 또 등장합니다. next(), hasNext()
 - 컴포지트 패턴 : 웨이트레이서가 살짝 나오지만 중요한것은 객체를 tree형태로 관리한다는거죠
 - 스테이크 패턴 : 왕뽑기 게임 ㅋㅋ (그냥 좀 특이합니다)
 - 원격프록시 패턴 : 여기서는 일반프록시를 위해 RMI를 이야기 하고 가상프록시도 다룹니다.
 - 컴파운드 패턴 : 지금하는 WEB의 MVC가 여기에 해당한다고 하는군요
 
 물론 용어적 차이는 있겠지만 내가 살펴보고 알아본것은 이렇게 15개에해당한다. (더 숨어있긴 합니다만..)
 모두들 적당한 예를 들어주고 적당한 이해를 위해 다양한 등장인물들이 나타나 디자인 패턴을  이야기 한다.

책을 소비하는 다양한 계층을 위해 좀 힌트를 주려한다.
책을 공부할 사람은
http://www.wickedlysmart.com/HeadFirst/HeadFirstDesignPatterns/HeadFirstPatternsIndex.html
에서 코드를 받아다가 실행해보거나 타이핑 해가면서 했으면 한다.
때로는 소스코드를 먼저 보고 패턴을 이해해 역발상의 학습방법도 효과적이니 말이다 .

내경우 스트래티지 패턴에서는 타이핑해가며 추상객체가 interface를 만나게 되면
얼마나 재미있는 일이 벌어지는지를 봤었기 때문에 적어도 타이핑 하기 쉬운 몇장은 해봤으면하는
가이드를 주고 싶다. 
아! 옵져버패턴까지만 타이핑 했다. 이후부터는 녹녹치 않은 양이 기다리고 있어 그냥 책만 보게 되었다.

하지만 책을 이렇게 갈아마시고 뇌속에 흡수시키실 분이 아니라면 (누군지는 아시겠죠?)
그냥 자신의 입담으로 적당히 책을 봤다고 이야기 하고 싶은 사람이라면 617페이지부터 보시길
바란다.

그곳에는 디자인 패턴에 대한 고상한 용어들과 GoF 4인방의 맴버들 이름이 언급되어있다.
(실제로 이들의 이름을 알고 있고 이들이 GoF라는것 가지고 마치 자신이 IT를 잘 아는적! 훌륭한척 하는
못봐줄 분들 참 많습니다. 님들! 제발 좀~!!)(에릭감마도 기막혀서 웃을꺼에요)

개인적으로 이렇게 가볍게 봤다 진진하게 본 책은 몇권 안되는데
Head First Design Patterns은 정말이지 신선하게 다가 왔다.
IT책들이 딱딱하고 부드럽지 않아서 잘 이해가 되지 않는다고 말하지만
내경우에 이책은 부드럽지만 쉽게 갈아마시기에는 결코 가벼운 책은 아니였다고 말하고 싶다.

책 추천자들은 화장실에서 봤다는둥 하루만에 봤다고 하지만 나는 아직도 배워는 중이라 좀 시간이 걸렸다.
중요한것은 책을 몇일만에 봤다는게 아니다.
책을 이해하고 얼마나 실전에 잘 이용하는냐가 중요할것으로 보인다.

끝으로 이책에서 말하는 진짜 디자인 패턴의 정의를 다시 언급하려고 한다.
"패턴이란? 특정컨텍스트 내에서 주어진 문제의 해결책이다. " (617Ppage)
 > 특정컨텍스트 : 반복적인 일을 줄여냄
 > 해결책 : 누구든지 적용해서 일련의 제약조건 내에서 목적을 달성하는것

모두가 패턴 황재가 되라는게 아니다.
모두가 이해하는 효율적인 코드.. 그것이 디자인 패턴이 바라는 궁극적인 해답이라고 생각한다.



책을 처음 소개받고 "반드시 사야겠다." 라고 느낌을 받는경우는 참 드물다.
하지만 이책의 경우에는 만사를 재쳐두고 사야겠다라는 생각이 들었다.

최근에 들어 나의 업무 특성상 Shell을 많이 만져야 하고 대용량의 로그데이터와
java에서의 막무가내식 프로그램으로 OutOfMemoryError을 맞딱드리기 싫기때문이다.

그러면서 자연스럽게 요구되어진 소양이 쉘프로그래밍이라는 놀라운 장르였다.

처음에는 그냥 옆에서 조금 하는 분들에게 조금씩 지식을 동량질하면 되었다.
하지만 양이 차지 않았다.
그래서 "유닉스 리눅스 (명령어사전)"을 구입했다.
이책으로 인해 상당부분 애로사항은 해결이 되었다.
리눅스 상에서 명령어를 날리고 which로 명령어와 개발자가 잘 보관해둔 명령어 찾아다니
그리고 보너스 트랙같이 역어진 awk 나 let sed 명령어등으로 짧은 프로그램
짜는것이 가능해졌다.

하지만!
역시나 아직도 배가 고프다.

그렇게 해서 눈에 들어온 서적이 바로 "유닉스쉘 바이블 "이다.
지금 이 서평을 쓰면서 내가 과연 이책의 서평을 쓸만큼의 자격이 될까하는 생각이든다.
아직 다 읽어보지 못한 상태 인데 다가 책을 한번 폈을때 휘익 하니 읽어볼만큼의 내공이
되지 못한 이유에서 일것 같다.

책은 바이블 이라는 단어를 채용할 만큼 자신감으로 덮여있다.
일반적인 유닉스 쉘 명령어라면 100페이지 안에서 모든설명을 다 해놓고 있다.
그리고 나머지 1000페이지는 모두 "쉘!" 이다.

책은 매우 짜임세 있는 구조로 되어있다.
적당한 text 구문을 만들어 놓고
쉘 프로그램을 자르고 , 붙이고, 치환하고 등등의 예제를 보여준다.

물론 이것 뿐만 아니다.
    - 기본적인 변수설정에 대한 방법
    - 지역번수의 통용되는 범위
    - 라다이렉션 연산자들의 설명과 각각의 쓰임 (exec 명령으로의 확장)
    - if / for / which / case 명령어 사용방법
    - ...

 등등이 모두 sample과 예제로 그리고 [해설] 이라는 매우 독특한 코맨트를 두어서
 설명에 설명을 해주고 있다.

나도 아직 잘 모르는 이 높고 높은 우아한 세계~
이제막 발들 디디고 있는터라
이미 이곳에도 고수라는 높은반열에서 나를 이끌기 위해 책이라는 손을 내밀어
올라오라 손짓을 한다.

혹시 나와같이 쉘은 관심은 있으나 다양한 쓰임에 관심을 더 기울이고자 한다면
이책을 추천해본다.



IT프로젝트라는 오케스트라가 연주가 된다.
서서히 막이 오르고 관중들이라는 갑은 화려한 팜플렛을 보고 오케스트라를 한껏 기대하고 있다.
무대를 홀로 등지고 있는 외로운 한사람이 서 있으니 그 사람의 직위는 PL이라는 지휘자이다.

지휘자는 손님들이 표값을 얼마나 내고 들어왔는지 계급과 신분이 어떻게 되는지 모른다.
다만 팜플렛이라는 RFP에 명시된 것을 가지고 충분히 갑들에게 감동을 줘야한다.

단원들은 하나 하나 긴장한다.
어떤 단원은 연주경력이 오래되어있지만 어떤 단원은 연주경력이 너무 짧아 오선지는 못보고
오선지위에 적혀있는 코드만 보고 연주를 해야하는 실정이다.

지휘자!
과연 그대는 손님들에게 감동을 줄 수 있겠는가?
그리고 극장이여~! 이런 무거운 짐을 지고 홀로 무대를 주무를 지휘자에게 기꺼이 비용을 지불할
능력이 되는가?



아키텍트 이야기라는 책을 보면서 실무에서 만날 수 있는 여러가지 변수를 가장 근접하게 도출해 냈다는
느낌이 우선 들었다.
요구사항에 대해서 충분히 도출해 내고 고객은 요구하지 않았지만 그래도 반드시 있어야 하는
비/기/능 이라는 부분까지 명시해 가며 충분하게 뭔가를 도출해 내는것이 흡사 이땅에 존재할지 의문스러운
PL이 그려지고 있었다.

아키텍트는 정확히 무엇인가?
실질적으로 이 질문에 잘 응답하고 있는 문구는 책 213페이지에 이야기된
"엔지니어로 일한 경험이 있어야 지탱할 수 있고, 매우 성실해야만 하는 업무. 건축가 라기 보다는
목수 가운데 대목이라는 편이 가깝다" 이다.
실로 초인적인 능력을 가진 사람이 PL이 아닐 수 없다.

이런 초인은 어떠한 능력을 가져야 할지 하나 하나 손꼽고 있는게 "아키텍트이야기"의 주요핵심이다.
1. 요구분석 담당자 에게 있어 아키텍트의 역할
2. 인프라 담당자 에게 있어 아키텍드의 역할
3. 프로그래머 에게 있어 아키텍드의 역할
4. 테스트 담당자에게 있어 아키텍드의 역할
5. 운용 담당자 에게 있어 아키텍드의 역할
6. 교육 담당자 에게 있어 아키텍드의 역할

그냥 나레벨로 언급하기만 했지만 아키텍트의 업무는 생각보다 다양하고 많이 포진되어있다.
이 많은 업무에서 아키텍트는 순간순간마다 카멜레온처럼 변신해가며 프로젝트를 리딩해야한다.

휴~!!

책은 각 단락별로 세분화 시켜서 상황을 만들어 아키텍트가 효과적으로 대응하는것을 보여주고 있다.
사용하는 툴로는 UML을 사용하고 J2EE환경에 스트럿츠와 EJB를 사용하고 있다.
프로젝트 규모에 대해서 언급한바는 없지만 Document에 대해서 UML을 충분히 인식하고 있고
운용과 교육에 비중이 있는것으로 보아 국내에서 이런 프로젝트를 수행한다면 15억에서 20억 사이의
중대형 프로젝트라 볼 수 있을것 같다.
투입인력에서도 휴먼리소스를 8명을 투입한것으로 되어있으니 음.. 의심은 가지만 아키텍트가 초인이니
8명 가지고도 가능할꺼라  생각해 본다.

책을 읽은 내가 자꾸 아키텍트를 초인이라고 말하는 이유는...
아키텍트가 고객의 요구사항을 거의 90%가 넘게 수렴해주고 있으며 남는 에너지를 가지고 갑사에 다른
허덕이는 프로젝트에 아키텍트로 2중업무를 한다는 것이다.
(과연 초인 초인 ~~)

개인적으로 질의를 날려본다?
1. 과연 이런 아키텍트가 존재하는 이 미스테리한 프로젝트를 본적 있는가?
실제로 CIO가 투입된 훌륭한 프로젝트도 본적이 있다.
당시 CIO 한사람만으로 프로젝트의 상당비용이 차지하였고 리스크가 상당한부분은 프로그래머에게
전가시키는 이상한 책임 전가의 프로젝트 경험은 있다.  (다소 실망스러웠슴)
당시 개발 PL과 프로그래머들은 당일퇴근은 고사하고 "월화수목금금금" 수고했었다.

2. 한회사가 이렇게 일하는 프로젝트 본적 있는가?
전문 아키텍트를 고용할 정도의 큰 프로젝트라면 국내에서는 컨소시엄을 맺기 마련인데..
와우~! 책의 가상시나리오는 그렇지 않다.

이번서평이 다소 개인적인 생각이 들어갔지만 사실 "아키텍트 이야기" 는 이런 아키텍트가
양성되었으면 좋겠다 라는 고객사, 갑사 들의 희망사항 모음집 같다라는게 내 생각이다.

하지만 프로젝트 경험자로써 이런 책임있는 아키텍트는 분명이 양성되어야하는게 맞다.
엔지니어 출신에 고객의 신음에 귀 기울이고 비기능도 연출하고 팀원들의 상심한 마음도 달래줄
그런 아키텍트만이 정말 훌륭한 output을 만들테니 말이다.



와우~ 이책 좋다 라는 느낌을 받은 책이 몇권이나 될까?
사실 나에게 몇번의 프로젝트와 몇번의 실무를 겪으면서 머리속에 잘 저장된것이
어느순간 사려져 있을때 가장 짜증났던것으로 기억된다.

정말 열심히 수행한 프로젝트에서 얻은 기술적 노하우와 팁들은 얼마나 많은가?
DB를 핸들링한 기술, 리눅스 쉘을 핸들링 했던 그런 작은 팁들과 노하우들..
물론 프로그래밍이야 꾸준하게 하니까 그리고 계속 하기때문에 그런다 치지만
방금 말한 프로그래머이면서 가지고 있는 소양이라 할 수 있는 각종 DB, 시스템등을
운용하는 팁들은 머리속에서 재발 사리지 않기를 부탁 드리는 소망이다.

"유닉스리눅스 명령어사전"은 아는 지인으로부터 선물을 받았다.
고내하고 있기에 그분은 나에게 검색으로 익숙한 녹색표지로 된 본 책을 건내 주었다.
와우~!

내가 이책을 보고 참 감동하고 즐거워 했던 부분은 몇가지 있다.

1. vi콘솔에 대한 명령어
   vi를 이야기 하지않는 인터넷 사이트 없고, vi를 빼놓은 유닉스 교재 본적은 없다.
   하지만 실전에서 유용하게 사용하는 vi명령어를 정리한 사이트들과 책은 못 보았다.
   개인적으로 vi에서 참 있었으면 하는것이 문자열 변경하는것이 참 번거로웠다.
   쉘 프로그램 잘 짜놓고서는 변수 하나 바꾸는것 때문에 얼마나 수고를 했다던가.
   바로 이런 부분에서 책은 편리하고 쉬운 변경 작업을 sample로 알려주고 있다.
   :%s/test/test001/gc
   별것 아닌것 일 수 있다. 이미 알고 있는 사람도 계실것이다.
   그러나 나에게는 정말 필요했다.

2. find 말고 which 명령어
   알고들 계시겠지만 find도 좋은명령어이지만 쉘에서 가동중인 command를 찾는것
   역시 까다로운 일이다.
   마찬가지로 shell 작업을 수행할때 java는 어디에 있고 ant는 어디에 있는지 찾는것도
   시간이 걸리는 일이다.  (이미 오래된 경험으로 머리속에 담겼다 날라간 명령어)
   늘 그렇지만 이런것은 왜 그리 잘 잊어 먹는지 가끔 나를 탓하기도 하지만 그래서 이런류의
   책이 꾸준하게 사랑받고 있는게 아닐 까 생각한다.

3. awk
   본 명령어의 경우에도 조금 깊이 shell로 들어간다 싶으면 보이기 힘든것이다.
   패턴언어 처리인데 java를 통해 외부명령어를 구동하려고 한다면 반드시 한번즈음
   해봤었던 명령어이다.  하지만 시간이 지나면 이것도 어찌그리 잘 잊어먹는지 휴~!

책은 명령어 사전이라는 부재를 달기 딱 맞을 정도로 잘 정리된 명령어들을 보여주고 있다.
고마울정도로 찾기 쉬운 구조와 sample이 잘 되어있기 때문에
아마 개발자나 SE나 유닉스나 리눅스로 shell 혹은 command를 다루는 사람의 책상
곁에는 있어준다면 언제나도 좋은 조언자가 되어주는 책인것 같다.

최근에 들어 점점더 높은 요구사항을 접하게 된다.
어렵다거나 넘지못할 산들이 아니다.
다만 쓸데없이 찾아다니는 내가 불편하고 안타깝기 때문이다.

개발자에게 운영자에게 가장 가치있는것은 시간을 줄이는것이 가장 가치있는게 아닐까 생각한다.
그렇게 본다면 "유닉스 리눅스 명령어 사전" 의 경우에는 개발자의 많은 시간을 절약해 주는
고마운 책임에 틀림없다.

추가...
 Oracle은 나와있고 mySQL정도는 나와줘도 훌륭할텐데..


진화라는것은 불필요한것을 줄이고 장점인 부분을 더욱 돋보이게 해주는것이라고 개인적으로 생각한다.
이러한 나의 생각으로 본다면 Ruby on Rails 은 WEB의 진화의 과정에서 탄생한
아름다운 작품으로 봐야할것 같다.

script/generate 라는 이 마법과도 같은 단순한 명령어가 만들어 내는 web프로그램의 세계는
생각보다 매력적으로 다가온다고 볼 수 있다.

과거 나는 Ruby on Rails의 Cookbook만을 가지고 5개의 step을 밟아 보았다.
당시 아무런 사전적 지식이 없었기 때문에 Ruby on Rails의 단순히 구동되는 모습을 보고 "해봤다!" 라는
개인적인 작은 목적에 다다른적이 있었다.
그 이후 쉽게 구할 수 있는 레퍼런서의 부족으로 Ruby on Rails의 진도를 잠시 중단했었다.
그리고 맞이한 바로 이책!!

솔찍히 이렇게 다양한 기능이 Ruby on Rails에 숨겨져 있다는 사실에 놀라웠다.
아니 진작 책을 봤더라면 Cookbook의 레벨에서 바로 한단계 진일보 했었을 꺼라는 생각이 불쑥 불쑥 들었다고
봐도 과언이 아니다.
혹시 이 서평을 읽는 분들중에 나와같이 Cookbook만을 연마한 사용자라면 개인적으로
이책을 추천해 보고 싶다.

책은 CookBook에 없는 다양한것들을 보여주고 있다.
 - 엑티브 레코드의 속성과 기본 구성
 - 스캐폴딩이라는 새로운 접근과 DB들간의 접근
 - 뷰 확장하기를 통해 pulic 폴더 그리고 이미지 ,css들이 놓이는 위치설정
 - ..

 그 이상 참 많은것들이 담겨져 있다.
CookBook이 맞보기 레시피라면 책은 레시피가 만들어진 상세 메뉴얼 수준이라고 볼 수 있다.
수준이 이렇다 보니 얇은책! 많은 정보를 담고 있는게 사실이다.
TDD나 리스크 관리처럼 술술술 보여지지 않을 수도 있으나 루비를 이용한 빠른 개발을 해보고 싶은 분이라면
역시나 또한번 추천드리고 싶다.

책을 이용해서 운영툴을 만들 었다.
가용 간은 1달여..
사용할 수 있는 리소스는 나 혼자 뿐이였으며 나또한 다른 업무까지 병행하는 상황에서 운영툴 개발은
매우 어려운 난재가 아닐 수 없었다.
하지만 모두가 공감할 수준의 output은 생산이 되었고 나는 그 성공요인을  Ruby였기 때문에 가능했다고 본다.

Ruby on Rails이 만능이 아닐 수 있다.
하지만 운영툴과 같이 훌륭한 디자인이 피요하지 않는 서비스에서는 충분한 빛을 발휘한다고 본다.
물론 멀티 DB나, nil 처리 등과 같은 까칠한 풀어야할 숙재가 있긴 하지만
이또한 찾아내는데 큰 매력이 있는것 같다.

끝으로 아쉬운 부분이 있다면 정가 2만원.. 아~! 정말 IT서적은 비싼게 흠이다.

CookBook URL :
http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html?page=1

 
2007년 한해를 마무리 하면서 무슨책을 볼까  하면서 손에 잡힌책이 "생각을 바꾸는 패턴"이다.
영어에서 문법을 알면 영어가 고급스러워지는것 처럼 패턴 역시 그러한 현격한 영향을 가져다 주기에
2007년을 패턴으로 마무리 지어보려 읽어보게 되었다.

책은 무척이나 가벼우면서도 깊이 파고들면 한없이 무거움이 느껴지는 책이다.
그도 그럴만한것이 책은 GoF의 에릭감마가 이야기한 23개의 패턴을 지지하는 내용이 샘플 소스코드와
함께 소개되어있기 때문일 것이다.
책을 찬찬히 보게 되면 알겠지만 매 단락마다 GoF의 인용을 뺴놓지 않고 하고 있다.

처음 책을 봤을때 생각을 바꾸는 패턴이라는책은 내 생각을 180도 다른 패턴에 임하는 그런 책은 아니다.
(역시 이번에도 제목만 보고 안티페턴처럼 선입견을 가지고 열여봐버렸답니다.)
책은 일반적인 현상이나 생활속에서 발생하는 우리의 생각을 Program적으로 어떻게 진화시킬 수
있는지를 GoF의 패턴을 이용하여 진화시켜주는 책이다.

개인적으로 책에서 가장 맘에 드는 한부분을 인용해보면 다음과 같다.
버거가게를 만드는 패턴!!
이해가 되는가? 햄버거를 만드는데 별다른 패턴이 필요하지 않을것 같은데 버거가게에서도 패턴이
도입이 되는게 바로 이책안에서 생각을 바꿔주는 일에 해당한다.

버거를 만드는데는 양파, 치즈, 살사소스, 토핑 등이 필요하고 이것들이 조합되어 맛있는 햄버거를 만들어진다.
자 그럼 어떻게 이런 조합들을 프로그램 적으로 어떻게 설명할 수 있을까? 그리고 어떻게 하면
가장 유지보수 하기 편하게 만들수 있을까? (아주 아주 깜찍한 발상이죠. ^^)

내용은 SandWich라는 라는 basic Class를 생성하고 SendWichDecorator 라는 Class가 SandWich를
상속받고 getPrice()가 내용물을 감싸는 샌드위치의 getPrice()를 호출하게 된다.
getPrice()는 ChooseDecorator 라는 Class에 선언되어있는데 ChooseDecorator 는 다양한 토핑정보를
가지고 있게 되는것이다.

나의 설명이 다소 어렵게 느껴질 수도 있다.
하지만 책에서는 UML로 이해하기 쉽게 잘 설명되어있으니 궁금하면 한번 찾아보는것도 좋을것 같다. (95Page)
이렇게 언급한 버거가게 패턴은 GoF의 "Decorator패턴"을 이해하기 쉽도록 설명해 놓고 있다.

그밖에도 책안에는 제품구성, 패턴시스템 개발 등과 같은 다양한 실습예제가 들어가 있고 또 책 초반에는
UML대해 짧은 소개도 들어가 있다(책이 UML로 소개되어있어 그런것 같습니다.)
얼마나 패턴이 쉽게 다가올지는 소비자의 이해도에 따라 다르겠지만
우리가 알고있는 에릭감마의 GoF의 딱딱한 하드커버가 쉽게 감동이 되지 않는다면 한번 이책을 보고
다시 GoF로 이동하는것도 좋은 방법이라 생각한다.

끝으로 이책을 총평하자면 생각을 바꾸는게 아니라 생각을 진화시켜 패턴에 도달케하는 책이라고 말하고 싶다.



미국쪽 서적이나 세미나를 보면 독자들이 지루하지 않게 하기 위해 책의 배경이되는
무언가를 설정해 놓거나 세미나 진행을 베틀형식으로 진행하는것을 종종 목격하게 된다.

이번에 읽게된 "엔터프라이즈 자바 애플리케이션 구축" 역시 비슷한 전계구조를 가지고 있다.
이런 구조는 XP Installed 에서 C3 Project (임금관리 시스템) 을 대 전제로 설정해 놓고
이야기 하는 전계와 흡사한 모습을 보이고 있다.

아마 이러한 전계가 다소 딱딱한 전문서적을 부드럽고 유하게 만드는 섬유린스적인 역할을 하는게
아닌가 하는 생각이 든다.

책은 실제 업무상황에서 발생할 수 있는 가상의 상황을 만들어 놓고 발생되는 요건에 대해
어떤식으로 개발을 해야 하는지를 설명해 주고 있다.
읽다보면 느끼겠지만 책의 소재목이(아키텍처) 붙은 이유처럼 아무것도 구성되지 않는 상황에서 인프라 스트럭쳐를
구성하는 요령과 이에 대한 운영프레임웍으로 EJB 2.0에 기반한 개발 절차와 방법을 이야기 하고 있다.

EJB 2.0의 특징에 대해 이미 알고 있는 분들도 있지만 기존 EJB가 Remote 자원에 대해서만 지원하여 2.0부터는
Local자원 Access라는 부분을 가지고 있다.
책은 2개의 상이한 자원  Access Bean을 만들어 낼때에도 아주 적절한 Nameing Rule을 보여주고 있다.
(Remote는 그냥 OfficeHome, Local은  OfficeLocalHome) (개인적으로 이런것도 제시하는 책이 좋다 ^^)

책은 커다란 하나의 줄기를 가지고있다.
데이터 계층, 비지니스 계층, 프리젠 테이션 계층이라는 3계층을 가지고 이야기 전개를 하고 있는데 데이터 계층
이 책의 절반 이상을 차지할 정도로 가장 심도 있는 설명을 하고 있다.

각각의 내용을 이야기 하면 아래와 같다.

> 데이터 계층 : EJB2.0 환경에 맞는 각종 환경설정및 Bean 구성 (4장~5장)
> 데이터 저장장치 계층 : DB뿐만 아니라 디렉토리 서버의 자원을 Access 하기 위한 구성 (6장의 매니저) (7장)  
> 비지니스 계층 : 포어소트 온라인 서비스 개발을 위한 비지니스 계층 입력해 내는 과정 (8장 비지니스 로직)
> 프리젠 테이션 계층 : 특별한 언급 없음 (아마 View 영역은 알아서 하라는 것 이겠죠^^)

이상이 내용을 보면 지극히 아키텍쳐 적인 성향이 강하다는것을 볼 수 있는 구성이다.
이러한 내용은 지난번 서평자가 서평한 (엔터프라이즈솔루션아키텍쳐디자인패턴) 과 매우 유사하다는 구조를 볼 수 있다.
엔터프라이즈솔루션아키텍쳐디자인패턴 이 .NET 에 기반한 아키텍쳐라면
엔터프라이즈 자바 애플리케이션 구축 은 JAVA 에 기반한 아키텍쳐라 볼 수 있을것 같다.

책은 실습을 적극 권장하기 위해 구독자의 실습을 돕는 여러 포인트를 두고 있다.
was를 구성하는 방법, DB Query, 빈과 xml 파일에대한 설정 방법등을 부록과 주요 지면을 통해 소스코드를
보여주고 있다. (부록 참고)
구독 방법은 오케스트라의 지휘자처럼 한번은 쓰윽 살펴보고 다시한번 보면서 악기 하나 하나에 대해 가다듬어주는
코딩 작업을 해보는것을 권장해 본다.

끝으로 책이 추구하는 방향은 저자가 밝힌 아래 문구가 가장 정확할것 같아 발취해 본다.
실제 상황에서 경험하게 되는프로그래밍 작업을 최소한 비슷하게나마 맛보게 하려고 노력하고 있는것이다. (265 Page)



비지니스의 정점은 같다 (고/객/만/족을 향해 가는거죠..)
하지만 서로다른 언어를 사용하는 우리는 닮았 으면서도 다른 길을 걷고 있는 모습을 보게 된다.

이런 면모를 보여주는게 "엔터프라이즈 솔루션 아키텍처 디자인 패턴"가 .NET 환경에서 개발자가 개발에
임해야 하는 자세를 이야기 해주고 있다.

책은 2권합본형태로 되어있다.
제 1본은 아키텍쳐 디자인, 제 2권은 솔루션 패턴..으로 되어있는데 처음 볼때
책을 중간만큼 넘겼을 무렵 목차가 다시 나오는것을보고 깜짝 놀랬다.  (2권합본)
이점이 내가 맞이한 다른책과의 첫번째 이책의 차이점 이다.

● 아키텍처 디자인 (제 1블럭)
책에서는 아키텍쳐 디자인을 크게 3가지 영역으로 나누고 여기에 확장영역으로 3가지를 더 두고 있다.
물론 이런 분류가 모든 서비스에 공통으로 적용할 수 없지만 이런것이 컴포넌트 디자인을 위한
표준안으로써의 가치가 되는것 같다.
표준안은 (Presentation Layer, Business Components, Data Access Components) 등을
기반으로 다양한 외부 서비스 호출이나, 보안, 호출방법등을 이야기 하고 있다.
이미 익히 이런 분야에 관심을 가지고 있는 분들이라면 참 일반적이다.. 라고 말하겠지만
역시 Microsoft 공식 학습서 답게 이 책에서만 볼 수 있는 놀라운 한가지를 더 볼 수 있다.
바로 링크! 이다.

책을 넘기다 보면 MSDN의 특정 URL을 참조하면 더 자세한 정보를 알 수 있다고 LINK를 걸어놓은것을
볼 수 있는데 작은부분에서 부터 커다란 부분까지 참고 url을 설정해 놓은것을 보면
사묻 MS사가 얼마나 많은 지식을 축적해 놓고 있는지 느끼게 해준다.
안타까운건 대부분 영문사이트라는 점과 좀 과다할 정도로 참조 link를 걸어놓았다는게 안타깝다.

● 솔루션 패턴 (제 2블럭)
개인적으로 객체지향언어와 패턴에 관심을 보여온 터라 2블럭에 나와있는 항목이 그다지 감동까지 밀려오지는 않았다.
하지만 아키텍쳐나 패턴 부분에 있어 JAVA나 C++로 편향되이 나오고 있다는 점을 감안해 본다면
.NET을 중심으로 나온책이라 이점에 있어 신선하게 다가왔다.
   (실제로 .net을 가지고 리팩토링을 하는 과정은 매우 흥미로웠음^^)

JAVA리펙토링은 많이 봐왔고 구현도 했다. 헌데 .NET은 어떻게 하지?
aspx, cs, js 를 이용한 리펙토링 방법 후후..

언어만 달랐지 java든 .net이든 리펙토링을 하고 패턴을 만들어 내고 아키텍쳐를
디자인하는 행위는 같다. 하지만 언어가 다르기 때문에 가이드 라인역시 비슷하지만 약간 다르게 제시되는게 당연하다.

책은 .net의 개발자들에게는 도움이 될것으로 보인다.
설령 .net 개발자가 아니더라도 주변에 이책이 쓰러져 있거나 소외되어있다면 한번 펼쳐 책이 무슨 이야기를
하는지 .net의 노래도 들어봐도 좋을것 같다.
 
어차피 모든 언어는 정재화 작업을 거치고 리팩토링을 하는 진화의 과정을 거쳐 나가니까 말이다.



디자인 패턴에 익숙한 나에게 "패턴 = 디자인 패턴 " 이라는 선입견이 많이 그려저 있었나 보다.
부분이 전체인양 판단하고 있었다는게 바로 이런 문제에 오류였는데
이런 예는 "라면 = 신라면" 의 공식과도 같을 수 있는것 같다.

책을 읽기 전에 안티패턴의 내용을 담은 이책은  디자인 패턴을 실날하게 비판하고
디자인 패턴과 반대 진영에서 뭔가를 이야기 할것 만 같았다.
실제로 이름에서 풍기는 이미지가 그러하지 않는가? 안/티/ ...

하지만 책보고 나서 용어적 해설만 가지고 섵부른 판단을 금해야 겠다는 생각이 들었다.
과연 안티패턴에 대한 쉬운 이해가 무엇일까?

"디자인 패턴은  그들을 정상까지는 데려다 줄 수 있었지만 그들을 안전하게 아래로
돌아오게 할 수 는 없었다. 위험한 시기에 산 정상세엇 머무르지 않고 돌아온 다거나, 시간을 정확히
지켜야 한다는 등의 등반 관련 안티패턴을 적절히 응용했더라면 이런 참혹한 결과는 일어나지 않았을
것이다. (책 47 Page)"

디자인 패턴이 에베레스트를 손쉽게 오르게 하는 방법이라면
안티 패턴은 오르다 발생할 수 있는 문제점들에 대한 대응책과 대응 방법을 이야기 한것이라고 할 수 있다.

물론 알고 있는 분들도 있겠지만 책은 위와같은 대전제 아래에서 소스코드 하나 보여주고
리팩토링의 과정을 거쳐가며 하나 하나 풀어나가는 과정을 알려주고 있는  전개 방식을 가지고 있다.

개인적으로 안티패턴을 쉽게 보다 관심있게 본 목록이 하나 있다.
Round-tripping이 해당하는 항목인데  EJB로 개발했다가 속도가 느리고
서비스가 심하게 부하가 걸린 사례를 경험해서 그런지 Round-tripping에 부분에서는 저자의 친절한 설명이 고맙게 다가왔다.

책을 보는 방법
 > 부록A 먼저 보기 : 부록을 먼저는게 이 책을 빠르게 이해하는 방법이다.
     용어적 설명을 간단하게 해 놨기 때문에 부록을 먼저 보고
     10Chapter 를 보면 핵심을 크게 벗어 나지 않는 범위에서
     책의 액기스만을 맛 볼 수 있을것이라 생각되어 진다.

모든 책이 그렇지만 책장 한장 한장이 감동스럽게 다가오지는 않는것 같다.
그중에 IT서적의 경우 필요한것만 꺼내보는 성향이 좀 강한것 같다 (나^^)
하지만 이미 알고있더라도, 다른곳에서 알았더라도
한권즈음은 독파를 해보는것은 어떨까 생각해본다.



ajax를 보고 가장 신선하게 느낀부분이 바로 submit이 사라진것이다.
물론 action도 없다.
web프로그래밍의 가장 중요한 두녀석이 ajax의 등장과 함께 동반 가출 한것이다.
가출을 했으면 그 아비가 찾아야 하는게 당연한데
어쩌지.. 새로온 녀석이 더 맘에 든다^^

최근 ajax이 부각된 이유는 WEB2.0이라는 개념이 OReilly를 통해 소개되면서 이에 해당하는 기술로써 ajax이 개발자들앞에 서게 되었다.
사실 WEB2.0이 얼마나 대단한지는 개인적으로 더 지켜보야 하기에 그리 높은 비중을 두고 싶지는 않다.
개인적으로 보기에 WEB2.0은 WEB의 진화의 과정을 총칭하는 단어일 뿐이지 그리 놀라운것이라 보기 어렵다.
OReilly가 WEB2.0을 들고 나와 분위기 몰이에 선봉을 서긴 했지만 글쎄.. WEB2.0이라 말하는
대부분이 이미, 예전에, 진작에 시작되고 있었다고 봐야 할것 같다. (xInternet, RSS, Blog, Ajax...  이런것들이 예전에 우리주변에 없었던가?)

그래서 서평자는 Ajax를 WEB을 개발하고 만들어가는 사람들의 요소기술로써 바라보고자 한다.
ajax이 말하고 있는 사상과 기술은 MVC를 논하던 개발로 하여금 사용자에게  한발짝더 다가가라고 말하고 있는듯 하다.
실제로 책에 나와있는 예제코드를 타이핑 해가면서 느낀바는 기존에 어줍잖은 Script로 이벤트를 겹겹히 걸었던것을 걷어내고
간단하고 명료한 명령어로 이벤트를 제어한다는것을 보고 놀라지 않을 수 없다.
기존에 난잡하게 흩어져있던 Script가 담긴 Head 영역이 비로소 ajax으로써 해쳐모여 진다면 WEB의 진화는 가속될꺼라 본다.
그럴만한 이유가 이제 WEB 서비스는 더이상 WEB 기반으로 움직이지 않을 가능성이 많기 때문이다.
양방향 TV의 등장, DMB와 같은 휴대가능한 매채, 유비쿼터스와 같은 이기종의 통합 등과 같은
기술의 통합과 강력한 커플링이 요구되기 때문이다.
이러면에서 ajax는 적어도 web 부분에 있어 Script 통합을 이뤄내고 있다.

"ajax입문" 최초 페이지를 넘기고 3장에서 예제코드를 만나기까지는 필자는 무엇을 말하고 싶은건지 알수가 없었다.
내가봐왔던 기술서적의 경우 책 첫 단원은 간단한 소개와 예제코드가 들어있었는데 "ajax입문" 의 전개방식은
사뭇 달랐다.
ajax의 소개 > ajax의 API라 할수있는 레퍼런스 > 크로스브라우져 > 예제(3~8장) 의 방식을 가지고 있다.
즉 ajax의 정확한 특징이 눈에 들어오지 않는다면 3장부터 봐도 큰 무리가 되지 않을 것같다.
하지만  크로스 사이트 스크립트는 피할 수 없는 벽으로 다가오기에 반드시 봐야할것 같다.

책은 tomcat을 구성하고 test 해봐도 무리없이 한단원 한단원 나갈 수 있는 수준이다.
말 그데로 "ajax입문" 인 것이다.
책에서는 PHP 중심으로 설명이 되어있긴 하지만 JSP로 쉽게 컨버젼 할 수 있는 비교적 간단한 PHP구문을
사용하고 있어 JSP 개발자들도 Test 해볼 수 있을것 같다.

끝으로 코딩을 하려고 할때 항상 눈에 띄는"jslb_ajax.js" 파일에 관해서다.
본 파일 내용이 75페이지에서 부터 장장 5페이지동안 진행되지만 이것을 실수 없이 한번에 타이핑하기란
어려운 문제이다. (양도 좀 많죠  헐헐헐..)

국내에서 본 파일을 찾아보려했으나 없어서 일문판을 찾아 URL을 알려주도록 한다.
http://jsgt.org/mt/archives/01/000409.html  (jslb_ajax.js 버전이 책보다 높습니다.)
1 2 3 

글 보관함

카운터

Total : / Today : / Yesterday :
get rsstistory!