박피디의 게임 아키텍트 블로그 http://parkpd.egloos.com 본 내용은 게임 개발 내용과는 별 상관 없을 수도 있습니다~ ko Fri, 20 Nov 2009 15:33:51 GMT Egloos 박피디의 게임 아키텍트 블로그 http://md.egloos.com/img/samplelogo2.gif http://parkpd.egloos.com 80 80 본 내용은 게임 개발 내용과는 별 상관 없을 수도 있습니다~ <![CDATA[ PMD Copy/Paste Detector(CPD) 를 써 보자. ]]> http://parkpd.egloos.com/1969980 http://parkpd.egloos.com/1969980 Copy/Paste Detector 을 써 봤는데 중복 코드(copy & paste code) 를 잘 잡아주네요. :)
PMD 를 받은 후 압축 풀고, bin 폴더의 cpdgui.bat 를 실행하면 다음과 같은 화면이 나옵니다.(단 자바를 먼저 설치해야 합니다)
화면은 보면 알겠지만, 몇 줄까지 중복될 때 중복코드로 처리할 것인지를 정할 수 있습니다.
cmd 로 실행해 보면 export 형식도 text, csv, xml 등을 선택할 수 있고
ruleset 을 지정하면, unusedcode 를 찾아주는 등의 작업도 할 수 있는 거 같습니다.



아래와 같은 병신 코드로 테스트 해 보면...

view plaincopy to clipboardprint?
  1. int Test()   
  2. {   
  3.     if (rand())   
  4.     {   
  5.         return 1;   
  6.     }   
  7.     else  
  8.     {   
  9.         return 0;   
  10.     }   
  11. }   
  12.   
  13. int Test1()   
  14. {   
  15.     if (rand())   
  16.     {   
  17.         return 1;   
  18.     }   
  19.     else  
  20.     {   
  21.         return 0;   
  22.     }   
  23. }   
  24.   
  25. int _tmain(int argc, _TCHAR* argv[]) {   
  26.     Test();   
  27.     Test1();   
  28.   
  29.     return 0;   
  30. } 
아래와 같이 중복 코드를 찾아줍니다.
Found a 13 line (22 tokens) duplication in the following files: 

Starting at line 7 of E:\work\test\Test3\Test3.cpp

Starting at line 19 of E:\work\test\Test3\Test3.cpp



int Test1()

{

	if (rand())

	{

		return 1;

	}

	else

	{

		return 0;

	}

}



int _tmain(int argc, _TCHAR* argv[])
CI 에 붙여서 쓴다던지, 여러 용도로 쓸 수 있겠네요.


tag : , , , ,  ]]> 개발 이야기 CopyPaste CPD 중복코드 프로그래밍 만악의근원 http://parkpd.egloos.com/1969980#comments Fri, 20 Nov 2009 14:35:45 GMT 박PD <![CDATA[ GDC2008 자료 - 계속 업데이트 됩니다. ]]> http://parkpd.egloos.com/1969497 http://parkpd.egloos.com/1969497 ?GDC08 에 다녀온 후 [http]위키를 통해서 몇 분이서 모은 발표자료들입니다.
한참 잊고 있었는데, 지금 다시 자료를 찾아보니 그 당시 공개 안 되어 있던 자료가 꽤 많이 웹에 공개되어 있네요.
지금 봐도 괜찮은 자료들도 많군요.
다른 좋은 자료도 있으면, [http]AnD 위키 나 댓글로 알려주세요.
틈나는 대로 업데이트 합니다. :)

[http]전체 강연 목록 #

자료 있는 것들 #

강연 후기 #

all2one: [http]셋째날, [http]넷째 날, [http]마지막 날

관련 페이지 #

[http]Top GDC Tutorial Picks
[http]4Gamers.net의 GDC관련 리뷰입니다.
[http]That was the news – Week 8, 2008: Unconvincing GDC governed by two main themes: flux and fear

강연 자료들이 올라올 만한 곳들 #

[https]GDC 2008 Proceedings
-. 하단의 'Only where Session includes download notes'를 Check하고 'Session Search'를 누를 것.
-. 보통 GDC 종료 후, 3~4개월까지 계속 추가됨.
-. 강연자의 Blog나 Homepage에 먼저 게재되는 경우가 많음.
[http]GDC Radio
[http]어느 MS 개발자의 GDC 강연 노트
[http]Bungie의 발표 자료(주로 HALO 3)
[http]Microsoft Game Studio User Research
[http]Intel Graphics
[http]This Is Game
[http]GameSpot
[http]Game Watch
[http]4gamer.net
[http]Google Video & Youtube
[http]Gametrailers.com
[http]Gamevideos.com
[http]Valve

