첫번째 글이 당연한 내용을 너무 길게 설명했다는 의견이 있어서, 이번 글부터는 더 짧고 간결하게 정리해 보려고 노력하고 있습니다. 그리고, 이 글의 대상은 한 번이라도
GTK+, Clutter 등과 같은 라이브러리는 C 언어로 구현되었지만 객체 지향 개념을 충실히 따르고 있는데, 그 중심에는 GLib 라이브러리의 GObject가 있습니다. 따라서 이러한
소스 코드 문서화에 Doxygen 을 이용하고 매뉴얼이나 공식 문서 작성에는 DocBook 을 사용하신다면 혹시 둘을 합칠 수 있는 방법이 있으면 좋겠다는 생각을 해보지 않으셨나요? 긴 말 필요
저는 개발자(developer)보다 프로그래머(programmer)라고 부르는 걸 더 좋아합니다. 왜냐하면 프로그래머라는 단어는 프로그램(pro
리눅스에서 메모리 침범이나 메모리 누수, 혹은 복잡한 메모리 접근 관련 오류를 디버깅할때는 대부분 Valgrind 도구를 이용합니다. 하지만 Valgrind는 많은 메모리를
장기간 실행되면서 빈번하게 메모리를 할당 / 해제하는 것은 물론 수십 개의 쓰레드가 동작하는 프로그램에서는 어쩔 수 없이 메모리 단편화(Memory Fragme
리눅스에서 개발할때 ‘man’ 명령을 이용해 매뉴얼 페이지를 많이 참고하는데, 자주 시스템을 다시 설치하다 보니 설치되지 않은 매뉴얼 때문에 매번 구글을 찾는라 귀찮은 적이
윈도우 비주얼 스튜디오 환경에서 디버깅을 하다보면 시스템에서 기본으로 제공하는 DLL 라이브러리에 대한 디버깅 심볼 정보가 없어 불편한 경우가 많습니다. 이 문제를 해
프리젠터 먼저하기(Presenter First) 는 모델-뷰-프리젠터(MVP) 디자인 패턴과 테스트 주도 개발(TDD) 등의 아이디어를 버무린 소프트웨어 개발 방
소프트웨어를 개발하면서 멀티 쓰레드 방식을 사용하는 경우는 많습니다. 하지만 그만큼 복잡도가 증가해서 세심하게 고려하여 설계하지 않으면 디버깅 재앙을 얻는 경우