꽤나 방대하다

좋은 글이 있어서 퍼왔습니다.

아꿈사 수몽님께서 번역해주신 내용이고, 출처는 아래와 같습니다.

좋은 글 번역해주시고 발표자료로 만들어주신 수몽님께 감사드립니다.

출처 : http://soomong.tistory.com/32





스터디그룹 패턴

A PATTERN LANGUAGE FOR STUDY GROUPS from Joshua Kerievsky

 

패턴이란

반복해서 나타나는 문제에 대한 범용적인 솔루션이라고 생각합니다.

 

아무것도 없는것에서 패턴을 만들어내려면

  1. 먼저 현상으로부터 문제라는것을 인식할수 있어야 할테고
  2. 그에 대한 해결책을 떠올릴수 있어야 하고
  3. 떠올린 해결책을 범용적으로 만드는 능력이 있어야 한다고 생각합니다.

이렇게 하려면 그 문제에 대한 엄청난 통찰력이 있어야 하겠죠.

 

뉴욕에서 Design Pattern 스터디 그룹을 진행하던 조슈아가

이런 능력을 발휘해서 스터디그룹에도 무언가 반복해서 나타나는 문제점들이 있고

그에 대한 범용적인 해결책을 패턴으로 정리해놓은 자료가 있습니다.

 

스터디 그룹 패턴 : http://www.industriallogic.com/papers/khdraft.pdf

 

이 스터디그룹 패턴의 내용을 한번 정리해보았습니다.


[아꿈사 발표자료]

스터디그룹 패턴 (A PATTERN LANGUAGE FOR STUDY GROUPS)
View more presentations from hyun soomyung.
[발표자료 정리버전]


SPIRIT

1. KNOWLEDGE HYDRANT : 지식이 콸콸 쏟아지는 소화전

사람들은 지식을 원하지만 그게 어디있는지도 모르고 어떤책을 봐야하는지도 모른다

 

너무 많은 책들과 기사, 강의들이 있어서 Right path 를 찾기가 정말 힘들다

학교나 회사는 우리가 찾는 지식을 배울수있다고 유혹하지만 정말로 우리가 필요한 지식은 잘 알려져있지 않다.

 

사람들이 목이 말라서 물을 찾는것을 생각해보자

물이 콸콸 쏟아지는 소화전이 있다고 생각해보면 사람들은 그 수많은 물중에서 그들이 원하는게 무엇인지 인지하지 못한다. 그들이 놓치고 있는게 과연 뭘까?

 

Greate literature 즉 대단한 지식은 공부하기 어려우며 이해하기도 어렵다.

대부분의 사람들은 이렇게 어렵게 공부하려하지 않으며 하기도 싫어한다.

대단한 지식은 큰 토론에서 발현되는 경우가 많다. 그래더 더욱 더 내용을 이해하기가 힘들어진다.

 

결국.

30년도 더 된 책에 자기가 찾고 있는 대단한 지식이 있음에도 불구하고 사람들은 그 책을 찾아보지 않는다. 오래된 책에는 인지하지 못한 많은 양의 지식이 있음에도 불구하고 말이다.

 

오늘날에도 이런현상이 팽배한데. 이것은 아래의 중요한 이유들을 인지하지 못하기 때문이다.

- 사람들이 지식을 원하는 마음은 계속 이어졌기 때문에 대단한지식을 습득하는 일은 가치있는 일이다.

- 대단한 지식은 순차적으로 공부할때 이해하기가 쉽다

- 다른사람들이랑 같이 하면 훨씬 더 공부하기가 쉽다

 

따라서

책이나, 발표자료, 기사, 스터디자료 등등에서 당신의 전문분야에 great literature 를 찾아서

스터디를 시작하라

 

2. POOL OF INSIGHT : 지식의 풀

Literature 를 혼자 공부하는데는 아무문제가 없다.

하지만 그룹 스터디와 비교하면 개인적인 공부는 얻는 지식이 얕을 수밖에 없다.

 

다른 사람들과 대화를 하게되면

- 다른사람들을 혼란스럽게 하는게 무엇인지

- 이해못한것들을 드러낼수있고

- 새로운 생각이 드러나며

- 이미 알고있던것인지도 몰랐던것을 표현할수있다

 

인용 - "토론은 누구도 이기려 하지 않는다. 한명이라도 이긴다면 모두 이긴것이다. 보통의 game 이 win-lose 인것에 비하면 토론은 win-win 이다.

Against each other 가 아니라 with each other ! "

 

따라서

혼자 공부하지말고 스터디그룹에 가서 토론하고 모르는것을 질문하라. 스터디팀원들과의 지식교환은 이해도를 훨씬 높여줄것이다.

 

3. SAFE PLACE : (질문하기) 편한 분위기

큰목소리, 자기자랑, 모든것을 다 안다는 태도, 서로를 공격하는 분위기 등은 서로를 불쾌하게 만들뿐, 지식공유에는 전혀 도움이 되지 않는 환경을 만들어낸다.

 

토론에서는 참석자가 아무리 바보같은 질문일지라도 편하게 질문 할 수 있어야 한다.

사람들이 자신이 모르는것을 인정하는것에 편한함을 느끼기 시작하면 진정한 배움이 발현된다.

모든 참석자가 이런 편한 분위기가 형성되도록 노력해야한다.

 

따라서

서로가 서로에게 질문하고 실수 할수 있는, 그래서 서로 배울수 있는

편안하고, 관대하고, 정중하고 집중할수 있는 환경을 만들어라.

 

4. ENDURING ENERGY : 지속적인 에너지

스터디그룹을 시작하는건 정말 쉽다. 하지만 맴버들이 열성적이고, 모임에 지식이 넘치며 그룹이 오래 지속되는것은 함께 고민해야하는 또다른 문제다.

 

스터디그룹의 에너지는 창시자로부터 온다. 창시자가 지식탐구를 중요시하면 스터디는 강력한 에너지와 함께 시작된다. 하지만 창시자가 개인적인 홍보, 단타지식에 집중하면 스터디그룹의 수명은 짧아질 수 밖에 없다

스터디가 지속적인 에너지를 가지려면 모이는 빈도, 시간, 장소, 스터디내용 등 모든것이 중요하다

얼마나 자주 얼마만큼의 시간동안 모일것인가

Frequent meeting , Hour meeting , Short breaks

모이는 장소도 중요하다

스터디하는 내용도 중요하다

 

따라서

일주일이나 이주일에 한번씩. 그리고 중간에 2시간정도씩 휴식하면서 모든사람이 좋아하는 장소에서 깊은 주제를 공부하는 스터디그룹을 만들어라.

 

5. KINDRED COLLABORATORS : 마음맞는 사람들

사람들은 전문적인 지식의 네트워킹을 원하지만 누구와 어떻게 해야하는지 모른다

 

직장에서 일하는데 대부분의 시간을 보내고 정말 자기가 하고 싶은 것을 하는 데는 조금의 시간밖에 쓰지못한다

사내스터디를 만들어보기도 하지만 대부분의 사내스터디는 관심부족과 시간나면 칼퇴 등으로 실패하기 마련이다. 컨퍼런스에 가보기도하지만 피상적인 관계들만 남을뿐이다.

정답 스터디그룹 안에서!

 

따라서

스터디그룹 안에서 정기적으로 만나고 당신이 중요하게 여기는것을 공유하는 소규모 그룹을 만들어라. 사람들을 알아갈수록 점점 발전하게될것이다

 

ATMOSPHERE

6. COMMON GROUND : 공동의 장소

사람들은 토론이 가능한 스터디 장소를 찾기 힘들어 한다. 회사, 집, 클럽등은 다른사람의 영역이란 생각이 들기 때문에 이런장소를 제공해주지 못한다.

 

스타벅스 CEO 왈

미국은 요즘 서로간의 교류가 가능한 장소가 없어지고 있다.

집과 회사가 아닌 위협 받지 않고 모일 수 있는 공간이 필요하다.

 

찾기가 어렵겠지만 이런 장소들은 피해야한다.

스터디그룹원 중 한명이 근무하는 큰 회사의 회의실. 여긴 돈도 안들고 , 넓고, 깨끗하고, 조용하기까지하니 정말 자연스럽게 선택할수있겠지만 이건 좋은 선택이 아니다.

왜냐하면 보통사람은 사무실 집기로 가득찬 숨막히는 회사안에서 여가시간을 보내고 싶어하지 않기 때문이다.

 

따라서

다양한 사람들이 모일수 있고 집,회사와 멀리 떨어져있는 공동의 장소에서 스터디를 하라

 

7. PUBLIC LIVING ROOM : 공개적인 거실

황량한 장소는 사람들을 숨막히게 하고 열정적이고 활발한 토론을 방해한다

 

스터디에 가장 적합한 장소는 넓고 편안한 내집같은 거실이다

많은 의자와 소파가 있는 조용한 까페정도.

스터디 시작 전이나 끝난후에도 편하게 앉아있을수 있고

늦게오거나 중간에 나가는 사람들이 스터디진행에 최소한의 영향을 미치는 장소가 좋다.

 

따라서

스터디전후로 사람들이 편안함을 느낄수있게하는 다양한 시설들. 즉 마실것, 먹을것, 재배열가능한 가구, 편안한 조명등을 제공하는곳을 선택하자.

 

8. INTIMATE CIRCLE : 친밀한 자리배열

이상한 의자배열은 사람들을 멀어지게하고 비효율적이다

 

모두 마주볼수있고 잘들을수 있는형태가 제일 좋은데 보통 이런 장소는 잘 없고 가구이동도 안되게 되어있다

소통하기 가장 효율적인 모양은 원형태.

서브그룹이 따로 얘기하려면 가구이동도 가능 해야함

 

따라서

자유롭게 넓혔다 좁혔다 배열이 가능한 많은 의자들과 책상이 있는 넓은 장소를 선택하라

 

9. VIRTUAL SPACE : 온라인 공간 

온라인 공간이 없으면 스터디그룹을 알리고 스터디공지 및 새로운맴버 모집에 비효율적일 수밖에 없다

 

쉽게 만들수 있는 웹싸이트가 가장 좋은 선택.

 

따라서

스터디 그룹의 목표, 활동들, 기존 스터디 결과 등을 올릴 수 있는 온라인공간을 만들어라

맴버들은 이곳에서 계속 토론을 할수도 있고 스터디 그룹에 대해 더 잘 알게 된다.

 

ROLES

10. ENTHUSIASTIC LEADER : 열정적인 리더

열정적인 리더가 없으면 스터디그룹이 쇠퇴하거나 오래 지속되지 못하고, 심지어 망해서 없어질수도 있다.

 

좋은 리더는

스터디 주제를 정하고

새로운 맴버를 쉽게 적응할수있도록 도와주며

유명인사.저자초청등의 스페셜 이벤트를 준비하고

새로운맴버들이 들어올수있도록 웹싸이트를 운영하며

스터디 장소를 정한다

 

따라서

열정을 가지고 스터디그룹을 리딩하라.

더 큰 모임과의 접선, 스페셜 이벤트 추진, 온라인 공간 개설, 사람들이 원하는 장소 선정등을 하고

맴버들의 idea 를 더 가까이 듣고 더 발전시켜주어라.

 

11. MOTIVATED MODERATOR : 의욕적인 사회자

사회자가 없는 토론은 목표없이 떠도는 배와 같으며 서로를 공격하기 바쁘고 상대방의 깊은 뜻을 이해하지 못하게 된다.

 

토론에는 중재자가 있어야한다.

좋은 중재자의 역할은

완벽한 사전준비

토론을 시작하는 질문던지기

침체되는 토론을 활성화시키기

지역방송관리

주위집중시키기

사람들을 말하도록 하기

이유없는 비판 막기

돌아가면서 사회맡기

배경지식

이해하지못하는 질문과 내용들 명확히하기

정중하고 인내심있게 진행

 

따라서

예리한 질문을 하고 모두를 대화에 집중하게 만들며 다양한 의견을 조율하고 사람들의 이해도를 높일수있도록 토론을 진행하라

