꿈을 코딩하는 프로그래머.

출하를 몇일 앞두고, 프로그램 전반적으로 메모리 누수가 발견됬다.

원인은, 객체를 동적 할당하여 이곳 저곳 벡터에 포인터 값을 넘겨 저장하고,

벡터의 멤버함수 close()를 호출하여 마무리 작업을 완료 하였기 때문. (당황스럽지만 실제 발생된 일이다.)

실수라고 보기엔 너무나도 어이없고 당황스러운일. 아무튼 문제를 빨리 해결하는게 급선무.

그럼 그냥 delete문만 추가해주면 되겠네?? 하지만 현실은 그리 호락호락 하지 않다.

동적 할당된 구조체의 주소를 이곳 저곳 벡터에서 동시에 사용 하다 보니, 어느 하나의 벡터의 요소들을

먼저 delete 해버리면, 다른 vector에 혹시라도 중복된 요소가 있을경우, 그 요소가 가리키는 메모리가

해제된걸 알지못하고 두번 delete하는 일이 발생하여 결국 프로그램 Down으로 이어진다.

그럼 어떻게 하냐고??

세가지 방안을 생각해봤다.

첫째, 동적 할당된 주소를 넘겨 처리하던 구조를 정적할당한 구조체 자체로 넘겨주는 구조로 변경한다.

이렇게 되면 해당 벡터의 요소를 참조하는 모든 부분의 접근 연산자를 '->' 에서 '.'으로 변경 해주어야 한다.

물론 이는 탐색 변경 기능으로 빠르게 수정 가능하다. 다만 메모리 사용률이 동적할당 주소값을 사용하던 시절보다

많아진다는 단점은 있었다.(당연히 동적 할당된 메모리를 처리하지 않아 누수되는것보단 백번 낫다)

둘째, 동적 할당된 주소들을 관리하는 로직을 추가한다. 이 방법을 사용 하면 첫째 방법에 비해 메모리 효율이 있고

지금의 구조는 그대로 유지 가능하나, 추가 로직을 구현하고 전반적으로 많은 테스트가 필요하다는것이 상당히

번거로우며 시간적 효율이 없어 보인다.

셋째, Boost 라이브러리의 Shared Pointer를 사용 한다. 이 방법을 사용 하면 동적 할당된 메모리의 해제를 직접

해줄 필요가 없다. 메모리를 참조하던 변수들의 개수가 0이 되는 순간(내부 참조 카운트를 가진다) 스스로를 delete

하는 아주 쓸모있는 포인터이다. 다만 한번도 써본적이 없어서 사용 방법을 익히고 동작 매커니즘을 이해해야 한다는

수고는 있다. (첫째 방법과 마찬가지로, 벡터 요소를 참조하는 모든 로직의 수정이 필요하다.)

자 어떤 방법을 사용 할까? 선택은 내 몫이다. 

*Shared Pointer : 동적 메모리의 주소값을 참조하는 변수들을 자체적으로 Count한다. 이를 레퍼런스 카운트라

하는데, 레퍼런스 카운트가 0이 되는 순간 스스로를 delete 시킨다. (즉 New가 있으나 Delete가 없는 광경)

*Weak Pointer : Shared Pointer가 스스로를 참조할경우 레퍼런스 카운트가 꼬이는? 현상을 방지하며, 해당

Shared Pointer가 가리키는 동적 메모리가 존재 하는지를 판별하는 용도로 사용 된다.(설명이 어렵다.)

*Smart Pointer : Pointer가 선언 범위를 넘어가는 순간 소멸자가 호출되고 소멸자 내에서 자기 자신의 동적 

메모리를 삭제 한다.

 책 제목을 보라. 얼마나 흥미진진하고 궁금증을 자아내는가. 컴퓨터 과학이고 컴퓨터 공학으로 분류되며

누군가에겐 지적 노가다 작업인 프로그래밍이 상상이라니. 제목에서 부터 강한 예술의 냄새가 풍기지 않는가.

 프로그래밍을 단순 노가다 작업으로 여기고 평가 절하하는 사람과, 모든 작업에 상상력과 창의력을 부여하며

창조적이고 예술적으로 여기는 사람에겐 큰 차이가 존재한다. 바로 프로그래밍을 통한 '기쁨'이다. 프로그래밍을

어떻게 생각하고 행하는가에 따라 만들어지는 결과물은 분명 큰 차이를 갖게 된다. 프로그래밍은 생산성의 향상을

위해 과학과, 공학과 결합한 컴퓨터 공학이나 컴퓨터 과학과는 다르다. 무에서 유를 창조하며 사용자에게 감동이나

