게임과 이야기... http://parang94.egloos.com 희생없이는 아무 것도 얻을 수 없다! ko Mon, 18 Feb 2008 06:40:15 GMT Egloos 게임과 이야기... http://md.egloos.com/img/samplelogo2.gif http://parang94.egloos.com 80 80 희생없이는 아무 것도 얻을 수 없다! <![CDATA[ AddOn Studio for World of Warcraft ]]> http://parang94.egloos.com/77365 http://parang94.egloos.com/77365 WOW의 애드온을 쉽게 개발하기 위한 비쥬얼 스튜디오 애드인이 나왔군요...

이런 멋진 아이디어를 내놓다니 역시 세상은 넓고 천재는 많다는 걸 느끼네요 +_+ㅋ;;

비쥬얼 스튜디오 쉘의 확장 기능을 이용해 이러 저러한 툴을 만들어 보는것도 아주 좋을 것 같습니다.


AddOn Studio for World of Warcraft

Visual Studio Extensibility

]]> 게임 개발 http://parang94.egloos.com/77365#comments Mon, 18 Feb 2008 06:39:55 GMT AZA_Style <![CDATA[ 마인드 맵 ]]> http://parang94.egloos.com/62137 http://parang94.egloos.com/62137 그 중에서 마인드 맵은 정리에 있어서 이미 정평이 나있으니 탁월한 효능(?)으로 인기를 끌고 있는데, 이에 대해서는 말할 필요가 없겠고 쉽게 작성할 수 있는 툴이나 사이트를 살짝 소개해 볼까 합니다... +_+ㅋ;;;

FreeMind
: 공개툴이기 때문에, 부담없이 사용할 수는 있는데 디자인이 좀 -.-ㅋ;;;

ThinkWise
: 국산 상용툴이고, 뛰어난 성능으로 해외에서도 호평을 받고 있다고 하네요... 제가 사용해 봐도 무지 편합니다..

MindJet
: 해외 상용툴이고 상당히 편하다고 합니다.

MindMeister
: 마인드 맵을 작성할 수 있는 사이트 입니다. 첫 로딩 속도가 느려서 성질 급하신 분들은 대략 난감하실듯 하네요... ]]> 여러가지... http://parang94.egloos.com/62137#comments Thu, 14 Feb 2008 04:05:36 GMT AZA_Style <![CDATA[ Debugging Applications 1장 ]]> http://parang94.egloos.com/61983 http://parang94.egloos.com/61983 < 버그 : 어디서 발생하고 어떻게 해결하는가? >

버그란 무엇인가?

1. 일관성없는 사용자 인터페이스
2. 요구 사항 불충족
3. 성능 저하
4. 충돌 또는 데이터 손상

프로세스 버그와 해결책

1. 지나치게 짧거나 불가능한 최종 기한
2. "코드 먼저, 생각은 나중에"식 접근 방법
3. 요구 사항 오해
4. 개발자의 무지 또는 부적절한 교육
5. 품질에 대한 책임감 결여

디버깅 선행 조건

1. 프로젝트
2. 언어
3. 기술/툴
4. 운영 체제/환경
5. CPU

디버깅 프로세스

1. 버그를 복사한다.
2. 버그를 기술한다.
3. 항상 버그를 여러분이 만든 것이라고 가정한다.
4. 분할 통치
5. 창조적으로 생각한다.
6. 보조 툴
7. 심도있는 디버깅을 시작한다.
8. 버그가 수정되었는지 검증한다.
9. 배우고 공유한다.

]]> Debugging http://parang94.egloos.com/61983#comments Thu, 14 Feb 2008 01:55:14 GMT AZA_Style <![CDATA[ Head First Object-Oriented Analysis & Design 1장 ]]> http://parang94.egloos.com/59528 http://parang94.egloos.com/59528 < 잘 설계된 프로그램이 세상을 뒤흔든다 >

쉬운 3단계로 위대한 소프트웨어 만들기

1. 여러분의 소프트웨어가 고객이 원하는 기능을 하도록 하세요.
    - 이 단계는 고객에 초점을 맞춥니다. 먼저 프로그램이 하기로 되어 있는 기능을 수행하도록 만드세요.
      이 단계는 요구 사항을 잘 수집하고 분석하는 것이 필요한 부분입니다.

