tf::blog

Catalyst 5.8へのアップグレード

2011-02-23T14:35:34Z

会社の業務で使っているシステムのアップグレードをそろそろ手をつけなきゃなと思いつつ、どんどん時間が過ぎていった。

変更点などを大まかに頭に入れつつ、熟慮した結果が「作り直したほうが早い」だったため、先延ばしにしていたがそろそろ限界です。

「動いているものには手を出すな」が鉄則だけど、あとあとメンテナンスしなければいけなくなった時に古すぎて手の施しようもなくなってしまう可能性が高いからな・・・。

	現状	アップグレード後
Language	perl 5.8	perl 5.12
Flamework	Catalyst 5.7	Catalyst 5.8
Web Server	Apache2	Apache2
Application Server	Apache2 + mod_perl	Starman

一番大きいな変化はMooseベースになったことと、使っていたPluginなどの多くが非推奨になっていること。

ビジネスロジック自体は変える必要がないが、土台だけをきれいサッパリかえることにする。

Catalystの5.8へのアップグレードはTest::WWW::Mechanizeがうまく入らなかった以外はほぼノンストップでいけた。

Apache2 + mod_perlからStarmanにする際にCatalystをPSGI経由で起動するように変更するのだが、これが一癖あった。

StarmanはStart::Server経由で下記のような感じで起動してみる。

sudo /usr/local/bin/start_server \
    --port=PortNo \
    -- starman \
    --workers X \
    /path/to/MyApp.psgi

Myapp.pmでは@INCから見つけられない、Myapp.psgiでは設定ファイルが見つからないというエラーになる。

どちらもFindBinモジュールで現在のPath情報を取得して、その位置から相対的に自分のモジュールのパスや設定ファイルの位置を指定していた。

エラー出力をみてみると、どうやら/usr/local/binが入っている。もしや・・・。

$ file /usr/local/bin/start_server
/usr/local/bin/start_server: a /usr/local/bin/perl script text executable

start_server自体が最初にKickされるperlのスクリプトなので、start_serverの位置が入ってしまったということか・・・。

このままでは本番環境やテスト環境によってプロジェクトのパスが変わるたびに内容を書き換えないといけなくなってしまう。

Cwd::getcwdなどでも現在のパス情報を取得できなかったため、起動スクリプトでhostnameで振り分け、環境変数を経由してプロジェクトのルートのパスを渡すことにした。

hostnameでの切り分け部分

HOST=$(hostname)

if [ $HOST = 'production' ]; then
    HOME='/path/to/production/home'

elif [ $HOST = 'development' ]; then
    HOME='/path/to/development/home'

else
    echo "Please set infomation of host!"
    return 0

fi

start_serverの起動部分

sudo CATALYST_HOME=$HOME /usr/local/bin/start_server \
    --port=8080 \
    -- starman \
    --workers 5 \
    $HOME/script/MyApp.psgi &

それに伴い、MyApp.pmとMyApp.psgiのライブラリのパスと設定ファイルの位置も下記のように変更した。

MyApp.pm

__PACKAGE__->config('Plugin::ConfigLoader' =>
                    {file => "$ENV{CATALYST_HOME}/aquos-web.yml"});

MyApp.psgi

use lib "$ENV{CATALYST_HOME}/lib";
use aquos::Web;

最終的に下記のwikiを参考に、start_serverの起動スクリプトを作成し、MyApp.psgiはとりあえずアクセスログ、エラーログ、セッション、Basic認証を有効にして最小限の環境で開発をスタートしていくことにした。

perlbal-starman-psgi - Catalyst::Wiki

starmanctl.sh

#!/usr/bin/env bash

PIDFILE='/tmp/start_server.pid'
START_SERVER=/usr/local/bin/start_server
APP=MyApp.psgi
PORT=8080
WORKERS=5
CATALYST_HOME=
HOME=
DEBUG=0 

check_host() {
    HOST=$(hostname)

    if [ $HOST = 'production' ]; then
        HOME='/path/to/production/home'

    elif [ $HOST = 'development' ]; then
        HOME='/path/to/development/home'
        DEBUG=1

    else
        echo "** Please set the infomation of this host!"
        exit 1

    fi
}

check_running() {
    [ -s $PIDFILE ] && sudo kill -0 $(cat $PIDFILE) >/dev/null 2>&1
}

_start() {

    sudo CATALYST_HOME=$HOME \
        CATALYST_DEBUG=$DEBUG \
        $START_SERVER \
        --port=$PORT \
        --pid-file=$PIDFILE \
        -- starman \
        --workers $WORKERS \
        $HOME/script/$APP &

    return 1
}

case "$1" in
    start)
        if check_running ; then
            echo "** Already running."
            exit 1;
        fi

        check_host

        _start
        ;;
    stop)
        sudo killall start_server
        ;;
    restart)
        sudo kill -HUP `cat $PIDFILE`
        ;;
     *)
        echo $"Usage: $0 {start|stop|restart}"
        exit 1
        ;;
esac

MyApp.psgi

#!/usr/bin/env perl

use strict;
use warnings;
use Plack::Builder;

use lib "$ENV{CATALYST_HOME}/lib";
use MyApp;

my $access_log = "$ENV{CATALYST_HOME}/script/log/access_log";
my $error_log  = "$ENV{CATALYST_HOME}/script/log/error_log";

# Main
MyApp->setup_engine('PSGI');
my $app = sub { MyApp->run(@_) };

# Extention
builder {
    my $logfh;
    open $logfh, ">>", $access_log or die $!;
    open STDERR, ">>", $error_log or die $!;
    $logfh->autoflush(1);

    enable "AccessLog", logger => sub { print $logfh @_ };
    enable "Auth::Basic", authenticator => \&authen_cb;
    enable 'Session';
    enable 'Debug';
    $app;
};

