Empty

01. 3D 그래픽의 이해

1. 3D 그래픽 파이프라인

1.1 게임 엔진을 구성하는 소스코드 모듈들

- User Input (사용자 입력)

- Resource Management (자원 관리)

- Loading and Rendering Graphics (그래픽 로딩과 렌더링)

- Interpreting and Executing Scripts (스크립트 해석과 실행)

- Playing Sound Effects (음향 처리)

- Artificial Intelligence (인공 지능)

1.4 좌표계

- Mesh (3차원 공간상의 객체) 를 기하학적으로 표현하기 위해선 좌표계가 필요하다.

- 2차원 좌표계(2차원 직교 좌표계, 화면(스크린) 좌표계), 3차원 좌표계(왼손 좌표계, 오른손 좌표계)

(출처 : http://msdn.microsoft.com/en-us/library/windows/apps/ff729721.aspx)

(출처 : http://blog.daum.net/jty71/15645437)

- 모델(or 지역) 좌표계와 월드 좌표계

- 모델 좌표계 : 객체의 지역적 공간(Local space)을 표현하는 좌표계(모델마다 별도의 좌표계를 갖고 있다고 가정)

- 월드 좌표계 : 게임 세계 전체를 하나의 통일된 좌표계로 표현하기 위한 좌표계(전역 좌표계)

(출처 : http://msdn.microsoft.com/en-us/library/windows/desktop/bb206365(v=vs.85).aspx)

1.5 와인딩 순서(Winding Order)

- Mesh 를 구성하는 다각형의 정점들을 나열하는 순서. 

즉, 다각형의 정점 or 모서리가 어떤 순서로 연결되는지를 나타냄.

- 은면(Back Face Culling : 카메라에서 보이지 않는 면) 제거를 수행하기 위해 사용한다.

- 시계 방향, 반시계 방향 순서가 있는데 Direct3D는 기본적으로 시계방향. (보통 반시계가 기본임)

Direct3D 기준으로 눈에 보이는 면들이 시계방향으로 와인딩 되기 때문에 
보이지 않는 면의 경우 반시계방향으로 와인딩 된다고 할 수 있다.

(출처 : http://cookiejeon.tistory.com/3)

1.6 화면 렌더링

- 화가의 알고리즘(Painter's Algorithm) : 3차원 세상을 2차원 평면에 그리는 과정이나 비효율적.

 자세한 내용은 위키백과.

( http://ko.wikipedia.org/wiki/%ED%99%94%EA%B0%80_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98 )

2. 변환 파이프라인

* 참고로 Primitive Transformation 에는 3가지 종류가 있다.

1) Translation (이동)   2) Rotation (회전)   3) Scaling (크기)

(관련 링크 : http://msdn.microsoft.com/en-us/library/windows/apps/ff729722.aspx)

# 월드 변환(World Transformation)

- 회전 변환 + 평행이동 변환을 통해 지역 좌표계로 표현된 객체의 Mesh 가 월드 좌표계로 변환되는 과정

(회전 변환 계산법 생략*), (회전을 먼저 하냐 평행을 먼저 하냐에 따라 결과가 다르다는 점 주의)

(출처 : http://goldface.tistory.com/archive/20120205)

# 카메라 변환(View, Camera Transformation)

- 월드 좌표계로 변환된 정점을 카메라 좌표계로 변환하는 것을 말한다.

- 3차원 공간이 투영되어 가상 카메라에 나타나는 2차원 평면을 카메라 평면이라 한다.

- 가상 카메라는 위치, 방향, FOV(Field of View) 와 같은 속성을 가진다.

※ FOV : 특정 방향과 특정 위치에서 어떤 물체가 보이는 지를 말한다. 

   사람의 경우 앞(Forward)을 향해 FOV를 가지고 있다. 그래서 자신의 뒤에 무엇이 있는지 볼 수 없다.

※ 화각(Viewing Angle) : 카메라에서 볼 수 있는 각도, 화각에 따라 FOV 공간의 형태가 달라진다.

아래 그림에서 Θ에 해당한다.

사람은 너무 가깝거나 or 너무 멀거나 하는 물체는 제대로 볼 수 없다.

그래서 컴퓨터 그래픽에서는 이 FOV 를 다음과 같이 View Frustum 으로 표현한다.

View Frustum 은 총 6개의 면으로 이루어져 있고 그 중 2 개는 XY 평면과 평행하다.

아래 그림에서 a 면이 Near-Z, b 면이 Far-Z 평면이라 불린다.

FOV 가 넓을수록 View Frustum 의 부피도 커지고 그만큼 시야가 넓어지는 것을 의미한다.

보통 좌표계에서 Z 축이 Forward 방향을 나타낸다. (X 축이 좌우, Y 축이 상하, Z 축이 앞뒤)

(출처 : http://msdn.microsoft.com/en-us/library/windows/apps/ff729721.aspx)

- 카메라 변환 과정

1) 카메라를 월드 좌표계의 원점으로 평행이동

2) 1)과 같은 변환을 게임 세계의 모든 객체에 적용

3) 카메라 좌표계 축들이 월드 좌표계 축들과 일치하도록 회전 변환

4) 3)과 같은 변환을 게임 세계의 모든 객체에 적용

