장애인 무슨 협회인지, happy 뭐라는 사이트와 관련된 단체라고한다. 작년 7월에도 내가 거절했고, 올해 2월에도 거절했단다. 모두 기억이 안나지만 이 전화를 거절하게 되어서 세번째 거절하는 것이 된다. 전화를 주시는 분은 약간 음성이 떨리고, 인간적인 생각으로 전화를 끊게 되는 것이 도의상 안되는 짓을 한 것 같다는 생각이 든다. 많은 생각이 든다. 내가 이런 류의 전화를 모두 거절할 만큼 매말랐거나, 몇몇 후원하는 것을 핑계로 마음을 닫거나, 이미 충분히 생각하지 않고 나도 잘 모르는, 사실 연고가 없는 단체를 후원하고 있기 때문에, 난 그 단체냐고 되물었지만 거기가 아니랜다. 내가 생각하는 후원은, 어떤 방식으로든 그 단체를 내가 알게되는 사람이 있어야 가능하다고 생각한다. 단지 그 단체가 무슨 ..
지난 1주일 노력 많이 했다. 20개 이상되었던 것을 모두 답변처리 혹은 다음 버전에 픽스하여 넣도록 수정하여 2 개로 줄이다. 오늘은 휴일이거든, 무슨 일이었냐고? 팀전체는 75개에서 25개로 줄이게 되었는데, 모두 묘한 경쟁체제 덕이 아닌가 싶다. ^^; 버그 트래킹 시스템의 TODO list를 한 시간에 한 번씩 메일로 날아 오도록 프로그램해놓았거든. 다른 글에서 소프트웨어 번역에서 경쟁의식을 느껴가며 (혼자서만) 일하는 것을 소개한 적이 있는데, 인간이 그런 것인지 아니면 내 성향이 그런 것인지, 꽤 건전한 성장 동력이 되는 것 같다. 주체할 수 없는 어떤 힘이 있을 때, 그것을 막는 것 보다는 잘 길들일 수 있고 힘이 분출 될 수 있는 길을 만드는 것이 현명한 일이다. 내 안에 있는 힘들의 종류..
이번에도 지난번 글과 같이 간단한 함수의 디스어셈블을 통하여 함수호출시에 일어나는 일들을 살펴보고자 한다. 참고로 이와 같은 학문(?)의 범주는 다음과 같은 위치에 있다. * C 언어 표준 스펙 * intel x86 CPU의 System V Application Binary Interface * gcc의 구현 System V ABI 를 검색어로 찾아 보면 원하는 글을 찾을 수 있을 것이다. void func6( char x1, char x2, char x3) { x1 = 1; x2 = 2; x3 = 3; } struct _p { int a1; int a2; int a3; }; void func7( struct _p p1, int p2 ) { p1.a1 = 1; p1.a2 = 2; p1.a3 = 3; p2..
C 언어는 전통적으로 다음과 같은 방식으로 실행파일이 만들어진다. (1) 편집기를 통한 소스 작성 (2) 전처리기를 통해 소스로부터 매크로 확장 및 주석 제거 (3) 컴파일러를 통해 전처리된 코드로부터 어셈블코드 생성 (4) 어셈블러를 통해 어셈블코드로부터 목적파일 생성 (5) 링커를 통해 목적파일들 (라이브러리 포함)의 결합에 의한 실행파일 생성 이 중에서 (3) 번과정을 재미로 살펴보면서 어떤일들이 일어나는지 알아보고자 한다. 테스트한 환경은 다음과 같다. * x86 CPU * gcc 3.3.2 테스트 코드는 다음과 같다. void func1() { } void func2( int x ) { x = 0; } int func3() { return 7; } void func4() { int y; y = ..
find 를 제법 잘 쓰는 사람은 다 아는 얘기일 것 같지만, 흔히들 사용하면서도 그 많은 옵션이 잘 안들어오는 사람들을 위해 정리하고자 글을 써본다. find의 철학은 그 이름에서 이미 감춰져 있다고 해도 과언이 아니다. find를 통해서 할 수 있는 것이 고작 원하는 이름의 혹은 원하는 속성을 가진 파일을 찾는 것이라 생각한다면 그것은 정말 누구나 사용할 줄 아는 방법으로서의 find 이다. find의 철학은 다음과 같다. 어디에 이런 글이 쓰여있는지는 나도 모르겠지만, 경험상 정리하자면, find 는 true/false에 의한 directory 탐색기이다. 신선한가? 우선 다들 그러하듯이 man find를 한번 수행해보고 true/false라는 말이 얼마나 나오는지 한 번 살펴보시라. 가능하면, 리..
하루에 한번씩 돌아가는 버그 어세신, 유닛 테스트는 업무중 한시간에 한 번씩 자동으로 수행하게 되어 있으며, 메일로 그 성공 여부가 전달된다. 그날의 담당자에게는 버그 어세신 푯말이 세워지고, 그날 발생하는 유닛 테스트의 버그 처리의 주 담당자가 된다. 좀더 자세히 보자 그러나.. 이렇게 하는 이유는 아무리 메일로 보고가 되어도, 메일을 자주 확인하지 않는자와, 다른 일에 치여 사는 자, 혼자 하기에 지쳐버린 자, 뭘 잘 모르는자로 구분되어서이다. 그리고 메일 한번씩 인스톨을 해보자스라. 이건 어제 선서했으므로, 지키겠지.
다섯시에 일어나면, 적어도 태양이 뜨는 것을 볼 수 있다. 요즘같은 하지 전에는 태양이 북동쪽에 뜨므로, 북쪽에 창이 나있기만해도 서서히 밝아 오는 태양을 볼 수가 있다. 태양은 질때도 그렇지만, 뜰 때도 순식간이지 저멀리 미래 도시같은 현대 백화점 멀리 뒤편으로 태양이 붉게 물들며 뜨는 광경은 아침에 일어나길 잘했다는 생각을 들게 한다. 지금 너무 늦었다. 하루를 그렇게 일찍 시작한다는 것은 필연 일찍 자야한다는 부담을 주게마련인데, 요즘 같이 일이 많은 때는 하루종일 잠에 빚진자처럼 산다. 지난주 금요일에 일단락해야할 프로젝트가 오늘도 금요일이다. 월화수목금금금금금. 5일동안 지속되는 금요일 봤나. 쉬지도 못하고. 훙
- Total
- Today
- Yesterday
- TCP/IP
- ssh
- 퀴즈
- 커피
- 킹벤자민
- 오픈소스
- BlogAPI
- MySQL
- SSO
- writely
- 대화
- 디버깅
- 구근
- macosx
- 수선화
- 벤자민
- 덴드롱
- 식물
- perl
- Linux
- 클레로덴드럼
- nodejs
- SVN
- Subversion
- url
- tattertools
- OpenID
- Tattertools plugin
- VIM
- JavaScript
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |