trypsr님의 노트

Head First Design Patterns

Tue, 04 Nov 2008 22:30:32 +0900

본 내용은 한빛미디어의 Head First Design Patterns : 스토리가 있는 패턴 학습법 을 읽고 나름대로 정리한 내용입니다.

디자인 원칙
- 어플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.
- 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
- 상속보다는 구현을 활용한다.
스트래티지 패턴(Strategy pattern) : 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용

옵저버 패턴(Observer pattern) :

Decorator pattern
Factory pattern
Singletom pattern

Spring 프레임워크 워크북

Thu, 30 Oct 2008 23:50:34 +0900

본 내용은 한빛미디어의 Spring 프레임워크 워크북 을 읽고 나름대로 정리한 내용입니다.

2. Spring IoC

Mon, 27 Oct 2008 22:45:03 +0900

2. Spring IoC

IoC (Inversion of Control) : 역제어
- 제어권의 역전이란 객체의 생성에서 부터 생명주기의 관리까지 객체에 대한 모든 제어권이 바뀌었다는 것
- 객체에 대한 생성 및 생명주기에 대한 제어권을 컨테이너가 가지게 되었다는 말
- Spring 컨테이너 : POJO 를 관리하는 컨테이너
IoC 컨테이너의 분류체계
- DL (Dependency Lookup)
- DI (Dependency Injection)
  - Setter Injection
  - Constructor Injection
  - Method Injection
DL (Dependency Lookup)
- 저장소에 저장되어 있는 빈(Bean)에 접근하기 위하여 개발자들이 컨테이너에서 제공하는 API 를 이용하여 사용하고자 하는 빈(Bean) 을 Lookup 하는 것
DI (Dependency Injection)
- 각 계층 사이, 각 클래스 사이에 필요로 하는 의존관계가 있을때, 이 의존관계를 컨테이너가 자동적으로 연결시켜 주는 것
- 각 클래스 사이의 의존관계를 빈 설정(Bean Definition) 정보를 바탕으로 컨테이너가 자동적으로 연결해 주는 것
- DL 사용시 컨테이너 종속성 증가, 이를 줄이기 위해 DI 사용
- Spring 프레임워크에서 DI 방법으로 Setter Injection, Constructor Injection, Method Injection 지원
  - Setter Injection : setter 메소드를 이용하여 클래스 사이의 의존관계를 연결
    - Spring 프레임워크의 빈 설정 파일에서 property 사용
  - Constructor Injection : 생성자를 이용하여 클래스 사이의 의존관계를 연결
    - Spring 프레임워크의 빈 설정 파일에서 constructor-arg 사용
  - Method Injection
    - Singleton 인스턴스와 Non Singleton 인스턴스의 의존관계를 연결시킬 필요가 있을 때 사용
    - 그러나 많이 사용하지 않음. 위의 경우 다른 방법으로 대체 가능.
Spring 프레임워크는 J2EE API 중에서 사용하기 어려운 API 들을 추상화하여 사용하기 쉽도록 많은 추상 API 들을 지원
- org.springframework.mail.javamail.JavaMailSendImpl 클래스 등등 (Java Mail 참조 URL)
BeanFactory 와 ApplicationContext
- BeanFactory : 빈 설정 파일에 정의되어 있는 정보를 바탕으로 기본적인 빈의 생성, 초기화, 빈에 대한 접근과 같은 기능 지원
- ApplicationContext : BeanFactory 의 하위 인터페이스, BeanFactory 의 기능 외에 추가적인 기능 지원
  - MessageSource 지원, 어플리케이션에서 필요한 메시지들을 관리
  - ApplicationContext 를 사용하여 이벤트 기능 구현 가능 (ApplicationListener 를 구현하여 설정파일에 등록할 경우)
  - 파일, URL 과 같은 다양한 하위 레벨의 자원을 Spring 프레임워크의 Resource 인스턴스로 생성 가능
  - 실제로 웹 어플리케이션에서는 BeanFactory 와 ApplicationContext 의 API 를 직접 전근하는 경우가 거의 없음.
  단, 테스트 프로그램을 작성할 때는 직접 접근하는 방법을 알아두는 것이 유용
Spring 프레임워크의 초기화 및 빈의 생명주기
- 빈 설정 파일 정보 초기화
  - 디폴트 생성자 Invoke
