허니몬(Honeymon)의 자바guru

지난 토요일(2013. 02. 23.) 코엑스에서 [Follower 에서 Creator로!] 라는 주제로 JCO가 주최한 제 13회 한국자바개발자 컨퍼런스 대회(http://jco.zdnet.co.kr/)가 열렸다. 

국내에서 열리는 자바관련 컨퍼런스로는 가장 큰 행사다(이제는 Deview, Devon, H3 등의 규모도 굉장히 커졌다). 개발관련 큰 컨퍼런스들이 열리는 것은 개발자들에게 굉장히 좋은 여건을 마련해준다.

2013/02/24 - [Java/Java] - 제13회 JCO 첫번째 발표, 우리들이 말하는 분산환경(Itembay mobile Service)

2013/02/24 - [Java/Java] - 제 13회 JCO 두번째 발표, 파이썬3 기반의 웹 프레임워크 : 파이라떼PyLatte

2013/02/24 - [Java/Java] - 제13회 JCO 세번째 발표, Server side software development

2013/02/24 - [Java/Java] - 제 13회 JCO 네번째 발표, MongoDB, DB설계 패턴 및 성능 튜닝 솔루션

2013/02/24 - [Java/Java] - 제13회 JCO 다섯번째 발표, OAuth 기반 오픈 API활용 실전

2013/02/10 - [Java/Java] - 제 13회 JCO에 대한 한소리

블로그 홍보왕, 2관왕

많은 사람들기 기다리고 기다리는 경품추첨의 시간!

운이 좋게도 JCO 블로그 홍보왕에 올해도 당선이 되었네요. 그저 블로그에 관련 이미지를 복사해서 올렸을 뿐인데...

2013/01/21 - [Java/Java] - [제 13회 한국 자바개발자 컨퍼런스]가 열립니다.

작년에는 SSD 128GB, 올해는 SSD 256GB를 받았습니다. 집에 오자마자, 데스크탑에 꽂힌 HDD를 뽑아내고 SSD로 꽂고 윈도우와 우분투 리눅스를 깔고 돌려보니 감동의 눈물... ㅠㅅ-)!!

JCO 풍경

이전다음

012345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182

한국자바개발자 컨퍼런스 참관, 그 후 이야기

Follower에서 Creator로!

  컨퍼런스 참관후기에는 '이 주제에 대한 답을 얻었는가?'에 대한 이야기를 중점적으로 다루는 것이 적절하겠다. 내가 그런 이야기를 할 수 있는 위치나 경험은 미천하지만...

  기술적인 트렌드가 많이 변했다. 과거 벤더(Vendor, Oracle과 IBM 같은) 중심이었던 데에 반해서, 이제는 오픈소스 중심의 시대가 되었다. 서비스를 제공하는 대부분의 기술들이 오픈소스를 기반으로 하고 있다. 빅데이터와 클라우드라는 용어가 흔하게 쓰이고 있는 기술적 트렌드의 중심에는 오픈소스들이 있다. 빅데이터의 중심에 있는 NoSQL 기반의 데이터베이스, 대용량 데이터 분산처리 및 클라우드 컴퓨팅의 근간이 되는 하둡, 기술들의 중심에는 오픈소스가 자리잡고 있다.

  오픈소스 기술을 사용할 때 중요한 것은, '소통'과 '기술의 내재화'라고 생각한다. 오픈소스 기술을 사용하면서 생길 수 있는 '내부적인 결함'과 '시행착오'를 개발자들이 해결해야한다. 해결하기 위해서는 '오픈소스 관련 개발자들과의 협력' 및 '내부 개발자들의 학습과 그 과정에서 생기는 경험의 축적'이 중요해진다.

  우리나라는 대기업 중심의 기술선도 문화가 깊게 자리잡고 있다. 대기업들은 풍부한 자본과 인력을 바탕으로 독점적으로 정보를 공유해왔었다. 그런  이들을 중심으로 최신 기술들을 도입을 시도하고 그 과정에서 시행착오들의 경험들이 은은히 퍼져나가게 된다. NHN, Daum, KTH, SKPlanet 등의 기업에서 큰 컨퍼런스를 주최하기 시작한 이유는... 뭘까요? +_+)~ ㅎㅎ

  그래도 요즘은 그 기업들의 노하우 공유의 장이 많이 열리기 시작해서 기술적인 유행에서 조금 멀리 있는 개발자들에게도 유행의 맛을 볼 수 있는 기회를 제공하고 있다. 수도권을 중심으로 열리는지라 지방에 계신 분들은 접하기가 어렵기는 하겠다. 그래도 전에 비하면 훨씬 나아졌지만... 