(출처 : http://msdn.microsoft.com/en-us/library/windows/apps/ff729721.aspx)

# 투영 변환(Projection Transformation)

- 카메라 좌표계에서 카메라에 보이는 객체에 대하여 카메라와 객체까지의 거리는 기본적으로 Z 좌표로 근사할 수 있다.

- 카메라와 Mesh 사이의 Z 좌표가 증가할 때 메시의 각 정점 X, Y 좌표를 Z 좌표(ViewSpaceZ)의 z 값에 반비례하도록

변환하면 원근 효과를 나타낼 수 있다.

- 카메라 FOV 공간에 있는 정점들이 투영되는 공간은 투영 윈도우(Projection Window) 라고 한다.

-1 <= X <= 1, -1 <= Y <= 1 :: 카메라 FOV 공간에 포함된 정점들을 투영 변환했을 때 값들의 범위

(그외의 값을 갖는 점들은 카메라 FOV 공간에 포함되지 않아 보이지 않음)

- 투영 변환 :

X(projected) = x / ( z / d )

Y(projected) = y / ( z / d )

d 는 카메라에서 투영 평면까지의 거리를 의미한다.

d = 1 인 경우는 FOV 의 화각이 90도인 경우를 말한다. Direct3D의 경우 항상 1.0 의 값으로 설정.

- 쉽게 설명하자면,

투영 변환이란 3D 좌표 → 2D 좌표로 바꾸는 작업이다. 그러면 어떻게 바꾸냐?

FOV 의 화각이 90도 라고 했을 때(d=1),

(x, y, z) → (x/z, y/z, z/z) → (x/z, y,z, 1) 으로 바꿔버린다.

그러면 모든 정점들의 Z 좌표 값이 모두 1이 될 것이다. 

즉, 한 평면에 모든 정점들이 표현되고 이는 2D 좌표와 다를 것이 없다.

여기서 중요한 건 d=1 이라는 가정이다. 정확히는 z / (z/d) = 1 / d 가 되어

투영 변환된 Z좌표의 값은 0 <= Z <= 1 값을 갖게 될 것이다.

'그러면 2D가 아니지 않느냐?' 라고 생각할 수 있는데 왜 이렇게 되어야 하는 지는

Z-Buffer 얘기를 해야하는데 위에 '화가의 알고리즘' 관련 링크를 따라가 보면 알 수 있다 :-)

# 화면 변환(Screen Transformation)

- 투영 변환을 거친 정점은 2차원 좌표라고 생각할 수 있다.

이러한 2차원 좌표를 화면 좌표계로 변환하여 2차원 화면의 Pixel 로 그리는 단계.

- 렌더링할 대상의 화면 영역을 뷰포트(Viewport) 라고 한다.