모든사람에게 사회자가 될수있는 기회를 주되 그들 스스로 결정하도록 하라

 

12. ACTIVE PARTICIPANT : 적극적인 참가자

스터디 그룹에 들어오고 싶어하는 사람이 느끼는 가장 큰 장벽은

많은 수의 기존 스터디 사람들, 스터디 장소, 기존에 스터디한 내용들에 대한 부족한 이해 등이다.

하지만 많은 사람들이 이것은 알아채지 못한다

그들이 스터디 그룹을 더 활기차게 바꿀 수 있으며 그들이 원하는것을 구체화 시킬수 있다는 것을말이다

 

모든 스터디 그룹은 열정적인 리더와 단골 참가자들로 이루어진다.

만약 리더와 단골 참가자들이 함께 노력한다면 스터디그룹은 모든 참가자들에게 훨씬 더 많은 지식을 전달할 수있다.

만약 새로 들어온 사람이 스터디 그룹에서 기존에 했던 내용을 스터디 하길 원한다면 서브그룹을 만들어서 시작하면 된다

또한 사회자가 되어 토론을 중재 하는방법을 배울 수도있다

 

따라서

그룹을 활동적이고 새로운 맴버에게 열려있는 그룹을 만들것

적극적으로 새로운맴버를 도와주어 중요한 참여자가 되도록 도와줄것

 

13. PREPARED PARTICIPANT : 준비된 참가자

토론전에 각자 미리 준비하지 않는다면 토론에 아무말도 하지못하거나 너무 많은말 즉, 주제를 벗어난 혼란스러운말들만 하게된다

 

스터디주제가 정해지면 참석자들은 미리 공부하고 정리해와야한다

이해한것들과 이해하지못한것들

중요키포인트라고 생각하는것들

이건 동의못하겠다하는것들

비슷한 내용의 다른글

어떻게하면 더 발전할수있을까등

 

모든사람들이 다 준비해올수는 없는게 현실. 준비해온 사람이 의욕적인 사회자가 되어 진행하자

 

따라서

스터디전에 내용을 미리 완벽히 공부하자

그럴만큼 동기부여가능한 내용을 스터디하고 한번에 진행하는 분량을 스터디그룹의 역량에 맞추어서 잘 조절하자

 

14. DISTINGUISHED PARTICIPANT : 뛰어난 참가자

뛰어난 참가자는 자신의 분야에서 많은 사람을 상대로 강연을 하곤 하지만 이것은 발표자에게나 청중에게나 멋진 토론보다는 지식 배움에 있어서 덜 효과적인 경향이 있다

 

뛰어난 사람은 비록 정말로 듣는 사람이 적더라도 많은 사람을 상대로 강연해야한다고 생각하는함정에 빠질수 있다.

진정한 배움은 일방적인 강연보다 토론을 통해서 발현된다. 강연 중의 토론시간. 즉 질의응답시간에서 더 많은 지식을 전달할수있지만 보통 여기에 많은 시간을 할애하지 않는다.

뛰어난 참여자가 생기면 그룹이 너무 커질 수 있음. 소규모 그룹으로 쪼개서 여러 번 진행.

 

따라서

뛰어난 사람을 스터디 그룹에 초대하자. 토론의 질을 높일 수 있을 것이다. 또한 모든 사람이 참여할수있도록 하자.

 

CUSTOMS

15. OPENING QUESTION : 토론을 시작하는 질문

화두를 던지는 질문없이 책을 읽으면 책의 진정한내용을 알지못하고 겉모양만 이해하게된다.

 

내용을 잘 이해하고있는 사람이 시작질문을 해야하므로 이건 쉬운일이 아니다

참가자들 역시 이 질문을 이해하고 토론을 계속 진행해나가야 한다.

 

따라서

참여자들이 생각해볼만한 주제를 화두로 던지는 시작질문으로 토론을 시작하라. 사람들이 시작질문에 대해 물어보도록 하고 그들의 질문을 기록해두라

 

16. SEQUENTIAL STUDY : 연속적인 스터디

관련된 내용을 발표된 시간순으로 스터디하지 않으면 이해가 어려운것들이 있다

 

한 책을 이해하지 못한다 해도 관련 있는 분야의 먼저 출간된 책을 같이 보면 이해하는데 도움이 될 것이다.

 

따라서

이해도를 최대로 높이기 위해 관련 있는 책들을 발표된 순서로 스터디 하라

그 순서는 결국 역자들이 어떤 책에 영향을 받았는지를 보여주는 것이고 가장 큰 영향을 미친 역작이 무엇인지를 알려준다

 

17. AGENDA : 토론주제

토론주제가 없으면 스터디는 물론, 스터디 맴버들도 길을 잃어버리게 된다.

 

사람들은 큰 그림을 원한다. 현재 스터디가 어디쯤 진행중이고 집중해야하는 것이 어떤 부분인지를 알고 싶어한다

 

따라서

전체적인 토론주제를 정하고 스터디를 진행하라

변경가능하고 특별 이벤트 같은것도 가능하도록 주제를 정하라

 

18. SUBGROUP : 서브그룹

스커디그룹의 규모가 커지다보면 더이상 효율적이지 못한 크기가 되버린다. 또한 모든 맴버들의 실력이 전부 다르니 하나의 공통된 관심주제를 찾기도 어려워진다

 

모든 서브그룹은 각자의 사회자가 필요하다

 

서브그룹이 만들어지게 되는 이유들

- 너무 많은 참가자들

- 다른 주제를 공부하기 원하는 사람들

기존 스터디 맴버들보다 지식이 떨어지는 사람들

- 아무도 스터디하지 않는 관련내용을 스터디하기 원하는 사람

서브그룹 만들라고 추천해줄것

- 스터디그룹에 새로운 맴버가 필요할때

현재 스터디 그룹의 수준이 너무 높을때 새로운 맴버는 초보자 서브그룹으로

 

따라서

스터디그룹이 너무 커지거나 다른주제를 스터디 하기 원하는 사람들이 있으면 서브그룹을 만들어라. 각 서브그룹은 주제를 정하고 새로운 맴버를 받아라. 그리고 사람들에게 서브그룹을 선택하도록 하라.

 

