|
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
 다들 추석을 잘 보내셨나요? 인사가 너무 빠른 감이 없잖아 있네요 ㅎㅎ 부산 가기 전에 글 쓰고 간다는게 잠을 너무 오래 자버려서 못 썼습니다. ㅋ 2008년도 Microsoft MVP에 다시 선정되었습니다. 분야는 똑같이 Visual C++이구요. ㅎㅎ 질답 개수가 너무 적어서 긴장했는데 재수좋게 붙었네요. 3,5,7년도 MVP를 했었는데 갱신은 첨으로 해봤습니다. 풉. ㅋㅋ 앞으로 더 좋은 정보만 엄선하여 올리도록 노력하겠습니다. ^^ P.S.) MVP 지원하시고 싶으신 분들은 아래 정보를 참고하세요. http://www.devpia.com/microsoft/mvp/mvpRecruit.aspx |
|
신입 개발자를 위한 조언 코드 리딩(reading)의 중요성 신영진, codewiz@gmail.com, http://www.jiniya.net 내가 컴퓨터 공학과 교과 과정에서 느끼는 가장 큰 안타까움은 코드 리딩의 중요성을 누구도 가르치지 않는다는 점이다. 그래서 컴퓨터 공학과를 졸업하고도 코드 리딩이 무엇인지, 그것이 어떻게 도움이 되는지를 모르는 웃지 못할 일들이 벌어진다. 이는 영문학을 전공한 학생이 영어 소설 한번 읽어보지 않고 졸업한 것과 다를 바 없는 상황이다. 왜 이런 악몽 같은 일이 벌어졌을까? 바로 베끼기 때문이다. 수업 과제로 나오는 프로그래밍 과제를 베끼지 않게 하기 위해서 남의 코드를 읽거나 서로 보여주는 것이 나쁘다고 학생들에게 주입시킨 결과라고 할 수 있다. 정말 안타까운 일이 아닐 수 없다. 예전에 “성공 시대”라는 TV 프로에 안철수씨가 나온 적이 있다. 그 때 안철수씨가 바둑을 배운 과정이 짤막하게 소개되었다. 우리는 바둑을 처음 배울 때 으레 화점에 돌을 놓는 것에서 시작한다. 하지만 안철수씨는 이와는 달리 바둑은 두지 않고, 바둑 관련 서적만을 열심히 읽었다고 한다. 그렇게 몇 십 권의 바둑 서적을 독파하고 나서야 처음으로 바둑을 두었는데, 신기한 사실은 처음 바둑을 둔 그의 실력이 아마추어로는 상당한 수준이었다는 점이다. 책을 읽으면서 실전의 다양한 경우에 대한 사전 경험을 했던 것이다. 코드를 작성하는 것도 이와 별반 다를 것이 없다. 좋은 코드를 읽는다는 것은 바둑 책을 읽는 것과 같다. 윈도우 개발자를 꿈꾼다면 완성된 윈도우 프로그램 소스를 분석해 보도록 하자. 어떤 책에서 배울 수 있는 것 보다 더 값진 경험을 하게 될 것이다. 이렇듯 좋은 코드를 작성하기 위함이 코드를 읽어야 하는 첫 번째 이유가 된다. 우리는 많은 경우에 남이 작성한 소스를 수정하는 일을 한다. 처음부터 완전히 새로 무엇을 만드는 경우는 흔치 않다. 이미 만들어진 소스의 버그를 수정하거나 새로운 기능을 추가하거나 하는 작업이 대부분이다. 이런 경우에 남의 소스를 읽어본 적이 없는 사람은 굉장히 당황한다. 자신의 생각 외에는 읽는 방법을 모르기 때문이다. 심지어는 다른 인덴트 방식, 다른 네이밍 방식 때문에 소스가 눈에 들어오지 않는 경우도 있다. 이는 코드 리딩을 충분히 하지 않은 탓이다. 코드 리딩을 많이 해본 개발자라면 자신의 스타일과 다른 코드도 별 무리 없이 읽고 그 뜻을 이해할 수 있다. 과거 그러한 패턴의 코드를 읽어본 경험이 많이 때문이다. 이와 같이 이미 만들어진 소스를 분석하는 작업을 쉽게 하기 위함이 코드를 읽어야 하는 두 번째 이유다. 몇 해전 작성한 코드를 지금 한번 다시 만들어 보자. 그리고 새로운 코드를 몇 해전에 작성한 코드와 비교해 보자. 아마 기교적인 부분은 상당히 바뀌었겠지만 큰 흐름은 별로 바뀌지 않았을 것이다. 그래프 컨트롤을 새로 만들었다고 생각한다면 DC를 조작하고 점을 나열해서 그리는 것과 같은 테크닉은 발전했을 지라도 그래프의 각 요소를 C++의 클래스화 시키는 구조나 그래프의 점들을 저장하는 구조, 좌표를 변환하는 체계 등은 변하지 않는다는 말이다. 쉽게 바뀌지 않는 이유는 그것이 그 사람의 생각의 틀이고, 그 사람의 사고 방식이기 때문이다. 보통 성인이 되면 성격과 사고 방식은 굳어져서 쉽게 바뀌지 않는다. 남의 코드를 읽지 않는다면 이러한 자신의 틀 속에서 빠져 나올 수가 없다. 심지어는 그것이 늘 최선의 방법이라고 생각하는 우를 범할 수도 있다. 이런 자신의 도그마(dogma)를 깨는 가장 좋은 방법이 코드 리딩이다. 자신과 동일한 분야의 다른 소스를 봄으로써 다른 사람의 사고 방식, 생각의 구조, 논리의 패러다임을 배울 수 있다. 자신의 생각의 한계를 깨고 좀 더 유연한 사고를 가지기 위함이 코드 리딩의 세 번째 이유다. 코드 리딩이 가지는 이런 이점에 비해서 학교에서 지적하는 베끼기란 아주 사소한 부작용에 지나지 않음을 알 수 있다. 말 그대로 빈대 잡으려다 초가 삼간 태우는 형국이 아닐 수 없다. 코드를 좀 더 넓은 관점에서 바라볼 필요가 있다. 논어, 맹자, 중용, 대학, 시경, 서경, 주역에 이르는 사서삼경을 우리는 고전이라 부른다. 그리고 그것을 선대 학자들이 우리에게 남겨준 위대한 선물로 생각한다. 그것을 읽는 것을 누구도 부끄럽게 여기지 않는다. 코드는 이와 같이 앞서간 선배 개발자들이 우리에게 남겨준 엄청난 문화유산이다. 우리는 그것을 읽고, 갈고 닦아서 더 나은 것을 만드는 밑거름으로 사용해야 한다. 그러한 것을 버리고 굳이 돌도끼부터 새로 시작할 필요는 없는 것이다. |
 주말에 읽으려고 레이몬드 첸의 윈도우 개발 282 스토리를 구매했다. 지난 번에 포스팅 했듯이 정말 읽고 싶어던 책이었다. 원서를 사고 싶었으나 가격 부담으로 번역서를 샀다. 그런데 이것은 정말 최악의 선택이었다. 책을 읽는 내내 고문서를 해석하기 위한 고고학자가 된 듯한 느낌이 들었다. 문장 하나하나 속에 들어있는 어색한 단어와 과도하게 한글화된 단어들은 나의 독서를 엄청나게 방해했다. 그나마도 좀 읽을만하다 싶으면 어김없이 튀어나오는 프로그래밍 내용에 대한 오역이 나를 괴롭혔다. 과연 정말 역자가 윈도우 프로그래밍을 알기는 할까? 라는 의문이 드는 내용들이 한 둘이 아니였다. 또한 구글에서 한번만 찾아봐도 나오는 각종 용어에 대한 잘못된 번역도 역자의 컴퓨터 공학적인 지식을 의심하게 만들었다. 한번 눈밖에 나면 계속 눈밖에 난다고, 한번 그런 생각이 들자 그 다음 부터는 정상적인 문장들 조차도 머릿속으로 들어오지 않았다. 절반정도 밖에 읽지 않았지만, 결국 다시 원서를 사기로 맘을 먹었다. 아래는 그 짧은 독서 시간 동안 발견한 잘못됐거나 어색하거나 이상하거나 한 내용에 대한 아주 일부분이다. 한번 시작해 보자. p27 윈도우 95 베타 테스트 도중에 사람들이 시스템 속성 페이지지를 실행한 후, '메모리 부족'에 대해 불평을 했다. 뒤쪽 내용을 쭉 읽으면 메모리 부족이랑 별 관계가 없는 내용이라는 것을 알 수 있다. 메모리 부족이란 윈도우 95가 많은 메모리를 사용해서 시스템이 느릴 때나 하는 말이다. 그런데 이 내용은 자신이 8메가 메모리를 가지고 있는데, 화면에 7메가라고 표시된다는 것에 관한 내용이다. 원문은 missing memory다. 메모리 부족이 아니라 사라진 메모리인 것이다. p28 단일화 메모리 구조 unified memory architecture를 번역해 둔 것이다. UMA란 비디오 카드랑 메인 메모리를 같이 공유해서 사용하는 시스템을 말한다. 보통은 통합 메모리 구조로 불린다. p31 당신의 백만분의 일 확률의 버그는 매년 윈도우 7만 벌 수입만큼의 비용을 회사에 가중시킨다. 당신의 자체가 어색하다. 7만 벌 수입만큼의를 한번에 이해할 수 있을까? 이건 7만 카피를 번역해둔 것이다. 백만분의 일의 확률로 발생하는 버그는 매년 7만 카피의 윈도우가 벌어들이는 수입과 맞먹는다. 정도가 좀 더 이해하기 쉬운 문장일 것이다. 카피를 벌로 번역하는 것은 정말 ㅠㅠ p.42 실제로 어떤 특별한 처리를 하면 오류가 발생되며, 창 관리자가 마샬링을 해준다. 원래 원문은 두 문장으로 쪼개진 것이다. 번역하면서 이를 되며로 연결을 시켰다. 결과적으로 엉뚱한 문장이 되었다. 특별한 처리를 하면 창 관리자가 마샬링을 해준다는 의미로 읽히기 때문이다. 원문의 의미는 특별한 처리를 하면 오류가 발생한다. 왜냐하면 창 관리자가 마샬링을 해주기 때문이다. 정도다. 물론 원문엔 왜냐하면은 없다. p86 수평 메뉴와 팝업 메뉴를 둘 다 추적하는 것이 귀찮을 수도 있다. It can be cumbersome keeping track of both the horizontal menu and the pop-up menu. 가 원문이다. 당췌 뭘 추적한다는 건지. ㅠㅠ 문맥상으로 해석하면 "수평 메뉴와 팝업 메뉴를 둘 다 관리하는 것은 귀찮다." 정도다. 여기서 keep track of는 리소스 제어용 변수 두 개를 관리하는 것을 말한다. HMENU가 두 개면 각각을 해제해야 하기 때문에 귀찮다는 의미다. p87 타이머가 점화되면 자신을 InvalidateRect에 보내고 타이머를 죽인다. 점화되면 자신을 보내고. 정말 가관이다. 이쯤까지 읽으면 이제 원문이 추론될 지경이 이른다. When the timer fires, it does an InvalidateRect of itself and kills the timer가 원문이다. 자신을 InvalidateRect에 보낸다는 건 정말 어처구니 없다. "타이머가 발생하면 InvalidateRect를 수행하고 타이머를 죽인다" 정도로 해석할 수 있다. of itself는 자기 자신을 보낸다는 의미가 아니라 자신에 대한 InvalidateRect를 호출한다는 의미다. 점화되면 또한 정말 어처구니 없다. p97 정적 컨트롤의 색상을 개인화하기 위해 DC 브러시를 사용해보자. Let's use the DC brush to customize the colors of a static control. static 컨트롤의 색상을 변경하기 위해서 DC 브러시를 사용해보자. 정적은 완전 잘못됐고, 개인화는 어색하다. 과도했던 한글화 화면 낭독기screen reader, 은유metaphor, Z 순서z-order, 서술자descriptor, 선택자selector, 서술자 테이블descriptor table, 자원resource, 종속물dependencies, 가져오기import 어딘지는 기억나지 않지만 이름 분해name resolution도 있었다. 네트워크에서 이름을 찾는 과정에서 나오는 name resolution을 이름 분해라고 해석한 것이다. 정말 당황 스럽다. 컴퓨터 번역서는 정말 최악이던 시절이 있었다. 그러나 요즘은 정말 많이 나아졌다. 번역을 잘하시는 분들이 좋은 책들을 많이 번역해 주셨고, 그나마도 최근에는 개발자들이 번역하는 사례가 늘면서 오역이 좀 사라지는 추세기 때문이다. 이제는 번역서 믿고 사도 되겠지하고 23000원 아껴볼라고 번역서를 지른 나에게 일침을 놓는 엄청난 책이었다. 책 내용은 훌륭하다. 대부분의 소재가 그의 블로그에 올라온 것들이다. 그런데 각색된 것이 많이 있고, 새로 다듬어진 것도 많이 있기 때문에 한권쯤 책으로 꼭 소장하라고 권하고 싶다. 윈도우 개발자가 아니라면 굳이 볼 필요는 없다고 생각된다. 물론 윈도우 개발자가 아니라도 도움되는 내용이 많지만 상당 부분이 윈도우 개발과 관련있는 내용이다. 윈도우 개발의 보다 깊은 곳을 느끼고 싶다면 꼭 사서 읽어 보자. 43000원은 결코 아까운 금액이 아니다. 영어 공부도 할 겸 꼭 원서를 사보자. 끝으로 번역서에 한 가지 더 불만이 있다면 종이 질이다. 뺀질뺀질하게 코팅된 용지를 사용했는데 이거 엄청 무겁다. 두깨는 얼마 되지 않는데 들고 읽기가 상당히 거시기 하다. 특히 밤에 읽으면 난반사가 심해서 눈이 엄청 아프다. 칼라도 아닌것이 왤케 비싼 용지를 써서 고통스럽게 만드는지 모르겠다. |