(출처 : http://www.asksatyam.com/2011/01/window-to-viewporttransformation.html)

아무리 비율 좋은 Mesh 라고 한다고 해도 화면 비율에 맞게 렌더링 하다보면

위와 같은 현상이 나타날 수 있다. 그러니 다음과 같은 식을 이용한다.

- 픽셀 위치 좌표계 :

ScreenX = projVertex.x * (ViewportWidth / 2) + ViewportLeft + (ViewportWidth / 2)

ScreenY = - projVertex.y * (ViewportHeight / 2) + ViewportTop + (ViewportHeight /2)

ViewportLeft, ViewportTop : 뷰포트의 원점 위치

ViewportWidth, ViewportHeight : 뷰포트 가로, 세로 크기

※ 투영 좌표계는 좌표계 한가운데가 원점인 직교 좌표계이고, 

뷰포트는 왼쪽 상단이 원점인 좌표계이므로 Y 축의 방향이 서로 반대 방향이라 (-) 부호를 붙인다.

Transformation Pipeline 의 흐름을 잘 이해할 수 있는 이미지를 가져와봤다.

(출처 : https://forum.libcinder.org/topic/finding-an-object-s-screen-coordinates)

* 그 외 참조 :

http://code.msdn.microsoft.com/windowsapps/Direct3D-Tutorial-Win32-829979ef

---

실용주의 프로그래머

저자

앤드류 헌트, 데이비드 토머스 지음

출판사

인사이트 | 2014-03-28 출간

카테고리

컴퓨터/IT

책소개

The Pragmatic Programmer 숙련공에서 마스터로...

---

코딩 호러 시리즈를 읽으면서 매우 자주 소개된 책이 2권있다.

하나는 조엘 시리즈, 다른 하나는 이 책이다.

이미 아주 예전에 출간되었으나 최근에 디자인이 인사이트 특유의 심플한 디자인으로

탈바꿈되서 새로 나왔다. 목차를 보니 크게 다른 점은 없었다. (페이지 수는 이게 조금더 많다)

다른 분들이 쓰신 책 서평을 보니 거의 다 칭찬일색인데...

에..뭐랄까... 내가 코딩 호러 시리즈에서 이 책에 대한 내용을 심하게

네타 당했는지 읽는 내내 '많이 봤던 내용들이네...?' 하면서 지루하더라.

그래서 진짜 겨우 읽었다. 머릿속에 잘 들어오지가 않아서 여러모로 아쉽다.

물론 아주 유명한 책인 만큼 공감할 수 있는 부분, 새롭게 깨달음을 얻는 부분들도 있었으나

저자님께서 Perl 을 무지 좋아하시는 것 같았다ㅋㅋㅋㅋㅋ

나는 Perl 을 잘 모르기 때문에 저자님께서 씡나게 Perl 얘기를 하면 지루....

'보이지 않는 이 거리감 어쩔거야 ㅋㅋㅋ' 라는 생각이 조금 들었다.

제길. 이거 먼저 읽고 코딩호러 시리즈를 읽었어야 하는데 ㅋㅋㅋㅋㅋㅋㅋ

리뷰를 써야되나 말아야되나 솔직히 지금 포스팅하고 있는 시점에서도 고민된다 ㅋㅋ

진짜 어디서 본 내용들 많이 나오더라.

깨진 유리창 이야기 부터 고무 오리 기법, select 는 망가졌어 등등

중복되는 내용은 대충 훌훌 읽었....ㅋ

막상 이렇게 시작부터 책을 까도 막상 리뷰 쓰다보면 엄청 써대니 잡소리는 여기까지 하겠다.

1. 실용주의 철학

'돌멩이 수프와 삶은 개구리' 부분은 재밌게 읽었다.

스토리는 조금 억지스럽지 않았나 싶기도 했지만 그로부터 얻는 교훈에서는 느낀 바가 없진 않다.

'지식 포트폴리오'

- 지식 포트폴리오를 만들라고 하는데 매우 공감한다. 

그렇기 때문에 나는 이 블로그를 개설했었다.

주로 프로그래밍 관련 포스팅만 해서 다각화가 조금 부족한 면이 있지만

확실히 나는 개발 관련 포스팅을 해놓고 필요할 때 다시 보는 경우가 굉장히 많다.

이렇게 반복학습을 하면서 더욱 그 내용을 상기시키게 되서 더욱 지식 자산을 견고히 쌓게 된다.

블로그 개설을 강요하는 건 아니지만 ㅡ_ㅡ; (하지만 제프 앳우드님은 블로그를 하라고 하셨지)

아무튼 이 책에는 지식 포트폴리오를 관리하는 가이드 라인이 소개 되어 있다.

1) 매년 새로운 언어를 최소 하나는 배워라.

2) 기술 서적을 분기마다 한 권씩 읽어라.

3) 비 기술 서적도 읽어라.

4) 수업을 들어라.

5) 지역 사용자 모임에 참여하라.

6) 다른 환경에서 실험해보라.

7) 요즘 흐름을 놓치지 마라.

8) 인터넷을 이용하라.

사실 회사 일에 치여 살다보면 지금 하고 있는 일과 관련없는 공부를 하기가 힘들다는 건 현실이다.

