머리가 나빠서인지 정규식은 사용할 때 열심히 습득하고 나서 한동안 쓰지 않으면 바로 잊어버리는 경향이 있어 정규식 빌더를 galileo 기반에서 만들어 봤다.
위 그림에서와 같이 정규식을 입력하고 검색 문자열을 입력하면 정상적인지 검증해 준다.
그림에서 검증한 내용은 email 값을 validation 하도록 구성해 봤다. 정규식 테스트에 조금이나마 도움이 되길 바란다.
소스는 http://code.google.com/p/regex-builder/ 에서 공개하고 있다.
업데이트사이트는 http://regex-builder.googlecode.com/svn/zbum.tool.site/site.xml 이다.
]]>1. 아래는 블로그나 웹사이트에 설치할 수 있는 위젯을 등록하기 위한 Script 이다.
| <div style="width: 400px" jquery1256011821610="55" sizset="0" sizcache="8" jquery1256514468082="55"> <script src="http://www.bbc.co.uk/worldservice/widget/widget.js" type="text/javascript"></script> <script type="text/javascript">bbcwswidget.settings({"package" : "le"}); </script> </div> |
2. 홈페이지나 블로그 뿐만 아니라 iGoogle, windows Vista Sidebar, Netvibes, Mac Dashboard, WordPress에서 사용할 수 있는 버전도 제공될 예정이다. (이미 제공하고 잇는 것도 있다)
http://www.bbc.co.uk/worldservice/learningenglish/specials/2009/07/090710_widget_page_2.shtml
]]>깊은 고민 속에 정말 세련되고 아름답고 유용한 기능을 제공했다고 하더라고 여전히 기능요구사항 1건에 대해서 동일한 비용이 지불된다. 눈에 보이지 않는 기능 개발은 결코 돈으로 환산되지 않는다.
관리자의 입장에서 비행 고도를 정하지 못하고 방황하는 개발자를 보면 리소스 낭비로 밖에 볼 수 없다.
나 역시 그런 성향이지만 한가지 이슈에 몰입하고 그 문제를 해결하거나 좋은 기능을 제공하기 위해서는 기꺼이 시키지 않은 야근이라도 해 왔었다. 그럴때 마다 한번씩 생각해보자. 이 활동이 고객에게 가치를 주는 것인지..
좀 더 좋은 기능을 제공하기 위해서 밤을 불사르고 있는 개발자 들이여… SI 의 현실을 직시하고 기술 연마는 집에서 하자. 인정해 주지 않고 이해하지도 못하는 곳에서 row level 기술을 뽐내봐야 허공에 치는 메아리도 못 들을 것이다.
이걸 왜 지금 알았을까…
]]>“쎈과 서연이의 행방불명” 블로그의 내용을 참조하여 eclipse의 mylyn과 google code의 issue 관리기능을 연동해 보았다.
혹시 몰라 내가 했던 작업을 복기해 본다.
1. google code 와 mylyn 연동 참조 사이트 검색
google 검색을 통하여 발견한 아래 두 사이트에서 주요 정보를 얻었다.
- http://eclipse.dzone.com/articles/using-mylyn-with-google-code-u
- http://docs.ssen.name/entry/AS3-Friends-Mylyn-과-Google-Code-Project-Issue-연동하기
2. eclipse mylyn connector 설치
- update site는 http://download.eclipse.org/tools/mylyn/update/incubator 임
- 여기서 Mylyn connector : Web Templates(Advanced) 설치 ( Mylyn과 Mylyn Extras가 설치되었음을 가정 )
3. Task Repository 에서 google code 를 등록
- window > show view > Task Repositories를 선택하여 Task Repositories를 표시한다.
- Context Menu 에서 Add Task Repositories , Web Template(Advanced) 선택
- server 에 http://code.google.com/p/${project name}/issues 입력 ( ${project name} 는 각자의 프로젝트 명으로 고치세요 )
- Label은 Task Repositories 에 표시될 명칭임 아무거나 바꿔도 됨.
4. Query 생성
- Task Repository 에서 Label 명을 선택하고 Context 메뉴에서 New Query 선택
- 아래와 같이 입력
Query URL : ${serverUrl}/csv?colspec=ID+Status+Type+Owner+Summary
Query Pattern : "({Id}[0-9]+?)","({Status}.*?)","({Type}.*?)","({Owner}.*?)","({Description}.*?)"\n
5. 이슈 생성
- Task List > New > Task > google repository(설정에 따라 다름) > Next > Finish
- 이슈 등록
끝~
]]>
적용 사례
사용방법
| <html> <body> <textarea> </textarea> </body> </html> |
실제 프로젝트에 적용해 보면 약간의 오차가 발생한다.
특히 space 가 많아 지면 오차가 더욱 커진다.
이를 해결하기 위해서 원 소스를 일부 수정하였다.
수정내역
| 원소스 var textareaContent = $textarea.val().replace(/&/g,"&").replace(/<|>/g, ' ').replace(/\n/g, '<br />'); 수정 소스 var textareaContent = $textarea.val().replace(/&/g,"&").replace(/ /g, ' ').replace(/<|>/g, ' ').replace(/\n/g, '<br />'); |
수정기능 확인
아직 스페이스에 대해서 완벽하게 동작하지는 않지만 어느 정도 된 듯 아닌 듯 하다… 시간날 때 좀더 봐야 겠다.
]]>결국 새로운 시도는 내가 만든 코드의 JUnit Test Case test를 유지하기로 맘 먹었다. 적어도 coverage를 60%이상 올려 보겠다는 목표를 세웠다. 알아 보고 싶은 것은 SI프로젝트에서 test case를 junit으로 만들고 유지하는 것이 가능한가를 스스로 검증해 보고 싶은 것이다.
상세 확인 내용은 아래와 같다 물론 정량적인 데이터는 생산하지 않을 작정이다. 만든다고 해서 믿어주지도 않겠지만 너무 많은 리소스를 이 일에 썼다간 X부장님과 마누라가 가만 있지 않을 것 같았다.
1. Spring 기반의 test case 구현이 정말 어려운가?
2. junit 로 검증한 코드의 품질이 다른 코드보다 높은가?
3. SI 프로젝트에서 junit을 강제 사항으로 적용하는 것이 정말 불가능한가?
4년만에 정보시스템의 업무개발 (가끔 이걸 게시판 만들기라고 비하할 때가 있다. ^^ 하지만 게시판을 우습게 보면 안된다.)을 하면서 다른 프레임워크에서는 고려가 없거나 불가능 하다고 생각했던 테스트 코드들이 Spring Framework에서는 가능했다. 프레임워크 개발자가 각 컴포넌트를 개발할 때 “테스트 가능한가?”에 대한 많은 질문을 하면서 만들었다고 상상하는 즐거움을 가지기도 했다. 이렇게 배경설명을 길게 하는 건 적어도 spring 기반 하에서는 Test Code 만들기가 어렵지 않다는 것이다. 많은 지원도구와 샘플들이 존재한다. 결국 1번의 결론은 어렵지 않다! 이다. 하지만 프로젝트 진행 중 어느 누구에게서도 조언을 구하기는 어렵다! 도 함께한다. 불행스럽게도 주변에서 테스트 전문가라는 말을 듣기 까지 했다.
<계속..>
]]>
이제 직접 subversive를 설치하고 subversion과 연동하는 과정을 살펴본다. 이는 동작하고 있는 subversion 이 개발환경에 설치되어 서비스하고 있음을 가정하고 진행한다.
1. subversive 설치
2. Subversion 연동 설정
3. 결론
여기까지 Subversion과 Eclipse를 연동하기 위한 설치와 설정을 설명하였다.
]]>이때 마다 Command 창을 뛰우고 "cd 경로"를 하긴 너무 귀찮다.
탐색기의 컨텍스트 메뉴에서 Command Prompt를 뛰울 수 있다면 매우 편리할 것이다.
아래의 방법으로 개발생산성을 높여 보자.
http://www.suodenjoki.dk/us/productions/articles/cmdprompt.htm
]]>http://download2.bea.com/pub/platform/81/server816_hpux32.bin
http://download2.bea.com/pub/platform/81/server816_win32.exe
http://download2.bea.com/pub/platform/81/server816_generic.jar
]]>${WarDirectory}/WEB-INF/web.xml에 다음과 같이 filter를 설정한다.
아래 xml에서 적용한 Filter는 SpringFramework에서 제공하는 필터이다. 기타 jboss, tomcat 등에서 제공하는 필터도 동일하게 적용할 수 있다.
| <filter> <filter-mapping> |
여기서 설정하는 Port는 jboss가 기동/종료 됨을 감지하는 정도의 역할 밖에 하지 않는 것 같다. jboss의 웹 포트를 변경하려면 다음의 설정파일을 수정하여햐 한다.
| ${jboss_installed_directory}/server/default/deploy/jboss-web.deployer/server.xml |
이 파일에서 Connector의 port를 수정하면 jboss의 웹포트가 변경된다.
| <Connector port="9090" address="${jboss.bind.address}" …. <Connector port="9009" address="${jboss.bind.address}" protocol="AJP/1.3" |
 |
 |
 |
