분산 (네트웍 ) 기반의 시스템에서 성능 측정시 고려해야 되는 사항들은 어떠한 것들이 있을까요?
서버나 네트웍 기반의 어플리케이션 구축을 업으로 삼고 있는 프로그래머라면 참고하시면 좋은 그림을 발견해 공유합니다.
위 그림을 눌리시면 큰 그림을 다운 받으실 수 있습니다.
2월 기고에 이은 Framework Engineering Part II를 여러분에게 공개합니다.
Part I에 대한 글에 대한 평이 없어서? 과연 좋은 글을 썼는가 다시 의문을 가집니다. 😦
.NET 진영은 Java 진영보다직접 Framework를 구축하는 일 보다는, 사용하는 일이 더 많으니 그러겠지 하고 혼자 생각하고 있습니다. 🙂
여기서 소개한 툴들과 거의 일대일 대칭이 되는 툴들이 Java 진영에도 있으니 Technic 적인 측면보다, Framework를 구축할때 어떠한 것들을 고려해야 되는지 경험과 프로세스 측면에서 저희들의 부족한 글을 이해해 주시길 부탁드립니다.
많이 부족한 지식이지만 조금이나마 다른 분들에게 도움이 되는 글이였으면 좋겠네요 🙂
이번 글은 지난호에 이어 아래의 주제들중 아키텍쳐에 다 못다한 애기부터 다루었습니다.
Pattern이라는 분야에서 GoF의 Design Patterns가 가지는 의미는 굳이 말을 하지 않아도 될듯 합니다.
몇몇 지식 계층들을 위한 학회에서나 애기되어지고 있는 Pattern들을 일반인들에게 알리는 신호탄 같은 존재이기 때문입니다.
예전 블로그에 올린 글이지만, 패턴을 공부하시거나 접하시는 분에게는 꼭 필요한 내용이라 재 포스팅 합니다.
이 포스트를 통해서 Design Pattern의 두번째 원칙에 대한 오해들을 여러분과 공유하고자 합니다.
문제가 되는 두번째 원칙을 보도록 하죠. 🙂
Favor Object Composition over Class Inheritance
이 말의 의미는 원문 그대로 해석을 한다면 클래스 상속보다는 객체 조합을 선호해라 라는 애기입니다. 대부분의 시중에 나와 있는 책들이 상속보다는 조합을 선호하는 것으로 의미를 파악하고 전달하고 있습니다.
물론 그 당시 CBD가 널리 유행했던 것도 한 몫했죠 🙂 과연 이말이 맞는걸까요?
6년 동안 다양한 패턴에책들을 본 경험을 들어 볼때, 상속이라는 것은 모든 패턴에 사용되고 있었습니다.
거기다 graybox 즉 whitebox(상속)과 blackbox(조합)을 함께 적용하는 것이 패턴계의 철학으로 굳혀져 있어서 과연 이말이 맞는지 많은 의구심을 가지게 되었습니다.
마소 1월호 주제인 Application과 Framework 동시 개발하기에 이어, 2월호에는 Framework 설계시 실제 필요한 Engineering 기법들에 대해 기고했습니다. 물론 결코 저의 머리에서 나온 것은 아닙니다. 🙂
이 글은 .NET Framework를 설계한 Krzysztof Cwalina의 TechED 강의 내용과 저의 지식을 덧분인 글입니다.
Krzysztof Cwalina의 강좌를 보시고 싶으신 분은 여기를 클릭하시길 바랍니다.
12월호 있었던 세미나와 지금까지 블로그에 기고한 Post들을 모은 내용이기 때문에, 저의 블로그 독자 분들(?)에게는 미안하네요 🙂
이번 글은 크게 6가지 주제들을 다룹니다.
● 조직 (가장 강력한 설계 툴)
● 계획 (프레임워크를 올바르게 구축하 기 위한 계획)
● 아키텍처 (오랫동안 사용할 수 있는 품질 좋은 프레임워크를 만들기 위한 고려사항들)
● 설계 (품질을 보장하기 위해 고려할 사항들)
● 개발 (프레임워크를 만들기 위해 팀플레이 시 고려해야 되는 사항들)
● 그 외에 고려해야 되는 것들 (가독성, 문서화)
이중 조직, 계획, 아키텍쳐에 대한 내용을 2월호에 다루었습니다.
패턴계에는 크게 두가지 박스가 있습니다.
GoF 패턴 책을 읽으신 분이라면 하얀 박스(상속)와 검은 박스(조합) 애기는 많이 들어 보셨을 겁니다. 혹시 회색 박스는 들어보셨나요? 🙂
12월에 진행했던 Framework’s Day 세미나의 내용들을 연달아 마소에 기고하고자 합니다.
거리상의 제약으로 참가하지시 못했던 분이나, 관심 있었던 분들에게 도움이 되었으면 합니다. 🙂
Framework’s Day에서 Framework에 대한 기본 개론과 Ralph Johnson의 Evolving Framework에 대한 이야기는 이미 2008년 11, 12월호에 김용현님이 작성을 해주셨구요.
그 뒤를 이어 Framework Design Guidelines 2nd Edition 번역 팀들이 실제 Framework를 구축히 만날수 있는 문제들에 대한 글을 기고하고자 합니다.
그리고 권효중님이 iBatis.NET과 Spring.NET에 대한 애기들을 진행 함으로써, 총 7회의 Framework 강좌가 마치게 됩니다.
세미나시 진행했던 ASP.NET MVC Framework와 ADO.NET Entitiy Framework은 이미 예전에 장현희님과 한용희님이 마소의 연재로 기고하셔서, 이번 Framework 강좌에서는 포함되어 있지 않습니다. 🙂
이번 기고 내용인 Application과 Framework 동시 개발하기 에 대한 주제는, 예전에 포스팅한 “성공적인 Framework 구축” 에 대한 연장 선상에 있는 글입니다.
여러분에게 즐거운 소식을 전해드리고자 합니다.
공개되지 않은 EuroPLoP Paper를 발견하게 되었습니다.
자료를 찾았을때 저의 마음을 표현해 주는 그림입니다. 🙂
제가 최근 Patterns for Understanding Frameworks 라는 논문을 정리하고 있는데, 여기에 수많은 Referecne 논문들이 EuroPLoP 최근 논문들이었습니다.
(조만간 이 논문의 정리 버젼이 여러분에게 공개될것 입니다.)
IT에 몸담은 이상 발전하는 기술들을 무시할수 없습니다.
수 많은 대형밴더들은 끊임없는 기술을 만들고 발전 시킴으로써 새로운 가치를 창출해야 살아 남을수 있으며, 저희 역시 끊임없이 그러한 기술들을 습득하고 배워나가야 됩니다.
하지만 엄청난 서포라이트를 바라보면서 사라진 기술들을 볼때, 어떻게 기술들을 객관적으로 바라 보아야 할까요?
그걸 설명해 주는 좋은 그래프가 있어 소개하고자 합니다.
2009년도이 왔습니다. 저의 블로그를 애독하시는 모든 분들 새해 복 많이 받으세요 🙂
새해 부터 어떠한 글을 Posting 해야 하나 많은 생각 끝에 기러기에 이은 또 다른 새 이야기를 전혀 드리고자 합니다.
이 세상에서 한번도 쉬지않고 가장 오랫동안 나는 새가 무엇일까요?
독수리? 기러기?
정답은 믿기 어렵겠지만.. 단지 600g의 조그만 몸무게를 가진 이 도요새입니다.
도대체 얼마나 이 새가 멀리 날길래 이럴까 ? 하고 생각했지만 이 조그만 새가 날아가는 거리를 한번 보도록 하시죠.
Architecture 101 