tag : , ,  ]]> 개발 이야기 GDC GDC08 강연 http://parkpd.egloos.com/1969497#comments Wed, 18 Nov 2009 22:43:48 GMT 박PD <![CDATA[ More Joel On Software - 조엘 온 소프트웨어를 넘어서 ]]> http://parkpd.egloos.com/1969211 http://parkpd.egloos.com/1969211 책이 나오고 나서 한 번, 그래서 두 번을 읽었지만 전혀 지루하지 않았다.
(책 뒷 표지에 보면 내가 쓴 짧은 베타리뷰어 서평을 찾을 수 있다.)
HARD CODE 저자인 에릭도 그렇지만, 마이크로소프트 출신들은 자신들을 '실용주의자' 라고 생각하는 듯 하다.
아니면, 애자일이니 폭포수니, 웹2.0 이니 하는 사람들을 보면서
'현실은 잘 모르는 애들 같으니. 마이크로소프트 제품 정도 되어야 제대로 소프트웨어를 만들어 봤다고 얘기할 수 있지' 라는 자신감(또는 약간의 오만함) 이 있다던가.
하지만, 덕분에 책 내용은 시원시원하다.
적당히 남들 눈치보느라 어중간하게 쓰지 않고, 조엘이 맞다고 생각하는 바를 아주 자신있게 써 놓은 점이 좋다.

다른 것들도 다 좋았지만, 그 중에서도
자신이 이미 서비스 중인 게임이나 2.0 을 준비하고 있는 소프트웨어 개발팀에 있다면,
[http]열둘. 밀리미터 싸움 A Game of Inches
[http]스물아홉. 단순함 Simplicity 를
Coding Convention 이 왜 필요한지, 헝가리안 표기법이 왜 좋은 것인지 잘 모르겠다면
[http]스물 셋. 틀린 코드를 틀리게 보이도록 만들기 Making Wrong Code Look Wrong
를 꼭 읽어보자.

링크에 있는 원문을 읽어보는 것도 좋겠지만,
돈 아깝지 않게 번역서가 잘 나왔으니 번역서을 사 보는 게 훨씬 시간, 노력을 아낄 수 있는 방법이다.

첫째마당 사람다루기 Managing People
[http]하나. 첫 번째 BillG검토회, My First BillG Review
[http]둘. 뛰어난 개발자를 찾아서 Finding Great Developers
[http]셋. 개발자를 대하는 실전 지침서 A Field Guide to Developers
[http]넷. 세 가지 관리방법(개요) Three Management Methods (Introduction)
[http]다섯. 명령과 통제 관리방법 The Command and Control Management Method
[http]여섯. ECON 101관리방법 The Econ 101 Management Method
[http]일곱. 일체감 관리방법 The Identity Management Method
[http]일곱 반. 명령과 무력정복, 그리고 돌덩어리들 Command and Conquer and the Herd of Coconuts

둘째마당 미래 프로그래머들에게 드리는 조언 Advice to Potential Programmers
[http]여덟. 자바만 가르치는 위험한 대학 The Perils of JavaSchools
[http]아홉. 예일대학 강연 Talk at Yale 1/3
[http]아홉. 예일대학 강연 Talk at Yale 2/3
[http]아홉. 예일대학 강연 Talk at Yale 3/3
[http]열. 전산학과 학부생에게 건네는 충고 Advice for Computer Science College Students

셋째마당 디자인 충격 The Impact of Design
[http]열하나. 폰트 스무딩, 안티 알리아싱, 서브픽셀 렌더링 Font Smoothing, Anti-Aliasing, and Subpixel Rendering
[http]열둘. 밀리미터 싸움 A Game of Inches
[http]열셋. 큰 그림 The Big Picture
[http]엘넷. 선택=골치 Choices = Headaches
[http]열다섯. 사용성이 다는 아니죠 It’s Not Just Usability
[http]열여섯. 커뮤니티 소프트웨어 만들기 Building Communities with Software

넷째마당 큰 프로젝트 관리하기 Managing Large Projects
[http]열일곱. 화성인 헤드폰 Martian Headsets
[http]MS 오피스 파일 형식은 왜 이렇게 복잡할까요? (더하기 피해 갈 방법) Why Are the Microsoft Office File Formats So Complicated? (And Some Workarounds)
[http]열아홉. 호랑이를 잡으려면 호랑이 굴에 들어가야지 Where There’s Muck, There’s Brass
[http]열아홉 반. 우주인 아키텍트의 역습 Architecture astronauts take over

다섯째마당 프로그래밍 조언 Programming Advice
[http]스물. 증거 기반 일정 세우기 Evidence-Based Scheduling
[http]스물하나. 전략 서신 Strategy Letter VI
[http]스물 둘. 여러분 프로그래밍 언어는 이런거 됩니까? Can Your Programming Language Do This?
[http]스물 셋. 틀린 코드를 틀리게 보이도록 만들기 Making Wrong Code Look Wrong

여섯째마당 소프트웨어 사업 시작하기 Starting a Software Business
[http]스물넷. '소프트웨어 비즈니스-에릭 싱크' 서문 Forward to Eric Sink on the Business of Software
[http]스물다섯. '마이크로-ISV : 전망에서 현실로' 서문 Forward to Micro-ISV: From Vision to Reality
[http]스물다섯 반. 개발 추상화 계층 The Development Abstraction Layer
[http]스물여섯. 고음 내기 Hitting the High Notes

일곱째마당 소프트웨어 사업 경영하기 Running a Software Business
[http]스물일곱. 생체공학 사무실 Bionic Office
[http]스물여덟. 오아시스 없는 사막 Up the Tata Without a Tutu
[http]스물아홉. 단순함 Simplicity
[http]스물아홉 반. 우아함 Elegance
[http]서른. 때 빼고 광내기 Rub a Dub Dub
[http]서른하나. 베타 테스트를 수행하는 열두 가지 비결 Top Twelve Tips for Running a Beta Test
[http]서른둘. 리마커블 고객 서비스로 가는 일곱 단계 Seven Steps to Remarkable Customer Service

