はじめての Wikipedia に携帯 IPアドレス一覧

携帯向けのサイトを作っていると、アクセス元の IPアドレスで携帯かそうでないかを判断する仕組みを導入することがあります。

いろいろ試行錯誤してこんなページを Wikipedia に作っちゃいました。
http://ja.wikipedia.org/wiki/Mobile:GatewayIP


（以下 Wikipedia にページを作った経緯など）

IPアドレスリストは各キャリアがそれぞれのサイトで公開しています。

docomo（NTTドコモ）
http://www.nttdocomo.co.jp/service/imode/make/content/ip/

SoftBank（ソフトバンク）
http://creation.mb.softbank.jp/web/web_ip.html

au（エーユー）
http://www.au.kddi.com/ezfactory/tec/spec/ezsava_ip.html
「※本情報はEZサーバ以外のホストによる上記表のIPアドレスでのアクセスがないことを保証するものではありません。」とか書いてあるのであまり使っちゃいけないかもしれないですね。。

かなり前もって情報は公開されるようなので普段気にしていればいいのですが、つい忘れてしまいがちです。（au は妙にコピペしずらいし）

そういう情報をまとめているサイトが無いか、プログラムから利用しやすいウェブサービスは無いかと探しますが、なかなか見つかりません。

プログラマなんで、各キャリアのサイトをスクレイピングして CIDR 形式のリストを抽出することが思いつきます。

自分で書く前に情報を探すと Net::CIDR::MobileJP という CPAN モジュールを使った素晴らしい情報に出会います。
http://dsas.blog.klab.org/archives/51117561.html

早速試してみましたが、最近 SoftBank の URL や構造が変わったようで情報が取れません。
そこで Net::CIDR::MobileJP とそのプラグインのソースを見てみると数行の洗練されたコードが見つかります。

これなら参考にして作れると思いますが、待てよと。
この行為はいろんな人が同じことやってるんだろうなーとか、またキャリアのサイトの構造が変わったらやだなーとか。

やっぱり公共性の高いスクレイピングできるまとめページがほしい。
というわけで Wikipedia に恐る恐るページを作っちゃいました。

決してスクレイピングしやすくは無いですが、ひとまず。。

LDReader 記事詳細の WebView をちょっと修正したり

LDReader 0.0.9 をリリースしました。
・記事詳細の WebView でリンクをクリックしたときにダイアログ表示
・ProgressDialog の表示後の処理を修正

記事詳細の WebView でリンクをクリックしたときにダイアログ表示

記事詳細では間違ってリンクをクリックしてしまってブラウザが起動してしまい、非常にストレスを感じていましたが確認用のダイアログを表示することで少し軽減されるようにしました。ソースはこちら。

// NOTE: WebView#setWebViewClient を使用
bodyView.setWebViewClient(new WebViewClient() {
    @Override
    public boolean shouldOverrideUrlLoading(WebView view, final String url) {
        // NOTE: 設定でリンクを無効にした場合はそのまま終了
        if (ReaderPreferences.isDisableItemLinks(getApplicationContext())) {
            return true;
        }
        // NOTE: ダイアログ表示
        new AlertDialog.Builder(ItemActivity.this)
            .setTitle(R.string.msg_confirm_browse)
            .setMessage(url)
            .setPositiveButton("OK", new DialogInterface.OnClickListener() {
                public void onClick(DialogInterface dialog, int whichButton) {
                    // NOTE: OK がおされたら Intent を発行
                    Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url));
                    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
                    startActivity(intent);
                }
            })
            .setNegativeButton("Cancel", new DialogInterface.OnClickListener() {
                public void onClick(DialogInterface dialog, int whichButton) {
                }
            }).show();
        return true;
    }
});

WebViewClient#shouldOverrideUrlLoading は true を返すことで、WebView の標準を動きをオーバーライドすることができます。

ProgressDialog の表示後の処理を修正

ProgressDialog を表示後に Handler#post を使っていた箇所をすべて Thead を使うようにしました。
実はここ、最初は Thread だったんですが Handler は post の他に postDelayed という遅延実行のメソッドも持っており、Thread のような動きをするので、「あ。こっちでいいのか」とつい思い込みをしてました。

意図しているのは

   プログレスバー表示
     ↓
   重い処理
     ↓
   終了

