もじゃの日記

perl のマルチスレッド

2011-09-03T12:37:00.005+09:00

ども。ある案件で perl のマルチスレッドを使うことになりました。

use threads;

my @ts;

for (1..5) {

   my $t = threads->create(sub {

       # some code

       …

       # 1つのスレッド処理完了 *1

   });

   push(@ts, $t);

}

eval { $_->join } for @ts;



# 終了処理 *2

このようなコードを書いたのですが、どれかのスレッドの「# 1つのスレッド処理完了 *1」のタイミング「Scalars leaked: 1」が発生します。
このエラーが発生するとまだ「# 終了処理 *2」は実行されず、メインプロセスごと落ちてしまいます。
まだ実行中のスレッドもメインプロセスとともに落ちます。

再現率は 100％ではないのですが、スレッドでやる仕事時間が長ければ長いほど「Scalars leaked: 1」は 100％に近い状態で発生していました。

スレッドの呼び出し方法が悪いのかと思い事前に関数定義したり

my $runnable = sub {

   # some coe

};

my @ts;

for (1..5) {

   my $t = threads->create($runnable);

   push(@ts, $t);

}

eval { $_->join } for @ts;

こんなことしたり

my @ts;

for (1..5) {

   my $t = threads->create(\&runnable);

   push(@ts, $t);

}

eval { $_->join } for @ts;



sub runnable {

   # some coe

};

こんなことしたり、色々試しましたが症状は改善しません。

my @ts;

for (1..5) {

   my $t = threads->create('runnable');

   push(@ts, $t);

}

eval { $_->join } for @ts;



sub runnable {

   # some coe

};

perl 5.8.8 を使っていたので perl 5.14.1 にもしてみましたが、「Scalars leaked: 1」の代わりに「Segmentation fault」が発生するようになりました。

最終的に以下の方法でひとまず解決しました。perl 5.10.x あたりから登場する threads::shared を使います。

use threads;

use threads::shared;



my %alive :shared;

my $keepalive :shared;



$keepalive = 1;

for my $i (1..5) {

   $alive{$i} = time();

   my $t = threads->create(sub {

       my $ii = shift;

       # some code

       $alive{$ii} = time(); # この時間にまだ生きいることを知らせる

       # some code

       $alive{$ii} = time(); # この時間にまだ生きいることを知らせる

       # some code

       delete $alive{$ii}; # このスレッドの処理が終わったので %alive を消す

       while (1) {

           last unless $keepalive; # 他のすべてのスレッドが終了し、メインスレッドの「# 終了処理 *2」が終わるまで待機

           sleep(2);

       }

   }, $i);

   $t->detach; # join しない

}



# join の代わりに %alive が全部なくなるまで待つ

while (1) {

   my @keys = keys %alive;

   last if @keys == 0; # %alive が無くなったら終了

   my $now = time();

   for my $key (@keys) {

       my $a = $alive{$key} or next;

       if ($now - $a > 30) {

            # %alive 処理ができずに落ちたスレッドがいるかも知れないので、最後の生存通知から 30秒以上たってる場合は以後処理しない。

           warn "timeout $key";

           delete $alive{$key};

       }

   }

   sleep(5);

}



# 終了処理 *2

# some code



$keepalive = 0; # すべてのスレッドに関数を終了して良いことを知らせる。このあとどこかで Segmentation fault が発生するかも知れないが、構わないものとする。

たぶん、大丈夫だと思う。美しくはないですが。。
あやうく Java で書きなおそうかと思いました。

memcached でキーの列挙 (3)

2011-08-23T14:06:00.001+09:00

前回のエントリ memcached でキーの列挙 (2)

こんなん作りました。memcached-tool ぽく。既にあったらすません～。
http://code.google.com/p/memcached-keys/

Google App Engine (GAE) の runserver 停止

2011-06-07T18:37:00.002+09:00

ども！ご無沙汰してます。

近頃は受託案件に加え、モバゲー向けに自社製ゲームを出したりしてましたが、6月2日にサービスを終了しました。
時間ができたら開発に至った経緯や失敗談など書いていこうと思います。

さて、最近は Google App Engine Java で試験的に開発などを行っています。
ビルドは Windows にて ant を使っていますが、そこで遭遇した問題を 1つ解決したのでメモ書きです。

ant でのビルドと動作確認は runserver タスクを実行しますが、ドキュメント通りに Ctrl+C でプロセスを落としても Jetty の java.exe が残ったままになる問題があります。

残ったままでは次の変更が反映されないので、タスクマネージャで java.exe を手動で終了させます。
めんどくさいので以下のように runserver を定義することで解決しました。

変更前
    <target name="runserver" depends="datanucleusenhance"
            description="Starts the development server.">
        <dev_appserver war="war" />
    </target>