여덟째마당 소프트웨어 배포하기 Releasing Software
[http]서른셋. 출시일 고르기 Picking a Ship Date
[http]서른넷. 낙타와 고무 오리 Camels and Rubber Duckies

아홉째마당 소프트웨어 다듬기 Revising Software
[http]서른다섯. 다섯 단계 왜 Five Whys
[http]서른여섯. 우선순위를 정하세요 Set Your Priorities


tag : , , , , , , ,  ]]> 책 MoreJoelOnSoftware Joel 조엘 조엘온소프트웨어 지앤선 싸이텍미디어 책 번역 http://parkpd.egloos.com/1969211#comments Tue, 17 Nov 2009 23:32:56 GMT 박PD <![CDATA[ 오늘의 gamasutra(2009.11.17) : Assassin's Creed 2 와 Uncharted 2 ]]> http://parkpd.egloos.com/1969076 http://parkpd.egloos.com/1969076 작년 ?GDC08 에서 재미있게 봤던 Assassin's Creed 와 Uncharted 에서 각각 2탄이 나왔다.
각각 gamasutra 에 관련 기사가 올라왔는데 여기에서도 [http]Assassin's Creed 2 개발팀과 [http]Uncharted 2 개발팀(Naughty Dog) 의 성향차이가 느껴진다.
?GDC08 에서 Assassin's Creed 측은 모든 캐릭터가 하나의 애니메이션 set 을 공유하도록 만들어서 개발 효율을 높혔다고 한 반면, Uncharted 에서는 [http]모든 캐릭터 2개 마다 프로그래머와 애니메이터를 1명씩 붙여서 작업했다고했다. (각자 2탄에서는 어떻게 작업했을런지...) 이러면 작업 효율은 어떨지 몰라도 좀 더 개성있는 애니메이션을 개발자가 맘껏만들 수 있을 것으로 보인다. Assassin's Creed 는 군중 scene 때문에 그런 시스템을 선택한 것일수도 있지만,Uncharted 보다는 보다 ' 먼저 설계 후 개발'하는 방식을 선호하는 것 같다.

기사 중에서 재미있는 내용을 몇 개 옮겨놔 본다.


[http]Assassin's Creed 2's Plourde On Why 'Fail Early, Fail Often' Is The Wrong Approach

Documentation forces you to think about your future. You start writingit, and then questions are raised. You will face those questions early.You're supposed to be a specialist at addressing those questions.
>> Assassin's Creed 2 같이 뭘 해야할지를 꽤나 분명히 알고 있고, 개발자가 300 명 이상 투입되는큰 프로젝트에서는 문서가 정말 중요하다. "Fail Early, Fail Often" 을 비판하고 있지만, 문서에 있어서는"Fail Early, Fail Often" 을 하고 있다.

Programmers like to do lists. If you make a list, programmers will be happy, and they'll want to use it. They use Excel.
>> 누가 문서를 읽을 것인가를 생각해서 쓰는 게 좋다. 프로그래머들에게 어떤 기획을 만들고 싶은지 설명하고 싶다면,목록 형태로 적어주는게 좋다. 분명하지 않은 컨셉 문서를 기획 문서라고 프로그래머에게 주면, 기획자가 원하는 결과를 절대 얻지못할 것이다.

"When making big-budget games, mistakes can prove extremely costly," heconcluded. "People don't like to work for nothing, and my job is tomake sure people on the team trust me enough that the game we're goingto make is not going to fail."
>> 당연한 얘기. 삽질(재미없을 거 같다거나, 제대로 구현 안 될 거 같은) 할 걸 뻔히 알면서 작업해야 할 때가정말 싫다. 기획 항목을 쭉 나열해 놓은 상태에서 다른 팀원들이 구현하고 싶은 것을 선택하게 한다면, 팀원을 설득하기 위해기획서를 좀 더 제대로 쓰지 않을까.


[http]Reflecting On Uncharted 2: How They Did It

Another thing that changed is that there are no producers. Everybody isworking on the game, and the people making the decisions about whatneeds to be cut and what goes in and out of the game are the peopleimplementing the stuff. We find that really helps us make the bestdecisions about the development of the title.
>> 진짜? 이것도 Uncharted 2 탄이어서 가능한 건가? 1 탄에서 개발자들이 마음대로 이건 넣고, 이건빼고를 할 수 있었다면 어떤 게임이 나왔을까? 아니면 Neil Druckmann 만 그렇게 생각하고, 실무자들은 그렇게 생각하지않는 건 아닐까? ㅎㅎ
게임개발은 독재가 필요하다 라고 얘기한 분도 있고 나도 그 부분은 맞다고 생각한다.
과연 저런 자유를 주었을 때, 객관적으로 자신의 작업을 판단해 과감히 빼 버릴만한 개발자들이 얼마나 많을지, 이렇게 해서 합쳐진 전체 작업물이 하나의 게임 느낌이 날 것인지가 궁금하다.

Every Monday, Wednesday, and Friday at 2:30, the whole company wasplaying multiplayer and giving feedback and iterating on stuff. And weended up with a pretty cool multiplayer component.
>> 개밥먹기. 다들 하고 있는지?