역시 개발자는 서울로 와야한다! 응?

참관 평가의 기준이 되는 'Follwer에서 Creator로!'에 대한 이야기 시작해보겠다.

이번에 참관했던 내용들을 가지고 내가 Creator가 될 수 있을까?

.... 좋게 대답하기 어렵다. 

  몇몇 발표들은 마음에 들었다. 그런데 몇몇 발표들은 '왜 들었을까...?'하는 생각이 들기도 했다. 자바와의 연관성을 찾아볼 수 없는 발표도 있었다. 다른 개발 컨퍼런스에서라면 '자바와의 연관성'에 대해서 크게 신경쓰지는 않았을 것이다. 하지만 JCO다. '한국자바개발자 컨퍼런스'라는 이름을 걸고 하는 컨퍼런스에서 '자바'와의 관계성이 적은 주제의 발표들이 섞여있는 것이 참 아쉬움이 많다. 다른 언어에 대한 소개나 사례를 발표한다면, 발표주제는 '자바언어를 사용하는 개발자가 효과적으로 접근할 수 있는 포인트와 자바와의 차이점'에 대해서 알려주는 것이 맞지 않을까?

개인적으로는 '자바'를 바탕으로 '스타트업Start-up'에서도 사용할 수 있을만큼 빠르고 안정적으로 생산성을 높이고 결과물을 도출할 수 있는 방법에 대해서도 이야기가 나올 수 있으면 참 좋겠는데, 이런 이야기가 '자바Java'라는 언어를 가지고는 할 수 없는건지 아쉬움이 많다. 

  해가 갈수록... 아쉬움이 많아지는 JCO 컨퍼런스다. 

올해 출시되는 오라클에서 처음으로 내놓는 JDK 8에 대한 소개를 하는 코너도 없는게 참 거시기 했다. 비록 우리나라에서 JDK 1.6이 사용되기 시작한 상황이기는 하지만, 아쉬움이 많이 남는다. 올해는 Lamda식 표현(JSR 335, http://openjdk.java.net/projects/lambda)을 익혀볼까 하고 있다.

어디선가 JCO 발표 주제와 발표 내용에 대한 글이 올라온 것을 보기는 했는데, 무심코 지나친 결과치고는 '참혹했다'는 생각이든다. 쩝.

나와 비슷하게, 상당히 많은 사람들이 발표제목과 발표자만 보고 세션을 선택해서 듣는 이들이 많을텐데(당일, 발표장소에서 발표내용에 대해서 확인할 수 있는 정보를 제공하는 그 어떤 것도 없었다. ㅡ_-)> 요즘 유행하는 긴 디스플레이로, 각 발표회장별 발표제목과 발표자, 발표내용을 보여줘도 되었을텐데...) 적잖게 실망했다는 이야기들을 들을 수 있었다. 처음 참관한 동생은 '우와, 이런 게 있는지 몰랐어요.'라며 신기해하기도 했다.

'무료'로 보는 컨퍼런스면, '그런대로 들을만 했어.' 라고 넘어갈 수 있다.