変更後
    <target name="runserver" depends="datanucleusenhance"
            description="Starts the development server.">
      <java classname="com.google.appengine.tools.development.DevAppServerMain"
            classpath="${appengine.tools.classpath}"
            fork="true" failonerror="true">
        <jvmarg value="-javaagent:${appengine.sdk.home}/lib/agent/appengine-agent.jar" />
        <arg value="--port=8080"/>
        <arg value="--address=localhost"/>
        <arg value="war"/>
      </java>
    </target>

Google App Engine 標準の runserver は dev_appserver マクロを呼び出し、com.google.appengine.tools.KickStart を起動していますが、これをすっ飛ばして
com.google.appengine.tools.development.DevAppServerMain を直接起動します。

キモは -javaagent ですね。

これで少し快適に開発ができるようになるはず。。

　

FastReader (android GoogleReader クライアント) のソースコードを公開しました

2010-05-17T04:10:00.005+09:00

FastReader を公開して 1か月半がたちました。

現在 9000件のダウンロード、34％のアクティブユーザ数です。
まさかこれほどのダウンロード数があるとは思いもよりませんでした。

さらに思いもよらぬことに、バグや機能改善要望などを（主に英語で）たくさん頂くことができました。
この場を借りてお礼申し上げます。

今、もっとも悩ましい問題は「同期が遅く CPU 使用率が高い状態が続く」ことです。
開発者としての意地もあるの調査を続けてましたが、どうにも解決策が見いだせず、悶々として過ごしていました。

いつまでも解決しないまま放置するのも申し訳ないので、ソースコードを公開して一緒に開発してくださる方を募集してみることにしました。
http://code.google.com/p/fast-reader/

もし参加しても良い、または少しでもお気づきの点がございましたら android-support@trycatch.jp までお寄せいただければ幸いです。

ちょっと恥ずかしいですが、広告を入れたり、有料バージョンを作ったりしようと目論んでいた時期もありました。
このプロジェクトに関しては一切を放棄します。

FastReader を公開してみました

2010-04-13T11:14:00.004+09:00

4月2日に FastReader という Android用 Google Reader クライアントを公開してみました。

最初は LDReader を改良して Google Reader にも対応するマルチなリーダを作ろうと試行錯誤をしていたのですが、カテゴリとタグ、既読管理の方法が大きく違うので断念しました。

似たようなアプリに NewsRob、NetaShare という素晴らしいものがあるのですが、せっかく Google Reader と通信するクラスを作ったので LDReader の UI 部分を流用して公開に踏み切りました。

今のところの特徴としては、
- タブでフィード一覧、タグ一覧を分けて表示
- オフラインでつけたスターも後で同期する
- 「記事一覧を省略」の設定をすることで、短いステップでフィード消化が可能
などです。

↓のキャプチャは Android のデベロッパーコンソールのものです。（4月13日午前）

公開してみてびっくりしたのが、意外にダウンロードして使ってくれてる人がいらっしゃることです。
2日で 1000 ダウンロードを超えました。英語でのバグ報告や機能改善要望も数件いただきました。

また恥ずかしながら version 0.0.1 からバグがたくさんあり、一時期は☆が 2.5 まで下がったりもしましたがなんとか 3.5 付近まで回復しました。なんとか 4まではもっていきたいですね。

というわけで、機能改善や追加を行っていきます。
今後ともよろしくお願いいたします。

Google Checkout 販売者登録

2010-03-24T09:44:00.002+09:00

Google Checkout の販売者としての法人口座登録がようやく成功しました。

銀行は東京三菱 UFJ 銀行です。英語名は「Bank of Tokyo-Mitsubishi UFJ」。
3か月かかりました。

何故 3か月もかかったのか、簡単に説明しますと、

・失敗の理由が良く分からない。Google に問い合わせても分からない。
・銀行側に問い合わせても分からない。何のことか理解してもらえず対応していないの一点張り。
・Google Checkout に法人格の括弧「ｶ)」が登録できなかった。（今はできるようになりました）
・会社名は「トライキャッチ」なのですが、口座名義は「トライキヤツチ」と小さいカタカナでないので気づくのに時間がかかった。

てな感じです。

Google のサポートさんとは 20通ぐらいのやり取りをさせていただきました。
最後までご対応いただいてありがとうございます。

有料の Android アプリはまだ無いですが、事前準備ができてやる気が沸いてきました。

LDReader 1.0.5 をリリースしました。

2010-02-05T15:44:00.002+09:00

（LDReader のリリース記事ばっかりですが。。）

LDReader 1.0.5 をリリースしました。主な変更点は以下です。
1. 記事の削除機能を追加
2. バックエンドで記事取り込み中のもっさり感を解消
（ソース差分 r12）

