전체 글 1294

NIO

JDK 1.5에는 서버 애플리케이션을 만드는데 필요한 거의 모든것이 다 들어가 있는 듯하다. 아래 포스트한 Thread Pool이외에서 JDK 1.4 부터 포함된 NIO에서는 Socket에 대한 Multiplexing이 가능한 API를 제공한다. http://www.onjava.com/pub/a/onjava/2002/10/02/javanio.html http://www.onjava.com/pub/a/onjava/2002/09/04/nio.html 고객사에 이슈가 있어서 검토중인데.. 간만에 재미있는 장난감 찾았다... 정리되면 나중에 다시 포스팅 해야겠다. ^^

JDK 1.5 부터 등장한 ThreadPool

Thread Pool이라는 것이 얼핏 생각하면 구현이 간단할 수 도 있지만, 막상 구현하려면 상당히 귀찮은데, JDK 1.5에 이 내용이 포함되어 있다. 상당히 설계도 잘한것 같아서 마음에 드는데.. 이정도면 쉽게 웹서버정도는 만들 수 있지 않을까? http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html#execute(java.lang.Runnable) 생성자를 잠깐 살펴보면 ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory ..

방문자 수가 늘었다 했더니..

블로그 방문자수가 오늘 급격하게 늘었다했더니.. 유입 키워드 대부분이 "jco", "JCO" 였다. 이번 JCO 컨퍼런스에 대해서 관련 정보를 찾은 사람들 또는 후기를 모으는 사람들이 들어오지 않았을까? 아침에 여기저기서 들려오는 컨퍼런스에 대한 소식과 잡음에 마음이 편하지 않다. JCO 활동을 접은지는 오래되었고 감히 technical mentor로써 남고자 했지만. 일년에 40분의 시간과 약간의 블로그 포스팅으로는 역시 터무니 없이 부족하다... 대부분의 걱정의 글이 조직의 운영성과 행사문제등에 초점이 맞추어져 있는데.. 이번 컨퍼런스에 발표를 하지 않은것중에 가장 중요한 이유가... 컨퍼런스의 강의 품질 문제다... 물론 열심히 발표하시는 분들도 있지만.. 벌써 해외와 현업에서는 기술이 저만치 흘러..

사는 이야기 2008.02.19

단위 테스트 2회 - 확장된 단위 테스트 도구 (Cactus,JUnitEE)

