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

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

황상철님의 애자일 SCRUM 방법론 적용기와 이상민님의 GWT 그리고 GWT-ext 세션에 이어서 제가 findbugs 예찬론을 폈습니다. (각 링크마다 발표자료 있습니다.)
30명이 안되는 인원이 모였고, 반은 SDS소속 반은 인터넷을 통해서 신청받은 분들이 모였습니다.

세 세션의 공통점이 있는 듯 했습니다.
회사 조직은 새로운 것을 나에게 요구하지 않는다. 
그래서 내가 새로운 방법과 기술을 익혀도 회사는 무관심하다.
새로운 것을 적용해 프로세스를 개선하려고 해도 회사 조직은 달가워하지 않는다.
귀찮아 한다. 이렇게 말하면서 "좋아 보이는군요. 하지만 너무 이상적이라 우리 팀에는 맞지 않아요." 시도하기를 꺼린다.
때문에 새로운 것을 적용하려면 또 다른 노력이 필요하다. 

황상철님의 소규모의 성공 사례부터 만들어 나가기를 얘기했고, 제 생각은 사람들의 행동을 이끌어 내는 것은 감동이기 때문에 쇼를 하라고 얘기합니다. 이상민님은 쉬면서 멋진 GWT 애플리케이션을 만드셨더군요.

9시까지 예정이었지만 25분씩 발표로 8시 반 정도에 끝나고 뒷풀이 장소로 옮겼습니다.

거대 조직 내의 조용한 움직임.
당장은 효과가 없지만, 10년, 20년 지난 우리나라 업계의 중요한 뿌리가 될 것입니다.
꽃이야 C자 들어간 직위의 사람들 몫이죠. 
저작자표시 비영리 변경금지
Hudson 메인 페이지의 Manage Hudson 메뉴로 이동하면 신규 버전 알림이 노란 줄로 뜹니다. download 링크를 클릭하면 바로 다운 받을 수 있죠. 그리고 플러그인의 업데이트는 Manage Plugins 설명에 (updates available) 이라고 빨간 글씨로 보입니다.


Manage Plugins로 가면 Updates 탭에 해당 플러그인이 보입니다. 체크하고 우측 하단의 Install 버튼을 클릭하면 업데이트가 진행됩니다. 

대체로 설치 후에 hudson을 재시작해줘야 됩니다.



그리고 다른 얘기인데, findbugs 플러그인에서 보여주듯이 okjsp사이트의 버그는 다 잡았습니다. 냐호~



저작자표시 비영리 변경금지
파일 첨부합니다.
지난 발표자료에 적용점에 대한 고민만 살짝 추가했습니다.
okjsp 사이트의 버그는 하나 남았습니다.
이것도 곧 잡으러 출격합니다.

저작자표시 비영리 변경금지
hudson의 최상위 페이지의 메뉴 "Manage Hudson(Hudson의 관리)" 메뉴로 갑니다.

Manage Plugins 를 선택하고, Available탭에서 findbugs 플러그인을 설치합니다.

hudson을 콘솔에서 재시작하고, 프로젝트의 configure 메뉴에 가면 findbugs 활성화 체크박스가 하단에 보입니다. 체크하면 hudson에서 findbugs 플러그인이 활성화됩니다.

Build 섹션에서 Add Build Step버튼을 클릭해서 findbugs 빌드를 추가합니다. 빌드서버에 설치된 findbugs 경로를 findbugs.home 에 지정합니다. 환경변수에 $FINDBUGS_HOME으로 지정되면 이 과정이 필요없습니다.

build.xml 의 findbugs 타겟 소스는 참고로 다음과 같습니다.
    <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>
   <target name="findbugs">
      <findbugs home="${findbugs.home}"
                output="xml:withMessages"
                outputFile="findbugs.xml" >
        <sourcePath path="${basedir}/src" />
        <class location="${publish.home}/WEB-INF/classes" />
      </findbugs>
    </target>

콘솔에 다음과 같은 메시지가 찍히면서 findbugs에 대한 보고서를 확인할 수 있습니다.

참조하는 jar파일의 경로가 지정되지 않으면 이런 메시지가 나타납니다.

 [findbugs] The following classes needed for analysis were missing:
[findbugs]   javax.servlet.http.HttpServlet
[findbugs]   javax.servlet.Servlet

findbugs 태스크에 다음과 같은 jar경로가 있는 줄을 추가하면 위 경고가 해결됩니다.
      <findbugs home="${findbugs.home}"
                output="xml:withMessages"
                outputFile="findbugs.xml" >
       <auxClasspath path="${catalina.home}/common/lib/servlet-api.jar" />
        <sourcePath path="${basedir}/src" />
        <class location="${publish.home}/WEB-INF/classes" />
      </findbugs>


버그의 추이가 그래프로 나타납니다.

버그의 자세한 리포트는 프로젝트 왼쪽 메뉴의 FindBugs Warnings 를 통해서 확인가능합니다.