그러나 '유료(아마, 조금씩 관람료는 오를 것이다. JCO 컨퍼런스를 해외 개발 컨퍼런스처럼 고급화하겠다는 이야기를 들었을 때, '관람료가 오르겠군.' 이라는 생각을 했으니까.)'로 보는 컨퍼런스로서는, '쩝...'하는 생각이 든다. 조금도 양질의 컨퍼런스로 만들고자 한다면 신경써야할 부분들이 많다는 생각을 하고 있다. 발표자를 모집하는 게 아니라 요청하면 어떨까? ㅡ_-)?

특정한 주제를 가지고 컨퍼런스를 진행하려고 했다면, '주제'에 맞게 '분야'선정하고 그 '분야'별 '기술적 흐름이나 유행'을 파악하여 '발표거리'를 선정하고, 각 '발표거리'에 적합한 '전문가'를 선정하여 그들에게 발표를 요청하는 것이 적합하지 않을까?

'유료'에 대해서는 불만이 없다. '정보'를 얻기 위해서는 그만한 댓가를 지불해야한다고 생각한다. 그러나 '유료화'가 되면 돈을 내고 들을 만한 값어치가 있어야 한다고 생각한다. 이에 대해서 조금 더 고민해주었으면 좋겠다.

컨퍼런스가 끝나고 쥐뿔(Google+)에서, 이번 JCO는 어디에서(소셜미디어, SNS라는 단어보다 맘에 드는 소셜미디어, 대부분의 공개되어 있는 네트워크 서비스들은 정보전달매체로서 활용된다는 점에서보면 소셜미디어라고 퉁쳐도 되지 않을까?)도 관련한 소식을 들을 수가 없다는 것이었다. 그 흔한 트위터 해시태그 #JCO 로 나온 이야기가 없다는 것도 아쉽기는 하다. 우리나라 개발자들이 생각보다 소셜미디어를 활용하는 사람이 없다는 점도 나로서는 신기하기도 하다. ㅡ_-)> 블로그를 운영하고 있다고 하면 그걸 신기해하는 사람들도 상당히 많고...

세미나나 컨퍼런스에 가면 알고있는 개발자들을 만나서 이런저런 이야기를 나누는 재미가 있다. 소셜미디어를 통해서만 알고 지내던 사람들을 만나는 재미도 있다. 실제로 얼굴을 대면하면서 만나기는 어렵지만, 스마트폰을 놓지 못하고 사는 개발자들이 소셜미디어를 통해서 서로의 생각을 나누고 친해질 수 있다면 좋지 않을까? 

사진출처 : 한국자바개발자협의회(JCO) https://www.facebook.com/groups/jco.or.kr/

기타

* 해쉬태그 활용하기 : http://twitteran.com/26

* 한국자바개발자협의회(페이스북 그룹) : https://www.facebook.com/groups/jco.or.kr/

* 한국자바개발자협의회(티스토리 블로그) : http://jcoorkr.tistory.com/32

* JCO 컨퍼런스 페이지 : https://www.facebook.com/jcoconf

* JCO 컨퍼런스 접수페이지 : http://jco.zdnet.co.kr/

JCO 관련 사이트는 찾을수록 여기저기 흩어져서 나오네. ㅡ0-);;

* 발표자 : 옥상훈, http://okgosu.net

* 관련자료

    * OAuth Core 1.0 Revision A : http://oauth.net/core/1.0a/

    * OAuth 2.0 : http://oauth.net/2/

* 인증이란?

* ID/PW 방식 인증의 위험성

* OAuth

* 사용자 입증에서 ID/PW 를 서드파티앱에 노출하지 않고 회원 인증할 수 있어야 함

* 서비스 제공자 입장에서는 인증한 API에 대해 권한을 부여하고 이에 따라 API를 제공할 수 있어야 함

* OAuth 버전

* 1.0 -> 1.0a -> 2.0 draft

* OAuth 적용기업

* Facebook

* Foursquare

* Daum

* NHN

* 국내는 아직 1.0a, 해외는 2.0

* OAuth 1.0a 작동방식

* 3-legged model

- User

- Consumer

- 서비스 제공자에게 컨슈머 정보를 등록해 컨슈머키(id)와 시크릿값을 발급 받아야 함