tag : , ,  ]]> gamasutra AssassinCreed Uncharted2 http://parkpd.egloos.com/1969076#comments Tue, 17 Nov 2009 12:06:41 GMT 박PD <![CDATA[ Sticky Monster Lab ]]> http://parkpd.egloos.com/1969054 http://parkpd.egloos.com/1969054
팀원 : NANA(김나나), FLA(최림), BOO([http]부창조) 님으로 구성된 한국 디자인 팀이라고 하는군요. 멋지다.





tag : ,  ]]> 사는 이야기 StickyMonsterLab 디자인 http://parkpd.egloos.com/1969054#comments Tue, 17 Nov 2009 10:03:43 GMT 박PD <![CDATA[ 프로그램은 왜 실패하는가 5주차 스터디 정리 ]]> http://parkpd.egloos.com/1968946 http://parkpd.egloos.com/1968946 여기에서





tag : , , , , ,  ]]> 모임 프로그램은왜실패하는가 디버깅 AnD Study Debugging 아꿈사 http://parkpd.egloos.com/1968946#comments Tue, 17 Nov 2009 02:46:53 GMT 박PD <![CDATA[ 카오는 유령 고래다. ]]> http://parkpd.egloos.com/1968834 http://parkpd.egloos.com/1968834 나도 그 녀석 때문에 몇 번 누워서 소리 지른 적이 있다.
사냥터에 몇 명 누워있어서 가 보면 사람들이 '근처에 위xx스 있으니 조심하세요' 알려준다.
그럼 바로 리스 타야한다. 젠장.

예전에 Bubble Bobble(보글보글) 해 본 사람들은 알겠지만 레벨을 빨리 못 끝내면 나오는 유령 고래가 있다.

카오를 볼 때마다 유령 고래가 생각난다.
내가 있는 사냥터는 전부 비선공이라 사실 긴장감은 그다지 들지 않지만, 가끔 나타날지 모르는 카오 때문에 항상 카메라를 열심히 돌려야 한다.
이런 점이 좋은지는 모르겠지만(사실 귀찮지만) 적어도 긴장감이 있다.
그리고 언젠가를 잡으리라 생각하면서 레벨업을 하게 만든다.
(나의 레벨업 속도로는 평생 불가능할지도 모르지만)
그래도 보글보글에서는 절대 못 잡는 유령고래를 여기에서는 언젠가는 잡을 수 있다는 점이 좋다.
기다려라. 위xx스...




tag : , , , , , , , , ,  ]]> Lineage2 보글보글 BubbleBobble 유령고래 혈맹전쟁 독종 리더스 NS LK 리니지2 카오 http://parkpd.egloos.com/1968834#comments Mon, 16 Nov 2009 15:13:26 GMT 박PD <![CDATA[ Programmers At Work(번역서 : 컴퓨터 소프트웨어의 창시자들) 리뷰 ]]> http://parkpd.egloos.com/1966991 http://parkpd.egloos.com/1966991 Programmers At Work(번역서 : 컴퓨터 소프트웨어의 창시자들) 에서 재미있었던 부분들을 정리해 보았습니다. ()는 제가 따로 쓴 내용입니다. 절판된 책이기도 하고 일부 내용만 정리해서 올린 것이긴 해도, 만약 저작권에 문제가 있을 경우 적절히 조치하도록 하겠습니다.

책에는 12명(원서 19명)의 프로그래머들과 인터뷰를 한 내용을 모았는데, 다들 핵심적인 부분에서는 생각이 비슷하더군요.
  • 처음에 구조, 만들려는 것을 정확하게 해야 한다.
  • 다른 사람의 프로그램을 연구해야 한다.
  • 단순하게 만들어야 한다.
