'IT서적서평'에 해당되는 글 41건

  1. 2010.12.14 [CleanCode] 숨겨왔던 버릇을 고쳐줄 책 (3)
  2. 2008.10.20 성능시험 방법론과 실무 (1)
  3. 2008.09.11 웹진화론 / 내일은 무슨일이??
  4. 2008.09.10 Thinking in java/ 내코드는 jdk 몇버전?
  5. 2008.04.14 AJAX ON JAVA
  6. 2008.04.12 아이벤의 와글와글 포토샵
  7. 2008.04.01 실용예제로 배우는 웹표준
  8. 2008.01.30 Head First Design Patterns
  9. 2008.01.27 유닉스 쉘 바이블
  10. 2008.01.23 아키텍트 이야기 (1)



책을 읽기에 너무 멀리온것은 아닐까?
개발자라고 이름을 달고 다니는 사람이 이책을 읽기에 그 많은 시간을 방치했다는게
가장 미안한 생각이였다.
좀더 일찍 알았더라면 짜장면과 스파게티가 어울어져 레거시의 진수를 느낀 코드들에게
앙드래김 선생님의 백색옷을 입혀주었을 텐데 많이 미안하다.

책이 나에게 다가온것은 12월 어느날!!
갑자기 프로젝트들이 붕붕 뜬것이다.
왜 일까? 왜 떳나?
서버발주가 늦어지고 예정된 시간이 안맞아 살짝 일정들이 공중부양을 하기 시작한 것이다.
이것은 팀원들이 준 기회라 생각하고 평소 읽고 싶었던 책 목록에서 하나 꺼내어 읽기 시작했다.
바로 CleanCode.. 영어실력이 농약 먹은지라 역서를 보게 되었다.

구구 .. 절절..
감탄과 내가 지난날 요리사였는지 아키텍쳐였는지 구분이 안가는 대목들 뿐이였다.
개인의 설명은 좀 줄여보고 책에서 이야기 하고 있는 내용에 대해서 요약된 요약본을 쓰는게 좋을것 같다.,
===========================================================
1. javaDocs 에서의  @author 의 의미하는 바는 저자이다. 우리는 이야기를 하듯 코드를 짜야 한다.
2. 의미있는 이름을 사용하자. i, j, k는 올바른 이름이 아니다.
3. 발음하기 쉬운 이름을 사용하라 genymdhms -> generationTimestamp
4. 기발한 이름은 피하자.
5. 함수는 최대한 작게 만들어라 하나의 함수에는 하나의 함수가 좋습니다.
6. if/else는 하나의 블록을 넘지 않도록 합니다.
7. 함수의 인수는 없는게 가장 좋고 1개면 충분하며 2개면 어쩔 수 없고 3개면 튜닝해보자
8. if/else가 복잡해 진다 싶으며 예외처리로 퉁쳐보자
9. 나쁜코드에 주석을 달지 마라 새로짜라 주석 자체가 나쁘다 .
 > 글쎄. 나는 주석 좋던데..
10. 가로행은 45자 정도가 좋다
11. 디미터 법칙
 > 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙
  - (객체형 : 디미터 X )final String outputDir = ctxt.getOptions().getScratchDir().getAbsoiutePath();
  - (자료형 : 디미터 ○)final String outputDir = ctxt.Options.ScratchDir.absoiutePath;
12. null을 반환 하지 마라 (168p)
 > 한줄 건너 하나씩 null을 확인하는코드로 가득한 응용프로그램을 수도 없이 봐왔다
 > 확인해야 할것이 너무 많기 때문이다. 이때문에 예외처리로
13. 클린코드의 주 목적은 (가독성 입니다. ) 187p
14. StringBuffer 는 보기  흉하다 실제 코드에서 크게 무리가 아니라면 피한다 (193) 클린코드 저자
 > 특히나 테스트의 경우에는 정말 더 그렇다.
