Eclipse for Everything – javanese

ZDNet에서 “고단한 SW개발자 생태계, 그래도 희망은 있다”라는 기사를 읽었습니다. 안철수씨가 개발자 문화에 대한 강연한 것을 요약한 내용인데요. 물론 우리나라에서 개발자로 산다는게 좀 손해보는 느낌은 있어도 하고싶은 것 하는 거라 별 불만은 없었습니다만.. 요즘들어 사실 좀 고단하긴 합니다.

안철수씨 강연 요약하면..

1. 기본기
2. 창조적 사고
3. 장인 정신
4. 커뮤니케이션 능력
5. +알파 : 영어, 팀워크

뭐 다른것도 꾸준히 모자라지만 특히 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에도 스크럼 지원이 있던데.. 그거나 기대해봐야겠습니다.

요즘 한창 Spring Framework 공부 중 입니다. 그래서 Spring 관련된 플러그인이랑 이래저래 Modeling 관련 플러그인 등 잔뜩 설치하고.. Spring 튜토리얼 보면서 열심히 따라하고 있는데 xml 파일들이 프로젝트 빌드할 때 계속 빠져버려서 일단 ant 빌드 해서 마무리는 했습니다.

뭔가 추가로 설치한 플러그인 중에 XML validation 하다가 에러나서 빌드를 방해하나 하고 플러그인 하나씩 빼보고 이런저런 삽질을 한참 했는데요.. 설치했던 걸 다 지워도 안되더군요 ㅠ_ㅠ 혹시나 해서 워크스페이스를 새로 만들었더니 됐습니다.

결론은 플러그인 문제는 아니고 Preferences > Java > Compile > Building에서 Output folder의 filtered resources 설정에 *.xml, *.html, *.svg 등이 들어가 있지 뭡니까 ㅠ_ㅠ 저는 절대로 설정한 적은 없는데.. 어느 플러그인이 환경설정을 바꿔버리는 것인지는 못찾았습니다. 같이 들어가 있는 filtered resource들이 *.datapool, *.testlog 등인 것으로 보아 TPTP 플러그인을 의심하고는 있습니다만..

비슷한 현상 겪으신 분은 참고하세요. 간만에 삽질다운 삽질 제대로 했네요. 크흑~