Eclipse for Everything – javanese

원문기사: http://www.ibm.com/developerworks/kr/library/aug06/pollice/index.html

프로세스(절차)를 제대로 수립하는 것은 꼭 필요한 일이지만 전파시키기 힘들다는 이유로 미뤄지기도 하고, 수립되더라도 현실을 정확히 반영해서 모든 사람을 만족시키는 경우는 쉽지 않습니다. 기사에서는 다양한 프로세스 중에서 현실에 적합한 프로세스를 선택할 수 있도록 범위와 인터페이스라는 개념을 설명하고 있습니다. 사실 개발자가 개발하는 결과물의 context scope/interface의 의미와 크게 다르지는 않아서 쉽게 이해는 갑니다. 문제는 어떻게 적절한 프로세스를 선택하느냐겠죠 ^^ 하지만 기사에서 설명하는대로 범위를 나누어 생각하면, 해당 프로세스의 목적이 좀 더 명확해져서 적절한 프로세스를 선택하는데 도움이 될 것 같습니다.

요즘 저희 팀에 사람이 빠르게 늘어나면서 프로세스 수립 이슈가 지속적으로 생기고 있습니다만.. 뭔가 가이드를 제시한다는 건 항상 어렵네요 ^^ 한방에 해결할 방법이야 존재하지는 않겠지만 기사에서 설명하는 것처럼 영향 범위와 커뮤니케이션 코스트를 고려하여 적절한 프로세스를 선택한다면 그래도 뒷걸음질 칠일은 없을 것 같습니다~

다음은 기사에서 분류한 프로세스의 범위입니다. 개인 프로세스부터 제대로 수립하고 싶어요 -,.-

1. 개인 프로세스
2. 팀 프로세스
3. 프로젝트 프로세스
4. 전사적인 프로세스

원문기사: http://www.ibm.com/developerworks/kr/library/tutorial/j-rest/index.html

자바로 구현된 Restlet이라는 프레임워크로 RESTful Web Service를 개발하는 것에 대한 기사입니다.

REST란 무엇인가?

REST는 메시지라기보다는 이름이 부여된 자원, 예를 들어 URL(Uniform Resource Locator), URI(Uniform Resource Identifier), URN(Uniform Resource Name)과 같은 형태로 된 자원에 의존하는 느슨하게 결합된 웹 애플리케이션을 디자인하는 한 형식이다. 엄밀히 말해 REST는 이미 웹에서 검증되었고 성공적인 인프라스트럭처라 할 수 있는 HTTP에 올라탄 형태로 HTTP를 잘 이용하고 있다. 즉 REST는 GET과 POST 요청과 같은 HTTP의 단면들을 이용했다고 할 수 있다. 이같은 요청들은 표 1에 보인 것처럼 생성(create), 읽기(read), 갱신(update), 삭제(delete) 즉 CRUD라는 표준 비즈니스 애플리케이션의 요구 조건에 꽤나 잘 맞아 떨어진다.

REST에 대해서는 HTTP의 Method들을 다 활용하고 URL 규칙을 잘 해 둔거라고 막연하게만 알고 있었습니다만 기사를 통해서 정리된 내용으로 보니 좋네요. REST의 대한 정의와 URL 규칙이 중요한 부분이고 나머지는 일반적인 웹 서비스 개발과 다를 바 없습니다. Restlet으로 한번 따라해보기 좋습니다만 RESTful Service 구현을 위해서 Restlet 프레임워크를 꼭 사용할 필요는 없어보입니다. API 네이밍 규칙이 친숙해 보이는데 Rails에서 사용하는 네이밍 규칙이네요. Rails가 REST를 충실히 따르고 있는 것이었군요 ^^

RESTful Web Service로 개발했을 때 어느 정도는 성능상의 오버헤드가 있다고 생각됩니다만(웹에서의 고객 대상 페이지가 아닌 미들웨어로 사용했을 경우).. 기존 HTTP 인프라를 잘 활용할 수 있기 때문에 더 좋은 성능을 얻기 쉽다고 합니다. 사실 궁금한 것은 더 좋은 성능을 쉽게 보여주는 HTTP 인프라 예시인데요. 단순히 가장 많이 사용되기 때문에 그만큼 성능향상에 활용할 것도 많다는 의미인지, 아니면 REST의 디자인 자체가 성능 향상에 이상적이라는 것인지는 좀 애매합니다. 그리고 자원을 URL로 매핑시키는 것은 좋지만.. 해당 자원이 너무 규모가 큰 것이어서 자원의 일부만 보여주는 뷰로 접근해야할 경우는 REST로 어떻게 표현해야할지.. 뷰도 자원으로 생각하면 될까요? 그러면 뷰를 위한 파라메터가 URL에 이래저래 붙어서 깔끔한 REST를 유지할 수 없을 것 같은데요. 기사를 하나 읽으면 알아보고 공부할게 더 늘어나네요 -,.-

어쨌든 간결한 REST의 핵심을 간결하게 볼 수 있는 기사였습니다!

원문기사: http://www.ibm.com/developerworks/kr/library/j-jtp04298.html

요즘은 이클립스 기사가 뜸해서 리뷰를 자꾸 미루게 되네요. ^^