15. 단일책임 원칙 (203)
 > 클래스나 모듈을 변경할 이유가 하나 단 하나뿐이여만 한다.
16.  응집도 (Cohesion)
 > 모든 인스턴스 변수를 메소드마다 하나씩 사용하는 클래스는 응집도가 가장 높다 .
  응집도가 높은 클래스는 가능히자도 바람직하지도 않다 .
17. 모든테스트를 실행한다, 중복을 없앤다. 프로그래머의 의도를 표현한다, 클래스와 매소드 수를 최소로 줄인다 .(240)
18. 동기화 하는 부분은 작게 만든다. 그리고 안전하게 처리한다 (Synchronized) 를 설정해서 락을 건다 (256)
 > 하지만 쓰래드의 경우 남발하면 문제가 커진다.
19. 보이스카웃의 룰을 지킬 필요가 있다 (캠프장은 왔을때 보다 깨끗하게 해놓고 간다) (359)
20. 주석에 대한 추가적인 이야기  (386)
 > 부적절한 정보, 쓸모없는 정보, 중복된 주석, 성의없는주석, 주석처리된 코드,
21. 함수에 대한 추가적인 이야기 (388)
 > 너무많은 인수, 출력인수, 플래그인수(피함), 죽은함수
22. 매직숫자는 명명된 상수로 교체하라
23. 부정 조건을 피한다.
===========================================================

고수의 향수를 느낄 수 있었던 대목도 있었다.
아틀란타행 비행기 안에서 이뤄진 2명의 개발자. 한명은 java를 배우고 싶었고 다른 한명은 스몰토크를 배우고 싶었다.
그둘이 비행기에서 내릴때는 jUnit의 기본이 만들어졌고 그것은 TDD의 중심에 서게 되었다.
캔트백은 TDD의 아버지 , 애릭감마는 이클립스 의 창시자 

 
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.


프로젝트를 진행하는 단계에서 가장 많이 누락이 되는것중에 하나가 성능에 관한 이슈가
누락이 되고 있다. 실질적으로 프로젝트 튜닝이라는 과정이 거의 개발이 완료된 시점에
시행하다보니 "어쩔수없다" 라고해서 간과해버리거나 프로젝트 비용으로 처리해버리는 경우가 있다.


200년중반! IT업계에서 빅뱅과 같은 엄청난일이 하나 벌어졌다.
SK에서 진행한 차세대프로젝트!
이 서평을 읽는사람들중에 어떤이는 나와같이 이름만 들어봤을테고 어떤이는 실질적으로
그 프로젝트에 참여를 했을것이다.
당시 시장의 상황에는 JAVA개발자가 가뭄이 들었다고 할 만큼 많은 개발자와 시장에
내노라하는 리소스가 투입이 되어서 국민은행+주택은행 이후로 가장 큰 프로젝트로
주목받기도했다.  (더큰 프로젝트들도 많겠지만 복잡도와 많은 이해관계를 형성해낸
프로젝트로는 2개가 가장큰것 같습니다.)


 당시에 어떠한 방법론이 도입되었는지 모르지만 해당 프로젝트에서는 성능! 이라는 이슈에
 과거의 머큐리!현재의 hp의 자문을 받아 진행을 했다.
 그리고 그 프로젝트가 완결이 되어 빛을 보게 되던날! 몇몇의 엔지니어들과 지각이 있는분들이
 after action에  돌입하기에 이른듯 하다.


 여기서 말하는 afterAction은 바로 실전에서 겪었던 다양한 사례와 '성능시험방법론' 에 대하여
 어떻게  접근하고 어떻게 일을 해나가야 하는지를 정형화 했다는 것이다.


 실무자가 이야기하는 방법론?!
 이책의 가장 큰 매력은 바로 여기에 있다고 볼 수 있다.
 실무자가 시행착오를 거쳐 만들어낸 방법론이기에 군더더기는 오븐에서 기름쫙뺀 상태이고 더군다나
 이해당사자의 합의하에 도출되었기 때문에 그 내용에 대해 신뢰가 깊다고 볼 수 있다.