개개인의 특징이 잘 드러나는 부분도 좋고, 1989년에는 사람들이 이렇게 생각했구나가 드러나는 부분도 좋았습니다. [http]Coders At Work 와 [http]Masterminds of Programming: Conversations with the Creators of Major Programming Languages 덕분에 이 책이 다시 주목받고 있다는 생각이 듭니다.
[http]programmersatwork.wordpress.com 에 원서 내용이 일부 공개되어 있고, 앞으로도 계속 추가 공개를 할 거 같으니, 아직 책을 못 구해 보신 분들은 이 블로그를 활용해 보셔도 좋을 거 같습니다.
[http]Programmers At Work, 22 Years Later 에는 인터뷰를 했던 개발자들의 요즘 근황을 정리한 기사를 올렸습니다. 죽은 사람들이 몇 분 있어서 맘이 아픈데, 오늘 [http]제랄드 와인버그(Gerald Weinberg) 소식을 들은터라 더욱 더 맘이 아프네요. 프로그래밍도 좋지만, 건강하게 삽시다.

  • Charles Simonyi(찰스 시모니)
    • 일을 거꾸로 하면, 까다롭던 문제가 갑자기 아주 간단해지는 경우가 있습니다.
    • 1972 년 이후에는 '헝가리안' 이라고 부르는 명명법으로 모든 코드를 짜 왔습니다.
    • 프로그램의 대부분은 사물의 명칭입니다. 헝가리안 방식은 명칭을 부여 받은 사물의 속성에서 거의 자동적으로 이름을 만들어내는 방식입니다. (헝가리안 표기법에 대해서는 [http]Joel 의 글도 읽어보자. 이 글은 '조엘 온 소프트웨어를 넘어서'에도 번역되었고, 가장 재미있게 읽은 글 중 하나다)
    • 프로그램을 만들려면 먼저 무엇을 만들고 싶은지 정확하게 알아야 합니다.
    • 프로그래밍의 1단계는 상상력을 발휘하는 것입니다. 그리고 나서 머릿속에서 충분히 구체화시킵니다. 그 다음 단계에서는종이와 연필로 낙서를 합니다. 아직 코드를 쓰지 않습니다. 머릿속에서 구조가 명확히 구체화되면 그 때 코드를 작성합니다. 핵심은머리에 있는 데이터 구조입니다.
    • 프로그래머를 관리하는 가장 좋은 방법은 직접 모범을 보이는 것, 그리고 여러 번 반복해서 코드를 검토하는 것이라고 생각합니다.
    • 젊었을 때에는 머리속에 방이 20개나 있어서 여러 개를 넣어둔 성 같았었는데...
    • 프로그래밍을 하지 않을 때는? 이집트의 상형 문자도 좀 보고... 개인용 헬리콥터 조종사 면허도 있습니다.
  • John Warnock (존 워녹)
    • 코드 작성 방법 : 무슨 일을 해도 우선 충분히 생각합니다. 한 가지 생각에만 너무 집착하지 않고 코드도 필요하면주저하지 않고 버릴 수 있는 용기가 필요합니다. 자신만 알고 있다고 생각하면 곤란합니다. 이 장사의 비결은 정보를 보다 빠르게입수하는 겁니다. '내 발명이 아니다(not-invented-here)' 따외는 신경쓰지 말고 그걸 활용해야 합니다.
    • 좋은 프로그램을 만드는 것은 균형입니다.
    • 좋은/나쁜 프로그래머를 구별하기란 어렵습니다. 작가를 고용하는 것과 마찬가지입니다... 하지만 문학상을 이미 몇 번 받은 사람이라면 매우 높이 평가됩니다... 대게 세상의 평판으로 고용 여부를 정합니다.
    • 수학, 국어, 기초 과학의 기본을 확실히 다져둔 다음에 컴퓨터 공부를 시작하는 게 좋다고 생각합니다.
    • 성공 비결 : 여러 기술을 지닌 재능이 뛰어난 사람들과 함께 있어야 합니다.
    • 중간 결과를 얻을 수 없고, 2년 이상 걸리는 개발은 손대지 않아야 합니다. 2 개월마다 결과를 내야 합니다. 그렇게 하면 그걸 평가하고 재편성하여 다시 시작할 수 있을 겁니다.(오... 애자일)
    • 특별히 좋아하는 언어는 없습니다. 우선 5, 6 개 정도 익히고 나면 다음에 5, 6개를 외우는 건 그다지 어렵지 않습니다.
  • Gary Kildall(게리 킬달)
    • 어려줘서 해결할 수 없을 거 같다고 생각될 때 일이 시작됩니다. 그리고 나서 이를 더 작은 부분으로 나눕니다.
    • 코드 자체에 대한 주석은 붙이지 않습니다.
    • 단순성을 밝혀내면 쉬워집니다.
    • 프로그래머로서 자신만의 스타일을 만들려면? 다른 사람의 작품을 연구해야 합니다.
  • Bill Gates(빌 게이츠)
    • 프로그래밍에서 가장 어려운 점은? 알고리즘을 결정하고, 이를 최대한 단순화시키는 겁니다. 더 이상 단순화할 수 없을때까지 최대한 단순화시키는 것은 대단히 어려운 일이죠. 프로그램의 기능을 어떻게 할 것인가에 대한 시뮬레이션을 머릿속으로그려야만 합니다.
    • 프리마돈나 같은 프로그래머는 신뢰하지 않습니다.
    • 마이크로소프트에서 프로그래머가 아니면서 프로그래밍 프로젝트를 관리하는 사람은 한 명도 없습니다.
    • 벌써 프로그램 속도의 한계를 얘기하는 사람은 게으르고 나태하기 때문이라고 생각합니다. 사용자는 정확히는 몰라도 정말 빠른 프로그램이 무엇인지를 알기 때문입니다.
    • 팀 관리 방법 : 그룹을 소규모로 유지, 똑똑한 사람으로만 구성, 훌륭한 툴 준비, 공통 용어 사용, 그룹 외부에 언제라도 조언해 줄 수 있는 초베테랑팀을 둘 것.
    • 시간이 많이 걸려도 기초를 튼튼히 한 후, 즐긴다는 기분으로 코딩을 하고, 실행해 봅니다. 제일 맛있는 음식을 가장 마지막까지 남겨두는 것과 같은 거지요.
    • 프로그래머의 능력을 시험하는 가장 좋은 방법은 프로그래머에게 30페이지의 코드를 건네주고 그가 어느 정도 속도를 그것을 읽고, 얼마나 이해하는지 알아보는 거라고 생각합니다.
    • 좋은 프로그래머가 되려면, 많이 만들어보고, 다른 사람의 프로그램을 연구해야 합니다.
  • C. Wayne Ratliff(C.웨인 래틀리프)
    • 무슨 일이든 순서대로 해야지
    • 프로그래밍에서 가장 즐거운 순간은 한 발만 더 나가면 완성되는 단계에 왔을 때입니다. 우선 해 보고, 실패하고, 몇 번이고 실패하다가 100번째에 그런대로 쓸 만한 상태에 이르렀을 때 기분이 최고가 됩니다.
  • Jonathan Sachs(조나단 삭스)
    • 요즘은 이미 일이 세분화되어 버려서 폭 넓게 경험할 기회가 부족합니다.
    • 다른 사람의 프로그램을 보면서 여러 가지를 배웠습니다.
  • Ray Ozzie(레이 오지이)
    • 여러 경험을 쌓은 프로그래머와 일하고 싶다. 컴퓨터공학 내에서도 전혀 다른 분야로 옮겨 다니는 것이 좋다고 생각합니다.
  • Bob Carr(보브 카아)
    • 법칙을 발견하는 것
    • 아키텍처는 균일해야 합니다. 즉, 예외가 없어야 합니다.
    • 소프트웨어에 익숙해지기만 하면, 사용자가 일 외에는 생각할 필요가 없는 프로그램이 되어야 합니다.
  • Jef Raskin(제프 래스킨)
    • 저는 메타 프로그래머일 뿐입니다.
    • 잡스는 처음 2년 동안은 이 프로젝트(매킨토시)가 갖는 의미를 전혀 이해할 수 없었던지 프로젝트를 무산시킬려고 생각했던 거죠.
    • 잡스는 다른 사람이 담당한 일까지 자신의 공으로 돌리려고 했습니다.
    • 세탁기 사용자 그룹이 없는 이유는, (사용법이 너무 쉽기 때문에) 세탁기를 사용하는 데 동호회 따위가 필요하지 않기 때문입니다.
    • 유감스럽게도 지금의 사회란 돈을 벌면 벌수록 그쪽의 말에 귀를 기울리는 사람도 늘어납니다.
    • 프로젝트 참가자 모두에게 특허권을 주고 있습니다.
    • 시스템에서 모드를 없애야 합니다.
    • 한 가지 행동으로 한 가지 일을 할 때 목표에 도달하는 길이 오직 한 가지 뿐일 때 고민할 필요가 없어지는데 이를 저는 단순함이라고 부릅니다.
  • Andy Hertzfeld(앤디 헤르츠펠드)
    • 지금 하고 있는 일이 재미있으며, 흥미를 잃게 되면 다른 일을 찾을 것이라고 했다.
    • 프로그래밍 배우기는 자전거처럼 실제로 해 봐야 합니다.
    • 애플사는 애플 II 가 무엇인지도 모르는 사람조차 전부 다 끌어들였습니다.
    • 한심하게도 가장 회사에 공헌을 많이 한 사람이 아닌, 주식 취득을 가장 열심히 한 사람이 돈을 가장 많이 벌었습니다.
    • 잡지사들이 관리자들과 인터뷰했기 때문에 리자를 개발한 것이 관리자 자신들이라고 착각합니다.
  • Toru Iwatani(이와타니 토오루. 岩谷徹)
    • 그 무렵 컴퓨터 게임은 전부 난폭한 것 뿐이었습니다. 여성도 즐길 수 있는 게임을 만들고 싶었습니다. (이 당시에도 벌써 이런 생각을?)
    • 피자를 주문한 후 V자형의 피자를 한 조각 집었을 때 남은 피자 모양이 재미있어 보여서 팩맨의 모양으로 만들었습니다.
    • 괴물의 알고리즘이 가장 어려웠습니다. 빨간 괴물은 바로 뒤에서 팩맨을 추적합니다. 두 번째 녀석은 팩맨의 전방을수비합니다. 즉, A, B 가 팩맨을 샌드위치 시킵니다. 다른 괴물들은 불규칙적으로 움직입니다. 하지만, 사람이 이렇게 쫓기기만하면 전의를 상실할 것이기 때문에, 공,수를 반복하게 했습니다.
    • 아이디어에서 제품까지 1년 5개월 걸렸습니다. 기능을 철저하게 시험하면서 일을 진행했기 때문에 상당히 오래 걸렸습니다.
    • 게임 디자이너는 먼저 인간의 마음을 이해할 수 있어야 합니다.
  • Michael Hawley(마이클 홀리, 마이클 호레이)
    • 워드프로세서로 작성한 문장은 꼴라쥬처럼 보입니다.
    • 음악이 어디서 생겼는지 보다, 음악을 만드는 과정이 중요합니다.