だったんですが、Handler#post を使うと

   重い処理
      ↓
   プログレスバー表示（一瞬）
      ↓
   終了

になっちゃいます。

ここに詳しい解説がのってました！
http://www.adamrocker.com/blog/261/what-is-the-handler-in-android.html

// NOTE: 修正前
final Handler handler = new Handler();
final ProgressDialog dialog = new ProgressDialog(this);
dialog.show();
handler.post(new Runnable() {
    public void run() {
        // NOTE: ここで遅い処理
        // (some code)
        // NOTE: 終わったら ProgressDialog を閉じる
        handler.post(new Runnable() {
            public void run() {
                dialog.dismiss();
            }
        });
    }
});

// NOTE: 修正後
final Handler handler = new Handler();
final ProgressDialog dialog = new ProgressDialog(this);
dialog.show();
new Thread() {
    public void run() {
        // NOTE: ここで遅い処理
        // (some code)
        // NOTE: 終わったら ProgressDialog を閉じる
        handler.post(new Runnable() {
            public void run() {
                dialog.dismiss();
            }
        });
    }
}.start();

LDReader フィード一覧の ListView, ListAdapter にハマる

ども。こっそり version 0.0.8 までバージョンアップしました。

[0.0.6] ListView とデータベースとの不整合でたまに例外発生する問題を解消したつもりが失敗。
[0.0.7] android.widget.CursorAdapter を使うことで修正、等
[0.0.8] フィード一覧からピン一覧を開くと、背景が真っ暗になる問題を修正。


[0.0.7] での主な変更

version 0.0.7 以前では、操作していると次のような例外がたまに発生しました。

java.lang.IllegalStateException:
  The content of the adapter has changed but ListView did not receive a notification.
  Make sure the content of your adapter is not modified from a background thread, but only from the UI thread.

この例外はデータベースのレコード数と ListView のレコード数に違いがあるときに発生します。
LDReader はバックエンドのサービスでレコードを挿入したりしているので自前で色々していたのですが、付け焼刃ではどうしてもこの例外を抑えることができませんでした。

java.lang.Object
   ↳  android.widget.BaseAdapter
      ↳  android.widget.CursorAdapter
         ↳  android.widget.ResourceCursorAdapter

BaseAdapter を継承してゴニョゴニョしていたのですが、探してみると CursorAdapter といクラスがあるではありませんか！

ソースをのぞいて見るとデータベースの更新通知を受け取ってクエリを再発行し、ListView との不整合を解消しているようです。さらに ResourceCursorAdapter では、行ごとの View をリソースを使ってカスタマイズしている場合にピッタリなようです。ApiDemos を見ながら四苦八苦して作ったのですが、まだまだ知らないことがたくさんありそうです。

ちゅうわけで主な変更はこちら。SubscriptionActivity (diff r5)


[0.0.8] での主な変更

Cursor#deactivate を自前でやっていたのですが、Activity#managedQuery を使っていれば deactivate と requery は勝手にやってくれるようです。削除しました。

ちゅうわけで主な変更はこちら。SubscriptionActivity (diff r6)

LDReader ピンに対応しました

関連記事

ども。LDReader をピンに対応させて ver 0.0.5 としました。このブログにコメントいただいちゃったので＾ ＾
以下スナップショットです。

ちょと見づらいですが、記事タイトル右にピンアイコンがあります。このアイコンをクリックするかメニューから「Pin」を選択するとピンをつけたり外したりできます。

ピンは本家同様に一覧でみることができ、ブラウザで閲覧することができます。
その他、記事 1件の URL をクリップボードにコピーしたり、全件の URL リストをメールで送れるようにしときました。

簡単なバージョンアップですが、今回は少し悩んだ点があります。

単純に実装するとすれば、ピン操作は常にサーバに対して追加や削除を実行し、一覧は最新をサーバから持ってくれば良いです。しかし、これだと地下鉄のようなオフライン環境ではピンを追加することができません。

そこで次のような pin テーブルを作成して、ユーザの操作をまず action として保存し、それから通信を行うようにしました。追加の場合は 1:ACTION_ADD, 削除の場合は 2:ACTION_REMOVE, サーバから取得した場合は 0:ACTION_NONE とします。

