nEKO'S tHINK

STL Map의 [ ] 연산자 사용시 주의점

2008-12-01T02:01:12+09:00

STL Map은 시퀀스 컨테이너(Sequence container)처럼 [ ] 연산자를 제공합니다. 중요한 점은 "C++ Standard Library 튜토리얼·레퍼런스(인포북, 니콜라이 M. 조슈티스)" 책에도 나와 있듯이 [ ] 연산자의 인덱스는 정수 값이 아니라 map의 key 값이라는 것입니다. 이것을 정확하게 숙지하지 않고 잘못사용하면, 심각한 문제가 생길 수 있습니다. 아래는 [ ] 연산자를 잘못 사용한 코드의 예입니다.

// 커피 자판기를 하나 만들고, 판매할 커피를 추가합니다.
std::map<int, std::string> mapCoffeeMachine;

mapCoffeeMachine[0] = "Espresso";
mapCoffeeMachine[1] = "Macchiato";
mapCoffeeMachine[2] = "ConPana";
mapCoffeeMachine[3] = "Latte";
mapCoffeeMachine[4] = "Cappuccino";
mapCoffeeMachine[5] = "Mcha";
mapCoffeeMachine[6] = "Caramel";
mapCoffeeMachine[7] = "Americano";

// 생각을 해보니 라떼와 카푸치노는 제고가 없네요.
// 라떼와 카푸치노 버튼을 자판기에서 사용하지 않습니다.
mapCoffeeMachine.erase( 3 );
mapCoffeeMachine.erase( 4 );

...

// 한 구매자가 자판기 앞에서 돈을 넣고 아메리카노를 누릅니다.
for ( int i = 0; i < mapCoffeeMachine.size(); i++ )
{
    if ( mapCoffeeMachine[i] == "Americano" )
    {
        ... // 따끈따끈한 아메리카노 한잔이 나옵니다.!?
    }
}

과연 구매자는 자판기에서 따뜻한 아메리카노 한잔을 뽑아 담배와 함께 커피한잔을 할 수 있을까요? 평생을 기다려도 아메리카노는 나오지 않습니다. 위의 코드는 [ ] 연산자의 인덱스를 정수 값으로 취급한 상당히 잘못된 코드입니다. 문제점은 크게 두 가지로 나뉠 수 있는데, 첫 번째는 size() 함수로 컨테이너의 크기를 구하면 제거된 3, 4번 키 값 때문에 사이즈가 6 이 됩니다. 그러므로 6, 7번 key 값은 아예 비교 대상이 안 됩니다. 커피를 마시러 온 사람은 메뉴를 보고 눌렀는데, 커피는 않나오고 동전이 반환된 꼴이 된 것입니다. 그러나 커피가 않나오는 것보다 더 큰 문제점이 있습니다. 바로 제거한 3, 4번 키 값의 내용이 == 동등 연산자를 통해 빈 value 값이 다시 추가가 된다는 점입니다. 컨테이너의 크기는 8이 되어 이제 커피메뉴에는 8개로 등장하는데, 아무것도 없는 메뉴가 자판기에서 눌러질 수 있다는 사실입니다. 커피가 들어있지 않는 빈 컵만 받게 되겠지요.

위에는 단순히 자판기로만 예를 들었지만 삭제한 내용이 다시 추가되는 문제점은 실제 개발 시에 큰 문제점을 가져올 수 있습니다. 특히 여러 명의 개발자가 작업을 할 경우 개발자 마다 서로 다른 작업방식으로 프로그램이 다운될 수도 있습니다. 이러한 문제점 때문에 컨테이너를 순회할 때는 반드시 반복자를 사용하는 게 필요합니다.

직원 할인으로 점심식사 후 거의 매일가는 서초동 포이트리 커피숍 :)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

"살인의 해석" 을 읽고

2008-11-19T01:10:13+09:00

"심리학적으로 해석하는 추리소설"

───────────────────────────────────────────────

⊙ 제 목 : 살인의 해석
(The Interpretation of Murder)

⊙ 지은이 : 제드 러벤펠드(글), 박현주(옮긴이)
⊙ 장 르 : 외국소설
⊙ 펴낸 곳 : 비채
⊙ 펴낸 날 : 2007년 2월 12일
⊙ Page : 555쪽
⊙ ISBN : 9788992036290

⊙ 평점 : ★★★★☆

───────────────────────────────────────────────

"환자를 치료하려온 정신분석학자가
범인을 추적하는게 다소 비현실적이다.

환자인 액튼 양과 정신분석학자인 영거의 관계,
끝까지 사건을 해결하려는 개성있는 캐릭터 리틀모어의 등장으로
이야기는 재미있게 전개된다.

챕터와 챕터 사이에 스토리 전개의 핵을 끊어
독자들로 하여금 궁금증을 유발시키는 미국식 스토리 전개는
책을 읽는동안 지루함을 느끼지 못하게 한다.

1909년도의 미국의 시대상, 현실에 대해서도 조금은 이해를 하게 된다."

인상깊은 부분

44쪽:

"의자나 뭐 그런 거요."
"의자?" 검시관이 되풀이했다.
"그럴 수 있잖아요."
"여자를 채찍으로 때리려고 의자 위에 올라가는 남자는 없네. 형사."
"어째서요?"
"그러면 웃기잖아. 떨어질지도 모르고."
"뭔가 붙잡고 있으면 안 떨어질걸요. 뭐 램프라거나, 모자걸이라거나."
"모자걸이? 범인이 뭐 하러 그런 짓을 했겠나?"
"키를 더 커 보이게 하기 위해서죠."
"자네 살인 사건을 몇 건이나 수사했지?"
"이게 처음인데요." 리틀모어는 흥분을 감추지도 않았다. "형사로 서는요."