sub authen_cb {
    my($username, $password) = @_;
    return $username eq 'username' && $password eq 'password';
}

MyApp.pm(抜粋)

package MyApp;

use Moose;
use namespace::autoclean;

use Catalyst::Runtime 5.80;
                                                                                                                                                    
use Catalyst;
extends 'Catalyst';

our $VERSION = '0.01';

__PACKAGE__->config('Plugin::ConfigLoader' =>
                    {file => "$ENV{CATALYST_HOME}/aquos-web.yml"});

our @plugins = qw/                                                                                                                                                                 
                     ConfigLoader                                                                                                                                                  
                     Unicode                                                                                                                                                       
                     Unicode::Encoding                                                                                                                                             
                     Static::Simple                                                                                                                                                
                 /;

if ("$ENV{CATALYST_DEBUG}") {
    push(@plugins, 'Log::Colorful');
    push(@plugins, 'StackTrace');
}
                                                                                                                                                           
__PACKAGE__->setup(@plugins);

Emacsでsimplenote-modeを使ってみる。

2011-01-23T01:25:05Z

最近スマートフォンの性能が上がって、ほとんどPCを開かなくても済むようになった。そうなっていくとスマートフォンとの相性がいいサービスばかり利用するようになってくる。

DropboxやEvernoteはもちろん使っているが、スマートフォンではどちらも扱いたいデータをダウンロードしてから編集するとプロセスを踏むので、気軽に編集、更新という使い方はしにくかった。

気軽にテキストデータだけを扱い、Emacsから扱えるサービスを探していたのだが、simplenoteというテキスト情報のみを扱うクラウド的なサービスがあったので使ってみた。

simplenote

http://simple-note.appspot.com/

simplenote.el

https://github.com/cefstat/simplenote.el

まだ書きかけの文章やプログラムのコードの一部などを書きためておいて、ある程度完成したらEvernoteなどに保存している。

色々なメモをEmacsからsimplenoteに直接書き込め、それがPCやスマートフォンからも簡単に閲覧、編集、同期ができるということでしばらく使ってみたのだが、simplenoteのサーバーと手動で同期しないといけないので、それを忘れてしまうと意味が無い。

やはりDropboxのように同期することを意識しないでできるようでないと。

そこで、simplenoteでメモをとっているときに、bufferをsaveしたらsimplenoteのサーバーと同期するようにしてみた。

大まかな処理の流れはこんな感じ。

(defun simplenote-sync-after-save ()
  "If there is the buffer on simplenote-directory, sync the buffer to simplenote."
  (interactive)
  (when (simplenoteを使っている時)
    (simplenoteの同期処理)
    その他の処理...
    ))

通常simplenote-modeでsimplenote上のノートを扱っているときは、simplenote-directory/notes/以下にbufferを作成し、それを編集している。

simplenoteとの同期はsimplenoteのbufferを扱っているときのみ同期して欲しいので、それを判断する条件として現在のディレクトリがsimplenote-directory(初期設定値は "~/.simplenote")にマッチするかどうかで判断することにする。

(string-match simplenote-directory default-directory)

また、simplenoteの同期処理は(simplenote-sync-notes)なので、上記を踏まえてlispで書くとこうなる。

(defun simplenote-sync-after-save ()
  "If there is the buffer on simplenote-directory, sync the buffer to simplenote."
  (interactive)
  (when (simplenoteを使っている時)
    (simplenoteの同期処理)
    その他の処理...
    ))

ちなみに新しくノートを作ったときは、"note-[0-9]+"という名前のbufferをsimplenote-directory/new/以下につくる仕様になっている。このままだとsaveする度に新しいノートを追加してしまうので、その時は同期したあとにbufferを消去して、simplenote-browseを呼び出すようにする。

simplenoteの新規ノートのディレクトリの変数を定義して

(let (simplenote-new-note-dir)
  (setq simplenote-new-note-dir (concat (file-name-as-directory simplenote-directory) "new")))

--> 初期設定値では"~/.simplenote/new"

現在のディレクトリが新規ノートのディレクトリにマッチするかどうかを判断して、マッチする場合はbufferを消去後、simplenote-browseを呼び出す。

(when (string-match simplenote-new-note-dir default-directory)
  (kill-buffer (get-buffer (current-buffer)))
  (simplenote-browse))

最終的にはこのように。

(defun simplenote-sync-after-save ()
  "If there is the buffer on simplenote-directory, sync the buffer to simplenote."
  (interactive)
  (when (string-match simplenote-directory default-directory)
      (simplenote-sync-notes)
      (let (simplenote-new-note-dir)
        (setq simplenote-new-note-dir (concat (file-name-as-directory simplenote-directory) "new"))
        (when (string-match simplenote-new-note-dir default-directory)
          (kill-buffer (get-buffer (current-buffer)))
          (simplenote-browse)))))

あとはafter-save-hookに引っ掛けてしまえば、完成。

(add-hook 'after-save-hook 'simplenote-sync-after-save)

これでsimplenoteのサーバーと同期することを意識しないでメモをどんどん取っていける環境ができた。

ドコモコネクションマネージャー

2009-09-17T12:19:57Z

Snow Leopardにはまだ対応してないみたい・・・。
起動してもちゃんと動かないし、新規でインストールもできない。

ただし、過去のドライバーなどの動作は問題ないようなので、環境設定のネットワークの項目で直接つなげば問題ないようだ。

ドコモコネクションマネージャーでつなげていると、アカウント名とパスワードは空白になっているが、プロバイダのアカウント情報を入れると手動で接続ができる。

Catalyst 5.7x on Snow Leopard

2009-09-10T13:11:26Z

MacBookでCatalystの開発をしていて、Snow Leopardにアップグレードしたら、案の定手間取った。