create table if not exists pin (
    _id integer primary key,
    uri text,
    title text,
    action integer, -- 0:ACTION_NONE, 1:ACTION_ADD, 2:ACTION_REMOVE
    created_time integer
)

ピンの追加はロジックはこんな感じ。

public boolean pinAdd(String uri, String title)
        throws IOException, ReaderException {
    if (!isLogined()) {
        login();
    }
    try {
        ContentResolver cr = this.context.getContentResolver();
        // NOTE: 事前に uri が重複するピンアクションを削除
        cr.delete(Pin.CONTENT_URI, Pin._URI + " = ? and " + Pin._ACTION 
            + " > " + Pin.ACTION_NONE, new String[]{uri});
        // NOTE: ピンアクションを追加。
        ContentValues values = new ContentValues();
        values.put(Pin._URI, uri);
        values.put(Pin._TITLE, title);
        values.put(Pin._ACTION, Pin.ACTION_ADD);
        values.put(Pin._CREATED_TIME, (long) (System.currentTimeMillis() / 1000));
        Uri pinUri = cr.insert(Pin.CONTENT_URI, values);
        // NOTE: 端末がオフラインの場合はここで終了
        if (!isConnected()) {
            return true;
        }
        // NOTE: サーバと http 通信。失敗したら IOException などがスローされる。
        boolean success = this.client.pinAdd(uri, title);
        if (success) {
            // NOTE: 通信が成功したら既存の重複ピンを削除して、
            //       1:ACTION_ADD を 2:ACTION_NONE に更新。
            cr.delete(Pin.CONTENT_URI, Pin._URI + " = ? and " + Pin._ACTION
                + " = " + Pin.ACTION_NONE, new String[]{uri});
            values.put(Pin._ACTION, Pin.ACTION_NONE);
            cr.update(pinUri, values, null, null);
        }
        return success;
    } catch (ParseException e) {
        throw new ReaderException("json parse error", e);
    }
}

このままでは、端末がオフラインのときには 1:ACTION_ADD と 2:ACTION_REMOVE が溜まります。
そこで回線がオンラインになったら実行される処理にピンの同期処理を追加します。

public int syncPins() throws IOException, ReaderException {
    if (!isLogined()) {
        login();
    }
    ContentResolver cr = this.context.getContentResolver();
    // NOTE: 1:ACTION_ADD と 2:ACTION_REMOVE の検索。
    String where = Pin._ACTION + " > " + Pin.ACTION_NONE;
    String order = Pin._ID + " asc";
    Pin.FilterCursor cursor = new Pin.FilterCursor(
        cr.query(Pin.CONTENT_URI, null, where, null, null));
    try {
        while (cursor.moveToNext()) {
            // NOTE: 順番にピンアクションを再現
            Pin pin = cursor.getPin();
            if (pin.getAction() == Pin.ACTION_ADD) {
                pinAdd(pin.getUri(), pin.getTitle());
            } else {
                pinRemove(pin.getUri());
            }
            Uri uri = ContentUris.withAppendedId(Pin.CONTENT_URI, pin.getId());
            cr.delete(uri, null, null);
        }
    } finally {
        cursor.close();
    }
    // NOTE: サーバからピン一覧を全件取得。
    PinsHandler pinsHandler = new PinsHandler();
    try {
        this.client.handlePinAll(pinsHandler);
    } catch (ParseException e) {
        throw new ReaderException("json parse error", e);
    }
    return pinsHandler.counter;
}

関連するソースはこのへん。
@see org.jarx.android.livedoor.reader.Pin
@see org.jarx.android.livedoor.reader.PinActivity
@see org.jarx.android.livedoor.reader.ReaderManager

このピンの実装によってずいぶんと使い勝手が向上したように感じます。ありがとうございます。
次はウィジェットを実装予定です。

論理削除とユニークキー制約

ども。久々に時間ができたのでぼちぼち日記書いてみようかなと。
技術ネタですが。。

データベース設計を行うとき、論理削除を採用することが多いです。
論理削除用のカラムとしては boolean 型もしくは小さい数値型を使います。

create table item (
    id int not null,
    code varchar(40) not null,
    name varchar(240) not null,
    removed boolean not null default false,
    constraint item_pk primary key (id) /* ,
    constraint item_code_uk unique key (code) 本当はユニークキー制約をつけたいが。。 */
);