19. STUDY CYCLE : 스터디 싸이클

베테랑급 스터디그룹의 주제는 보통 심도깊은 분야를 다루는 경향이 있다. 이것은 초반지식이 부족한 새로운 맴버에게는 확실히 문제가 될수있다.

 

스터디싸이클은 전적으로 새로운 맴버를 위한것이다. 베테랑 맴버들처럼 순차적인 스터디를 할 수 있는 기회를 제공해주는 것이다.

 

뉴욕의 디자인패턴 스터디그룹을 예로 들면

서브그룹으로 총 23개의 패턴을 1주에 한패턴씩 스터디 싸이클을 돌렸다. 중간에 2~3번 휴식을 포함해서. 그리고 23주후에는 또 새로운 맴버를 받아서 다시 스터디싸이클을 시작했다.

 

따라서

초반지식을 분류해서 그룹에 원하는 사람이 있을때마다 서브그룹을 만든뒤 스터디 싸이클을 돌려라.

 

20. DISTRIBUTED DIARY : 공유되는 기록

스터디 그룹은 가치있는 생각들, 질문, 의견들을 만들어내지만. 이런것들이 기록되고 공유되지 않으면 스터디에 참가하지 못한사람들에게는 도움을 줄수가 없다.

 

가치있는 내용들이 기록 되지못하는 이유는

- 스터디 그룹 자체가 기록의 중요성을 인지하지 못함

- 기록해주는 사람을 찾기가 힘듬

- 기록을 한다고는 하는데 중요한 생각들이 기록되지 못함

 

그렇다면 어떻게 해야 계속 잘 기록할 수 있을까?

지원자 한명을 뽑아서 기록하면 그사람 주관적으로 중요하다는 내용만 기록되버리는 문제

기간이 길어지면 지원자가 기록이 힘들다고 더이상 하기싫어함

 

녹음기를 이용하는 방법도 있다

하지만 사람들은 대부분 녹음파일 전체보다는 중요한 부분만 듣고싶어한다.

 

해결책은 중요한 내용을 기록하는 과정을 각자 나눠서 하는것이다.

- 나눠준 카드에 각자 작성하고

- 카드 취합한뒤

- 기록을 통합해서 공유한다

 

따라서

스터디 참가자들은 스터디중에 생각나는 아이디어, 질문, 의견들을 각자 기록하여 한사람이 통합한후 공유하라.

 

21. AFTERHOURS : 스터디후 모임

스터디가 끝나고 난뒤의 모임에서도 계속 이어서 사람들과 지식을 나눌수있다.

 

디자인패턴 스터디에서는 "social time" 이라는 이름으로 항상 스터디후에 모여왔으며 일이 있어서 스터디에 못온사람도 이 시간을 위해 참석하는 경우도 있었다.

다른말로는 "같이 밥먹기"

 

따라서

공식적인 스터디시간 후에 비공식적인 모임을 가져라.

가깝고 괜찮은 장소로 이동해서 먹고 마시며 경험을 공유하고 즐겨라.


덧말 1.

이런 생각을 해낼수있는 조슈아가 정말 대단해보입니다. 그래서 다시금 그의책을 집어들었습니다.

 

덧말 2.

각 패턴들마다 해당패턴을 설명해주는 간단한 그림들이 있었는데요.

저는 이 그림들이 너무나 너무나 마음에 들었습니다.

디자인패턴이 디자인책이냐며 물어보는 후배들에게 제가 제일 처음 권해주는 책이

"Java 언어로 배우는 디자인 패턴입문" 인데요.

그 이유는 이 책의 저자가 각 패턴을 그림으로 설명해놓았기 때문입니다.

하나의 그림으로 전달하는 명쾌한 insight 에 대해서 한번 포스팅을 따로 해봐야겠네요.

 

덧말 3.

바로 전 포스팅에서 레거시코드 활용전략의 안좋은 번역을 단점으로 꼽았었는데

영어로된 스터디그룹 패턴을 저도 번역하면서 이해하다보니

역시 번역이 쉬운일이 아님을 다시한번 깨달았습니다 ㅜㅜ

혹시 제가 잘못 번역한 부분을 알려주시면 너무 감사할것 같습니다.

원문 출처 : http://www.massively.com/2008/09/28/eve-evolved-eve-onlines-server-model/


짧은 실력으로 번역하느라 너무 힘들었습니다. ㅠ_ㅠ
표현이 어색하거나 틀린 것이 있다면 말씀해주세요~ 언제든 수정하겠습니다~

EVE Evolved: EVE Online's server model

진화된 이브 : 이브 온라인의 서버 모델

by Brendan Drain  Sep 28th 2008 at 5:30PM

Filed under: Sci-fi, EVE Online, Business models, Economy, MMO industry, PvP, Politics, Virtual worlds,EVE Evolved


Almost any time a discussion about EVE Online comes up, one way or another we end up talking about the server. EVE Online is unique among today's most popular MMOs for its single-server approach. While most MMOs deal with large number of users by starting up large numbers of separate servers with identical game universes, EVE maintains only a single copy of its game universe on a massive cluster of servers. CCP's decision to go with a server model that doesn't use any sharding or instancing whatsoever has had a major impact on in-game activities and how the game has developed.
거의 매번 이브 온라인에 대한 논의가 있을 때마다, 우리는 어떻게 해서든 결국 서버에 대해 이야기합니다. 
이브온라인은 오늘날의 가장 인기있는 MMO들 사이에서 단일 서버 체제 (single-server approach) 를 사용하는 독보적인 게임입니다. 
대부분의 MMO 들이 많은 수의 동일한 게임 세계를 가진, 서로 분리된 서버에 의해 수많은 유저들을 다루는 동안, 이브온라인은 오직 하나의 게임 세계를 서버들의 거대한 클러스터 기반으로 유지합니다. 
그 어떤 샤드화 또는 인스턴스화를 사용하지 않는 서버 모델로 간다는 CCP – Crowd Control Production, 이브온라인 제작사 – 의 결정은 게임내 활동과 게임이 어떻게 개발될지에 대한 중대한 충격을 안겨줬습니다.


