PLoP 첫번째 날인 오늘은 매우 재미나고 신나는 하루였습니다.
오늘 말로만 듣던 Writer’s Workshop을 직접 체험한 날이였습니다. 하나는 참가자의 역할로 또 하나는 저자의 역할로 진행을 했습니다. 행사가 시작하기 이전에, PLoP의 대표자들이 모여 진행한 Writer’s Workshop 을 어떻게 진행하는지 설명하는 데모 사진을 찍어보았습니다. 김창준 님이 이미 공개한 내용이지만, 그래도 직접 사진과 보시는게 좋을듯 해서 올려드리도록 하겠습니다.
PLoP에서 참가자는 크게 세 부분으로 나뉩니다. 저자, 참가자, 그리고 행사를 진행하며 조정하는 조정자입니다.
PLoP이 시작 하기 전에, Pre Conference 행사로 BootCamp가 매년 열립니다. BootCamp는 패턴을 올바로 이해하고, 올바른 패턴을 만드는 방법을 전수하기 위한 목적이 있습니다. 위 그림 처럼 패턴을 만들어 보고, 서로간의 의견을 주고 받으면서 점진적으로 패턴을 완성해 나갔습니다.
주제는 자전거 경주에서 승자가 되는 패턴인데. 신선하고 재미있었습니다. 이러한 패턴을 잘 만들기 위한 가이드라인을 알고 있었던 것이지만, 직접 누군가와 같이 애기하면서 패턴을 만들어 나간다는게 흥미로웠습니다. 짧은 영어로 인해 후배녀석한테 물어보면서 눈치껏 듣느라 🙂 고생했지만, 좋은 경험이었습니다. 올바른 패턴을 만들기 위한 Pattern Template을 간략히 요약해 나누어 주셨는데, 나중에 집에가서 스캔해서 올리도록 하겠습니다.
오늘 BootCamp행사 도중 깨달은 몇가지를 나누고자 합니다. PLoP의 정신을 이해하는 행사였다고 봅니다.
PLoP에 참여하기 위해 드디어 시카고로 갑니다. 꿈꿔왔던 일을 하나 하러 가네요 :).
행사 중간 중간 사진을 찍어가면서, 경험했던 내용들을 여러분하고 공유하도록 힘쓰겠습니다.
굳이 이 분이 누군지 말 안해도 다들 아실겁니다. 🙂 바로 Grady Booch 입니다. UML을 탄생시킨 3인방 중에 한명이며, 지금의 소프트웨어 공학에 지대한 영향을 끼치신 분이죠 .
Grady Booch의 끊임없는 지적 호기심을 보여주는 좋은 사이트가 있어서 소개합니다.
바로 Handbook of Software Architecture 라는 사이트 입니다. 아마 아실 분은 다 아시겠죠 :). 여기에 Pattern들에 대한 보물이 숨겨져 있습니다.
바로 지구상에 발표된 패턴들을 잘 요약해 놓고, 적절하게 다양한 관점으로 분류하고 잘 요약정리해 놓았습니다. 단순히 GoF, POSA, PLoP 에 나온 분류 보다 훨씬 자세하게 잘 분류되어 있고, 지구상에 많은 패턴을 끊임없이 요약 정리하고 계시다니.. 대단하시네요. 저도 나름대로 분류 작업을 진행해야 겠네요 🙂
드디어 PLoP에 제출한 논문이 Published Paper List에 올라왔습니다. 이거 감회가 무척 새롭네요. 제 블로그를 통해서 제가 직접 만든 패턴을 소개하다니… 여튼 신선하고 기분 좋은 일입니다 🙂
패턴의 이름은 Half-Push / Half-Polling 입니다. (눈치있는 분은 아시겠지만 작명은 “Half-Sync/Half-Async”에서 얻어왔습니다. 🙂 )
패턴의 주 아이디어는 Upgrade시 일반적으로 사용되는 두가지 기법(Push 방식 과 Polling 방식)을 혼합하여 장점은 살리고 단점은 제거한 패턴입니다.
여러분!! 인기 있는 Framework를 만들고 싶으신 가요? 저 역시 그렇습니다.
인기 있는 Framework를 만들기 위해 Framework Design Guidelines에서 나온 내용(.NET Framework 설계자인 Krzystof Cwalina의 조언)들을 일부 여러분과 공유하고자 합니다.
- 사용성 테스트
- 점진적인 학습 곡선
- 캡슐화의 오해
이번 포스트에서 다룰 주제는 이렇습니다. 자 그럼 하나씩 살펴 보도록 하죠 🙂
꿈을 찾아 달리는 두 청년을 소개합니다.
아시는 분들은 다 알겠지만요. 워낙 유명해 져서 🙂 바로 이번 Imagine Cup에서 우승을 거머쥔 영웅들 중 두명 (오른쪽 신상, 중간 동훈)입니다. (자세한 정보는 위 링크를 따라 류한석 님의 Smartplace를 방문해 주시면 될듯 합니다.)
사실 작년에 제가 멘토로 Imagine Cup에 같이 참석했지만, 아쉽게 국내 2위로 쓰디 쓴 잔을 마셔야 했습니다. 그때 1위를 했으면 하며 아쉬움이 너무 많았었는데…
Design Patterns의 GoF중 한 사람이자, Framework의 대가인 Ralph Johnson이 내한 합니다.
이번 방문과 함께, Korea Spirng User Group의 안영회님께서 수고해 주셔서 세미나를 여시네요.
비록 5만원의 유료 세미나지만, Ralph Johnson과의 점심 시간도 가질 수 있고, 세미나 정보도 알차니, 참여하시면 매우 값진 것들을 얻으리라 믿습니다.
관심 있는 분은 꼭 참여하셔서 Ralph Johnson의 경험과 지식을 얻어가시길 바랍니다. 자세한 정보는 안영회님에게 요청해주세요!
건축가에 배워야 하는 교훈들을 여러분과 공유하고자 합니다.
“아키텍쳐는 사회적 행동과 인간 활동의 중요한 극장이다. — Spiro Kostof”
명시적, 주도적, 기술적으로 자신의 배역(역할)을 아는 아키텍트가 얼마나 있을까요? 오히려 소프트웨어 아키텍트는 이해 당사자 (stake-holders) 사이에서, 서로 의견이 충돌이 발생하는 파벌들의 중재인, 중개인, 조정자 이지 않을까요?
소프트웨어 아키텍트의 일 중 인적 요소(human-factor)에 적절한 가중치를 부여하지[1] 않고, 순수하게 지적인 정신(소프트웨어 설계)을 요구하는 일이 얼마나 있을까요?
위대한 아키텍트는 머리가 아니라 노력과 풍요로운 마음으로 만들어진다. — Frank Lloyd Wright
여러분 조직에서, 아키텍트 선발 기준은 무엇입니까? 순수한 지적인 능력, 유사한 문제를 겪어봤고, 문제를 간단하게 정리하고(정제), 기술적으로 상세부분까지 기억해 내는 방대한 지식 또는 경험, 그리고 너그러운 마음? 당신은 어떤 분위기에서 일 하는 것이 좋은 가요?
일반적으로 알고 있는 것 과 달리, Namespace의 주 목적은 같은 이름을 가진 타입들의 충돌을 해결하고자 하는 것이 아니다
Namespace의 주 목적은 응집력 있고, 쉽게 찾을수 있으며, 쉽게 이해할 수 있는 계층구조로 타입들을 구성하는 것이다.
하나의 프레임워크 안에 타입 이름의 충돌은 조잡한 디자인을 나타낸다고 생각한다.
동일한 이름을 가진 타입들은 더 나은 통합을 위해 라이브러리의 특정 부분들을 합치거나, 코드의 읽기와 검색을 향상시키기 위해서 새로운 이름을 할당하는 것이 좋다.
출처 – Framework Design Guidelines 2nd Edition.
Architecture 101 