쎈과 서연이의 행방불명

개발개발 : 상황 단계

2009-09-05T06:17:11+09:00

상황 단계

플래시 혹은 플렉스 라는 작업 방법론을 통해서 도출되는 결과물은 swf 파일 입니다. 그 Shockwave Flash 라는 클라이언트 상에서 작동하는 인터렉티브 미디어 파일을 만들어내는 것이 바로 우리들이 하는 일이죠.

자, 우리가 목표로 하는 여러가지 툴들에 대해 총괄적인 이해를 하기 위해서는 바로 그 swf 가 만들어지고, 사용되어지는 상황들에 대한 이해가 필요합니다. 그 단계는 크게 세가지로 나눌 수 있습니다.

여러가지 파일들을 작업하는 소스 단계와 해당 소스들이 mxmlc 라는 컴파일러를 통해서 컴파일 되는 단계, 그리고, 컴파일이 정상적으로 종료가 된 후 아웃풋 되는 swf 가 실제 구동되는 런타임 단계 입니다.

굉장히 기초적인 이야기지만 여러가지 툴들에 대해서 대략적인 이해를 하기 위해서는 이 각 단계들에 대해 이해하는 것이 매우 중요합니다.

디버깅

우선적으로 여기서 에러에 대한 구분을 할 수가 있는데요.

소스가 컴파일 되는 과정에서 발생하는 오류가 컴파일 에러이고, 정상적으로 컴파일이 완료된 이후 swf 가 작동되는 과정 상에서 발생하는 오류는 런타임 에러 입니다.

이런 단계별 에러에 대한 것은 위와 같이 레퍼런스 상에 따로 분리되어 기재되어 있습니다.

그리고, 이 에러 상황을 해결하는 행위를 디버깅이라고 하고, 그것을 도와주는 유틸리티를 디버거 라고 합니다.

디버거는 위와 같이 컴파일 에러, 런타임 에러에 대한 에러 영역에 대한 확인이나 원인에 대한 안내, 런타임 상황에서 자원들의 변화를 감시하는 등의 역활을 합니다.

우리가 ActionScript 3.0 이라는 규칙이 까다로운 언어를 사용해야 하는 이유 중 하나는 바로 이런 디버거 라는 기계적 장치가 에러에 대한 원인을 파악하는데 있어서 인간이나 알아보는데 2.0 과 같은 규칙이 자유로운 코드가 아닌, 기계가 파악하기 쉽게 기계적 규칙이 까다롭게 적용된 3.0 같은 코드가 좋기 때문입니다.

2.0 보다 3.0 의 코딩이 좀 더 불편하긴 하지만, 디버거가 제공하는 오류 정보의 양은 2.0 보다 3.0 이 압도적으로 많습니다.

이런 디버거는 Flex builder 나 FDT 의 경우에는 위와 같이 Eclipse 고유의 Debug 패널과 유사한 형태로 제공되고,

Flash 의 경우엔 위와 같이 컴파일러 에러의 경우엔 compiler errors 패널로, 런타임 에러의 경우엔 output 패널로

변수의 변화나 breakpoint 의 적용등엔 위와 같은 Debug 모드를 통해서 지원합니다.

이런 디버거를 적절히 잘 활용하는 것은 (특히 흔히 사용하지 않는 변수에 대한 감시 같은 기능을 잘 활용하는 것은) 에러 상황에 대한 보다 빠른 대응에 큰 도움을 주곤 합니다.

그리고, Flex builder 나 FDT 같은 고급 에디터들의 경우엔 이렇게 컴파일이나 런타임 상황 이전에 소스 레벨에서 에러를 체크해 주기도 하는데요.

고급 (비싼) 에디터들의 경우 컴파일, 런타임 이전에 위와 같이 코딩을 진행하는 상황에서 바로 에러를 검출해주기도 합니다. 이런 소스 레벨에서의 에러검출은 작업에 대한 안정성을 향상시키는데 굉장히 큰 도움을 주죠. 컴파일 단계에서 발생할 수 있는 에러의 경우는 거의 대부분 발생하지 않게 해주고, 런타임 상의 에러 역시 많은 부분 미리 수정이 가능하게 해줍니다.

형상관리 및 버그리포팅

엄청나게 복잡한 맵이 탄생했는데요.

소스의 파일과 텍스트 소스코드의 특징을 사용하는 SVN, CVS 와 같은 형상관리 툴과 Trac, JIRA 와 같은 스케쥴, 프로젝트 관리툴, 그리고, 버그에 대한 리포팅 역활을 담당하는 BugZilla 와 Trac, JIRA, 그리고 그와 같은 전반적인 툴들이 Eclipse 기반의 Mylyn 과 통합되어서 소스코딩에 영향을 미치게 되는 것까지 좀 더 견고한 작업환경을 구축하는데 중요한 여러가지 개념들이 적혀있는 맵입니다.

이런 기능들은 소스코드가 어떤 방향으로 발전해야 하는지에 대한 좀 더 객관적인 시각에서의 방향성을 제시해주게 되는데 큰 도움이 됩니다.

뭐 이 중, 이 강좌가 다룰 것은 SVN, Trac, Mylyn 인데요. 지금 당장 저 맵을 보면서 "엥?" 할 필요는 없구요. 천천히 하나 하나 다뤄나갈 것이니 일단 기능들이 어떤 단계의 보강을 위해서 존재하는 것인지 대략 살펴보기만 하면 될 것 같습니다.

빌드 자동화

프로젝트가 커지고, 점점 Ctrl+Enter 따위로 컴파일 하기에는 그 분량이 너무 많아진다 싶을때쯤이 되면 빌드 자동화에 대한 요구가 생기게 됩니다.

이런 빌드자동화는 기본적으로 컴파일과 컴파일 된 결과물을 퍼블리싱 하는 과정을 기계적으로 자동화 시켜줍니다.

빌드 자동화 툴은 Action Script 개발의 경우는 크게 두가지를 씁니다. Ant 라는 Eclipse 와 궁합이 잘 맞는 상당히 편리한 빌드툴을 사용하던가, 아니면, shellscript 나 batch 등을 사용해서 직접 mxmlc 의 커맨드라인을 제어하는 방법 입니다. 이 두가지는 서로 장단점이 있는데요.

Ant 의 경우엔 Eclipse 라는 개발툴의 지원부터 시작해서 이미 FDT, Flex builder 상에서 Ant 에 대응하는 좋은 기능들을 이미 구현해놨지만, XML tag 형식으로 구성되어있어서 조금 분량이 많아진다거나 하면 아무래도 노가다량이 충분히 많아진다는 점이고,

Shellscript 의 경우엔 Ant 에서 사용할 수 없는 function 같은 script 적 표현을 사용해서 자동화 할 수 있기 때문에 보다 다채로운 표현이 가능하나, 아무래도 Eclipse 와 같은 에디터를 통해 지원되는 기능등은 없다는 것이 문제입니다. (Ant 보다는 좀 더 사용하기가 까다롭지만, 그만큼 다채롭기도 하죠...)

역시 이런 빌드 자동화에 대한 부분들도 하나 하나 세세하게 살펴보는 시간이 있을테니 일단 이런게 있구나 라면서 알아두면 될 것 같습니다.

프로그램이란 것은 필요에 의해 만들어진다...

인간이 만드는 모든 것은 결국 필요에 의해 만들어지지 않을까 싶습니다. 엄청 대단한 천재가 뜬금없이 나타나서 엄청 새로운 것을 만들어내는 것이 아닌, 기존에 아주 불편하던 것을 좀 더 편리하게 만드는 것... 그것이 바로 발명 이란게 아닐까 싶습니다.

swf 라는 결과물을 만들어내기 위해서 엄청나게 많은 툴들을 꼭 사용해야 하는 것은 아닙니다. 메뉴바, 배너 하나 만드는데 SVN, Trac 을 사용해서 형상관리나 프로젝트 관리 따위를 할 필요는 없고, 당연히 Ant 등을 사용한 빌드 자동화 따위도 필요없겠지요. 해당하는 툴들이란 "일이 너무 많아져서 버거워질때 그 업무량을 일정 부분 기계에게 할당하기 위해" 발명되어진 툴들이므로 자신의 작업분량을 줄이는데 도움이 되지 않는다면 사용을 구지 할 필요는 없습니다.

여러분이 어떤 툴을 이해하려고 할때 저와 같은 작업 단계에 대한 고려를 하면서 접근하는 것은 상당한 이해의 폭을 제공해줍니다. 어떤 툴도 그냥 만들어지지는 않았고, 결국 swf 를 만들어내는데는 저 세단계 중 한가지 단계의 작업을 보조하기 위해서 만들어진 것일테니깐요.

뭐 복잡하게 써놓긴 했지만, 그렇게 복잡하지도 않습니다. 그냥 소스 > 컴파일 > 런타임 이라는 swf 가 만들어지고 사용되어지게 되는 상황 단계를 이해하고 넘어가면, 앞으로 나올 여러가지 개발도구들에 대해 이해하는데 큰 도움이 될테니 꼭 기억해두도록 하세요.

개발개발 : mxmlc 에 대한 기초적인 이해

2009-09-02T01:52:06+09:00

논리와 감각, 원론과 응용

일단 눈으로 보고 차이를 이야기해보죠.

