[JS]prototype.js로 기본적인 배열 다루기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

prototype.js에서 제공하는 배열을 다루는 함수는 꽤나 강력하다. 여러가지가 있는데

• all() -> boolean
• any() -> boolean
• include() -> blolean
• size() -> number

가 잇다.

사용법은 간단하다.

var testArray = $w("5 7 10 25 59");
testArray.all(function(t) {return t > 2;});

와 같이 사용한다. testArray안에 모든 아이템이 함수안에 있는 조건을 만족하는 지를 검사한다. 모두 만족하면 true를 반환하고 하나라도 만족하지 않는 것이 있으면 false를 반환하고 순회를 멈춘다.

var testArray = $w("5 7 10 25 59");
testArray.any(function(t) {return t > 50;});

any는 all과는 반대로 단 하나라도 만족하는 것이 있는지를 검사한다. 아이템중에 단 하나라도 만족하는게 있으면 true를 반환하고 하나도 만족하는 것이 없으면 false를 반환한다.

var testArray = $w("5 7 10 25 59");
testArray.include(7);

include는 파라미터안에 값이 배열내에 있는지를 검사한다. 있으면 true를 반환하고 없으면 false를 검사한다. 비교는 ===가 아닌 ==를 사용해서 비교한다. 이거 배열 순회돌리면서 조건검사할때 상당히 유용하다.

var testArray = $w("5 7 10 25 59");
testArray.size();

size()는 다른언어에서도 많이 사용하듯이 그냥 사이즈이다. 위의 경우에는 5를 리턴한다.

이 외에도 배열을 다루는 많은 메서드들이 있지만 인단 사용해 본것들 위주로 정리... 손에 익어야 자유자재로 쓸텐데... ㅎㅎㅎ

[JAVA]리다이렉트 방식에 대해서..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

리다이렉트는 현재페이지를 다른페이지로 보내는 것을 말한다. 포워드와는 다르게 리다이렉트는 클라이언트단에서(브라우저) 발생하게 되고 결과적으로 보면 새로운 URL로 요청이 다시 일어나도록 하는 것이다. 자바의 입장에서 보면 리다이렉트에는 3가지 방법이 있다.

1. 메타태그 이용
   <meta http-equiv="refresh" content="0; url=http://www.google.co.kr">
2. 자바스크립트 이용
   document.location.href= "http://www.google.co.kr";
3. sendRedirect이용
   <%
       response.sendRedirect("http://www.google.co.kr");
   %>

1,2번의 방법은 브라우저가 소스를 보고 판별해서 재요청을 하는것이고 3번째 방법은 전에 포스팅에 올렸던대로 header정보를 이용해서 브라우저가 리다이렉트를 하도록 서버쪽에서 코드를 심는 방법이다.(자바에선 이렇게 쓰고 헤더를 이용하는 방법은 다른 언어에도 있다.)

나는 1번은 잘 사용안하고 보통 2번을 사용하거나 3번을 사용한다. 솔직히 그냥 그때 기분내키는대로?? ㅡ..ㅡ

여러가지 용도가 있겠지만 가장 노말하고 일반적으로 쓰이는 곳이 게시판등의 글등록이 아닐까 싶다.

등록폼 페이지 -> 등록 처리 페이지 -> 처리 후 이동할 페이지

보통 이런  단계를 밟아서 페이지를 만든다. 이제 가장 노말한 형태이다. 등록폼에서 내용을 입력하고 submit을 누르면 등 등록처리 페이지에서 등록처리를 해서 DB에 넣고 alert() 메시지로 등록 성공 혹은 실패 메시지를 뿌려준 뒤에 상황에 맞는 페이지로 이동을 시킨다. 여기서 이동을 시킬때 리다이렉트를 할 필요가 있다. 이동자체야 큰 차이점은 없지만 사용자 입장에서 2번과 3번 방법에 큰 차이점이 있다.

이 2가지 방법 사이에 가장 큰 차이점은 "뒤로가기"의 활성화 여부이다. 이건 UX적인 면에서 큰 차이점이라고 생각한다. 흔히들 많이 보았을 것이다. 처리후 이동한 페이지에서 뒤로가기 버튼을 누르면 등록처리페이지로 뒤로가기가 되서 다시 alert이 뜨고 처리후 이동페이지로 다시 오게되는 현상(또는 에러가 나거나...) 의도대로 하면 되겠지만 처리페이지는 DB저장등을 위해서 존재하는 페이지이기 때문에 뒤로가기과정에서는 나타나지 않는게 정상이 아닌가 싶다. 그래서 좀 정리를 해 봤다.

자바스크립트 document.location.href= "http://www.google.co.kr";로 리다이렉트 했을 경우

IE6 : 등록처리 페이지로 뒤로가기 된뒤 다시 alert뜨고 원래페이지로 다시 돌아옴
IE7 : 등록처리 페이지로 뒤로가기 된뒤 다시 alert뜨고 원래페이지로 다시 돌아옴
Firefox2 : 등록폼 페이지로 뒤로가기 됨
Firefox3 : 등록폼 페이지로 뒤로가기 됨
Opera 9 : 등록처리 페이지로 뒤로가기 되지만 스크립트는 실행되지 않음.
Safari 3 : 등록처리 페이지로 뒤로가기 되지만 스크립트는 실행되지 않음.
Chrome : 등록처리 페이지로 뒤로가기 되지만 Confirm Form Resubmission라는 에러나옴

Http Header를 이용한 response.sendRedirect("http://www.google.co.kr");를 했을 경우

IE6 : 등록폼 페이지로 뒤로가기 됨
IE7 : 등록폼 페이지로 뒤로가기 됨
Firefox2 : 등록폼 페이지로 뒤로가기 됨
Firefox3 : 등록폼 페이지로 뒤로가기 됨
Opera 9 : 등록폼 페이지로 뒤로가기 됨
Safari 3 : 등록폼 페이지로 뒤로가기 됨
Chrome : 등록폼 페이지로 뒤로가기 됨

파이어폭스를 제외하고는 location.href를 사용하면 등록처리 페이지가 뒤로가기로 활성화가 된다. 사용자 편의성과 보안(?)면에서도 Http Header를 이용한 방식이 더 좋아보인다.

참고삼아 메타태그를 이용해서도 테스트를 해보았다.  메타태그를 이용했을때도 등록처리 페이지는 뒤로가기에 해당되지 않는다...
IE6 : 등록폼 페이지로 뒤로가기 됨
IE7 : 등록폼 페이지로 뒤로가기 됨
Firefox2 : 등록폼 페이지로 뒤로가기 됨
Firefox3 : 등록폼 페이지로 뒤로가기 됨
Opera 9 : 등록폼 페이지로 뒤로가기 됨
Safari 3 : 등록폼 페이지로 뒤로가기 됨
Chrome : 등록폼 페이지로 뒤로가기 됨

덧) 테스트한 웹브라우저 버전
IE6, IE 7.0, Firefox 2.0.0.14, Firefox 3.0.3, Opera 9.60 beta, Safari 3.1.2, Google Chrome 0.2.149.30

My Comment..
ㅋㅋㅋ.. 대단한 형.. 내가 만약 이 글을 포스팅 했다면, 저렇게 테스트를 할 수 있었을까..
아마도.. 아니 그냥 불가능 했을성 싶다.. 우선 귀차니즘이 문제지만..
각각의 사이트를 다 해본다는 것 자체가 짜증이 났을 듯한.. 그래도..
이렇게라도 보고서 "아.. 이런거였구나.." 하고 알게 되면.. 다행인듯.. ㅎㅎ..