지친 심신을 위한 휴식도 중요하지만 휴식이 지나치지 않은가에 대해 경계할 필요가 있는 것 같다.

물론 나에게 해당되는 얘기다 ㅋ 너무 쉬기만 하면 머리가 급속도로 포맷이 되니까 ㅡ_ㅡ

아, 그리고 이 장에서 Guru 가 뭔지 대강 알게되었다.

2. 실용주의 접근법

'중복의 해악'

- DRY : Do NOT repeat yourself

책 읽다보면 DRY 가 정말 많이 나온다. 그만큼 중복을 피하라는 것을 강조한다.

'예광탄'

- 목표물을 찾기 위해 예광탄을 써라.

프로토타이핑 VS. 예광탄 코드 

* 프로토타이핑 : 최종 시스템의 어떤 특정한 측면을 탐사해보는 것이 목표다.

진짜 프로토타입 방식을 따른다면, 어떤 개념을 구현해 보려고 시도할 때 대충 끼워 맞춘 것들을

모두 버린 후, 실험 과정에서 얻은 교훈을 바탕으로 다시 코드를 만들게 된다.

* 예광탄 코드 : 문제에 대한 대응 방법이다.

'애플리케이션이 전체적으로 어떻게 연결되는지 알고 싶고,

사용자들에게 실제로 이 애플리케이션이 어떻게 상호작용하는지 보이고 싶고,

개발자들에게는 코드를 붙일 아키텍처적 골격을 제시하고 싶다.' 라고 생각하는 경우, 

대강 구현한 알고리즘과 단순하지만 동작은 하는 사용자 인터페이스로 구성된 예광탄을 만들 것이다.

프로토타입은 나중에 버릴 수 있는 코드를 만드는 것이고,

예광탄 코드는 기능은 별로 없지만 완결된 코드이며 최종 시스템 골격의 일부를 보인다.

3. 기본적인 도구

'일반 텍스트의 힘'

- 지식을 일반 텍스트로 저장하라.

* 단점 

1) 압축된 이진 포맷을 사용하는 것보다 더 많은 공간을 차지할 수 있고

2) 일반 텍스트 파일을 해석하고 처리하는데 더 많은 계산이 필요할 수 있다.

* 장점

1) 구식이 되는 것에 대한 보험

2) 호환성

3) 더 쉬운 테스트

장점이 단점을 다 덮고도 남는다고 강조하신다ㅎ

지식을 저장하는 최고의 포맷은 Plain Text 라고 하시면서.

4. 실용주의 편집증

'단정적 프로그래밍'

- 연습문제가 재미있길래 가져와봤다.

Q. 간단한 현실 점검. 다음 '불가능한' 것들 중 무엇이 실제로 일어날 수 있는가?

1. 한 달이 28일 보다 적은 것

2. stat(".", &sb) == -1 (즉, 현재 디렉터리에 접근할 수 없다)

3. C++ 에서 a = 2; b = 3; if ( a+b != 5 ) exit(1);

4. 내각의 합이 180도가 아닌 삼각형

5. 60초가 아닌 1분

6. 자바에서 (a+1) <= a

해답

1. 1752년의 10월은 19일 밖에 없다. 그레고리 교황의 달력 개혁의 일부로

달력 간의 날짜를 맞추기 위해서 이런 일이 생겼다고 한다.

2. 다른 프로세스가 디렉토리를 없앴거나 디렉토리를 읽을 퍼미션이 없을 수 있다. 또는 &sb가 잘못 되거나.

3. 함정. (a 와 b 의 자료형을 명시하지 않았기 때문에)

연산자 오버로딩 때문일수도 있고, 또는 a 와 b 가 동일한 변수의 참조 변수일 수도 있다.

4. 비유클리드 기하학에서 삼각형의 내각의 합은 180도 안 될 수도 있다.

구 표면에 그려진 삼각형을 생각해보자.

5. 윤분(leap minute)은 61초나 62초일 수도 있다.

6. 오버플로 때문에 a+1 값이 음수가 될 수도 있다.

'리소스 사용의 균형'

- 기억에 남는 연습문제가 있었다.

Q. 일부 C 개발자와 C++ 개발자들은 어떤 포인터가 가리키는 메모리의 할당을 해제한 다음에는

반드시 그 포인터가 NULL 을 가리키게 하곤 한다. 왜 이것이 좋은 생각일까?