item（商品）テーブルに一意な code（商品コード）という人が認識しやすい番号を任意に設定できるテーブルを設計するとき、ユニークキー制約をつけてしまうと一度論理削除した商品コードが使いまわせない問題が発生します。仕方なくデータベース側のユニークキー制約は外していました。

このテーブルを使うアプリケーション側では、挿入、更新前にユニークキーチェックを行いますが、アプリケーションサーバが複数台あったり、バッチ処理が平行して実行される可能性があったりでなかなか厳密な整合性はとりづらいです。

最近になってふと、論理削除用のカラムをユニークキー制約に含めてインクリメントすればいいじゃんと思いつきました。そして、主キーが 1つあるタイプならばインクリメントとかしなくてそのまま使えるなーと。

create table item (
    id int not null, -- 0 以上の主キー
    code varchar(40) not null,
    name varchar(240) not null,
    removed int not null default 0,
    constraint item_pk primary key (id) ,
    constraint item_code_uk unique key (code, removed)
);

論理削除するときは、

update item set removed = id where id = ?

通常の検索時には where 句に removed = 0 を指定します。

select * from item where removed = 0

まだ実践で使ってないですが多分大丈夫なはず。
いやースッキリした。

Java のフレームワークどうしましょ

あけましておめでとうございます。

次の受託開発案件で Java を使うことになりそうなのでフレームワークの比較検討しています。

私が今まで使ったことのあるフレームワークは
・Struts 1、2系 → EC など
・Tapestry 3系 → 業務システム
・Click Framework → 自社サービス（openidea.jp）
の 3つです。

一言にフレームワークといっても色々な役割がありますが、私は次の 4つが主要な機能だと考えます。
・URI マッピング
・フォームのバリデーション
・テンプレート
・データベースアクセス

表にするとこんな感じでしょうか。かなり昔の記憶で書いているものあって、正確でなかったり、当時スキル不足や調べ切れなかったものもありますが。。

	URI マッピング	バリデーション	テンプレート	データベースアクセス
Struts	サーブレットフィルタ *.do 標準	独自	JSP 2.0 標準	なし
Tapestry	サーブレットを /app などにマッピング	独自	独自 + ognl 形式	なし
Click Framework	サーブレットフィルタ *.htm 変更不可	独自	Velocity 標準	Cayenne、Spring サポート

この 3つはどれもぴったりハマることなく、気に入らないところは色々いじって使ってました。それぞれの使った感想を簡単にあげます。

Struts:
・設定ファイルが面倒。設定ファイルにして便利だったことはほとんどない。
・*Form, *Action とたくさんのクラスができて管理が面倒。
・学習は比較的容易？情報がたくさんある。

Tapestry:
・業務システムで採用したのが間違いだったかもしれないが、複雑な画面になるとイベントの制御がかなり難解になる。
・カスタムコンポーネントを作り始めると面白い。
・ページ制御側の学習コストは非常に高くつく。HTML テンプレートはスッキリ。

Click Framework：
・拡張子 *.htm が固定で変更できないのが痛い。
・学習は容易。

ほとんどのフレームワークはテンプレート部分や、データベースアクセスは他のプロダクトに変更することが可能です。実はここの選定が肝だったりします。別途テンプレートやデータベースアクセス部分のことは書きたいなと思います。

これらの今まで使ってきたフレームワークの追加調査に加え、Wicket も調査したいです。Spring Framework、S2 など DIコンテナを含むものは今回はパスしようと思います。

ここ 2、3年は Perl、PHP 案件がほとんどだったので忘れていましたが、Java 案件は
→ 新しいフレームワークの選定
→ 開発スタートしてから新しいフレームワークの細かい部分の調査ハマる
で遅延しがちなので要注意ですねー。

mod_ktai バージョンアップ

mod_ktai がバージョンアップしたようです。

前回は mod_ktai おしいなぁという感想だったんですが、今度のバージョンは VirtualHost に対応しています。UTF-8 の PCサイトと Shift_JIS の携帯サイトが共存する環境でも問題なく使えるようになりました。

よかったよかった＾ ＾

これによって表示は mod_ktai に任せることができるので、あとは入力される 3キャリアの絵文字をノーマライズすればいいですね。

