책에는 많은 정보가 담겨있다.
그래서 많은 사람들이 정보를 얻기 위해 책을 읽는다.

하지만, 그 책에 있는 정보만으로는 할 수 없는, 얻을 수 없는 것들이 꽤 많다.
그것은 일을 다시 시작하고 모르는 것들을 배워가면서 눈에 보이기 시작한다.
Java를 이용한 서비스, 컨트롤러 단의 처리, 그것을 프리마커를 이용하여 화면에서 받고 스크립트를 이용하여 작동시키는 것들은 한 분야의 책만을 가지고 알 수는 없다. 물론 꽤 많은 책들이 기술과 관련한 정보를 전달하려고 노력하지만 여러가지 이유로 전달하는 데에 한계가 따른다. 그것을 인정하게되면 많은 것들이 눈에 들어오기 시작한다. 그리고 사람이 눈에 들어온다. 그 사람은 내가 필요로 하는 정보들을 이미 경험 속에 축적해두고 있다. 그 사람의 힘을 빌어 알게 되는 것들이 참 많다.

_IMG_0888
_IMG_0888 by redslmdr 저작자 표시비영리동일조건 변경허락



사람에게 잘하자.
일의 시작과 끝, 그리고 그 연장선에는 사람이 있다.
정보의 시작과 끝, 그리고 그 연장선에도 사람이 있다.

^^ 오늘 하루도 즐겁게 보냅시다!!  

발표자 : 채수원

테스트주도개발TDD실천법과도구
카테고리 미분류
지은이 채수원 (한빛미디어, 2010년)
상세보기
• 주제 : Play Framework 를 이용한 빠른 개발과 MongoDB를 이용한 실습

Play Framework :
• 목적 : 웹 서비스를 개발하는 방식에 대해 되짚어보고 '생산성' 이라는 측면에 대해서 생각해본다.
• 목표 : MongoDB와 Play framwork 의 컨셉을 이해한다.
∘ 특징적인 기능들을 간략히 살펴본다.
∘ 짧은 시간
• Live Coding(발표자가 발표현장에서 직접 소스코드를 작성하면서, 청중의 몰입을 유도하는 효과를 가져온다. 실수를 하면 웃을 수 있는 여유가 필요하다.)


No pain, No Gains!
• 생산성에 대환 포커스(Ruby on Rails)
• 토비의 스프링3 : 흉기로도 쓸 수 있는 자바 스프링 프레임워크 참고서적!!
토비의스프링3
카테고리 컴퓨터/IT > 프로그래밍/언어 > 프로그래밍일반
지은이 이일민 (에이콘출판, 2010년)
상세보기

• Java Web Frmeworks를 만든 사람들은 Java 개발자가 만들었지, Web Developer가 만든 것이 아니다.
• Productivity focus by Java : Play Framework
• GWT, Rails, Grails, Play!
• Play Framework 가 인기를 끄는 이유?
∘ Ready for REST
∘ Java Full Stack, 수많은 자바 OpenSource 프로젝트들을 포함하고 있음
∘ Pure Java
• 백번듣는 것보다 한번 보는 게 낫지.
∘ clonetwit
∘ play run clonetwit/
∘ Eclipse 로 프로젝트 import
∘ dev
∘ play eclipsify clontwit
∘ MVC
∘ Routing 처리 :  Rest 스타일의 URL 을 지정할 수가 있다. routes
• 개발에서 다른 사람의 방식을 보는 경우는 많지 않다.
• 생각해 볼 문제들
∘ 장점과 단점?
∘ 성능은 상대적이다?
‣ 자바가 1일때, RoR은 5, Play는 4
‣ 서비스의 성격에 따라서 고민
• One Possible Solution
∘ 복잡성을 가지지 않는 SQL
∘ NoSQL : SQL 을 안쓰고도 DB를 사용하자.
∘ MongoDB를 사용하는 것에 대한 이야기
‣ MongoDB가 타겟으로 삼고 있는 것
‣ 배우기 쉽고 쓰기 쉽고
‣ No SQL
‣ JavaScript
‣ JSON을 닮았음
‣ Replecation이 쉽다??
• 실행방법
∘ 압축을 푼다
∘ mongod
∘ 실행 끝
• MongoDB : Transaction 기능이 없다.
• 생산성에 대한 이야기
• NoSQL
∘ 장점과 단점
‣ 장점 : 쓰기 쉽다.
‣ 단점 : 조인이 안됨, 분야가 특정적이다.

Scap Folding 기능?


