ByteArray는 플10에서 추가된 가장 강력한 클래스입니다. 사실 수많은 기저 클래스를 Vector와 ByteArray와 또한 ApplicationDomain.domainMemory 매커니즘으로 이사시킨게 플9에서 플10으로의 이전 핵심이라 할 수 있습니다.

잡설은 대략 그만하고 암튼 이번 글의 주제는 저번에 썼던 포스팅에서 ByteArray를 문자열로 치환하는 것에 대한 언급을 했는데, 그것에 대한 포스팅입니다.

Continue reading ‘byteArray를 문자열로 만들기’ »

원래 PMD는 오픈소스로 진행되는 일종의 문자열 검사기 입니다.

미리 규칙을 정해놓고 텍스트파일을 검사해서 해당 문자규칙에 맞지 않으면 레포트를 해주는 툴인데 원래는 자바를 위해 개발되었으나 어느새 범용적인 툴로 자리잡고 있습니다.

PMD 홈은 여기입니다.

컴파일러가 코드에 대해 검사를 해주는데 왜 이게 필요할까요?

컴파일은 되지만 올바르지 않다고 생각할만한 코드는 얼마든지 있기 때문입니다. 예를 들어 case문 뒤에 break는 안 써도 되지만 대부분 디버깅하기 어려운 런타임에러를 만들어 낼 뿐입니다.

따라서 이러한 경우 case 문 뒤에는 반드시 break가 와야 한다. 아니면 경고를 내라 라는 규칙을 설정해두면 컴파일에러에도 안 나오는 잠재적인 에러를 방지할 수 있습니다.

이러한 추가적인 코드 검사기는 코딩 스타일에서 팀에서 정한 코딩 규칙 등도 모두 강제할 수 있는 수단을 제공합니다.

Flex PMD 설치 방법

1. http://opensource.adobe.com/wiki/display/flexpmd/Downloads 에 가서 All – in – one – bundle 을 받는다.
2. 안전하고 계속 사용할 폴더에 푼다.
3. 이클립스의 소프트웨어 업데이트를 통해 http://opensource.adobe.com/svn/opensource/flexpmd/plugin/trunk/flex-pmd-eclipse-plugin-site 를 잡아주고 플러그인을 설치한다.
4. 환경설정의 FlexPMD로 들어가 FlexPMD command line installaion 항목에 2번의 압축 푼 폴더에 있는 flex-pmd-command-line-1.0.jar 를 지정해준다.
5. 환경설정의 FlexPMD에서 FlexCPD command line installaion 항목에 2번의 압축 푼 폴더에 있는 flex-pmd-cpd-command-line-1.0.jar 를 지정해준다.
6. 뷰패널에서 FlexPMD view를 추가해준다.
7. 이제 아무 프로젝트나 가서 src폴더에서 오른버튼을 누르면 나오는 FlexPMD 메뉴의 Run FlexPMD를 실행한다.
8. FlexPMD View 패널의 정보를 참조하여 코드에 반영해본다.
9. 만약 PMD실행결과가 x마크를 만들어 컴파일을 방해한다면 FlexPMD View 패널 우상단에 있는 빨간 버튼은 누르면 이를 제거할 수 있다.

자신만의 룰셋 설정방법

1. 슬슬 이 모든 룰셋이 다 필요없고 선택적으로 쓰고 싶은 생각이 든다.
2. http://opensource.adobe.com/svn/opensource/flexpmd/bin/flex-pmd-ruleset-creator.html 에 간다.
3. 필요없는 룰셋을 쓰레기통 표시로 지운다.
4. export하여 pmd.xml을 적당한 곳에 저장한다.
5. 이클립스의 환경설정의 FlexPMD로 들어가 FlexPMD custom ruleset을 아까 받아온 xml로 지정해준다.
6. 이제 필요한 룰만 검사할 수 있게 되었다.

더욱 더 커스터마이징 하고 싶을 때

1. PMD룰 클래스를 공부한다.
2. 룰 클래스를 만들고 ant Task로 다시 래핑한다(ant task도 공부한다)
3. 새로 만든 룰셋을 룰xml에 추가하여 규칙을 추가한 커스텀 룰셋xml을 작성하여 적용한다.

결론

