서비의 다락방

아래영상은 넷빈즈 5.5와 UML팩을 통하여 자바 소스로부터 클래스 다이어그램이나
시퀀스 다이어그램과 같은 UML을 작성해 내는 방법을 보여주고 있습니다.

아.. 주말이네...
삼실에서 나 뭐하고 있는거지?
하늘은 꾸리꾸리하고.. 아무것도 하기 귀찮네..

빨랑 끝내고 집으로 고고싱~ 하면 될 것을
이렇게 밍기적 대고 있는건 뭐냐..


상콤한 노래 들으며 빨랑 끝내고 집으로 고고싱~
해야쥐~~~~

세션 타임아웃이 일어날경우 특정 페이지로 리다이렉션을 수행하는 필터클래스 코드

블로고스피어를 다니다보면 부정클릭을 신고 했다거나 계정을 박탈당했다는 글을 심심찮게 볼 수 있습니다.
제 블로그야 일방문자수가 많지않아 그만큼 부정클릭이 일어날만한 환경이 조성되지 않았기에
애드센스의 부정클릭에대해 거의 신경을 안쓰고 있었던게 사실입니다.

그러다 도아님의 애드센스 운영 규칙을 보게되고 구글, 광고주, 광고게시자 모두가
서로의 신뢰를 바탕으로 윈-윈하는 시스템을 운영할 수 있도록 해야한다는 생각에
뜻을 같이하며, 광고 게시자로써 깨끗한 광고 운영 의무를 지키고 제 자신을 지키기위한 방패로
제 블로그와 갤러리에 Adlogger와 MySense 를 가동 하기 시작하였습니다.

로깅툴을 사용한지 3일째인 오늘 오전.
Adlogger로부터 부정클릭으로 의심되는 접속이 발생했다는 매일을 받았습니다.
햐~ 도대체 내 블로그같이 격리된곳에도 와서 부정클릭을 해대는 사람이 있다니..
이건 뭐.. 기뻐해야 하는건지.. 슬퍼해야 하는건지.. 반신반의하며
Adlogger 기록을 보니 특정 ip에서  제 갤러리의 광고를 대여섯번정도 클릭 했더군요..

근데.. 더 놀라운건 그 ip가 제 직장의 ip라는 사실이었습니다.
알고보니 저랑 친한 팀 동료였습니다.
한번 클릭에 광고비가 얼마 안된다는 사실은 알았지만 구글이 부정클릭에 대해 어떤 대처를
하는지는 잘 알지 못하는 제 팀동료가 악의없이 클릭을 한것이었습니다.
저 역시 그 친구를 잘 알고 있기에 그럴수도 있겠다는 생각이 들더군요..

광고 게시자에게 선의를 가지고 한 행동이라도, 광고주-구글-게시자의 시스템 관점에서
보면 결코 바람직 하지 않은 양상입니다.

모르는 ip였다면 차단을 해 두었겠지만 사내 동료로 인한 헤프닝이었기에..
ip차단조치는 취하지 않고,

애드센스팀에 정황을 설명하고 부정클릭이 있었다고 신고 절차를 밟았습니다.
한국 애드센스팀에 메일을 보낸지 한시간 정도 후에 애드센스 신고 후 회신을 받았다는
여느 블로거의 회신과 같은 내용의 메일을 받았습니다.

이번일을 계기로 광고 부정클릭이 꼭 악의로 이루어지지 않을 수 있음을 알게 되었고
구글 광고를 건 제 스스로를 보호하기 위해서도 광고의 클릭 행태에 관심을 가질 필요가
있겠다라는 생각을 했습니다.

메탈이나 정신없이 시끄러운 음악을 싫어하신다면 아래 뮤직비디오를 보시지 말것을 권유 드립니다.
저 역시, 메탈계열의 음악은 거의 듣질 않고 그닥 좋아하지 않는편입니다. ^^a