[Book] 윈도우 프로젝트 필수 유틸리티..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

윈도우 프로젝트 필수 유틸리티 - 이재홍 지음/한빛미디어

난 개발환경에 상당히 관심이 많다. 더 좋은 환경, 자동화 되고 쉽고 편하고 빠르고... 등등.... 개발과 환경의 시간의 투자의 비중을 맞추려고 노력하고 있기는 하지만... 물론 툴 맹신주의자가 되지 않으려고 노력하고 있기는 하지만 툴의 이점을 충분히 이용하자고 믿는 주의이다. 초기에 툴의 적응과정에서의 어려움은 있을지 몰라도 그 뒤에는 훨씬 효율적으로 돌릴수 있다고 믿고 있기 때문에.....IDE를 안쓰고 에디트플러스를 특수한 과정이 아닌데서 사용한다면 솔직히 "미련하다"고 밖에 생각되지 않는다.

어쟀든 내가 이책을 본 가장 큰 이유중의 하나는 Trac이다. 몇년전부터 각광받기 시작한 Trac.... 대표적으로는 이 블로그 툴인 텍스트큐브의 개발주체인 TNF에서 사용하고 있다. 이슈트래킹과 위키를 결합한 시스템... 한번 써보려다가 실패하고는 아직 못써보고 있다. 물론 툴의 사용은 사용법 외에도 팀에 도입하려면 여러가지 어려움이 많기는 하지만.... ㅎㅎㅎㅎ

이 책은 윈도우 개발자가 개발환경의 일련화된 자동화 시스템을 구축하기 위한 모든 것을 다루고 있다. 형상관리툴인 Subversion, 자동화 빌드툴인 CruiseControl.NET, 그리고 이슈트래킹 시스템인 Trac에 Powershell까지... 저자가 초반에 언급한 대로 대부분의 자동화 시스템이 리눅스를 위주로 되어 있는데 반해 이책은 철저히 윈도우 위주로 되어 있고 설명도 각 설치화면까지 스크린샷을 떠서 자세하게 설명하고 있다. 내 경험상으로 툴을 익히는 것은 쉽지 않다. 솔직히 툴은 책으로 사기 약간 부담스런 면이 있기도 하고 아주 유명툴 아니면 책도 별로 없고 그중에 괜찮은 책도 적다. 대부분은 틈틈히 웹서핑을 통해서 터득해야 하는데 자료 얻기가 쉽지 않은게 사실이다.

툴의 적응을 위해서 각 툴의 용도와 사용법에 대해서 자세히 설명한 뒤에 각 툴을 어떤식으로 섞어서 전체 자동화 시스템을 구축하는지 설명하고 있다. 사용법에 집중하기는 했지만 중간중간 자주 직면할 수 있는 문제들에 설명을 해주고 있다. 개인적으로 툴은 적응력이라고 생각한다. 사용법이야 솔직히 몇번 다루면 컴맹 아닌이상 다룰수 있다. 그 다음부터는 그 툴에 얼마나 적응이 되어 있고 편하게 쓸수 있냐하는 건데 그걸 넘어서지 못하면 결국은 툴을 버리게 된다. 그런 면에서 다양환 케이스 또는 완성된 시스템에서의 편리함을 강조해 주어 툴 적응에 목표성을 갖게 된 점은 참 좋아보인다.

내가 가장 도움을 받은 부분은 서브버전과 트랙이다. 서브버전을 막상 찾아보면 많은 자료가 없고 또 너무 리눅스의 명령어 위주로만 되어 있어서 적응하기가 쉽지 않다. 단순 사용정도는 할 수 있었지만 충돌이나 여러면에서 해매고 있었던게 사실인데 이 책을 보면서 서브버전에 대해서큰 한번 죽 정리된 느낌이 있다. 개인적으로 이 책의 저자가 초기에 서브버전을 공부할때 열심히 보았던 매뉴얼인 피라시스닷컴의 운영자라는 것을 알고 좀 깜짝 놀랬다. 책의 각 팁을 보면 저자가 경험에서 얻은 많은 지식들이 책에 녹아 있는 것을 느낄 수 있다. 트랙이야 아예 몰랐으니 도움 받은건 당연하고... 트랙 자료는 찾기도 쉽지 않은데... ㅎㅎㅎㅎㅎ 저자인 이재홍님의 페이지에 가면 관련정보를 더 얻을 수 있다.

나는 웹개발자이지만 이책은 전체를 아우르기는 하지만 기본적으로는 윈도우용 개발자를 위해서 설명을 하고 있기 때문에 자바개발자인 나로써 그대로 적용하기는 어렵다. 보면서 내내 아직 써보진 못했지만 내 환경에서는 크루즈컨트롤보다는 Ant가 낫겠다는 생각을 계속 했다. 또한 파워쉘도 내가 언어를 배우는 전체적인 방향성에서는 파워셀보다는 파이썬이 낫겠다는 생각은 했다. 하지만 각 툴의 선택이야 회사에 자기에 맞게 얼마든지 바뀔수 있는 것인데.... 자동화된 개발환경 시스템에 대한 전체 그림을 좀 그리게 된데에도 나에겐 큰 도움이 되었다. (머 서브버전만으로도 만족이다.)

[Talk]지속적으로 날 괴롭히는 것들..

날 괴롭히는 것들이 있다.. 다름 아닌.. 용어 정의..
항상 헷갈리게 하는 것들이어서..
이번 기회에 정리해둔다.. 지금 당장 다 기억나는게 아니어서..
나중에 또 추가 될지도 모르겠다..

남들이 보면, "저게 왜..??" 라고 할 테지만..
머 내가 헷갈린다는데.. 어쩔.. ㅡㅡ.. 무엇보다 여기에 정의 되는 것들의 형식이..
여타 사이트와는 틀릴 수도 있다.. 왜냐면, 우선 내가 이해를 해야되기 때문에..
나만의 이해방식으로 변형되기 때문에.. 어쩔 수 없는 부분일 수도 있다..

내가 아직은 모든 사람이 다 이해될만한.. 3자 입장에서의 포스팅 능력은.. 안된당..

절대경로/상대경로..

• 절대경로는.. 모든 패키지를 다 정의해서 사용하는 주소라고 이해하면 될 듯 하다.. [이건 어디까지나 내가 이해하는 방식..]
• 예를 들어서 http://www.test.co.kr/ 사이트의 yong 폴더에 있는 test.html의 절대경로를 표시하면, http://www.test.co.kr/yong/test.html 이 되는 것..

• 상대경로는.. 반대라고 해야될까.. 모든 경로가 표시 되는 것이 아닌 ../ [현 위치에서 한 단계 전이라고 보면 됨] 으로 구분을 하는 것이라고 보면 된다.. 좀 더 축약해서 표현한다고 할까..
• 예를 들면 절대경로와 같은 똑같은 상황일 때.. yong/test.html 로 표시 되는게 아닌.. ../test.html 으로 표시..

주관적/객관적..

• 주관적은.. 내가 보는 입장.. 1인칭 시점이라고 해야 될 듯.. 내가 느끼고 내가 생각하고 내가 결정한.. 반응한 것들에 대한 모든 부분이다..

• 객관적은.. 내가 보는 것이 아닌.. 3자의 입장.. 즉, 연구결과 처럼.. 기타 모든 사람들에 의해서 정의되고 결정되어서.. 각종 발표자료로 쓰이는 증빙자료라던지 그런 신빙성 있는 자료를 바라보는 눈이라고 하면 판단이 쉽다..