어떤 object 의 위치 x 를 10 에서 100 으로 옮긴다고 했을때를 생각해보죠.

소스코드를 통해서 컨트롤 할때는 위와 같이 단순한 코딩으로 해결이 됩니다. (물론 Tweener 를 사용해서 그런것이고, 기본 기능만으로 통해서 코딩하면 보다 복잡해지겠죠.)

하지만, 이렇게 애프터 이펙트와 같은 애니메이션 툴을 사용했을때는 좀 더 복잡하지만, 대신 사람이 손쉽게 이해할 수 있는 형태로 작업을 할 수 있게 됩니다.

보다 원론적인 논리에 가까운 형태의 작업은 Text 에 가까워지게 됩니다. 보다 인간의 감각기관이 인지하기 쉬운 형태의 응용 형태는 위와 같이 여러가지 다른 형태를 띄게 되죠.

이런 차이점은 서로 장단점이 존재합니다. 보다 논리적인 작업 형태는 보다 다채로운 작업을 가능하게 하지만 인간의 접근이 어려워지는 문제점이 있고, 보다 감각적인 작업 형태는 최초의 접근이 쉽고 인간의 감정이 보다 손쉽게 표현될 수 있지만 대신 그 작업 형태에 얽매이게 되는 한계성이 있죠.

이런 시각에서 바라보면 컨텐츠의 효율적인 구조와 흐름을 만들어내는 기획자와 서버사이드 쪽의 데이터 개발자, 디자이너와 플래시 개발자가 하는 일이 엇비슷 하면서 서로 다른 장단점의 작업 방식을 통해서 상호보완 되고 있다는 것을 알 수 있게 됩니다. (이런 차이점을 이해하게 되면 단순히 너는 포토샵 쓰니깐 저쪽팀, 넌 코딩하니깐 이쪽 팀 이라는 무식한 조직운영의 단점이 눈에 보이게 되죠.)

자... 여기서 중요한 것은 바로

감각적인 작업 형태가 가지는 "보다 손쉽게 표현될 수 있지만 대신 그 작업 형태에 얽매이게 되는 한계성"

입니다.

우리가 사용하는 Flash 를 비롯한 Flex builder 같은 툴들은 모두 "인간이 보다 쉽게 작업 할 수 있도록" 감각화된 편리한 기술들에 해당하게 됩니다. 그래서 "편리하지만" 대신 "얽매이게 만드는" 기술들 이기도 하죠.

하지만, 우리가 개발 환경을 만들어나가는데 있어서 중요한 여러가지 기술들은 모두 Adobe 에서 만든것은 아닙니다. 그렇기에

우리들이 그 많은 기술들을 정상적으로 활용하기 위해서는 "편리하지만 얽매이게 만드는" 기술 보다는 "좀 불편하더라도 원론에 가까운 논리적 형태의" 기술로 내려갈 필요가 있습니다.

mxmlc 를 이해하는 것은 일단 Flash 냐 Flex builder 냐 FDT 냐 Flash Develop 이냐 어쩌고 하는 툴에 대한 제약사항에서 벗어나는데 가장 중요한 일이 됩니다.

서론이 길었네요. 시작해 봅시다.

Flex SDK 다운로드 받기

구글을 통해 "flex sdk download" 등을 검색하면 Flex SDK 다운로드 받을 수 있는 링크들이 제시되게 됩니다. 링크들을 통해서 Flex SDK 의 Release 최신 빌드를 다운로드 받도록 합니다.

(앞으로의 모든 강좌에서는 링크가 제공되지 않고, 검색 키워드만이 제공되게 됩니다.)

제가 받은 버전은 3.4.0.9271 입니다. SDK 는 zip 형태로 압축되어 있는데 압축을 풀어서 적당한 곳에 놓아둡니다.

제 경우에는 위처럼 data 드라이브에 setting 폴더에 넣어두었습니다.

많은 윈도우 사용자들을 위해서 윈도우로도 진행을 해보도록 하겠습니다. 윈도우에서는 C 드라이브에 setting 폴더 내에 넣어두었습니다.

SDK 를 적절한 위치에 두었으면 해당 위치에 대한 경로를 인식하고 있어야 합니다. 맥킨토시로 진행하는 경우의 경로명은 "/Volumes/data/settings/flex_sdk_3.4.0.9271" 이 되고, 윈도우의 경우엔 "C:\settings\flex_sdk_3.4.0.9271" 가 되게 됩니다.

mxmlc 를 통한 기초적인 소스코드 컴파일 하기

우리는 이제 평소에 굉장히 쉽게 해오던 것들을 굉장히 어렵게 하게 될 것입니다. 강좌를 보시는 동안 "이게 뭔짓이여..." 하는 분들도 있으실텐데, 그런 분들이 있으시면...

그냥 따라오세요... 오빠를 믿어요~

일단 적절한 코딩을 해놓은 뒤에 (한 번 개고생 해보자는 의미로 메모장 같은 프로그램을 사용해서 코딩하는 것을 추천합니다.)

테스트 폴더를 만들어서 저장을 하도록 합니다.

윈도우의 경우는 위와 같이 저장했습니다.

그리고, 터미널을 열고 위와 같이 입력합니다. 명령어를 분석해보면

/Volumes/data/settings/flex_sdk_3.4.0.9271/bin/mxmlc
:: mxmlc 의 경로를 지정합니다.

/Volumes/data/Test/src/MXMLCTest.as
:: 컴파일 할 as class 의 경로를 지정합니다.

-o /Volumes/data/Test/mxmlcTest.swf
:: -o 는 "output" 을 의미하고, 생성할 swf 의 경로를 입력해줍니다.

이렇게 세가지로 나눌수 있습니다. 대충 쉽게 이야기해서 mxmlc 의 커맨드라인 입력은

(mxmlc 의 경로) (as 소스코드의 경로) (이후 부터는 -? 의 옵션 입력들)

이렇게 세가지로 규칙화 되게 됩니다.

그러면 위와 같이 flex-config.xml 을 로딩한다는 메세지가 뜨고, 최종적으로 mxmlcTest.swf 가 만들어졌다는 메세지가 뜨면서 mxmlc 가 종료되게 됩니다.

해당 위치에 가보면 mxmlcTest.swf 가 만들어진 것을 확인할 수 있고

실행해 보면 위와 같이 throw new Error 에 대한 구문이 실행되게 됩니다.

만일 위와 같은 구문들이 등장하지 않는다면 구글에서 "flash debug player download" 로 검색해서 플래시 플레이어 제거 프로그램과 플래시 디버그 플레이어를 다운 받고, 제거 프로그램으로 기존의 플레이어를 삭제한 뒤에 디버그 플레이어를 설치하도록 합니다. (매우 기초적인 사항이니 삽질을 하더라도 꼭 자기 손으로 다운받고 설치하는 방법을 익혀두도록 합니다.)

윈도우의 경우는 위와 같이 도스창을 열어서 진행하면 됩니다. 경로명이 C:\ 형식으로 시작된다는 것 이외에는 동일한 사용방식을 가지고 있으므로 앞으로 진행될 강좌에서는 따로 윈도우용 스크린샷이 없더라도 감안해서 적용하시면 됩니다.

좀 더 많은 mxmlc 옵션 이해하기

MXMLCTest.as 에 코드를 추가시켜 줍니다. 추가시키는 코드들은 TweenMax 를 통한 트위닝과 커스텀 클래스를 통한 ColorBox 입니다.

ColorBox.as 의 코드입니다.

그리고, 각기 파일들의 위치는 위와 같이 잡아주도록 합니다.

기존대로 소스를 컴파일 하려고 하면 에러가 발생하게 됩니다.

이 에러들이 바로 우리가 Flex builder 나 FDT, Flash 등을 통해서 컴파일을 진행할때 뜨는 컴파일 에러의 원본 입니다. 이렇게 SDK 를 통해 발생되는 에러메세지를 FDT 나 Flex builder 는 콘솔창을 통해서, Flash 의 경우는 컴파일 에러 창을 통해 정리된 형태로 보여주게 되는거죠.

에러를 잡기 위해서 좀 더 옵션들을 추가해보도록 하겠습니다.

추가적인 옵션들을 살펴보도록 하죠.

-sp /Volumes/data/Test/src2/
:: 외부에 마련된 ColorBox 가 존재하는 src2 폴더를 컴파일에 포함시킵니다.

-library-path /Volumes/data/Test/libray.swc
:: (TweenMax 가 들어있는) swc 라이브러리 파일을 컴파일에 포함시킵니다.

이렇게 추가적인 옵션들을 통해서 컴파일 시키면 정상적으로 컴파일이 진행되게 됩니다.

swf 파일을 실행시켜 보면 지정된 트윈 애니메이션이 실행되고, 종료시에 지정한 throw new Error 가 뜨게 됩니다.

이와 같은 -sp 나 -library-path 와 같은 기능들은 여러가지 툴들에서 다양한 형태로 감각화 되어있습니다.

Flash 에 존재하는 Publish Settings/(Script Settings... 버튼 클릭)/Advanced ActionScript 3.0 Settings 의 기능이나

FDT 에 존재하는 Source, Library 기능들이 바로 그것이죠.

Flex builder 와 Flash Develop 역시 마찬가지의 기능들이 비슷한 다른 형태로 구현되어 있습니다.