Server woes:
서버의 고민:
Unfortunately for CCP, maintaining their vision of a single game universe has proven a lot more difficult and costly than anyone anticipated. Working with IBM, the EVE server cluster is maintained in London and is currently the largest supercomputer employed in the gaming industry. Even with this massive power behind the EVE universe, there are still problems as CCP tries to keep the server upgraded ahead of its ever-expanding playerbase.
CCP로서는 불행하게도, 단일 게임 세계 (single game universe) 의 비전을 유지하는 것이 그 누구의 예상보다 매우 어렵고 비용이 많이 든다는 것이 입증되었습니다. 
IBM 과 함께 일하면서, 이브온라인 서버군은 런던에 유지되었고, 이는 현재 게임 업계에 도입된 가장 큰 슈퍼컴퓨터입니다. 
이브온라인 세계의 뒤에 이러한 거대한 힘이 함께 하더라도, CCP로서 꾸준히 증가하는 유저들을 안고( its ever-expanding playerbase) 서버를 업그레이드 된 상태로 유지하기 위한 문제가 여전히 남아있습니다.

In this article, I discuss the unique gameplay that is possible thanks to EVE's server model, the problems the server currently faces and what CCP is planning to do about it.
이 글에서, 이브 온라인의 서버 모델 덕분에 가능한 유일한 게임 방식과 서버가 현재 직면해 있고, CCP 가 계획하고 있는 문제들에 대해 논합니다.


With a single game world, players are free to flock to whatever solar system they like even if the server that solar system is on can't handle the load. Popular trade hub Jita and several popular mission-running systems such as Dodixie suffer badly from lag at peak play times on the weekend. Massive fleet battles over important territory often suffer from the same crippling lag, turning what should be an amazing sci-fi space battle into a poor slideshow.
하나의 게임 월드에서, 유저들은 스스로 어떠한 태양계를 좋아하더라도, 심지어는 태양계가 있는 서버가 부하를 다룰 수 없을때 조차도 - 랙이 걸렸을때라도? - 무리를 자유롭게 이룰 수 있습니다. 
인기있는 교역 허브인 Jita 와 Dodixie 같은 몇몇 유명한 미션 수행 시스템은 주말 피크 타임에 생기는 랙으로부터 안좋은 영향을 받습니다. 
중요 영역을 넘어 거대 함대들이 전투하는 것은 자주 극심한 랙(crippling lag)으로부터 영향을 받고, 놀라운 SF 전투가 초라한 슬라이드 쇼로 돌변합니다. - 느려진다는 얘기 -

Server structure:
서버 구조:
Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together. These "SOL Servers" are tied into EVE's main database server where changes to the game take place (where the magic happens).
이브 온라인의 5000개 이상의 각각의 항성 시스템은 분리된 프로세스로 수백대의 IBM blade 서버중 하나에 로딩되는데, 
몇몇의 부하가 큰 시스템들은 하나의 서버에 그것들 - 프로세스들 - 모두가 주어지고, 다수의 부하가 적은 시스템들은 결합되어지고 서버들 상에서 함께 수행됩니다. 
이러한 "SOL 서버들" 은 이브 온라인의 (마법이 일어나는) 메인 데이터베이스 서버에 연결됩니다.

Since players need to move between solar systems, they are connected to proxy servers which keep track of which SOL server the player is on. It's an ambitious system buthas worked well for over five years with constant upgrades going on in the background to keep up with the increasing number of players entering EVE daily.
유저들이 태양계 간에 이동을 원하기 때문에, 태양계들은 유저들이 있는 SOL server 의 길을 유지해주는 proxy server 들로 연결되어있습니다. 
야망적인 시스템 - 구현이 어렵다는 내용을 뜻하는듯 - 이지만, 매일 이브 온라인에 접속하는 유저의 증가에 뒤떨어지지 않게 보이지 않는 곳에서 꾸준한 업그레이드를 통해 5년이 넘는 시간동안 잘 동작했습니다.

Effect on PvP:
PvP 에 대한 효과:
You could be forgiven for thinking that an MMO's server model doesn't affect its gameplay significantly but EVE Online has proven this wrong for five years running. Putting all players together in one server drastically increases the opportunity for PvP. Instead of the MMO norm of less than 5,000 potential players for you to interact with and barely 1000 online at peak hours, EVE's server houses over 300,000 players with a peak concurrent user record of over 40,000. Additionally, since there's only one server for all players, there's no option to sign up to a non-pvp version of the game. This puts all players in the same world with the same rules whether they like it or not. If all you want to do is trade, mine and run missions you're just as vulnerable to PvP as everyone else and that's a major factor in defining the harsh feel of the EVE universe.
당신은 MMO의 서버 구조는 게임 플레이에 의미있는 영향을 주지 않는다는 생각에 용서받을 수 있습니다. - 서버 구조가 게임에 중대한 영향을 미치지 않는다고 생각할 수 있습니다. - 
그러나 이브 온라인은 5년간 동작하면서 이것이 틀렸다는 것을 증명했습니다. 
모든 유저들을 하나의 서버에 몰아넣은 것은 철저히 PvP 의 기회를 늘렸습니다. 
당신에게 피크시간에 간신히 1,000명 정도 되고 잠재적으로 5,000명도 안되는 유저와 상호작용 하는 MMO 기준 대신에, 이브의 서버는 피크 시간에 40,000명 이상의 동시접속 기록과 함께 300,000명 이상의 유저에게 장소를 제공합니다. 
게다가, 모든 유저에게 단지 1개의 서버만 있기 때문에, PvP 가 없는 버전의 게임을 선택할 옵션이 없습니다.
이것은 동일한 월드에 있는 모든 유저들에게 그들이 좋던 싫던 동일한 룰을 적용합니다. 
만일 당신이 교역, 채굴, 미션 수행하기만을 원한다면 당신은 다른 모든 사람들에게 PvP 공격을 받기 쉬워질 뿐이고 그것은 이브 온라인 세계의 가혹함을 추정하는 주요한 요인입니다.