- Service Provider

* OAuth 인증 프로세스

- 써드파티앱은 회원을 서비스 제공자 화면으로 이동시켜 회원인증을 하면서 서비스 제공자로부터 접근토큰을 전달받음

- 서비스 제공자의 API를 호출할 때 접근토큰을 함께 넘겨야 사용가능

* OAuth 1.0a 개발은 서비스 제공자로부터 '접근토큰'을 발급 받기 위함

- 1단계 : 서비스 제공자에게 요청토큰을 요청함

- 2단계 : 화면을 서비스 제공자의 로그인 페이지로 이동시킴

- 3단계 : 서비스 제공자에게 접근토큰을 요청함

* OAuth 1.0a 전체 절차

* OAuth 2.0의 등장

* OAuth 1.0 의 불편한 점을 개선하기 위해 스펙논의

- 암호화, 다양한 앱 지원 등 애플리케이션에 대한 지원 강화

* OAuth 1.0 vs OAuth 2.0 비교

* OAuth 2.0 인증방식

- 3-legged

- 2-legged

* OAuth 1.0a 인증예제

* 네이버 카페 API 활용

* Consumer key, Consumer Secret 은 정확하게!

* 필수 라이브러리

- 인증 로그인화면을 띄우기 위해 WebView invisible 로 선언

* OAuth 2.0a 인증 예제

* 구글 Task API 활용

1. 인증시작

2. 회원로그인

3. 접근토큰 획득

4. API 호출

* 클라이언트 API KEY 생성

* HTTPS를 사용

* 인증서비스를 만들 때 고려사항은?

* 정리

이전다음

012

    플랫폼을 지향하는 서비스들이 대거 출현하고, 이 서비스들에서 OPEN API를 제공하면서 많은 매시업Mashup 서비스들이 출현한다. 이 과정에서 사용자의 인증 절차를 제대로 파악하는 것이 중요하다.

    플랫폼 서비스를 고려하는 이들이 OAuth 인증절차에 대한 좋은 이해의 장이 되었을 것이라 생각한다.

* 발표자 : 주종면

* MongoDB 공식 한국 사용자 그룹 운영자

- 사이트 : http://mongodb-korea.org

* NoSQL 개념

* IT 기술전망 : 클라우드, 빅데이터에서 많은 이야기가 거론됨

* Bic Data 솔루션

- 빅데이터의 수집과 저장기술 오늘의 소개 주제

- NoSQL, MongoDB, Casandra, Hbase

- 빅데이터의 추출과 분산기술

- Hadoop, Storm, Spark, Kafka

- 빅데이터의 분석 및 통계기술

- R, SAS, SPSS

* DBMS for NoSQL : 150여개

- NoSQL 제품군 : 유용성Availability, 일관성Consistency, 파티셔닝Partioning

- Key-Value Database

- Big Table Database

- Document Database

- Graph Database

* NoSQL 제품별 평가결과

- MongoDB : 평가기준에서 전체적으로 좋은 성능의 제품이 나타남

- Community Support 지원

* Data Modeling & 설계 패턴

* MongoDB주요 특징

- Humongos라는 회사의 제품명 

- JSON 타입의 데이터 저장구조를 제공

- CRUD 위주의 다중 트랜잭션 처리가 가능하고 인덱스를 통한 빠른 데이터 검색이 가능

- 분산/병렬처리MapReduce 기능을 제공

- 분산Sharding/복제Replica 기능을 제공

- RDBMS 에서는 대용량의 데이터 처리가 어려워질 수 있다

- Memory Mapping 기술을 기반으로 Big Data 처리에 탁월한 성능 제공

* Collection 생성 : 데이터 저장 가능공간 생성

- 비정형화된 데이터

- db.createCollection("emp", {capped:false, size:8192}); 8k -> 이 공간을 넘어서면 새로운 확장을 하기 위해서 대기상태가 자주 발생하게 된다. 