이런 부분은 추가적으로 -external-library-path 에 대한 옵션도 있지만 해당 부분이나 이와 관련된 더 자세한 내용들은 추후에 설명하도록 하겠습니다. 오늘은 mxmlc 에 대한 전반적인 옵션들을 이해하려고 하는 것이니깐요.

추가적으로 swf 의 기본적인 모양에 대한 옵션들도 존재합니다. (위에 스펠링 틀려서 꽤 다시 쓴 흔적들이...;;;) 분석해보면

-default-size 800 600
:: width 800 height 600 pixel 의 사이즈로 swf 를 만듭니다.

-default-frame-rate 31
:: 기본 fps 를 지정합니다.

-default-background-color 0xffffff
:: swf 의 기본 배경색을 지정합니다.

이 부분은 굉장히 익숙한 옵션들일 겁니다.

Flash 에서 가장 기본적으로 지정하는 Document Properties 의 내용이기 때문이죠.

원론적인 컴파일러에 대한 이해도가 작업환경 확장의 기본

FDT 를 비롯한 Flash Develop 같은 다양한 소스코딩 툴과 SVN, Trac, Mylyn 등의 소스코드 관리 및 작업관리 툴, 그 외에 Ant, Maven 과 같은 엄청난 시간을 절약해주는 빌드 자동화툴 등 플래시 개발이 고도화 되면서 점점 많은 기존에 있던, 그리고, 새로 나오는 보조 도구들이 생기고 있습니다.

하지만, 시작 부분에도 말했듯이 모든 작업환경들이 Adobe 라는 기업에서 만들어지는 것은 아니고, 각자의 방식에 의해서 개발됩니다. 그렇기에 Flash 와 호환성이 없는 툴이 있을수도 있고, 또 극단적으로 해당 툴들을 사용하기 위해서는 Flash 로 작업되어서는 안되는 경우도 있죠.

여러분들이 그 많은 보조 도구들을 이용해서 자신의 작업을 좀 더 자동화 시키고, 공정화 시켜서 고퀄리티와 보다 빠른 작업시간을 가지길 원한다면 여러분은 특정한 툴에 얽매여서는 안됩니다. 가장 기본적인 소스코드 레벨과 컴파일러 레벨의 작동을 이해해야만 그 다양한 툴들을 필요에 따라 사용할 수 있게 됩니다.

그리고, 다수의 작업자들이 가지는 작업환경을 배려하면서도 통합을 가능하게 하기 위해서 역시 가장 최하위에 존재하는 컴파일러에 대한 이해가 필요하죠. 이에 대한 원론적인 이해가 없다면 "Flash 로 개발한 작업물을 Flex builder 를 사용하는 내가 어떻게 작업하라는거야!" 라는 소리를 할 수 밖에 없게 되는데, 사실 자랑스럽게 할만한 이야기는 아니다 라고 말씀드리고 싶습니다.

앞으로의 모든 수업은 이 Flex SDK 레벨의 원론적인 내용들을 바탕으로 진행되게 됩니다. 지금껏 Flash 나 Flex builder 등 툴에 많이 의존해오던 분들은 적응에 상당히 많은 어려움을 겪으시게 될텐데 도움이 될테니 열심히 따라오라고 말씀드리고 싶네요.

다음 시간엔 오늘 배운 mxmlc 에 대한 내용을 바탕으로 FDT 를 분석해보는 시간을 가지도록 하겠습니다.

ps . 개그컷에 속지말자. 알고보면 훈남이다.

개발개발 : 시작하며

2009-09-01T19:32:36+09:00

강좌를 시작하며

이 강좌는 제가 운영하려 하는 스터디 그룹에서 다룰 Flex SDK, FDT, Ant, Trac, Mylyn 과 같은 개발환경 툴들에 대한 내용을 다루게 됩니다.

스터디 시간 동안 쓸데없이 강의하면서 날려먹을 수 있는 시간을 아끼고, 좀 더 "기술을 어떻게 활용하면 좋을 것인가?" 나 모르는 부분에 대한 상호 스터디를 활발하게 하는 것이 좋겠다 싶어서 시작하는 것이죠.

혼자서도 글 보면서 배울수 있는 부분과 모여서 논의하면서 배울수 있는 부분에 대한 구분을 확실하게 해서 효율성을 높이고자 하는 의도에서 스터디 계획의 일부를 강좌로 빼려고 합니다.

강좌의 목적 : 개발 환경의 변화...

이 강좌의 목적은 쉽게 이야기해서 "플래시도 좀 사람답게 개발해보자." 입니다.

그리고, "할머니도 하는 액션스크립트" 라는 강좌 때와는 틀리게 스터디 그룹까지 하려고 하는 것은 "사람답게 개발할 수 있는 환경" 이라는 것은 "개인의 기술력" 을 갖추는 것 만으로는 해결되지 않는 사항들이기 때문입니다.

제대로 된 개발환경 위에서 개발을 진행하는 것과 그렇지 않은 환경에서 개발을 진행하는 것은 수치적으로는 말하기 어렵지만, 체감한 바로 적어도 2배 ~ 3배 이상의 차이를 보이게 됩니다.

"우왕~ 두배에~~"

할지도 모르겠지만, 실제적으로 업무량에 대한 처리 효율이 2배까지 차이가 날 수 있다는 것이고, 이런 차이는 바로 "업무량" 에 직접적으로 영향을 끼치며, 그 업무량은 다시 "인간다운 생활" 이나 "보다 고퀄리티의 결과물" 을 만들어내는데 영향을 끼치게 되죠.

하지만, 말했다시피 이런 개발환경은 "개인의 기술력" 과는 다르게 "조직 전체" 의 보다 나아가서는 "시장의 표준" 에 의해서 결정되는 사항들입니다. 아무리 개인이 할 수 있어도 조직이, 시장이 변하지 않는다면 아무런 의미가 없다는 것이죠.

전 프리랜서 입니다. 상당히 오래되었죠... 그래서 여기저기 많은 곳에서 일을 하는 편인데, 까놓고 이야기해서 대형의 플래시, 플렉스 어플리케이션들은 "증오" 위에서 개발된다 싶을 정도로 프로젝트 진행에 있어서 트러블이 심한 편입니다. 끝내고 나서 마음이 개운한 다른 일들과는 틀리게 대체적으로 언제나 지랄맞은 결과가 나오게 되죠.

개발주체인 서버사이드 그룹의 클라이언트 개발에 대한 이해부족과 마찬가지의 디자이너들에 대한 플래시 개발 프로세스에 대한 이해부족, 그리고, 개발자들 끼리도 표준화 되지 않는 개발환경의 문제가 심각하죠. 요구사항 자체가 달나라 꿈꾸는 소리로 넘어오는 경우가 많고, 주변은 "그게 뭔데? 멍~~" 뭐 이렇고, 달나라 꿈꾸는 소리를 아무리 막아도 막아도 작업량은 드럽게 많고... 유지보수를 넘길라고 해도 표준기술 자체에 대한 시장 이해력이 없기 때문에 상당히 고통스럽죠. 여러가지 직업을 가지고 있지만, 플래시, 플렉스 개발만큼 이해관계에 의한 고통이 심한 직업은 겪어본 적이 없습니다...

(아 씨발... 정말 다 때려쳐 버리고 싶어... 이 개노므 플래시고 나발이고...)

이 부분은 개인의 능력이 얼마나 올라가냐를 넘어서 시장의 개발환경 자체가 변화되어야 해결될 수 있는 부분이지 않을까 싶습니다. 아니... 직접적으로 이런 개발환경의 변화가 해결책이 되지는 않겠지만, 적어도 해결책을 마련할 수 있는 리소스의 확보는 가능해지기 때문이죠.

말은 뻔드르하게 하지만, 사실 까놓고 이야기해서 저 자신은 "반 디자인에 반 개발" 을 섞어서 하는 혼혈종 이기 때문에 원론적인 지식에 있어서 "전문적인 개발자" 보다는 딸리는 편입니다. 그래도... 아는 것이라도 공유해보고자 강좌와 스터디 그룹을 시작합니다.

아... 졸라 진지한 분위기...;;; 글 쓰면서 먹는 초코파이가 콧구멍으로 삐져나올 것 같아... "할머니도 하는 액션스크립트" 를 읽어본 사람들은 알겠지만, 내가 이렇게 진지한 캐릭터가 아니라서...;;;

어쨌든 시작합니다~

AS3 Friends : Eclipse Ant Task 로 인생 편하게 살기

2009-09-02T01:52:06+09:00

Eclipse Ant Task

인큐베이팅 되던 Ant Task 가 Eclipse 에 공식적으로 포함되기 시작한지도 꽤나 시간이 흐른것 같습니다. Eclipse 에 기본 포함되기 때문에 Flex builder 나 FDT 모두 build 시에 Ant 를 사용하는 것을 적극적으로 지원하고 있습니다.

Ant Task 꺼내기

Ant task 는 FDT 나 Flex builder 나 기본적으로 꺼내져 있는편이지만 (Flex builder 는 잘 사용하지 않아서 정확하지 않음) 만일 Ant task 가 나와있지 않다면 Eclipse 의 View 를 새롭게 꺼내도록 합니다.

Ant task view 가 보입니다.

선택을 하면 위에 Flash Explorer 아래 보이는 것처럼 Ant task 가 보이게 됩니다.

기본적인 Ant build file 만들어보기