If EVE did offer a non-PvP server option, roles such as the pirate or corporate spy wouldn't really be possible any more because most potential targets would be playing on the non-pvp server. The players on the non-pvp server would also suffer from having a duller, less challenging game experience. We'd have one server full of hunters with no prey and one server full of prey with no excitement to their game.
만일 이브 온라인이 non-PvP 서버 옵션을 제공했다면, 해적이나 법인 스파이 같은 역할은 정말 더이상 불가능할 것입니다. 
대부분의 잠재적인 타겟들은 non-PvP 서버에서 게임중일 것이기 때문입니다. 
non-PvP 서버에 있는 유저들은 또한 지루하고 덜 도전적인 게임 경험 - 별로 도전적이지도 않고, 지루해빠진 게임 - 으로부터 괴로워합니다. 
우리는 한 서버가 먹잇감 없이 사냥꾼들로만 가득 차고, 한 서버는 아무런 동요 없이 먹잇감으로 그들의 게임을 가득 채운 적이 있습니다.

Ultima Online experienced this issue in the Renaissance expansion when they released Trammel, a server where non-consensual PvP was no longer possible. With all the cut-throat villains separated from the general population, the villains had nothing to do and the remaining players lost their opportunity to be heroes.
울티마 온라인은 Trammmel 을 릴리즈 할 때 르네상스 확장팩 안의 합의되지 않은 PvP 가 더이상 불가능한 서버에서 이러한 이슈를 경험했습니다. 
모든 극악 무도한 사람들은 일반적인 유저로부터 분리된 채, 아무 할 일이 없었고, 남은 유저들은 영웅이 될 기회를 잃었습니다.

Territorial conflict:
영토 분쟁:
The lack of instancing in EVE Online's game universe has had an even more profound impact on PvP than the lack of a non-PvP server. When a solar system is depleted of resources, is becoming overcrowded or is being camped by pirates, there is no second instance of the system to switch to. The ability to pursue attackers from system to system successfully or to lock down a star system and prevent your enemy from passing through allows for piracy and very real territorial control that just isn't possible with another server model. Conflict over resources and space arises as a natural consequence of gameplay and not from a developer-defined game mechanic. Real player alliances are forged and broken every week in EVE with complex politics behind them.
이브 온라인의 게임 세계에 인스턴스화의 부재 - 여기서는 인던보다는 채널 같은 것들이 없는 경우를 말하는 듯 - 은 non-PvP 서버의 부재보다 PvP 에 더욱 큰 영향을 줍니다. 
태양계의 자원이 고갈되거나, 인구 과밀화 현상이 일어나거나, 혹은 해적이 거주할 때, 변경할 시스템의 또다른 인스턴스가 없습니다 - 빠져나가고 싶어도 빠져나갈 곳이 없다는 얘기인듯 - . 
시스템 전반에 걸쳐 공격자들을 성공적으로 추격하거나 또는 항성 시스템을 차단하고 지나가는 길목으로부터 당신의 적을 방어하는 능력 (혹은 기능) 은 해적행위와 매우 사실적인 영토 통제를 가능하게 하는데, 이러한 것들은 다른 서버 모델에서는 불가능합니다.  
자원과 공간을 넘어선 분쟁이 개발자가 정의해놓은 게임 메카니즘에 의해서가 아니라, 게임 플레이의 자연스러운 결과로 일어납니다. 
실제 유저 동맹들은 이브 온라인의 동맹들 뒤의 복잡한 정치관계 때문에 매주 조약이 맺어지기도 하고 깨지기도 합니다.

Economic impact:
경제적 효과:
EVE is often lauded for its realistic player-based economy and real working markets but neither of these would function well on a sharded server. Throwing all of the players together in one place forces the markets to act based heavily on the rules of supply and demand. Without enough players driving both sides of the supply and demand curve, a single player could interfere with the global market very easily for a very long time. This has been done before in games like World of Warcraft to manipulate prices for a profit. It worked because with so few players on each server, one particularly rich player's effect on the market can be proportionally massive.
이브 온라인은 리얼한 유저 기반의 경제와 정말 활성화된 시장 (working market) 에 의해 자주 찬사를 받지만, 둘 중 그 어떤것도 샤드로 이뤄진 (sharded) 서버에서는 그 기능을 제대로 발휘하지 못합니다. 
한 곳에서 모든 플레이어가 함께 던지는(?) 것은 시장이 수요와 공급의 법칙에 크게 기반을 두고 행동하도록 강요합니다. 
수요와 공급 곡선의 모든 측면을 주도하는 충분한 유저 없이는, 단일 유저가 전체 시장 (global market) 에 매우 긴 시간동안 매우 쉽게 간섭할 수 있습니다. 
이것은 World of Warcraft 같은 게임에서 수익을 내기 위해 가격을 조정하는 것으로 이미 발생된 적이 있습니다. 
각 서버의 매우 적은 유저들 사이에서 특정 부유한 유저의 시장에서의  영향은 규모에 비례할 수 있기 때문에 (시세 조작 같은) 그런 일들이 가능했습니다.

In EVE's safer systems, even major price manipulations tend to be balanced out by other players in a matter of hours, making price manipulation in trading hubs a very expensive and risky venture. It's said that the number of players in EVE caused the markets to hit critical mass long ago, reaching a point where high demand is almost always met by players with adequate supply within reasonable time-frames. As a result, the game's market hubs are always stocked full of whatever you might need.
이브 온라인의 보다 안전한 시스템에서 심지어 교묘한 주요 시세 조작조차 다른 유저에 의해 몇시간 내로 조절되고, 교역 허브에서 시세 조작을 하는 것을 매우 비용이 크고 위험한 모험으로 만드는 경향이 있습니다. 
이브온라인의 많은 유저가 오래 전부터 시장이 바라는 합당한 시간 이내에 높은 수요가 거의 항상 충분한 공급과 함께 유저들에 의해 만족 되는 지점에 도달하는 결과를 낳도록 야기했다고 합니다. - 많은 유저가 진정한 시장 경제를 이룰 수 있게 했습니다. - 
결과적으로, 게임의 시장 허브는 당신이 원하는 그 무엇들로 가득히 항상 판매할 상품을 갖춰두고 있습니다.