여당/야당.. [이건 IT 도 아니고, 걍 내가 헷갈리는 거..]

• 여당은.. 집권계층.. 즉, 현 정권.. 대통령 라인에 있는 세력들을 뜻한다..

• 야당은.. 반대세력.. 집권계층을 반대하는 세력이다.. 그래서 우리 국회가 노상 싸우는.. 대통령에 반하는 세력이라고 보면 편하다..

동기/비동기..

• 동기는.. A와 B 가 있다고 하면, 두 개의 행위가 동일하게 이뤄지는것을 보면 된다.. 혹은 A가 너무 앞서가 있거나.. 선진행이 되었다면, 후 작업을 바로 하는것이 아니라.. B의 작업이 끝날 때까지 대기를 하다가 다시 진행되는 것이다..

• 비동기는.. 엇박자라고 생각할면 될듯하다.. 동기식이 손벽이 제대로 맞아서 소리가 나는것이라면, 반대로 비동기는 한박자씩 늦게 되는.. 엇박인 것이다..

[JS]script.aculo.us의 Builder 사용하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

자바스크립트 질을 하다보면 동적으로 HTML 엘리먼트를 생성해야 하는 경우가 있는데 이럴 경우에 innerHTML을 이용하는 방법과 DOM 스크립트를 이용하는 방법이 있다. innerHTML은 어떤 엘리먼트 안의 내용을 바꾸어 주는 것인데 스트링형태로 HTML코드를 직접 넣는 형태를 취하기 때문에 간단한 것은 편하지만 복잡한 구조의 엘리먼트 생성에는 적합하지가 없다. DOM 스크립팅은 appenChlild(), createElement()같은 메서드를 이용해서 엘리먼트를 추가/삭제하는 것인데 사용하기가 만만치 않다.

때문에 스크립타큘러스에서는 HTML 앨리먼트 생성을 위해서 Builder라는 클래스를 제공하고 있다. 스크립타큘러스의 Wiki를 보면 다음과 같이 정의되어 있다.

Builder.node( elementName )
Builder.node( elementName, attributes )
Builder.node( elementName, children )
Builder.node( elementName, attributes, children )

같은 함수명으로 4가지로 오버라이딩이 되어 있다. 필요한대로 사용하면 된다.

Builder.node()를 사용하려면 상단에 아래처럼
<script type="text/javascript" src="scriptaculous.js?load=builder"></script>
builder.js를 로드해야 한다.

var elem = Builder.node('div', {id:'test', name:'test', className:'layout'});
=> <div id="test" name="test" class="layout"></div>

var elem = Builder.node('img', {src:'/banner.gif', alt:'광고', onclick:'move();'});
=> <img src="/banner.gif" alt="광고" onclick="move();" />

var span = Builder.node('span', '텍스트 내용...');
=> <span>텍스트 내용...</span>

텍스트의 경우는 children이라고 생각하면 된다. 실제로 DOM서치를 하여도 그렇게 나오는거고. {}으로 사용하는 옵션에는 엘리먼트의 어트리뷰트를 그냥 써주면 된다. 몇번 해보면 따로 분석할 필요가 없을정도로 직관적이다. 다만 class는 className이라고 써주어야 한다는 것 외에는....


위처럼 간단한 경우야 innerHTML을 사용해도 되지만 실제 사용하면 훨씬 복잡한 경우가 자식이 있을 경우에는 아래와 같이 사용한다.

var elem = Builder.node('div', {id:'test', name:'test', className:'layout'},
                    Builder.node('div', {className:'innerStyle'}, '텍스트 내용')
               );
=> <div id="test" name="test" class="layout>
          <div class="innerStyle">텍스트 내용</div>
     </div>

TEXT를 집어 넣을때처런 children 위치에 Builder.noder()를 다시 삽입해 주면 된다. 이런식으로 삽입하면 복잡한 DOM도 직관적으로 만들어 낼 수 있다.


자식이 여러개일 경우는 배열([])을 사용한다.

var elem = Builder.node('div', {id:'test', name:'test', className:'layout'},
                     Builder.node('ul', {className:'ulstyle'},  [
                          Builder.node('li', '목록1'),
                          Builder.node('li', '목록2'),
                          Builder.node('li', '목록3'),
                          Builder.node('li', '목록4'),
                          Builder.node('li', '목록5'),
                     ])
                );
=> <div id="test" name="test" class="layout>
         <ul class="ulstyle">
               <li>목록1</li>
               <li>목록2</li>
               <li>목록3</li>
               <li>목록4</li>
               <li>목록5</li>
          </ul>
    </div>

한개일때는 그냥 사용해도 되지만 같은 레벨의 자식이 여러개인 경우에는 배열을 이용해서 추가해 주면 된다.

다 만들고 나면 일반적인 방법을 이용해서 만든 객체를 원하는 위치에 삽입해 주면 된다.

$("targetDivision").appenChlild(elem);
$("targetDivision").update(elem);
$("targetDivision").insert(elem);

삽입할 때는 원하는대로 사용이 가능하다.

[JS]prototype.js에서 $w로 배열상수 사용하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

배열 상수를 사용할 때 prototype.js에서 제공하는 $w를 사용하면 아주 편리하다. 배열 상수라는 건 여러가지로 쓰일 수 있겠지만 보통 어떤 여러가지 값을 원하는대로 불러다가 사용하기 위해서이다. 나같은 경우는 요일이랑 달 같은거...?

var month = ['1월', '2월', '3월', '4월', '5월', '6월', '7월', '8월', '9월', '10월', '11월', '12월'];

