雑記帳 2005年 12月第4週

2005/12/18 Sun.

今日は休日出社ですよっと。リリース作業だから休日にやらなきゃいかんのはわかるが、せめて代休を取らせなさい。
今まで試験環境に突っ込んできたモノを一斉に本番環境に吐き出します。障害が出なければ激しく楽なんだがなぁ。
10時に出社してファイルをリリース、試験を即開始。んで、昼飯を挟んでも13時くらいには全検査を終了できた。
ざっと見た感じ、障害っぽいのは一件もないだろうし、試験環境でも障害報告なかったから無事に終了ってとこか。

【アメリカ】施錠忘れの車にダイヤの指輪…「車を盗む代わりにあなたにプレゼントを」

1 :諸君、私はニュースが好きだφ ★ :2005/12/16 22:45:19 ID:???0
ドアの施錠を忘れたまま車を駐車場に止めて、盗難に遭った――という
話は珍しくない。だが、米マサチューセッツ西部に住む男性(37)の場合
は違った。車に戻ってみると、座席の上に見知らぬ人からの贈り物が
置かれていたのだ。それは、3つのダイヤモンドをはめ込んだ指輪だった。

男性が車を止めていたのは、ボストンから西へ約50キロ離れた街
ウエストボローの鉄道駅。指輪には手紙が添えられていた。「メリー
クリスマス。ドアのロックを忘れてくれてありがとう。車を盗む代わりに、
あなたにプレゼントを贈ります。この指輪が、あなたの愛する人の手に
届きますように。私の愛する人は、もう去ってしまったから」

男性は4日間考えた末、この不思議な出来事を警察に通報した。
地元警察は「施錠されていない車を探し回って、偶然この車を見つけた
のだろう」との見方を示している。
宝石業者に鑑定を依頼した結果、指輪の価値は1万5000ドル
(約174万円)相当と判明した。警察によると、男性は指輪を手元に置く
ことにしたという。

ソース(CNN) http://www.cnn.co.jp/usa/CNN200512160018.html
5 名前:名無しさん@6周年 :2005/12/16 22:46:29 ID:5Bd6kr+Q0
いつかきっと出来るに違いない俺の彼女にプレゼントしたいから下さい
15 名前:名無しさん@6周年 :2005/12/16 22:49:08 ID:WHqin6ft0
指輪まで買っておいてふられた人が、せめて誰か幸せになってくれ。と置いて行ったのかな?
16 名前:名無しさん@6周年 :2005/12/16 22:50:18 ID:i6MJeYOX0
全米が泣いた
69 名前:名無しさん@6周年 :2005/12/17 03:00:35 ID:/oG+BqyG0
     ;:;:;.
     ;:;:;              ,、-ー-、              ど
     ;:;:            ,r'"´ ̄`ヾ、             明  う
     ;:;:.            リ ,,, ニ ,,,_ ヾト、            る  だ
     :;:;:;.             ,ハ ^7 ,^   !.:.\          く
     ;:;:;:           /.:.:.V,r''''''ゞyイ.:.:.:.:..ヽ       な
     ;:;:.         ノ.:!:.:.:.:`ゞ-<7.:〉.:.:.:i.:.:}   ろ  っ
     从 __  _,,,/.:.:/:.:.:.:.:.:| }-{/i.:/.:.:.:.:|.:/     う  た
      从从百円}と_」.:/!.:.:.:.:.:.:.!  ̄ リ.:.:.:.:.:り     ?
         ̄ ̄    ̄  |.:.:.:.:.:./_ :__ヽ.:.:.:.:\
                \/.:.::..:.:.:.:.:.:..:\:.::./
                /.:.:.:.:.:.:.「^Y.:.:.:.:.:.:|´
                 {.:.:.:.:.:.:.:.| ,!.:.:.:.:.:.:|
                  \.:.:.:.:.:.V.:.:.:.:.:.:.:|
                  \.:.:.::|.:.:.:.:.:.:.:!
                    > 'ゝ─‐イ、
                    `ー' ``''ー‐'