本番環境は下記の通り。

OS: i386 GNU/Linux
Perl: v5.8.x built for i686-linux
Aplication Server : Apache/2.2.x (Unix) with mod_perl 2.x
DB: PostgreSQL 8.x

なるべくこの環境に近い開発環境をSnow Leopardで作ろうと思ったが、なかなかうまくいかない・・・。

問題点を整理してみるとうまくいかない原因は、

・デフォルトで64bitでコンパイルされている、またはコンパイルしてしまうので、アーキテクチャがそろわないため、不具合が起きる
・CPANのモジュールが意図せずバージョンがあがってしまう
・Universal仕様でコンパイルされていると、Dinamicにlinkする場合にどのアーキテクチャ用にすべきかわからずに停止してしまう

などなど。64bitへの布石がウリであるSnow Leopardならではの不具合。

解決の方向性としては、
1. 関連するものをすべてi386, 32bitに統一する
2. CPANのモジュールを本番環境と同じバージョンに保持する

っと決めるのは簡単なのだが、これがまたなかなか大変・・・。
まずは、Perl。

デフォルトのPerlは5.10.0で、しかも64bitでモジュールをコンパイルしてしまう。

$ file `which perl`
/usr/bin/perl.org: Mach-O universal binary with 3 architectures
/usr/bin/perl.org (for architecture x86_64):    Mach-O 64-bit executable x86_64
/usr/bin/perl.org (for architecture i386):      Mach-O executable i386
/usr/bin/perl.org (for architecture ppc7400):   Mach-O executable ppc

今回はバージョンを本番環境とあわせるため、5.8.xを使用したい。/usr/binには、perl5.10.0とperl5.8.9も用意されているのだが、

$ file /usr/bin/perl5.8.9
/usr/bin/perl5.8.9.org: Mach-O universal binary with 2 architectures
/usr/bin/perl5.8.9.org (for architecture i386): Mach-O executable i386
/usr/bin/perl5.8.9.org (for architecture ppc7400):      Mach-O executable ppc

となっているため、CPANのモジュールをコンパイルする際に、

Can't load 'lib/auto/File/Glob/Glob.bundle' for module File::Glob: dlopen(lib/auto/File/Glob/Glob.bundle, 1): no suitable image found.  Did find:
        lib/auto/File/Glob/Glob.bundle: mach-o, but wrong architecture at lib/XSLoader.pm line 73.
 at lib/File/Glob.pm line 96
Compilation failed in require at installperl line 133.
BEGIN failed--compilation aborted at installperl line 133.
make[1]: *** [install.perl] Error 255
make: *** [install] Error 2

というようになってしまう。もしSnow Leopard付属のPerlを利用する場合は、

$ cd /usr/bin
$ sudo lipo ./perl5.8.9 -thin i386 -output ./perl.5.8.9.i386
$ sudo mv perl{,.org}
$ sudo ln -s ./perl.5.8.9.i386 ./perl

もしくは

$ sudo cat > /usr/bin/perl5.8.9.i386
#!/bin/sh
/usr/bin/arch -i386 /usr/bin/perl5.8.9
^D
$ sudo chmod 755 /usr/bin/perl5.8.9.i386
$ sudo ln -s /usr/bin/perl5.8.9.i386 /usr/bin/perl

というように、i386のみのバイナリにしておく。

自前でPerlを入れる場合は、/usr/bin/perl5.8.9 -Vの出力を参考に、

$ sh ./Configure ¥
    -ds -e ¥
    -Accflags="-arch i386 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include" ¥
    -Aldflags="-arch i386 -L/usr/local/lib" ¥
    -Alddlflags="-arch i386 -bundle -undefined dynamic_lookup -L/usr/local/lib"
$ make; make test
$ sudo make install

i386 32bitバージョンのみのバイナリを作成しておく。

$ file /usr/local/bin/perl
/usr/local/bin/perl: Mach-O executable i386

Snow Leopard付属のApacheは例のごとくUnivarsalで、デフォルトが64bitで起動する・・・。

$ file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 3 architectures
/usr/sbin/httpd (for architecture x86_64):  Mach-O 64-bit executable x86_64
/usr/sbin/httpd (for architecture i386):    Mach-O executable i386
/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc

Apacheも同様にi386 32bitバージョンを作成するか、lipoコマンドで32bitバイナリを作成する。
自前でコンパイルする場合は、CFLAGSとARCHFLAGSを指定するとよい。

$ CFLAGS="-arch i386" ARCHFLAGS="-arch i386" ¥
./configure ¥
     --prefix=/usr/local/apache2 ¥
     --enable-module=so ¥
     --enable-proxy ¥
     --enable-dav ¥
     --enable-dav-fs ¥
     --enable-dav-lock ¥
     --enable-rewrite ¥
     --with-included-apr ¥
     --enable-ssl ¥
     --with-ssl=../openssl-$(OPENSSL_VERSION) ¥
     --enable-suexec ¥
     --with-suexec-caller=$(APACHE_USER) ¥
     --with-mpm=prefork ¥;
     make;
$ sudo make install

fileコマンドで確認。

$ file /usr/local/apache2/bin/httpd
/usr/local/apache2/bin/httpd: Mach-O executable i386

mod_perlも32bit版のApacheで。

$ perl Makefile.PL ¥
MP_APXS=/usr/local/apache2/bin/apxs; ¥
make; sudo make install

$ file /usr/local/apache2/modules/mod_perl.so
/usr/local/apache2/modules/mod_perl.so: Mach-O bundle i386

DBもCFLAGSとARCHFLAGSを同様に指定してコンパイルするか、バイナリ版を利用する場合は、fileコマンドで32bitバージョンかどうか確認すること。
ちなみに、PostgreSQLは下記のようにした。

