제 1회 Paper Meeting에 여러분을 초대합니다.
기존의 단방향 세미나에서 탈피해, 새로운 형태의 모임을 만들었습니다.
하나의 Paper를 선택하시시면, 여러분과 동일한 Paper를 선택하신 분들과 조를 나누어 토론/지식 공유 모임을 하고
맨마지막 조별 10분식 자신의 조가 나누었던 애기들을 마인드 맵 형태로 정리해서 나누는 유익한 세미나 입니다.
좀더 자세한 정보및 등록은 http://www.onoffmix.com/e/only2u4u/149 에서 얻으실수 있습니다.
소프트웨어의 현재 상태를 모니터링하거나, 오류시 원인을 파악하기 위해 Log를 남기실 겁니다. 많은 분이 Log4J , Log4NET을 이용하십니다.
하루에 쌓이는 엄청난 로그양때문에, 골치 아프신 경험이 있다면 이 논문을 꼭 읽어 보시길 바랍니다.
이 패턴은 Logging 데이터의 Overflow를 막기 위해 우리가 어떻게 해야되는지 접근 법을 설명하고, Log4XXX(.NET, Java …) 의 내부기능과 비교하여 설명을 합니다.
호환성 (Compatibility) 이라는 말을 들어보셨나요?
- .NET 3.0 버젼 Framework에서 .NET 2.0으로 구현했던 Application이 돌아가지 않는다면?
- JDK 1.6버젼에서 JDK 1.4 Framework 기반의 Application이 돌아가지 않는다면?
새로 나온 제품이 아무리 좋은 기능이 많이 추가 되어 있더라도..예전 제품과 호환이 되지 않는다면, 그 제품은 잘 팔리지 않을 겁니다. 이번 POST 를 통해 우리가 Product 또는 Framework을 만들때 고려해야 되는 호환성과 여러가지 종류에 대해서 공유하고자 합니다.
혹시 소프트웨어를 만드실때, 땅콩버터 방식으로 만드시지는 않나요?
땅콩 버터라는 것은 Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스를 말합니다.
Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들때 주로 사용하는 방법입니다.
이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올수 있는 장점이 있습니다. 마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저수준의 Library를 개발할때는 이러한 방식이 선호 됩니다.
만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야하고, 다양한 시나리오를 요구하는 경우인데도, Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 국내의 많은 회사들이 이러한 구조를 가지고 있는데요. 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될뿐만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제등이 발생됩니다.
여러분에게 좋은 소식을 하나 전해드리고자 합니다.
POSA2에 이어 또 하나의 명서인 Framework Design Guidelines 2nd Edition의 편역을 위한 모임을 가졌습니다.
이 책은 Framework를 잘 설계하기 위한 Guideline을 제공하는 서적으로 Microsoft의 .NET Framework 설계팀들이 직접 집필한 서적입니다. Framework을 처음 설계하는 개발자에게는 매우 유용한 서적이 될듯 합니다.
현재 http://fdg.springnote.com 에서 작업을 시도하고 있으면, 저희 스터디시 만들어진 가치있는 공유물들을 여러분과 함께 나눌 생각입니다.
Conway’s law (콘 웨이의 법칙)
If you have four groups working on a compiler, you’ll get a 4-pass compiler
당신이 하나의 컴파일를 만들기 위해 4개의 팀을 만든다면, 당신은 4단계(four-pass) 컴파일러를 얻을 것이다.
이 말은 시스템의 구조는 시스템을 설계한 조직의 구조(형태)를 그대로 반영한다는 것입니다. 보면 볼수록 묘한 감정과 예전 기억들이 떠오르는 법칙입니다.
성공적인 회사생활을 하기 위해서는 순수한 개발 능력외에 많은 변수들이 우리를 따라 다닙니다.
- 사내 정치에 승리하기 위한 명분 만들기
- 서로간의 책임을 회피하기 위한 일 덜 가져오기
- 영업 / 기획 / 개발 부서 간의 대화 단절
- 직급 문화가 가져오는 대화의 단절 (상명하복의 의사 전달)
Microsoft Architecture Journal 15권이 발간 되었습니다.
Microsoft는 Architecture에 관한 다양한 소재들을 모아 분기마다 잡지를 만들어 배포하는데요. 비 Microsoft 기술에 대한 Article들이 더 많은 편이니 플랫폼에 관계없이 아키텍쳐에 관심있다면 꼭 한번 보시길 권해드립니다.
MSDN Architecture Journal 에서 이전 버전을 무료로 다운 받으실수 있으며, 저의 예전 블로그에서는 각 이슈를 한글로 간단히 소개했습니다.
저 역시 많은 경험이 없지만 10년이란 시간 동안 IT에 몸 담아온바 오랜만에 비 기술지향적인 애기들을 함으로써 후배 개발자들에게 몇가지 조언을 하고자 합니다.
제가 본업을 가지고 있으면서도 무료 세미나에 스피커로 활동한지도 5년이 다 되어 갑니다. 항상 신기술, 변화의 중심에 서 있을려고 노력했습니다. 하지만 많은 시간이 지난후 과거를 되돌아 보니, 너무 신기술만 바라보는 바보같은 생활을 하지 않았나 생각이 듭니다.
꿈을 찾아 당장 하고 싶은 재미난 흥미위주의 공부와 스터디를 해왔고 이것들이 나쁜 것들은 아니지만, 좀더 균형잡인 시선과 시각으로 기술을 이해하길 바라며 이러한 것들이 매우 중요하다는 것을 공유하고자 합니다.
늦은 Summit 후기네요. Summit의 꽉꽉찬 스케줄로 인해 이제셔야 포스팅을 올립니다.
행사 둘째/셋째날은 직접 Visual Studio Team System (VSTS)을 만든 개발자들과의 세미나, 미팅, 회의 시간을 가지는 날입니다. VSTS 관련 제품의 신기능과 이야기를 알려드리고 싶지만.. 내부 기밀이라 어떻게 말씀드릴수가 없네요. 기밀 사항을 외부로 알려 미국 MVP중 한명이 벌써 제명되었다고 합니다. 아쉽게도 여러분에게 드릴수 있는 말씀은 놀라운 기능들이 추가되었기 때문에, 정식 버젼을 기대하라는 말씀 밖에는 드릴수 밖에 없을듯 합니다.
대신 이 글을 통해서 Microsoft의 내부 개발자들, 환경, 문화에 대해서 언급하고자 합니다. 구글이 최고의 식사, 문화 환경을 제공한다면 Microsoft는 최고의 개발 환경을 제공합니다.
Architecture 101 