개인적으로 이책을 보게된 결정적인 이유는 시스템의 성능을 어떻게 하면 잘 볼 수 있고 모니터링
할 수 있을까 하는 기대로 봤는데 안타깝게도 그 부분은 방법론과는 조금 거리가 멀어서 기대만큼
큰 비중을 두고 책에서 다루고 있지는 않다. 하지만 실무자 답게 iostat, vmstat 등과 같은 몇몇
unix, NT 계열에서 모니터링 하는다양한 기법에 대해서 갈증을 풀어줄 만큼은 소개 해주고있다.


책은 무척이나 독특하다.
일반 IT서적에서 쉽고 볼 수 없는 구어체 적인 느낌이 많이든다.
다, 나, 까 로 끝나는 종결어는 볼 수 없고 ~ 하겠습니다. 로 나온다
 (읽기 어찌나 불편하던지 '실용예제로 배우는 웹표준','Head First' 도 그러더만 쩝~)


방법론 답게 문서를 산출해내는 다양한 포멧과 양식! 그리고 성능 분석에 따르는 다양한 수치적인
것은 공식화 해낸것을 볼 수 있다. (이산수학에서나 볼법한것들이 조금 등장합니다.)


더불어 이책은 현장에서 투입한 리소스들의 이름이 가끔 보이는데 아마도
성능에관한 기술컨설팅을 받게 된다면 해당 이름을 가진 담당자를 만나지 않을까 하는 기대도 하게된다.
 (싸인을 받아야 할런지~)


그래도 무엇보다도 이책의 장점은 성능에 관한 방법론책!이라는점이다.
물론 Appilcation은 제니퍼보다는 머큐리에서 만들어낸 Roadrunner기반으로 되어있기 때문에
일반 필드에서 100% 적용 사용하기에는 무리가 있고 성능방법론에 새로운 가치를 발견하고 현업에
일부적용하기에 적당하다고 볼 수 있다.


책은 맘에든다.
실무자가 작성해서 맘에든다.
연구소에서 스타나하면서 만든 방법론이 아니라 갑사와 피터지게 합의하며 만든 방법론이나 맘에든다.
이책을 만들기 위해 노력한 3명의 저자분들을 직접뵌적은 없지만 그들의 노고가 IT를 더욱 가치있게
만드는 것으로 보인다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사용자 삽입 이미지


많은 사람들이 웹의 진화에대 곰곰히 연구를 했다.
그즈음 게시판에서 블로그로 사람들의 행동이 변화를 일으키자 갑자기 어디선가 선구자적같은
용어하나가 툭! 튀어나왔다.

WEB2.0 !!

순간 밥좀먹고 산다는 컨설턴트들이나 말좀한다는 기획자들은 땅을 치며 후회를 했을것이다.!
"아! 저게 내가 하고 싶은 말인데 저런 간략한 용어를 만들어 내지 못한거야!!"
하지만 보다 정확한 표현은 WEB2.0이 아니다.
웹은 지속적으로 진화하고 있고 그것을 용어적으로 잘 풀이한다면 웹 진화론이 정답에 가깝다.
하지만 책은 꼭 진화론을 이야기하고 있는것은 아니다.
사회 전반적으로 흘러가고 있는 WEB의 형태를 마치 X-ray로 찍어내듯 이야기 하고 있다.
좀 아쉽지만 그래도 이책이 WEB2.0보다는 잘 인터넷을 이야기 하고 있는듯 해서 책을 읽어보도록 했다.

1. 진화라는 변화
 진화라는것은 아이가 어른이 되는것처럼 성장을 하고 변화를 일으킨다.
 손바닥 뒤집듯이 한꺼번에 일어나는게 아니라 서서히 그리고 인지하는 순간 빠른속도로 변화한다.
 책은 사회 전반적에서 벌어지는 진화를 소개하고 있다.
 구글이라는 회사의 진화, 실리콘 벨리에서의 진화, 소수의 의견들에 집중되는 사회적 변화 등을
 예의주시하고 이야기 하고 있다.
 바로 진화라는 변화를 작은 균열들에서 찾아내고 있다.

