프론트엔드 웹 개발을 위한 자동화 관리 툴: Yeoman, Grunt, Bower

이미지 출처: http://yeoman.io/learning

최근에 개인적인 스터디 그룹 프로젝트에 Grunt와 Bower를 적용 해봤는데 정말 재밌었고, 나름대로 상당히 만족을 하고 있다.

잘 배워두고 자주 사용하면 기본적인 구조를 잡는 것부터 각종 라이브러리 설치와 의존성 관리, 그리고 각종 빈번한 작업들(소스 코드 합치기, 압축 등등)을 편리하게 수행하고 관리 할 수 있을 것 같다.

이번 포스팅은 Grunt, Bower와 더불어 Yeoman에 대한 간단한 소개와 참고 링크 정도를 남겨 본다.

Grunt

• 자바스크립트 프로젝트를 위한 테스크 기반의 커맨드 라인 빌드 툴
• 테스크(task)란 무엇인가?
  작업의 단위라고 생각하면 되겠다.
  js, css, html 같은 static 파일들을 하나로 합치고(concat) 압축을 해서 파일 사이즈를 줄이는(minification) 작업들, 테스트, 배포 등등을 각각 하나의 테스크라고 생각하면 쉽다.
  Grunt는 이런 빈번한 작업들을 사용자가 미리 정의해 놓은대로(Gruntfile.js) 자동으로 빌드해주는 툴이다.
  
• Node.js로 만들어져 있다. 따라서 Node.js가 설치 되어 있어야 하고, npm에 등록 되어 있으며 global로 설치 한다.

Bower

• 프론트엔드 컴포넌트 의존성 관리 툴 이다. 쉽게 말해 위에서 Grunt를 설치하기 위해 사용한 npm과 비슷한 것이다.
• 예를 들어, 새로운 프로젝트를 시작하거나 진행하던 프로젝트에 bootstrap3을 설치한다고 했을때 bootstrap 웹사이트에 가서 소스코드를 다운 받고, 프로젝트의 적당한 디렉토리에 복사할 것이다.
  하지만 이미 설치 되어 있는 jquery 버전과 bootstrap에 포함된 jquery 버전과 차이에 의한 의존성 관계가 문제 될 수도 있다.
• bower는 이런 상황에서 각종 컴포넌트들의 설치도 간편하게 해주겠지만, 의존성 부분도 말끔하게 관리해준다.

Yeoman

• 일단은 스캐폴딩 기능만 사용해 봤기 때문에 웹 어플리케이션의 기본 구조를 쉽고, 편하게 잡아줄 수 있는 도구로 생각하고 있다.
• Generator 라는 것을 이용해서 개발하려는 프로젝트 종류(webapp, bootstrap, angularjs 등등)에 따라 기본적인 구조를 알아서 잡아준다.
• 내부적으로 Grunt, Bower를 사용하고 있다.

설치와 사용법 참고 사이트

• Grunt
• [번역]Grunt 공식 사이트, http://gruntjs-kr.herokuapp.com
• 자바스크립트 빌드 도구 Grunt, http://blog.outsider.ne.kr/892
• Bower
• Bower 공식 사이트, http://bower.io
• bower:웹 프론트앤드 패키지 관리자, http://blog.outsider.ne.kr/933
• Yeoman
• Yeoman 공식 사이트, http://yeoman.io

스터디 그룹 프로젝트에 적용해 보면서 생각 한건데 Python Flask 웹앱을 스캐폴딩 해주는 Yeoman Generator가 있었으면 좋겠다는 생각이 들었다.

그랬는데 역시나 있었다. github에서 2개 정도 찾았는데 한개는 angularjs와 flask 조합 제너레이터(generator-angular-flask) 이고, 나머지 하나(flask-app-generator)는 package.json 도 없고, 기타 등등 없는게 많은지 제대로 동작을 안한다.

바로 python virtual 환경 세팅(virtualenv)랑 flask 설치, 그리고 테스트 웹서버 실행까지 Grunt랑 조합해서 가능할 것 같은 생각이 드는데...

간단하게 하나 만들어 봐야겠다.

Read More

Python - 파이썬2.x Unicode와 UTF-8 인코딩 감잡기

 파이썬2.x의 기본 인코딩은 ascii 이다. 파이썬 스크립트에서 한글을 사용하게 될 때 파이썬은 ascii 인코딩일 것으로 예상하고 해석하려고 하지만 한글을 ascii로 해석이 불가능 하기 때문에 SyntaxError가 발생 한다.

 이 문제를 해결하기 위해 파이썬 파일의 최상단에는 아래와 같은 주석을 추가하면 조금 도움이 된다.

#-*- coding: utf-8 -*-

 이 주석이 있으면 해당 파이썬 스크립트는 utf-8로 인코딩 되어 있다는 것을 미리 알려주는 역할을 한다.

 여기서 잠깐 유니코드(unicode)와 utf-8에 대한 설명을 간단하게 하자면 utf-8은 유니코드를 위한 문자 인코딩 방식 중에 하나이다. utf-8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지 사용한다고 한다.

 다시 파이썬의 인코딩에 대한 부분으로 돌아가서 간단한 예제를 하나 보도록 하자.

# -*- coding: utf8 -*-

print(type('한글').__name__)  # str
print(type(u'한글').__name__)  # unicode

print(type('한글').__name__)
print(type(u'한글').__name__)

SyntaxError: Non-ASCII character '\xed' in file…블라블라~

 위 예제 코드의 결과를 보면 쉽게 감을 잡을 수 있다.

 첫번째 에제코드에서 상단에 내부 문자에 대한 인코딩을 utf-8로 하겠다는 미리 알려줬기 때문에(누구에게?? print에게!!) ‘한글’이라는 문자열의 타입은 확인해보면 string 이다. 그리고 u’한글’으로 하게 되면 유니코드로 잘 변환해서 출력 시켜주는 것을 알 수 있다.

 두번째 예제에서는 상단에 선언한 부분을 제거하고 스크립트를 실행 시켜봤는데 역시나 문법에러(SyntaxError)가 발생 하는 것을 확인 할 수 있었다. ‘한글’을 기본적으로 ascii로 해석하려 하기 때문에 type을 알 수도 없고, 유니코드로 변환도 할 수 없는 것이다.