tag : , , ,  ]]> 책 ProgrammersAtWork 빌게이츠 찰스시모니 게리킬달 http://parkpd.egloos.com/1966991#comments Tue, 10 Nov 2009 15:15:10 GMT 박PD <![CDATA[ Programmers At Work, 22 Years Later ]]> http://parkpd.egloos.com/1966728 http://parkpd.egloos.com/1966728 [http]programmersatwork.wordpress.com 원서 내용이 일부 공개 - 계속 업데이트 하는 듯
[http]애자일 이야기 - 컴퓨터 소프트웨어의 창시자들
[http]저자 Susan Lammers 홈페이지

[http]Programmers At Work 한글판을 구해서 읽은 후 찾아봤더니 [http]Programmers At Work, 22 Years Later 과 같은 기사가 있어서, 대강 번역해 봤습니다. 번역이 잘 안 되는 문장은 몇 개 빼고, 댓글에서 재미있는 내용은 몇 개 추가했습니다. 이상한 부분이 있으면 알려주세요. :)

그들은 지금 어디에 있는 걸까? :
  • [http]Charles Simonyi(찰스 시모니) [http]Charles Simonyi 와의 새로운 인터뷰. 당시 : 마이크로소프트 프로그래머. 현재 : 완전 부자, 우주 여행, Oxford 에 석좌 교수용 기금을 기부. [http]Intentional Software 에서 근무. (역주 : 그 자리의 첫번째 교수가 저명한 리차드 도킨스 박사. [http]Intentional Software 팀블로그 에 글을 가끔 쓰는 듯?)
  • [http]Butler Lampson(버틀러 램슨). 당시 : PARC dude. 현재 : [http]Microsoft Fellow. (한글판에서 제외)
  • [http]John Warnock(존 워녹). 당시 : Adobe 공동 창업자. 현재 : 퇴직, 이사로 근무, [http]민박집을 운영하는 듯.
  • [http]Gary Kildall(게리 킬달) : 당시 : CP/M 개발. 1994 사망(역주 : 당시 52세). Programmers at Work(이하 ?PaW) 당시 그가 개발하던 프로젝트는 CD-ROM 으로 배포된 최초의 백과사전이 되었음. [http]Computer Chronicles 도 한 동안 운영했었음.
  • [http]Bill Gates(빌 게이츠).당시 : Microsoft 설립자, "super" 라는 단어가 어울리는 사람. 현재 : 세계에서 (한 때) 가장 부자. 90년대에는 악마의 화신(역주 : 독점법 소송 같은 걸 얘기하는 듯?) 이었지만, 지금은 반쯤 퇴직한 상태로 자선 사업에 집중.
  • [http]John Page(존 페이지). 당시 : Software Publishing Company 의 공동 창립자, 초창기 데이터베이스 프로그램인 PFS:?FILE 개발자. 현재 : 분명하지 않음. [http]2006 년에 그에 대한 비디오가 있는 걸 보면, 아마 아직 살아있을 거 같지만 웹에서는 보이지 않음. [http]SPC 는 1996 년에 합병됨. 약간 묘한 회사간 시너지를 통해서 나온 비지니스를 [http]Harvard Graphics 에서 확인할 수 있음. (한글판에서 제외)
  • C. Wayne Ratliff(C.웨인 래틀리프). 당시 : dBase 개발자. 현재 : [http]퇴직.
  • Dan Bricklin(댄 브릭클린). 당시 : ?VisiCalc 공동 개발자. 현재 : [http]블로그 있고, [http]그의 프로젝트에 대한 역사적인 정보에 대해 알아볼 수 있다. [http]Software Garden 운영 중. ?PaW 의 일러스트레이션과 거의 달라진 게 없음. (한글판에서 제외)
  • Bob Frankston(밥 프랭크스톤). 당시 : ?VisiCalc 의 나머지 공동 개발자. 현재 : Microsoft 에서 몇 년 일 하다가 지금은 퇴직. [http]블로그 있음. (한글판에서 제외)
  • Jonathan Sachs(조나단 삭스). 당시 : Lotus 1-2-3 공동 개발자. 현재 : 실무에서 한 발 물러남. Pocket PC 소프트웨어를 [http]자신의 홈페이지 에서 배포. Digital Light & Color 이라는 [http]사진 소프트웨어 판매. 더 자세한 내용은 [http]this 2004 oral history 에서 참고.
  • Ray Ozzie(레이 오지이). 당시 : Lotus Symphony dude, 나중에 Lotus Notes 로 판매된소프트웨어를 개발하기 위해 Lotus 떠남. 현재 : IBM 에서 근무하다가 Groove Networks 를 시작한 후 지금은Microsoft 의 Chief Software Architect. [http]블로그 있지만, 1년 이상 새로운 포스팅 없음. (역주 : [http]여기 에게 Joel 에게 우주인 아키텍트라고 씹힘)
  • Peter Roizen(피터 로이젠). 당시 : 스프레드시트 프로그램인 T/Maker 개발자. 현재 : 프로그래머 컨설턴트. [http]Inventor of a Scrabble variant that uses shell glob syntax. (한글판에서 제외)
  • Bob Carr(보브 카아). 당시 : PARC Alum, Ashton-Tate 의 Chief Scientist, Framework integrated suite 개발자. 현재 : [http]Keep and Share 창립자. 중간 기간에는 : Go 공동 창립자, Autodesk 근무. 웹에서는 보이지 않음.
  • Jef Raskin(제프 래스킨). 당시 : Macintosh project 개발자, Information Appliance 창립자. 2005 사망. [http]그의 멋진 웹사이트는 아직 살아 있음. The Humane Interface ([http]번역서 있음) 라는 훌륭한 책의 저자. ?PaW 당시 작업하던 프로젝트인 ?SwyftCard 는 별로 성공하지 못함.
    댓글에 따르면 Jef Raskin 에게는 Aza 라는 아들이 있는데, [http]his project 멋진 UI 를 개발 중이라고 함
  • Andy Hertzfeld(앤디 헤르츠펠드). 당시 : Macintosh OS 개발자. 현재 : [http]Google 에서 근무 중, [http]folklore.org, [http]Susan Kare 의 사이트 등등 [http]여러 웹사이트를 운영 중. (요즘 Susan Kare 은 Chumby [http]이걸 얘기하는 듯? 에서 일한다.) 중간 기간에는: General Magic 과 Eazel 에서 근무.
    ?PaW에 나온 사람들 대부분이 프로그래밍 샘플이나 사고 프로세스의 과정을 보여줬지만, Susan Kare 의 Macintosh아이콘이 윈도우 안에서 마구 튀게 만드는 어셈블러 프로그램을 보여준 Herzfeld 의 것이 최고였다고 생각함.
  • Toru Iwatani(이와타니 토오루. 岩谷徹). 당시 : Pac-Man 기획자. 현재 : 2007년 남코에서 은퇴. 일본의 대학 객원 교수. ?PaW 에서는 Libble Rabble 이라는 게임을 굉장히 자랑스럽게 얘기했지만, 나는 들어본 적 없음. [http]PaW interview 가 Iwatani 에 대한 유일한 영어로 된 정보라고 생각함
    [http]a recent interview 를 보면, Iwatani 는 Ms. Pac-Man 과 Pac-Man 간의 관련성을 부인했음. 아마도 Ms. Pac-Man 이 사실상 [http]Pac-Man 에서 성별만 바꾼 클론 이고, Namco 에서 말이 새어 나가지 않길 바라는 것 같음.
    (역주 : 댓글을 보면, 디스커버리 채널에 출연했다는 얘기도 있고, [http]Tokyo Polytechnic 의 전임강사 라는 얘기도 있음)
  • Scott Kim. Paw 에 나온 사람들 중에서 만나본 유일한 사람. 당시 : 퍼즐 디자이너. 현재 : 여전히 퍼즐 디자이너. [http]His website. 수학 교육에도 관심이 있음. (한글판에서 제외)
  • Jaron Lanier(제론 레이너). 당시 : 비주얼 프로그래밍/시뮬레이션 언어쪽에서 작업. [http]"Virtual World" in Future Stuff). 현재 : Berkeley 의 주재학자(scholar in residence), 가끔 Discover 에 칼럼을 기고. [http]그의 웹사이트에서 많은 걸 확인할 수 있음. [http]그가 만든 비디오 게임. (한글판에서 제외)
  • Michael Hawley(마이클 홀리, 마이클 호레이). 당시 : ?LucasFilm 의 Sound Droid (오디오 편집 소프트웨어라고 생각됨) 쪽에서 근무. 현재 : [http]MIT Media Lab. 중간 기간에는: ?PaW 가 출간된 후 잠시동안 ?NeXT 에 있었음.


