I can do it!

의존성 주입에 관하여..

Sat, 18 Jul 2009 13:06:19 +0900

우리가 객체와 객체의 관계를 설계할때 고려할 사항이 몇가지 있습니다만, 그중 하나가 재사용성입니다.
객체지향을 이루는 원리 중 하나가 재사용성이라고는 강의중에 말씀드린바 있습니다. 재사용성을 높이기 위해 사용하는 방법 중 하나가 인터페이스를 추출해 내는 것입니다.
인터페이스를 추출하고, 이를 상속받는 오브젝트를 구현함으로서, 추후 동일한 클래스를 사용하는 클래스, 즉 클라이언트 클래스의 로직을 수정하지 않도록 하는 것이지요.
예를 들어 보겠습니다.
우리는 비디오대여점에서 고객의 주소정보를 바꾸고 싶다고 하겠습니다. 먼저 비디오 대여점의 코드는 다음과 같습니다.

public class MovieRenter {
        private PersonCustomer customer = new PersonCustomer();
        ...
        public void changeCustomerAddress(String newAddress) {
                // 고객의 주소 정보를 바꾼다.
                customer.changeAddress(newAddress);
        }
        ...
}

PersonCustomer 라는 클래스가 있습니다. 이 클래스는 고객중에 개인 고객 정보를 담는 클래스로서, 주소를 바꿀 수 있는 메소드를 제공하죠. 소스는 다음과 같습니다.

public class PersonCustomer {
        ...
        public void changeAddress(String address) {
                // 주소를 바꾼다.
        }
        ...
}

여기서 만일 또 다른 고객 유형이 추가 된다고 생각해 보세요.(실제로 고객 유형은 상당히 많죠)
새로운 고객 유형이 추가 된다면, 우리는 MovieRenter 소스를 수정해야 합니다. 즉, MovieRenter 클래스는 재사용할 수 없는 클래스가 되어 버리고 말죠.
이를 위해서 고객 클래스들을 Customer 라는 인터페이스를 상속받도록 하겠습니다. 코드는 아래와 같습니다.

public interface Customer {
        ...
        public void changeCustomerAddress(String newAddress);
        ...
}

그리고 PersonCustomer는 위의 인터페이스를 상속받죠. 코드는 다음과 같습니다.

public class PersonCustomer implements Customer {
        ...
        public void changeAddress(String address) {
                // 주소를 바꾼다.
        }
}

자. 다시 MovieRenter 클래스 코드를 보겠습니다. 고객 객체를 생성하는 부분을 잘 확인하세요.

public class MovieRenter {
        private Customer customer = new PersonCustomer();
        ...
        public void changeCustomerAddress(String newAddress) {
                // 고객의 주소 정보를 바꾼다.
                customer.changeAddress(newAddress);
        }
        ...
}

고객을 생성하는 코드 확인하셨나요? new PersonCustomer();를 호출하게 되어 있습니다. 자, 이것이 문제 입니다.
우리는 소스를 수정하기 않기 위해 Customer 인터페이스를 이용하고자 하였습니다. 하지만, 코드상에서는 객체를 생성하기 위해서 PersonCustomer를 사용하게 됩니다.
결국 인터페이스를 사용하였어도 구현 클래스에 의존할 수 밖에 없어 지는 것입니다..

의존성 주입은 위와 같은 의존 상황을 회피하기 위한 방법입니다.
MovieRenter클래스에서 PersonCustomer클래스를 참조하지 않기 위해 즉, 의존하지 않기 위해, 스프링 프레임웍 같은 컨테이너에서 customer 오브젝트에 객체를 생성해 주는 것입니다. 이를 주입(injection)이라 합니다.
실제로 의존성 주입을 사용한 코드는 다음과 같습니다.

public class MovieRenter {
        private Customer customer;
        public void setCustomer(Customer newCustomer){
                this.customer = newCustomer;
        }
        ...
        public void changeCustomerAddress(String newAddress) {

                // 고객의 주소 정보를 바꾼다.

                customer.changeAddress(newAddress);
        }
        ...
}

코드상에서 PersonCustomer가 사라진 것을 확인하실 수 있습니다.
위와 같이 우리는 의존성 주입을 이용하여 불필요한 의존성(PersonCustomer참조)을 제거 할 수 있습니다.