$ ARCHFLAGS='-arch i386' ¥
CFLAGS='-arch i386' ¥
PERL=/usr/bin/perl ¥
./configure ¥
--prefix=/usr/local/pgsql ¥
--with-perl ¥
--with-pam ¥
--with-bonjour ¥
--with-libxml ¥
--enable-debug ¥

ここまでで、必要なすべての物がi386、32bitバージョンでそろうはず。

CPANモジュール。これが一筋縄ではいかない。まずバーションをあわせるため、本番環境の.cpanディレクトリをローカルにコピーし、ミラーを作成しておく。モジュールのダウンロード先をローカルのミラー二向ければ、理論上は同じバージョンでそろうはず。

$ mv .cpan ~/cpan
$ sudo cpan
> o conf urllist unshift file:///path/to/cpan/sources/
> o conf commit

o confコマンドで、urllistがローカルに置いたミラー先に向いていることを確認し、install Task::Catalystすればよいのだが、上記の設定で指定しても、あくまでも一次参照先でしかないので、ちょっと気を許すとftp.cpan.orgに取りにいってしまう。

そのため、ネットに接続しない環境にしておき、モジュールをインストールするほうがよい。たとえばHoge::Fugaというモジュールをインストールする場合、下記のような優先順位でインストールするとよい。

> install Hoge::Fuga
> install H/HF/HOGEFUGA/Hoge-Fuga.tar.gz

これでもできない場合は、しょうがなくcpan.orgからダウンロードする。tar玉の指定が大変なので、下記のようにリストを作っておいて、grepすると楽。

$ find /path/to/cpan -name '*.tar.gz' | sed -e 's!/path/to/cpan/sources/authors/id/!!' > cpan.txt
$ grep Hoge cpan.txt

理論上バージョンがそろうはずなのだが、実際にやってみるといつのまにかCatalyst::Runtimeが5.8にあがっていたりする・・・。そういう場合は、

> install M/MR/MRAMBERG/Catalyst-Runtime-5.7014.tar.gz

というように、強引に上書きするしかない。

Snow Leopardならではのトラブル。あとから思いかえすと簡単なことなんだけどねぇ・・・。

Apache2がMac OS X 10.5.5 アップデートでおかしくなった件

2008-10-11T00:52:53Z

Mac OS X 10.5.5 アップデートを当てた後、Catalystで動かしていたアプリケーションが動かなくなった・・・。

いつかまとめてその辺の環境は書いていくつもりだけど、もともとMac(Leopard)に入っていたApache2にmod_perlをいれて、下記のURLの通りに32bitのバイナリを作って運用していたのだが、

Leopard で PHP5 を再構築できなかった話

どうやら64bitバージョンに置き換えられていたようで、再度作り直すはめに・・・・。
アップルのサイトにはApache2についての記述は全くないので、少しハマった。

Mac OS X 10.5.5 アップデートについて

Emacs org-mode

2008-04-11T14:18:47Z

普段文章を書くときには、Emacsのoutline-modeを使っていて、内容はWikiにまとめる、という流れで情報はまとめていた。

WikiはPuki-wikiを使っているので、見出しがout-lineモードの*(アスタリスク)と共通。
特に問題は感じていなかったのだが、ショートカットをど忘れしたので、ググっていたら見つけたのがorg-mode。

Org-Mode Homepage
Org-mode is a mode for keeping notes, maintaining ToDo lists, and doing project planning with a fast and effective plain-text system.

普段文章を書くときに必要な要素といえば、だいたい以下のようなものがあれば事足りる。

見出し
表
強調
リンク
引用

見出し

見出しはPukiwikiの見出しと同じ、*(アスタリスク)なので都合がいい。
見出しの開閉はTABキーで行う。

表

これはみてもらうしかないのだが、区切りは「|-」をつかう。
その後は、「|」で区切るのだが、入力が終わると自動で整形してくれる。

残りは次回・・・・

FeedBurnerをTypePadに導入したが

2008-03-22T14:42:59Z

TypePadにて、feedburnerを導入する際のやり方はFeedBurnerに説明があるのだが、

FeedBurnerヘルプTypePadにフィードフレアを導入する手順
TypePadにフィードフレアを導入する手順 FeedBurnerとTypePadは驚く程親和性が高く、FeedFlareのブログへの導入はこれ以上ない程簡単なものとなっています。

その通りにやった結果がこちら・・・・。

orz....

説明ではMain Index Templateのentry-list-stickyに追加するようになっている。 entry-list-stickyは下記のような構造になっていて、

				 
<!-- entries -->
<MTBlogIfHasSticky>
    <MTBlogStickyEntry>
			Sticky（いつも上に表示するもの）の内容
    </MTBlogStickyEntry>
</MTBlogIfHasSticky>
<MTEntries>
    <MTEntryIsSticky>
			通常のエントリーの内容
  </MTEntryIsSticky>
</MTEntries>

そこのフッターの部分に下記のようなコードを埋め込め、と書いてあるけど、


<MTEntries>
<script src="http://feeds.feedburner.jp/YOUR-FEED-URI-HERE?flareitem=<$MTEntryPermalink$>" type="text/javascript"></script>
</MTEntries>

エントリーごとに繰り返すタグである<MTEntries>の中でもう一度繰り返すのだから、考えてみれば当たり前の結果。
どう考えてもヘルプの内容がよくないと思う・・・。

単純に<MTEntries>を抜いて、stickyと普通のエントリーのfooterに記述しまえばいい。

これでトップページのすべての記事ごとににfeedflareが出力される。

すべてのページのエントリーにfeedflareを埋め込むとなると、もう一手間必要。

残りのページは下記のようになっている。

