## 오픈소스/무료툴을 활용한 부하/성능테스트 사례소개

### 발표순서

* 발표자 : 임성현(KSUG, 스펙트라) / 이경환(스펙트라)

* Content

1. 동기 - 부하/성능테스트

2. 성능/부하 툴 소개

3. 설치 가이드

4. 활용 가이드

5. 병목 발견 및 조치

6. 여러가지 함정들

7. 활용팁

### 내용

* 오픈소스로 되어 있는 성능측정도구들은 대부분 영어로 되어 있어 설치가 쉽지 않다. 설치가이드를 제공하여 쉽게 접근할 수 있도록 했다.

* 동기

* 오픈소스/무료 성능 툴이 필요한 이유

- 좀 더 빠른 시점에

- 개발자가 직접

- 부담없이

- 성능을 고려한 실험을 할 수 있도록

* 아래의 질문 해결

- Filter를 사용하면 **얼마나** 성능이 떨어질까요?

* 성능/부하 툴 소개

* 부하툴 : [nGrinder](http://www.nhnopensource.org/ngrinder)

- 소개자료 :  [prezi : 김광섭](http://prezi.com/sv1xtz75ybaq/ngrinder/)

* 자세한 설명

* nGrinder 구성

- nGrinder controller

- Agent

- script 중요

- **지성인이라면 회사 내 서버 혹은 로컬서버를 이용**

* 모니터링 툴 : AppDynamics 지원사양

* 성능툴 : New Relic : http://newrelic.com

* 장점 : 성능 모니터링 서버의

* OpenSource 툴 소개

* 설치 가이드 - overview

* 전자정부에서 공개한 게시판을 이용

- 다양한 비즈니스 로직을 가지고 있음

- WAS, DB

* nGrinder 3.1, 3.1.1 스크립트의 약간 차이가 있음

- nGrinder, nGrinder_agent 실행 설정이 다름

* AppDynamics 설치

* New Relic 설치

* 테스트 대상 환경 구성

- Tomcat, 전자정부 프레임워크 공개 게시판 설치

* Port정리 : 수정필요, 수정안함 구분

* catalina.bat 내에 apDynamics, newrelic 설정

* new Relic을 통한 성능 테스트

* 활용가이드

* nGrinder Basic

- 웹으로 화면 구성되어 있음

- script 작성 : Jython으로 작성되어 있음(새로운 언어에 대한 학습압력이 크다)

- nGrinder는 theGrinder를 감싼 웹 애플리케이션

- 브라우저 중에는 firefox가 제일 궁합이 잘 맞음

- proxy 설정해야함

- python coding:utf-8 설정

- ngrinder_agent/agent.conf

- 자신이 속해있는 agent를 등록

- 테스트 생성 및 실행

- 하나의 트랜잭션에서 얼마나 시간이 소요되는지

* Seesion 처리 - nGrinder 기본 제공

* JSON 처리 : 스크립트 만들 때 라이브러리/리소스 폴더 생성 후 JSON 라이브러리 업로드

- 스크립트 생성시 라이브러리 추가 가능

- 라이브러리를 Java로 작성한 후 jar로 만들어 추가가능

* 그 결과를 확인하기 위해서 appDynamics를 활용

* Sequence : 동일한 User ID를 막는다면 -> python의 글로벌 변수 활용

* Doc 생성 - groc 활용(http://blog.outsider.ne.kr/907)

- Python 문서화 도구

* 병목발견 및 조치

* 성능 측정과 함께 모니터링 해야할 것

- visualVM 의 snapShot 기능

- nGrinder

* 성능 측정 후에 모니터링 해야할 것

* WAS가 죽거나 멈췄을 때 확인해야할 것

- 메모리 덤프를 뜨고 툴로 확인

- 동시접속자가 증가하면 세션이 계속 생성됨

- 세션은 static 영역에서 정보가 기록됨

* **중요** : 성능 리소스를 확인해봐야할 것

- nGrinder의 TPS 만으로는 확인할 수 없다.

- DB 문제, 병목구간

- VisualVM을 활용해서 확인

- sampling 플러그인

* 활용팁

* [SUT, nGrinder, 전략]

* 오픈소스를 사용하며 얻은 경험을 피드백

* 발표 후

* 성능에 대해 무관심했지. 앞으로는 신경을 좀 써야겠어.

* 성능분석해서 어떤 의미를 둘 것인가를 고민

## 자바카페와 함께하는 Apache HttpComponents

### 발표순서

* 발표자 : 김흥래

### 내용

* 관련 사이트 : [http://hc.apache.org/](http://hc.apache.org/)

* HttpClient 의 new brand

* HttpComponent

* Web Spider, Http Proxy, Web Service System

* HttpClient, HttpCore 라이브러리로 구성

* Apapche Commons 프로젝트에서 독립 프로젝트로 승격

* ApacheCommons : [http://commons.apache.org/](http://commons.apache.org/)

* HttpClient의 시작 : Apache Slide 프로젝트 진행중에 HttpClient 모듈이 commons로 분리

* HttpClient Module : 사용되면서 인지도가 높아짐

* 2005년 : Jakarta Commons HttpClient

- Apache Commons 에서 가장 많이 사용되는 라이브러리 : Common Loggin

- HttpClient 3.x 출시

* HttpClient 3.x 와 HttpClient 4.x 호환성이 없음

- HttpClient 3.x Blocking I/O 만 지원, non-Blocking I/O 지원

- Java NIO 지원여부

* HttpComponents(HttpCore + HttpClient)

* [HttpCore](http://hc.apache.org/httpcomponents-core-ga/index.html)

* [HttpClient](http://hc.apache.org/httpcomponents-client-ga/index.html)

* [Http AsyncClient](http://hc.apache.org/httpcomponents-asyncclient-dev/index.html) : HttpCore NIO 이용, 현재 베타버전 지원, non-Blocking I/O 기반

* Common HttpClient : 기존 HttpClient 3.x 지원

* HttpCore를 이용하여 구현함

* HttpCore 라이브러리

* Low Level HTTP 라이브러리

* Blocking I/O 기반 기술 제공

* non-Blockoing I/O 기반 기술 제공

* [HTTP 1.1 프로토콜](http://www.w3.org/Protocols/rfc2616/rfc2616.html) 완벽 지원

* HttpCore / HttpCore NIO

* HttpClient 라이브러리 특징

* 모든 HTTP 메소드 구현(OPTIONS, TRACE)

* Blocking I/O 기반의 동작방식

* HTTP 메시지 전송 및 수신 가능

* 손쉬운 HTTP proxy 구성 가능

* javascript 실행 불가능

* URI redirect 동작, HTML 랜더링 불가

* **Web Broswer** 가 아니다.

- 맞어. HTTP 통신만 지원하지.

- [관련페이지](http://hc.apache.org/httpcomponents-client-ga/primer.html)

* HttpClient

* 

* 모듈

- HttpClient

- org.apache.http 패키지 경로 획득

- DefaultHttpClient 생성

- HttpMime

- HttpClientCache

- CachingHttpClient 생성

* Http proxy

* Java URLConnection

- JDK 기본 API

- 성능적인 이슈가 존재함

* HttpClient 3.x

- HTTP 통신 라이브러리

- 쿠키 핸들링 가능

- Http Pipelining : 이미지 다운로드 시, 동시에 여러개의 연결시도

- 응답이 오기전 요청을 날린다?

* HttpClient 4.x

- 기존 3.x와 하위호환성 없음

- Non-Blocking I/O 지원(정확하게는 Http AsyncClient, 현재 베타)

- Proxy Cache 지원

* HttpComponents 사용예

* [pache Synapse](http://synapse.apache.org/)

- 서로 다른 서버들간의 통신을 프록시로 처리

- ESB(Enterprise Service Bus)

* Android

* 기타 

* 블락킹Blocking 에 빠진다는 것은 어떤 의미일까?

* Cross Domain 법칙?

* Proxy 처리의 이점에 대해서 공부해봅시다.

* Thread safe한 개발이라

* https, ssl 통신모듈 지원?

* HttpClient는 Browser가 아니다. 

* 안드로이드에서 유용하게 싸용했다. 

## OpenStack을 적용한 클라우드 컴퓨팅 환경의 구현

### 발표순서

* 발표자 : 안명호(MHR Inc, foolishjames.com)

* 참고자료

* [2011.11.25 / OpenStack한국커뮤니티 안재석 on DevOn](http://devon.daum.net/2011/pdf/b-1-openstack.pdf)

### 내용

* Project Mission : 450대의 서버를 가상화로 100대로 줄여 동일한 기능 수행!

* AWS을 만들고 기존에 있던 웹 호스팅일 하자.

* 희망찬 출발! :cloudstack(레퍼런스가 많아서)

- KT도 클라우드 컴퓨팅을 사용했었음

* 고객의 요구

- 안정정

- 성능저하 최소화

- **기존 시스템의 100% 이전**

- 다양한 서버 및 인프라 환경 지원

- 오픈소스 사용(VMware 로 실행시 5억원)

* 시험운영에서 많은 문제가 발생 : 설치 다음이 문제

1. 나만이 이 문제를 겪는 것은 아니다.

2. **질문은 많지만 답이 없는 경우가 대부분**이다.

3. 대부분의 답은 몇놈으로부터 나온다.

- 커미터가 대부분의 대답을 해준다. 

4. 소스코드가 깔끔하지 않다.

- function 이름이 비슷하고, 기능의 중복이 많다.

* 시험운영과 함께 포기

* 불안한 새출발 : OpenStack

* Python으로 진행

* 코드가 깨끗

* 질문과 답변 참여도가 높음

* 활발한 커뮤니티 활동

* Data swift : Data Storace 서비스

* 결정의 순간들Decisions

* CloudStack vs OpenStack

- **Hypervisor** : KVM or XEN

- 하이퍼바이저는 호스트 컴퓨터에서 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼을 말한다. 가상화 머신 모니터라고도 부른다.

- KVM : Redhat 에서

- XEN : Cytrix 에서

- 하이퍼바이저가 서버를 만들어주기 때문에 클라우드 컴퓨팅에서 제일 중요한 요소이다.

- 어느 쪽을 선택하느냐에 따라서 성능을 판가름

- XEN < KVM 의 성능이 급격히 좋아지고 있다. 

- KVM이 설치, 유지관리가 쉬워짐

* 하이퍼바이저 : KVM 선택

- 버그수 : KVM 0 vs XEN 23

- 개발사 : redhat

- performance : KVM이 좋아졌어

* 스토리지 : 가상머신이 동작하는 디스크

- Local

- 성능은 뛰어나지만

- 유지보수가 어려워??

- Remote

- Hybrid

- 선택

- 가장 빈번하게 사용하는 리소스 : VM의 생성과 삭제

- AutoScale : 필요에 따라서 VM을 생성했다가 삭제하도록 하는 것

- OS 는 Local

- File이나 DB는 Remote(NFS) 처리

* Networking Model

- 네트워크 문제는 쉽지 않다.

- Physical Layer와 Logical Layer

- Flat

- 기존에 있는 Physical Layer을 그대로 사용

- **FlatDHCP**

- 네트워크 결정 판단 기준 : Multi tennants or Not?

- Single 여부?

- VLAN 

* 설치Installation

* Deployment tool

- 100대의 대상 머신에 대한 Deploy를 어떻게 할까?

- 3가지

- Del clover

- JuJu

- ???

- tool을 이용한 툴을 활용

* Devstack

- 동작한다Working!

- private Cloud : Rackspace

- 믿을만한 회사다!

- 조작Customization 가능

* Devstack 의 아쉬운 점

- 재부팅후 서비스가 재시작되지 않음

- Restart.sh script를 작성해서 등록

* Configuration

* 경험자의 조언 : 하지만 만나지 않는 것이 좋을 뻔 했다. "2개월 걸려 설치와 환경설정을 했고 실제 운영하다보니 예상치 못한 문제가 지속적으로 발생한다"고 했다.

- 노하우는 공개가 어렵지.

* **Logging!!**

- 본인 스스로 문제를 해결해야 하고, 해결하기 위해서는 정보가 필요하고 로그를 수집해야했다.

* 컴퓨터마다 log 수집

- rsyslog

- 3가지 레벨 

- Nova : 하이퍼바이저에 접근하지 않음

- Nova-compute.log

- libvirtd

- instance-xxxxx.log

- libvirtd.log

- HyperVisor

- XEN or KVM log

* Nova --debug

- 동작 프로세스 확인

* 착각!Migration

* 'Fedora 8'이 안되요!

- 지원여부를 확인

- VM 이미지를 이용해서 가상머신 생성

- Booting Error

- 문제의 원인은 Disk IO

- VM Image 생성 후 IDE IO를 수정해서 해결

* 배치Deployment

* Final Decision!!

- 4대 : 1.5개월

- 추가 96대 : Fabric

- 스크립트 Push실행

* VM Deployment Balancing

- 클라우드 컴퓨팅 : 4가지의 컴퓨팅 자원 제공

- DISK, CPU, Memory, Network

- Good machine

- Disk, CPU & Memory, Network

- Bad machine

- Network, Network, Network

- Disk, Disk, Disk

- 적절하게 컴퓨팅 리소스가 분배되어 처리되도록 처리

* 온전한 행복, 교훈

* **오픈스택 소스코드를 수시로 보게 된다.**

* **Virtualization Hardware Spec이 중요하다.**

* **Log와 Monitoring이 매우 중요하다.**

* Storage가 Performance Bottle Neck이 된다.

* **Automated Configuration Management가 필수**

* Balanced VM Deployment가 중요하다.

* Network performance Degradation을 예상

* 문제가 발생하면 직접 해결해야 한다.

* **Host Server 성능의 70%를 넘지 마라.**

* 결론은 Cloud Friendly Software Architecture!!

* OpenStack 팁

* Openstack에서 지원하지 않는 기능

- devstack 을 이용해서 upgrade 처리

* Openstack 을 이용한 구축

1. devstack(설치방법)

* Cloud Computing 이 가져오는 변화(개발자에게?)

1. 컴퓨팅 환경의 변화

- 물리적인 환경

- 아키텍처의 큰 변화

- Component jar -> API Service

- SQL DB -> NoSQL

- Tangled interface -> layered interface

- Fat complex Object -> Lightweight Object 

- Service

- Latency(데이터 동기화)

- Distributed(API Service)

2. DevOps = Developer + Operator

- DevOps - improvement -> Users -> Feedback -> DevOps

- 클라우드 환경에서는 자동화Automation이 가능하기 때문에 Operator의 역할이 자연스럽게 개발자에게로 스며들었다.

- Netflix

* 기타

* **개발환경이 크게 변화하고 있다.**

## 데이터를 실시간으로 모아서 처리하고자 하는 다양한 기법들

### 발표순서

* 발표자 : 김병곤(JBoss Community)

### 내용

* 빅데이터는 real-time으로 간다.

* KB 국민카드의 실시간 빅 데이터

* 금융권 최초로 실시간 빅 데이터 프로젝트를 추진

* 금융권에서는 RM에서 큰 쓴맛을 봤기 때문에 빅 데이터에 매우 조심하는 경향이 있음

* 과거의 방식과 별 차이가 없음

* 분석에서 접근하지 말고 기술적인 문제를 해결하는데 오히려 더 집중해야 함

* 상용 제품이냐 오픈소스냐는 중요하지 않지만 비용을 줄이기 위해서는 IT 전담조직의 의지가 필요

- 시작은 엔지니어에게서 시작된다.

* 실시간 빅데이터의 요건들

* 쇼핑몰 사이트의 사용자 클릭 스트림을 통해 실시간 개인화

* 위치 정보 기반 광고 서비스

* 시스템 정보 수집을 통한 장비 고장 예측

* 카드 결제시 각종 상황에 맞는 경품/쿠폰 제시

* Scale up vs Scale out

* Scale up : 하드웨어 스펙 증가(장비의 성능)

- Concurrent Programming

- 언어 :  Eralng, Scalar, Clojure

* Scale out : 서버의 갯수를 통한 수평적 확장

- Distriubted Programming

- 기법 : MapReduce

* scale up과 scale out이 교묘히 혼용되지만 기본은 Sacle out

* Scale up과 Scale out 선정기준

- Performance

* Scale out을 선택하는 가장 큰 이유

- 지리적인 분산 등의 여러요인을 고려해야 하기 때문에

* 하지만 Scale out은 어렵다.

- Availability, Scalability

* 실시간 처리 방식에 따른 기술적 특징

* 이벤트 중심 처리

- 시간에 따른 일련 연속된 이벤트 흐름을 처리

- 특정한 Time Window 또는 건수를 연속적으로 처리

- Scale up 아키텍처

- 선언적 Rule 기반 처리

- 단순한 시스템 구성

- 내가 긁을 때

* 스트리밍 중심 처리 

- 시간에 따른 일련의 연속된 이벤트 흐름 처리

- Scale out 아키텍처

- Computation 중심 처리

- 복잡한 시스템 구성

- 강남지역에서 해당카드를 긁는 사람이 몇명? 

* 실시간 처리를 위한 오픈소스

- Esper CEP, Drools Fusion CEP 는 손쉽게 가능

- Storm, Apache S4 프로그래밍으로 구현해야해서 어려움

* tweetping.net

* 데이터를 화면에 어떻게 뿌릴까(가시화)를 할 것인가?

- 고객이 데이터를 확인하려는 시점 등의 영향을 받음

- Log 수집 분석

- Bic data for Real-time it

- 더 많은 정보를 수집하고 팔아야 한다.

- 실시간!!!

* Splunk

- 비싸! 고가의 라이센스비용

* Sumo Logic

* 2013 아키텍처 컨퍼런스에서 발표했던 자료

- 필요에 따라서 적절한 자원을 선택 사용

* CEP & Flume & Hadoop

- Esper CEP

- Scale up 아키텍처 기반 이벤트 탐지

- Length Windows

- Time Window

- 최근 10분 이내, 20분이내

* 개발자의 Skill set이 달라진다.

- 시스템 엔지니어링이 동반

- 장비 설치 테스트

* MapReduce 처리방법

* 한 자바싱 10기가

* 단순무식한 방법이지만 빅데이터에서 사용하는 기본적인 방법

* 배치에서 실시간 처리

* Apache S4

* Yahoo

* Scale out 아키텍처 기반 분산 스트리밍

* Near Real-time search index

* Hadoop MapReduce

- Process Element(PE)

- 패키징을 해서 서버에 전달하면 알아서 분산처리

* Twitter Topic Counter

- DataPE -> Pojo 생성

* 동작하는 원리를 이해해야 하고

* 외부시스템과의 연계를 통해서 동작을 확인해야 하고

* 엔지니어링을 해야 한다. 

* Storm

* Twitter

* Scalable, Scalar로 구현

* 서버 -> TCP/IP -> Storm 전송 -> 수집데이터 MongoDB 등에 넣어 두었다가 데이터를 분석하여 Chart로 표현

* Bolt로 넣고...

* 손실율을 0%로 만들겠다. 

* Getting started with Storm

- 책을 따라서...

* 배운 것들

* 시스템 구축에 대한 노하우 또는 노력이 절대적으로 필요

* 상대방의 경험이 중요할 수도 있지만 중요하지 않을 수도 있다.

* 많은 하드웨어가 없다면 구현이 어렵다.

* 업무를 알아야 한다. 기술이 모두라면 좋겠지만 결국 업무를 알아야 한다.

* 모든 것을 실시간으로 할 수 없다.

* 실습 예제

* 내가 앉아서 듣고 싶은 내용은 뭘까나?? 나도 발표를 한다면 어떤 내용으로 발표를 할 것인가?

* **개발환경이 크게 변화하고 있다.**

* 누가 오픈소스를 잘 활용하느냐가 관건이다.

* 문서화, 커뮤니티, 성숙도 등을 고려해야 한다.

- 성숙도와 문서화가 중요하다.

* 인프라, 개발, 의 요소가 잘 잡혀 있어야 해. 

* 고객의 요구사항만 받고서 쉬이 접근할 수 없는 요건들이 있다.

* 실시간은 내가 시간을 유지하는 것이 아니라 시스템이 유지한다.

* 값만 넣어주면 된다.

* 시스템 구축과 차트를 그리는 것

* D3 프레임워크

* 조금 공부하고 효과를 볼 수 있는 분야

3개월에 한번씩 찾아오는 '공감세미나'가 지난 10월 20일, 강남 교보타워 23층에서 열렸다.
이번 '공감세미나'의 주제는 '자바 라이프, 자바 스타일'이었다. 
  자바의 탄생에서 시작해서 자바가 가지고 있는 장점을 통해 자바라는 언어를 한줄로 정의해보고, 
자바라는 프로그래밍 언어와 함께 지내온 세월을 되짚어보고, 현재 사용하고 있는 자바를 보다 
효율적으로 분석하고 활용할수 있는 방법을 배워보았다. 마지막에는 '토비의 스프링3' 낭독회(솔직히 ... 이런 느낌이었다)로 정리가 되었다. 

  마지막 부분에서는 아쉬운 부분들이 많았다. 그렇다고 딱히 내가 뭐라고 할 수 있는 부분은 아니다(그러면서 뭐라고 하고 있는 이 몹쓸 행태, 나중에 내가 발표를 하면 어떤 소리를 듣게 될기 걱정이 앞선다).

  이번 '공감세미나'는 내가 자바개발자로서 걸어온 삶에 비추어, 15년 이상의 연륜을 머금은 자바라는 
언어를 살펴볼 수 있는 좋은 시간이었다. 적어도 십여년 정도는 우리나라에서 '자바'라는 프로그램 언어를 통해서 밥굶을 일은 없을거라는 확신도 가지게 되었다. 물론 밥굶을 걱정이 사라지면, 그 다음은 잉여력을 모아서 조금 더 새로운 것들에 대해 관심을 가지고 익히려는 '자기계발'의 노력을 멈춰서는 안된다. 
  '프로그래머'로 살아가기 위해서 필요한 습관은 '새로운 것을 배우고 익히는 것을 멈추지 않는 것'이라 생각한다. 그런 의미에서 보면 '요즘의 나'는 많이 게을러졌다. 회사일이 힘들다는 핑계로 10월은 
배움을 멀리해왔다.

공감 세미나 시작전 소식전달

• NIPA 공개SW 역량프라자
  • www.oss.kr
SK planet 소식
• README 블로그(http://readme.skplanet.co.kr/) 소개
• SK Planet 에서 주관하는 기술 컨퍼런스(테크 플래닛http://www.techplanet.kr/)이 곧 열린다.
  자세한 정보는 사이트를 참조하기 바라며, 곧 참관신청이 열릴 것이다. 이때는 빠르게 신청러쉬를 해내야겠다. 
  10월 마지막에 열리는 H3 컨퍼런스는 아쉽게도 참관신청을 따내지 못했다. 하아. Orz…

자바 탄생 이야기

• 발표자 : 김영수
• James Gosling : 자바의 창시자
• Hello world(s)!
  • From Code to culture : A 10 Year Celebration of Java Technology
  • We’re missing it
  • 환경의 변화가 일어나고 있는 시기
  • Gang of four
  • Green team at Menlo Park
  • 네트워크 기반의 서비스 제작
• OAK - THe tree outside his window
  • No Language for his idea then make it
  • 실험용으로 만든 언어를 활룡하는 것
• In 1992, 13 members
• Duke - Poe Palrang
  
  
• 다른 관점? 자신이 작성한 코드를 단순히 돌리고 실행하는 것을 뛰어넘는다라…
• Bill Joy
  • C++ 과 비슷하지 않느냐?
  • But almost nobody liked it.
• going public : 공개의 길에 접어들다. Release
  • 실크
  • 시
  • 후추
  • 네온사인
• May 23, 1995
  • SunWorld Conference 에서 자바가 세상에 그 모습을 드러냈다.
• 창시자의 많은 고민들이 묻어나는 언어
  • 디바이스에 대한 고민
• 프레임워크를 사용하지 않으면 개발을 못하는 개발자들
  • 프레임워크에 대해서 의존적으로 변해가고 있는 것은 분명하다.
  • 나 역시도 프레임워크가 없다면 제대로 힘을 발휘할 수 있을까?
자바
• 네트워크 환경에 적합한 언어
• Remote Contoler 에 적합한 언어
• A Simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, high-performance, multithreaded, dynamic language
  
  

•  컴퓨터 개론의 느낌이 났다.  자바를 생업의 수단(내가 밥을 먹기 위해 선택한 언어니까. 내게는 밥과 같은 존재지! 
    먹고 사는 건 중요하잖아?)으로 삼았지만, 자바의 역사는 잘 모른다. 꽤 많은 사람들은 자신이 사용하는 언어의 ’역사’에 대해 무지하다. 그것이 어떤 목적을 가지고 누군가 만들었는지에 대해서는 관심을 가지고 시작하는 일은 흔하지 않다. 그러다가 애정이 생기면, 자신이 사랑하는 것에 대해서 하나라도 더 많은 것을 알고 싶은 욕심이 생긴다. 그 욕심들이 쌓이고 쌓여서 사랑이 되는 것이다. ’자바’를 사랑해서 나쁠 건 없잖은가? ㅎㅎ 요즘은 파이썬과 바람을 피고 싶은 마음이 뭉글뭉글 피어오르고 있는 상황이기는 하지만, 나의 프로그래밍 베이스캠프는 ’자바’다.

Java : The Good Parts

• 주제 ; 자바 언어의 특징과 활용 방안의 주관적인 탐구
• 발표자 : 박성철(남자는 핑크!)
• “프로그래밍 언어들을 한 문장으로 소개”
  • http://npcode.com/blog/archives/124
    • Perl
    • C++
    • J
    • List
    • Java : 자바는 공신력 있고 설득력 있는 한문장 소개를 찾지 못했다. C++ 보다 정체성이 불분명한 녀석이다.
      • Java 가 어떤 언어인지 살펴보고 정의를 해보자.
• 화산파(화산파 정보)의 수련
  • 기종? 기본기, 내공부터 쌓자?
  • 검종? 기술부터 익히자!
  • 과연 나의 선택은? 나는 본의 아니게 검종부터 시작한듯 하다. 이제는 내공수련의 중요성을 깨닫고 심신수련을 병행하고 있달까?
• 자신의 체격조건을 이용해서 홈런을 잘 친다.
  • 자바가 좋은 언어는 아니지만, 그 의미가 있다.
• 자바 백서
  • 자바의 설게 목표
    1. 단순함, 객체중심, 친숙함
    2. 견고하고 안전한
    3. 아키텍처 중립성과 이식성
    4. 고성능
    5. 인터프리터, 스레드, 동작
    6. 1, 2는 언어, 3, 4, 5는 VM
  • 단순함, 친숙함
    • Java = C/C++ - WTF
    • 설계는 더이상 넣을 것이 없을 때 완성되는 것이 아니라, 더이상 뺄 수 없을 때 완성되는 것이다.
    • 지금까지 배워온 Syntax(다른 언어를 배워오던 경험)를 유지하면서 배울 수 있다.
  • 견고하고 안전한
    • 견고성 = 정적 static 타입(컴파일러가 타입을 확인)
    • 안정성 = 엄격한 strong 타입(실행 중에 타입 확인)
      • 타입체크를 통해서 안정성을 높여주겠다.
    • Unit testing isn’t enough. You need static typing too.
      • http://evanfarrer.blogspot.ca/2012/06/unit-testring-isnt-enough-you-need.html
      • 정적 타이핑은 버그를 탐지하기엔 불충분하며, 단위테스트를 해야한다.
      • 단위 테스트를 장착하고 나면, 정적 타입 확인은 과잉이다.
      • 정적 타이핑은 유효한 프로그램을 오류로 분류하기도 하므로 해롭다.
      • 사용자가 많고 테스트가 잘 정착되어 있는 파이선 오픈소스 프로젝트 네 가지를 하스겔로 1:1 포팅했더니…
    • 정적 타입의 또다른 장점
      • 도구(TOOL)지원
      • IDE : Eclipse, IntelliJ IDEA, Netbeans
        • FEED BACK
        • 자동 완성 / 자동 제안
        • 리팩터링 지원
        • Boiler plate code(너저분한 코드) 자동 생선
        • 자바 언어가 우리나라에서 지금의 영향력을 가지고 있는 이유 중 하나는 정적 타입이 가지는 장점이 최대한 활용되어 있기 때문이 아닐까 한다. 리팩토링(소스의 통합과 변경이 용이하다는 것이 가지는 장점은 무시할 수 없다)이 자유롭다(자유로운 만큼 잘못하면 낭패를 보기 쉽다).
      • 정적 코드 분석
        • PMD, CheckStyle, FindBugs, JDepend
  • 객체중심 프로그래밍
    • 범용언어
      • 인터페이스
        • 시뮬라67
          • 알고리즘 표현
          • 코드 분해
        • 스몰토크
          • 메시징 : 생물의 세포, 상호 작용을 하는 유기체로 판단
      • 패키지
        • 디렉토리
        • 이름 영역
        • 모듈 : 응집의 단위
      • 기본 가시성
        • public < protected < package-private < private
        • 캔트백(Kent beck)과 에릭 감마(Erich Gamma)의 가시성 토론 : 은익 정보 단위 테스트
      • 내부 클래스
        • Lisp 에서 나온 개념
        • 클래스 = 파일 원칙 위배(자바 1.1에서 추가)
      • 열거형(Enum)
        • C++에서 일부러 가지고 오지 않았던 특징
        • Java Enum = Class = Type Safe
        • Java 영역 namespace이 기본제공
        • 설계 패턴 중 상대 패턴(State Pattern) 적용가능
      • 지네릭
        • C++(template)에서 유보한 특징
        • 알고리듬이 처리할 타입을 사용시에 지정 코드 재사용 기술
        • Object는 안녕
        • 하지만 복잡한 상황이 생기기도
  • JVM
    • 인터프리터
      • 자바는 인터프리터 언어
      • 아키텍처 중립성, 이식성
      • 동적 로딩 & 바인딩 : 클래스 로더
      • 파이선과 유사한 실행구조 .java -> .class -> JVM .py -> .pyc -> PVM
    • 자동 메모리 관리(GC)
    • 리플렉션
      • 프로그램의 메타 데이터를 다를 수 있는 기술
    • 메타 프로그래밍
      • 다른 프로그램을 생성하거나 조작하는 프로그램을 작성하는 행위
        • 선행처리
        • 컴파일러 확장 - Lombok
        • 리플렉션 | 바이트 코드 생성/조작 - Spring Framework DI + AOP
    • 다언어 프로그래밍Polyglot
      • JVM 은 Java 만의 VM이 아니다.
      • Byte Code 라면 원천을 따지지 않고 실행
      • 80 : 20, 모든 문제를 해결할 수는 없다.
      • JVM에서 돌아가는 프로그밍 언어의 수는 90여개
• Java는 관리자가 좋아하는 언어
  • 자바 코드의 총량
    • 상위 구조 재사용
    • 실 작성 코드량
    • 하위 기능 재사용
• 언어 확장 : Library
  • 자바는 언어적 한계를 설계로 해결하도록 합니다. 그래서 좀 수다스럽고 번거롭지만 지금까지는 21세기의 코볼 역할을 잘 하고 있어요.
• 구조 재사용 : 프레임워크
  • ’나 이제부터 프레임워크 만들거야.’라고 하면 망하기 쉽다.
• 자바에 대한 공식 정의
  • 자바 프로그래밍 언어는 범용 병행 클래스 기반 객체 중심 프로그래밍 언어다. 특히 가능한 별다른 조건 없이 다양한 환경에서 동작하도록 설계되었다.

• 자바를 배우려고 ’자바에 대한 입문서’를 펼치면 항상 첫장에서 하는 이야기가 있다.
  자바는 객체지향적인 프로그래밍 언어이고 다양한 환경(윈도우, 리눅스, 유닉스)에서 실행가능한 인터프리터 언어이다.
   이런 식의 설명이 있다. 아무런 지식이나 경험없이 읽으면 그냥 ’그렇군.’하고 쿨하게 넘어가게 된다. 사실 나는 지금도 ‘쿨하게’ 넘어간다. ㅡ_-);; 그런거 생각하면 머리 아프니까. ㅎㅎ 레드불 2캔의 위력은 엄청났다…

챔피언이 사랑한 언어, Java

• 발표자 : 양수열(Heimdallr CEO)
• 1996년
  • Java 라고 쓰고 Innovation 이라고 읽는다.
• 오래전 그날
  • 새롭고 혁신적인 젊은 언어
  • 새롭게 성장하는 기술
  • 웹과 같이한 언어
  • 혁신을 좋아한 젊은 엔지니어들
  • 좋은 취지에 공감한 자바 개발자 커뮤니티
• Keyword
  • Distrubuted Object(분산-객체)
  • OOP
  • Garbge Collector
    • JVM 엔지니어들이 C 전문가
  • Enterprise
    • 시스템이 커져가고 있다.
  • SOA
  • CBD
• 2012년
  • Java 라고 쓰고 Platform 이라고 읽는다?
    • Java가 과연 플랫폼(기반)으로서의 역할을 하고 있는건가?
• 우리의 오늘
  • Well matured Technology.
    • 서버 사이드의 개발을 하는 개발자는 없다. 서버 사이드 개발자가 귀한 대접을 받게 될거야. +_+)b
  • Language - > Platform
  • Old fashion & Old Engineer.
  • Cloud, Big data, Mobile + Java + other!!
  • Server-side 가 요구에 따라서 분리가 되고 있다.
• 우리는 어디로?
  • Forever WAS!! (like Mainframe)
  • Mobile
  • Startup(Scale up! 확장에 대한 이야기)
    • 수요가 공급에 비해 턱없이 부족하다.
      • 하지만 자신의 실력이 없다면, 그것도 소용이 없다.
      • 자신의 실력을 키워라.
  • Platform + New language
  • Data Analysis(Big data, 개발자가 직접 빅데이터를 분석)
  • Algorithm
  • Courage(용기!) : 격변의 시기! 도전하고 시도해봐야한다.
• A whole new World!
  • Developer = Creator!
  • Global Market
  • One Man Company
    • 개발할 수 있는 능력이 없으면 불가능하다.
  • HW -> SW 이슈 변화
  • High Technology

•   전자정부 커뮤니티에서 만났던 양수열님과는 또 다른 편안한 모습이었다.
    그 때와는 달리 편안한 분위기로 세미나에 참가한 사람들의 분위기를 살피며 이야기를 하는 양수열님의 모습은 여유로워 보였다.
    청계천 옆 정보화진흥원에서 지켜봤던 떄와는 확연히 달랐다. 그 때야, ’전자정부 프레임워크를 통해 어떻게 써먹을 수 있을까?’라는 기대를 품고 갔던 사람들의 기대치와는 다른 발표였던 탓도 있긴 했다. ’전자정부 커뮤니티’에서는 왕왕 발생하는 일이다.
    사석에서 만나 이야기를 나눠본 ’양수열’님은 ’사람좋고 경험많은 부장님 스타일’의 느낌이 물씬 풍겨났다. ’JAVA 챔피언’이라는 칭호를 가진 사람에게서 풍겨나는 연륜을 품고 있달까? 그 모습은 어딘지 15년 묵은 자바와 비슷한 느낌이 났다. ㅎㅎ ’15년 묵은 자바’의 느낌은 어떤 모습일까? 쓰면서 상상해보고 있다.

자바 기반 시스템의 개발 및 운영에 도움이 되는 툴들

• 발표자 : 이상민(About me로 청중의 웃음을 이끌어 낼 수 있는 발표자! 응?)

• JDK, Profiling, troubleshooting, monitoring, ui, test, IDE tools

• IDE
  • Eclipse만 IDE가 아니에요.
  • Netbeans, IntelliJ(하지만, 난 안쓸거야. 아마.)
• JDK Tools
  • jps
    • java process 목록을 제공하는 툴
    • “pid 프로그램이름”
    • 자세한 옵션 보고 싶으면 jps -v
    • 해당 계정으로 실행한 자바 프로세스만 보임(다른 계정으로 실행한 프로세스 목록은 보이지 않음)
  • jstat
    • JVM의 상황을 모니터링하는 프로그램
    • 이 중에서 유용한 옵션들
      • gcutil : GC 상태 모니터링
      • gccapacity : JVM의 메모리 점유 상황 모니터링
    • GC 최적화시 사용
    • 운영중에도 사용가능하다
  • javap
    • 자바 클래스 파일 분석
    • javap -c className 을 실행하면, 해당 클래스의 opcode를 출력
    • Java virtual machine spec.
  • jstack
    • 스레드 덤프(thread dump) 발생 덤프 발생 시점에 어떤 스레드가 어떤 작업을 수행하는지 제공하는 덤프 파일
    • 사용하지 않는 것이 좋음 경우에 따라서 프로그램에 Hang 이 발생할 수 있음
    • Kill –3 pid 를 사용할 것을 권장
  • jmap
    • 힙 덤브 팔생 덤프 발생시 어떤 객체가 어떤 값을 갖고 있는지 저장
    • 운영시에 해당 프로그램을 실행하면 자바 프로세스가 멈추므로 꼭 필요한 경우에만 사용할것
    • 실행 옵션 jmap -dump:format=b,file=filename pid
  • jhat : Heap Dump 분석
  • jconsole, jvisualvm

• Unit test tool

• UI test tool
  • 주요툴
    • Selenium
    • NHN의 GUITAR
• Acceptance test tool
  • 인수 테스트
  • 주요툴
    • fitness
    • NAF
• Performance test tool
  • 시스템의 성능을 측정하기 위한 툴
  • Load Runner만이 성능 테스트 툴이 아님
  • 상용툴
    • QA Load(Microfocus)
  • 무료툴
    • Grinder
    • JMeter
• Profiling tool
  • 프로그램의 성능, 메모리 사용량, 코드 커버리지 등을 확인할 수 있음
  • 운영 서버에 많은 성능 저하를 발생시키므로 반드시 개발자 PC 및 개발 서버에서 사용해야만 함
  • 상용과 무료툴로 나뉘지만, 상용툴을 권장
  • 자바 프로그래머들이 IDE만큼 옆에 끼고 살아야 하는 툴
  • 상용 프로파일링 툴들은 소스의 라인단위까지 분석이 가능하다.
    • 특정 라인에서 얼마나 시간과 메모리가 소요되었는지를 파악할 수 있음
  • 주요 툴
    • DevPartner for java
    • JProbe
    • JProfiler
      • Lock이 걸린 상황에 대한 분석이 쉽다.
  • 시작점을 찍고, 끝점을 찍으면 Snapshot 정보를 떨구는데 CPU 사용량, 각종 기록을 tree 형태로 제공
• Monitoring tool이란?
  • APM : Application Performance Monitor
    • Jennifer
    • WebTune
    • Pharos
  • JMX : Java management extension
    • Visual VM
    • JConsole
• Troublshooting 툴의 구분
  • Thread dump 분석툴
    • TDA
  • Heap dump 분석툴
    • IBM Heap analyzer
    • MAT
  • Tracing 분석툴
    • BTrace
      • Dtrace와 같이 수행중인 애플리케이션에 붙어 필요한 검증 가능
    • Byteman
• CI Tool
  • 지속적이고 반복적으로 빌드를 수행해 주는 툴
  • Hudson, Jenkins
• F/E tools(Front-End)
  • 웹 기반의 UI를 분석하기 위한 툴
  • 웹 페이지 최적화 툴
    • YSlow : 웹페이지에 대한 성능평가
    • Google Chrome : speed tracer
• 유의사항
  • Tool은 Tool일뿐
  • 용도에 맞춰 사용
    • 남용할 경우 심각한 문제가 생김
    • 상황에 맞는 툴을 제대로 선택하는 것이 제일 중요
Tech Planet!
• 11월 16일 코엑스 에서 열립니다.
• 사전 참가등록은 10월 23일 오후 1시(13시)에 시작합니다. +_+)b
  
• 
  

• ---

  

  프로그래머로 산다는 것

  저자

  유석문 지음

  출판사

  로드북 | 2012-09-26 출간

  카테고리

  컴퓨터/IT

  책소개

  -

  

  ---

• 의 공동저자 중 한번이시다. 지금 읽고 있는 책을 모두 읽으면 구매해보려고 한다.
  

자바 개발 안티 스타일 - 스프링을 이용한 레거시 코드 개선 중심으로

• 발표자 : 윤여진
• 초난감 Dao
• 책 내용정리의 시간이구나. 죄송합니다. 쓸 말이 별로 없어요.

  ’자바’라는 언어를 밥벌이의 도구로 삼고 이 바닥에 뛰어든지 어느덧 3년째에 들어서고 있다. 보통 3년차가 되면 뭔가 일을 잘 할 수 있을 듯한 느낌을 품게 된다. 그런데 막상 일을 하면, 여전히 모르는 것이 더 많다. 그래서 좌절감을 느끼는 경우가 많아진다. ‘나, 프로그래밍 좀 하는 것 같아!’ 라고 자신만만하게 들이대다가, 차갑게 마음이 식어버린 여인의 손바닥 마냥 매서운 현실 앞에 좌절을 느끼게 된다. 모든 사람들이 그러지는 않겠지만, 요즘의 내가 그런 상황이다. 뜻하지 않게 회사에서 진행하는 ’회사의 운명’이 걸린 ’프로젝트’를 진행하는 역할을 수행하게 된 것이다. 쩝. 고달프다. 고달퍼.

  힘들거나 잘못된 상황에 닥치면 ’초심으로 돌아가라’는 말이 있다. 처음 시작할 때의 겸손하고 낮은 자세로 임하던 때로 돌아가 다시 차근차근 정리하면서 처리해보라는 뜻이랄까? 이 부분에 대해서는 해석이 여러 개니까 자기한테 맞춰서 해석하자. 요즘 어깨에 들어간 힘을 너무 빼서 추욱 늘어진 것은 분명하다. 이 순간을 잘 견뎌내고 앞으로 한걸음 나가면 나에게 좋을 거라 기대하며 한걸음을 뗀다.

내가 ’자바’를 배우겠다고 이 바닥에 뛰어든지 횟수로 3년째다. 

 - 개발자의 길(Developer’s Road) - 1.1. 나의 개발자 입문 과정 

그렇게 자바를 배우는 과정의 기록을 남기면서 지금까지 도달했다. 그리고 앞으로도 쭈욱 ’자바’를 밑바탕으로 해서 개발자의 삶을 이어갈 것이다. 그리고 그 기록을 꾸준하게 남기려고 노력하겠지.

p.s. 내가 블로그를 시작한지도 어느새 6년을 넘겼네요. 남긴 글의 수는 1080개가 넘어섰고, 처음 블로그를 시작할 때의 그 마음을 다시 되새겨 봐야겠습니다. 이제 블로그에 쓰는 글의 일부는 어떤 목적(모아서 책을 만들어보고 싶은 욕심이 있음)을 위해 쓰여지겠죠. ^^

밤에 잠자기 전에 휘리릭 정리하고 휘리릭 쓰니, 정리가 안된 부분들이 생겨나는군요. 흐음...

발표제목 : Apache Thrift
발표자 : JBoss 김병곤님
발표자료 :

 Apache Thrift_v0.1_20110914.pdf

윽... 쓰다가 날려먹었군요. 블로그 편집기에서 글을 작성하지 말아야겠습니다. ㅡ_-)>

이 부분에 관련해서는 찬찬히 내용을 쓰도록 하겠습니다. 하고 싶은 이야기가 많거든요. ^^

우리들의 생활 속에 IT가 밀접하게 파고들면서(우리는 스마트폰을 우리 손에서 놓을 수가 없습니다. 아, 저만 그런가요?) 사용자들이 쓰기 쉬운 서비스를 제공하기 위한 기술은 복잡해져만 갑니다. 기술이 어려운 건 그때나 지금이나 마찬가지라고 하시더군요. ^^

발표제목 : The state of union : Cappuccino
발표자 : OSXDEV 김정님
발표자료 :

- 카푸치노(cappuccino) 사이트 : http://cappuccino.org/

- 오브젝티브-제이(Objective-J) tutorial : http://cappuccino.org/learn/tutorials/objective-j-tutorial.php

- OSXDEV.org 사이트 : http://osxdev.org/phpBB3/

 CappuccinoStateOfTheUnion.pdf

  데스크탑 애플리케이션을 웹앱으로 빠르게 만들 수 있는 오픈소스 프레임워크다. 맥OS에서 개발툴 Xcode를 이용해서 개발할 수가 있다고 한다. Objective-J는 Objective-C 처럼 작성해서 Javascript 로 컴파일 해준다. Objective-J 로 만들어진 소스를 language.js 파서를 이용해서 javascript로 컴파일해준다. 와웅. 개발 고수님들은 language.js(PEG : Parser Expression Grammar)에 관심을 가지셨습니다. ^^

깃헙 language.js : https://github.com/tolmasky/language

에서 소스를 확인해봐야겠네요.

  카푸치노 0.9 버전에서는 아직 모바일 웹에 대한 지원은 되지 않고 있다고 합니다. 1.0 에서 모바일 환경을 지원한다고 하지만 아직은 미완의 프레임워크이기 때문에 찬찬히 지켜봐야할 필요가 있을 듯 합니다. xcode의 UI환경을 웹앱으로 옮겨줄 수 있다는 장점이 있는 프레임워크라서 많은 분들에게 관심을 얻을 것 입니다. 맥OS 환경을 가진 개발자들이라면 한번 이상씩은 접해볼 수 있겠죠(라면서 나도 맥북을 쓰고 있다는 것을 깨달았... ㅠㅅ- 걍 리눅스환경을 계속 쓸 것을...).  깔끔한 맥UI를 사용할 수 있다는 것은 큰 장점이 될 수 있을 듯 합니다.

  모토로라로 넘어갔던 소유권이 구글에게 넘어가면서 어떻게 다듬어져서 나올지 기대해봅시다. ^^

발표제목 : Grails와 애자일 개발

발표자 : KSUG 장시영님

발표자료 :
Grails.pdf

Grails.pptx

또 부끄럽습니다. >ㅅ<

- 프로그래밍 그루비

프로그래밍 그루비 Groovy in Action 국내도서>컴퓨터/인터넷 저자 : 디에크 쾨니히(DIERK KNIG),기욤 라포르쥬(GUILLAUME LAFORGE),앤드루 글러버(ANDREW GLOVE),폴 킹(PAUL KING),존 스킷(Jon Skeet) 출판 : 인사이트 2009.03.06 상세보기

그루비(Groovy)는 자바(java)같은 루비(Ruby)라고 한다.

자세한 내용은 여길 참고하면 더욱 좋을 것 같다.

http://greatkim91.tistory.com/15

그루비는 극도로 복잡해진 자바 웹애플리케이션 개발환경의 복잡성을 극적으로 줄여줄 수 있다고 한다. 여기에는 DDD(Domain-Design Development - http://en.wikipedia.org/wiki/Domain-driven_design)와 ORM(Object Relation Mapping - http://en.wikipedia.org/wiki/Object-relational_mapping)의 막강한 힘을 사용할 수 있게 된다고 한다....는데, 쉽지 않아 보인다. 하지만 자바를 배운 사람이라면 조금은 쉽게 그루비에 접근할 수 있지 않을까 조심스레 추측해본다. 나도 들여다봐야할 것 같지만 당장은 자바, html, javascript, 안드로이드를 익혀야하는 중이다.

  엔터프라이즈 환경은 점점 복잡해지고 있다. 다양한 프레임워크와 기술들이 혼합되어 고도화되고 있다. 하지만 그걸 사용하여 개발해야하는 개발자들은 크게 발전하지 못하고 제자리 걸음을 하고 있다. 그루비를 통해서 이런 답보상태를 벗어나 한걸음 더 나아갈 수 있다면 그것으로도 큰 진전을 이룰 수 있을 것이다. ^^

  그루비를 이용한 레퍼런스(큰 프로젝트에 적용되어 성공한 사례를 레퍼런스라고 하더라. 우리나라에서는 이런 레퍼런스가 많이 나타나는 게 금융권에서 진행하는 차세대사업...이었던 것 같다. @_@ 우리나라에서 새로운 웹서비스나 애플리케이션들이 성공한 사례가 많지 않으니까...)들이 많이 나타난다면 우리나라 IT업계에서도 그루비가 듬직하게 한 분야를 차지할 수 있지 않을까?

  초반에 약간의 학습비용이 지출되긴 하겠지만 그 이상의 가치를 얻을 수 있을까?

  조만간 이 녀석을 사용하는 프로젝트를 경험할 수 있기를 바란다. +_+)