오늘로 데쓰노트 TV방영 애니메이션이 끝났습니다..
역시나 키라가 생각하는 '정의'가 막을 내리는 것으로 정리가 되더군요..
열광 할 정도는 아니지만 꽤 흥미롭게 지켜본 애니메이션이었습니다.

아래의 노래는 데쓰노트 2기에서 오프닝으로 쓰인 노래인데요..

데쓰노트의 강열한 오프닝 이미지와 잘 맞아떨어져서 제 뇌리에 남으면서
은근히 중독성이 있어서 자꾸 듣게 되네요.. ( 역시.. 반복 학습..)

개인적으로 이 뮤직비디오 보단 데쓰노트 오프닝 영상과 더 잘 어울린다고 생각하지만
애니에서는 온전한 곡으로 들을 수 없기에.. 뮤비를 이렇게 담아 놓습니다.

JAR 관련 클래스는 ZIP 관련 클래스의 하위 클래스이므로 이 팁에서는 ZipOutputStream 및 java.util.zip 패키지에 대해 구체적으로 다룬다.

ZIP 또는 JAR 파일의 생성을 살펴보기 전에 그 목적을 언급하는 것이 중요하다. ZIP 파일은 패키징 메커니즘을 제공하여 여러 파일을 하나의 파일로 묶을 수 있게 한다. 따라서 파일 그룹을 웹에서 다운로드해야 할 경우 이 파일들을 하나의 ZIP 파일로 패키지하여 단일 파일로 쉽게 전송할 수 있다. 이 패키지 파일은 디렉토리 계층구조 같은 추가 정보를 포함할 수 있으므로 압축을 풀 때 애플리케이션 또는 시리즈의 자원에 필요한 경로를 유지할 수 있다.

이 팁에서는 ZIP 파일 사용의 세 가지 측면을 다룬다. 즉, ZIP 파일 생성, ZIP 파일에 파일 추가 및 해당 추가 파일 압축에 대해 다룬다.

우선 ZIP 파일을 생성할 때는 ZIP 스트림이 생성된다. ZipOutputStream은 송신 바이트 압축을 위한 스트림을 제공한다. 다른 OutputStream을 받는 ZipOutputStream의 단일 구성자가 있다.

public ZipOutputStream(OutputStream out)

구성자 인수가 FileOutputStream 유형이면 ZipOutputStream이 작성한 압축 바이트는 파일에 저장된다. 하지만 ZipOutputStream을 파일과 관련해서만 사용할 수 있는 것은 아니다. 소켓 연결 또는 기타 일부 비파일 중심 스트림으로부터 나오는 OutputStream을 사용할 수도 있다. 따라서 파일 중심 ZipOutputStream의 경우 일반적인 사용법은 다음과 같다.

String path = "afile.zip";
FileOutputStream fos = new FileOutputStream(path);
ZipOutputStream zos = new ZipOutputStream(fos);

생성된 후에는 ZipOutputStream에 바이트를 작성하는 것으로 충분하지 않다. 대신 출력 스트림을 구성요소의 컬렉션으로 다루어야 한다. ZipOutputStream의 각 구성요소는 ZipEntry와 쌍을 이룬다. 이 ZipEntry를 생성하고 ZipOutputStream에 추가한 후에 해당 컨텐츠를 스트림에 실제로 작성해야 한다.

String name = ...;
ZipEntry entry = new ZipEntry(name);
zos.putNextEntry(entry);
zos.write(<< all the bytes for entry >>);

각 엔트리는 전체 스트림에서 마커 역할을 하며 라이브러리 파일에서 엔트리와 관련된 바이트를 찾을 수 있다. ZIP 파일이 생성된 후 엔트리 컨텐츠를 도로 가져와야 할 경우 관련 입력 스트림을 요청하기만 하면 된다.

ZipFile zip = "afile.zip";
ZipEntry entry = zip.getEntry("anEntry.name");
InputStream is = zip.getInputStream(entry);

