건우농장

Dan Pink 가 동기 유발의 놀라운 과학에 대해서 설명합니다.

농부건우 — Wed, 14 Dec 2011 16:11:01 +0900

Effective Java 2th

농부건우 — Sun, 06 Nov 2011 21:52:01 +0900

[이미지 출처는 강컴]

예전에 사놓고, 읽다 안읽다가 이제야 완료!
읽다 보면 읽히지 않는 부분도 있지만(동시성, 직렬화 등) 모두 읽음!!!!
개인적인 생각으로는 자바 개발자라면 한 번은 꼭 읽으면 좋은 책인것 같음
100% 이해는 못했지만 차후에 다시 한 번 읽어야 할 것 같은 책

펌] 행복한 회사와 나라를 만들기 위한 노력

농부건우 — Tue, 11 Oct 2011 00:27:06 +0900

원본 : http://health20.kr/2192

SmartFox Server Video Tutorials

농부건우 — Mon, 05 Sep 2011 15:26:04 +0900

듣기가 안되지만 대충 흐름은 ㅡㅜ

생활코딩 아마존 동영상 강의 링크

농부건우 — Sun, 04 Sep 2011 14:44:05 +0900

역시 세상에는 좋으신 분들이 많이 있습니다 @_@

https://twitter.com/#!/egoing/status/108724438949838848
http://vimeo.com/album/1680709

1. 아마존 웹서비스 - 회원가입편 from egoing on Vimeo.

2. 아마존 웹서비스 - 제품의 종류 및 가격 from egoing on Vimeo.

3. 아마존 웹서비스 - EC2 생성방법 from egoing on Vimeo.

4. 아마존 웹서비스 - EC2 접속방법 from egoing on Vimeo.

5. 아마존 웹서비스 - 아파치 설치 from egoing on Vimeo.

6. 아마존 웹서비스 - 콘솔관리 from egoing on Vimeo.

lombok

농부건우 — Sun, 04 Sep 2011 14:42:59 +0900

예전 회사 과장니밍 알려주신 lombok
확실히 불필요한 부분이라든지 그런 부분을 어노테이션으로 처리 할 수 있어서 코딩량이 확실히 줄어 듬

공식 사이트 : http://projectlombok.org/
ibm developer work : http://www.ibm.com/developerworks/kr/library/os-lombok/index.html?ca=drs-
pom

<groupId>org.projectlombok</groupId>

<artifactId>lombok</artifactId>

<scope>provided</scope>

</dependency>

windows 사용시 사용하는 프로그램

농부건우 — Fri, 02 Sep 2011 11:53:33 +0900

RocketDock :http://rocketdock.com/
launchv : http://www.launchy.net/

mac port을 열고 있는 프로세스

농부건우 — Wed, 31 Aug 2011 00:01:36 +0900

http://snippets.dzone.com/posts/show/5712

sudo lsof -i -P | grep port번호

spring 3 exception http status code

농부건우 — Thu, 25 Aug 2011 21:48:34 +0900

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html

Exception	HTTP Status Code
`ConversionNotSupportedException`	500 (Internal Server Error)
`HttpMediaTypeNotAcceptableException`	406 (Not Acceptable)
`HttpMediaTypeNotSupportedException`	415 (Unsupported Media Type)
`HttpMessageNotReadableException`	400 (Bad Request)
`HttpMessageNotWritableException`	500 (Internal Server Error)
`HttpRequestMethodNotSupportedException`	405 (Method Not Allowed)
`MissingServletRequestParameterException`	400 (Bad Request)
`NoSuchRequestHandlingMethodException`	404 (Not Found)
`TypeMismatchException`	400 (Bad Request)

Application Express

농부건우 — Wed, 10 Aug 2011 23:52:09 +0900

알게된 링크 : http://apex.oracle.com/pls/otn/f?p=4600:6:2379073318715443::NO:::
한글 설명 : http://mudchobo.tistory.com/285
page : http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html

sql developer 에서 mssql 프로시저 실행 실패

농부건우 — Wed, 10 Aug 2011 23:45:49 +0900

요즘 mssql 기반으로 개발을 진행 해야 하게 되었음
개발 환경은 mac 기반이라 디비 클라이언트를 무엇을 쓸까 고민 시작
원격으로 접속해서 써도 되지만 그렇게 하기 싫어서 client 검색 시작(재난의 시작 -_-)
예전에 sql developer로 my sql client 사용한 적이 있어서 검색 시작!
역시 mssql도 연결 하여 사용 가능
여자 저차 검색하여 셋팅 후 테스트 하니 제대로 실행
문제는 프로시저가 실행이 안되는 기이한 현상이 발생 ㅡㅜ
열심히 구글 신께 문의 드렸지만 특별한 해결책을 찾지 못함
아 오늘 이걸로 귀중한 시간 및 힘을 낭비 ㅡㅜ

restful api 설계

농부건우 — Thu, 28 Jul 2011 22:49:18 +0900

요즘 restful api(??) 설계를 하는데 완전 개삽질중 ㅡ,.ㅡ

다행이 이사님이 리뷰 해주셔서 산으로 가지는 않는데 그래도 머리가 나빠서 그런지 잘 나오지는 않음

오늘 이사님과 대화 중 기억에 남는 것들 정리

operation 들의 조합에 따라 client 입장에 따라 어떤 작업이냐에 focus를 맞추는게 중요
id가 들어가면 그 아이디의 소속을 써줘야 함 -> id가 들어 갈 때는 앞에 collection 들어가주는게 좋음

ex) /items/item_no

url로 카테고리 구분 시 교집합이 없도록 구성

/items/swords
/items/spears

이거 말고도 많은 내용을 말씀해주셨는데 기억력의 한계로 많이 못 적음 아나 ㅡ,ㅜ

담부터는 녹음을 해야 겠음

어제에 이어서 오늘도 추가

* 프로시저 중심의 비지니스 로직에서 리로스 중심으 비지니스 로직을 변경해야 하는 이유를 생각해보자 -> 도메인 주도 개발 -> 리소스 중심 비지니스 로직이 100% 좋은거는 아니지만 장점이 무엇인지 고민해 보자 -> 도메인 == 데이타
* url는 되도록 명사로 작성하자 -> 맨 처음 설계할때 자꾸 룰을 url 에 배핑시킬려고 한 url를 보고 지적해주심 @_@
* 전체적인 url은 예외를 최대한 줄이는 것이 좋다. -> 추가시 설명이 없어도 추가하기가 쉽다 -> client가 url를 봤을 때 url의 의미를 쉽게 볼 수 있는가? -> 인식을 잘 되도록

훗 이번에는 녹음했다는 ㅋㅋㅋ

spring sts jboss 6 버전 추가

농부건우 — Tue, 19 Jul 2011 23:11:14 +0900

sts download 후 servers에서 jboss 등록 할려고 하니 5 버전까지 없음.

열심히 구글링 한 결과 처리

참고url : http://blog.naver.com/PostView.nhn?blogId=fbstar&logNo=100125533104

플러그인 url : http://download.jboss.org/jbosstools/updates/stable

merge tool

농부건우 — Sun, 03 Jul 2011 23:41:47 +0900

http://www.araxis.com/

소프트웨어 아키텍트가 알아야 할 97가지

농부건우 — Tue, 28 Jun 2011 22:50:33 +0900