Category Archives......カテゴリーから参照した場合のページ
DateBased Archives.....日や月別アーカイブから参照した場合のページ
Individual Archives....個別のページのリンクから参照した場合のページ
Pages..................Webページ

それぞれのfooter部分に

	
<script src="http://feeds.feedburner.jp/YOUR-FEED-URI-HERE?flareitem=<$MTEntryPermalink$>" type="text/javascript"></script>

のコードを埋め込めば、ページすべてにfeedflareが出現する。

この方がRSSの出力結果に近いと思う。

RSSフィードをFeedBurnerへ

2008-03-05T12:08:13Z

RSSフィードをFeedBurnerに委譲しようと思う。

他のBlog等でも紹介されているように、下記のような理由です。

RSSフィードへのトラフィックの軽減
Movable TypeでのRSSフィード作成の負荷軽減
フィードの購読者などの情報の把握

手順としては、下記のような手順になる。

FeedBurnerへの登録
RSSフィードの生成方法の変更
RSSフィードへのアクセスをFeedBurnerへ転送

FeedBurnerへの登録

Feedburnerでアカウントを作成し、Feedburner側へはfeedburner.xmlを送信するようにする。

Movable Type側で、Atomを生成しているテンプレートの生成ファイル名を変更し、保存、再構築する。

念のため、生成したatomがちゃんと読めるか、ブラウザーでアクセスし、問題なければFeedburner側の設定情報を更新する。

RSSフィードの生成方法の変更

Movable Type 4.1では、RSSの作成部分は「テンプレートモジュール」の「ヘッダー」の最初の方、<mt:setvatblock>タグの部分になる。

<mt:setvarblock name="html_head" prepend="1">
    <MTIf name="main_template">
<link rel="alternate" type="application/atom+xml" title="Atom" href="<$MTLink template="atom"$>" />
<link rel="alternate" type="application/rss+xml" title="RSS" href="<$MTLink template="rss"$>" />
        <MTUnless name="main_index">
<link rel="start" href="<$MTBlogURL$>" title="Home" />
        </MTUnless>
<$MTCCLicenseRDF$>
    </MTIf>
</mt:setvarblock>

今回の場合、AtomとRSSの両方をFeedBurnerに変更するため、

<mt:setvarblock name="html_head" prepend="1">
    <MTIf name="main_template">
<link rel="alternate" type="application/atom+xml" title="Atom" href="http://feeds.feedburner.jp/tf_blog" />
<link rel="alternate" type="application/rss+xml" title="RSS" href="http://feeds.feedburner.jp/tf_blog" />
        <MTUnless name="main_index">
<link rel="start" href="<$MTBlogURL$>" title="Home" />
        </MTUnless>
<$MTCCLicenseRDF$>
    </MTIf>
</mt:setvarblock>

に変更する。Feedburner側でRSSとAtomの両方の形式に対応してくれるので、同じものを指定している。

Movable TypeはRSD、RSS、Atomの3種類のフィードをインデックステンプレート再構築時に生成しているので、RSDとRSSは生成しないようにチェックを外しておく。

RSSフィードへのアクセスをFeedBurnerへ転送

Webサーバー側でRSSフィードへのアクセスをFeedBurnerへ転送するのだが、Apacheを使っているのでmod_rewriteで対応する。

で、この処理をどこでやるのかが悩ましい・・・。

Apacheの設定ファイル側で指定する。
.htaccessで指定する。

上記のどちらでもできるが、サーバー管理者の視点から考えると、Rewriteルールをみるのにディレクトリの.htaccessにまとめられても見逃す可能性があるので、設定ファイルで指定するのがいいでしょう。

ちなみに、設定ファイルは以下のように分けています。整理整頓は大事です・・・。

$APACHE_ROOT/conf                       Apache全体の設定、読み込む追加ファイルの指定
                 /conf.d                読み込むモジュールなどの個別の設定
                        /virtualhost    Virtural Host毎の設定

設定ファイル側に下記のように設定し、apachectl configtestでエラーがないか確認して、stop & start。

RewriteEngine on
RewriteRule ^/tf/index\.rdf$ http://feeds.feedburner.jp/tf_blog [R=permanent,L]
RewriteRule ^/tf/index\.xml$ http://feeds.feedburner.jp/tf_blog [R=permanent,L]
RewriteRule ^/tf/atom\.xml$  http://feeds.feedburner.jp/tf_blog [R=permanent,L]

Redirect時に恒久的に移動した旨を伝えてもらうために、permanentを指定する。

ちなみに、こういう感じの返答を返します。

$ telnet blog.on-net.jp 80
Trying 59.106.25.213...
Connected to blog.on-net.jp.
Escape character is '^]'.
GET /tf/index.xml HTTP/1.0

HTTP/1.1 301 Moved Permanently
Date: Wed, 05 Mar 2008 14:07:49 GMT
Location: http://feeds.feedburner.jp/tf_blog
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved <A HREF="http://feeds.feedburner.jp/tf_blog">here</A>.<P>
</BODY></HTML>
Connection closed by foreign host.

期待通りの動作をしているのが確認できる。

TypePadでのSitemapの作成

2008-03-04T15:13:57Z

仕事で使っているTypePadでは、Sitemapはナレッジベースに載っているものをすこし手を加えたものを利用することにした。

しかし、ここでトップレベルのSitemapに問題が発生。

現状、下記のような構成になっているのだが、

example.domain /corp/           本社のブログ
              |
              +/branch_A/       支店Aのブログ
              |
              +/branch_B/       支店Bのブログ
              |
              .
              .
              .

このドメインは本社のブログに割り当てているのだが、TypePadの仕様上ブログはサブディレクトリ以下に作ることが望ましい、とのことなので、corpディレクトリ以下に作っている。