Upgrades:
개선:
CCP recently encountered a problem they hadn't seen since late 2005. Certain server nodes were running out of memory, filling up with legitimate user data and crashing. Their response has been a controversial change to introduce player limits to star systems under heavy load. Although this was changed to only affect trade hub Jita for now, it highlights hardware inadequacy that CCP are meeting head-on with another round of server upgrades. The current server hardware uses impressive processors and advanced solid-state RAMSAN disks with the fast access speeds and large storage capacity that EVE's servers require.The bottleneck at the moment is getting data from one processor or ram disk to another and this is where their latest project comes in.
CCP 는 최근 2005년도 이후로 본적없는 문제에 부딪혔습니다. 
특정 서버 노드들은 메모리가 부족해지고 적법한 유저 데이터로 채워지고 크래쉬되고있었습니다. 
그들의 응답은 과부하 하에 있는 항성 시스템의 유저 한계를 보여주는(introduce) 논란을 일으키는 변화였습니다. 
비록 이것은 현재 교역 허브인 Jita 에서만 영향을 주도록 변화했지만, 그것은 CCP 가 서버 업그레이드의 또다른 라운드에 정면으로 맞딱들이는 하드웨어적인 불충분을 드러냈습니다 (highlights). 
현재의 서버 하드웨어는 굉장한 프로세서들과 선진화된 빠른 접근속도와 이브 온라인 서버가 요구하는 큰 스토리지 용량을 가진 solid-state RAMSAN 디스크를 이용합니다. 
바로 지금 병목은 어느 한 프로세서 또는 램디스크로부터 다른 곳으로 데이터가 옮겨지는 것이고 이러한 동작은 그들의 최근 프로젝트에서 도입했습니다.

CCP aims to link the processors and RAM drives of every SOL server together with high-speed low-latency "Infiniband" technology, allowing data transfer at rates of several gigabytes per second. This will allow any processes which can be threaded to be split off and run on a processor that's not being used heavily at runtime, which should massively increase the server's load-balancing ability. The infiniband project poses a huge task for EVE's programmers, who are in the unenviable position of having to rewrite large portions of the core server code. If all goes well with their internal infiniband tests, these major changes in server architecture could eventually spell the end of laggy fleet battles and node crashes. 
CCP는 모든 SOL 서버의 프로세서들과 램드라이브들을 high-speed low-latency의 매초 수 기가바이트의 전송률로 데이터를 전송할 수 있는 "Inifiniband" 기술로 함께 연결하는 것을 목표로 합니다. 
이것은 스레드화 될 수 있는 모든 프로세스들이 나눠지도록 할 것이고 runtime에 심하게 사용되지 않고 있는 프로세서 위에서 실행 될 것인데, 이는 서버의 로드밸런싱 능력 (기능) 을 크게 향상시킬 것입니다. 
Infiniband 프로젝트는 핵심 서버 코드의 많은 부분을 다시 작성해야만 하는 (할 일이 많아서) 별로 부럽지 않은 이브온라인의 프로그래머들에게 커다란 작업을 제기합니다. 
만일 그들의 내부 Infiniband 테스트를 통해 모든 것이 괜찮아진다면, 서버 구조의 주요한 변경은 결국에 랙이 있는 선단 전투와 노드간 크래쉬를 종식 시킬 수 있을 것입니다.

Summary:
요약:
With the problems CCP are constantly facing with their server and the cost of its upkeep, other developers seem reluctant to take EVE Online's server model on board. However, this model affects a lot more than its running costs and complexity and may be practically required for any successful next-generation PvP based MMO. It makes avenues of gameplay such as meaningful politics, piracy and real territorial warfare not just a possibility but an unavoidable consequence of group play. Could the single server approach become commonplace in the next generation of PvP-based MMO? I, for one, hope it does.
문제들과 함께 CCP 는 지속적으로 그들의 서버와 유지 비용에 직면하고 있습니다. 
다른 개발자들은 마지못해 이브 온라인의 서버 모델에 승선한것처럼 (서버 구조를 채택했다는 내용) 보입니다. 
그러나, 이 모델은 그것의 유지 비용과 복잡도보다 많은 영향을 끼치고 사실상 다른 성공적인 차세대 MMO 기반의 PvP 를 위해 필요할지도 모릅니다. 
그것은 가능성이 아닌 집단 플레이의 불가피한 결과로의 의미있는 정치, 해적행위 그리고 진정한 영토 전쟁 같은 게임 플레이의 방향을 만듭니다. 
MMO 기반의 PvP 의 다음 세대에서는 단일 서버 접근방식이 당연한것이 될 수 있을까요? 
그렇게 되길 빌어봅니다.

Compiling...
cl : Command line error D8003 : missing source filename



위와같은 메시지를 만났습니다.
소스 파일 이름이 그리워..???
3초 생각해보다가.. 구글링 시도!



http://www.windows-tech.info/17/1860b7c3c6ce2b18.php



중간에 이런 글이 나온다


Re: Visual C++ General cl : Command line error D8003 : missing source filename

Viorel. 



From the displayed command line, it probably has an unneeded quotation mark. I would first advise to go to project properties -> C/C++ -> Preprocessor -> Preprocessor Definitions and ensure that Preprocessor Definitions field does not contains unneeded quotation marks and other accidental characters, in both Debug and Release configurations.


Can you check or show us the Preprocessor Definitions field


See also: http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=2356968&SiteID=1.








See also 로 링크가 보이길래 얼른 눌러봤지만, 링크는 Bad Request 를 보여주기만 할 뿐.. -_-;








그런데 글 내용을 자세히 보니, 