확장된 단위 테스트 도구 (Cactus & JUnitEE) 자바스터디 조대협 (http://bcho.tistory.com) 지금까지 기본적인 단위 테스트 도구에 대해서 알아보았다. 좀더 상세화된 단위 테스트의 단계를 나눠 보면 다음과 같이 나눠볼 수 있다. l Type 1.코드 단위 테스트 코드상의 로직에 대해서만 테스트를 수행한다.앞 장에서 살펴본 테스트 방법이 일반적인 코드 단위 테스트 방법이다. 그러나 EJB,Servlet과 같은 J2EE 컴포넌트에 대해서 로직이 Dependency를 가지는 경우에는 EJB,Servlet 객체를 직접 연동하는 경우 container (WAS)에 배포하고, 기타 환경 설정이 필요하기 때문에, 로직 테스트를 위해서는 container 환경을 구성하기 전에 동일한 인터페..

ALM/Test Automation 2008.02.19

가장 무서운것...

가장 무서운것은? 무능력이 아니고... 무능력을 모르는게 아닐까? 요즘 들어서 드는 생각인데... 예전에는 그래도 Technical한 내용을 많이 보고 연구도 했는데. 근 1년간 많이 게을러 지지 않았나 싶다.. 이름으로 먹고 사는것도 같기도 하고.. C과장은 잘하니까는.. 걱정없어.. C과장이 왔으니 문제가 없을거야.. 일하는데 별로 건들지도 않고.. (물론 시키지 않아도 일을 너무 벌려서 문제이긴 하지만..) 요즘 긴장감이 많이 떨어졌다... 이런 기간이 오래 지속되면 나태해지는데.. 이러다가 과거의 영광을 먹고 사는 3류 가수 신세가 되지 않을까? 누가 그러더라..."과거의 영광이 미래의 실패라고..." 초심으로 돌아가야 하지 않을까?

사는 이야기 2008.02.19

빌드 자동화 업체

Clover,JiRA, CI 툴등. 이런거 수입해서 국내에서 팔았으면 좋겠다 생각했는데.. 벌써 하는 업체가 있었네.. 반갑기도 하고.. ^^ 역시 사람들 빠르다는 생각도 들고... 마침 업체가 최종명 선배가 있는 업체기도 해서 기술에 신뢰도 간다... 기회가 되면 프로젝트 초반에 같이 한번 일해보고 싶은 업체. Architecture Group http://www.arctgroup.com 555-4847

Test Coverage Rate

테스트 Coverage rate에 대해 고민하던중 재미있는 글 하나 발견 사실 Coverage rate를 올리는것도 중요하지만, Coverage rate는 value있는 test 로 cover가 되어야 한다. 코드 Coverage rate를 올리는것 자체는 중요하지 않다. 얼마만큼 꼼꼼한 테스트가 도느냐가 문제이지... 여러 문서들을 찾아보니까는 보통 80%의 Coverage를 이야기 하는데, 이정도의 Coverage라면, 적어도 개발 과정 전에 Test 에 대한 방법이 고려된 상태에서 개발을 해야지 않는다면 개발 중간에 일정에 미칠 IMPACT가 어마어마할것이다. 지금 프로젝트는 60~70% 정도를 고민중인데.. 어떻게 될려나? == http://www.artima.com/weblogs/viewpost..

ALM/Test Automation 2008.02.11

통합 빌드 환경 설정 완료

9개의 프로젝트로 구성된 WLI 시스템에 대한 통합 빌드 시스템을 구축하였다. Hudson + ANT + WebLogic Workshop ANT TASK 를 조합해서 구성하였고 Free STMP 서버로 Alert 기능은 지원할 생각이고.. 인자 자동 DEPLOY 자동화까지 진행할 예정 다음주면 이건 될것이고.. == 표준화 팀에서 JUnit + DBUnit + Hudson으로 기능 테스트에 대한 자동화를 진행중이고 다음주 부터는 JUnit + Cactus 기반의 Unit 테스트를 구현할 예정이다. 이 과정에서 개발팀에게 Test Case와 Tuning을 위한 Issue Tracking 시스템을 설치할 예정인데.. 아직도 Trac을 할지.. 몰 쓸지를 결정을 못했네 그랴... 차라리 익숙한 Bugzilla..

HP 비리...

드디어 걸렸다. IT 업계에서 비리 뇌물, 단합이 하루이틀일이 아닌데.. HP가 제일 먼저 걸렸네. 몇년전에 IBM에서도 이런일이 있었는데.. 그나마 깨끗하고 룰을 지켜가며 일하는 HP가 이정도였다니.. 나름 충격이네.. 한국에서 골프장 사용고객층의 가장 많은 부분이 IT쪽이라니.. 할말 다한거 아닌가? 이글을 보면서.. 내가 영업쪽이 아니라 기술쟁이인것이 한편으로는 다행이고.. 이런 비리에 무감각해져있던 내 모습을 되돌아보면서... 자칫하면 큰일나겠다도 싶다.. 항 상 이야기 하지만 공급업체가 바뀌어야 하겠지만.. 무엇보다 고객이 가장 많이 바뀌어야 하지 않을까? 아직도 고객 회식자리에는 영업이 회식비 내주러 오는 경우가 종종 있으니.. 이런걸 미안해 하지도 않고 당연시 하는 문화가 이런일들을 계속 만..

Code Coverage Tools

상용 도구 Code Pro Anlytix Pro : 기능이 풍부한것 같고, 정적 코드 분석을 통해서 Complexity 분석도 되고 기능은 풍부한편으로 보인다. http://www.instantiations.com/codepro/analytix/server/index.html Clover : 다들 잘 아는 툴 이미들 많이 사용하고 있고, 널리 알려진 만큼 다른 시스템 (CI툴이나 Issue Tracking Tool, 소스 관리툴)들과의 통합도 쉽다. 오픈소스 Cobertura - 요즘 가장 유행하는 툴이 아닐까도 싶고.. 사용이 쉽고 직관적이다. 추천할만한 툴 EMMA-꽤 오래된듯한 툴 같은데... 여기저기 사례도 충분한거 같고 이클립스 플러그인도 지원한다. 마음에 드는것중 하나가 컴파일이 이미 다된 j..

WLW에서 Project ANT로 빌드하기

WLW에서 WLI나 WLP 애플리케이션들을 ANT 스크립트로 빌드할 필요가 있다. 절차는 다음과 같다. === 1. 각 프로젝트별로 File>Export > Workshop ANT Script로 build.xml 을 생성한다. 2. EAR 프로젝트에서 File>Export >Workshop ANT Metadata를 생성한다. 이때 같이 빌드될 모든 프로젝트를 선택한다. NEXT를 누르면 각종 절대 경로들을 설정하게 나온다. 이 경로를 설정해야 한다. 3. Remote server에 Project 디렉토리들을 업로드한다. workspace.xml 로 업로드 한다. 4. EAR 프로젝트에서 ant -Dworkspace={workspace.xml 경로} -Dwl.home=웹로직 홈 경로 build ant -D..

Project Reference와 J2EE Module Dependency 혼용해서 쓰지 마세요.. 제발..

휴우.... 다들 알다 싶이, 이클립스에서 개발을 할때는 동시에 여러개의 프로젝트를 열어서 개발을 하게 되고, 프로젝트간의 Dependency를 지정하는게 중요한데. 이게 개념을 모르고 하면 정말 독이 된다는... -_- 지금 개발중인 시스템도 총 9개의 프로젝트로 나뉘어져 있는데... 이게 정리가 안되서 컴파일이 제대로 돌아가지를 않는다. 허허.. 먼저 프로젝트의 레퍼런스와 J2EE Module Dependency는 프로젝트 폴더에서 오른쪽 버튼을 누르고 "Properties"를 보면 나온다. 1. Project Reference 이건 간단하게 생각해서 ClassPath에 넣느냐 마느냐를 결정하는것으로 보면 된다. 현재 프로젝트를 빌드하고자 할때, 다른 프로젝트의 class가 필요한 경우 Project..

JCO 컨퍼런스 2008

JCO 2008년 컨퍼런스 아젠다가 발표됐다. 보고나서 나오는 한숨은 어쩔 수 가 없다. 국내의 최고 자바 개발자라는 사람들이 주류와 흐름을 멘토링 하고 일반 개발자들을 이끌어 가는 자리가 되야 하는데.. 정작 실상은.. 유행 잔치라고나 해야 하나? 뽑내기 대회라고 해야하나? 열심히 발표 준비하시는 분들께는 죄송하지만.. 우리가 다루어야 할 자바 기술들은 다 어디로 갔나? 해외에서는 이미 Struts는 사향세이고 JSF가 쓰이고 시작하고 OR-Mapper에 대한것도 Hibernate,IBatis뿐만 아니라, JDO도 국내외 벤더에서 지원하면서 그 사용성이 높아지고 있으며, SCA역시 새로운 아키텍쳐로 주목 받고 있는데, EJB 이야기는 몇년전부터 쏙 들어간지 오래고.. (실제 기업에서는 아직도 EJB 사..

사는 이야기 2008.01.23

Hudson

테스트를 JUnit으로 만들어서 단위 테스트가 아닌 기능 테스트로 진행하려고 하는데. 테스트를 빌드 자동화 툴을 이용해서 자동화 할 예정인데. Hudson 이거 정말 물건이다. 사용도 쉽고, 대부분의 빌드/테스트에 사용되는것들이 다 지원이 되니.. 물건이네. http://hudson.gotdns.com/wiki/display/HUDSON/Home Corbertura도 플러그인으로 지원이 되는데.. 이걸 해..? 말아?

다시 운동 시작...

근 20일만에 다시 운동을 시작했다... 이번이 3번째 코치인데.. 코치를 바꿀때 마다.. 알려주는 폼도 다 틀린다. 자세를 어느정도 잡았다고 생각했는데. 새 코피가 알려주는 자세를 책에서 찾압니까는 그 자세가 맞다는. 그럼 그동안 잘못된 자세로 치고 있었나? 이번주 정도면 자세는 교정이 가능할것 같은데.. 그나저나 간만에.. 무리를 해서 그런가.. 편도선도 붓고 몸이 컨디션이 안좋네. 오늘은 몸 관리좀 해야겠다..

프로젝트 자동화 도구..

작년 7월 부터인가? 개발 자동화에 대해서 이것 저것 찾아봤다. 이런것 저런것 사용도 해보고 프로젝트에 적용도 해보고.. 사용했던것중에서 이슈 트랙킹 시스템의 장점에 대해서는 완전 감동.... 소스 관리는 SVN이 제일 나은것 같고. 빌드 자동화는 그동안 AntHill이나 Cruise Control이 대세 였으나.. 이번에 Sun에서 HudSon이라는 것이 나왔네. 장점이 인스톨이 매우매우 쉽고... 다른 솔루션과 연계가 가능하다는것. 이슈 트랙킹인 다들 잘 아는 JIRA 이건 좋긴 한데.. 사용이고. Bugzila 정말 힘들게 깔았는데. 인스톨이 힘들고 버그 트랙킹에만 국한 된다. 인터페이스도 약간 불편한듯하고.. Mantis는 인스톨이 쉽고 UI도 직관적이라서 이번 프로젝트에 적용해볼까 했는데. Tr..

ALM 2008.01.18

테스트 성공!!

빌드 배포 자동화 과정중에 테스트의 자동화는 말할 필요 없이 중요한 내용... 테스트 자동화를 시간 날때마다 계속 했는데. 오늘에야 대충 전체 시나리오를 만들었다... POJO 기반의 테스트는 JUnit J2EE 컴포넌트의 인컨테이너 테스트는 Cactus DB 테스트는 DBUnit 하면은 HttpUnit과 JWebUnit 정말 관건은 J2EE 애플리케이션에서 필요한 InContainer 테스트에 대한 내용이었다. 단순히 InContainer Test만으로는 기능 이외의 다른 요건을 충족하기 힘들어서 J2EE 애플리케이션의 커버러지와, 성능 단위테스트가 필요하였다. 그래서 조합한것이 Cactus + Cobertura = J2EE 애플리케이션의 커버러지 분석 Cactus + Japex = J2EE 애플리케이..

사는 이야기 2008.01.17

Cactus에서 JUnit 테스트 케이스 재활용 하기

Cactus에서 이미 만들어놓은 JUnit 케이스를 재활용할 수 있는데. 만들어놓은 JUnit을 서버로 올려서 TestRunner를 이용하여 브라우져에서 실행하면 그대로 실행된다. 만약 ANT TASK에서 호출하고자 할때는 기존 JUnit케이스를 다음과 같이 ServletTestCase로 묶어야지 호출이 가능하다. == Cactus is able to run pure JUnit TestCase on the server side. This is done by using the ServletTestSuite Test Suite that wraps your existing Test Cases. For example: public class TestJUnitTestCaseWrapper extends TestCa..

ALM/Test Automation 2008.01.17

Cobertura를 이용한 커버러지 테스트시 주의할 사항

서버쪽에서 Cobertura를 이용한 커버러지 분석을 할때 주의할점은 Cobertura는 기본적으로 ASM을 이용하여, 테스트를 진행할 코드에 커버러지 분석 코드를 삽입하는 방식이다. (AOP와는 다르게 STATIC한 방식을 사용) 그렇기 때문에, Instrumented 된 코드가 반드시 실행되도록 클래스패스에 삽입 하거나 또는 패키징 할때 Instrumented 되지 않은 코드를 WEB-APP에 먼저 복사한후 그 다음에 Instrumented된 코드를 복사하여 Overwrite가 되게 해야 한다. 그리고, Cobertura는 커버러지 분석한 정보를 메모리에 담아 놨다가 서버가 shutdown될 당시에 한꺼번에 파일에 쓰기 때문에 메모리 요구량이 높을 수 있다. 그래서 각 단위 테스트마다 리스타트를 해서..

ALM/Test Automation 2008.01.17

요즘...

얼마전에 카메라를 5D 로 다시 구입했다. 결혼하고 나서 거의 사진을 손대기 않았는데... 아기 사진 찍어주려고 여기저기 스튜디오를 기웃거려 봐도 마음에 드는 사진을 찍는데는 없고 금액만 비싸더라. 그래서 거금 투자해서 카메라와.. 매킨토시를 장만했는데. 문제는 이 맥에서 포토샵이 제대로 돌지 않는다는.. -_-; 결국 5D 살때 딸려온 Adobe Lightroom 으로 편집하는데.. 마음에 들지 않네 그랴... 어여 편집 환경을 설정해야 할텐데.. 위에 사진은 지난주인가? 용인 한택 식물원 갔다가.. 빛이 좋아서... 찍었던 사진.. 표정도 따뜻하고 햇살도 따뜻하고.. 참 보기좋네... 내 와이프...

사는 이야기 2008.01.14