프로젝트에서 java 빌드 툴로서 ANT 또는 maven을 선택해야 할 때, 두 도구의 차이점을 이해함으로써 많은 도움을 얻을 수 있을 것이다.
개발(자)의 관점에서의 빌드도구
경영자의 관점에서의 빌드도구
역사적으로 ANT는 매우 오래된 빌드 도구 이다. 어떤 면에서는 C 나 C++의 make 와 흡사하다. 과거 make를 이용한 개발자들은 그들이 원하는 것이면 무엇이든 처리할 수 있었다. 하지만 ANT는 좀 다르다. make가 Shell 커멘드를 확장한 반면 ANT는 java class를 확장하는 방식이기 때문이다. shell 커멘드를 빌드 스크립트에 포함하는 것이 아닌 xml 기반의 설정파일을 작성하여야 한다. 각 프로젝트에서는 각각의 다른 Build Process를 작성해야 하고 새로운 팀 멤버는 그 빌드 파일을 분석해야 하는 부담이 있다.
반면에 Maven은 빌드 프로세스를 표준화하였고, 프로젝트의 구성을 규정하고, 프로젝트 정보에 대한 산출물 작성을 용이하게 하고 , 타 프로젝트 jar파일의 의존성을 관리하도록 하였다. Maven은 배스트 프렉티스를 권장한다.
Maven은 ANT에 비해서는 다소 유연하지 못한 면이 있다. 하지만, Maven은 ANT의 TASK를 호출할 수 있기 때문에, ANT에서 할 수 있는 모든 작업이 Maven에서 가능하다.
ANT에서 ,Maven으로 전향해서 얻을수 있는 장점은 프로젝트 빌드의 표준화, 명확히 정의된 의존성, 다른 프로젝트와 공유할 수 있는 산출물 컨셉, 보고서 등이다.
Maven과 Ant 비교표
| Maven | ANT |
| 프로젝트에 대한 기술 | 각 프로젝트마다 빌드 스크립트 개발 |
| 기 구현된 goal(taget) 수행 | 프로젝트 특화된 target 수행 |
| 프로젝트 전체 정보를 정의 | 빌드 프로세스만 정의 |
| 빌드 생명주기, 표준화된 디렉토리 레이아웃 | 매우 복잡한 빌드 스크립트 |
| 재사용 가능한 플러그인, 저장소 | 스크립트가 재사용 가능하지 않음 |
| 매우 빠른 속도로 발전하고 있음 | 발전속도가 느려짐 |
Maven은 온라인 저장소에 들어 있는 매우 많은 플러그인 들로 구성되어 있어 매우 유연하다고 할 수 있다.
]]>