174 名前:名無しさん@6周年 :2005/12/18 00:59:55 ID:8r1NvoQPO
アメリカってこういう微妙な美談多いよな
庭にあったカエルの置物がなくなったと思ったら
旅に出ます心配しないでね、なんて書き置きがあって
月1ペースで世界の観光地から記念写真送ってきて
1年後にはリムジンで帰宅するとか

車を盗まれるか、ダイヤの指輪が置かれるか。日本じゃこういう類の美談って絶対ありえないよなぁ。羨ましい話だ。
最後のAAは、おそらく成金になった米マサチューセッツ西部に住む男性(37)を象徴しているんだろう。多分だけど。
それにしても「CNN.co.jp」って面白いよな。「こぼれ話」の項目とかはお気に入りに突っ込んであるくらいだし。
こんな話を頻繁に見かけるようになると、金ってのはある日突然どっかから降ってくるものだと勘違いしそうになるな。
みずほ証券」によるジェイコム株大量誤発注問題でボロ儲けした千葉県の無職男性(27)なんかはいい例だよね。
ちなみにこの人、誤発注があった8日に自己資金34億3661万6000円を投入してジェイコム株7100株を取得しています。
その後の強制決済で約20億3500万円の利益を獲得。うーん、個人レベルでそんなに金を持ったら、人格破綻しそうだな。

2005/12/19 Mon.

さて、久々にgzip圧縮転送を頑張りますよ。10月の最終週にもやってたけど、結局成果を上げてなかったんだよな。
以前はどんなことやってたっけかと思って10月第5週の雑記を見直してたけど、web.xmlの例が既に間違ってるじゃん。
dev2dev Online」の「GZipFilter」の例のはずなのに、何故か「Compress Filter」の「gzipflt」の例になってる。直しておくか。
とりあえずこの二つの動作を再確認してみる。やはり出力HTMLが欠けたり、マルチバイト文字のみの圧縮になってるな。
一応「ONJava.com」の「jspbook.jar」も試してみて、動作は相変わらずだということを確認。何かいいフィルタは無いものか。
公開されてるソースを上手いこと流用して自作でもしてみるか?結構時間かかりそうなのは覚悟の上になるけどね。
GZIPFilter」とかで検索すると結構色々なのが出てくるんだけど、決定的な情報が載っていないのが残念でならない。
ってか、はっきり言ってこの作業は行き詰ったも同然なんだよな。「jspbook.zip」でも真面目に覚えるつもりでやってみるか。

2005/12/20 Tue.

GZIPFilter.java」と「GZIPResponseStream.java」と「GZIPResponseWrapper.java」なんてモノを書いてみたりする。
リクエストやレスポンスが発生した場合、Servletがかけるフィルタ処理を記述したものです。結構勉強になったかも。
当然このままでは使えないので、指定したPackage通りのディレクトリ階層を作って、「jar cvf gzip.jar com」とかを実行。
正常に終われば、「gzip.jar」なんてモノが出来上がります。「WEB-INF/lib」などのクラスローダーに置くモノですね。
さらにweb.xmlの変更が入る。これを設定しないと肝心のフィルタ処理がどこにも入らない。こんな感じで書きます。

<filter>
    <filter-name>GZIPFilter</filter-name>
    <filter-class>com.junmix.utilities.gzip.GZIPFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>GZIPFilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>GZIPFilter</filter-name>
    <url-pattern>*.html</url-pattern>
</filter-mapping>

ちなみに、この記述はweb.xml内の<web-app></web-app>内にならどこに書いてもいいというワケではないのがメンドい。
記述順を間違えると起動時にエラーが出て「こういう順番で書け」って怒られる。これで結構悩まされたこともある。
さて、実際に作ったファイルやら設定やらをローカルの「Tomcat」に適用してみる。「Tomcat」のバージョンは4.1.31です。
バージョンというのは結構重要で、例えば「Tomcat」のバージョンが3.xxとかだとServlet APIが2.2とかになってしまう。
web.xmlを変更して、先ほど作った「gzip.jar」をクラスローダーに突っ込む。再起動、そしてページにアクセスしてログを確認。

おお、すんげー圧縮率。ちなみにこれはマルチバイト文字を一切含まないJSPを圧縮転送した場合。では、含む場合は?