tag : , , , ,  ]]> 책 ProgrammersAtWork 찰스시모니 게리킬달 빌게이츠 천재프로그래머컴퓨터소프트웨어의창시자들 http://parkpd.egloos.com/1966728#comments Mon, 09 Nov 2009 23:45:32 GMT 박PD <![CDATA[ Ignite Seoul 1회 다녀왔습니다. ]]> http://parkpd.egloos.com/1965834 http://parkpd.egloos.com/1965834 자세한 내용은 정진호님의 발표 후기를 보세요.
정진호님 좋은 자리 마련해 주셔서 감사합니다.

저는 발표자였기 때문에 빨리 갔었어야 했지만,
내부 개발 일정이 걸려버리는 바람에 8시에서야 겨우 도착할 수 있었습니다.
야후 건물이랑은 정말 걸어서 5분도 안 걸리는 곳에 있었는데 말이죠.

참 발표 잘 하시는 분들 많더군요.
15초마다 자동으로 PT 가 넘어가는 방식이라 시간 조절하기도 쉽지 않았을텐데
제가 본 발표자들 대부분이 전혀 시간 조절에 어려움을 안 느끼시더군요.
덕분에 그 짧은 시간동안 20 명에 가까운 많은 사람들의 이야기를 들을 수 있었습니다.

