이산적인 시간과 연속적인 시간

우리의 삶은 연속적이다. 모든 시간과 모든 날은 우리의 편의를 위해서 이산적으로 나누어지고 있지만, 그래도 우리의 생은 연속적으로 진행되는 것이다. 우리는 컴퓨터가 하는 이산적인 계산을 딱딱한 것으로 취급하지만, 역설적으로 우리도 시간을 이산적으로 쪼개서 모두 소중한 시간을 어떤 날, 어떤 시간은 더 특별하게 취급하면서 산다.

 

무덤덤하게 모든 날을 똑같이 살아가는 내가 남들을 질투해서 그렇게 느껴지는 걸지도......

barycentric coordinate

bary centric coordinate가

다음과 같이 u, v를 두 축으로 가지는 평면 좌표계를 구성하는데

v
|
|
|
|
|
|
+---------------- u

u + v <= 1이기 때문에 결국 삼각형의 영역만을 나타낼 수 있는 좌표계가 됩니다.

삼각형을 이루는 정점 세 개를 v1, v2, v3라고 하고 v1이 원점이고
v2-v1이 u축을 이루고, v3-v1이 v축을 이루면 다음 그림과 같아지고

v3
|
|
|
|
|
|
+----------------- v2
v1

coordinate frame으로 나타내면 u*(v2-v1) + v*(v3-v1) + v1이 됩니다.

풀어서 정리를 하면 v*v2 + v*v3 + (1 - u - v) * v1으로 bary centric coordinate의 표현이

됩니다(1 - u - v = w라고 하자).

이제 u, v, w가 삼각형의 어떤 영역인지를 알아봅시다.

임의의 점 (u', v')를 위의 좌표계 상에 나타내보면, 다음과 같이 됩니다.

v3
|
|
|
|           +(u', v')
|
|
+------------------ v2
v1

u,v 축이 단위길이이므로, v1, v2, (u',v')로 이루어지는 삼각형은 1/2 * v'의 크기를 가지고 v1, v3, (u',v')로 이루어지는 삼각형은 1/2 * u'의 크기를 가지고 나머지 영역인 w는 1/2 - 1/2(v' + u')의 크기를 가지게 됩니다.

면적비를 구해보면 v', u', (1-u'-v')가 되므로 v1, v3, (u',v')가 이루는 영역이 u좌표가 되고, v1, v2, (u',v')가 이루는 영역이 v좌표가 되고 나머지 영역이 w가 됩니다.

설명이 잘되었는지 모르겠네요.^^ 

프로젝트가 서쪽으로 간 까닭은

 

 이 책은 소프트웨어 개발팀에서 드러나는 안좋은 행동 패턴에 대한 모음집이다. 원제가 첫 번째 패턴인 아드레날린 정키와 마지막 패턴인 템플릿 좀비를 합쳐놓은 아드레날린 정키와 템플릿 좀비인데, 번역서의 제목이 솔직히 더 재미있게 느껴지고 가슴 속으로 심금을 울렸다.

 

 사람의 사고는 자유롭다. 그렇지만 언어적인 한계인지 아니면 학습에 의한 정형화인지 사회적인 관계의 따른 제약때문인지, 모든 사고와 행동은 그룹화가 가능한 것 같다. 그래서 개인이나 조직이나 행동의 패턴이 있기 마련이다. 뭐 이런 패턴화때문에 프로파일링이라는 것이 가능하고 그래서 멘탈리스트나, 라이투미와 같은 재미있는 미드가 나오는 것이고, 실제적으로는 범죄 수사에 도움이 되는 것이기도 하겠지만 말이다.

 

 책을 읽으면서 역시 소프트웨어 개발에서 게임개발팀이 가지는 특수성이 있다라는 생각도 들긴했다. 항상 가까운 곳에서 고객이 같이 호흡을 하고 있고, 이질적인 팀원들과 대화의 창구가 항상 열려있다는 게임 개발의 특징들로 인해서 공감이 가지 않는 몇 가지 패턴들이 있긴 했지만  대부분의 내용에서 공감이 가는 부분이 많아서  너무 재미있게 읽었고, 많은 도움을 받은 것 같다.