뭐 이런식으로... 따옴표(')랑 콤마(,)가 계속 반복되기 때문에 작성하는게 은근히 귀찮다. 또 중간에 추가하고 삭제하고 하려면 더 귀찮다....

var month = $w('1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월');

이렇게 쓸 수 있다. 따옴표를 한번만 묶어 주면 되고 공백으로 구분해 주면 된다. 그냥 보아도 훨신 편하다는 것을 알 수 있다. 추가나 삭제도 쉽게 할 수 있다. 이렇게 만들면 배열이랑 동일하게 each를 사용해서 루프를 돌려줄 수 있다.

JavaScript

month.each(function(m, idx) {
    // w는 루프돌면서 month를 받음
    // idx는 루프의 인덱스를 받음 (0부터 시작, 없어도 됨)
});

다만 공백으로 구분을 하기 때문에 공백이 들어있는 상수는 사용할 수 없다.

[EP]SUN Tech Days 2008 Seoul 2일차 후기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

썬테크데이 2008 2일차이다. 이렇게 세미나때문에 회사출근을 안한 적은 처음이라 왠지 어색했다. 서류 결재 다 받고 온 것이기는 한데 왠지 연락올 것 같은 불안감. ㅋ 썬테크데이는 회사에서 공식적인 휴가라고 이벤트 1등은 말이 크게 공감이 갔다. 쉬니까(?) 좀 편하긴 하네....  썬의 큰 행사답게 사람들은 엄청 많았다. 큰 행사치고는 제법 깔끔하게 진행하기는 했지만 특정 트랙으로 사람들이 몰려서 어떤 트랙쪽은 자리가 텅텅비고 어떤 트랙은 너무 사람많아서 들어가기도 힘들정도이고 외부에서도 볼수 있게 TV랑 스피커를 배치한 건 좋았지만 동시통역기는 전파가 약해서 제대로 들리지 못했던 점은 아쉽다. 특히 점심때 잘 줄서서 먹었는데 너무 많다보니 줄이 미친듯이 길게 서고 관리안되서 이리보냈다 저리보냈다 하고 정상적으로 먹고 왔더니만 이미 세션은 시작되어 있고 그런건 많이 아쉬웠다.

REST를 통한 네트워킹 - Michael Li

OpenAPI 때문에 관심은 많지만 아직 경험해보지는 못했던 REST... REST는 유니크한 URI를 이용하고 CRUD기능을 모두 제공하고 있는제 제한적으로 보이기는 하지만 실제로 생각해 보면 이 이상의 기능을 그리 필요하지 않다.

REST의 5가지 조건

1. 모든 것은 ID를 가지고 있다.
   아이디는 POJO를 사용하고 @Path어노테이션을 준다.(리소스에 아이디를 줄 수 있다.)
2. 모든 것은 Link 되어 있다.
   메서드의 이름은 중요하지 않고 어노테이션이 중요하다.
3. 표준적인 방법으로 접근한다.( Get(Select), Put(Update), Post(Insert), Delete)
   @produceMine을 이용하고 XML, JSON을 만든다.
   @consumeMine은 Put, Post를 받기 위해 사용한다.
4. Multiple Representation
5. Stateless Communication : state는 클라이언트에 따르기 때문에 서버는 Request만 받고 state가 없다.

서버측 장점

기존 웹인프라와 잘 맞는다. (CS간의 커플링이 줄어든다. 세션이 서버에 없어서 서버부담이 적다.)
서버세션이라는 것 자체가 없어서 failover가 쉽다.(별다른 셋팅없이 다른 서버로 넘기면 된다.)

클라이언트측 장점

캐쉬나 북마킹이 가능하다.
테스트가 쉽다.
모든 언어가 가능하다.
Data-Format이 다양하다.

REST는 아키텍쳐 스타일이다.


Simplicifying Persistence using JAP - Sridhar Reddy

원래는 AMD의 세션이었는데 세션이 취소되고 퍼시스턴트자바에 대한 세션으로 대체되었다.

EJB 에서는(난 아직 EJB 못해봤지만.. ㅠ..ㅠ) 엔티티빈을 만들때의 여러가지 이슈들이 있었다. 아무리 적게 만들어도 최소한 3개는 만들어야 하고 복잡하고 무겁다. 때문에 어떻게 EJB를 간소화 가능한가를 고민하게 되었고 EJB 3.0에서 간소화 하였다. 그리고 이 세션에서도 어노테이션에 대해서 언급을 했다. (어노테이션에 대해서 좀 공부를 해야겠구만...)


Comet 및 Ajax를 이용한 웹애플리케이션개발 - Michael Li

2일간의 컨퍼런스중에 나한테는 가장 쇼킹했던 세션.... Comet이 먼지도 몰랐지만 웹애플리케이션 개발이라길래 들어갔는데 이거 장난아니다. 웹이라는 거의 방식상 절대 불가능하다고 생각되는 것이 이 기술로 가능하다.

Comet은 기술이름인데 Ajax Push라고도 하고 Reverse Ajax라고도 한다. 개인적으로는 Comet이라는 이름이 잘 맘에 안 와닿아서 Ajax Push라는 이름이 더 맘에 든다. Comet이 뭐의 약자인가 했는데 어디서 유래됐는지는 모르겠지만 달리 유래가 나온 정보는 찾아볼 수가 없었다.

이 Comet이라는 기술은 마치 소켓통신같은걸 가능하게 한다. 일반적인 Ajax로는 서버로부터 무언가를 받으려면 반드시 요청을 날려주어야 한다. 그래서 수시로 업데이트가 되어야 하는 사이트(채팅등등)은 셋타임아웃으로 일정 기간 간격으로 요청을 계속 날려주는 것이 보통이다. 싸이월드 같은거 봐라 로긴하고 계속 보고 있으면 몇분마다 한번씩 요청해서 페이지가 갱신이 된다. 이게 당연한거고 이렇게 밖에 할 수 없었다. 하지만 Comet은 다르다. Comet 은 서버가 클라이언트에게 이벤트가 발생할 때마다 데이터를 보내고 클라이언트는 데이터가 돌아오면 처리하면 된다. 클라이언트가 데이터가 바뀌었는지 일일이 요청할 필요가 없어서 서버의 부하가 줄어들고 Latency나 트래픽도 줄어든다.

Ajax Push는 2가지가 있는데 Long Poll과 Streaming이다. Long Poll은 클라이언트가 Request를 보내면 서버가 응답해야 할 내용이 없으면 Request를 가지고 있다가 이벤트가 발생하면  Response를 보내고 클라이언트는 Response를 받고 다시 Request를 보낸다. Streaming방식은 Request를 서버가 받으면 그 Request를 이용해서 Event가 발생할 때마다 계속 Response를 보낸다.

이런 Ajax Push방식과 비교해서 기존의 Ajax방식은 Ajax Poll이라고 표현했다. Ajax Poll은 특성상 데이터가 없는 것과 서버와의 통신이 느린 것을 구별해 낼수가 없는데 Ajax Push는 이런 점을 해결 할 수가 있다.

물론 Ajax에도 문제가 있는데 특성상 Connection이 항상 열려 있는데 이런 쓰레드가 대기상태로 Block 되면 메모리를 잡아먹기 때문에 전통적인 서버기술로는 Commet을 효율적으로 쓰기가 쉽지 않다. JVM의 쓰레드 갯수를 늘려야 하기 때문에 서버 확장성에 문제가 있다. 이를 해결하는 방법이 JAVA NIO를 사용하여서 블럭킹이 되지 않게 하고 한 쓰레드가 여러 커넥션을 공유할 수 있도록 하며 여러 커넥션을 열어놓고도 블럭킹이 일어나지 않도록 해야 한다. 이렇게 하면 오직 오픈된 소켓수에만 제약을 받고 메모리 이슈가 없기 때문에 확장성을 가질 수 있다.

이에 필요한 기술로는 비동기 IO(비동기 Read/Write)와 서스펜스가 가능한 리퀘스트/레스폰스, 그리고 유요한 데이터 딜리버리를 보장하는 기술이다.

서버쪽 기술이 필요하긴 하지만 이거 완젼 흥미로와.. 이런게 되다니.. ㅠ..ㅠ


OpenSSO 및 OpenID를 비롯한 웹보안 강화방안 - Sang Shin

오픈아이디에 관심도 많고 아이덴티티 2.0에서 관심이 집중되고 있는 기술인데 크게 얻을만한 건 많이 없었다.

SSO의 이슈는 조직내에서의 SSO와 조직외에서의 SSO라고 할 수 있는데 OpenSSO가 이에 대한 대안이 될수 있다. 코딩이 필요없고 Aject가 인터셉트를 하고 SAML을 이용해서 권한을 교환한다.

자세한 기술얘기는 많이 논하지 않아서 이렇다하게 정의하기가 쉽지 않네.. ㅎ

[EP]SUN Tech Days 2008 Seoul 1일차 후기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/


썬마이크로시스템즈에서 지난 10월 15~16일에 Sun Tech Days 2008 컨퍼런스를 서울에서 개최해서 갔다왔다. 이런 유료교육은 회사에서 결재처리하기가 겁나 복잡해서 갈까말까를 엄청 고민했는데 무료쿠폰이 썬에서 날라와서 냉큼 신청하고 무료로 갔다가 왔다. 발표자료 및 세미나 동영상은 썬테크데이 사이트에서 받을수 있다.

위의 Agenda처럼 트랙별로 계속 진행이 되고 원하는 트랙쪽으로 왔다갔다 하면서 들을수 있다. 내가 관심있는 세션들은 대부분 "자바와 클라우드 컴퓨팅"에 집중되어 있었다.

화려한 모래쇼(?)를 시작으로 기조연설이 시작되었다. 기조연설을 한 소프트웨어부문 수석 부사장 Rich Green은 썬의 정책변화에 대해서 얘기했다. 과거의 썬은 너무 느렸던 것을 인정하고 과거와는 다른 빠른 혁신을 추구하기 시작되었고 시장에서 할 수 있냐보다는 해야되는 것이 요구 되었다. 그래서 오픈소스를 적극적으로 지원하고 RIA기술인 JavaFX를 선보였다. JavaFX는 현재 프리뷰상태이고 12월에 풀버전이 공개되고 이때 J2SE6 Update 10도 같이 공개될 예정이다.

리눅스의 미래 : 오픈솔라리스 - Jim Hughes

이번 컨퍼런스에서 한 트랙을 담당한 것처럼 썬은 오픈솔라리스를 적극적으로 들고 나왔다. 썬의 Unix였던 솔라리스를 아무나 사용할 수 있도록 오픈소스화 해서 오픈솔라리스라는 이름으로 공개했다. 썬측의 말로는 솔라리스와 기능적차이는 거의 없다고 한다. 시연으로 볼 때는 우분투정도의 편의성까지 느껴질 정도로 괜찮아보였다. 몇몇특징을 나열하자면

• ZFS 파일시스템을 사용함으로써 파일복구가 가능하며 OS롤백 또한 지원한다.
• 오픈소스로 버츄얼박스도 있다.(이녀석은 원래 있었던 듯...)
• 6개월마다 공식적인 Update를 할 것이며 지속적인 지원

썬측에서 많은 어플들을 제공하고 있기는 하지만 리눅스가 아닌 유닉스이기 때문에 데스크탑용도로 쓸때는 호환어플에 대해서 고민을 좀 해봐야 할듯 싶다. ㅎ


Zembly와 SocialSite를 이용한 클라우드 컴퓨팅 - Sang Shin

상신님은 영어지만 강좌가 좋다고 해서 몇번 가봤던 Javapassion을 운영하시는 분인데 이번에 썬에서 오픈한 Zembly라는 사이트에 대한 트랙이었다. 이 Zembly라는 사이트의 방식이 상당히 흥미로운 방식인데 Wikipedia가 집단지성을 이용한 백과사전이라면 Zembly는 쉽게말하면 집단지성을 이용한 웹어플리케이션을 만드는 것이다.

가장 로우레벨이라고 할 수 있는 서비스를 만들고 그걸 사용해서 위젯을 만들고 위젯을 모아서 애플리케이션을 만들 수 있는데 이 모든것이 직접 만들수도 있고 다른 사람이 만든걸 불러올 수도 있다. 다른사람이 만든걸 불러오면 코드가 들어오고 그 코드에 더 살을 붙히고 하는 방식이다. 매쉬업과는 또 약간 접근방향이 다르다고 할 수 있는데 발상자체까 꽤나 재미있다. 모든 개발은 Zembly상에서 즉 웹브라우저 위에서 바로 개발을 하고 개발은 자바스크립트로 한다.


Ajax와 프레임워크 - Michael Li

사람들이 너무 많아서 점심먹는데 오래걸려서 약간 늦게 들어갔는데 앞에선 무슨 얘기를 했는지 몰라도 이 세션에서는 주로 jQuery에 대해서 설명을 했다. jQuery가 얼마나 편한지 어떻게 사용하는지 어떤걸 제공하는지 등등...  그리고 jMaki에 대한 약간의 소개... 개인적으로는 자바스크립트 프레임워크를 잘 모르던 사람들을 타게팅인듯 싶다. 개인적으로 많으 프레임워크를 비교해주고 방향이나 머 그런거를 얘기해 주기를 바랬었는데... ㅎ 주로 사용법에 대해서 얘기했는데 차후에는 jQuery도 써보고 싶지만 지금은 prototype.js를 사용하고 있고 메서드 사용법이야 그렇게 서서 듣는다고 감을 잡을 것도 아니기 때문에 크게 흥미있게 보지는 않았다.


자바 플랫폼의 신기능 : 강진영

자바가 가는 방향에 대해서 알려고 들었는데 내 자바수준은 솔직히 Java2에 거의 머물러 있는 상태이고 5와 6에 대한 특별한 기능을 사용하고 있는 수준이 아니었기 때문에 내가 이해하기에는 좀 어려웠다. 솔직히 난 이게 Java6 Update10을 얘기하는 건지 Java 1.7을 얘기하는 건지도 잘 모르겠다.(어쨌든 JSR 308에 대해서 얘기하는 건 확실한것 같다.) 그냥 내가 들은 수준 정도로만 정리한다.

어쨌든 Annotation에 대해서 상당히 강조했다. 1.5에서 처음 등장한 Annotation은 Class등등에만 제한되어 있었기 때문에 좀더 다양하게 적용할 수 있도록 타입, 제너릭에서 사용할 수 있도록 하고 타입오류도 미리 체크할 수 있단다. 기존의 Jar Hell이라고도 부르면 JSR 277에서 Jar의 문제점을 해결하기 위해 자바모듈시스템인 Jam이라는 파일을 Java SE 7에서 새로 도입하고 multi-catch를 지원하며 AWT의 성능을 향상시켜 투명 및 둥근모서리도 지원하도록 한다.

File System API를 강화하여 실제 파일시스템은 아닌 java.io.File의 문제점을 해결하여 더 쉽게 사용할 수 있도록 하고 멀티코어를 지원하여 병렬처리가 가능하게 한다. 그리고 FolkJoin Framework와 divide-and-conquer 얘기가 있었는데 잘 모르겠다. ㅡ..ㅡ


자바 성능 향상 - 전은수

자바 성능향상을 위해서 자바 컴파일러의 Client VM, Server VM모드에 대해서 설명하고 GC의 minor GC, Full GC등에 동작방식과 Jconsole등을 이용해서 다양하게 GC가 돌아가는 방식에 대한 데모와 조심해야 할 점을 얘기했는데 50분이란 짧은 시간때문인지 내가 핵심을 캐취 못한건지는 몰라도 저번에 들은 자바튜닝 세미나보다는 좀 못한 느낌이었다.

(J)Ruby on Rails - Sang Shin

개인적인 루비온레일즈의 관심으로 들어갔는데 시작할 때 말씀하시긴 했지만 세션의 타켓팅이 루비온레일즈를 아예 모르는 사람들을 타겟으로 했기 때문에 아주 기초적인 얘기만 했기 때문에 책으로 예제정도만 만져본 정도로도 큰 흥미를 느낄 수 없을 정도였다. 요즘은 책만 사놓고 루비온레일즈를 만져보지 못하고 있기 때문에 이렇게 한번 정리해서 듣는것도 나쁘진 않았다. 안타깝게도 jRuby에 대한 언급은 전혀 없었다. ㅠ..ㅠ

[HTML]제발 a href="#" 좀 쓰지 말자..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

웹이 점점 화려해 지고 인터넷속도가 빨라지면서 웹페이지들은 점점 빨라지고 있고 디자인은 갈수록 중요해지고 있기 때문에 웹사이트에는(특히 국내에서) 정말 많은 이미지가 들어가고 있다. 근데 HTML 코드를 보다보면 정말 흔히 볼 수 있는 이미지버튼의 형태가

<a href="#"><img src="경로" alt="" /></a>

이런 형태이다. 나도 회사처음 들어왔을때 내 바로 윗사람이 이렇게 쓰는것을 권고하기도 했었고 대부분의 사람들이 이런 형태로 이미지 버튼을 만들고 있는데 이건 정말 잘못된 형태의 html이다. 무엇보다 이렇게 써서 얹을 수 있는 잇점이 단 한개도 없다고 생각한다.

저렇게 허위 a태그를 거는 상황은 100% 이미지를 버튼으로, 즉 클릭용으로 사용하기 위함이다. 그래서 img에 onclick 속성을 사용하고 있다.

<a href="#"><img src="경로" alt="" onclick="clickBtn();" /></a>

이렇게 이벤트까지 추가된 형태가 일반적이다.(물론 onclick도 인라인으로 하지 않고 따로 빼는게 표현과 기능의 분리면에서 더 낫기는 하지만 이건 여기서 논할 얘기는 아니니...) IMG태그 만으로도 클릭은 되는데 굳이 이렇게 A태그를 걸어준 단하나의 이유는 다른이미지랑 다르게 버튼처럼 보이게 하기 위해서 이다. 즉 이미지위로 마우스 커서가 이동했을때 클릭이 가능하다는 걸 사용자에게 알려주기 위해서 마우스 커서가 화살표에서 손모양으로 바뀌게 하기 위함이다. 그냥 이미지태그만 있어도 되는걸 커서바꾸자고 a태그로 감싸버린 것이다.

그럼 이렇게 하면 끝이냐... 브라우저마다 특성이 있긴 하지만 기본적으로 이미지에 A태그를 걸면 IE에서는 보기싫은 파란색의 테두리가 생겨버린다. 하이퍼링크가 달렸다는 것을 알려주기 위해서인데 요즘은 이걸 쓰는 사람이 없기 때문에 대부분은 border="0"을 주어서 해결한다.

<a href="#"><img src="경로" alt="" onclick="clickBtn();" border="0" /></a>

그럼 코드가 이렇게 되어버린다. 이미지버튼하나인데 코드가 너무 길어져버렸다. 단지 커서 바꾸자고???

이건 CSS를 사용하면 금방 해결할 수 있다.

Html

<style>
.btn {cursor:pointer;}
</style>
<img src="경로" alt="" class="btn" onclick="clickBtn(); />

커서의 모양을 바꾸는 것은 스타일로 해버리면 된다. (보통은 img에도 border:0을 기본적으로 주기는 하지만 이 상황에서 꼭 필요한건 아니다.) 그리고 심플한 img태그만 사용하면 된다. CSS를 사용한게 훨씬 많아 보인다면 웹사이트에 버튼이 한 100개쯤 있다고 생각해봐라. CSS는 공통적으로 쓸수 있으니 이미지 태그부분만 작성하면 끝이다.

A태그를 이미지를 감싸줄 필요가 없음을 얘기했고 그냥 하던대로만 하기에도 A태그를 사용했을 때의 문제가 있다. 좀 원론적인 웹표준얘기대로 A태그는 하이퍼링크를 위한 것이기 때문에 A태그는 하이퍼링크만 사용해 주는 것이 좋다. 이건 머 웹표준을 동의하지 않는 사람들에게는 그리 통하지 않을 논리고....

A태그의 구조를 보면 Anchor를 사용한 것임을 할 수 있다. Anchor는 다들 알고 있을꺼라고 생각하지만 간단히 설명하자면

<a href="#title">제목으로 이동</a>
........중간내용.............
<h3 id="title">제목</h3>

과 같이 사용하는 것이 Anchor이다. #과 같이 사용하며 #이 있으면 해당경로로 페이지를 이동시키는 것이 아니라 현재페이지에서 해당 id를 가지고 있는 엘리먼트를 찾아서 이동한다. 이걸 이용해서 #은 주고 id는 null을 주어버린 것이다. 그래서 페이지는 다른페이지로 이동하지 않고 현재 페이지에서 Anchor를 찾지만 찾지 못하는 허위 Anchor를 사용한 것이다.

말했듯이 Anchor는 현재 페이지의 해당위치로 이동하는데 이건 스크롤이 있어도 이동된다. 여기서 문제가 발생하는데 href="#"을 해 놓으면 무조건 페이지 최상단으로 이동한다. 이미지 버튼이 윗쪽에 있을 경우에는 상관없지만 스크롤 내려서 아래에 있다고 생각하면 버튼을 누를때마다 페이지 스크롤은 맨위로 올라가고 다시 스크롤 내려서 다른걸 해야하는 사용자의 편의성을 무진장 해친다...

거기에다가 Anchor도 URL에 포함되기 때문에 저 버튼을 누르면 주소맨뒤에 #가 붙게 된다. 크게 문제가 있다고 할 수는 없지만 보기에 좋지 않은건 사실이다. 그리고 자바스크립트 펑션을 호출해서 location.href로 페이지 이동만 할꺼라면 그냥 A태그에 경로를 주자!!

별거 아닌 내용으로 은근 길게 작성해 버렸다. 그냥 작업하는데 버튼마다 계속 A태그 달려있는거 보다가 짜증나서.. ㅎㄷㄷ

덧) 약간은 도전적인 제목이었는데 역시나 내 영역은 아니라 약간의 논란이 있었다. 보통 작성뒤에 잘못된 내용은 빨리 수정하는 편이지만 이번에는 애매모호한 면이 있어서 이 포스트를 읽으시는 분들은 아래 댓글들도 꼭 읽어주시기 바람. 위에 얘기한대로는 링크이동이 아닌 버튼의 경우에 a를 안쓸경우 선택할때 점선이 생기지 않아서 접근성을 해칠우려가 있음. 명확한 결론을 내리기 어려운 관계로 나라디자인의 정찬명님의 포스트를 참고로 건다. 많이 고민해 보아야 할 문제..