- db.emp.validate(); Collection의 현재 상태 및 정보분석

* 성능을 개선하기 위해서는 구조에 대한 이해가 필요하다.

* 논리적 구조

- 입력과정에서 생기는 extent의 사이즈에 대한 고려가 필요하군.

* MongoDB 설계 주요 특징

1. MongoDB는 데이터의 중복을 허용하며 비정형화된 설계를 지향한다.

2. MongoDB는 중첩 데이터 구조를 설계할 수 있기 때문에 불필요한 JOIN을 최소화시킬 수 있다.

3. MongoDB는 N:M 관계 구조를 설계할 수 있고 구축할 수 있다.

4. MongoDB는 Schema 중심으로 설계하지 않는다.

* OODBMS vs RDBMS

- Embedded Document

- Extend Document : 먼저 Root Document를 넣고, Root Document에다가 Document 추가

- Linking Document

* 설계패턴

* MongoDB 데이터 저장 구조(Embedded)

- 장점

1. Query가 단순해지고 Join 문을 실행할 필요가 없기 때문에 Document 단위의 데이터 저장에 효과적이며 빠른 성능이 보장된다.

2. 데이터 보안에 효과적이다.

- 단점

1. Embedded 되는 Document의 크기는 최대 10MB  내외

* Manual Linking

- RDBMS : relationship을 통해 제한

- OODBMS : 

- 장점

1. 별도의 논리적 구조로 저장되기 때문에 Document 크기에 제한받지 않는다.

2. 비즈니스룰 상 별도로 처리되는 데이터 구조에 적합하다.

- 단점

1. 매번 논리적 구조간에 Linking해야 하기 때문에 Embedded보다 성능이 늦다.

2. Collection 갯수가 증가하며 관리비용이 많이 든다.

* 만들고자 하는 데이터의 패턴을 고려하여 적합한 설계패턴을 고려해야한다.

- 설계에는 답이 없다.

* Self reference join

* 계층형 데이터 구조

- ANCESTOR, PARENT 를 이용하여 계층혀 데이터 구조 설계 가능

* Inheritence(OODBMS) : 상속 

- 데이터가 저장되는 시점에서 필드와 크기가 저장되기 때문에, 별도로 표현할 필요가 없다.

* MongoDB 성능 튜닝 솔루션

* 적절한 분석을 통해 최적의 컬렉션 구조를 설계하라.

* 빅 데이터의 빠른 검색을 위해 인덱스를 적절히 활용하라.

- 다양한 인덱스 종류

- TTL index : 2.0 에서 추가됨 

- GeoSpatial Index : 좌표정보(위도, 경도, 온도)

* MongoDB의 분산Sharding/복제Replica를 적절히 활용

* Database profiler

- 성능 저하 요소를 찾아 튜닝

* Hint 절과 실행계획

- DB에서 말하는 Hint는 뭐지? +_+)?

* 빅데이터 추출 및 분석

- MongoDB의 Map/Reduce 기능을 이용한 빅데이터 추출

- Javascript function으로 구현

- Aggregation Framework 를 이용해서 기본적인 추출 가능

- MongoDB 와 Hadoop을 연동한 데이터 처리

- Map/Reduce in Python

* Sharding

* MongoDB Architecture

- 좋은 시스템보다는 충분한 메모리 용량이 있을 때 성능만족!

* 정리

이전다음

01234567

    딱, 'DB 전문가'의 느낌이 나는 발표였다. ^^; 몽고DB를 사용할 때 주의해야할 요소요소들을 콕콕 찝어주었다. NoSQL 관련 DB 중에서 가장 높은 선호도와 기술안정성을 가지고 있는 것이 MongoDB기에 많은 사람들이 NoSQL 관련 DB를 고려할 때 우선적으로 떠올리는 DB이기도 하다. 몽고DB 도입시 고려사항들에 대해서 상세히 잘 이야기해주셨다.

    내가 'MongoDB'를 사용하고 경험할 수 있을 때가 언제 오려나~?