|
일전에 사이냅 소프트 문제에 관해서 포스팅 했었습니다. 그 때 문제 답을 보내곤 잊고 있었는데, 회신도 없고 어떻게 진행되는지 전혀 연락이 없더군요. 그러다 어제 새벽녂에 마소 원고를 쓰다 궁금해서 다시 사이냅 소프트 홈페이지에 들어가 봤습니다. 떡하니 Hall Of Fame 코너가 생겼더군요. 쭈욱 내리는데 보이지않는 이름 순간 당황했습니다. Ctrl + F를 해도 나오지 않더군요. 기념품 하나에 목메달고 열심히 풀었는데 ... 허탈했습니다... 그러다 불현듯 스치는 생각이 있더군요. 저는 처음에 답을 하나씩만 출력해서 보냈습니다. 답이 여러개 존재하는데 하나만 출력했으니 틀렸다고 할 수도 있잖아요. 그래서 다시 답을 다 출력하도록 수정한 다음 새로 메일을 보냈습니다. 오늘 기쁘게도 회신이 왔습니다. 그런데 원인은 당황스럽게도 스팸 필터 때문이었답니다. 어찌됐든 공짜 기념품을 받게 되서 기분은 좋네요. 클래식라디오디지털시계가 선물로 배송된답니다. 라디오를 잘 듣지 않아서 어떤 용도로 쓸 수 있을진 모르겠지만... 알람 기능이 된다면 유용하게 쓸 수도 있을것 같네요. ^^ 이 기회에 GMP나 다시 들을까하는 생각이 ㅋㅋ  참고로 정답이 궁금하신 분들을 위해서 간단히 공개하겠습니다. 첫 번째 답은 205486422643, 두 번째 답은 1211209, 세번째 답은 average, badform 입니다. 그리고 마지막 답은 아래 그림과 같습니다. result.txt는 모든 답을 다 기록해둔 파일입니다.  졸지에 이상한 사람이 되버렸네요. 아래 댓글을 달아주신 신규하, grail님 말씀대로 모든 문제에 답이 있습니다. 그런데 정말 이상하군요. 제가 원래 캡쳐해서 보낸 시스템은 위에 보시다시피 Vista입니다. 지금 회사 들어와서 댓글을 보고 이상해서 새로 실행을 시켜 보았습니다. 허걱 ... 그런데 모든 문제의 답이 나오는 군요. 컥... ㅠㅠ 노트북에서 캡쳐한 화면과 소스 입니다. 참고로 소스는 처음 보낼때 캡쳐했던 소스입니다. 답을 한 가지만 구하는 소스죠. 내일 집에 가서 새로 해보고 결과를 다시 올리도록 하겠습니다. 그나저나 정말 이상하군요. 먼가에 홀린듯하네요. ㅠㅠ 참고로 소스는 걍 답만 구하려고 짠거라 delete도 없고 중복된 내용도 많고 그렇습니다. more..  방금 집에 와서야 무엇이 문제였는지 알아냈습니다. 제가 처음 문제를 풀 때 받았던 파일이 나중에 변경된 것 같습니다. 처음 문제를 풀었던 시간은 제가 포스팅을 했던 10일 새벽이었습니다. 위에 vista에서 캡쳐한 화면을 보면 답없음이 나온 두 줄이 아래와 같습니다. MANET + MANTISSE + MIRO + MONET + RENOIR = ARTISTS그런데 제가 어제 회사에서 돌릴 때 새로 받은 파일은 두 줄이 아래와 같습니다. MANET + MATISSE + MIRO + MONET + RENOIR = ARTISTS아직 눈치를 못 채셨을 수도 있습니다. 저도 디버깅을 하다가 알아냈으니까요 ㅠㅠ MANTISSE가 MATISSE로 ORAGNE가 ORANGE로 변경된 것입니다. |
 지난 번에 소개했던 퍼즐 메이커 입니다. 그림 파일을 입력하면 김태희 퍼즐과 같은 퍼즐 게임을 만들어 줍니다. "게임 바로 시작 하기" 옵션을 적용하면 게임 시작시에 바로 섞여서 시작합니다.  김태희 퍼즐 이탄입니다. 사진보면 퍼즐을 풀고 싶은 마음이 마구마구 샘솟지 않나요? ㅎㅎ 사진은 네이버 검색에서 퍼온 것 입니다. 자기 사진이나 친구 사진으로 만들어서 풀어보라고 해보는 것도 재밌을 것 같네요. 시간이 된다면 다음에 게임적인 요소가 좀 더 가미된 버전을 올리도록 하겠습니다. 게임을 즐기고 싶으신 분들은 아래 파일을 다운로드 받으시면 됩니다. puzmak.zip은 퍼즐 메이커 실행 파일입니다. p1.zip은 제 사진으로 만든 퍼즐 게임이고, p2.zip은 김태희 퍼즐 이탄입니다. |
result.txt
p2.zip