Ant 는 XML 형식의 문법이기 때문에 HTML 처럼 손쉽게 사용할 수 있을겁니다. 그리고, Ant editor 도 지원을 하기 때문에 작업 편리도가 높은 편이죠.

HTML 이 <html><head></head><body></body></html> 의 기본 구조를 가지고 있다면 Ant build file 은 위와 같이 <project><target></target><target></target></project> 의 구조를 가지고 있습니다.

Ant task 로 가서 Add Buildfiles 를 누릅니다.

그러면 위와 같이 build file 을 선택할 수 있는 창이 뜨게 됩니다. 테스트로 만든 test.ant 를 선택하도록 합니다.

대충 보면 알 수 있습니다. project.@name 은 build 의 타이틀이 되게 되고, project.@default 로 지정된 target.@name 은 default task 로 취급이 되어서 이 build 를 실행할때 기본적으로 실행되는 task 로 지정이 되게 됩니다. (이 부분은 나중에 이야기를 하죠.)

build 환경변수 만들기 <property>

환경변수는 두가지 종류가 있습니다. 파일경로를 지정하는 location 과 어떤 값을 지정하는 value 로 구분됩니다.

property 는 위에서 보는 것처럼 ${value name} 의 형식으로 사용이 가능합니다.

위에 보이는 build 를 더블클릭 해서 실행시키면

이렇게 console 에 내용이 뜨게 됩니다.

Properties file 로 분리시키기

하지만 위와 같이 build file 안에 property 를 포함시켜 버릴 경우 많은 문제점들이 생기게 됩니다. 일단 두 대의 컴퓨터에 각각 다른 Flex SDK 의 위치를 build file 안에 포함시킬 수 없다는 것부터 시작해서 말이죠.

보통 ant build file 을 만들때는 *.properties 형태로 환경변수 파일을 따로 만들게 됩니다.

properties 는 위처럼 name=value 의 형태로 작성하게 됩니다.

그리고, 그렇게 만들어진 properties 파일은 위에서 처럼 불러들여 사용할 수 있습니다.

위에 properties 파일에 정의한 output.asdoc 을 아래에서 ${output.asdoc} 으로 사용하는 것을 볼 수 있습니다.

Target Group

만든 target 들을 그룹으로 묶어서 일괄 실행 시키는 새로운 target 을 만들수도 있습니다.

위와 같이 depends 를 통해 여러개의 target 들을 하나로 묶어줄 경우 해당 target 은 한 번의 클릭만으로 여러개의 작업들을 일괄적으로 처리하게 됩니다.

예제 : ASDoc 퍼블리싱

뭐 위에까지 설명을 했으면 더이상 별달리 알아야 할 게 없습니다. 사용법 자체가 단순하기 때문이죠. 그리고, 특별히 필요한 기능들이 있을땐 구글을 뒤져보면 다른 사람들이 공개한 task 들이 있으니 긁어다 사용하면 됩니다.

이 아래부터는 개인적으로 사용하는 기능들을 소개해 보도록 하겠습니다.

8번째 라인은 ${output.asdoc} 폴더를 지웁니다.

9번째 라인은 새롭게 폴더를 만들죠.

11 번째 exec 은 properties file 에 정의된 asdoc.exe 를 지정하고

12 번째 라인부터는 전달할 변수들을 지정하게 됩니다.

-source-path 는 asdoc 으로 퍼블리싱할 소스의 최상위 디렉토리를 지정하고

-doc-sources 는 뭔지 잘 기억이 안나네요...;;;

-library-path 는 참조해서 사용하는 swc 라이브러리들의 폴더 위치를 지정합니다.

-window-title 이나 -main-title 은 문서에 표시할 내용을 지정하고,

-output 은 document 를 퍼블리싱 할 폴더를 지정하게 됩니다.

그 아래쪽에 delete, mkdir, copy 는 개인적으로 문서를 두군데의 폴더로 퍼블리싱 하기 때문에 만든 행동들입니다.

이렇게 대충 코딩하고 Ant task 에서 더블클릭하면 간단하게 현재 코딩중인 소스들의 document 가 나오게 됩니다. 다만, ASDoc 자체가 예외에 대해 굉장히 깐깐하기 때문에 소스상에 이상한 부분이 있으면 그냥 죽어버리므로, 코딩습관을 깐깐하게 들여야 합니다. (예를 들어 Fla 의 라이브러리에 지정된 Bitmap 같은것을 new 로 생성할때... ASDoc 을 위해서는 getDefinitionByName 을 사용하는 것이 좋고, MovieClip 내부의 instance name 을 가져올때도 getChildByName 을 사용하는 것이 좋습니다.)

예제 : SWC 라이브러리 컴파일

31 번째 라인은 flex sdk 의 compc.exe 를 지정합니다.

-o 는 만들 swc file 의 위치와 파일 이름을 지정하게 됩니다.

-l 은 참조할 swc 라이브러리의 폴더를 지정하고,

-sp 는 기본 source-path 를 지정하고

-is 는 source-path 에서 swc 에 포함시킬 package 를 지정하게 됩니다.

예제 : FTP 업로드

60 번째 라인에서 업로드할 폴더와 서버 주소, 아이디, 패스워드를 지정합니다.

62 번째 라인에서 포함시킬 파일들을 지정하게 됩니다.

63 번째 라인을 보면 알다 시피 (*) 와일드카드를 사용해서 규칙에 해당하는 모든 파일들을 포함시킬 수 있습니다.

폴더내의 모든 폴더와 파일들을 대상으로 할 경우엔 <include name="**/*.*" /> 이렇게 하면 됩니다.

하지만, 이렇게 코딩하고 Ant task 에서 더블클릭을 하면 에러가 나게 되는데요. FTP 를 사용하기 위해서는 확장 라이브러리가 필요해서 입니다.

Eclipse 환경설정에 들어가서 위의 Ant runtime 에 commons net 라이브러리와 jakarta oro 라이브러리를 Add External JARs... 를 통해 포함시켜줘야 합니다. 검색하면 손쉽게 구할 수 있는 라이브러리 들이니 다운받아 포함시키도록 합니다.

예제 : FDT 일괄 컴파일, 브라우저 디버깅

뭐 Flex task 를 사용하기도 하는데 개인적으로는 FDT 를 사용하기 때문에 FDT task 를 자주 사용하는 편입니다.

위와 같은 properties 를 참고하는 ant build 입니다.

대충 projectname 은 현재 eclipse project name 을 지정해주고, main class 는 swf로 컴파일 할 as class 를 지정합니다.

debug="true" 로 해놔야지 trace 등이 정상적으로 출력되는 디버그용 swf 가 만들어지게 되고,

target 은 퍼블리싱할 swf 파일의 위치, 이름을 지정하게 됩니다.

24 번째 라인의 startDebugger 는 현재 프로젝트에 대한 디버그 감지를 활성화 한다는 뜻입니다.

그렇게 디버거를 활성화 시키고, 25 번째 라인에서 browse 를 하면 웹브라우저를 통해서 지정한 localhost 웹서버의 문서가 뜨면서 디버깅이 시작되게 됩니다.

이런 디버깅 기능을 FTP 업로드와 함께 사용할 경우 번거로운 작업들 없이 한 번의 클릭만으로 컴파일 --> FTP 업로드 --> 디버깅을 한꺼번에 할 수 있죠. swc 컴파일과 asdoc 퍼블리싱도 같이 묶어 버리면 매우 편리합니다.

그 외에 FDT 가 지원하는 Ant 기능들은 help 에서 볼 수 있습니다.

이 내용은 http://ssen.name/recipe 에서 볼 수 있습니다.

Action script 3.0 Lanquage Reference 가이드 (F1 보기)

2009-03-11T23:33:13+09:00

playerGlobal.swc

우리가 사용하는 3.0 에서 flash. 으로 시작되는 패키지들은 모두 playerGlobal.swc 라는 라이브러리 파일에 들어있습니다. Flex SDK 를 열어보면 frameworks/libs 폴더 안에 들어있습니다.

flash 의 경우 fl. 이라는 패키지들이 같이 포함되어 있고, flex 의 경우엔 mx. 이라는 패키지들이 같이 포함되어있죠.

이 fl 이나 mx 라는 것들은 콤보박스 같은 UI 콤포넌트들과 Easing 같은 모션그래픽 같은 기능들을 포함하고 있고, (mx 의 경우엔 그 분량이 fl 과는 비교할 수 없을 정도로 방대합니다.) 소스가 공개되어 있어서 파일 경로만 찾는다면 내부 소스를 확인할 수도 있습니다. 어느정도 수준이 되면 공부하느라고 자주 찾아보게 되는 소스들입니다.

flash.data.*
AIR 에서 사용됩니다. SQLite(에스큐라이트)를 다루는데 필요한 기능들이 들어있습니다.

flash.desktop.*
AIR 의 desktop application 을 제작하는데 필요한 여러가지 기능들이 모여 있습니다. OS 의 system tray 나 AIR application 에 대한 update, Clipboard 접근 등의 기능을 지원합니다.

Clipboard 의 경우 text 에 한해서 web application 에서도 사용할 수 있습니다.

flash.display.*
보 통 가장 많이 사용하는 MovieClip, Sprite, BitmapData 등 화면에 표시되는 기능들을 포함하고 있습니다. 최근 벡터그래픽 드로윙이 개편되어서 Graphics 로 시작되는 Class 들이 엄청나게 늘어났는데, 이것들은 무시해도 됩니다.