[Book] 최범균의 JSP 2.0 프로그래밍 - 기초부터 중급까지..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

최범균의 JSP 2.0 프로그래밍 - 최범균 지음/가메출판사

이 책은 작년에 입사하기 전에 Java교육을 받으면서 JSP교재로 사용했던 책이다. 개인적으로 최범균님의 책이 기술적인 내용도 탄탄하면서 설명을 기초부터 잘 해놓아서 초보자들이 입문용으로 사용하기 괜찮다고 생각하고 있다. 한번 보기는 했지만 JSP에 개념도 없을때 교육의 빠른 진도에 눈돌아가면서 봤던거고 거기에 진도일정을 맞추다보니 건너뛴 내용들도 좀 있고 해서 좀더 고급 Java개발을 하기 전에 정확히는 MVC Model2로 넘어가기 전에 기초를 좀 다지고 가자는 차원에서 다시 봤다.

한번 본 내용이고 상당부분은 익히(?) 알고 있는 내용들인지라 좀 빠르게 봤다. 원래 책은 아는만큼 보인다고 요기 이런것들이 있었나? 하는 것들도 있었고 JSP를 어느정도 하고 난뒤에 보니까 확실히 기초부터 탄탄히 얘기하고 있다는 생각이 든다. 물론 처음 이책을 볼때는 뭔소린지.. 어떻게 하라는 건지 엄청 해매기는 했지만 그리 어렵지 않게 간단한 JSP부터 구동방식과 각 객체들에 대해서 자세히 설명하고 좀더 쉽고 좋게 웹개발을 하기 위한 필요한 모든 JSP 기술에 대해서 제목대로 초중급용에 적당한 난이도의 정보와 예제를 잘 제공하고 있다.

