발표자 : 채수원

테스트주도개발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년)
상세보기
• 발표는 재미있게 하는데, 두번째 들으니까... 식상하네...
  작년 아키텍트 대회에서 들었던 내용과 크게 다르지 않은 내용이었다. 처음 들었을 때는 신선하고 재미있었지만, 두번째 들으니 조금 시큰둥하게 느껴졌다. 처음 들었을 때도 그랬지만, 두번째 에서도 발표시간을 제대로 지키지 못하는 모습을 보니 준비가 무성의하지 않았는가 하는 생각도 들었다.
  분명 발표를 준비하느라 노력을 기울이셨을테지만, 사소한 것들에서 점수가 깍이는 것이 많이 아쉬웠다.

+ Recent posts