휴우 다 읽는데 1주 걸렸네.
거이 모든 글이 마음에 와 닫지만 그 중에서 크게 와 닫는거는

고객의 요구사항보다 여러분의 이력에 더 우선순위를 두지 말라 (Page 2)
말하는 것에 대해서 말하다.
반복 작업과 싸워라(Page 92)
아키텍처 메타포어를 확대 해석하지 말자(Page 112)
간단한 것은 간단하게 하라(Page 124)

이것을 기억하세요 미래 요구사항을 추측한다면 여러분의 50%가 틀렸을 겁니다. 그리고 나머지 49%는 완전히 틀린 요구사항일 것입니다. 오늘의 문제는 오늘 풀어야 합니다.
완벽함은 충분함의 적이다(Page 140)

꼭 아키텍트가 아니더라도 읽어 보면 좋은 책인 듯 합니다
(난 아키텍트가 아닌데 읽었네 ㅋㅋㅋ)

MVCC(다중 버전 동시성 제어)

농부건우 — Thu, 09 Jun 2011 00:04:42 +0900

MVCC는 행 수준 잠금을 으용한 것이라 볼 수 있는데, 대부분의 경우 잠금이 필요 없으며 오버헤드가 메우 적다. 구현 방식에 따라, 쓰기 작업 동안 잠금 없는 읽기를 허용하고 필요한 레코드만 쓰기 잠금할 수 있다.

MVCC는 트랜잭션이 시작할 때 스냅샷을 만들고 해당 트랜잭션은 그것을 가지고 동작한다. 그러므로 트랜잭션의 실행 기간에 관계 없이 일관된 데이터를 볼 수 있다. 이는 다른 트랜잭션이 동시에 같은 테이블에서 다른 데이터를 보게 될 수도 있음을 의미한다.

출처] MySql 성능 최적화 page 13

android emulator no space error

농부건우 — Sat, 04 Jun 2011 23:02:44 +0900

error message
[2011-06-02 15:49:37 - ddms]transfer error: No space left on device

[2011-06-02 15:49:37 - Device]Error during Sync: No space left on device

해결 메세지
./emulator -avd emulator-name -partition-size 512 -no-snapshot-load

android tab link

농부건우 — Sun, 22 May 2011 22:16:13 +0900

http://cranix.net/364
http://androidhuman.tistory.com/151

mac eclipse 단축키

농부건우 — Sun, 22 May 2011 22:09:32 +0900

키 옵션 보기 귀찮아서 정리중

option+command + 화살표 위아래 : 라인 복사
shift_controll + 화살표 위 -> 블록 선택
controll + option + 화살표 위아래 > 메소드 이동
command+shift+c -> 주석처리

컴포넌트

농부건우 — Wed, 20 Apr 2011 19:52:58 +0900

Activities : 사용자 인터페이스를 구성하는 기본 단위
Srvice : 백그라운드에서 무한히 실행되는 컴포넌트
Broadcase Receiver : 시스템으로부터 전달되는 방송을 대기하고 신호 전달시 수신하는 역활
Content Provider : 다른 응용 프로그램을 위해 자신의 데이터를 제공

출처] 안드로이드 프로그래밍 정복

ThreadLocal 사용법과 활용

농부건우 — Fri, 15 Apr 2011 01:23:29 +0900

원본]

자바 1.2 버전부터 제공되고 있지만 아직 다수의 개발자들이 잘 몰라서 활용을 잘 못하는 기능이 하나 있는데, 그 기능이 바로 쓰레드 단위로 로컬 변수를 할당하는 기능이다. 이 기능은 ThreadLocal 클래스를 통해서 제공되는데, 본 글에서는 ThreadLocal 클래스의 기본적인 사용방법과 활용 방법을 살펴보도록 하겠다.

ThreadLocal이란?

일반 변수의 수명은 특정 코드 블록(예, 메서드 범위, for 블록 범위 등) 범위 내에서만 유효하다.

{
    int a = 10;
    ...
   // 블록 내에서 a 변수 사용 가능
}
// 변수 a는 위 코드 블록이 끝나면 더 이상 유효하지 않다. (즉, 수명을 다한다.)

반면에 ThreadLocal을 이용하면 쓰레드 영역에 변수를 설정할 수 있기 때문에, 특정 쓰레드가 실행하는 모든 코드에서 그 쓰레드에 설정된 변수 값을 사용할 수 있게 된다. 아래 그림은 쓰레드 로컬 변수가 어떻게 동작하는 지를 간단하게 보여주고 있다.

위 그림에서 주목할 점은 동일한 코드를 실행하는 데, 쓰레드1에서 실행할 경우 관련 값이 쓰레드1에 저장되고 쓰레드2에서 실행할 경우 쓰레드2에 저장된다는 점이다.

ThreadLocal의 기본 사용법

ThreadLocal의 사용방법은 너무 쉽다. 단지 다음의 네 가지만 해 주면 된다.

ThreadLocal 객체를 생성한다.
ThreadLocal.set() 메서드를 이용해서 현재 쓰레드의 로컬 변수에 값을 저장한다.
ThreadLocal.get() 메서드를 이용해서 현재 쓰레드의 로컬 변수 값을 읽어온다.
ThreadLocal.remove() 메서드를 이용해서 현재 쓰레드의 로컬 변수 값을 삭제한다.

아래 코드는 ThreadLocal의 기본적인 사용방법을 보여주고 있다.

// 현재 쓰레드와 관련된 로컬 변수를 하나 생성한다.
ThreadLocal<UserInfo> local = new ThreadLocal<UserInfo>();

// 로컬 변수에 값 할당
local.set(currentUser);

// 이후 실행되는 코드는 쓰레드 로컬 변수 값을 사용
UserInfo userInfo = local.get();

위 코드만으로는 ThreadLocal이 어떻게 동작하는 지 잘 이해가 되지 않을테니, 구체적인 예제를 이용해서 ThreadLocal의 동작 방식을 살펴보도록 하겠다. 먼저 ThreadLocal 타입의 static 필드를 갖는 클래스를 하나 작성해보자.

public class Context {
public static ThreadLocal<Date> local = new ThreadLocal<Date>();
}

이제 Context 클래스를 사용해서 쓰레드 로컬 변수를 설정하고 사용하는 코드를 작성할 차례이다. 아래는 코드의 예이다.

class A {
    public void a() {
        Context.local.set(new Date());

        B b = new B();
        b.b();

        Context.local.remove();
    }
}

class B {
    public void b() {
        Date date = Context.local.get();

        C c = new C();
        c.c();
    }
}

class C {
    public void c() {
        Date date = Context.local.get();
    }
}

위 코드를 보면 A, B, C 세 개의 클래스가 존재하는데, A.a() 메서드를 호출하면 다음 그림과 같은 순서로 메서드가 실행된다.

위 그림에서 1~10은 모두 하나의 쓰레드에서 실행된다. ThreadLocal과 관련된 부분을 정리하면 다음과 같다.

2 - A.a() 메서드에서 현재 쓰레드의 로컬 변수에 Date 객체를 저장한다.
4 - B.b() 메서드에서 현재 쓰레드의 로컬 변수에 저장된 Date 객체를 읽어와 사용한다.
6 - C.c() 메서드에서 현재 쓰레드의 로컬 변수에 저장된 Date 객체를 읽어와 사용한다.
9 - A.a() 메서드에서 현재 쓰레드의 로컬 변수를 삭제한다.