뒷부분에서는 갈수록 지양하고 있는 JSP 스크립틀릿 방식을 벗어난 표현언어나 JSTL을 이용해서 어떻게 사용할 수 있는지와 요즘 대세가 되어버린 MVC 모델2에 대해서 설명함으로써 자연스럽게 중급기술에 다가갈 수 있도록 유도하고 있다. 더불어 틈틈히 유행기술이나 생각없이 남들 다하는대로만 하지 않고 창의적인 생각을 할 수 있도록 노력하고 있다.

나로써는 제대로 개념이 안잡히거나 애매했던 부분에 대해서 한번 좀 깔끔히 정리된 느낌이고 JSTL을 어떻게 사용하는 건지 알게 된것과 서블릿의 필터라는 유용한 기능을 알게 된것만으로도 충분히 읽은 보람이 있다. 물론 안좋은걸 해바야 좋은걸 체감할 수 있는거지만 JSTL을 본 순간 난 왜 여태 JSP 스크립틀릿 노가다를 해왔던 것인지 한탄할 수 밖에 없었다... ㅠ..ㅠ 다음 프로젝트때 적용해 보면 확실히 감잡을 수 있겠다... ㅎㄷㄷㄷㄷㄷ

My Comment..
흠.. 이 책은 나도 추억에 사로잡히게 만드는 책인 듯..
햄과 같이 학원에서 배운.. 현존하는 동기들이라고 하는 형, 친구, 동생들을..
알게 해준 곳이기도 하공.. 무튼 머 그곳에서 배운것인데..