150쪽:

"말을 놔줘요!" 누군가 소리쳤다. 분노와 고통에 찬 소녀의 목소리였다. 액튼 양이었다. 그녀는 군중을 따라 42번가로 걸어갔고, 지금은 사람들 맨 앞에 나와 있었다. 영거는 액튼 양 바로 옆에 서 있었고, 리틀모어는 몇 줄 뒤에 있었다. 여자가 다시 외쳤다. "말을 내려줘요. 누구 저 사람 좀 말려줘요!"
"올려." 밴월이 명령했다. 그는 소녀의 목소리를 들었다. 그는 한순간 소녀를 돌아보았다. 그러고 나서 다시 말에게 주의를 돌렸다. "더 높이."
크레인 기사는 명령대로 말을 더 높이 올렸다. 땅에서부터 6미터, 9미터, 12미터 높이까지. 철학자들은 동물이 인간에 견줄 만한 감정을 느끼는지 알 수 없다고 했지만, 누구든 말의 눈에 어린 순수한 공포를 보았다면 그 사실을 의심하기 어려웠을 것이다.

224쪽:

"오늘 아침에 액튼 양이 거리에서 받은 경고장입니다." 내가 말했다. "밴월 씨도 잘 알고 있겠죠. 당신이 썼으니까요." 다들 너무 놀라 입도 벙긋하지 않았다. "시장님, 리틀모어 형사, 이 사람이 바로 우리가 찾던 범인입니다. 액튼 양은 사람들이 들어오기 바로 전에 공격 사건을 기억해냈습니다. 즉시 이 사람을 체포해주기를 요청합니다."
"네까짓 게 감히?" 밴월이 말했다.
"이게...... 이 사람 누구에요?" 밀드레드 액튼이 나를 가리키며 물었다. "어디서 온 사람이에요?"
"영거 박사." 맥클레런 시장이 말했다. "무고죄가 중죄라는 걸 모르나보군요. 어서 철회하시오. 액튼 양이 그렇게 말했다면 기억이 속인거요."

318쪽:

"다 끝났네." 휴겔이 힘없이 말했다. 그의 얼굴이 어두워지기 시작했다. "그 여자애는 정신병원에 보내야겠군."
"잠깐만요, 휴겔 씨. 이 얘기 좀 들어보세요." 리틀모어는 검시관에게 넥타이핀을 발견한 이야기를 해주었다.
휴겔은 내 말이 귀에 들어오지 않는 듯했다. "너무 사소해. 너무 늦었다고." 검시관은 씁쓸히 말했다. 그는 넌더리가 나는지 툴툴거렸다. "그 여자가 한 말을 그대로 믿었지 뭔가. 그 애를 정신병원에 보내야 해. 내 말 알아듣겠나?"
"검시관님께선 그 여자가 미쳤다고 생각하시나봐요."
검시관은 숨을 깊이 들이마셨다. "축하하네. 형사. 추리가 면도날처럼 날카롭군. 리버포드, 액튼 사건은 이제 종결이네. 시장에게 알려. 난 그 양반한테 입도 벙긋 안 할 테니까."

356쪽:

"도대체 뭐지?" 프로이트가 말했다.
"저 소리를 알겠군요." 융이 말했다. 그는 승리를 확신하는 듯한 눈빛을 하고 있었다. "전에도 저 소리를 들은 적이 있습니다. 박사님의 증거가 저기 있군요! 저게 바로 촉매를 통한 외면화입니다."
"뭐라고?"
"심령 속에 흐르는 기가 외부 사물을 통해 나타나는 현상이죠."
"융, 제발 그만하게." 프로이트가 말했다. "내가 듣기에는 총소리 같던데."
"잘못 아신 겁니다. 그럼 증명하기 위해서 다시 한 번 일으켜보죠. 지금 이 순간!"
이 놀라운 말을 융이 뱉어낸 순간, 신음 소리가 다시 시작되었다. 바로 이전과 똑같은 식으로 소리가 점점 참을 수 없을 만큼 커지더니, 엄청난 폭음을 내며 폭발했다.

499쪽:

노라는 이해했다. 그녀는 윗몸을 돌려 내게 등을 맡겼다. 의사에게 처음으로 진료를 받았던 바로 그 방이었다. 나는 소파에 등을 대고 누운 채 한 손을 뻗었다. 배를 움켜쥔 손이 아닌 깨끗한 손이었다. 나는 그 손으로 노라의 드레스 단추를 풀었다. 옷이 열리자 코르셋 끈을 풀어 작은 구멍들을 양쪽으로 벌렸다. 대각선으로 얼기설기 얽힌 끈 안쪽으로 노라의 우아한 어깨뼈가 드러났다. 아물어가고 있는 찢어진 상처들이 몇 개 보였다. 나는 하나를 만져보았다. 노라는 비명을 질렀지만 곧 소리를 죽였다.
"됐어요" 나는 소파에서 일어섰다. "그걸로 마무리됐습니다. 이제 경찰을 불러서 내가 치료를 받을 수 있게 해줘요. 그럴 수 있죠?"
노라는 멍한 채로 나를 바라보았다. "하지만 죽을 거라고 하셨잖아요."
"그럴 겁니다. 언젠가는. 하지만 벼룩에 뜯긴 이 정도 상처로는 어림도 없죠."

