├── README.md
├── coding-protocol
    ├── README.md
    └── tab2space
├── css
    ├── inuit.css
    │   ├── README.md
    │   ├── modules-1.jpg
    │   ├── modules-2.jpg
    │   ├── pt1.md
    │   └── pt2.md
    ├── oocss
    │   └── 2013-04-24-oocss.md
    └── smacss
    │   ├── 2013-02-08-pt1.md
    │   ├── 2013-02-22-pt2.md
    │   ├── 2013-03-11-pt3.md
    │   ├── 2013-03-14-pt4.md
    │   └── README.md
├── epub
    └── 2013-10-10 EPUB 제작시 알아둬야 할 점.md
├── git
    ├── 01-git-basic.md
    ├── 02-remote-repo,checkout.md
    ├── 03-branch,conflict.md
    ├── README.md
    └── memo.md
├── javascript
    └── maintainable_javascript
    │   └── 2013-04-26-turtle_book.md
├── php
    ├── 2013- 11-16 PHP와 UTF-8.md
    ├── 2013-08-28 암호 저장 ― phpass 라이브러리를 이용해 암호 해시와 비교하자.md
    ├── 2013-09-02 PHP 환경.md
    └── 2013-10-03 이메일 보내기.md
└── process
    └── TDD
        ├── pt1.md
        └── pt2.md


/README.md:
--------------------------------------------------------------------------------
1 | - Date: 2013-09-02 16:14:31
2 | 
3 | 레프트21 웹개발팀 개발 자료 축적/공유 공간
4 | ================================
5 | 
6 | 레프트21 웹개발팀의 개발 정보 축적 공간입니다. 자료를 체계적으로 축적하는 데 github가 도움이 될 거라 생각했습니다. 
7 | 
8 | 물론 다른 분들께도 우리 경험과 공부 결과를 공유하고 도움이 되고자 만든 것이기도 합니다.


--------------------------------------------------------------------------------
/coding-protocol/README.md:
--------------------------------------------------------------------------------
 1 | - Date: 2013-09-02 16:14:31
 2 | 
 3 | LEFT21 개발팀 코드 작성 규약
 4 | =======================
 5 | 
 6 | ## 작명
 7 | 
 8 | * PHP, js 단어 띄어쓰기는 `_`로 한다. CSS는 `-`로. CamelCase는 전혀 사용하지 않는다. PHP 클래스도.
 9 | * CSS 레이아웃 클래스는 `l-` 접두어를 붙인다.
10 | * CSS 모듈 클래스는 접두어 없이 BEM 표기법을 따른다.
11 | * CSS 상태 클래스는 `is-` 접두어를 붙인다.
12 | * js에서 jQuery 객체를 담은 변수는 앞에 `$`를 붙인다.
13 | * 함수든 변수든 이름은 단어 세 개를 넘기지 않을 것을 권장한다.
14 | * 이름은 가급적 영어로 지을 것을 권장한다. 너무 복잡한 경우에만 한글로 짓는 것을 허용한다.
15 | * 이름을 영어로 지을 때는 정확한 단어로 짓는다. (모를시 원웅에게 문의할 것!)
16 | * 한글로 이름을 지을 때도 `get_`, `is_` 등의 접두어는 맨 앞에 영어로 넣는다. (자동완성을 위해.)
17 | * 데이터를 가져오는 함수는 `get_`으로 시작한다.
18 | * 상태를 검사하는 함수는 `is_` 혹은 `has_`로 시작한다.
19 | * 파일명에서 단어 구분은 `-`로 한다.
20 | * 실제 스타일에 관여하지 않고 js용으로만 사용하는 선택자는, `js-` 접두어를 붙인다. (예외는 등장했을 때 더 논의)
21 | * 변수명에서 복수인 경우 복수형을 우선 사용하고, 이름이 겹치면 타입을 명시한다. (`_str`, `_arr`)
22 | * 약어는 사회적으로 통용되는 것만 사용하고 따로 만들어서 사용하지 않는다.
23 | * `$i`, `$j`, `$tmp`, `$temp` 등은 알아서 쓴다.
24 | * 파일 구조는 폴더로만 구분하고 접두어로 구분하지 않는다. 접두어는 내용에 관련한 것만.
25 | * 파일 작명은 다음을 기본으로 한다.
26 |     * person-detail.php
27 |     * person-manage.php (입력/수정 통합)
28 |     * person-action.php
29 |     * person-list.php
30 |     * person-delete.php
31 | * 함수 CRUD 작명은 다음을 기본으로 한다.
32 |     * get_person
33 |     * insert_person
34 |     * update_person
35 |     * delete_person
36 | 
37 | ## 코드 포맷
38 | 
39 | * `{}`는 절대로 생략하지 않는다.
40 | * 들여쓰기는 모든 경우 공백 4칸으로 한다. (물론 Sass는 안 되지만;;)
41 | * 모든 언어에서 한 줄은 80자로 하고, 넘어가는 경우 줄이 끝나지 않았더라도 (ex. HTML 여는 태그, SQL문) 엔터값을 넣는다. 한 줄이 끝나지 않은 채 넘어간 두 번째 줄은 들여쓰기를 두 번 더 한다.
42 | * CSS는 선택자와 속성을 한 줄에 절대로 쓰지 않으며, 한 줄에는 속성 하나만 들어가야 한다.
43 | * 모든 CSS 선택자는 2단계를 넘기지 않는다.
44 | * 모든 `{`는 줄을 띄우지 않고 한 줄에 쓴다.
45 | * 배열은 여러 줄로 쓴다. 닫는 괄호는 시작 부분과 들여쓰기를 맞추고, 배열 안의 요소들은 들여쓰기를 한 번만 더 한다.(아주 짧은 경우엔 예외)
46 | * 한 줄 주석(`//`)을 시작할 때는 무조건 바로 위의 한 줄을 띄운다.
47 | * 여러 줄 주석은 두 번째 줄부터 앞에 ` * `을 붙인다.
48 | * `switch`문에서 default가 없는 경우엔 주석으로 명시해 준다.
49 | * `switch`문에서 안쪽은 추가로 더 들여쓰기 한다.
50 | * PHP 안에서 HTML을 출력해야 할 때는 `echo`를 쓰지 말고 그냥 PHP 태그를 닫고 쓴다.
51 | 
52 | ## 기타 코딩 규칙
53 | 
54 | * CSS에서 선택자로 ID 사용을 금지한다.
55 | * 주석 코드 태그는 TODO(구현할 것)와 FIXME(고칠 것)를 사용한다. 
56 | * 주석에는 날짜(yyyy-mm-dd)와 작성자를 쓴다. 
57 | * jQuery에서 `$(document).ready(function(){})`를 사용하고 `$(funciton(){})`는 사용하지 않는다.
58 | * HTML 안에는 `style`과 `script`를 코딩하지 않는다.
59 | * `onclick` 등의 요소를 사용하지 않는다.
60 | * js 전역 변수는 하나만 만들어 본다. (객체로 만들어서 그 안에 다 때려 넣는다.)
61 | * `$_POST`와 `$_GET` 안에 담긴 변수를 웬만하면 밖으로 꺼내서 사용하지 않는다. 변수의 출처를 알기 위해서다. (특히 `extract`는 사용하지 않는다.)
62 | * CSS와 JS는 한 파일로 유지한다.
63 | * PHP 함수 안에서 `$_POST`와 `$_GET`을 사용하지 않는다. 필요하면 인자로 받아서 쓴다.
64 | * js 함수 안에서 `event` 객체를 사용하지 않는다. 필요하면 인자로 받아서 쓴다.
65 | * 모든 함수에 PHPDoc 주석을 단다.
66 | 
67 | 
68 | 
69 | 
70 | 
71 | 
72 | 
73 | 
74 | 
75 | 


--------------------------------------------------------------------------------
/coding-protocol/tab2space:
--------------------------------------------------------------------------------
1 | #!/bin/sh
2 | 
3 | for s in php js css html; do
4 | 	for f in $(find $1 -name "*.$s"); do
5 | 		expand --tab=4 $f > $f.notab
6 | 		mv $f.notab $f
7 | 	done;
8 | done;
9 | 


--------------------------------------------------------------------------------
/css/inuit.css/README.md:
--------------------------------------------------------------------------------
 1 | - Date: 2013-09-02 16:14:31
 2 | 
 3 | inuit.css CSS 프레임워크를 사용하기로 결정하다
 4 | =======================================
 5 | 
 6 | CSS 생산성을 높일 방법을 고민해서 나온 결론 두 가지는 이거였다.
 7 | 
 8 | 1. CSS 유지보수성을 향상시키기 위한 학습을 한다.
 9 | 2. 다들, CSS 프레임워크를 사용하라고 하는데, 그래 어디 한 번 사용해 보자.
