Archive for February 2010
회사에 자바스크립트 관련 책은 정말 많습니다만, 문제는 너무 어렵거나 너무 두껍다는 것이었습니다. MSpress답게 명쾌하고 알찬 구성으로 되어있습니다.
핵심원리는 국내저자임에도 불구하고 상당히 고심하여 쓴 흔적이 많습니다. 프로그램이 뭔지, 컴터가 뭔지 잘 모르는 사람들에게 추천합니다.
게임마케팅은 일단 실무입장에서 정리한 다른 책이 없다는 점에선 유일한 책이 아닌가 싶습니다.
이번엔 정말 직원교육용 책들만 한 가득 사온 느낌이군요. 돈 뽑으려면 직원들 머릿 속에 우겨 넣어야 할 듯.
원래 컴터는 아무 뜻도 없는 변수명으로 백만개를 만들어서 함수도 없이 코드를 나열해도 잘 작동합니다. 애시당초 문제는 그걸 개발하는 사람은 그런 복잡성을 감당할 수 없다는 거죠.
인자객체를 사용하는 이유는 함수가 필요로 하는 인자를 코드힌트로 제공받기 위해서입니다. 특정 함수에 필요한 인자들이 복잡한 기능이나 제약을 갖고 있다면 그것을 이해하는 걸 넘어 외워야 하는 부담 때문에 사용하지 않게 됩니다. 여러분들은 정말로 drawGraphicsData 를 사용해보셨나요? 혹은 GraphicsGradientFill의 옵션을 사용하고 계신가요? 복잡한 함수일수록 사용하지 않게 되고 그러다 보니 필연적으로 CS4같은 비주얼화 된 툴에 의존하게 됩니다. 결과적으로 코드로 생산하지 않은 컨텍스트가 결과물에 다수 포함되고 나중엔 이것이 개발자의 잘못인지 디자인의 잘못인지 디자인을 다시 컨트롤한 개발자의 잘못인지 점점 알 수 없게 되고 맨날 플래시 개발자만 밤을 세고 있는 상황이 됩니다.
쨌든 개발자가 쓰기 편한 상태가 아니면 절대로 그 함수나 객체는 사용되지 않을 것이란 거죠.
그러한 편리한 개발을 위해 인자객체를 도입하여 보다 친절한 코드힌트로 개발을 돕는 설계를 합니다. 인자객체의 핵심은 메서드의 반환값이 this라는데 있습니다.
이 책은 실용주의 프로그래머 시리즈의 최신작으로 Git라 불리는 버전관리 시스템을 다루고 있습니다.
이미 SVN에 익숙해졌는데 왜 Git를 써야할까라는 질문부터 얘기해보겠습니다.
실제 이클립스에서 대다수의 프로그래머가 하는 일은 SVN에만 의존적이지 않습니다. 반드시 로컬히스토리를 같이 사용하게 됩니다.
왜냐면 원격지에 있는 SVN에 커밋하는 건 수많은 애자일 개발론이 가르친대로 단위테스트를 통과하여 버그가 없는 코드만 커밋하는게 기본이기 때문입니다.
하지만 개발 시엔 커밋과 커밋 사이에도 수많은 수정, 저장이 있고 이러한 스냅샷 내에서도 자유롭게 변경점을 확인하여 되돌리거나 수정하는 등의 작업이 이루어집니다.
따라서 실제 개발 시점에서 생각해보면 SVN의 버전 사이에 차이점을 인식하는 이벤트보다는 로컬 히스토리를 뒤져서 처리하는 횟수가 훨씬 많습니다(전 심지어 이클립스를 인스톨하자마자 로컬히스토리 용량부터 늘리고 보는 타입입니다)
어쨌든 이러한 현실 자체가 로컬 저장소와 원격지 저장소가 서로 다른 니즈를 갖고 있다라고 얘기해주고 있습니다.
분산버전 관리 시스템이란 쉽게 얘기해 로컬에서 작업할 때는 이클립스의 히스토리 같은 로컬 저장소에 그 이력을 꾸준히 기록해가다가 네트웍 넘어에 있는 원격저장소와는 로컬저장소를 통채로 동기화 시키는 방법입니다.
이렇게 함으로서 이클립스라는 특정 프로그램이 제공하는 히스토리기능에 의존하지 않고(혹은 다른 히스토리 기능) 손쉽게 로컬에서 프로그램독립적인 히스토리를 관리할 수 있으며 네트웍에는 이를 히스토리상태로 동기화 시키므로 보다 지능적이고 향상된 통합이 가능해집니다.
이러한 분산버전관리는 이미 개념이 오래된 내용이지만 Git가 각광받는 이유는 훨씬 더 편리하고 강력하기 때문이겠죠?
최초 이 Git는 간단한 쉘스크립트에서 시작했습니다. 리누스가 새로운 버전의 리눅스를 개발하기 위한 코드 관리 차원의 유틸을 작성한 게 기원이죠. 개발 이전에 개발에 필요한 바른 환경과 자동화를 먼저 생각한 뒤 개발을 해가야한다는 점은 현대 개발규모를 보건데는 거의 필수적이라 할 수 있습니다.
이 책은 다른 실용주의 시리즈처럼 얇고 따라해보기 편하다는 것이 장점이자 단점이라 할 수 있습니다.
참조로 현재 Git는 윈도우즈 지원이 여전히 미약하여 SVN처럼 쾌적하지 않습니다. 단지 이클립스 플러그인은 나와있고 나름대로의 유틸도 출시되고 있는 상황입니다.
뷰데이터를 기술함에 있어 이상적인 형태는 무엇일까? 에 대해 사람들은 다양한 생각을 합니다. 하지만 일반적인 형태는 이미 정형화 되어있습니다.
바로 xml을 통해 기술한다는 것이죠.
xml을 사용하는 이유는 뭘까요? 데이터를 복잡한 계층구조로 기술함에 있어 표현이 명확하며, 기술방법 자체가 전부 표준화 되어 있다는 점이 큰 매력이 아닐까 싶습니다.
단점이라면 비대한 덩치와 개발자가 아닌 사람은 건드리기 어려운 난이도 등이 있습니다만, 그보다 심각한 점은 복잡성을 제한하는 어떠한 한계가 없기 때문에 무한히 복잡해지는 경향을 갖는다는 점입니다.
이 무한히 복잡해지려는 경향은 대부분의 xml포멧에서 일반적으로 보이는 것으로 soap, mxml 등 대부분이 버전업을 반복하며 계속 복잡해져갑니다.
결국 이런 엔트로피 증가는 파국으로 이어지게 마련입니다. 웹서비스의 soap를 포기해버리고 다시 rest가 득세버린다던가 데이터전송 포멧이 효율적이고 제한적인 amf쪽으로 가버린다던가 하는 식이죠.
하지만 제가 xml을 사용하지 않으려는 이유가 보다 현실적인 문제 속에 있었습니다.
툴이 작성해주지 않는다.
mxml을 일일히 타이핑쳐서 만들기란 사실상 불가능합니다. 왜냐면 너무 양이 많기 때문입니다. 전 플렉스 빌더같은 툴을 만들 생각은 없었기 때문에 타이핑으로 충분히 기술할 수 있는 포멧이 필요했습니다.
누구나 사용할 수 있어야 한다.
xml은 누구나 사용할 수 없냐구요?
맞습니다. 사실 xml은 거의 누구도 사용할 수 없다고 표현하는 편이 더 적절합니다. 기획자, 디자이너 등 거의 모든 프로젝트 참여자들이 xml을 수정하거나 생성하지 못합니다.
심지어 개발자들도 html 코딩이 자신의 일이 아니라고 우기는걸 보고 있자면, SGML에 근간을 둔 태그 언어라는 건 애시당초 생성해주는 툴과 태그 전문가 외엔 사용할 수 없는 언어란 생각이 들기도 합니다.
그럼 ‘왜 누구나 사용할 수 있어야 하는가?’ 에 대해 말씀드리자면 뷰데이터작업은 근본적으로 개발의 일부가 아니기 때문에 반대로 개발자가 아닌 다른 사람이 만들수 있어야하기 때문입니다. 쉽게 말해 배경그림을 바꾸거나 버튼의 위치를 바꾸는데 있어 개발로직은 존재하지 않는다는 것이죠.
호환성 및 런타임 파싱
뷰데이터란 결국 렌더링할 그래픽스의 메타데이터입니다. 따라서 뷰데이터야말로 언어와 플랫폼을 넘어 공유할만한 의미가 있는 데이터입니다.
한번 작성한 뷰데이터를 다양한 플랫폼에서 사용하기 위한 필수조건은 런타임파싱입니다. mxml의 경우 컴파일타임에 파싱하기 때문에 다른 플랫폼에서 사용하려면 자바로 작성된 파서를 해석한 뒤 그게 왜 as로 그렇게 번역되는지를 이해한 후 파서를 재작성 해야합니다. 돈주고 수주하지 않는 이상 이런 짓을 하기란 쉽지않습니다.
따라서 다양한 언어에서 뷰데이터가 호환된다는 의미는 어찌보면 뷰데이터 파서가 이식하기 쉬워야 한다는 의미에 가깝습니다.
게다가 ‘그래픽스적인 이슈를 분리하여 개발하고자 함’ 은 ‘뷰데이터로 인해 재컴파일을 하지 않는다’ 는 의미이기 때문에, 실행 중에 로딩하여 사용하는 건 기본입니다. 이 점에서 어도비의 카탈리스트는 완전히 다른 개념이라고 할 수 있습니다. 카탈리스트는 저작툴로서 사실 개발적인 입장에서는 컴파일에 병합되어야하는 디자인적인 이슈를 다른 툴로 생성해온다라는 의미이기 때문입니다.
런타임에 뷰데이터가 로딩되어서 사용되려면 파서가 가볍고 짧게 구현되어 다른 프로그램 내부에서 쓰일 때 부담을 주지 말아야겠죠. 파서가 이렇게 만들어지려면 뷰데이터 포멧 자체가 가볍게 파싱할 수 있도록 설계 되어야 합니다.
어떻게 하면 가볍게 파싱할 수 있는 포멧이 될까요?
유연하고 확장성이 뛰어나면 그만큼이나 파서의 수비범위가 넓어집니다. 따라서 규칙적이고 룰이 확실하고 제한적이라면 파서는 상대적으로 가볍게 작성할 수 있습니다.
위에서 설명한 여러 가지를 요약해드리면 결국 기존의 포멧이 딱히 맘에 들지 않아 새로 만들었다는 겁니다.
해서 결국 제가 만든 포멧은 아래와 같습니다. ini를 기본으로 하는 형태입니다.
[윈도우선언]
엘레먼트타입:이름=화면요소
-엘레먼트인자
*데이터바인딩
@애니메이션기술
손쉽게 위의 샘플은 아래와 같습니다.
[view1]
bitmap:b1=p:[50,50], s:[100,50]
-’titleImage’
위의 뷰데이터는 titleImage 라는 이름의 비트맵을 생성하여 이름을 b1으로 부여합니다. 그 뒤에 위치(position)를 50,50으로 이동시키고 크기(size)를 100,50 으로 설정합니다.
전체적인 위젯코드 스펙은 아래와 같습니다.
윈도우
하나의 위젯데이터에는 여러 개의 윈도우를 포함할 수 있습니다.
아래의 예는 다중 윈도우 샘플로 join과 login은 별도의 윈도우가 됩니다. as3에서는 하나의 윈도우는 Sprite하나로 인식됩니다.
[join]
bitmap:j1=p:[50,50]
-’join’
[login]
bitmap:l1=p:[50,50]
-’login’
엘레먼트타입
엘레먼트 타입은 사실상 무한히 확장할 수 있는 구조로 되어 있습니다. 기본적으로 지원되는 타입은 아래와 같습니다.
bitmap, Sprite, vector, rect, circle, text…
엘레먼트인자
엘레먼트 타입에 따라 요구받는 인자는 서로 다릅니다만 인자를 기술할 경우 단순한 값 뿐만 아니라 해당 엘레먼트의 메서드도 직접 호출할 수 있습니다.
아래의 예는 다양한 인자의 예를 보여줍니다.
bitmap:b1=p:[0,0]
-’test1′
VECTOR:v1=p:[0,0]
-’test2′
text:t1=p:[0,0]
-LOAD(‘title’).html( ‘test’ )
엘레먼트이름
사실 이름은 고유한 아이디가 아닙니다. 하지만 지역적인 범위에서 유저가 식별할 목적으로 사용됩니다. 위젯코드는 내부적으로 아이디를 고유하게 생성할 책임을 파서에게 위임합니다.
화면요소
화면에 표시될 속성은 기본적으로 제 ddo규격을 사용하도록 디자인 되어 있습니다. 위에서 등장했던 p:[50,50] 이나 s:[30,100] 과 같은 표현식입니다.
이러한 조합을 통해 표현된 위젯데이터의 특성은 xml 수준의 유연성은 없지만 뷰데이터를 기술하기에는 충분한 수비범위를 갖고 있습니다.
예를 들어 비트맵이 깔리고 그 위에 텍스트로 설명이 들어간 버튼을 만든다고 하면 아래와 같은 형태의 위젯코드를 생각해볼 수 있습니다.
Sprite:button1=p:[100,100]
{
bitmap:bg1=p:[0,0]
-’buttonBack’
text:t1=p:[0,0]
-LOAD( ‘button’ ).html( ‘submit’ )
}
중괄호식은 자식을 나타낼 수 있으므로 두개의 요소를 부모 Sprite타입에 묶었습니다.
시리즈 마지막 포스트에서는 실제 샘플을 보고 해소해야하는 다양한 이슈들에 대해서 살펴보는 것으로 마무리 하겠습니다.
백문이 불여일견 일단 보겠습니다. 클릭해서 크게 보세요.
이 솔루션의 목표는 다음과 같습니다.
이 솔루션은 이미 레퍼런스가 생겼습니다.
http://hgss.pokemonkorea.co.kr/11.asp#2
httpwatch, fiddler등 네트웍 모니터를 이용하면 손쉽게 확인할 수 있습니다.
이후 2, 3편에서는 이를 가능케 하는 파서와 전체 솔루션의 구조를 확인하고 확장을 어떻게 하는지 컨트롤러와 어떻게 바인딩되는지를 설명하겠습니다.
또한 자바스크립트 버전의 파서와 ObjectiveC, C++용 파서에 대한 계획을 설명합니다.
