지금까지 화면 캡쳐시에는 오직 오픈 캡쳐라는 프로그램만을 사용하고 다른 프로그램에 눈길 한 번 준 적이 없었는데 오늘 실행을 시키니 자동 업데이트가 되면서 위와 같은 약관 동의 창이 나왔다. 아무래도 회사에서는 돈 내고 쓰라는 말 같다. 하이고, 그럼 이제 못 쓰잖아.
원래 오픈 캡쳐는 개발자 한 명이 혼자서 만들어 개발자의 개인 홈페이지에서 운영을 했었다. 나중에는 같이 개발하는 사람들 몇 명이 생겼고 그 때부터 자동 업데이트나 광고, 트위터로 보내기 같은 원하지 않는 기능들이 생겨나기도 했다.
이번에 오픈 캡쳐의 새로운 주인이 된 회사와 개발자간에 어떤 거래가 있었던 건지는 모르겠지만 나는 사용자 입장으로서 좋아하던 프로그램을 하나 잃어버리게 되었다. 오픈 캡쳐의 윈도우 자동 스크롤 캡쳐는 정말 좋아했던 기능인데 이제 뭘 써야하나.
오픈 캡쳐는 언젠가부터 소스 코드를 공개 했었는데 이제부터 그 라이센스는 어떻게 되는건지 모르겠다. 오픈 소스 버전을 사용하면 회사에서 계속 사용해도 되는 걸까.
2010년에 이 책을 사두고는 책장에만 썩혀두었는데 얼마전에 김난도 교수의 '아프니까 청춘이다'를 읽고 그 글 솜씨에 큰 자극을 받아 다시금 꺼내게 되었다.
아프니까 청춘이다를 포함해서 많은 책들이 이 책을 통해 글쓰기 훈련을 하는 것을 추천 하였는데 실제로 도움이 많이 되었다.
이 책은 제목 그대로 글쓰기의 정석만을 가르친다. 수식어를 이용해 문장을 화려해 보이도록 만든다거나 강조해서 쓰는 법은 이 책에서는 좋지 못한 행동으로 취급받는다.
글에 리듬감을 불어넣는 방법이라든지 간결한 문장을 쓰는 요령 등 평소에 궁금해 해왔던 내용들을 배울 수 있었다.
8장 까지의 내용은 모든 단원마다 유익했지만 블로그 글이나 이메일을 쓰는 요령을 다루는 9장 이후의 내용은 인상적이지 못했다.
코드잡이라는 사이트가 생겼다.
스택오버플로우의 시스템을 거의 본따서 만들었는데, 아직 디테일한 부분에서는 부족해보이지만 많은 사람들이 사용을 해서 멋진 개발자들의 놀이터가 될 수 있었으면 좋겠다.
스택오버플로우와 완전히 똑같지는 않고 페이스북 같은 소셜 기능도 넣었는데, 이는 참신해 보이기도 하지만 커뮤니티의 전체적인 분위기가 약간 가볍게 흘러가지는 않을까 걱정이 되기도 한다. 하지만 어떻게 될지는 지켜봐야 알 일이다.
부디 양질의 질문/답변들이 많이 쌓여서 많은 개발자들에게 도움이 되는 사이트가 되었으면 한다.
파일을 열 때 파일 포인터는 0으로 셋팅된다. 이후 해당 파일에 ReadFile이나 WriteFile등의 함수를 통해서 I/O를 하게 되면 파일 포인터가 자동으로 증가하게 된다. 물론 윈도우는 사용자가 직접 오프셋을 조정할 수 있는 인터페이스도 제공해주는데 SetFilePointer 함수가 바로 파일 포인터를 이동 시키는 인터페이스이다.
파일 포인터는 각 핸들별로 따로 관리된다. 즉 같은 파일이라 할지라도 2번을 열어서 핸들을 2개 가지고 있다면 각 핸들에 연결된 파일 포인터는 각각 독립적으로 움직인다.
이 SetFilePointer는 너무 복잡하게 만들어진 함수이다. 그래서 제대로 사용하기가 어렵다. 지금까지 내가 SetFilePointer 함수를 사용하는 코드를 보았던 곳에서는 제대로 작성된 코드가 거의 없었던 것 같다. 그렇다면 어떤 부분이 그렇게 SetFilePointer의 사용을 힘들게 만드는 것일까?
SetFilePointer 함수는 다음과 같이 생겼다. 32비트와 64비트를 동시에 지원하기 위해 2번째 인수와 3번째 인수를 통해 각 4바이트씩 총 64비트 만큼의 오프셋 정보를 전달할 수 있도록 만들어졌다.
DWORD WINAPI SetFilePointer(
__in HANDLE hFile,
__in LONG lDistanceToMove,
__inout_opt PLONG lpDistanceToMoveHigh,
__in DWORD dwMoveMethod
);
첫번째로 많이 하는 실수는 오프셋이 32비트 크기를 넘어갈 수 있는 경우에도 항상 lpDistanceToMoveHigh 에 NULL을 넣고 있는 경우이다. 4기가보다 큰 파일에 대해서 제대로 지원하지 못하는 경우인데 오래 전에 작성된 코드에서 흔히 볼 수 있다.
두번째. SetFilePointer의 리턴값은 변경된 오프셋 값이며 함수가 실패할 경우에는 INVALID_SET_FILE_POINTER 를 돌려주게 된다. INVALID_SET_FILE_POINTER의 값은 -1로 정의되어 있고, 이 값은 DWORD로 받아지기 때문에 0xFFFFFFFF가 된다. 그런데 만약 내가 변경하고 싶었던 위치가 0xFFFFFFFF(4기가) 였다면? 사용자는 0xFFFFFFFF위치로 오프셋을 옮겨줄 것을 요청했고 함수는 사용자가 원한 동작을 제대로 수행한 뒤 0xFFFFFFFF를 리턴했다. 이제 이 값이 에러인지 정상적인 오프셋 값인지 어떻게 구분해야할까? 사용자는 이를 확인해보기 위해서 반드시 GetLastError를 호출해야 한다. 만일 함수가 성공했고 제대로된 오프셋이라면 LastError가 ERROR_SUCCESS로 셋팅되어 있을 것이다. 지난 번에 윈도의 LastError값은 오직 함수가 실패할 때만 셋팅된다고 했었는데, SetFilePointer와 같은 몇몇 특별한 함수에서는 성공시에도 값을 0으로 만들어 준다. 물론 그렇게 하는 이유는 위처럼 리턴값만으로는 모든 정보를 전달해줄 수가 없기 때문이다.
따라서 SetFilePointer를 사용하는 곳에서는 다음 표에 있는 것처럼 리턴값을 확인해야 한다.
맥북 에어가 한 대 생겨서 좀 써보려고 하는데 도대체 뭘 어떻게 쓰는건지 알 수가 있어야지. 그래서 책을 보고 공부하기로 했다. 나는 아직까지 인터넷보다는 책으로 공부하는 것을 선호한다. 맥 라이언 책들이 수두룩하게 있었는데 이 책이 가장 좋아보이고 역자 이름이 눈에 익어서 이걸로 선택을 했다.
응용 프로그램들에 대한 설명은 대충대충 보고 넘어가고, 맥 OS X 전체적인 공통 인터페이스나 파인더 셋팅, 미션컨트롤과 같은 부분들은 하나씩 따라하면서 꼼꼼히 읽어보았다.
그림들이 컬러로 되어있고 폰트들이 아주 맘에 들어서 좋았다.
한 달여 동안 집에서 쿠분투를 꺼놓고 맥북만을 사용했는데 덕분에 이제는 꽤 익숙한 사용자가 되었다.
나는 애플 Hater라고 말할 수 있다. 지금까지 애플 제품을 한번도 사서 써본 적이 없었는데, 다른 이유는 없고 그냥 그네들이 돈을 너무 비싸게 받아먹기 때문이었다. 주위에서 애플 제품이 끝내주게 좋다고 말하는 사람들이 너무나도 많아져서 얼마나 좋은지 나도 한번 써보고 싶었다. 한번 써보면 윈도우로 다시 돌아가지 못한다나 어쩐다나. 멀티 터치 같은 트랙패드 기능들은 정말 훌륭해서 매번 감탄하고 있다. 세 손가락 드래깅으로 창을 이동시키는 것이 너무 익숙해져서 다른 노트북을 만질 때마다 몹시 불편함을 느낀다. 하지만 사람들이 말한 정도로 맥 OS X가 끝내준다고 생각되지는 않는다. 처음 보는 사람들도 한눈에 직관적으로 사용법을 알 수 있다고 하는데, 아니, 옵션키를 눌러야 메뉴에 새로운 아이템이 추가되는 것을 누가 설명서도 안 읽어보고 알아챌 수 있겠는가.
무엇보다 쓸만한 응용들이 윈도우즈에 비해 턱 없이 부족하다. 그래도 우분투보다는 낫지만.
한 때 이 글을 읽고 레지스트리를 다루는 책을 도서관에서 몽땅 빌려서 읽었던 적이 있다. 어느 정도 숙달이 되어 레지스트리 에디터를 열면 빛의 속도로 트리를 탐색해 나갈 수 있었는데, 작년에 회사를 그만두고 2달여를 집에서 쉬다가 다시 새로운 회사에 들어갔을 때 나의 이 능력이 마법처럼 사라져 버렸다는 것을 깨닫게 되었다. 아쉬운 일이다.
GetLastError는 윈도 Api를 호출 한 뒤 해당 함수의 Win32 에러 코드를 받아오기 위한 함수이다. 이 오류 정보는 쓰레드별로 하나만 저장되기 때문에 함수가 실패한 후 다른 함수를 실행하기 전에 에러 값을 읽어와야 한다. 다른 함수들이 호출된 이후에는 에러 값이 덮어 씌워져 버릴 수 있다.
보통은 아래와 같이 사용한다.
HANDLE h = CreateFile(...);
if (h == INVALID_HANDLE_VALUE)
{
DWORD dw = GetLastError();
... Do something
}
경험이 많지 않거나 주의 깊지 않은 프로그래머들은 프로그램을 유지보수 하면서 이미 잘 만들어져있던 위와 같은 코드를 별 생각 없이 아래처럼 바꾸기도 한다.
HANDLE h = CreateFile(...);
if (h == INVALID_HANDLE_VALUE)
{
DoSomethingElse(); // 뭔가 예외를 처리하기 위해 추가적인 코드를 여기에 쑤셔넣는다. 아니, 왜 하필 여기에.
DWORD dw = GetLastError();
... Do something
}
처음에 말했듯이 DoSomethingElse()안에서 윈도 Api를 사용한다면 쓰레드 저장소에 있던 LastError 코드가 다른 값으로 바뀌어버릴 수 있다는 것을 예상할 수 있다. 항상 코드를 읽으면서 GetLastError를 호출하는 부분이 에러값을 확인하려고 했던 함수의 바로 아래에 붙어있지 않다면 섬뜩함을 느껴야 한다. 하지만 잘 모르고 있으면 보이지 않는 법.
HANDLE h = CreateXXX(...);
DWORD dw = GetLastError();
if (dw == ERROR_SUCCESS)
{
... 핸들을 가지고 다른 무엇인가를 한다.
}
else
{
... 함수의 실패처리를 한다.
}
이번에는 한 Api를 호출 한 뒤에 바로 GetLastError를 호출해서 에러값을 얻어왔다. 얼핏보면 맞는 것도 같지만 역시 틀린 코드이다. 함수의 성공 실패 여부는 함수의 스펙에 따라 리턴 값 등으로 확인해야지 GetLastError 값으로 확인해서는 안된다. 왜냐하면 Win32에서 제공되는 대부분의 Api들이 함수가 성공했을 때는 LastError 값을 건드리지 않기 때문이다. 위 코드에서는 함수가 성공할 때는 에러 값도 0(ERROR_SUCCESS)으로 셋팅시켜 줄 것이라 굳게 믿고 있다. 실상은 그렇지 않다. GetLastError는 오직 함수가 실패했을 때만(그 바로 직후에) 호출해야 한다.
대부분의 함수들은 그 성공 여부를 리턴값으로 가르쳐준다. 리턴 값으로 성공과 실패 여부를 호출자에게 전달해주기로 했다면 뭐하러 또 SetLastError(ERROR_SUCCESS) 와 같은 추가적인 코드를 호출하겠는가.
하지만 어떤 함수들은 성공시에도 SetLastError(ERROR_SUCCESS)를 정확히 호출해주기도 하는데, 이것에 대한 이야기는 다음 포스트에서 해보려고 한다.
Sparse파일을 만들게 되면, 파일 포인터를 충분히 크게 이동하고 SetEndOfFile을 호출해도 실제로 데이터를 기록하지 않으며(그러므로 SetEndOfFile이 금방 반환된다) 나중에 파일의 해당 부분을 읽을 때 파일 시스템이 해당 부분의 데이터는 0으로 돌려주게 된다. WriteFile 같은 함수를 통해 실제로 데이터를 쓰는 경우에만 디스크의 용량을 차지하게 되는 이점이 있는데, 버추얼 박스나 VMware에서 생성하는 커다란 동적 하드 디스크를 구현 할 때 이런 방법을 사용하면 된다. -처음에 가상 디스크의 용량을 크게 잡아둬도 실제 하드 디스크 용량을 차지하지 않다가, 사용하면 할수록 하드 디스크의 사용량이 늘어나는 것을 본 적이 있을 것이다.
윈도에 인스톨 될 수 있는 모든 파일 시스템이 Sparse 파일을 지원한다고 가정해서는 안된다. FAT이나 다른 벤더에서 만든 인스톨러블 파일 시스템은 Sparse 기능을 지원하지 않을 수도 있다. Sparse 기능이 지원되는지 알아보기 위해서는 GetVolumeInformation 함수를 사용한다.
FAT 파일 시스템도 Sparse파일을 지원하지 않는데, 그러므로 NTFS상의 Sparse 파일을 FAT 볼륨으로 복사하게 되면 FAT볼륨에서는 더 이상 공간이 절약되지 않는다. (실제로 0을 디스크에 써버릴 것이다.)
Sparse 파일에서 실제로 디스크에 저장된 용량을 알고 싶을 때는 GetCompressedFileSize 함수를 사용하면 된다.
위대한 해커이자 이제는 소설가(?)이기도한 윈도의 대가 마크 러시노비치의 처녀작이다.
책이 처음 나왔을 때부터 재미는 있으려나, 기술적으로 배울만한 것도 있을까 관심을 가지고 있었는데, 영어로 읽기는 싫으니 번역되는 날만을 기다렸다. 그런데 오늘 드디어 떴구나! 새해 선물인가.
그가 쓴 해커가 되는 방법이라는 글에서, 훌륭한 프로그래머가 되려면 얼마나 걸리냐는 질문에
얼마나 재능이 있고 열심히 공부하는지에 따라서 다르다. 만약 충분히 노력한다면 1년 반에서 2년 정도 사이에는 꽤 훌륭한 수준의 기술을 갖게 될 수 있다. 하지만 그게 끝이라고 생각해선 안된다. 훌륭한 프로그래머가 되기 위해서는 10년 정도가 걸린다.
만약 진정한 해커가 되고 싶다면 끊임없이 학습하고 기술을 다듬는데에 남은 인생 모두를 투자해야 한다.
당신이 제 학생이 아닌 것이 다행입니다. 그러한 설계로는 아마도 좋은 학점을 받지 못할 것입니다.
1991년 지금 시점에서, 386에서만 돌아가는 이식성 없는 새로운 OS를 설계하는 것은 당신에게 F를 안겨 줄 것입니다. 다만 기말 시험을 잘 본다면 이 과목은 통과할 수 있습니다.
잘은 모르겠지만 그래도 확신하건데, 아마도 이 논쟁은 타넨바움의 머리 속에서 가장 지워내고 싶은 기억 중 하나일 것이다.
MSDN에 따르면 구조체의 디폴트 패킹 값은 8이다. 간혹 32비트 운영체제에서는 4바이트이고 64비트 운영체제에서는 8바이트라고 주장하는 사람들도 있는데 디폴트 패킹 크기는 컴파일러가 결정하지 운영체제가 결정하는 것이 아니다. MSVC에서 디폴트 패킹을 8바이트로 정한 이유는(32비트 운영체제에서 조차) 기본 타입 중 가장 큰 타입이 8바이트이기 때문이다. 만약 이후에 16바이트 포인터나 INT128 같은 타입을 기본 타입으로써 사용하는 날이 온다면, 그 때는 디폴트 패킹 값도 16바이트로 변경될 것으로 예상한다.
답은 7bytes 와 24bytes이다. 틀린 사람들은 이 포스트를 계속 읽어볼 필요가 있다.
두 개를 다 맞췄고 Y 구조체에 어떻게 padding이 들어갈지 머리 속에 제대로 그려낸 사람들은 읽을 필요가 없다.
Y 구조체의 레이아웃은 다음처럼 된다.
struct Y
{
char c;
// pad[7]
double d;
int i;
// pad[4]
};
구조체의 멤버들은 자신의 크기의 배수로 정렬되는 것이 좋다. char는 1의 배수, short은 2의 배수, int는 4의 배수, double은 8의 배수의 메모리 번지 주소에 위치하고 있을 때 우리는 해당 데이터가 정렬되어 있다고 말한다.
x86호환 아키텍쳐에서 윈도우즈 응용 프로그램을 만들 경우에는 정렬이 되어있지 않을 때 CPU가 메모리에 다시 접근하려고
시도하면서 성능이 떨어지게 된다. 다른 아키텍쳐에서는 응용이 크래시가 나거나 따로 예외 핸들링을 해주어야 할 수도 있다.
컴파일러는 데이터를 정렬시키기 위해서 구조체의 적당한 위치에 패딩을 집어넣는다. 조금 생각해보면 위 Y구조체에 마지막 4바이트 패딩은 필요가 없을 것 같다. 중간에 넣은 7바이트 패딩으로 인해 3개의 필드가 모두 잘 정렬이 된 것 같은데 말이다.
뒷 부분에 4바이트 패딩을 넣은 이유는 구조체가 배열에서 사용될 때 구조체의 멤버들이 메모리의 정렬된 위치에 올라가도록 하고 싶기 때문이다. 뒷 부분에 패딩을 넣지 않았으면 int나 double 타입이 자신의 타입에 맞게 정렬된 주소에 올라가지 못했을 것이다.
다음 Z구조체를 보자. 위의 Y구조체에서 double과 int의 위치만 바꾸었다. -위치만 바꾸었는데 패딩이 Y구조체와 다르게 들어가는 것에 대해서도 유심히 살펴 보아야 한다.
struct Z
{
char c;
// pad[3]
int i;
double d;
};
int _tmain(int argc, _TCHAR* argv[])
{
// 다음 코드를 사용해서 어떻게 padding이 들어가 있는지 쉽게 확인해볼 수 있다.
printf("position c:%d\n", FIELD_OFFSET(Z, c));
printf("position i:%d\n", FIELD_OFFSET(Z, i));
printf("position d:%d\n", FIELD_OFFSET(Z, d));
printf("Total size:%d\n", sizeof(Z));
}
직접 코드를 실행시켜보는 것도 좋고, 아래 그림을 보고 이해해도 좋다. 이 구조체가 배열에서 사용될 때에는 아래와 같은 레이아웃을 갖게 될 것이다.
char는 1의 배수에, int는 4의 배수에, double은 8의 배수에 정렬되어져 올라가 있는 것을 주목하라. 진한 파란색으로 표시된 3바이트 패딩의 매직이다.
맨 처음 문제에서 X구조체의 크기가 8bytes가 아니라 7bytes인 이유는 모든 멤버가 char이기 때문이다. char는 1의 배수인 어느 주소에나 올라가도 되므로 padding을 집어 넣지 않아도 모든 멤버가 항상 자신이 원하는 주소에 올라가게 된다.
Y구조체가 Z구조체와 멤버 위치만 바꾸었는데 다른 레이아웃을 가지고 있는 이유도 그림을 그리면서 확인해보면 이해할 수 있을 것이다.
8로 패킹한다는 것은 구조체의 크기를 8의 배수로 맞추겠다는 것이 아니라, 크기가 8보다 큰 멤버가 있을 때는 정렬을 포기한다는 것을 뜻한다. 즉, 크기가 8보다 작은 타입에 대해서만 정렬하려고 시도하며, 이것은 다른 말로, 변수의 메모리 주소를 최대 8의 배수로 정렬한다는 뜻이 된다.
만약 패킹 크기를 4로 바꾼다면 double이나 int64_t 같은 타입들이 사용되었을 때 더 이상 정렬이 보장되지 않게 된다. 왜 디폴트 값을 8로 정했는지 이해가 되는가?
구조체를 만들 때는 어떻게 패킹이 될지 잘 예상해서 조각을 맞추듯이 만들어야지 아무 순서로나 마구 쑤셔넣는 것은 프로답지 못하다. 마이크로소프트에서 만든 거의 대부분의 구조체들은 이런 사소한 것들까지 잘 고려해서 만들어져 있다.
틀린 내용인거 같은데... double이 많을까요? Pointer가 많을까요?
포인터가 32비트에서 4바이트고 64비트 8바이트라서 패킹을 각각 하고 있습니다. 구조체 크기랑은 별개의 이야기지요.메모리크기는 당연히 데이터 사이즈대로 나오겠죠. 패킹과 메모리사이즈는 별개의 얘기죠.
단편화 생기는 과정을 만들어서 프로그램이 어떻게 죽는지 확인해보시기 바랍니다.
필자는 ms vs compiler만 확인해보신 것이 아닌지... 메모리 패킹은 운영체제가 변경됨에 따라도 얼마든지 바뀔수 있으니 무조간 8바이트라고 단정하는건 문제가 됩니다.
프로 당구 선수에게 가장 굴욕적이고 부끄러운 순간이 있다면 바로 키스를 내는 일일 것이다. -아마추어 세계에서는 삑사리를 내는 것일지도 모르지만. 축구 선수에게는 알까기를 당하는 것, 농구에서는 블록킹을 당하는 순간일지도 모르겠다.
만일 프로그래머에도 이런 순간을 하나 꼽으라면 나는 버그 관리 시스템에서 이슈를 해결 처리 했는데 재등록이 되거나 그로인해 다른 버그를 유발하는 것이라 생각한다. 버그가 재등록된다는 것은 제대로 테스트 해보지 않았다는 것이고 다른 버그를 유발 시켰다면, 앞뒤 로직을 충분히 검토하지 않고 버그가 발생한 바로 그 곳만 바라보고 버그를 수정했다는 뜻이다. 부끄러워하고 반성해야 한다.
뒤돌려치기(우라마시)를 치는데 그냥 운에 맡기고 친 후 쫑이 날 수도 있는게 당연하다고 생각한다면 절대 당구 실력이 늘지 않는다. 프로그래머에게도 마찬가지라고 생각한다.
갑자기 이런 이야기가 생각이 난 것은 레이몬드 첸의 한 포스트를 읽고 나서였는데, 옛날 처음에 회사에 들어갔을 때의 내 모습이 떠올랐기 때문이다. (그냥 글을 읽는 중에 그런 일들이 떠올랐던 것 뿐, 지금 말하는 이야기가 레이몬드 첸이 말한 요지과 관련이 있는 것은 아니다.)
나는 프로그램을 디버그 하다가 널 포인터 접근 등의 예외로 프로그램이 크래시 된 것을 확인하였으면 해당 부분을
if (ptr)
{
// *ptr을 사용
}
등으로 널 포인터 체크를 추가하여 수정하고는 이슈를 완료시키곤 했다. 하루에 버그를 10개 넘게 고친 날도 많았다.
꼭 널 포인터만의 이야기를 하는 것은 아니다. 버그가 발생한 앞뒤 로직을 충분히 점검하지 않고, 그 곳만 쳐다본채 코드를 수정하는 것에 대한 문제점을 이야기 하고 있는 것이다. 그 때 그 버그들이 정말 고쳐진 건지 아직도 모르겠다.
부작용도 많았지만, 또 어떻게 어떻게 메꾸어 내었고, 이슈 해결량이 많았기 때문에 나는 생산성이 좋다는 평가를 받았다. 지금 생각하면 부끄러운 일이다. 나는 그냥 버그를 숨겼을 뿐이다.
언제부턴가 그런 것이 잘못된 것이라는 것을 깨닫게 되었다. 아마도 나의 스승(?)이 일을 처리하던 모습을 유심히 관찰하면서였던 것 같다.
그 이후로는 버그가 발생했을 때 항상 전후 함수들을 모두 따라가보면서 로직들을 점검하고 어디가 문제인지, 널 포인터 체크를 추가해서 버그를 해결해도 되는건지, 또는 널 포인터가 들어오게 하는 것이 잘못인지 등을 꼼꼼히 따져보고 코드를 작성하는 습관을 들이게 되었다.
이런 습관을 들인 후에는 버그가 재등록이 되거나 다른 버그를 유발하는 일이 점점 줄어갔다. 예전처럼 하루에 버그를 10개 넘게 고치지는 못하지만 지금도 여전히 생산성이 좋다는 평가를 받는다. 다시 재등록 되는 버그에 대한 작업을 할 필요가 없기 때문이다. 코드를 추가할 때마다 다른 버그가 발생해서 고치고 또 고치고 하면서 시간을 보내는 경우를 본 적이 있는가? 주위를 유심히 잘 살펴본다면, 얼마나 그런 경우가 많은지에 대해서 놀라게 될 것이다. 어쩌면 여러분 자신일지도 모른다.
하루에 버그를 1개를 고치더라도, 코드를 10줄을 작성하고 퇴근하더라도 제대로 하는 것이 더 프로젝트를 빠르게 진행하는 길이라는 것을 이제는 확실히 알고 있다.
만일 여러분이 팀장이나 프로젝트 관리자라면, 10분만에 버그를 고치는 사람에게는 칭찬을 해줄 것이 아니라, 혹시 저런 문제가 있는 것은 아닌지 잘 관찰해봐야한다. 그리고 만일 어떤식으로든 가르침을 주어 변화시킬 수 있다면 여러분 또한 멋진 스승이고 멘토이다.
개발자들은 스타일에 관한 이야기를 하는 것을 좋아합니다. 이 문제는 마치 "무엇이 진정한 하나의 에디터일까"에 대한 이야기처럼 자주 입에 오르내립니다. 마치 이견이 있는 것처럼 말이죠. 답은 이맥스입니다. - Effective STL에서 컨테이너들의 범위 멤버 함수를 사용하는 것은 단일 요소 멤버 함수를 사용하는 것보다 모든 면에서 좋기 때문에 이견이 있을 수가 없다는 것을 설명하면서.
나는 비록 Vim을 더 좋아하지만 스캇 마이어스의 이 말을 듣고 이맥스를 배우고 싶다는 욕구가 미친듯이 몰려왔었던 때가 있었다. 비록 실패로 끝나고 말았지만.
앤드류 타넨바움이 그에게 유닉스를 다시 만들 수 있다면 무엇을 다르게 만들고 싶으냐고 질문하자
creat를 create로 바꾸고 싶다.
책을 보면서 너무 웃기긴 했는데 한참 웃다가 무슨 뜻일까 곰곰히 생각을 해봤다.
유닉스 설계는 지금 다시 봐도 세련되어서 딱히 바꾸고 싶은 것이 없다는 뜻일까, 아니면 10년이 넘는 시간이 지나도록 creat라는 작명이 다른 결정들을 다 제쳐두고 후회할만큼 계속 가슴을 후벼파서 한 말일까.
나는 TeX의 마지막 버그를 1985년 11월 27일 발견해서 제거했다고 믿는다. 그러나 아직도 코드 내에 약간의 버그라도 있다면 그것을 처음으로 발견해서 알려준 사람에게는 기꺼이 20.48 달러를 드리겠다. 이것은 이전 금액의 두 배이다. 나는 이 상금을 매년 두 배로 늘릴 계획이다. 나는 정말 자신이 있다.
몇 일전에 다음에서 주최하는 devon 행사가 신도림에서 있었다.
김택진과 이재웅과 허진호 세 사람이 나온다길래 재밌겠다 하고 얼마전부터 기대를 하고 있었다. 평일이라서 가지는 못했지만 오늘 동영상으로 볼 수 있었다.
나는 김택진이라는 사람이 개발자인지 지금까지 모르고 있었는데 오늘 이 사람 때문에 너무 많이 놀랐다. 아래아 한글하고 한메타자를 개발했었다면 분명히 한 번 들어봤을 것 같은데 왜 이제까지 그걸 몰랐는지 모르겠다.
어쨌거나 그 사람의 입에서 GitHub이나 stackoverflow.com 같은 단어가 나왔다는 것이 믿어지지 않을 정도로 충격적이었다. 그렇게 바쁜 사람이 아직도 혼자 아이폰에 코딩을 하고 stackoverflow.com에서 질문 답변을 읽어보고 GitHub에서 코드를 받아서 돌려본다고 한다. 지금 현역에 있는 개발자들에게 GitHub이나 stackoverflow.com이 뭔지 아냐고 물어봐도 모른다고 대답할 사람들이 태반은 될텐데 말이다. 진행을 하던 김국현씨가 말했던 것 처럼 나 또한 참 많은 자극이 되었고 신선한 충격을 받았다.
이번 devon 행사가 끝나고 중박 대박 이야기로 김택진씨가 사람들에게 나쁜 소리를 많이 들었는데 나는 잘 이해할 수 없었다. 꼭 돈을 벌어야 행복한건가, 어떤 아이디어를 구현하면서 자신의 코드가 잘 돌아가는 것을 보고 즐거움을 느끼면 그 또한 행복한 삶이고 성공한 것이다라는 류의 이야기를 했는데, 그가 말하는 동안 진정성이 느껴져서 내게는 너무 좋은 느낌으로 다가왔다. 만약 개발자들이 그 말을 듣고 정말로 배신감에 몸서리쳤다면 그 또한 개발자 정신을 잃은 사람은 아닐까 나는 생각한다.
다른 두 분의 이야기는 김택진씨보다는 그다지 인상깊지 못했지만 허진호씨가 말한 페이스북 CTO의 이야기는 정말 좋았다. 완전히 동감한다.
무슨 이야기인지 궁금하신 분들은 동영상을 직접 한번 보길 바란다.
나는 이 책의 0x 버전을 읽었는데, 얼마전에 정식판이라고 할 수 있는 C++11 버전이 발표되었다.
거의 모든 장이 아래 그림 처럼 코드 조각들로 이루어져 있고 스캇마이어스의 짧은 설명들로 보충된다.
예제 코드들이 궁금했던 점들을 너무도 잘 긁어주기 때문에 C++11의 새로운 기능들을 빠르게 익히는데 도움이 많이 되며 영어 때문에 부담스러워하지 않아도 된다.
오래전에 폴 그레이엄의 해커와 화가와 에릭 레이먼드의 해커가 되는 방법을 읽으면서, 언젠가는 나도 꼭 LISP를 공부해서 궁극의 위대한 해커가 되어야지 하고 불타올랐었을 때가 있었는데, 한해 한해를 흘려 보내다가 오늘까지 왔다. 그러고 보니 중간에 마법사 책으로 리스프를 공부한다고 까불다가 크게 좌절한 적이 한번있긴 했다.(책을 펼칠 때마다 마법처럼 떡실신해서 잠이 들었는데, 어느 날은 그렇게 잠이 들고 아침에 눈을 뜨자마자 누운채로 그 자리에서 다시 읽었는데 또 잠이 들고 말았다. 맙소사)
이번 11월달에 나오는 책 중 기다리고 기다리던 책이 하나 있었는데 바로 이 리스프! 마법사 책처럼 압박감이 들지도 않고 겉표지만 본다면 왠지 좀 만만해 보이기까지 한다.
소프트웨어 개발의 모든 것과 비슷한 종류의 책이며 아래 내용들을 다룬다.
재미있는 편이며, 대체로 그 내용에 동의한다. 책의 완성도는 소프트웨어 개발의 모든 것이 좀 더 낫다고 생각한다.
개발 표준
코딩 스타일
공통 라이브러리/프레임워크
문서화 표준
개발 기반
소스 코드 관리 시스템
이슈 트래커
개발/테스트/운영서버 분리
지속적 통합
개발 기법
단위 테스트
TDD
리팩터링
개발 방법
폭포수 vs. 애자일
조직론.
스크럼.
협업.
개발 관리.
위의 내용들은 소프트웨어 개발에 있어서 아주 중요한 내용들이지만 학생 때는 쉽게 접하지 못하는 내용들이다. 보통은 처음 회사에 들어가고 나서 저런 것들을 배우게 되는데, 아주 잘하는 회사도 있고 그저 그런 회사도 있기 때문에 회사를 잘 골라 들어가는 것이 중요하다.
취업이 안된다고 초조한 마음에 우선 1, 2년만 배우고 좋은 회사로 옮겨야지 하고는 저기 구로공단에 이름 없는 아무 회사나 들어가서는 안된다는 뜻이다. - 구로공단은 그냥 예로만 들었을 뿐 나쁜 의도는 없다.
그런 작은 회사들 중에는 소스코드 관리 툴도 사용하지 않는 곳이 잔뜩 하기 때문에 그런 곳에 들어가면 고생은 고생대로 하고 시간만 낭비하는 셈이다.
이 책에서 나오는 내용들을 가장 쉽고 빠르게 터득하고 싶은 방법은 이런 시스템이 잘 구축되어 있는 회사에 들아가는 것이다. 어떤 회사가 잘하는 회사인지 잘 모르겠다면 어느 정도 이름을 많이 들어봤고 개발자 수가 많은 회사를 찍는 것이 맞을 확률이 높다.
만일 그런 회사에 다니고 있지 않다면 회사를 옮기는 것도 좋다고 생각한다. 스스로 공부하면서 배울 수도 있겠지만 쉽지는 않을 것이다. 서버를 구성하는 것도 몹시 귀찮은 일인데다가, 혼자서 이슈 트래커에 이슈를 기록하고 완료하면 (왕따놀이를 하는 것도 아니고) 도대체 무슨 재미로 하나.
아래 위키 페이지에 있는 회사들은 적어도 소스코드 형상 관리툴 정도는 모두 사용할 것이라 생각한다. 대한민국의 IT기업
반면에 CI 서버를 구성해놓고, 코드 커버리지 측정이나 정적 분석 등을 자동으로 수행 하고 있는 회사는 여전히 별로 없는 것 같다. NHN에서는 위 목차의 내용을 모두 하고 있고 심지어는 코드의 라인 수 까지도 체크해서 라인이 얼마가 늘었고 라인당 버그수가 얼마인지 까지 보고 되는데 이건 얼핏 보면 한심하고 쓸데 없어 보이지만, 내 생각은 안하는 것보다는 훨씬 낫다이다.
잘 구축된 CI 서버는 마치 똑똑한 군사와도 같다. 전쟁의 상황에 대해서 지속적으로 보고 해주고 위험한 일이 발생하면 적절한 조언도 해주는 것이다.
어떤 사람들은 위에서 나오는 내용들을 꼭 대학교 커리큘럼에 넣어야 한다고 주장하는데, 거기에는 별로 동의하지 않는다. 이 많은 과정을 쑤셔넣으려면 그만큼을 빼내야 하는데 무슨 과목을 빼낼 셈인가.
컴퓨터 과학분야의 교수이며 카네기 멜론 대학에서 가상현실을 연구하던 랜디 포시 교수가 암에 걸려 시한부 인생을 살면서 쓴 책이다.
시한부 인생을 선고 받은 후 '마지막 강의'를 준비해서 카네기 멜론에서 발표를 했고 이는 유투브에도 올라가서 많은 조회수를 기록했다. 이 강의는 훗날 자신의 아이들에게 보여주기 위해서 만들었다고 한다.
책을 읽으면서 그가 아내와 아이들을 대하는 자세와 삶을 슬기롭게 살아가는 지혜들에 많은 감명을 받았다.
반성도 참 많이 했다. 누구는 내일 죽을 것 처럼 처절하게 살아가는데, 내가 너무 시간을 낭비하면서 사는 것은 아닌가. 늙어서 암에 걸리면 얼마나 후회를 하려나, 건강을 최우선으로 신경써야지.
프로그램을 처음 배울 때는 거의 정신병자 수준으로 코딩 스타일에 집착했었는데 나이가 들어가면서 코딩 스타일에 조금씩 둔감해져가고 있다.
대학 때는 들여쓰기를 tab으로 했었는데 첫번째 회사에서 space가 규칙이라고 꼭 그렇게 쓰라고 강제했다. 나는 tab을 버리기 싫었지만 규칙을 어기지 않기위해 그렇게 쓰다보니 space가 너무 좋아져버렸다. 2번째 회사에서는 다시 tab을 사용하라고 한다. 좀 촌스럽네? 아직도 tab을 쓰는데가 있었나 정도의 생각은 들지만 거부감 없이 받아들일 수 있었다. 그 외의 다른 스타일들도 비슷하다.
그래도 여전히 눈에 거슬리고 바꿔버리고 싶은 욕구가 드는 C/C++ 코딩 스타일이 2가지가 있는데 그 중 하나는
if (0 == str.Length())
{
}
위처럼 상수를 좌측에 쓰는 코드이다.
프로그램을 읽기에도 불편하고 쓸 때 또한 불편한데 도대체 왜 상수를 왼쪽에 쓰는가.
아마 어떤 사람들은 그렇게 써야 == 연산자 대신 = 를 사용해버리는 실수를 방지할 수 있어요, 라고 대답할지도 모른다. 하지만 요즘 컴파일러는 이런 실수를 경고로 가르쳐주는 기능을 다 가지고 있는데 굳이 저렇게 쓸 필요가 있는가? 컴파일러나 정적분석툴의 도움를 받을 수 없는 상황에서나 어쩔수 없이 사용하던 구식 방법인데 이를 무작정 따라하는 사람들이 많다. 다음 코드는 조금 더 보기에 안좋다.
if (MAX_PATH <= str.Length())
{
}
'상수를 왼쪽에 써야 실수를 줄일수 있다고 했지'. 라고 생각없이 이 말을 받아들인 사람들은 == 이 아니라 비교연산자를 사용할 때에도 모든 상수는 죄다 왼쪽에 써버린다. 위 코드를 읽을 때 머리가 2번씩 돌아가는 것 같지 않은가?
또 한가지 싫어하는 C/C++ 스타일은
bool xxx = fOk;
if (xxx == true)
{
}
이렇게 불린 테스트를 true나 false와 명시적으로 비교하는 것이다.
아래 strcmp 함수의 경우 처럼 표현식의 결과가 불린 값이 아닌 경우에는(strcmp의 리턴값은 정수이다) 같은 타입으로 명시적으로 비교를 해서 표현식을 참 혹은 거짓으로 맞추어 주는 것이 의미가 있다.
if (!strcmp(xxx, yyy)) // 이보다는
if (strcmp(xxx, yyy) == 0) // 이게 더 낫다고 생각한다.
하지만 이미 어떤 변수나 식이 이미 참과 거짓을 나타내고 있다면 또 다시 그것을 true나 false와 비교하는 것은 명백한 중복이다. 나는 그런 경우는 그냥
if (xxx)
{
}
또는
if (!xxx)
{
}
이렇게 쓰는 것을 선호한다.
위에서 처럼 true와 비교하는 것보다 1로 정의된 대문자 TRUE를 비교하는 것은 훨씬 나쁘다.
if (xxx == TRUE)
{
}
xxx 값이 0도 아니고 1도 아닌 값(하지만 참인)을 가진 경우에는 골탕을 먹게 되기 때문이다.
오늘 stackoverflow를 구경하다가 재밌는 사실 하나를 알게되었다.
많은 사람들이 나만큼이나 위 두가지 스타일을 싫어한다는 것이다. 어떤 코딩 스타일이 가장 거지같다고 생각하나요?
내가 위에서 말한 2가지 스타일이 1등과 3등을 차지 했다니 아마 저런 스타일을 사용하는 사람들은 잘 믿기지 않을 것이다.
재밌는 답변과 댓글들이 많으니 관심있는 사람들은 위 포스트를 한번 읽어보기 바란다.
나는 아래 댓글이 가장 재밌고 인상적이었다.
Damn. We say "if it's raining, open your umbrella" and NEVER "if it's
true that it's raining, take your umbrella"... Testing explicitely
against boolean is as verbose and as un-natural as the second example
안녕하세요.
저같은 경우도 0 == xxx 싫어합니다. 사람이 사람보기 편하게 코딩해야지 이건 뭥미.. 텍스트에디터로 코딩하는것도 아니고.. 상수도 마찬가지.
하지만 저는 명시적으로 true/false를 적어주는것을 선호합니다. 다양한 언어들을 접하고 사용하다보니 명시적으로 적지 않으면 제가 눈에 확 안들어오더라고요
if문의 경우 true를 쓰지 않는 부분에 대해선 공감합니다만
false의 경우엔 !를 사용하는경우 상황에 따라 눈에 잘 안들와
잘못 읽는 경우도 생기는 갓 같아 false인 경우에는 명시적으로 쓰고있네요.
if (!variable)
=>
if (variable == false)
if (variable == false)는 전혀 문제가 없고 보기에도 좋은 코드입니다.
if (!variable) 도 역시 보기에 좋습니다.
이런 경우에 저는 최대한 다른 사람들이 많이 사용하는 스타일을 사용하려고 합니다. 이렇게 하면 많은 경우에 유리합니다. (특히 스타일을 가지고 누군가 따질 때. C/C++하는 사람들이 흔하게 맞게 되는 일이죠)
C/C++ 세계에서는 if (boolean_variable == false)보다는 if (!boolean_variable) 이라고 생각이 되어요.
몇 일전 deview 2011 행사 중 한 세션에서 재미있는 이야기를 들었다.
NHN 김정민 이사의 세션이었는데, 이런 말을 했다.
애플, 마이크로소프트, HP 같은 회사에서 15년 동안 일했던 (지금은 NHN에서 일하고 있는) 송창현 이사가 예전에 우리회사에 면접을 보러 왔을 때 잘하는 게 뭐냐고 물어봤더니,
"저는 meticulous code reader입니다. 남의 코드를 아주 꼼꼼하게 읽어줄 수 있습니다."
대부분의 경력을 많이 가진 사람들은, 저는 유닉스를 10년을 넘게 다뤄서 커널 구석 구석까지 깊게 알고 있습니다. 오라클 전문가입니다 라고 말하지 저런 식으로 말하지는 않는데, 김정민 이사는 그게 상당히 인상적이고 멋있어 보였다고 한다.
나 또한 그 말이 멋있어 보인다는데에 완전히 동의한다.
저는 자바스크립트만큼은 누구보다 잘할 자신이 있습니다, 라는 말(또는 뻥)보다 훨씬 멋지지 않은가?
직장 생활을 하다보면 Meticulous code reader가 거의 없다는 것을 쉽게 알게 된다. - 나는 이전에 다니던 직장에서 여태껏 그런 사람을 딱 1명 만나봤다.
여러분이 후임이 있다고 치자. 어떤 기능을 구현해달라고 일을 주고 후임이 나중에 다 만들었습니다 했을 때, 또는 만들고 있는 도중에, 코드를 한줄 한줄 다 꼼꼼하게 읽어주고 피드백 해준 적이 있다면, 당신은 좋은 Meticulous code reader가 될 수 있는 가능성이 있다. 거의 대부분의 사람들은 그렇게 하지 않는다.
갑자기 이런 이야기를 하는 이유는, 최근에 Writing Solid Code라는 책을 읽으면서 이 책의 저자인 Steve Maguire가 그런 Meticulous code reader 라는 생각이 들었기 때문이다.
이런 사람들은 회사에 꼭 필요하다. 마이크로소프트가 10년 넘게 황제의 자리를 차지할 수 있었던 이유는 이런 사람들이 많이 있었기 때문일 것이다.
이 책에서는 정교하고 튼튼한 프로그램을 짜기 위한 많은 기술들을 배울 수 있으며, 또한 프로그래머가 프로그램을 만든다는 것 대해서 가져야할 바람직한 자세를 배울 수 있다.
매 챕터가 끝날 때에는 '생각할 점'이 나오는데, 여기에도 좋은 내용들이 참 많다. 부록에 답까지 있으니 모두 꼼꼼하게 읽어보도록 하자.
인터넷 어딘가에서 번역이 최악이라는 평가를 본 것 같은데, 이 책의 번역은 정말 잘 되었다고 생각한다. 부분 부분 약간 어색한 단어 선정이 보였던 것 같긴 하지만, 나는 왜 최악의 번역이라고 하는건지 이해할 수가 없다.
얼마전에 안랩이 판교에 사옥을 짓고 입주를 했는데, 이번 11월 9일 18시 30분에 오픈하우스 행사를 한다고 한다. 외부인들을 초청해서 사옥을 소개시켜주는 자리인데, 초대권을 받으려면 블로그나 트위터에 소개를 해야한다고 해서 나도 한번 이렇게 신청을 해본다.
내가 생각하는 안철수연구소의 이미지는 커널 레벨 드라이버를 만드는 아저씨들이 가득하고, 사무실에서 홀애비 냄새도 날 것 같은 여의도의 조그만 회사였는데, 이번에 새로 지은 사옥을 보고서 돈을 많이 썼구나하고 깜짝 놀랐다.
IT 회사들도 이렇게 신경써가며 예쁘게 건물을 꾸미는 추세를 몹시 환영한다. 좋은 사옥을 가진 IT 회사들이 훨씬 많아졌으면 좋겠다.
안랩의 직원은 700명 정도로 알고 있는데, 건물은 1000명도 훨씬 넘게 들어갈 수 있을 것으로 보인다.
안철수연구소에서 일해보고 싶었던 사람들에게는 지금이 기회라는 뜻이기도 하다.
사진을 보다보니 안랩 사옥 중에서 부러운 것 중 하나가 있었는데 바로 운동 시설이다.
휘트니스 클럽은 네이버의 그린팩토리에도 없는 공간인데, 참 과감하게 결정했다는 생각이 든다.
그런데 사람들이 이 넓은 공간을 얼마나 덜 이용하게 될지 또한 몹시 궁금하다. 나중에 꼭 한번 물어봐야겠다.
뭐 비효율적으로 운영된다 할지라도 직원들의 건강을 염려해서 이런 공간을 마련해준 회사가 참 보기 좋긴하다.
GNOME3에 너무 많은 기대를 해서 그런가. 이번 우분투 11.10은 많이 기대가 되서 알파3 부터 받아서 사용하고 있었는데, 기대가 큰 만큼 실망도 컸다.
문득 KDE는 얼마나 좋아졌나 싶어서 쿠분투를 설치해서 한달여 동안 사용해왔는데, UI 콘트롤들도 다 하나같이 고급스럽고 부드럽게 동작하는게 아주 만족스럽다. 예전에 2008년도 쯤 쿠분투를 설치해봤었을 때 그 조잡함에 충격 받았던 기억이 남아있었기 때문에 사실 좀 놀랐다. 아마 KDE4로 올라오면서 많이 좋아진 것 같다.
한달 동안 많이 익숙해 졌겠다, 정식 버전도 나왔겠다. 이번 주말에는 새로 이미지를 받아서 kubuntu로 데스크탑을 싹 정리했다. 아, 참 깔끔하고 좋다.