# -*- coding: utf8 -*-

print str(unicode('한글'))
print str(unicode(‘한글', ‘utf-8'))

 ‘한글’을 유니코드로 변환하고, 그 유니코드를 다시 문자열로 바꿔서 출력하려고 한다.
이 코드는 결과는 무엇일까?
unicode() 기본적으로 전달된 인자값을 ascii로 해석하려고 하기 때문에 위 예제는 아래와 같은 에러가 발생한다.

UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in position 0: ordinal not in range(128)

 결국 상단에 utf-8을 사용할 것이라고 선언했어도 unicode() 함수를 사용할때는 소용없다는 것을 알게 되었다.

이 코드를 정상적으로 동작하도록 해보자.

# -*- coding: utf8 -*-

# 유니코드로 다루기 예제1
hoo = unicode('한글', 'utf-8')
print str(hoo.encode('utf-8'))

# 유니코드로 다루기 예제2
bar = '한글'.decode('utf-8')
print bar.encode('utf-8')

# 유니코드로 다루기 예제3
foo = u'한글'
print str(foo.encode('utf-8'))

정신 건강을 위해서라도 파이썬 스크립트 내부에서 사용하는 모든 문자열은 유니코드로 다루는 것이 좋겠다.
그리고 파일이나 DB에 저장하거나 네트워크로 전송하기 직전에는 string으로 변환해서 넘겨주는 방식으로 개발하는 것이 좋다…