이제 남은 일은 버그의 수를 줄이는 것이겠죠.
저작자표시 비영리 변경금지
허드슨은 클래스 파일들의 파인드버그 분석 결과를 시각화할 수 있습니다. 이 옵션이 설정되면 이 기능을 사용하기 위해 빌드에서 파인드버그를 실행해야 합니다! 이 플러그인은 실제로 분석을 수행하지는 않습니다; 단지 분석결과에 대한 결과 트렌드 이력, 모듈과 패키지 통계, 분석 리포트와 경고 표시를 위한 웹 UI 등의 유용한 정보를 표시할 뿐입니다.

메이븐 설정

findbugs-maven-plugin 1.2 이상의 버전에서 최상의 결과를 얻을 수 있습니다. 버전 1.1.1은 경고 정보를 표시하는데 부족한 예전 파일 형식입니다. 가능하다면 업그레이드 하십시오. 파인드버그 분석을 하기 위해서 pom.xml 파일에 다음을 추가합니다:
<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>findbugs-maven-plugin</artifactId>
   <version>1.2</version>
   <configuration>
      <findbugsXmlOutput>true</findbugsXmlOutput>
      <findbugsXmlWithMessages>true</findbugsXmlWithMessages>
      <xmlOutput>true</xmlOutput>
      [...]
   </configuration>
</plugin>
마지막으로 정확한 결과를 얻기 위해 **/findbugsXml.xml 패턴을 지정해야 합니다.

앤트 설정

build.xml에서 파인드버그를 사용하려면, 다음과 같은 태스크 정의를 추가해야합니다. 
  <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>
태스크 정의가 추가되면, 아래와 같이 findbugs 태스크를 사용하는 타겟을 정의할 수 있습니다. 예를 들면:
  <target name="findbugs" depends="jar">

    <findbugs home="${findbugs.home}"
              output="xml:withMessages"
              outputFile="findbugs.xml" >
      <auxClasspath path="${basedir}/lib/Regex.jar" />
      <sourcePath path="${basedir}/src/java" />
      <class location="${basedir}/bin/bcel.jar" />
    </findbugs>
  </target>

마지막으로 정확한 결과를 얻기 위해 **/findbugsXml.xml 패턴을 지정해야 합니다.

저작자표시 비영리 변경금지
findbugs 세미나 중에 박현준님 덕분에 알게 된 기능입니다.
findbugs 플러그인을 깔지 않아도 가니메데에서는 런타임 익셉션에 대한 경고가 뜨게 됩니다. 먼저 이미지를 보시죠.

Null pointer access라는 메시지가 보입니다. 실행결과 나타나는 것도 아니고, 코드 분석 후 뿌려지는 내용입니다. 아직 깊이 맛본 기능은 아니지만 이클립스의 똑똑해지는 모습이 가볍게만 느껴지지 않습니다.

박현준님 감사합니다. ^^

저작자표시 비영리 변경금지
허드슨 강의하면서 배경지식으로 설명했던 지속적인 통합의 팀 적용에 관한 이야기입니다.

위 링크에 첨부파일로 올려놓았습니다.

관련 마인드맵은 이전 블로그에 올려놓았습니다.

저작자표시 비영리 변경금지
Hudson을 이용한 프로젝트 모니터링
Hudson.mm

Continuous Integration in Practice
ContinuousIntegrationinPractice.mm


http://freemind.sf.net 형식의 파일입니다.

저작자표시 비영리 변경금지
내일 강의에서 빌드에 대한 얘기가 있습니다. 빌드는 컴파일의 확장이다 라고 처음에 썼다가 너무 막연해서 구글링을 해 보았습니다. 델파이 툴의 메뉴 경험담이 처음으로 나왔고, 조엘 아저씨 사이트의 토론 게시판이 눈에 들어왔습니다. 나름 이렇게 설명하면 좋겠다 하는 부분도 있구요.

Build usually means the entire process of getting a system ready for use.
빌드는 보통 사용할 준비가 된 시스템으로 만드는 프로세스 전체를 뜻한다.

Compile is usually an action on a single file or group of files. The output of a compile step might be an executable or an object file or even a library of some sort.
컴파일은 한 파일 또는 파일 그룹을 대상으로 행해진다. 컴파일의 산출물은 보통 실행파일이나 오브젝트 파일 또는 어떤 라이브러리가 될 수도 있다.

Sometimes there is another step after build, to prepare a system for distribution.
때때로 배포를 위한 시스템을 준비하기 위해 빌드 이후에 다른 단계가 있기도 하다.

from: http://discuss.joelonsoftware.com/default.asp?joel.3.184483.14

인용한 부분의 설명이 마음에 듭니다. 베타 버전에는 흔히 빌드 번호가 노출이 됩니다. 빌드 번호라고 하지 컴파일 번호라고 붙이지는 않지요.

하지만 설명이 쉽지는 않군요. ㅡㅡ;
저작자표시 비영리 변경금지

+ Recent posts

티스토리툴바