"살인의 해석"의 또 다른 원서 표지, Photo courtesy of Daum Book

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Billboard Hot 100 Chart 50th Anniversary

2008-11-19T00:06:27+09:00

- 빌보드 싱글 차트가 어느덧 50년이 되었다...

Photo courtesy of Billboard -

1958년 8월 4일 시작으로 50년 동안 팝 음악의 인기도 측정에 기준이 된 빌보드 차트. 어느덧 50년 세월을 보내고 현재까지 최고의 음악 차트로 자리 매김하고 있다. 음악의 역사와 함께한 빌보드 차트. 그동안 잊고 지내다가 오랜만에 들어 본 괜찮은 노래 몇 곡을 뽑아봤다.

Santana Featuring Rob Thomas - Smooth
최고 순위 : 1위-12주 동안(1999.10.23)

1999년 10월 산타나가 "Smooth"라는 곡으로 1위를 하기 정확히 30년 전, 그의 원년 밴드는 "Jingo"라는 제목의 싱글로 Hot 100 차트에 처음 등장했다. 이 싱글은 56위를 기록하며 순조롭게 데뷔하지 못했다. 그러나 당신이 그때로 거슬러 올라가 카를로스 산타나에게 그의 30년 경력에 가장 큰 히트를 칠 것이라고 이야기를 했었다면, 그가 당신의 말을 믿었으리라 생각하나? 아마도 아닐 것이다. Itaal Shur와 Matchbox Twenty의 Rob Thomas 공동으로 작사한 "Smooth"는 산타나의 폭발적인 호흥을 이끌어낸 앨범 "Supernatural"에 수록되어 있으며, 12주 동안 1위를 기록하며 근 10년간 최고의 라디오 청취 곡이다. 내용 더 보기

LeAnn Rimes - How Do I Live
최고 순위 : 2위(1997.12.13)

1996년 26위에 오른 "Blue" 이후, 리앤 라임즈의 두 번째 Hot 100 순위 곡. 지금까지 Hot 100 차트를 통틀어 최장기간 순위에 든 곡(1997년 6월부터 1988년 10월까지 68주 동안). 리앤 라임즈가 만으로 14살 때 출시한 이 곡은, 그녀의 다음번 출시된 2곡 보다 오랫동안 차트에 머물렀다. 내용 더 보기

Jewel - Foolish
최고 순위 : 2위(1997.4.19)

쥬엘의 데뷔 싱글인 "Who Will Save Your Soul" 곡이 11위로 깜짝 등장하고, "You Were Meant for Me"의 출시에 기름을 부어 1997년 4월 19일 빌보드 Hot 100 차트 2위를 이끌었다. (뒤따라 싱글 "Meant"의 B-Side 곡인 "Foolish Games" 가 출시되었다.) 이 곡은 65주 동안 차트에 머물렀다.

- 지금 다시 들어도 "How Do I Live"는 귀에 쏙 들어온다.

Photo courtesy of MySpace-LeAnn Rimes -

위에서 소개된 곡 외에도 오랜만에 들어서 좋았던 노래로는 Mariah Carey 의 2005년도 출시 곡인 "We Belong Together", 아름다운 발라드 듀엣곡인 Diana Ross & Lionel Richie 의 "Endless Love", 아카펠라 화음이 매력적인 Boyz II Men 의 "I'll Make Love To You" / "End Of The Road", 현재 솔로로 활동중인 스팅의 밴드시절인 The Police 의 "Every Breath You Take", Mariah Carey & Boyz II Men 의 감미록운 듀엣곡인 "One Sweet Day", 피아노 화음과 어쿠스틱 기타가 잘 조화된 Savage Garden 의 "Truly Madly Deeply", 다이아나비 추모곡인 Elton John 의 "Candle In The Wind 1997", 고음과 피아노 연주가 멋진 Alicia Keys 의 "No One" 등이 있다 :)

관련 사이트

Billboard Hot 100 Chart 50th Anniversary

Billboard Hot 100 All-Time Top Songs (10-01)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

내용으로 파일 찾기, nEKO'S Finder!

2008-10-08T01:43:20+09:00

nEKO'S Finder! 스크린 샷 - 검색 내용을 입력하고 Find! 클릭

───────────────────────────────────────────────

Finder.zip

nEKO'S Finder! 실행파일 다운로드

───────────────────────────────────────────────

프로그램 : nEKO'S Finder!
버 전 : 0.1 ( 2008.09.23 )
기본기능 : 특정 내용으로 파일 검색, INI 파일로 이전 검색 내용 / 경로 저장
개발언어 : C# (.NET Framework 2.0)
개발환경 : MS Visual Studio 2005
구동환경 : MS Windows XP / Vista (MS .NET Framework 2.0 이상)
추가 라이브러리 : INI API Legacy Class

───────────────────────────────────────────────

기본 설명

내용으로 파일을 찾기. 찾을 내용이 특정 경로의 특정 텍스트 파일에 들어 있다고 생각하는데 어느 파일인지 모를 때 사용합니다. 현재 해당경로(하위 폴더 제외)에 대해서만 탐색을 합니다.

소스 설명