2. 소수자 생각의 존중
 변화의 속도를 더 빠르게 하는 주된 힘은 소수자의 생각을 메이져 기업들이 수용을 한다는것이다.
 일명 롱테일이라는 한 분야로 싸잡아 이야기 하는게 아니라 블로그를 통해 세상과 소통하는
 소수자들을 포털이나 쇼핑몰에서 의견을 듣고 이에 맞는 모듈을 제공해줌으로써 웹의 진화를
 이끈다고 볼 수 있다.  하지만 정말 중요한것은 그 소수자의 생성 컨텐츠는 생각 이상으로 가치
 있다는것이다.
 바로 변화를 이끄는 선봉을 차지하는 깃발뺏기 게임은 시작되었다.

3. 오픈소스
 책 저자의 직업이 참 의심스럽게 보여진는 부분이다.
 아직 개발자들 사이에서도 홍보와 참여교육을 통해 늘어날것으로 예상하고 조심스럽게 다가가고
 있는 부분에 대해 저자는 콕 찝어 오픈소스 영역에 대해 높은 비중을 두고 있다.
 물론 전문가 수준은 아니겠지만 openAPI가 미치는 사람들의 소통의 방법을 저자는 충분히 알고
 구독자에게 잘 전달해 주고 있다.

웹은 진화하고 있다.
그리고 그 진화의 선봉에는 소수의 블로거들이 존재하고 있다.
그들의 소리는 메이져기업들이 들어주고 있고 기업은 진화의 속도를 높인다.
속도는 기업에게 발전과 수익을 가져다 주고 일반 유저들은 새로운것을 경험하게 된다.


마치 경제의 순환고리를 생성해내는 과정과도 일맥상통하는 이러한 웹의 진화를 책을 통해 살짝
맛볼 수 있었다는데 이책이 만족스러웠다는것을 전해본다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사용자 삽입 이미지


나는 지금 jdk 몇버전에 머물며 개발하는 개발자인가?
우리의 물음은 거기에서 부터 시작이 되었다.
우리의 물음은 나 자신에게 다시 질문이 던져졌고
openAPI 한개더 알아가고 어디서 세미나 연다는 정보를 안다는것을 이제 더이상
중요한 정보로써의 가치를 잠시 버려보려고 했다.
그랬더니 JAVA개발자가 진화를 지연시켜온것을 알게 되었다.


그렇게 시작된 나의 자랑스런 팀원들과의 스터디가 진행이 되었다.
책을 배송을 시켰고 배송된책의 엄청난 부담감 1300페이지가 날 기다리고 있다.
이전에CODE COMPLETE 도 봤는데 이까이꺼 뭐~ 라고 말하겠지만 이것은 수준이 다른 문제였다.
책은 내가 아는 내가 지금도 주로 사용하는 언어를 이야기 하면서 마치 다른 이야기를 하듯이 풀어내고 있었다.
SCJP를 준비하려고 무작정 외웠던 소스코드들에 대한 원론적인 해석의 방법과 코드가 패턴을 가지게되는 역치의 순간들 그리고 우리가 늘 사용하고 있는 JAVA 용어적 해설까지 실로 바이블!
이라는 단어가 아깝지 않은 책이였다.


헌데 왜! 이책은 그 유명한 바이블이라는 단어를 버리고 Thinking in java라 지었을까?
그 이유는 책의 챕터를 한장 한장 넘겨가면서 알게 되었다.
앞에 코드를 생각하지 않으면 전혀 뒷장이 연상되지 않는 구조~!
챕터도 모두 떨어져 있지만 앞챕터를 이해하지 못하면 뒷 챕터역시 알토랑같은 지식을 주워먹을수
없는 구조의 책이였다.