위 코드에서 중요한 건 A.a()에서 생성한 Date 객체를 B.b() 메서드나 C.c() 메서드에 파라미터로 전달하지 않는다는 것이다. 즉, 파라미터로 객체를 전달하지 않아도 한 쓰레드로 실행되는 코드가 동일한 객체를 참조할 수 있게 된다.

ThreadLocal의 활용

ThreadLocal은 한 쓰레드에서 실행되는 코드가 동일한 객체를 사용할 수 있도록 해 주기 때문에 쓰레드와 관련된 코드에서 파라미터를 사용하지 않고 객체를 전파하기 위한 용도로 주로 사용되며, 주요 용도는 다음과 같다.

사용자 인증정보 전파 - Spring Security에서는 ThreadLocal을 이용해서 사용자 인증 정보를 전파한다.
트랜잭션 컨텍스트 전파 - 트랜잭션 매니저는 트랜잭션 컨텍스트를 전파하는 데 ThreadLocal을 사용한다.
쓰레드에 안전해야 하는 데이터 보관

이 외에도 쓰레드 기준으로 동작해야 하는 기능을 구현할 때 ThreadLocal을 유용하게 사용할 수 있다.

ThreadLocal 사용시 주의 사항

쓰레드 풀 환경에서 ThreadLocal을 사용하는 경우 ThreadLocal 변수에 보관된 데이터의 사용이 끝나면 반드시 해당 데이터를 삭제해 주어야 한다. 그렇지 않을 경우 재사용되는 쓰레드가 올바르지 않은 데이터를 참조할 수 있다.

브라이언의 동기화 규칙(Brian's Rule of Synchronization)

농부건우 — Tue, 12 Apr 2011 17:44:29 +0900

언제 synchronized를 적용해야 할까? 브라이언의 동기화 규칙을 따르자.

이후에 다른 스레드가 읽을 수 있는 변수를 기록할 때나 이전에 다른 스레드가 기록했ㅇ르 수 있는 변수를 읽을 때 동기화를 사용해야 한다. 추가적으로 읽는 객체나 기록하는 객체 모두 동일한 모니터 락을 사용하여 동기화를 해야 한다.

출처] Thnking In Java Page 1073

현재 개발자로서 나의 위치는 어디일까나?

농부건우 — Tue, 12 Apr 2011 01:08:34 +0900

회사가 생각지도 않게 파산하게 되어 실업자 놀이중.

여기 저기 이력서 넣고, 면접 보러다니면서 느끼는 점은 개발자로서 나의 위치는 어디일까? 라는 생각이 문든 듬.

대학생활때는 C, C++, Win32에 관심 있어서 공부하고,

사회에 나와서는 웹 개발자로 근 5년 가까이 근무.

그러고 보니 한 3년은 서버 관리도 같이 병행.

돌이켜 보면 회사생활에 매진하고, 시간 쪼개서 공부 하고 그랬는데. 월등하게 잘 하는거는 없는것 같음.

머리가 나쁜건지, 욕심만큼 머리가 못 따라 가는 것 같고.

머리가 나쁘면 하나라도 꾸준히 해야 하는데. 이것 저것 손대고 ㅡㅜ

JavaScript도 잘 하고 싶고,
SE로도 대성하고 싶고,
Spring 같은 프레임워크도 만들고 싶고,
디비도 DBA처럼 관리도 잘 하면서, 쿼리도 잘 짜고 싶고
설계도 잘 하고 싶고,

아~~~~ 이렇게 하고 싶은거는 많은데 ....

용어 정리

농부건우 — Sat, 09 Apr 2011 23:56:19 +0900

과장님과 이야기 하다가 모르는 용어가 나와서 정리

OLTP(online transaction processing)
[출처]
OLTP[오엘티피]는 일반적으로 은행이나, 항공사, 우편주문, 수퍼마켓, 제조업체 등을 포함한 많은 산업체에서 데이터 입력이나 거래조회 등을 위한 트랜잭션 지향의 업무을 쉽게 관리해주는 프로그램이다. 아마도, 가장 광범위하게 설치된 OLTP 제품은 IBM의 CICS일 것이다.

오늘날 온라인 거래처리는 하나 이상의 회사가 관련되는 네트웍 트랜잭션을 지원해야하는 요구를 점점더 많이 받고 있다. 이러한 이유 때문에, 새로운 OLTP 소프트웨어는 트랜잭션들이 네트웍 상의 다른 컴퓨터 플랫폼들 위에서 실행될 수 있도록 해주는 클라이언트/서버 처리 및 브로커 소프트웨어를 사용한다.

OLAP(online analytical processing)
[출처]

OLAP[올랩]은 사용자로 하여금 데이터를 다른 관점으로 쉽게, 또한 선택적으로 추출하고 바라볼 수 있게 해준다. 예를 들어, 어떤 사용자는 분석될 데이터로서 9월 중 같은 제품과의 매출액을 비교하기 위해 7월중에 플로리다주에서 팔린 모든 회사의 비치볼 제품 판매량을 보여주는 스프레드시트를 요청함으로써, 같은 시기동안에 플로리다주에서 팔린 다른 제품들과 비교해 볼 수 있다. 이러한 종류의 분석을 쉽게 하기 위해 OLAP 데이터는 다차원 데이터베이스 내에 저장된다. 관계형 데이터베이스가 2차원이라고 생각할 수 있는데 반해, 다차원 데이터베이스란 각 데이터 속성(제품, 매출지역, 기간 등과 같은)이 각기 별개의 차원으로서 간주되는 것이다. OLAP 소프트웨어는 차원들 간의 교점을 찾아내어, 그것들을 표시할 수 있다. "기간" 등과 같은 속성들은 세부속성으로 나뉘어질 수 있다.

OLAP은 데이터 마이닝, 또는 이전에는 판별하지 못했던 데이터 항목들 간의 상관관계를 찾아내는 일 등에 활용될 수 있다. OLAP 데이터베이스는 데이터웨어하우스 만큼 클 필요는 없는데, 왜냐하면 추이분석을 위해서 모든 트랜잭션 데이터가 필요한 것은 아니기 때문이다. ODBC를 사용하면, OLAP을 위한 다차원 데이터베이스를 만들기 위해 기존의 관계형 데이터베이스로부터 데이터를 가져올 수 있다.
OLAP 제품을 선도하고 있는 제품으로는 Arbor Software의 Essbase와 오라클의 Express Server가 있다. 이러한 제품들은 다중사용자 환경을 위해 설계되었으며, 사용자 수에 따라 사용자 1인당 최소 $2,500 정도의 비용이 소요된다.

DB(Data warehouse)
[출처]

데이터웨어하우스(data warehouse)란 사용자의 의사 결정에 도움을 주기 위하여, 기간시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스를 말한다. 줄여서 DW로도 불린다.

1980년대 중반 IBM이 자사 하드웨어를 판매하기 위해 처음으로 도입하였다. IBM은 인포메이션 웨어하우스(Informationn Warehouse)라는 용어를 사용하였다. 이후 이 개념은 많은 하드웨어, 소프트웨어 및 툴 공급 업체 들에 의해 이론적, 현실적으로 성장하였으며, 1980년대 후반 Inmon이 데이터 접근 전략으로 데이터 웨어하우스 개념을 사용함으로써 많은 관심과 집중을 받게 되었다.