* 발표자 : 조대협(조병욱), http://bcho.tistory.com

* 발표자료 : http://bcho.tistory.com/717

* 서버 사이드 개발 

* 모바일 개발쪽으로 엔지니어들의 대거 이동이 일어남

* 4가지 이야기

* 개발프로세스

* 개발도구

* 아키텍처

* 테스트 

* 요즘 트렌드는?

* 서버 사이드 트렌드가 많이 바뀜

- 과거 : EJB, WebLogic만 알면 되었다.

- 벤더를 이용한 테스트 가능

- 현재 : 동물원처럼 tomcat, camel, 코끼리 등

* 소규모(10~20)

* 새로운 트렌드에 대한 수용이 용이함

* 끊임없이 공부, 사람이 재산

* 개발 프로세스 : 소프트웨어 개발 현실 

* 개발자의 현실

* 관리자의 현실

* 소프트웨어 결과물

* 망한 프로젝트가 없다 : 망하기 전에 차세대 진행!

* RUP, CBD, MUI, 방법론

- 방법론은 방법론

- 소프트웨어 개발은 하향평준화 해야한다.

- 웹 서비스는 어렵다.

- REST

* 하향 평준화 : 실용적으로 개발하자

- 기존 방법론과의 차이점

- 요구사항이 변한다는 것을 인정하다.

- 에러가 있음을 인정하여, 자주 테스트

- 협업과 커뮤니케이션

- 애자일 방법론 적용시 자신의 조직 문화에 맞춰서 해야한다.

* 대표적인 개발 방법론

- 스프린트

- 매니지먼트 쪽에서 가시성이 나타나지 않음

- 대안 : Big Umbrella 방법론

- 관리층에게는 예측성, 실무진에게는 가시성

- 각 단계를 스프린트 형태로 세분화하여 애자일 방법론 적용

- 제약

- 어떻게?

- 어려운 것, 중요한 것 먼저

* 테스크 흐름을 만듬

- 태스크를 하루나 이틀의 크기로 나눠 주어야 한다.

- 팀의 속도, 예측이 가능하다.

* 도구들 : JIRA, Redmine, Trac, Mantis

- off site 개발에 유리

- 도구는 도구일뿐, 프로세스를 정립하고 실천하는 것이 우선!

- 실무 적용 : 이슈를 등록하고, 이 이슈를 내가 하고 있는 일을 다른 사람에게 전달할 수 있는 형태로 전달

- 디테일한 기록을 남기기 위해서

- 내가 휴가를 떠나더라도, 다른 사람이 노트만 보고 일을 할 수 있도록 해준다.

- 도구를 공부하는데 너무 많은 시간이 할당된다.

* 엑셀부터 시작하세요.

- 프로젝트의 흐름을 몸에 익히는 것이 중요하다.

* 스크럼, 툴 등 자신에게 맞춰서 하면 된다.

* 개발방법론은 한가지만 사용하지 마라.

- 린(큰 그림), 스크럼(작은 업무처리를 어떻게 할 것인가), XP(커뮤니케이션)

* 개발환경

* 소스 체크아웃 -> 작업 확인 -> 코딩 -> 빌드 등등...

* 툴셋업 보다는 실천

- 커밋 후 일일 빌드

- 일일 빌드 후 메일 알림 처리, 빌드 처리

- 80% 라인 커버리지 

- 빌드 태깅, 테스트 자동화

* daily check out & commit

- 소스 형상화 최신 상태 유지

- SomeUI

- REST API만 테스트

* DEV, QA & STAGE

- 자동빌드 -> 배포시스템(Python Fabric, Ruby Capistrano) -> DEV -> QA -> STAGE

- Python Fabric, Ruby Capistrano : 하루 이틀 정도로 할 수 있을까?

* 아키텍처

* 기술 트렌드의 변화

- 기업 중심의 벤더 주도형 : 기업 중심의 벤더 주도형

- 웹로직, 오라클, EJB, J2EE 몇몇 기술만 알던 시대