インデックステンプレートを作成すると、corpディレクトリ以下に作成されてしまい、トップレベルのsitemapが自動生成されない。また、作成されたとしても、各支店のsitemap.xmlをどうやって読んでもらうようにすればいいのか。

まあ、こういうときの基本は本家のドキュメントをしっかりと読む、ということにつきる。

sitemaps.org - プロトコル
サイトマップインデックスファイル (複数のサイトマップファイルのインデックス) を使用する場合

つまり、こう記述すればよいわけだ。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   /* 本社のサイトマップ */
   <sitemap>
   <loc>http://example.dmain/corp/</loc>
   </sitemap>   
   /* 支店Aのサイトマップ */
   <sitemap>
   <loc>http://example.dmain/branch_A/</loc>
   </sitemap>   
   /* 支店Bのサイトマップ */
   <sitemap>
   <loc>http://example.dmain/branch_B/</loc>
   </sitemap>   
   .
   .
   .
</sitemapindex>

トップレベルのsitemapは各ブログが自動生成するsitemap.xmlへのポインタだけの役割に徹する、各ブログのsitemap.xmlはTypePadが更新の旅に自動生成するため、最新の状態が保てるという仕組みになる。

あとはrobots.txtにサイトマップの位置を記述して、各検索エンジンのクローラーに教えてあげればよい。

The Web Robots Pages
About /robots.txt In a nutshell Web site owners use the /robots.txt file to give instructions about their site to web robots; this is called The Robots Exclusion Protocol.

こんな感じの内容になる。

$ cat ./robots.txt
User-agent: *

Sitemap : http://example.domain/sitemap.xml

Google Webmaster ToolsのURLの合計値が、支店のsitemap.xmlで記述されたURLの合計になっていることを確認できる。

数時間後にはGoogleのクローラーがきて、いろいろ収集してくれる。

Movable TypeでのGoogle Sitemapの自動生成

2008-03-03T09:01:06Z

Blogも書いてみたことだし、SEO対策も研究してみるかと思い立ち、Googleを調べてみると、

ウェブマスター向けガイドライン
ウェブマスター向けガイドライン下記のガイドラインに沿ってサイトを作成すると、Google のインデックスに登録されやすくなります。ガイドラインでは、Google のインデックスから完全に削除されるか、ペナルティが科せられる可能性のある不正なサイトについて説明しています。ペナルティが科せられたサイトは、Google.co.jp や Google のパートナーサイトの検索結果に表示されなくなることがあります。 * デザイン、コンテンツ、および技術に関するガイドライン * 品質に関するガイドラインサイトの準備ができたら * 他の関連するサイトをリンクします。 * 下記の URL から Google に送信します。 http://www.google.co.jp/addurl.html * Google ウェブマスターツールを使用してサイトマップを送信します。 Google では、サイトマップを使用してサイトの構造を認識し、ウェブページを検出しやすくします。 * 必要なすべてのサイトにサイトが公開されたことを連絡します。 * Open Directory プロジェクト、Yahoo!、その他の業界専門サイトなど、適切なディレクトリにサイトを登録します。

GoogleのSEO対策として、推奨されるガイドラインでは、URLを登録した後にサイトマップなるものを送信する必要があるらしい・・・。

サイトマップとは何ですか。サイトマップが必要なのはなぜですか。
サイトマップを使用すると、サイトの追加情報を Google に送信して、通常のウェブクロール機能をさらに強化することができます。サイトマップにより Googleでサイトのより多くのページをより迅速にクロールできますが、サイトマップの URL が Google のインデックスに追加されるかどうかは保証できません。サイトマップを送信することで、サイトにとってデメリットとなることは一切ありません。

へぇ〜、しばらくこの分野から離れていたので浦島状態です・・・orz。

Google ウェブマスターツール
サイトマッププロトコルを使うと、ウェブサイト内のクロールさせたい URL を検索エンジンに知らせることができます。サイトマッププロトコルを使用した場合は、サイトの URL リストを含む簡単な形式の XML ファイルでサイトマップを作成できます。このプロトコルは高い拡張性を持つため、どのような規模のサイトでも使用できます。また、最終更新日、更新頻度、URL の優先度など、各 URL の詳細情報を含めることができるため、検索エンジンでサイトをより正確にクロールできるようになります。サイトマップは、ウェブサイトのインターフェースやリンクからアクセスできないページがある場合に特に効果的です。たとえば、検索フォームを使った場合にのみアクセスできるページがある場合は、サイトマップを作成して、検索エンジンに送信することができます。ここでは、サイトマップファイルの形式と、検索エンジンに提供するサイトマップファイルの配置場所について説明します。

ここに詳細に仕様が載ってるね。ここまでドキュメントが充実しているのはすばらしいなぁ。
あとはMovable Typeで自動生成されるようにやるだけですなぁ。

Google Webmaster Toolsにログインし、「サイトを追加」の部分に目的のサイトのURIを入力し、コンテンツを識別するキーを生成する。

Moovable Typeで、テンプレートモジュールを作成し、Metaタグの中身を追加。
ヘッダーモジュール内で、<$MTInclude module="モジュール名"$>で呼び出すようにする。

ヘッダーモジュールに直接書いてもいいけど、メンテナンス性や可読性を考えると面倒だけど参照するやり方の方がわかりやすい。

再構築してサイトに反映した後に確認ボタンを押すと、下記のような画面になりGoogle側に更新の情報がいく。これによって、クローラーに対して詳細な情報がいくようだ。

続いて、Movable Type側で自動でサイトマップが作成されるようにしなければならない。

Movable Typeのテンプレートタグリファレンスを確認しながら、以下のようなサイトマップのひな形を作成していく。

<MTほげほげ lastn="9999">
    <loc>文書のURI</loc>
    <priority>プライオリティ</priority>
    <changefreq>更新頻度</changefreq>
    <lastmod>最終修正日をW3C Datetime形式で</lastmod>