==> 아마도 불필요한 인용부호 ["] 가 있을거다. 속성 -> C/C++ -> Preprocessor -> Preprocessor Definitions 에 가서 Debug와 Release 설정 모두에, 불필요한 인용부호나 오타같은게 있는지 확인해보라







라고 되어있습니다.


열어봤더니.. Additional Include Directories 에 따옴표가 있는......


지우고 다시 해봤습니다.


잘 되네요 ^^
원문 : http://stackoverflow.com/questions/136752/how-do-you-make-stackwalk64-work-successfully-on-x64


I have a C++ tool that walks the call stack at one point. In the code, it first gets a copy of the live CPU registers (via RtlCaptureContext()), then uses a few "#ifdef ..." blocks to save the CPU-specific register names into stackframe.AddrPC.Offset, ...AddrStack..., and ...AddrFrame...; also, for each of the 3 Addr... members above, it sets stackframe.Addr....Mode = AddrModeFlat. (This was borrowed from some example code I came across a while back.)

With an x86 binary, this works great. With an x64 binary, though, StackWalk64() passes back bogus addresses. (The first time the API is called, the only blatantly bogus address value appears inAddrReturn ( == 0xFFFFFFFF'FFFFFFFE -- aka StackWalk64()'s 3rd arg, the pseudo-handle returned by GetCurrentThread()). If the API is called a second time, however, all Addr... variables receive bogus addresses.) This happens regardless of how AddrFrame is set:

  • using either of the recommended x64 "base/frame pointer" CPU registers: rbp (= 0xf), or rdi (=0x0)
  • using rsp (didn't expect it to work, but tried it anyway)
  • setting AddrPC and AddrStack normally, but leaving AddrFrame zeroed out (seen in other example code)
  • zeroing out all Addr... values, to let StackWalk64() fill them in from the passed-in CPU-register context (seen in other example code)

FWIW, the physical stack buffer's contents are also different on x64 vs. x86 (after accounting for different pointer widths & stack buffer locations, of course). Regardless of the reason, StackWalk64() should still be able to walk the call stack correctly -- heck, the debugger is still able to walk the call stack, and it appears to use StackWalk64() itself behind the scenes. The oddity there is that the (correct) call stack reported by the debugger contains base-address & return-address pointer values whose constituent bytes don't actually exist in the stack buffer (below or above the current stack pointer).

(FWIW #2: Given the stack-buffer strangeness above, I did try disabling ASLR (/dynamicbase:no) to see if it made a difference, but the binary still exhibited the same behavior.)

So. Any ideas why this would work fine on x86, but have problems on x64? Any suggestions on how to fix it?


Given that fs.sf is a STACKFRAME64 structure, you need to initialize it like this before passing it to StackWalk64: (c is a CONTEXT structure)

  DWORD machine = IMAGE_FILE_MACHINE_AMD64;

  RtlCaptureContext (&c);

  fs.sf.AddrPC.Offset = c.Rip;

  fs.sf.AddrFrame.Offset = c.Rsp;

  fs.sf.AddrStack.Offset = c.Rsp;

  fs.sf.AddrPC.Mode = AddrModeFlat;

  fs.sf.AddrFrame.Mode = AddrModeFlat;

  fs.sf.AddrStack.Mode = AddrModeFlat;

This code is taken from ACE (Adaptive Communications Environment), adapted from the StackWalker project on CodeProject.


FWIW, I've switched to using CaptureStackBackTrace(), and now it works just fine.


Link : http://www.rri-usa.org/Deobfuscator.pdf
블럭을 굴려서 원하는 곳으로 옮기는 일종의 퍼즐 게임

http://img.flashgame.co.kr/flashgame/park13/872.swf

초반에는 Password 가 있는지도 모르고 하고 있다가 나중에 발견하고 적기 시작했습니다 ㅋㅋ

13 - 448106
14 - 210362
15 - 098598
16 - 000241
17 - 683596
18 - 284933
19 - 119785
20 - 543019
21 - 728724
22 - 987319
23 - 293486

Windows XP Professional x64 Edition 에서 열심히 Visual Source Safe Automation 기능을 이용해서
C#으로 툴을 만들고 실행을 했더니만..
계속 VSSDatabase 를 new 하는 곳에서 COMException 발생..
뭐 이런게 다있나 싶어서 Registry 에 등록된 정보도 수정해보고.. regsvr32도 다시해봤으나.. 모두 무산!
결국엔 이런 문제였다는걸 알고 가슴이 좀 아프긴 했으나 얼른 수정해서 돌려보았습니다.

글에 등록되어 있는 링크들은 현재 페이지를 참조하지 않고 있으니, 참고하시기 바랍니다.
누르면.. 바로 kbalertz 로 날아갑니다~~~

Link from : http://kbalertz.com/952691/Automation-fails-Windows-Operation-System.aspx

Microsoft Knowledge Base Article

This article contents is Microsoft Copyrighted material.
©2005-©2007 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks
Article ID: 952691 - Last Review: May 5, 2008 - Revision: 1.1

VSS Automation code fails on 64-bit Windows Operation System

View products that this article applies to.
Expand all | Collapse all
Source: Microsoft Support
Back to the top

RAPID PUBLISHING

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.
Back to the top

Action

You are using Visual Studio 2005 or Visual Studio 2008 to develope an application that implements Visual SourceSafe automation.
Back to the top

Result



You find that the code compiles on a 32-bit Windows operating system but fails on a 64-bit Windows operating system with the error:

Retrieving the COM class factory for component with CLSID {783CD4E4-9D54-11CF-B8EE-00608CC9A71F}
failed due to the following error:  80040154
Back to the top

Cause

The code in Visual Studio was compiled in 64-bit by default. Visual SourceSafe is a 32-bit application; therefore, you get an error.
Back to the top

Resolution



Alter the build parameters of Visual Studio to build the code in 32-bit.  To make this change, do the following:
  1. Choose Build from the menu then click Configuration Manager.
  2. Change Active Solution Platform to <New>. 
  3. Change "Type or Select the new platform" to x86 in the New Solution Platform dialog.
  4. Recompile the code project.
Back to the top

More Information



Compiling a simple VS 2005 Visual Basic .Net console application with this code demonstrates the problem:

Module Module1
Sub Main()
Dim vssDatabase As New VSSDatabase
Dim vssProject As IVSSItem
End Sub
End Module
Back to the top

DISCLAIMER

MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE “MATERIALS”) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.
Back to the top
APPLIES TO
  • Microsoft Visual SourceSafe 2005 Standard Edition
  • Microsoft Visual SourceSafe 6.0d
  • Microsoft Visual SourceSafe 6.0C

+ Recent posts

티스토리툴바