Directory.GetFiles 함수로 검색 경로의 파일을 문자열 배열에 모두 담고, 반복문을 사용하여 해당 파일의 내용을 File.ReadAllText 함수로 검색 내용이 일치하는 파일의 존재 여부를 sContents.IndexOf 함수로 검사한다.
// 텍스트 검색 수행 bool bFind = false; string[] sfiles = Directory.GetFiles(Browser.SelectedPath, "*.*", SearchOption.TopDirectoryOnly); foreach(string s in sfiles) { string sContents = File.ReadAllText(s).ToLower(); int result = sContents.IndexOf(m_sFind.ToLower()); // 텍스트 검색 성공 if (result != -1) { bFind = true; listBox_Result.Items.Add(s); } }

FinderSolution.zip

: nEKO'S Finder! 솔루션 파일 다운로드

추후 고려사항

하위 폴더 까지 검색하는 기능을 옵션으로 제공(현재 지정된 폴더만 검색), 숨김 파일에 대한 검색 여부를 옵션으로 제공(현재 숨김 파일도 무조건 검색), 프로그레시브 바를 사용하여 검색시간을 출력(현재 파일 검색을 수행하는 동안 프로그램이 얼어 있음) 등

개발 후기 보기

more..

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

nEKO'S SyntaxHighlight Plug-In with Lua

2008-10-02T01:25:40+09:00

//------------------------------------------------------
// Desc: nEKO'S SyntaxHighlight 플러그인 테스트
//
// Auth: 2008.09. 외계고양이(815soju@gmail.com)
//------------------------------------------------------
#include <iostream>
using namespace std;

int main()
{
    // nEKO'S tHINK 방문 환영 출력
    cout << "Welcome to the nEKO'S tHINK\n";

    return (0);
}

SyntaxHighlight.zip

nEKO'S SyntaxHighlight 플러그인 다운로드

dp.SyntaxHighlighter 1.5.1 버전 적용
루아 5.1 신택스 하이라이트 추가

# 설 명
Textcube에 사용 가능한 코드 신택스 하이라이트 플러그인 입니다. 현재 지원하는 언어는 C++, C#, CSS, Delphi, Java, Java Script, PHP, Python, Ruby, Sql, VB, XML/HTML 그리고 Lua 입니다.

# 사용 방법
[ code ] [ /code ] 사이에( " [ "와 " code ", " code "와 " ] " 사이에 띄워쓰기 사용 않함 ) 출력할 코드를 넣어주면 자동으로 신택스 하이라이트가 적용됩니다. 기본값 [ code ] 는 C++코드를 신택스 하이라이트로 출력하며 [ code CShap ], [ code Java ], [ code lua ] 등 해당 언어에 대한 식별자를 지정하여 신택스 하이라이트를 적용시킬 수 있습니다.

언어	식별자
C++	`cpp`, `c`, `c++`
C#	`c#`, `c-sharp`, `csharp`
CSS	`css`
Delphi	`delphi`, `pascal`
Java	`java`
Java Script	`js`, `jscript`, `javascript`
PHP	`php`
Python	`py`, `python`
Ruby	`rb`, `ruby`, `rails`, `ror`
Sql	`sql`
VB	`vb`, `vb.net`
XML/HTML	`xml`, `html`, `xhtml`, `xslt`
Lua	`lua, l`

# 추가 기능
새 창에 출력, 클립보드로 복사, 인쇄 기능

# 추가 설명
nEKO'S SyntaxHighlight 플러그인은 겐도사마님이 제작한 CodeHighLight 를 기반으로 dp.SyntaxHighlighter 1.5.1 버전을 적용하고 루아 신택스 하이라이트를 추가하였습니다:)

--------------------------------------------------------
-- Note : nEKO'S SyntaxHighlight 플러그인 루아 테스트
--
-- Auth : 2008.09. 외계고양이(www.nekothink.com)
--------------------------------------------------------

function main()

    -- 루아도 문제 없다!!
    print( "No Problem Lua!!" )

end

main()

# 개발 후기 보기

more..

shBrushLua.zip

: 루아 신택스 하이라이트 원본코드 다운로드

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

"설득의 심리학 2"를 읽고

2008-09-17T10:59:05+09:00

"이런 장르의 책을 보면 어떠한 상황이 닥치든
사람의 마음먹기에 따라 달라진다는 생각이 든다."

───────────────────────────────────────────────

⊙ 제 목 : 설득의 심리학 2

⊙ 지은이 : 노아 J. 골드스타인, 로버트 치알디니,
스티브 J. 마틴(지음), 윤미나(옮김)
⊙ 장 르 : 경제경영
⊙ 펴낸 곳 : 21세기북스
⊙ 펴낸 날 : 2008년 7월 1일
⊙ Page : 298쪽
⊙ ISBN : 9788950914882

⊙ 평점 : ★★★★☆

───────────────────────────────────────────────

"사회적 증거의 법칙_다수의 행동이 '선'이다.
8월 중순 회사에서 Microsoft의 Visual Studio Team System 관련 세미나를 했다.
강연 중반 타 회사에서도 VSTS를 사용해서 개발 효율을 높였다는 통계를 보여줬는데,
동종 업계에서 사용한다고 하니 우리한테도 필요한 게 아닌가 하는 생각이 불현듯 들었다.
비록, 비싼 구매 비용 때문에 사회적 증거의 법칙이 단번에 허물어졌지만...

국내 현실과 다소 동떨어진 내용도 있지만,
설득에 실패하였을 때 대비사항과
잘못된 방식의 설득에 대한 문제점을 집어주는 게 무척 유쾌하다.

2002년도에 출간한 '설득의 심리학'이
1대 1, 개인에 대한 설득을 시작으로 점진적으로 다수에게 다가간다면,
2권에서는 다수에 대한 설득 방법에 대해서만 알려준다."