해답

대부분의 C나 C++ 구현에서는 어떤 포인터가 정말 유효한 메모리를 가리키는지 확인할 방법이 없다.

어떤 메모리 영역의 할당을 해제한 다음에 프로그램의 나중 부분에서 그것을 참조하는 잘못은

자주 일어난다. 그때쯤이면, 가리키는 메모리는 다른 목적을 위해 재할당되어 있을 수도 있다.

프로그래머는 포인터를 NULL 로 맞추어 놓음으로써 이런 잘못된 참조를 하지 않을 수 있기를 기대한다.

대부분의 경우 NULL 포인터를 참조하는 것은 런타임 에러를 발생하기 때문이다.

(비공개 포스팅에도 한번 언급했지만 NULL 포인터는 

일반적으로 '0' 이라는 값을 갖으며 유효한 참조나 메모리 주소를 가르키지 않는다)

5. 구부러지거나 부러지거나

'메타프로그래밍'

- 코드에는 추상화를, 메타데이터에는 세부 내용을.

메타데이터는 애플리케이션을 기술하는 모든 데이터로 보통 컴파일타임이 아닌 런타임에 접근, 사용된다.

메타데이터를 이용하여 반환 매개 변수, 사용자 선호사항, 설치 디렉터리와 같은

애플리케이션 설정 옵션을 기술하라. ex) 윈도우에서 .ini 확장자 파일

6. 코딩하는 동안 해야할 일들

'우연에 맡기는 프로그래밍'

- 우연에 맡기는 프로그래밍을 하지 말라.

휴... 왠지 이 파트를 읽으면서 나도 모르게 반성하게 되었다.

애초에 시작부터 우연에 맡기는 프로그래밍을 하는 것도 큰 잘못이고 어리석은 짓이나..

내 경우에는 조금 다르다.

코딩을 하다가 내가 생각했던 방식대로 계속 잘 안 되면 다른 방법을 찾게 된다.

다른 방법 역시 뭔가 계속 안 되면 나는 멘붕에 빠지기 시작하면서 짜증 지수가 최고조로 급상승.

결국 폭발하면 반드시 되게끔 만들어보이겠다는 오기가 생기기 시작해

온갖 수단과 방법을 가리지 않고(?) 마구잡이로 덤벼든다. 

생각해보면 이 과정은 우연에 맡기는 프로그래밍과 크게 다를 바 없다.

안 되니까 될 때까지 미친 애마냥 이거저거 막 찔러보는......

이래서 냉정과 침착 (=멘탈甲) 이 필요하다.

'리팩터링'

- 언제 리팩터링을 해야할까?

1) 중복(DRY)    2) 직교성이 좋지 않은 설계    3) 유효기간이 끝난 지식    4) 성능

연습문제가 3문제 있는데 모두 풀어볼 만한 흥미로운 문제였다.

풀면서 느낀 건 디자인 패턴 공부를 해놓은게 확실히 도움이 된다.

'읽기 좋은 코드가 좋은 코드다' 라는 책도 풀다가 중간에 생각날 정도로 도움이 됐다.

7. 프로젝트 전에

'요구사항의 구렁텅이'

- 요구사항을 수집하지 말고 채굴하라.

ㅋㅋㅋㅋ... 이 파트 읽으면서 설마 객체지향 수업시간에 징하게 배웠던

Use-Case 가 나올 줄이야 ㅋㅋㅋㅋㅋ 심지어 UML 도 나와서 좀 웃겼다.

'와, 이게 실제로 쓰이긴 쓰이나 보구나....' 싶었다.

개인적으로 Use-Case 작성하는 것에 대해 >매우< 스트레스 받는다ㅋㅋㅋ

그리고 요구사항을 수집하지 말고 채굴하라고 하는데... 맞는 얘기다.

실제로 내가 인턴했을 때 전달 받은 요구사항에 대한 문서들을 모아 잘 정리해서 

내 나름대로 코딩을 하고 있었다. (문서 중간에 조금 의심스러운 부분이 있었음에도 불구하고)

그런데 중간에 요구사항이 변경되는 바람에... 내가 우려했었던 그 부분에 대한 코드를 통째로 날렸다 ^^ㅋ

그러니 수집하지 말자. 채굴하자. 정말 쌀알만한 한 점의 의심스러운 부분이라도 캐내자.