정리하겠습니다. 의존성 주입은 객체에 필요한 타 객체의 생성을 책임지는 방법입니다.(객체 생성 방법중 하나로 보셔도 좋습니다.) 다시 말하면, 프레임웍에서 주입할 객체(PersonCustomer)를 생성하여 필요한 객체(MovieRenter)에 의존성을 주는 것입니다.

UI Mockup Tool - Balsamiq

Fri, 03 Jul 2009 14:44:32 +0900

고객에게 요구사항을 털어내게 하는 방법중 가장 좋은 방법은 대화이다. 대화를 하면서 모르거나 궁금한 것을 물어보고, 그에 대한 답변을 해주는 방식이 가장 일반적인 것이라 할 수 있겠다. 하지만, 우리는 무엇이 궁금한지 모르고 고객은 무엇을 답변해야 하는지 모른다. 무언가를 만들어 보여주어야 할 우리가 궁금한 것을 모른다는 것은 어쩌면 황당한 상황일런지는 모르지만, 현실이 그렇다. 그래서 우리는 최대한 궁금한 것을 짜 내어 프로토타입핑 작업을 하고, 이를 매개체로 하여 고객과 대화 한다.
빠른 프로토타이핑이라는 것은 빠른 요구사항 도출에 필수적이다. 일정한 시간내에서 빠른 요구사항 도출은 프로젝트를 성공으로 이끄는 데 상당한 역할을 한다. 빠른 프로토타이핑을 위해 깔끔하고 사용하기 편한 UI 목업 툴을 하나 소개하고자 한다.이미 상당수의 사람들이 사용하고, 사랑하고 있는 Balsamiq 이다.

부차적인 설명은 필요 없을 듯 하다. 아래의 동영상을 보자.

전부터 눈 여겨 보고 있던 툴인데, 이번 프로젝트에 적용해보게 되었다.

오브젝트와 오브젝트 타입, 그리고 클래스

Mon, 15 Jun 2009 10:43:10 +0900

회사내에서 한 사원이 가지고 있는 OO 기본 책을 보면서 다시금 Object(이하 오브젝트)와 Class(이하 클래스)의 차이점에 대해 생각해 보았다. 학부때 배웠던 이야기 이지만, 다시 잊지 않기 위해 정리해 본다.

잘못된 개념의 시작

Java의 유행이 시작되던 2000년대 초반, 우리는 클래스와 오브젝트의 개념을 붕어빵과 빵틀이라는 잘못된 예로 배워왔다. 빵틀에서 재료를 넣고 쿵 찍어내면 붕어빵이 나오듯 클래스를 이용해 오브젝트를 만들어 낸다고 배워왔던 것이다. 이것은 Java(OOP)에서 클래스를 설명하기 위해 가장 쉬운 방법이자 잘못된 개념을 습득하기 가장 쉬운 방법이었다.

오브젝트 타입

오브젝트와 클래스 관계는 사실 오브젝트 타입이라는 우리가 간과하는 개념이 숨어 있는데, 오브젝트와 클래스를 설명하기 위해선 것을 놓치지 말아야 한다. 보통 그냥 타입이라고도 일컬어 지는 오브젝트 타입은 무엇일까?

오브젝트는 정보를 가진 Attribute(이하 속성)과 정보를 가지고 행동을 할 수 있는 Behavior(이하 행동)을 가진다. 하나의 객체가 생성되는 이유는 하나의 목적을 취하기 위함이다. 어떤 사람이 집에서 중간 경유지를 들러 목적지에 도착하는 것과 같다. 사람이 목적지로 가기 위해 선택할 수 있는 몇가지 방법들이 있는데 이것이 타입이다. 즉, 하나의 목적을 가진 오브젝트들의 행동패턴들의 집합을 오브젝트 타입이라고 한다.

클래스

그럼 클래스는 무엇일까? 앞에서 이야기한 오브젝트 타입과는 무엇이 다른까? 클래스는 사전적 의미로 공통 성질을 가진 종류라고 정의한다. 타입은 어떠한 형태를 의미한다. 타입이 클래스 보다 엄격한 의미를 지닌다. 결론적으로(개인적인 의견이다), 클래스라는 용어를 사용하며 우리는 보다 유연하게 또는 느슨하게 사용할 수 있다.

즉, 우리가 프로그래밍을 할 때 머릿속의 개념은 오브젝트 타입이 될 것이고, 이것으로 그대로 구현한 것은 클래스이다. 다시말해서 설계는 오브젝트 타입으로 하고, 구현은 클래스로 한다. 그리고, 시스템은 클래스를 인스턴스화 한다. 그럼 인스턴스는? 인스턴스의 사전적 의미는 보기, 사례이다. 클래스에 담겨 있는 어떠한 성질의 사례라는 의미로 이해하면 되겠다.