1. 책의 세밀한 배려
 책은 구독자를 위한 세심한 배려들이 많이 숨어있다.
 a. 주석의 표준화된 표기
  주석의 표준화된 사용으로 작은 sample도 javaDoc를 만들어 낼 수 있는 구조로 되어있다.
  또한 챕처의 초반(2장)에 주석을 효과적으로 달아주는 doc 테그 달기 방법에 대해서 이야기 해준다.
 b. 컴파일 결과를 보여준다.
  코드의 제일 하단! 코드를 눈으로 해석하고 그 결과를 볼 수 있도록 결과를 주석으로 달아주었다.
  국내서적이 따로 그 결과를 뽑아내 코드로 페이지수 늘리기 할 법도 하지만 이것역시 간단한 주석처리
 c. 용어적 해설
  program language가 가지는 특징은 용어에 대한 함축적 사용이다.
  java도 예외가 아닌데 이런 용어에 대해서 책은 간간히 반복적으로 보여준다는것이다.


 이 외에도 책은 참 많은 세심한 배려를 보여준다.
 같은 코드를 가,나,다,라 형태로 진화시켜 나가는것을 보면 이책이 왜 그토록 많이 읽혔는가를 볼 수 있다.
 더불어 진행하는 사이사이 vm안에서 객체와 메모리힙 영역에서 어떤일이 벌어지는지도 보여준다.
 

2.  솔직한 저자의 생각
 java도 신이 만들어낸 언어가 아닌이상 사람의 철학이 담겨져 있고 사람의 실수가 있을 수 있다.
 저자는 이런 부분에서 자신의 솔직한 생각들을 책에 담아놓았다.
 물론 이것이 정답이 될 수 없지만 생각의 깊이를 많이하고 토다는것이기 때문에 저자의 생각마져도
 곰곰히 지켜볼 필요가 있다.
 개인적으로 내부클래스는 Thread 생성을 제외하고는 난 그다지 선호하지 않는다 하지만 저자의 경우에는 내부클래스를 interface를 통해 내부클래스의 확장된 활용을 이야기 하고 있다. (대단~)
 (챕터 가장 마지막 부분에 있는 요약도 참 보기  좋네요)


3. 뜨거운 감자 다루기
 String이 좋은가 StringBuffer가 좋은가? Exception을 이용한 객체 던지기는 바람직 한가?
 finally를 통해 객체 Close를 시도할때 신뢰할만한가?
 하하하...
 개발하면서 얼마나 논란이 많이 되는것들인가. 이것에 대해 책은 저자의 실전코딩을 통해 이것을 이약한다.
 결론는 기대하는 수준에서 결론이 대부분이지만 책은 충분한 설명을 동반한 결과를 이야기 한다.


4. 그리고 응용
 개인적으로 난 이책이 정말 대단하다고 보는것은 일반적인 java지식을 14장까지 보고 싶다.
 그리고 15장부터는 이것에 기반한 좀더 깊이있는 java다루기라 보고 싶다.
 물론 이미 충분히 알고있는것! 그래서 잘 생각없이 사용하는것! 에대해 14장까지 이해를 하고
 15장부터는 정말 깊이있게 생각할 수 있는 응용하는 바를 다루고있다.
 챕터 사이사이마다 비슷한 느낌을 받는 내용들이 있지만 역시나 이책의 주요 의도하는 바는
 개발자로 하여금 jdk의 버전이 높아짐에 따라 같이 버전업하라는게 농후한 메세지다.


이 작렬하는 포스의 책은 정말 1명의 저자가 사람이 만들었을까 하는 생각이 든다.
대단하다. 정말 이렇게 까지 할 수 있다는게 대단하다.
이 책을 모두 이해만 한다며 나도 java의 해안을 얻을것만 같은데 아직 그만한 지식이 갖춰져
 있지 않아서 오직 열심히라는 단어밖에 떠오르지 않는다.