웨어하우스(warehouse)는 창고라는 의미인데 데이터의 수용이나 분석 방법까지 포함하여 조직 내 의사 결정을 지원하는 정보 관리 시스템으로 이용된다. 목적별 데이터를 비롯해 기업 활동 전반에 필요한 정보를 전 회사 규모의 데이터베이스로 일원화해 관리한다. 원시 데이터 계층, 데이터 웨어하우스 계층, 클라이언트 계층으로 구성되며 데이터의 추출, 저장, 조회 등의 활동을 한다. 데이터웨어하우스를 사용하는 것은 고객의 구매 동향, 신제품에 대한 반응도, 제품별 수익률 등 세밀한 마케팅 정보를 얻는 것을 목표로 한다. 목적별 데이터뿐만 아니라 기업 활동에 관한 모든 정보를 전 회사 규모의 데이터베이스로 일원화하여 관리하므로 그 용량이 작게는 수백 GB에서 수 TB에 이른다. 따라서 대형 메인 프레임 등 기존의 플랫폼으로는 시간과 비용의 제약으로 곤란한데 병렬 서버기의 등장과 자기 디스크 장치의 대용량화•저가격화로 가능하게 되었다. 병렬 서버를 사용하면 하나의 검색 처리 요구를 분할하여 복수 프로세스로 병렬 처리함으로써 고속으로 검색할 수 있기 때문이다. 병렬 서버에 대응해서 관계형 데이터베이스 관리 시스템(RDBMS)을 사용한다.

[편집]특징

웨어하우스 데이터는 비즈니스 사용자들의 의사결정 지원에 전적으로 이용된다.
기업의 운영시스템과 분리되며, 운영시스템으로부터 많은 데이터가 공급된다. 데이터 웨어하우스는 여러 개의 개별적인 운영시스템으로부터 데이터가 집중된다. 기본적인 자료 구조는 운영시스템과 완전히 다르므로 데이터들이 데이터 웨어하우스로 이동되면서 재구조화되어야 한다. 운영시스템과 데이터 웨어하우스는 근본적으로 다르며, 두 개의 매우 상이한 시스템을 요구한다.
데이터 웨어하우스는 신뢰할 수 있는 하나의 버전 (one version of truth)을 사용자에게 제공한다. 기존 운영시스템의 대부분은 항상 많은 부분이 중복됨으로써 하나의 사실에 대해 다수의 버전이 존재하게 된다. 그렇지만 데이터 웨어하우스에서 이러한 데이터는 전사적인 관점에서 통합된다.
시간성 혹은 역사성을 가진다. 즉 일, 월, 년 회계기간등과 같은 정의된 기간과 관련되어 저장된다. 운영시스템의 데이터는 사용자가 사용하는 매순간 정확한 값을 가진다. 즉 바로 지금의 데이터를 정확하게 가지고 있을 것이 요구된다. 반면 웨어하우스의 데이터는 특정 시점을 기준으로 정확하다.
주제 중심적이다. 운영시스템은 재고 관리, 영업관리 등과 같은 기업운영에 필요한 특화된 기능을 지원하는 데 반해, 데이터 웨어하우스는 고객, 제품 등과 같은 중요한 주제를 중심으로 그 주제와 관련된 데이터들로 조직된다.
컴퓨터 시스템 혹은 자료 구조에 대한 지식이 없는 사용자들이 쉽게 접근할 수 있어야 한다. 조직의 관리자들과 분석가들은 그들의 PC로부터 데이터 웨어하우스에 연결될 수 있어야 한다. 이런 연결은 요구에 즉각적이어야 하고, 또한 신속성을 보여야 한다.
데이터 웨어하우스는 읽기 전용 데이터베이스로서 갱신이 이루어지지 않는다. 웨어하우스 환경에서는 프로덕션 데이터 로드(Production Data Load)와 활용만이 존재하며, 운영시스템에서와 같은 의미의 데이터의 갱신은 발생하지 않는다.
데이터 웨어하우스는 일정한 시간 동안의 데이터를 대변하는 것으로 snap shot과 같다고 할 수 있다. 따라서 데이터 구조상에 '시간이 아주 중요한 요소로 작용합니다

Materialized View란?

농부건우 — Sat, 09 Apr 2011 23:50:11 +0900

마소 보다가 정확한 개념을 찾지 못해 검색하니 바로 나온 좋은 글

역시 인터넷이 좋아 ㅡㅜ

[출처]

Materialized View란 ?

Materialized View(이하 MView로 표시) 이것은 제목 그대로 View 입니다.

하지만 일반 View는 논리적인 테이블이고, MView는 물리적으로 존재하는 테이블 입니다. 물리적으로 존재한다는 것은 Data가 일정 공간을 차지하고 있다는 거죠..

MView는 어떤 결과를 뽑아 내는 쿼리가 너무나도 빈번히 사용 될 경우, Query 실행 시간의 수행속도 향상을위하여 , 여러 가지의 Aggregate View를 두어, 미리 비용이 많이 드는 조인이나, Aggregate Operation 을 처리하여야 하는 SQL을 위해, 데이터베이스의 한 테이블로 저장 하며, 그 테이블을 조회 하도록 하는 것 입니다.

간단하게 설명하면 대용량의 데이터를 SUM, MIN, MAX, AVG, COUNT(*)이런 명령어를 사용해 너무나도 자주 조회하는 Query를 수행속도를 향상을 위해서, Query의 결과 만큼의 새로운 테이블을 생성해 놓는 벙법 입니다.

자주사용되는 View의 결과를 디스크에 저장해서 Query 속도를 향상시키는 개념 입니다.

Materialized View의 특징

- MView를 만들어두면 QUERY의 수행속도를 증가 시킬 수 있습니다.

- SQL 응용프로그램에서 MView 사용시 DBA는 프로그램에 영향을 끼치지 않고 언제든지 생성 및 제거가 가능 합니다.

- MView는 실행의 결과 행과 뷰 정의 모두 저장이 되고, 실행 결과 행으로 만들어진 테이블은 일정 공간을 차지 합니다.

- MView관련 기초 테이블을 변경하면, MView로 생성된 Summary 테이블도 변경 됩니다.

Materialized View와 일반 View의 차이점

- 가장 큰 차이점은 MView의 결과값은 물리적으로 존재하는 것이고, 일반 View의 결과값은 물리적으로 존재하지 않습니다. 즉 SELECT * FROM USER_SEGMENTS 하면 MView는 나오지만 일반 View는 나오지 않습니다.

- MView는 MView를 생성할때의 Query로 물리적으로 이미 데이타가 생성되어 있기 때문에 조회 속도가 빠릅니다. 하지만 View는 단지 쿼리정보가 딕셔너리에 저장되어 있고 사용될때 그 SQL이 다시 실행되는 것이기 때문에 MView보다 느립니다. MView로 생성된 결과값이 일반 View로 조회하는 Data의 결과값 보다 훨씬 적은 Row를 조회하게 되죠.

MView 관련 파라미터

- OPTIMIZER_MODE : MView를 사용하기 위해서는 Cost-Based 옵티마이져 여야 하므로 ALL_ROWS, CHOOSE, 혹은 FIRST_ROWS 중의 어느 하나를 사용 합니다.

- QUERY_REWRITE_ENABLED : Query Rewrite 사용을 위해서는 TRUE로 설정하면 됩니다.

