調べてみたところ Amazon Webサービス (ECS3) の応答メッセージ自体が文字化けしているようで、ちょっといかんともしがたい状況です。先方のシステム復旧待ちです。
15:32 追記: 直りました
]]>いずれ、フィードのURLも301で向こうに飛ばすかもしれませんが、とりあえずはフィードは現状維持させておきます。
]]>一方、はてなRSS は http://r.hatena.ne.jp/xmlrpc に ping することでクロール間隔を早めることができる。
この両者に ping を飛ばす場合、順番に気をつけないと、FeedBurner との同期が完了するまえに巡回君が来てしまう可能性があり、いや〜んなことになる、というのに気付きました。FeedBurner → はてなRSS の順番が正解。
ということでテスト中です。
あ、最近はnaoyaのはてなダイアリーの方をメインに更新していますので、こちらもよろしくお願いします。NDO::Weblogを今後どうするかは検討中。
]]>ということで、コメントでやりとりしていた話を ishinao さんがまとめています。とてもよくまとまっているので、御一読を。
あと、今回の件でMT に脆弱性が、という記事を書かれた方は、その後のフォローとしてこういった記事も一緒に引用あるいは参照として記載しておくと、周囲の人の理解が正しい方向へ向かうので有益ではないかと思います。
]]>というアナウンスが出ていてるのですが、これに関してメディアとか巷の blog で過剰に反応しているものが散見されます。
が、アナウンスで赤字で強調し指摘れてるところを良く読んでからも分かるとおり、これは Movable Type そのものの脆弱性ではないですし、そもそも脆弱性なのかどうかも怪しいという話です。
第三者が、Cookieの値を取得する。
Cookie の値を取得されたら、Movable Type に限らず大概のどんなブログ、どんなツールでも不正アクセスが可能です。(AtomAPIとログインパスワードが..とありますが、実際には Cookie を抜かれたらその Cookie を仕込んで mt.cgi そのものにログインが可能です。)
近頃の一般的なウェブアプリケーションでは Cookie によるログインのセッション保持というのをやるので、Cookie の値そのものがパスワードと同等の役割を持っています。それゆえ、(アプリケーションの欠陥で)Cookie が漏れるような事態は脆弱性と言えるでしょうが、今回の件は Movable Type に Cookie 漏洩の脆弱性が見つかったわけではないです。
Cookie を抜かれないために http から https にするとか、それはもう Movable Type の問題ではなくそのシステムを個人としてどうするかという問題ですね。
技術について詳しくない個人の方はともかくとして、メディアの人はもう少し考察してから記事を書くなりなんなりした方がよいんじゃないでしょうか。
追記
mt.cfg を隠さないとやばい、見たいな話にもなっています。確かに人に見せるような代物ではないので見えないように対処を行っておいたほうが良いとは思いますが、これも見えたからといってじゃあそのサイトが何か問題を突かれて云々かというとそういうものではないです。
mt.cgi のパスが知れてしまうと問題、という認識は間違いです。mt.cgi は普通コメントとかトラックバックとかの cgi と同じパスに置かれているのだし、HTML や rsd.xml の中身を見ればそんなものはすぐにでも分かります。そこにアクセスされたら危険というものはアクセスされないように任意の名前で隠せばセキュアという認識が間違っています。(この辺の語りは高木さんの役割かもｗ)
mt.cfg の中には、ログインに必要なパスワードであるとか、DB に接続するためのパスワード、それから Cookie の値を何らかの方法で知るための値が記述されているわけではないので、見られたからってサイトが不正アクセスの被害を被るわけではないのです。
見られたら危険、というものだったらそれを、一般のアクセスからは物理的に見れない場所におく、例えばウェブサーバがハンドリングしていないディレクトリに置くとか、それが適切な対処ですが、mt.cfg はパッケージの中ではウェブに公開される可能性のある領域にもともと置かれています。開発者側の判断は、特に mt.cfg が見られたからといって脆弱性が発生するわけではないという認識の元でしょう。見られたら気持ち悪いファイルではあるので、隠しておくに越したことはない、程度のものです。
この話に関しても Six Apart Japan の文書が誤解を招きやすい表現になっているという点は否めないですけれども。
]]>東工大の奥村研究室の研究成果である blogWatcher、その 2.0 が公開されています。なんというか、内部的に GETA から Lucene に変更されたなどの点もあるものの、外側のインタフェースが改良されていて、2.0 というより別物に近い印象。実用性を考えていろいろ変更したというのがよくわかります。
API があったり (OKUMURANK!) いろいろ面白いのですが、僕個人として一番これはいいと思ったのは、メインの blogWatcher ではなく blogWatcher の研究成果を利用して作られたなんでもRSSの方ですね。
名前のとおり(日付情報のあるサイトを)なんでもRSSに変換しちゃいますという代物で、ためしに僕が手HTMLで作っていたゲームサイト（オタい)のURLを突っ込んでみました。
その結果がこれ。正直かなりびっくりしました。HTMLをコピペしながら作ったものなので、規則性が若干崩れてるところがあったりするのに、その辺はちゃんと補正してかなり正確に記事を分割してRSSを生成しています。こりゃすげーや。
以前に東工大でblogWatcherのプレゼンを聴かせてもらったときに、その内部で利用しているコンテンツ・フィルタ (ページの日付情報やHTMLの規則性から、そのページがブログかどうかを判定し、かつデータ記事単位に分割するフィルタ) の仕組みを見せてもらって、これでなんでもRSSとか作れそうですねみたいなことをみんなでワイワイ言ってたんですけど、その成果物ですね、素晴らしいです。
早速色々使わせてもらいます。
]]>例えば、はてなブックマークは自分のブックマークにブックマークを追加するのに Bookmarklet を使うのですが、何か Bookmarklet の JavaScrpipt のコード側にバグがあったとか、機能を追加したいという場合に毎回アナウンスして Bookmarklet をセットアップし直してもらう必要があります。(今のところ、そういったことはないのですが。) ウェブアプリケーション、というかサーバーサイドアプリケーションの最大のメリットである、徐々に機能を追加していくというフローに、配布型の Bookmarklet の仕組みが合わないんですね。
それが悩ましいので、はてなブックマークの Bookmarklet は、それを実行した先でサーバーサイドのプログラムを呼び出して、そちら側になるべく機能を集中させるようにしています。
が、今日素晴らしい情報を発見。
bookmarkletを作るとき、IEでは500文字ちょい、Firefoxでは2000文字ぐらい(?)の文字数制限がある。また、作った後に一行にまとめたり、デバッグしたりも大変面倒。でもそれがとても簡単な方法でどうにでもなることをインターフェイス！インターフェイス！の人に教わった。
表題は文字数制限をなくす、ということなのですが、実際のコードは document.createElement で script エレメントを作ってやってそこで src で外部ファイルを読むようにしてやるというもの。
この方法を使えば、JavaScript のコードそのものをサーバー側に置いた Bookmarklet が作れます。素晴らしい。
Perl の O/R マッピングのデファクトは多分 Class::DBI で、Class::DBI と相性が良いテンプレートエンジンと言えば Template-Toolkit。という感じで、自然とモデルとビューに何を使うかは決まってきます。そこであとはコントローラ、というわけですが、Catalyst は主にそのコントローラの部分です。CDBI + TT なアプリケーション向けのコントローラですが、モデルやテンプレートは CDBI と TT に限定されてるわけではないので、別の組み合わせでも使えます。
と、いうことでちょっとお勉強がてらいじってみました。以下、そのメモというか解説です。Perl でウェブアプリケーション作りたいけど良いフレームワークはないかなあ、とお嘆きの方は一読していただければこれ幸い。
]]> 何はなくともまずは準備から。CPAN から Catalyst モジュールをインストールします。[naoya@colinux naoya]$ sudo perl -MCPAN -e 'install Bundle::Catalyst' [naoya@colinux naoya]$ sudo perl -MCPAN -e 'install Bundle::Catalyst::Everything'
これで Catalyst に必要なモジュールは全部入る...といいたいところですがデータベースに何を使うかによって、自動では入ってくれないものもいくつかあります。MySQL を使うなら Class::DBI::Loader::mysql、Class::DBI::mysql あたりを明示的にインストールする必要があるかも。(もちろん DBD::mysql も。)
普通ならここでいったんフレームワークのインストール作業は終えて、ウェブサーバーのセットアップとかに入るところなんですが、Catalyst にはデバッグ用の、コマンドラインから実行できる httpd が付属してくるのでその必要はないです。これが結構便利です。
さて、何を作ろうか...というところですがとりあえずお勉強目的なので qootas.org でも取り上げられている TinyURL っぽいものを作ってみました。qootas.org の記事では Catalyst のバージョン 4.34 を使っていますが、最新の 5.10 ではコントローラ周りの API が結構変わってたりするので、同じようなものを作るのでも調べごとが必要そうですし、題材としては良さそだった、ということで。(なので記事の中身は qootas.org のそれとかなり被っています。)
仕様としては
といったところです。本物の TinyURL は短縮URL の識別子にランダムな文字列を使っていますが、ここでは簡単のため http://.../23 といった感じで auto_increment な数値を使うことにしました。
あらかじめ、MySQL 上にこんな感じのテーブルを作成しておきます。データベース名は tinyurl、テーブル名は urlmap です。
mysql> desc urlmap; +-------+------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+------------------+------+-----+---------+----------------+ | id | int(10) unsigned | | PRI | NULL | auto_increment | | url | varchar(255) | | | | | +-------+------------------+------+-----+---------+----------------+
ここから Catalyst を使った開発に入ります。最初にウェブアプリケーションのパッケージ名を決めます。ここでは NDO::TinyURL としました。パッケージ名を決めたら、catalyst.pl を実行します。すると、各種ディレクトリや Helper スクリプトが生成されます。
[naoya@colinux naoya]$ catalyst.pl NDO::TinyURL created "NDO-TinyURL" created "NDO-TinyURL/script" created "NDO-TinyURL/lib" created "NDO-TinyURL/root" created "NDO-TinyURL/t" created "NDO-TinyURL/t/m" created "NDO-TinyURL/t/v" created "NDO-TinyURL/t/c" created "NDO-TinyURL/lib/NDO/TinyURL" created "NDO-TinyURL/lib/NDO/TinyURL/M" created "NDO-TinyURL/lib/NDO/TinyURL/V" created "NDO-TinyURL/lib/NDO/TinyURL/C" created "NDO-TinyURL/lib/NDO/TinyURL.pm" created "NDO-TinyURL/Build.PL" created "NDO-TinyURL/Makefile.PL" created "NDO-TinyURL/README" created "NDO-TinyURL/Changes" created "NDO-TinyURL/t/01app.t" created "NDO-TinyURL/t/02pod.t" created "NDO-TinyURL/t/03podcoverage.t" created "NDO-TinyURL/script/ndo_tinyurl_cgi.pl" created "NDO-TinyURL/script/ndo_tinyurl_fcgi.pl" created "NDO-TinyURL/script/ndo_tinyurl_server.pl" created "NDO-TinyURL/script/ndo_tinyurl_test.pl" created "NDO-TinyURL/script/ndo_tinyurl_create.pl"
次に、これは結構お約束な作業っぽいですが、Template-Toolkit (TT) をベースにしたビュークラスを作成します。といってもこれも Helper スクリプトを実行するだけ。
[naoya@colinux naoya]$ cd NDO-TinyURL/ [naoya@colinux NDO-TinyURL]$ script/ndo_tinyurl_create.pl view TT TT created "/home/naoya/NDO-TinyURL/script/../lib/NDO/TinyURL/V/TT.pm" created "/home/naoya/NDO-TinyURL/script/../t/v/tt.t"
引数には "view TT TT" としてます。(なんか他の人のを見てても TT TT としてるのが多かったので。) テンプレートエンジンに TT 以外の物を使う場合とかは "view MyViewer" とすると MyViewer.pm がスケルトンとして生成されるのでそこにコードを書いていくといいみたいです。
なお、この Helper で生成された NDO::TinyURL::V::TT クラスは Catalyst::View::TT を継承しているだけのクラスになります。Template-Toolkit で提供されている以上の機能をビューに追加したい場合とかは、このクラスにメソッドを定義していくと良いでしょう。
ビューの下準備はこれでおしまい。以降、ビューの開発は、コントローラを作りながらウェブアプリケーションの各アクションに合わせてテンプレートを書いていく作業になります。
次はモデルの作成です。通常 Class::DBI でモデルを作る場合は、データソースやテーブルのスキーマに合わせて、テーブル一つにたいして Class::DBI のサブクラスを一つ定義していく、ということをやりますが、Catalyst ではやはりここも Helper スクリプトにお任せできます。
[naoya@colinux NDO-TinyURL]$ script/ndo_tinyurl_create.pl model CDBI CDBI DBI:mysql:tinyurl nobody nobody created "/home/naoya/NDO-TinyURL/script/../lib/NDO/TinyURL/M/CDBI.pm" created "/home/naoya/NDO-TinyURL/script/../lib/NDO/TinyURL/M/CDBI" created "/home/naoya/NDO-TinyURL/script/../lib/NDO/TinyURL/M/CDBI/Urlmap.pm" created "/home/naoya/NDO-TinyURL/script/../t/m/cdbi_urlmap.t"
うーん、楽ちん。"model モデルのパッケージ名 モデルに使うクラス DSN [username] [password]" として実行します。まあ、Class::DBI を使うならお約束的に "model CDBI CDBI DBI:mysql:foobar user pass" でしょうか。
これで下準備は完了。作ったモデルを組み合わせてウェブアプリケーションを作成...つまりコントローラを作っていきます。コントローラのクラスは lib/NDO/TinyURL.pm です。スケルトンがあらかじめ生成されているので、それを書き換えていきます。
ちなみに、今回は / と /12345 と /make の3つしかアクションがないアプリケーションで、いずれも / 直下なので NDO/TinyURL.pm を編集していますが、一階層下って /foobar/action, /foobar/action2, /foobar/action3...なんてことをやる場合は
$ script/ndo_tinyurl_create.pl controller FooBar
として /foobar/ 以下のコントローラのスケルトンを生成し、lib/NDO/TinyURL/C/FooBar.pm を編集します。antipop2.0 - Catalyst で作る簡単 Web アプリケーション: Feed2JS 解説 にはその具体例が載ってます。
話がそれました。コントローラのコードはこんな感じになりました。バージョン 5.10 では sub action : Attribute とかしてメソッドを定義したりします。なんか Perl の Syntax 的に風変わりですが。この辺も詳しくは quootas.org : Catalyst入門: Actionの定義とその処理の流れ（前編） で解説されてたりします。
package NDO::TinyURL;
use strict;
use Catalyst qw/-Debug/;
our $VERSION = '0.01';
NDO::TinyURL->config(
name => 'TinyURL',
root => '/home/naoya/NDO-TinyURL/root',
templates => {
index => 'templates/index.tt',
make => 'templates/make.tt',
}
);
NDO::TinyURL->setup;
sub default : Private {
my ( $self, $c ) = @_;
$c->stash->{template} = NDO::TinyURL->config->{templates}->{index};
$c->forward('NDO::TinyURL::V::TT');
}
sub make : Global {
my ($self, $c) = @_;
my $url = $c->req->param('url') or $c->res->redirect('/');
$url = 'http://' . $url unless $url =~ /^http(?s):\/\//i;
my $map = NDO::TinyURL::M::CDBI::Urlmap->find_or_create({ url => $url});
$c->stash->{map} = $map;
$c->stash->{template} = NDO::TinyURL->config->{templates}->{make};
$c->forward('NDO::TinyURL::V::TT');
}
sub redirect : Regex('^(\d+)$') {
my ($self, $c) = @_;
my $map = NDO::TinyURL::M::CDBI::Urlmap->retrieve($c->req->snippets->[0]);
$map ? $c->res->redirect($map->url) : $c->res->redirect('/');
}
まず、/ にリクエストが来た場合を考えます。/ は default アクションになります。特に何もせずフォームのある画面を表示したいので、
sub default : Private {
my ( $self, $c ) = @_;
$c->stash->{template} = NDO::TinyURL->config->{templates}->{index};
$c->forward('NDO::TinyURL::V::TT');
}
として、$c->forward('NDO::TinyURL::V::TT') を実行します。$c は Context オブジェクトで、コントローラでは基本的にこの Context オブジェクトのメソッドを呼び出してほげほげ、ということをします。ここでは先に Helper スクリプトで用意したビュークラスに、処理の転送を行っています。
転送する前に $c->stash->{template} に、このアクション用のテンプレートファイルのパスをセットしています。なんか、テンプレートファイルのパスを stash に保存しておくというのがちょっと気持ちわるい気もしますが、そういうことみたいです。なお、stash や config にセットしておいた値はテンプレート側から自由にアクセス可能です。
/ 用のテンプレートは templates/index.tt と指定したので、それを用意します。実際の場所は root/templates/index.tt です。
<html> <head></head> <body> <h1>[% name %]</h1> <form action="make" method="post"> URL: <input type="text" name="url" size="30"> <input type="submit" value="tinyurl" type="submit"> </body> </html>
フォームがあるだけの画面です。[% name %] は TT のテンプレートタグで、TinyURL.pm の中で config にセットしておいた値を展開してます。
これで / は完了。
次は、URL が入力されたら短縮URLを作って画面に表示する /make です。
sub make : Global {
my ($self, $c) = @_;
my $url = $c->req->param('url') or $c->res->redirect('/');
$url = 'http://' . $url unless $url =~ /^http(?s):\/\//i;
my $map = NDO::TinyURL::M::CDBI::Urlmap->find_or_create({ url => $url});
$c->stash->{map} = $map;
$c->stash->{template} = NDO::TinyURL->config->{templates}->{make};
$c->forward('NDO::TinyURL::V::TT');
}
make : Global と書くと、/make に来たらこのアクションを呼びなさいという指示になります。Global 属性はこんな風に使います。ここでは Class::DBI の find_or_create メソッドで、入力された URL を urlmap テーブルに保存してます。あとは、stash にオブジェクトをセットしつつテンプレートを指定してビューに転送。
なんか url が入力されてなかったときは / に戻すということをやってますが、Catalyst::Plugin::FormValidator あたりを使ったほうが美しいかも。(Catalyst はエラーハンドリングに関する機能はフレームワークに組み込まれてないのかな、誰か教えて。)
root/templates/make.tt はこんな感じです。
<html> <head></head> <body> <h1>[% name %] created</h2> <p><a href="[% map.url %]" target="_blank">[% map.url %]</a> to <a href="/[% map.id %]" target="_blank">[% base %][% map.id %]</a></p> </ul> </body> </html>
最後に、/12345 に来たときにリダイレクトするアクション。
sub redirect : Regex('^(\d+)$') {
my ($self, $c) = @_;
my $map = NDO::TinyURL::M::CDBI::Urlmap->retrieve($c->req->snippets->[0]);
$map ? $c->res->redirect($map->url) : $c->res->redirect('/');
}
ここでは /make のように、アクションの名前は固定じゃなく変数である数値なのですが、このように Regex 属性を使うことでそれを実現できます。正規表現メモリに入れた変数($1) は Request オブジェクトの snippet メソッドで取り出せます。
これでアプリケーションは完成。Catalyst に付属の httpd でテストしましょう。
[naoya@colinux NDO-TinyURL]$ script/ndo_tinyurl_server.pl [Thu May 5 11:18:10 2005] [catalyst] [debug] Debug messages enabled [Thu May 5 11:18:10 2005] [catalyst] [debug] Loaded dispatcher "Catalyst::Dispatcher" [Thu May 5 11:18:10 2005] [catalyst] [debug] Loaded engine "Catalyst::Engine::HTTP" [Thu May 5 11:18:10 2005] [catalyst] [debug] Found home "/home/naoya/NDO-TinyURL/script/.." [Thu May 5 11:18:10 2005] [catalyst] [debug] Loaded tables "urlmap" [Thu May 5 11:18:11 2005] [catalyst] [debug] Loaded components .=----------------------------------------------------------------------------=. | NDO::TinyURL::M::CDBI | | NDO::TinyURL::V::TT | | NDO::TinyURL::M::CDBI::Urlmap | '=----------------------------------------------------------------------------=' [Thu May 5 11:18:11 2005] [catalyst] [debug] Loaded private actions .=-------------------------------------+--------------------------------------=. | Private | Class | |=-------------------------------------+--------------------------------------=| | /make | NDO::TinyURL | | /redirect | NDO::TinyURL | | /default | NDO::TinyURL | '=-------------------------------------+--------------------------------------=' [Thu May 5 11:18:11 2005] [catalyst] [debug] Loaded public actions .=-------------------------------------+--------------------------------------=. | Public | Private | |=-------------------------------------+--------------------------------------=| | /make | /make | '=-------------------------------------+--------------------------------------=' [Thu May 5 11:18:11 2005] [catalyst] [debug] Loaded regex actions .=-------------------------------------+--------------------------------------=. | Regex | Private | |=-------------------------------------+--------------------------------------=| | ^(\d+)$ | /redirect | '=-------------------------------------+--------------------------------------=' [Thu May 5 11:18:11 2005] [catalyst] [info] TinyURL powered by Catalyst 5.10 You can connect to your server at http://colinux:3000/
なにやらディスパッチ先はここがこうなってるとかいうステータスが色々出て、サーバーは localhsot の 3000 番にバインドしました。指示通りアクセスすると、
てな感じで画面が遷移し http://colinux:3000/2 にアクセスしたところちゃんとリダイレクトされました。めでたしめでたし。
まだ触りぐらいしか使ってないのですが、とりあえず Helper スクリプトと httpd が超ベンリ。最初引数がよくわかんなかったりしましたが、その辺はフレームワーク学習のためのコストのうちですね。慣れてくると Helper でセットアップ、コントローラとテンプレートをもりもり書いて、必要に応じてロジックをクラスにまとめて...というのの繰り返していくだけでお手軽にウェブアプリケーションを作ることができそうです。
フレームワークのアーキテクチャとしては、一人もしくは少人数向けのフレームワークかなあという印象です。今回正規表現でいじったように、URLとロジックのマッピングをコントローラでかなり柔軟にいじれて自由度が高いのは便利ですが、ちょっと自由度が高すぎるので、少人数ならよさそうだけど、と思った。大規模開発も可能でしょうけど、一番効果を発揮するのは Hacker な人が一人でどんどん作ってくケースかな。
今回ははてなで使っているはてなフレームワークとの比較のために勉強してみました。(アーキテクチャは Catalyst と結構違うんですが)はてなフレームワークは一人よりも少人数開発にフォーカスしたフレームワークで、もう少しプログラマに対する制約が強い。そのおかげでコードが均一になりやすいというメリットが得られてます。その辺の使用感覚と比べて、Catalyst は一人向けかなあと感じた次第。
プラグインでフレームワークそのものの機能を拡張していけるのが良いですね。Sledge もそうだけど、オープンソースなフレームワークはプラグインアーキテクチャでいかに Hacker を刺激するかがその発展の肝かもしれない。(あとドキュメンテーションｗ)
ちなみに、プラグインを書くには Catalyst::Plugin::Foobar というクラスを作ってその中にメソッドを定義します。ここで定義されたメソッドは Context オブジェクトのメソッドとして定義されます。使うためには use Catalyst qw /Foobar/ とします。プラグインそのものに機能を実装しても良いし、Catalyst::Plugin::Prototype のようにプラグインの中身が更に汎化できる場合は HTML::Prototype のようにそれを外出しのモジュールにしてしまっても良い、といった感じです。
と、いうことで結構使ってみて楽しかったので、次からプライベートで何か作るときは CGI::Application じゃなく Catalyst を使ってみてもいいかな、と思いました。おしまい。
参考にしたドキュメント
]]>そこで新しいのを買おうかと思いましたが、せっかくなので別の物を試してみようと思い、購入したのはこれ。
思っていたより静か
びっくり！ 値段からすれば大変お買い得以前の下敷きタイプのものではなく、ファンのものにしました。ノートPCの後部をこのクーラーに載せて使います。ファンが熱気を吸い取って側面から冷却風を流します。これでノートPCの底面が冷却されます。電源は USB から取ります。
効果の程ですが、さすがにファン付ということもあって、下敷きタイプのものよりかなり冷える。PCの底面を触ると冷たいぐらいです。ちょっとファンの音がしますが、気になるほどではないです。
PC が斜めになって、ちょうどデスクトップ用キーボードの足を立てた状態のようになるので、タイピングがしやすくなるというメリットもあります。(人によってはタイプしづらいかな?)
さくっと下に敷いて用が終わったらPCと一緒にかばんにしまえるという意味では下敷きタイプのものがよかったですが、オフィスなんか定位置で使うのであればこっちのタイプでもいいかもしれませんね。
]]>傭兵日記でyoheiさんがREST入門として、RESTアーキテクチャの解説を日々アップしています。日ごろ何気なくしている HTTP GET とかの処理が、アーキテクチャ的にはどういう意味を持っているのかとかがよくわかって面白いです。要チェック。
ここでは実際に稼動している REST 実装の例としてはてなブックマーク AtomAPI を使います。 はてなブックマークそのものの説明はしませんので、あらかじめご了承ください。
第5回目の今日ははてなブックマークAtomAPIを題材にPUT, DELETE, POST について解説しています。確かに、REST を理解するにはその具体例として AtomAPI の仕様を学ぶとわかりやすいですよね。
]]>これはいいと思い、早速ノートPCに導入。
coLinux は Windows の中で動く Linux なんですが、coLinux そのものはディストリビューションではなく、Windows などの OS の上で、その OS と協調して動作する Linux カーネルです。なので、coLinux を使って Linux 環境を PC に作るにあたっては、ディストリビューションを選択することができます。Fedora Core、Debian、Gentoo なんかがサポートされてます。(他のものでもイメージを作れば動くんでしょう。) 僕は Debian を選択。
インストール方法は blog.bulknews.net でも紹介されていたcoLinuxのメモ - coLinuxのインストールが詳しいです。
coLinux インストール時に TAP-WIN32 とかいう仮想ドライバがインストールされるのですが、これが素晴らしい働きをしてくれます。
ネットワーク接続の方法はいろいろあるのですが、その一つの方法でこの仮想ドライバによってWindows 側にインタフェースを追加しそれを NAT にすることができます。つまり、Windows に、既存のネットワークインタフェースに加えてもう一本足ができて片足をインターネットに、片足を coLinux 側に突っ込んだ環境が構築できると。
coLinux からは TAP-WIN32インタフェース経由でインターネットに接続できるし、Windows から coLinux へも直接アクセスできる。一方外部のホストからは coLinux にはアクセスできないので、ちょうどファイアウォールの内側にあるような状態になり、開発機にはもってこいの環境が構築できます。
ここに Apache、mod_perl、MySQL なんかを放り込んで Perl モジュールも入れて Catalyst が使える状態になりました。楽しいなあ。ノートPCを畳んでスリープモードにして、そこから立ち上げてもちゃんと Linux が動いててすぐ開発に入れるっていうのはかなり感動です。Windows内部にウェブアプリケーション開発環境を持つ、というのを Cygwin でがんばろうと思ったけど mod_perl やなんやが動かなくて諦めてたんですが、coLinux で実現できた感じです。サンキュー miyagawa 氏。
以下、メモっておきます。