검색결과 리스트
프로그래밍 에 해당되는 글 428건
- 2014.01.06 배경 화면 지우기
- 2014.01.06 기본 틀 소스
- 2014.01.06 새로운 각오
- 2010.01.06 UML Relation
- 2010.01.06 좋은 프로그래머와 나쁜 프로그래머
- 2008.09.04 Lucas Kanade Tracking 에 관하여
- 2008.09.01 glClear( ) 와 glClearColor( ) 의 차이
- 2008.08.19 Point Tracking 에러
기본 코드를 확인해보자
SetupRC() 함수는 초기에 한 번 호출 된다 ( Init() 함수와 같다고 보면 된다 )
SetupRC() 함수 안에 Region 1 안에 glClearColor(0.0f, 0.0f, 1.0f, 0.0f); 를 입력한다
이 함수는 지우는 색을 지정하는 함수이다
일단은 처음에 한 번만 지정한다
Region2에 다음 코드를 입력한다
glClear(GL_COLOR_BUFFER_BIT);
Color Buffer(색상 버퍼, 픽셀 버퍼)를 지우는 함수이다
GL_COLOR_BUFFER_BIT로 플래그로 설정한다
색상 버퍼 이외에도 버퍼 종류로는 깊이 버퍼, 스텐실 버퍼 등이 있다
이 버퍼들은 이후에 자세히 다룬다
glutSwapBuffers() 함수를 추가한다
이 함수는 더블 버퍼일 때 Front Buffer와 Back Buffer를 교체한다
코드의 추가 내용은 다음과 같다
결과 내용은 다음과 같다
우리가 원하는 대로 창을 지정한 색으로 다 지우고 그 색으로 채웠다
다음 과정은 이 위에 원하는 그림을 그리자
아래의 코드는 전체 코드이다
* 프로그래밍 연습
1. 배경 화면을 빨간색으로 채워보자
2. 배경 화면을 녹색으로 채워보자
3. 배경 화면을 노란색으로 채워보자
앞으로 사용될 기본 코드이다
Visual Studio 2010을 사용했다
Console Application을 사용했고
Empty Project이고 Unicode에서 구현한다
다음 소스는 기본 틀이다
맨 위의 주석 두 줄은 GPL License의 기본 틀이다
OpenGL 기본 세팅은 생략한다 다른 사이트를 참고하기 바란다
크게 다른 프로그램을 만들지 않는 한 Region 으로 구분, 코드를 추가한다
다음은 실행 결과이다
코드와 일치시켜서 알 수 있는 것은
4-3과 4-4의 코드가 적용 되었다는 것을 확인
4-3 윈도우 사이즈가 800 x 600 이다
4-4 윈도우 타이틀 제목이 "OpenGL Basic Code Window~~!!" 이다
4-8 은 GLUT 프레임 워크를 실행하는 기능이다
4-5는 화면의 사이즈가 변할 때 호출되는 콜백함수(ChangeSize)를 등록한다
4-6은 화면이 그려질 때 호출되는 콜백 함수를 등록한다
다음에 할 일은 창에 나타난 부분이 배경화면인데
이 부분을 지우는 부분을 구현하도록 한다
즉 창 바탕 화면을 원하는 색으로 칠해보도록 하자
* 프로그래밍 연습
1. 윈도우 사이즈를 400 x 200으로 수정해보자
2. 윈도우 타이틀 제목을 "Hello, World"로 바꾸어 보자
5년 만에 제대로 다시 자료를 정리하고 어느 정도까지 기술을 오픈하고
라이센스를 걸어야 할 지 모르겠다
상업적으로 많은 돈을 벌 수도 있고
GPL로 오픈 하자니 상업 쪽에서 안 쓰면 활용 가능성이 없을 수도 있고
BSD로 하자니 막 갖다 쓸 수도 있고 해서
우선 GPL 라이센스로 오픈하고 정말 상업적으로
필요하신 분들은 lividious@naver.com 으로 연락주시면
BSD 허가 여부를 알려 드리겠다
그리고 대부분은 핵심 코드만 올려놓거나 추상적으로 이론만 올려 놓으면
아무 도움도 안 되고 공부도 안 된다
물론 머리 좋은 사람은 단박에 알아낼 수 있지만 나 같은 사람은
그렇지 못하다
소스 코드만 올려 놓는다.
다이얼로그나 솔루션은 알아서 하시고
그러나 너무 복잡한 프로그램일 때는 같이 올려 놓는다
OpenGL, OpenCV, CUDA, Image Processing, Augmented Reality, 3D Reconstruction 에 관해 일단 자료 정리 하고
도전 분야는 Network Programming, Pattern Recognition, 동영상 프로그래밍에 관해 할 생각이다
추가 분야로는 리눅스, C#이 될 것이다.
다시 열심히 하자
- Code
{
void play(B b)
{
}
}
{
int num;
}
출처 : [기타] http://blog.naver.com/blubeard/80035938698
Code Craft 요약 – 좋은 프로그래머 나쁜 프로그래머
1. 방어하기
l 좋은 프로그래머
- 자기 코드가 튼튼한지 신경을 씁니다.
- 모든 추측을 방어적 코드안에 명시적으로 캡처해서 표현합니다.
- 가비지가 입력되었을 때에도 잘 정의된 동작이 실행되기를 원합니다.
- 코드를 작성하면서 그 코드에 대해 신중히 생각합니다.
- 다른 사람의 어리석음으로부터 코드가 자신을 보호하도록 작성합니다.
l 나쁜 프로그래머
- 자기 코드 안에서 잘못된 일이 발생할 수도 있다는 사실을 생각하고 싶어 하지 않습니다.
- 고장을 일으킬 수도 있는 코드를 통합하라고 내주고, 다른 사람이 대신 정리해 주기를 바랍니다.
- 코드의 사용법에 대한 중요한 정보를 자기 머리 속에만 넣어둠으로써, 쉽게 잊어버릴 수 있게 합니다.
- 거의 생각을 하지 않고 코드를 작성하기 때문에, 결국 예측할 수 없고 신뢰할 수 없는 소프트웨어를 만듭니다.
2. 최고의 레이아웃 계획
l 좋은 프로그래머
- 무의미한 논쟁을 피하고, 다른 사람들의 의견에 예민하게 신경을 씁니다.
- 겸손해서 자기가 항상 옳지 않다는 것을 압니다.
- 코드 레이아웃이 가독성에 얼마나 영향을 미치는지 알고, 가능한 한 명료한 코드를 작성하기 위해 노력합니다.
- 자기의 개인적인 기호와 다르더라도 하우스 스타일을 채택할 것입니다.
l 나쁜 프로그래머
- 마음이 닫혀 있고 고집이 셉니다.
- 아주 사소한 일을 가지고도 아무하고나 싸움을 합니다.
- 개인적인 코딩 스타일에 일관성이 없습니다.
- 다른 사람의 코드를 자기 스타일을 가지고 짓뭉갭니다.
3. 이름이 뭐길래
l 좋은 프로그래머
- 이름이 중요하다는 것을 알고, 이름을 소중히 다룹니다.
- 이름을 어떻게 만들지에 대해서 생각하고, 자기가 생성하는 모든 것에 적절한 이름을 붙입니다.
- 이름의 길이, 명료성, 콘텍스트 등과 같은 힘들의 균형을 맞춥니다.
- 더 큰 그림을 바라보고, 한 프로젝트 전체에 걸쳐서 자기가 만든 이름들이 조화를 이루게 만듭니다.
l 나쁜 프로그래머
- 자기 코드의 명료성에 대해 거의 신경 쓰지 않습니다.
- 일회서 코드를 생성합니다.
- 언어 고유의 관용구를 무시합니다.
- 이름을 짓는데 있어서 일관성이 없습니다.
- 전체론적으로 생각하지 않습니다. 자기가 만든 코드가 전체와 어떻게 맞물리는지 생각하지 않습니다.
4. 문서화 도구
l 좋은 프로그래머
- 스스로 문서화하는 명료한 코드를 작성하기 위해 노력합니다.
- 꼭 필요한 최소 분량의 문서를 작성하기 위해 노력합니다.
- 자기 코드를 유지보수할 프로그래머가 무엇을 필요로 할지 생각합니다.
l 나쁜 프로그래머
- 이해가 불가능한 스파케티 코드의 작성을 자랑스러워합니다.
- 어떤 문서 작성도 안 하려 듭니다.
- 문서의 업데이트에 신경을 쓰지 않습니다.
- 이런 생각을 합니다. “내가 작성하기 힘든 코드는 다른 사람도 이해하기 힘들어야 돼”
5. 가벼운 코멘트
l 좋은 프로그래머
- 정말 훌륭한 소량의 코멘트를 작성하려고 노력합니다.
- 왜에 대해서 설명하는 코멘트를 작성합니다.
- 과도한 코멘트가 아니라 좋은 코드의 작성에 집중합니다.
- 의미 있는 유용한 코멘트를 작성합니다.
l 나쁜 프로그래머
- 좋은 코멘트와 나쁜 코멘트의 차이를 모릅니다.
- 어떻게에 대해서 설명하는 코멘트를 작성합니다.
- 코멘트가 자기에게만 의미가 통해도 개의치 않습니다.
- 잘못된 코드를 많은 양의 코멘트로 보강합니다.
- 쓸데없이 중복되는 정보로 소스 코드를 채웁니다.
6. 사람은 실수를 하기 마련
l 좋은 프로그래머
- 자신의 좋은 의도를 좋은 코딩 습관과 결합시킵니다.
- 에러 처리 코드도 주된 코드를 작성할 때처럼 작성합니다.
- 코드를 철저히 작성해서 모든 에러 가능성을 커버합니다.
l 나쁜 프로그래머
- 자기가 하는 일에 대해 생각이나 검토를 하지 않고, 되는대로 식의 접근 방법으로 코드를 작성합니다.
- 코드를 작성하는 도중에 발생하는 에러를 무시합니다.
- 처음부터 에러 상황을 고려하는 일이 절대 없기 때문에, 나중에 고장 난 부분을 찾아서 오랜 디버깅 작업을 하게 됩니다.
7. 프로그래머의 도구 상자
l 좋은 프로그래머
- 지루한 일을 하고, 하고, 또 하는 식으로 반복하기 보다는, 적절한 툴의 사용 방법을 배우는 편을 택하려고 합니다.
- 여러 가지 툴체인(Toolchain)의 모델을 알아두고, 각각을 힘들지 않게 사용할수 있습니다.
- 자기의 생활을 더 편하게 만들기 위해서 툴을 사용합니다. 하지만 툴의 노예가 되지는 않습니다.
- 자기가 사용하는 모든 것을 툴로 봅니다.
- 생산성이 높습니다. 왜냐하면 툴이 제2의 천성이 되었기 때문입니다.
l 나쁜 프로그래머
- 몇 가지 툴의 사용 방법을 알고 있지만, 모든 문제를 그 툴의 관점에서만 바라보려고 합니다.
- 새로운 툴을 배우기 위해 시간을 보내는 것을 꺼려합니다.
- 어떤 개발 환경을 사용하기 시작하면, 그것을 종교처럼 받들고, 절대 다른 것의 사용을 시도하거나 검토조차 하지 않으려 듭니다.
- 가치 있는 새로운 툴을 마주쳐도 자신의 툴박스에 추가하지 않습니다.
8. 시험 보는 시간
l 좋은 프로그래머
- 자기가 작성한 모든 코드에 대해 테스트 코드를 작성합니다.(일반 코드를 작성하기 전에 작성할 수 도 있습니다.)
- 마이크로 레벨에서 테스트를 하기 때문에 매크로 레벨에서 테스트를 할 때 바보 같은 코딩 실수로 인해 방해 받는 일이 없습니다.
- 전체 테스트에서 자기가 맡은 역할을 하면서, 제품의 품질에 대해 신경을 쓰고, 그에 대한 책임을 집니다.
l 나쁜 프로그래머
- 테스트가 소프트웨어 개발의 중요한 필수 요소라고 생각하지 않습니다.
- 테스트하지 않은 코드를 QA 부서에 제출하고, 테스트가 결함을 드러내면 놀라는 모습을 보입니다.
- 문제를 너무 늦게 발견해서 자기 인생을 복잡하게 만듭니다.
9. 결함 찾기
l 좋은 프로그래머
- 버그르르 배양하지 않습니다. 코드를 조심스럽게 작성해서 애초에 버그를 끌어들이는 일을 방지합니다.
- 자신의 코드가 무엇을 하는지 알고 있고, 쉽게 고장 나지 않도록 보장하기 위해 테스트 코드를 신중하게 작성합니다.
- 전투 계획도 없이 무모하게 돌진해서 버그 사냥을 하기보다는 방법론적이고 신중하게 합니다.
- 자신의 한계에 대해 알고 있고, 앞뒤가 모두 막혔을 때는 다른 사람에게 결함 찾는 일을 도와달라고 요청합니다.
- 코드의 변경을 조심스럽게 합니다.
l 나쁜 프로그래머
- 디버깅을 하지 않습니다. 여기저기 마구 두드리면서 잘못된 코드의 바다 속으로 침몰합니다.
- 대부분의 생활을 디버거 안에서 보내고, 그 안에서 자신의 코드가 무엇을 하고 있는지 풀어내려고 합니다.
- 고장에 직면하면 감추려 듭니다.
- 자신의 코드 품질과 결함을 고치는 능력에 대해 비현실적으로 큰 기대감을 가지고 있습니다.
- 진짜 원인을 찾아내기 위해 뒤로 돌아가서 문제점을 추적하기보다는, 증상을 감추는 것으로 버그를 고칩니다.
10. 코드 빌드
l 좋은 프로그래머
- 자신이 사용하는 빌드 시스템의 작동 방법, 사용 방법, 확장 방법을 알고 있습니다.
- 단순하고 한 단위로 빌드 시스템을 잘 만들어서, 소스 코드와 나란히 관리합니다.
- 될 수 있는 한 많은 빌드 작업을 자동화 합니다.
- 오버나이트 빌드를 이용해서 통합의 문제점을 잡아냅니다.
l 나쁜 프로그래머
- 빌드 시스템의 작동 방법을 무시하다가 바보 같은 빌드 문제에 발목이 잡힙니다.
- 자신의 빌드 시스템이 얼마나 불안전하고 신뢰할 수 없는 것인지에 대해 걱정을 하지 않습니다.
- 자신의 묘하고 복잡한 빌드 절차를 신참이 거의 적대적인 방법으로 스스로 터득하기를 기대합니다.
- 정의된 릴리즈 절차를 따르지 않고, 한꺼번에 던지는 식으로 릴리즈 빌드를 만듭니다.
11. 속도의 필요성
l 좋은 프로그래머
- 최적화가 절대적으로 필요하다는 사실이 증명되지 않으면 최적화를 하지 않습니다.
- 사려 깊고 신중한 접근 방법으로 체계적인 최적화를 시도합니다.
- 코드 수준의 최적화에 호소하기 전에, 일찍 대안을 찾고 설계 개선에 대해 연구합니다.
- 코드의 품질을 파괴하지 않는 최적화를 선호합니다.
l 나쁜 프로그래머
- 코드의 부적절성을 증명하기도 전에 최적화부터 시작합니다.
- 측정이나 조사도 하지 않고 보틀텍이라고 생각하는 코드를 공격합니다.
- 더 큰 그림을 고려하는 일이 절대 없습니다. 자기가 하는 최적화가 다른 코드 영역이나 사용 패턴에 대해 어떤 의미를 갖는지 전체적으로 고려하지 않습니다.
- 코드의 품질보다 속도가 더 중요하다고 생각합니다.
12. 불안전 콤플렉스
l 좋은 프로그래머
- 자기가 일하는 각 프로젝트의 보안 요구사항에 대해 알고 있습니다.
- 본능적으로 일반적인 보안 취약점을 피하면서 코드를 작성합니다.
- 시스템 각각에 대해 보안을 설계합니다. 보안을 마지막에 끼워 넣지 않습니다.
- 보안을 테스트하는 전략을 가지고 있습니다.
l 나쁜 프로그래머
- 보안이 별로 중요하지 않다고 간단하게 결론을 내려버립니다.
- 자기가 보안 전문가라고 생각합니다.
- 취약점이 발견되었을 때, 더 나쁜 경우로는 자기 코드가 손상되었을 때, 자기 프로그램에 있는 보안 결합에 대해서만 생각합니다.
- 코드를 작성할 때만 보안에 초점을 맞추고, 설계나 아키텍처 수준에서는 보안을 무시합니다.
13. 웅대한 설계
l 좋은 프로그래머
- 자기가 건드린 모든 것이 좋은 상태로 남게 되기를 희망합니다.
- 프로그래밍을 창의적인 과정으로 생각하고, 자기가 하는 일에 예술적인 요소를 끼워 넣습니다.
- 코드 작업을 시작하기 전에 코드의 구조에 대해 생각합니다.
- 지저분한 코드를 보면 추가 작업을 하기 전에 깔끔하게 정리하고 리팩토링해야겠다는 생각을 합니다.
- 다른 소프트웨어의 설계에 대해 끊임없이 공부하고 성공과 실패에 대한 지식을 쌓아 올립니다.
l 나쁜 프로그래머
- 뜨개질하듯이 코드를 작성해서 점점 더 큰 딱딱한 공처럼 만듭니다. 자기가 만족할 때까지 그 일을 계속하고, 결과에 대해서 불평을 합니다.
- 나쁜 설계를 알아볼 줄 모르고, 밀집된 코드를 가지고 작업할 때도 아무 협오감도 느끼지 않습니다.
- 즐겁게 해킹하듯 코딩하고 나서 자기가 어질러놓은 것을 다른 사람들이 치우라고 남겨둔 채 도망갑니다.
- 코드의 내부 설계를 음미하거나 존중하지 않습니다.
14. 소프트웨어 아키텍처
l 좋은 프로그래머
- 자기의 소프트웨어 아키텍처에 대해 알고 있고, 그 안에서 새로운 코드를 작성합니다.
- 설계 시나리오 각각에 대해서 적절한 아키텍처를 적용할 수 있습니다.
- 아름답고 세련된 단순한 아키텍처를 만들어냅니다 – 소프트웨어 설계의 아름다움을 올바르게 인식하고 있습니다.
- 시스템 아키텍처를 캡처해서, 계속 업데이트되고 있는 활성화된 문서 안에 기록합니다.
- 시스템 구조에 관한 문제점을 시스템 아키텍트에게 전달해서 설계의 개선에 도움이 되도록 합니다.
l 나쁜 프로그래머
- 아키텍처의 전체 비전에 전혀 신경을 쓰지 않으면서 코드를 작성합니다 – 그 결과 코드는 다른 부분과 조화를 이루지 못하게 되고, 컴포넌트들은 서로 통합 되지 않습니다.
- 코딩을 시작하기 전에 높은 수준의 설계를 수행하지 않습니다. 아키텍처 상에서 선택할 수 있는 대안을 모두 무시합니다.
- 아키텍처 수준의 정보를 머리 속에만 둠으로써 아예 접근할 수 없게 만들거나, 위험할 정도로 업데이트가 되지 않는 규격서 안에 둡니다.
- 부적절한 아키텍처를 꾹 참고 계속 사용합니다. 하부에 깔려 있는 문제점을 고치는 것이 아니라 거기에 잘못 설계된 코드를 추가 합니다 – 일이 커지는 것을 귀찮아 합니다.
15. 소프트웨어의 진화 또는 혁명
l 좋은 프로그래머
- 깨끗한 구조와 논리적인 레이아웃을 갖는 유지보수가 쉬운 소프트웨어를 작성한다.
- 나쁜 코드를 알아차리고, 그런 코드를 다룰 각오가 되어 있다.
- 코드의 변경을 시작하기 전에 코드와 원작성자의 모리 속 모델에 대해서 가능한 한 많은 것을 알려고 합니다.
- 자기가 작업하고 있는 코드의 품질을 돌본다.
l 나쁜 프로그래머
- 유지보수 프로그래머가 필요로 하는 것을 생각하지도 않고 복잡한 코드를 생성한다.
- 예전 코드를 관리하지 않으려 하고, 문제를 고치기보다 무시하는 것을 더 좋아한다.
- 좋은 솔루션을 생각하는 것보다 손쉬운 땜질을 더 좋아한다.
- 재빠르고 지저분한 해킹으로 코드의 주변을 어지럽힌다. 할 수 있는 모든 꼼수를 다 사용한다.
- 엉뚱한 곳에 주의를 집중하고, 실제로 고칠 필요가 없는 부분을 땜질한다.
16. 코드 멍키
l 좋은 프로그래머
- 정치적이고, 대인관계가 좋고, 예술적이고, 기술적으로 뛰어납니다.
- 팀 플레이어이고, 정직/겸손하고, 끊임없이 발전하고, 주의 깊고, 열심히 합니다.
l 나쁜 프로그래머
- 좋은 코드의 작성에 관심이 없습니다.
- 팀에 속해서 일을 잘하지 못합니다.
- 실제의 자신보다 더 능력 있는 사람처럼 보이려고 애를 씁니다.
- 활기가 없습니다. 자신을 발전시키려고 하지 않습니다.
17. 여기 우리 함께 서 있네
l 좋은 프로그래머
- 자기가 작성한 코드에 대해 영역권을 주장하지 않습니다.
- 소프트웨어 시스템을 더 좋게 만들 수 있다면, 어떤 종류의 개발 업무든 수행할 것입니다.
- 팀에 기여하면서 배우고 성장합니다. 팀을 희생시키지 않으면서 성취할 수 있는 개인적인 목표를 세웁니다.
- 의사소통을 잘 할 수 있습니다. 항상 다른 팀원들의 말에 귀를 기울입니다.
- 겸손하고, 팀에 도움이 되고, 다른 팀원들을 존중하고 가치 있게 평가합니다.
l 나쁜 프로그래머
- 자기만의 코드 제국을 건설하고, 자신을 아주 중요한 사람으로 만들려고 노력합니다.
- 자기만의 일을 하고 싶어하고, 가장 매력적인 일을 찾아 다닙니다.
- 팀의 효율성을 희생시켜가면서 가지가 하고 싶은 일을 수행합니다.
- 항상 자기의 개인적인 의견을 주장하고 싶어합니다.
- 팀이 자기에게 봉사하기 위해 존재한다고 생각하고, 자기가 팀의 최고 팀원이라고 생각합니다.
18. 안전한 소스 습관
l 좋은 프로그래머
- 자기가 한 일에 대해 책임을 지고, 코드 개발을 안전하게 보호하는 방법을 알고 있습니다.
- 소스 컨트롤을 신중하게 사용하고, 항상 레포지터리를 일관성 있고 사용 가능한 상태로 만들어 둡니다.
- 망가진 코드를 절대 소스 컨트롤에 체크인하지 않습니다.
- 유지보수하기 쉽고 사용하기 쉬운 코드를 만들겠다는 의도를 가지고 모든 툴을 신중하게 사용합니다.
l 나쁜 프로그래머
- 재앙이 일어나기 전까지는 코드의 안전성과 접근 가능성에 대해 신경을 쓰지 않습니다.
- 코드의 백업과 안전에 대해서 다른 사람이 생각할 것이라고 추측합니다.
- 문서의 업데이트에 신경을 쓰지 않습니다.
- 레포지터리에 있는 자기 코드의 상태에 대해 신경을 쓰지 않습니다 – 망가진 코드를 체크인하고, 자기가 어질러놓은 난장판을 다른 사람이 치우라고 그대로 둡니다.
19. 규격화 하기
l 좋은 프로그래머
- 규격서의 중요성을 알고 있고, 규격서를 이용해서 자기의 개발 생활을 편하게 만듭니다.
- 문서의 적절한 수준을 알고 있습니다.
- 자신의 문서 작성 스킬을 향상시키고 싶어 하고, 리뷰와 연습할 기회를 쫓아다닙니다.
l 나쁜 프로그래머
- 설계, 문서, 리뷰에 대한 생각을 하지 않고 코딩으로 곧장 다이빙합니다.
- 자기가 쓰는 텍스트에 대해서 생각을 하지 않습니다. 구조도 없고, 따라가기도 힘든 규격서를 만들어냅니다.
- 문서 작성을 피하려고 하고, 따분하고 무의미한 일이라고 생각합니다.
20. 사냥감 확인하기
l 좋은 프로그래머
- 코드 리뷰를 받고 싶어 하고, 자기의 코드 품질에 자신이 있습니다.
- 다른 사람의 의견을 받아들이고, 그 의견으로부터 배웁니다.
- 다른 사람의 코드에 대해 상대방 기분을 생각하면서 정확한 의견을 제시할 줄 압니다.
l 나쁜 프로그래머
- 코드 리뷰를 두려워하고, 다른 사람의 의견을 무서워합니다.
- 비평을 나쁘게 받아들입니다. 방어적이고 쉽게 화를 냅니다.
- 리뷰를 통해서 자기보다 못한 코더들보다 자기가 잘났다는 것을 보여주려고 합니다. 심할 정도로 가혹하고 비건설적인 논평을 합니다.
21. 얼마나 걸릴까?
l 좋은 프로그래머
- 개발 프로세스의 모든 부분에 대해 잘 생각하고, 건실한 컴포넌트 분할에 기초해서 훌륭한 소요시간 추정치를 만들어냅니다.
- 예상 소요 시간 안에 완전히 문서화되고 테스트된 코드를 만들어내고, 올바르게 통합시키려고 노력합니다.
- 소요 시간의 문제점을 일찍 부각시켜서 처리될 수 있게 합니다.
l 나쁜 프로그래머
- 오로지 육감과 직관에 기초한 자기가 희망하는 추정치를 만들어냅니다.
- 추정된 소요 시간 안에 약간의 코드를 해킹하듯이 만들어내기는 하지만, 높은 품질의 제품과 버그 없는 코드를 만들어내지는 못합니다.
- 소요 시간의 문제점을 받아들이는 것을 약함의 표시라고 생각하고, 바보 같이 그것을 따라잡으려고 애씁니다.
22. 프로그램의 요리법
if(ptnum > 0)
{
cvCalcOpticalFlowPyrLK(prev_gray, gray, prev_pyramid, pyramid,
m2DOld, m2DNew, ptnum, cvSize(win_size, win_size),
3, status, 0,
cvTermCriteria(CV_TERMCRIT_ITER|CV_TERMCRIT_EPS, 20, 0.03), flags);
flags |= CV_LKFLOW_PYR_A_READY;
int k = 0;
for(int i = 0; i < ptnum; ++i)
{
if( !status[i] )
continue;
m2DNew[k++] = m2DNew[i];
}
ptnum = k;
}
if(add_point)
{
m2DNew[ptnum].x = (float)pt.x;
m2DNew[ptnum].y = (float)pt.y;
add_point = false;
cvFindCornerSubPix( gray, m2DNew, ptnum,
cvSize(win_size,win_size), cvSize(-1,-1),
cvTermCriteria(CV_TERMCRIT_ITER|CV_TERMCRIT_EPS,20,0.03));
++ptnum;
}
tracking을 먼저 한 다음에 점을 추가해야
tracking이 제대로 된다
if(add_point) 를 한 다음에
if(ptnum > 0)
를 실행하면 new2D 에 0.413 등의 소수점으로 바뀌어서
계속 tracking이 되지 않는다
주의하자
glClear(GL_COLOR_BUFFER_BIT);
이렇게 하면 바탕 색이 적용된다.
glClear(GL_COLOR_BUFFER_BIT);
glClearColor(0.0f, 0.0f, 1.0f, 1.0f);
이렇게 하면 바탕색이 적용되지 않는다.
생각하건데 OpenCV 모든 함수에서도 그렇겠지만
함수의 인자에서 포인터를 넣으면 안 된다
예를 들어서
class CDataSet
{
protected:
CvPoint2D32f * m2DNew;
CvPoint2D32f * m2DOld;
public:
CvPoint2D32f * GetNew() { return m2DNew; }
CvPoint2D32f * GetOld() { return m2DOld; }
};
이라고 했을 때
cvCalcOpticalFlowPyrLK(prev_gray, gray, prev_pyramid, pyramid,
OldPt, NewPt, *n,
cvSize(win_size, win_size), 3, status, 0,
cvTermCriteria(CV_TERMCRIT_ITER|CV_TERMCRIT_EPS, 20, 0.03), flags);
이렇게 했을 때
Point Tracking 이 되지 않는다.
이거 때문에 이틀을 날리고 그 다음에
두번째 실수이다 잊어버리지 말자
그래서 같은 클래스에 넣었었던 것으로 기억된다.