Shift_JIS で encodeURIComponent

Ajax が流行り始めてからほとんど UTF-8 でウェブアプリケーションを作っていたので気にならなかったのですが、Shift_JIS で作るとなるとちょっと面倒くさいです。

例えば script.aculo.us の Ajax.InPlaceEditor のコールバックとかで普通に書くと encodeURIComponent が UTF-8 エンコードを施すので、サーバ側で Shift_JIS として受け取れません。

new Ajax.InPlaceEditor(e, "/example/modify_text", {
    callback: function(f, v) {
        return "text=" + encodeURIComponent(v);
    },
    ajaxOption: {method: "post"}
}

そこで思いついたのが encodeURIComponent を 2回行う方法。これでサーバ側で個別にデコードしてやれば良いです。JavaScript を使って日本語パラメータを送信する必要があるところだけです。

new Ajax.InPlaceEditor(e, "/example/modify_text", {
    callback: function(f, v) {
        return "double_encoded_text=" + encodeURIComponent(encodeURIComponent(v));
    },
    ajaxOption: {method: "post"}
}

他に方法あるのかなぁ。。

mod_ktai を試しました

避けてきた携帯3キャリアの絵文字対応をすることになりました。

色々さがして mod_ktai を試しましたが、3つの不満点が・・・

1) 入力のフィルタはしてくれない
2) UTF-8 での閉じるダブルコーテーションが外れるバグ
3) ダブルコーテーションバグを回避しようとして、UTF-8 で提供している他のサービスと分けて、VirtualHost 内に AddOutputFilterByType を記述してみたら、docomo 用のレスポンスヘッダ application/xhtml+xml に反応しないんです。
そこで次のようにタイプを追加したら、docomo 端末でアクセスしても何故か PC 用の絵文字画像に変換されてしまう＞＜

LoadModule ktai_emoji_module modules/mod_ktai_emoji.so
KtaiEmojiConvertMode             auto
KtaiEmojiConvertNativeEmojiDocomo   0
KtaiEmojiEnableAddGuidOn            0
KtaiEmojiHasIconFile                1
KtaiEmojiIconDir           /img/emoji

<VirtualHost *:80>
ServerName example.com
AddOutputFilterByType KTAI_EMOJI_OUTPUT_FILTER text/html application/xhtml+xml
</VirtualHost>

おしい。

簡単クラスパス設定 シェルスクリプト

Java のクラスパス、設定するの正直面倒くさいです。そこで少しだけ便利なスクリプトを使っています。使い方はこんな感じ。

Usage: . classpath.sh (option) [dir]
(option)
  -a  add CLASSPATH
  -r  recursive

指定したディレクトリを走査して jar ファイルだけを環境変数 CLASSPATH に追加します。以下ソースです。

#!/bin/sh

if [ -z "$1" ]; then
  echo "Usage: . classpath.sh (option) [dir]"
  echo "(option)"
  echo "  -a    add CLASSPATH"
  echo "  -r    recursive"
  exit 0
fi

_recursive=0
_add=0
dir=

parse_arguments() {
  for arg do
    case "$arg" in
      -r) _recursive=1 ;;
      -a) _add=1 ;;
      *) dir=$arg ;;
    esac
  done
}

classpath() {
  for i in "$1"/*; do
    if [ -d "$i" -a $_recursive -eq 1 ]; then
      classpath "$i"
    elif [ "${i##*.}" = "jar" ]; then
      _classpath=$_classpath:$i
    fi
  done
}

if [ $_add -eq 1 ]; then
  _classpath=$CLASSPATH
  if [ -z "$_classpath" ] ; then
    _classpath=.
  fi
fi

parse_arguments $*
classpath "$dir"
export CLASSPATH=$_classpath
unset _classpath

プログラミングコードの貼り付け（3）

前記事：プログラミングコードの貼り付け（2）

現在はこれに落ち着いてます。

pre.code {
  background: #eee;
  border: 1px solid #ddd;
  width: 95%;
  padding: 5px;
  font-size: 85%;
  white-space: -moz-pre-wrap; /* Mozilla */
  white-space: -pre-wrap;     /* Opera 4-6 */
  white-space: -o-pre-wrap;   /* Opera 7 */
  white-space: pre-wrap;      /* CSS3 */
  word-wrap: break-word;      /* IE 5.5+ */
  overflow: auto;
}

