Atomの絡みでRESTな何かを作ってみようということで、Catalyst Advent Calendarから、9日目のやつを触った。

Catalyst::Controller::RESTを利用してRESTなサービスをつくってみるという内容

• _GET,_POST,_PUT,_DELETという接尾語をつけるとそれぞれのリクエストに応じた処理を担当するようになる。

• Content Typesに応じたシリアライザーが呼ばれる

あと余談だけど

Path('/user') : Args(1)

とかやってArgsあるときとないときの処理分けするといいのか。defaultの中でargsの数かぞえてあるときないときでifで分けてた。

XML::Atomでcontentとcontent->typeをimageにしてやれば画像が投稿できる。

$entry->content($image);
$entry->content->type('image/jpeg');
$entry->title('Fu-ku-u-me');

で、entryの部分を書き換えてvoxに投稿してみると、ちゃんと投稿されとるよ。

ははてなフォトライフAtomAPIとAtom 出版プロトコルを知るを参考にした。

ラーメンはnon-Atom（無化調）派だけど、最近の興味はAtomなんです。

use XML::Atom::Entry;

my $PostURI = 'http://www.vox.com/services/atom/svc=post/collection_id=mkmkmk';
my $api = XML::Atom::Client->new;
$api->username('mogemoge@gmail.com');
$api->password('mogemoge');

my $entry = XML::Atom::Entry->new;
$entry->title('Atomのチカラ');
$entry->content('XML::Atomを使って投稿しますヨ');

my $EditURI = $api->createEntry($PostURI, $entry);
print $EditURI;

これだけで投稿される!

構造最適化計算に悩まされすぎで、ゆっくりCatalystいじる暇もない。まったくもってムキーだ。というわけで、最近のであったトラブルとTodoメモ

avogadroで最適化すると遅い、あと変な構造が出る。

後ろではしっているopenbabelのせいかどうかわからんけどMWT500ぐらいのちょっと複雑な構造はやたら遅い。あとベンゼン環が壊れたりする。

gamessめんどい

Wingamessのbatchmaker経由もめんどい。なんかAvogadro経由でインプット作るのも、数をこなしたいときには邪魔臭くなってきた。っていうかAvogadroってopenすると必ずexeのあるフォルダが開くんでworkdirに移動すんのが面倒。

そもそも今はAvogadroのオプションのGamessのインプットを吐く機能を使っているだけなので、perlでインプット吐いてrunとかも面倒見てくれるモジュールを書けばいいだけの気もしてきた。っていうか書く。

MMのとこも考える

MMで2,30個安定なコンフォメーション発生させて、欲しいコンフォマーをピックするようなのも用意しないとあかん。これはwebでいいや。

それにしても、量子化学計算のできない合成化学者はBlast検索のできない分子生物学者みたいなもんじゃないのかなぁとか思うんだけど、この主張は言い過ぎなのか？

自分のvoxのAtomFeedを例にとりながら、Atomに関して勉強してみた。

• XMLの論考：Atom駆け足解説
• Atom 1.0 Syndication Formatの概要
• Atom 出版プロトコルを知る

MeadowをAtomPPのクライアントにできるみたい。

clmemo@aka: Blog の記事を Emacs からポストする (1) |Emacs|AtomPP|

さて、 GNU Emacs 用の Atom PP クライアントを Erik Hetzner 氏が公開してる。名前は emacs-atom-api 。Pure EmacsLisp なソフトで、Blog の投稿・編集・削除をサポートしている。

なんとなくMeadowからもVoxに投稿できそうな気がするので週末にでも。

で、descriptionのところで悩んだわけですが。

TT使ってRSS生成するようなCatalystアプリケーション書いたときにはCDATAセクションにコンテンツをそのまま埋め込むようにしたんだけど、XML::Feedのsummaryにhtmlを突っ込んで$feed->as_xmlをすると、下の例みたいにブラ(<)だけが実体参照になって出力されとる。

<item>
<title>テストの一言</title>
<link>http://prv:3000/entry/1180677450</link>
<description>&lt;h2>おめでとう、初LLチケットゲット。&lt;/h2>
&lt;p>そしてメタモとかぶらなかったことに感謝!&lt;/p>

</description>
<author>kerolinq@gmail.com</author>
<guid isPermaLink="true">http://snow:3000/entry/1180677450</guid>
<pubDate>Tue, 05 Jun 2007 22:23:53 +0900</pubDate>
</item>

