最新

おおいわのこめんと (2005-12)


2005-12-01

[Comp] PHP with suexec

Apache 2 + Suexec 環境下で、通常のCGIと同じ権限でPHPが走って欲しいと思って sarge で色々設定してみたのだが、どれもうまくいきそうにないねぇ……。

  • 1. Apache module 版
  • 自明に駄目駄目。全部 www-data 権限。

  • 2. suphp
  • home の下では全然動かない……。

  • 3. FastCGI
  • これが最適解にほぼ近いかと思ったのだが、 実行権限の検査が wrapper-script に対して行なわれて、 実際の php スクリプトに対しては行なわれないので、 あるユーザで設定した php-fcgi に対して、 別のユーザが自分のスクリプトを割り当てられてしまう。 よって、結論としてはやっぱり全然駄目。

mod_fcgid を試してみるか。

(追記)

やっぱりだめですた orz

FastCGI を元にすれば技術的にはそこそこいけそうなんだけどねぇ……。 うーん……。

[Comp] VMware 5.5

早速入れてみた。なんか動作がきびきびした気がする。いい感じだ。

しかし、5.0 の時からNATネットワークの調子が悪くて、下りは70〜80Mbps 出るのに 上りが1.5Mbps以下という状態なのは変わらず。Cisco の VPN も繋がらないまま (ホストの側で non-promisc モードでスニファをかけてみると、 Checksum Error なパケットが出まくっている謎の状態)だし……。

問題の所在が NAT モジュールなのか仮想ネットワークインタフェースなのかが イマイチわからなかったので、試しに NAT 設定のまま、Linux ホストの方に IP masquerade を設定して、 内側のマシンのデフォルトルートを VMware の NAT 用 IP からホストマシンの vmnet8 内のアドレスに 書き換えてみると、上りが 50Mbps まで改善した。 やっぱり NAT かぁ……。VPN も無事解決。似たような症状って出てる人いるのかなぁ。

[Misc] 逆誕生日問題

$M$ 個の物を $N$ 個の選択肢の中から重複を許してランダムに選ぶときに、 重複が生じる確率が $1/2$ になるには、 $M$ がおよそ $M \sim \sqrt N$ のオーダであればよい、というのは、一般に 「誕生日問題」とか「誕生日パラドクス」と呼ばれている問題である。 具体的な話で言えば、40人のクラスなら1組は誕生日の同じ人がいる確率は かなり高い (89.1%) という話である。ついでに、$M > N$ なら 1組は必ず重複があるというのは、いわゆる鳩の巣定理。

では、$N$ 個の物から重複を許して $N$ 個を取り出したときに、 その中に含まれる物の種類の数の期待値はどれくらいだろうか、というのが 気になった。とりあえず「逆誕生日問題」と名付けてみる。 *1 オーダが O($N$) であることが強く期待されている気がするのだが、さて実際は どんなもんだろう……。ここでの目下の課題は、「誰かが解いていることを期待して文献を探す」 と、「文献を探す手間に比べたら比較的解きやすい問題であることを期待して自分で解く」の 2つの戦略のどちらが有利かという判断である。

追記 (12/2)

翌日以降の宿題にしようかと思って寝たらもう答えが出てた(笑)。 それも、昨日と違う方法で計算してみようと寝ている間に考え付いて、 起きて計算して、ふとみたら菊さんの答えが先に出てるし(笑)。

としさんの計算は、ちょっと打ち切る部分の論理が飛躍している気がするのですが……。 確かに正しそうなんですが、完全に一致していると断言する自信がない……。 結果がほぼ一致してるから正しいんだろうなぁ。ちょっと考えてみます。

で、なんの計算かというと、もうお分かりかも知れませんが、

$k$ ビットの乱数を $k$ ビットの完全にランダムな ハッシュ関数にかけると、結果は何ビット分の秘密情報になるか」

であります。この計算結果だと、$k$ がマトモな値の時 ($N = 2^k$ が十分巨大なとき)、 大体 $k - 0.66$ ビット分の秘密を持っている、ということでいいみたい。 まぁ当然だが問題にはならないんだね、というのを確認したかっただけなんですが。