- QUERY_REWRITE_INTEGRITY : 오라클이 Query Rewrite의 정확성을 제어하는 파라미터로, "STALE_TOLERATED", "TRUSTED", "ENFORCED" 로 지정할 수 있습니다.

STALE_TOLERATED : 사용되어진 기초테이블과 Consistent 하지 않은 View를 이용한Query Rewrite를 허용 합니다

TRUSTED : Optimizer에서 MView의 데이터가 정확하다고 간주하고 질의 수행. Integrity 확인을 하지 않습니다.

ENFORCED : QUERY_REWRITE_INTEGRITY 의 기본값으로, 사용자가 Integrity Constraint를 확인하여야 합니다.

- COMPATIBLE : 사용할 수 있는 오라클 함수들의 Compatibility를 결정하는 값으로 8.1.0 또는 그 이상으로 설정 해야 합니다.

참고문헌

- Oracle Technical Note Materialized View 글 / 박경희
- Oracle Technical Bulletins No.12181 MATERIALIZED VIEW 활용방법
- Oracle 8i Tuning 정식 교재

- 작성자 : 김정식 (oramaster _at_ naver.com)
- 작성일 : 2005-03-12
- 강좌 URL : http://www.oracleclub.com/lecture/1857
- 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
- 오라클클럽의 모든 강좌는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에
따라 자유롭게 사용할 수 있습니다.

보충]
출처 : 마소 2011년 3월호
원본 테이블에 대한 대량의 DML이 발생하면 M-view에도 순차적으로 반영되어야 하기 때문에 성능저하 발생 가능

추가보충]
출처 : 과장님
대부분의 경우 전체 데이터를 다시 만들때 모두 delete 하고 다시 insert 함

ibm] 다섯 가지의 Ajax 우수 사례

농부건우 — Thu, 07 Apr 2011 01:59:07 +0900

원본] http://www.ibm.com/developerworks/kr/library/wa-aj-5best/index.html

linux] linux kernel 이 64비트 인지 확인

농부건우 — Thu, 24 Mar 2011 00:53:02 +0900

[원본]

getconf LONG_BIT

펌] Java classpath (UNIX와 Mac OS X) 관리하기 (한글)

농부건우 — Thu, 24 Mar 2011 00:48:15 +0900

http://www.ibm.com/developerworks/kr/library/j-classpath-unix/

classpath는 자바 런타임과 파일시스템간 연결이다. 인터프리터가 로딩할 .class 파일들을 검색할 장소를 정의한다. 기본 개념은, 파일시스템 계층이 자바 패키지 계층을 미러링 하고, classpath가 파일시스템에서 어떤 디렉토리가 자바 패키지 계층에 대한 루트의 역할을 할 것인지를 지정하는 것이다.

안타깝게도, 파일시스템은 복잡하고, 플랫폼에 상당히 의존하며, 자바 패키지와 완벽하게 들어맞지 않는다. 따라서, classpath는 신참 사용자와 숙련된 자바 프로그래머 모두에게서 가시와 같은 존재가 되었다. 자바 플랫폼에서도 환영을 받는 존재도 아니다. 지독하게도 솔루션이 나오지 않는 소소한 문제들을 해결하느라 많은 노력을 기울여야 한다.

Eclipse 같은 훌륭한 IDE는 classpath 관리의 어려움을 덜어주기는 하지만, 어디까지나 모든 것이 잘 작동하고 있을 경우에만 해당된다. (어떤 것은 늘 잘못되기 마련이다.) 결국, 모든 자바 프로그래머는 classpath를 완전히 이해해야 한다. 완벽한 통달만이 classpath에서 발생하는 가시 같은 문제들을 해결할 수 있다.

이 글에서, UNIX, Linux, Mac OS X 플랫폼에서 자바 classpath(관련 sourcepath 포함)에 대해 알아야 할 모든 것을 망라했다. 참고 기술자료에서는 Windows 플랫폼을 대상으로 설명했다. 이 글이 충실한 가이드가 될 것이며, 대부분의 classpath 문제들을 해결할 수 있을 것이다.

패키지 구조

classpath 마스터는 소스 코드부터 시작한다. 모든 클래스는 패키지에 속해 있고, 이 패키지는 표준 네이밍 규약을 따라야 한다. 간단히 정리하면 다음과 같다. 패키지 이름은 com.example 또는 edu.poly처럼, 두 개의 도치된(reversed) 도메인 이름으로 시작한다. 그 다음에는 패키지의 내용을 설명하는 한 개 이상의 단어가 나온다. 예를 들어, 도메인 네임 elharo.com이 있고, Fraction 클래스를 작성한다면, 다음과 같은 패키지 형태가 될 것이다.

com.elharo.math
com.elharo.numbers
com.elharo.math.algebra.fields

도치된 도메인 네임 다음에는, 한 단어로 된 서브패키지(subpackage) 이름만 사용한다. 단어를 생략하지 말고, 모든 단어를 정확하게 작성한다. 필요하다면, 스펠 체커를 사용한다. classpath 관련 문제들 대부분이 소스 코드에 한 단어를 사용하는 데서 기인하고, 파일시스템의 단어와 약간 다른 스펠링 또는 축약 때문에 발생한다. 가장 현명한 방법은 줄이지 않은 정확한 스펠링을 사용하는 것이다.

전체 패키지 이름은 소문자로 하며, 일반적으로 대문자를 사용하는 고유 명사와 두문자일 경우에도 소문자를 사용한다. 패키지 이름은 ASCII 문자들로 구성된다. 컴파일러는 Hebrew, Cyrillic, Greek, 기타 스크립트로 작성된 패키지 이름들을 허용하지만, 많은 파일 시스템들은 그렇지 않다. 이러한 패키지 이름들은 디렉토리 이름으로서의 이중 기능을 할 필요가 없다. 결국, 패키지(그리고 클래스) 이름들은 ASCII로 제한되어야 한다. (자바 패키지와 클래스 이름은 Unicode이지만, 많은 파일 시스템들은 아직 Unicode가 아니다. 다른 디폴트 인코딩으로 파일을 시스템으로 복사하면 컴파일러와 인터프리터가 올바른 클래스를 찾을 수 없도록 한다.)

폐기용(Throwaway) 코드

API를 테스트 하기 위해 하나의 클래스를 작성해서, 실행 후에 즉시 버릴 것이라면, 이것을 패키지에 둘 필요는 없다. 하지만, 한 번 이상 사용될 클래스는 패키지에 저장되어야 한다.

패키지 이름에 인색하게 굴지 말라. 장기적으로 볼 때 큰 재앙이 될 수 있다. 도메인 이름이 필요하면, 구매해도 좋다. 이름이 너무 길다면, 짧은 것을 구매하라. (나는 xom.nu를 샀기 때문에, 나의 패키지 접두사는 단 여섯 문자뿐이다.) 클래스를 디폴트 패키지(클래스에 패키지 문을 추가하지 않을 경우 얻게 되는 패키지)에 두지 말라. 패키지 액세스가 객체 통신을 금하면, 더 많은 퍼블릭 메소드를 클래스에 추가하라. 한 번 이상 사용하는 모든 클래스는 패키지에 있어야 한다.

디렉토리 구조

