「ARIEL 読本」
検索が楽なので単一ファイルで書くそうな。 ARIEL の場合は 29話から 53話までで 2.5Mbytes を越えるとか。 (p.235)
銀座にいって、Suica 改札機のデザインの展示を見て来る。
少数のサンプルを詳細に観察することが(も)重要だということが述べられていた気がする。
iconv-io が version up されていたので、 きっと readpartial 対応に違いないと思って見てみるとやはりそうであった。
... が、readpartial の EOF 時の挙動は EOFError にしたので、微妙にうまくない。
% ruby -riconv/io -e '
Iconv::Reader.new(STDIN, "EUC-JP", "UTF-16LE").each_line {|line|
p line
}'
ふにょ
"u0k0\2070\n"
へにょ
"\000x0k0\2070\n"
^D
/home/akr/ruby/lib/ruby/site_ruby/1.9/iconv/io.rb:88:in `readpartial': End of file reached (EOFError)
from /home/akr/ruby/lib/ruby/site_ruby/1.9/iconv/io.rb:88:in `_readpartial'
from /home/akr/ruby/lib/ruby/site_ruby/1.9/iconv/io.rb:98:in `_buffer_fill'
from /home/akr/ruby/lib/ruby/site_ruby/1.9/iconv/io.rb:279:in `_gets_normal'
from /home/akr/ruby/lib/ruby/site_ruby/1.9/iconv/io.rb:204:in `gets'
from /home/akr/ruby/lib/ruby/site_ruby/1.9/iconv/io.rb:320:in `each_line'
from -e:2
まぁ、1行入力する毎に変換結果が出て来るところをみると、 readpartial は正しく動いているようではある。
それはそれとして、UTF-16LE での each_line というのは難しい。 改行文字は "\n\0" なのに \0 が次の行にいってしまう。 改行文字以外にも \n は現われる可能性がある。 結局、内部コードに関しては iconv が教えてくれる以外の知識も必要ということか。
ファイルもソケットも読み書きできるという点では同じようなものである。
もちろん、違う点はいろいろあるけれど、 バッファリングを行なうという視点からはどんな違いがあるだろうか?
英単語の末尾が -ter か -tor か迷うことがある。
むかし、これを判断するのに、-tion という単語がある場合には -tor で、 そうでない場合には -ter だという信用できるのかどうか良く分からない 判断基準を聞いたことがある。
ふと、思い立ってこれを確認してみる。
% cd /usr/share/dict
% comm -12 =(sed -n 's/tor$//p' words) =(sed -n 's/tion$//p' words)|wc
130 130 983
% comm -12 =(sed -n 's/ter$//p' words) =(sed -n 's/tion$//p' words)|wc
20 20 131
% comm -12 =(comm -12 =(sed -n 's/ter$//p' words) =(sed -n 's/tion$//p' words)) =(sed -n 's/tor$//p' words)|wc
3 3 20
ふむ。けっこう当たるか?
glibc とか Solaris には、stdio_ext.h なんてものがあることを知る。
CGI, FastCGI, mod_ruby のどれでも無変更で動かせるスクリプトを書くための webapp.rb というライブラリを作ってみる。
まだプリミティブ的なメソッドしか用意していないので長ったらしいが、 次のスクリプトを webapp.cgi, webapp.fcgi, webapp.rbx として実行できた。
#!/path/to/ruby
require 'webapp'
WebApp {|request, response|
response.header_object.add 'Content-Type', 'text/plain'
response.body_object.puts Time.now
request.header_object.each {|k, v|
response.body_object.puts "#{k}: #{v}"
}
}
Apache で、URL の path の部分に %2F をいれると 404 Not Found になるようだ。 これは、その path の部分が実際のファイルシステムにマップされず、 CGI の PATH_INFO になるとしても変わらない模様。
webapp.rb で作ったサンプルで、pid を表示する。 なかなか楽しい。
CGI は毎回変わり、 FastCGI は変わらない。 そして、mod_ruby は周期 5 とか 6 でサイクルする。
周期 5 という長さが StartServers 5 だからなのはわかる。 だが、周期 6 というのはなぜか。
てきとうに試してみると、restart 直後は周期 5 で、 FastCGI で動かしたときから周期 6 になるようだ。 まぁ、なんとなくわからないでもない。
PATH_INFO がいろいろと変わる状況でも、 簡単に (処理中のページの PATH_INFO を気にせずに) 相対 URL を生成できるようにしてみる。
webapp.rb のサンプルとして、(htree と sqlite-ruby を使って) SQLite のデータを web から閲覧する view-sqlite というプログラムを作ってみる。
面倒だったのでテンプレートはプログラムに埋め込んでしまったのだが、 w3m view-sqlite.rb で (v で) HTML として解釈させることによって、 テンプレートをレンダリングさせることが可能であることに気がついてしまった。
メールを仕分けするには、 そのメールがどの ML のメールなのかを判断しなければならない。
まぁ、X-ML-Name (とか X-ML-Nickname とか ML-Name とか X-Mailing-List とか Mailing-List とか List-Id とか Delivered-To: mailing list ... とか X-Sequence とか envelope from が ...-return-... であるとか) などを使うというのが常套手段ではあるのだが、 違う方法として、Reply-To と To に同じアドレスが入っていたら ML とみなすのはどうかということを考え付いた。
正確には、((To | Cc) & Reply-To) - (From | Sender | Return-Path) として 出て来たアドレスは結構な確率で ML のアドレスなのではないかということである。
まぁ、ML サーバが Reply-To をつけることが前提ではあるが。
試してみるとかなり当たるが、 ある程度外れるのもある。
なお、ついでに Mail-Followup-To について考えると、 その内容のアドレスがひとつしかない場合で、 それが From のアドレスと異なる場合には ML のアドレスの可能性が高いのではないか。
request と response を分けるべきかどうか、という話が ruby-talk で出ている。
読んで考えてみると、ひとつでいい気がして来た。
request は request-line + message で、 response は status-line + message だから、 どっちも似たような構造で、同じクラス、あるいは継承で微妙に変えたクラスで表現したくなる。 そうすると、それぞれにオブジェクトを対応させることになる。
が、使われ方はかなり違う。 response は書き込むだけだし、 request は読み込むだけで、 さらにいえば、 多くのケースで request へのアクセスは submit された form をデコードするインターフェースを使うので、 直接読み込むこともあまりない。
使われる機能とめったに使われない機能をおなじ使いやすさのところに配置しておくのは 誘導を失敗しやすいのでよろしくない。
で、推奨するメソッドだけ残すと、request と response はぜんぜん似ていないオブジェクトになる。 そうなると、同じ(もしくは似た)クラスで表現することは出来なくなる。
webapp はひとつにするか。
form の validation をしようと思って、HTML4 の form の項を読み直す。
それでいまさらながらに気がついたのだが、 application/x-www-form-urlencoded でも、 multipart/form-data でも、 パラメータの順番は文書における出現順であることが規定されている。
まぁ、守らないブラウザもありそうだが。 (べつに例を知っているわけではないけれど)
調べてみると、いろいろとブラウザ依存性があるようだ。
たとえば、
<input type=submit name=n>
というので submit すると、 w3m では n=SUBMIT となり、 mozilla では n= となり、 IE では n=%83N%83G%83%8A%91%97%90M となる。
また、
<input type=image name=n value=v>
というので submit すると、mozilla では n.x=X&n.y=Y&n=v となるが、 w3m や IE では n.x=X&n.y=Y となる。
また、
<input type=button name=n>
というのがあると、w3m は n=SUBMIT というのがつくが、 mozilla や IE ではつかない。
きっと他にもたくさんあるに違いない。
[latest]