- POJO 빈 초기화 상태
  - 의존관계의 빈 존재 여부 체크 -> 존재하지 않으면 초기화 실패
  - setter 메소드(or 생성자의 인자로 실질적인 값 추가 or 다른 빈에 대한 레퍼런스 전달 등)의 작업
  - setBeanNames(), setBeanFactory(), setApplicationContext() 메소드 호출
  - 생성한 빈이 InitailizingBean 인스턴스이면 afterPropeties() 메소드 호출
  - 빈 설정 파일의 init-method 호출
- POJO 빈 준비 상태 (빈에 대한 초기화가 완료되고 서비스 가능한 준비상태)
- POJO 빈 소멸 상태
  - 생성한 빈이 DisposableBean 인스턴스이면 destory() 메소드 호출
  - 빈 설정 파일의 destory-method 호출
초기화 과정
- Spring 프레임워크가 지원하는 인터페이스를 상속하여 초기화를 지원하는 방법
  - InitializingBean 을 상속하여 afterPropertiesSet() 메소드를 구현함으로써 빈의 초기화를 지원
- 개발자들이 원하는 특정 메소드를 초기화를 위한 메소드로 빈 설정 파일에서 추가하는 방법
  - 특정 메소드를 빈 설정파일에 init-method 로 지정
소멸화 과정
- Spring 프레임워크가 지원하는 인터페이스를 상속하여 소멸화를 지원하는 방법
  - DisposableBean 을 상속하여 destory() 메소드를 구현함으로써 빈의 소멸화를 지원
- 개발자들이 원하는 특정 메소드를 소멸화화를 위한 메소드로 빈 설정 파일에서 추가하는 방법
  - 특정 메소드를 빈 설정파일에 destory-method 로 지정
Singleton 빈과 Non Singleton 빈의 관리 방식
- Spring 프레임워크 기반 하에서 관리되는 POJO 빈은 디폴트로 Singleton 방식으로 관리
  - 단 하나의 인스턴스가 존재, 한 번 생성된 인스턴스는 재생성 없이 재사용
- Non Singleton 방식으로 인스턴스를 생성하려면 빈 설정파일에서 빈 정의시 singleton 속성을 false 로 설정
- Singleton 인스턴스로 관리 해야 할 경우
  - 생성되는 인스턴스 내에 공유되는 상태가 없는 경우
  - 생성되는 인스턴스 내에 read-only 상태만 있는 경우
  - 생성되는 인스턴스 내에 공유되는 상태가 있더라도 상태를 변경할 때 동기화를 보장할 수 있는 경우
- Non Singleton 인스턴스로 관리 해야 할 경우
  - 인스턴스에 변경 가능한 상태가 많아 동기화 비용이 많이 들 경우
  - 객체들 간의 동작을 분리시키기 위하여 private 상태의 변경 가능한 상태가 존재하는 경우
MessageSource 이용하기
- ApplicationContextAware 인터페이스 구현하여 이용하는 방법
- MessageSourceAccessor 클래스 사용하여 이용하는 방법

web2.0

Sun, 26 Oct 2008 23:04:54 +0900

simple 의 미학
- me2day
- playtalk
- twitter
- springnote
롱테일

Ruby

Sun, 26 Oct 2008 23:04:23 +0900

다시 보는 ‘루비 온 레일즈 굴려보기’

다시 보는 ‘루비 온 레일즈 굴려보기’ - Part 2

루비 온 레일즈, 이클립스를 만나다(1)

iBATIS in Action

Sun, 26 Oct 2008 23:03:55 +0900

본 내용은 위키북스의 iBATIS in Action 을 읽고 나름대로 정리한 내용입니다.

iBATIS 의 사용 이유
- 간단함
- 생산성
- 성능
- 관심사의 분리
- 작업의 분배
- 이식성
- 오픈 소스와 정직성
iBATIS 를 사용하지 않는 경우
- 개발자가 모든 것에 대해 영원한 결정권을 갖고 있을 경우
  : 완전한 객체 관계 매핑 솔루션(Hibernate 와 같은) 을 쓰는게 낫다.
- application 이 완전히 동적인 SQL 을 요구할 때
  : JDBC 또는 자신만의 프레임워크를 만들어서 사용하는 게 낫다.
- 관계형 데이터베이스를 사용하지 않을 때
  : 순수한 JDBC나 저수준 파일 입출력 API 를 사용하게 낫다.
- 간단히 작동하지 않을 때
  : 복잡한 요구사항으로 iBATIS 자체를 수정해야 하는 경우가 있다면 차라리 다른 해결책을 찾아보는게 좋다.

웹표준 준수

Sun, 26 Oct 2008 23:03:11 +0900

유용한 사이트 및 extention