매일 매일 새로운것을 배우고 내가 배운것을 단단히 해야하는 개발자~
좀 고되지만 이렇게 수준높은 사람들의 지경을 만나면 고개가 숙여진다.


신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
TAG java, 도서

AJAX ON JAVA

IT서적서평 2008.04.14 18:26



이제 흔하디 흔해져버린 AJAX 그리고 더 흔하디 흔해져 버린 JAVA
이미 공부한 사람들에게는 그다지 눈에 확~ 띄는 그런 도메인은 아니다.


하지만 두개를 잘 엮어낸 책에는 무엇이 담겨져 있을까?
역시나 기대했던바 데로 둘사이의 끈끈한 관계가 녹아져 있었다.

  - AJAX 위한 JSP 테그라이브러리
  - 스트럿츠에서의 AJAX
  - JSF와 AJAX
  - sample 구글 웹 툴킷

 보통의 AJAX를 이야기 할때면 http Protocol 을 상세히 이야기하고 그 풀어낼 썰을 가지고
 뭔가를 또다시 이야기 한다.   하지만 이 책에서는 그렇게까지는 다루지 안았다.
 실망할 필요는 없다.

 알면 좋은것 이지만 빠른 기술 습득을 위한 경우라면 오히려 책을 보는 포인트에 해가될 뿐이다.
 이런면에서 책은 처음부터 쉽고 빠르게 다가왔다.


 Ajax call을 위해 브라우져가 무엇인지 확인하는방법 (32p)
   > window.XMLHttpRequest / window.ActiveObject

 req.open("get",url, true) 이 강력한 의미 (33p)
   > 개인적으로 맘에 든 부분인데 구질구질한 설명이 많지 않아서 맘에 들었음


redState   의 응답 코드와 그 종류 (35p)
   > 이것도 맘에 들었던 부분으로 4: Complete 의 간결한 의미 전달
 


등이 참 간결하게 짧은 페이지에 이야기 되어주고 있다.
물론 이것을 가지고 뒷부분은 주욱~~ sample코드들을 나열하고 있다.
상황에 따라 좀더 복잡해지고 javaScript가 어떻게 XML을 파싱할지 값을 받을지 등등을 말하고 있다.


이전에도 난 AJAX를 개발을 하고 있었다.
앞선 사람이 사유한 결과를 충분히 습득하지 않은채 그냥 IN값을 넣으면 툭~ Out이 나오는
블랙박스처럼 그냥 그러려니 하는 막연한 신뢰를 가졌던게 사실이다.
하지만 이것을 구체적으로 볼 수 있었던 기회를 마련한게 있다면 이 책을 통해서라고 볼 수 있다.
사유에 배경이된 지식 습득 이라고 볼 수 있겠다.


책은 내가 알고있던 단편적인 지식에 일침을 가하기도 하였다.
JSON의 문법으로 Action에서 생성된 결과를 javaScript로 받아서 파싱하는 방법이 fullset으로 담겨있다. (82p)
그동안 JSON 포멧에 결과만 만들었지 별로 신경쓰지 않았던 javaScript 영역도 함께 연속선상에서 볼 수 있도록 책은 이야기 해주고 있는것이다.


개발자로써 자신의 롤을 좁게 보면 UI에서 벌어지는것 까지 생각할 필요가 있겠는가 싶겠지만
장르와 영역에 상관하지 않고 월급주는 일 외에 모든일을 총괄해도 무방하다고 생각하는게 개발자가
가져야할 소양인듯 싶다.
(실제로 WEB2.0은 S/W의 영역을 세분히 나누며 전문화 시켰지만 누군가는 그 순환고리를 설계해야한다.)


이야기가 잘못 전해졌다.
책은 재미있는 실험을 해볼것을 살포시 요구하고 있다.
바로 XML 문서를 생성하는데 있어 Jdom, dom4j, SAX 파서를 가지고  누가누가 빠를까?
라는 궁금증을 이야기 한다. (물론 결과는 SAX가 1등이지만 얼마나 빠른지는 TEST해보면 놀람^^)