W3Cのバリデータにかけてみると

オメデトさん、バリッドだよ

とか言われたので、こういうやり方でもいいのかと思った次第。

あとは、Atomもちょっと調べる、というか吐けるようにしてみる。

引き続きCatalyst::Controller::FormBuilderをいじってるヨ。ってかCGI::FormBuilder読んだ。

で、昨日はこんな感じで書いてたんだけど

my $data = {
            title            => $form->field('title'),
            content          => $form->field('content'),
            tag_text         => $form->field('tag_text'),
            pubdate         => $dt
            };

my $e = $c->model('DBIC::Entries')->update_or_create($data);

でも、podみてたら$form->fieldってメソッド使えばハッシュのリファレンスが返ってくるので、

my $data = $form->field;
my $e = $c->model('DBIC::Entries')->update_or_create($data);

でいいらしい。早速書き直した。フォームのパラメータとかバリデーションとかよきに計らってくれる上に、DBICとの連携も楽だ。

それがDWIMmery?

CGI::FormBuilder - Easily generate and process stateful forms - search.cpan.org

The goal of CGI::FormBuilder (FormBuilder) is to provide an easy way for you to generate and process entire CGI form-based applications. Its main features are:

• Field Abstraction
• DWIMmery
• Built-in Validation
• Template Support

HTML::Widgetだと細かいところに手を入れにくいいので、 Catalyst::Controller::FormBuilderに変えてみたらよさげ。

フォームの設定とかバリデートの情報はYAMLで。しかもデフォルトがTTSiteみたいな階層を取っているので管理しやすい。例えば/books/editに対応する設定ファイルはroot/forms/books/edit.fbと言った具合にfbっていう拡張子をつけておけばよい。

TTで使う場合には

[% FormBuilder.render %]

でよくて細かくいろいろいじりたい場合には

[% formbuilder.start -%]
...
[% END %]

で。

FC6のこんな構成で

• httpd-2.2.4-2.fc6
• mod_perl-2.0.2-6.1
• mod_fcgid-2.1-1.fc6
• Catalyst 5.7007
• ImageMagick-perl-6.2.8.0-4.fc6
• ImageMagick-6.2.8.0-4.fc6

CatalystからImage::Magickが動かない。Catalyst組み込みのサーバーだとOKなんだけど、mod_perl,fcgidでは動かない。

どうも、アップロードしたファイルが読めてないようで、

my $i = Imager->new;
$i->read(file => $upload->tempname);

のところでコケテル。あーselinuxの設定か？と思って見直したんだけど、全然違った。単順にアップロードするだけならできてるし、readできてないみたい。

もうちょっと追ってみたら、

Exception 420: no decode delegate for this image format

とあってどうもImage::Magickがファイルの形式判別できてないみたいな感じ。

うーん、全然わからんなぁと悩んでたら、use Imager; という記事がナイスなタイミングで。

ナイスすぎる。早速乗り換え。

っていうかちょっと書き直しただけですぐ動いた。

my $i = Imager->new;
$i->read(file => $photo_data->tempname);
my $w = $i->getwidth();
my $h = $i->getheight();
my ($width,$height,$top,$left);
if($w > $h){
$width = $h;
$height = $h;
$top = 0;
$left = int(($w - $h)/2);
}elsif($h > $w){
$width = $w;
$height = $w;
$top = int(($h - $w)/2);
$left = 0;
}

画像を正方形にして36pxのアイコンにするという処理なので、とりあえずちょっと書き直したら動いたけど、

use Imager

例えば scale() の項目を見ると、200x200に「収まるように」小さくするには、type => 'min'、縦横比を無視してそのサイズに引き伸ばしたい場合は type => 'nonprop' というオプションをつければいいことがわかります。

minっていうオプション付けれぼ綺麗にかけそう。

そういえば、ImagerとかImage::Magick,imlib2なんかのリサイズを比較したエントリあったなと、livedoorclip探した。タグつけしないと探しづらくてあかんなぁ。

TheSchwartzで分散ジョブ実行環境が順調に立ち上がったのだけどWorkerのプロセスってのは普通どうしておくんだろうか?

nohupで動かしておくんだろうか?

それともデーモン化させたほうがいいんだろうか？

と、コンソールで立ち上がってるWorker眺めながらふと考えた。