これは……もしかして正常に動いてるんじゃ!?あれこれ頭を悩ませ続けて一ヶ月半、ようやく成果を上げられたのか!?
さっそくこの「gzip.jar」をWebLogicの方の開発環境に適用してみる。web.xmlも変更して、まずはとにかく再起動。
サーバー起動時のログには何もエラーは吐かれない。これはいけるんじゃないか?起動終了後、早速ログイン画面へ。

                   _ _     .'  , .. ∧_∧
          ∧  _ - ― = ̄  ̄`:, .∴ '     (    )
         , -'' ̄    __――=', ・,‘ r⌒>  _/ /
        /   -―  ̄ ̄   ̄"'" .   ’ | y'⌒  ⌒i
       /   ノ                 |  /  ノ |
      /  , イ )                 , ー'  /´ヾ_ノ
      /   _, \               / ,  ノ
      |  / \  `、            / / /
      j  /  ヽ  |           / / ,'
    / ノ   {  |          /  /|  |
   / /     | (_         !、_/ /   〉
  `、_〉      ー‐‐`            |_/

文字化けしまくってHTMLがぶっ壊れたせいか、ログイン画面すら開きません!ごめんなさい!これでも頑張ってます!
ローカルの「Tomcat」だと全く問題無く動いてくれるんだけど、何でWebLogicに乗せるとこうなるかなぁ。原因不明。
出力文字コードが悪い?確かにソースの中でSJISに強制指定してあるけど、これが原因で文字化けとかはありえない。
フィルタをかける前にレスポンスの中身を覗いてみて、吐き出すストリームの文字コードを判別させるとかってなるの?
ちなみに、ソース内で記述してあるSJISの部分をJISAutoDetectにしてもダメでした。こりゃ何らかの手段を講じないとな。
さらにワケわからないのが、JSPやHTMLなどの「text/plain」は圧縮できないのに「image/jpg」「image/gif」などは圧縮可能。
静的なファイルであり、かつバイナリであるものは正常に圧縮できるのか。でも、ローカルだと全部正常に圧縮できるんだが。
ヘッダ情報が足りてないのかなー。WebLogicに限った特定の現象なのか?もうちょい資料が転がってるといいのになー。

2005/12/21 Wed.

懲りずにgzip圧縮転送を頑張ります。環境を確認しなおしたところ、サーバーは「WebLogic Server 7.0」を使用。
もちろんServlet APIは2.3のはず。フィルタリングも正常に使えるはずなんだけどな。結局動かない原因は不明のまま。
ってか、デフォルト状態のweb.xmlに<filter></filter>が記述されているんだから、考えてみれば使えるのは当然だったな。
@IT」にも紹介として「@IT:製品紹介『WebLogic Server 7.0』」があったけど、既存の知識以上のは得られなかったな。
WebLogic Server 7.0」の「フィルタ」の項目も読んでみたけど、フィルタの使用方法とか概念的なことしか書いていない。
つーか、別に使い方自体が間違っているワケじゃないだろう。静的なバイナリファイルだけは正常に圧縮できてるし。
やはりコーディング自体に問題があるのだろうか。それとも、ローカルでの動作環境と決定的な違いがあるのか?
結局今日も解決策が見つからん。そもそもソースにミスがあったらローカルじゃ動かないだろうし、サーバーの設定かな。
本当に困ったな。ブラウザに文字化けした状態でHTMLが表示されるのは、gzip状態のHTMLを直で表示してるからか。
web.xmlの<mime-mapping></mime-mapping>に手を加えようと思ったが、gzipだといっても拡張子は変わってないか。
一応「application/gzip」とかも加えて、さらにjarのソースにresponse.setContentTypeを使ってみたが、結果は変わらず。
無理矢理gzip状態のHTMLを「application/octet-stream」で吐かせてから解凍して確認でもしたかったが、これも無理だ。
まずはブラウザに吐かれる文字化け状態のHTMLの原因がjarなのか設定なのかを特定しないと、先へは進めなさそうだ。

2005/12/22 Thu.

PerlとJavaでそれぞれ「Output.log」というファイルを作成して「This is Test.」という文字列を吐かせてみる。まずはPerlで。

open (FILE, ">Output.log");
flock (FILE, 2);
print FILE "This is Test.\n";
close (FILE);

最初の行はWindowsで使う環境変数の%JAVA_HOME%を定義しているようなものなので、実質は4行しかない。
これくらいなら、Perlを始めたばかりの人でも2時間しないくらいで覚えてしまえるレベル。んで、次はJavaで書く。

import java.io.*;
public class Output {
    public static void main(String[] args) {
        try {
            //    この方法だとファイルに追記するのは不可能
            FileOutputStream fos = new FileOutputStream(new File("Output.log"));
            OutputStreamWriter osw = new OutputStreamWriter(fos);
            BufferedWriter bw = new BufferedWriter(osw);
            bw.write("This is Test.\n");
            bw.flush();
            bw.close();
            osw.close();
            fos.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

見ただけでも急にメンドくさくなる。ちなみに上記のJavaの例で作ったファイルは、改行コードが何故かLFになってしまう。
Windows環境のデフォルトは文字コードがShift-JISで、改行コードはCR+LFなのが基本。例外があるかもしれないけど。
try句直後の3行をまとめて1行にした書き方はこうなるけど、これって正しいのかな。これについては後述しますが。

BufferedWriter br =
new BufferedWriter(new OutputStreamWriter(new FileOutputStream(new File("Output.log"))));

同じファイル出力を別の書き方でも書いてみる。どっちの方法が一般的に広く使われているかは全く知りませんが。

import java.io.*;
public class Output {
    public static void main(String[] args) {
        try {
            //    FileWriterの引数をString fileName, boolean appendにすると、ファイルの末尾から追記が可能
            FileWriter fw = new FileWriter(new File("Output.log"));
            BufferedWriter bw = new BufferedWriter(fw);
            PrintWriter pw = new PrintWriter(bw);
            pw.println("This is Test.");
            pw.flush();
            pw.close();
            bw.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

PrintWriterを使うと、こんな感じの記述になる。この例で作成されたファイルの改行コードは、何故かCR+LFになってる。
FileWriterの引数がFile file, boolean appendでも追記できるが、あれはJVMのバージョンが1.4以上からのはず。
こっちもtry句直後の3行をまとめて1行に。当然この書き方でも動くんだけど、JVM的にはどの記述が優しいんだろ。

PrintWriter pw =
new PrintWriter(new BufferedWriter(new FileWriter(new File("Output.log"))));

pw.println()は渡された文字列の最後に改行を付加してファイルに出力するけど、この付加される改行コードはOS依存か。
この2つのJavaのパターンを今の開発環境であるSunOS 5.8(Solaris 8)で実行すると、両方とも改行コードがLFになった。
JVMによって改行コードとかが変わることはありえないだろうけど、一応使用したJVMはローカルもサーバーも1.3.1_04だ。
ってことは、手動にてJavaで「\n」を出力するとLFになるのか?こういう基本的な部分の知識がかなり欠けてるよなぁ。
とにかく、Javaでファイル操作ってメンドくさいねって話です。んじゃ、次はファイルの読み込みの例を出してみるか。

open (FILE, "<Input.txt");
flock (FILE, 1);
@line = <FILE>;
close (FILE);
foreach (@line) {
    print $_ ;
}

まずはPerlで。ファイルを一行ずつ読み込んで、それを画面に表示するだけのもの。Perlだと短いが、Javaはメンドい。

import java.io.*;
public class Input {
    public static void main(String[] args) {
        try {
            FileInputStream fis = new FileInputStream(new File("Input.txt"));
            InputStreamReader isr = new InputStreamReader(fis);
            BufferedReader br = new BufferedReader(isr);
            while (br.ready()) {
                System.out.println(br.readLine());
            }
            br.close();
            isr.close();
            fis.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

try句直後の3行も1行にまとめられるけど、書き方としてはどっちが美しいんだろうね。Perlには省略の美学があるけど。

BufferedReader br =
new BufferedReader(new InputStreamReader(new FileInputStream(new File("Input.txt"))));

こうすると、BufferedReaderだけをclose()するだけだから楽なのだろうか。大した違いは無さそうだけどね。可読性くらいか。

この書き方で何が不安なのかって言うと、close()処理を明示しない場合は、残り処理はJVM任せってことになるのでは?
BufferedWriter」「OutputStreamWriter」「FileOutputStream」「PrintWriter」がファイル書き出し時に使うクラス。
BufferedReader」「InputStreamReader」「FileInputStream」がファイル読み出し時に使うクラス。その共通点は何か?
これら全てのクラスは手動でclose()処理を行なえる。しかし、try句直後3行を略して1行で書くと、close()処理はできない。
要するに、close()処理をJVMのカベージコレクタか何かに任せたままでいいのかなってこと。ベンチマークでもしてみる?
でも、処理時間を計測したところでJVMにかかる負荷やメモリの使用状況とかは調べることができないんだよな。

【初心者】Java質問・相談スレッド78【大歓迎】

6 :デフォルトの名無しさん :2005/12/22 13:10:55
ファイル読み込みや書き込み操作時のclose()処理について質問です。

1. ----------------------------------------------------------------------

FileInputStream fis = new FileInputStream(new File("Input.txt"));
InputStreamReader isr = new InputStreamReader(fis);
BufferedReader br = new BufferedReader(isr);
while (br.ready()) {
System.out.println(br.readLine());
}
br.close();
isr.close();
fis.close();

2. ----------------------------------------------------------------------

BufferedReader br =
new BufferedReader(new InputStreamReader(new FileInputStream(new File("Input.txt"))));
while (br.ready()) {
System.out.println(br.readLine());
}
br.close();

1.の場合、FileInputStreamもInputStreamReaderもBufferedReaderもclose()を入れていますが、
2.のケースですとBufferedReaderのみのclose()処理があります。

個々のインスタンスを作らずにBufferedReaderのコンストラクタの引数に
直接new InputStreamReaderやnew FileInputStreamなどを指定する場合、
これに対してのclose()処理はJVMが自動で行なってくれるのでしょうか。
また、それによってメモリの使用状況なども変わってくるのでしょうか。
7 名前:デフォルトの名無しさん :2005/12/22 14:08:47
どのclose()も
コンストラクタの引数に指定したストリームのclose()を呼び出すから大丈夫。
この場合だとBufferedReaderのclose()がInputStreamReaderのclose()を呼び出して、
InputStreamReaderのclose()がFileInputStreamのclose()を呼び出す。

1.はbr.close();だけで全部閉じるので後の2つはいらない。

なるほど、そういうことか。だったら、1行にまとめて記述する方法もありなのかな。まだいまいち慣れないけど。
Closeable (Java 2 Platform SE 5.0)」を見る限り、メソッドの概要の部分に一応それっぽい記述があるな。

void close()
このストリームを閉じ、関連付けられているすべてのシステムリソースを解放します。

どうもJavaでのファイル操作は苦手意識が取れない。StreamとかReaderとかWriterとか色々とメンドいんだよ。
こういうのでも日常的に書いていれば覚えられんのかな?Perlなんてファイル処理が目的の言語だから簡単だけどね。

2005/12/23 Fri.

今日は某埼玉県庁勤務公務員主催の飲み会。そんなワケで立川に行ってきました。18時15分集合だったが、微妙に遅刻。
南口の気利屋だったんだけど、この系列の店はどこも食事が美味しいね。多摩センにも気利屋があるけど、久しく行ってない。
参加者は俺とK岡とY崎先生(先生をつけるに値する方だと思う)、某商会の営業マンとN川。S保は用事か何かで途中参加。
それにしても、今日飲んだカシスウーロンの不味いこと。これだけはハズレだったが、食事がそれをカバーできるほどの質。
散々食って飲んで22時半くらいまで騒いで解散。さすがに遠くから来てる連中もいたし、この時間から遊びに行くのは無理。
自分はモノレールでさっさと帰り、風呂入って寝る。それにしても某商会の営業よ、もう少しお前は攻めろ。人のこと言えんが。