재미 즐거움을 전달한다는 점에서 이미, 감각적이고 창의적인 프로그래머의 손끝을 통해 탄생한 예술 작품인 것이다.

임백준 작가는 이와 같은 프로그래밍의 즐거움과 예술성을 책의 전반에 걸쳐 이야기 한다.

 책 발간 당시의 여러 관심사와 최신 IT 트렌드에 대해서 이야기 하고 있지만, 2004년에 발간된 책이니 만큼 지금의 

최신 트렌드에 많이 뒤쳐져 있는 내용이다. 하지만 '최신' 이라는 속성만 제외 하고 본다면 개발자로써, 그리고 IT 상식

으로써 충분히 알아 두어야할 내용 들이라고 생각한다. 에자일 프로그래밍 방법론, 자유 소프트웨어, 웹3.0 등이 그렇

다. 또한 리팩토링, 객체지향, 디자인 패턴등에 대한 개요는 본격적인? 이론은 아니었지만 핵심을 살짝 들여다 볼 수

있어서 좋았다. 왜 필요하고 공부해야할 가치가 있는 이론들인지 느껴졌다.

 좋은 개발자가 되기 위해서는, 알고리즘이나 디자인패턴과 같은 테크닉 뿐만 아니라 개발에 대한 태도나 마음가짐

사람들과의 커뮤니케이션이나 논쟁과 같은 비기술적인것들도 중요하다는 것을 깨달았다. 

- 프로그래머에게 필요한 본질은 논리력, 끈기, 순발력. 프로그래머는 상상하기 떄문에 행복하다.

- 프로그래밍은 프로그래머에게 놀이다!

- 웹 2.0, 시맨틱 웹, 웹 3.0

- 가상화 기술

- 리아 시장

- 서비스 중심 아키텍쳐(SOA), SOA가 추구하는 원리는 근본적으로 객체지향의 원리가 지향하는 바와 다를 바 없다.

- 매쉬업

- 하드코어 프로그래머, 멀티 쓰레딩

- 메타프로그래밍

- 상황중심의 프로그래밍(Aspect Oriented Programming)

- 유닛테스트

- 프로그래밍을 구성하는 일곱 개의 단계

- 애자일 프로그래밍 

- 프로그래밍은 예술이다.

- 소설처럼 읽히는 프로그래밍

프란체스코회 수도사 라는 의미의 '프란치스카너'

독일 뮌헨 맥주이다.

목넘김이 매우 부드럽다.

신맛이 적다.

부담없이 먹기 좋은듯.

독일 바이에른주 뮌헨 맥주이다.

옥토버페스트의 대표 맥주 6종중 하나.

신맛이 강하고 쌉싸름 하다.

목넘김은 깔끔한편

 나의 개발 결과물은 다양한 환경 요소의 영향을 받곤 한다. 조여오는 일정. 개발 당시의 컨디션,

수많은 테스트와 검증이 진행된(그래서 안전하다고 착각을 할 수 있는) 코드에 대한 믿음과 신뢰,

내 영역이 아닌 코드를 수정함으로 인해 오는 스트레스, 심지어 눈앞에 아른거리는 신상 가죽자켓에 대한 생각 등. 

나의 손끝에서 이루어지는 코딩 작업은 이러한 뇌속의 수많은 복잡한 생각들을 반영하듯 뒤죽 박죽일때도,

한편의 아름다운? 시처럼 매끄러울때도 있다. 그 중. 특히 내게 많은 영향을 끼치고 있던 것은

"이전 사람들이 구현해놓은 구조에 대한 강박" 이다.

 회사 프로젝트는 많은 멀티 쓰레드 & 멀티 프로세스 프로그램이다. 그러다보니 여러 쓰레드와 프로세스가 사용하는 

버퍼가 있는데, 이 버퍼의 용도는 다양한 구조체의 정보를 담아 여기 저기에 전달하는, 

말 그대로 데이터들의 버퍼로 사용 되고 있었다. 

 프로그램의 특정 내부의 어떤 리스트의 크기가 증가함에 따라 구조체의 크기가 증가하였고, 필연적으로 이 버퍼에도 영

향이 발생 하였다. 하지만 수정은 호락호락하지 않았는데, 미친년 머리카락처럼 꼬여있던 코드는, 단순히 전역 상수

(버퍼 크기)만 증가시켜서는 무시무시한 프로그램 종료를 피할 수 없는 지경이었다. 

나는 이 문제를 해결하기 위해 연관된 모든 사이즈, 로직 등을 전역 상수의 값으로 변경시키는 작업을 진행 하였고, 