보 통 기초단계에서 꼭 봐야할 기능은 DisplayObject, InteractiveObject, DisplayObjectContainer, Sprite, MovieClip, SimpleButton 정도이고, 이것들을 떼고 좀 더 고급 화면표시를 배우고자 할때 BitmapData, Bitmap, Shape 등을 봐줍니다. 그렇게 기초적인 디스플레이 기술들에 알게 되면 Stage 의 Event.RESIZE 와 stageWidth, stageHeight 등을 통해 전체 플래시 어플리케이션 정렬법 등을 배워두면 됩니다.

이 후 MovieClip 에 대한 고급제어가 필요할때 FrameLabel, Scene 등을 보고,
벡터 그래픽 드로윙을 할때는 flash.geom.Matrix 와 함께 Graphics... 로 시작되는 것들과 JointStyle, CapsStyle 등을 보고,
비트맵 드로윙을 할때는 역시 flash.geom.Matrix 와 함께 BitmapData 를 봐주고,
swf 들을 여러개로 분해해서 어플리케이션을 구성할때 Loader 등을 봐주도록 합니다.
(드로윙을 할때 Matrix 를 이해못하면 여러모로 어려움을 많이 겪게됩니다.)

최근엔 Shader 에 관련된 기능들도 많이 나왔는데, 이건 저도 아직 안써봐서 뭐라 말하기 어렵네요.

flash.errors.*
여 러가지 Error 들이 포함되어 있습니다. 기초 레벨에선 자주 사용되지 않지만, 공용 라이브러리 등을 만들때나 네트워크 작업을 할때 부터는 조금씩 사용하게 됩니다. debug player 를 깔고 웹서핑을 할때 종종 뜨는 경고창들이 바로 이 Error 들을 알려주는 것입니다.

직접 만든 Custom Error 들을 꼼꼼하게 사용하면 다른 개발자가 라이브러리를 사용할때 큰 도움이 되게 됩니다.

flash.events.*
ActionScript 3.0 의 핵심중에 하나라고 볼 수 있는 IEventDispatcher 와 EventDispatcher, Event 를 포함한 패키지 입니다. 이야기한 세가지를 이해하지 않으면 ActionScript 3.0 의 가장 최하 기본을 모른채 공부하고 있다고 할 수 있을겁니다.

뭐가 이야기한 세가지는 꼭 봐둬야 하며, 나머지 Class 들은 여러저기 사용되는 event 들입니다.

보통 UI 구성시에는 MouseEvent, KeyboardEvent, TextEvent 를 꼭 봐둬야 하고,
Loader, URLLoader 등의 웹자원 활용 기능을 만들땐 ProgressEvent, NetStatusEvent, IOErrorEvent 등을 봐둬야 합니다.
Timer 를 돌릴때 사용되는 TimerEvent 도 있습니다.

flash.external.*
html 의 javascript 와 통신하는데 사용하는 ExternalInterface 가 들어있습니다.

flash.fileSystem.*
AIR 에서 desktop 의 file, directory 등을 읽고, 쓰고 하는 기능들을 만드는데 사용합니다.

인터넷 상의 자원을 활용하는 flash.net.* 과 비교해보면 재밌습니다.

flash.filters.*
DropShadow, BlurFilter 들을 만드는데 사용합니다. DisplayObject.filters 와 같이 봐두고, 비트맵 드로윙 등을 할때도 사용할 수 있습니다.

쓰는건 무지 쉽지만, 막 쓰면 성능에 치명적인 영향을 미치게 되므로 절제가 필요한 기능입니다.

flash.geom.*
왜곡, 변형 등의 기능들을 포함합니다.

기초단계를 지나기 시작하면 Matrix, Point, Rectangle 을 매우, 매우 자주 사용하게 됩니다. 행렬, 거리계산 등의 수학적 지식이 뒷받침 되어야지 보다가 머리털 빠지는 일이 없습니다.

flash.html.*
AIR 에서 사용됩니다. HTMLLoader 가 Sprite 를 상속받은걸 보면 알겠지만 Flash 내부에서 HTML 객체를 만들고 컨트롤 하는데 사용됩니다.

flash.media.*
Sound, Video 등을 다루는데 필요한 기능들이 모여있습니다. Camera 나 Microphone 처럼 입력되는 멀티미디어 데이터를 다루는데도 사용되구요.

flash.net.*
서버 데이터 연동, swf 로드무비, 이미지 웹에서 불러오기 등의 인터넷 자원 연동을 할때 꼭 필요합니다.

기 초적으로 navigateToURL(), sendToURL(), URLLoader, URLRequest, URLVariables 는 꼭 봐줘야 하고, 조금 지나서 파일 업로드, 다운로드 기능을 사용할때는 FileReference 정도를 보게 됩니다.

시 간이 좀 지나면 네트웍 게임등을 만들때 사용하는 Socket, cookie 와 비슷하게 사용할 수 있는 SharedObject, swf 들끼리 서로 통신하는데 필요한 LocalConnection 등을 보게 되기도 합니다. 고급기능들이니깐 기초단계에서는 자주 사용되지 않습니다.

flash.printing.*
프린터를 통해서 출력하는데 필요한 기능들이 포함되어 있습니다.

flash.sampler.*
저도 사용해보지는 않았는데, 디버깅 상황에서 좀 더 상세한 정보들을 수집하는데 사용되는 것 같습니다. (아마도...)

Object 하나가 얼마의 memory 를 사용하는지를 알 수 있기도 하고... 뭐 여러모로 배워두면 좋을것 같은데, 나온지 얼마 안되서 저도 아직 잘 모르네요.

flash.system.*
보안에 관련된 기능들을 다루게 됩니다. cross domain 작업등을 하다보면 자주 접하게 됩니다.

Loader 를 통해서 불러온 swf 에서 Class 를 뽑을때 사용하는 ApplicationDomain 도 있습니다. 자원의 분리, 재활용을 할때 한번쯤 보게 되는 Class 입니다.

flash.text.*
TextField 로 대표되는 flash 의 text 기능을 다룰때 보게 되는 매우 중요한 패키지 입니다.

기본적으로 TextField 와 TextFormat 등을 보게되고, embed font 등을 만질때는 Font 도 자주 접하게 됩니다.

조금 고급제어를 하게 되면 TextLineMetric 등을 통해서 TextField 상의 행, 열 등을 만지게 되기도 합니다.

최 근엔 FTE(flash text engine) 라고 부르는 flash.text.engine.* 기능이 추가되어서 앞으로 점점 사용도가 줄어들 기능입니다. Flex4 gumbo 정도 부터는 FTE 를 확장한 flashx.text.* 의 패키지로 구성된 text layout framework 가 TextField 를 대체하게 될 것입니다. undo, redo, rich edit, data formatting 등을 지원하므로 내년 정도엔 지금은 html 에 밀려 뜸한 flash 를 사용한 rich text application 을 자주 보게 될겁니다.

flash.text.engine.*
위에서 이야기한 FTE 입니다. flash 에서 text 를 제어하는 새로운 방식이지만, TextField 처럼 손쉽게 사용하기는 무리가 있습니다.

flash.ui.*
마 우스 오른클릭을 하면 나오는 context munu 에 대한 커스터마이징이나 마우스 포인터 모양 바꾸기, 비밀번호 입력등에서 실수하기 쉬운 키보드의 caps lock, num lock 등이 활성화 되어있는지를 알아내는등의 기능을 만드는데 필요합니다.

flash.utils.*
최고수가 사용하는 막강 무공중 하나인 ByteArray 나 EnterFrame 대신 사용할 수 있는 Timer, 대리자를 만들때 사용하는 Proxy 등이 있습니다.

기 초레벨에서는 디버깅시에 유용한 getQualifiedClassName(), getQualifiedSuperClassName() 등은 꼭 알아두는게 좋고, 뭐 성능테스트 같은걸 하려면 getTimer() 를 알아두는 것도 좋습니다. (getTimer() 로 알아낸 시간 두개를 b-a 형식으로 빼서 얼마의 시간이 소요되는지를 테스트 하게 됩니다.)

Timer 놔두고 interval 을 사용하는 분은 없을거라 믿습니다.

flash.xml.*
최상위의 XML 을 사용하면 딱히 볼 일 없습니다. 2.0 버전때 사용하던 xml 컨트롤 입니다.

Top Level
기초단계에서는 flash.display 나 flash.net, flash.text 등을 자주 보게 되지만, 중급을 넘어서면서 부터는 여기를 무지하게 자주 보게 됩니다.

Vector, Array, XML, String, RegExp, Math, Date 등의 "우하하 기초~" 하면서 웃다간 캐작살 나기 쉬운 심오한 세계들이 존재하는 Top Level 이니, 왠만큼 조금 한다 싶을때 부터는 꼼꼼하게 공부하는게 좋은 내용들이 많습니다.

AS3 Friends : Mylyn 과 Google Code Project Issue 연동하기

2009-09-02T01:52:06+09:00

이번 이야기는 Google Code Project, Subclipse, Mylyn 의 후속편 입니다.

Mylyn 의 connector 중에서 web template 를 라는 connector 가 있더군요. 당연히 자주 사용되어지는 Google code project 역시 사용할 수 있습니다.