그 때는 개포자였기 때문에.. 걍 그런가보다 하고.. 따라서 치기 바뻤다..
[물론, 따라 치는데도 못 칠정도로 기본의 기자도 모른 시절이긴 했다..]
내가 형처럼 전반적으로 다 보기 위해서 책을 꺼내들었던 건 아니고, 잠시 참고할것이..
있어서 책을 다시금 본적이 있었는데.. 확실히 그 때는.. 눈에 들어오더라..

진짜 아는만큼 보이는 듯.. 아는게 힘.. But.. 모른다고 부끄러워하지 말고..
모르는 것을 찾아보려는.. 알려고 하는.. 노력을 해야 될 듯하다..

[Book] 사랑하지 않으면 떠나라! - 개발자의 자기 계발과 경력 관리를 위한 52가지 실천 가이드..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

사랑하지 않으면 떠나라! - 차드 파울러 지음, 송우일 옮김/인사이트

제목이 꽤 인상적으로 다가왔었던 책.... 국내 출판으로는 부제로 붙었지만 원제인 "My Job Went to India: 52 Ways to Save Your Job"가 더 어울리는것 같다... 사랑하지 않으면 떠나라는 이 책의 극히 일부분일 뿐이지 전체 책 내용을 대변하기에는 좀 약한것 같다. 사실난 제목에 끌렸었는데.....

책 내용이 나쁘지는 않았지만 그리 인상적이지도 않았다. 다 좋은 내용들이기도 하고 자기 계발에 대해 효과적인 많은 애기를 하고 있기는 하지만 전체적으로 느껴지는 느낌이라면 다른 자기계발 책들과 그닥 차별성이 안드는 느낌이고 자기 계발에 신경을 쓰는 사람이라면 대부분은 알고 있었을 만한 내용들.... 그리고 각 챕터가 너무 짧아서 논지가 빈약한 느낌이 없잖아 있다. 많은 내용을 담다보니까 그랬겠지만 제목대로 자기계발에 필요한 많은 것들을 얘기하고 있기는 하지만  구체적인 실천방안을 제시하는 것은 아니기에 ......

그래도 읽다보면 많이 와닿는 얘기들도 꽤 있긴 하다. 나에게는 8번째 "가장 못하는 사람이 되라"가 가장 와닿았다. 제목이 반어법을 사용하긴 했지만 항상 자기보다 잘하는 사람들과 일하라는.... 현실은 쉽지 않지만... 정말 공감하는 부분이라서 내게는 크게 와 닿았다.

쓰다보니 좀 안좋은 애기를 쓰게 된것 같은데 읽은만은 하다. 임팩트가 없어서 그렇지....

[JAVA]InputStream, OutputStream으로 파일 이동하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

대부분의 웹사이트에는 게시판 등에 파일업로드가 들어가기 때문에 파일을 지우거나 삭제하는 기능이 필요했다.(솔직히 전에는 빡빡한 일정과 사이트 분위기 봐서 무시해버린것도 사실인데.. ㅎ) 이런저런 상황에서도 필요할테고 나같은 경우에는 파일업로드하고(cos.jar가 일단 다 업로드를 해버리니까...) 확장자같은 거 등 유효성을 체크해서 통과한 파일만 실제 폴더에 옮겨주고 나머진 지워준다. 임시폴더는 어차피 외부로 공개도 안될테니... ㅎ

Java

// 파일을 해당위치로 복사하고 지운다.
public boolean moveFile(String source, String dest) {
    boolean result = false;
        
    FileInputStream inputStream = null;
    FileOutputStream outputStream = null;
        
    try {
        inputStream = new FileInputStream(source);
        outputStream = new FileOutputStream(dest);
    } catch (FileNotFoundException e) {
        e.printStackTrace();
        result = false;
    }
        
    FileChannel fcin = inputStream.getChannel();
    FileChannel fcout = outputStream.getChannel();
        
    long size = 0;
    try {
        size = fcin.size();
        fcin.transferTo(0, size, fcout);
            
        fcout.close();
        fcin.close();
        outputStream.close();
        inputStream.close();
            
        result = true;
    } catch (IOException e) {
        e.printStackTrace();
        result = false;
    }
        
    File f = new File(source);
    if (f.delete()) {
        result = true;
    }
    return result;
}

소스는 간단하다. 복사할 파일을 FileInputStream으로 만들고 복사할 경로를 FileOutputStream으로 만든뒤 FileChannel을 통해서 복사를 하는 것이다. 그리고 복사한 후에 파일은 삭제해준다. 함수 호출은 아래와 같이 한다.

moveFile(fileObj.getAbsolutePath(), saveDirectory + "/downloads/" + fileName);

파일복사기 때문에 서버의 절대/상대 경로가 아닌 물리적 절대경로가 되어야 한다. fileObj는 File객체이고 saveDirectory는 저장경로의 물리적 경로가 저장되어 있다. fileName은 fileObj객체의 파일명이 저장되어 있다.

saveDirectory는 아래처럼 서버의 경로를 주어서 물리적인 절대경로를 구한다.

saveDirectory = config.getServletContext().getRealPath("/temp");

위의 파일복사 소스는 서비님의 자바 파일복사 코드와 성능 1을 참고해서 작성하였다.(이런류의 소스가 사용하는 방식이 거의 고정되어 있다고는 생각하지만 참고수준을 넘어서서 그냥 그대로 갔다가 약간만 상황에 맞게 고쳤다 ㅡ..ㅡ 보통은 참고한것과 개발하면서 알게된 것을 복합적으로 포스팅하는 편인데 이번경우에는 소스를 많이 바뀌지 않은 관계로 간단히 소스만 보여주고 원본글의 링크로 소스설명은 대체한다.) 자세한 설명을 서비님의 글을 참고 하기 바란다. 아주 자세하게 설명을 해 놓으셨다.

서비님의 포스트에는 파일복사를 하는 3가지 종류가 나와 있는데 이곳에 사용한 것은 3번째 "Channel을 이용한 네이티브OS 기능 사용하기"를 사용한 것이다. 자바 파일복사 코드와 성능 2를 보면 파일복사의 3가지 경우에 대해서 성능테스트까지 한것을 볼수가 있는데 서비님이 추천한대로 성능이 가장 좋아보이는 "Channel을 이용한 네이티브OS 기능 사용하기"를 사용했다.