ZIP 파일을 생성하고 해당 파일에 엔트리를 추가하는 방법을 살펴본 이 시점에서 java.util.zip 라이브러리가 ZipOutputStream의 추가 엔트리에 대해 일정 수준의 제어를 제공한다는 것을 지적할 필요가 있다. 먼저, 엔트리를 ZipOutputStream에 추가하는 순서는 엔트리가 .zip 파일에 실제로 위치하는 순서이다. ZipFile의 entries() 메소드에 의해 반환된 엔트리의 열거를 조작하여 영문자 또는 크기 순서대로 목록을 생성할 수도 있지만 엔트리는 출력 스트림에 작성된 순서대로 저장되어 있다.

ZIP/JAR 파일에 추가된 파일은 개별적으로 압축된다. 라이브러리 패키지를 전체적으로 압축하는 Microsoft CAB 파일과 달리, ZIP/JAR 파일 내의 파일들은 각각 별도로 압축되거나 압축되지 않는다. ZipOutputStream에 ZipEntry를 추가하기 전에 해당 연관 바이트의 압축 여부를 결정해야 한다. ZipEntry의 setMethod 메소드를 사용하면 두 가지 사용 가능 압축 형식 중에서 어떤 형식을 사용할지 지정할 수 있다. 압축되지 않은 파일을 원하면 ZipEntry의 STORED 상수를 사용하고, 압축된 버전을 원하면 DEFLATED 설정을 사용한다. 압축 효율성은 제어할 수 없다. 이는 연관 엔트리의 데이터 유형에 좌우된다. 일반 텍스트는 원래 크기의 80% 정도까지 쉽게 압축할 수 있지만 MP3 또는 JPEG 데이터의 압축률은 이보다 현저히 떨어진다.

모든 파일을 압축하는 게 당연하다고 생각할 수도 있지만 파일을 압축하고 푸는 데에는 시간이 소요된다. 생성 시점에서 압축 작업에 너무 많은 시간과 자원이 소요될 경우 전체 파일 데이터를 STORED 형식으로 저장하여 원시 바이트를 저장하는 것이 나은 경우가 있다. 압축 해제의 경우에도 마찬가지이다. 물론, 압축되지 않은 파일은 용량이 더 크므로 파일 전송 시 더 많은 대역폭을 사용하고 더 많은 디스크 공간을 차지하므로 이에 따른 비용을 지불해야 한다. ZipFile 전체가 아니라 각 엔트리에 대한 설정을 변경해야 한다는 것을 유념한다. 하지만 각 엔트리에 대해 각기 다른 설정을 사용하는 것보다 전체 ZipFile을 압축 또는 비압축하는 것이 보다 일반적이다.

압축 방법으로 STORED 상수를 사용할 경우 알아 두어야 할 한 가지 사항이 있다. 엔트리가 압축될 때 자동으로 설정되는 ZipEntry의 특정 속성을 명시적으로 설정해야 한다. 해당 속성은 엔트리의 입력 스트림에 대한 체크섬, 압축 크기 및 크기이다. 입력 파일인 경우 크기 및 압축 크기는 바로 파일 크기가 될 수 있다. 체크섬을 계산하려면 ava.util.zip 패키지의 CRC32 클래스를 사용한다. checksum 값을 무시하기 위해 단순히 0 또는 -1을 전달할 수는 없다. ZIP 파일을 작성하고 나중에 해당 파일을 읽을 때 입력사항을 검증하기 위해 CRC 값이 사용된다.

ZipEntry entry = new ZipEntry(name);
entry.setMethod(ZipEntry.STORED);
entry.setCompressedSize(file.length());
entry.setSize(file.length());
CRC32 crc = new CRC32();
crc.update(<< all the bytes for entry >>);
entry.setCrc(crc.getValue());
zos.putNextEntry(entry);

예 를 들어, 다음 프로그램은 STORED 압축 메소드를 사용하여 일련의 파일을 결합한다. 프로그램의 첫 번째 인수는 생성할 ZIP 파일이 된다. 나머지 인수는 추가할 파일을 나타낸다. 생성할 ZIP 파일이 이미 존재하면 프로그램은 파일을 수정하지 않고 종료된다. 존재하지 않는 파일을 ZIP 파일에 추가하는 경우 프로그램은 존재하지 않는 파일을 건너뛰고 나머지 명령줄 인수를 생성된 ZIP에 추가한다.

