확실히 두 번째 시간은 첫 번째 시간보다 무리 없이 실습 시간이 진행됐습니다.
이제 수강하시는 분들도 테스트 작성에 익숙해진듯이 보였고,
중간에 막히면 옆에 분들이 서로서로 도와가며 따라 오시는 모습이 아직 두 번째 시간밖에 안 됐는데
벌써 강의 분위기가 잡혔구나 하는 생각이 들었습니다..
이번 강의에서 제가 정한 목표가 몇 가지 있었는데, 그 중에 하나인 수강하시는 분 전원이 마지막까지 낙오되지 않고 함께 끝내자 였습니다. 아직 강의가 끝나지는 않았지만, 두 번째 시간까지는 무리 없이(없었겠죠^^;) 따라 오시는 것 같아 참 다행이다 하는 생각이 들었습니다.
Jdbc Template 실습은 예상보다 시간이 조금 더 걸리기는 했지만, 역시나 모든 분들이 다 함께 실습을 맞췄다는데 의의를 둘 수 있을 것 같고.. 특히, 막판에 공통 메소드를 뽑아 낼 때 조금 이해도가 떨어지는 경우가 있었는데, 이 부분을 조금 더 이해하기 쉽도록 변경하면 좋겠다라는 생각도 들었구요..
JbcTemplate API로 무턱대고 바로 시작하는 내용 구성보다는 확실히 강의 이해도가 높아지는 걸 느낄 수 있었습니다. 작년 강의할 때는 Template 소개만 간단히 하고 바로 API 실습을 들어가는 방향으로 구성했을 때와 분위기가 사뭇 달랐습니다..
이번 주 강의 무사히 맞쳤고, 이제 다음 강의를 다시 준비해야겠네요..
또 어떤 내용을 함께 나눌지 고민해봐야 하는 한 주가 될것 같습니다..
이제 수강하시는 분들도 테스트 작성에 익숙해진듯이 보였고,
중간에 막히면 옆에 분들이 서로서로 도와가며 따라 오시는 모습이 아직 두 번째 시간밖에 안 됐는데
벌써 강의 분위기가 잡혔구나 하는 생각이 들었습니다..
이번 강의에서 제가 정한 목표가 몇 가지 있었는데, 그 중에 하나인 수강하시는 분 전원이 마지막까지 낙오되지 않고 함께 끝내자 였습니다. 아직 강의가 끝나지는 않았지만, 두 번째 시간까지는 무리 없이(없었겠죠^^;) 따라 오시는 것 같아 참 다행이다 하는 생각이 들었습니다.
Jdbc Template 실습은 예상보다 시간이 조금 더 걸리기는 했지만, 역시나 모든 분들이 다 함께 실습을 맞췄다는데 의의를 둘 수 있을 것 같고.. 특히, 막판에 공통 메소드를 뽑아 낼 때 조금 이해도가 떨어지는 경우가 있었는데, 이 부분을 조금 더 이해하기 쉽도록 변경하면 좋겠다라는 생각도 들었구요..
JbcTemplate API로 무턱대고 바로 시작하는 내용 구성보다는 확실히 강의 이해도가 높아지는 걸 느낄 수 있었습니다. 작년 강의할 때는 Template 소개만 간단히 하고 바로 API 실습을 들어가는 방향으로 구성했을 때와 분위기가 사뭇 달랐습니다..
이번 주 강의 무사히 맞쳤고, 이제 다음 강의를 다시 준비해야겠네요..
또 어떤 내용을 함께 나눌지 고민해봐야 하는 한 주가 될것 같습니다..
-
-
영회 2009/06/29 15:13
할 일이 주어지지 않는다고 손 놓고 있으려고?
지난 주에 말해주려고 했는데 여의치 않아 못했는데
틈이 날 때 로그를 남기면 어떨까?
찬욱이도 자신이 어떻게 진행했나
1) 세세하게 기억하지 못할 뿐더러
2) 듣는 사람 관점이 보는 모습을 볼 수 없으니
분명 도움이 될꺼야.
교재가 있으니 교재 내용에 없지만, (a) 찬욱이가 활용한 설명을 적어두거나 (b) 오고 가는 질문 혹은 수강생이 어려워 하는 부분을 메모하거나 (c) 수강생 관점에서 아쉬운 점을 교재에 메모해두면 적은 노력으로 큰 효과를 거둘 듯 한데
-
-
차우차우 2009/06/29 21:35
개인적으로 아주 인상깊었던 두번째 강의 였습니다. 리팩토링을 통해 중복을 제거해 가는 모습이 신선했던것 같구요. 단순한 API교육보다 훨씬 몰입도가 있었습니다.
다른 교육생분들도 비슷한 생각들을 하시는것 같았구요 ^^
첫 째 날 강의가 무사히 끝났습니다.
열심히 준비한 만큼 많은 분들이 쉽게 이해해 가셨는지 모르겠네요..
강의 때도 (트래삐뽀리 동영상을 보여드리면서까지^^) 말씀드렸지만, 이번 강의의 목적은 크게 두 가지로 나눌 수 있습니다.
첫 번째는 Spring의 근간이 되는 개념들에 대해 이해하는 것이고, 두 번째는 이를 테스트를 통해서 검증해 나가는 것입니다.
아무래도 첫 번째 시간이니, 강의 하는 사람이나 강의 들으시는 분 모두 아직 몸이 덜 풀려 조금 분위기가 딱딱하긴 했지만,
다들 열심히 실습하시는 뜨거운 분위기 였습니다^^.
실습이 진행된 후에도, 코드를 뚫어져라 보면서 이게 왜 이런가 하는 표정으로 궁리하시는 분들을 보니 왠지 모를 만족감(?)이 뭉글뭉글 피어오르기도 했습니다. 아무튼 다음 주 강의는 더 알차게 준비해야죠.
실습이 조금 빠르다고 말씀해주신 분이 계셔서 다음 실습은 조금 더 세밀하게, 단계를 잘 나눠 준비해야 겠습니다.
열심히 준비한 만큼 많은 분들이 쉽게 이해해 가셨는지 모르겠네요..
강의 때도 (트래삐뽀리 동영상을 보여드리면서까지^^) 말씀드렸지만, 이번 강의의 목적은 크게 두 가지로 나눌 수 있습니다.
첫 번째는 Spring의 근간이 되는 개념들에 대해 이해하는 것이고, 두 번째는 이를 테스트를 통해서 검증해 나가는 것입니다.
아무래도 첫 번째 시간이니, 강의 하는 사람이나 강의 들으시는 분 모두 아직 몸이 덜 풀려 조금 분위기가 딱딱하긴 했지만,
다들 열심히 실습하시는 뜨거운 분위기 였습니다^^.
실습이 진행된 후에도, 코드를 뚫어져라 보면서 이게 왜 이런가 하는 표정으로 궁리하시는 분들을 보니 왠지 모를 만족감(?)이 뭉글뭉글 피어오르기도 했습니다. 아무튼 다음 주 강의는 더 알차게 준비해야죠.
실습이 조금 빠르다고 말씀해주신 분이 계셔서 다음 실습은 조금 더 세밀하게, 단계를 잘 나눠 준비해야 겠습니다.
-
윤성철 2009/06/22 14:04
안녕하세요 그날 수업을 들었던 사람입니다.
수업자료에 고심하신 흔적이 다 드러납니다.
자주 여기서 눈팅도 하고 했었는데 ^^
오늘쪽 상단에 사진과 실제로 뵌 모습과는 좀 느낌이 달랐습니다. ^^
포스가 느껴졌다고나 할까요~~...
저도 열심히해서 다른사람들에게 자신의 지식을 공유할 수 있는 사람이 되었으면
합니다.
앞으로 잘 부탁드리겠습니다.
P.S 제가 사회에서 사용하는 이름과 지인들과 사용하는 이름이 다릅니다 ^^
나중에 강의가 마무리 되고 회원여러분과 다시한번 자기소개할 기회가 되어
많은 분들과의 연을 계속 이어가고싶네요 ^^
좋은강의에 좋은 연을 이어갈 기회를 만들어주신 안회장님과 찬욱님께 감사드립니다 ^^
즐거운 하루 되세요~ ^^
근래 몇 달을 하루 3, 4시간 정도 자면서 보내니 슬슬 몸이 고장나기 시작했습니다..
오늘은 하루 종일 귀에 이명 현상이 심하게 나 머리가 다 지끈지끈 아플 정도였습니다..
오늘은 조금 일찍 자야할듯 합니다.
그래도 강의 준비는 해야하니 피티 조금 보다 자려고 컴퓨터를 잡고 있습니다.
이번 강좌는 정말 스프링을 배우고, 나누고 싶어하시는 분들만 모셔놓고 하는 시간이 될 것 같아 기대가 됩니다.
억지로 신청해서 시간 때우기로 듣는 시간이 아니라, 직접 (더군다나 선착순으로) 신청하고, 서류도 챙기시고..
아무튼 이런 분들이 모여서 나누는데 모자람이 없도록 준비하는 건 제 몫이니 열과 성을 다해야겠죠.
회사일도 있고, 번역도 있고, 가정 생활(아마 세 번째 언급해서 우리 부인에게는 혼날 겁니다^^;)도 있어 시간을 많이 내지 못하는게 가장 힘든 점이긴 하지만, 아내분의 배려로 그나마 밤 시간과 주말에 준비를 할 수 있어서 다행입니다. 그래도 준비하려고 하면 할 수록 시간이 부족할 뿐입니다.
집중을 조금 하다 보니 귀 소리가 더 커지네요.. 찾아 보니 1주일 정도 계속되면 병원 가라던데, 얼른 났으면 좋겠네요..
일하다 중간에 갈 수도 없고 말이죠..
이제 마무리하고 자야죠.
좋은 밤 되세요~
오늘은 하루 종일 귀에 이명 현상이 심하게 나 머리가 다 지끈지끈 아플 정도였습니다..
오늘은 조금 일찍 자야할듯 합니다.
그래도 강의 준비는 해야하니 피티 조금 보다 자려고 컴퓨터를 잡고 있습니다.
이번 강좌는 정말 스프링을 배우고, 나누고 싶어하시는 분들만 모셔놓고 하는 시간이 될 것 같아 기대가 됩니다.
억지로 신청해서 시간 때우기로 듣는 시간이 아니라, 직접 (더군다나 선착순으로) 신청하고, 서류도 챙기시고..
아무튼 이런 분들이 모여서 나누는데 모자람이 없도록 준비하는 건 제 몫이니 열과 성을 다해야겠죠.
회사일도 있고, 번역도 있고, 가정 생활(아마 세 번째 언급해서 우리 부인에게는 혼날 겁니다^^;)도 있어 시간을 많이 내지 못하는게 가장 힘든 점이긴 하지만, 아내분의 배려로 그나마 밤 시간과 주말에 준비를 할 수 있어서 다행입니다. 그래도 준비하려고 하면 할 수록 시간이 부족할 뿐입니다.
집중을 조금 하다 보니 귀 소리가 더 커지네요.. 찾아 보니 1주일 정도 계속되면 병원 가라던데, 얼른 났으면 좋겠네요..
일하다 중간에 갈 수도 없고 말이죠..
이제 마무리하고 자야죠.
좋은 밤 되세요~
-
물개 2009/06/09 11:01
흠.. 너무 무리하는거 아냐?
-
아내 2009/06/09 17:42
세번째 언급은 좀 섭섭하지만(!!)...
내조가 부족한 탓도 약간 있는듯해서 참을게요;;
몸에 좋다는 건강식품 주문해놨어요♨
당신이 아프면 내맘이 더 아프단거 잊지말구..
우리남편 화이팅~~^0^!! -
2009/06/03 00:41
Spring Web Flow를 활용해 복잡스러운 화면 처리 방법 고민해보기.
2009/06/03 00:41 in Spring 지식 공유하기/web flow
예약 처리 화면을 생각해보면, 사용자가 직접 예약을 하는 웹 사이트 화면은 간단할지 모르겠지만, 직접 예약을 처리해주는 업무 프로그램의 화면 같은 경우에는 엄청나게 복잡한 화면을 구성하게 됩니다.
요즘 저희 관심사 중에 하나가 이렇게 복잡한 화면을 보다 정형화 하고, 쉽게 처리할 수 있는 방법을 찾는 겁니다.
이런 유형의 화면에서 관심을 갖어야 하는 부분으로는 일단 가장 먼저 값의 상태 처리가 될 수 있을 것 같습니다.
프레임으로 나눈 5 개 이상의 화면에, 팝업 화면이나 입력 도중에 발생하는 다양한 액션이 존재하는 화면을 생각해보면,
우선 각 화면에 맞춰 논리적인 업무 트랜잭션이 끝날 때까지 상태를 유지하고, 또 끝날 때 뒷처리해주는 비즈니스 로직과는 관련 없는 부수적인 작업에 대한 코드가 상당히 많이 필요합니다.
두 번째로 URL 처리 방법도 이슈가 될 수 있습니다. 앞서 말했듯이, 해당 업무에 대한 정말 다양한 액션이 일어날 텐데 이를 매번 컨트롤러 매핑 해야할 수 있고, (당연히) 패턴으로 매핑시켜도 단순한 조회성의 업무들은 by-pass 형식의 컨트롤러가 난무할 수도 있습니다. 더군다나 실제로는 하나의 JSP로 구성되는 화면 조각들이 개별 URL을 갖게 되어, 나쁜 행동의 빌미를 제공할 수도 있습니다.
특히 물론 해당 화면 내에 각 액션들이 서로 유기적으로 연관을 맺고 있으며, 논리적인 트랜잭션으로 묶을 수 있는 어떤 흐름(flow, 또는 conversation)을 갖고 있는 경우가 있을 수도 있습니다.
이런 유형의 화면을 처리하는 서버 쪽의 방법(해결책)으로 Spring Web Flow를 적용하기 위해 테스트하고 있습니다.
SWF 적용하면 순차적으로 flow를 갖는 화면만 떠올리기 쉬운데, 곰곰히 생각해보면 위에서 언급했던 상황처럼 한 페이지가 여러 프레임나 div로 나뉘는 상황에서도 손쉽게 처리할 수 있는 훌륭한 기반이 됩니다. 실제로 화면을 구성하는 방법을 달리(한 화면 모음 내에 다수의 페이지 fragment냐, 화면 당 하나의 페이지를 갖도록 flow를 두느냐겠죠..)한 것일 뿐, 페이지의 흐름으로 구성된 것과 일맥상통한다고 볼 수 있겠습니다.
일단 첫 번째 이슈는 SWF의 다양한 Scope을 활용하면 정말 간단하고, 강력하게 처리할 수 있습니다. SWF는 Scope 내 자동 객체 처리 기능을 제공하며, 특정 Scope에 바인딩된 객체는 해당 Scope 생명주기 동안 유지되며, 또한 쉽게 접근해서 사용할 수 있습니다. flowScope.booking 처럼 말이죠. 해당 Scope이 끝나면 자동으로 언바인딩이 됩니다. 화면단에서도 객체와 적절히 매핑(form binding)하기만 하면, 서버단에서 별도의 매핑 로직 없이도 자연스레 객체 바인딩이 되는 장점을 얻을 수도 있습니다.(상당히 편리합니다.) 여기에 자연스레 화면당 언바인딩(unbiding)도 가능합니다.
두 번째 이슈도 손쉽게 해결이 됩니다. 일단 SWF는 해당 Flow 내에서는 파라미터를 기준으로 네비게이션이 되기 때문에,별도의 URL이 필요가 없습니다. Flow 내 각 state들은 동일한 URL을 갖게 되는 것이죠. 그리고 (구성하기에 따라 다르지만) 컨트롤러를 전혀 작성하지 않고도, 기존에 개발된 (또는 맞춰 개발한) 서비스 단의 메소드를 활용해 각 액션 지정마다 바인딩이 가능합니다.
간단히 생각나는데로 적어봤지만, 이 외에도 SWF를 도입함으로써 얻을 수 있는 다양한 장점을 기반으로 구성할 수 있다는 장점이 많이 있습니다. (백터튼, get-post-redirect 처리 등)
JSP에서 커스텀 태그를 활용해 보다 편리하게 화면에서의 액션을 구성할 수 있습니다. 실행키(execution key)를 파라미터로 매번 던지기도 불편하고, 이벤트 ID를 주는 방법도 물편하니, 커스텀 태그로 훨씬 접근성을 높일 수 있습니다. SWF 지라를 살펴보면 3.x에서 커스텀 태그를 제공한다고 합니다.
그러나 장점만 있는 건 아닙니다.
일단 추가로 XML 설정이 필요합니다. 이 문제는 보는 관점에 따라 견해가 다양한데, 제 생각으로는 여기 저기 흩어져 있는 코드들 보다는, 관련 처리에 대한 정의를 이 XML 파일에 집중해 적용하고, 관리하는 것도 그리 나쁘지 않다고 생각합니다. DSL까지는 아니더라도, flow xml 파일로 화면 흐름을 파악하는데도 많은 도움이 됩니다.
그리고 아직은 Ajax 연동이 썩 자연스럽지 않습니다. 저는 주로 jQuery기반으로 작업을 하는데 아직 spring-js는 Dojo 기반의 기능만 제공합니다. 일부 사용자들인 각 ajax 프레임웍으로 구현해서 올리기도 했던데.. 조금더 기달려 봐야될 것 같습니다.
그 외에도 생각해볼 다양한 문제들이 있는데, 일단 오늘 이정도에서 정리하고 넘어가야 할 것 같습니다.^^;
요즘 저희 관심사 중에 하나가 이렇게 복잡한 화면을 보다 정형화 하고, 쉽게 처리할 수 있는 방법을 찾는 겁니다.
이런 유형의 화면에서 관심을 갖어야 하는 부분으로는 일단 가장 먼저 값의 상태 처리가 될 수 있을 것 같습니다.
프레임으로 나눈 5 개 이상의 화면에, 팝업 화면이나 입력 도중에 발생하는 다양한 액션이 존재하는 화면을 생각해보면,
우선 각 화면에 맞춰 논리적인 업무 트랜잭션이 끝날 때까지 상태를 유지하고, 또 끝날 때 뒷처리해주는 비즈니스 로직과는 관련 없는 부수적인 작업에 대한 코드가 상당히 많이 필요합니다.
두 번째로 URL 처리 방법도 이슈가 될 수 있습니다. 앞서 말했듯이, 해당 업무에 대한 정말 다양한 액션이 일어날 텐데 이를 매번 컨트롤러 매핑 해야할 수 있고, (당연히) 패턴으로 매핑시켜도 단순한 조회성의 업무들은 by-pass 형식의 컨트롤러가 난무할 수도 있습니다. 더군다나 실제로는 하나의 JSP로 구성되는 화면 조각들이 개별 URL을 갖게 되어, 나쁜 행동의 빌미를 제공할 수도 있습니다.
특히 물론 해당 화면 내에 각 액션들이 서로 유기적으로 연관을 맺고 있으며, 논리적인 트랜잭션으로 묶을 수 있는 어떤 흐름(flow, 또는 conversation)을 갖고 있는 경우가 있을 수도 있습니다.
이런 유형의 화면을 처리하는 서버 쪽의 방법(해결책)으로 Spring Web Flow를 적용하기 위해 테스트하고 있습니다.
SWF 적용하면 순차적으로 flow를 갖는 화면만 떠올리기 쉬운데, 곰곰히 생각해보면 위에서 언급했던 상황처럼 한 페이지가 여러 프레임나 div로 나뉘는 상황에서도 손쉽게 처리할 수 있는 훌륭한 기반이 됩니다. 실제로 화면을 구성하는 방법을 달리(한 화면 모음 내에 다수의 페이지 fragment냐, 화면 당 하나의 페이지를 갖도록 flow를 두느냐겠죠..)한 것일 뿐, 페이지의 흐름으로 구성된 것과 일맥상통한다고 볼 수 있겠습니다.
일단 첫 번째 이슈는 SWF의 다양한 Scope을 활용하면 정말 간단하고, 강력하게 처리할 수 있습니다. SWF는 Scope 내 자동 객체 처리 기능을 제공하며, 특정 Scope에 바인딩된 객체는 해당 Scope 생명주기 동안 유지되며, 또한 쉽게 접근해서 사용할 수 있습니다. flowScope.booking 처럼 말이죠. 해당 Scope이 끝나면 자동으로 언바인딩이 됩니다. 화면단에서도 객체와 적절히 매핑(form binding)하기만 하면, 서버단에서 별도의 매핑 로직 없이도 자연스레 객체 바인딩이 되는 장점을 얻을 수도 있습니다.(상당히 편리합니다.) 여기에 자연스레 화면당 언바인딩(unbiding)도 가능합니다.
두 번째 이슈도 손쉽게 해결이 됩니다. 일단 SWF는 해당 Flow 내에서는 파라미터를 기준으로 네비게이션이 되기 때문에,별도의 URL이 필요가 없습니다. Flow 내 각 state들은 동일한 URL을 갖게 되는 것이죠. 그리고 (구성하기에 따라 다르지만) 컨트롤러를 전혀 작성하지 않고도, 기존에 개발된 (또는 맞춰 개발한) 서비스 단의 메소드를 활용해 각 액션 지정마다 바인딩이 가능합니다.
간단히 생각나는데로 적어봤지만, 이 외에도 SWF를 도입함으로써 얻을 수 있는 다양한 장점을 기반으로 구성할 수 있다는 장점이 많이 있습니다. (백터튼, get-post-redirect 처리 등)
JSP에서 커스텀 태그를 활용해 보다 편리하게 화면에서의 액션을 구성할 수 있습니다. 실행키(execution key)를 파라미터로 매번 던지기도 불편하고, 이벤트 ID를 주는 방법도 물편하니, 커스텀 태그로 훨씬 접근성을 높일 수 있습니다. SWF 지라를 살펴보면 3.x에서 커스텀 태그를 제공한다고 합니다.
그러나 장점만 있는 건 아닙니다.
일단 추가로 XML 설정이 필요합니다. 이 문제는 보는 관점에 따라 견해가 다양한데, 제 생각으로는 여기 저기 흩어져 있는 코드들 보다는, 관련 처리에 대한 정의를 이 XML 파일에 집중해 적용하고, 관리하는 것도 그리 나쁘지 않다고 생각합니다. DSL까지는 아니더라도, flow xml 파일로 화면 흐름을 파악하는데도 많은 도움이 됩니다.
그리고 아직은 Ajax 연동이 썩 자연스럽지 않습니다. 저는 주로 jQuery기반으로 작업을 하는데 아직 spring-js는 Dojo 기반의 기능만 제공합니다. 일부 사용자들인 각 ajax 프레임웍으로 구현해서 올리기도 했던데.. 조금더 기달려 봐야될 것 같습니다.
그 외에도 생각해볼 다양한 문제들이 있는데, 일단 오늘 이정도에서 정리하고 넘어가야 할 것 같습니다.^^;
2009. 05. 21
몇 일만에 켄트 아저씨한테 답장이 왔습니다.
현재 JUnit Max 구현 구조상 JVM을 선택해서 사용하도록 변경은 어렵다고 하면서, 자기 작업 리스트를 보여주면서 빨리 처리해줘야 하냐고 물어보더군요.. 일단 짧은 영어로 지금 JUnit Max를 거의 사용하지 못하고 있다라고 답해줬습니다.
확실히 바쁜지 답이 몇 일 지나야 옵니다.
어쨌든 사소한 요청 하나에도 정겹게 답해주는 켄트 아저씨가 한 번 보고 싶은 뿐이죠.
=======================================================================================================
JUnit Max를 사용한지 3주 정도 지났습니다..
근근히 테스트 할 때 상당히 편리하며, 제게 주는 가장큰 장점은 백그라운드 테스트의 결과를 마치 컴파일 에러인 마냥 빨간불을 켜준다는 겁니다.
개발 중에 눈에 제대로 띄기 때문에 매우 좋습니다.
그러나 사용상 가장 큰 문제는 JDK 1.4 기반에서는 실행되지 않는다는 점입니다.
JUnit Max는 해당 프로젝트에 설정된 JDK로 실행되게 되는데, 프로젝트의 JDK가 1.4면 JVM을 찾을 수 없다며 실행되지 않습니다.
제가 Yahoo 계정을 잊어먹어, 직접 켄트백 아저씨한테 메일 보냈더니, JDK 1.4는 지원하지 않는다고 하더군요.
JDK 1.4는 지원하지 않는다고, 공식 페이지제 올려주겠답니다..
그래도 JVM을 선택하는 방법으로라도 지원해주는건 어떻겠냐고 보냈는데, 아직 답이 없습니다.. >.<
몇 일만에 켄트 아저씨한테 답장이 왔습니다.
현재 JUnit Max 구현 구조상 JVM을 선택해서 사용하도록 변경은 어렵다고 하면서, 자기 작업 리스트를 보여주면서 빨리 처리해줘야 하냐고 물어보더군요.. 일단 짧은 영어로 지금 JUnit Max를 거의 사용하지 못하고 있다라고 답해줬습니다.
확실히 바쁜지 답이 몇 일 지나야 옵니다.
어쨌든 사소한 요청 하나에도 정겹게 답해주는 켄트 아저씨가 한 번 보고 싶은 뿐이죠.
=======================================================================================================
JUnit Max를 사용한지 3주 정도 지났습니다..
근근히 테스트 할 때 상당히 편리하며, 제게 주는 가장큰 장점은 백그라운드 테스트의 결과를 마치 컴파일 에러인 마냥 빨간불을 켜준다는 겁니다.
개발 중에 눈에 제대로 띄기 때문에 매우 좋습니다.
그러나 사용상 가장 큰 문제는 JDK 1.4 기반에서는 실행되지 않는다는 점입니다.
JUnit Max는 해당 프로젝트에 설정된 JDK로 실행되게 되는데, 프로젝트의 JDK가 1.4면 JVM을 찾을 수 없다며 실행되지 않습니다.
제가 Yahoo 계정을 잊어먹어, 직접 켄트백 아저씨한테 메일 보냈더니, JDK 1.4는 지원하지 않는다고 하더군요.
JDK 1.4는 지원하지 않는다고, 공식 페이지제 올려주겠답니다..
그래도 JVM을 선택하는 방법으로라도 지원해주는건 어떻겠냐고 보냈는데, 아직 답이 없습니다.. >.<
Prev
Rss Feed