1. 記事の削除機能を追加
・全記事
・未読記事のみ
・特定フィードの全記事
・特定フィードの未読記事のみ
の削除機能を追加しました。

2. バックエンドで記事取り込み中のもっさり感を解消
一覧系の画面では、ResourceCursorAdapter の autoRequery オプションを true に設定していたのですが、記事が 1件挿入されるたびに SELECT文を発行しており、このせいで画面が固まったようになる問題がありました。autoRequery を false にして独自の更新通知を受け取った場合のみに requery するようにしました。

LDReader 1.0.2 パフォーマンス改善と記事一覧画面追加

2010-01-31T03:07:00.004+09:00

android の LDReader 1.0.2 をリリースしました。主な変更点はこちら。

・記事一覧画面を追加
・パフォーマンス改善
・バグ修正
（ソース差分）

記事一覧画面について

今までの画面遷移は
フィード一覧 → 記事詳細
だったのですが
フィード一覧 → 記事一覧 → 記事詳細
としました。

記事一覧を作ってみたら今まで無理して記事詳細に詰め込んでいた機能が、以外とすんなりおさまるようになりました。
使用感もこちらの方が自然になったと思います。

パフォーマンス改善

使っていてデータがたまってくると、記事詳細からフィード一覧へ戻るときどうしても遅いことに気づき調査したところ。。

sqlite に対する次の SQL が遅いことが分かりました。

select count(*) from item subscription_id = ? and unread = 1

item テーブルのスキーマはこんな感じです。id にアンダーバーがついてるのは android の慣例ですね。

CREATE TABLE item (
  _id integer primary key,
  subscription_id integer,
  uri text,
  title text,
  body text,
  author text,
  unread integer,
  created_time integer,
  modified_time integer
);
CREATE INDEX idx_item_created_time on item(created_time);
CREATE INDEX idx_item_modified_time on item(modified_time);
CREATE INDEX idx_item_subscription_id on item(subscription_id);
CREATE INDEX idx_item_title on item(title);
CREATE INDEX idx_item_unread on item(unread);

item テーブルの subscription_id と unread にはそれぞれインディクスを貼ってあるのにどーしてこんなに遅いんだろうと。

色々と回り道しつつ、次のように複合インディクスを追加することで解決しました。

CREATE INDEX idx_item_unread_by_sub_id on item(subscription, unread);

使ってくださってる方がいらっしゃったら是非アップグレードをお勧めします＾＾

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

2009-11-25T18:49:00.004+09:00

携帯向けのサイトを作っていると、アクセス元の 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 をちょっと修正したり

2009-11-19T17:28:00.002+09:00

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 にハマる

2009-11-16T19:28:00.004+09:00

ども。こっそり 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 ピンに対応しました

2009-11-15T02:34:00.007+09:00

関連記事

ども。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

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

LDReader の画面遷移

2009-11-11T21:17:00.006+09:00

前記事

LDReader の画面遷移は少し変かも知れません。

現在の画面遷移は
フィード一覧 → 未読の最新の記事詳細 → （未読がなければ）既読の最新の記事詳細
となっています。

普通にやるなら
フィード一覧 → 記事一覧 → 記事詳細
ですかね。

記事一覧画面が無いです。個人的な需要の ”とにかく未読をチェックしたい”で作り始めたのでこうなっちゃってますが、どうでしょう？もし使いづらいとかコメントたくさんもらったら変えたいと思います。

フィード一覧画面：

記事詳細画面：

android アプリ LDReader をマーケットに公開しました

2009-11-11T19:08:00.006+09:00

android で動く LDReader という livedoor Reader クライアントを作ってみました。

androlib.com: マーケット紹介ページ
code.google.com: Google Code プロジェクトページ

今のとこ 30件ぐらいダウンロードがあります。（紹介ページの星 4つは、つい自分で押してしまいましたｗ）

この LDReader については何回か書いていきたいなと思います。

LDReader とは：
定期的にサーバと通信して端末内に情報を保存し、オフラインで RSS の内容を閲覧できるのが特徴です。端末で独自に既読/未読の管理を行います。表示形式はフラットのみです。

作った経緯：
android を入手して最初にほしいなと思ったアプリケーションで、探しても良さそうなのが見つけられなかったためです。地下鉄での移動が多いのでオフラインでも更新をチェックできることを重要視しました。

Google Code でソースコードを公開した理由：
android の SDK やその特性は少しクセがあって作るのに結構苦労しました。つまづいた点の紹介をしたかったのと、ここはこれでいいのか？という疑問を持ったままリリースしたのでツッコミがほしかったのが一番の理由です。
オープンソース版の FastLadder もあるし、作ったのものをオープンにしてみたかったのもありますね＾＾

