Web application framework をつくっている場合、Tiffany を依存にいれるのがいやだ、というむきがあるかとおもいます。そんな場合、Xslate をつかうのであれば、別に Tiffany を依存にいれる必要はありません。 なぜならば Text::Xslate は Tiffany プロトコルにしたがっているからです。Tiffany プロトコルを利用して Web application framework をつくるならば、そのまま Text::Xslate という名前を Tiffany の任意のクラスにさしかえればうごくようにつくることが可能です。 というか、各テンプレートエンジンにそれぞれの web application framework がそれぞれ対応するという状況が馬鹿馬鹿しいから Tiffany があるわけなのです。

デフォルトのテンプレートを HTML5 に変更Tiffany への依存をなくしたhttp://amon.64p.org/ を充実させた(using sphinx)DBI へ依存してみたが、XS 依存しない方針だったことをおもいだしたのではずしたAmon2::DBI をつくってリリースしたBEFORE_DISPATCH は、Plack::Response 以外の true value のときの誤動作しないようになったPlugin::JSON が Opera でうごいてなかったのを修正Amon2::Trigger が祖先クラスのトリガーもよぶようになったskinny 用のコードを amon2-setup.pl からはずしたセットアップ時にでてくるコードをましなものにしたなどなど。

白方さん翻訳分における Pod::L10N スタイルの目次の日本語訳形式への対応ディストリビューションページの整形翻訳データをおくための git repository を追加Scss の採用iphone でみてもそれなりにみえるように調整google 検索への対応s や qw などが表示できるように(reported by @akiym)モジュール一覧に最新のバージョンがいくつかを表示するようにモジュール一覧で同じモジュールがいくつもある場合にはまとめるように(by ktat++)といったあたりまでやった。

https://github.com/perldoc-jp/module-pod-jp ここにつくってみた。 「Japanized Perl Resources Project は CVS だから面倒だ」「sourceforge.jp のアカウントつくるのめんどくさい」などといったことを言う人がおおいので、github におきばをつくってみた。 ここにいれれば自動的に perldoc.jp に表示されるようになります(現状、10分に一度同期してます)。 コミット権限は https://github.com/perldoc-jp ここにのっている人達にいえば貰えるし、pull-req してきてもいいです。github なので、ウェブでの編集も可能ですから、web 上で勝手に typo をなおしたりすることも可能。 まあとりあえずの試験運用ってかんじですが。

http://perldoc.jp/ perldoc.jp は、もともと miyagawa さんがつくったサイトだったわけですが、これを JPA が去年ぐらいにドメインだけひきとっていたのを、僕の方でウェブアプリケーションとして実装しました。 元のものよりもだいぶみやすいんではないかとおもいます。 http://perldoc.jp/perlsyn とかもうごくので、べんりべんり。

UNIVERSAL::require$module->require() or die $@ ってかけるのが cool という話ではあるのだが、UNIVERSAL をつかうのに抵抗があるかもしれない。 そして、Module::Load にたいする優位性はとくにないので、最近はあまりつかってない。 Class::Load上記2つにくらべると、機能がおおい。これは Moose から派生したパッケージで、Moose の is_class_loaded 相当の機能もそなえている。 Moose 由来ということで、%INC の中にはいっていなくても、package がすでにつかわれていれば、ファイルをよみにいかないという点がすぐれている。具体的には package Foo; sub bar { } package main; use Class::Load qw/load_class/; load_c

