タグ

ブックマーク / gfx.hatenadiary.org (28)

  • テンプレートエンジンの自動エスケープ機能について - Islands in the byte stream (legacy)

    最近Xslateの自動エスケープ機能について考えていたのですが、これは「この機能によって安全性が高まる」というものではなく(結果的にそうでないものより安全ではありますが)、むしろテンプレートエンジンとしてはこれこそ正しい振る舞いなのではないかと思うに至りました。 この「値を渡すと、ソースコードに埋め込む際に適当に加工する」という振る舞いは、SQLとプレースホルダの振る舞いがまさにそうです。SQLに値を埋め込む際、アプリケーションでいちいち値をエスケープするというのは危険であり、避けるべきです。可能であれば常にプレースホルダを使うという方針をとるだけで、エスケープ問題について余計なことを考える必要はなくなります。 テンプレートエンジンについても同じこと。テンプレートに値を埋め込む時は、そのまま渡せばいいのです。これを手動で行わせるのは、プレースホルダに埋め込む値のエスケープの有無をユーザーに

    テンプレートエンジンの自動エスケープ機能について - Islands in the byte stream (legacy)
    kwry
    kwry 2010/08/22
  • Xslate 0.1058の新機能 - Islands in the byte stream (legacy)

    HTMLのソースを返す関数で正しくHTMLソースを出力させるには、戻り値をmark_raw()する必要があります。さもないと、自動エスケープ機構が働いてしまうからです。 このために、0.1057以前のXslateはわざわざラッパー関数を書く必要がありました。しかし、繰り返し同じことをするのは面倒なので、これを簡単にできるようにするためのユーティリティを追加しました。 以前以下のように書いていたところが(Cookbookより引用): use Text::Xslate qw(mark_raw unmark_raw); use HTML::FillInForm; sub fillinform { my($q) = @_; my $fif = HTML::FillInForm->new(); return sub { my($html) = @_; $html = unmark_raw($html

    Xslate 0.1058の新機能 - Islands in the byte stream (legacy)
    kwry
    kwry 2010/08/18
  • How and when Xslate escapes html special characters - Islands in the byte stream (legacy)

    Xslate のエスケープポリシーについて考えたので、ここでまとめておく*1。 Xslate のエスケープ処理について、覚えることは以下の三つである*2。 テンプテートタグ内で生成した値は自動的にエスケープされる エスケープ処理をさせたくないときはmark_raw フィルタを使う エスケープ処理を強制させたいときは unmark_rawフィルタを使う 以下、詳しく解説する。 まず、基的には Text::MicroTemplate のポリシーを踏襲している*3。すなわち、テンプレートタグ内で生成された文字列については、HTMLのメタ文字(< > & " &apos)が自動的にエスケープされる。エスケープ処理は、一般式に対する出力コマンドが担っている。 # Text::Xslate version 0.1032 $ xslate -e '<foo>' # 地の文字列はそのまま出力 <foo>

    How and when Xslate escapes html special characters - Islands in the byte stream (legacy)
  • File::Spec::Memoized - Makes File::Spec faster - Islands in the byte stream (legacy)

    File::Specはファイルパスを扱うために欠かせないモジュールだが,メソッドによっては非常に遅くプログラムのボトルネックになりかねない。 このようなケースでは,メモイズ(Memoize)というテクニックが役に立つ。メモイズは,引数が単純で副作用を持たない関数の結果をキャッシュして高速化する手法である*1。 メモ化(Memoization) - Wikipedia たとえば,重い処理を行うf()があったとして,そのf()の結果が特定の引数に対して一意に決まり,かつf()に副作用がないとき,以下のように結果をキャッシュしたmemozied_f()を用意したとしても,f()とmemozied_f()の意味は変わらないが,memoized_f()の二度目以降の呼び出しがf()の呼び出しよりも高速になる。 my %cache; sub memoized_f{ # 引数からIDを作成する my $

    File::Spec::Memoized - Makes File::Spec faster - Islands in the byte stream (legacy)
  • Time loading modules, compareing the blead with the released - Islands in the byte stream (legacy)

    開発中のモジュールのロード時間を計るベンチマークスクリプト: #!perl -w use strict; use Benchmark qw(:all); my $module = 'Moose'; cmpthese timethese 10 => { released => sub{ system($^X, '-e', "require $module") == 0 or die; }, blead => sub{ system($^X, '-Iblib/lib', '-Iblib/arch', '-e', "require $module") == 0 or die; }, };

    Time loading modules, compareing the blead with the released - Islands in the byte stream (legacy)
  • Don't write "HTTP::Engine::Response" - Islands in the byte stream (legacy)

    HTTP::Engine::Responseと書かなければならいのがなんだか煩わしい。 HTTP::EngineのSYNOPSISより: sub handle_request { my $req = shift; HTTP::Engine::Response->new( body => Dumper($req) ); } これを↓みたいに書きたい。 sub handle_request { my($req, $res) = @_; $res->print( Dumper($req) ); return; # $resを返す必要すらない } こうなると,まずhandle_request()が完全にHTTP::Engine非依存になるため,たとえばHTTP::Engine::MinimalCGIのようなHTTP::Engine互換のモジュールと自然に切り替えられる。 そのうえ,$resの自由度

    Don't write "HTTP::Engine::Response" - Islands in the byte stream (legacy)
  • strict無効化の誤謬 - Islands in the byte stream (legacy)

    シンボルテーブルを操作するときに"no strict 'refs'"で一時的にstrictを無効化することはよくあるが,デバッグしにくいバグが紛れ込む可能性がある。 たとえば,以下のようにアクセサを動的に生成するコードはCPANのそこかしこにある。 sub make_accessor{ my($class, $property) = @_; no strict 'refs'; # simple read-only accessor *{$class. '::' . $property} = sub{ my($self) = @_; return $self->{$property}; } } このようなコードによって生成されたメソッドを,正しくオブジェクトに対して使う分には問題ない。しかし,このメソッドをクラスメソッドとして呼び出すと,グローバル変数${$self}を参照し,その値をハッシ

    strict無効化の誤謬 - Islands in the byte stream (legacy)
  • Perl/XSが得意なこと - Islands in the byte stream (legacy)

    最近ひたすらXSを書いていて思ったのが,XSはやっぱり速いということ。 ただ,いつでも無条件に速いというわけでもなく,何も考えずに書くとPurePerlのコードより遅くなることも珍しくない。実際,最近書いたShikaやMOPのXS版もいきなり高速だったわけではなく,一番最初のコードはPurePerlのほうが10%-30%ほど高速だった。 いろいろベンチマークをとった結果の感触として,XSの得手・不得手が分かってきたのでメモしておく。ちなみに下記で「注意を払う」というのは内部で呼ばれるmalloc()を極力減らすという意味で使っている。SVの生成自体はmalloc()を伴わないことが多い*1が,文字列の生成/連結や配列の生成/push/unshiftでは内部でmalloc()が呼ばれる可能性が高く,速度を落とす原因となる。 得手分野 ループ - XSのループが早いというより,Perlのループ

    Perl/XSが得意なこと - Islands in the byte stream (legacy)
    kwry
    kwry 2008/12/03