10 | 
11 | 프레임워크를 고르는 기준은 그동안 여기저기서 읽은 것을 바탕으로 이렇게 정했다.
12 | 
13 | 1. 지속적으로 유지될 프레임워크를 고르자.
14 | 2. OOCSS에 기반한 CSS 프레임워크를 고르자.
15 | 3. 혹시나 이 프레임워크가 나중에 망하더라도, 지금 버전으로 앞으로 상당 기간을 커버 가능한 그런 프레임워크를 고르자.
16 | 
17 | 그래서 고른 게 [inuit.css](http://inuitcss.com/)다. 좀 허무한 이야기지만, OOCSS에 기반한 CSS 프레임워크는 두 개밖에 없었다. inuit.css를 제외하면 [Cascade Framework](http://jslegers.github.io/cascadeframework/)라는 놈이 있었는데, inuit.css를 사용하기로 했다. Cascade Framework는 너무 신생이라서 안정성에 대한 믿음이 없었고, 우리가 필요한 것에 비해 기능이 너무 많다는 생각도 들었다. 
18 | 
19 | 그러나 Cascade Framework는 IE6도 지원한다는 장점이 있다. 약간의 디자인과 자체의 아이콘 폰트도 제공한다. (inuit.css는 디자인을 **전혀** 제공하지 않는다.) inuit.css는 [4.1.5버전](https://github.com/csswizardry/inuit.css/archive/v4.1.5.zip)이 IE7을 지원하는 마지막 버전이다. [현재 버전은 5.0](http://inuitcss.com//2013/03/inuit-css-v5.0)이다. 그래서 우리도 v4.1.5를 사용하며, 여기서 탐구 대상으로 삼는 것도 v4.1.5다. 한국은 2013년 5월 현재를 기준으로 여전히 IE7 비율이 10%를 넘기 때문이다.
20 | 
21 | 여튼간에, CSS 생산성을 높이기 위해 선택하고 공부하기 시작한 프레임워크가 바로 inuit.css다.


--------------------------------------------------------------------------------
/css/inuit.css/modules-1.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/left21wm/dev-sharing/12f05f63d57a0bbb492f49bf641ac974042ea6cc/css/inuit.css/modules-1.jpg


--------------------------------------------------------------------------------
/css/inuit.css/modules-2.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/left21wm/dev-sharing/12f05f63d57a0bbb492f49bf641ac974042ea6cc/css/inuit.css/modules-2.jpg


--------------------------------------------------------------------------------
/css/inuit.css/pt1.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | 기본 파일 구조
  4 | 
  5 | 	\
  6 | 	 + watch.sh
  7 | 	 + _vars.scss
  8 | 	 + your-project.scss
  9 | 	 + inuit.css
 10 | 		\+ inuit.scss
 11 | 		 + partials
 12 | 			\+ base
 13 | 			 + generic
 14 | 			 + objects
 15 | Generic
 16 | --------
 17 | 
 18 | ### Mixins ###
 19 | 
 20 | 다음 믹신은 수직적 리듬을 일정하게 유지하기 위한 것이다. 폰트 크기(`$font-size`)를 넘기면, 줄 높이를 언제나 `$base-line-height`의 정수배가 되도록 계산한다.
 21 | 
 22 | 	@mixin font-size($font-size){
 23 | 	    font-size:$font-size +px;
 24 | 	    font-size:$font-size / $base-font-size +rem;
 25 | 	    line-height:ceil($font-size / $base-line-height) * ($base-line-height / $font-size);
 26 | 	}
 27 | 
 28 | 그 다음엔 제조사별 접두어와 CSS 애니메이션을 위한 믹신이 나온다. 다음과 같이 쓰면 된다.
 29 | 
 30 | 	@include vendor($property, $value);
 31 | 	@include keyframe($animation-name);
 32 | 
 33 | 마지막으로 말줄임표를 위한 믹신이다. 너비를 인수로 넘겨주면 된다. 
 34 | 
 35 | 	@include truncate($truncation-boundary);
 36 | 
 37 | ### Reset ###
 38 | 
 39 | inuit.css는 리셋 CSS를 차용했지만, 너무 고지식한 리셋은 없애버렸다. 그런 예로는: 
 40 | 
 41 | - 목록 스타일 리셋
 42 | - `big`, `center`, `acronym`처럼 폐기될 요소들의 리셋
 43 | - `fieldset` 테두리 리셋
 44 | - 폰트 굵기 및 스타일 리셋
 45 | - `u`와 `a`에서 밑줄 제거
 46 | 
 47 | 기본 스타일을 재정의한 것도 있다.
 48 | 
 49 | - 양식 요소에서 글꼴을 상속하게 함
 50 | - `img`의 글꼴 스타일을 지정해서, 이미지 로드 실패시 나타나는 `alt` 텍스트가 본문과 구별되게끔 함
 51 | - 그 밖에 텍스트 관련 요소들
 52 | 
 53 | 저자는 빈번히 덮어쓰는 리셋은 제거할 것을 촉구한다. 
 54 | 
 55 | ### Clearfix ###
 56 | 
 57 | inuit.css에서는 "micro clearfix"라는 방법을 쓴다. CSS로 요소의 앞과 뒤에 `display`가 `table`인 가짜 요소를 만들어서 위쪽 여백이 접히는 것을 막고, 요소 뒤쪽을 `clear`해주는 방식이다. Firefox 3.5 이상, Safari 4 이상, Chrome, Opera 9 이상, IE 6 이상에서 모두 지원된다. 다만 IE6, 7에서  hasLayout 프로퍼티를 켜고 부동(`float`) 요소를 포함하게 하려면 `*zoom: 1;`을 선언해야 한다. 
 58 | 
 59 | inuit.css에서는 `cf` 클래스를 를 일일이 붙여주기 보다는, 그 클래스를 확장하라고 한다.
 60 | 
 61 | (익스플로러에서는 요소마다 hasLayout이라는 프로퍼티가 있어서 이것이 `true`이면 조상 요소에 의존하지 않고, 독자적으로 자신과 후손 요소들의 크기와 위치를 정하고, `false`면 조상 요소에 의존한다고 한다. 마이크로소프트는 "성능과 단순함"을 위해 이 프로퍼티를 도입했다고 하지만, 이것은 오히려 상황을 복잡하게 만들었다고 한다. `hasLayout`이 `false`인 `div`에 부동 요소가 있거나 절대 위치로 위치를 잡은 요소가 있으면, 내용이 사라지거나 이상하게 배치되거나, 창을 움직이거나 스크롤할 때 제대로 렌더링이 되지 않는 등 다양한 문제가 발생한다고 한다. 이런 문제는 `hasLayout`을 켜는 CSS 규칙을 선언함으로써 해결할 수 있다고 하는데, 그 중 하나가 `zoom`이다. 참고: <http://reference.sitepoint.com/css/haslayout>)
 62 | 
 63 | (여백 접힘이란, 두 요소의 수직 여백이 맞닿아 있을 때에는 더 큰 여백이 살아남고, 작은 여백은 0으로 접힌다는 것이다. 부모와 자식 요소일 경우에도 여백이 맞닿기만 하면 모두 적용된다. 심이나 테두리를 넣으면 여백이 접히는 일을 막을 수 있다.(그런데 익스플로러 7까지는 `hasLayout` 프로퍼티가 있으면 여백이 아예 접히지 않았다고 한다). 다만 작은 여백이 음수일 경우에는 두 여백을 둘 다 적용한다. 부동 요소, 절대 위치 요소, 줄글-덩어리 요소, `overflow`가 `visible`이 아닌 요소, 루트 요소에서는 여백 접힘이 발생하지 않는다. 참고 <http://reference.sitepoint.com/css/collapsingmargins>
 64 | 
 65 | ### Shared ###
 66 | 
 67 | 여기에는 몇몇 요소들과 객체의 여백이 지정돼 있다.
 68 | 
 69 | 여기서 저자는 한 쪽 방향으로만(`margin-bottom`과 `margin-left`로만) 여백을 지정한다. 한 쪽 방향으로만 지정할 때의 이점은
 70 | 
 71 | - 수직적 리듬을 규정하기 더 쉽다
 72 | - 컴포넌트를 없애거나 이동시켜도 일정한 여백이 보장된다.
 73 | - 따라서 컴포넌트들이 나열되는 순서에 종속되지 않게 된다. 
 74 | - 여백 접힘을 신경쓰지 않아도 된다. 
 75 | 
 76 | 여기서 지정된 여백의 값은 모두 $base-spacing-unit이며, $base-font-size를 기준으로 한 `rem` 값을 쓴다. 기본 여백이 지정된 요소와 객체들은 다음과 같다. 
 77 | 
 78 | - margin-bottom=$base-spacing-unit
 79 | 	- `h1`~`6`, `hgroup`, `ul`, `ol`, `dl`, `blockquote`,
 80 | 	   `p`, `address`, `table`, `fieldset`, `figure`, `pre`
 81 | 	- `.media`, `.island`, `.islet`
 82 | 	- `%sass-margin-bottom`
 83 | 	- `.islet & .islet`(절반)
 84 | 	- `.landmark`(2배)
 85 | 	- `hr`(줄의 두께인 2픽셀만큼만 뺌)
 86 | - margin-left=$base-spacing-unit: `ul`, `ol`, `dd`
 87 | 
 88 | Base
 89 | ----
 90 | 
 91 | ### Main ###
 92 | 
 93 | html요소의 스타일이다. $base-font-size가 여기에 적용된다.
 94 | 
 95 | ### Headings ###
 96 | 
 97 | 저자는 니콜 설리반의 아이디어를 따라 제목에 해당하는 클래스를 모두 만든다. 그렇게 하면 사이드 바에 있는 `h2`가 `h3`처럼 보이게 하고 싶다거나, 푸터에 있는 `h3`가 `h4`처럼 보이게 하고 싶을 때 코드를 줄일 수 있다고 한다. 제목 클래스의 이름은 그리스식 알파벳에서 따왔다.
 98 | 
 99 | 	h1,.alpha   {}
100 | 	h2,.beta    {}
101 | 	h3,.gamma   {}
102 | 	h4,.delta   {}
103 | 	h5,.epsilon {}
104 | 	h6,.zeta    {}
105 | 
106 | 각 제목의 크기는 `$h1-size`...`$h2-size`이라는 변수로 설정하며, inuit.css는 이 값을 `font-size`라는 믹신의 인수로 넘긴다. 
107 | 
108 | `.hN` 클래스는 `hgroup` 요소나 수준이 딱히 정해지지 않은 제목 요소에 사용한다. 
109 | 
110 | 	<hgroup>
111 | 		<h1 class="hN>inuit.css</h1>
112 | 		<h2 class="hN>Best Framework. Ever!</h2>
113 | 	</hgroup>
114 | 
115 | `.giga`, `.mega`, `.kilo`는 기존 제목 수준(`h1`...`h6`, `.alpha`...`.zeta`)에서 벗어나는 예외적인 커다란 제목에 쓰는 클래스다. 각각의 크기는 `$giga-size`, `$mega-size`, `$kilo-size`라는 변수로 설정하고, `font-size`라는 믹신으로 넘어간다. 
116 | 
117 | ### Paragraph ###
118 | 
119 | 기사 첫 머리에 들어가는 요점이 들어간 한 두 문장짜리 문단을 Lede(Lead와 발음이 같고, 활판 인쇄에 쓰이는 Lead와 구분하기 위해 스펠링을 바꿨다고 한다)라고 한다. `.lede`나 `.lead`는 그런 문단에 쓰이는 클래스이며, 일반 문단보다 글꼴 크기가 12.5퍼센트 크다.
120 | 
121 | ### Small Print ###
122 | 
123 | 여기 있는 규칙들은 작은 글씨에 적용한다. `small` 요소는 `font-size`의 단위가 `em`이어서 언제나 부모 요소보다 글꼴이 작다. `.giga`, `.mega`, `.kilo`처럼 예외적인 글꼴(이번에는 예외적으로 작은 경우다)은 `.smallprint`,`.milli`,(글꼴 크기 변수 `$milli-size`)`.micro`(`$micro-size`)을 쓴다. 
124 | 
125 | ### Quote ###
126 | 
127 | 인용 관련 요소인 `q`와 `blockquote`에 적용되는 규칙들이 여기서 선언된다. `q`로 둘러싸면 홅따옴표로 둘러싸고, 한번 더 `q` 둘러싸면 쌍따옴표로 둘러싼다. inuit.css에서 기본 설정을 덮어쓰지 않고 `q`로 쌍따옴표를 붙이는 방법은 없는듯하다.
128 | 
129 | `blockquote` 요소를 쓰면 쌍따옴표를 쳐준다. 
130 | 
131 |    <blockquote>
132 |        <p>Insanity: doing the same thing over and over again and expecting
133 |        different results.</p>
134 |        <b class=source>Albert Einstein</b>
135 |    </blockquote>
136 | 
137 | `.source` 클래스는 "—"를 본문 앞에 붙여준다. `p`요소의 본문 첫줄은 쌍따옴표 너비만큼 내어쓴다(음수로 지정한 들여쓰기, `text-indent`). `p`요소에 자동으로 붙는 쌍따옴표는 요소 덩어리가 아니라 그 안에 있는 텍스트에 자동으로 붙는다. 이것은 `:last-of-type` 선택자를 활용한 것으로 IE8까지는 지원이 안된다고 한다.
138 | 
139 | ### Code ###
140 | 
141 | 코드를 인용하는 스타일에 대한 것인데, 당장은 쓸 일이 없을 것이므로 생략하겠다. 선언된 클래스: `.code-comment`, `.numbered`, `.numbered__numberes`, `.numbered__numberes code`
142 | 
143 | ### Link ###
144 | 
145 | inuit.css는 기본적으로 링크에서 밑줄을 없앴고, 마우스를 올리면 밑줄이 생기게 했다. 저자는 마우스를 올릴 때 부정적 반응(뭔가 없어진다거나, 더 흐려진다거나 하는 등의 반응)이 아니라 긍정적 반응(뭔가 생긴다거나, 더 진해진다거나 하는 등)을 보이도록 해야 한다고 주장한다.
146 | 
147 | 다만 이렇게 할 경우 색맹에게는 링크가 구별이 잘 안 될 수도 있다고 말하며, 이럴 때를 대비해서 링크와 본문의 색상 대비를 높이라고 주문한다.
148 | 
149 | `.current`는 링크 목록에서 현재 페이지를 나타낼 때 쓰는 클래스이며, 밑줄이 들어가 있고, 마우스를 올려도 커서는 `text`로 유지된다.
150 | 
151 | ### Image ###
152 | 
153 | `img` 요소는 너비가 `100%`를 넘지 않게끔 돼 있다. 
154 | 
155 | 	img{
156 | 	    max-width:100%;
157 | 	    height:auto;
158 | 	}
159 | 	figure > img{
160 | 	    display:block; /* 원래는 inline이다 */
161 | 	}
162 | 
163 | ### List ###
164 | 
165 | 중첩된 목록은 수직 여백(inuit.css에서는 `margin-bottom`)을 없앴다. 
166 | 
167 | ### Table ###
168 | 
169 | 기본 표 스타일은 다음과 같다. 
170 | 
171 | 	table{ width:100%; }
172 | 	th,
173 | 	td{
174 | 	    padding:$base-spacing-unit / 4 +px;
175 | 	    @media screen and (min-width:480px){
176 | 	        padding:$half-spacing-unit +px;
177 | 	    }
178 | 	    text-align:left;
179 | 	}
180 | 	
181 | 	[colspan]{ text-align:center; }
182 | 	[colspan="1"]{ text-align:left; }
183 | 	[rowspan]{ vertical-align:middle; }
184 | 	[rowspan="1"]{ vertical-align:top; }
185 |  	.numerical{ text-align:right; }
186 | 	
187 | 	.t5     { width: 5% }
188 | 	.t10    { width:10% }
189 | 	.t12    { width:12.5% }     /* 1/8 */
190 | 	.t15    { width:15% }
191 | 	.t20    { width:20% }
192 | 	.t25    { width:25% }       /* 1/4 */
193 | 	.t30    { width:30% }
194 | 	.t33    { width:33.333% }   /* 1/3 */
195 | 	.t35    { width:35% }
196 | 	.t37    { width:37.5% }     /* 3/8 */
197 | 	.t40    { width:40% }
198 | 	.t45    { width:45% }
199 | 	.t50    { width:50% }       /* 1/2 */
200 | 	.t55    { width:55% }
201 | 	.t60    { width:60% }
202 | 	.t62    { width:62.5% }     /* 5/8 */
203 | 	.t65    { width:65% }
204 | 	.t66    { width:66.666% }   /* 2/3 */
205 | 	.t70    { width:70% }
206 | 	.t75    { width:75% }       /* 3/4*/
207 | 	.t80    { width:80% }
208 | 	.t85    { width:85% }
209 | 	.t87    { width:87.5% }     /* 7/8 */
210 | 	.t90    { width:90% }
211 | 	.t95    { width:95% }
212 | 
213 | 여기에서 확장되는 테이블용 클래스는 다음과 같다.
214 | 
215 | - `.table--bordered`: 테두리 있는 표
216 | - `.table--striped`: 아무 스타일이 없는 표
217 | - `.table--data`: 데이터용 표(글꼴 크기가 2/3다).
218 | 
219 | ### Forms ###
220 | 
221 | 1. `input[type=text]`나 `input[type=email]`, `input[type=password]` 등은 `type` 어트리뷰트를 불문하고 모두 텍스트 입력란으로 나온다. 그래서 텍스트 입력란은 `[type]` 선택자가 아니라, `.text-input`이라는 클래스로 스타일을 매긴다. 
222 | 2. 여러 필드는 목록으로 처리한다. 하나의 항목(`li` 요소)에는 `label` 요소(`display`는 `block`임)와 `input` 요소가 차례대로 들어간다. 
223 | 3. `label`과 동일한 효과를 내는 `.label`이라는 클래스가 있어서, `label` 요소를 쓰기에는 부적절하지만 라벨의 기능을 하는 요소에 적용할 수 있다. (가령 4지선다 문항에서, 질문에 해당하는 부분)
224 | 4. 체크리스트 목록은 `.check-list` 안에 넣는다. 
225 | 5. "내 이름은 __입니다"와 같은 구어체 입력란의 경우에는 라벨을 `.spoken-form`의 자식 요소로 둔다. 그럴 경우 라벨은 `block`이 아니라 `inline-block`이 된다. 
226 | 6. `.additional`: 라벨에 들어가는 추가적인 도움말에 적용한다.
227 | 7. `.extra-help`: 앞에 나오는 `input` 요소가 포커스 되거나 활성화되면 나타나는 도움말 메시지
228 | 
229 | Objects
230 | -------
231 | 
232 | ### grid ###
233 | 
234 | 격자는 기본적으로 `.grid-wrapper`(줄여서 `.gw`)로 둘러싼다. 기본적으로는 왼쪽에서 오른쪽으로 격자를 채우지만, `.grid-wrapper--rev`(줄여서 `.gw--rev`)를 덧붙이면 오른쪽에서 왼쪽으로 격자를 채운다. 
235 | 
236 | ### flexbox ###
237 | 
238 | Flexbox는 향후 CSS에 포함될 레이아웃 모드이며, `display`가 `flexbox`인 다양하게 배치할 수 있다(가로, 세로, 가운데 정렬(세로로도), 공간의 균등 분할, 심지어 순서도 바꿀 수 있다고도 한다). 
239 | 
240 | 다만 inuit.css에서는 그냥 `display`가 `table`인 요소이며, 이 모듈 안에 들어간 요소들은 공간을 균등하게 분배 받는다.
241 | 
242 | ### text-cols ###
243 | 
244 | 컬럼을 구현한 모듈인데, 익스플로러는 전혀 지원하지 못하는 듯하다. 
245 | 
246 | ### nav ###
247 | 


--------------------------------------------------------------------------------
/css/inuit.css/pt2.md:
--------------------------------------------------------------------------------
 1 | - Date: 2013-09-02 16:14:31
 2 | 
 3 | 보조 클래스
 4 | --------------
 5 | 
 6 | 	1   .one-whole
 7 | 	
 8 | 	1/2 .one-half 
 9 | 	
10 | 	1/3 .one-third
11 | 	2/3 .two-thirds
12 | 	
13 | 	1/4 .one-quarter
14 | 	2/4 .two-quarters
15 | 	3/4 .three-quarters
16 | 	
17 | 	1/5 .one-fifth
18 | 	2/5 .two-fifths
19 | 	3/5 .three-fifths
20 | 	4/5 .four-fifths
21 | 	
22 | 	1/6 .one-sixth
23 | 	2/6 .two-sixths
24 | 	3/6 .three-sixths
25 | 	4/6 .four-sixths
26 | 	5/6 .five-sixths
27 | 	
28 | 	1/8 .one-eighth
29 | 	2/8 .two-eighths
30 | 	3/8 .three-eighths
31 | 	4/8 .four-eighths
32 | 	5/8 .five-eighths
33 | 	6/8 .six-eighths
34 | 	7/8 .seven-eighths
35 | 	
36 | 	1/10 .one-tenth
37 | 	2/10 .two-tenths
38 | 	3/10 .three-tenths
39 | 	4/10 .four-tenths
40 | 	5/10 .five-tenths
41 | 	6/10 .six-tenths
42 | 	7/10 .seven-tenths
43 | 	8/10 .eight-tenths
44 | 	9/10 .nine-tenths
45 | 	
46 | 	1/12 .one-twelfth
47 | 	2/12 .two-twelfths
48 | 	3/12 .three-twelfths
49 | 	4/12 .four-twelfths
50 | 	5/12 .five-twelfths
51 | 	6/12 .six-twelfths
52 | 	7/12 .seven-twelfths
53 | 	8/12 .eight-twelfths
54 | 	9/12 .nine-twelfths
55 | 	10/12 .ten-twelfths
56 | 	11/12 .eleven-twelfths
57 | 	
58 | 	pull--
59 | 	push--
60 | 	
61 | 	.brand
62 | 	.brand-face
63 | 	.brand-color
64 | 
65 | - .fr: float right
66 | - .fl: float left
67 | - .text-center
68 | - .full-bleed: .island의 내용을 꽉차게
69 | - .informative: help 커서
70 | - .proceed: "더 보기"용 오른쪽 정렬
71 | - .go:after: 뒤에 "»"를 붙여줌 
72 | - .caps: 대문자화
73 | - .accessibility: `display: none`을 쓰지 않고 숨기기
74 | 
75 | 디버그
76 | ------
77 | 
78 | - 황색 경보
79 | 	- 빈 요소
80 | 	- `img` 요소에 `alt` 어트리뷰트가 없는 경우
81 | 	- `a` 요소에 `title` 어트리뷰트가 없는 경우
82 | 	- `a`의 `href`가 `#`이거나 `javascript`를 포함한 경우
83 | 	- `a` 요소에 `target` 어트리뷰트가 있는 경우
84 | 	- `th` 요소에 `scope` 어트리뷰트가 없는 경우
85 | 	- `table`의 새끼 중에(후손 말고) `tr`인 경우
86 | 	- `tbody`가 `tfoot`보다 먼저 오는 경우
87 | 	- 인라인 스타일이 있는 요소
88 | 	- `id`가 있는 요소
89 | - 적색 경보
90 | 	- `ol`,`ul` 속에 `li`가 아닌게 있을 경우
91 | 	- `form` 요소에 `action` 어트리뷰트가 없는 경우
92 | 	- `input` 요소에 `type`이 없는 경우
93 | 	- `textarea`에 `row`와 `cols`가 없는 경우
94 | 	- `input`의 `type`가 `submit`인데 `value`가 없는 경우
95 | 	- `.gw`의 새끼 중에 `.g`가 아닌 녀석이 있는 경우


--------------------------------------------------------------------------------
/css/oocss/2013-04-24-oocss.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | [OOCSS][]
  4 | -----
  5 | 
  6 | 좁은 의미로는 [니콜 설리반][](Nicole Sullivan)이 만든 CSS 프레임워크를 뜻하지만, 이 프레임워크를 만든 접근법을 지칭하는 말로도 쓰인다. 여기서는 접근법을 지칭하겠다. OOCSS는 Object Oriented CSS의 약자이며, 반복되는 시각적 패턴을 독립적인 HTML, CSS, 자바스크립트 코드 조각으로 분리해서 재사용하는 것을 말한다. 이 재사용 되는 코드가 객체 지향 언어에서의 객체에 비유된다.  
  7 | 
  8 | [OOCSS]: https://github.com/stubbornella/oocss/wiki
  9 | [니콜 설리반]: http://www.stubbornella.org/content/
 10 | 
 11 | 2009년에 니콜 설리반은 통상 '좋은 CSS 코딩 방법'으로 통하던 방식, 말뜻에서 벗어나는 요소를 배제하고, 클래스 사용을 자제하며, CSS의 계단식 세계관에 맞춰서 후손 선택자를 사용하라는 통설에 [의문을 제기했다][니콜 설리반 발표].
 12 | 
 13 | [니콜 설리반 발표]: http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/
 14 | 
 15 | 니콜 설리반은 이러한 방법이 선택자 점수(specifity) 경쟁을 일으켜서 CSS를 엉망으로 만든다고 주장했다. 요소 선택자와 ID를 이용해서 스타일을 지정하면, 변종을 만들 때 마다 더 점수가 높은 선택자를 써야하기 때문이다. 가령
 16 | 
 17 | 	h3 {
 18 | 		color: #333;
 19 | 		font-size: 17px;
 20 | 		font-weight: bold;
 21 | 	}
 22 | 	#sidebar h3 {
 23 | 		color: #797979;
 24 | 		font-size: 12px;
 25 | 		font-weight: bold;
 26 | 		border bottom: 1px solid #c5c5c5;
 27 | 		padding-bottom: 5px;
 28 | 	}
 29 | 	#sidebar .account h3 {
 30 | 		color: #333;
 31 | 		font-size: 13px;
 32 | 		font-weight: bold;
 33 | 		background-color:#deeef8;
 34 | 	}
 35 | 	#sidebar .weatherMod h3 {
 36 | 		color: #fff;
 37 | 		text-transform: uppercase; 
 38 | 	}
 39 | 
 40 | 	/* 출처: http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/ */
 41 | 
 42 | 사이드바에 모듈이 추가될 때마다 원하는 모습을 얻기 위해 점수가 높은 선택자를 사용하게 되고, 이런 상황은 모듈이 중첩될 때 더 악화된다. 결국 개발자들이 파이어버그로 코딩을 하게되고 급기야는 원하는 겉모양을 얻을 수 없는 지경에 이른다는 것이다. 게다가 상위 모듈이 선언한 스타일을 덮어쓰느라 코드를 중복하게 된다.
 43 | 
 44 | 니콜 설리반이 밝힌 [OOCSS의 두가지 원칙][]은 다음과 같다.
 45 | 
 46 | 1. __골격과 겉모양의 분리__: 반복되는 시각적 특징은 골격과 별개인 겉모양(skin)으로 분리시켜서, 이것을 결합시키면 다양한 결과물을 얻을 수 있다. 이것은 겉모양을 위한 클래스를 만들고, 필요하다면 겉모양을 위한 요소도 추가할 수 있다는 것을 뜻한다.
 47 | 2. __내용과 내용을 담는 그릇을 분리하기__: 이것은 "위치에 의존하지 않는 스타일"을 뜻한다. 즉 하위 선택자를 되도록 쓰지 않는다는 것을 뜻한다. 예를 들어 `.sidebar h3`와 같은 선택자보다는 `<h3>` 요소에 클래스를 매겨서 `.article-heading`를 선택자로 쓴다는 것이다.
 48 | 
 49 | [OOCSS의 두가지 원칙]: https://github.com/stubbornella/oocss/wiki#two-main-principles-of-oocss
 50 | 
 51 | 이처럼 OOCSS는 대부분 클래스에 의존해서 스타일을 준다. 클래스 이름을 어떻게 지어야하는지에 대해서 니콜 설리반은 다음과 같은 [가이드라인][]을 제시한다. 
 52 | 
 53 | - 간결함: 되도록 짧게
 54 | - 명료함: 스타일과 작동 방식이 고스란히 드러나게
 55 | - 분명한 말뜻(Semantics): 어떻게 생겼는지가 아니라, 어떤 모듈인지
 56 | - 포괄성: 대부분의 사이트에서도 적용되도록
 57 | - 화면 중심성: 종이나 다른 매체가 아닌 모니터를 기준으로
 58 | 
 59 | [가이드라인]: https://github.com/stubbornella/oocss/wiki/FAQ#is-this-semantic-will-i-end-up-with-classes-like-formyellow-or-tinyblueh2
 60 | 
 61 | 스타일을 클래스에 의존하기 때문에 클래스 작명은 CSS 설계의 핵심이 된다. OOCSS는 클래스 이름에서도 말뜻을 분명히 할 것을 권장하기 때문에, 클래스 범벅(classitis)과는 다르다. 다음은 말뜻이 분명치 않은 클래스 이름의 전형적인 사례다.(예시 출처는: <http://takazudo.github.com/presentation-oocss-sass/>)
 62 | 
 63 | 	<a class="blackborder redbg">Twitter</a>
 64 | 	<a class="blackborder bluebg">Facebook</a>
 65 | 
 66 | 전통적인 방법론에서는 이런 클래스를 피하고 최대한 말뜻이 분명하게 할 것을 요구한다.
 67 | 
 68 | 	<a class="twitterbtn">Twitter</a>
 69 | 	<a class="facebookbtn">Facebook</a>
 70 | 
 71 | 그러나 이는 많은 중복을 낳는다.
 72 | 
 73 | 		.twitterbtn {
 74 | 			border: 3px solid #000;
 75 | 			padding: 10px; 20px;
 76 | 			color: #fff;
 77 | 			border-radius: 10px;
 78 | 			background: red;
 79 | 		}
 80 | 	
 81 | 		.facebookbtn {
 82 | 			border: 3px solid #000;
 83 | 			padding: 10px; 20px;
 84 | 			color: #fff;
 85 | 			border-radius: 10px;
 86 | 			background: blue;
 87 | 	}
 88 | 
 89 | OOCSS에서는 말뜻이 분명한 클래스에서 시각적 패턴을 분리한 새로운 클래스를 신설한다. 이렇게 하면 코드를 재사용할 수도 있다. 
 90 | 
 91 | 	<a class="btnbase twitter">Twitter</a>
 92 | 	<a class="btnbase facebook">Facebook</a>
 93 | 
 94 | 	.btnbase {
 95 | 		border: 3px solid #000;
 96 | 		padding: 10px; 20px;
 97 | 		color: #fff;
 98 | 		border-radius: 10px;
 99 | 	}
100 | 
101 | 	.twitter  { background: red;  }
102 | 	.facebook { background: blue; }
103 | 
104 | 그러나 때로는 설리반 자신도 `.md-hd`(medium heading)처럼 말뜻에 표현 방식(presentation)이 포함된 클래스 이름을 쓰기도 한다. 실제로 마이크로포맷을 제외하면 클래스 이름은 검색 엔진이나 스크린리더에게 아무런 의미가 없다. 그래서 [니콜 설리반이 말하듯][니콜 설리반의 입장] 가이드라인이 충돌할 때에는 실용적으로 접근할 수 밖에 없다고 본다. 
105 | 
106 | [니콜 설리반의 입장]: https://github.com/stubbornella/oocss/wiki/FAQ#is-this-semantic-will-i-end-up-with-classes-like-formyellow-or-tinyblueh2
107 | 
108 | OOCSS에서의 객체는 SMACSS에서 말하는 모듈과 비슷하다. 다만 SMACSS에서는 모듈을 구성하는 컴포넌트에 매길 클래스에 모듈의 클래스를 접두어로 쓸 것을 요구한다. 이렇게 하면 일단 모듈의 독립성을 보장할 수 있고, 다른 컴포넌트들과 이름이 충돌하는 것을 막을 수 있다. 그리고 각 컴포넌트들은 모듈화 해야할 시점이 왔을 때 하면 되지 않을까 추측한다.
109 | 
110 | 이처럼 클래스에 의존하면 선택자 점수가 균일하기 때문에 재사용할 수 있는 코드 조각을 만들 수 있다. 덕분에 수많은 컴포넌트들이 중첩돼 있고, 중첩 관계가 다양해서 모든 컴포넌트를 계층화할 수 없는 대규모 사이트에서 빠른 속도로 개발을 할 수 있다.
111 | 
112 | 한편 재사용되는 코드가 많다는 것은 사이트 어느 곳에서나 사용되는 코드가 많다는 것이고, 이것은 브라우저가 캐싱할 가능성이 높아진다는 것을 뜻한다. 그래서 사이트의 성능을 크게 향상시키는 데에 도움이 된다. 
113 | 
114 | 하지만 다중 클래스에 크게 의존하는만큼 HTML 마크업을 어질러서 유지 보수성을 떨어뜨린다는 비판도 있다. 게다가 OOCSS는 HTML 측에 대한 완전한 통제력을 전제하기 때문에, HTML 마크업을 건드릴 수 없는 경우에는 적용하기 어렵다. 그러나 전처리자를 사용하면 가능하다. Sass에서는 `@extend`를 이용해서 HTML쪽에 클래스를 추가하지 않고도 객체를 적용한 효과를 낼 수 있다. (예시 출처는: <http://takazudo.github.com/presentation-oocss-sass/>)
115 | 
116 | 	.btnbase {
117 | 		border: 3px solid #000;
118 | 		padding: 10px; 20px;
119 | 		color: #fff;
120 | 		border-radius: 10px;
121 | 	}
122 | 
123 | 	.twitter  { @extend .btnbase; background: red;  }
124 | 	.facebook { @extend .btnbase; background: blue; }
125 | 
126 | 위 파일을 Sass로 컴파일하면 다음과 같은 css가 생성된다.
127 | 
128 | 	.btnbase, .twitter, .facebook {
129 | 		border: 3px solid #000;
130 | 		padding: 10px; 20px;
131 | 		color: #fff;
132 | 		border-radius: 10px;
133 | 	}
134 | 
135 | 	.twitter  { background: red;  }
136 | 	.facebook { background: blue; }	
137 | 
138 | sass가 컴파일해준 css는 공유하는 시각적 특징으로 선택자를 몰아줬다. 이것은 사실 DRY CSS의 방법론이기도 하다. 서로 다른 접근법이 하나로 만나는 순간이다.
139 | 
140 | sass 3.2부터는 가상 객체를 만들 수도 있다. 이 가상 객체는 호출될 때에만 css를 출력한다. 이것을 이용하면 말뜻 없는 클래스를 하나도 만들지 않고서도, OOCSS를 구현할 수 있다.
141 | 
142 | 컴파일 전: 
143 | 
144 | 	%btnbase {
145 | 		border: 3px solid #000;
146 | 		padding: 10px; 20px;
147 | 		color: #fff;
148 | 		border-radius: 10px;
149 | 	}
150 | 
151 | 	.twitter  { @extend %btnbase; background: red;  }
152 | 	.facebook { @extend %btnbase; background: blue; }
153 | 
154 | 컴파일 후: 
155 | 
156 | 	.twitter, .facebook {
157 | 		border: 3px solid #000;
158 | 		padding: 10px; 20px;
159 | 		color: #fff;
160 | 		border-radius: 10px;
161 | 	}
162 | 
163 | 	.twitter  { background: red;  }
164 | 	.facebook { background: blue; }		
165 | 
166 | 물론 이런 방식을 쓸 경우에도 몇가지 한계는 있다.
167 | 
168 | 1. 어떤 클래스가 어느 클래스에서 상속을 받았는지가 불분명해질 수 있다(SMACSS에서 제시하는 작명 규칙을 따르면, 번거롭기는 하지만 클래스 이름을 이용해서 어느 정도 이 단점을 보완할 수는 있다. 물론 자바스크립트를 걸 때에는 더더욱 번거로울 수도 있다). 
169 | 2. `@extend`가 선택자 점수를 바꿔주진 않기 때문에, 선택자 점수가 낮은 규칙으로 높은 규칙을 확장하려는 헛된 시도를 할 수 있다.
170 | 3. 확장된 규칙이 확장하기 전의 규칙과 선택자 점수가 같기 때문에 규칙을 어디서 선언하느냐가 중요하게 된다.
171 | 
172 | ### 그 밖에 참고한 문헌 ###
173 | 
174 | - <http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/>
175 | - <http://philipwalton.com/articles/the-future-of-oocss-a-proposal/>
176 | 


--------------------------------------------------------------------------------
/css/smacss/2013-02-08-pt1.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | SMACSS(이하 '스맥스')는 대규모 프로젝트를 위한 스타일링 지침이다.
  4 | 
  5 | 스타일의 다섯가지 유형
  6 | ---------------------
  7 | 
  8 | 스맥스는 스타일을 다섯가지로 분류하고, 각 유형에 맞는 선택자(selector)와 작명법(naming convention), 코딩 기법을 제시한다.
  9 | 
 10 | 1. 기초(Base)
 11 | 2. 레이아웃(Layout)
 12 | 3. 모듈(Module)
 13 | 4. 상태(States)
 14 | 5. 테마(Theme)
 15 | 
 16 | ### (1) 기초 스타일 ###
 17 | 
 18 | 흔히 말하는 reset 스타일류를 말하는 것이다.
 19 | 
 20 | - __기능__: 요소(elements) 스타일의 기본값 지정
 21 | - __선택자__
 22 | 	- 주로 **요소 선택자**(ex. `input[type=text]` 같은 것)
 23 | 	- 필요에 따라서 자식(child) 선택자, 자매 선택자, 
 24 | 	어트리뷰트(attribute) 선택자 등
 25 | 	- `!important`를 쓸 이유가 없다. 
 26 | 
 27 | #### 예 
 28 | 
 29 | 	html, body, form { margin: 0; padding: 0; }
 30 | 	input[type=text] { border: 1px solid #999; }
 31 | 	a { color: #039 }
 32 | 	a:hover { color: #03C; }
 33 | 
 34 | ### (2) 레이아웃 스타일 ###
 35 | 
 36 | - __기능__: 페이지를 구획하는 스타일(예: 헤더, 푸터, 그리드 ...)
 37 | - __선택자__: 아이디나 클래스
 38 | 	- 아이디는 CSS에서 클래스와 성능 차이가 없으며, 오히려 선택자 우선순위 점수(specificity) 때문에 함정에 빠질 우려가 있으므로, 신중하게 써야 한다. 
 39 | - __작명법__
 40 | 	- 아이디에는 이름 공간(namespace)을 할당하지 않아도 무방(이름 공간은 SMACSS에서 사용하는 접두어를 말한다. 예컨대 layout은 `l-`이라는 접두어를 붙인다.)
 41 | 	- 클래스는 '`l-`'을 앞에 붙여서 다른 유형의 클래스와 구분
 42 | 
 43 | 레이아웃 스타일은 재사용성에 따라 큰 레이아웃 스타일과 작은 레이아웃 스타일로 구분된다. 
 44 | 
 45 | #### 큰 레이아웃 스타일 ####
 46 | 
 47 | 예시:
 48 |  
 49 | 	#header, #article, #footer {
 50 | 	    width: 960px;
 51 | 	    margin: auto;
 52 | 	}
 53 | 	
 54 | 	#article {
 55 | 	    border: solid #CCC;
 56 | 	    border-width: 1px 0 0;
 57 | 	}
 58 | 
 59 | #### 작은 레이아웃 스타일 ####
 60 | 
 61 | `960.gs`와 같은 레이아웃 프레임워크를 쓸 경우다. 아이디가 아니라 클래스를 매겨서 요소를 재사용한다.
 62 | 
 63 | #### 재사용성 ####
 64 | 
 65 | 저자는 아이디를 매기기 전에 해당 요소의 재사용성을 숙고하라고 한다. 예시: 
 66 | 
 67 | 	<div id="featured">
 68 | 	<h2>Features</h2>
 69 | 	<ul>
 70 | 	    <li><a href="...">...</a></li>
 71 | 	    <li><a href="...">...</a></li>
 72 | 	    ...
 73 | 	</ul>
 74 | 	</div>
 75 | 	
 76 | 	div#featured ul {
 77 | 	    margin: 0;
 78 | 	    padding: 0;
 79 | 	    list-style-type: none;
 80 | 	}
 81 | 	div#featured li {
 82 | 	    float: left;
 83 | 	    height: 100px;
 84 | 	    margin-left: 10px;
 85 | 	}
 86 | 
 87 | 위 코드는 다음과 같은 가정이 깔려있다.
 88 | 
 89 | 1. 격자가 딱 한번만 사용된다.
 90 | 2. 항목은 왼쪽부터 띄운다(float).
 91 | 3. 항목의 높이는 100픽셀이다.
 92 | 
 93 | 위 코드를 아래와 같이 개선하면
 94 | 
 95 | 	.l-grid {
 96 | 	    margin: 0;
 97 | 	    padding: 0;
 98 | 	    list-style-type: none;
 99 | 	}
100 | 	
101 | 	.l-grid > li {
102 | 	    display: inline-block;
103 | 	    margin: 0 0 10px 10px;
104 | 	
105 | 	    /* IE7 hack */
106 | 	    *display: inline;
107 | 	    *zoom: 1;
108 | 	}
109 | 
110 | 다음과 같은 이점이 있다.
111 | 
112 | 1. 어느 박스에서나 그리드 레이아웃을 만들어낼 수 있다
113 | 2. depth of applicability(나중에 다룰 것임)를 1로 줄였다
114 | 3. 선택자의 우선순위 점수를 줄였다
115 | 4. 가장 높은 항목의 높이에 따라 열의 높이가 바뀐다
116 | 
117 | 다음과 같은 단점이 있긴 하지만
118 | 
119 | 1. 자식 선택자(`>`) 때문에 IE6이 배제된다(자식 선택자를 쓰지 않는 식으로 이 문제를 해결할 수 있다).
120 | 2. CSS의 크기와 복잡성이 증가했다.
121 | 
122 | 재사용성이 증가했기 때문에, 코드를 중복하지 않아도 되고, 선택자의 우선순위 점수를 줄였기 때문에 레이아웃을 확장하기에 좋다. 
123 | 
124 | ### (3) 모듈 스타일 ###
125 | 
126 | - __기능__: 레이아웃 요소 안에 들어가는 더 작은 부분들(예: 네비게이션 바, 말풍선, 대화 상자, 위젯 ...)
127 | - __선택자__
128 | 	- 클래스
129 | 	- 모듈에 포함된 요소는 후손 선택자나 자식 선택자로. (그냥 띄어쓰는 게 후손 선택자고, `>`로 연결하는 게 자식 선택자다. 후손 선택자는 `.my-module li`, 후손 선택자는 `.my-ul>li`)
130 | 	- 요소 선택자(`a` 같은 태그 선택자)는 피한다.(충돌을 피할 자신이 없다면)
131 | 	- 내용을 반영하는 선택자일수록 좋다.
132 | 
133 | #### 하위 클래스 만들기(sub-classing) ###
134 | 
135 | 모듈의 변종은 언제나 하위 클래스로 스타일링한다.
136 | 
137 | 나쁜 예:
138 | 
139 | 	.pod {
140 | 	    width: 100%;
141 | 	}
142 | 	.pod input[type=text] {
143 | 	    width: 50%;
144 | 	}
145 | 	#sidebar .pod input[type-text] {
146 | 	    width: 100%;
147 | 	}
148 | 
149 | 위 예에서 새로운 하위 클래스를 추가하면 선택자가 번잡해진다.
150 | 
151 | 	.pod {
152 | 	    width: 100%;
153 | 	}
154 | 	.pod input[type=text] {
155 | 	    width: 50%;
156 | 	}
157 | 	#sidebar .pod input[type=text] {
158 | 	    width: 100%;
159 | 	}
160 | 	.pod-callout {
161 | 	    width: 200px;
162 | 	}
163 | 	#sidebar .pod-callout input[type=text],
164 | 	.pod-callout input[type=text] {
165 | 	    width: 180px;
166 | 	}
167 | 
168 | 다음은 좋은 예다:
169 | 
170 | 	.pod {
171 | 	    width: 100%;
172 | 	}
173 | 	.pod input[type=text] {
174 | 	    width: 50%;
175 | 	}
176 | 	.pod-constrained input[type=text] {
177 | 	    width: 100%;
178 | 	}
179 | 	.pod-callout {
180 | 	    width: 200px;
181 | 	}
182 | 	.pod-callout input[type=text] {
183 | 	    width: 180px;
184 | 	}
185 | 
186 | 하위 클래스 적용하기:
187 | 
188 | 	.pod.pod-callout { }
189 | 	
190 | 	<div class="pod pod-callout"> ... </div>
191 | 
192 | ### (4) 상태별 스타일 ###
193 | 
194 | - __기능__: 다른 스타일에 덧붙이거나 덮어 씌워서 상태를 나타냄(예: 펼침과 접힘, 성공과 실패 등)
195 | - __선택자__
196 | 	- 클래스 선택자 한개
197 | 	- `!important`를 쓸 수도 있다(최소화 할 것)
198 | 	- 같은 모듈에 두 상태를 적용하지 말 것
199 | - __작명법__
200 | 	- '`is-`'를 앞에 붙인다
201 | 	- 특정 모듈에 한정된 상태는 모듈 이름도 그 뒤에 붙인다.(예: `is-tab-active`)
202 | - __유의__: 전역 상태 스타일은 모듈 상태 스타일과 구분한다. 모듈 상태 스타일은 모듈 스타일과 병기한다. 
203 | 
204 | #### 예시
205 | 
206 | 	<div id="header" class="is-collapsed">
207 | 	    <form>
208 | 	        <div class="msg is-error">
209 | 	            There is an error!
210 | 	        </div>
211 | 	        <label for="searchbox" class="is-hidden">Search</label>
212 | 	        <input type="search" id="searchbox">
213 | 	    </form>
214 | 	</div>
215 | 
216 | - `#header`
217 | 	- 레이아웃 요소임을 알 수 있다.
218 | 	- `.is-collapsed`로 접힌 상태임을 알 수 있다.
219 | - `.msg`
220 | 	- 모듈이다.
221 | 	- `.is-error`로 오류 상태임을 알 수 있다.
222 | - `#searchbox`
223 | 	- 연관된 라벨은 숨겨져 있다.
224 | 	- 라벨이 마크업 된 이유는 스크린 리더기를 위한 것
225 | 
226 | #### 모듈과 다른 점 ####
227 | 
228 | - 모듈과 레이아웃 둘 다에 적용할 수 있다
229 | - 페이지가 로드된 이후의 상태 변화를 나타내므로 __자바스크립트에 의존한다.__
230 | 
231 | ### (5) 테마 스타일 ###
232 | 
233 | 사용자가 테마를 선택할 수 있는 경우를 염두에 두고, 색상이나 이미지를 불변하는 스타일과 분리하는 것이다. 거의 사용할 일은 없지만 필요할 때가 있다.
234 | 
235 | 예시
236 | 
237 | 	/* 모듈 스타일 */
238 | 	.mod {
239 | 		border: 1px solid;
240 | 	}
241 | 	
242 | 	/* 테마 스타일 */
243 | 	.mod {
244 | 		border-color: blue;
245 | 	}
246 | 
247 | - 적용 범위가 넒은 테마는 `theme-`를 접두어로 붙여서 혼란을 피한다
248 | - `i18n` 등을 염두에 두고 글꼴도 사용자가 바꿀 수 있게 하기 위해 글꼴 스타일도 따로 분류할 수 있다. 그러나 굳이 글꼴 별로 클래스를 만들 것 까지는 없다
249 | 