ant-velocity

どもー。

静的コンテンツだけのページを作るとき、どーしてもヘッダフッタをコピペで何度も書きたくないので調べたところ、Apache Jakarta プロジェクトから次の 2つのプロジェクトを見つけました。

・Apache Velocity Anakia
・Apache Velocity Texen

どちらも、Velocity というテンプレートエンジンを使って Ant のカスタムタスクを提供しています。それぞれすばらしいツールなんですが、ちょっと気に入りません。

Apache Velocity Anakia ... XML をソースとして、vsl を記述する必要がある。
Apache Velocity Texen ... コントロールファイルを記述する必要がある。

Ant と Velocity 使うならもっとシンプルにできそうなのに。。そう考えて作っちゃいました！

ant-velocity-1.0.0

もっともシンプルな Ant ビルドファイルはこんな感じ。カスタムタスクを定義して、todir、fileset を指定するだけ。tmpl ディレクトリ以下の html ファイルを Velocity テンプレートとして評価し、htdocs に出力します。

<taskdef name="velocity" classname="org.jarx.ant.VelocityTask"
    classpathref="classpath" />
<velocity todir="htdocs" encoding="UTF-8">
    <fileset dir="tmpl" includes="**/*.html">
</velocity>

変数を指定したい場合はこう。

<velocity todir="htdocs" encoding="UTF-8">
    <fileset dir="tmpl" includes="**/*.html">
    <parameter name="baseurl" value="http://jarx.org/" />
</velocity>

変数をプロパティファイルに記述したい場合はこう。

<velocity todir="htdocs" encoding="UTF-8"
        propertyFile="resource.properties">
    <fileset dir="tmpl" includes="**/*.html">
</velocity>

ボーダーテンプレートを使いたい場合はこう。

<velocity todir="htdocs" encoding="UTF-8"
        borderTmplFile="tmpl/border-template.html">
     <fileset dir="tmpl" includes="**/*.html">
</velocity>

ボーダーテンプレートはこんな感じ。#parse(${path}) の部分に fileset で指定したテンプレートの内容が入ります。

<html>
<head><title>border template example</title></head>
<body>#parse(${path})</body>
</html>

svn:ignore にハマった

svn:ignore が有効になるのは、「SVN 管理下にないディレクトリ・ファイル」に対してなんですね。ちょっと勘違いしてました。

jar ファイルの場所を見つける方法

自作の jar ファイルに含まれたクラスを使うとき、その jar のパスやディレクトリを知りたいと思ったことありませんか？

かなり昔に作った自作ライブラリの一部ですが、最近、思い出したように使ってみて便利だったので紹介します。

import java.io.File;
import java.io.IOException;
import java.net.URL;
import java.net.URLDecoder;
import java.security.ProtectionDomain;
import java.security.CodeSource;

public class ClassUtils {

    public static URL findClassLocation(Class c)
            throws SecurityException {
        Package p = c.getPackage();
        String className;
        if (p != null) {
            className = c.getName().substring(p.getName().length() + 1);
        } else {
            className = c.getName();
        }
        URL location = c.getResource(className + ".class");
        if (location == null) {
            // NOTE: 昔 Tomcat の WEB-INF/lib とかの jar を探すときはこの
            //       処理に入ったのだが。。。今は不要かも。
            ProtectionDomain domain = c.getProtectionDomain();
            CodeSource source = domain.getCodeSource();
            if (source != null) {
                location = source.getLocation();
            }
        }
        return location;
    }

    private static File findBaseDirectory(URL classLocation)
            throws IOException {
        if (classLocation == null) {
            return null;
        }
        String file = classLocation.getFile();
        if (classLocation.getProtocol().equals("jar")) {
            int i = file.lastIndexOf('!');
            if (i != -1) {
                file = file.substring(0, i);
            }
            return findBaseDirectory(new URL(file));
        }
        File dir = new File(URLDecoder.decode(file,
            System.getProperty("file.encoding")));
        if (!dir.isDirectory()) {
            dir = dir.getParentFile();
        }
        return dir;
    }

    public static File findBaseDirectory(Class c)
            throws SecurityException, IOException {
        return findBaseDirectory(findClassLocation(c));
    }