</MTほげほげ>

っていう感じで作っていけばよさそう。

注意するようなところとしては、

W3c Datetimeは原文を見れば一目瞭然。
MTほげModifiedDateの出力フォーマットだが、下記のどちらのアトリビュート指定でも大丈夫だった。

<$MTほげModifiedDate format="%Y-%m-%dT%H:%M:%S+09:00"$>
<$MTほげModifiedDate format_name="iso8601"$>

URIはファイル名に平気で日本語をつけてしまう担当者がいるかもしれないリスクを考慮して、encode_xmlのアトリビュートを指定しておく。

<?xml version="1.0" encoding="UTF-8"?>
<urlset
  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9
  http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd">
  /* Title */
  <url>
    <loc><$MTBlogURL encode_xml="1"$></loc>
    <priority>1.0</priority>
    <MTEntries lastn="1" sort_by="modified_on">
      <lastmod><$MTEntryModifiedDate format_name="iso8601"$></lastmod>
    </MTEntries>
  </url>
  /* Category  */
  <MTCategories>
    <url>
      <loc><$MTCategoryArchiveLink encode_xml="1"$></loc>
      <changefreq>weekly</changefreq>
      <priority>0.5</priority>
    </url>
  </MTCategories>
  /* Entry */
  <MTEntries lastn="9999">
    <url>
      <loc><$MTEntryPermalink encode_xml="1"$></loc>
      <changefreq>daily</changefreq>
      <lastmod><$MTEntryModifiedDate format_name="iso8601"$></lastmod>
      <priority>0.8</priority>
    </url>
  </MTEntries>
  /* Web pages */
  <MTPages lastn="9999">
    <url>
      <loc><$MTPagePermalink$>
        <$MTPagePermalink encode_xml="1"$></loc>
      <changefreq>weekly</changefreq>
      <lastmod><$MTPageModifiedDate format_name="iso8601"$></lastmod>
      <priority>0.5</priority>
    </url>
  </MTPages>
</urlset>

あとはMovable Typeのほうでインデックステンプレートを新規作成し、「出力ファイル名」に「sitmap.xml」などと指定して、保存と再構築をすれば生成される。

Google Webmaster Toolsの方で、「確認」ボタンを押して確認すると登録される。

メニューのサイトマップのリンクをたどり、「サイトマップを追加」画面で先ほど生成したxmlを指定する。

あとはGoogle側からクロールしてくるまでじっと待つだけ。

しばらく様子を見てみよう。

Polipoを導入

2008-03-01T12:10:57Z

Drift Diary12: dolipoで更に加速するインターネット : polipo proxy用GUIアプリを作りました。
ごく一部で話題になり初めてるようですが、polipoは個人用にネットワークの高速化に特化したプロキシーサーバーで、実際試してみたところ、光の自宅回線ですら、mixiやFlickrが劇的に快適になったので、感動のあまり、Mac用GUIを作成しちゃいました。

ということなので、polipoを導入してみました。

Mac OS用のGUIはこちらのページに任せるとして、polipoのインストールの方を・・・。

Polipo -- a caching web proxy
Polipo is a small and fast caching web proxy (a web cache, an HTTP proxy, a proxy server). While Polipo was designed to be used by one person or a small group of people, there is nothing that prevents it from being used by a larger group.

tarballをとってきて、解凍した後に、

$ make all
$ sudo make install

であっさりインストールできてしまう。

このままだと再起動時にサービスが起動しないので、ドキュメントを確認してみる。

System Startup Programming Topics: Creating a Startup Item
The /System/Library/StartupItems directory is reserved for startup items that ship with Mac OS X. All other startup items should be placed in the /Library/StartupItems directory. Note that this directory does not exist by default and may need to be created during installation of the startup item.

しばらくMacを使っていない間に、launchdで管理するようになっていたとは・・・。
lookupdとかは、過去の遺物ですか。

気を取り直して、起動スクリプトを書いてみる。

$ sudo mkdir /Library/StartupItems/Polipo
$ cat > /Library/StartupItems/Polipo
#!/bin/sh

. /etc/rc.common

PATH=$PATH:/usr/local/bin; 

# The start subroutine
StartService() {
#    polipo daemonise=true logFile="/var/log/polipo.log"
    polipo logFile="/var/log/polipo.log" &amp;

}

# The stop subroutine
StopService() {
    killall polipo
#    killall -9 mydaemon
}

# The restart subroutine
RestartService() {
#    killall -HUP polipo
    StopService
    StartService
}

RunService "$1"
^D

$ cat > /Library/StartupItems/Polipo/StartupParameters.plist 
<plist version="1.0">
<dict>
    <key>Description</key>
    <string>a caching web proxy</string>
    <key>Messages</key>
    <dict>
        <key>start</key>
        <string>Starting Polipo</string>
        <key>stop</key>
        <string>Stopping Polipo</string>
    </dict>
    <key>OrderPreference</key>
    <string>None</string>
    <key>Provides</key>
    <array>
        <string>Polipo</string>
    </array>
    <key>Uses</key>
    <array>
        <string>Network</string>
    </array>
</dict>
</plist>
^D

$ chmod 755 /Library/StartupItems/Polipo/Polipo

操作はSystemStarter経由でするのが正しいらしい。

$ /sbin/SystemStarter start "Polipo"
$ ps awx|grep polipo
53075   ??  S      0:01.28 polipo logFile=/var/log/polipo.log
53148 s000  R+     0:00.00 grep polipo

$ sudo /sbin/SystemStarter restart "Polipo"

$ ps awx|grep polipo                  
53153   ??  S      0:00.00 polipo logFile=/var/log/polipo.log
53155 s000  S+     0:00.00 grep polipo