8. 실용주의 프로젝트

'결국은 모두 글쓰기'

- 아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다.

진짜... 저 말에 매우매우매우 10000% 동의한다.

특히 나는 일주일도 안 되서 내가 전에 무엇을 했었는지 기억을 잘 못한다. ㅠ_ㅠ

그래서 혹시라도 까먹을까봐 불안해서 핸드폰이나 주변에 잘 보는 곳에 기록을 남긴다.

이는 개발할 때도 마찬가지다. 예를 들어 소스 코드 주석.

책에서 JavaDoc 도구가 제안하는 주석의 수준을 하나의 예를 들어 보여주는데 훌륭했다.

그리고 적절한 주석이 제자리에 있으면 JavaDoc 이나 DOC++ 같은 도구가 API 수준의 문서를

자동으로 추출, 포맷까지 해준다고 한다. 한번 해볼 가치가 있다고 느꼈다.

나의 경험을 비추어 봤을 때... 

인턴을 하면서 내가 분명히 무슨 이유가 있어서 어떤 코드를 작성을 했는데

대리님께서 그 코드를 보고 이거 누가했냐면서 왜 이렇게 해놓았냐고 약간 짜증이 섞인 말로 물어보셨다.

그래서 내가 한 거라고는 밝혔는데 문제는 왜 그랬었는지 내가 기억을 못 했다 ! ! ! ! (real 상황이었음)

지금 생각만해도 정말 절망스러웠다....ㅋㅋㅋㅋㅋ...

거의 한소리 듣기 일보 직전에 내 사수님께서 그 이유를 기억하셔서 잘 설명해주셨고,

이유가 잘 먹혀서(?) 결국 그 코드는 보존하게 되었다. 

Aㅏ, 정말.... 주석....

잘 달아놓자 ㅠ_ㅠ.............!

그리고 공부한 내용은 잘 정리해서 기록에 남기자. 나중에 진짜 다시 찾아보게 된다.

'오만과 편견'

- 자신의 작품에 서명하라.

마지막 파트라서 그런가, 꽤 중요한 내용이라고 생각된다.

'내가 이걸 만들었고, 내 작품의 품질을 보증합니다' 라는 뜻의 서명.

품질의 보증수표 ㅋㅋㅋㅋ 마치 화가들이 자신의 작품에 서명하듯이.

그러고보니 인턴할 때 누군가의 코드를 보고 있었는데

가끔가다 주석에 닉네임 같은 것이 적혀있었다. 

그걸보고 '누군지 몰라도 꽤 자신이 있나보다..' 라는 생각을 하게 되었다.

사실 자신이 있는 것도 있는 거지만 그만큼 자기 코드에 대해 책임을 지겠다는 뜻인데.

나는 아직 초보 개발자여서 내 코드에 대한 자신이 없기때문에 사실 지금은 서명하는 게 조금 두렵다.

더 솔직히 까발리자면(?) 누군가에게 지적받는 게 두려운 것 같다.

초보 개발자이든 뭐든 간에 맡은 일을 하다가 지적받을 수도 있는거고,

'받아들일 건 받아들이자' 면서 머리 속으로도 쿨하게 넘기려고 하는데도

막상 지적받으면 스스로가 창피하고 뭔가 굴욕적? 이다 ㅋㅋㅋㅋ 이러면 안되는데.

좀 더 덤덤하게 철판을 깔고 더 배운다는 자세로 내 흔적을 남겨야 할텐데. ㅋㅋㅋ

아니면 지적도 못 하게 완벽하게 코드를 짜든가. (실질적으로 이건 불가능)

쩝. 아무튼 책임 회피를 하는 것 만큼 최악인 것도 없으니

내 개인의 창피함 보다는 책임감을 좀 더 중요시 여기려고 노력해야겠다.

역시 리뷰 쓰다보니 앞에 지루하다고 투덜댈 때는 언제고 마구 쓰게 된다ㅋ

가끔 기록 강박증이 있는 건가 스스로 의구심이 들 때가 있지만 아직 그 단계까지는 아닌듯.

나는 좀 글을 써야된다. 평소에 너무 안 쓰니까 어휘력도 딸리고 표현력도 딸리고 ㅋㅋㅋㅋㅋ orz

다음엔 조엘 시리즈 ㄱㄱ ~

불타오르는 프로그래밍 트렌드 15가지, 그리고 식어가는 트렌드 15가지