작업기준 브라우저
- FF 에 맞춰 작업하고 사파리, 오페라에서 테스트, 뒤에 IE 에서 수정하는 것이 시간, 비용이 절약

알아야 할 새로운 HTML 태그 : div, span 태그
- div : 단락이나 제목처럼 별도의 불할된 내용 구간을 의미한다. 너무 남용을 하지 않는것이 좋다.
- span : 인라인 엘리먼트에 사용

잊어야 할 HTML 태그 : font, b, i, 외형만을 보강해주는 attribute
- b 대신 strong, i 대신 em
- background, bgcolor, text, link, alink, vlink 처럼 외형만을 보강해주는 attribute

br 태그의 오용 : p, ul 또는 li를 사용하여 단락에 의미 부여가 되도록 사용하여야 함
h1 태그는 단 한번만 사용. 페이지의 핵심 주제를 표시
h1 다음으로 순차적으로 h2, h3 순으로 사용
텍스트 단락에는 p 태그를 사용
네비게이션 링크, 제목, 팁모음 등 몇개의 관련 항목의 목록을 만들때는 비순차 목록(ul) 태그를 사용한다.
인기순과 같이 순서가 있을 때는 순차목록(ol) 태그를 사용한다.
용어 및 용어들의 정의나 설명을 담은 용어집을 만들려면, dl(정의목록), dt(정의용어), dd(정의설명)태그를 사용
인용구 blockquote 태그, 짧은 글 q 태그
책 제목, 신문기사, 웹 사이트 등을 넣을때는 cite 태그, 연락처 정보는 address 태그
유효성 검사기로 작성 중 계속해서 유효성 검사
반드시 문서 유형 정의로 시작 (DOCTYPE 선언)
tag 및 attribute는 소문자
attribute 는 반드시 따옴표
태그는 반드시 닫아줘야 함
CSS 에서 사용하는 선택자(selector)
- tag 선택자
- class 선택자
  - class 선택자는 . 로 시작
  - class 명에는 문자, 숫자, 하이픈(-), 밑줄(_) 만을 사용
  - 대소문자 구분
- id 선택자
  - id 선택자는 # 으로 시작
- 하위 선택자
  - h1 string { ... }
- 그룹 선택자
  - h1, h2, table { ... }
- 전체 선택자
  - *
- 가상 클래스 및 가상 앨리먼트
- 자식 선택자
- 인접 동기 선택자
- 애트리뷰트 선택자
id 와 class 어떻게 사용
- 페이지에 여러번 나오는 경우 - class
- 페이지에 한번 나오는 경우 - id
- 브라우저는 id 에 우선권
스타일의 단계적 적용 원리
- 충돌하는 경우
  - 동일한 프로퍼티가 여러 조상으로 부터 계승되는 경우
  - 동일한 엘리먼트에 하나 이상의 스타일에 적용되는 경우
- 상속 스타일의 누적
- 가장 인접한 피상속자가 우선
- 직접 적용된 스타일이 우선
css import 사용 : 보통 최신 브라우저에서 인식되는 css 들을 모아서~

Spring

Sun, 26 Oct 2008 23:00:11 +0900

개발TIP

Mon, 20 Oct 2008 23:15:20 +0900

BaseObject 클래스(BaseObject.java)를 생성하여 모든 도메인 모델 클래스가 상속하도록 하면
toString(), equals(), hashCode() 를 따로 구현해야하는 수고를 덜 수 있다. (출처 : Spring 프레임워크 워크북)
Exception 처리 전략 (출처 : Spring 프레임워크 워크북)
- Checked Exception : java.lang.Exception 을 상속한 Exception 으로 컴파일 시점에 try ~ catch 구문으로 처리하지 않을 경우 에러 발생
- Unchecked Exception : java.lang.RuntimeException 을 상속한 Exception
- 비즈니스 로직을 수행하는 중 발생하는 비즈니스적인 Exception 을 제외하고는 모든 Exception 을 Unchecked Exception 으로 처리
- Checked Exception 중 사용자가 인지해야 하는 Exception 은 사용자들에게 해당 메시지를 출력. 그렇치 않은 경우에는 시스템 관리자에게 메일을 전송
- Unchecked Exception 이 발생하는 경우 Exception 내용을 시스템 관리자에게 메일로 전송
- 데이터베이스 다운과 같이 프로그램적으로 해결하기 힘든 에러가 발생하는 경우에는 Unchecked Exception 을 사용
Logging 처리 전략 (출처 : Spring 프레임워크 워크북)
- 비즈니스 클래스와 DAO 클래스는 메소드의 시작과 끝에 logging 메시지를 추가한다. 메소드 이름 시작, 메소드 이름 끝
- Unchecked Exception 이 발생할 경우에는 print stack trace
- logging 메시지 유형에 따라 DEBUG, INFO, WARN, ERROR 로 나누어서 저장
- logging 시에는 현재 logging 레벨을 체크하는 구문을 추가한다. 예) if(logger.isDebugEnalbed){ ....}
메시지 처리 전략 (출처 : Spring 프레임워크 워크북)
- 모든 메시지들은 별도의 properties 파일로 관리
- 메시지 파일은 언어별로 구분하여 구현