    public static void main(String[] args) throws Exception {
        System.out.println(findBaseDirectory(java.lang.String.class));
    }
}

これがあれば xxx.home などのシステムプロパティ渡さずに済むことが多々あると思います。
sen などもこれに対応してくれればなぁ。。。

プログラミングコードの貼り付け（2）

前記事：プログラミングコードの貼り付け
またまた Blogger の仕様が元に戻りました？今日確認したら pre の中に br が入らなくなったようなので、以下の CSS を取り除きました。

pre.code br {
  display: none;
}

どうせやるなら以下のような書き方のほうが Blogger 云々に右往左往しなくて良かったかも。

pre.code br+br {
  display: run-in;
}

Java めんどくさっ

先日 OpenIdea.jp というサービスを初めた記事を書きました。Java で出来ています。でも作ってる途中、感じました。。。

Java めんどくさっ

ちゃんと書くにはいい言語で、総合的には最も好きなんですが、何せ面倒くさい。

そんなとき以下の記事見つけました。
COBOL のように死んだ言語 ～ Java は置き換えられる時期に来ているのか

ふむ。なるほど。。。とりあえず Groovy はじめてみよう。

サーブレットコンテナ（Tomcat）とリバースプロクシを組み合わせた時の問題解決

Tomcat とリバースプロクシを組み合わせた時に微妙な問題に直面しました。その問題の解決方法をメモしておきます。

状況としては、Tomcat は http://localhost:8080/app/ のようにコンテキストパス /app で動作しています。
/app で動作しているアプリケーションに http://app.example.com/ という URL でリバースプロクシの設定を行います。
Tomcat は他のアプリケーションも動作しているので、ルートコンテキストは用いることができません。

http://app.example.com/ （Apache）
↓
（リバースプロクシ）
↓
http://localhost:8080/app/ （Tomcat）

まずはこんな感じで設定しました。問題は 2つあります。

ProxyPath / http://localhost:8080/app
ProxyPassReverse / http://localhost:8080/

1つ目は Cookie 問題です。Tomcat の発行する Set-Cookie の Path 属性が /app となり、ブラウザが / へのアクセスのときにはリクエストヘッダに Cookie をつけて送信しません。

Set-Cookie: JSESSIONID=XXXXXXXXXXXXX; Path=/app

ここでは、ProxyPassReverseCookiePath ディレクティブを用いて、Set-Cookie の Path属性 /app を / に置換します。

ProxyPath / http://localhost:8080/app/
ProxyPassReverse / http://localhost:8080/
ProxyPassReverseCookiePath /app /

これでブラウザへは次のヘッダが返されます。

Set-Cookie; JSESSIONID=XXXXXXXXXXXXX; Path=/

2つ目はコンテキストパス問題です。Tomcat をルートコンテキストで動かしたり、ルートコンテキストは他で使っていても、ポートを変えてもう 1つ Tomcat を起動すれば問題はすぐ解決するのですが、ここは敢えて別の方法をとってみます。

やりたいことは、次の 2つの URL どちらからアクセスしても同じように動くことです。

http://app.example.com/
http://localhost:8080/app/

今回は以下のような方法を使ってみました。

まず、リバースプロクシの設定に加え X-Context-Path という独自のヘッダを付与します。

RequestHeader set X-Context-Path ""
ProxyPath / http://localhost:8080/app/
ProxyPassReverse / http://localhost:8080/
ProxyPassReverseCookiePath /app /

これで Tomcat は、リバースプロクシからきたリクエストを X-Context-Path というヘッダで判断することができます。
次にサーブレットフィルタを作成し、リクエストオブジェクトをラップして、getContextPath メソッドをオーバーライドします。

public void doFilter(ServletRequest req, ServletResponse res,
        FilterChain chain) throws IOException, ServletException {
    doFilter((HttpServletRequest) req, (HttpServletResponse) res, chain);
}
public void doFilter(HttpServletRequest req, HttpServletResponse res,
        FilterChain chain) throws IOException, ServletException {
    // NOTE: X-Context-Path を受け取って、null で無ければその値を
    // コンテキストパスとして使用する。
    // ※実際は XSS などを埋め込まれないように文字列チェックする必要
    // あります。
    final String contextPath = req.getHeader("X-Context-Path");
    if (contextPath != null) {
        req = new HttpServletRequestWrapper(req) {
            public String getContextPath() {
                return contextPath;
            }
        };
    }
    chain.doFilter(req, res);
}