JAR 파일의 봉합 및 버전 지정을 비롯한 자세한 내용을 보려면 The Java Tutorial의 JAR Files 단원에서 Packing Programs를 참조한다.

원문 출처 : http://www.sdnkorea.com/blog/398

웹로직 설정 온라인 참고 문서

BEA WebLogic Server and WebLogic Express 8.1 Documentation
http://edocs.bea.com/wls/docs81/

BEA WebLogic Server and WebLogic Express 6.1 Documentation
http://edocs.bea.com/wls/docs61/

BEA 웹로직에서 JMS 서비스 구현에관한 Dev2Dev 링크:
http://www.dev2dev.co.kr/devcenters/category.jsp?category=jms

BMT Message-Driven Bean 과 Spring을 이용한 고성능 메세지 프로세싱
http://www.dev2dev.co.kr/pub/a/2006/01/custom-mdb-processing.jsp

WebLogic JMS 프로그래밍 하기
http://edocs.bea.com/wls/docs81/jms/index.html (weblogic 8.1 )
http://edocs.bea.com/wls/docs61/jms/index.html (weblogic 6.1 )

BEA 웹로직8.1 JMS설정하기 :: JMS and WebLogic Server
http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_config.html (weblogic 8.1 )
http://edocs.bea.com/wls/docs61/adminguide/jms.html (weblogic 6.1 )

Gmail을 편지함을 열어 보다 문득
'나는 하루동안 얼마나 많은 시간을 Google에 할애 하고 있는거지?'
란 생각이 들었다.





내가 현재 이용하고 있는 구글의 서비스는

우선 매일 같이 이용하는 구글검색을 필두로
메일을 열람하는 구글메일..
구글 개인화 페이지인 i구글
광고인 구글 애드센스가 있고..
음.. 사이트 방문 통계를 보는 구글 애널리틱스 가 있고.. 에.. 또
구글 검색엔진에서 내 사이트를 얼마나 잘 크롤링 하는지 알아 보는 구글 웹마스터,
웹오피스웨어 서비스인 구글 워드프로세서 & 스프레드쉬트 까지..

클라이언트 프로그램인 피카사를 제외하고도 7가지나 된다..
헉.. 많이도 이용하고 있다.
( 나보다 더 많은 구글 서비스를 이용하는 사람들도 있겠지..? )

가만히 보고 있으면 구글을 통해 제공받고 있는 서비스의 특징은
한 두개의 서비스를 제외하면, 그 자체가 필요하다기 보단 다른 뭔가를 하는데 도움이 되는
일종의 메타 서비스 성향이 짙은것 같다..

이런 서비스를 이용하고/확인 하기위해 하루에 상당한 시간을 할애하고 있음을
나 스스로도 의식 하고 있지만, 좀처럼 그 시간을 줄일 수 없는건,
그 서비스들이 제공하고 있는 가치 때문인걸까?
아니면 일종의 새로운 '타마고치'의 역할을 구글이 수행 해 주어서 일까?

구글 중독. 한동안은 헤어나기 힘든 문제일지도 모르겠다.

화니님의 마이센스 ( MySense ) ::
 http://adsensekr.com/
 http://wanny.tistory.com/396
 http://www.soonjin.net/128

애드로거( AdLogger ) ::
 http://www.engagestory.com/tt/217
 http://offree.net/541
 http://blog.iteach4u.net/dikafryo/entry/태터툴즈에-구글-ADSense-광고-플러그인부정클릭방지-AdLogger-v14-버전

새벽 두시가 넘은 시간에 보기 시작해서 화면에서 눈을 뗄 수가 없을 정도로 몰입 해서 본 영화.
개봉 당시에 극장에서 꼭 보고싶었는데, 이런저런 이유로 보지 못한게 한스러울 정도 였다.

