dieBuster

http://help.adobe.com/ko_KR/AS3LCR/Flash_10.0/flash/media/Sound.html#play()

일단 공식문서를 보시면 아래와 같은 반환 값에 대한 설명이 있습니다.

반환값
SoundChannel — 사운드 제어에 사용하는 SoundChannel 객체입니다. 사운드 카드가 없거나 사용 가능한 사운드 채널이 없을 경우, 이 메서드는 null을 반환합니다. 동시에 사용할 수 있는 사운드 채널의 최대 수는 32개입니다.

원래 SoundChannel 자체는 Sound.play()의 반환값으로 얻게 됩니다. 하지만 사운드 카드가 없는 경우 아예 null을 반환하기 때문에 이후 여기서 생성된 SoundChannel을 이용하여 음량을 조절하거나 위치를 이동하는 등의 모든 행위는 null객체 접근 에러가 되어버립니다.

제가 특별히 윈도우7을 지목하는 이유는 이 OS에 재밌는 기능이 들어있기 때문입니다. 사운드카드가 있음에도 불구하고 연결된 스피커나 이어폰이 전혀 없는 경우 윈도우7이 스스로 사운드카드를 비활성화시키는 기능을 갖고 있습니다.

일반적인 노트북의 경우 이어폰을 연결하지 않아도 무조건 스피커가 연결되어있는 상태이기 때문에 경험하기 어려울 수 있습니다만, 데스크탑에서 스피커도 이어폰도 연결되지 않는 경우 사운드채널을 이용하는 어플이 무조건 적으로 다운되는 경우가 많습니다.

따라서 사운드 채널을 사용하는 어플은 반드시 사용 전에 널객체 조건으로 검사를 한 뒤 사용하도록 소스를 고쳐야합니다.

주문한 책이 도착했습니다. 실험을 반복해본 결과 코코아 자체 만으로 게임에 필요한 퍼포먼스는 전혀 나오지 않는다는 결론에 도달했습니다. OpenGL ES 책이야 여러 개 있지만, 역시 코코아랑 같이 돌아가는 꼴을 확인해야해서 한권 구매했습니다. 내용은 참 나이브하군요.

하지만 도움이 됩니다.

개인적으로는 현재 PC에서 결국 모든 설치형 어플이 지고 웹어플 정확하게는 브라우저가 승리한 것처럼 과도기가 지나면 모바일어플도 설치형은 지나가고 웹어플이 점령할거라 생각합니다.

애플이 주장하는 html의 미래에선 결국 구지 코코아어플을 만들 필요가 없다는 결론에 이르기 때문이기도 하구요.

현재 PC시장처럼 설치형 어플은 결국 매우 강력한 수준으로만 생존하지 않을까요 ^^;

회사에 자바스크립트 관련 책은 정말 많습니다만, 문제는 너무 어렵거나 너무 두껍다는 것이었습니다.  MSpress답게 명쾌하고 알찬 구성으로 되어있습니다.
핵심원리는 국내저자임에도 불구하고 상당히 고심하여 쓴 흔적이 많습니다. 프로그램이 뭔지, 컴터가 뭔지 잘 모르는 사람들에게 추천합니다.
게임마케팅은 일단 실무입장에서 정리한 다른 책이 없다는 점에선 유일한 책이 아닌가 싶습니다.

이번엔 정말 직원교육용 책들만 한 가득 사온 느낌이군요. 돈 뽑으려면 직원들 머릿 속에 우겨 넣어야 할 듯.

인자객체

원래 컴터는 아무 뜻도 없는 변수명으로 백만개를 만들어서 함수도 없이 코드를 나열해도 잘 작동합니다. 애시당초 문제는 그걸 개발하는 사람은 그런 복잡성을 감당할 수 없다는 거죠.