오버플로 디버깅에 귀중한 시간들을 소모 했다. 결과는 만족스러웠다. 팀장님의 코드리뷰가 있기 전까지는..

 "뭐하러 관련된 부분을 다 수정시킨거야??. 그 기능에서 사용하는 구조체만 따로 빼서 관리하면 되는걸."

망치로 맞는 기분이었다. 저렇게 간단하고 직관적인 해결책이 있었는데, 나는 왜 그렇게 어렵고 크게 일을 해결하려

했던걸까?? 곰곰이 되짚어 보았다. 그리고 오래지 않아 그 답을 알 수 있었다. 

이유는 바로, "이전 구조와 틀을 넘어서면 무시무시한 일이 일어날 거야"라는 강박에서 비롯된 것이다. 

이 말이 틀린것은 아니다. 회사 프로젝트는 여러 사람의 공동 작업물이며, 효율과 관리를 위해 공통의 코딩규칙(그 

외에도 있다.)이나 설계가 존재 하기 마련이다. 하지만 눈앞의 사실 하나에만 집중 하면, 더 멀리 있는 본질을 

놓칠 수가 있다. 이전의 구조체와 버퍼의 흐름 구조를 유지하는 선에서의 개선방법만을 찾다 보니 그것에서 조금이라도 

벗어나는, 바로 옆의 더욱 간단하고 강력한 해결책을 놓친 나의 경험처럼 말이다.

  이전의 검증되고 안정된 코드와 모듈은 유지 하되, 필요에 따라 과감한 수정이나 개선을 할 수 있는 깡다

구와 멀리 내다 볼 수 있는 시야가 필요 하다.

*인터넷 뒤지며 얻은 정보를 개인 적으로 종합, 정리 하였음.

- 라인 피드 (LF : Line Feed, 0x0a) : 캐럿을 다음 줄(현재 위치에서 바로 아래)로 이동 시킨다.

- 캐리지 리턴 (CR : Carriage Return ) : 캐럿을 줄의 맨 앞으로 이동 시킨다.

즉 모두 '줄 바꿈'과 관련이 있는 문자다.

줄 바꿈에 대한 정의는 시스템(OS), 언어 마다 다르다.

- 유닉스/리눅스 : LF만으로 줄 바꿈을 정의 한다.

- 윈도우/DOS : CRLF 조합으로 줄 바꿈을 정의 한다.

- C언어 : 유닉스 태생으로 LF만으로 줄 바꿈을 정의 한다.

위와 같이 유닉스/리눅스 시스템과 윈도우/DOS 시스템의 줄 바꿈에 대한 정의에 차이가 있다.

프린터나 타자기?와 같은 장비에선 LF로 캐럿의 위치를 현재 위치에서 바로 아래로 이동 하며 CR을 통해 줄의 맨 앞으로

이동 시키는 CR/LF (LF/CR과 다르다)의 조합을 통해서 줄 바꿈이 이루어 지는데

윈도우와 DOS는 이를 그대로 따라 가고 있다.(시스템 입장에서 보면 불편 한듯?)

따라서 윈도우의 파일을 그대로 리눅스로 옮기면 문자열 맨 끝에 '\r\n'이 붙게 되며

이를 리눅스 프로그램에서 그대로 사용시 문제가 발생할 소지가 있다.

윈도우와  DOS의 경우 C의 줄바꿈에 대한 정의와 차이가 있다.

즉 윈도우와 DOS에서 작성된 C프로그램이 줄바꿈을 '\n'으로 입력하면 하거나 읽어들이면

실제 파일에 '\r\n'으로 기록 되거나 읽히게 된다.

이러한 차이를 없애기 위해 fopen 함수 호출시 두번째 인자로 'b'(바이너리 모드)를 주지 않게 되면 C 라이브러리에서

'\n'을 '\r\n'으로 인식 하게 된다. 그러나 이 경우 두개의 '\r\n' 문자를 하나의 '\n' 문자로 인식 하기 때문에

파일 크기를 다루는 상황 등에서 문제가 발생할 수 있다.

이전 리눅스 파일 시스템에서 File의 최대 크기는 2147483647byte 즉 2GB(1.99)였다.

이는 2^31 -1의 값이다. 즉

int32형에서 표현 가능한 최대 양수이다.

OS상에서 File의 주소, Offset 관련 Data가 int32형으로 표현 되어 있었기에 제한이 있었던 것 같다.

마찬가지로 fopen, fwrite등의 함수로 2GB넘는 파일에 접근이 불가능 하다. 내부적응로 int32가 박혀 있을 것 같다.