개인적으로 궁금해서 TTXML포멧의 헤더부분만 가지고 생성을 해봤는데 속도 만능주의만 아니라면 Jdom, dom4j, SAX  각각 그 독특한 장점들이 빛이 나고 있으니 SAX만 강요하지  말기 바란다. 
코드의 인지적인 측면(Jdom), 결과의 가독성적인 측면(dom4j), 속도적인 측면(SAX)


끝으로 이 책에는 컨설턴트들이 찾아보고 싶은 구라들은 그리 많지 않다.
90% 이상 개발자를 위한 서적이다.
적당히 이책으로 어디 컨설팅 나가 썰을 풀어낼 계획이라면 다른책을 권해보고자한다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.


나도 참 이상하다.
개발자 이지만 이런 예쁘장한 포토샵책이 참 맘에든다.
허기야 그럴만도 한게 프로그램 서적들은 UI가 없어서 그럴만도 하다.


책으로 들어가보자.
책은 다른 포토샵책처럼 평범~ 하지 않다. 매우 독특하다.
예전에 석가시리즈같은 경우 1명의 저자가 책 1권을 모두 완성시키는데
주력했지만  "와글와글 포토샵" 의 경우에는 저자가 1명이 아니다.
카페구성원이 모두들 저자가 되어준 그런 책이다.


저자가 많다 보니 포토샵의 기능 하나하나 필터 하나하나의 나열보다는
타켓이 되는 이미지를 만들어 놓고 그러한 디자인과 효과를 만들어 내기위해
어떠한 포토샵의 기법을 사용했는지를 이야기 해주고있다.


독특한 구성!
사실 이 책이 가장 맘에 든다.
그러다 보니 다른 포토샵책에서는 찾아보기 힘든 재미있는 아이템들이 눈에띈다.
그중에 하나가 예쁜 손글씨^^


마트에 진열된 상품에서나 볼 법한 타이포그라피의 놀라운 세계와
포스터에서나 볼 수 있는 꼬불꼬불한 포스터 글씨는 정말 재미있기 그지없다.


사실 이런것을 표현하는데는 다른 책들이 언급한 그러한 기술들을 이용하면
충분히 나타낼 수 있다. 하지만 이 책의 포커스는 그런걸 만드는데 있는것이지
기술을 연마하는것은 아니다.


자! 그리고 또 있다.!
단축키와 중간중간에 텍스티콘은 참 맘에 든다.
그냥 글씨로만 주욱~ 설명해주는것이 아니라 직접 조그마한 포토샵 아이콘을
책 사이사이 글 사이사이에 잘 넣어주고 있다.


이상의 몇가지 포토샵에서나 볼 수 있는 재미있는 구성!
이맛에 디자이너가 아니면서 감히 디자이너들의 심오한 세계에 발을 살짝쿵
디딜려고 하는 구석이 있나 보다.


하지만 나만 그런것 같지 않은가 보다.
책을 보는 많은 독자들도 이런 것을 공감 했나 보다.
책은 5쇄까지 나아갔다!
개인적인 사사로운 취미중에 하나가 얼마나 재 출간 되었느냐인데, 역시나였다.

좋은책은 많이 찾는다. ^^

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.


함께 일하는 많은 개발자들 책상과 그들의 가방에 이책을 많이 봐왔다.
구리한 주황색 표지는 마치  지나와함께하는 java를 보는것 같은 다소 유행에
뒷 떨어진듯 보엿다.


하지만 모두가 "그 책 어때?" 라고 말하면 10인1색 "좋아 ^^" 라는 답 이였다.
뭐가 좋은지 그리고 왜 저리도 이 책에대해 강하게 찬성표를 던지는지 의문스러웠다.
나의 책 선택의 첫번째는 바로 주변사람들을 적셔내는 그런 책의 호평이였다.


