12월 5일은 okjsp 9주년이라 저는 참석이 힘듭니다만, 아쉬움을 갖고 좋은 모임을 소개합니다. 지난 페차쿠차에서 발표를 했었는데, 다른 발표자들의 내용 덕분에 좋은 정보들을 얻을 수 있었습니다. 오픈소스웹디자인 http://www.oswd.org/ 같은 곳 말이죠.

11월 27일까지 발표자도 모집합니다.
http://www.ibm.com//developerworks/kr/event/seminar/dwlive_1205/index.html

봄싹 스터디(http://springsprout.org/)도 발표를 하는데, 현재 자바 협업으로 재밌게 오픈소스 프로젝트를 진행하는 모임입니다. issue tracker, version control system, ide, continuous integration 같은 도구 뿐만아니라 메일링리스트를 통한 의견교환 등 제가 생각하기에는 제대로 오픈소스를 경험하는 모임같은데, 이 모임의 발표가 상당히 보고 싶네요.

좋은 모임하시고, 블로그에 후기 잘 남겨주시면 그것이라도 찾아봐야겠습니다.

http://www.google.com/search?q=페차쿠차+ibm
저작자표시 비영리 변경금지
한국에 다시 오십니다. 8월 18일
현재 엔터프라이즈 개발도구 시장의 플랫폼을 쫙 깔아버린 이클립스, 그 이클립스 개발을 진두지휘해 온 멋진 분입니다.
IBM Rational 사업부에서 모셔서 협업개발에 대한 세미나를 하십니다.

신청 주소입니다.
https://www-950.ibm.com/events/wwe/grp/grp005.nsf/v16_enrollall?openform&seminar=39C365ES&locale=ko_KR



저작자표시
컴파일도 필요없고, 즉석에서 바로 확인도 가능합니다. 마치 z80시대의 BASIC 느낌이라고 할까요. 물론 LIST, RUN 등의 원초적인 시절과 현재의 shell은 확연히 다르지만 말이죠.

http://www.ibm.com/developerworks/kr/library/tutorial/au-dw-au-unixtips4-i.html

엔터프라이즈라고 하는 기업 환경에서 프로그래밍 하려면 shell 프로그램은 짜기 힘들어도 읽고 내용 간파 정도는 기본이 아닐까 생각됩니다.

ps. 어째 초짜 대상으로 돌팔이 짓을 하는 글일 수도 있는데, 그냥 제 생각입니다.
저작자표시 비영리 변경금지
developerWorks의 컬럼에 개발일정을 줄이는 방법-테스팅이라는 제목으로 글이 올라왔습니다. 소프트웨어 프로젝트에서 오픈일에 가까워 질 수록 일정의 고무줄 현상은 피하기 힘들고, 가장 빠르게 일정을 지키는 방법 중 하나가 프로젝트 진행과정에서 결함을 제거하는 것이라고 합니다.

IBM의 Jones에 조사된 상기 표는 결함 제거율이 95% 선에 있는 프로젝트가 가장 빨리 수행되었음을 보여준다. 즉 프로젝트 진행 중에 품질에 신경을 쓴 경우가 그렇지 않은 경우보다 개발 기간이 단축되었음을 알 수 있다. 또한 대부분의 회사가 위치하는 결함 제거율 50% 미만의 경우 개발 기간이 늘어났음을 알 수 있다
from: http://www.ibm.com/developerworks/kr/library/dwclm/20090120/

결함을 제거하는 방법으로 추천하는 것이 코드 리뷰와 인스펙션이라고 합니다. 만약 짝프로그래밍을 한다면 더 많은 결함을 줄일 수 있겠지요. 혼자서도 벅찬 일이기는 합니다만, 팀에 적용하려면 참 어려운 이야기 같기도 합니다.

설득의 심리학을 읽어도 마찬가지겠죠.
저작자표시 비영리 변경금지
One Source, Multi Use 라는 말만 쉬운 것이 있습니다. 비즈니스 로직 하나를 구현해 놓으면 여러 다른 환경에서 쉽게 사용한다는 뜻입니다. 이클립스에서 제시하는 것은 데스크톱용 애플리케이션 RCP(Rich Client Platform), 웹용 RAP(Rich Ajax Platform), 모바일용 eRCP(embeded Rich Client Platform)입니다. 지난 자바원에서 이에 대한 강의를 듣고 고개를 끄덕거렸던 기억이 있는데, 관련해서 dw에 기사가 모두 올라왔습니다. RCP에 대한 것은 이전 블로깅에도 있습니다.

part1: http://www.ibm.com/developerworks/kr/library/tutorial/os-dw-os-eclipse-ganymede-pt1.html
part2: http://www.ibm.com/developerworks/kr/library/tutorial/os-dw-os-eclipse-ganymede-pt2.html
part3: http://www.ibm.com/developerworks/kr/library/tutorial/os-dw-os-eclipse-ganymede-pt3.html

세 문서를 따라해보면 이에 관한 감각을 익힐 수 있을 것입니다.



저작자표시 비영리 변경금지
자기가 만들어 놓은 것에 대한 평가는 항상 긴장하게 됩니다. 소프트웨어 프로젝트에서 가장 마지막 단계는 개발자들이 담당합니다. 프로젝트의 품질에 가장 많은 비중을 차지하게 되죠. 이렇게 만들어진 프로젝트에 대한 평가가 이뤄지면 가장 민감하게 반응하는 것이 개발자들이기도 합니다. 아무리 감정이입을 시키지 않으려해도 쉽지 않은 것이 자신의 결과물에 대한 평가이기 때문일 겁니다.

dw에 올린 김창준님의 글은 이런 관점에서 새로운 접근법을 제안합니다. 읽고 나서 인상에 남는 법은 마치 크리스마스 캐럴의 스크루지 이야기랄까. 영구없다 상태에서 작품에 대해서 피드백을 얘기하는 것을 지켜보게 됩니다. 자칫 감정적으로 치우칠 평가를 배제하기 위해서 중재자의 역할도 굉장히 중요할 것 같습니다.

Writer's Workshop이라고 불리는 이 방법 어떻게 경험해 볼까 머리를 굴려봅니다. 

저작자표시 비영리 변경금지

툴바에서 컨텍스트 메뉴를 부르면 다음과 같이 보입니다. Customize Perspective...를 선택합니다.


그 다음에는 툴바의 메뉴를 조정할 수 있는 창이 뜹니다.

툴바에서 컨텍스트 메뉴 부를 생각을 왜 안 해봤을까요. ^^; 이클립스 경력 6년에 처음봤습니다. ^^; 물론 아는 게 많지는 않지만요.

http://www.ibm.com/developerworks/kr/library/os-eclipse-master1/ eclipse V3.4 완전정복 기사에 나온 내용입니다. 새롭게 알게된 팁들이 몇 가지 있군요.

번역기사들이 많이 올라옵니다. 발견하는 것이 쉽지는 않은 듯 하고요. 이클립스 가니메데 버전에 대해서 기초서적처럼 설명해주는 페이지입니다.

저작자표시 비영리 변경금지
desktop을 데스크탑이라고 할지 데스크톱이라고 할지 고민되어서 제목에 desktop이라고 표기했습니다. (책상이라고 하긴 싫습니다.)
지난 자바원에서 the many moons of eclipse강의를 듣고 굉장히 인상적이었는데, 그와 관련된 기사입니다.
비즈니스 계층과 프리젠테이션 계층의 완벽한 분리 덕분에 비즈니스 컴포넌트는 하나이지만 프리젠테이션 티어의 컴포넌트는 세 가지로 표시됩니다. 각각의 프리젠테이션 컴포넌트는 비즈니스 컴포넌트를 개별 플랫폼에 표시합니다. 바로 desktop, web, mobile이죠.
일단 desktop에서 돌아가는 RCP(Rich Client Platform) 버전입니다.
설치가 쉽지 않은 서브버전 클라이언트에 대한 설명도 봐줄만 합니다.

저작자표시 비영리 변경금지
스프링노트의 에디터 xquared를 만드신 강규영님의 글이 올라와있군요.

RIA 개발에 있어서 개발자, 기획자, 디자이너 역할 분담을 강하게 하면 제대로 서비스를 만들기 어렵게 됩니다. 세 역할의 각자 전문 기술이 있겠지만 세 역할의 지식 공유 영역이 넓을 수록 높은 퀄리티의 서비스를 만들 수 있습니다. 사실 웹 초기에는 웹 마스터라는 역할이 혼자서 다 했던 일이죠. 서버 구축부터 포토샵, 그리고 서버 프로그램까지 혼자서 다 했죠.

요즘은 디자인과 개발 사이에 UI 또는 UX라 하여서 인터페이스 액션을 주로 처리하는 팀이 생기고 있기는 합니다. 플래시의 ActionScript와 Ajax의 Javascript 전담이죠.

협업의 기본은 커뮤니케이션입니다. 이에 관한 강규영님의 의견에 저는 심히 공감합니다.


저작자표시 비영리 변경금지
백기선님이 잘 번역하신 글입니다.
http://www.ibm.com/developerworks/kr/library/j-ap07088/index.html?ca=drs-kr 
findbugs를 통해서 코드의 취약성을 발견할 수 있었습니다.

CheckStyle, PMD, JDepend 등의 도구는 코드의 유지보수성과 가독성, 확장성을 떨어뜨리는 구문을 찾아줍니다.
이러한 도구들의 사용법과 리팩토링에 대한 글이 올라왔습니다. 아울러 글에서는 Switch구문을 polymorphism으로 리팩토링하기, 중복코드 줄이기, 긴 메소드(큰 클래스) 경량화하기, 너무 많은 import 줄이기 등에 대한 예들이 나옵니다.

참고하시면 좋은 애플리케이션 만드는데 큰 힘이 될 것입니다.
저작자표시 비영리 변경금지

+ Recent posts

티스토리툴바