この他に getServerPort や getRequestURI など変更すべき箇所がたくさんありますが省略。。こうしておけば、http://localhost:8080/app/ にアクセスしたときも http://app.example.com/ にアクセスしたときも期待通りに動作します。

OpenIdea.jp

OpenIdea.jp というサービスを作ってみました。

作った理由：

• 日ごろ思いつくアイデアを公開したかった。（普段はメールの下書きでためていました。）
• 何でも良いからサービスを 1つ公開したかった。

苦手な HTML コーディングや、ロゴなども自分でやってます。
Java、ClickFramework、DbUtils、MySQL などで動いてます。まだ検索やランキングも動いてなかったり。。

今のとこ、何ら新しいことはないのですが、実験場として色々追加していく予定です。

今後の予定：

• アイデアグラフ（最初はツリー表示でいいかな）
• OpenID 2.0 対応
  
• メール投稿

まだプレスリリースとかしてません。もうちょっと触ったらやろうと思います。

memcached でキーの列挙（2)

前回（memcached でキーの列挙）の続きです。サンプルの Perl コードです。ちょこっといじればイベント駆動のモジュールが作れそう。。

my $size = 1000;
my $cache = Cache::Memcached->new({
    servers => ['localhost:11211'],
});
my $slabs = $cache->stats('slabs');
my @stat_ids = ();
for my $host (keys %{$slabs->{hosts}}) {
    my $slabs_text = $slabs->{hosts}->{$host}->{slabs};
    my @lines = split("\n", $slabs_text);
    for my $line (@lines) {
        ($line =~ /STAT ([0-9]+):chunk_size [0-9]+/) or next;
        push(@stat_ids, $1);
    }
}
for my $stat_id (@stat_ids) {
    my $cmd = "cachedump $stat_id $size";
    print "[$cmd]\n";
    my $cachedump = $cache->stats($cmd);
    for my $host (keys %{$cachedump->{hosts}}) {
        my $cachedump_text = $cachedump->{hosts}->{$host}->{$cmd};
        my @lines = split("\n", $cachedump_text);
        for my $line (@lines) {
            ($line =~ /^ITEM (.+) \[(.+) b; (.+) s\]/) or next;
            my ($key, $b, $s) = ($1, $2, $3);
            print "\t$key [$b bytes]\n";
        }
    }
}

memcached でキーの列挙

memcached で、キーの列挙ができないか調査していたところ、PHPで実現している方のブログ記事を見つけました。（ http://blog.cles.jp/item/2141 ）

これ Perl の Cache::Memcached でできるだろうと思って挑戦したのですが、何故か stats cachedump が動作しないんです。

そこで telnet を使って直接コマンドをたたいてみることにしました。まずは接続。。

> telnet localhost 11211

次に stats slabs コマンドを実行してみます。

stats slabs
STAT 1:chunk_size 80
STAT 1:chunks_per_page 13107
STAT 1:total_pages 1
STAT 1:total_chunks 13107
STAT 1:used_chunks 13107
STAT 1:free_chunks 0
STAT 1:free_chunks_end 13065
STAT 2:chunk_size 100
STAT 2:chunks_per_page 10485
STAT 2:total_pages 1
STAT 2:total_chunks 10485
STAT 2:used_chunks 10485
STAT 2:free_chunks 0
STAT 2:free_chunks_end 10447
.....
STAT active_slabs 16
STAT total_malloced 16763844
END

この出力結果のうちの STAT {数字} の部分を使って stats cachedump コマンドを実行します。STAT {数字} は連番ではないみたいなので注意が必要です。

stats cachedump {数字} {ダンプするキーの最大数}
ITEM {キー} [{統計情報}]
.....
END

おお。キーの列挙できるじゃん。ちゅうことで Cache::Memcached のソースみたら stats メソッドは引数を最初の 1個しか使ってないのか。

# 中身も見ずにこういう呼び出しをしてしまってた。
$cache->stats('cachedump', 1, 100);

# こうすりゃ良かったんすね。
$cache->stats('cachedump 1 100');

memcached でキーの列挙（２）へ続く