개봉당시에 서양의 눈으로 바라본 왜곡된 일본 이야기 라고 꽤 이슈가 되었던 영화이기도 하다.

영화가 가지는 문화적 파급 효과를 모르는 바 아니나, 난 그런 문화적 이해에 대한 심도가
0.1mm도 되지 않는 바. 무게 있는 이야기들을 다 덜어내고 나면 이 영화는
'보고 즐길 수 있으며, 보고난 후 몇 장면이 강하게 기억에 남는' 그런 멋진 영화다.
(극장에서 못본게 정말 후회 된다.)

이 영화가 멋지게 느껴지 몇가지 이유는
첫째, 볼거리! 멋진 색감과 그에 부응하는 화면 구성.
시카고를 통해 멋진 화면을 선보였던 롭 마샬 감독은 게이샤의 추억 이라는 이 영화를 통해
또 한번 나를 감동 시켰다.
영화를 보는내내 이런 화면을 만들어 내기위해 고심하고 이렇게 멋진 화면을 내 눈 앞에 펼쳐 준
스탭과 배우 분들에게 박수를 보냈다.

둘째, 이야기! 원작이 꽤나 인지도 있는 소설인 만큼(아쉽게도 원작을 읽어보지 못했다.)
드라마로서의 이야기가 부족하다고 느끼지 못했다.
영화를 보는 내내 그들의 이야기에 빠져들었으니 탄탄하다고 해 줘도 괜찮을 듯.

셋째, 배우! 이 영화에서 일본의 숨은 보석 같은 아역 배우를 찾아낸 것 만으로도 럭키!
그 특유의 눈매와 생김새에 시선 고정.
(뭐.. 내가 이쁜 애기들 보면 언제나 기분이 좋아지는 타입이긴 하지..)
앞으로 그녀의 출연작은 관심있게 지켜 봐야 겠다. 좋은 연기자로 자라서 날 실망 시키지 않았으면
좋겠다.

자... 그럼 영화의 몇 장면을 감상 해 보자..

정말 간만에 황홀한 영상속에서 눈이 즐겁고 감정이 풍부해 지는 영화를 봐서 기분이 좋다..

본글은 제가 2006년 9월 모 포탈 블로그에 게시했던 글입니다.

올 여름 극장가를 달굴 블록버스터.. 트랜스포머..
극장가서 보기전에 트랜스포머의 세계관을 이해하는 차원에서 86년도에
개봉한 극장판 애니메이션을 보고 싶었는데.. 이렇게 구할 수 있을 줄이야..
86년이면 초등학생 때였는데.. 국내에서는 '유니크론과 변신로봇'이었나..
뭐 그런 제목으로 방영을 해 준것 같은데.. 거의 기억이 나질 않는다..
이렇게라도 다시 볼 수 있어서 다행이다.

트랜스포머 The Movie 1 (1986年 作)


트랜스포머 The Movie 2 (1986年 作)

헉.. 있다..

짧은 감상평 : 트랜스포머 극장용 장편 만화는.. 참... 산만 하구나.. 끙..

86년도 극장판 트랜스포머에 대한 자세한 이야기는 http://infinity99.egloos.com/3239282 참고.

지난 19일 Gallery2 의 마이너 버전업이 있었습니다.
2.2.1 버전업 때와 마찬가지로 새로운 기능추가는없으며,
버그픽스만 이루어 졌습니다.
사이트에서는 30개 이상의 버그픽스가 이루어 졌다고 밝히고 있습니다.







갤러리 개발 사이트에서는 몇가지 주목 할 만한 기능 개선을

Gallery 2.2.2 is now available for download. As a minor stability release it adds no new features and includes bug fixes only.

Over 30 bugs have been fixed in this stability release. Some highlights are:

• Fixed WebDAV for OS X / GNOME clients - Items are now recognized as images
• Fixed fallback theme / theme reset functionality
• Fixed PHP error in fetchWebPage() on too many redirects
• Fixed rewrite rule for embedded core.DownloadItem
• Fixed Upgrade Code for IBM DB2 / MS SQL Server