다음 단계는 소스 파일들을 구성하여 패키지 구조와 맞추는 것이다. 빈 디렉토리를 만들어라. 이 글에서는 그 이름을 project로 하겠다. 이 디렉토리 안에, 두 개의 디렉토리를 더 만든다. bin과 src이다. (어떤 사람들은 이것을 각각 build와 source로 하기도 한다.)

src 디렉토리 안에, 패키지 계층과 똑 같은 계층을 만든다. 예를 들어, com.elharo.math.Fraction이라는 클래스가 있다면, src 디렉토리에 com 디렉토리를 둔다. 그런 다음, com 디렉토리 안에 elharo 디렉토리를 만든다. 그리고 나서, elharo 디렉토리 안에 math 디렉토리를 둔다. 마지막으로, math 디렉토리 안에 Fraction.java를 넣는다. (그림 1)

그림 1. 디렉토리 구조는 패키지 구조를 따른다.

중요: src 디렉토리에 소스 코드 외 다른 것을 절대 넣지 말라. 그곳에 들어갈 유일한 파일은 .java 파일들이다. 가끔 이 디렉토리에 .html(Javadoc) 또는 다른 유형의 소스 코드를 넣는 경우도 있다. 하지만, .class 파일이나 다른 생성물들을 이 계층에 넣어서는 안된다. 큰 문제로 돌아올 것이다. javac 컴파일러의 경우 조심하지 않는다면 반드시 문제를 일으킨다. 다음 섹션에서 이러한 문제를 해결하는 방법을 설명하겠다.

위로

컴파일

자바 코드 컴파일은 다르지만 관련된 여러 가지 것들을 트래킹 해야 하기 때문에 손이 많이 간다.

컴파일 대상 파일
컴파일러가 대상 파일이 반입하는 .java 파일을 검색할 디렉토리
컴파일러가 대상 파일이 반입하는 .class 파일들을 검색할 디렉토리
컴파일러가 아웃풋을 둘 디렉토리

기본적으로, javac 컴파일러는 이 모든 것이 현재 실행 디렉토리라고 간주하는데, 대게는 우리가 원하는 것이 아니다. 결국, 컴파일 할 때 엘리먼트들을 명확하게 지정해야 한다.

컴파일 대상 파일

우선, 컴파일 하고자 하는 .java 파일을 지정해야 한다. 이것은 현재 실행 디렉토리에서 그 파일로 가는 경로로 주어진다. 예를 들어, 그림 1처럼, project 디렉토리를 생각해 보자. 이 디렉토리에는 src 디렉토리가 있다. src 디렉토리에는 com 디렉토리가 있고, com 디렉토리에는 예제 디렉토리가 포함되어 있다. 여기에는 Fraction.java 파일이 있다. 다음 명령행이 이것을 컴파일 한다.

$ javac src/com/elharo/math/Fraction.java

경로가 정확하지 않다면, 다음과 같은 에러 메시지를 받게 된다.

error: cannot read: src/com/example/mtah/Fraction.java

에러 메시지를 보면, 경로를 보면서 철자가 올바르게 쓰였는지를 확인한다. ls를 실행하여 파일이 있어야 할 곳에 있는지를 확인하라.

$ ls src/com/example/math
ls: src/com/example/math: No such file or directory

이 문제는 잘못 입력된 경로를 나타내지만, 여러분이 생각한 디렉토리에 있지 않다는 것도 의미한다. 이 예제에서, 현재 실행 디렉토리가 project 디렉토리인지를 확인했다. pwd 명령어가 이때 도움이 된다. 예를 들어, 다음 문장은 내가 실제로 project 디렉토리 대신 project/src에 있음을 알려준다.

$ pwd
/Users/elharo/documents/articles/classpath/project/src

컴파일 하기 전에 cd ..를 실행해야 한다.

아웃풋이 가야 할 곳

신택스 에러가 없을 경우, javac는 .java 파일이 있는 디렉토리에 컴파일 된 .class 파일을 배치한다. 이것은 우리가 원한 것이 아니다. .class와 .java 파일을 섞어 놓으면, 컴파일 된 파일들을 지우기가 매우 어렵다. 실수로 .java 파일들을 지울 수도 있다. 이는 깨끗한 구현도 문제거리로 만들며, 버저닝 문제도 일으킨다. 또한 바이너리를 배포할 때, 컴파일 된 .class 파일들만 압축하기도 힘들다. 따라서, 완전히 다른 디렉토리에 컴파일 된 결과를 두도록 컴파일러에 명령해야 한다. -d 스위치는 아웃풋 디렉토리(대게 bin, build, classes)를 지정한다.

$ javac -d bin src/com/elharo/math/Fraction.java

그림 2 같은 아웃풋이 생겼다. javac는 완성된 com/elharo/math 디렉토리 계층을 만들었다. 우리는 이것을 직접 수행할 필요가 없다.

그림 2. 병렬 소스와 컴파일 된 계층

sourcepath

자바가 소스 파일들을 검색할 디렉토리는 sourcepath이다. 여기에서는, src 디렉토리이다. 이 디렉토리에는, 자신들의 디렉토리로 구성된, 소스 파일의 계층이 포함되어 있다. com 디렉토리도 src/com/elharo/math 디렉토리도 아니다.

대부분의 프로젝트는 한 개 이상의 클래스와 한 개 이상의 패키지를 사용한다. 이것은 import 문과 전체 패키지 클래스 이름들로 연결된다. 예를 들어, com.elharo.gui에 새로운 MainFrame 클래스를 만든다고 해보자. (Listing 1)

Listing 1. 한 패키지의 클래스가 또 다른 패키지의 클래스를 반입할 수 있다.

				
package com.elharo.gui;

import com.elharo.math.*;

public class MainFrame {

  public static void main(String[] args) {
    Fraction f = new Fraction();
    // ...
  }

}

이 클래스는 MainFrame 클래스와는 다른 패키지에 있는 com.elharo.math.Fraction 클래스를 사용한다. 소스 설정은 그림 3과 같다. (이전 단계의 컴파일 된 아웃풋을 삭제했다. 언제든 다시 컴파일 할 수 있다.)

그림 3. 여러 패키지의 소스 구조

이제, 전에 했던 것처럼 MainFrame.java를 컴파일 할 때 어떤 일이 발생하는지 보자.

Listing 2. MainFrame.java 컴파일

				
$ javac -d bin src/com/elharo/gui/MainFrame.java
src/com/elharo/gui/MainFrame.java:3: package com.elharo.math does not exist
import com.elharo.math.*;
^
src/com/elharo/gui/MainFrame.java:7: cannot find symbol
symbol  : class Fraction
location: class com.elharo.gui.MainFrame
  private Fraction f = new Fraction();
          ^
src/com/elharo/gui/MainFrame.java:7: cannot find symbol
symbol  : class Fraction
location: class com.elharo.gui.MainFrame
  private Fraction f = new Fraction();
                           ^
3 errors

javac가 MainFrame.java를 어디에서 찾아야 할 지를 알지만, Fraction.java를 어디에서 찾아야 할지 모르기 때문에 Listing 2에 에러가 생겼다. (매칭 패키지 계층들을 인식하는 것으로도 충분히 똑똑하다고 생각하겠지만, 그렇지가 않다.) sourcepath를 지정해야 한다. 이것은 컴파일러가 소스 파일의 계층을 검색할 디렉토리를 지정한다. Listing 2에서, 이것은 src이다. 따라서, 나도 다음과 같이, -sourcepath 옵션을 사용한다.