*1 本当に欲しいのはこれの逆関数で、期待値を固定した時に必要な母数が知りたい。

本日のツッコミ(全4件) [メッセージを送る]

菊やん [私の適当な計算によると N - \frac{(N-1)^N}{N^{N-1}} になりました。 ]

とし [「n 種のくじがあった時何回引けば全部集めることができるのか?、その期待値を求めよ」 という問題を思い出しました。 ..]

とし [先ほどの議論は自分でも怪しいとは感じていたんですよね。 今度は大丈夫なはずです。 a回目の試行でb種類のものが含ま..]

菊やん [なにやら面倒な計算をしているようですが、確率論をかじってると真ん中の議論はさくっととばせます。 Nを種類の数として..]


2005-12-07

[Misc] おつー

これまでにないほど実装は障害無く進んでいるのだが、今日は実装と実装と実装と実装と事務と事務と事務と 打ち合わせと打ち合わせと………と、特に後半の作業は著しく不馴れなので、すっかり 疲弊してしまった。

うーん、こういうときは少し薬効成分を体に入れてぐっすり寝るか……と、氷結果汁グレープフルーツ缶を 買ってきたわけだが、いざ自室に開けてみると、部屋が寒くてガクガクブルブルでとても呑めたもんじゃない。

完全に選択を間違えたな (^^;;


2005-12-12

[Work] 英語

国際学会のホテルの予約のやりとりを電子メールでやっても全く埒があかなくて、 いよいよ部屋が売り切れてきたので、現地の朝を狙って国際電話攻撃………。

………敗退(ぉ

電話の音質が悪いのと僕の英語が悪いのが相まって全然話が通じないので、 結局要件をFAXで送ってから交渉する羽目に。弱い。

実際のところ電話の音質が酷くて、向こうが黙ってるだけなのか音信不通になってるのかわからないしねぇ。 お互いにハローって5回くらい言ってからやっと話が始まるとかそんな状態じゃ日本語でも交渉になりまへん。 自分の耳が壊れたんじゃないかってくらい受話音小さいし。

可能性としては (1) 構内PHS (2) 内線VoIP (3) 業務用callingカード(国内某大手通信会社の) (4) アメリカの国内事情 (5) ホテル内線 のどれかが悪いのだが、 2つのホテルと交渉して両方とも音が酷かったので、(5) はなさそう。また、 NTT直結回線からのFAXもマトモに送れるので、(3) (4) もなさげ。 あとは (1) か (2) か、あるいはそれらと何かが相互干渉してるかのどれかだなぁ。 今度は構内固定電話からかけるか (;_;/


2005-12-19

[Misc] TV会議システム

職場で大分前に発注していたのだが、今日やっと納入された。

業者が来る前に午前中に配線作業。パッチパネルに必要な配線を施しておく。 午後は業者が液晶モニターと共に設置。思ったより土台のサイズがでかいぞ。 モニター重いから仕方ないけど。

早速、所内(3kmほど南南西)と所外(400kmほど西南西)に協力者を得て接続試験。 ファイヤウォールの関係で相手先に応じて接続ネットワークを切り替えないといけないので、 ちょっとDHCPに細工をして、線を差し換えるだけで万事うまく行くようにしてある。

元の研究室 (1.7kmほど北北西) へはIPアドレスをお知らせしてお願いしておいたので、今度接続を試してみよう。 まぁ、必要なら30分あれば行けちゃうんだけど……。 上司は明日早速本部(45kmほど北北東)との会議に使うらしい。 これで研究上必要な相手は(↓を除いて)ほぼ尽くしているかなぁ。

あとは300kmほど北 (北北東?) の方々とお話しできるようになると便利なんだけどなぁ(とか言ってみる)。 相手方は実は Microsoft NetMeeting でもいいらしいので、試してみるか。

本日のツッコミ(全2件) [メッセージを送る]

おおたき [うちも最近会議システムを導入しました。分割窓で参加者の顔が見えるのが面白いですね。 声に反応して発言者を追うカメラの..]

西南西の協力者 [こんにちは.突然すみません. 昨日は無事つながってなによりです. そちらの皆さんとビデオチャ...じゃなくて 情報交..]


2005-12-22

[Misc] 勤務時間

…の今月の分をExcelにいれて標準偏差を取ってみたところ、1時間44分もあるんですが……。 我ながら酷いな(苦笑)

いやー、風邪気味とか師走の忙しさとか、いろんな意味でムチャクチャな1ヶ月だった。

一応年内に片付けなければいけない大きな任務は終わったので、あとは 師走らしからぬ平常の研究生活を3日送れば年末休暇の予定。


2005-12-23

[Misc] 結婚式

従姉妹の結婚式・披露宴に出席。

「どうしても入場のピアノを弾いてくれ」とのリクエストがあったので、譜面持参。 曲 (Schubert の Ave Maria) 自体はけして難しくはないのだが、 人前で弾くのは15年ぶりとかそんな感じ、 しかも発表会以上に失敗できない場面となると、 プレッシャー強いこと強いこと……。 数日前から、頭の中をこの曲が無限ループしていた(笑)。

挙式の前に披露宴会場に入って、音合わせというか、慣らし練習をさせてもらう。 会場の広さを見て、時間配分の想定もしておく。繰り返し2回目の途中くらいで 終わるんじゃないかと予想したので、何カ所か途中から Coda に繋がる短縮ルートを考えておく。

挙式後本番までは、控室が隣なのもあって、練習できず。 入場ということで、本番は宴席の一番最初。 弾き始めてみると、なんか予想よりえらくペースが速いんですけど……。 もう2人とも席の辺りまで来ているよ……。 というわけで、繰り返しの後に想定していた短縮ルートを、 繰り返し前に発動することになった。

大任を終えてほっと一息。ご本人や列席の皆様にも喜んでもらえたようなので、なにより。

公私共にこれで今年の巨大イベントは終了かな……。


2005-12-26

[Security] 文字コードとXSS

(書きかけ)

例によってセキュリティホールmemoより。厄介ですねぇ……。

  • キチンと全文書に文字コード指定をしておく
  • マイナーな文字コードで送信するときは、対応環境と影響を考えておく。 不安なら ASCII 完全上位互換の文字コード (ASCII の有効バイトは常に ASCII と同じ意味を持つ EUC-JP、UTF-8 など) を使う。
  • cross-site injection で META が埋め込めるとかは論外。

位は比較的簡単だし、やっておかないといけないかな。

で、ちょっと気になっているのとしては、とりあえず、UTF-7 はやばやばなのは明らかとして、 ISO-2022-* への派生している議論はちょっとずれている気がしている。 とりあえず、 Bugzilla.jp の 4868: ASCIIと互換性のない文字コードはユーザーの指定で選択可能にすべきでない は、ちょっと違うかなぁ……。 ユーザによる強制文字コード指定で脆弱性が生じるケースとしては例えば 星屑さんの日記に 示されているわけだが、これは「ISO-2022-JP を SJIS で解釈すると危険」という話なので、 この Bugzilla で提案される対策をしても意味がない(順序が逆)。 一般論としてはこの手の危険性をメニューからの削除で対策するなら、 EUC-JP とか Shift_JIS とか ASCII とかも禁止しないと対策にならないが、 それはさすがにちょっと的を外してしまう。

ASCII のバイト列を ISO-2022-* でうかつに解釈すると危険なケースというのは、 <ESC(Bscript> みたいなケースなのだが、これってもともと ASCII で安全か? と言われると、 未エスケープな文字が残っている時点でそもそも微妙……。 ISO-2022-* はある意味で ASCII 上位互換になっていて、主な問題は 「ASCII の特殊文字が文脈によっては特殊文字として扱われない」ということと、 上記のような元々微妙なバイト列がシーケンス消滅によって脆弱になるケースなので、 UTF-7の「ASCII の非特殊文字が文脈によっては特殊文字として扱われる」*1ケースとは取るべき対策が異なるのではないか。

ASCII や ISO-8859-1 の表示可能文字+単純な制御記号 (CR, LF, SPC, HT, FF) だけで構成された 未エスケープ単独文字を含まない正当な HTML 文書で、ISO-2022-* で評価すると危険な例は ちょっとまだ思いついていない。その点からも、とりあえず ASCII / ISO-8859-1 などで ESC(そもそも非表示文字だし)をキチンと処理しておいた方がいいのは確かなようで。 これをやっておかないとちょっと嫌らしい例は作れる。("ESC $ B" で必要な閉じ記号だけを隠してしまうとか)。 尤もそれを言い出すと、EUC-JP とか Shift_JIS とかでも、 解釈器の作りによっては不完全なコードで 1バイト食い潰すのは可能だったりするので、 微妙な場合を生じうる。 もうちょっと正しい言い方をすれば、「文字コード指定をしたときに、 想定されるコード体系での正しいコードでないバイト列を出力してはいけない」、 「ASCII/ISO-8859-1 強制指定をしない場合は、少なくとも全ての ASCII 上位互換エンコーディングにおいて 特殊な意味を持たないコード (表示可能文字+一部の安全な制御文字) だけを出力しなければならない」になるだろうか。

この「異常入力」周りは、いずれちゃんと実験してみないといけないなぁ。時間がいくらあっても足りない。

ちなみに、IE で ISO-2022-JP がメニューに現れないのは、 危険だからではなくて、むしろ自動判定で完璧に判定される (他の ASCII 上位互換文字コードと曖昧なケースは ASCII 文字だけからなる文書の時だけ) からではないかと思うのだが。

尤も、EUC-JP のように完全に ASCII と独立した部分だけに拡張文字を持っている文字コードは、 確かに安全性は高い。どちらももともとそういう用途(ファイルシステムへの適応など)を十分に想定して 作られているから当然なのだが。そういう意味では、無理に CGI の出力を ISO-2022-JP にするよりは、 charset をつけて EUC-JP にしておくのは正しい気がしている。UTF-8 については、仕様上は安全なのだが、 例の「冗長な多バイトエンコード」の問題について個々の実装に注意が必要か。 Shift_JIS は、HTML に関しては偶々特殊文字が 0x3f 以下に集中しているので、とりあえずは大丈夫かな。 CSS とかだと \ (0x5f) が嫌な感じかも。

あと、場当たり的で嫌ではあるが、ISO-2022-JP については、ASCII に変換(あるいは誤解釈)したときに 2文字以上の意味のあるタグに化けることを防ぐ方法は 実は存在したり (危険な文字の直後に ESC $ B を挟んでしまう) するのだが……。

この項、数日中にもう一回まとめます。

もうちょっと整理してみる。

とりあえず、本当は文字コードの全組み合わせに対してマトリクスを作るべきなのですが、 実際は ISO-8859-1 との二者関係の組み合わせにほぼ帰着できるので、とりあえずそれで考えてみます。

ISO-8859-1 の8ビットのバイト列を入力として、 別の文字コードで解釈したときに、次の可能性が考えられます。

  1. ASCII 部分の解釈が完全に一致し、GR 部分の文字の切り方も一致する
    • (ASCII)
    • ISO-8859-*
  2. ASCII 部分の解釈が完全に一致するが、GR の列は一部無効な組合わせになることもある
    • EUC-JP
    • UTF-8 (注)
  3. ISO-8859-1 可読範囲外のバイトの影響で、ASCII の文字だったバイトが、 ASCII 文字集合外の別の文字に解釈されることがある
    1. ほぼ全ての ASCII 文字が該当
      • ISO-2022-JP
  4. ISO-8859-1 可読範囲内の文字列が、ASCII 文字集合外の別の文字に解釈されることがある
    1. アルファベットと一部の記号に限る
      • Shift_JIS
    2. ほぼ全ての ASCII 文字が該当
      • UTF-1
      • HZ
  5. 何らかのバイト列が、元と違う ASCII の文字に解釈される
    • UTF-7

まず、1. や 2. のケースでは、ほとんど問題は生じません。2. のケースでは、 例えば < 0xa1 s c r i p t > のような列があったとき、 0xa1 を無効な文字として単純に除去してしまうと、ちょっと嫌な感じになりますが……。 UTF-8 については、「例のバグの問題」がありますが、まぁとっくに直ってると思いたいところです。

次に、3. や 4. のケースでは、次の3つの問題があります。 まず、上記の設定と逆に当該の文字集合で書かれた文書を誤って ASCII で解釈した際に、 本来無かった特別な意味を持ってしまう可能性があります。 先ほどの星屑さんの日記の例がそれで、 本来の ISO-2022-JP では特殊な意味がなかったバイト列が、ASCII では無効文字 ESC と多少の正当な文字と、 script タグに解釈されてしまいます。 尤も、4. の中でも Shift_JIS の2バイト文字には、HTML の特殊文字 " < > & に相当するバイトが含まれないので、 危険性は低減されます (但し \ に注意)。

また、タグ要素中にそのようなシーケンスが現れると、要素終了の " や > などが 吸収され、タグが閉じなくなる可能性があります。3. では非可読な文字が必ず存在しますので、 そのような文字をエスケープしてしまえば済みますし、Shift_JIS や UTF-1 でも 必ず GR のコードが含まれますが、HZ は嫌らしいところです。

また、ISO-2022-JP などでは、一部のバイト列が ISO-2022-JP では0文字に縮退することがあるため、上で挙げたような例 (<ESC(Bscript>)のように、ASCII で無効だった文字列が ISO-2022-JP で有効な ASCII 相当文字の列として解釈される可能性があります。 ISO-2022-JP の場合、このようなシーケンスは必ず特殊文字 ESC を含みますし、HZ などでは 必ずしもそうではありません。特に HZ では ASCII 可読文字の列 ~{~} が縮退する 可能性がありますので、選択的なタグ除去などをしている場合には注意が必要でしょう。 UTF-1 では (有効なバイト列では) この問題はないはずです。また、無効バイト列の問題は 2. と同様です。

最後に、5. のケースは、今回の問題にありましたが、かなり対処が困難です。 自動判別されてしまうと、完全にASCII可読文字が別の解釈を持ってしまうので始末が悪いです。 この場合、「ブラウザはこのような文字集合を自動判定の候補とすべきでない」といえるでしょう。

*1 さすがに ISO-2022-JP において、X0208 の < がタグ開始記号と同一視されるって実装は聞いたことがない。


2005-12-27

[tDiary] 「編集」「追記」ボタン

tDiary を使っていると、当然一般読者の画面でも常に「編集」「追記」ボタンが出ているのだが、 僕的には(セキュリティではなくて)UIデザイン的にちょっと気持ち悪かった*1ので、 ちょっと細工をしてみた。 というわけで、みなさんに表示される画面からは当該ボタンが消えているはず。

実際のところ、「追記」ボタンは別にURL直打ちでなんとかなるのだが、 「編集」ボタンはちょっと欲しかったので、Cookie を使って細工している。 中身をみりゃ判る通り、な〜んの秘密もない "0" だけの内容の cookie を1つセットしているだけなので、 あくまで「見た目」だけの変更*2。 当然ですが、初回は追記/設定画面への直接の入り方を知らないとどはまるので、要注意(笑)。

追記 (12/30)

「"navi_user.rb" で解決?」について。ソース見てもらうと判りますが、実質的には cookie で navi_user と navi (navi_user + navi_admin) の切り替えをやっているだけです。 「読者向けには navi_user を表示したいんだけど、自分は navi_admin のボタンも表示されてないと困る」という 欲張りな話なのです。ま、navi_admin は目立たない別のところに移動しておく、で十分という話もありますが……。

*1 押してはいけないボタンがあるUIってなんか生理的に嫌だよね? 自爆ボタンなら燃える人がいるかも知れないけど :-)

*2 むしろ変な細工がない方が判りやすいし、セキュリティ機構だと勘違いする人も(きっと)出ないよね?


2005-12-29

[Comp] [Security] 自動quoteつきERBの実験

高木さんの日記で、

そうすると、「h」付きと「h」無しを逆にしたらよかったのにと思えてくる。

ということだったので、ERB を改造してサクッと作ってみた。 rerb

とりあえず、h の意味を逆転させてしまうと(hを流用してしまうと)それはそれで 混乱すると思ってそれは避けたのだが、高木さんは「hの逆」を命名してくれなかったので、 とりあえず "raw html" ということで r を使った。何かいいアイディアはないものか。

ついでに、rerb-cgi という名前で起動された場合は CGI モジュールを内包して、 ローカル変数 cgi, header 経由で引数や出力ヘッダにアクセスできるようにしてみた。 そういうわけで、test.ehtml は (rerb-cgi という実行ファイルを用意すれば) 単独でcgiとして動作して ……/test.cgi?q=%3c%3d%3e%3f&p=2nd+param とか起動しても ちゃんと quote が行われるような例になっている。

内部的には、Ogawaさん

で、やっぱり思ったのは、PHPにしろPerlにしろSQLにしろ、String Processingの範疇にあるプログラムは、ほとんど常に処理中の文字列が指し示す「型」を意識しなければ作れないにも関わらず、最もベーシックな型である「文字列型」だけを使って実装されていることに、一番の問題があるのではないか、ということです。

とか、この「こめんと」その他でも何度となく「HTML と String は違う型だと思え」とは主張してきたわけですが、 それをちょっとだけ踏まえて HTML 文字列型は RERB::Rerb_html という型で実装されていたりします。 (というか, r 埋め込みを実装するには今の ERB/Ruby を前提にするとそうせざるを得ない)

実際に作ってみると、本当はもっと強く型を意識して言語から設計しないといけない気もしてきたり するのですが、それはおいおい研究ネタにでもすることにして、quick hack としては 結構面白いものができたかな、と思ってみたり。あ、header 部分の RHS 対策とか、 attribute を single quote で括ったときの処理とか、 「これを使えば万全」になるような細工は全然してないので気をつけてね :-)

ちなみにライセンスですが、元のERBと同じ Ruby ライセンス(GPLと独自のdual)にしておきます。 逆にする部分のアイディアを除けば実装は結構な部分が ERB の切り貼りですし。継承で何とかなるかな……と思ってたのだが 実際はかなりの部分をコピーアンドモディファイにする羽目になってしまった。

[Comp] 平民的プログラミングのススメ

高木さんの日記『「サニタイズ言うなキャンペーン」とは何か』から、セキュリティと(直接)関係ない*1方向に派生。

いまどき、そんな貧民的プログラミング思考をするのはプログラム職人として恥ずかしいことだ。

……それはその通りなんだけどね。実際、高木さんの書いている通り、 あの日記中の例で「id と postdate は HTML のメタ文字が含まれないから、 htmlspecialchars を通すのは勿体ない」、みたいな感覚は、いまどきの コンピューティング環境を考えたらみっともない。 実際 htmlspecialchars 通したところで1ms *2 も処理時間変わらないだろうしね。 そういう意味で、貧民的プログラミングはやめよう、というのは正しい。

しかし、個人的に最近気になってることとしては、 一方でやたらと富豪的プログラミングが度を過ぎていて、 プログラムが機能として破綻していることもよく見掛ける気がするのだ。 破産的プログラミングとでも呼ぼうか。

例えば、こういうところで例に出すのは申し訳ないのだが、 tDiary のアクセス回数やアクセス元の記録処理。単純に月単位のDBを PStore や (索引構造のない単純な) テキスト形式で 書き出しているので、アクセス回数 n に対してトータルで少なくとも n2 以上のオーダの IO処理がかかっている。実際、 アクセス数が5桁になるとカウンタ周りは破綻し始めるようだ。 *3 で、本質的に中でやってることは何かというと、当該アクセスに関係ない部分のデータを毎回毎回コピーするという なんか穴を掘っては埋めているような処理。確かにこの手の (PStore のような) 機能、使うとすごくプログラムが楽に書けるのだけどね……。

追記 (1/2)

アクセス回数 (PStore) とアクセス元URL (独自形式テキスト) が混乱しそうな文章になってたので修正。 もっとも、アクセス元記録も O(n2) の重〜い処理になっていることは変わりない。

そういうわけで、僕は「富豪的プログラミング」という言葉は (↑のような誤解に基づくプログラミングを招くので) あまり好きではない。 やっぱり緻密な計算量評価に基づいた最適な処理が物を言うことは多いと思うのだ。

僕の基本的な考え方は、「一番性能に影響する入力サイズ n」というものを考えて、 最適な実装をしたときの計算量から定数倍(1桁)または O(log n) 程度しか変わらないなら、 奢ったプログラミングを許容する、という感じ。一方で入力サイズが小さいと判っているものに関しては、 徹底的に楽で綺麗なプログラミングを奢る、というような感じかな。

例えば tDiary のようなシステムを自分で作ることを考えるなら、日記の更新は高々月100回程度(推敲含む)だし、 サイズも高々月数十エントリ、100kB〜1MB程度であることが想定されるので、 その辺の更新処理に関しては、特に最適化はしない。 *4 今の td2 ファイルみたいに、そこそこ扱いやすい形式で月単位でまとまっていたほうが 利便性が高いと思う。(読込のことはちゃんと考えたほうがいい気もするけど、 まだソースちゃんと読んでないのでパス。) 一方で、読者がアクセスしてくる回数は性能上かなり効いてくる箇所なので、 一回のアクセスにかかる処理量がアクセス回数 n の1乗以上にならないように設計する *5と思う。 実際、Referer の記録やアクセスカウンタの処理は、適切なDB構造を使えば 1回当たり O(log n) の計算量で抑えられる*6(つまり、全体では O(n log n) になる)はずなのだから。

この手の「奢るべきでない場所をちゃんと考えるプログラミング」こそが本来の富豪的 *7 プログラミングだと思うのだが、言葉の響きに「抑制的」なものがないのがよろしくないのだろうか。というわけで、 「無駄に金は使わないけど、奢るべきところでケチケチして後ろ指さされたりはしない、 ごく普通のマットウな社会人としての生き方」と対比させて 表題の「平民的プログラミング」となるわけだが、いいネーミングは何か無いかな。

*1 厳密に言えば、Denial of Service 対策などと絡むので、全く関係ないわけではない。

*2 追記 (2006-01-02): とりあえず、手元の php4-cgi で、実際に10文字程度の文字列を htmlspecialchars にかける時間を測定してみた。 ……約 1us と出ました。全く省略する意義ないですねぇ ;-)

*3 ちょっと直そうかとソースを見たのだが、結構構造を大きく変えないと直らなさそうなので、 tDiary 本家の開発と同期しないと怖くて直せなかった。dbi-io での猛烈なSQLアクセスとも関連してそうなんだけどね。

*4 ちなみにこの日記、通常表示は FastCGI 化してあるが、更新側は通常CGIの update.rb のまま。 更新処理で1回当たり0.5〜1.0sec 程度を削っても全く意味がないので、こうなっている。

*5 実際問題として、日記表示側はマシンによっては定数項が重要になったりする……。 この日記程度のアクセス数でも、FastCGI 化による定数時間削減の効果はある。

*6 但し、リンク元の種類数が アクセス数に比例して増えたりはしない場合に限る。

*7 よくよく考えたら社会的に立派な富豪の方々って、別に何でもかんでも無条件に財布が緩いわけじゃないよねぇ。

本日のツッコミ(全7件) [メッセージを送る]

Before...

おおいわ [一方で、昔他人に「ASPって何が嬉しいの?」と聞いたところ、「<% %> をタグとしてみたときに、HTMLそのものな..]

おおいわ (admin mode) [ちなみに、元々のツッコミのメッセージのURLに間違いがあったので、修正させて頂きました。 ああ、テキスト形式ってこう..]

 [ERBはHTMLじゃないところでも使うものなのだけど、HTMLに依存したモードがあったらうれしいのかしら。かっこいい..]

おおいわ [> ERBはHTMLじゃないところでも使うものなのだけど、 一応それは承知しています(笑)。ただ、HTML 出力前..]

 [DivやRailsなどERBをライブラリとして使うものの多くはフレームワーク(?)が生成したHTML片を挿入すること..]


大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)