오늘은 Mylyn 의 web template 를 사용해서 google code project hosting 의 Task 들을 eclipse 의 TaskList 로 가져오는 작업을 해보도록 하겠습니다.

이 내용은 당연히 SVN, Eclipse, Subclipse, Mylyn, Google code Project Hosting 에 대해 알고 계시는 분들을 대상으로 합니다.

Mylyn Incubator > web templates 업데이트 하기

Eclipse 의 Software Updates... 를 선택해서 업데이트 창을 띄웁니다.

Add Site... 를 눌러서 http://download.eclipse.org/tools/mylyn/update/incubator 를 추가해줍니다. 제 경우에는 이미 설치가 되어 있겠죠.

우리가 설치해야하는 web templates connector 는 위와 같습니다. 하지만, 이것만 딸랑 인스톨 하려고 하면 에러가 뜨는데요. 그럴땐 Mylyn for Eclipse 3.4 와 Mylyn Extras 들을 같이 체크해서 인스톨 받도록 합니다.

설치가 되면 Eclipse 를 재시작 하라는 메세지가 나옵니다. 재시작 하면 지금까지 설정해놓은 Perspective 들이 모두 초기화 되어버리는 상황이 벌어지는데요. 업데이트의 영향이니 좀 불편하더라도 다시 설정을 하시면 됩니다.

Google Project Hosting 의 Issue Data 들 가져오기

우선 새로운 Task Ropository 를 만듭니다.

위와 같이 Web Template 가 추가되어있는걸 확인할 수 있습니다. Next 를 눌러서 진행합니다.

보면 위와 같이 Google Code 가 있습니다. 선택하고 자신의 프로젝트에 맞게 수정을 해줍니다.

제 경우에는 프로젝트 아이디가 (ssen-library) 라서 위와 같이 설정을 해주었습니다. (상단의 에러표시는 같은 URL 의 저장소가 이미 존재하기 때문입니다. 신경 안써도 됩니다.)

저장소를 만들었으면, 이제 저장소의 내용을 가져올 새로운 쿼리를 만듭니다.

맨처음 쿼리를 만들면 Query URL 과 Query Pattern 이 위와 같이 되어있는데요. 그것을 아래와 같이 수정합니다.

Query URL : ${serverUrl}/csv

Query Pattern : "({Id}[0-9]+?)","({Type}.+?)","({Status}.+?)","({Priority}.+?)","({Milestone}.+?)","({Owner}.+?)","({Description}.+?)"\n

쿼리 URL 은 위에 보이는 CSV 링크의 url 이 됩니다. 해당 url 을 다운받아서 메모장으로 열어보면 아래와 같이 CSV 포맷으로 보이는데요.

Query Pattern 은 이 CSV 패턴을 해석하는 역활을 하게 됩니다. 제 경우에는 Component 를 추가적으로 오기 때문에

"({Id}[0-9]+?)","({Type}.+?)","({Status}.+?)","({Priority}.+?)","({Milestone}.+?)","({Component}.+?)","({Owner}.+?)","({Description}.+?)"\n

이렇게 설정되어있습니다.

뭐 하지만 유감스럽게도 web template 이 가져오는 정보는 ID, Status, Owner, Summary 뿐이기 때문에 Priority 나 Type, Milestone 같은 중요한 데이터들을 대부분 연동해서 볼 수가 없습니다. 뭐 인큐베이팅 중인 확장이라서 아직 부족한 부분이 있는게 아닐까 싶네요.

Google Code Project 의 Issue 관리하기

Issue 를 좀 더 편하게 사용하기 위해서는 Admin 에서 어느정도 셋팅을 해주는게 좋습니다. 뭐 별로 어려운 부분은 아니니 자세한 설명은 생략하고 그냥 스크린샷만 보여드리도록 하겠습니다.

설정한 Issue 라벨들의 경우엔 실제 이슈 생성시에

이렇게 작동을 하게 됩니다.

개인적으로 템플릿은 프로젝트 멤버 (개발자) 가 사용할 새 작업사항과 유저가 리포팅을 할 오류보고만 만들어놓았습니다. 입맛에 맞게 더 추가하면 됩니다.

그리고, 아랫쪽의 Default columns shown in list view 는 Label Type-XXX 의 Type 과 연동이 됩니다. 만일 여러분이 Label 에

Module-Core

Module-Extension

이라고 추가를 해놓고, 위의 리스트에 Module 을 추가시켜 놓으면

이 리스트 상에 Module 이 추가되어 나오는 거죠.

AS3 Friends : Google Code Project, Subclipse, Mylyn

2009-01-13T14:34:42+09:00

이번 이야기는 Trac on Windows, Subclipse, Mylyn 의 후속편 입니다.

TOW 와 Mylyn 을 사용한 프로젝트의 관리는 장점들이 많지만, 아무래도 늘 상 서버를 켜놓아야 한다는 부담이 있기 때문에 선뜻 사용하기가 어렵습니다. 그리고, 이동성의 문제나 소스코드 공유나 배포의 문제점도 있죠.

그래서, 오늘은 특별한 개인 서버 없이 사용할 수 있는 Google Code Project Hosting 을 사용해서 프로젝트를 관리하고, 또 Mylyn 으로 내부적인 task 들을 관리하는 방법들을 이야기해 보겠습니다.

참고로 여기에 나오는 내용들은 기본적으로 eclipse 나 subclipse, svn, mylyn 이 뭔지 아는 분들을 대상으로 합니다.

Google Code Project 에 Project 만들기

http://code.google.com/hosting/ 에 들어가셔서 자신의 google 아이디로 로그인을 일단 합니다.

(아... 참고로 google code project hosting 은 오픈소스 프로젝트들을 지원할 목적으로 만들어진 녀석인지라 모든 소스코드가 공개되게 됩니다. 그게 싫다면 사용하지 않는게 좋습니다.)

하일라이트 된 "Create a new project" 를 누릅니다.

그럼 이런 화면이 나오게 되는데요. project name 은 domain 으로 사용되기 때문에 소문자로 써주도록 합니다. Summary 나 Description 역시 적절히 써주고, 이제 아래쪽에 license 를 선택해 줍니다.

오픈소스 라이센스들이 나옵니다. 라이센스에 대해서는 적절히 찾아서 써줍니다.

혹은 이렇게 CCL 로 사용해줄수도 있습니다. 뭐 오픈소스 라이브러리를 배포할 생각이 아니라면 딱히 자세하게 기록할 필요는 없지만요.

뭐 프로젝트를 만들었으면 상단의 Profile 을 누르면 위처럼 이동을 하게 됩니다. Project Ownership 은 자신이 운영하는 Project 의 리스트를 보여주는거구요.

그 옆의 tab 인 Settings 를 누르면 위와 같은 화면이 나오는데요. 저기 보이는 "Your googlecode.com password" 가 중요합니다. (개인비밀번호라서 가렸습니다) SVN 의 비밀번호가 되거든요. 구글코드의 비밀번호는 개인이 지정할 수 없고, 자동으로 생성되는 8자리 난수를 비밀번호로 사용하게 됩니다. 비밀번호를 교체해야 할때는 아래 보이는 Regenerate 를 눌러서 바꿔주면 됩니다.

프로젝트 사이트 접속하기

아까전 만든 project site 로 이동해보도록 하겠습니다. 아까전 만들었던 프로젝트의 project name 이 ssen-test-project 였었죠.

도메인은 http://code.google.com/p/ssen-test-project/ 가 됩니다. 하지만... 쓰잘데기 없는 쓰레기 프로젝트를 만들기 싫었는지라 최종적으로 프로젝트 생성 버튼은 안눌렀기 때문에 링크를 따라 들어가도 프로젝트는 없습니다.

예제를 개인 프로젝트로 보여드리죠. 최초 인덱스 페이지는 위처럼 나오게 됩니다.

Updates 를 누르면 위와 같은 화면이 나오게 되는데요. 이 화면에서는 wiki 나 svn 의 update 현황을 보여줍니다. 예를 들어 저 r2 라는 릴리즈 링크를 누르면

이렇게 릴리즈 별로 수정된 파일들의 리스트가 나오게 되고, 소스파일들의 경우 어떤 부분이 어떻게 수정되었는지의 분석이 나오게 됩니다.

Downloads 의 경우엔 배포할 파일을 등록하는건데, 아직 작업중인지라 등록한게 없네요. action script library 를 만들어서 배포할 생각이라면 swc 파일을 등록해주면 되겠죠. 그 옆에 wiki 가 있고 (wiki 가 뭔지는 다들 아시겠죠...;;;) Issues 의 경우엔 버그리포팅등을 받거나 할 수 있는건데... 딱히 사용할만하지는 않습니다.

이제 Source 에 가면 위와 같은 화면이 나오는데요. 여기서 Browse 는

이렇게 소스코드를 보여주고

Changes 는 이렇게 커밋 이력을 보여주게 됩니다.

그리고, 이 https 로 시작하는 url 이 이제 SVN 의 주소가 됩니다.

Subclipse 에서 SVN check out 받기

subclipse 에서 이렇게 새로 Repository Location 을 새로 등록해 줍니다.

등록해줄 주소는 아까전에 https 로 시작하는 주소를 입력해주면 됩니다. Finish 를 누르면 아이디/비밀번호를 물어보게 되는데 아이디는 자신의 구글 아이디를 입력하고, 비밀번호는 아까전에 봤던 자동으로 생성되는 비밀번호를 입력해줍니다.

