저자 : 박재호
포항공과대학교 컴퓨터공학과 학부와 포항공과대학교 대학원 컴퓨터공학과를 졸업했다. 블로그 '컴퓨터 vs 책'(http://jhrogue.blogspot.com)을 운영하고 있다. 지은 책으로『IT EXPERT, 임베디드 리눅스』(한빛미디어, 2002) 등이 있고, 옮긴 책으로『The Art of Project Management : 마음을 움직이는 프로젝트 관리』(한빛미디어, 2006)『, 리눅스 디바이스 드라이버, 개정5판』(한빛미디어, 2005), 『리눅스 문제 분석과 해결』(에이콘, 2006), 『 조엘 온 소프트웨어 : 유쾌한 오프라인 블로그』(에이콘, 2005) 등이 있다.
1장. 단순한 파일 비교를 넘어서
2장. 원시 코드 색인은 나에게 맡겨라
3장. 공유 라이브러리와 심볼 이름을 찾아라
4장. 분위기 파악 못하는 훼방꾼 configure(1)
5장. 분위기 파악 못하는 훼방꾼 configure(2)
6장. 자동화된 빌드 시스템 구축(1)
7장. 자동화된 빌드 시스템 구축(2)
8장. 숨겨진 1인치의 의존성을 찾아라
9장. 메모리 디버깅을 위한 친구
10장. 프로그램을 동적으로 추적하는 도구
11장. 스택 탐색을 통한 디버깅
12장. 스택 탐색을 통한 백트레이스 구현
13장. 공포의 커널 패닉과 웁스
14장. raw 디바이스 다루기
열씨미 씨는 디렉토리가 10개이며, 원시 코드 파일(*.[ch]) 개수가 500개가 넘는 큰 프로그램을 수정 중이다. 혼자서 만들어도 뭐가 바뀌었는지 기억이 가물가물할 텐데 팀원이 여러 명이다 보니, 어디서 뭐가 바뀌었는지 매번 길을 잃고 헤매고 있다. 하도 답답한 나머지 우리의 꾀돌이 게을러 씨에게 맥주 한잔을 걸고 방법을 물어 보았다.
열씨미: 버전이 올라감에 따라 어떤 파일이 변경되었는지 알아내려고 할 때마다 머리가 아파 죽을 지경일세.make와 같이 특정 파일이 변경된 시각을 기준으로 바뀐 파일만 출력하는 방법이 없을까?
게을러: 변경된 시각으로 비교하고 싶다면 직접 셸스크립트를 만들어도 되지만, find(1)를 한번 써보면 어떨까? 어떤 파일을 기준으로 변경시각을 비교하고 싶은 거야?
열씨미: myproject 디렉토리에 있는 yesterday.c인데, 이 파일은 내가 어제 오전에 변경한 파일일세. 이 파일보다 나중에 만들어진 파일(즉, 오늘 변경된 파일)을 볼 수 있으면 정말 좋겠어.
게을러: 다음과 같이 명령을 한번 내려 보자구.
$ find
/home/jrogue/project/very_very_large_project
-newer./myproject/yesterday.c
열씨미: 우와 정말 멋지...열씨미 씨는 디렉토리가 10개이며, 원시 코드 파일(*.[ch]) 개수가 500개가 넘는 큰 프로그램을 수정 중이다. 혼자서 만들어도 뭐가 바뀌었는지 기억이 가물가물할 텐데 팀원이 여러 명이다 보니, 어디서 뭐가 바뀌었는지 매번 길을 잃고 헤매고 있다. 하도 답답한 나머지 우리의 꾀돌이 게을러 씨에게 맥주 한잔을 걸고 방법을 물어 보았다.
열씨미: 버전이 올라감에 따라 어떤 파일이 변경되었는지 알아내려고 할 때마다 머리가 아파 죽을 지경일세.make와 같이 특정 파일이 변경된 시각을 기준으로 바뀐 파일만 출력하는 방법이 없을까?
게을러: 변경된 시각으로 비교하고 싶다면 직접 셸스크립트를 만들어도 되지만, find(1)를 한번 써보면 어떨까? 어떤 파일을 기준으로 변경시각을 비교하고 싶은 거야?
열씨미: myproject 디렉토리에 있는 yesterday.c인데, 이 파일은 내가 어제 오전에 변경한 파일일세. 이 파일보다 나중에 만들어진 파일(즉, 오늘 변경된 파일)을 볼 수 있으면 정말 좋겠어.
게을러: 다음과 같이 명령을 한번 내려 보자구.
$ find
/home/jrogue/project/very_very_large_project
-newer./myproject/yesterday.c
열씨미: 우와 정말 멋지군! 이걸 써서 당장 어떤 파일이 변경되었는지 찾아봐야겠어. 나중에 맥주 한잔 하자구.
- Story 01 _단순한 파일 비교를 넘어서 중에서
--- 본문 중에서
문제해결의 실마리를 제공하는 리눅스 개발 경험담
책에 싣기에는 내용이 가볍고, 월간지 기사 형식으로 내기에는 분량이 많으며, 블로그에 올리기에는 무거운 주제가 틀림없이 존재한다. 리눅스로 개발하면서 겪은 경험담도 바로 이런 주제에 해당하는데 책으로 정리하면 부드럽게 시작한 글이 딱딱한 글로 끝나버리고, 월간지에 매달 조금씩 연재하면 독자에게 전달되는 기간이 너무 오래 걸리기에 '경험담'이라는 좋은 특성이 사라져버린다. 그렇다고 블로그에 올리자니 글이 너무 길어져서 지루하다. 이런 상황을 어떻게 극복해야 할까?
생각 끝에 낸 아이디어는 독자들이 편안하게 읽을 수 있도록 짤막하게 끊어서 내용을 전개하되, 유기적으로 '블로그처럼' 구성하자는 것이었다. 이 책은 전형적인 리눅스 해커 '게을러'와 리눅스 신참인 '열씨미'가 리눅스로 개발하면서 겪는 애로사항을 대화형식으로 풀어낸다. 이런 대화형식은 어느 정도 개발 실력이 있지만2% 부족함을 느껴 다른 사람이 겪은 경험담에 목이 마른 개발자에게 문제를 푸는 실마리를 제공한다. 두 주인공이 주고받는 대화를 엿듣다 보면 '아하!' 하고 문제의 원인과 해결책을 깨닫는 순간이 찾아올 것이다.
이제 다른 사람이 저지른 실수를 반복하지 말자.
같은 실수를 겪은 저자의 경험담과 노하우가 이 책에 있다.
-. 개발 현장 속에서 얻은 소중한 지식을 블로그의 글처럼 재미있게 구성했다.
-. 리눅로 개발하면서 겪는 다양한 문제들과 그 해결책을 14개의 이야기로 엮었다.
-. '열씨미', '게을러'라는 가상인물의 대화를 통해 실제로 개발현장에서 일어나는 현장감을 담아냈다.
-. 두 주인공의 대화는 어느 정도 개발 실력이 있지만 2%의 부족함을 느껴 다른 사람이 겪은 경험담에 목이 마른 개발자에게 문제를 푸는 실마리를 제공해준다.
카트