$ javac -d bin -sourcepath src src/com/elharo/gui/MainFrame.java

이제 프로그램은 에러 없이 컴파일 하고, 그림 4와 같은 아웃풋을 만들어 낸다. javac 역시 내가 컴파일 했던 파일에 의해 참조된 Fraction.java 파일을 컴파일 했다.

그림 4. Multiclass 아웃풋

sourcepath에서 여러 디렉토리 컴파일 하기

sourcepath에 한 개 이상의 디렉토리가 생겼다. 필요한 것은 아니지만, 콜론으로 구분되어 있다. 예를 들어, 또 다른 프로젝트용 소스 코드를 관리할 로컬 src 디렉토리와 /Users/elharo/Projects/XOM/src 디렉토리를 추가하고 싶다면, 다음과 같이 컴파일 할 수 있다.

$ javac -d bin -sourcepath src:/Users/elharo/Projects/XOM/src
  src/com/elharo/gui/MainFrame.java

이 명령어는 그 계층에서 발견된 모든 파일들을 컴파일 하지 않는다. 컴파일 되도록 분명히 요청했던 하나의 .java 파일에 의해 직/간접적으로 참조된 파일만 컴파일 한다.

.java 파일용으로 하나의 소스 디렉토리가 있지만, 사전 컴파일 된 서드 파티 라이브러리가 배치된 클래스 또는 JAR 아카이브용 여러 디렉토리가 있다. 이것은 classpath의 역할이다.

classpath 설정하기

중대형 프로젝트에서, 매번 모든 파일들을 재 컴파일 한다는 것은 시간 낭비다. 다른 클래스나 bin 디렉토리에 같은 프로젝트의 독립된 부분들을 개별적으로 컴파일 및 저장함으로써 이러한 문제를 완화시킬 수 있다.

클래스를 classpath에 추가하는 여러 가지 방법이 있다. 하지만, 여러분은 -classpath 명령행 스위치만 사용해야 한다. 이전에 컴파일 했던 또 다른 프로젝트에서 파일을 /Users/elharo/classes 디렉토리로 반입하고 싶다면? -classpath /Users/elharo/classes를 다음과 같이 명령어에 추가한다.

$ javac -d bin -sourcepath src -classpath /Users/elharo/classes
  src/com/elharo/gui/MainFrame.java

두 개의 디렉토리, /Users/elharo/project1/classes와/Users/elharo/project2/classes를 추가한다고 해보자. 콜론으로 구분하여 다음과 같이 추가한다.

$ javac -d bin -sourcepath src
  -classpath /Users/elharo/project1/classes:/Users/elharo/project2/classes
  src/com/elharo/gui/MainFrame.java

상위 디렉토리

여기에서 참조하는 디렉토리들은 com/elharo/foo/bar 또는 nu/xom/util같은 계층을 포함하고 있는 상위 디렉토리이다. 이름이 패키지 이름(com, elharo, math 등)과 매치하는 디렉토리들은 sourcepath나 classpath에 직접 포함되어서는 안된다.

물론, 원한다면, 상대 경로라는 다양한 형태를 사용할 수 있다. project1과 project2가 현재 실행 디렉토리와 인접해 있다면(같은 부모 디렉토리를 갖고 있다면) 다음과 같이 한다.

$ javac -d bin -sourcepath src
  -classpath ../project1/classes:../project2/classes
  src/com/elharo/gui/MainFrame.java

지금까지, 프로그램이 완전하고, 개별적으로 컴파일 된 서드 파티 라이브러리를 사용하지 않는 경우를 가정했다. 만약 그렇다면, 이들을 classpath에도 추가해야 한다. 라이브러리는 junit.jar 또는 icu4j.jar 같은 JAR 파일로서 배포된다. 이 경우, classpath에 추가하는 것은, JAR 파일 그 자체이다. 이것을 포함하고 있는 디렉토리가 아니다. (본질적으로, JAR 파일은 컴파일 된 .class 파일들을 포함하고 있는 디렉토리로서 작동한다.) 예를 들어, 다음 명령어는 classpath에 세 가지를 추가한다. /Users/elharo/classes 디렉토리, 현재 실행 디렉토리에 있는 icu4j.jar 파일, /Users/elharo/lib에 있는 junit.jar 파일.

$ javac -d bin -sourcepath src
  -classpath /Users/elharo/classes:icu4j.jar:/Users/elharo/lib/junit.jar
  src/com/elharo/gui/MainFrame.java

JAR 파일들은 .java 파일과 sourcepath가 아닌, .class 파일과 classpath에만 사용된다.

위로

프로그램 실행하기

프로그램을 성공적으로 컴파일 했고, 이제 실행할 준비가 되었다. 컴파일과 비슷하지만 더 간단하다. 프로그램을 실행할 때, 다음 두 가지를 지정하면 된다.

The classpath.
main() 메소드를 포함하고 있는 클래스의 전체 이름

sourcepath를 지정할 필요가 없다.

일반적으로, classpath는 프로그램을 컴파일 하기 위해 사용했던 것과 같은 classpath이다. 컴파일 된 아웃풋이 배치되었던 디렉토리가 추가된다. 예를 들어, 컴파일 명령어가 다음과 같고,

$ javac -d bin -sourcepath src
  -classpath /Users/elharo/classes:/Users/elharo/lib/junit.jar
  src/com/elharo/gui/MainFrame.java

main() 메소드가 com.elharo.gui.MainFrame 클래스에 있었다면, 다음과 같이 프로그램을 실행한다.

$ java
   -classpath bin:/Users/elharo/classes:/Users/elharo/lib/junit.jar
    com.elharo.gui.MainFrame

명령행의 마지막 아이템은 클래스 이름이다. 파일 이름이 아니다. .java나 .class로 끝나지 않는다. 이 클래스는 classpath 어디에선가는 발견되어야 한다.

위로

다른 클래스들이 있는 곳

컴파일 할 때나, 실행할 때, 언제나 분명하게 classpath를 지정해야 한다. 파일을 둘 수 있는 다른 장소들이 있기 때문에, classpath에 추가되고, javac 컴파일러와 자바 인터프리터에 의해서 발견될 수 있다. 이 옵션들은 적은 양의 타이핑만 저장하고, classpath에 오래된 버전의 클래스를 둘 경우 디버깅에 많은 시간이 걸릴 것이다.

예기치 않게 classpath로 와서 문제를 일으키는 클래스 하이딩을 찾을 장소를 설명하겠다. 서버처럼, 우리들이 제어할 수 없는 머신이 될 것이다.

현재 실행 디렉토리

요청을 하든, 하지 않든 간에, 컴파일러는 현재 실행 디렉토리(.)를 classpath에 추가한다. 같은 디렉토리 안에 무엇이 있고, 없는지를 쉽게 잊는다. 따라서, 클래스나 계층들을 프로젝트나 홈 디렉토리에 두지 말라. 대신, .java 파일용 src 디렉토리와 bin 디렉토리에 명확하게 분리해서 저장해야 한다.

CLASSPATH

bin 디렉토리와 JAR 아카이브를 classpath에 직접 추가하는 것이 지겨워 질것이다. 이때 CLASSPATH 환경 변수를 찾는다. 디렉토리와 JAR 아카이브를 단 한번만 CLASSPATH 환경 변수에 추가할 수 있다. javac나 자바를 실행할 때마다 경로를 입력할 필요가 없다.

