이번 저자 워크샵은 정말 힘든 강행군의 연속이었습니다.

PLoP 2011의 의장인 Lise Hvatum 과 2일에 거쳐 패턴을 같이 다듬었습니다. 사실 이번 PLoP에는 저희가 바쁜 일정에 논문을 잘 쓰지 못해서 논문을 같이 다듬는 Writing Group으로 배정을 받았는데, 오히려 많은 것을 배운거 같습니다.

같이 논문을 써준 김 지원님이 같이 간 덕분에 외롭지 않고, 이래 저래 정리한 내용도 2배로 늘어났습니다.

결과적으로 좀더 Clear하게 그리고 Simple 하게 전체적으로 패턴을 바꾸었습니다. 첫째날 차 유리가 깨지고 지원이가 노트북을 읽어 버리는 바람에 사고 수습하느라 하루가 날라가 버리고, 남은 2일동안 강행군을 펼쳤고, 마지막날 새벽 4시에 겨우 마쳐서 최종본을 보냈슴니다.

지원가 맘고생도 많았지만, 이 잃어버린 노트북만 아니였어도.. 이렇게 고생을 하지않았을 텐데… 마지막날에 발표한 자료가 pdf 로 변환하면서 몇몇이 깨져버려 이래 저래 고생을 가장 많이한 PLoP 입니다.

Lise에게 보여주니, 새벽 4시에 온 메일을 보고 놀랐다고,정말 용감했다고 하더라구요! 좀더 명확하고 간결해졌다고 피드백을 받았습니다.

저자 워크샵
저자 워크샵이 무엇인지 모르시는 분은 제가 일전에 포스팅 한 저자 워크샵 데모 포스트를 보시고읽어보시면 좋을듯 합니다.

(중앙에 있는 분이 PLoP 11 Chair이자 , 저희 논문 Shepherd였던 Lise Hvatum , 그리고 오른쪽에 있는 분이 AsianPLoP의 리더이자, 와세대 대학의 조교수이신 Hironori Washizaki 입니다.)

실제 저희 워크샵에서 받은 내용을, 지원이가 잘 정리해 주었습니다.  추후 mp3를 듣고 더 업데이트 할 생각입니다.

시작 :

저자가 일어나서 자신의 패턴을 잘 소개할 수있는 문장을 읽습니다. 지원이가 Introduction 에 있는 한 문단을 통째로 읽었습니다.

Fly on the wall :

이제 저자가 “벽위의 파리” 가 됩니다. 아무런 발언권도 없고 모여 있는 사람들이 패턴을 어떻게 이해하는지만 볼수 있습니다.

칭찬:

논문에 대한 긍정적인 점을 먼저 말합니다.

• 논문의 구조가 패턴 템플릿에 맞춰 아주 잘 잡혀 있다.
• 그림이 잘 들어가 있다.
• 학생들의 연구의 자료가 아닌, 업계에서 사용되는 기술을 공유해 줘서 가치가 있다.

하지만 나중에 그림이 혼돈스럽다고 피드백을 많이 받았습니다. ^^;;

개선 :

Design 그룹의 좌장이신 Bob Hanmer가 조정자가 되어 한 페이지씩 읽어가며 피드백을 받습니다.

• Introduction

인트로덕션에서는 실제 세계에서 쓰이나 너무 범위가 크다. 그건 실제로 받아들여지기 어렵다. 변경은 비즈니스 요구사항에서 올것이다.

리사: 키워드는 단지 용어에 가깝다. terminology. 한-영에 도움을 주기 위해서 필요.
pull, poll 은 같은것인지. 헷갈린다. concept에서..

앙드레 : 3인지 2패턴의 조합인지 헷갈린다. 그림 및 내용이 너무 크다. 레퍼런스로 밀어버릴 수 있다.

히로 : 어디에 이벤트가 발생하고, 저장되는가. 그림 1은 있으나, 그림 2에는 없다.
앙드레 : poll은 지가 알아서 체크하니 그런거 필요없다.

