技術ネタ

Eye-Fi から S3 にアップロード

ブログネタ
Webアプリケーション に参加中!

昨年末に発売された Eye-Fi Share の日本語版ですが、これまで個人的なバックアップ用途に利用していた Amazon S3 が使えないようだったので Gallery の Protocol を受けとって S3 にアップロードする Proxy 的なアプリを書いて対応してみました。

ソースは CodeRepos に入れておきました。Catalyst 使ってます。
Catalyst 以外に Catalyst::Plugin::Session 系がいくつかと Net::Amazon::S3 あたりが必要だと思います。

設定項目として画像をアップロードするバケット名を指定します。
mod_perl や FastCGI 等で Catalyst アプリを立ちあげたあとは、Eye-Fi の設定画面から Gallery2 を選択します。
以下は mod_perl2 の場合の設定例です。

<Perl>
use lib qw(/home/www/apps/GR2S3/lib);
</Perl>
PerlModule GR2S3
<Location /gr2>
    SetHandler perl-script
    PerlResponseHandler GR2S3
</Location>

URL に アプリケーションの URL、 ユーザー名に S3 の API KEY、 パスワードに シークレットを設定します。
Eye-Fi 側が Gallery2 を想定してるので /gr2/main.php のような パスにアクセスがあるのがちょっと気持ちわるいですが、気にしないでおきましょう。
画像は日付でプレフィックスがつけられて 2009-01-02/PICT001.JPG のようなキーで保存されます。

Gallery のリモートプロトコルは以下に仕様があります。全然綺麗とは言い難いのですが、簡単なので再実装は容易です。
Eye-Fi に対応するためには login, fetch-albums-prune, add-item, new-album のみを実装しておけば大丈夫なようです。

http://codex.gallery2.org/Gallery_Remote:Protocol

OpenID の Attribute Exchange

弊社の OpenID 拡張の参考に。。色々調べてるところです。
mixi の OpenID が AX と SREG に対応してるとの事なので試してみた。

SREG は使った事あるので、今回は AX を実装。以下のような感じでちゃんとニックネーム取れた。
AXだと独自で拡張した野良フィールド足して返してもいいのかなぁ。

やはり、さらりと使いたい人用の SREG と色々追加の属性が取れる AX の両方を実装しておいた方がいいのだろうか。
# だいぶ適当
sub login : Local {
    my( $self, $c ) = @_;
    my $csr = Net::OpenID::Consumer->new(
        ua => LWP::UserAgent->new,
        args => $c->req->parameters,
        consumer_secret => 'xxx',
        required_root => 'http://localhost:3000',
    );
    my $identity = $c->req->param('identity');
    if ($c->req->param('openid-check')) {
        if (my $vident = $csr->verified_identity) {
            my $ax = $vident->signed_extension_fields(
                'http://openid.net/srv/ax/1.0',
            );
            # ニックネームとれた!
            return $c->res->body( join ':', $vident->url, $ax->{'value.nickname'} );
        }
    }
    elsif (my $claimed = $csr->claimed_identity($identity)) {
        $claimed->set_extension_args('http://openid.net/srv/ax/1.0', {
            mode => 'fetch_request',
            'type.nickname' => 'http://axschema.org/namePerson/friendly',
            required => 'nickname',
        });
        my $check_url = $claimed->check_url(
            delayed_return => 1,
            return_to => 'http://localhost:3000/login?openid-check=1',
            trust_root => 'http://localhost:3000',
        );
        return $c->res->redirect( $check_url );
    }
}

社内で使った Apache モジュールの資料

社内の技術MTGで Apache モジュール入門なプレゼンをしたので、資料公開します。
非常に基礎的な内容ですが。

実際の Web サービスでの Apache モジュールの使いどころとしては、translate_name フェーズでゴニョる事が多いですね。
ユーザーへみせる URL と実体の場所との関係が複雑化してきた際には Rewrite でがんばるよりモジュール書いちゃった方がスッキリします。続きを読む

Web標準

ちょっと気になったので釣られてみる。。

hidetox blog | Webの「標準」って?

自社メディアなのに(誰からも文句を言われないのに)ちゃんとしてるライブドアは偉い。というか、他がダメすぎなんだ。


でも、現状がこうならば、「他がダメ」なのではなく、「Web標準などというものに実効性はなく、まったく【標準】ではなく、そんなものに対応しているライブドアは変だ」という主張だって可能だ。(私がこう思っているというわけではなく)

スノッブでギークなスタッフを抱える会社が社内の圧力で何の得にもならない(むしろ経営的にマイナスな)「Web標準とやら」にコストをかけていて苦々しい思いをしているのが経営陣かもしれませんね。知らないけど。


確かに最近書いてる HTML は意識してちゃんとしようとしてます。
メンテナンス性と人材採用とかの副次的要素を考えると、得になってると思ってます。

メンテナンス性に関しては、例えば、広告メニューにページジャックとかあるわけですが HTML 綺麗じゃないと余計に手間がかかってしまいます。
納品して終了というようなスタイルでは無く、継続的な変更していかなかればならない自社メディアなので、初期制作時のコストだけでは無く変更にかかるコストも考えると綺麗にしておいた方がいいと思っています。

副次的な要素としてはソース見てから面接に来る人が結構多いので、綺麗なソースを見せた方が優秀な人材を採用出来る可能性があがるのかなと。

OpenID 実装した件

OpenIDを実装してみました。
このブログでもさっそく、delegate 設定しました。
とりあえず、サーバ側の提供ですが、OpenID を利用したサービスも何か出来るといいかなと思ってます。

実装自体は Net::OpenID::Server を使ったので非常に簡単でした。
一つハマったのが Net::OpenID::Server は Crypt::DH を使ってるのですが、Math::BigInt::Pari か Math::BigInt::GMP をインストールしておかないと非常に動作が遅くなってしまいます。
素の Math::BigInt を使ってても、遅いだけで正常に動作するのでなかなか気づきづらいです。。
Perl で OpenID 実装しようと思ってる方はご注意を。


Profile
  • ライブドアブログ