인상깊은 부분

78쪽: 도울 때는 조건 없이, 순수하게

... 동료든 고객이든 그냥 아는 사람이든, 다른 사람의 협조를 구할 때는 순수하고 완전하게 무조건적인 방식으로 먼저 도움을 주어야 한다. 이런 방식으로 접근하면, 상대방의 동의를 얻어낼 가능성이 커진다. 게다가 연약하기 짝이 없는 인센티브 시스템 대신 신뢰와 상호 이해를 바탕으로 한 굳건한 토대 위에서 협력 관계를 수립할 수도 있다. 이렇게 시작한 관계야말로 오래 지속된다. 만약 약속한 인센티브를 더 이상 제공할 수 없거나 상대방이 인센티브를 바라지 않는 상황이 되면, 그 즉시 당신이 세운 연약한 다리는 금이 가고 이내 무너지고 말 것이다.

96쪽: 한 걸음의 놀라운 마력

... 부담스러운 요청을 하기 2주일 전에 한 연구 조교가 다른 그룹의 주민들에게 접근했다. 그리고 창문 앞에 '안전운전자가 되어주세요!' 라고 쓰인, 비교적 눈에 잘 안 띄는 작은 표지판을 세워도 되겠냐고 물었다. 이것은 부담 없는 부탁이었기 때문에 거의 모든 주민들이 동의했다. 2주일 후 또 다른 조교가 같은 주민들에게 찾아가서, 완벽하게 손질된 잔디 위에 눈에 거슬리는 표지판을 세워도 되겠냐고 물었더니 훨씬 더 많은 사람들이 동의했다. 먼저 작은 요청을 한 것뿐이었는데, 어째서 훨씬 더 엄청난 부탁을 들어줄 확률이 높아졌을까? 연구자들은 이러한 방법을 '문간에 발 들여놓기' 기법이라고 부른다.

152쪽: 작은 약점과 큰 장점을 지닌 '완벽한 사람'

채용에 관한 연구 결과, 이력서에 긍정적인 참고사항만 나열한 지원자들은, 작은 약점이나 부족한 점을 먼저 밝히고 나서 긍정적인 점을 설명해나간 지원자보다 면접 기회가 더 적은 것으로 나타났다. ... 이 전략은 협상 테이블에도 적용할 수 있다. 예를 들어 사소하지만 취약한 분야가 있다면, 협상 파트너가 나중에 발견하게 내버려두는 것 보다 먼저 솔직히 밝히는 것이 좋다. 그렇게 하면 상대는 당신을 더 믿을 만한 사람으로 볼 것이다. ... 여기서 명심해야 할 것은 자진해서 털어놓는 약점이 비교적 사소한 것이어야 한다는 사실이다.

161쪽: 실수에 더 끌린다

한 그룹은 다른 소방관들이 결정을 잘못내려서 실제로 안 좋은 결과를 초래한 사례로 배웠다. 다른 그룹은 소방관들이 결정을 잘해서 나쁜 결과를 피할 수 있었던 사례를 가지고 배웠다. 연구팀의 분석 결과, 실패 사례로 훈련을 받은 소방관들이 성공 사례로 훈련을 받은 소방관들보다 판단력이 더 향상된 것으로 나타났다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

UI 모듈 리팩토링(Refactoring)

2008-09-13T03:29:58+09:00

최근 UI 출력에 사용되는 컨트롤 개선작업을 진행하면서, 리팩토링시 중요한 점이 무엇일까 하는 궁금증이 생겼습니다. 리팩토링은 일반적으로 완성된 로직 또는 모듈의 성능을 높이고 유지보수를 쉽게 하려고 내부 소스코드를 정리하는 작업을 일컫습니다. 성능과 유지보수를 위한 사용 편의성 중 어느 것이 더 중요하다고 구분할 수는 없습니다. 성능은 기본이고 개발 편의성을 최고로 끌어올려야 올바른 리팩토링 아닐까 생각합니다. 아무리 성능이 좋아도 인터페이스를 실제로 사용하는 개발자 입장에서 활용하기가 까다로우면 그 개발자에게 득이 되는 건 없기 때문입니다.

- Refactoring 서문

리팩토링은 소프트웨어 시스템의 원래 기능은 그대로 두면서 내부의 구조를 개선하는 것을 의미한다. 그것은 버그의 가능성을 최소화하기 위해서 코드를 깔끔하게 정리하는 엄정한 방법이다. 한마디로 리팩토링을 한다는 것은 이미 작성된 코드의 설계를 나중에 개선하는 것이다.

- 임백준의 소프트웨어 산책 중

리팩토링은 새로운 코드를 만들면서 미래를 향해 나아가는 프로그래밍이 아니라, 이미 존재하는 코드를 부수면서 과거로 뛰어드는 프로그래밍이다. 마치 미래의 전쟁에서 승리하기 위해서 과거로 뛰어든 영화 터미네이터의 주인공처럼 프로그래머는 과거로 돌아가서 미래를 코딩한다. 그 때 그들의 손에 들린 무기가 바로 리팩토링이다.

