trunkのHTTP::Engineのsubカバレッジが100%になった今日この頃皆様いかがおすごしでしょうか。
今現在はtrunkのテストカバレッジを高めた上で、lazy_requestブランチを本格的に採用すべく動いている所です。
nothingmuchによるブランチで、request関連の情報を必要になった時に作り出すような物になっています。
今までは(Catalystもそうだけど)clientからrequestが有るたびに使いもしないデータを最初に作ってたんだけど、そういった事が解消されます。
ただ、今の状態だとPOSTでfile uploadした時が上手く動かない。
lazy_request自体は外部インターフェィスは変わらない予定なので、別に互換性とかの問題は出ないはずなんですが、このブランチが落ち着き次第 HTTP::Engine::Context を無くすブランチを作る予定す。
今までは request や response の情報は $c に生えているメソッド $c->req や $c->res 経由でアクセスする感じでしたが、mstやnothingmuch曰く「context使うなんてCatalystの二の舞になっちゃうyp！(意訳)」といった提案を受けて、「結局 $c ある利点てそんなにないよね」って考えに至ったのでcontextを無くす方向で動こうと思います。
ぶっちゃけWAF側にcontextあったら、どのコンテキストがWAFのなのかHTTP::Engineのなのかわかんなくなって混乱しそうだしね。
sub handle_request {
my $c = shift;
$c->res->body($c->req->uri);
}このコードが
sub handle_request {
my $req = shift;
return HTTP::Engine::Response->new( body => $req->uri);
}になる感じす。
冗長になっちゃうんじゃ無いか?みたいな意見もありそうですが昔のnothingmuchのプランによると
sub handle_request {
my $req = shift;
return HTTP::Engine::Response::Redirect->new('http://example.com/');
}
(あ、これも冗長か＞＜)
sub handle_request {
my $req = shift;
return HTTP::Engine::Response::JSON->new({ foo => 'bar' });
# 18:39 < t*kihirom> return HTTP::Engine::Response::JSON->new({ foo => 'bar' });
# 18:39 < tokihir*m> HATE HATE HATE
}みたいに、特定用途によってレスポンスのクラスを変えれるようにしたらどうか的な話になった。
HTTPEx::Declareつかえば
use HTTPEx::Declare qw( res redirect );
interface {
module => 'ServerSimple',
args => {
host => 'localhost',
port => 1978,
}
};
run {
my $req = shift;
return redirect('http://example.com/') if $req->uri =~ /redirect/;
return res( body => 'hello' );
};
とかになると思う。
HTTP::Engine::Compat的なモジュールを使って、過去のHTTP::Engineアプリと互換性をなるべく保つようにする事も一応考えています。
HTTP::Engine->newするかわりにHTTP::Engine::Compat->newする感じで。
HTTP::Engineはなるべくシンプルであれというのが我々の共通認識であるのでcontextを無くす変更により、よりスマートになるんではないかと思っている次第です。
今まで時間があいた分を取り戻すかのように怒濤に進める予定。
codereposの移転作業やってたら夕方になったので急いで新幹線に飛び乗って京都へ。
駅から歩いて、五条から河原なんとかの道を北上してホテルへ。
そのあと京都に住んでいる人としゃれにならないうまさのホルモン屋で晩飯。
codereposの微調整やりながらきぜつ
ねた
tokuhiromに言われたからcodereposを前の状態8割くらいまでやった。
そのごホテルでて清水寺まであるいていった。
舞台から飛び降りた後に清水坂の高いご飯やで湯葉懐石食べて祇園まであるいた。たくさん料理出てきてびっくり。そしてうまい。
四条橋渡ってから鴨川を北上してお池まで歩いた。砂だらけで不快。
その後京都市役所の前とか通りながら京の城まで歩いた。激しくつまらない道だった。
自宅に入城するさまをustで配信しようとしたら玄関で撮影禁止と怒られたり自分の今に入ろうと思ったらへんなロープはってあるしでとても不快で無礼な者共が沢山いた。
多分今日も行く予定なので自宅に入って速攻で出た。
で、地下鉄のって西の終点(なまえ良くわからない)でおりて路面電車乗った。
そのまま嵐山てまえでおりてトロッコ最終便のった。
亀岡市に入った瞬間激しい土砂降りでdnbkしてとんぼ返り。
で、JRで奈良線の最初の駅で京都版京急に乗って5条までのって一旦ホテルへ。
大阪とか直ぐ行けそうだったけど、京都の人とビアガーデンにいった。
舞妓ビアガーデンとかいうのだったから、麻衣子さんがビール持ってくるかと思いきや、なんとキャバクラの女の子が舞妓になっている感じのとこだった。
道理で生ビールが950円だ。
そして16才とかいってる。
で、宴もたけなわ帰宅して、肛門の人は右の方に帰ったので、二人だけで2城駅まであるいて電車で京都市役所までいく。
そのあと祇園まであるいてグルグルまわって鴨川沿い歩いてたら東京の自宅のご近所さんに偶然遭遇してホテルに帰る。
そして←イマココ
以前予告した通り、CodeReposサーバのお引っ越しを今週中に行います。
とりあえず場所は家に置いて、さっき電力会社に電源工事発注した。
リバースproxyの部分にCentOSの新しいのをいれて、coderepos自体はバックエンドにいるXenのインスタンスで動かそうと思ってます。
QX6600 8G メモリの環境なのでcoderepos以外のインスタンスとかも十分に対応できそう。
既にiscsiの環境もあってライブマイグレーションとか出来るようにはなってるんだけど、それやると別途ファイルサーバ持たなきゃ行けないとかQX6600なCPUのマシンが一台しかないから、別のホストマシンにインスタンス移したらカーネルがクラッシュするとかで、どうしようか悩んでる。
別にこの規模じゃそういうのいらないかなぁ。
で、それらの環境を今晩から1から作ろうと思ってたら、年始に遊んでた環境がそのまま使えそうな事を発見。
xenのインスタンスを新規に作ってしまえばOS環境の設定は楽に終わりそうな気がしたけど、今流行ってるXenの管理ツールを使いたいなと思っていて誰かにおすすめを聞きたい所。
ちなみに良い案が無ければYappoLogs: Cobbler Koan を CentOS な Xen で動かしたよで作った環境でxenのイメージを作る予定。
イメージファイルをiscsiじゃなくてローカルディスクに置いて、iscsiのマシンに依存しない方向で運用しときたい予定。
仮想ディスクはSparseという実際に使ったぶんしか実際のディスクサイズが食われないというwrite性能の低いフォーマットを使う予定で(参考文献)す。バージョン管理システムだから問題無いよね？
ちなみに移行自体は、新しい環境にtracとかもろもろ入れて、svnはdump/loadしてtracはsqliteのファイルをコピペしてくるだけの簡単なお仕事です。
メンテナンス開始日時の具体的な予定は立てられないので、作業直前に各種ircチャンネルやtwitterで告知を行います。
coderepos専用のインスタンス作るので、codereposのadmin的な意味でサーバのログインアカウントを任意の誰かに渡せると思います。
#coderepos@irc.freenode.netではxenとかに詳しいエンジニアを募集します！報酬はありません！！！
EC2でやれって話？とりあえず金曜までにやんなきゃいけないので勘弁してくだちぃ。
空前のwassrブームの中皆様いかがおすごしでしょうか。
ついにあのTwitがTwit4WSとしてwassr対応して面白い感じですが、Mac用のいいツールが無さげです。
先週末の、はてなハイククライアント制作者の集いにdrkinさんもいらしてたのでwassr対応を聞いてみたのですが、ちょっと面倒くさそうな感じだったので、僕が勝手にTwitterPodをwassr対応しちゃいました。
かいつまむと「wassr APIをtwitter APIを使うクライアントからアクセスできるコンバータ付きproxy」です。
Macのターミナルとperlが使える環境の人前程ですが、物凄く簡単にwassr対応が出来ます。
TwitterPodをアプリケーションディレクトリに入れておいて下さい。
そして、ここからターミナル操作です。
まずは
svn co http://svn.coderepos.org/share/lang/perl/misc/WassrPod ~/WassrPodとかで、仕組み一式をチェックアウトして
$ cd /Applications $ ~/WassrPod/install.plとするだけでWassrPodがアプリケーションディレクトリに出来上がります。
次に肝心のproxyですが、~/WassrPod/wassrpod.plがそうです。
これを使うには各種CPANモジュールが必要なので
$ sudo cpan > install MooseX::Getopt > install HTTP::Server::Simple > install HTTP::Engine > install JSON > install DateTime > install XML::Simpleとかして必要なモジュールを全部入れておきます。
$ ~/WassrPod/wassrpod.pl --port 9277で起動します。9277はproxyのサーバポートです。
ここまできたらあとはアプリケーションディレクトリのWassrPodを起動して、設定画面からwassrのアカウントを入れて、最後が肝心だけど「Enable Proxy」にチェックをいれて「Server」に「127.0.0.1」を入れ「Port」に「9277」を入れればokです。
結構無理栗なhackなのでWassrPodのアプリケーションが落ちちゃったりもしますが、結構快適に使えます。
今後の予定はwassrならではの機能をWassrPodから使えるようにwassrpod.plを拡張してく感じです。
なんでも一から作るのは大変ですが、この程度なら大変じゃなくて良い感じですね。
どうぞご利用下さい。
なんだか知らないがTwitterのAPI制限が一時間に20回までになってしまったようだ。
3分に一回しかtimelineを拾えない。
ただでさえ取りこぼしまくってるのに、もうこの制限じゃマトモにTwitter APIが使えなくなってしまったと言わざるを得ない。
この調子だとWebとかでスクレイピングとかするのにも制限はいるんじゃ無いか。
そんな皆さんにおすすめなのがwassrです！
wassrにはAPI制限なんてありませんし、followとかとは別に個別のテーマのルームが作れたりします！
しかも@で言及されたらメールでおしらせしてくれたり、secondlifeから書き込めたりとtwitterより凄いサイトなんです！
wassr専用クライアントってのは凄くマイナーで数少ないけど、Twitter APIと同等なので、Twitterクライアント書いてる人にお願いをするかCodeReposにimportしてあるものだったら自分でパッチ書いてコミットして作者さんにリリースしてもらうだけで、wassr専用クライアントがいっぱい誕生すると思います！
CHEEBOWさんお願いします！
もう今時小学生もwassrを選ぶっていう話もあるんだし、いまだにTwitterなんかで喜んでないで皆もwassrをやってみませんか？
ちなみにこのエントリ経由で100人以上wassrのユーザ登録があったら、wemaの人がしゃぶしゃぶおごってくれるらしいです！