Read on for more details and upgrade instructions...

정도로 밝히고 있습니다.
그러면서 친절하게도 차기 메이저 버전업인 Gallery 2.3 릴리즈를 기다리지 못하는 이용자라면
갤러리 2.2에서 사용 가능한 실험적인 플러그인들을 통해 2.3의 기능을 미리 볼 수 있다고 하는군요..

자.. 그럼 전 서비의 갤러리 업그래이드 하러 이만.. 춍춍춍...

해외 호스팅이기 때문에 페이지 로딩 속도에서 어느정도 패널티는 생각하고 있었지만,
최근 서비의 Photo Gallery 가 특정시간대가 되면 극심히 느려져 페이지를 열어보기 힘들 정도가 되는 현상을 종종 목격하면서,
속도개선을 위해 뭔가 하지 않으면 안되겠단 생각을 하게 되었다.
( 그래봐야 옵션을 만지는 정도지만.. )

그래봐야 옵션....

그동안 최적화를 해 놨다고 생각했던 옵션들을 며칠에 걸쳐 이리저리 조작해 보다 간신히 원인을 찾아
시간을 잡아먹던 기능을 off하는 선에서 마무리 지었다.
원인은 앨범과 사진 리스트에 별점을 주는 기능이었다. - 다른 테마를 사용하면 그닥 티가나지않는데
PGtheme 와 앨범 별점기능을 사용하면 PGtheme 에서 백그라운드로 돌아가는 스크립트와 별점기능이
서버에 부담을 많이 주는듯 하다.

주말사이 여러 시간대에 걸쳐 갤러리 페이지를 열어봤는데.. (속도에 대한 갈증은 여전 하지만..)
지금처럼 극악의 속도를 보이지 않는듯해서 다행이라 생각중.

방금전 서비의 다락방과 서비의 Photo Gallery에 웹페이지 분석툴인 다음웹인사이드 와 구글 애널리틱스를 설치 하였습니다.

다음과 구글에서 계정을 등록하고 분석 스크립트를 내려받은 후 제 블로그와 갤러리의 하단에 삽입 후 페이지를 열어 보았습니다.

그랬더니, 제 갤러리는 아래와같은 Fatal error를 내면서 페이지가 안열리더군요..
에러 메세지를 보니 syntax error: unrecognized tag: _dwiCatch(); 라고 나타나고 있더군요..
다음 웹인사이드 스크립트 코드에 보면 _dwiCatch() 함수를 호출하는 부분이 있는데, 이때까진
'다음 웹인사이드는 Gallery2랑은 안맞나 보군...' 이라고 대수롭지않게 여기고 다음 웹인사이드 스크립트를 삭제 한 후
다시 갤러리를 열어보니 잘 열립니다.

그런 후 블로그 페이지를 열어봤습니다. ( 참고로 전 오페라 9을 씁니다. )
아래처럼 페이지가 다 열여도 네트워크 전송바가 끝나지 않는 현상이 보이더군요.. 저 상태로 멈춰있습니다.
테터툴즈 스킨과 플러그인페이지에 들어 갔을때도 비슷한 현상이 보였는데..
덕분에 이런 현상이 다음 웹인사이드 때문인지 알게되었습니다.

다음 웹인사이드만 있었더라면 Gallery2와 오페라의 문제라고 치부하고 넘어 갔겠지만.. 같은 분석툴인
구글 애널리틱스는 페이지를 열람하는데 아무런 방해도 하지 않고 브라우저에 이상한 증상도 없이 잘 작동합니다.

덕분에 제 사이트에서 다음웹 인사이드 코드를 삭제 할 수 밖에 없었습니다.
저 _dwiCatch() 함수내에서 무슨일을 하고 있는지는 모르겠지만,
다음 웹인사이드 팀에서 제 글을 보신다면 수정이 이루어질 수 있도록 해 주셨으면 좋겠습니다.

행여나하는 마음에..