툴을 이용한 리팩토링도 가능합니다. 마소의 "리팩토링을 통한 프로젝트 망치기"를 보면 툴 지원 없이 섣불리 리팩토링하지 말라는 내용이 나옵니다. 리팩토링으로 프로그램의 버그가 증가한다면 오히려 해가 되겠지요. C++ 리팩토링 툴로는 Visual Studio .Net 2003 버전을 지원하는 Ideat Solutions의 Ref++ 가 있고(현재 Ideat Solutions는 해체되어 더 이상 새로운 버전을 출시하지 않습니다.), 개발자들이 많이 사용하는 Whole Tomato의 Visual Assist X 에도 리팩토링 기능이 따로 존재합니다. Visual Studio .Net 2005 버전에 무료로 사용 가능한 Refactor! 도 있습니다. Visual Assist에서 사용 가능한 리팩토링 기능으로는 이름 변경(Rename), 함수 추출(Extract Method), 필드 캡슐화(Encapsulate Field), 시그너처 변경(Change Signature), 소스파일로 함수 정의부 이동(Move Implementation to Source File), 멤버 함수 / 변수 추가(Add Member), 유사 멤버 함수 / 변수 추가(Add Similar Member), 함수 주석(Document Method), 함수 선언부 생성(Create Declaration), 함수 정의부 생성(Create Implementation) 등의 있습니다. 반복적인 작업을 수월하게 하는 데 도움이 됩니다.

Steam 프로젝트의 파일 입출력 모듈 리팩토링, Photo courtesy of Gamasutra, Valve

리팩토링에 있어서 최종 버전이라는 건 있을 수 없습니다. 보통 성공한 온라인 게임의 수명이 10년을 넘기게 되는데, 소스코드가 너무나 완벽해서 10년 넘게 리팩토링 할 내용이 없다는 것은 있을 수 없는 일입니다.

관련 사이트

임백준의 소프트웨어 산책 - 3장 리팩토링 이야기, 임백준
마이크로 소프트웨어 - 2003년 9월호 리팩토링을 통한 프로젝트 망치기(?), 이복연
Refactoring - 마틴 파울러

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

오픈소스 UML 툴 StarUML, 한방에 끝내는 VSTS

2008-09-12T23:17:55+09:00

과거와 미래보다 바로 지금, Now! 현재가 가장 중요하다는 생각으로, 차드 파울러의 실천사항 중 하나인 개발 일기 작성을 시작합니다. 개발 일기는 특별히 잘 써야겠다는 생각보다는 그날그날의 작업 내용 또는 앞으로 필요한 내용 위주로 짤막하게 적을 생각입니다.

UML 모델링 툴로 오픈소스 프로젝트인 StarUML 이 있습니다. 이전에 MS Visio 의 리버스 엔지니어링 기능으로 Visual Studio 솔루션에 포함된 클래스를 UML 다이얼 그램으로 뽑아 본 적이 있는데, 각 클래스별 상태 확인은 수월하나 클래스 간의 관계도를 확인하기가 어려웠습니다. StarUML 은 비록 오픈소스라 상용 UML 툴에 비해 기능이 부족할지 모르겠지만 클래스 간의 관계도를 한눈에 보기 쉽도록 잘 뽑아줍니다. 특정 프로젝트 소스를 분석할 때 도움이 되지 않을까 생각합니다. 한번 설치해서 사용해 봐야 할 유용한 툴입니다.

Visual Studio Team System에 대한 Microsoft 사의 세미나를 들었습니다. 형상관리와 관련하여 버그 리포트 확인과 수정한 소스에 대한 커밋을 동시에 진행하는 게 인상적이었습니다. 현재 저희 팀에서는 SVN 과 Mantis를 사용합니다. 사실 이슈 트래킹이 잘 안되어 있어서 이슈 추적이 어려운데, Trac 을 요긴하게 활용하면 괜찮을 듯합니다. 사내에서 Mantis를 사용하기 때문에 Trac 를 따로 또 사용하는 건 버그 관리 기능이 중복되는 문제가 있긴 합니다. 또한, 프로파일링이나 튜닝 등과 관련돼서 여러 가지 기능을 Visual Studio 하나로 다 처리할 수 있는데, 실제 활용도 측면에서 어느 정도 효율이 있는지는 직접 써보지 않고는 모를 일입니다. :)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

"사랑하지 않으면 떠나라!" 를 읽고

2008-09-12T23:17:41+09:00

"모니터 앞에 앉아 반복된 코드뭉치를 바라보는 개발자들에게
모니터 밖의 넓은 세상에 대해..."

───────────────────────────────────────────────

⊙ 제 목 : 사랑하지 않으면 떠나라!

⊙ 지은이 : 차드 파울러(지음), 송우일(옮김)
⊙ 장 르 : 컴퓨터관련 교양
⊙ 펴낸 곳 : 인사이트
⊙ 펴낸 날 : 2008년 1월 11일
⊙ Page : 295 쪽
⊙ ISBN : 9788991268357

⊙ 평점 : ★★★★☆

───────────────────────────────────────────────

"이 책은 다른 컴퓨터 교양서적과 마찮가지로
실무에 직접적인 도움을 제공하진 않는다.
하지만 꺼져가던 개발에 대한 열정은 다시 불타오르게 한다."

인상깊은 부분

48쪽: 그냥 앞서 갈 것인가, 위험까지 무릅쓸 것인가?

초기에 자바에 투자하면 다가오는 거대한 기술 추세에서 리더가 됐을 것이다. 물론 그렇게 했다면 여러분은 옳은 결정을 한 것이다. 또한 개인적으로 자바에 투자하기로 패를 던졌다면, 자바에 대한 개인적인 투자는 매우 수지 맞는 것이 됐을 것이다. 위험이 큰 만큼 보상도 큰 것이다.
...
BeOS는 위험하지만 매력적인 기술 투자였다. 그러나 BeOS에 경력을 투자하기로 한 개발자들에게는 구체적이고 장기적인 보상을 주지 못했다. 위험은 컸지만 보상은 없었다.