後はdolipoを起動していれば、ネットワークが切り替わったらpolipoのdaemonを再起動してくれるらしい・・・が、Dolipoがうまく動いていない。

RestartをしてもpolipoのPIDが変わっていない。普通に考えて、一般ユーザーがSuperユーザーのプロセスをコントロールできるとも思えない。

と、ここまで書いてて気がついた・・・。一般ユーザーであげればいいじゃん！

$ polipo &
[1] 528
 Disabling disk cache: No such file or directory
Established listening socket on port 8123.

$ ps awx|grep polipo
  528 s000  SN     0:00.00 polipo
  530 s000  R+     0:00.00 grep polipo

ここで、DolipoでRestartしてみる。

[1]  + done       polipo
$ ps awx|grep polipo
  535   ??  Ss     0:00.01 /Applications/dolipo.app/Contents/Resources/polipo -c config 
  537 s000  R+     0:00.00 grep polipo

DolipoはただのGUIのフロントエンドではなく、polipoを内蔵していたという落ちですか。

しかも、某データセンターで働いていたときに刷り込まれた、「再起動時にもちゃんとあがるよう起動スクリプトを設置して、再起動時にちゃんとdaemonが上がるか確認する」という鉄則が今でも抜けないらしい・・・。

今後の方針としては、

1. polipoはSystemStarter経由で起動し、ネットワークが切り替わったときに自動的にRestartさせる
2. 一般ユーザーでDolipoのパッケージ内のpolipoを使用する

が考えられるけど、1の方が好きだな・・・。ネットワークが切り替わる時のhookにあたるようなものを探さねば。

普通に考えればDolipoで何にも問題ないんだけど、

メニューバーが埋まるのが少し嫌
どうせならCUIで完結したい

という一般的でない理由のために、もう少しがんばってみようかな・・・。

Youtubeのダウン、の衝撃

2008-02-27T01:00:06Z

［WSJ］ YouTubeの世界的障害、原因はパキスタンの検閲を読んだとき、衝撃だった・・・。

詳細は、こちらに詳しく書いてるが、

Insecure routing redirects YouTube to Pakistan
In the case of YouTube and Pakistan Telecom, YouTube injected the address block 208.65.152.0/22 (208.65.152.0 - 208.65.155.255) in the Internet's routing tables, while Pakistan Telecom advertised the 208.65.153.0/24 (208.65.153.0 - 208.65.153.255) block. So even though YouTube's routing information was still there, packets would flow towards Pakistan Telecom because of the longest match first rule.

つまり、Youtube側がアドバタイズしている内容が、208.65.152.0/22、パキスタンの技術者が208.65.153.0/24を国内のネットワークだけにアドバタイズして、そのネットワークの通信を破棄して、Youtube側へのアクセスをブロックしようとした。

しかし、間違って外にもアドバタイズした結果、longest matchの法則により、208.65.153.0/22より208.65.153.0/24のほうが優先され、事実上のネットワークの乗っ取りが成立してしまった、という話。

A> ルーティングの設定の効率化を考えるとlongest matchだと思うけど、それって、結局インターネットが良心で成り立っているってことだよね。

B> そんなの前からわかってたことじゃん。

A> じゃあ、この記事に書いてあるようにルーティングの情報はフィルタリングして入れれば？

B> でも多くの管理者が自分のネットワークの情報を登録してないし。意味ないな・・・。

A> なら細かいネットワーク範囲でアドバタイズすれば？

B> いやいや、登録するレコードが多すぎて、経路の最適化の計算の負荷で反応できない→落ちたと判断した他のルーターが経路の再計算→ふりだしに戻る、の連鎖地獄でBフレッツのネットワークのルーターが落ちて障害になったじゃん・・・。

A> じゃあ、どうしろと・・・。

B> ・・・。

という内容が各地で話されたことだろう・・・・。
前々からわかっていたことだし、実際におこるとみんな思っていたこと。

でも、やっぱり実際おこると衝撃だよな・・・・。

Movable Typeの高速化・・・・(2)

2008-02-22T13:51:51Z

Apache 1.xの環境の再構築とDBの移行が完了したので、早速試してみる。

Movable Type を mod_perl 1.x で高速化する

とりあえず、Apache::Requestのインストールか・・・と、インストールしようとすると、

mod_perl 1.x ( < 1.99) is required at Makefile.PL line 34.

というエラーが・・・。Makefile.PLをみてみると、怪しい・・・。
多分他の人も引っかかっているなと思って、ググってみると@INCに
mod_perl2.pmがあると読み込んでしまい、判定されてしまうようだ。

最初はApache2環境だったからな・・・。気を取り直し look Apache::Request して、apxsとhttpdを指定して、Make install。
後はドキュメントを参考に設定をしてapachectl stop & start。

気になるスピードは、ひとりしか使っていないので早くなったとは思うがROIを考えるとかなり微妙な所か・・・。

モチベーションが落ちたので、mod_perlハンドラにするのは、また今度に。

Movable Typeの高速化・・・・

2008-02-18T01:55:01Z

Movable Typeのマニュアルを読んでいると、高速化のやり方が書いてある。

Movable Type を mod_perl 1.x で高速化する

mod_perl 1.xのみ対応ですか・・・・・。
Apache 2.xじゃだめなようだけど、別に2.xじゃないといけない訳でもないので、これを機会に入れ替えるか、と作業を始めたところ、apache, openssl, mod_ssl, mod_perlのインストールが済んだところで、気がついた・・・。

あれ、他のCMSで使っているphpも作り直し? うーん、それって、mysql, postgresql作り直し&すべてのテーブルのバックアップ、リストア祭り??・・・・orz。

やり始めると./configure オプションも見直したり、雪だるま式に作業が増えていく・・・。

Movable Typeの高速化はまだまだ先になりそう。