TargetProcess

 팀에서 agile 방법론으로 개발을 하고 있다면, TargetProcess를 사용하면 많은 도움을 받을 수 있다. 그 전에는 일일이 포스트잇에다 사용자 스토리와 태스크들을 적고, 화이트보드에 붙여서 진행중,완료구역으로 트레킹을 수작업으로 일일이 하느라 불편하고 무엇보다, 상태를 저장할 방법이 적당하지 않다는 것이었다.

 

 이 모든 것들을 해결해주는 Web-based 툴이 바로 TargetProcess이다. 유명한 게임 개발사인 Bioware에서도 사용하는 것인데, 평가판으로 몇개월 사용해보니 장점이 많은 것 같아서 정식라이센스를 하고 팀에 도입하기로 결정했다.

 

 그런데 솔직히 가장하고 싶은 이야기는 TargetProcess가 좋다라는 이야기가 아니라 화이트보드에서 수동으로 관리할 때도 태스크를 생산하고 트레킹을 잘하지 못하던 개발자는 여전히 똑같았다. 모든 방법론에서 가장 중요한 가치중 하나가 실천이라고 하는 이유를 다시 한번 느끼게 된다.

 

 또 단점이라면, 화이트보드가 있을때는 지나다니면서 가끔 보기라도 하기때문에 전체적인 업무에 대한 가시성이 높았는데 TargetProcess는 접속을 잘하지 않는 경우가 많아서 가시성이라는 면에서 봤을 때는, 화이트보드보다 못하다는 생각이 든다.

 

 

 

규범의 디자인

펼쳐두기..

펼쳐두기..

 

 

지하철의 에스칼레이터를 보면 오른쪽 줄은 서있는 줄이고 왼쪽은 이동을 하는 줄이라는 규범이 디자인되어 있다. 이러한 규범을 디자인해서 정착하는데 그렇게 오랜 시간이 걸린 것 같지는 않다. 그런데 이 디자인을 엇갈려서 양쪽 모든 서있는 것으로 고치려한 서울지하철공사의 노력은 헛수고인 것 같다. 한번 적용된 규범은 다른 규범으로 그렇게 쉽게 대체되지 않는 것 같다.

 

 이런 이야기를 꺼낸 것은 최근 오른쪽 보행 규범의 디자인에 대해서 이야기를 하려고 하기때문이다. 역사가 짧은 에스칼레이터의 규범 조차도 이미 자리잡고 있는 규범을 대체하지 못하는데, 언제부터 시작된지 모르는 좌측통행을 우측통행으로 바꾸려하는 우매함으로 인해서, 과장해서 말하면 지하철 역사내에서 이동은 항상 아비규환이다.

 

 사람의 행동 유도를 위해서 이곳저곳에 우측으로 보행이라는 스티커들을 붙쳐놓았지만, 오랫동안 머릿속에 규범으로 인식된 좌측통행의 지배력을 능가하지는 못하는 것 같다.

 

 우매한 규범의 디자인이 혼란만 가중시키고 있다는 느낌을 지울 수 없다.

아 오로라를 보러가고 싶구나

 

겨울철 노르웨이에서 오로라를 볼 수 있는 확률이 가장높다고 하던데......

 

후띠루튼 크루즈를 타고 노르웨이 서해안을 따라 떠나느 여행이라. 오로라는 정말 보고싶다. 어디 멀리로 떠나본지도 오래됐고, 5박7일에 2,790,000원이라...... 이번 겨울이 지나기전에 한번쯤 가고싶은 여행지다.