서비님의 자세한 포스트 덕분에 간단하게 해결.... 감사합니다.

[Book] 웹사이트 최적화 기법 - UI 개발자를 위한 필수 지침서..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

웹 사이트 최적화 기법 - 스티브 사우더스 지음, 박경훈 옮김/ITC(아이티씨)

제목에서 알 수 있듯이 이 책은 웹사이트의 성능튜닝에 대한 내용이고 클라이언트단 혹은 앞단이라고 부르는 UI에 대한 성능튜닝에 대해서 이야기 하고 있다. 자바스크립트나 CSS를 어떻게 짜는지 같은 것을 다루는 것이 아니라 어떤 사이트이든지 성능튜닝을 위해서 적용할 수 있는 경험에서 나온 14가지 규칙을 차례차례 설명하고 있다.

이 책의 저자는 야후에서 일하면서 실제 UI 최적화에 대해서 오랫동안 노력한 경험을 바탕으로 책을 쓰고 있기 때문에 그 내용에 대해 지식도 해박하며 설명이 쉬워서 이해하기가 좋다. 번역도 상당히 깔끔한 편인데다가 책의 분량이 많지 않아서 가볍게 읽을 수 있었다. 기술적인 부분도 기술적인 부분이지만 원리와 이유에 대해서 더 집중해서 설명하고 있는 느낌이다.

시작부분에서는 왜 튜닝을 하는데 UI쪽을 신경써야 하는지에 대해서를 설명하고 각 규칙들에 대해서 어떤 문제때문에 튜닝을 해주어야 하는지 튜닝후에는 어떤 효과가 나는지 자세하게 설명해 주기 때문에 이해하기가 쉽다. 물론 튜닝과 관련한 내용의 양이 방대하기 때문에 모든 부분을 다 설명하고 있는 것은 아니다. 스크립트등 간단한 규칙들은 기술적으로도 설명하지만 서버쪽에서 셋팅해야 하는 부분은 간단히 소개정도를 하고 넘어가는 정도이다. 그럼에도 허술하다는 느낌은 없다. 그런부분은 각 환경마다 너무 다르기 때문에 일일이 다 소개하는 것은 불가능하고 어떤 적용을 해야하는 지만 이해된다면 적용에 대한 기술적인 부분은 각자 찾아봐서 해결하면 될 노릇이다.

각 경우별로 해결법이나 조심해야 하는 부분에 대해서도 다양하게 제시해 주고 있고 각 경우별로 확인을 할 수 있도록 온라인에 페이지 주소를 알려주기 때문에 직접 확인해 볼 수 있어서 이해하는데 큰 도움을 주고 있다.

개인적으로도 UI쪽에 관심이 꽤 있었기 때문에 이런부분에 대해서도 궁금함이 어느정도 있었는데 이책으로 어느정도의 궁금함은 풀린상태이다. 프로젝트를 하다보면 서버단에 비해서 클라이언트단쪽의 퍼포먼스는 좀 등한시 하게 되는 경향이 있는데 요즘은 RIA다 Ajax다 해서 클라이언트도 점점 무거워지고 있는 상황에 이런 성능 최적화에 대해서도 생각해 보아야 한다.

그리 많은 시간을 투자하지 않고도 UI성능최적화에 대해서 한번 생각해 볼 수 있게 하는 책....

물론 적용은 찬찬히.... ㅋ

나중에 참고하기 위해서 내용을 약간 요약하자면......

1. HTTP 요청을 줄여라.
   이미지맵, CSS Sprite, data:를 이용한 인라인 이미지

2. 콘텐츠 전송 네트워크를 이용하라. -> CDN사용

3. 헤더에 만료기한을 추가하라 -> 헤더의 Expires를 통해 캐시가능, HTTP/1.1에서는 Cache-Control, 1.0에서는 max-age
   HTML문서를 제외한 이미지, 스크립트, 스타일시트, 플래시 모두에 적용하라

4. Gzip 컴포넌트
   클라이언트는 Accept-Encoding: gzip, deflate형태로 지원여부를 알려주고 서버는 Content-Encoding: gzip을 통해 알려준다.
   이미지와 PDF는 압축하지 않는다.
   프록시를 사용할 경우는 Vary속성을 이용한다.

5. 스타일시트는 위에 넣어라.
   스타일시트가 아래 있으면 다 받을때까지는 브라우저가 렌더링을 하지 않는다.
   @import를 사용할때는 다른 요소보다 앞서서 선언해야 한다.

6. 스트립트는 아래에 넣어라(body전에)
   스크립트를 다운로드할 때는 렌더링을 하지 않는다.
   스크립트는 동시다운로드가 불가능하다. (스크립트의 순서를 지키기 위해서)

7. CSS Expression을 피하라 (IE5부터 지원)
   스크롤이나 마우스가 움직일때도 계속 실행되는 문제가 있다. (다른 방법을 통해서 이걸 해결되도록 만들어야 함)

8. 자바스크립트와 CSS를 외부 파일에 넣어라.
   HTTP요청때문에 인라인이 성능이 좋지 때문에 외부파일은 개시된다.

9. DNS조회를 줄여라.
   DNS를 조회하는데 시간이 소요되고 완료될때까지 다운로드가 불가능하다.
   OS와 브라우저가 DNS정보를 캐시하기 때문에 TTL을 너무 짧게 설정하지 않는다.

10. 자바스크립트를 최소화하라
     JSMIN을 통해 압축하던지 난독화를 한다. 결과성능에 거의 차이가 없기 때문에 특별한 목적 아니면 압축이 낫다.

11. 리다이렉트를 피하라
     가장 많이 쓰는 리다이렉트는 301, 302가 있는데 리다이렉트는 페이지를 느리게 만든다.
   주소뒤에 슬래시(/)를 이용하지 않을때 발생하는 리다이렉트가 가장 많은 실수다. (호스트에서는 발생하지 않는다.) -> Alias등으로 해결

12. 중복되는 스크립트를 제거하라
     여러 명이 개발할 때 생길수 있는 중복스크립트가 생기지 않도록 하라.

13. ETag를 설정하라.
ETag(Entity Tag)는 웹서버와 브라우저가 캐시된 구성요소의 유효성을 확인하기 위해서 사용하는 메커니즘
브라우저가 캐시의 유효성을 파악할 때는 마지막 수정일을 비교하거나 ETag를 이용한다.
ETag는 서버가 고유한 문자열로 만드는데 서버가 분산서버일때는 ETag에 문제가 생기므로 주의한다.

14. 캐시를 지원하는 Ajax 만들기
     사용자의 요청에 의해 발생하는 능동적 Ajax가 최적화의 대상 -> 동적으로 생성되는 것을 고려해서 캐시될 수 있도록 쿼리스트링 파라미터를 이용한다.(시간이나 고유아이디)
     개인정보 보호를 위해서는 SSL을 이용해라

* 조건부 GET 요청 : 캐시의 구성요소가 유효한지 확인하기 위해서 조건부 GET 요청을 보내고 유효하면 캐시를 사용한다.
   (헤더의 Last-Modified를 비교한다. -> 수정되지 않으면 304 를 보냄)

항상 책보고 나면 나중에 참고할라고 좀 정리를 하고 싶은데 파는 책이기 때문에 신경이 쓰인단 말이지.. ㅡ..ㅡ 머 이정도 선에서는 책정보의 목차와 크게 차이나는게 없으니까 별 문제가 없겠지... 있으면 후덜덜덜