최근 읽었던 책 Java Concurrency In Practice의 저자 Brian Goetz가 쓴 기사가 있어서 읽어보았습니다. JDK 5.0에서 추가된 Generics의 사용법 예시를 소개하는 기사입니다. Generics는 컬렉션 API 사용할 때나 그냥저냥 사용했던 것인데요. 뭐 그냥 귀찮은 타입 캐스팅을 줄이기 위한 것 정도로 이해해고 있었습니다만, 좀 더 명확한 의미와 JVM 내 구현 방법을 알게 되니 좀 달라보입니다.

Generics를 사용한 클래스를 만들 경우는 흔치 않지만 Generics 클래스의 오브젝트를 다룰 경우는 흔히 있는데(List<?> 등) 이때도 와일드카드의 사용은 특별히 고려해본 적이 없습니다. 제한적인 도메인 로직을 다루는 프로그래밍이 생업이다보니 굳이 와일드카드가 별 필요없기도 하고 제너릭 API을 쓰더라도 타입을 명시하는 편이 더 코드 가독성에 좋다고 생각했는데요. 기사를 읽고 생각해보니 와일드카드를 쓰면 적절한 부분도 있을 것 같습니다. 일단 컬렉션 API의 인터페이스를 구현하는 클래스인 경우에도 항상 타입제한을 걸었었는데요. 제너릭 팩토리 메서드를 이용해서 받는 쪽에서만 타입제한을 걸면 이래저래 활용범위도 넓어지고 쓰기도 더 편할 듯 합니다.

자바에서 autoboxing말고 타입 추론을 하는 경우가 있다는 것도 처음 알았구요. 어쨌든 재미있는 기사라 추천합니다~

함께 볼만한 기사 : Generics gotchas, Introduction to generic types in JDK 5

원문기사: http://www.ibm.com/developerworks/kr/library/08/0701_ellingsworth/index.html

Jazz 플랫폼기반의 IBM Rational Team Concert에서 스크럼 프로젝트 관리하는 예를 설명하는 기사입니다. Jazz는 Erich Gamma가 참여한 프로젝트라는 것만으로도 기대하던 프로젝트인데.. 현재 회사에서 사용하고 있는 스크럼 활용에 대한 기사라 바로 훓어보았습니다.

일단.. 툴은 정말 덩치가 커보이네요. 이클립스 + 아웃룩 + 이슈트래커 + Mylyn + 알파 쯤으로 보입니다. 기사 내용만으로는 실제 사용할 때의 느낌이 완전히 와닿지는 않습니다만, 한데 잘 묶어놨을테니 충분한 시너지 효과가 있을 법해보입니다. 이슈트래커로 쩔쩔매며 스프린트 백로그 관리하고 있는 저로서는 눈이 번쩍하네요.

다만.. 아웃룩(+익스체인지 서버)의 역할을 묶어놓는 바람에 모든 사람이 Concert를 메인 커뮤니케이션 도구로 해야 의미가 있을 것 같아요. 상용이라 트라이얼 해보기도 부담스럽고.. 최소한 본부 단위로 적용하지 않는 이상 팀 단위로 유지보수하기는 어려워보입니다. 무료 버전이 있긴 하지만 대시보드와 레포트 기능이 빠져있어서 실제 활용에는 무리가 있습니다.

<Rational Team Concert Dashboard – 출처: IBM developerWorks Korea>

그래도 화려한 대시보드와 레포트는 정말 부럽네요. 꼭 써보고는 싶은데 흑.. 기사 내용과 비교해 볼 때 이슈트래커로 낑낑대고는 있어도 나름 스크럼 답게 프로젝트를 진행하고 있었다는 점이 그나마 위안입니다. Eclipse Process Framework에도 스크럼 지원이 있던데.. 그거나 기대해봐야겠습니다.

원문기사: http://www.ibm.com/developerworks/kr/library/notes8-google-calendar/index.html

Lotus Notes 8에서 구글 캘린더의 Atom Feed를 받아서 Lotus Notes의 원래 캘린더 뷰와 연동해서 보여주는 애플리케이션 예제입니다. 독립적은 애플리케이션은 아니고 Notes 8을 확장하는 Add-in을 개발하는 과정입니다. 제목만 보고는 Notes의 캘린더 뷰에 구글 캘린더를 통합하는 것인 줄 알았습니다만 그건 아니구요. 캘린더 뷰의 상태에 따라 별도 브라우저 뷰에서 구글 캘린더의 내용을 함께 보여주는 예제네요.

사실 Notes 개발환경을 다뤄볼 기회가 없어서 막연히 이클립스랑 비슷하겠거니 했는데, 웹 서비스 매시업 도구와 매우 비슷해서 의외였구요. 더구나 개발언어가 Visual Basic 문법이라는 것에 더 놀랐습니다. 아무래도 Office 유형의 애플리케이션 개발자가 VB 개발자가 많아서인가 봅니다. WSDL로 정의되는 웹 서비스를 데스크탑 애플리케이션에서 연동시키는 도구가 어떤 식으로 구성되는지 볼 수 있었습니다.

<출처: IBM developerWorks Korea>