- HP 수퍼돔 같은 소수의 대형 서버

- 벤더 지원

- 현재의 기술 트렌드 : SNS 중심의 서비스회사 주도형

- 수 많은 오픈소스 조합

- x86기반 분산 시스템 클라우드 컴퓨팅(Devops)

- 구글

- 개발자가 똑똑해진 시대가 되었다.

* 아키텍처 설계순서

1. 비즈니스 아키텍처

- 비즈니스 관점

2. 시스템 아키텍처

- 아미텍쳐 기본Architecture Principals

- Application Architecture

1. Static Arch.

2. Dynamic Arch.

3. interface Arch.

- Technical Architecture

1. SW deployment arch.

2. HW deployment arch.

- Data Architecture

- Reference Architecutre를 찾아라.

- Reference Arch

- Vendor Consulting

- Case study

3. Architecture Decision Process

- 기술트렌드 : 장애가 나면 빠르게 고치는 것으로 변화

* 일반적인 서버 아미텍처

- 내부 트랜잭션 처리

- 시스템간 연동

- 통계 분석

- 운영

* 레퍼런스 아키텍처 

- User Interface Layer

- Access Layer

- Business Component Layer

- Stroace Layer

* 솔루션

- Apache Camel : 외부 연계가 쉬워?

* Global roll out 시스템의 설계

1. 위치선정

- 법적 이슈 : Regulation

- 회선 속도

- 세금

- 3센터 : 미서부, 영국, 중국

- 중국은 서비스하려면 중국내에서 위치해야하며, 26개 성에 각각 있어야 한다.

2. API 라우팅

3. 데이터 복제

- ETL, CDC

- 과연 데이터 복제가 필요할까?

* 클라우 컴퓨팅상의 아키텍처 설계

- 클라우드 컴퓨팅의 장점

- 빠른 시장 진입

- 운영비 절감

- 초기 투자비용

- 유연한 자원

- 설계시 고려사항

- 느려요 :IO Performance

- 싸지 않다.

- 자신에게 맞는 환경을 선정하는 것이 중요

- 기존 솔루션이 안돌아요

- 장애가 납니다.

* 언어 트렌드

- 스크립트 언어 하나정도는 더 해놔야...

* 테스트

* 테스팅 모델

* 테스트 레벨별 키 포인트

- 단위 테스트

- 통합 테스트 : End2End 시나리오 : 웹은 화면, 단말은 단말에서, 기능검증은 다른 사람이!

- 시스템 테스트 : 성능, 장애, 확장성(증설에 대한 안정성), 안정성

- 마이크로 벤치 마크 테스트

- 기술검증, 1~2일 소요, 30 vuser 정도의 부하

- SOAP UI, Python

- 부하테스트

* 코드 리뷰

- Peer review -> Walk Through -> **Team review** -> Inspection

- Team review가 가장 효과가 좋았다. 

* 정리

이전다음

01234

    서버 관련 기술을 검색해보면 많이 나오는 블로그 '조대협의 블로그'를 운영하고 있는 조대협님의 발표다. 삼성에서 아키텍트로 근무하고 있으며, 수원에서 일할 개발자들을 찾고 있다. 처음듣는 조대협님의 발표였다. 꽤 많은 준비를 해온 것으로 보인다. 발표하는 중간중간 가벼운 이야기로 분위기를 전환하면서 이야기에 대한 집중도를 유도하는 기술도 좋았다.

    JCO에서 들었던 발표자들 중에서는 잘준비된 발표였다. 기술 트렌드나 서버 사이드 개발과 관련된 4가지 주제로 잘 정리된 이야기도 괜찮았다. 전체적으로 흠을 잡을 데 없는 발표였다.

    발표 이후에 발표자료도 자신의 블로그에 빠르게 공개하셨다.

* 발표자 : 박상근