이와 같은 유혹과 싸워라. 잘못된 클래스나 잘못된 클래스 버전을 로딩할 때 문제를 일으킬 것이다. 저장할 때 마다, 잘못된 클래스를 로딩했기 때문에 생긴 문제들을 디버깅 할 때 수백 번 취소당할 것이다. classpath를 자동화하고 타이핑을 피할 수 있는 더 나은 방법이 있다.

jre/lib/ext

jre/lib/ext 디렉토리에 있는 JAR 아카이브는 가상 머신에서 실행되는 모든 애플리케이션의 classpath에 추가된다. 이것이 안전해 보이지만, 디렉토리들을 CLASSPATH 환경 변수에 추가하는 것과 비슷한 실수이다. 조만간, 생각하지도 않았던 장소에서 잘못된 클래스 버전을 로딩하고, 이것을 디버깅 하느라 귀중한 시간만 낭비하게 될 것이다.

이 문제는, 서버 측 애플리케이션을 전개할 때 특별히 위험하다. 전개할 서버에 jre/lib/ext 디렉토리에 추가 JAR 파일들이 없어야 한다. classpath에서 잘못된 버전의 JAR 아카이브로 생긴 문제들은, 증상을 인지하지 못하거나, 무엇을 찾아야 할지 모를 경우, 디버깅이 매우 어렵다. 이러한 문제들을 피하기 위해, 일부 프레임웍은 자바 코드의 일반 클래스 로딩 메커니즘을 우회하는 클래스 로더를 작성하기도 한다.

jre/lib/endorsed

jre/lib/endorsed에 있는 JAR 파일들은 가상 머신으로 실행되는 모든 애플리케이션의 classpath에도 추가된다. 차이점은, 이 파일들이 실제로 일반 classpath가 아닌 bootclasspath에 추가되고, 표준 클래스를 JDK로 대체할 수 있다. 이러한 방식은 XML 파서를 업그레이드 하고, VM에서 버그를 픽스할 때 유용하다.

이 기술은 간편해 보이지만, 이 역시 장기적으로 볼 때는 위험하다. JDK 클래스로 대체해야 한다면, 런타임 시 -Xbootclasspath/p옵션을 사용하여 잘못된 버전의 클래스를 로딩하는 것을 피한다.

$ java -classpath /Users/elharo/classes
       -Xbootclasspath/p:xercesImpl.jar com.elharo.gui.MainFrame

위로

classpath 관리 자동화하기

못총(nail gun)을 집어 들기 전에 망치를 사용하는 방법부터 배워야 한다. 마찬가지로, 보다 강력한 툴을 찾기 전에 클래스를 직접 관리하는 것에 익숙해져야 한다. 하지만, sourcepath와 classpath를 다루어야 하는 고통을 줄여주는 툴들이 있다. 대부분 이 툴들은 파일들을 라인 별로 정리한다.

IDE

Eclipse와 NetBeans 같은 통합 개발 환경은 classpath 관리의 일부를 자동화 한다. 예를 들어, 패키지 이름을 변경할 때, Eclipse는 상응하는 .java 파일을 매치하는 것으로 옮긴다. (그림 5)

그림 5. Eclipse에서 classpath

하지만 IDE는 다른 툴과 다른 IDE와 통합해야 한다면, 올바르게 설정되어야 하는 파일시스템 상에 여전히 있다. 이 툴의 주된 특징은 GUI 다이얼로그, 트리 뷰, 탭들이 명령행 스위치를 대체한다는 점이다. 하지만, 기본 파일 구조는 같다.

Ant

Ant는 빌드 프로세스를 자동화 하는 표준 툴이다. 디렉토리를 jre/lib/ext 또는 CLASSPATH 환경 변수에 두는 것과는 달리, Ant에서는 원스텝 빌드 프로세스를 만들 수 있다. 여전히, Ant build.xml 파일에 classpath를 설정하고, 올바른 디렉토리에 소스 파일들을 직접 저장해야 한다. 하지만, 컴파일 할 때마다 이것을 다시 지정할 필요는 없다.

Maven

Maven은 빌드 프로세스와 관련 classpath 문제들을 구성 및 자동화 한다는 점에서 Ant 보다 더 향상되었다. Maven은, 단 몇 줄의 코드로도 간단한 프로젝트를 구현할 수 있도록, 합리적인 디폴트 설정을 제공한다. Maven이 찾을 수 있는 곳에 소스 파일을 두면 된다. 여전히, 파일 시스템 계층과 패키지 계층을 조정해야 한다. Maven은 삼자 라이브러리에 대한 의존성 관리에 특별히 뛰어나다. Ant 만큼 커스터마이징은 쉽지 않다.

위로

맺음말

classpath는 문제가 많지만, 몇 가지 간단한 규칙을 사용하면 능히 다스릴 수 있다. 특히,

모든 클래스는 패키지에 둔다.
패키지와 클래스 네이밍 규약 및 대/소문자 규약을 엄격하게 지킨다.
패키지 계층과 디렉토리 계층이 맞는지를 확인한다.
javac에는 언제나 -d 옵션을 사용한다.
jre/lib/ext에 어떤 것도 두지 않는다.
jre/lib/endorsed에 어떤 것도 두지 않는다.
.class 파일과 같은 디렉토리에 .java 파일을 두지 않는다.
현재 실행 디렉토리에 .java나 .class 파일들을 두지 않는다.

마지막 팁: classpath와 관련한 많은 문제들은 디렉토리 이름을 잘못 입력했다거나, 잘못된 디렉토리에서 컴파일 하는 등 간단한 에러에서 진화한다. 무엇이 잘못되었는지 알 수 없다면, 동료나 친구에게 물어보고 문제를 찾아야 한다. 오히려 문제에 너무 집착하여, 다른 사람들 눈에는 명확하게 보이는 버그를 못 볼 수도 있다. 두 눈은 매우 효과적인 디버깅 방법이다.

classpath는 분명 쉬운 것은 아니다. 하지만, 관리도 가능하다. 네이밍 규약, 명령행 인자, 디렉토리 구조에 신경을 쓴다면, 실수를 최소한으로 줄이고 프로그램을 컴파일 및 실행할 수 있을 것이다.

기사의 원문보기

Managing the Java classpath (UNIX and Mac OS X)

참고자료

교육

"Managing the Java classpath on Windows" (Elliotte Harold, developerWorks, December 2006)
"Project management: Maven makes it easy" (Charles Chan, developerWorks, April 2003)
"IBM Cloudscape: Understanding the Java classpath" (Jean Anderson and Susan Cline, developerWorks, September 2004)
"Best Practice: Classpath structure for WebSphere Application Server" (WebSphere Best Practices team, developerWorks, August 2001)
developerWorks technical library for Java

제품 및 기술 얻기

토론

오픈 소스 프로젝트 참여를 통한 개발자 커리어 관리

농부건우 — Sun, 20 Mar 2011 21:29:48 +0900

오픈 소스 프로젝트 참여를 통한 개발자 커리어 관리

View more presentations from trustinlee.

웹 개발자를 위한 대규모 서비스를 지탱하는 기술

농부건우 — Sat, 19 Mar 2011 01:01:47 +0900

영풍문고에 갔다가 구입한 책.
꼭 se가 아니지만 웹 개발자라면 읽어보면 도움이 될 것 같음.
내용도 어렵지 않고 재미있음 @_@