57쪽: 새 프로그래밍 언어를 배우라.

자바 또는 C# 프로그래머라면 강 타이핑(strong typing), 정적(static) 타이핑을 쓰지 않는 스몰토크나 루비를 배워 보라. 또는 오랫동안 객체지향 프로그래밍을 해왔다면 해스켈(Haskell)이나 스킴(Scheme)같은 함수형 언어(functional language)를 시도해 보라. 전문가가 될 필요는 없다. 새 프로그래밍 환경의 차이점을 정확히 느낄 만큼 코드를 충분히 하나하나 살펴보라. 그다지 낯설게 느껴지지 않는다면 엉뚱한 언어를 골랐거나 옛 사고방식을 새 언어에 적용하고 있는 것이다.

69쪽: 진정한 전문가가 되라.

닷넷 전문가라는 게 닷넷 이외에 아무것도 몰라도 된다는 이유가 되지 않는다. 닷넷 전문가라는 것은 닷넷과 관계가 있는 일에 권위가 있다는 의미다. IIS(Internet Information Server)가 죽어서 재시동해야 하는지 질문하면 "문제없어요"라고, 비주얼 스튜디오 닷넷(Visual Studio.NET)과 소스 제어 통합에 대해 물으면 "어떻게 하는지 보여줄게요."라고, 모호한 성능 문제 때문에 플러그를 뽑아버리겠다고 고객이 위협하면 "30분만 주세요."라고 대답할 수 있어야 한다.

79쪽: '가장 못하는 사람이 되는' 상황을 스스로 찾으라.

자신이 감탄하고 있고, 그 프로젝트 개발자들의 수준이 자신이 이루려는 '높은단계'에 있는 것처럼 보이는 오픈소스 프로젝트를 하나 고르라. 프로젝트의 할 일 목록이나 메일링 리스트 아카이브를 조사해 기능 구현이나 주요 버그 수정 사항을 골라 해당 코드를 짜라! 프로젝트 코드의 스타일을 흉내 내라. 게임을 하듯이 재밌게 하라. 자신의 설계와 코드를 프로젝트의 나머지 코드와 구별할 수 없게 만들면 원 개발자라도 누가 그 코드를 썼는지 기억할 수 없을 것이다. 그 다음에 자신의 작업에 만족하면 패치로 제출하라. 패치가 좋다면 프로젝트에 받아들여질 것이다.

82쪽: 사랑하지 않으면 떠나라!

바에서 귀가 먹먹해진 저녁을 보내고 집에 늦게 돌아와 프로그래밍 설명서가 있는 고퍼(Gopher) 사이트를 돌아다니다 보면 해가 뜨곤 했다. 해가 뜨면 눈을 좀 붙인 후 일어나 공부를 계속하다가 다시 연주하러 나갔다. 공부하는 도중에 좋아하는 컴퓨터 게임을 하면서 놀기도 하고 다시 고퍼를 가지고 빈둥거렸다. 결국 어떤 컴파일러든지 쓸 수 있게 됐다.
...
열정이 충만한 것처럼 한동안은 속일수 있겠지만 열정 부족은 자신과 자신의 일에 나쁜 결과를 가져올 것이다.

110쪽: 연습, 연습 또 연습

몸에 익히기 : ... 현대적인 프로그래밍 언어들은 대부분이 모든 영역에 대한 풍부하고 강력한 라이브러리를 제공하지만 소프트웨어 개발자는 작은 서브셋만 배우려는 경향이 있다. 결국 같은 코드를 비효율적으로 짠다. 개발자들이 이용할수 있는 도구 전체를 습득했다면 그렇지 않았을 것이다.
악보 읽기 : ... 기능을 고른 후 소프트웨어 소스코드를 다운로드하고 살펴보기 시작하라. 어디를 봐야 할 것인가? 어떤 요령으로 코드 중 주요 부분을 찾을 것인가? 출발점은 어디인가?
즉흥 연주 : ... 사고를 날카롭게 하고 즉흥 코딩 솜씨를 향상시킬 멋진 방법으로는 스스로 제한 조건(constraint)을 두고 연습하는 것이 있다. 간단한 프로그램을 골라 제한 조건을 두고 작성해 보라.

129쪽: 자동화 기술을 이용해 일자리를 찾아라.

평소에 되풀이하는 작업을 하나 고르고 그 작업에 대한 코드 생성 프로그램을 하나 짠다. 단순하게 시작한다. 재사용성에 대해서는 걱정하지 말라. 코드 생성 프로그램 때문에 시간을 절약할 수 있다고 확신하기만 하면 된다. 여러분이 만드는 추상화 수준을 높이는 방법에 관해 생각해 보라.

143쪽: 매일의 성과

간단한 목표를 세우고(일간, 주간 또는 자신이 할 수 있는 아무것이나) 이러한 성과를 추적하다 보면 자신의 행동이 근본적으로 바뀔 수 있다. 두드러진 성과가 무엇인지 찾을 때, 자신의 활동이 비즈니스 가치에 바탕을 두고 있는지 평가하여 우선순위를 정하는 과정을 자연스럽게 거치게 된다.적절한 빈도로 성과를 추적하면 확실히 정체되지 않을 수 있다. 매일 성과를 하나씩 내겠다고 마음먹었다면, 완벽하게 태스크를 마무리하는 데는 2주일이 채 걸리지 않을지도 모른다.