개인적으로는
Keynote User Group 에서 오신 최웅식님과
개발자의 수명 - 맹창규님
Double Deck Performance 의 장상준, 윤동훈님,
보랏빛 소의 사랑과 전쟁의 조민희님 이 좋더군요.
(전체 PT 는 여기에서 보실 수 있습니다.)

제 발표는 발표 자체는 그럭저럭 했다고 생각하는데, 내용이 흥미롭지는 않았나 보더군요.
제가 생각해도 아하~ 할 만한 내용 보다는, 다 알지만 잘 틀리는 내용이었으니까요.
그래도, 하고 싶은 얘기를 할 수 있어서 좋았습니다.
저에게 한 표 주신 분(자봉으로 보이지만 ㅎㅎ) 감사합니다.


다른 분 후기
발표자 이미영님
발표자 김민지님

1) PDF 발표 자료
http://www.slideshare.net/tag/igniteseoul

2) Screen Cast 동영상
http://www.youtube.com/user/phploveme

3) 캠코더 동영상
http://www.youtube.com/user/dongeuny

4) Flickr 사진들
http://www.flickr.com/search/?q=igniteseoul&s=rec



tag : ,  ]]> 모임 IgniteSeoul Yahoo http://parkpd.egloos.com/1965834#comments Fri, 06 Nov 2009 15:20:44 GMT 박PD