ちょっとした RPC サーバーを C/C++ でかきたいな、なんてケースはままあるわけですが、そんなときに便利なライブラリがあったので紹介します。 KyotoTycoon をつかうと、TSVRPC over HTTP な RPC サーバーが超簡単にかけて便利だった。libkyototycoon は GPL だけど、それが問題にならない場合なら、とてもいいとおもう。商用ライセンスかえるならそれもいいとおもう。 RPC サーバーとしては他にもいくつか実装があるんだけど、HTTP の上で実装されているから、デバッグが容易だったりとか、直接 telnet ではなしたりとか tcpdump できたりして、いろいろ便利なので、よいとおもう。 SConstruct でビルドルールをかいてから e = Environment() e.Program('ktechoserver', ['ktechoserv

http://blog.clouder.jp/archives/000759.html ちょっと遅レスですが、プロファイラにかけてみると、実際には gif に encode するところで時間をちょうくってるということがわかった。 なんでだろう。Imager がおそいのか、減色処理的なのに時間くってるのか、giflib がおそいのか。。。そこまで深追いしてない。 というわけで、出力画像フォーマット別のベンチマーク。 use strict; use Imager::QRCode; use Benchmark qw(timethese cmpthese); use Encode; my $count = shift // 100; my $text = encode('cp932', decode('utf8', 'これはテストです')); cmpthese(timethese($count,

DB に接続失敗したばあいに数秒後にリトライしてほしいとか、 API なげるのに失敗したときにリトライしてほしいとか、そういう処理を楽にかけるモジュールつくった。 以下のようにしてつかう。 use Sub::Retry; use LWP::UserAgent; my $ua = LWP::UserAgent->new(); my $res = retry 3, 1, sub { my $res = $ua->post('http://example.com/api/foo/bar'); $res->is_success or die; $res; };

https://rt.cpan.org/Public/Bug/Display.html?id=64785 Imager 0.78 以後で、なぜか gif の圧縮がおそいのではないかということを id:clouder さんにおしえていただいたので、ベンチマークをとって、本家に feedback しておいた。モジュールの分離によって若干おそくなるというのはまあかんがえられるのだが、これはさすがに遅すぎる。 Imager 0.75 までをつかっていて、Imager 0.78 以後にアップデートする場合、50倍遅くなるということなので、なおるまではモジュールのバージョンアップ時には注意してください。 #!/usr/bin/perl use strict; use warnings; use utf8; use Benchmark ':all'; use Config; use lib; # cpa

HTTP Server から複数のファイルを一回のレスポンスでかえしたいときは multipart/mixed をつかうのが普通だとおもうのだけれど、それを Perl でやるにはどうしたらいいかという話題。 multipart/mixed を Plack なアプリでだすには、ライブラリをつかうのではなく手でだした方が結局楽っぽい。 クライアント側では、LWP は multipart/mixed に対応しているので、素直に my $res = $ua->get(...); # $res is-a HTTP::Response. for my $part ($res->parts) { say $part->content_type; }などとすればよろしい。

http://pjp.64p.org/ https://github.com/tokuhirom/PJP/ perldoc.jp はいかんせん、みるのがめんどくさいという難点があったので、もうちょいみやすく表示できるサイトをつくってみた。 公式ドキュメントのみに特化しています。perldoc.perl.org をめざしてそういうかんじにしてあります。 だれかデザインをまともにしてくれるとうれしいですね。

現時点で、search.cpan.org よりも、検索精度よくなったとおもいます。つまりこれは「俺がのぞむ検索結果」にちかい結果をだしてくれてる気がするという程度の意味ですが。 基本の検索エンジンに groonga をつかうという方針はかわってないんですが、prefix match した場合に score をつよめにつけたりとかしてます。 あと、これはおおきいとおもうんですが、FrePAN には I use this っていう機能があって、自分がつかってるモジュールを登録できるようになってるんですが、今回、つかってる人がおおいモジュールは検索スコアがあがるようになりました。これは前からかなりやりたかった機能だったので、やっと実現したというかんじ。なお、コメントはべつに日本語でかいてもぜんぜんおーけーです。 個人的に CPAN Ratings があんまりすきじゃないんですよね。「いや、あんた

あけましておめでとうございます。正月早々、O/R Mapper についてかんがえてみたことについて、ちょっとだけかいてみます。 O/R Mapper は RDBMS の差異をうめるためのものではない「O/R Mapper つかってるから RDBMS が MySQL から Pg になっても大丈夫!」というのはわりと幻想。まあえてして、ORM に由来しないところで、RDBMS に依存してしまったりしますし、たとえば ORM つかっていても Skinny は FOR UPDATE をサポートしているけれど、FOR UPDATE は、SQL 標準じゃない気がするので、サポートしてない RDBMS だとうごかなかったりしますね。 そもそも SQL 標準の範囲でやろうとおもうなら、SQL 標準にのっとった SQL を発行すればいいだけなので、ORM をつかう必要はありませんね。 で、また RDBMS

マルチスレッドで云々とかかんがえないでよいケースでは、XS::Object::Magic をつかうと楽にできる。 xs/typemap というファイルに以下の内容をコピペする。 TYPEMAP MyStruct * T_PTROBJ_MG INPUT T_PTROBJ_MG $var = ($type)xs_object_magic_get_struct_rv_pretty(aTHX_ $arg, \"$var\");xs_object_magic.h を http://frepan.64p.org/src/NUFFIN/XS-Object-Magic-0.02/xs_object_magic.h このへんとかからとってきて、おく。 あとは、普通に XS をかけばいい。magic まわりの諸々は隠蔽されているので、気にする必要がない。 #include "xshelper.h" #incl

http://frepan.64p.org/ FrePAN に incremental search を追加した。groonga を採用しており、非常に高速な検索が可能。スコアリングもそれなりに考えて実装してあるので、ぼちぼちいいかんじの結果がでているとおもう。 今回なんで groonga を採用したのかというと、たいした理由はないのだが、それなりに簡単につかえそうだったから、といったところ。HTTP interface があるので、バインディングなどをわざわざかかなくていいし。 package 名の prefix にマッチした file の score をあげるとかそういうのをやりたいんだけど、まだできてない。

Test::TCP の中で exec 発行すれば、groonga だろうと KT だろうと memcached だろうと、サーバープロセスのテストは簡単にできるのであって、サーバーごとにモジュールにする必要はない。以下は、groonga をテストする例。 Test::TCP は、さまざまなTCPサーバーのテストにつかわれており、さまざまな BK をふくんだ実装となっていて、これを再発明しようとすると、意外とめんどくさかったりするので、素直につかうとよいです。 use strict; use warnings; use utf8; use Test::More; use Test::TCP 1.08; use File::Temp (); use File::Which; my $bin = scalar which 'groonga'; plan skip_all => 'groonga

RDBMSレベルのtriggerはアプリケーションレベルのトリガーにくらべてもれもなく、安心感があってよいものですね。 しかし一方で、RDBMS レベルのtriggerは、deploy がむずかしいという問題もあります。 わたくしは、以下のようなスクリプトをつかって、スキーマと実際のDBの様子をつきあわせて、ちがっていれば DROP して CREATE しなおすというようなスクリプトをかいています。 みなさんはどのように管理していますか? #!/usr/bin/env perl use strict; use warnings; use utf8; use 5.10.0; use autodie; use Log::Minimal; use File::Spec; use Data::Dumper; ... my $dbh = $dbh; my %db_triggers = map { $

http://blog.eorzea.asia/2010/12/post_94.html Active Record パターンでは Single Table Inheritance パターンがつかえないというのは誤りです。件の記事にかいてある Active Record だからー、ってかいてあるのは単に DBIC の問題か DBIC のつかいかたの問題じゃないかとおもいます。 実際に僕は DBIC で Single Table Inheritance つかってましたし。なので、それを紹介しようとおもったものの、すっかりわすれてしまっている上に DBIC のつかいかたもおもいだせないので、Skinny で example code をおこしました。 以下のコードではつかって若干トリッキーなことをやってる風にみえますが、本質的にはごく普通のことをしています。 #!/usr/bin/perl u