정리

오브젝트, 오브젝트 타입, 클래스, 인스턴스에 대하여 알아보았다. 정리하자면, 머릿속에 떠다니는 개념상의 용어로 오브젝트와 오브젝트 타입이 쓰이고, 이것들의 구현체가 클래스와 인스턴스 라고 생각하면 되겠다.

어찌보면 작은 용어의 차이지만, 알고 사용하는 것과 모르고 사용하는 것의 차이는 크다. 또, 잘못된 용어의 선택은 큰 재앙을 가져오는 경우가 많기 때문이다.

JPQL에서 (bulk) Update, Delete 사용하기

Wed, 21 Jan 2009 16:29:38 +0900

JPA에서 데이터를 수정, 삭제하는 방법은 크게 두가지로 나뉠수 있다. 첫째로 JPA에서 제공하는 EntityManager를 사용하는 방법. 그리고, JPQL에서 UPDATE, DELETE를 실행하는 방법. 여기서 이야기 하고자 하는 것은 JPQL에서 UPDATE, DELETE 하는 방법이다. (bulk update / delete 라고 한다.)

JPQL을 이용하여 데이터를 DELETE 하는 방법은 쉽다. 아래 소스를 참고하자.

@PersistenceContext em;

. . .

// start transaction

Query query = em.createQuery("DELETE USER u WHERE u.status = :status ");

query.setParameter("status", 'GOLD');

int results = query.executeUpdate();

//end transaction

UPDATE 하는 방법 또한 동일하다. 고로 UPDATE 예제는 생략하도록 하겠다.

이제 하고자 하는 이야기를 하자. 위의 예제는 의도하여 삽입하였다. 무슨 이야기? 예제에서 트랜젝션의 시작과 끝을 알리는 주석에 주목해보자. 타 작업(task)이 포함되어 있지 않고, 하나의 트랜젝션으로 묶여 있다. 왜 그럴까? 누가 그랬을까?

만일, 위의 예제를 실행하고 나서 다른 작업을 시도한다면, 의도한 데이터 저장/수정, 삭제 작업은 이루어지지 않을 것이다. 왜?

JPA는 EntityManager가 엔티티Entity의 영속성(Persistance)를 관리하고 있다. 엔티티는 많은 관계들로 연결되어 있고, 이 관계들도 EntityManager가 관리하고 있다. Vender에서 사용하는 것처럼 JPA에서 Update, Delete문을 사용하게 된다면, EntityManager는 할일이 엄청나게 많아 질 것이다. 그럼 EntityManager를 관할하는 WAS도 우리에게 불만을 내뿜게 될게 뻔하지 않은가? 고로, JPA는 (bulk) Update, Delete를 실행했을 경우, EntityManager는 사용한 엔티티들을 Detached 상태로 되돌려 놓고, 트랜젝션이 종료되기를 기다리도록 하였다. 그러므로, 의도한 데이터작업은 실행할 수 없는 것이다.

요약하자면, bulk UPDATE, DELETE 를 사용했을 시엔 테잎 갈고 하자.

참조 : EJB3 In Action, Debu Panda, Reza Rahman, Derek Lane, Manning, 2007

StringBuffer 와 StringBuilder의 차이 (in Java 1.5 이상)

Sun, 28 Dec 2008 17:21:30 +0900

자바에서 문자열을 사용할때 도움을 주는 연산자 들은 많다. 하지만 흔히 권하는 방법은 String과 StringBuffer 그리고 StringBuilder 클래스들이다. 사용할 땐 다음을 고려해주면 된다.

String은 한번 선언하면 변하지 않기 때문에, 사용하려는 문자열이 변하지 않을때 사용하도록 한다.
StringBuffer는 동기화방식으로 저장되기 때문에, 멀티 쓰레드(multi Thread) 환경하에서 문자열 변경시에 사용하도록 한다.
StringBuilder는 비동기화방식으로 저장되기 때문에, 싱글 쓰레드(Single Thread) 환경하에서 문자열 변경시 사용하도록 한다.

자바 1.5에서 StringBuilder가 추가된 이유는 위에서 보이는 차이점과 같이 동기화 문제이다. 문자열 수정시 동기화 작업을 거치게 되면 큰 오버헤드를 거칠 수 밖에 없어 성능에 직접적으로 영향을 준다.