그래서 라이브러리에서는 2GB 이상의 파일을 다룰 수 있도록 fopen64, fwrite64등의 함수를 제공 하고 있다.

그렇다면 기존의 파일은 어떻게 하나? 일일히 바꾸기 힘들기에 다음 옵션을 사용 할 수 있다.

컴파일 옵션에 -D_FILE_OFFSET_BITS=64 을 입력 하면 file 관련 함수, 변수들이 자동으로 32->64 bit용으로 변경이 

된다고 한다.

** 16.02.07 추가

fseek 함수와 ftell 함수는 위의 컴파일 옵션으로 해결이 안된다.

이 함수들은 자체적으로 fseeko 와 ftello 함수로 변경 해주어야 한다.

BSD(Berkeley Software Distribution)는 1977년 미국 캘리포니아 대학교 버클리(University of California, Berkeley)에서 개발한 유닉스 계열의 컴퓨터 운영 체제이다.

출처 : 위키 백과

 월플라워 Wall Flower. 무슨 뜻인가 검색해 보았는데. 댄스스포츠사전에 "댄스 모임에서 파트너를 만나지 못한 여성"이라는 뜻이 기재 되어 있었다. 영화의 내용과 비추어 본다면 친구가 없는 외톨이에 소극적이고 내성적이고 인기없는 주인공을 빚대어 표현한것이 아닐까 생각해본다.

 로건 레이먼이 연기한 찰리는 고등학교에 입학하여 중학생때와 마찬가지로 수업시간 답을 알고도 말하지 못하며 항상 혼자 밥을 먹고, 남은 졸업일만을 세고 있을 만큼 소심하고 내성적인 아웃사이더이다. 그러던 그가 럭비 경기를 보러 간날 만나게 된 말썽꾸러기 문제아 패트릭과 그의 이복동생 샘(엠마와슨) 그리고 그 친구들을 만나면서 달라진 삶을 살기 시작한다.

 소설가가 꿈인 찰리는 책 읽기를 좋아하고 오래된 팝송 듣기를 좋아하는 취미를 가지고 있다. 그래서 늘 집에만 있으며 친구가 없는데 그런 찰리를 거리낌 없이 대해주는 문제아(스스로를 그리 칭하는) 친구들과 교감하고 소속감을 느끼며 하루 하루 달라진 삶을 살아 간다. 그러던 중 다른 사람의 시선을 신경쓰지 않으며 자신의 음악적 취향에 큰 공감대를 형성하는 샘에게 이성적 감정을 느끼게 된다.하지만 자신감이 부족한 찰리는, 그녀에게 좋아하는 마음 한번 표현 하지 못하고 그녀가 다른 남자와 키스 하는 모습을 보면서도 그녀가 행복해 하는걸로 만족하며 잘 되었으면 좋겠다는 생각만을 갖는다.

 영화 후반부 샘이 찰리에게 이런 말을 한다. 

샘 "왜 한번도 나에게 고백하지 않았어?" 

찰리 "나는 네가 그걸 원한다고 생각 하지 않았거든"

샘 "니가 원하는건 뭔데"

찰리 "그냥 난 네가 행복했음 좋겠어"

샘 "모르겠어 찰리? 난 느낄 수 없어. 정말 고마운 말이지만 그냥 앉아서 사람들의 인생에 개입할 순 없는거야 넌 그걸 

사랑이라고 생각 하겠지만 난 누군가의 짝사랑으로 남긴 싫어. 난 그 사람들이 진짜 나를 좋아해주기를 바래"

 짝사랑 하는 이들 그리고 사랑을 하고 있는 이들 모두에게 공감 가는 대사일 것이다. 우리가 누군가를 진심으로 위한다고 할지라도 그것을 말로, 행동으로 표현하지 않으면 상대에게 닿지 않는다. 표현해라! Behavior!

 찰리는 친구들을 사귀고, 샘을 좋아하며 이전 과는 다르게 "적극적으로 개선하는 삶"을 하기 위해 노력하며, 자신의 재능을 알아봐주고 지지해주는 좋은 교수를 만나 소설가로써의 꿈을 키워간다. 비록 그 과정 속에 크고 작은 아픔과 상처, 시련들이 있지만 찰리는 항상 스스로 문제를 해결하기 위해 행동하고 노력한다. 그 결과가 모두 달지는 않더라도 말이다. 