1. Spring 탄생 배경

Mon, 20 Oct 2008 22:47:17 +0900

1. Spring 탄생 배경

Spring 프레임워크 = Lightweight 컨테이너의 선두주자
Non EJB 아키텍처
- 장점
  - 초기 개발 속도 빠름, 단기적으로 가시적인 성과
  - 서블릿 컨테이너만으로 운영 가능 (비싼 EJB 컨테이너의 불필요, EJB 컨테이너보다 이식성이 좋음)
  - 추가적인 교육 없이도 쉽게 이해, 개발 가능
  - 개발 생산성의 향상 (개발주기가 EJB 보다 짧다)
- 단점
  - 후반부로 갈수록 개발 속도 지연 (추가 요청사항, 변경사항 발생시 대응 속도 느림)
  - 명확한 계층 분리의 어려움 (중복되는 코드의 발생 확률이 높아지므로 유지보수가 어렵다.)
  - 사내의 일관된 개발 방식을 갖기 어려움 (유지보수의 어려움)
  - 분산 환경을 지원할 수 없음.
  - 비즈니스 객체의 생명주기를 프로그램에서 직접 관리
  - 프로그램에서 트랜잭션 처리를 직접 작성 (EJB 가 지원하고 있는 선언적인 Transaction 같은 기능 없음)
EJB 아키텍처
- 장점
  - 정형화된 비즈니스 계층 제공 (논리적인 분리 뿐만 아니라 물리적인 분리)
  - 선언적인 트랜잭션 관리 기능 제공
  - 다양한 클라이언트에 대한 지원 (웹 UI 계층 뿐만 아니라 Swing 같은 GUI 클라이언트도 지원)
  - 분산 기능 지원 (뿐만 아니라 비즈니스 객체를 여러 서버에 분산도 가능)
- 단점
  - 실행 속도의 저하 (가장 큰 문제, 분산 환경을 지원하기 위해 객체를 직렬화하여아 하므로)
  - 개발 생산성 저하 (수정, 빌드, 배포, 테스트와 같은 복잡한 과정을 거쳐야 함)
  - 테스트의 어려움 (EJB 컨테이너에 배포 후 테스트를 해야 하므로) 으로 인해 제품의 Quality 떨어질 수 있다.
  - EJB 컨테이너 사이의 이식성이 떨어짐 (속도 실행 저하를 해결하기 위한 EJB 컨테이너 벤더들의 작업으로 인하여)
Lightweight 컨테이너 아키텍처
- 프레임워크 내부에 컨테이너 개념을 가지고 있는 프레임워크
  - 컨테이너 기능을 가진다는 것 : 트랜잭션 처리, Security, 빈의 생명주기 관리와 같은 컨테이너를 통해서 지원할 수 있는 기능들을 지원한는 것
- Non EJB 아키텍처와 다른 부분은 각 계층별 인터페이스를 담당하는 POJO 빈들을 유기적으로 관리해 주는 컨테이너를 가지고 있다는 것
- 장점
  - EJB에 비해 배우기 쉬우며, 빈을 설정하는 방법도 쉽다.
  - 서블릿 컨테이너에서 실행하는 것이 가능하므로 이식성이 뛰어나다.
  - 특정 인터페이스에 종속되지 않은 POJO를 기반으로 하기 때문에 테스트가 용이.
  - AOP의 지원으로 EJB 컨테이너에서 지원 가능했던 컨테이너 기능들을 지원하는 것이 가능
  - OOP(Object Oriented Programming) 형태로 개발하는 데 제약사항이 없다.
- 단점
  - 분산환경을 지원하지 못한다. (요즘엔 웹 서비스로 충북히 극복 가능)
  - Lightweight 컨테이너에 대한 표준 없음.
  - Lightweight 컨테이네 아키텍처를 새로 배워야 한다는 부담

JavaScript

Wed, 08 Oct 2008 11:42:22 +0900

jQuery