뭐 그러면 SVN Repositories 에 위와 같이 나올텐데요. 여기서

trunk 에 오른클릭을 한 다음에 check out 을 받습니다.

check out 을 받다보면 이렇게 내려받을 소스들을 어떤 project 로 만들지를 결정하게 됩니다. 대충해서 내려받도록 합니다.

그러면 이렇게 Project Explorer 에 check out 받은 것들이 나오게 되는데요. 맨처음에 해줘야 할 일은

filters 를 선택해서

.* 의 filter 를 풀어주고

아무런 .* 에 해당하는 파일들 (.project 같은류의 이클립스 프로젝트 구성 파일들) 을 선택해서 오른클릭 한 다음

이렇게 Team > Add to svn:ignore 를 해주도록 합니다.

제외패턴에 .* 을 추가해주면 SVN 이 취급할 파일들에 쓰잘데기 없는 이클립스 설정파일들은 제외되게 됩니다. 이걸 해주지 않으면 쓸데없는 파일들까지 커밋이 되어서 매우 지저분한 svn 저장소가 되겠죠.

그리고, 위에 보이는 build.ant 처럼 노출되어선 안되는 파일, 폴더 들의 경우 역시 제외패턴에 등록해줘야 합니다. 특히 ant 에 ftp upload build 등을 만들어뒀다면 정보유출 가능성도 있기 때문에 조심해야겠죠. (google code search 로 검색하다보면 ftp 비밀번호 확 드러난 애들 꽤 있거든요...;;;)

여기까지 작업이 되었다면 이제 평범하게 SVN 을 사용하듯 해주면 됩니다.

Mylyn 을 사용해서 Local Repository Task 관리하기

mylyn 을 사용하면 기본적으로 이렇게 Local Task Repository 가 주어지게 됩니다. Trac 이나 Bugzilla, JIRA 와 같은 외부 서버를 사용하는 Task Repository 가 아닌, Eclipse 내부적으로 사용하는 것이지요. 당연히 Trac 이나 Bugzilla 와 같이 고급화된 기능은 제공해주지 못하지만 혼자서 작업하는 경우엔 그럭저럭 쓸만한 편입니다. 무엇보다 서버없이 Trac 과 같은 Task 관리를 사용할 수 있다는게 장점이지요.

mylyn 의 local repository 는 trac 처럼 로드맵, 버전같은 분류를 지원해주지 않습니다. 그래서 이렇게 분류가 필요한 task 들을 묶을 category 를 만들어서 관리해주는 것이 좋습니다. 저기 보이는 ssen library 0.1 이란 버전 카테고리를 만들어서 사용하는 것처럼요.

그리고, 새로운 task 를 만들때는 위에 보이는 new task 버튼을 눌러서 만들어줍니다.

task 를 새로 만들어서 이렇게 써줍니다. 일단 기본적으로 제목과 작업우선순위 (Priority) 를 지정해줍니다. Status 는 Incomplete (작업 미완료) 와 Complete (작업 완료) 를 지정해주게 됩니다. 그 아랫쪽으로 작업에 대한 스케쥴 계획을 지정할 수 있는데요. 필요하다면 Due date 등을 지정해주면 좋습니다.

그렇게 이것저것 task 들을 만들어주면 이렇게 리스트가 보여지게 되는데요. 앞쪽의 아이콘 표시를 보면 알겠다시피 Priority 와 Complete 에 대한 상황을 표시해주게 됩니다. 완료 목록의 경우 strike 처리가 되어서 보이게 되죠.

Mylyn 의 Task Activation 사용해서 작업하기

마지막으로 Mylyn 의 task activation 을 살펴보도록 하죠.

task 리스트의 앞쪽을 보면 저렇게 동그라미 표시들이 있는데요. 위에 채워져서 보이는 동그라미 (폰트가 bold 처리된 녀석) 은 현재 작업 활성화가 되어있다는 뜻입니다.

일단 간단한 시나리오를 보여드리자면

이렇게 Activation 을 클릭해서 바꿔주게 되면

Eclipse 의 작업창들이 모두 닫혀지게 됩니다. 이것은 새로운 task 의 작업이 시작되었다는 것을 의미하죠.

그리고 이렇게 소스코드 몇개를 열어놓은 다음에

Activation 을 해제해 주면

다시 작업창들이 닫히게 됩니다.

그리고, 다시 Activation 을 활성화 해주면

이렇게 닫혔던 작업창들이 다시 열리게 됩니다.

즉, task 의 activation 단위로 최종 작업환경을 기억해주기 때문에 task 의 흐름대로 체계적인 작업관리를 해줄 수 있습니다. 보통 tab 을 스스로 열고, 닫고 하면서 작업하시는 분들의 경우 맨 처음엔 익숙지 않아서 당황할 수 있으나, 익숙해지면 매우 편리해지게 됩니다.

그리고, 이렇게 task 가 활성화된 상태에서 svn 커밋을 시도하면

커밋시에 이렇게 자동으로 안내 메세지가 입력되게 됩니다.

프로젝트를 오랫동안 진행하다보면 커밋 로그를 분석하는 것도 상당히 피곤한 일이 되는데, 이렇게 task 단위로 작업하고, task 단위로 커밋을 하다보면 자신이 어떻게 작업을 했었는지에 대해서 쉽게 쉽게 파악을 할 수 있습니다.

AS3 Friends : FABridge

2009-09-02T01:52:05+09:00

ActionScript 와 JavaScript

Flash 와 HTML 은 할 수 있는 영역의 일이 완전히 틀리다고 할 수 있을 정도로 그 활용성이 차이가 납니다. 그렇게 틀리기에 서로 섞어서 사용하면서 많은 시너지 효과를 만들어내게 됩니다. 그리고, 웹개발 시에 Flash 에 익숙하지 않은 웹개발자들과의 협업에 있어서도 자주 사용되고, Flash 가 가진 컴파일해야 한다는 단점을 극복하기 위해서도 자주 사용됩니다.

보통은 ExternalInterface 를 사용하지만, 조금 복잡성이 있는 작업의 경우엔 어느덧 beta 딱지를 떼고 정식으로 Flex framework 에 포함된 FABridge (Flex - Ajax Bridge) 를 사용해보는 것도 괜찮습니다.

FABridge 의 기능?

사실 저도 많이 사용해보진 않은지라 뭐라 말하기가 애매한데, 구지 FABridge 에 대한 것을 설명하자면 이게 ExternalInterface .call() 보다는 ExternalInterface.addCallBack() 에 대한 고급화라고 볼 수 있을것 같습니다. 그러니깐 ActionScript 가 JavaScript 에 간섭할 수 있는 기능보다는 JavaScript 가 ActionScript 에 간섭할 수 있는 기능에 더 특화되어 있습니다.

Document 도 없고, 예제도 없는지라 딱 확정지어서 말하기는 어렵지만 일단 제가 파악하고 있는 바로는 그렇습니다.

ActionScript 측 작업하기

아… 일단 Flex 와 FABridge 연동은 구글 뒤져보면 우르르 나오므로 패스하고, 개인적으로 MXML 을 사용하지 않기 때문에 ActionScript 위주로 설명하겠습니다.

FABridge 의 as 파일과 js 파일은 위와 같이 Flex SDK 안에 포함되어있습니다. (왜 이렇게 숨겨둔걸까…;;;)

일단 보시다시피 FABridge 는 Flex framework 에 포함되어져 있기 때문에 FABridge 순수한 Flash 프로젝트나 playerGlobal.swc 만을 사용하는 순수 ActionScript 프로젝트에서는 as 파일만 임포트해서는 사용할 수 없습니다.

그래서 이렇게 Flex 상에서 간단한 라이브러리 프로젝트를 구성해서 swc 를 찍어냈습니다.

그렇게 찍어낸 swc 파일을 사용하면 Flash 프로젝트나 순수 ActionScript 프로젝트에서도 별다른 번거로움 없이 이렇게 FABridge 를 사용할 수 있습니다.

미리 말했듯이 FABridge 는 JavaScript 에서 ActionScript 로 간섭하는 편입니다. 그러므로 ActionScript 상에서는 그닥 해줄만한게 없는 편입니다.

주석에도 달아놓았지만 테스트용으로 만드는 txt 와 btn 을 public 이란 것을 확인하고, FABridge 객체의 초기화 부분을 잘 살펴보도록 합니다. 첫번째는 FABridge 의 target 이 될 Object 를 두고, 두번째는 연결할 FABridge 의 ID 를 적습니다.

JavaScript 측 작업하기