2. 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하세요.
    - 당신의 소프트웨어가 고객이 원하는대로 동작한다면, 은연중에 작성된 중복 코드를 찾고 객체지향 방식을 제대로 적용했는지 확인해야 합니다.

3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요.
    - 고객이 원하는 일을 하는 좋은 객체지향 프로그램이 되었죠? 이제 디자인 패턴과 원리를 적용하여 훗날 다시 사용할 수 있게 해야 합니다.

책을 읽은지가 좀 지나니... 이 책에 무슨 내용이 있는지 가물 가물해져서 다시 살펴보기로 했답니다...
개인적으로 이 책을 좋아하는 이유는 아주 단순한 원리속에 위대함이 담겨져 있다는 것을 일깨워 준달까~~~

특히, 1번 내용은 사용자 스토리나 TDD 등과도 같은 맥락이라고 생각됩니다. 결국, 사용자가 원하는 것을 구현하지 않으면 아무리 좋은 프로그램이라도 위대해 질 수는 없다는 것!

책에서도 계속 같은 내용을 강조하듯이, 결국 우리가 위대한 프로그램을 만드려면 그 길로 가기위한 목표와 방법을 늘 머리속에 담고 있어야 할 것 같네요~ ^^

tag : ,  ]]> OOA&D OOA_D 책 http://parang94.egloos.com/59528#comments Wed, 13 Feb 2008 04:10:30 GMT AZA_Style <![CDATA[ 애자일 회고 ]]> http://parang94.egloos.com/55806 http://parang94.egloos.com/55806

오.. 제목부터 뭔가 강력한 포스가 느껴지는 이 책..!!!
당연히 읽어봐야 한다는 생각에 잠겨~~~ 휘리릭~~~ 읽어보았답니다.

책 초반에는 회고의 목적과 그를 통해 기대할 수 있는 효과에 대해서 쭉~ 나오고,
대부분은 실제로 회고를 진행하면서 어떤 활동들을 어떻게 진행할지에 대한 내용들이 나옵니다.
그리고, 마지막은 짧은 이터레이션에 대한 회고를 넘어서 릴리즈나 프로젝트 완료시의 회고 방법에 대해 간단히 나오고 모든 책 내용이 마무리 됩니다.

일단, 저자들이 권하고 있는 회고 순서는

1. 사전 준비
2. 자료 모으기
3. 통찰 이끌어내기
4. 무엇을 할지 결정하기
5. 회고 끝내기

의 5단계로 이루어집니다.

일반적으로 제가 진행하는 리뷰가 2,4 번 혹은 2,3,4 번만 하는것에 비해 1,5번을 추가하여 참여자들을 배려하고 팀을 생각하는것 같습니다.

책의 내용 중 대부분을 차지하는 실제 활동들을 들여다보면 기존의 제가 해오던 리뷰 방식과는 천지차이라고 할 수가 있는데, 설명도 쉽고 적절한 사례들도 추가되어 있어서 매우 좋았습니다.

가장 좋았던 부분은 특별히 어떤 내용이 아니라 저자들이 제시한 회고 자체에 대한 느낌인데 회고 진행자를 중심으로 모든게 진행되는게 아닌 참여자를 중심으로 진행되고, 진행자는 이들 간의 역학을 조율하는 부분이었습니다. 이렇게 진행이 된다면, 단순히 참여한다는 의미의 "같이"가 아닌 정말 모두가 동참해서 문제점을 분석하고 의견을 내고 상대방을 존중해 주는 의미에서 "같이"란 말을 사용할 수가 있겠네요..~ ^^

평소 프로세스에 대해 관심이 많은 분들은 다들 읽어보실 듯 하지만, 회고 진행자가 아니면 필수도서는 아닐 것 같네요.. 하지만, 평소 리더의 위치에 계신 분들은 반드시 읽어보시면 많은 도움이 될 것 같습니다.



tag : ]]> 좋은 책... +_+ 책 http://parang94.egloos.com/55806#comments Mon, 11 Feb 2008 07:26:49 GMT AZA_Style