C++을 익히는 데에 주로 사용되는 대부분의 책들은, 문법에 치중되어 있다. 심지어 The C++ Programming Language 마저 그렇다. 우선 이 책은 서점에서 검토해보고 주문한 책이 아니었다. 이 책을 고르며 생각한 이 책의 방향성은 좋은 코딩 좋은 습관처럼 코딩 규칙이나, 가이드 라인에 대한 책인줄 알았다. 실제로 부제목도 코딩 가이드라인에 대해 언급했고. 하지만 막상 읽어보니 코딩 규칙이나, 가이드 라인보다는 표현의 자유가 강하지만 그 만큼 복잡하고 잘못 사용될 여지가 많은 C++을 객체 지향적으로 잘 활용할 수 있는 방법에 대한 느낌이 더 강했다. 자바가 대세가 된지 한참 되었고, C#도 많이 성장했고, 클라이언트-서버 모델에서 웹으로 흐름이 옮겨간지도 꽤 오랜시간이 흘렀다. 하지만 ..
사실 나는 영화를 볼때 예고편이나, 영화에 대한 평가를 가급적이면 듣지 않으려고 한다. 첫째는 편견을 갖지 않기 위해서고, 둘째는 기대감을 갖지 않기 위해서다. 그렇지만 예외도 있는데, 내가 좋아하는 감독이나, 배우가 출연할 때에는 기대감을 갖고 보기도 한다. 이래 저래 예고편이나 관련 정보를 얻기도 하고. 책을 고를때에는 그와 반대로 최대한 많은 정보를 얻고 책을 선택한다. 잘못 선택한 책이 미치는 여파는 생각보다 크기 때문이다. 하지만 임백준씨는 나에게 너무 많은 영향을 주셨고, 임백준씨의 책에 너무 감명 받은 것들이 많은지라, 임백준씨의 책이라면 목차를 보지 않고도 바로 구입하곤 한다. 그리하여 목차도 모르고 받아본 이번 책은 프로그래밍과 상상의 연관관계인줄 알았거늘...!! 그간 기고하셨던 컬럼의..
나는 학창 시절 주입식 교육의 영향인지 뭔진 몰라도, 일본에 대한 반감을 갖고 있는 편이다. 일본 게임, 일본 만화를 많이 접하면서도 일본색이 지나친 것들에 대해선 다짜고짜 싫어해서 (논리적으로 설명하지 못하면서까지 싫어해서) 친구들과 소모적 논쟁도 많이 하곤했었으니...정도가 좀 심했다. 그럼에도 불구하고, 일본의 문화적 역량과, 마인드는 대단하다는 것을 여러가지 측면에서 깨닳게 된다. 린 소프트웨어 개발에서 극찬한바 있는 도요타식 마인드라던가, 실제 일본인들의 일처리 방법에 대해서 깨닳게 되는 장점이 굉장히 많았다. 내가 느낀 일본인들은 변화에 민감하진 않았다. 오히려 두려워 하는 느낌이라면 맞을까? 그 대신 현재 알고 있는 것에 대한 집중도나, 꼼꼼함은 상상 이상이었다. 이렇게 꼼꼼하니 일본 제품이..
사실 나는 메모를 자주 하긴하지만, 메모를 잘 활용한다 말하긴 힘들었었다. 나에게 있어 메모는 기록의 용도지, 기억의 용도는 아니었었다. 잊기 위해 기록한다? 쉬운 말이지만, 나에겐 너무나 혁신적이었다. 나의 기본 발상을 바꿔버릴 획기적인 발상이었던 것이다. 사실 나는 기록은 증빙의 수단으로 주로 사용해왔다. 최대한 많은 것을 외우길 바랬고, 외우려해왔다. 기록이란 최후의 수단에 불과했다. 왠지 기록에 의지하는 것이 내 자신의 기억력을 믿지 못하는거 같아 자존심이 상하기도 했다. 그런데 모든 사람은 기억력에 한계가 있다는 사실을 받아 들이고나니 너무나 편안해졌다. 잊기 위해 기록을 하고나니, 기억한 것들을 잊지 않기 위한 쏟는 노력을 하지 않아도 되었다. 지금 순간에 더 집중할 수 있게 되니, 일을 더 ..
소프트웨어 업계가 아직 젊다고 하지만, 벌써 50년 이상의 세월이 지나왔다. 그 세월 동안 다양한 경험과 통찰로 이루어진 결론들이 있었지만, 이 업계의 많은 사람들은 그 결론들을 일반화 시키는 것을 두려워하고, 인정하지 않으려 해온게 사실이다. (그리고 여전히 대부분 그렇다.) 사람 5명이 해오던 일을 10명이서 한다고, 수행 속도가 2배가 되는 것은 '절대' 아니다. 소프트웨어 업계는 생산업계의 방식을 그대로 적용해선 안된다. (물론 같이 통용될 수 있는 것들도 있지만!) 업계의 대부분 관리자들이 생각하는 더 좋은 능률을 내기 위한 방법들은 여전히 너무나 무지하다. 왜 같은 실수를 반복하는가? 폭포수 방식에 대한 폐해는 여실한데, 업계는 여전히 폭포수 방식을 선호한다. 이유는? 그것이 관리하기 편하기 ..
프로그래밍을 시작한지 어언 12년이 되었고, 프로그래머를 업으로 삼은게 엇그제 같은데 벌써 4년차가 되었다. 내 꿈은 프로그래밍을 시작했을 때도, 지금도 프로그래머다. 그래서 프로그래밍을 잘하기 위해 노력해왔고, 다양한 언어, 다양한 툴을 익히기 위해 노력했다. 내가 프로그래밍만 '잘'한다면 모든게 다 잘될거라고 생각했다. 실상은 그렇지가 않았다. '프로그래밍을 잘한다'는 것과 '일을 잘한다'는 것과는 꽤나 큰 차이가 있었다. 취미나, 해커 (크래커적인 의미가 아닌)로써가 아닌 프로그래밍을 업으로 삼는 사람이라면, 일을 함께 잘해야 한다. 논쟁 거리가 될만한 얘기가 될수도 있다는 생각이 들지만, 존 카맥에 대한 내 생각을 말하자면 그는 뛰어난 프로그래머일 뿐, 같이 일하기 좋은 프로그래머는 아니다라는 생..
일반적으로 네트웍 프로그램을 작성할때 대부분 소켓을 이용한다. 하지만 소켓을 사용할줄 안다는 것이 TCP/IP를 이해한다는 의미는 아니다. 대부분의 네트웍 프로그래머가 소켓이 왜 그렇게 처리 되고 있는지, 왜 그렇게 해야만 하는지에 대해서 모르는 실정이다. 이 책에선 좋은 네트웍 프로그램 (효율과, 안정성을 모두 보장하는) 을 만들기 위해선 어떠한 사항들을 신경써야 하는지 잘 정리해주고 있다. 윈속, 리눅스를 총 망라하는 데다가, 흔히 겪게 되는 네트웍 프로그래밍 실수에 대해서도 이야기 해주고 있으므로, 큰 도움이 될 서적이라 할 수 있다. 이 책에에서 다루는 내용을 간략하게 나열하자면 TIME_WAIT 상태에 대한 설명 이라던지, TCP/IP가 연결 닫기 정보를 통보하지 않는다는 점, 데이터 복사 효율..
천재들은 대부분 영재인 경우가 많더군요. 해당 분야를 일찍 접하고, 그와 동시에 재능을 발휘해오며 천재 소리를 듣게 되었기 때문일 것입니다. 대부분의 좋은 평가를 받는 프로그래머는 꼼꼼하고 성실해서 일을 잘 하거나, 경험이나 연륜에서 묻어 나오는 판단으로 좋은 결과를 내는 사람들이 대다수죠.하지만 천재들은 그런 경험 없이도 뛰어난 판단력과 통찰력을 갖고 있는 경우가 있습니다. 고등학교 때 만난 한 친구는 문제의 핵심을 파악하고, 그 문제점을 해결하는 방법을 찾는 능력이 매우 뛰어나, 제가 생각하지 못한 부분까지 생각한 능력을 보여주곤 했습니다. 그 친구는 3개월밖에 안했고, 나는 몇년이나 했는데...나도 열심히 해왔고, 그 생각 때문에 괴로웠고, 이 길이 내길이 아닌가보다 내 자신이 부족한 점만 생각나 ..
- Total
- Today
- Yesterday
- SDL
- RoR
- 바로가기 프로그램
- 리버스 엔지니어링
- NDC2013
- 게임데브포에버
- 디자인 패턴
- 디버깅
- svn
- ruby
- 조엘 온 소프트웨어
- ftp
- perfmon
- TDD
- Ruby on Rails
- 게임개발포에버
- 좋은 프로그래머
- Rails
- 엘키
- EzShortcut
- 멀티스레드
- 루비
- EasyExec
- MS-SQL
- c언어
- 루비 온 레일즈
- TraceRoute
- 임백준
- SQLite Spy
- CppSQLite
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
31 |