고로, 싱글쓰레드에서 동작하는 문자열들은 StringBuilder로 작업하는 것이 옳다.

JavaScript 관련 Favorate Site 모음

Mon, 15 Sep 2008 23:14:33 +0900

1. 클로저
http://jibbering.com/faq/faq_notes/closures.html

equals() perfect 하게 사용하기

Wed, 06 Aug 2008 14:11:15 +0900

List의 contains 메소드를 사용할 일이 있어서 equals() 메소드에 대하여 찾다가 다음과 같은 나이스 사용 예제를 찾게 되었다. 책에다 있는 내용이니궁금한점은 책을 찾다보도록 하자.

    public boolean equals(Object otherObject){
        if (this == otherObject )
            return true;

        if (otherObject == null)
            return false;

        if (getClass() != otherObject.getClass())
            return false;

        CareCustomer careCustomer = (CareCustomer) otherObject;

        return (careCustomerId == careCustomer.careCustomerId
                && customerId == careCustomer.customerId);
    }

토드 단축키 모음 by 김기사

Sun, 06 Jul 2008 22:58:49 +0900

간만에 기사네집에 놀러갔다가
꽤 오래된 포스팅을 보게 되었다.
도움이 될까 하여 퍼옴! thx 김기사

테이블 정보 상세보기

F4 : Table, View, Proc, Funct, Package를 DESC(테이블명 위에 커서를 두고 F4키)

자동완성

Ctrl+. : Table Completion (매칭되는 테이블목록 출력)

Ctrl+T : Columns Dropdown (해당테이블의 컬럼목록 표시)

SQL문 실행

F5 : SQL Editor내의 모든 SQL문 실행

Ctrl+Enter : 현재 커서의 SQL문 실행

F9 : SQL문 실행 후 Grid에 출력

히스토리(과거 수행SQL문 조회)

F8 : 과거에 실행한SQL문 HISTORY 목록

Alt+Up : History UP

Alt+Down : History DOWN

텍스트 대/소문자 변환

CTRL+L : 텍스트를 소문자로

CTRL+U : 텍스트를 대문자로

주석처리

Ctrl+B : 주석처리

Ctrl+Shift+B : 주석해제

편집 창 전환(이동)

F6 : SQL Editor와 결과창간의 이동

F2 : SQL Editor창 전체화면 전환

Shift+F2 : Grid Output창 전체화면 전환

기타 단축키

F7 : 화면을 모두 CLEAR

Ctrl+Shift+F : 쿼리문을 보기좋게 정렬

Ctrl+F9 : SQL문 Validate (SQL문을 수행하지 않음)

WP의 부활

Sun, 30 Mar 2008 23:29:38 +0900

오늘 새벽 워드프레스 2.5 버전이 베타 딱지를 떼어 버리고, 공개되었다. 오래전 접했던 워드프레스가 2.5버전으로 다시 돌아왔다고 하니, 방갑지 아니할수 없지 아니 하였다. 그래서 설치했다. 또 묵혀두었던 드루팔 또한 다시 한번 꺼내본다. (얼마전 업데이트 하다가 뻗었었구나..)

왜 설치만 재미 있는 것이냐? 좀 제대로 이용할 줄 알아야겠다. ㅋㅋ

Enum의 압박

Sat, 15 Mar 2008 00:44:04 +0900

#1. enum
public enum Coupon {
    saleCoupon("판매용"), sameCoupon("동일쿠폰");

    private String name;
    private Coupon(String name)
    {
       this.name = name;
    }
    private String getName()
    {
       return name;
    }
}

위와 같이 enum형을 선언했을때. String형의 입력을 받고 같은 이름을 가진 Coupon을 생성할때, 다음과 같은 코드를 작성하곤 했다.

String input = "saleCoupon";