override keyword

 어제 VUTPP의 구글 테스트용 Bind코드가 구글 테스트 1.4버전과 호환되지 않아서, 고치면서 고생했던 것이 VUTPP용 Listener class를 만들 때,

 

 이전 버전에선 본래 void OnNewTestPartResult라는 이벤트를 발생시키는데, 1.4버전에선 그 event의 이름이 OnTestPartResult로 바뀌어서 교체를 하고 다른 수정부분들도 수정을 하고 당당히 컴파일을 성공해서 실험을 하는데 왠일인지,

 

 함수가 호출되지 않아서 bRun의 값이 false인 상태로 있어서 모든 테스트들이 다 can't find test에러를 발생시키는 것 아닌가?

 

 좌절하고 있었는데, 가상 함수를 다시 잘 살펴보니 이전 버전은 인자가 포인터였는데 이제는 레퍼런스로 바뀐 것 아닌가? 결국 함수가 오버라이드되지 않고 새로운 함수를 정의한 것이 되었으니 이벤트 함수가 호출되지 않았던 것이다.

 

 나는 오버라이드하고 싶었는데 그 의도를 컴파일러한테 알려줄 수가 없으니 컴파일러가 오류를 알려주지 못하는 것이라서, 컴파일러한테 의도만 전달할 수 있으면 쉽게 발견할 수 있는 오류였던 것이다. 그런데 그런 역활을 해주는 keyword가 visualstudio 2005에서 추가되었는데 그것이 바로 override 키워드다.

 

 이것만 알았어도, 고생 덜했을텐데......

 

 

다시 VUTPP

main.cpp

GoogleTest 1.4버전과 Sample로 들어있는 GoogleTest Bind용 main.cpp가 호환되지 않아서 컴파일이 되지 않는다. 그 사이 GoogleTest의 소스 구조가 좀 바뀌었나보다. 뭐 간단한 일이라서 직접 수정해서 첨부한다. 뭐 이 블로그에 방문할 사람이 있을까 하지만, 필요한 분이 있다면 가져다 쓰시길......

Borderland

최근 열심히 즐기고 있는 게임. 흔히 FPS 디아블로라고 부르는 게임임. 헉슬리가 FPS+RPG가 잘못 혼합된 형태라면 이 게임은 잘된 케이스임. 발매될 때까지도 모르고 있었던 게임인데, 정말 물건임!!!

 

지금 회사에서 Unreal을 사용해서 NPR느낌으로 게임을 만들고 있어서 Unreal을 사용해서 첨으로 NPR느낌의 게임을 만드는지 알았는데, 이 녀석이 나오면서 이제 그냥 따라쟁이 게임이 되겠군.

동생이야기

 

 작년에 Daum에서 웹툰 작가로 데뷔해서 이런저런 집안 사정으로 연재 내내 악플로 시달려오다가 한 동안 다음 작품을 준비하는 기간이 길어졌지만, 올해 다시 시작한 연재물이 바로 Hang-off다. 형인 나도 황당하게도 바이크 만화였던 것이다. 물론 동생이 바이크를 좋아해서 고등학교때도 바이크로 등교를 하긴 했지만, 어떻게 이야기를 진행할지 궁금했는데 26화나 진행 중......            

헝가리언 표기법의 무용론

실용주의 프로그래머를 읽다보니, 저자가 헝가리언 표기법은 객체지향 시스템에서 전혀 적절하지 못하다는 이야기가 나오는데, 전적으로 동의한다.

사용자가 타입을 정의할 수 있는 언어들에서 각 타입마다 일대일 대응이 되는 접두어를 할당하는 것은 사실상 힘겨운 일이며, 결국 여러 타입들이 하나의 접두어에 대응되는 중복이 생겨난다. 이러한 중복은 의미상의 오류를 발생시킬 소지가 크고 의미상의 오류는 정말 가장 발견하기 힘든 버그가 되는 경우가 많다.

 

imays

 그래서 제 회사에서는 프로그래머들이 primitive type을 제외하고 접두어에 변수 타입을 안넣는걸 권장하고 있습니다.

CppCheck

http://www.thisisgame.com/board/view.php?id=302087&amp;category=106&amp;subcategory=2