- 우리가 종종 우리에게 적합한 기술이 아니라, 우리가 쓰고 싶은 기술을 사용하기 위해 욕심(Desire)을 부린다. '욕심' 자체는 '악'이 아니지만, 타인을 희생하면서까지 그 욕심을 채우려 할 때 우리는 그것을 '탐욕' 이라고 부른다. 탐욕보다는 배려.




  많은 것을 보여주려는 욕심 때문에 시간을 조금 초과하시면서도 많이 아쉬워하셨던 발표였다.
  발표하시는 걸 들을 때마다 느끼는 거지만, 적절하게 던지는 농담과 돌발상황에 유연하게 대처하는 모습에서 연륜(!?)을 느끼게 하는 개발자다.
  지난 KSUG 발표회에서 강연을 듣고 난 이후부터 종종 뵙고 있는데, 그 때마다 새로운 무엇인가를 시도하는 '도전정신'으로 무장한 '여유로움'을 풍기는 개발자다.
  이 강연을 들은 주변의 개발자들이, Play Framework에 대한 관심을 가지기 시작했다. 거기에 나도 포함?


• 부제 : Architecting, Designing, and Developing Reusable Libraries
• 발표자 : 손영수(http://www.arload.net)
∘ EVA팀 리더
∘ PLoP 패턴 저자
∘ AsianPLoP

• 개발자의 진화
• 건강을 지켜라.
• 정덕영 : http://uvicrabbit.tistory.com
• Framework : semi-product <-> libraries 와는 다르다.
∘ 애플리케이션의 제어는 Framework 에게 넘기지.
∘ Framework 를 사용하면서, Framework에 대한 공부학습요구량은 증가하였지만, 실제로 작성하는 소스는 줄어들었다.
∘ Control Flow(IoC) 권한을 가지고 있는 녀석이 누구냐?
∘ 사용 이유
‣ 중복 제거(Avoid Dulpication)
‣ 생산성 향상
‣ 표준성 싸움(DeFacto war)


• 5topic
∘ Organization(조직) - The most powerful design tool
‣ 기술의 끝장(대부분의 문제는 사람에게서 발생한다)
‣ 많이 먹이면 관계가 원활해진다.
‣ Project management Triangle
‣ +1 Organization (조직의 문화를 고려하라).
• conway's law(http://en.wikipedia.org/wiki/Conway's_Law) : 4개의 그룹이 일을 하게되면, 4종류의 컴파일을 얻게 된다?
‣ 분위기 : 가족적인가?
‣ peremptory
‣ 조직의 크기
• 작은 조직
∘ simple Design
∘ Consistency Design : 분할되어 있는 디자인
∘ 80/20 법칙에 집중
• 큰 조직
∘ powerful design
∘ lack Consistency
‣ Framework를 사용하는 조직에게 맞춰라.
• 요구사항을 줄이는 방법
∘ 밥을 사라
∘ 호형호제
∘ Planning
‣ Peanut Butter
‣ Skyscrapers
‣ Moderation(중도)
• MS : MileStone = Scenarios + Feature
∘ Architecture
‣ Type 고려
• Primitives
• Libraries
• Abstractions
• Manage Dependencies
∘ Component : 시대의 흐름에 따라서 결합형태(기능이나 모양)이 변하는 것(가치를 흡수)
∘ Type of Dependencies
‣ API Dependency
‣ Implementation Dependency
‣ Circular Dependency : A -> B -> C -> A -> B -> C
∘ Layer를 적절하게 나누는 작업이 필요하다.
∘ 엄격한 계층화
∘ Tools를 이용하여 Dependency가 커지는 것을 제한한다.
∘ xDepend(Ndepend, Xdepend, CDepend)
∘ Solution : creat new a package.
‣ Packaging Principle
• Package Cohesion Principle
• Pakcage Coupling Principle
‣ 호환성 (Compatibility)
• 팀의 공간
• 소스를 보여주고 말하기
• 문제 처리 공간
• 물어볼 사람이 있다.
∘ Design
‣ Code Samples
‣ KISS(Keep It Simple! Stupid!
‣ 우선순위를 중심으로 해서 구현하기
∘ Development


• 조직에 대해서 신경써라.
• 아... 내가 산 아키텍트가 알아야할 97가지 이야기...를 쓴 사람이구나....
소프트웨어아키텍트가알아야할97가지
카테고리 미분류
지은이 RICHARD MONSON HAEFEL (지앤선, 2011년)
상세보기
• 발표는 재미있게 하는데, 두번째 들으니까... 식상하네...
  작년 아키텍트 대회에서 들었던 내용과 크게 다르지 않은 내용이었다. 처음 들었을 때는 신선하고 재미있었지만, 두번째 들으니 조금 시큰둥하게 느껴졌다. 처음 들었을 때도 그랬지만, 두번째 에서도 발표시간을 제대로 지키지 못하는 모습을 보니 준비가 무성의하지 않았는가 하는 생각도 들었다.
  분명 발표를 준비하느라 노력을 기울이셨을테지만, 사소한 것들에서 점수가 깍이는 것이 많이 아쉬웠다.

• 발표자 : 박용권 , 변정훈


• 발표주제 : Server-Side와 Client-Side 사이의 연결을 유지한 실시간 웹 개발.

• 발표내용 : Server Push 기술을 Comet과 WebSocket을 이용하여 구현하는 방법..이랄까?
• Server Push -> Mobile Service Push

• What is Realtime Web?
∘ http://springsprout.org:10000/


client-side : Polling : 브라우저 에서 요청 -> 서버에서 응답 , 서버에서 이벤트 발생시, 브라우저가 요청하면 이벤트 내용을 바로 전달
∘ Ajax를 이용해서 polling 을 전달, 서버에서 변경사항 발생시 클라이언트의 지연시간 여부에 따라서 부하가 발생할 수가 있다.
∘ Server push라고 보기는 어렵다.


• Comet & Web Socket
Comet(http://en.wikipedia.org/wiki/Comet_%28programming%29)
web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.
웹서버와 클라이언트가 HTTP request로 긴 접속을 유지하면서, 웹서버에서 클라이언트로 데이터를 보내는 모델.
: Ajax처럼 특정기술이 아닌 패턴 : realtime 을 구현하기 위한 패턴
∘ Long lived Http connection : http 연결 상태 장기 지속
∘ Long Polling
∘ 브라우저가 서버에 요청 -> 서버는 대기(서버 이벤트 발생시까지 대기) -> 응답 -> 연결끊김 반복
∘ Json polling : JSONP :
‣ 스크립트 태그로 호출,
‣ 서버에서 콜백함수로 JSON 객체로 리턴
‣ 필요한 이유 : 동일출처정책 : Same origin Policy
‣ 브라우저에서 도메인당 커넥션 2개 제한
∘ Streaming : 일반적인 Server Push에 가깝다.
‣ 브라우저에서 요청 -> 서버에서 대기하다가 이벤트 발생할때마다 응답해줌(Connection이 지속됨)
‣ Chunked : Transfer-Encoding : 전체 데이트는 알 수 없지만 Chunked 단위로만 받을 수 있음.
∘ IE는 Chunked 를 지원하지 않습니다. -> Forever IFrame
‣ 웹페이지에서 hidden iFrame 을 두고서  서버에 요청 -> 서버에서 Chunked Data<script>데이터></scipt>
‣ iFrame 에서 Script가 계속 발생하는 문제가 발생
‣ 클릭소리, 로딩바 문제 등의 다양한 문제가 발생한다.
‣ AcitveXObject("htmlFile")
∘ WebSocket
‣ HTML5
‣ W3C/IETF 표준
‣ WebSocket 프로토콜 사용
‣ 진정한 양방향 통신
‣ HTTP를 업그레이드해서 Socket연결
‣ http 호환 handshake 80/443 으로 동작 : web socked protocol handshake
∘ Adobe flash socket


server-side
∘ 클라이언트와의 지속적인 연결(persistent connection)이 유지되어야 한다.
∘ 자바 서버의 문제 : Thread or Request : Request 가 thread가 발생된다. 접속을 유지하게되면 thread가 누적되면서 서버 부하가 발생하게 된다.
∘ Thread 에서 발생하는 문제가 발생하기 시작 : Servlet Container CometServlet
∘ Resin 3.1+  에서 CometServlet 을 통해서 지원(service, resume[지속적인 커넥션 유지] : boolean 타입)
∘ jetty(suspend, resume)
∘ Tomcat 6.0+ : CometProcessor(http://tomcat.apache.org/tomcat-6.0-doc/aio.html)
∘ Servlet
‣ <async-suspend>true</async-suspend> 처리를 하여 비동기 처리를 하겠다는 설정
‣ AsyncContext startAsync();
‣ HttpServletRequest
‣ Servlet 3.0
‣ 비동기 처리....
∘ WebS

• Realtime Web application  의 중점
접속(Connection)의 지속적인 유지(Long Connection)를 위한 기술들이 필요하다.
∘ Client Side
∘ Server Side


  발표자들이 생각했던 것보다 많은 청중이 몰려와 자리가 없어서, 발표장 앞쪽에 앉아서 발표를 경청했습니다. 꽤 많은 준비를 했고, 청중들이 모바일 접속을 하여 함께 참여할 수 있는 기회를 제공함으로 해서, 청중들의 관심을 불러일으키는데 성공한 좋은 발표였습니다.
  Server Push와는 다른 형태로, 클라이언트가 서버에 접속을 유지할 수 있도록 Comet이라고 하는 모델을 활용한 웹 애플리케이션을 구동하여 보여주고 소스를 보여주며 개발자들의 흥미를 끌기도 했습니다.



발표자 : 김민재, 이경진
발표내용 : 소프트웨어 중심에 존재하는 복잡성에 도전장을 내밀다
DDD : Domain Driven Developemnet - 회사에서 새롭게 진행하는 프로젝트에서 사용하게되는 JPA와 Hibernate 를 이용하면서 DDD를 활용하게 되다.
∘ The String, Entertainer

∘ 목적(Objectives)


‣ Modeling in out
‣ 강사 -> Ubiquitous language <- 청중
발표자와 청중이 만나서 메시지를 주고받으면서 그에 대한 호응이 있어야 한다고 말함. 하지만, 발표자분은 본인이 말한 부분을 제대로 달성하지 못한 아쉬움이 있다.
‣ 멘토스 <-> 멘토,
‣ DDD 에릭 에반스 : http://artofsoftwaredev.tistory.com/94 강연
‣ 켄트 백 : Four Strategies : leap(건너뛰기) -> parallel(병렬화) -> stepping stone(가뿐하게 건너뛰기) -> simplification
‣ 질서유지
‣ 일관성
‣ 저장이 아니라 소화(지식을 단순히 보관하는 것이 아니라, 그것을 이해하고 활용(소화)하여 자신의 것으로 만드는 작업이 중요하다).
• 소화에서는 질문이 일어난다.
‣ 연계(Alignment)
• 계획(Plan)  vs. 일(Work)
• Plan to work, Work By plan
• 방향, 거리
• 머릿돌(capStone)과 건축(construction) : 머릿돌이 움직이는대로 몸체가 움직인다?
• 목적 vs 활동
∘ 1. Set Objectives
∘ 2. Compare
∘ 3. provide Direction
∘ 4. IT Activities

∘ 활동(Activies)
‣ 디자인(Design) vs. 프로세스(Process) : DDD는 디자인 책인가? 프로세스 책인가? DDD에서는 방법론에 대한 이야기를 많이 한다. XP, Agile
‣ 질문
• 애자일을 하면 모델이 필요없나요?
∘ 모델을 강조한다. Red -> Green, Refactoring
∘ 코딩의 생산성
∘ 고객의 필요에 대한 만족
‣ 해결책 :  DDD -> 디자인 & 프로세스 패턴 모음집
• Entitiy -> Relation -> Entitiy
• Boundary Context
‣ 어떤 문제가 있는가?
‣ 소통, 언어 : Ubiqutous Language Pattern
‣ 모델은 생각을 반영한다. 모델을 통해서 구현부분에서 작성자를 떠올릴 수 있다.
‣ 소통, Deep & Supple : 언어 + 모델
‣ 모델 -> Paradigm -> Design : Deep Model & Supple Design
‣ 통일성

• DDD 적용 사례(Reference) : 11번가
∘ CBD : DDD도 CBD와 유사한 Architect 구조를 유지하고 있다.
∘ A -> B -> C -> D : D에 대한
∘ 식별성




※ 발표... 들은 시간이 왜이리 아쉽냐....
  DDD에 관심을 가지는 이유는, 개발을 조금 더 객체지향적으로 할 수 있기를 바라는 개발자들의 바람 때문이다. 아직 우리나라에는 ORM을 바탕으로 하는 서비스나 애플리케이션들이 많지는 않다. 그래서 DDD에 대한 참고자료나 글이 적은 듯 하다. 나도 최근에 업무차원에서 JPA를 이용해서 ORM을 활용하게 될 것으로 보인다. 그래서 기대하고 트랙에 참가해서 들었는데 기대에 못미치는 아쉬운 점들이 많다.
  개인적으로 DDD에 대해 공부하고 이를 정리하는 글을 적어보는 것이 좋겠다.
  DDD와 ORM에 대한 이해가 필요하다. 객체에 대해서 정리한 개념도 필요하고...

참고 사이트 : http://aeternum.egloos.com/category/Domain-Driven%20Design

+ Recent posts