Coupon c;
if(input.equals(Coupon.saleCoupon.toString()) {
    c = Coupon.saleCoupon;
} else if(input.equals(Coupon.sameCoupon.toString(){
    c = Coupon.sameCoupon;
}

오늘. 분명히 다른 방법이 있을 것이다.! 라고 믿고, Core Java를 뒤져보니 역시 다음과 같은 코딩방법이 있었다.

String input = "saleCoupon";

Coupon c = Enum.valueOf(Coupon.class, input);

조금 설렁~한 방법이긴 하지만, 다른 방법은 없는 것 같다. enum, 알아도 안쓰니 모르는 것만 못한것 같다.

#2. assert
enum형을 보다가 assert 예약어를 다시 훓어 보게 되었다. assert의 사용법은 다음과 같다.

assert condition;
또는
assert condition : expression;

예)
assert x >=0 : x;

if문을 쓰는것 보다 훨~ 씬 쉬울 것 같아 앞으로 자주 사용할까 했지만, 역시나 Test시에만 사용하는 이유가 있었다.
위의 condition이 옳지 않을 경우 AssertError 를 던진다. -_-;; (Exception이 아닌 Error이다.)
책에서도 내부 테스트 프로그램에서만 사용할 것을 권고하고 있다. 아쉽지만. 접자~

느림의 미학

Tue, 11 Mar 2008 23:27:01 +0900

언제나 그렇듯이 망우역에서 내려 역을 내려가는 에스퀄레이터에 몸을 실었다. 그 과정은 마치 토끼와 거북이의 달리기 시합과 같아, 내가 거북이가 되고 주위 사람들이 토끼가 되어, 나는 느릿 느릿 앞을 향해 가고 있었고, 사람들은 남에게 뒤질세라 앞을 향해 나아가고 있었다. 에스퀄레이터에서 나를 앞질러 내려가는 사람들의 뒷 모습을 보자니, 이런 생각이 들었다.
"왜 저렇게 빨리 걷는 것일까?"
다시 느린 걸음으로 횡단보도에 서니, 아까 빨리 걸어가던 사람들이 함께 서 있는 것이 아닌가?
"쯧쯧, 그러길래 왜 그리 빨리 가셨수? 이렇게 천천히 걸어도 어차피 같은 시간인걸.."
하고 생각했다.

생각해보면 그렇다. 원래 인간이란 여유를 즐기는 동물이라 했다. 나는 이 여유로움이 인간미를 만든다고 생각한다. 여유로울때 우리는 생각을 하고, 주위를 둘러보며, 외로워 한다. 그 외로움에 같은 종족을 찾아 나선다. 하지만, 지금은 어떠한가? 우리들은 이렇게 여유로울수 없다. 아니 그러해선 안된다. 왜? 동족이자 이족인 인간들이 있기 때문이다. 인간은 경쟁상대가 되어 버렸기 때문이다.

멀리 안동에서는 이렇게 답답할땐 손에 닿일 듯 한 별이 사는 밤하늘을 바라보며 한을 풀곤 했는데, 나는 오늘 그런 돌파구를 찾지 못했다. 올려본 하늘은 이미 아무것도 없었고, 번쩍이는 네온사인만이 나의 눈을 피로하게 만들고 있었다. 오늘도 피곤한 몸을 이끌고 지하 방에 스탠드를 켜 놓고, 이렇게 주저리 하며 밤을 맞고 있다.
그리고, 내일 아침엔 아마 지각하지 않도록 서둘러 방금 걸어온 길을 다시 걷고 있을 것이다. 조금 더 빠른 발걸음으로...

블루레이의 성공으로 JMF가 살아날까?

Sun, 09 Mar 2008 21:13:07 +0900

학부 시절 JMF(Java Media Framework)를 이용하여 잠시동안 아르바이트를 한 적이 있었다. 썬과 IBM의 합작으로 연구를 하다 (여러가지 이유로) 포기하곤 사장되어 버려 아쉬워 했던 기억이 있는데, 이 기술을 살릴 수 있는(발전시킬 수 있는) 기회가 왔다.

'블루레이' 승리의 이면에는 '자바'의 승리가 있었다. - Blu-ray Disc Java(BD-J) 의 글을 보면 블루레이가 기본적으로 자바플렛폼을 사용한다고 되어 있다.

출처 : Blu-ray BD-J Application Development using Java ME

위의 그림에서 BD-J Object로 쓰일 수 있는 Xlet, JMF등을 확인할 수 있다.

그동안 그닥 관심없이 보던 블루레이였다만, 관심있게 지켜보아야겠다. 오홍~

원스

Fri, 07 Mar 2008 23:51:20 +0900

역시 개봉했을때 봤어야 했는데.. 라는 후회가 밀려온다.

맥북을 사고 처음 밀어넣었던 Once OST 중. Say It to me now를 감상해보자.. 감미롭게. 기타소리가 좋쿠나~

더불어 후배녀석이 얼마전에 공개한 기타리스트 카미 연주 화면을 링크걸어본다. ㅋㅋ

링크는 여기에.

무제.

Thu, 06 Mar 2008 21:25:10 +0900

욕심은 없고

결코 성내지 않으며

언제나 조용히 웃고 있어

...

남쪽에 죽어가는 사람있으면

가서 겁내지 말라고 일러주고

북쪽에 싸움이나 송사 있으면

부질없는 짓이니 그만두라 말하고

....

모두에게 멍청이라 불리고

칭찬도 듣지 않고

골칫거리도 되지 않는

그런 인간이

나는

되고 싶다.

- 미야자와 겐지 -

은하철도 999의 원작이 된 은하철도의 밤의 저자 미야자와 겐지의 말이다. 그동안 podcast를 이용해 다운받아 놓은 EBS의 e-지식채널 방송을 훓어보다가 알게된 글이다. 사람의 본성(특히 외로움)을 그토록 훌륭하게 그려낸 영화나 책이 있을까 하는 정도로 인간의 다채로운 심리에 대하여 자세히 묘사한 애니메이션인 은하철도 999. 안타깝게도 우리나라에선 어린이를 위한 만화영화 정도로 전락해버렸다.

은하영웅전설을 본적이 있는가? 개인적으로 이 애니메이션은 남자라면 꼭 보아야 할 영화다 라고 강추한다. (하드를 날렸기 때문에 소스제공은 힘들다.) 여기에는 사람이 또는 남자가 살아가면서 겪는 인생사 그리고 삶의 미래를 예측하는 능력, 시야를 넓게 보는 안목등 어지간 해서 얻기 힘든 이야기들을 내재하고 있다. 역시 은하영웅전설이라는 소설을 원작으로 하고 있다.

많이들 아는 슬램덩크. 길게 이야기 하진 않겠지만, 젊음의 열정을 충분히 느낄 수 있고, 그것이 사람을 얼마나 변신을 시키는가를 확인해볼 수 있는 만화이다.

갑작스런 이야기지만, 사소하지만 의미를 두고 보면 좋은 점들을 확인 할 수 있는 것들이 주위에는 많은 것 같다. 정신차리고, 주위를 둘러보아야겠다. 좋은 애니 있으면 제공좀요~ 긁적;

철학을가진개발자 Vs 그렇지않은개발자

Wed, 05 Mar 2008 00:44:03 +0900

언젠가 이야기했던가? 잠시동안 아르바이트를 했던 도서관의 복사집의 돈많고 4가지 없어 보이던 주인이 한 이야기. 슬픈 공대의 현실을 콕 찝어 "공대인도 철학이 있어야해." 라고 했던.. 한잔의 막걸리를 앞에두고 들은 이 말은 가슴에 꽤 깊숙히 박혀갔다.
나도 철학을 가지고 살았던가? 라는 반성과 함께..

회사의 과장님께서 올려주신 Getting Real: 성공적인 웹어플리케이션을 개발하기 위한 방법 을 보며 잠시 옛 기억이 났다.

무엇이 개발자를 성공하게 하는가? 등의 추상적인 프로그램 개발 답안들이 여기 이 책에 담겨 있다. 37signals에서 정리한 이 프로그램 개발법(방법론이라고 하진 않겠다.)은 실제 그들이 프로젝트를 하며 배우고, 느끼고, 실행한 방법들이 녹아 있다. 하나의 철학론이 되어..

'컴퓨터. 일주일만 하면 전유성만큼 한다.' 라며 마치 정말 컴퓨터가 정말 쉬운냥 누군가를 현혹했던(또는 당했던) 경험처럼 이 책을 자근자근 읽다보면 진정 웃으며 할 수 있는 개발이 무엇인지, 어떻게 프로젝트를 성공할 것지에 대해 상상하게 된다.

과연 대한민국의 SI에서 이것이 적용될 수 있으런지 또는 어떻게 적용할 것인지는 조금 고민해 보아야겠지만, 열정과 행복에 관련된 이야기들은 스스로를 다독이기에 상당히 매력적인 내용이다.

철학은 어디에나 있다. 흔히 말하는 개똥에도 철학은 있다.(개똥철학이라고. 으흠) 삶의 철학이었던 웃으며 또 즐기며 키보드를 두드리지 못했던 약 3개월간 살아온 날들을 돌아본다.

원본 : http://gettingreal.37signals.com/toc.php
번역본 : http://gettingreal.37signals.com/GR_kor.php