에서 발췌.

 

NCSoft에 다닐 때 들었던 이야기 중에 삼성은 코드품질을 분석하는 툴이 있어서 그 툴로 코드를 분석해서 프로그래머들의 고과점수를 매긴다는 소문이 있었는데 바로 그 소문의 툴이 Coverity Prevent이라는 정적분석툴 소프트웨어 시장 점유율 25%를 차지하고 있는 어마어마한 녀석이다. 물론 가격도 어마어마해서 현재 우리 벤처기업에선 엄두도 내지 못하는 녀석인 것이다.

UnitTest는 특정 행위에 대한 결과가 정확한지 확인하고 객체의 상태 중심적인 테스트인 것이지, 언어적인 측면에서 실행시 발생할 수 있는 잠재적인 오류를 알려주지는 못하기때문에 개인적으로 정적 분석툴에 대해서 관심이 많이 있었는데, Visual Studio에 /analyze라는 옵션이 있어서 컴파일때 정적 분석을 할 수 있다는 것은 알지만, Team Suite버전에 있다라는 씁쓸한 소식과 Tema Suite의 가격을 알아보니 Coverity Prevent보다는 진짜진짜 저렴한 가격이지만 그래도 1300만원대여서 Professional버전을 사용하고 있는 우리의 실정으로는 그것조차 먼 하늘에 떠 있는 별과 같아서 꿈만 꾸었는데, 여기 저기 블로그들을 돌아다니다 알게된 것이 바로 CppCheck라는 오픈소스 정적 분석툴인 것이다. 상용툴에 비해서 아직 부족한 기능이지만 아무 것도 확인하지 않는 것보다는 나을 것 같아서 프로젝트에 도입 결정......

되도록이면 빠르게 업데이트되어서 정말 멋진 녀석으로 성장하길 기도해야겠다. 몰론 항상 바쁘다는 핑계로 오픈소스 프로젝트이지만 기여할 생각은 전혀없다. 솔직히 얘기하면 기여할 능력이 없다라는 것이 정답일 듯......

VUTPP를 사용해보고......

서버 개발을 위해서 개발 환경을 구축하면서, TDD를 위해서 UnitTest++를 쓰려고 Google에서 검색하다가 발견한 Add-in 프로그램인 VUTPP, 지겨운 콘솔 Output이나 XML Reporter에서 벗어나 GUI로 TEST들의 결과와 실패 이유를 볼 수 있다는 엄청난 장점을 가지고 있지만 사용을 하면서 몇몇 가지 단점들을 발견했다.

솔직히, 시간을 내서 OpenSource로 이런 프로그램을 만든 분들의 노고를 생각하면 이런 단점들을 가지고 왈가왈부하는 것이 참 쫌스러운 행동이지만, 그래도 항상 구경꾼이 할말이 더 많은 법이라서......

단점을 적어보자면 다음과 같다.

• 우선 Project의 설정이 NMake로 되어있으면 PreprocessorDefinitions에서 VUTPP_UNITTEST++ define을 읽어오지 못하지만, 약간의 소스 수정으로 정상적으로 동작하게 고칠 수 있다.
• 그 다음은 마찬가지로 NMake일 때 Run All, Run Selected가 다 작동하지 않는다. 실행파일 경로를 얻어올 때, bind설정이, application, dynamiclibrary이렇게 두 가지 밖에 없어서 실행파일 경로가 null로 세팅되기 때문이다.
• 마지막으로 x64 플랫폼으로 컴파일을하면 Bind Failed(Timeout) 오류가 난다. 같은 프로젝트를 win32로 컴파일해서 해보면 정상적으로 동작한다.

개인적으로 Custom BuildTool을 만들어서 사용을 하고 있기때문에, 위의 단점이 엄청크게 느껴지긴 하지만, 누군가를 위해서 이런 공개용 프로그램을 만들어 본 적이 없기때문에, 스스로의 무능력함을 책망할 뿐이다.