156쪽: 오늘은 얼마나 잘 할 수 있을까?

그렇다면 어떻게 해야 일과 중의 평범하고 자질구레한 일(아마 개발자들의 시간 중 80% 이상을 차지할 것이다)을 하면서도 창조력을 발휘하고 스스로에게 도전 의식을 불러일으킬 수 있을까? 지겨운 일을 완벽하게 하려고 노력해 보는 건 어떨까? 예를 들어 단위테스트를 싫어한다고 하자. 프로그래밍은 좋아하지만 자동화된 테스트 코드를 짜야만 하는 것은 성가시다. 테스트를 완벽하게 하려고 애써보는 것은 어떨까?

174쪽: 8시간 열중하기

시간의 가치가 떨어지면 일을 하기 위해 더 많은 시간이 필요하다. 로버트 마틴의 8시간 열중하기는 여러분에게 제한(constraint)을 두고 그 제한을 다루는 법을 알려준다. 여러분은 일하면서 다음과 같이 생각한다. '여덟 시간 밖에 없어! 자, 부지런히 일해야지!' 시작과 끝 시간에 엄격한 제한을 두면 자연히 시간을 더 효율적으로 조정한다. 그날 해야 할 업무를 우선순위에 따라 나열하고 한 번에 하나씩 해치우기 시작할 것이다.

178쪽: 실패하는 법을 배워라.

알게 되자마자 문제를 제기하라. ... 소프트웨어 개발과 테스트에서처럼 실수를 일찍 잡아내면 늦게 잡아내는 것보다 문제가 줄어든다.
책임을 지라. ... 혼자서 다 비난 받는 게 아니더라도 책임을 지고 나아가라. 목표는 가능한 빨리 이 시점을 지나가는 것이다.
해결책을 제시하라. 자신에게 해결책이 없으면 해결책을 찾기 위한 착수 계획을 제안하라. 구체적이고 예측할 수 있는 기간으로 말하라.
도움을 구하라. 문제에 대한 비난을 혼자서 받는다 하더라도 자존심 때문에 해결 과정에서 도움을 거절해 상황을 악화시키지 말라.

209쪽: 개발 일기를 쓰기 시작하라.

매일 조금씩 쓰면서 뭘 했는지 기록하고, 설계 결정에 대해 타당성을 증명하고 어려운 기술적 또는 전문적 결정을 자세히 조사하라. 자기 자신만 보는 것이라 하더라도 자신의 입장을 분명하게 표현할 수 있도록 작문의 품질과 능력 향상에 주의를 기울이라. 이따금 옛글을 다시 읽고 비평해 보라. 옛 글에서 좋았던 것과 나빴던 것을 바탕으로 새 글을 수정하라. 이러한 일기를 통해 글쓰기가 개선될 뿐만 아니라 자신이 내린 결정을 좀더 잘 이해하는 데 이용할 수 있다. 또한 과거에 어떤 일을 왜, 어떻게 했는지 다시 봐야할 필요가 있을 때 참조할 수도 있다.

249쪽: 주 중에 시간을 내 첨단기술을 연구하라.

최소한 매주 두 시간 정도 여유를 만들어새 기술을 조사하고 그 기술에 능숙해지도록 연습하기 시작한다. 이 새 기술들로 실무 작업을 해 본다. 간단한 애플리케이션을 만들라. 현재 기술 프로젝트에서 어려운 부분을 새 기술 버전으로 프로토타입을 만들어 둘 간의 차이가 무엇이고 새 기술로 무엇을 할 수 있는지 이해하라.

294쪽:

인도에서 깨달은 것이 하나 있다면, 미국인들은 인도인들이 빈곤 속에 불행하게 산다고 여기지만 그 인도인들이 평균적으로 미국인들보다 행복하다는 것이다. 나는 몹시 가난한 사람들을 만났다. 하지만 그 사람들은 작은 집에 살면서도 미국인들보다 단연 건강한 전망을 계발하고 있었다. 이 경험에서 나는 '지금 무슨 일을 하는지'나 '무엇을 가졌는지'가 중요하지 않다는 것을 진짜 배웠다. 그것은 어떻게 받아들이냐에 달려 있다. 그것은 내면의 문제이다. 만족스런 경력을 만들어 나가려면 항상 적극적으로 찾아야 하고 그것을 목적을 갖고 판단하고 결정해야 한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Bob Dylan - Knockin' on Heaven's Door

2008-09-12T23:17:22+09:00

- 포크록의 살아있는 전설 밥 딜런,

수많은 뮤지션들에게 사랑받는 밥 딜런의 "Knockin' on Heaven's Door",

Photo courtesy of RollingStone -

"Knockin' on Heaven's Door"는 1973년 영화 "관계의 종말 (Pat Garrett and Billy the Kid)"에 삽입된 곡으로, 영화는 성공하지 못하였지만 음악적으로 밥 딜런의 가치를 높여 주었다. 4 코드(G, D, Am7, C)로 구성되어 있으며 G - D - Am7 - Am7 / G - D - C - C 가 반복되는 패턴으로 노래가 진행된다. 빌보드 싱글차트(Billboard Hot 100) 12위를 기록하였으며, 2004년도에는 롤링스톤(RollingStone)지가 선정한 이 시대 최고의 500곡에 뽑혔다.

다른 뮤지션들이 부른 "Knockin' on Heaven's Door" 감상

more..

Like a Rolling Stone,
1965. 7. 25 Newport Folk Festival에서...

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.