追加で考えている機能：
・未読数と最新記事の何件かが表示されるウィジェットに対応する。
・記事検索ができるように。
・キャッシュ記事のクリア。
・表示形式を livedoor Reader 本家と同じく、フォルダやレートに対応する。
・FastLadder に対応する。（fastladder.org と任意のドメイン）
・ピンをつけれるようにする。
・レートをつけれるようにする。
・android ではあまり見ないフィードを隠す。

開発元は株式会社トライキャッチとしました。
パッケージのドメインは org.jarx.android を使ってます。オープンソースモノはこのドメインを使っていこうと思ってます。そのうちウェブページも充実させないと。。

XML の Preference で Intent 呼び出し

2009-10-28T18:40:00.002+09:00

ちょっとハマったのでメモ

    <PreferenceScreen
           android:title="[タイトル]"
           android:summary="[サマリ]">
       <intent android:action="android.intent.action.VIEW"
               android:targetPackage="[パッケージ名]"
               android:targetClass="[パッケージ名].[クラス名]" />
   </PreferenceScreen>

android ソース入手。(CentOS 5.3 yum git-1.5.4)

2009-08-14T02:15:00.006+09:00

簡単なことですが、すぐ忘れるのでメモ投稿です。

android ソースを入手したくて repo コマンド実行しようとすると、git 1.5.4 以上が必要なんですって。

repo init -u  git://android.git.kernel.org/platform/manifest.git
fatal: git 1.5.4 or later required

私は yum(rpm)派なんですが、rpmforge には 1.5.2 しかなくてどうしようと思ってたら git 本家に yum リポジトリがあったのでそれを使いました。
git は 1.5.4 の最新と思われるものを指定してます。

wget http://kernel.org/pub/software/scm/git/RPMS/git.repo -O /etc/yum.repos.d/git.repo
yum install git-1.5.4.6-1

あとは repo というスクリプトをダウンロードして

mkdir ~/bin
wget http://android.git.kernel.org/repo -O ~/bin/repo
chmod 755 ~/bin/repo

git config で user.email, user.name を設定して、repo init、repo sync でソースコードのダウンロードがはじまります。

git config --global user.email "メアド"
git config --global user.name "名前"
repo init -u git://android.git.kernel.org/platform/manifest.git
repo sync

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

2009-07-03T16:46:00.005+09:00

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

データベース設計を行うとき、論理削除を採用することが多いです。
論理削除用のカラムとしては 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

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

起業して1年

2009-04-06T03:19:00.002+09:00

1年が早いです。去年の4月に起業してから過去お付き合いのある会社、知人から仕事をいただいて何とかやってこれました。ありがとうございます。

今年は大きな仕事を受注し、社員を増やしたいと思います。

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

2009-01-20T14:03:00.006+09:00

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

次の受託開発案件で 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 案件は
→ 新しいフレームワークの選定
→ 開発スタートしてから新しいフレームワークの細かい部分の調査ハマる
で遅延しがちなので要注意ですねー。

仕事でつながるサービス

2008-12-22T07:22:00.003+09:00

どもどもー。起業して半年以上たちますが、未だに一人で受託案件こなしてます。
今期は何とか黒字でしたが、そろそろこの一人受託開発スタイルから脱却しないとだめですね。

つまり、社員を雇ったり仕事の一部を外注していきたいのですが。。

そんなときに見つけたサービス「ランサーズ」さん。最近できた様子です。
http://www.lancers.jp/

楽天ビジネスっぽい仕組みは、世の中に無ければ作りたいなーと思ってましたが、これ大変分かりやすくて良いです。どんどん発展していきそうな予感です。

試しに仕事の依頼をしてみようかなー。

mod_ktai バージョンアップ

2008-11-12T02:27:00.004+09:00

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

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

よかったよかった＾＾

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

Shift_JIS で encodeURIComponent

2008-10-24T11:20:00.003+09:00

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 を試しました

2008-10-17T06:26:00.003+09:00

避けてきた携帯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>

おしい。

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

2008-09-15T17:38:00.003+09:00

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

上流工程と下流工程の別の呼び方

2008-08-29T13:30:00.005+09:00

いわゆるウォーターフォール開発の工程で、企画から要件定義や設計は「上流工程」、プログラミングからテストや運用は「下流工程」にあたります。私はこの言葉あまり好きではありません。

水が流れる → 川をイメージして出来たのでしょうが、どうも下流はイメージが良くないです。
日本だけですかね？これって。

全工程を半分に割ってそれぞれを呼べばよいのですが、

前半工程、後半工程
往路工程、復路工程

むむむ。どれもしっくりこないですねぇ。。