• context

핸머 : 일종의 예 섹션
앙드레 : 위치에 대한 것이 context이고 building은 예. 핸머 context result 섹션은 없다. / wired, wireless 는 중요하나? 왜 언급했나? 너무 자세한 부분으로 뛰어 들어 갔다.
리사 : 그냥 connected면 오케이,
앙드레 : 맞다
리사 : 근데 전략 선택에서는 중요 요소일 수 있고 ,하나의 조건거리로 생각할 수 있다.
앙드레 : 다양한 면을 보여주지만, 너무 커서 뭔가 재사용에 대한 것을 생각하기 힘들다.

• problem section

앙드레 : 분산은 좀더
A : consistency
B : …
요런식으로

알렉스 software updates? 어떻게 분산시킬래? 헷갈린다.
리사 백그라운드가 필요하다
히로 : 다중 클라이언트가 들어간다.
하나의 클라이언트? = 디바이스들의 모임?
디바이스가 뭔가?,
PC? 모바일? 타입?
뭐든지 생각해볼수 있다.

• forces

알렉스 : 이미 설치되고 있다는 거냐? 그냥 사용할 소프트웨어라는 거냐?
알렉스, 언어표현이 좀 그렇다.
리사: 번역하면 그렇더라
히로 : composing이 어떤 의미인가?
핸머 : 하이브리드다.
앙드레 : 컴포지팅이 헷갈린다. push, polling을 그냥 복합시킨다는게 애매하다.
이게 negative인지 모르겠다?

• solutions

Ticket 이 업그레이드를 표현하는 적합한가?
히로 : 누가 Ticket을 만드나?
아마도 정책이거나, 뭐 그런거 같은데. 내가 직접 하나?
앙드레 : 이름은 이 도메인에서 쓰이나?
리사 : 처음으로 쓴 용어다. 근데 도메인에서는 일반적이다.
히로 : 프로젝트 서비스 관리에서,
앙드레 : 좀더 큰 영역에서 사용될 수 있나?
핸머 : 여행 티켓팅 시스템을 생각해 볼 수 있지 않나?
리사 : 작업관리와도 같다.
앙드레 : 여전히 헷갈린다.
서비스 팩.
이해하는데 좀 시간이 걸린다.

• structure

히로 : 채널이 어디있는지 부정확하다.
다중 채널은 어떻게 되나?
앙드레 : uml인가? 아니면 custom인가?
알렉스 : 이게 얼마나 큰건지 모르겠고 역할도 잘 모르겠다. 특히 티켓 메니져는 뭐하나?
앙드레 : 이름과 설명이 없다.
알렉스 : 누가 채널 만드나?, 티켓을 만드나?

• dynamics

알렉스 : 왜 이게 필요한가?
채널이 하는게 어디갔나?
앙드레 : behavior가 더 낫지 않나?
히로 : 서버사이드만 있다. client사이드는 어디있나? 핸머 : 맞다
갭이 있다.

• known use and variations.

리사 : 레퍼런스로 가는게 좋지 않나? 실제 쓰는지 잘 모르겠다. 메인스트림에서 말이지.

• consequences

리사 : advantage는 좋다.
히로 : 제안 : 어떻게 이 패턴이 각각의 forces를 해결했는지. 매칭시키면 좋겠다.

핸머 : 글치

• related patterns

핸머 : 다른 패턴과 무슨 관련이 있는지 알겠다. 내 산업군에서는 이런걸 많이 해서, 쓰기에 좋다. 좀더 명확히 할 수 있겠다.

Welcome Back

피드백 주기가 마치면, 이제 저자가 다시 대화를 할수 있습니다.
먼저 감사의 말을 하고, 피드백중 궁금한 것이 있으면 물어볼 수 있습니다.

감사의 박수

그리고 마치면 나머지 저자들이 좋은 패턴을 만들어 준것에 감사하며, 박수를 치며 저자 워크샵을 마무리 합니다.