영화 중간 중간 이모에 대한 추억 장면들이 나오는데 영화 마지막즈음에 반전이 하나 숨어 있었다. 영화 초중반 좋은 추억으로만 비추어졌던 찰리 이모는 사실 어린 시절 자신에게 성적인 상처(성추행일지 성폭행일지는 불분명하다.)를 남겨 찰리에게 트라우마를 안겨준 인물 이었던 것이다.. 그 래서 찰리는 이모가 죽길 원했고, 실제 이모가 사고로 돌아가자 그것이 자신의 잘못이라는 죄책감을 안고 살았던 것이다. 그러한 상처들이 찰리를 소심하고 자신감 없는 아웃사이더가 되는데 영향을 주었다고 생각한다.

 항상 그저 그런 남자들만 만나고, 자존감 없는 샘을 보며 가슴 아프던 찰리가 교수에게 물어본다.

"왜 항상 괜찮은 사람들은 별로인 사람들과 만나는 걸까요? 그들을 제가 바꿀 수 있을까요? 

그러자 교수가 말한다.

"노력은 할 수 있지"

 그리고 찰리는 샘의 대학 진학을 위해 함께 공부하며 도와주고, 그녀에게 항상 "넌 그럴 자격이 있어" 라는 말을 하며

용기를 북돋아준다. 그리고 결국 샘은 자신이 원하던 펜실베니아 대학교에 입학하게 된다.

 떠나기전 찰리와 샘의 대화에서 영화의 메시지이자 명대사가 나온다.

샘 "왜 항상 사람들은 자신을 함부로 하는 사람들을 사랑 하는 걸까?"

찰리 "사람은 자기가 생각하는 만큼만 사랑 받기 마련이거든"

 우리가 우리 자신을 한계 짓고 낮은 자존감을 갖는다면 누구에게 큰 사랑을 받을 수 있을까?

 영화는 찰리가 '누군가'에게 쓰는 편지를 읽으며 진행이 되는데, 이 편지에서 영화 흐름 중간 중간 찰리의 심경 변화를

알 수 있다. 영화의 라스트 장면에서, 찰리는 과거의 아픔과 트라우마를 극복 하고, 더 나은 '적극적인'삶을 살기위해 노

력 하겠다는 편지를 쓰며 앞으로는 편지 쓰기가 힘들것 같다는 말을 남긴다.

 미래에 어떤 글을 쓰는 작가가 될지 고민하는 찰리에게 샘이 이런말을 한적이 있다. "우리의 이야기를 써"

영화가 끝이 나지만 찰리는 앞으로 자신의 이야기를 펼쳐 나갈 것이다.

"지금 이 순간 만큼은 책에서의 이야기가 아니야. 지금 일어나고 있는 이야기고 난 여기에 있어.

넌 살아있어. 그리고 난 확신활 수 있어. 우리에게 한계는 없다는걸"

 우리는 지금 살아 있다. 어떠한 일이든 해낼 노력과 시간이 있다. 자신을 한계 짓지 말고, 더욱 적극적으로 자신을 변화시키는 삶을 살아 갸야 하지 않을까? 아웃사이더 찰리처럼 말이다.

작년 14년 하반기부터 읽기 시작해서 2월말쯤 완독한 책..

무슨 책을 반년이나 읽는지에 대한 핑계로는.. 다른 책도 병행해서 보고 있었고 이런저런 공부에 준비도 하고 있었고

현 직장에 잦은 출장과 야근도 있었기 때문.. 앞으론 한번 손에 잡은 책은 빠르게 읽고 내려 놓자는 다짐으로

리뷰를 시작해 보면..

자세히 깊게 쓰고 싶지만.. 딱히 뭐 기억이 안난다. 디테일하게.. 두번째 완독 이후에 정리 하기로 하고

간략히 쓰면.

이전 마이크로소프트 개발자였고 현 개발자이자 CEO인 조엘이 오래전부터 자신의 블로그에 올리던 기고하던

반응 좋던 글들을 모아놓은 책으로

(당시의)트렌드나 이슈에 대한 생각. 마이크르소포트에서 일한 경험을 토대로한 여러 경험담들.

그리고 특히나 "관리자와 소프트웨어 기업의 관리직에 있는 사람들에게 도움이 될" 내용을 다루고 있다.

개발자와 팀의 효율을 끌어 올리기 위한 관리법이라던가, 도움이 되는 개발 프로세스들에 대한 이야기들이

담겨 있다. 일일 빌드나 일정 잡는법 등 개발자에게 도움이 되는 내용도 많다.

글의 문체도 재미있고 유익한 내용도 많았지만 지금 특히 기억에 남는건. "모든 완벽해 보이는 것에는 약점이 있다(맞나?)

라는 내용의 챕터였는데 추상화, 객체 지향의 허점 등의 내용이 재미 있었다.

다음에 볼 책은 "모어 조엘온 소프트웨어!"