스프링 3.0 GA(General Availability) 출시가 내일이다. GA란 표현이 생소할 수 있는데 최종 버전 혹은 정식 버전을 의미한다. 스프링 3.0을 공부하고 있지도 않았고, 딱히 최종 버전을 쓰고 싶어 기다린 터도 아니라 동동 구르며 출시를 기다리며 쓴 글은 아니다. 솔직히 고백하면 유치하게도 자랑하고 싶어 올린 글이다. :) 금요일에는 분명히 열린 이슈가 4~5였는데 다시 늘었다. 그 중 하나의 이슈에 낯익은 이름이 있다. Toby형 글을 읽고 메신저로 이야기를 나누다가 발견한 옥에 티다. 스프링의 Javadoc에 대한 신뢰가 있었던 터라 오류가 믿기지 않아 우선 Toby형에게 확인을 부탁했다. 그리고 혹시나 낡은 코드를 보고 뒷북치는 일이 아닐까 해서 스프링 프로젝트 Trunk에 있는 소스를 직접 확인했다. 이미 할당한 작업이 있는지도 보았는데 없었다. 짧은 영어 실..

Using a combined SOA and TOGAF environment for increased productivity: Part 1: Introduction to the TOGAF Enterprise Continuum 오늘 DW가 좋은 글을 많이 올린다. 요약을 시작하는 문구부터 마음에 든다. Service-oriented architecture (SOA) can transform organizational silos into functional groups, thereby measurably increasing productivity. 그리고, 현실 인식이다. At present, both the Open Group Architecture Framework (TOGAF) and SOA are unapproachable and poorly understood. 이후에 스크랩해 둘만 한 그림이 연속으로 보인다. 최상위 개념도 Architecture Continuum의 여러 상태(혹은 단계)를 나타내는 그림 그리고, 상태 전이(혹은 단계 전진)의 특성을 명쾌하게 정리했다. From conceptual to logical to physical From technology solutions to business technology systems From industry-neutral to vertical business domain-compliant architectures From general taxonomies to physical architectu..

The Timeline/Milestone pattern라는 글을 보는데 마침 고민하던 문제라 모델이 한눈에 들어왔다. 결산 프로세스에 대해 고민하던 중이어서인지 꽤 인상적이다. 기사가 다룬 문제는 지표까지 관리한다는 점이나 특정 기술을 전제하고 있어 차이가 있지만,참조할 내용이 있다는 점만으로도 고마운 그림이다. 도해(diagram)를 사용함에 있어서도 문제 상황을 보여주는 그림 정보의 구성을 다룬 그림 그리고, 주요 상태도 시스템 수준의 큰 그림 핵심이 되는 컴포넌트의 상호작용을 그린 그림은 훌륭한 모델링 결과이고 효과적인 전개다. 모델링을 하려면 이 정도는 해야 할텐데...

JBoss 월드에서 "Java EE and the Spring Framework: Compare/Contrast"란 제목의 발표가 있었나 보다. 웹에 발표자료를 공개하고 있다. 작동하는 제품이 아니라 스펙인 Java EE와 제품을 비교하는 이유가 궁금했지만, 결국 잘 포장된 FUD로 컨퍼런스 참가자를 현혹할 의도가 아니었나 의심하게 하는 내용이 눈에 띈다. 출발점과 결론을 기록한 박스의 내용은 수긍이 가지만, Java EE와 Spring 프레임워크 비교는 한심하다. 이제는 지루할 지경인 XML 논쟁이 2009년에도 등장한다. 만일, 스프링 설정이 복잡하다고 기술적인 비교를 하려면 정의에 지나지 않는 Java EE가 아니라 Java EE를 구현한 제품의 모든 설정과 Spring(혹은 Spring + Tomcat)이 요구하는 설정을 비교해야 하지 않을까? Java EE 두 번째 항목을 보면 발표자의 수준을 의심할 수 있다. Non-redundant APIs with specialized roles 꾸러미 성격..

마침 DW에 올라온 글을 보고 어제 트위터에서 본 후배의 푸념이 생각났다. 예전에 형상관리도구 사용에 반감을 품은 개발자를 개발자/팀을 자주 만나곤 했다. 파일서버를 쓰거나 빌드 시점에서 한꺼번에 코드를 통합해오던 습성을 가진 개발자/팀에게 형상관리시스템 적용은 코드를 관리가 어렵게 하는 제약으로 비춰지는 듯하다. 그도 그럴 것이 SVN을 쓰고 나서는 골치 아픈 충돌을 해결하는 과정이 생겨 무척 번거롭게 볼 수도 있다. 요즘은 CI 도구를 사용하는데, 뒤로 미루던 통합 작업을 당겨서 일상으로 만드는 역할을 한다. 만일, SVN/CVS 사용에 큰 무리가 없는 팀이라면 CI 도구 적용에 큰 거부감이 없다. 하지만, SVN/CVS을 파일서버 대용으로 쓰는 식으로 충돌이 발생하지 않게 작업하는 조직이라면 CI 도구 적용은 요원할 수 있다. 보통 이런 팀은 통..