코드의 품질검사는 이미 대규모 프로젝트에서 기본입니다. 플래시, 플렉스 프로젝트도 점점 대형화 되어가는 추세 속에 당연히 도입되어야 하는 부분이겠죠. 익숙하지 않다면 반복하여 숙달시키고 익숙해집시다.

라이브러리의 라이브러리 의존성이 문제인 경우

한 가지 간단한 예를 생각해 보겠습니다. 만약 지금 개발하려는 라이브러리가 범용적인 3D 라이브러리라고 합시다. 다음과 같은 목표를 갖고 있다고 가정해보죠.

• 다양한 기저 라이브러리를 엔진으로 교체하여 사용할 수 있다.
• 3D엔진별로 공통적으로 제공되는 기능은 엔진의 기능을 사용하고 엔진이 지원하지 않는 기능은 추상층에서 제공한다.
• 물리엔진과 통합된 api를 제공한다.
• 다양한 3d포멧을 추가적으로 지원한다.
• 고수준의 유틸리티 기능을 제공한다.

이러한 라이브러리를 구축하는 경우 다양한 엔진들과 호환이 가능하려면 import를 꽤나 여러 가지 패키지로부터 해 와야만 합니다.

3D엔진만 해도 pv3d, away, alternativa, infinity정도를 기본으로 수많은 엔진이 존재하고, 애니메이션을 위해 tweenMax를 비롯한 수 가지의 트위너들, 물리엔진 역시 유명한 box, wow 등 아마 이 엔진이 범용적이다 라고 불리우려면 20가지 정도의 기존 라이브러리들과 관계를 맺게 됩니다.

이 결과는 역설적으로 전혀 범용적이지 않은 엔진이 된다는 것입니다. 이유는 실제 이 소스를 갖고 컴파일을 하려면, 호스트가 pv3d, tweenMax로 가려고 했으나 위에 열거한 모든 라이브러리를 프로젝트에 추가하지 않으면 컴파일이 되지 않기 때문입니다.

또한 호스트코드 입장에서는 사용하려는 라이브러리가 의존하는 라이브러리를 인지할 수 없고 오직 에러 메세지로만 알게 되죠. 이러한 상황은 매우 일반적이라 이를 알리는 방법은 고작해야 문서화에 명시하는 정도입니다만, 문서화란 여러분들이 어도비나 트윈맥스 정도의 인지도를 갖고 있지 않다면 문서를 사람들이 봐주지 않기 때문에 쓰나 안쓰나 비슷합니다.

따라서 범용적인 라이브러리를 다른 라이브러리들의 코드합체(?)로 구축한다는 것은 호스트 측의 사용성을 생각해보건데 상당히 무리라는 것이죠.

이것이 연계참조의존성이라고 알려져 있는 라이브러리가 다른 라이브러리를 베이스로 구축될 때의 가장 큰 문제점입니다.

Continue reading ‘컴파일 시의 라이브러리 의존성 해결’ »

v10과 v11은 중대한 인터페이스의 변화가 꽤나 많았습니다. 덕분에 추상트위너를 사용하는 저에게는 재난이었습니다.

간단히 몇 가지 주의할 점을 짚어 보겠습니다.

1. 옵션에서 바뀐 점

• loop → repeat : {loop:3} 이 {repeat:3} 으로 변경됨.
• 기존에는 무한 루프가 0이었으나 -1로 변경됨
• yoyo가 기존에는 loop 대신 사용하는 개념이었으나 현재는 Boolean으로 바뀌어 repeat를 한 뒤 속성으로 처리됨
• repeatDelay 추가( 드디어! )
• startAt 추가 ( 편하다! ) {startAt:{x:3, y:5}, x:10, y:15} 초기화를 지정할 수 있음

2. 메서드의 변화

• killAllTweens → killAll
• killChildTweensOf 추가 ( 편하다! ) TweenMax.keillChildTweensOf( spriteA ); spriteA의 자식은 전부 해제

3. 패키지의 변화

• gs.TweenMax → com.greensock.TweenMax
• gs.easing.Back → com.greensock.easing.Back

mxmlc에 추가로 주는 구문
-static-link-runtime-shared-libraries=true -target-player=10.0.0 showunused-type-selector-warnings=false -keep

compc에 추가로 주는 구문
-debug=false -compute-digest=true -target-player=10.0.0

혹시 여기에 의견 있으시다면 많은 댓글 성원 부탁드립니다. 정말이지 가장 공유하고 싶은 노하우 입니다.