먼저 JavaScript 측 작업을 하는데 있어서 FABridge.js 파일의 swfobject 에 맞춰진 수정본은 "머드초보" 님의 자료를 참고했음을 밝힙니다. (http://mudchobo.tomeii.com/tt/305) swfobject 를 사용하는 분들은 URL 에 있는 압축파일을 다운받아서 그 안에 있는 FABridge.js 파일을 사용하도록 하세요.

기본적으로 주어지는 FABridge.js 파일은 swfobject 와 같이 사용할 시에 에러가 튀나오게 됩니다.

그러면 간단하게 코딩을 해보도록 하죠.

주석을 달아놓았습니다.

우선 23번 라인의 var bridgeID 가 43번 라인에서 flashVars 의 bridgeName 으로 들어가게 되고, 51번째 라인에서 swf 에 전달되게 되죠. 이렇게 전달된 bridgeName 파라메터는 ActionScript 에서 사용되게 됩니다.

그리고, 24번째 라인은 55번째 라인에 보이는 <div> 의 id 값입니다. (swfobject 에 관계된 내용이니 넘어가겠습니다.)

주목해야 하는 부분은 32번째 라인입니다. 여기서 var swf 는 FABridge.fabridge(=bridgeName).root() 를 대입받게 되고, 이후 swf 는 ActionScript 에서의 FABridgeTest 로 취급되게 됩니다.

그렇게 되기에 37번째 라인에서 getBtn() 을 통해서 ActionScript 상의 btn 을 가져오게 되죠.

이 ActionScript 상의 btn 을

이렇게 getBtn() 으로 가져오게 됩니다.

테스트 해보기

아… 당연한 이야기지만, JavaScript 와 연동부분이기 때문에 그냥 HTML 을 더블클릭해서는 보안때문에 실행이 안됩니다. 웹서버 상에 올려서 테스트를 해야 합니다.

테스트를 해보면 이런 화면이 나오게 됩니다.

Flash 상의 버튼을 누르면

이 부분의 코드가 실행되면서

정상적으로 alert 이 뜹니다.

뭐 HTML 측의 button 을 눌러도

이 부분이 실행되고

다시 ActionScript 쪽의 이 메서드가 호출되면서

이렇게 Flash 상의 txt 에 안내문이 찍히게 되죠.

그리고, 약간의 응용력을 발휘하면 이렇게도 되겠죠.

정상적으로 찍히는 것을 확인할 수 있습니다.

ActionScript 에서 javaScript function 호출하기

아니 이렇게 JavaScript 에서 ActionScript 로 간섭하는건 되는데 어째서 ActionScript 에서 JavaScript 에 접근하는건 없는거지? 라는 생각을 한참 했습니다. 이상하더라구요…

근데 생각하다 보니깐 그건 그냥…

ExternalInterface.call() 해도 되겠더만요…;;;

FABridge

보통 웹개발자들이 ActionScript 를 모르고, 왠만한 경우 웹개발자가 만든 JavaScript function 을 액션개발자가 호출하는 형태의 업무가 되므로 이 FABridge 에 대한 활용도는 현재의 개발자 생태계에서는 쓸일이 거의 없는 편일겁니다.

뭐 구지 쓴다고 해봤자 매번 링크 수정될때마다 캐귀찮게 플래시 수정해달라는 요청을 떼버리기 위해서 UI 용도로 만들어진 swf 에 직접 EventListener 를 걸수 있도록 환경셋팅 해주는 정도겠지요. 그 외에는 딱히 뭐따 써야할지 생각이 안나는 물건이네요. 아무래도 JavaScript 가 ActionScript 내부에 간섭할만한 일이 많지 않기 때문이지요.

흠… 아닐라나 일단 JavaScript 상에서 ActionScript 상의 메서드 호출이 가능하기 때문에 보통 ActionScript 에서

var info:String = ExternalInterface.call("jsFunction") as String;

과 같은 형태로 되는 작업을 JavaScript 상에서

swf.setInfo(str)

과 같이 사용할 수도 있게 되어서, JavaScript 연동시에 고질적으로 발생하던 타이밍 문제 (JavaScript 상에서 ActionScript 의 구동 시점을 결정하지 못하는 것) 을 해결하는데 사용되어질수도 있겠네요.

뭐… 일단 사용하기가 무척 불편하던 ExternalInterface.addCallBack 보다는 매우 편리하게 사용되어질 수 있으므로 연구를 해보면 여러모로 활용처가 생기지 않을까 싶습니다.

FABridge 에 대해서 좀 더 자세히 알길 원한다면

http://www.adobe.com/kr/devnet/flex/articles/framework_beta_fabridge.html

이 주소로 가서 알아보세요.

OneNote, Live Writer 를 사용한 글 쉽게 쓰기

2009-09-02T01:52:05+09:00

강좌를 쓰는데 스크린샷을 꼭 찍어야 할때가 있는데 Print Screen 키 누르고, 그림 저장하고, 다시 자르고, 업로드 하고, 문서에 넣고… 할 필요없이 바로 바로 글 쓰는데 필요한 간단한 팁입니다.

원노트의 경우

원노트의(오피스2007에 포함되어 있음) 경우 자체적으로 스크린샷 기능 (Window + S) 가 있기 때문에 쉽게 스크린샷을 찍을 수 있습니다.

원노트를 설치하고, 실행시키면 트레이바에 위와 같이 원노트 아이콘이 뜨게 됩니다.

오른 클릭을 해서 옵션 > 화면 캡처 기본값을 클립보드에만 복사 로 바꿉니다.

이렇게 셋팅을 완료하면 이제 그냥 원노트에서 글을 씁니다. 스크린샷을 첨부하고 싶을때는 단축키 Window + S 를 눌러서 스크린샷을 찍고, Ctrl+V 로 붙여넣으면 됩니다.

그리고, 글 작성이 다 끝나면

이렇게 해당 글의 목차에 오른클릭을 해서 블로그에 게시를 선택합니다.

그러면 써놓은 글들이 워드로 열리게 되는데, 블로그 계정이 셋팅되어 있지 않다면 계정관리를 누릅니다.

티스토리 계정이 있다면 티스토리 계정으로 들어가서 BlogAPI 설정을 합니다. 티스토리 계정이 없으면 티스토리 계정을 만들던, 하여튼 MetaWeblogAPI 나 BlogAPI 를 지원하는 블로그툴을 사용해서 API 주소를 알아냅니다.

그렇게 알아낸 API 주소를 워드의 계정관리에 추가해줍니다.

그림옵션은 반드시 "내 블로그 공급자" 로 설정합니다.

그러면 (계정이 여러 개라면) 이렇게 계정을 선택할 수 있게 나오는데… 다 셋팅이 되었으면 이제

게시를 누르면 자동으로 블로그 계정으로 올라가게 됩니다.

원노트의 단점

원노트의 단점은 아무래도 이게 HTML 기반의 문서를 작성하는 툴이 아닌, 오피스 형식의 문서툴 이라서 Flash 나 사운드를 삽입한다거나 CSS 를 사용해서 테이블을 꾸민다거나 하기가 어렵고, 무엇보다 폰트설정이 기본 맑은 고딕으로 되어있어서 퍼블리싱 된 문서를 보는 사람 컴퓨터에 클리어타입 설정, 맑은 고딕 폰트가 없으면 매우 매우 곤란해지는 경향이 있습니다.

왠만하면 상대방에 맞춰줘도 되겠지만, 매우 귀찮으므로… 맑은 고딕은 인터넷에 많으니 알아서 다운받아서 컴퓨터에 깔라고 하고, 클리어타입 설정은 아래 URL 에서 하라고 하면 됩니다. (까놓고 말해서 맑은고딕 + 클리어타입이 가독성이 더 높습니다.)

클리어타입 설정 : http://www.microsoft.com/typography/cleartype/tuner/Step1.aspx

윈도우 라이브 라이터의 경우

원노트와는 다르지만 윈도우 라이브 라이터라는 프로그램 역시 있습니다. 이건 프리웨어라서 그냥 검색해서 다운받으면 됩니다. 하여튼 설치합니다. 실행시켜보면 우선

계정을 추가해줍니다.

아까전의 티스토리 계정을 추가하기 위해서 기타 웹로그 서비스를 선택하고

티스토리 주소와 함께 아이디/비밀번호를 적어줍니다.

뭐… API 주소를 입력하고 어쩌고 할 것없이 그냥 알아서 찾아줍니다.

설정 완료 화면이 나오면서 블로그 연결이 됩니다.

라이브 라이터에는 원노트와 같은 스크린샷 찍는 기능이 없습니다. 원노트가 깔려있다면 그냥 Window + S 단축키로 스샷을 찍어서 Ctrl+V 붙여넣기를 하면 되지만, 원노트가 깔려있지 않다면 PicPick 과 같은 전문 스크린샷 프로그램을 사용하도록 합니다.

PicPick : http://picpick.wiziple.net/

PicPick 을 다운 받아서 실행시키면

아래쪽에 이렇게 팔렛트 모양의 아이콘이 뜨게 되는데

오른클릭을 해서 이렇게 영역을 지정하여 캡쳐하기를 하면 원노트의 부분 캡쳐와 같이 사용할 수 있게 됩니다.

캡쳐 환경설정 > 캡쳐 방식은 클립보드에 복사로 해두는게 좋고

캡쳐 환경설정 > 기능 단축키 설정 에서 영역지정 스크린샷 찍기를 단축키로 지정해놓으면 더 편합니다.

역시 작성이 끝나면 게시하기를 눌러서 올리면 됩니다. 혹은 문서를 중간까지만 저장하려면 임시저장을 눌러서 저장한 다음에 나중에 다시 열어서 이어쓰기를 하면 됩니다.

janrain openid error : Define Auth_OpenID_RAND_SOURCE as null to continue with an insecure random number generator

2009-09-02T01:52:05+09:00

23 번 라인의 define 두번째 인자를 null 로 넣어주면 제대로 돌아가게 된다.