* 공식 홈페이지 : [PyLatte](http://pylatte.org/)

* 스프링 

* Get started

* 토스 3.1, 두꺼워서 베개로도 사용하지 못한다

* 왜 거론했을까? 

* 파이썬 기반 웹 프레임워크

* Django, Webpy, Bottlepy

* python3를 지원하지 않음

* 친구들과 고민하다가 파이썬3으로 프레임워크를 만들어보자

* PyLatte, 카이스트 지식서비스공학과 석사과정

* 구조 

* Django 와의 비교

* python 문법, 상식과 다름

* html 안에 Python 문법 적용해서 사용가능

* 간단해서 탈락 -> 너무 심플하다?

* 기능

* URL Mapping

* Database

- db-mapping.xml

- sql_ex.html

- java iBatis 차용 

* Dictionary : Get/Post -> param 에 모두 합류

* {$ $}

- {$= session[''] $}

* Download

- github : 

- pyPI : [Pylatte 1.0](https://pypi.python.org/pypi/Pylatte/1.0)

- PIP : pip-3.2 install pylatte

* 데모시연

* python 으로 가볍게 MVC1 방식(Servlet)으로 구현한 것 같잖아? ㅡ_-)?

* 말하고 싶은 이야기 : 파이라떼를 만들면서 겪은 이야기들을 나누고 싶었다. 

* Python의 창시자 귀도 반 로썸의 Pylatte 언급

* 첫번쨰 Python 3 웹 프레임워크

* 아직도 python3 가 확산이 안되어 있다는 거구만.

* 무료 홈페이지 영어 교정 : 메일을 주고받으면서 교정받음. 좋구만!

- 인문학(영문학)을 전공한 개발자라...

* 듣다보면 화가 나고, 우울해지고?

* 단순했던 기능들이 '너무 단순하다.' 라는 멘토들의 조언에 따라 Servlet, iBatis를 Python으로 옮겨구현했다는 이야기를 들으면서 어이가 없어서 '피식' 웃었다. 

* 한국인은 칭찬에 인색하다?

* Feedback

* 오픈소스 참여

* 정리

이전다음

01234

    2번째 세션은 '그냥 사람들과 모여서 이야기를 나눴으면 좋았겠는걸?' 하는 시간대였다. 딱히 메리트가 없는 발표이 모여있는 시간대였다. 나한테는 말이다.

    발표내용을 정리해보면 **Python3 을 기반으로 하는 웹프레임워크 'PyLatte'를 국내에서는 최초로 만들어서 '공개소프트웨어 개발대회에서 수상'**했다.

    내가 파이썬이라는 개발언어를 많이 접하게 된 건 3~4년 정도 된 듯 하다. 파이썬을 배워야지 하면서 맨날 변수, 함수 부분에서 맴돌고 있는 상황이지만, 이것도 돌파를 해야지.

    딱히 스프링을 걸고 넘어갈만한 그런 요소들이 없는데, 왜 스프링을 걸고 넘어가는지는 이해가 안되었다. 파이라떼와 스프링의 프레임워크로서의 목적이나 위치가 전혀 다른데 굳이 '도발'식으로 개발자들을 모으려고 했던건가 하는 생각은 지울 수가 없다. 자신만만했던 발표와는 다르게 딱히 매력적인 요소는 없었다. 자바에서 Model1 식으로 서블릿으로 HTML코드를 생성하고, iBatis를 이용해서 SQL을 관리하고 DBMS와 연동하는 거랑 별다른 차이점을 못느꼈으니까.

    개발하는 과정에서 '너무 쉽다.'라는 '멘토'의 이야기를 들으면서 어이없다는 생각도 한다. '단순함'의 아름다움을 모르는 고지식한 '전문 심사위원' 교수님들이 왕성하게 활동하고 있는 '공공기관' 지원 행사들은 문제가 많아보인다. '독창성', '창의성'과 '참신함'을 중점적으로 평가하는 것이 좋은 '개발대회'에서 '트위터'나 '페이스북' 같은 그럴싸한 상품을 바라는 사람들이 '멘토'라고 활동하는 것이 안타깝다.