사실 w3c의 표준화가 급속도로 확산되면서 많은 설치형블로그에서 CSS를 이용한
표준화된 가이드들을 속속들이 만들어 내고 있다.
과거 제로보드에서 막코딩(?) 이라 불리우는 HTML 작업은 진화를 강력히 요청 받아왔다.
그리고 지금! 그 진화의 과정에 CSS 라는 훌륭한 과정을 거치고 있게 되는것이다.


책을 보면서 저자가 옆자리에 앉아서 뭔가를 쉴세없이 이야기 해주려는 노력이
돋보였다.  일반적이고, 학문적이며, 메세지만을 전달하려는 노력보다는 이해를 위한
다양한 설명들이 이책에는 달려있다.


내용은 모두가 기대하고 있듯이 XHTML과 CSS에 모여져 있다.
웹접근성!
바로 이점이 이책이 이야기 하려는 주된 키포인트다.
테이블에 보이지 않는 설명을 달고, 장애인과 일반인을 위한 포괄적인 디자인을 만들기
위해 어떠한 작업을 수행하면 되는지 간단하고 명료한 과정들을 설명해 주고 있다.


개인적으로 이책이 맘에드는구석은 <h1> 과 같은 과거에는 별로 사용하지 않았던
테그에 관해서 새롭게 조명해주고 있다는것이다.
물론 <tbody> 와 같은 테그들을 얼마나 효과적으로 표현이 가능한지를 보여주고있다.
친절한 설명 그리고 그 설명에 걸맞는 개발의 과정이 잘 보여지고 있다.


이왕 책에 맘에드는것을 이야기 했으니 몇개 더 칭찬해보자!
CSS 메뉴만드는 방법도 들어있다! 티스토리 스킨을 만드는 방법도 들어있다!


음..
이것 가지고 티스토리 스킨을 블로그가 아닌 일반 사이트 디자인으로 만들어 보는것은
어떨까 하는 엉뚱한 생각도 해본다.


또 있다!
레이어 잡는 방법도 들어있다.
과거에는 커다란 Table 하나 잡고 뭔가 시작했다면 css에서는 header, body, footer를 잡고
시작한다는 UX개발의 과정에서 과정에 대한것도 책은 잘 설명하고 있다.
코드도 쉬워 따라하는데 별 어려움없이 타이핑 해볼 수 있었다.
Header first 처럼 처음 몇페이지 따라하다 그만둘만큼 어렵지도 않으니 타이핑 해가며 보는
것도 좋은 방법이라고 본다.


책을 다 보고 느낀 충동은 역시나 티스토리 스킨한번 만들어 봐야겠다는것이다.
그리고 다른 누군가에게 권하고 싶다는 충동역시 들었다.


이책은 IT서적이 겪는 1판 1쇄 끝! 이라는 단명의 벽을 넘어 3쇄발행이라는 기엄을 토했다.
그만큼 많은 사람들이 본것이고 좋아하고 있다는 반증이기도 하다.
(물론 저자가 미친척 책을 다 사들였다면 모를까??? ㅎㅎ)


책은 참 좋다.
CSS를 시작하는 사람들이라면 이책을 추천해본다.
과거 JAVA를 처음시작하는 사람에게 권했던 "지나와 함께하는 JAVA" 처럼 말이다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.


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)
 > 특정컨텍스트 : 반복적인 일을 줄여냄
 > 해결책 : 누구든지 적용해서 일련의 제약조건 내에서 목적을 달성하는것

모두가 패턴 황재가 되라는게 아니다.
모두가 이해하는 효율적인 코드.. 그것이 디자인 패턴이 바라는 궁극적인 해답이라고 생각한다.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.



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

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

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

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

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

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

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

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

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

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

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

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

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.



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을 만들테니 말이다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
1 2 3 4 

글 보관함

카운터

Total : 565,471 / Today : 87 / Yesterday : 109
get rsstistory!

티스토리 툴바