아! 그리고  ‘유니코드가 아닌 상태로 CJK(Chinese. Japanese, Korean) 비교할 때 주의할 점’(https://gist.github.com/kimdwkimdw/a2ea13848167984adc8f)도 참고하고 숙지해서 개발시에 엉뚱한 삽질은 안하도록 하자!

참고 자료

• http://ko.wikipedia.org/wiki/UTF-8
• http://libsora.so/posts/python-hangul/
• http://seorenn.blogspot.kr/2011/02/python-unicodeutf-8.html
• http://www.slideshare.net/LeeSeongjoo/2-17395073
• http://amornatura.tistory.com/104
• http://www.lug.or.kr/m/bbs/view.php?bo_table=python&wr_id=68&page=1

Read More

javascript 상속(Inheritance) - 의사 클래스 방식과 Object.create 메소드 의 연관성

객체지향 프로그래밍에서 상속은 너무나 자연스럽게 다뤄지는 프로그래밍 기법이다.
상속은 코드 재사용의 한 형태이고, 부모 객체의 데이터 타입 체계를 그대로 전달 받기 때문에 개발 비용을 감소 시켜주는 장점이 있다

하지만 일반적인 객체지향 프로그래밍 언어와 다르게 자바스크립트는 클래스(class)가 없다. 상속(Inheritance) 메커니즘을 구현하기 위해서는 자바스크립트의 특징이라고 할 수 있는 프로토타입(prototype)을 기반으로해서 부모 객체를 자식에게 상속 할 수 있다.
이것은 다시 말해 객체가 다른 객체로 바로 상속 된다는 것을 의미 한다.

이번 포스트에서 정리할 내용은 자바스크립트의 상속 패턴중에서 함수의 프로토타입 프로퍼티를 활용한 방식이다.

지난번 javascript 함수 - 함수 객체의 프로토타입 프로퍼티 이해하기 에서 정리한 함수의 프로토타입 프로퍼티(prototype property)을 먼저 살펴보면 좋을 것 같다.

의사 클래스 방식 Pseudoclassical

---

의사 클래스(Pseudo class, 슈도 클래스라고 읽음)는 가짜 클래스 정도로 이해하자. 사실 이번에 처음 알게된 표현인데 너무 어렵게 생각했던 것 같다.
자바스크립트에서의 의사 클래스 방식은 클래스가 없는 자바스크립트가 클래스를 흉내내기 위해 작성하는 패턴이라고 생각하면 된다.

자바스크립트는 프로토타입적 특성에 맞게 객체에서 다른 객체로 직접 상속하는 방법을 갖기는 하지만 생성자 함수를 통해서 객체를 생성해야하는 조금 혼란스러운 단계가 있다.

좀 더 자세히 설명하자면, 객체의 프로토타입은 해당 객체가 생성 될때 사용한 객체의 원형에 대한 연결을 담고 있기 때문에 이미 생성된 객체의 프로토타입에 다른 객체를 바로 상속할 수는 없다.
다른 객체를 새로운 객체에 상속하기 위해서는 객체가 생성되기 전에 생성자 함수에서 함수객체의 프로토타입 프로퍼티에 객체를 직접 할당하는 식으로 상속을 구현하는 것이다.
(함수 객체의 프로토타입 프로퍼티에는 자신을 통해 생성될 객체가 참조할 객체의 원형을 갖고 있다.)

자, 그럼 이제 자바스크립트의 상속을 구현하기 위해 의사 클래스 방식으로 예제를 작성해보겠다.

다음 코드는 '여자친구가 당분간 연락하지 말자'고 했을때 당분간의 정확한 기간을 계산해주는 객체를 생성한다.

var Love_anger_formula = function () {
    this.__swear_word_constant = 18;  // 욕주율
    this.get_swear_word_constant = function () {
        return this.__swear_word_constant;
    };
};

var do_not_contact = function (contact_stop_time, lie_count) {
    this.contact_stop_time = contact_stop_time;  // 연락 두절 시간
    this.lie_count = lie_count;  // 거짓말 횟수
};

// do_not_contact 함수의 prototype property 객체를 Love_anger_formula 의 인스턴스로 대체한다.
do_not_contact.prototype = new Love_anger_formula();

var how_long = new do_not_contact(24, 2);

// how_long 객체에 새로운 메소드를 추가한다.
// '당분간'의 기간을 계산한 결과를 돌려준다.
how_long.get_remain_period = function () {
    var  swear_word_constant = this.get_swear_word_constant();
    return this.contact_stop_time * this.lie_count * swear_word_constant;
};

console.log(how_long.get_remain_period());

Do_not_contact 라는 생성자 함수를 정의 하고, 이 함수의 prototype을 Love_anger_formula 의 인스턴스로 대체하는 방식으로 의사 클래스 만들어서 객체를 상속했다.

더글라스 크락포드는 이런 의사 클래스 패턴을 객체지향처럼 보이게 고안 됐지만 마치 어디 외계에서 온 패턴과 같다고 말했다.
자바스크립트에 익숙하지 않는 개발자에게 친숙한 방식이 될 수도 있겠지만, 자바스크립트의 장점을 가리게 되는 방법이라는 말도 덧붙였다.

아무튼 이렇게 생성된 객체의 최대의 문제점은 바로 모든 속성들이 public 이라는 것이다. private은 없다.
how_long.__swear_word_constant로 부모 객체의 속성에 바로 접근해서 읽거나 값을 변경할 수 있다.

또한 생성자 함수를 new 연산자로 실행하지 않으면 this는 새로운 객체에 바인딩 되지 않고, 전역 객체(window)에 연결된다. new 연산자를 빼먹어도 어떠한 에러도 발생하지 않기 때문에 매우 심각한 문제가 발생할 수 있다.

이 문제에 대한 해결책(?)으로 더글라스 크락포드가 추천하는 방법은 2가지가 있는데 new 연산자로 실행해서 객체를 생성하는 생성자 함수의 이름은 첫글자를 대문자로 표기하는 것이다.
그리고 나머지 한가지는 new 연산자 사용을 피하는 것이다.

언어의 특징을 비교하는 차원에서 위 예제 코드와 동일한 기능을 하는 파이썬(python) 코드를 작성해 보았다.
LoveAngerFormula 클래스의 __swear_word_constant 변수는 완전 안전한 private 이다.

# -*- coding: utf8 -*-


class LoveAngerFormula():
    __swear_word_constant = 18  # 욕주율

    def get_swear_word_constant(self):
        return self.__swear_word_constant


class DoNotContact(LoveAngerFormula):
    def __init__(self, contact_stop_time, lie_count):
        self.contact_stop_time = contact_stop_time  # 연락 두절 시간
        self.lie_count = lie_count  # 거짓말 횟수
        self.swear_word_constant = self.get_swear_word_constant()

    def get_remain_period(self):
        """
        '당분간 연락하지 말자' 했을때 당분간의 정확한 기간을 계산
        :return: 기간(일)
        :rtype: integer
        """
        return self.contact_stop_time * self.lie_count * self.swear_word_constant


how_long = DoNotContact(24, 2)
print(how_long.get_remain_period())

Object.create() 전달한 객체를 프로토타입으로 새로운 객체를 생성하는 메소드

---

Object.create() 메소드로 만들어지는 객체는 프로토타입을 직접 지정해서 생성할 수 있는 편리한 기능을 제공한다.
이런게 있는지도 몰랐었는데 이미 표준에 포함되어 있는 메소드 이다!
크롬(Chrome)과 파이어폭스(Firefox)에서는 당연히 제공하고 있었고, IE는 뒤늦게 9부터 지원한다.

Object.create() 메소드가 생기게 된 배경은 new 연산자 사용이 '자바스크립트 스럽지 못하다'는 의견이 나오게 되면서 new 연산자 사용을 자제하기 위해 만들어졌다고 한다.

그런데 이 메소드를 지원하지 않는 브라우저를 위해서 작성하는 코드를 보면 조금 웃긴 사실을 알 수 있다.

if (typeof Object.create !== 'function' ) {
    Object.create = function (obj) {
        function F();
        F.prototype = obj;
        return new F();
    }
}

결국 Object.create()메소드도 내부적으로 F()라는 빈 함수를 만들고, 위에서 살펴본 의사 클래스 방식으로 F 함수의 프로토타입 프로퍼티에 전달받은 객체를 대체한다.
그리고 new 연산자로 생성한 객체를 돌려준다.

new 연산자 사용을 자제하기 위해서 만들어진 메소드는 결국 손바닥으로 하늘을 가리는 꼴이다.

마무으리

---

자바스크립트의 프로토타입 특징을 활용한 상속에 대해 정리 해봤는데 조금 찝찝한 느낌을 지울 수 없는 것은 사실이다.
하지만 함수의 프로토타입 프로퍼티로 클래스를 흉내내는 의사클래스방식과 Object.create()메소드의 연관성에 대한 부분은 확실히 알고 간다는 것에 매우 만족한다.

Read More

javascript 함수 - 함수 객체의 프로토타입 프로퍼티 이해하기

앞으로 몇번에 걸쳐서 자세히 알아볼 부분은 모든 개발 언어에서 굉장히 많이 사용하고, 자바스크립트에서도 핵심이라고 할 수 있는 함수에 대한 부분이다.
그리고 이번 정리에서는 함수 객체와 프로토타입 연결 특성과의 관계에 대해서 중점적으로 알아볼 것이다.

객체의 프로토타입(prototype)

---

자바스크립트에서 숫자, 문자열, 불리언(true/false), null, undefied를 제외한 모든 값은 객체이다. 생소한 표현이지만 숫자나 문자열, 불리언은 메소드를 갖기 때문에 유사객체라고도 한다. 이 유사객체에 대한 부분은 다음 기회에 좀 더 조사해 볼 것이다.

더글라스 크락포드의 'Javascript The Good Parts'에서는 함수 객체에 대해 설명한 부분에서 프로토타입과 관련해서 설명한 부분을 요약해서 정리하자면 아래와 같다.
프로토타입에 대해 어느정도 알고 있더라도 이것을 보게 되면 상당히 혼란을 일으킬 가능성이 높다.

함수는 객체이다. 객체는 프로토타입 객체(Prototype Obeject)로 숨겨진 연결을 갖는 이름/값 쌍들의 집합이다. 객체 중에서 객체 리터럴로 생성되는 객체는 Object.prototype에 연결 된다.  반면 함수 객체는 Functon.prototype에 연결 된다. Function은 다시 Object.prototype에 연결 된다.  모든 함수 객체는 prototype이라는 속성이 있다. 이 속성의 값은 함수 자신 자체를 값으로 갖는 constructor라는 속성이 있는 객체이다. 이는 Function.prototype으로의 숨겨진 연결과는 다른 의미 이다.

자바스크립트 개발을 해본 경험이 있다면 대부분 프로토타입(Prototype)에 대해서 들어봤을 것이다. 프로토타입은 클래스가 없는 자바스크립트에서 객체지향적인 프로그래밍을 하기 위해서 사용하는 특징이라고 할 수 있다.
좀 더 쉽게 말하자면 상속(Inheritance)을 구현하여 객체가 다른 객체에 속성들을 물려줄 수 있도록 하기 위해 프로토타입을 사용할 수 있는 것이다.

위 인용문의 내용을 살펴보면 크게 객체와 프로토타입과의 관계와 함수와 프로토타입과의 관계 부분으로 구분되는 것을 알 수 있다.

간단하게 객체를 만들어서 차이점을 확인해 보면 좋을 것 같다.

var func = function () {
    this.one = 'Hello';
    return {
        one: one,
        two: 'world'
    };
};
var obj1 = func();

var obj2 = {
    one: 'Hello',
    tho: 'world'
};

console.dir(obj1);
console.dir(obj2);

위 예제를 실행 결과로 나오는 obj1과 obj2는 완전히 똑같다. 객체 생성 방법에 대한 다른 표현 방식이 있다는 것을 보여주기 위해 똑같은 객체를 생성했을 뿐이지 사실 여기서 중요하게 봐야하는 부분은 console.dir()의 결과로 콘솔에 출력되는 내용이다.

인용문에서 언급된 '객체 리터럴로 생성된 객체는 Object.prototype에 연결된다'는 부분은 위 그림에 나타나있는 __proto__를 말한다.
어렵다. 이렇게 하면 이해하기가 쉽지 않다. 이해를 해야 사용할 수 있고, 누구에게나 설명할 수 있기 때문에 이 개념을 좀 더 명확한 예제로 확인해 볼 필요가 있다.

var Func = function () {
    this.prp = 'Jonnung';
}

var ins = new Func();

console.dir(ins);

이 예제 코드는 new 키워드를 사용해서 객체를 생성할 수 있는 생성자 패턴으로 작성된 함수이다.
생성된 ins라는 객체 내부를 살펴본 모습은 아래와 같다.

ins 객체의 __proto__.constructor를 확인 해보면 Func() 생성자 함수가 들어 있는 것을 알 수 있다. 한마디로 ins 객체는 Func() 라는 생성자 함수를 원형(프로토타입)으로 생성된 객체라고 할 수 있다.
이제 그림이 조금 명확히 보이기 시작하는 느낌이다.
위에서 객체 리터럴로 생성된 객체는 __proto__.constructor 속성에 Object()가 있던 것은 리터럴 표기법으로 생성 된 객체는 리터럴의 특성상 즉시 객체화가 되기 때문에 직접적인 객체의 원형이라고 할 수 있는 대상이 없고, 바로 최상위 원형인 Object이 원형이 되는 것이다.

함수는 객체이다.

---

객체의 프로토타입에 대해 정리가 끝났다고 프로토타입에 대한 이해가 끝난것은 아니다.
이전 단락의 인용문에서 말하듯 함수도 역시나 객체이다. 이제부터 혼란을 방지하기 위해 함수를 함수 객체로 표현하도록 하겠다.
이번에 살펴볼 내용은 함수객체만이 갖고 있는 프로토타입 프로퍼티(prototype property) 라는 것이다.

위 단락의 두번째 예제의 console.dir()을 객체가 아닌 생성자 함수에 대해 실행해 보도록 하겠다.

var Func = function () {
    this.prp = 'Jonnung';
}

var ins = new Func();

console.dir(Func);

위에서 객체의 내부에 __proto__가 객체의 원형인 프로토타입이라고 했는데 이 함수 객체에는 __proto__도 있고, prototype 이라는 속성도 있는 것을 확인 할 수 있다.

이 prototype property는 함수 객체만이 갖고 있는 속성이다. 그리고 위에서 설명한 객체의 프로토타입과는 의미가 전혀 다르기 때문에 절대로 착각해서는 안된다. 우리가 흔히 상속의 개념으로 생각하는 객체의 원형인 프로토타입은 전 단락에서 설명한 객체가 생성되기 위해 사용한 원형이라는 의미의 프로토타입이 맞다.

그럼 함수 객체만이 갖고 있는 이 prototype property는 무엇인가!
바로 자신을 통해 만들어질 객체들이 원형(프로토타입)으로 사용할 객체 이다.

일단 정의 자체가 다르기 때문에 혼란스러워할 이유는 없다. 그리고 이런 흐름을 증명할 수 있는 증거는 이미 위 코드의 결과에서 확인한 것이나 다름없다. (갑자기 반전스러운 말투)

마무으리

---

1. Func() 생성자 함수는 자신을 원형으로 해서 생성될 객체가 참조할 객체를 프로토타입 프로퍼티(prototype property)에 갖고 있다.
2. Func() 생성자 함수로부터 탄생한 객체 ins는 흔히 프로토타입이라고 하는 자신이 만들어질 때 원형으로 사용한 객체에 대한 연결 정보를 갖고 있다.

참고

---

• 더글라스 크락포드의 자바스크립트 핵심 가이드 (Javascript The Good Parts)
  (http://www.yes24.com/24/goods/3071412?art_bl=5547705)
• Javascript 기초 - Object prototype 이해하기
  (http://insanehong.kr/post/javascript-prototype/)

Read More

Python 기초 팁과 트릭

객체 진위

• 객체의 길이가 0인지, 값이 비어 있는지 체크할 필요가 없다. 파이썬의 객체는 비어있으면 거짓(False)이다. 숫자 0도 거짓이다.

삼중 따옴표를 사용한 문자열 선언

• 삼중 홑따옴표든 쌍따옴표든 내부에 인용구 표현처럼 또 다른 삼중따옴표를 쓸 수 있다. 이스케이프가 필요 없어진다.

문자열안에 부분 문자열 찾기

• 부분 문자열을 찾기위해 find 메소드를 사용할 필요가 없다. 리스트, 튜플, 사전을 다루듯이 in을 사용하면 같은 효과를 볼 수 있다.

람다함수

• 람다함수는 단 하나의 표현식의 결과를 돌려주는 미니 함수 이다.
• 람다함수는 그 자체가 표현식이다. 다른 서술문 안에 사용 될 수 있다.
• 함수를 인자로 넘겨여 할때나, 복잡한 연산을 여러번 하고 싶을때 람다함수를 활용할 수 있다.

Read More

Concept git rebase and example

git으로 코드의 버전관리를 하면서 브랜치 작업을 많이 하게 되는데 사실 난 브랜치 생성을 좀 즉흥적으로 하는 감이 없지 않아 있다.

무언가 작은 것이라도 개발을 할 때는 브랜치 계획을 어느정도 수립해 놓게 되면 느닷없는 브랜칭으로 커밋 로그가 복잡해지는 일은 없을 것 같는 생각이 든다.

브랜치를 사용하면서 개발을 하다 보면 어느 순간에는 머지(merge)를 하기 마련이다.
그런데 예전에 Git 브랜치 배우기을 해보면서 git에 merge와 결과는 같지만 동작 방식이 다른 리베이스(rebase)라는 기능이 있다는 사실을 알게 되었다.
그때 rebase 예제를 풀어보면서 개념 부족으로 상당히 오랜 삽질을 했던 기억이 난다. 윽..

아무튼 일단 rebase와 merge의 차이에 대한 결론부터 정리하자면 아래와 같다.

Merge는 결과를 합치고

Rebase는 과정을 비교하여 결과와 같이 합친다.

rebase와 merge의 차이를 간략하게 알았다면, 언제 rebase를 써야하는 지가 가장 중요하다.

위에서 말 했듯이 브랜치를 merge 하게 되다보면 히스토리가 복잡해지기 마련이다.
rebase를 사용하면 이런 히스토리를 깔끔하게 정리할 수 있는 효과가 있다고 보면 된다.

간단한 예제를 직접 해보면서 rebase와 merge의 차이와 명령어를 좀 더 자세히 알아보겠다.

Base History

---

일단 merge와 rebase를 비교하기 위해 적당한 히스토리를 만들어 보겠다.
number.txt 라는 새로운 파일을 하나 만든다.
적당히 내용을 입력하고, master 브랜치의 stage영역에 추가(add) 후 커밋(commit)을 했다.
그리고 또 한번 number.txt 파일의 2번 줄의 문장을 변경 하고, 다시 한번 commit을 한다.

123456789
Number content.

이제 2명의 개발자가 각각 브랜치를 만들어 내용을 수정하는 과정을 진행 하겠다.
첫번째 개발자의 브랜치명은 dev-1, 두번째 개발자의 브랜치명은 dev-2로 정했다.

일단 dev-1 개발자가 먼저 파일을 2번 수정하고 각각 2번 commit 했다.

0123456789
Number content!!!

아직까지 dev-2 개발자는 파일을 수정하지 않았다. 그런데 이번에는 master 브랜치에서 파일의 수정이 한번 더 발생 했다. (파일 내용은 생략)

그리고 이제 dev-2 개발자가 자신의 브랜치에서 파일을 수정한다

0123456789
9876543210
10 Numbers contents.

그리고 마지막으로 다시 master 브랜치로 돌아와 새로운 내용을 한번만 더 추가 했다.

123456789
987654321
192837465
Number content.

자 이제 모든 수정이 완료 되었다. 횟수는 적지만 약간 복잡하게 파일 수정이 발생했고, 중간 중간에 master 브랜치의 내용도 수정이 되면서 상황은 점점 악화 되고 있다.

벌써부터 conflict의 그림자가 발밑까지 와있는 느낌이다.

제가 이렇게 히스토리를 만든 이유는 히스토리 그래프를 이해하기 쉽게 만들기 위함과 conflict 발생시 해결하는 과정 그리고 merge와 rebase의 차이점 모두를 담기 위함이 였습니다. 돌 던지지는 마세요. ㅠ_ㅠ)a

현재 상태에서 merge와 rebase를 각각 진행 해보겠다.

Merge

---

일단 현재 브랜치가 master 인지 확인하고, dev-1 브랜치를 merge 한다.

$ git branch
  dev-1
  dev-2
* master

$ git merge dev-1

위와 같이 master와 dev-1브랜치 사이에 conflict가 발생했다고 알려준다. 그렇다면 에디터를 열고 number.txt 파일을 원하는 형태로 직접 수정을 해주고 계속 진행을 해야 한다.

<<<<<<<< HEAD
123456789
987654321
192837465
Number content.
=======
0123456789
Number content!!!
>>>>>>> dev-1

'======='을 중심으로 위쪽은 master 브랜치쪽 내용, 아래쪽은 dev-1 브랜치쪽 내용 이다.

123456789
987654321
192837465
Number content!!!

위 결과처럼 dev-1 브랜치의 내용 중 마지막 'Number content!!!'만 병합 하도록 수정 했다.
conflict를 해결하고 머지를 마무리하는 머지 커밋(Merge commit)을 한다.

$ git add number.txt
$ git commit
[master bc64d16] Merge branch 'dev-1'

그리고 dev-2 브랜치도 위와 동일한 방법으로 master브랜치에 merge 한다.

$ git merge dev-2 
# 에디터에서 Conflict를 해결하고 다시 커밋!

$ git add number.txt
$ git commit
[master 2195143] Merge branch 'dev-2'

Rebase

---

이제 rebase를 해보겠다.

이번에는 merge때와 위치하는 브랜치가 다르다는 것을 주의 해야 한다. 아래와 같이 rebase가 되는 토픽 브랜치(Topic)로 checkout 하고 master 브랜치로 rebase를 하도록 명령어를 실행 시킨다.

$ git branch
  dev-1
  dev-2
* master

$ git checkout dev-1
$ git rebase master

여기서 rebase의 특징이 나오게 된다. Git은 변경 이력을 모두 비교하면서 병합을 시도 하기 때문에 위와 같이 conflict가 발생하는 것을 알려주고 처리 방법을 제안 한다.

123456789
<<<<<<< HEAD
987654321
192837465
Number content.
=======
Number content!!!
>>>>>>> 마침표를 느낌표 3개로 변경

저는 아래와 같이 수정하여 conflict를 해결하고 stage 영역에 올려놓고(add) 다음 rebase를 진행 한다.

123456789
987654321
192837465
Number content!!!

$ git add number.txt
$ git rebase --continue

다음 리비전에서의 conflict도 위와 동일한 방법으로 해결하고 계속 rebase를 진행 한다.

$ git add number.txt
$ git rebase --continue

$ git rebase --skip

$ git checkout master
$ git merge dev-1

dev-2 브랜치에 대해서도 위와 동일한 방법으로 master 브랜치에 rebase 한다.

$ git checkout dev-2
Switched to branch 'dev-2'

$ git rebase master

$ git add number.txt

$ git rebase --continue

$ git add number.txt
$ git rebase --continue
Applying: 더 자세한 내용 정의 문장으로 수정

$ git checkout master
Switched to branch 'master'

$ git merge dev-2
Updating bad6d94..258c855
Fast-forward
number.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

이제 필요 없어진 dev-1과 dev-2 브랜치는 삭제 한다.

$ git branch -d dev-1 dev-2
Deleted branch dev-1 (was bad6d94).
Deleted branch dev-2 (was 258c855).

위에서 각각 해 본 rebase와 merge는 결과는 같지만 보여지는 커밋 트리들의 차이가 있는 것을 알 수 있다.

Read More

Git 기본 명령어 정리와 참고하면 좋은 링크 정보

 작년에 처음 Github를 알게 되면서 Git을 배워볼 기회가 있었다.
개인적으로 진행하는 스터디에 활용을 해보기는 했으나, 당시 회사에서 사용하는 버전관리 프로그램으로 SVN에서 머큐리얼(Mercurial)로 전환하는 시기였다.
그러다 보니 머큐리얼도 학습하게 되었고, 사용하게 되면서 당연히 Git보다는 머큐리얼을 사용하는 비중이 높아졌다.

 하지만 시간이 흐르면서 Github에서 소스 코드를 검색하고, 참고하는 빈도가 증가하는 것을 느끼게 되었다.
 그러면서 드는 생각이 올해는 내가 만든 소스 코드들을 Github에 올려서 전세계 개발자들과 공유하고, 평가 받으며(관심을 끌 수만 있다면..) 핵심적으로는 내가 열정을 갖고 진행하는 것들에 대한 증거를 남기고 싶다는 목표가 생기게 되었다.
 그래서 올 한해 계획을 세우면서 가장 먼저 배우고 능숙하게 다뤄야 하는 기술로 Git을 선정했고, 이번 포스트에서는 Git을 사용하기 위한 기본적인 명령어를 정리해 보았다.

 기본적인 명령어에 대한 구성은 웹 상에서 Git의 기본적인 명령어를 직접 실행해보고, 사용 방법을 배울 수 있는 Code School의 Try Git의 각 단계를 참고 하였다.

 각 명령어에 대한 설명은 Try Git에서 나오는 설명들을 기초로 하였고, 나름 번역을 해보았다.
 Git을 처음 접하는 사람들은 이 포스트를 보는 것 만으로 Git을 사용하기에는 많이 부족할 것이지만 Try Git을 단계별로 학습하면서 참고하면 좋을 것 같다.

Git의 고급 테크닉을 조금 더 능숙하게 다루기 위한 정보를 하나 더 추가 하자면 Git 브랜치 배우기를 추천한다.
Try Git에서 다루지 않지만 Git에서 좋다고 소문난 Rebase와 Cherry pick에 대한 학습에 많은 도움이 되었다.

---

Initializing

Initialize a Git repository

Git 저장소를 생성 한다.

git init

Checking the status

To see what the current state of our project

현재 상태를 확인 한다.

git status

Adding Changes

Notice how Git says 'untracked?' That means Git sees that this is a new file.

추적 되지 않은 새로운 파일이 있다는 의미 한다.

To tell Git to start tracking chang
es made to this file. we first need to add it to the staging area by using git add

파일의 변경 내역을 추적하기 위해 Git의 준비 영역으로 파일을 추가 할 필요가 있다.

git add octocat.txt
git add '*.txt'

Committing All Changes

Notice how Git says 'changes to be committed?' The file listed here are in the Staging Area, and they are not in our repository yet. We could add or remove files from the stage before we store them in the repository.

 git status 명령어로 현재 상태를 확인하면 'changes to be committed'라는 부분을 볼 수 있다.

 여기에 해당하는 파일 리스트는 아직 Git 저장소의 준비 영역에 있는 파일들의 목록이고, 저장소로 보내기 전에 준비 영역에서 추가 하거나 삭제 할 수 있다.

To store our staged changes we run the commit command with a message describing what we've chaged.

준비 영역에서 변경 내역을 저장소로 저장하기 위해서는 남길 메세지와 함께 commit 명령어를 사용한다.

git commit -m "Add cute octocat story"

History

Git's log as a journal that remembers all the changes we've committed so far, in the order we commited them.

Git 로그는 커밋 된 모든 변경 사항에 대한 기록 이다.

git log

Remote Repositories

To push our local repo to the GitHub server we'll need to add a remote repository.

로컬 저장소의 변경 내역을 Github 서버에 push 하기 위해서는 원격 저장소(중앙 저장소)를 추가 해야 한다.

git remote add origin https://github.com/try-git/try_git.git

Pushing Remotely

The push command our local changes to our origin repo (on Github)

push 명령어는 로컬 변경 내역을 origin 이라고 지정한 중앙 저장소로 보낸다.

The name of our remote is origin and the default local branch name is master.

origin은 원격(중앙) 저장소의 이름(닉네임 정도)이고, 기본 로컬 브랜치의 이름은 master 이다.

The '-u' thel Git to remember the parameters, so that next time we can simply run git push and Git will know what to do.

'-u' 파라미터를 추가하면 다음 push 명령어 실행부터는 중앙 저장소와 로컬 브랜치의 이름을 입력하지 않고도 push 할 수 있다.

git push -u origin master

Pulling Remotely

We can check for changes on our Github repository and pull down any new changes.

Github 서버의 변경 내역이 있는지 확인하기 위해서 pull 명령어를 사용해 새로운 변경 사항을 가져온다.

git pull origin master

Differences

Let's take a look at what is different from our last commit by using the git diff command.

로컬 저장소의 최종 커밋 로그와 차이점을 살펴보기 위해서 diff 명령어를 사용 한다.

In this case we want the diff of our most recent commit, which we can refer to using the HEAD pointer

가장 최근의 변경 내역을 비교하려면 HEAD 포인터를 사용해서 조회 할 수 있다.

git diff HEAD

Staged Differences

Another great use for diff is looking at changes within files that have already been staged.

diff는 이미 준비 영역에 있는 변경 내역과의 비교하기에도 좋다.

Staged files are files we have told git that are ready to committed.

준비 영역의 파일은 커밋 되기를 전의 파일을 말한다.

git diff --staged

Resetting the Stage

Unstage files by using the git reset command.

준비 영역의 파일을 삭제하려면 reset 명령어를 사용한다.

git reset octofamily/octodog.txt

브랜치로 하여금 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다. 이러한 관점에서 '히스토리를 고쳐쓴다.'라고 할 수 있다. 이것은 마치 애초에 커밋을 하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것과 같다.

git reset HEAD~1

Undo

Files can be changed back to how they were at the last commit by using the command: git checkout -- <target>

마지막 커밋 된 파일로 교체하기 위해서 checkout 명령어를 사용한다.

git checkout -- octocat.txt

위 명령은 로컬의 변경 내용을 변경 전 상태(HEAD)로 돌려놓는다. 하지만 이미 준비 영역에 추가된 변경 내용과 새로 생성한 파일은 그대로 남는다.

Branching out

Code make separate commits to. Then when they're done they can merge this branch back into their main master branch.

새로운 코드는 새로운 브랜치에 커밋을 할 수 있다. 브랜치는 특정 커밋에 대한 참조(Reference)이며, 그 코드가 완료가 되면 다시 master 브랜치와 병합 할 수 있다.

Create a branch call.

branch는 새로운 브랜치를 만들기 위한 명령어 이다.

git branch clean_up

Delete a branch

branch를 삭제하려면 -d 파라미터를 추가하고 브랜치명을 입력 한다.

git branch -d clean_up

Switching Branches

다른 브랜치로 변경 하려면 checkout 명령어와 브랜치명을 같이 입력한다.

git checkout clean_up
git checkout -b clean_up

Removing all the things

Not only remove the actual files from disk, but will also stage the removal of the files for us.

rm은 준비 영역의 파일을 삭제 할 뿐만 아니라 실제 개발자 컴퓨터에 있는 파일도 삭제 된다.

removed all files you'll need to commit your changes.

파일을 삭제한 변경 내역도 커밋해야 한다.

git rm octodog.txt
git rm '*.txt'

Preparing to Merge

The moment has come when you have to merge your changes from the clean_up branch into the master branch.

별도 브랜치의 변경 내역으로부터 master 브랜치로 병합할 때가 오면 merge 명령어를 사용한다.

git merge clean_up

Rebase

브랜치끼리 작업을 접목하는 방법으로 rebase가 있다. 리베이는 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳으로 떨궈 놓는 것이다.

리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있다.

git rebase master

Revert

각자의 컴퓨터에서 작업하는 로컬 브랜치의 경우 reset을 잘 쓸 수 있지만, '히스토리를 고쳐쓴다'는 점 때문에 다른 사람이 작업하는 원격 브랜치에는 쓸 수 없다.

변경 내역을 되돌리고, 되돌린 내용을 다른 사람들과 공유하기 위해서는 revert를 사용해야 한다.

git revert HEAD

Push

All that's left to do is to push everything you've been working on to your remote repository.

모든 것이 완료 되면 원격(중앙) 저장소로 push 한다.

git push

---

참고하면 좋은 정보

http://rogerdudler.github.io/git-guide/index.ko.html
http://git-scm.com/book/ko
http://marklodato.github.io/visual-git-guide/index-ko.html

Read More

php XDebug를 사용하여 원격 디버깅 하기 (xampp 환경)

XDebug를 적극 활용하여 그동안 echo, print_r, var_dump를 이용해서 출력값을 확인하던 디버깅 습관을 바꿔보자!

일단 php xdebug의 동작 원리를 이해하기 위해서 '생활코딩' 이고잉님이 만드신 강좌를 참고 하도록 한다.
( Remote Xdebug 메커니즘 : http://opentutorials.org/course/692/3758 )

나도 생활코딩 강좌를 보고 생각을 정리할겸 간단하게 그려보았다.

php에서 xdebug를 사용하기 위해서는 크게 3가지 단계가 필요하다.

1. 서버측 php.ini에서 xdebug 사용 설정
2. 개발 IDE XDebug 사용 설정(플러그인 같은)
3. 브라우저 XDebug 확장 프로그램 설치

1. php.ini 수정

 php.ini 파일을 열어 아래의 부분을 찾고, 문장 첫줄에 있는 주석(;)을 제거하고, 저장 후 아파치를 재시작 한다.

[XDebug]
 zend_extension = "D:\zSever\xampp\php\ext\php_xdebug.dll"
 xdebug.profiler_append = 0
 xdebug.profiler_enable = 1
 xdebug.profiler_enable_trigger = 0
 xdebug.profiler_output_dir = "D:\zSever\xampp\tmp"
 xdebug.profiler_output_name = "cachegrind.out.%t-%s"
 xdebug.remote_enable = On
 xdebug.remote_handler = "dbgp"
 xdebug.remote_host = "127.0.0.1"
 xdebug.remote_port = 9000
 xdebug.trace_output_dir = "D:\zSever\xampp\tmp"

2. 개발 IDE 플러그인

 현재 Sublime Text2를 사용하고 있기 때문에 pci(Package Controll Installer)를 이용하여 'SublimeXdebug' 플러그인을 설치 한다.

https://github.com/Kindari/SublimeXdebug

3. 브라우저 XDebug 확장 프로그램 설치

 파이어폭스를 기준으로 'easy Xdebug' 확장 기능을 설치 한다. (크롬은 xdebug helper)
설치 후 에 파이어폭스 상단 탭 근처에서 마우스 우클릭 후 '부가기능모음' 버튼을 활성화 하면, 브라우저 우측 하단에 벌레가 나타난다.ㅋㅋㅋㅋ

 이제 모든 구성은 끝났고 실제로 사용하는 일만 남았다. ㅎㅎ
글로 설명하는 것보다 실제로 사용하는 모습을 남기고 싶지만 유투브에 딱 알맞는 영상을 있어서 그걸루 대체하기로~

http://www.youtube.com/watch?v=9bV0_gk0fkk

Read More

라즈베리 파이(Raspberry pi) - XBMC 설치 (Openelec)

 HTPC 라는 용어도 XBMC라는 프로그램도 사실 이번에 라즈베리파이를 때문에 알게 되었다.

HTPC는 홈시어터 PC (home theater PC)라는 의미이고, XBMC는 HTPC에 최적화 된 프로그램이라고 생각하면 되겠다.

XBMC에 대한 소개는 'XBMC 사용자 모임'의 소개글을 참고.

사전 준비 단계

sd 카드 포맷

SD Formatter 4.0 for SD/SDHC/SDXC
https://www.sdcard.org/downloads/formatter_4/

win32diskimager 다운로드 설치

http://sourceforge.net/projects/win32diskimager/

openelec 다운로드

http://openelec.thestateofme.com/official_images/

Openelec 설치 단계

준비 단계만 완료 되면 설치는 너무 간단하기 때문에 아래의 링크를 참고하여 그대로 쭉 따라하면 된다.
(주의 깊게 따라할 정도도 아님..)
http://www.rasplay.org/?p=206
http://squirrelhosting.co.uk/hosting-blog/hosting-blog-info.php?id=9

XBMC 설정

 편의를 위해 변경해야 하는 설정들이 있나 찾아 봤으나, 언어와 폰트 이외에는 특별하게 꼭 변경해야 하는 설정 항목은 없는 듯 하다.
Openelec을 기준으로 언어를 변경하는 방법은 아래의 순서를 따라하면 된다.

* 스샷 출처 : http://blog.naver.com/PostView.nhn?blogId=kyb016&logNo=60171977936

폰트 변경

System > Setting > Appearance > Skin >> Fonts >>> Arial based

언어 변경

System > Setting > Appearance > International >> Language > Korean

외장 하드 연결

 라즈베리에 USB 외장하드를 연결하면 XBMC에서 바로 인식하고 내부 컨텐츠를 읽어 올 수 있다.

XBMC 원격 컨트롤 앱(아이폰)

 XBMC 정말 편리하고, 강력한 미디어 프로그램이지만 거실에서 영화 한편 보겠다고 마우스랑 키보드까지 대동하는건 여간 불편한게 아니다.

 XBMC 아이폰 공식앱을 다운 받아 사용해 보았는데 정말 괜찮다!! 생각보다 반응 속도가 빨라서 앞으로 많이 사용 할 것 같다.

https://itunes.apple.com/us/app/unofficial-official-xbmc-remote/id520480364?ls=1&mt=8

Read More

소켓(Soket) 통신이란?

Node.js를 공부하면서 Soket.io 사용하는 부분을 배우기 전에 간단하게 소켓 통신에 대한 개념에 대해 조사를 해 보았다.

잘 맞는 것인지는 모르겠지만 조사를 하는 과정에서 추상적이지만 개념정도는 정립이 된 것 같다.

UDP는 예전에 친구들과 PC방에서 편먹고 스타크래프트1 할 때 들어가던 메뉴 였던 것으로 기억하는데 이제야 뭔지 알게 되었다.ㅋㅋ

소켓 통신

네트워크를 통하여 서로 다른 컴퓨터에서 수행되는 프로세스간의 통신 채널이다.

소켓통신에는 신뢰성 프로토콜인 TCP(Transfer Control Protocol)와 비신뢰성 프로토콜인 UDP(User Datagram Protocol)가 있다.

TCP 통신의 개념

TCP 통신은 쉽게 전화 통화하는 방식으로 동작한다. 상대방의 전화번호를 알고 있어야 전화를 걸 수 있듯이 상대방의 IP 주소와 포트를 알고 있어야 연결을 할 수 있다. 

서버가 응답을 받아주지 않으면 계속적으로 요청을 하게 된다. 어느 시점에서 요청을 포기하게 될 수도 있다.

이처럼 TCP 통신은 계속적으로 소켓을 통해 데이터를 주고 받을 수 있는 양방향 통신이 가능하다. 또한 데이터를 받지 못했을 때 다시 요청하는 메커니즘을 가지고 있다.

UDP 통신의 개념

상대방과 연결되어 있는 개념이 아니다. 소켓을 개설하고 그냥 데이터를 보내는 개념이다. 

이는 편지를 보내는 방식과 유사하다. 편지를 보냈더라도 편지를 받는 사람은 편지함을 열어보기 전에는 편지가 왔는지 안왔는지 알 수 없다. 

따라서 UDP 통신은 UDP 소켓을 통해서 자신의 포트를 열어보기 전에는 데이터가 왔는지 오지 않았는지 알 수 없다.

TCP와 UDP의 비교

TCP 통신은 데이터를 주고 받을 때 데이터가 도착했는지 여부를 내부적으로 확인한다.

만약 데이터가 오지 않았다면 재요청을 하는 메커니즘을 가지고 있어 양방향으로 연결 되어 있지만 이러한 확인 절차로 인해 속도면에서 느리다. 

하지만 UDP는 이러한 확인 절차를 거치지 않고 계속적으로 데이터를 전송하기만 하기 때문에 속도면에서 훨씬 빠르다.

속도면에서는 UDP가 빠르지만 UDP는 데이터가 도착했는지 알 수 었는 비신뢰성 프로토콜이다.

Read More