--------------------------------------------------------------------------------
/css/smacss/2013-02-22-pt2.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | 상태 바꾸기
  4 | -----------
  5 | 
  6 | ### 클래스 이름으로 바꾸기 ###
  7 | 
  8 | 버튼을 눌러서 요소를 숨기는 방법.
  9 | 
 10 | 	$('.btn-close').click(function(){
 11 | 		$(this).parents('dialog').addClass('is-hidden');
 12 | 	});
 13 | 
 14 | 버튼을 눌러서 메뉴를 보이는 방법(버튼을 누르면 버튼이 눌린 상태가 되고, 메뉴는 보이는 상태가 된다) 세가지. 
 15 | 
 16 | #### 작명 규칙(naming-convention)을 활용한 방법 ####
 17 | 
 18 | 마크업
 19 | 
 20 | 	<div id="content">
 21 | 		<div class="toolbar">
 22 | 			<button id="btn-new" class="btn" data-action="menu">New</button>
 23 | 		</div>
 24 | 	</div>
 25 | 	<div id="menu-new" class="menu">
 26 | 		<ul>...</ul>
 27 | 	</div>
 28 | 
 29 | - `data-action` 어트리뷰트가 어떤 자바스크립트 코드를 호출할지 결정한다.
 30 | - 버튼을 클릭하면 버튼의 아이디를 토대로 메뉴를 찾는다.
 31 | 
 32 | 		$('#btn-new').click(function(){
 33 | 			$(this).addClass('is-pressed');
 34 | 			$('#menu-' + $(this).id.substr(4)).removeClass('is-hidden');
 35 | 		});
 36 | 
 37 | #### 메뉴와 버튼을 이웃하게 하기 ####
 38 | 
 39 | 마크업
 40 | 	
 41 | 	<div id="content">
 42 | 		<div class="toolbar">
 43 | 			<button id="btn-new" class="btn" data-action="menu">New</button>
 44 | 			<div id="menu-new" class="menu".
 45 | 				<ul>...</ul>
 46 | 			</div>
 47 | 		</div>
 48 | 	</div>
 49 | 
 50 | 1. `div.toolbar`에 '.is-active'를 추가하고 스타일을 매기는 방법
 51 | 
 52 | 		.is-active .btn { color: #000; }
 53 | 		.is-active .menu { display: block }
 54 | 	
 55 | 	메뉴와 버튼이 같은 요소 안에 있어야만 하고, 다른 항목이 툴바에 들어가도 안된다.
 56 | 	  
 57 | 2. 형제 선택자(`+`)를 이용하는 방법
 58 | 
 59 | 		.btn.is-active { color: #000; }
 60 | 		.btn.is-active + .menu { display: block; }
 61 | 	
 62 | 	여전히 HTML 구조에 의존한다. 언제건 버튼과 메뉴가 이웃한다는 일관성을 지킬수만 있다면야 상관 없다.
 63 | 
 64 | "버튼 메뉴"를 위한 위 규칙들은 어디에서 선언해야 할까? 버튼? 메뉴? 버튼에 다는 게 낫다.
 65 | 
 66 | ### 어트리뷰트 선택자로 상태 바꾸기 ###
 67 | 
 68 | 이점
 69 | 
 70 | - 레이아웃 클래스나 모듈 클래스와 구분돼 보인다.
 71 | - 여러가지 상태로 쉽게 전환할 수 있다.
 72 | 
 73 | 예시:
 74 | 
 75 | 	.btn[data-state=default] { color: #333; }
 76 | 	.btn[data-state=pressed] { color: #000; }
 77 | 	.btn[data-state=disabled] { opacity: .5; pointer-events: none; }
 78 | 
 79 | HTML5는 `data-`로 시작하는 어트리뷰트를 허용한다. 
 80 | 
 81 | ### CSS 애니메이션이 있는 클래스 기반 상태 변화 ###
 82 | 
 83 | __딜레마__: CSS는 모습, 자바스크립트는 페이지의 작동을 규정한다. 
 84 | 그러나 애니메이션은 주로 자바스크립트로 처리돼왔다.
 85 | 
 86 | 나타났다 사라지는 메시지의 예:
 87 | 	
 88 | JS: 
 89 | 
 90 | 	function showMessages (s) {
 91 | 		var el = document.getElementById('message');
 92 | 		el.innerHTML = s;
 93 | 		el.className = 'is-visible';
 94 | 		setTimeout(function() {
 95 | 			el.className = 'is-hidden'
 96 | 		}, 3000);
 97 | 	}
 98 | 
 99 | CSS: 
100 | 
101 | 	@keyframes fade {
102 | 		  0% { opacity:0; display:block; }
103 | 		100% { opacity:1; display:block; }
104 | 	}
105 | 
106 | 	.is-visible {
107 | 		display: block;
108 | 		animation: fade 2s;
109 | 	}
110 | 
111 | 	.is-hidden {
112 | 		display: none;
113 | 		admination: fade 2s reverse;
114 | 	}
115 | 
116 | 자바스크립트는 상태를 바꾸고, 상태에 따른 모습은 CSS가 담당한다. 
117 | 그러나 많은 브라우저가 이를 구현해주지 않는다. 다행히도 CSS3 애니메이션 권고에 따라 브라우저들이 바뀌고 있는 중이다. 당분간은 윗 부분을 다음과 같은 방식으로 써야 하고, is-removed 클래스를 추가해야한다. 
118 | 
119 | 	@-webkit-keyframes fade {
120 | 		...
121 | 	}
122 | 
123 | 	...
124 | 	
125 | 	.is-removed { display: none; }
126 | 
127 | 자바스크립트는 다음과 같이 쓴다.
128 | 
129 | 	function showMessages (s) {
130 | 		var el = document.getElementById('message');
131 | 		el.innerHTML = s;
132 | 		el.className = 'is-visible';
133 | 		setTimeout(function() {
134 | 			el.className = 'is-hidden'
135 | 			setTimeout(function(){
136 | 				el.className = 'is-removed';
137 | 			}, 2000);
138 | 		}, 3000);
139 | 	}
140 | 
141 | ### 의사(pseudo) 클래스 이름으로 상태 바꾸기 ###
142 | 
143 | 예시:
144 | 	
145 | 	.btn { background-color: #333; }
146 | 	.btn:hover { background-color: #336; }
147 | 	.btn:focus { box-shadow: 0 0 3px rgba(48,48,96,.3); }
148 | 
149 | 하위 모듈을 만들시 규칙을 다시 맞춰서 써야할 수도 있다.
150 | 	
151 | 	.btn { background-color: #333; }
152 | 	.btn:hover { background-color: #336; }
153 | 	.btn:focus { box-shadow: 0 0 3px rgba(48,48,96,.3); }
154 | 
155 | 	.btn-special { background-color: #DEDB12; }
156 | 	.btn-special:hover { background-color: #B8B50B; }
157 | 
158 | 여기에 클래스로 상태를 나타내면 더 복잡해진다.
159 | 
160 | 	.btn { ... }
161 | 	.btn:hover { ... }
162 | 	.btn:focus { ... }
163 | 
164 | 	.btn-special { ... }
165 | 	.btn-special:hover { ... }
166 | 	
167 | 	.btn.is-pressed { ... }
168 | 	.btn.is-pressed:hover { ... }
169 | 	
170 | 	.btn-special.is-pressed { ... }
171 | 	.btn-special.is-pressed: hover { ... }
172 | 
173 | ### 미디어 쿼리 ###
174 | 
175 | 예시: 
176 | 
177 | 	@media screen and (max-width: 400px) {
178 | 		#content { float: none; }
179 | 	}
180 | 
181 | SMACSS에서는 특정 모듈에 적용되는 스타일을 분리해야하므로, 분기점을 하나만 만들기보다는 미디어 쿼리를 모듈의 상태와 함께 둬야한다. 
182 | 
183 | 	.nav > li { float: left; }
184 | 	@media screen and (max-width: 400px) {
185 | 		.nav > li { float: none; }
186 | 	}
187 | 
188 | 미디어 쿼리 선언을 여러번 해야할테지만, 모듈에 대한 정보를 한 곳에 다 모을 수 있다. 그러면 테스트하기에도 좋고, 모듈화해서 템플릿과 CSS를 따로 불러와도 된다. 
189 | 
190 | 적용 깊이(Depth of Applicability)
191 | --------
192 | 
193 | __뜻__: 규칙에 영향을 받는 세대의 수. "`body.article > #main > #content > #intro > p > b`"는 6. 같은 페이지에서 "`.article #intro b`"도 6. 
194 | 
195 | 적용의 깊이가 크면 HTML 구조에 더 많이 의존하게 된다. 그러면 컴포넌트를 이동시키기 어려워진다. 사이드바에 있는 모듈을 푸터에도 만드려는 경우: 
196 | 
197 | 	#sidebar div, #footer div { border: 1px solid #333; }
198 | 	#sidebar div h3, #footer div h3 { margin-top: 5px; }
199 | 	#sidebar div ul, #footer div ul { margin-bottom: 5px; }
200 | 
201 | 이 모듈의 루트는 `div` 요소이고, 여기서 모듈을 만들면 된다.
202 | 
203 | 	.pod { border: 1px ... }
204 | 	.pod > h3 { ... }
205 | 	.pod > ul { ... }
206 | 
207 | 1. 모듈을 쓸 때마다 클래스에 `pod`를 써줘야 하지만, 이렇게 하면 적용 깊이를 줄일 수 있는 이점이 있다. 그러면 동적 콘텐츠를 위한 템플릿을 자유자재로 쓸 수 있다. 
208 | 
209 | 		<div class="pod">
210 | 			<h3>{{heading}}</h3>
211 | 			<ul>
212 | 				{{#items}}
213 | 				<li>{{item}}</li>
214 | 			</ul>
215 | 		</div>
216 | 	
217 | 2. 더 유연한 구조가 필요치 않다면, `h3`나 `ul`에 클래스를 매길 필요는 없다. 그러나 더 유연하려면 반드시 클래스를 매겨야 한다. 가령 `ul` 대신에 `ol`, `div`가 들어가는 경우: 
218 | 
219 | 		.pod > ul, .pod > ol, .pod > div { ... }
220 | 
221 |    이렇게 스타일을 매길 수도 있지만, 클래스를 붙이면 다음과 같이 축약할 수 있다.
222 | 
223 | 		.pod-body { ... }
224 | 
225 | 선택자의 성능
226 | ------------
227 | 
228 | Steve Souders의 연구에 따르면 CSS 선택자의 성능은 기껏해야 0.05초 밖에 나지 않는다. 그러므로 너무 신경쓸 필요는 없지만 알아두긴 하자.
229 | 
230 | 선택자는 오른쪽부터 계산된다. `.module h3`의 경우 브라우저는 페이지 내에 있는 모든 `h3`를 먼저 찾아낸다. 그 다음 `.module`에 속한 것을 찾는다. 그러므로 오른쪽에 요소 선택자를 두면 성능이 떨어진다. 그래서 구글에서는 모든 요소에 클래스를 붙여 쓰지만, 저자는 실용적으로 접근하자고 한다. 
231 | 
232 | HTML5와 SMACSS
233 | ---------------
234 | 
235 | HTML5이든 HTML4이든 SMACSS가 효과적인 이유 
236 | 
237 | 1. HTML 페이지에 말뜻(semantic value)을 더해준다.
238 | 2. HTML 구조에 덜 의존한다.
239 | 
240 | HTML5에는 좀더 말뜻이 분명한 요소가 추가됐다.(e.g. `section`, `header`, `aside`)
241 | 
242 | 그러나 태그가 모듈을 대체할 수는 없다. 다음 `nav`가 같은 `nav`일까?
243 | 
244 | 	<nav class="nav-primary">
245 | 		<h1>Primary Nav</h1>
246 | 		<ul>...</ul>
247 | 	</nav>
248 | 	
249 | 	<nav class="nav-secondary">
250 | 		<h1>External Links</h1>
251 | 		<ul>...</ul>
252 | 	</nav>
253 | 
254 | `nav.nav-primary`는 페이지 상단에 있는 수평 네비게이션이겠지만, `nav.secondary`는 아마 사이드바에 들어갈 네비게이션 같다. 
255 | 
256 | 	nav.nav-primary   li { display: inline-block; }
257 | 	nav.nav-secondary li { display: block; }
258 | 
259 | 근데 클라이언트가 와서 수평 메뉴에 수직 메뉴를 추가해달라고 한다.
260 | 
261 | 	<nav class="nav-primary".
262 | 		<h1>Primary Nav</h1>
263 | 		<ul>
264 | 			<li>About Us
265 | 				<ul>
266 | 					<li>Team</li>
267 | 					<li>Location</li>
268 | 				</ul>
269 | 			</li>
270 | 		</ul>
271 | 	</nav>
272 | 
273 | 그럼 하위 메뉴에 있는 `li`가 수평으로 나열되지 않게 하려면? 
274 | 
275 | 1. `ul`을 `<nav class="nav-secondary">`요소로 감싼다.
276 | 2. 다음과 같이 CSS를 고친다.
277 | 
278 | 		nav.nav-primary   li { ... }
279 | 		nav.nav-secondary li,
280 | 		nav.nav-primary   li li { display: block; }
281 | 
282 | 3. `nav` 선택자를 버리고 클래스에만 의존한다.
283 | 
284 | 		<nav class="l-inline">
285 | 			<h1>Primary Nav</h1>
286 | 			<ul>
287 | 				<li>About Us
288 | 					<ul class="l-stacked">
289 | 						<li>Team</li>
290 | 						<li>Location</li>
291 | 					</ul>
292 | 				</li>
293 | 			</ul>
294 | 		</nav>
295 | 		.l-inline  li { display: inline-block; }
296 | 		.l-stacked li { display: block; } 
297 | 
298 |   이게 SMACSS 스타일. 한 술 더떠서 이 레이아웃 규칙을 더 일반화할 수 있다(선택자의 성능은 희생되겠지만): 
299 | 
300 | 		.l-inline > *  { display: inline-block; }
301 | 		.l-stacked > * { display: block; }
302 | 


--------------------------------------------------------------------------------
/css/smacss/2013-03-11-pt3.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | 프로토타이핑
  4 | ------------
  5 | 
  6 | 프로토타이핑은 디자인에서 나타나는 패턴을 기록해서 사이트의 기초 자재를 만드는 데에 도움이 된다. 프로토타이핑은 다음과 같은 목표가 있다. 
  7 | 
  8 | - 상태별 모습을 확인하기
  9 | - 지역화 때문에 깨지지 않나 확인해보기
 10 | - 의존성 분리
 11 | 
 12 | Yahoo!에서는 Mustache 템플릿을 기반으로 JSON 형태로 저장한 데이터와 각 패턴에 필요한 CSS, JavaScript를 끌어와서 모듈을 컴파일해주는 프로토타이핑 엔진이 있었다. 
 13 | 
 14 | 프로젝트에 규모가 클 수록 이런 프로토타이핑 엔진이 유용하다. 
 15 | 
 16 | 소규모 프로젝트에서도 디자인 패턴은 기록해 두는 것이 좋다. (예: [MindChimp][]).
 17 | 
 18 | [MindChimp]: http://www.flickr.com/photos/aarronwalter/5579386649/sizes/o/in/photostream/
 19 | 
 20 | 전처리자(Preprocessors)
 21 | --------
 22 | 
 23 | 전처리자를 사용하면 개발자들의 인생이 쉬워진다고들 한다. 전처리자는 특수한 문법을 사용해서 작성한 파일을 CSS 파일로 컴파일해준다. 지금은 Sass와 Less가 CSS 전처리자 시장을 주도하고 있다. 
 24 | 
 25 | ### Sass 설치하고 사용하기 ###
 26 | 
 27 | Sass를 사용하려면 ruby 인터프리터가 깔려 있어야 한다. Sass는 ruby 패키지 관리자인 gem을 이용해서 쉽게 설치할 수 있다. 
 28 | 
 29 | 	gem install sass
 30 | 
 31 | Sass는 Sass 문법으로 작성한 `.scss` 파일을 `.css` 파일로 컴파일해준다. 다음과 같이 입력하면 특정 디렉토리를 감시하면서, 변경된 파일이 있으면 그때그때 컴파일해준다. 
 32 | 
 33 | 	sass --watch [inputdir]:[outputdir]
 34 | 
 35 | 혹은 다음과 같이 명령줄을 입력해서 컴파일 할 수도 있다.
 36 | 
 37 | 	sass [inputfile] [outputfile]
 38 | 	sass --update [inputdir]
 39 | 
 40 | ### Sass의 기능들 ###
 41 | 
 42 | #### 변수 ####
 43 | 
 44 | scss input:
 45 | 
 46 | 	$color: #369
 47 | 	
 48 | 	body {
 49 | 		color: $color;
 50 | 	}
 51 | 
 52 | 	.callout {
 53 | 		border-color: $color;
 54 | 	}
 55 | 
 56 | result: 
 57 | 	
 58 | 	body {
 59 | 		color: #369;
 60 | 	}
 61 | 	
 62 | 	.callout {
 63 | 		border-color: #369;
 64 | 	}
 65 | 
 66 | #### 중첩 ####
 67 | 
 68 | scss input:
 69 | 
 70 | 	.nav {
 71 | 		> li {
 72 | 			float: left;
 73 | 			> a {
 74 | 				display: block;
 75 | 			}
 76 | 		}
 77 | 	}
 78 | 
 79 | result:
 80 | 
 81 | 	.nav li {
 82 | 		float: left; }
 83 | 		.nav > li > a {
 84 | 			display: block; }
 85 | 
 86 | #### Mixin(범벅?) ####
 87 | 
 88 | scss input:
 89 | 
 90 | 	@mixin border-radius ($size) {
 91 | 		-webkit-border-radius: $size;
 92 | 		   -moz-border-radius: $size;
 93 | 		        border-radius: $size;
 94 | 	}
 95 | 
 96 | 	...
 97 | 
 98 | 	.callout {
 99 | 		@include border-radius(5px);
100 | 	}
101 | 
102 | result: 
103 | 	
104 | 	.callout {
105 | 		-webkit-border-radius: 5px;
106 | 		    moz-border-radius: 5px;
107 | 		        border-radius: 5px;
108 | 	}
109 | 
110 | #### 함수 ####
111 | 
112 | scss input:
113 | 
114 | 	$btnColor: #036;
115 | 	.btn { 
116 | 		background-color: $btnColor;
117 | 	}
118 | 	.btn:hover {
119 | 		background-color: lighten($btnColor, 20$);
120 | 	}
121 | 
122 | result:
123 | 
124 | 	.btn {
125 | 		background-color: #003366;
126 | 	}
127 | 	.btn:hoveer {
128 | 		background-color: #0066cc;
129 | 	}
130 | 
131 | #### 확장 ####
132 | 
133 | scss input: 
134 | 	
135 | 	.btn {
136 | 		display: block;
137 | 		padding: 5px 10px;
138 | 		background0color: #003366;
139 | 	}
140 | 	.btn-default {
141 | 		@extend .btn;
142 | 		background-color: #0066cc;
143 | 	}
144 | 
145 | result:
146 | 
147 | 	.btn, .btn-default {
148 | 		display: block;
149 | 		padding: 5px 10px;
150 | 		background-color: #003366;
151 | 	}
152 | 	.btn-default {
153 | 		background-color: #0066cc;
154 | 	}
155 | 
156 | 
157 | `#main .btn`과 같은 복잡한 선택자는 사용할 수 없다. 
158 | 
159 | 전처리자의 함정
160 | ---------------
161 | 
162 | > "큰 힘에는 큰 책임이 따른다" - 스파이더맨
163 | 
164 | 전처리기는 유용하지만, 컴파일된 결과가 비대해져서 디버그하기 어려워질 수도 있다. 
165 | 
166 | ### 중첩 남용 ###
167 | 
168 | scss input:
169 | 
170 | 	#sidebar {
171 | 		width: 300px;
172 | 		.box {
173 | 			border-radius: 10px;
174 | 			background-color: #EEE;
175 | 			h2 {
176 | 				font-size: 14px;
177 | 				font-weight: bold;
178 | 			}
179 | 			ul {
180 | 				margin: 0;
181 | 				padding: 0;
182 | 				a {
183 | 					display: block; 
184 | 				}
185 | 			}
186 | 		}
187 | 	}
188 | 
189 | result:
190 | 
191 | 	#sidebar {
192 | 		width: 300px; }
193 | 		#sidebar .box {
194 | 			border-radius: 10px;
195 | 			background-color: #EEE; }
196 | 			#sidebar .box h2 {
197 | 				font-size: 14px;
198 | 				font-weight: bold; }
199 | 			#sidebar .box ul {
200 | 				margin: 0;
201 | 				padding: 0; }
202 | 				#sidebar .box ul a { 
203 | 					display: block; }
204 | 
205 | SMACSS식 스타일: 
206 | 
207 | 	#sidebar {
208 | 		width: 300px;
209 | 	}
210 | 
211 | 	.box { ... }
212 | 	.box-header { ... }
213 | 	.box-body {
214 | 		...
215 | 		a {
216 | 			display: block; 
217 | 		}
218 | 	}
219 | 
220 | 
221 | ### 확장의 남용 ###
222 | 
223 | `@extend`를 사용하면 HTML 요소에 클래스를 여러개 적지 않아도 된다. 기존에는 HTML 요소에 하위 클래스 이름을 적었다면, `@extend`는 하위 클래스의 이름을 공통된 스타일 선언부로 보내준다. `@extend`를 쓸 경우 하위 모듈의 이름을 잘 지어야 한다. `btn`의 하위 모듈 이름이 `small`이라면 나중에 볼 때 혼란스럽다. 뭐가 작다는 거지? `btn-small`이라고 명명하면 나중에 봐도 쉽게 알 수 있다. 
224 | 
225 | `@extend`는 하위 모듈을 만들기 위한 명령어다. 서로 관련 없는 두 모듈에 `@extend`를 써선 안된다. 
226 | 
227 | 	.box {
228 | 		border-radius: 5px;
229 | 		box-shadow: 0 0 3px 0 #000000;
230 | 		background-color: #003366;
231 | 	}
232 | 	.btn {
233 | 		@extend .box;
234 | 		background-color: #0066cc;
235 | 	}
236 | 
237 | 
238 | 이처럼 모듈의 상호 의존성을 심화시키면 적시(just-in-time) CSS를 구현하기도 힘들어 진다. 
239 | 
240 | SMACSS식 확장은 그냥 요소에 클래스 이름을 여러개 적는 것이다. 
241 | 
242 | 	<a class="btn btn-default">My button</a>
243 | 
244 | 이렇게 하면 모듈의 원형을 쉽게 알 수 있다. 그리고 원형에는 '`-`'이 없기 때문에 HTML 마크업에서도 눈에 잘 띈다. 
245 | 
246 | (내 개인적인 생각으로도, SMACSS의 작명 규칙에선 컴포넌트에도 '`-`'를 붙이고, 하위 모듈에서도 '`-`'을 붙이기 때문에, 클래스 이름을 여러개 쓰는 것이 하위 모듈 이름과 컴포넌트 이름을 구분하는 데에도 어느 정도 도움이 되지 않을까 싶다.)
247 | 
248 | ### Mixin 남용 ###
249 | 
250 | scss input: 
251 | 
252 | 	@mixin theme-border {
253 | 		border: 2px solid #039;
254 | 		border-radius: 10px;
255 | 		background: #EEE;
256 | 	}
257 | 
258 | 	.callout {
259 | 		@include theme-border;
260 | 	}
261 | 
262 | 	.summary {
263 | 		@include theme-border;
264 | 	}
265 | 
266 | result:
267 | 
268 | 	.callout {
269 | 		border: 2px solid #039;
270 | 		border-radius: 10px;
271 | 		background: #EEE;
272 | 	}
273 | 	
274 | 	.summary {
275 | 		@include theme-border;
276 | 	}
277 | 
278 | SMACSS식 스타일:
279 | 
280 | 	.theme-border { ... }
281 | 	.callout { ... }
282 | 	.summary { ... }
283 | 
284 | SMACSS식 마크업: 
285 | 
286 | 	<div class="callout theme-border"></div>
287 | 	<div class="summary theme-border"></div>
288 | 
289 | 전처리기 제대로 활용하기
290 | ---------------
291 | 
292 | ### 상태 기반 중첩 미디어 쿼리 ###
293 | 
294 | scss input:
295 | 
296 | 	.nav > li {
297 | 		width: 100%;
298 | 		@media screen and (min-width: 320px) {
299 | 			width: 100px;
300 | 			float: left;
301 | 		}
302 | 		@media screen and ( min-width: 1200px) {
303 | 			width: 250px;
304 | 		}
305 | 	}
306 | 
307 | result:
308 | 
309 | 	.nav > li {
310 | 		width: 100%; }
311 | 	@media screen and (min-width: 320px) {
312 | 		.nav > li { ... } }
313 | 	@media screen and (min-width: 1200px) {
314 | 		.nav > li { ... } }
315 | 
316 | 
317 | ### 파일 관리 규칙 ###
318 | 
319 | - 기초 규칙은 파일을 따로 둔다
320 | - 레이아웃 파일도 따로 두고, 거대 레이아웃은 한 번 더 분리할 수 있다. 
321 | - 각 모듈별로 파일을 둔다. 
322 | - 전역 상태도 따로 파일을 둔다.
323 | - 모듈 파일에는 레이아웃과 모듈 상태, 모듈에 영향을 미치는 미디어 쿼리를 둔다. 
324 | 
325 | 이런 식으로 파일을 분리해두면 프로토타이핑을 하기 용이하다.
326 | 
327 | 변수 선언이나 Minxin이 있는 전처리자 전용 규칙들은 따로 파일을 둬야 한다.
328 | 
329 | 예시:
330 | 
331 | 	layout/
332 | 		grid.scss
333 | 		alternate.scss
334 | 	module/
335 | 		callout.scss
336 | 		bookmarks.scss
337 | 		btn.scss
338 | 		btn-compose.scss
339 | 	base.scss
340 | 	states.scss
341 | 	satates.scss
342 | 	site-settings.scss
343 | 	mixins.scss
344 | 
345 | 그리고 각 파일을 결합하는 마스터 파일을 둔다.
346 | 
347 | 	@import
348 | 		"site-settings",
349 | 		"mixins",
350 | 		"base",
351 | 		"states", 
352 | 		"layout/grid",
353 | 		"module/btn",
354 | 		"module/bookmarks",
355 | 		"module/callout";
356 | 
357 | 그러면 전처리자가 이것을 하나의 파일로 컴파일해준다. 
358 | 
359 | 런칭 준비가 완료되면 CSS 파일을 압축해서 배치한다.
360 | 
361 | 	sass -t compressed master.scss master.css
362 | 
363 | 


--------------------------------------------------------------------------------
/css/smacss/2013-03-14-pt4.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | 기초 스타일 쓰지 않기
  4 | ---------------
  5 | 
  6 | 자주 쓰이지 않거나 용도가 다양하지 않은 요소라도, 기초 스타일로 스타일하겠다는 생각은 버려야 한다. `<button>`, `<table>`, `<input>`이 그런 예다. 특정한 목적을 위한 스타일은 모듈로 만들어라. 그래야 내다보지 못한 일이 벌어졌을 때, 기존에 쓴 스타일을 덮어쓰느라 고생할 필요가 없다. 
  7 | 
  8 | 아이콘 모듈
  9 | ------------
 10 | 
 11 | CSS 스프라이트를 쓰면 HTTP 요청을 줄일 수 있고, 필요한 이미지를 미리 적재할 수 있다. 스프라이트 이미지는 배경으로 들어간다. 
 12 | 
 13 |  	.menu li { 
 14 | 		background: url(/img/sprite.png) no-repeat 0 0;
 15 | 	}
 16 | 	.menu .menu-inbox {
 17 | 		background-position: 0 -20px;
 18 | 	}
 19 | 
 20 | 	.menu .menu-drafts {
 21 | 		background-position: 0 -40px;
 22 | 	}
 23 | 
 24 | 위와 같이 스프라이트를 이용할 경우 다음과 같은 문제가 생긴다.
 25 | 
 26 | - `<li>`이라는 특정한 HTML 요소에 의존하게 된다
 27 | - 다른 모듈에서 스프라이트를 쓰려면 위 규칙을 다시 정의해야 한다. 
 28 | - 이미지를 보이는 자리로 쓰는 요소 자체가 굉장히 불안정하다. 예를 들어 글꼴을 키우거나 할 경우 해서 스프라이트의 다른 부분이 드러날 수도 있다. 
 29 | 
 30 | 이러한 어려움을 해결하기 위해 아이콘을 모듈로 만들자.
 31 | 
 32 | 	<li><i class="ico ico-16 ico-inbox"></i> Inbox</li>
 33 | 
 34 | 여기서 `<i>`를 쓴 이유는 짧고, 말뜻이 없는(mostly devoid of semantics) 요소이기 때문이다. 아이콘이 홀로 쓰이는 경우 `title` 어트리뷰트를 매겨서 스크린 리더가 알아볼 수 있게 한다. `<i>`을 쓰는 것이 마음에 안들면  `<span>`을 쓰든지. 
 35 | 
 36 | 한편 여기서 클래스를 세 개 쓴 이유는 무엇일까?
 37 | 
 38 | 	.ico {
 39 | 		display: inline-block;
 40 | 		background: url(/img/sprite.png) no-repeat;
 41 | 		line-height: 0;
 42 | 		vertical-align: bottom;
 43 | 	}
 44 | 
 45 | 	.ico-16 {
 46 | 		height: 16px;
 47 | 		width: 16px;
 48 | 	}
 49 | 
 50 | 	.ico-inbox {
 51 | 		background-position: 20px 20px;
 52 | 	}
 53 | 	
 54 | 	.ico-drafts {
 55 | 		background-position: 20px 40px;
 56 | 	}
 57 | 
 58 | 스프라이트를 조밀하게 짤 수록 성능은 높아진다. 이미지 파일을 최적화해주는 Smush.it이나 ImageOptim과 같은 서비스를 이용해도 좋다.
 59 | 
 60 | 복잡한 상속
 61 | --------------
 62 | 
 63 | 예를 들어 달력을 만들어보자.
 64 | 
 65 | 	<table class="cal">
 66 | 		<tr>
 67 | 			<td>1 <td>2
 68 | 			<td>3 <td>4
 69 | 			<td>5 <td>6 <td>7
 70 | 		.....
 71 | 	</table>
 72 | 
 73 | 	.cal td {
 74 | 		background-color: #EFEFEF;
 75 | 		color: #333;
 76 | 	}
 77 | 
 78 | 그런데 오늘 날짜를 강조하고 싶다.
 79 | 
 80 | 	.cal td.cal-today {
 81 | 		background-color: #F33;
 82 | 		color: #000;
 83 | 	}
 84 | 
 85 | 여기서 선택자를 그냥 `td.cal-today`라고만 썼다면? 이 규칙이 적용되려면 반드시 기본 규칙 다음에 나와야 한다. `.cal td`와 `.cal td.cal-today`는 선택자의 점수가 같기 때문이다. 두 점수가 같으면 뒤에 나오는 규칙이 채택된다.
 86 | 
 87 | 	.cal td      = 클래스 + 요소 = 10 + 1 = 11
 88 | 	td.cal-today = 요소 + 클래스 = 1 + 10 = 11
 89 | 
 90 | 한편 `.cal-today`만 선택자로 쓴다면 `!important`를 붙이지 않는 이상 먹히지 않을 것이다. 
 91 | 
 92 | 프로젝트를 진행하려면 언제나 이런 선택의 기로에 놓이게 된다. 위 예에서 채택한 선택자 `.cal td.cal-today`는 `.cal-today`가 `.cal`이 거느리는 `<td>`에만 적용된다는 것을 뜻한다. 
 93 | 
 94 | 이번에는 선택한 주를 강조하고자 한다. 
 95 | 
 96 | 	<tr class="is-selected">
 97 | 		<td>1
 98 | 		<td class="cal-today">2
 99 | 		<td>3
100 | 		...
101 | 
102 | 여기서 `.is-selected`는 어플리케이션 전반에 걸쳐서 사용되는 클래스다. 이 클래스는 어떻게 생겼을까?
103 | 
104 | 	.is-selected {
105 | 		background-color: #FFD700;
106 | 		color: #000;
107 | 	}
108 | 
109 | 보통은 `<tr>`의 배경색이 `<td>`로 상속되지만, 여기서는 그 주가 노랗게 되지 않는다. `.cal td`와 `.cal td.cal-today`가 상속받은 스타일을 덮어쓰기 때문이다.(그러나 저자의 말과는 달리 `background-color`는 상속되지 않는 프로퍼티다. 물론 이 경우에도 td에 걸린 규칙이 `.is-selected`가 지정한 배경을 가리는 것은 매한가지다.)
110 | 
111 | `!important`를 붙여도 소용이 없다. `!important`는 상속을 덮어쓰지 않으며, 선택자 점수만 높여주기 때문이다. 
112 | 
113 | 그래서 선택자를 다음과 같이 고쳤다.
114 | 
115 | 	.is-selected td {
116 | 		background-color: #FFD700;
117 | 		color: #000;
118 | 	}
119 | 
120 | 이 규칙은 `.cal td` 다음에 나와야 제대로 적용될 것이다. 
121 | 
122 | 만일 `!important`를 썼다면?
123 | 
124 | 	.is-selected td {
125 | 		background-color: #FFD700 !important;
126 | 		...
127 | 	}
128 | 
129 | 그럼 더이상 `.cal td.cal-today` 스타일이 적용되지 않는다. 이 스타일을 먹이려면 상태 규칙과 모듈 규칙을 뒤섞을 수밖에 없다.
130 | 
131 | 	.is-selected td.cal-today {
132 | 		background-color: #F33 !important;
133 | 		...
134 | 	}
135 | 
136 | 이처럼 상속은 얘기치 않은 문제를 낳을 수 있고 완전한 해결책은 없다. 
137 | 
138 | 코드 조판(Code Formatting)
139 | ---------
140 | 
141 | ### 1줄 vs 여러줄 ###
142 | 
143 | 1줄로 쓰면 선택자를 빠르게 훑어볼 수 있었다. 규칙이 짧은 시기에는 한 번에 모든 규칙을 다 볼 수 있었다. 
144 | 
145 | 그러나 CSS3와 브라우저별 특수 규칙이 쓰이면서 1줄짜리 규칙은 점점 보기에 어려워졌다. 예: 
146 | 
147 | 	.module {
148 | 	    display: block;
149 | 	    height: 200px;
150 | 	    width: 200px;
151 | 	    float: left;
152 | 	    position: relative;
153 | 
154 | 	    border: relative;
155 | 	    -moz-border-radius: 10px;
156 | 	    -webkit-border-radius: 10px;
157 | 	    border-radius: 10px;
158 | 	
159 | 	    -moz-box-shadow: 10px 10px 5px #888;
160 | 	    -webkit-box-shadow: 10px 10px 5px #888;
161 | 	    box-shadow: 10px 10px 5px #888;
162 | 
163 | 	    font-size: 12px;
164 | 	    text-transform: uppercase;
165 | 	}
166 | 
167 | 위 예에서 눈여겨 볼 다른 점들
168 | 
169 | - 콜론 다음에 공백을 넣었다. 
170 | - 탭이 아니라 공백 4개를 써서 들여썼다. 
171 | - 프로퍼티를 종류에 따라 묶었다.
172 | - 선택자와 같은 줄에서 괄호를 열었다.
173 | - 색깔은 짧은 형식으로 썼다(예: `#888`)
174 | 
175 | ### 스타일 묶기 ###
176 | 
177 | 저자는 주관적인 중요도에 따라 다음과 같은 순서로 선언 블록을 쓴다고 한다.
178 | 
179 | 1. 박스: `display`, `float`, `position`, `left`, `top`, `height`, `width`
180 | 2. 테두리: `border`, `border-image`, `border-radius`
181 | 3. 배경
182 | 4. 텍스트: `font-family`, `font-size`, `text-transform`, `letter-spacing`
183 | 5. 기타: 나머지
184 | 
185 | 


--------------------------------------------------------------------------------
/css/smacss/README.md:
--------------------------------------------------------------------------------
 1 | - Date: 2013-09-02 16:14:31
 2 | 
 3 | # 레프트21 웹개발팀 SMACSS 세미나
 4 | 
 5 | 유지보수 용이성을 향상시키기 위해 기획한 세미나다. [OOCSS](https://github.com/stubbornella/oocss/wiki)와 [SMACSS](http://smacss.com/)를 기본으로 삼았고, 더 잘 정리돼 있고 포괄적인 SMACSS를 우선 탐구 대상으로 삼았다. SMACSS는 책이 온라인에 무료로 공개돼 있었기 때문에 접근하기 좋았다.
 6 | 
 7 | 단, 영어라는 단점이 있었다. 영어에 능숙한 팀원이 거의 번역을 하다시피 하며 요약을 해서 함께 공부했다. 
 8 | 
 9 | CSS는 유지보수 용이성이라는 측면에서 개발단(server side)보다 관심을 덜 가지는 영역인 것처럼 느껴진다. 레프트21 웹개발팀의 경우, 가장 많은 시간을 잡아먹는 영역이 CSS였고, 그래서 CSS 유지보수 용이성을 향상시키려는 의식적인 노력을 하게 된 것이었다.
10 | 
11 | 비슷한 고민을 하고 있는 팀이 있다면 도움이 됐으면 한다.


--------------------------------------------------------------------------------
/epub/2013-10-10 EPUB 제작시 알아둬야 할 점.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-10-10 18:59:52
  2 | - Type: 세미나
  3 | - Tags: EPUB
  4 | - Title: EPUB 제작시 알아둬야 할 점
  5 | - Author: 박충-
  6 | 
  7 | ## 읽기 전에
  8 | 
  9 | - HTML/CSS에 대한 기본적 이해를 전제하고 작성했다.
 10 | - EPUB 2.01을 기준으로 작성했다.
 11 | 
 12 | ## 문서의 형과 XML 작성
 13 | 
 14 | EPUB은 HTML과 XML의 묶음으로 형태는 ZIP이나, 정확한 mimetype은 application/epub+zip이다. 그렇기 때문에 간혹 임의로 ZIP을 통해 압축을 하는 경우, EPUB 파일을 읽을 수 없게 된다.
 15 | 
 16 | 표준에 따라 mimetype, contaioner.xml 등의 파일이 필수적으로 필요한데, 제작자가 이런 것들을 일일이 수작업으로 만들 필요는 없다. Sigil 같은 편집 프로그램을 사용하면 기본적인 구조를 만들어 준다.
 17 | 
 18 | content.opf 파일은 EPUB이 어떤 구성으로 이루어져있는지 설명하는 문서로, 대략적으로 다음과 같은 요소로 이루어져 있다.
 19 | 
 20 | 	XML 정의
 21 | 		<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
 22 | 
 23 | 	메타데이터
 24 | 		<metadata>
 25 | 			<dc:title>
 26 | 			<dc:creator>
 27 | 			<dc:language>
 28 | 
 29 | 	컨텐츠 정의
 30 | 		<manifest>
 31 | 			<item href="toc.ncx" id="ncx" media-type="application/x-dtbncx+xml"/>
 32 | 			<item href="Text/example.xhtml" media-type="application/xhtml+xml"/>
 33 | 			<item href="Images/cover.png" media-type="image/png" properties="cover-image"/>
 34 | 			<item href="Images/table.png" media-type="image/png"/>
 35 | 
 36 | EPUB 파일의 메타데이터도 XML에 하드코딩 해 집어넣을 수 있지만, 편집 프로그램으로 넣는 것이 편하다. content.opf 파일에 넣으면 되고 필수, 권고 메타데이터 항목은 다음과 같다.
 37 | 
 38 | 	필수 메타데이터
 39 | 		제목 : <dc:title>
 40 | 		저자 : <dc:creator opf:role="aut">
 41 | 		출판사 : <dc:publisher>
 42 | 	
 43 | 	권고 메타데이터
 44 | 		출판일 : <dc:date opf:event="publication">
 45 | 		구분자 : <dc:identifier>
 46 | 		언어 : <dc:language>
 47 | 		유형 : <dc:type>
 48 | 
 49 | 메타데이터 중 language는 단순히 정보 제공을 넘어서 컨텐츠의 표현에도 영향을 준다. 예컨대 값이 영문를 의미하는 en일 경우에는 영단어 한가운데에서 줄바꿈이 이루어질 경우 하이픈(-)을 제공한다(단, CSS에서 text-align: justify인 경우에는 지원하지 않는다). 국문을 의미하는 ko일 경우에는 하이픈을 제공하지 않는다.
 50 | 
 51 | 표지의 경우, 표지를 표현하는 XHTML을 만들어 이미지를 가로 너비에 맞춰 확대하도록 하는 경우가 많지만, body에 걸려있는 기본 스타일이 뷰어마다 제각각일 수 있고 제어하기가 까다로우므로, 편집 프로그램을 이용해 EPUB 파일의 이미지들을 넣는 폴더에 표지 이미지를 넣고 content.opf 파일에서 해당 이미지에 해당하는 item에 properties="cover-image"라는 프로퍼티와 값을 줘 표현하는 것이 무난하다. 예는 다음과 같다.
 52 | 
 53 | 		<item href="Images/cover.png" id="cover.png" media-type="image/png" properties="cover-image"/>
 54 | 
 55 | 
 56 | 목차는 toc.ncx에 작성하며, 역시 하드코딩하는 것 보다는 편집 프로그램으로 생성하는 것이 편하다. 참고로 toc는 table of content를 의미한다. Sigil의 경우, h1, h2, h3 등의 헤딩 요소를 기준으로 toc.ncx를 생성하며, 헤딩 요소 뒤의 숫자에 따라 계층을 정할 수 있으므로 의미론적으로 마크업 하는게 좋다.
 57 | 
 58 | ## HTML/CSS 작성
 59 | 
 60 | ### HTML
 61 | 
 62 | 당연한 이야기이지만, 표준 마크업을 사용하는 것을 원칙으로 한다.
 63 | 
 64 | 제목은 h1, h2, h3 등의 헤딩 요소로 작성한다.
 65 | 
 66 | 문단은 p로 작성한다. br/은 사용하지 않는다.
 67 | 
 68 | 목록은 ul, ol, li로 작성한다.
 69 | 
 70 | HTML 문서 구분은 장을 기준으로 나누되, 편집은 종이 책의 그것에 따르는 것이 일반적이다.
 71 | 
 72 | 특별한 단어나 문장을 강조하기 위해 별도의 폰트나 색을 사용하는 것은 좋지 않다. 뷰어의 배경색이나 폰트는 얼마든지 바뀔 수 있기 때문이다. 강조가 필요하다면 font-weight: bold를 사용하거나 관련 b, strong을 사용한다.
 73 | 
 74 | 폰트 임베딩은 권장하지 않는다. 폰트 자체가 EPUB 파일의 덩치를 키우고 로딩을 위한 성능을 저해할 수 있다.
 75 | 
 76 | table 사용은 지양한다. 뷰어 환경에 따라 제어하기 어려울 가능성이 높다. 표를 표현해야 한다면 SVG를 사용하거나, 차라리 이미지로 대체하는 것이 좋다.
 77 | 
 78 | ### 이미지
 79 | 
 80 | EPUB에서 지원하는 이미지 파일 형식은 GIF, JPEG, PNG, SVG다.
 81 | 
 82 | 이미지를 사용할 시, 배경이 검정색이나 세피아일 것을 고려해야 한다. 이미지 둘레에 흰 여백을 1em 정도는 주는 것이 보기 좋다.
 83 | 
 84 | 
 85 | ### CSS
 86 | 
 87 | 기본적인 룰은 모범적인 CSS 작성 룰에서 크게 벗어나지 않는다.
 88 | 
 89 | EPUB 뷰어에 따라 스타일 해석이 제멋대로일 수 있고, 복잡한 스타일은 의도대로 해석되지 않을 가능성이 높으므로 최소화 한다.
 90 | 
 91 | 스타일은 style.css와 같은 별도의 스타일 시트를 만들어 HTML 파일에서 link한다. 간혹 Inner HTML 형식이나 Inline 형식으로 작성된 EPUB을 발견하기도 하는데, 유지 보수가 거의 불가능하다.
 92 | 
 93 | 가급적 기본 마크업의 스타일을 재정의 해 사용하되 꼭 필요한 스타일이 있을 때만 class를 지정한다. class 이름은 한글로 작성하는 것이 가독성이 높기 때문에 편리하다.
 94 | 
 95 | 점수 관리에 용이하도록 id 사용은 가급적 지양하고, class를 사용한다.
 96 | 
 97 | EPUB 특성상 body 내의 마크업 계층이 생길 일은 거의 없으므로, 중첩은 불가피한 경우가 아니면 사용하지 않는다. 단, 서지사항, 미주 등의 특별한 페이지의 경우 body에 class를 지정하는 것이 좋다.
 98 | 
 99 | 특별한 경우가 아니면 단위 사용은 %, em 등의 상대적 크기로 지정하는 것이 좋다.
100 | 


--------------------------------------------------------------------------------
/git/01-git-basic.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-10-10 16:07:32
  2 | 
  3 | git 기초
  4 | ========
  5 | 
  6 | 세미나 날짜 : 2013-04-22
  7 | 
  8 | 개념 이해
  9 | -------
 10 | 
 11 | 일단 용어를 익히고 넘어 가자.
 12 | 
 13 | * 작업 사본(working copy) : 저장소(repository)의 특정 리비전을 복사해 와서 내가 갖고 있는 파일들. svn에서 300번 리비전을 다운받아서 내 컴퓨터에 해당 리비전의 파일들이 있다고 하자. 그게 작업 사본이다. 
 14 | * 저장소 : 모든 commit history, tag, branch를 갖고 있는 곳. svn은 중앙 저장소에 이걸 모두 저장한다.
 15 | 
 16 | SVN은 원격 저장소에 commit history가 누적되고, 각 개발자는 작업 사본(working copy)을 들고 작업한다. SVN의 경우 현재 최신 리비전이 300번이고, 내가 최신으로 업데이트를 했다면, 내 컴퓨터에는 rivision 300번인 작업 사본만 존재한다. SVN의 정보는 `.svn`이라는 폴더에 저장되며, 여기엔 원격 저장소와 통신할 때 사용할 다양한 정보가 저장된다.
 17 | 
 18 | 반면 git(한글 발음은 기트로 하겠다)는 원격 저장소가 필수가 아니다. 작업 사본과 commit history는 한 폴더에 함께 있다. 내가 left21이라는 프로젝트를 git 저장소로 만들고 싶다면, left21 폴더에서 `git init`이라고 치면 끝이다. 그러면 그 때부터 그 곳은 git 저장소가 된다. `.git`라는 git 폴더가 생성되며, 이곳에는 모든 commit history가 저장된다. 이 저장소들 중 하나를 원격 저장소로 만들고 ssh나 http, https로 접속을 가능하게 만들면 그냥 그게 원격 저장소가 된다. (`git://` 프로토콜이나 `file://` 프로토콜도 사용할 수 있다.)예컨대, 아래처럼 할 수 있다.
 19 | 
 20 |     git clone http://192.168.0.30/left21.git
 21 | 
 22 | `left21.git`은 원격 저장소 폴더명이다. (원격 저장소 폴더에는 `.git`이라고 suffix를 붙이는 게 관례다.) 원격 저장소를 만드는 명령으로 만드는 건데, 일단 개념을 익히기 위한 것이니 그냥 보고 넘기자. 원격 저장소는 작업 사본을 포함하지 않고 `.git` 폴더의 내용만 들어있다. 여튼간에 여기서 기억할 것은 아래 두 가지다.
 23 | 
 24 | 1. git는 원격 저장소가 필수가 아니다. 모든 개발자의 컴퓨터가 하나의 저장소다.
 25 | 2. 여러 저장소 중 하나를 원격 저장소로 변환해서 사용하면 그만이다. (변환하지 않고 그냥 사용해도 되는 것 같은데 일단 패스.)
 26 | 
 27 | 장점
 28 | ----
 29 | 
 30 | 로컬에 커밋한다는 점때문에 생기는 장점이 분명하다.
 31 | 
 32 | * 커밋 속도가 무지하게 빠르다.
 33 | * 브랜치 생성 속도가 무지하게 빠르다. 이 덕에 브랜치를 상당히 부담없이 만들었다 날렸다 할 수 있다. 브랜치는 나중에 설명한다.
 34 | * 브랜치를 굳이 원격 저장소에 보낼 필요가 없으므로 동료들의 코드를 어지럽힐 걱정 없이 로컬에 있는 소스를 마음대로 갖고 놀 수 있다.
 35 | * 원격 저장소가 날아가도 commit history가 대부분 보전된다. (원격에만 있는 branch 같은 건 보전 안 될 수도 있는 것 같던데 더 공부해 보고.)
 36 | 
 37 | 설치
 38 | ----
 39 | 
 40 | 데비안 계열 리눅스에선 아래 명령어면 된다. (버전에 따라 `apt-get install git-core`라고 쳐야 할 수도 있는 것 같다.)
 41 | 
 42 |     apt-get install git
 43 | 
 44 | 윈도우에선 git를 따로 다운받아 설치하면 된다. 윈도우용을 제공한다.
 45 | 
 46 | 기초설정
 47 | ------
 48 | 
 49 |     git config --global user.name "myname"
 50 |     git config --global user.email "mymail@email.com"
 51 | 
 52 | 이렇게 자신을 설정해 주지 않으면 작동하지 않는다. 이건 뭘 설정한 걸까? 한 컴퓨터에 git가 설치되면 해당 컴퓨터는 하나의 저장소가 된다. 이 저장소를 사용하는 주인의 이름과 이메일을 적는 것이다. 이 저장소에서 다른 저장소의 것을 받아오거나, 다른 저장소로 `push`를 하거나 뭐 그럴 때 이 이름을 사용하게 되는 거다.
 53 | 
 54 |     git config --global core.quotepath false
 55 | 
 56 | 위 명령은 한글 파일명을 제대로 보기 위한 설정이다. 위 설정을 하지 않으면 한글 파일명이 `\302` 하는 식으로 표시된다. 물론 한글 파일명은 사용하지 않는 게 귀찮은 일을 원천 차단하는 게 될 거다.
 57 | 
 58 | 맥 유저가 있다면, 맥에서 아래 설정을 해 줘야 정신 건강에 좋을 거다. 한글 파일명 때문이다. 맥은 한글 파일명을 자소별로 분리해서 저장한다. (NFD방식이라고 한다. 자소를 합쳐서 저장하는 건 NFC 방식이라고 하고.) 이 때문에 생기는 문제가 있다. 아래와 같은 문제다.
 59 | 
 60 | 1. 리눅스 유저 팀원이 "한글파일명" 이라고 저장한 뒤 푸시한다.
 61 | 1. 맥 유저 팀원이 풀한다. "한글파일명"이 추가된다. 그러나 내부적으로는 "ㅎㅏㄴㄱㅡㄹㅍㅏㅇㅣㄹㅁㅕㅇ"이라고 저장됐다. 따라서 이 파일은 git 저장소에 없는 새로운 파일이다. untracked 파일이 발견됐으므로 커밋하라고 나온다. 시키는대로 커밋하고 푸시한다.
 62 | 1. 리눅스 유저 팀원이 풀하면 "ㅎㅏㄴㄱㅡㄹㅍㅏㅇㅣㄹㅁㅕㅇ"이라는 파일이 또 생긴다.
 63 | 
 64 | 그걸 회피하려면 아래처럼 설정한다.
 65 | 
 66 |     git config --global core.precomposeunicode true
 67 |     git config --local core.precomposeunicode true
 68 | 
 69 | 위처럼 일단 글로벌 설정을 해 준다. 그리고 이미 생성된 저장소에서는 모두 local로 유니코드 설정을 해 준다. 글로벌 설정과 로컬 설정 중에 당연히 우선순위를 갖는 것은 로컬 설정인데, 기본적으로 모든 저장소에는 `core.precomposeunicode`가 `false`로 설정돼 있기 때문에 로컬로 다 고쳐 줘야 한다.
 70 | 
 71 | 저장소 만들기
 72 | ----------
 73 | 
 74 | 저장소로 만들 폴더로 가서 다음 명령어를 치면 끝이다. git는 기본적으로 로컬 커밋이 가능하기 때문에 원격 저장소는 염두에 두지 않고 로컬 저장소를 만든다. 원격 저장소를 만드는 방법은 나중에 설명하도록 하겠다. (모든 로컬 브랜치는 그 자체로 원격 저장소가 될 수도 있을 지 모르겠는데, 정확힌 모르니까 일단 이렇게만 쓴다.)
 75 | 
 76 | 로컬에서 사용할 용도니 로컬 저장소긴 한데, 특별히 로컬 저장소라고 부르진 않겠다.
 77 | 
 78 |     git init
 79 | 
 80 | git에 파일을 추가하고 commit하기
 81 | --------------------------
 82 | 
 83 |     git status
 84 | 
 85 | 위 명령을 치면 저장소의 현재 상태가 나온다. 커밋할 놈 정보를 보여 주니까 이걸 보고 확인하면 된다. 파일을 하나 만들고 `git status`라고 쳐 보자.
 86 | 
 87 | 그러면 git가 추적하고 있지 않은 놈 목록에 방금 만든 파일이 포함돼 나온다. 아래 명령을 치면 모든 파일을 stage 상태로 넣는다. `.gitignore`에 포함된 파일은 제외하고 말이다.
 88 | 
 89 |     git add .
 90 | 
 91 | 그렇게 하고 다시 `git status`라고 쳐 보자. 그러면 파일이 커밋할 놈에 포함됐다고 나온다. 이걸 stage 상태라고 부른다. 이제 커밋을 하자.
 92 | 
 93 |     git commit
 94 | 
 95 | 그러면 에디터가 뜨고 commit 메시지를 적게 한다. 에디터는 기본으로 vi로 돼 있다. 이 기회에 vi의 기본 명령을 익히자. `i`를 누르면 입력 모드로 들어간다. esc 키를 누르면 다시 명령 모드로 돌아온다. `:`를 누르면 명령줄이 나타나고, `wq`를 명령줄에 써 주고 엔터치면 저장(write)하고 빠져나온다(quit). 어떤 에디터를 쓰건 간에 저장하고 빠져나오면 바로 commit이 된다.
 96 | 
 97 | 파일 수정 후 달라진 점을 확인하고 commit하기
 98 | -----------------------------------
 99 | 
100 | 아까 커밋한 파일을 수정해 보자. 그리고 다시 `git status`라고 명령을 내려 보자. 그러면 수정된 놈 목록에 포함돼 나온다. 뭐가 달라졌는지 확인해 보자.
101 | 
102 |     git diff 파일명
103 | 
104 | 그러면 달라진 점을 확인할 수 있다.
105 | 
106 | `diff`를 볼 때 색을 입혀서 보고 싶으면 아래 명령을 내려서 색을 입힌다.
107 | 
108 |     git config --global color.diff auto
109 | 
110 | `diff`는 기본적으로 줄바꿈이 안 돼서 나온다. 줄바꿈을 해서 보고 싶다면 아래처럼 설정을 해 준다.
111 | 
112 |     git config core.pager 'less -r'
113 | 
114 | `less`는 문서가 길 때 페이지를 넘기면서 볼 수 있게 해 주는 놈인데, `-r` 옵션을 주면 줄바꿈을 해서 보여 주나 보다. 
115 | 그리고 `less`에서 페이지를 넘길 때는 기본적으로 다음 키를 사용할 수 있다.
116 | 
117 | * 엔터 : 한줄씩 넘어간다
118 | * 스페이스바 : 한 페이지씩 넘어간다
119 | * q : 종료
120 | * /단어 + 엔터: '단어'라는 글자를 검색한다. 엔터친 상태에서 `N`을 누르면 다음 검색 결과로 간다. `Shift+N`을 누르면 이전 검색 결과로 간다.
121 | 
122 | 자, `git diff`로 달라진 점을 확인했다면 아래 명령을 치자.
123 | 
124 |     git add 파일명
125 | 
126 | 이렇게 파일을 staged 상태로 만들고 `git commit` 명령을 내려서 또 커밋을 하자.
127 | 
128 | 파일을 git에서 삭제하기
129 | ------------------
130 | 
131 | 파일을 git 저장소에서 지우려면 어떤 파일이 삭제됐다고 알려 줘야 한다.
132 | 
133 |     git rm 파일명
134 | 
135 | 이렇게 하면 된다. 
136 | 
137 | 그냥 파일시스템에서 탐색기로 파일을 지웠다면 어떻게 해야 할까? 마찬가지로 위 명령어로 git에게 파일이 삭제됐다고 알려 주면 된다. 현재 파일 시스템에 해당 파일이 없어도 상관 없다. 여튼 git 저장소에서 파일을 삭제하려면 `git rm`을 거쳐야 하는 것이다. 
138 | 
139 | SVN도 마찬가진데, GUI 툴들은 탐색기 같은 데서 삭제하면 저장소에서도 지우는 걸 알아서 해 주는 거다. (이클립스에서 svn 커밋할 때 탐색기에서 지운 놈들은 deleted라고 표시되지 않고 missing이라고 표시되는 걸 봤을 거다.)
140 | 
141 | 파일을 이동하거나 파일명을 바꾸려면 `mv`를 사용한다.
142 | 
143 |     git mv 원래파일명 바꿀파일명
144 |     git mv 원래파일명 바꿀파일위치
145 | 
146 | 파일명에 경로가 포함된 것으로 생각하면 파일명 변경이나 이동이나 어차피 같은 거라고 이해하기 쉬울 것이다.
147 | 
148 | 즉, 개념상 `/myfolder/mytext.txt` 까지 전체를 파일명으로 이해하면 되겠다. 개념을 그렇게 잡으면 `/myfolder/sub/mytext.txt`는 파일명이 변경된 것으로 이해할 수 있게 된다.
149 | 
150 | 저장소에서 작업 사본 받기
151 | -------------------
152 | 
153 | SVN의 checkout은 git에서 `clone`이다. SVN은 최신 작업 사본을 받는 것이지만, git은 저장소를 통째로 복사해 오는 것이므로 명령어가 `clone`인 것이다.
154 | 
155 |     git clone 저장소주소
156 | 
157 | 작업 사본을 받아 보자.
158 | 
159 |     git clone https://github.com/left21wm/seminar.git
160 | 
161 | 이렇게 치면 이 문서를 쓰고 있는 저장소를 복사해온다. 그런데 이 세미나 저장소는 쓰기는 안 되게 돼 있을 테니 자신의 저장소를 만들어 보자. github는 널리 사용되는 git 저장소니까 github를 이용해서 저장소를 만들어 보자.
162 | 
163 | 저장소를 만들었으면 제공하는 주소를 통해서 저장소를 받아와 보자. 그리고 나서 아무 문서나 만들고 `git status`라고 치고 `add`하고 `commit`하자. 그리고 저장소로 보내 보자.
164 | 
165 |     git push origin master
166 | 
167 | 한 번 `push`하면 다음부터는 `git push`라고 치면 `origin master`로 간다.
168 | 
169 | origin은 기본 원격 저장소의 닉네임이다. 원격 저장소 닉네임은 마음대로 설정할 수 있다. 이건 나중에 설명. 여튼 내 컴에 있는 하나의 저장소를 여러 개의 원격 저장소에 연동할 수 있어서 이런 기능이 있는 것 같다.
170 | 
171 | master는 기본 branch인데, branch는 나중에 설명하자.
172 | 
173 | 여튼간에 위 명령을 치면 저장소로 보내진다. 
174 | 
175 | 아래 명령은 저장소의 변경 사항을 받아 오는 명령이다.
176 | 
177 |     git pull origin master
178 | 
179 | 위와 같이 치면 변경 사항이 받아진다. origin과 master는 위에 설명한대로다.
180 | 
181 | 여럿이 작업할 때 A가 `push`를 했는데, B가 `pull`하지 않고 `push`를 하려고 하면 `push`가 되지 않는다.
182 | 
183 | 이 정도면 git를 일단 기본적으로는 사용할 만큼 됐을 거라 본다.


--------------------------------------------------------------------------------
/git/02-remote-repo,checkout.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-10-10 16:07:32
  2 | 
  3 | git 기초 2 - 원격 저장소 만들고 로그인하기, 소스 되돌리기
  4 | ========================================================
  5 | 
  6 | 세미나 날짜 : 2013-05-03
  7 | 
  8 | 원격 저장소 생성하기
  9 | ---------------
 10 | 
 11 | 원격 저장소를 생성하려면, 서버로 사용할 컴에서 작업을 해야 한다.
 12 | 
 13 | SVN은 흔히들 저장소 하나를 만들고 각 폴더를 한 프로젝트로 사용했을 거다. git는 그럴 필요가 없다. 그냥 프로젝트 하나를 저장소 하나로 만들면 된다.
 14 | 
 15 | ### 빈 원격 저장소 생성하기 ###
 16 | 
 17 | 비어 있는 원격 저장소를 생성한 다음, 로컬 컴퓨터에서 `clone` 받고 `push`를 하면서 시작하는 것도 방법이다. 그렇게 하려면 원격 프로젝트 저장소로 사용할 폴더로 가서 이렇게 `--bare`라고 옵션을 붙여서 명령을 내리면 된다. 원격 저장소로 사용할 폴더는 관례상 `.git`라는 접미사(suffix)를 붙인다. 알아 두자.
 18 | 
 19 |     git --bare init
 20 | 
 21 | 그러면 그 폴더가 원격 저장소가 된다. 접속을 어떻게 하는지는 뒤에서 다룬다.
 22 | 
 23 | ### 이미 있는 프로젝트를 원격 저장소로 만들기 ###
 24 | 
 25 | 일단 원격 저장소를 둘 Server컴에 `.git` 폴더 없이 소스만 다 복사하든가, 아니면 로컬에 있는 git 저장소를 통째로 Server컴으로 복사를 뜬다. `clone`을 하든, `.git`까지 포함해서 `scp`를 하든 소스만 복사를 뜨든 뭐 알아서 하란 말이다. 물론 소스만 복사를 뜨면 기존 git commit history는 날아가 버리는 거겠지만.
 26 | 
 27 | 복사 뜬 프로젝트가 git 저장소가 아니라고 가정하자. 그럼 우선 git 저장소로 만들어 줘야 한다. `git init`이라고 쳐서 저장소로 만들고, `.gitignore`에 무시할 파일들을 적어 주고, `git add .` 명령으로 모든 파일과 폴더를 git에 추가한 다음, `git commit -a` 명령으로 추적을 시작하자. 이러면 준비완료다. 
 28 | 
 29 | 만약 서버에 카피뜬 저장소가 이미 git 저장소라면 앞의 과정은 생략해도 되겠다.
 30 | 
 31 | 여튼 방금 복사 뜬 서버쪽 저장소의 위치가 `/git-repos/my-project`라고 치자. 그럼 어떻게 할까? 일단 원격 저장소로 만들 폴더를 만든다.
 32 | 
 33 |     mkdir /git-repos/my-project.git
 34 | 
 35 | 이렇게 치면 폴더가 만들어지고... 다음으로 그냥 `clone`을 뜨면 된다. 단, 아래 명령어를 보면 알 수 있겠지만, `--bare`라는 옵션을 줘야 한다. 이게 원격 저장소를 만드는 옵션이다.
 36 | 
 37 |     git clone --bare /git-repos/my-project /git-repos/my-project.git
 38 | 
 39 | 이러면 원격 저장소 생성 완료.
 40 | 
 41 | 아, 내 컴에 원격 저장소를 만든 다음 그걸 서버컴으로 통째로 복사해 옮기는 것도 방법이다.
 42 | 
 43 | ### `--bare` - 벌거벗은 저장소 ###
 44 | 
 45 | 원격 저장소와 로컬 저장소의 차이는 working copy를 갖고 있냐 없냐밖에 없다. 로컬 저장소의 `.git` 안에 있는 것들이 원격 저장소에선 밖으로 나와 있다. 그뿐이다. 그래서 bare, 벌거벗은 저장소인 거다. 
 46 | 
 47 | 원격 저장소 접속
 48 | ------------
 49 | 
 50 | 와우 원격 저장소를 만드는 게 이렇게 쉽다니. SVN에 비해서 스트레스가 훨씬 적다. SVN은 저장소마다 인증 문제를 처리해야 해서 상당히 귀찮았단 말이다. 그런데 git는 ssh로 다 처리해 버리니, 저장소 그 자체를 만드는 게 상당히 간결해진 것 같다. 여튼, 저장소 로그인 문제는 뒤에 다루고 이번엔 어떻게 원격에서 접속할 것인지를 다룬다.
 51 | 
 52 | 원격 저장소로 접속하는 방법은 다양하다. git는 `http`, `https`, `git`, `ssh` 프로토콜을 지원한다. 자세한 내용은 [《Pro Git》](http://git-scm.com/book/ko/Git-%EC%84%9C%EB%B2%84)을 참고할 것을 권한다. 여기서는 소규모 비공개 작업 팀에게 적합하다고 생각되는, ssh 접속만 다룬다.
 53 | 
 54 | 아까 `/git-repos/my-project.git`를 Sever컴에 만들었다고 치자. Client컴은 여기에 어떻게 접속해야 할까? Server컴엔 원래 ssh로 접속할 수가 있었다고 가정하자. ssh 접속용 ID는 `left21wm`이라고 하자. 그리고 Server컴은 소규모 팀답게 IP가 `192.168.0.100`이다. 그러면 Client컴 쪽에서 아래처럼 `clone`을 하면 된다.
 55 | 
 56 |     git clone left21wm@192.168.0.100:/git-repos/my-project.git
 57 | 
 58 | 이럼 끝이다. 이렇게 `clone`을 해왔다면, 그 다음부턴 지난 세미나때 배웠던 것처럼 `git add .`과 `git commit`으로 로컬에 작업 내역을 저장하고 `git push origin master` 명령어로 서버와 통신하면서 작업을 하면 끝이다.
 59 | 
 60 | ### 팀원 모두가 `left21wm` 아이디로 접속한다고? ###
 61 | 
 62 | 그렇다. `left21wm` 아이디로 팀원 모두가 접속하면 된다. 어차피 `git commit`은 내 컴퓨터에 내 자격증명을 바탕으로 하는 것이다. 내 자격증명은 첫 번째 세미나에서 `git config --global user.name "myname"`와 `git config --global user.email "mymail@email.com"`로 했었다. `commit`한 사람은 바로 이 자격증명으로 기록된다. 어디에? 내 컴퓨터의 저장소에 말이다. 
 63 | 
 64 | `git push`를 하게 되면 내 컴에 기록된 commit history를 서버 컴에 밀어넣게 된다. commit한 사람의 이름이 바뀌지는 않는다. ssh 접속은 원격 git 저장소에 로그인하는 게 아니라, 원격 Sever컴에 로그인하는 것이다. Sever컴에 로그인한 다음 git commit history를 `push`하는 것이다. jpg를 카피한다고 jpg 안에 있는 EXIF 태그가 변경되는 게 아닌 것처럼, git를 `push`한다고 git commit history 안에 있는 작성자가 변경되지는 않는다는 말이다.
 65 | 
 66 | ### 평소에 사용하는 ssh 계정을 사용해도 되지만 git 전용 계정을 만드는 것도 좋다 ###
 67 | 
 68 | Server컴에 git 전용 계정을 만들고, 해당 계정은 git 명령어만 사용할 수 있도록 설정하는 것은 보안에 도움이 될 것이다. 사용자를 만드는 방법은 다음과 같다.
 69 | 
 70 |     sudo adduser git
 71 | 
 72 | 이 명령 내리면 패스워드 입력하라고 나온다. 그건 입력하면 되고. Full Name도 입력하라고 한다. 뭐 대충 입력해 준다. 그런데 갑자기 룸 넘버 묻고 전화번호 묻고 막 이런다. 룸 넘버부터는 그냥 다 엔터치면 된다. 성실히 적고 싶으면 적든가.
 73 | 
 74 | 여튼 이렇게 터미널에서 사용자를 만드는 건 무지하게 쉽더라.
 75 | 
 76 | 물론 저장소의 소유자를 방금 만든 저 git 계정으로 돌리는 걸 잊지 말기 바란다.
 77 | 
 78 |     sudo chown -R git:git /git-repos
 79 | 
 80 | 만약 git 계정이 /git-repos 폴더에 읽기 권한만 있고 쓰기 권한이 없다면 쓰기는 할 수 없게 된다. ssh로 간단한 권한 조정은 이렇게 할 수 있는 것이다. git 계정은 읽기 쓰기를 다 할 수 있도록 설정하고, git-readonly 같은 계정을 또 만들어서 저장소를 읽기만 할 수 있게 해 두는 식으로 말이다.
 81 | 
 82 | 자, 여튼간에 그러면 앞으로는 Client컴에서 이렇게 `clone`하면 되겠다.
 83 | 
 84 |     git clone git@192.168.0.100:/git-repos/my-project
 85 | 
 86 | ### git 계정은 git 명령어만 사용할 수 있도록 해볼까 ###
 87 | 
 88 | git 명령어만 사용할 수 있도록 설정을 하려면 아래 절차를 따른다. 일단, Server컴에 들어가서, `git-shell`이 어디에 있는지 찾는다. 아래 명령어로 찾으면 된다.
 89 | 
 90 |     which git-shell
 91 | 
 92 | `which`는 전역에서 사용하는 명령어의 실제 위치를 알려 주는 명령어다. 내 우분투 서버는 이런 결과를 출력한다.
 93 | 
 94 |     /usr/bin/git-shell
 95 | 
 96 | 자, 이걸 기억해 놓고 다음으로 넘어가자. 이렇게 치자.
 97 | 
 98 |     sudo mkdir /home/git/git-shell-commands
 99 |     sudo chown git:git /home/git/git-shell-commands
100 | 
101 | 위 명령어는 `git-shell`을 활성화하기 위해 필요한 폴더를 만들고 해당 폴더를 git 계정 것으로 만드는 명령이다. (물론 git 계정으로 로그인해서 폴더를 만들면 권한 부분은 신경 안 써도 된다.)
102 | 
103 | 이제 `git-shell`을 쓸 준비가 됐으니, git 계정이 사용할 쉘을 `git-shell`로 바꾸는 작업을 하자.
104 | 
105 | 아래 명령어로 사용자 계정 문서로 들어간다.
106 | 
107 |     sudo nano /etc/passwd
108 | 
109 | 보통 터미널 에디터로 vim을 쓰던데, 터미널 세대가 아닌 나는 nano가 더 편하더라. 여튼간에 자신이 편한 에디터를 사용하면 된다.
110 | 
111 | 그리고 다음과 같이 `git:`로 시작하는 줄을 찾는다. 
112 | 
113 |     git:x:1000:1000::/home/git:/bin/bash
114 | 
115 | 마지막 줄의 `/bin/bash`가 해당 계정이 사용할 쉘 프로그램을 명시해 주는 부분인 거 같다. 이 부분은 사용하는 시스템마다 다르니까 이 부분이 다르다고 당황해 하지는 말자. 《Pro Git》의 예제에는 이 부분이 `/bin/sh`라고 나온다. 
116 | 
117 | 자, 이제 이 부분을 아까 `which git-shell` 해서 나왔던 결과로 교체해 준다. 나 같은 경우는 `/usr/bin/git-shell`이라고 나왔으니까 그렇게 바꿨다. 여튼 그래서 결과적으로 위의 줄은 아래처럼 바뀔 것이다.
118 | 
119 |     git:x:1000:1000::/home/git:/usr/bin/git-shell
120 | 
121 | 이제 저장하고 나온 다음 아래 명령어로 git 계정에 접속해 보자.
122 | 
123 |     su git
124 | 
125 | 아마도 결과가 버전에 따라 다른 것 같은데, 두 가지 경우 모두 성공이다. 내가 테스트해 본 버전이 두 개고, 굳이 변천사 같은 걸 찾아 볼 필요는 없는 것 같아서 테스트한 버전만 적는다.
126 | 
127 | ### 1.8.1.2 버전에서 ###
128 | 
129 | `git>` 라고 표시되면 성공! 한 번 `ls` 명령어를 쳐 보자. `unrecognized command 'ls'`라고 나온다면 확실히 성공인 거다.
130 | 
131 | ### 1.7.0.4 버전에서 ###
132 | 
133 |     fatal: What do you think I am? A shell?
134 | 
135 | 이런 메세지가 나오고 로그인이 안 된다. 해석하면, "치명적 오류: 내가 쉘이라고 생각하니?" 정도 되겠다. 역시 이런 메세지가 나와도 성공이다.
136 | 
137 | ### 22번 외의 포트 ###
138 | 
139 | ssh의 기본 포트는 22다. 그런데 보안 때문에 22번 포트를 사용하지 않는 경우도 있다. 그런 경우엔 아래처럼 사용하면 된다. 포트를 52222번을 사용한다고 가정하자.
140 | 
141 |     git clone ssh://git@192.168.0.100:52222/git-repos/my-project
142 | 
143 | 이러면 된다. 포트가 22번이 아닌 경우엔 앞쪽에 `ssh://`라고 프로토콜을 밝혀 줘야 하더라.
144 | 
145 | Client컴에서, 내 git 저장소가 어느 원격 저장소에 연결돼 있는지 보려면 아래처럼 써 준다.
146 | 
147 |     git remote -v
148 | 
149 | 그럼 쭉 나온다. 뭐 사실 기본적으로 `git help`라고 치면 `git` 명령어 바로 다음에 칠 수 있는 명령어들이 나오고, `git help remote` 하는 식으로 치면 해당 git 명령어를 사용하는 방법이 상당히 자세히 나오니까 궁금한 거 있으면 그냥 help 쳐 보면 된다.
150 | 
151 | 소스 되돌리기
152 | ----------
153 | 
154 | SVN에서 `checkout`은 원격 저장소에 있는 것을 최초로 받아 오는 것이다. `update`는 원격 저장소와 자신의 working copy를 합치는 것이고, `revert`는 원격 저장소의 것으로 내 working copy를 되돌리는 것이다. 
155 | 
156 | git에서는 최초로 원격 저장소에 있는 것을 받아 오는 것은, `clone`이다. 한 working copy를 받아 오는 게 아니라 저장소를 통으로 복사해 오기 때문에 `clone`이란 표현이 적절해 보인다. 그리고 `pull`이 원격 저장소 (개념을 좀더 쉽게 하기 위해 내 멋대로 말을 만들면, '다른 저장소')에 있는 것을 '땡겨' 와서 내 저장소와 합치는 것이고, `checkout`은 원격 저장소로 내 저장소를 덮어 쓰는 것이다. (`checkout`은 `branch`에서도 사용하는데, 여기선 패스.)
157 | 
158 | ### 명령어 정리 ###
159 | 
160 | 갑자기 좀 쌩뚱맞지만 몇 가지 명령어를 SVN과 비교해서 정리하면 이렇다.
161 | 
162 | * SVN : git
163 | * `checkout` : `clone`
164 | * `update` : `pull`
165 | * `revert` : `checkout`
166 | * `commit` : `push`
167 | 
168 | 다음 시간엔
169 | --------
170 | 
171 | 다음 시간엔 git 원격 통신을 암호 입력 없이 하는 방법을 알아 본다. 그리고, 충돌을 해결하는 방법과 branch를 만들고 활용하는 방법을 알아 본다.


--------------------------------------------------------------------------------
/git/03-branch,conflict.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-10-10 16:07:32
  2 | 
  3 | git branch 활용하기, 충돌 관리하기
  4 | ===============================
  5 | 
  6 | 세미나 날짜 : 2013-10-03
  7 | 
  8 | branch가 필요한 이유
  9 | ------------------
 10 | 
 11 | branch를 엄청난 속도로 만들고 통합할 수 있는 것이야말로 git의 최대 장점이라고 생각한다. 그러니 일단은 활용을 하는 게 좋겠다. 검색해 보면 작업과정(Workflow)에 따라 branch를 어떻게 활용하는지도 찾아볼 수 있다. 그러나 일단은 개인적, 기본적인 것부터 활용을 해 보자. 그래서 익숙해져야 작업과정에 따른 다양한 시나리오를 그려 볼 수 있을 것 같다. (자세한 시나리오는 ['이클립스로 GIT 사용하기'](http://www.slideshare.net/UyeongJu/git-15379130)나 ['분산 환경에서의 Git - 분산 환경에서의 Workflow'](http://git-scm.com/book/ko/%EB%B6%84%EC%82%B0-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98-Git-%EB%B6%84%EC%82%B0-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98-Workflow)를 참고하자. ['Git 브랜치 - 브랜치 Workflow'](http://git-scm.com/book/ko/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98-Workflow)에 나오는 Topic branch가 이 예제에서 설명하는 branch 종류다.)
 12 | 
 13 | branch를 기본적으로 활용하는 것은 아주 쉽다. 다음 시나리오를 머리에 그려 보자.
 14 | 
 15 | 첫 화면(index)을 대대적으로 개편하고 있는 상황이다. 지금 마무리 단계에 있어서 사흘 후면 런칭을 할 수 있다. 당연히 서비스되고 있는 첫 화면은 예전 화면이고, 지금 개편하고 있는 것은 로컬에서 작업하고 있다. 그런데 버그 신고가 들어왔다. 현재 서비스되고 있는 첫 화면의 메인 상품을 변경했더니 슬라이드가 다 깨진다! (왜 깨지는지 따지지는 말자. 그냥 버그다.)
 16 | 
 17 | 어떻게 해야 할까? 세 가지 선택지가 있다.
 18 | 
 19 | 1. 버전 관리 시스템을 사용하지 않는 경우 : 좀 위험하긴 하지만 FTP로 들어가서 온라인 디버깅을 한다.
 20 | 1. 버전 관리 시스템을 사용하지만 branch를 사용하지 않는 경우 : 버전 관리 시스템에서 개편 작업 전으로 돌아가서 버그를 고친다. 개편 index에는 잡은 버그를 수동으로 반영한다.
 21 | 1. 버전 관리 시스템을 사용하고, branch도 사용하는 경우 : master branch로 돌아가서 버그를 고친 뒤 개편작업 branch로 돌아온다. 개편작업 branch에서 `git rebase master`를 해 디버그한 코드를 branch에도 반영한다.
 22 | 
 23 | 딱 봐도 세 번째가 가장 깔끔하다는 걸 알 수 있을 거다. 사실 버그가 간단히 잡히는 거고 개편작업도 규모가 크지 않은 거라면 1이나 2도 별로 문제가 안 될 수 있다. 하지만 개편의 규모가 크고 버그도 수정하는 데 꽤 많은 작업을 요하는 것이라면? branch는 필수적이다.
 24 | 
 25 | branch 연습으로 들어가기 전에 개념을 하나 익히자. branch 없이 작업한다는 말은, 하나의 branch에서 작업한다는 말로 이해하면 되겠다. branch를 만들지 않아도 우리는 master라는 branch에서 작업을 하고 있었던 거다. 새로운 branch를 만든다는 것은 master가 아닌 branch를 만든다는 것으로 이해하면 되겠다.
 26 | 
 27 | 그럼 간단하게 branch 연습을 해 보자.
 28 | 
 29 | 아래와 같은 코드가 있다.
 30 | 
 31 |     <ul class="unordered-list">
 32 |         <li class="list-item">이것은 1번째 li입니다.</li>
 33 |         <li class="list-item">이것은 2번째 li입니다.</li>
 34 |         <li class="list-item">이것은 3번째 li입니다.</li>
 35 |         <li class="list-item">이것은 4번째 li입니다.</li>
 36 |         <li class="list-item">이것은 5번째 li입니다.</li>
 37 |         <li class="list-item">이것은 6번째 li입니다.</li>
 38 |     </ul>
 39 | 
 40 | 이 코드는 현재 커밋된 상태다. 자, 인덱스를 개편해야 한다. branch를 만들자. branch 이름은 renewal이다. 현재 코드가 모두 커밋돼 있어야 branch를 만들 수 있으니 커밋을 잊지 말자.
 41 | 
 42 |     git branch renewal
 43 | 
 44 | branch를 만들었으면 이제 만든 branch로 옮겨 가 보자.
 45 | 
 46 |     git checkout renewal
 47 | 
 48 | 이렇게 하면 아래와 같은 메시지가 나오면서 현재 branch를 알려 준다.
 49 | 
 50 |     Switched to branch 'renewal'
 51 | 
 52 | 현재 branch가 어딘지 알려면 간단하게 `git status`라고 치면 된다. 첫 줄에 `# On branch renewal`라고 나올 거다.
 53 | 
 54 | 인덱스를 개편하면서 목록 아래에 '더 보기' 버튼을 달았다. 그래서 코드는 아래처럼 됐다.
 55 | 
 56 |     <ul class="unordered-list">
 57 |         <li class="list-item">이것은 1번째 li입니다.</li>
 58 |         <li class="list-item">이것은 2번째 li입니다.</li>
 59 |         <li class="list-item">이것은 3번째 li입니다.</li>
 60 |         <li class="list-item">이것은 4번째 li입니다.</li>
 61 |         <li class="list-item">이것은 5번째 li입니다.</li>
 62 |         <li class="list-item">이것은 6번째 li입니다.</li>
 63 |     </ul>
 64 |     <a href="#">더 보기</a>
 65 | 
 66 | 커밋도 하자.
 67 | 
 68 | 어이쿠, 아직 개편이 다 끝나지 않았는데 원래 페이지 수정 요청이 들어왔다. `ul`위에 제목을 달아 달라는 거다. 평소때라면 당황했겠지만, 이제 branch를 사용하고 있으니 걱정할 거 없다. 메인 branch인 master branch로 돌아가자.
 69 | 
 70 |     git checkout master
 71 | 
 72 | 이렇게 하면 master branch로 돌아올 수 있다. 아래와 같은 메시지를 만났다면 안심!
 73 | 
 74 |     Switched to branch 'master'
 75 | 
 76 | `git log`도 한 번 쳐 보자. 아까 renewal branch에서 커밋한 내용은 나오지 않을 것이다.
 77 | 
 78 | master branch에서 코드를 아래처럼 수정했다.
 79 | 
 80 |     <h2>Branch 연습용 목록</h2>
 81 |     <ul class="unordered-list">
 82 |         <li class="list-item">이것은 1번째 li입니다.</li>
 83 |         <li class="list-item">이것은 2번째 li입니다.</li>
 84 |         <li class="list-item">이것은 3번째 li입니다.</li>
 85 |         <li class="list-item">이것은 4번째 li입니다.</li>
 86 |         <li class="list-item">이것은 5번째 li입니다.</li>
 87 |         <li class="list-item">이것은 6번째 li입니다.</li>
 88 |     </ul>
 89 | 
 90 | 이제 커밋을 하고, renewal branch로 돌아가자.
 91 | 
 92 |     git commit -am "제목 추가"
 93 |     git checkout renewal
 94 | 
 95 | 그럼 다시 renewal branch로 돌아온 걸 확인할 수 있을 것이다. index.html을 열어 보면 master branch에서 작업한 `h2`는 없다는 걸 확인할 수 있을 거다.
 96 | 
 97 | 그런데 개편작업이 끝나도 제목은 있어야 한다. 제목 하나 추가하는 건 어렵진 않은데, branch 연습중이니 git 기능을 이용하자. 그리고 지금이야 예제니까 간단하지 현실에선 이거보다 복잡한 일이 많이 벌어진다. 그럼 어떻게 해야 할까? master branch에 있는 걸 renewal branch로 가져오면 된다.
 98 | 
 99 |     git rebase master
100 | 
101 | 그러면 아래와 같은 메시지가 나오면서 작업이 진행된다.
102 | 
103 |     First, rewinding head to replay your work on top of it...
104 | 	Applying: 더 보기 추가
105 | 
106 | 이제 `git log`를 쳐 보자. 그러면 아래처럼 log를 확인할 수 있다.
107 | 
108 |     commit 26ac074b70e667222a51c882c96e2517aab66ba8
109 |     Author: mytory <mytory@gmail.com>
110 |     Date:   Thu Oct 3 01:48:25 2013 +0900
111 |     
112 |         더 보기 추가
113 |     
114 |     commit 8d6fe1d6a6d4bd5dec10e46610f0eaf86df27825
115 |     Author: mytory <mytory@gmail.com>
116 |     Date:   Thu Oct 3 01:48:38 2013 +0900
117 |     
118 |         제목 추가
119 |     
120 |     commit 61aa525f5fbbe1f671e45fa6b12a69c96b2f2e06
121 |     Author: mytory <mytory@gmail.com>
122 |     Date:   Thu Oct 3 01:26:42 2013 +0900
123 |     
124 |         initial
125 | 
126 | master에서 작업한 '제목 추가'가 '더 보기 추가'보다 앞에 끼어든 것을 확인할 수 있다.
127 | 
128 | ### rebase 개념
129 | 
130 | rebase는 단어 그대로 재구축이다. 근데 뭘 어떻게 재구축하는지 기억하는 게 중요하다. 현재 branch를 재구축하는 거다. 명령을 내릴 때는 뭘 기반으로 재구축하는 것은지를 명시해 주는 것이다. 그래서 `git rebase master`는 'master branch를 바탕으로 현재 branch를 재구축하라'는 명령이 된다.
131 | 
132 | 다른 branch의 내용을 끌어오는 것으로는 `git merge master`도 있다. 개념은 똑같은데 '현재 branch에 master branch를 가져와서 합쳐라'라는 뜻이 된다. rebase가 과거 커밋들을 바탕으로 commit history를 재작성하는 반면에 merge는 합친 내용으로 현재 branch에 새로운 커밋을 하게 된다. rebase는 가져온 branch에 commit이 많았다면, 그만큼 과거의 commit이 많이 생기게 되지만, merge는 변경 내역을 가져와서 다 합친 다음 새로운 커밋을 한 번만 한다.
133 | 
134 | 궁금하면 해 보시라. merge보다 rebase를 쓸 것을 권장하기 때문에 굳이 merge 예시를 해 보고 넘어가지는 않겠다.
135 | 
136 | 충돌 관리
137 | --------
138 | 
139 | 앞선 예시를 바탕으로 충돌 관리 연습까지 계속 가 보자.
140 | 
141 | 버전 관리 툴을 사용할 때 초보자들이 가장 무서워하고 잘 못 다루는 게 충돌(conflict)인 것 같다. 사실 별 거 아닌데 말이다. 같은 부분을 두 개발자가 동시에 고친 다음 한 명이 먼저 push를 하고, 다음 사람이 push를 하면 충돌이 일어난다.
142 | 
143 | 혼자 일할 때도 충돌을 만날 수 있다. 우리가 연습할 게 이건데, branch에서 작업을 하다가 master에서 뭔가 고친 다음, branch에서 또 같은 줄의 것을 고치면 충돌이 일어난다. stash 상태에서 pull을 한 뒤 `git stash apply`를 했을 때도 충돌이 벌어질 수 있다. 정확힌 모르겠는데 같은 걸 동시에 고치지 않았는데도 충돌이 나는 경우도 있다. 여튼, git가 알아서 합치지 못하는 상황이 벌어지면 충돌이 벌어진다.
144 | 
145 | 만능 해법이 있다. git가 시키는대로 하면 된다.
146 | 
147 | 아까 예제에서 계속 가 보자. renewal branch에서 계속 작업할 거다. class명을 BEM 기반으로 사용하기로 결정해서 아래처럼 고쳤다.
148 | 
149 |     <h2>Branch 연습용 목록</h2>
150 |     <ul class="index-list">
151 |         <li class="index-list__item">이것은 1번째 li입니다.</li>
152 |         <li class="index-list__item">이것은 2번째 li입니다.</li>
153 |         <li class="index-list__item">이것은 3번째 li입니다.</li>
154 |         <li class="index-list__item">이것은 4번째 li입니다.</li>
155 |         <li class="index-list__item">이것은 5번째 li입니다.</li>
156 |         <li class="index-list__item">이것은 6번째 li입니다.</li>
157 |     </ul>
158 |     <a href="#">더 보기</a>
159 | 
160 | 이제 `git commit -am "BEM 방식 클래스명"`이라고 커밋을 해 준 뒤, `git checkout master` 명령으로 master branch로 돌아가자.
161 | 
162 | index.html을 아래처럼 고쳤다. 제목과 목록, 더 보기를 합쳐서 index-box라고 이름을 지어야 할 일이 생긴 거다. 아직 개편 전인데 말이다.
163 | 
164 |     <div class="list-box">
165 |         <h2 class="list-box__title">Branch 연습용 목록</h2>
166 |         <ul class="unordered-list">
167 |             <li class="list-item">이것은 1번째 li입니다.</li>
168 |             <li class="list-item">이것은 2번째 li입니다.</li>
169 |             <li class="list-item">이것은 3번째 li입니다.</li>
170 |             <li class="list-item">이것은 4번째 li입니다.</li>
171 |             <li class="list-item">이것은 5번째 li입니다.</li>
172 |             <li class="list-item">이것은 6번째 li입니다.</li>
173 |         </ul>
174 |     </div>
175 | 
176 | `list-box`라는 클래스가 전체를 감쌌다. `h2`에도 클래스가 붙었다. `git diff`라고 쳐 보면 아래처럼 나온다. 맨 앞에 `-`가 붙은 게 삭제된 것, `+`가 붙은 게 추가된 것이다.
177 | 
178 |     diff --git a/index.html b/index.html
179 |     index 49aefc6..29296ed 100644
180 |     --- a/index.html
181 |     +++ b/index.html
182 |     @@ -5,15 +5,17 @@
183 |          <title>Git Branch Example</title>
184 |      </head>
185 |      <body>
186 |     -    <h2>Branch 연습용 목록</h2>
187 |     -    <ul class="unordered-list">
188 |     -        <li class="list-item">이것은 1번째 li입니다.</li>
189 |     -        <li class="list-item">이것은 2번째 li입니다.</li>
190 |     -        <li class="list-item">이것은 3번째 li입니다.</li>
191 |     -        <li class="list-item">이것은 4번째 li입니다.</li>
192 |     -        <li class="list-item">이것은 5번째 li입니다.</li>
193 |     -        <li class="list-item">이것은 6번째 li입니다.</li>
194 |     -    </ul>
195 |     +    <div class="list-box">
196 |     +        <h2 class="list-box__title">Branch 연습용 목록</h2>
197 |     +        <ul class="unordered-list">
198 |     +            <li class="list-item">이것은 1번째 li입니다.</li>
199 |     +            <li class="list-item">이것은 2번째 li입니다.</li>
200 |     +            <li class="list-item">이것은 3번째 li입니다.</li>
201 |     +            <li class="list-item">이것은 4번째 li입니다.</li>
202 |     +            <li class="list-item">이것은 5번째 li입니다.</li>
203 |     +            <li class="list-item">이것은 6번째 li입니다.</li>
204 |     +        </ul>
205 |     +    </div>
206 |      </body>
207 |      </html>
208 |     \ No newline at end of file
209 | 
210 | 들여쓰기만 변경돼도 삭제된 것으로 처리되는 것을 알 수 있다. 아래 명령어로 커밋을 하고 renewal branch로 돌아가자.
211 | 
212 |     git commit -am "list-box 클래스 추가하고, h2에도 list-box__title 클래스 매김."
213 |     git checkout renewal
214 | 
215 | master에서 변경된 사항을 끌어와야 하니 `git rebase master` 명령을 내려 보자. 그러면 아래처럼 충돌이 발생한다.
216 | 
217 |     First, rewinding head to replay your work on top of it...
218 |     Applying: 더 보기 버튼 추가
219 |     Using index info to reconstruct a base tree...
220 |     M	index.html
221 |     Falling back to patching base and 3-way merge...
222 |     Auto-merging index.html
223 |     CONFLICT (content): Merge conflict in index.html
224 |     Failed to merge in the changes.
225 |     Patch failed at 0001 더 보기 버튼 추가
226 |     The copy of the patch that failed is found in:
227 |        /path/to/.git/rebase-apply/patch
228 |     
229 |     When you have resolved this problem, run "git rebase --continue".
230 |     If you prefer to skip this patch, run "git rebase --skip" instead.
231 |     To check out the original branch and stop rebasing, run "git rebase --abort".
232 | 
233 | 번역해 보면 이렇다.
234 | 
235 | 
236 |     우선, 작업을 처음부터 재실행하기 위해서 head로 되감습니다.
237 |     '더 보기 버튼 추가'를 적용중입니다.
238 |     base tree를 재구축하기 위해 색인 정보를 사용중입니다.
239 |     M index.html (index.html이 수정됐다는 뜻)
240 |     base 재구축과 3방향 합치기가 잘못되는 경우에 대한 대비책을 만들고 있습니다.
241 |     index.html을 자동으로 합칩니다.
242 |     충돌 발생 (내용): index.html에서 합치기 충돌 발생
243 |     '0001 더 보기 버튼 추가' patch 실패
244 |     실패한 patch는 다음 경로에서 볼 수 있습니다.
245 |         /path/to/.git/rebase-apply/patch
246 |     
247 |     이 문제를 수정한 뒤, "git rebase --continue"를 실행하세요.
248 |     이 patch를 건너뛰려면, "git rebase --skip"을 실행하세요.
249 |     rebase를 중단하고 원래대로 되돌리려면, "git rebase --abort"를 실행하세요.
250 | 
251 | 사실 위쪽은 볼 거 없고 아래쪽 세 줄이 핵심이다. 고친 경우, 건너뛸 경우, rebase를 취소할 경우, 각각의 경우에 내려야 할 명령을 친절하게 알려 주고 있다. 메시지를 다시 보고 싶으면 `git status`를 하면 된다.
252 | 
253 | 이제 명령도 알았으니 두려워할 거 없이 고치자.
254 | 
255 | index.html을 열어 보면 아래와 같이 충돌이 난 부분이 표시돼 있다.
256 | 
257 |     <<<<<<< HEAD
258 |         <div class="list-box">
259 |             <h2 class="list-box__title">Branch 연습용 목록</h2>
260 |             <ul class="unordered-list">
261 |                 <li class="list-item">이것은 1번째 li입니다.</li>
262 |                 <li class="list-item">이것은 2번째 li입니다.</li>
263 |                 <li class="list-item">이것은 3번째 li입니다.</li>
264 |                 <li class="list-item">이것은 4번째 li입니다.</li>
265 |                 <li class="list-item">이것은 5번째 li입니다.</li>
266 |                 <li class="list-item">이것은 6번째 li입니다.</li>
267 |             </ul>
268 |         </div>
269 |     =======
270 |         <h2>Branch 연습용 목록</h2>
271 |         <ul class="unordered-list">
272 |             <li class="list-item">이것은 1번째 li입니다.</li>
273 |             <li class="list-item">이것은 2번째 li입니다.</li>
274 |             <li class="list-item">이것은 3번째 li입니다.</li>
275 |             <li class="list-item">이것은 4번째 li입니다.</li>
276 |             <li class="list-item">이것은 5번째 li입니다.</li>
277 |             <li class="list-item">이것은 6번째 li입니다.</li>
278 |         </ul>
279 |         <a href="#">더 보기</a>
280 |     >>>>>>> 더 보기 버튼 추가
281 | 
282 | 
283 | 뭣때문인지는 모르지만, 'HEAD'랑 'BEM 방식 클래스명'이랑 합치다가 git가 판단을 못 하고 멈춰선 거다. 우리는 사람이니까 명료하게 판단을 할 수 있다. 우리가 얻어야 할 코드는 위쪽의 `list-box`와 `list-box__title` 코드, 아래쪽의 더 보기 버튼이다. 두 코드를 통합해서 아래처럼 만들자.
284 | 
285 |     <div class="list-box">
286 |         <h2 class="list-box__title">Branch 연습용 목록</h2>
287 |         <ul class="unordered-list">
288 |             <li class="list-item">이것은 1번째 li입니다.</li>
289 |             <li class="list-item">이것은 2번째 li입니다.</li>
290 |             <li class="list-item">이것은 3번째 li입니다.</li>
291 |             <li class="list-item">이것은 4번째 li입니다.</li>
292 |             <li class="list-item">이것은 5번째 li입니다.</li>
293 |             <li class="list-item">이것은 6번째 li입니다.</li>
294 |         </ul>
295 |         <a href="#">더 보기</a>
296 |     </div>
297 | 
298 | 고쳤으니 저장을 하고, 아까 git가 시킨대로 명령을 내리자.
299 | 
300 |     git rebase --continue
301 | 
302 | 이렇게 명령을 내리니 이상한 메시지가 또 나온다.
303 | 
304 |     index.html: needs merge
305 |     You must edit all merge conflicts and then
306 |     mark them as resolved using git add
307 | 
308 | 해석하면 이렇다.
309 | 
310 |     index.html: 합칠 필요가 있습니다.
311 |     모든 충돌을 해결하고 합쳐야 합니다. 그리고 나서
312 |     git add를 이용해서 해결됐다고 표시하세요.
313 | 
314 | 아놔 처음부터 말해 주지. 해결 표시를 해야 계속할 수 있단다. 시키는대로 하자.
315 | 
316 |     git add index.html
317 | 
318 | 그리고 다시 `git rebase --continue` 명령을 내리자. 
319 | 
320 | 그러면 또다시 충돌이 벌어질 거다. 이번엔 'BEM 방식 클래스명'을 적용하다가 충돌이 난다. 위 순서대로 고친 뒤, `git add index.html`, `git rebase --continue`를 해 주자. 그러면,
321 | 
322 |     Applying: BEM 방식 클래스명
323 | 
324 | 이렇게 깔끔하게 한 줄만 나오고 끝난다. `git log`로 로그가 어떻게 변했는지 보자.
325 | 
326 |     commit c10a1e433b75dfe937fe55b0a43530653c4918a8
327 |     Author: mytory <mytory@gmail.com>
328 |     Date:   Thu Oct 3 02:50:45 2013 +0900
329 | 
330 |         BEM 방식 클래스명
331 | 
332 |     commit 26ac074b70e667222a51c882c96e2517aab66ba8
333 |     Author: mytory <mytory@gmail.com>
334 |     Date:   Thu Oct 3 01:48:25 2013 +0900
335 | 
336 |         더 보기 추가
337 | 
338 |     commit d2982daba131646e66591422c3ace21c9a64972e
339 |     Author: mytory <mytory@gmail.com>
340 |     Date:   Thu Oct 3 02:54:18 2013 +0900
341 | 
342 |         list-box 클래스 추가하고, h2에도 list-box__title 클래스 매김.
343 | 
344 |     commit 8d6fe1d6a6d4bd5dec10e46610f0eaf86df27825
345 |     Author: mytory <mytory@gmail.com>
346 |     Date:   Thu Oct 3 01:48:38 2013 +0900
347 | 
348 |         제목 추가
349 | 
350 |     commit 61aa525f5fbbe1f671e45fa6b12a69c96b2f2e06
351 |     Author: mytory <mytory@gmail.com>
352 |     Date:   Thu Oct 3 01:26:42 2013 +0900
353 | 
354 |         initial
355 | 
356 | 코드 수정 순서가 재배열됐다. (내 생각엔 master 수정사항이 앞으로 들어가고, 현 branch의 내용이 뒤에 들어가는 것 같다.)
357 | 
358 |     제목 추가 > list-box 클래스 추가 > 더 보기 추가 > BEM 방식 클래스명
359 | 
360 | 간단한 충돌 관리를 해 봤는데, 핵심은 이거다. "git가 시키는대로 해라." pull을 했을 때도, stash apply를 했을 때도 마찬가지다.
361 | 
362 | ### branch를 중앙 저장소에 보내기
363 | 
364 | branch를 중앙 저장소에 보내서 공동작업을 해야 할 때도 있을 거다. 원격에 저장을 하지 않으면 불안한 경우도 있을 테고 말이다. 그럴 땐 아래 명령을 사용한다.
365 | 
366 |     git push origin renewal
367 | 
368 | 전에 push를 한 상태에서 `git rebase master` 같은 걸 한 뒤 push를 하려고 하면 history가 변경됐기 때문에 push가 안 될 수 있다. 그런 경우엔 과감하게 아래 명령을 내리자.
369 | 
370 |     git push -f origin renewal
371 | 
372 | 그러면 로컬의 branch 변경이력으로 원격의 branch 변경이력을 덮어 써버린다.
373 | 
374 | 원격 branch 이름을 다르게 할 수도 있다. 물론 권장하지 않는다. 예외적인 경우에만 사용하게 될 거다.
375 | 
376 |     git push origin renewal:remote-renewal
377 | 
378 | 로컬의 저장소 두 개를 하나의 원격 서버에 각각 저장해야 했을 때 저런 걸 써 본 적이 있는데, 관리하다가 실수할까봐 엄청 긴장했었다. 그런 상황은 빨리 없애 버렸다. 불가피하게 저런 상황에 직면하더라도 빨리 상황을 없애 버리기 바란다.
379 | 
380 | branch를 master에 통합하고 삭제하기
381 | ----------------------------------
382 | 
383 | 리뉴얼이 끝나서 renewal branch를 master branch에 통합하기로 했다. 그럴 땐 아래처럼 하면 되겠다.
384 | 
385 |     git checkout master
386 |     git merge renewal
387 | 
388 | 아까는 renewal에서 master를 끌어왔지만, 이번엔 반대로 master에서 renewal을 끌어오는 거다. 사실 renewal branch에서 이미 master의 내용을 다 통합해 둔 상태이므로 실제로 일어나는 일은 fast forward(git의 커서가 renewal branch의 내용까지 앞으로 이동하는 것)다. 마지막으로 아래 명령어로 renewal branch를 제거해서 코드 혼란을 없앤다.
389 | 
390 |     git branch -d renewal
391 | 
392 | 아직 master에 통합하지 않은 내용이 renewal branch에 남아있다면 삭제되지 않으니 걱정할 것 없다. 물론 `-D` 옵션을 주면 통합되지 않은 branch도 삭제된다.
393 | 
394 | ### 팁 - stash 혹은 git reset HEAD~
395 | 
396 | branch에서 코드를 작성하다가 master branch에서 긴급하게 수정을 해야 할 게 생겼다! 그런데 아직 branch에서 작성중인 코드는 commit을 하기 싫다! 어떻게 해야 할까?
397 | 
398 | 그럴 땐 두 가지 방법 중 하나를 택하면 된다.
399 | 
400 |     git stash
401 | 
402 | 위 명령을 내리면 지금 작성중인 코드가 어딘가 다른 데로 저장되고 모든 코드가 원상태로 돌아온다. 원상태란 당연히 마지막 commit 상태를 말한다.
403 | 
404 |     git checkout master
405 | 
406 | 이후 위 명령어를 쳐서 master branch로 이동한 뒤, 코드를 수정하고 커밋까지 한 다음 아래 명령어를 사용해 수정하던 코드를 되살린다.
407 | 
408 |     git checkout my-branch
409 | 
410 | 일단 원래 작업하고 있던 branch로 돌아온다.
411 | 
412 |     git stash apply
413 | 
414 | 그리고 이렇게 하면 적용(apply)을 하면 수정중인 코드가 되살아난다.
415 | 
416 | 깔끔하게 완료!
417 | 
418 | 다른 방법도 있다. 그냥 간단하게 커밋을 한 뒤 취소하는 거다. 로컬에서 단선적으로 커밋을 하는 분산형 시스템이기 때문에 가능한 방법이다.
419 | 
420 |     git commit -am "임시"
421 | 
422 | 코드를 수정하고 돌아와서 아래 명령으로 해당 branch의 마지막 커밋을 취소한다.
423 | 
424 |     git reset HEAD~
425 | 
426 | 그러면 마지막 커밋이 취소되고 모두 수정중인 상태가 된다. (참고로 옵션없는 그냥 `git reset`은 `add`를 취소하는 명령이다. 또, pull이나 merge를 하다가 충돌이 벌어졌는데 취소하고 싶다면 `git reset`을 하고, `git checkout ...`으로 원상복구한다.)
427 | 
428 | ### 팁 - branch에서 작성중인 코드를 master로 옮기기
429 | 
430 | branch에서 한참 코드를 작성하다가, 이 코드는 branch에 있을 게 아니라 master에 있어야겠다는 생각이 들었다면? stash를 이용하면 된다.
431 | 
432 |     git stash
433 |     git checkout master
434 |     git stash apply
435 | 
436 | 그럼 stash에 넣었던 코드가 master에 적용된다.
437 | 
438 | ### 개념을 명확히!
439 | 
440 | master는 branch의 하나다. 따라서 위 예제의 master를 다른 branch로 바꿔 이해해도 모든 것이 제대로 돌아간다.
441 | 


--------------------------------------------------------------------------------
/git/README.md:
--------------------------------------------------------------------------------
 1 | - Date: 2013-09-02 16:14:31
 2 | 
 3 | 레프트21 웹개발팀 git 세미나
 4 | ======================
 5 | 
 6 | 기본적으로 터미널에 익숙하지 않고, SVN을 GUI로 주로 사용해 온 그룹에서 git 터미널 사용법을 바탕으로 개념을 좀 충실히 익혀 보고자 시작한 세미나다.
 7 | 
 8 | 참고한 텍스트는 [《pro git》](http://dogfeet.github.io/articles/2012/progit.html)이다. 
 9 | 
10 | 이 세미나는 소규모 비공개 작업 팀에게 가장 알맞은 내용일 거라고 생각한다. 우리가 그런 팀이니까.
11 | 


--------------------------------------------------------------------------------
/git/memo.md:
--------------------------------------------------------------------------------
1 | - Date: 2013-10-10 16:07:32
2 | 
3 | - __`git rm --cached filename`__ : git에서만 지우고 local 파일은 남겨 둔다.
4 | - __`git push origin local-branch`__ : 로컬 브랜치를 원격으로 푸시. 원격에 생성되는 브랜치명은 로컬 브랜치와 같음.
5 | - __`git push origin local-branch:remote-branch`__ : 로컬 브랜치를 원격으로 푸시. 원격에 생성되는 브랜치명은 지정된 것.
6 | - __`git push origin :remote-branch`__ : 원격 브랜치 삭제.


--------------------------------------------------------------------------------
/javascript/maintainable_javascript/2013-04-26-turtle_book.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | 프로그래밍 기법
  4 | ================
  5 | 
  6 | UI 인터페이스 층위 분리하기
  7 | ----------------------------
  8 | 
  9 | 사용자 인터페이스의 세 층위
 10 | 
 11 | - JavaScript: 페이지의 동작
 12 | - CSS: 겉모습
 13 | - HTML: 데이터와 의미
 14 | 
 15 | 세 층위를 되도록 느슨하게 연결해야 한다. 즉 세 층위는 서로 딱 알만큼만 알아야 한다. 그래야 필요한만큼만 영향을 주고 받고, 문제가 발생하면 어디에서 문제가 발생했는지 알기 쉬워진다. 
 16 | 
 17 | ### CSS에서 자바스크립트의 분리 ###
 18 | 
 19 | `expression()` 프로퍼티는 성능을 떨어뜨릴 뿐만 아니라, 문제가 발생하면 누구의 책임인지 알아내기 어려워진다. 
 20 | 
 21 | 	// 하지마라
 22 | 	.box { width: expression(document.body.offsetWidth + "px"); }
 23 | 
 24 | ### 자바스크립트에서 CSS 분리 ###
 25 | 
 26 | 자바스크립트에서 CSS 프로퍼티를 직접 수정하지 않는다(위치 이동하거나 크기를 조절하는 경우는 예외. 가령 애니메이션). 그렇지 않으면 페이지의 겉모습에서 생긴 문제를 해결하기 위해 자바스크립트와 CSS 둘 다를 들여다봐야 한다. 자바스크립트는 클래스를 뗐다 붙였다 하는 식으로 CSS와 소통해야 한다.
 27 | 
 28 | 	// 하지마라
 29 | 	element.style.cssText = "color: red";
 30 | 	element.style.color = "red";
 31 | 
 32 | ### HTML에서 자바스크립트 분리하기 ###
 33 | 
 34 | "onclick"과 같은 "on-" 어트리뷰트에서 함수를 호출해선 안된다. 이벤트 핸들러가 요소보다 나중에 정의되면 문제가 생긴다. 그리고 호출되는 함수의 이름을 바꾸거나, 다른 이벤트 핸들러를 할당할 때 HTML을 변경해야 한다. 그러므로 이벤트 핸들러는 스크립트에서 할당해야 한다.
 35 | 
 36 | 	<!-- 하지마라 -->
 37 | 	<button onclick="doit()" />
 38 | 
 39 | `<script>` 요소에 스크립트를 직접 쓰지도 마라.
 40 | 
 41 | ### 자바스크립트에서 HTML 분리하기 ###
 42 | 
 43 | 둘을 분리하지 않으면 마크업을 수정할 때 자바스크립트와 HTML을 둘 다 봐야 한다. 더군다나 텍스트 노드나 어트리뷰트 값 등은 이스케이프를 해야하므로 html 요소 문자열을 자바스크립트로 직접 처리하면 일이 복잡해진다. 
 44 | 
 45 | - AJAX로 서버에게 마크업을 요청하는 방법
 46 | - 클라이언트 측에서 템플릿을 쓰는 방법
 47 | 
 48 | #### 간단한 템플릿 ####
 49 | 
 50 | HTML:
 51 | 
 52 | 	<ul id="list"><!--<li id="item%s"><a href="%s">%s</a></li>-->
 53 | 	</ul>
 54 | 
 55 | Javascript:
 56 | 
 57 | 	function sprintf (text) {
 58 | 		var i = 1, args = arguments;
 59 | 		return text.replace(/%s/g, function () {
 60 | 			return (i < args.length) ? args[i++] : "";
 61 | 		});
 62 | 	}
 63 | 	function addItem (id, url, text) {
 64 | 		var template = document.getElementById('list').firstChild.nodeValue,
 65 | 		    result   = sprintf(template, id, url, text);
 66 | 		$('#list').append(result);
 67 | 	}
 68 | 
 69 | 	...
 70 | 	addItem('1','/1','item1');
 71 | 	addItem('2','/2','item2');
 72 | 	addItem('3','/3','item3');
 73 | 
 74 | 결과:
 75 | 
 76 | 	<ul id='list'><!--<li id="item%s"><a href="%s">%s</a></li>-->
 77 | 		<li id="item1"><a href="/1">item 1</a></li>
 78 | 		<li id="item2"><a href="/2">item 2</a></li>
 79 | 		<li id="item3"><a href="/3">item 3</a></li>
 80 | 	</ul>
 81 | 
 82 | - `sprintf()`의 용법은 다음과 같다:
 83 | 	
 84 | 		sprintf('안녕 %s? 내 이름은 %s야.','토끼야','거북이');
 85 | 
 86 |    결과는 다음과 같다. 
 87 | 
 88 | 		안녕 토끼야? 내 이름은 거북이야
 89 | 
 90 | - arguments 객체는 함수 실행 맥락이 시작되면서 생성되는 객체이며, 넘겨받은 인수들을 담고 있다. 
 91 | 
 92 | 전역 선언 방지
 93 | ---------------
 94 | 
 95 | 자바스크립트가 실행되면 전역 객체가 생겨서 여기에 모든 스크립트 세상의 삼라 만상이 다 들어간다. 브라우저에서는 `window`가 바로 그런 객체다. 전역으로 선언한 변수와 함수는 이 객체의 프로퍼티로 들어간다. 
 96 | 
 97 | ### 전역의 문제점 ###
 98 | 
 99 | - 이름 공간의 오염으로 인한 이름 충돌
100 | - 함수들이 전역 변수에 의존한 경우 전역 변수를 변경할 경우 어디에서 무슨 일이 벌어질지 예측하기 어려워진다. 
101 | - 전역 변수를 사용하는 함수를 제대로 테스트하려면, 실제 전역 환경과 테스트 환경을 맞춰야 한다. 즉 테스트용 환경과 실제 환경을 다 구축해야 하고, 둘이 차이가 나지 않도록 동기화해야 한다.
102 | 
103 | ### 전역을 피하는 방법 ###
104 | 
105 | - 변수 선언시 언제나 `var`를 쓴다. 
106 | - 객체를 하나 만들어서 관련된 코드를 거기에 몰아넣기
107 | - 그 객체 안에서도 관련된 코드를 객체의 프로퍼티로 묶어두기
108 | - 모듈
109 | - 바로 호출되는 익명 함수를 쓴다: 다른 스크립트와 상호작용이 전혀 없는 경우 가능.
110 | 
111 | 이벤트 처리
112 | ------------
113 | 
114 | 이벤트를 처리할 때에는 이벤트 핸들러의 동작을 분리해야 한다. 그래서 해당 함수를 호출하는 것만으로도 그 동작을 일으킬 수 있도록 해야 한다. 그렇게 하면 그 동작을 재사용할 수도 있고, 테스트를 하기 위해 매번 직접 이벤트를 발생시키지 않아도 된다. 
115 | 
116 | 한편 이벤트를 처리할 때는 이벤트 객체의 극히 일부만을 사용한다. 그러므로 이벤트 핸들러의 동작을 일으키는 함수에게는 이벤트 객체가 아니라, 이벤트 객체에서 사용할 프로퍼티를 인자로 넘겨야 한다. 그렇게 하면 이벤트 객체를 생성하지 않고도 동작을 재사용할 수 있고, 인터페이스도 더 이해하기 쉬워진다. 
117 | 
118 | 	function(event) {
119 | 		event.clientX ... 
120 | 		event.clientY ...
121 | 	}
122 | 
123 | 가 아니라
124 | 
125 | 	function(x, y) { ... }
126 | 
127 | 로 선언하고 
128 | 
129 | 	function(event.clientX,event.clientY);
130 | 
131 | 로 호출해야한다.
132 | 
133 | 한편 버블링은 막아서 이벤트 핸들러 하나만 작동하게 하는게 좋다.
134 | 
135 | 	event.preventDefault();
136 | 	event.stopPropagation();
137 | 
138 | `null` 비교 금지
139 | ----------------
140 | 
141 | 인자로 넘겨받은 값이 제대로 된 것인지 확인하려면, 넘겨받은 값을 `null`과 비교해서는 안된다. 예를 들어 배열을 넘겨받을 때만 제대로 작동하는 함수를 만들 경우, 넘겨받은 인자가 문제 없는 놈인지 확인한답시고, 인자를 `null`과 비교해서는 안된다는 것이다. 
142 | 
143 | `typeof` 연산자를 사용하면 기본 데이터 타입을 알아낼 수 있다. `typeof` 연산자가 반환하는 자바스크립트의 기본 데이터 타입은 다음과 같다
144 | 
145 | - `string`
146 | - `number`
147 | - `boolean`
148 | - `undefined`
149 | 
150 | `typeof`는 연산자이므로 되도록 괄호를 쓰지 않는다. 
151 | 
152 | 진짜로 `null`인지 아닌지를 검사하는 경우에는 `typeof` 연산자를 쓰면 안된다. `typeof` 연산자는 `null`에 대해 `object`를 돌려주기 때문이다. 그러므로 `===`나 `!==`를 사용해야 한다. 
153 | 
154 | ### 객초 참조 타입 알아내기 ###
155 | 
156 | 기본 데이터 타입을 제외한 모든 값은 참조(`reference`)다. 참조는 다른 값을 가리키는 값이다. 
157 | 
158 | 사용자 정의 객체의 경우 `typeof` 연산자는 어떤 생성자로 생성했든지 간에 모두 `object`를 돌려주기 때문에 쓸모가 없다. 생성자를 알아내서 객체의 프로토타입을 알아내려면 `instanceof`라는 이항 연산자를 쓴다. 용법은: 
159 | 
160 | 	값 instanceof 생성자명
161 | 
162 | `instanceof` 연산자는 상속받은 프로토타입도 같이 검사한다. 
163 | 
164 | 프레임을 사용할 경우 `instanceof` 연산자는 해당 프레임에서 생성된 것인지를 검사하므로, 객체를 다른 프레임으로 넘기면, 다른 프레임에도 똑같은 생성자가 있다고 하더라도 `false`가 나올 수 밖에 없다. `function`과 `array`를 넘길 대도 마찬가지다. 
165 | 
166 | ### 함수인지 알아내기 ###
167 | 
168 | 함수의 경우 `Function`이라는 생성자가 프레임 별로 따로 있어서 다른 프레임으로 넘기면 `instanceof`로 검사하면 `false`가 나온다. 이런 일을 피하려면 `typeof` 연산자를 쓰면 된다. `typeof` 연산자는 함수에 대해서 언제나 `function`을 돌려주기 때문이다. 
169 | 
170 | 다만 IE8 이하에서는 `typeof` 연산자는 DOM의 메서드에 대해 `object`를 돌려준다. 그러므로 하위 호환성을 위해 DOM의 메서드가 존재하는지 확인하려면 `in` 연산자를 이용한다. 
171 | 
172 | 	if ("querySelectorAll" in document) { ... }
173 | 
174 | ### 배열인지 알아내기 ###
175 | 
176 | 배열도 함수처럼 다른 프레임으로 넘기면, `instaceof`로 검사해도 배열이 아니라고 나온다. 그래서 더글라스 크록포드가 제안한 판별법은 다음과 같다. 
177 | 
178 | 	function isArray(value) { return typeof value.sort === "function" }
179 | 
180 | 위와 같은 기법을 오리 타이핑(duck-typing)이라고 한다. 오리 타이핑은 객체의 상속이나 클래스가 아니라 객체가 가진 메서드와 프로퍼티로 객체를 규정하는 스타일을 말한다. 이 용어는 제임스 위트콤 라일리라는 작가의 비유에서 나온 말이다.
181 | 
182 | > 오리처럼 헤엄치고, 오리처럼 꽥꽥대는 새가 있으면 그게 바로 오리다.
183 | 
184 | 그러나 오리처럼 헤엄치고, 오리처럼 꽥꽥된다고 다 오리인 것은 아니고, 이것이 덕타이핑의 약점이다. 크록포드의 방법을 쓰면 꼭 배열이 아니어도 메서드 중에 `sort`가 있으면 배열로 판별된다. 
185 | 
186 | 유리 자이체프는 다음과 같은 해결책을 제시한다. 
187 | 
188 | 	function isArray(value) {
189 | 		return Object.prototype.toString.call(value) === "[object Array]"
190 | 	}
191 | 
192 | 향후 ECMAScript5 스펙에는 `isArray` 메서드가 추가된다고 하니 좋은 소식이다. 
193 | 
194 | ### 프로퍼티 알아내기 ###
195 | 
196 | 프로퍼티 값을 직접 검사했다간 피를 볼 수도 있다. 프로퍼티 값 자체가 0이거나 `false`일 수도 있기 때문이다. 그러므로 `in` 연산자를 쓴다. 
197 | 
198 | `hasOwnProperty()`는 인스턴스의 프로퍼티인지 검사한다. 


--------------------------------------------------------------------------------
/php/2013- 11-16 PHP와 UTF-8.md:
--------------------------------------------------------------------------------
 1 | # PHP와 UTF-8
 2 | - Type: 세미나
 3 | - Tags: PHP Best Practice
 4 | - Author: 박충-
 5 | - Date: 2013-11-16 13:29:21
 6 | 
 7 | 유감이지만, PHP의 UTF-8은 병맛이다.
 8 | 
 9 | 현재 PHP는 낮은 수준에서 유니코드를 지원하지 않는다. UTF-8 문자열을 처리하기 위한 방법들은 있지만, 쉽지 않고, HTML에서 SQL, PHP까지 웹 프로그램의 거의 모든 수준을 파야 가능하다. 여기에서는 개요에 집중하기 위해 실질적인 요약만 해 둔다.
10 | 
11 | ## PHP 층위에서의 UTF-8
12 | 
13 | 두 문자열을 연결하거나 변수를 할당한 문자열처럼, 기본 문자열 활용에 있어서는 별거 없다. 반면에 `strpos()`이나 `strlen()`같은 대부분의 문자열 함수들은 특별한 고려가 필요하다. mb_어쩌고 하는 함수들도 있다(예: `mb_strpos()`, `mb_strlen()`). 이런 함수들을 멀티 바이트 문자열 함수라고 부른다. 이 멀티 바이트 문자열 함수들은 유니코드 문자열을 다루기 위해 만들었다.
14 | 
15 | 유니코드 문자열을 다룰 때는 반드시 mb_어쩌고 하는 함수들을 써야 한다. 예컨대 UTF-8 문자열에 `substr()`을 쓴다면 문자열이 깨진다. 멀티 바이트 문자열에 맞는 함수는 `mb_substr()`이다.
16 | 
17 | 난점은 mb_어쩌고 하는 함수들을 사용하는걸 매번 떠올리는 일이다. 한 번이라도 까먹으면 당신의 유니코드 문자열은 작살날거다.
18 | 
19 | 덧붙이자면, 모든 PHP 코드들 맨 위에 `mb_internal_encoding()` 함수를 써주거나 인클루드해줘야하고, 브라우저에 코드를 출력할거면 `mb_http_output()` 함수를 그 다음에 붙여줘야 한다. 모든 코드의 문자열을 명시적으로 정의하는게 머리가 덜 아플거다.
20 | 
21 | 마지막으로, 문자열을 다루는 많은 PHP 함수들은 구체적인 문자 인코딩을 추가적인 인자값으로 요한다.
22 | 
23 | ## MySQL 층위에서의 UTF-8
24 | 
25 | PHP 코드가 MySQL에 접근할 때, 모든 예방 조치에 따랐음에도 당신의 문자열이 DB에 비 UTF-8 문자열로 저장될 수 있다.
26 | 
27 | 당신의 문자열이 PHP에서 MySQL로 갈 때 UTF-8로 확실히 가기 위해, 당신의 DB와 테이블들을 utf8mb4 문자열로 확실히 설정해야 한다. 완벽한 UTF-8 지원을 위해 반드시 utf8mb4 캐릭터 셋을 사용해야 한다는걸 명심하자. UTF-8 캐릭터 셋이 아니다! 왜 그런지는 더 읽을거리를 참고하라.
28 | 
29 | ## 브라우저 층위에서의 UTF-8
30 | 
31 | PHP 코드가 UTF-8 문자열을 브라우저에 출력하게 하기 위해 `mb_http_output()` 함수를 사용해야 한다. HTML 페이지의 `<head>` 태그 안에 `<meta>` 태그를 써서 캐릭터 셋을 해라.
32 | 


--------------------------------------------------------------------------------
/php/2013-08-28 암호 저장 ― phpass 라이브러리를 이용해 암호 해시와 비교하자.md:
--------------------------------------------------------------------------------
 1 | - Type: 세미나
 2 | - Tags: PHP Best Practice
 3 | - Title: 암호 저장 ― phpass 라이브러리를 이용해 암호 해시와 비교하자
 4 | - Author: 박충*
 5 | - Date: 2013-08-30 18:19:15
 6 | 
 7 | 참고 : 이 문서는 [PHP Best Practice][pbp]의 글 중 하나를 내 나름으로 번역한 것에 주석 등 일부 변형을 가한 것이다. 원문은 [이곳][pbp:password]을 참고 바란다.
 8 | 
 9 | - [phpass][phpass] 0.3에서 테스트했다고 한다.
10 | - 공식 웹사이트에 들어가 보니, pH pass로 발음하라고 한다. ㅋ
11 | 
12 | 해싱은 사용자 암호를 DB에 저장하기 전에 보호하는 표준 방법이다. md5나 sha1같은 많은 일반적 해싱 알고리즘들은 암호 저장을 하는데 안전하지 않다. 왜냐하면 [해커들이 이런 일반적인 해싱 알고리즘들을 이용해 쉽게 해싱된 암호를 깨기 때문][link01]이다.
13 | 
14 | 패스워드를 해싱하는 가장 안전한 방법은 bcrypt 알고리즘[1]을 이용하는 것이다. 오픈 소스 [phpass][phpass] 라이브러리는 클래스를 사용하기 쉬운 기능을 제공한다.
15 | 
16 | ## 예제
17 | 
18 | 	<?php
19 | 	// phpass 라이브러리 인클루드
20 | 	require_once('phpass-0.3/PasswordHash.php');
21 |  
22 | 	// 포터블 해시 없이 초기화 (이게 더 안전하다)
23 | 	$hasher = new PasswordHash(8, false);
24 |  
25 | 	// 암호를 해시한다.  $hashedPassword는 60자의 문자열이 된다.
26 | 	$hashedPassword = $hasher->HashPassword('my super cool password');
27 |  
28 | 	// 이제 $hashedPassword의 내용이 DB에 안전하게 저장할 수 있다.
29 |  
30 | 	// 사용자가 정확한 암호를 넘겼는지 해시와 비교해 체크한다.
31 | 
32 | 	$hasher->CheckPassword('the wrong password', $hashedPassword); // false
33 |  
34 | 	$hasher->CheckPassword('my super cool password', $hashedPassword); // true
35 | 	?>
36 | 
37 | ## 팁
38 | 
39 | - 많은 소스들은 암호를 해싱하기 전에 암호에 "소금(salt)"을 칠 것을 추천한다. 그건 훌륭한 생각이고, phpass는 이미 HashPassword() 함수의 일부로 "소금"을 친다. 그렇기 때문에 (phpass를 사용하면) 일일이 "소금"을 칠 필요가 없다.
40 | 
41 | ## 더 보기
42 | 
43 | - [phpass][phpass]
44 | - [md5나 sha로 암호를 해싱하면 왜 안전하지 않을까?][link02]
45 | - [암호 안전하게 저장하기][link03]
46 | 
47 | <hr/>
48 | 
49 | [1]bcrypt : Adaptive Key Derivation Functions[2] 방식 중 하나로, 지금까지 사용되는 가장 강력한 해시 매커니즘 중 하나라고 한다. 애초에 패스워드 저장을 목적으로 설계되었다고 한다. 
50 | 
51 | [2]Adaptive Key Derivation Functions : 다이제스트를 생성할 때 솔팅과 키 스트레칭을 반복하며 솔트와 패스워드 외에도 입력 값을 추가하여 공격자가 쉽게 다이제스트를 유추할 수 없도록 하고 보안의 강도를 선택할 수 있다고.
52 | 
53 | [pbp]: https://phpbestpractices.org/
54 | [pbp:password]: https://phpbestpractices.org/#passwords
55 | [phpass]: http://www.openwall.com/phpass/
56 | [link01]: http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
57 | [link02]: http://blogs.msdn.com/b/lixiong/archive/2011/12/25/md5-sha1-salt-and-bcrypt.aspx
58 | [link03]: http://codahale.com/how-to-safely-store-a-password/
59 | 


--------------------------------------------------------------------------------
/php/2013-09-02 PHP 환경.md:
--------------------------------------------------------------------------------
 1 | - Type: 세미나
 2 | - Tags: PHP Best Practice
 3 | - Title: PHP 환경
 4 | - Author: 박충*
 5 | - Date: 2013-09-02 17:08:56
 6 | 
 7 | 참고 : 이 문서는 [PHP Best Practice][pbp]의 글 중 하나를 내 나름으로 번역한 것에 주석 등 일부 변형을 가한 것이다. 원문은 [이곳][pbp:this]을 참고 바란다.
 8 | 
 9 | ## PHP Best Practice의 문서들은 우분투 12.04 LTS에 설치된 PHP 5.3.10-1ubuntu3.6에 Suhosin-Patch를 적용한 PHP 버젼을 기준으로 하고 있습니다.
10 | 
11 | PHP는 웹에서 백만 년 된 거북이같은 놈이다. 이놈의 등딱지에는 풍부하고, 복잡하고, 배배꼬인 역사가 새겨져 있다. 공유 호스팅 환경(?) 설정은 당신이 할 수 있는 것을 제한할 수 있다.(???)
12 | 
13 | 제정신을 유지하기 위해서, 우리는 PHP의 한 버젼에 초점을 맞추기로 했다. 그 버젼은 2013년 4월 30일을 기준으로, <strong>Suhosin-Patch를 적용한 5.3.10-1ubuntu3.6</strong>이다. 이 PHP 버젼은 <strong>우분투 12.04 LTS</strong>에서 apt-get을 통해 설치할 수 있다. 다시 말 해, ㅈㄴ 많은 사람들이 쓰는 기본 버젼이다.
14 | 
15 | 아마도 PHP Best Practice의 몇몇 방법들이 오작동을 일으키거나 구버젼의 PHP에서 제대로 안돌아갈 수 있다. 그런 경우, 구버젼의 미묘한 버그나 보안 문제에 대한 연구는 당신한테 달린 문제다.
16 | 
17 | [pbp]: https://phpbestpractices.org/
18 | [pbp:this]: https://phpbestpractices.org/#version
19 | 


--------------------------------------------------------------------------------
/php/2013-10-03 이메일 보내기.md:
--------------------------------------------------------------------------------
 1 | - Type: 세미나
 2 | - Tags: PHP Best Practice
 3 | - Title: 이메일 보내기
 4 | - Author: 박충-
 5 | - Date: 2013-10-03 12:00:00
 6 | 
 7 | ## 이메일 보내기 ― PHPMailer
 8 | 
 9 | PHPMailer 5.1.에서 테스트했다.
10 | 
11 | PHP는 간단하고 쉬워 매력적으로 보이는 mail() 함수를 제공한다. 불행히도 PHP의 많은 것들이 것들이 그렇듯, mail() 함수의 간단함은 기만적인데다가 ‘간단하게’만 사용하면 심각한 보안 문제를 야기할 수 있다. (보안 문제에 대해서는 이것저것 검색해 봤지만 정확히 어떤 문제를 낳을 수 있다는건지 잘 모르겠다.)
12 | 
13 | 이메일은 PHP보다 더 끔찍한 역사를 가진 프로토콜의 집합이다. PHP의 mail() 함수를 쓰는데 있어 많은 어려움이 있다는걸 아는 것 만으로도 충분하다.
14 | 
15 | PHPMailer는 인기있고 성숙한 오픈 소스 라이브러리로, 안전한 이메일 발송을 위한 쉬운 인터페이스를 제공한다. PHPMailer는 PHP mail() 함수를 사용하는데 따르는 많은 함정이 아니라, 더 중요한 문제에 집중할 수 있게 해 준다.
16 | 
17 | ### 예
18 | 
19 | 	<?php
20 | 	// Include the PHPMailer library
21 | 	require_once('phpmailer-5.1/class.phpmailer.php');
22 | 	 
23 | 	// Passing 'true' enables exceptions.  This is optional and defaults to false.
24 | 	$mailer = new PHPMailer(true);
25 | 	 
26 | 	// Send a mail from Bilbo Baggins to Gandalf the Grey
27 | 	 
28 | 	// Set up to, from, and the message body.  The body doesn't have to be HTML; check the PHPMailer documentation for details.
29 | 	$mailer->Sender = 'bbaggins@example.com';
30 | 	$mailer->AddReplyTo('bbaggins@example.com', 'Bilbo Baggins');
31 | 	$mailer->SetFrom('bbaggins@example.com', 'Bilbo Baggins');
32 | 	$mailer->AddAddress('gandalf@example.com');
33 | 	$mailer->Subject = 'The finest weed in the South Farthing';
34 | 	$mailer->MsgHTML('<p>You really must try it, Gandalf!</p><p>-Bilbo</p>');
35 | 	 
36 | 	// Set up our connection information.
37 | 	$mailer->IsSMTP();
38 | 	$mailer->SMTPAuth = true;
39 | 	$mailer->SMTPSecure = 'ssl';
40 | 	$mailer->Port = 465;
41 | 	$mailer->Host = 'my smpt host';
42 | 	$mailer->Username = 'my smtp username';
43 | 	$mailer->Password = 'my smtp password';
44 | 	 
45 | 	// All done!
46 | 	$mailer->Send();
47 | 	?>
48 | 
49 | ## 이메일 주소 검사 ― filter_var() 함수
50 | 
51 | 사용자가 정확한 이메일 주소를 입력했는지 검사하는건 웹 어플리케이션이 당연히 해야 할 기본적인 작업(task)이다. 
52 | 
53 | 아마도 이 문제를 해결하기 위해 온라인에서 눈 돌아갈 만큼 복잡한 정규 표현식을 찾으려 하겠지만, 이메일 주소 검사를 하는 가장 쉬운 방법은 PHP에 내장된 filter_var() 함수를 사용하는 것이다.
54 | 
55 | ### 예
56 | 
57 | 	<?php
58 | 	filter_var('sgamgee@example.com', FILTER_VALIDATE_EMAIL); // Returns "sgamgee@example.com". This is a valid email address.
59 | 	filter_var('sauron@mordor', FILTER_VALIDATE_EMAIL); // Returns boolean false! This is *not* a valid email address.
60 | 	?>
61 | 
62 | ### filter_var()
63 | 
64 | filter_var() 함수는 이메일 형식 검사를 위한 FILTER_VALIDATE_EMAIL 외에도 여러가지를 기능이 있다.
65 | 
66 | - FILTER_VALIDATE_BOOLEAN : 1, true, on, yes를 받으면 TRUE로 반환한다. 그 외에는 FALSE를 반환한다. (filter_var()의) 세 번째 인자로 FILTER_NULL_ON_FAILURE 플래그를 세팅하면 0, false, off, no, ""만 FALSE를 반환하고, 그 외의 나머지 불린 타입이 아닌 값들을 받으면 NULL을 반환한다.
67 | - FILTER_VALIDATE_FLOAT : float 타입의 값을 검사한다. 소수(0.xx 같은) 검사가 가능하다. FILTER_FLAG_ALLOW_THOUSAND 플래그를 세팅하면 천 단위에 붙는 콤마(,)도 포함해 검사한다.
68 | - FILTER_VALIDATE_INT : integer 타입의 값을 검사한다. min_range와 max_range를 옵션으로 넣어서 범위 안의 값으로 검사할 수 있다.
69 | - FILTER_VALIDATE_IP : IP 주소 형식의 값을 검사한다.
70 | - FILTER_VALIDATE_URL : URL 형식의 값을 검사한다. ASCII URL만 검사를 통과할 수 있다.
71 | 


--------------------------------------------------------------------------------
/process/TDD/pt1.md:
--------------------------------------------------------------------------------
 1 | - Tags: TDD
 2 | - Type: 세미나 자료
 3 | - Date: 2013-05-13 11:03:33
 4 | 
 5 | 테스트 주도 개발이란?
 6 | ----------------------
 7 | 
 8 | 테스트 주도 개발의 목표: '잘 돌아가는 깔끔한 코드'.
 9 | 
10 | 테스트 주도 개발은 개발에서 나타나는 두려움을 관리하는 방법이다. 고통이 우리에게 "그만해!"이라고 몸이 보내는 신호이듯, '도대체 어디서부터 어디까지인지 알 수 없는 엄청난 문제가 있다'는 두려움은 개발자에게 조심하라는 신호이다.
11 | 
12 | 조심하면 좋긴한데 두려움에는 부작용도 있다.
13 | 
14 | - 자신감이 떨어진다
15 | - 의사소통이 줄어든다
16 | - 피드백이 두려워진다
17 | - 성질을 낸다
18 | 
19 | 무엇이든 개발에는 하등 도움이 안되는 것들이다. 어렵고 복잡한 것을 개발할 때는 더 그렇다. 그러므로
20 | 
21 | - 자신감을 잃지 말고 신속하고 구체적으로 파악하라
22 | - 입다물지 말것이며 분명하게 얘기하라
23 | - 피드백을 피하지 말고 도움이 되고 구체적인 피드백을 구하라
24 | - (성질머리는 알아서 다스려라)
25 | 
26 | 테스트 주도 개발의 두가지 원리
27 | --------------------------------
28 | 
29 | 1. 자동화된 테스트를 통과하지 못할 때에만 코드를 추가한다.
30 | 2. 중복을 제거한다
31 | 
32 | 말은 간단하지만, 이것을 현실에 구현할 때 함의하는 바는 더 풍부하다. 우선 다음과 같은 작업 과정을 따라야 한다. 
33 | 
34 | 1. 빨간불: 테스트를 쓴다. 제대로 돌아가기는 커녕 컴파일도 안될 수도 있다.
35 | 2. 파란불: 수단과 방법을 가리지 않고 테스트를 통과할 수 있는 코드를 되도록 빨리 쓴다.
36 | 3. 리팩터링: 테스트를 통과하면서 저지른 죄악과 중복에서 코드를 구제한다
37 | 
38 | 이런 개발 방식 하에서 생산되는 코드는 이렇다:
39 | 
40 | - 테스트 없이는 코드도 없다. 개발자는 코드를 쓰기 전에 테스트를 써야 한다.
41 | - 테스트는 코드의 한계를 긋는다. 테스트가 __요구한 만큼__만 코드를 써야 한다.
42 | - 테스트는 코드의 모든 기능을 남김 없이 테스트해야 한다
43 | - 테스트 주도 개발이 모든 코드에 적용되면, 모든 코드는 테스트에 대응하기 때문에, 개발 결과 생겨난 테스트 모음집은 시스템 전체를 테스트할 수 있다.
44 | 
45 | 이런 작업이 기술의 측면에서 함의하는 바는 다음과 같다
46 | 
47 | - 하루에도 몇 십 번씩 테스트를 할 것이므로 남에게 테스트 코드를 맡겼다간 기다리느라 하루를 다 보낼 것이다. 테스트 코드는 직접 써야 한다.
48 | - 바로 바로 테스트하고 결과를 얻을 수 있는 개발 환경이 있어야 한다.
49 | - 쉽고 빠르게 테스트하려면 컴포넌트의 상호 의존성을 최대한 줄여야 한다.
50 | 
51 | 테스트 주도 개발의 사회적 결과는 다음과 같다.
52 | 
53 | - 결함 빈도가 줄어들 것이므로, 그때 그때의 결함에 대응하는 것을 넘어서 더 나은 것을 먼저 제시하는 능동적 품질 보증 서비스를 제공할 수 있다
54 | - 뜻하지 않은 결함이 줄어들면, 프로젝트 관리자는 프로젝트 진척 상황을 정확하게 예측할 수 있다
55 | - 기술 관련 대화에서 주제가 분명해지고, 팀원들이 유기적인 협업을 할 수 있다
56 | - 매일매일 새로운 기능을 탑재한 소프트웨어를 출하할 수 있고 사업이 잘 된다
57 | 


--------------------------------------------------------------------------------
/process/TDD/pt2.md:
--------------------------------------------------------------------------------
  1 | - Date: 2013-09-02 16:14:31
  2 | 
  3 | PhpUnit 설치와 사용법
  4 | ----
  5 | 
  6 | 패키지 관리자를 쓸 수도 있지만, 일단은 가장 간단한 방법: 
  7 | 
  8 | 	$ wget http://pear.phpunit.de/get/phpunit.phar
  9 | 
 10 | 이 파일을 테스트 케이스 파일을 인자로 넘겨서 실행하면 테스트를 수행한다. 일단 실행하기 편하도록 실행 권한을 주고 `$PATH`에 등록된 경로에 집어넣는다.
 11 | 
 12 | 	$ chmod +x phpunit.phar
 13 | 	$ mv phpunit.phar ~bin/phpunit
 14 | 
 15 | 그러면 다음과 같은 식으로 사용할 수 있다.
 16 | 
 17 | 	$ phpunit [테스트 케이스]
 18 | 
 19 | 테스트 케이스
 20 | ----
 21 | 
 22 | phpunit에서 테스트 케이스는 php 클래스이고, `PHPUnit_Framework_TestCase`의 하위 클래스다.
 23 | 
 24 | 	class MyTest extends PHPUnit_Framework_TestCase {
 25 | 	}
 26 | 
 27 | 각 테스트는 `test`로 시작하는 메서드다. 메서드 이름은 무엇을 테스트하는지 알 수 있도록 쓴다. 완전한 문장으로 쓰는 사례도 많이 볼 수 있다.
 28 | 
 29 | 	class MyTest extends PHPUnit_Framework_TestCase {
 30 | 		public function test_equality () {
 31 | 			$this->assertTrue(1 == 1);
 32 | 		}
 33 | 	}
 34 | 
 35 | 각 테스트에는 검증돼야할 진술(Assertion)이 있다. 이 진술이 모두 참으로 판명 나면 테스트는 성공한다. phpunit에는 `assert`로 시작하는 각종 메서드가 있어서 이 메서드로 참/거짓 여부를 가른다. 위의 경우에는 `assertTrue`가 호출됐고, 이 메서드는 인자의 값이 `True`여야 테스트가 성공할 수 있다. `assertFalse`나 `assertEquals` 등도 이와 비슷하다.
 36 | 
 37 | `MyTest.php`로 저장하고 테스트 케이스를 한 번 테스트해보자.
 38 | 
 39 | 	phpunit MyTest.php
 40 | 
 41 | 결과물은 대략 다음과 같다.
 42 | 
 43 | 	PHPUnit 3.7.24 by Sebastian Bergmann.
 44 | 
 45 | 	.
 46 | 	
 47 | 	Time: 2 ms, Memory: 5.25Mb
 48 | 
 49 | 	OK (1 test, 1 assertion)
 50 | 
 51 | 세번째 줄에 나오는 `.`는 통과된 테스트에 대응된다. 테스트가 여럿 있고 모두 통과하면 `.....`과 같이 나올 것이다. 통과하지 못한 테스트는 `F`로 나온다. 
 52 | 
 53 | 한 테스트에 진술이 여러개 있을 수도 있다. 그런 경우 모든 진술이 참으로 판명돼야 한다.
 54 | 
 55 | ### 테스트의 정석 ###
 56 | 
 57 | - 그러나 일반적으로는 테스트 하나에 진술을 하나씩 검증하는 것이 좋다. 그래야 테스트가 실패하면 무엇이 문제인지 바로 알 수 있기 때문이다.
 58 | - 테스트는 진술이 반드시 검증되게끔 작성해야 한다. 그러므로 `if` 구문은 피해야 한다.
 59 | 
 60 | ### `assert-` 메서드들 ###
 61 | 
 62 | - `assertTrue`, `assertFalse`
 63 | - `assertEquals($expected, $actual)`, `assertSame($expected, $actual)`(둘의 차이는 `==`와 `===`의 차이라고 생각하면 된다)
 64 | - `assertContains($needle, $haystack)`, `assertNotContains($needle, $haystack)`
 65 | - `assertArrayHasKey($key, $array)`
 66 | - `assertContainsOnly($type, $variable)`
 67 | - `assertType($type, $var)`: 타입 검사
 68 | - `assertNotNull`
 69 | - `assertLessThan`, `assertGreaterThan`
 70 | - `assertStringsStartWith($prefix, $str)`, `assertStringsEndsWith($suffix, $str)`
 71 | 
 72 | 붙박이(fixture)
 73 | -----
 74 | 
 75 | 테스트를 작성하다보면 테스트가 공유하는 환경이 있을 수 있다. 가령 클래스를 테스트한다면 언제나 인스턴스를 만들 것이다. 가짜 데이터 베이스를 만드는 테스트 케이스라면 각 테스트를 마치고 데이터 베이스를 날려야 할 것이다. 모름지기 프로그래머란 매 테스트 케이스마다 같은 코드를 매번 작성하는 부지런을 떨어선 안되는 존재다.
 76 | 
 77 | 여러 테스트가 공유하는 코드를 '붙박이'(fixture)라고 한다. phpunit에서 붙박이는 `setUp()`과 `tearDown()` 메서드로 정의된다. 두 메서드는 각 테스트가 수행되기 전과 후에 호출된다. 기본 테스트 케이스 클래스에서는 그냥 빈 메서드고, 필요할 경우 테스트 케이스용 클래스에서 덮어 쓰면 된다.
 78 | 
 79 | 	class FixtureTest extends PHPUnit_Framework_TestCase {
 80 | 		private $_instance;
 81 | 		public function setUp () {
 82 | 			$this->_instance = new SomeClass('arg1', 'arg2');
 83 | 		}
 84 | 		public test1 {
 85 | 			// ... $this->_instance로 테스트를 한다. ...
 86 | 		}
 87 | 		public test2 {
 88 | 			// 마찬가지 ...
 89 | 		}
 90 | 	}
 91 | 
 92 | - 보통은 다음번 `setUp`을 호출하면서 기존 객체가 수거되기 때문에 `tearDown()`은 빈 메서드로도 충분한 경우가 많다.
 93 | - `setUp`은 매 테스트 마다 호출된다. 다른 붙박이가 필요하면 테스트 케이스를 따로 작성하는 게 보통이다. 다른 시나리오 하에서의 테스트인 만큼 테스트 케이스도 따로 작성하는 것이다. 
 94 | - 여러 테스트 케이스가 붙박이를 공유하면 코드가 구리다는 징후일 수 있다. 클래스가 잘 분리되지 않으면 그런 일이 벌어진다. 
 95 | - `setUpBeforeClass()`와 `tearDownAfterClass()`는 테스트 케이스 시작 전과 후에 호출되는 메서드다.
 96 | 
 97 | 주석(annotations)
 98 | ----
 99 | 
100 | phpdoc 형식의 주석으로 반복되는 코드를 더 줄일 수도 있다.
101 | 
102 | 예를 들어 예외를 제대로 토해내는지 검사하는 테스트가 있다.
103 | 
104 | 	public function test_exception() {
105 | 		try {
106 | 			$iterator = new ArrayIterator(42);
107 | 			$this->fail();
108 | 		} catch (InvalidArgumentException $e) {
109 | 		}
110 | 	}
111 | 
112 | 표준 PHP 라이브러리(SPL)에 포함된 `ArrayIterator` 클래스는 생성자의 인자로 정수를 받을 수 없다. 그래서 `new ArrayIterator(42)`는 예외를 토해내고 그 다음 구문이 실행되지 않는다. 예외를 토해내지 않으면 `$this->fail()`(이것은 `$this->assertTrue(false)`와 같다)이 실행되고 테스트는 실패로 끝난다. 
113 | 
114 | 예측을 불허하는 사용자의 입력값을 다루는 클래스의 경우 예외를 제대로 토해야 탈이 없다. 그래서 위와 같은 테스트가 종종 필요하다. 그런데 위 코드는 그 의도가 명확히 드러나지는 않는다. 진술을 검증하는 코드가 실행되지 않아야 통과하는 테스트이기 때문이다. 게다가 비어있는 `catch` 구문을 써야 한다는 것도 성가시다.
115 | 
116 | 그러나 phpdoc 형식으로 주석을 달아서 이런 코드를 줄일 수 있다.
117 | 
118 | 	/**
119 | 	 * @expectedException InvalidArgumentException
120 |  	 */
121 | 	public function test_exception() {
122 | 		$iterator = new ArrayIterator(42);
123 | 	}
124 | 
125 | `@expectedException`으로 어떤 예외를 토해낼지를 쓰면 알아서 phpunit은 알아서 그에 맞게 알아서 테스트를 수행한다. 
126 | 
127 | 다양한 입력 값을 시험해보고 싶다면 `@dataProvider`를 쓰면된다. 다양한 값의 참여부를 알아내는 간단한 테스트가 있다.
128 | 
129 | 	public function test_truthness () {
130 | 		$values = array(1, '1', 'hello', true);
131 | 		foreach ($values as $value) {
132 | 			$bool = (bool) $value;
133 | 			$this->assertTrue($actual);
134 | 		}
135 | 	}
136 | 
137 | `foreach` 구문은 번거롭다. `@dataProvider` 태그가 있는 주석을 달면 의도가 더 분명한 코드를 쓸 수 있다. 우선 `$values`에 해당하는 배열을 돌려주는 정적 메서드를 정의하고, 그 메서드를 테스트 메서드의 주석에서 `@dataProvider` 태그를 달아 언급한다.
138 | 
139 | 	public static function values() {
140 | 		return array(
141 | 			array(1), 
142 | 			array('1'), 
143 | 			array('on'),
144 | 			array(true)
145 | 		);
146 | 	}
147 | 
148 | 	/**
149 | 	 * @dataProvider values
150 | 	 */
151 | 	public function test_truthness ($value) {
152 | 		$bool = (bool) $value;
153 | 		$this->assertTrue($actual);
154 | 	}
155 | 
156 | 이렇게 하면 `@dataProvider`로 지정한 정적 메서드가 돌려준 배열의 각 요소로 테스트를 실행한다. 각 요소 또한 배열인데, 이것은 테스트 메서드의 인자로 넘어간다. `func_get_args()`를 출력해보면 확인해 볼 수 있을 것이다.
157 | 
158 | 주석으로 불가피한 테스트 의존성을 해결할 수도 있다. 가장 좋기로는 모든 테스트가 순서에 상관 없이 독립적으로 실행될 수 있어야 하지만 그럴 수 없는 때가 있다. 가령 어떤 클래스에서 `add()` 메서드와 `delete()` 메서드를 테스트하는데, `delete()` 메서드는 일단 `add()`가 제대로 작동해야 테스트할 수 있는 상황이 있을 수도 있다. 이럴 경우 `@depends` 태그를 달아서 의존하는 테스트를 적어주면 된다.
159 | 
160 | 	public function test_set() {
161 | 		$arr = array();
162 | 		$arr[0] = 'foo';
163 | 		$this->assertTrue(isset($arr[0]));
164 | 		return $arr;
165 | 	}
166 | 	/**
167 | 	 * @depends test_set
168 | 	 */
169 | 	public function test_unset($arr) {
170 | 		unset($arr[0]);
171 | 		$this->assertFalse(isset($arr[0]));
172 | 	}
173 | 
174 | `test_unset`는 `test_set`에 의존하는 테스트다. `@depends` 태그를 달면, 거기에 언급된 테스트가 돌려주는 값을 인자로 받아서 테스트를 수행한다. 
175 | 
176 | To be continued...
177 | --------
178 | 
179 | 다음 시간에는 Stub과 Mock 개념을 다루겠다.
180 | 


--------------------------------------------------------------------------------