인자객체를 사용하는 이유는 함수가 필요로 하는 인자를 코드힌트로 제공받기 위해서입니다. 특정 함수에 필요한 인자들이 복잡한 기능이나 제약을 갖고 있다면 그것을 이해하는 걸 넘어 외워야 하는 부담 때문에 사용하지 않게 됩니다. 여러분들은 정말로 drawGraphicsData 를 사용해보셨나요? 혹은 GraphicsGradientFill의 옵션을 사용하고 계신가요? 복잡한 함수일수록 사용하지 않게 되고 그러다 보니 필연적으로 CS4같은 비주얼화 된 툴에 의존하게 됩니다. 결과적으로 코드로 생산하지 않은 컨텍스트가 결과물에 다수 포함되고 나중엔 이것이 개발자의 잘못인지 디자인의 잘못인지 디자인을 다시 컨트롤한 개발자의 잘못인지 점점 알 수 없게 되고 맨날 플래시 개발자만 밤을 세고 있는 상황이 됩니다.

쨌든 개발자가 쓰기 편한 상태가 아니면 절대로 그 함수나 객체는 사용되지 않을 것이란 거죠.

그러한 편리한 개발을 위해 인자객체를 도입하여 보다 친절한 코드힌트로 개발을 돕는 설계를 합니다. 인자객체의 핵심은 메서드의 반환값이 this라는데 있습니다.

더보기 – 인자객체의 그 다음 »

이 책은 실용주의 프로그래머 시리즈의 최신작으로 Git라 불리는 버전관리 시스템을 다루고 있습니다.

이미 SVN에 익숙해졌는데 왜 Git를 써야할까라는 질문부터 얘기해보겠습니다.

실제 이클립스에서 대다수의 프로그래머가 하는 일은 SVN에만 의존적이지 않습니다. 반드시 로컬히스토리를 같이 사용하게 됩니다.
왜냐면 원격지에 있는 SVN에 커밋하는 건 수많은 애자일 개발론이 가르친대로 단위테스트를 통과하여 버그가 없는 코드만 커밋하는게 기본이기 때문입니다.
하지만 개발 시엔 커밋과 커밋 사이에도 수많은 수정, 저장이 있고 이러한 스냅샷 내에서도 자유롭게 변경점을 확인하여 되돌리거나 수정하는 등의 작업이 이루어집니다.
따라서 실제 개발 시점에서 생각해보면 SVN의 버전 사이에 차이점을 인식하는 이벤트보다는 로컬 히스토리를 뒤져서 처리하는 횟수가 훨씬 많습니다(전 심지어 이클립스를 인스톨하자마자 로컬히스토리 용량부터 늘리고 보는 타입입니다)

어쨌든 이러한 현실 자체가 로컬 저장소와 원격지 저장소가 서로 다른 니즈를 갖고 있다라고 얘기해주고 있습니다.

분산버전 관리 시스템이란 쉽게 얘기해 로컬에서 작업할 때는 이클립스의 히스토리 같은 로컬 저장소에 그 이력을 꾸준히 기록해가다가 네트웍 넘어에 있는 원격저장소와는 로컬저장소를 통채로 동기화 시키는 방법입니다.

이렇게 함으로서 이클립스라는 특정 프로그램이 제공하는 히스토리기능에 의존하지 않고(혹은 다른 히스토리 기능) 손쉽게 로컬에서 프로그램독립적인 히스토리를 관리할 수 있으며 네트웍에는 이를 히스토리상태로 동기화 시키므로 보다 지능적이고 향상된 통합이 가능해집니다.

이러한 분산버전관리는 이미 개념이 오래된 내용이지만 Git가 각광받는 이유는 훨씬 더 편리하고 강력하기 때문이겠죠?

최초 이 Git는 간단한 쉘스크립트에서 시작했습니다. 리누스가 새로운 버전의 리눅스를 개발하기 위한 코드 관리 차원의 유틸을 작성한 게 기원이죠. 개발 이전에 개발에 필요한 바른 환경과 자동화를 먼저 생각한 뒤 개발을 해가야한다는 점은 현대 개발규모를 보건데는 거의 필수적이라 할 수 있습니다.

이 책은 다른 실용주의 시리즈처럼 얇고 따라해보기 편하다는 것이 장점이자 단점이라 할 수 있습니다.

참조로 현재 Git는 윈도우즈 지원이 여전히 미약하여 SVN처럼 쾌적하지 않습니다. 단지 이클립스 플러그인은 나와있고 나름대로의 유틸도 출시되고 있는 상황입니다.