はてなキーワード: mod_rewriteとは
※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。
マネージャ「たぶん2週間ぐらいでできますよ!wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です!」
デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」
.... 略 ....
上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない?」
マネージャ「違うんですよ!デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたんです!たぶん自分だけだったらこんなに時間かなりませんよ。」
デザイナ(「XHTMLになってない!」とか余計な所に口突っ込んできやがって!)
プログラマ(PHPなんて簡単だよとか言ってJavaプロジェクトからコンバートさせたのテメーだろうが!)
原因
マネージャ「このスケジュールなんだけど、テスト期間長過ぎじゃない?」
プログラマ「え、でも機能もこれだけありますし10日程度は妥当かと」
マネージャ「いやいや、画面たったこれだけじゃない、通しのテストなんてみんなでやれば1日ぐらいで終わるでしょ?」
マネージャ「俺がレビューしてるんだからそんなでかいバグ出るわけねえだろ。ナメてんのか」
.... 略 ....
プログラマ「セキュリティ周りのバグもあるので、修正には3日程かかると思いますが」
マネージャ「ふざけんな!テストは今日で終わるスケジュールだろ!」
原因
プログラマ「前のプロジェクトでgitを使って便利だったので、今回のプロジェクトでも使いたいのですが…」
マネージャ「バージョン管理とか使ってるの?あんなの効率悪くなるからやめたほうが良いよ」
マネージャ「前に俺がやってたプロジェクトではフォルダで日付ごとに管理してた。同じ風にすれば大丈夫だろ」
マネージャ「古いフォルダからファイルをコピーすればいいだけだろ。馬鹿か」
.... 略 ....
デザイナ(間違ってファイル上書きしたのは黙っておこう)
プログラマ(ローカルにgitリポジトリあるのは黙っておこう)
原因
マネージャ「何このCodeIgniterっていうの?」
プログラマ「あ、それ最近流行ってるPHPのフレームワークで、URLのルーティングが…」
マネージャ「はぁ!?フレームワークとか使わないと開発できないわけ?これだから最近のゆとりはダメなんだよ。」
プログラマ「でも、便利ですよ?」
マネージャ「俺のプロジェクトではそういう怪しいやつは使わないから。バグがあったらお前責任取れるの?」
.... 略 ....
マネージャ「どう、俺の書いたURLルーティングライブラリすごく便利じゃない?」
マネージャ「あー、それは仕様だからしょうがないよ。mod_rewrite使えば問題無いでしょ?」
プログラマ(他人が再発明した車輪のバグを修正するのって本当に不毛だな…)
原因
支えてくれる家族または友人がいない場合、社会的な制度が整っていない以上、今の環境を逃げようが結果的には死にたいであるから、さっさと今の辛い環境を受けいれろ
が理解できないからその帰結の理由を教えてほしいといっただけなのですが...論点がずれているようですね?
プログラマーとしてはどうなんだろう。
ぜひ上を
プログラマーとしては彼の著書を二冊ANSI Common Lisp、On Lisp、後半は2回読み直すと考え方が変わると思います
またLispでWebサービスを作る意義は当時はあったのだと思いますが、今ではメタ言語でプログラムを生成することが一般的になって
きておりマクロの有用性、Slimeの素晴しさ、最適化ヒントのための機構が言語に内包されている点以上に特別な認識はしておりません
ただリーダマクロを利用すると構文自体を拡張することが出来るためLispを書く人はすべからく言語設計者としての腕が試されるのだと思います
(といっても私は本物のLispプログラマーではなく初〜中級者の域程度のものと認識しているため上級者以上の方はまた違う見解なのだと思います)
正直なところ、一時期自分もLuaに感動して、Luaで(mod_lua?)Webアプリを書こうとしたときもあったけど、RailsやCake、Nodeのexpressみたいなのでさえ、多くのユーザーが書いている方法の方が同じ悩みにぶつかり、googleすれば誰かがstackoverflowで解決しているので、コピペで取り敢えず乗り切る可能性が高くなる。
が、mod_luaに関してはガチレスしますと、Apache のpre post filter, mod_rewriteの煩雑さ軽減、Access,Auth,UserCheckのpre post、CustomLog置き換えくらいに試作品として個人だったら利用すると思います(プロダクションレベルならば実際利用する前に検証すると思います) mod_luaでもいいですが文章は何が目的かをはっきりさせて書いてください
後半のRails、Cake、Nodeでも同じで、「形にすることが目的」であれば、コピペ出来るものを御自分でえらべばいいのじゃないのでしょうか?なにが主張したいのかよくわかりません
# ゲームなどのアプリケーション内で使う言語はシンプルが一番だ。それはBASICやTclのように、美的には醜いものでも正解になることが多々ある。
# lispを選ぶのは正解だと思う。
TclをVHDLのシミュレーションツールとして数年利用しましたが、美的に醜いものではありません そしてなによりもゲームと一括りにしておりますが近年のゲームプロダクションを「舐めないでください」???Lispを触りもしないのに正解だと思うなども???
そんなことを最近のApple製品やGoogle製品の苛立ちとともに感じ、自分の人生の終焉や世界の終わりに思いを馳せながら今日もコードを書くか、身辺整理をするか、絶望感を眠ることでかわす毎日を送るだろう。
現実ではなく煽り文章だと理解しているつもりなのですが、中身がよくわからず何を伝えたい文章で帰結はなんなのかが大変よくわかりませんでした
酷い会社に就職するとブール演算さえまともに理解していない人たちが、銀行や年金のコードを書いている日本の恐ろしさに驚かされる。
金に困って、私もときどきバイトを探すのだが、バイトで地方銀行のプログラミングとか書いてあるのが普通の日本はちょっとおかしい。
多分、証券会社とかの方がまともなコードを書いているのだと思うが、精神的にはキツい気がして門を叩いたことはない。
もう、年齢的にも限界なんでね。
テクノロジーや数字に対して無知な文章と思えるようなことを主張しているようにしか理解できないことがひっかかります。他人は他人ですし変えることは出来ません。ですが自分の考え方はいくらでも受けとめかたは変えられるのではないでしょうか?
別にPerlでなくても、シェルスクリプト、Cでも構わないけど、所詮CGIだし、正規表現とか文字列に明るいから、打算的な面もあったんだろうと思う。
考えてみれば、あの頃は負荷についてあまり考えてなかったよな。
根本的なコンピュータの仕組みの理解が食い違っている認識なのですが、当時負荷を考えたときスケールアップをしていた理由は、「1台」のマシンと「2台以上」のマシンを管理する方法がまったく別のスキル(コスト)を要求するからです 現在ではフェールオーバだけでなく、冗長化の考え方が広くオープンソースの世界でプロダクションレベルに適用されたためであって、当時から負荷自体については考えている所では考えていました
また所詮CGIという意味では標準入出力さえあればどの言語でも出来るのは事実かと思いますが一方Lispだから打算というのは異なるのではというのは上の文章を読んでいただければ
エッセイのどのことを示唆しているかは不明ですが「成功している理由」を考察していることはあっても(時系列でいう後ろから前への考察)、「こうすれば成功する」という考察(時系列でいう前から後ろへの考察)について伝えてる文章は知りません よろしければその文献情報はどこにあるのでしょうか?
あの頃に成功しなかった人(つまり、私)はもう浮かばれることはないだろうし、今、彼らが言うようにやったとしても、あまり夢がないというか、生きてくのもどうだろうという気がしてならない。
誰も失敗した人の発言には耳を傾けないからね。
人生というのは、確かに一定の年齢を過ぎると選択の幅が狭まるというのは事実ですが「なくなる」というのは嘘です そしてそもそもその歩いてきた道だけは変えることは出来なく、これからの道は落とし穴かもしれませんが90度直角に歩くことさえ出来るものだと思います
また失敗した人の発言に耳を傾けないわけではないと思いますよ?むしろ否定的な感情を表に出しすぎるために難しくなってるのではないでしょうか?
この考察はその通りだと思いますが合理的ではないでしょうか?前回もお伝えしたように株式会社なのであれば株辺りの利益を最大限にすることが目的です また会社というのは民主主義ではなく株主主義です それさえ理解すれば組織の維持=経営者が優先されるのは当然なのではないでしょうか?従いまして「人間的に正しい」の意味を理解していませんが、あなたのいうその「人間的に正しい」と「組織の目的」との間で落とし所をつけ提案することが本来の従業員の仕事に含まれると理解しています。
支えてくれる家族または友人がいない場合、社会的な制度が整っていない以上、今の環境を逃げようが結果的には死にたいであるから、さっさと今の辛い環境を受けいれろ
長々と書きましたが、上の内容を簡潔に聞きたいだけでして、ブール演算やらLuaなどの話は聞いていません ブール演算などは高校生に3時間でも教えれば理解する人はいるでしょう
もう、いいおっさんの年齢なんですが、先日、とあるWEBサービスを公開しました。
5年ほど前からぼーっと考えていたんですが、如何せん、事務職の自分には”創る技術”が無かった。
優れた若い技術者(id:amachangとかうらやましい)や、チャレンジ精神あふれる経営者(id:hiroyukiegamiとか)が出てくる中うつうつとしている自分に嫌気がさし、4か月前の7月頃からHTMLやプログラムの勉強を始めた。
本屋で立ち読みしたら、まずはHTMLを勉強する必要があると、書いてあった。同時にCSSを学んだ。
プログラムを作りたかったので、次にJavascriptをやった。
jQueryがすごい。「プログラムって誰でもできるんだ。」この時そう思った。
検索システムを作りたかったので、本屋に行ったらCGI/Perlの本がいっぱいあったので、Perlを勉強した。
しかし、HTMLテンプレートが使いたかったのでPHP+Smartyを勉強した。
作りたかったWEBサービスは大手サイトのデータの検索サイトだったので、自動でデータを集める必要があった。
PerlのLWPを勉強したが、データを集めた後に加工する必要があった。簡単そうだったRubyとMechanizeを勉強した。
Rubyはものすごくきれいにプログラムがかけることを知った。話し言葉に近い気がする。
プログラムを作っている時、最初は自分のパソコンの中でやっていて気付かなかったが、実際に公開するときはレンタルサーバーを使うというのを知って調べると、Linuxのサーバーが多いということを知った。
だから、今度は自宅のあいているパソコンにLinuxを入れた。
Linuxを入れたはいいものの、全く使い方が分からず四苦八苦してRubyのインストールをした。
世界中でメインで動いているWEBサーバーがApacheということも3か月前に知った。
Apacheの設定がテキストファイルなのも驚いた。cd,ls,vi,mv,cp,chmod等、基本的なUNIXコマンドを覚えた。
例の図書館の事件があったので、クローラーを動かすのをためらったが定期的にちょっとずつなら怒られないんじゃないかと、Crontabを勉強した。
自宅のサーバーが壊れてしまい、構築が大変だったので今度はVPSサーバーを借りた。
同じように構築はしたがかなり苦労した。このとき、始めてmakeというコマンドを使った。コンパイルというらしい。
クローラーが自動的にデータを集めていたが、動かし始めて2カ月目でデータファイルが1GBを超えていることに気がついた。
このとき、テキストファイルでデータを扱おうと思っていたが大きすぎて動かない。
最終的にデータ量は5GBを超えた。
11月も後半、本稼働用のサーバーを探していたら、丁度カゴヤがVPSサーバーのベータ版を募集していた。
すごく、快適です。まだベータ版ですが、本番稼動でも、50GBで900円という激安プランです。
http://www.kagoya.jp/cloud/vps/
ベータ版では、3つまでOSのインストールができます。もちろんそれぞれにIPアドレスが振られます。
このVPSにサーバー管理システムをインストールし、もろもろの環境も作って、11月末についに、公開。
AV女優をスリーサイズから検索できるシステム、「完全に一致」です。
類似検索機能付きで、2次元と3次元をつなげる夢のシステムです。はい。
真剣に作ったんだ。仕事をしながらよく頑張ったと自分をほめてあげたい。
----------------------------------------------
インターフェース:jQuery+selectToUISlider
-----------------------------------------------
サーバー上にある静的なHTMLは1ページもなく、mod_rewriteですべてPHPが処理しています。
一番大変だった事は、、、
このサイトのデータはDMM社のデータを使わせてもらったのですが、AV女優の顔写真をそのまま使うのは、肖像権的にNGらしく、AV女優の作品の中からその女優の顔が一番大きく写っているパッケージを使うことにしました。
しかし、女優データは約5万件。作品データは12万件。とても手作業でやるわけにもいきませんでした。
結局どうしたかというと、Face.com(http://face.com/)という、画像の顔認識ができるAPIを無料で提供しているサービスを利用しました。
同様のことができる、OpenCVというソフトがあるのですが、最初から付いているパターンデータでは人の正面の写真しか顔として認識しませんでした。
それに比べて、Face.comの認識精度は驚くほど高く、横だろうが斜めだろうがかなりの精度で顔を認識してくれました。
データをJSON形式で返してくれる(JSONもこのとき初めて知った)為、取得したデータを後で加工しやすかったです。
1.このAPIを使い12万件の作品データをすべてスキャンするプログラムを書く※1
2.顔の縦の長さと横の長さを取得
3.縦×横で顔の面積を計算
6.その女優の作品の中で顔面積が一番大きなパッケージ写真をその女優の顔写真として代用しました。※2
※1 APIの制限が1時間1000リクエスト迄だったので、これまたCronで・・・
※2 実際には女優テーブルと作品テーブルを繋ぐ中間テーブルのフラグをONにした。若干の間違いはあるものの、かなり正確に出ました。
長々と書きましたが、ズブの素人から約4ヵ月でここまで出来ました。
勉強する前、SEをやっている友人に話したら、「3年はかかるんじゃないか?」と言われましたが、できたものを見せたら褒めてくれました。
WEBサービスを作りたいと思っていて、技術がないからとあきらめている人は、とりあえずやってみてください。意外に簡単にできますよ。
あと、クローラーが動いていると、全能感を味わえるので楽しいです。
-----------------------------------------
19:30追記
サーバーソフトからアラートが上がって、見てみてたらなんかすごいアクセス貰ってまして。
>カゴヤの中の人乙wwww VPSといったらさくらかServersManくらいしか選択肢が無いのは現状当然の認識であるはずなのに!
カゴヤの人間じゃないですよー。広告してるつもりもないんですが、ベータ版だからかもしれませんけど、すごい快適ですよ。今は。
何よりタダなので。
本当に月額900円のまま本公開になったら、環境構築もめんどくさいのでそのまま契約しちゃうかもです。
>カゴヤはOpenVZだからなあ。俺としてはより自由度の高いさくらのVPSをお薦めしたい。
そうなんですか。2週間のお試し期間はつかったのですが、正直どっちがいいとかわかりません。
どんな風に自由度が高いんですかね?あと、アダルトOKなんですっけ?
>組み立てるプログラミングは本当に簡単だよ。 みんなで入り口を隠しているだけだよ。 #組み立てるだけじゃなくて、アルゴリズムを練ることが真のプログラミングかもしれない
サンプルプログラムの組み合わせで作ったようなサービスですので、プログラムのソースとかぐっちゃぐちゃです。
もともと、作ろうと思ったきっかけなんですけど、
椎名舞さんがですね、すでに引退しちゃってるんですよ。ずいぶん前に。
それで、検索エンジンで検索したんです。でも、なかなか出ないんですね。
欲望のままにやってたら、次から次に壁にぶち当たって、そしたらいつの間にかできました。
結果、このシステム使って椎名舞さんのプロポーションに似たAV女優を探すと、
雛乃つばめさんとか、果梨さんとか、佐伯さきさんとか既にDVD持っている女優さんばっかりヒットしちゃうんですね。確かに似てるんです。スタイル。
とくに最近の細い子は。
あ。デザインは、某企業をパk、じゃないリスペクトさせてもらいました。
-------------------------------------
23:55追記
寝てたらサーバーからアラートメールが携帯に飛んできておこされました!
こんな瞬発的なアクセスを考えていなかったので、とりあえず再起動しました。
-------------------------------------
12/4 01:45追記
何度再起動してもサーバーが反応しなくなるので、うぎゃーってなってたのですが、
親切な方が「MySQLサーバーが原因じゃね?デフォルトだろ?query_cache_sizeを設定したらいいよ。」とわざわざお問い合わせからアドバイスくれました。
設定してみたら驚くほどつながりやすくなりました!
同じSQLクエリーを保持してくれるらしく、実際にデータ検索を行わないので高速になるそうです。こんなの知らなかった。ありがとうございました!
プログラムはサンプルがあるからどうにかなるんですが、サーバー周りの事が全然わかりません。。。。ぐうぅぅ。。。。
おやすみなさい。
-------------------------------------
ブックマークコメントもらっていた事を別の日記で説明しました。
http://anond.hatelabo.jp/20101206224349
-------------------------------------
なるほど。ただ、ファイル名をView.AccountOK.phpという形にしなくてもファイル構造を
(非公開ディレクトリ)
/template
account_ok.tpl
account_off.tpl
/view
account.php
(公開用ディレクトリ)
/html
としても良いわけだよね?どのテンプレートを読み込むのかは、account.php内で分岐させるとして。
あるいは、index.php?view=account&act=ok みたいに追加パラメータを入れるとか。
俺としては、例えmod_rewriteを使うと言っても
http://test/view/account/username/hogehoge/param1name/value1/param2param/value2
2chレン鯖板スレッド+http://f43.aaa.livedoor.jp/~sils/参照、レン鯖板の各スレより拾った。
ぐぐって見つけたコチラも参照した。http://arekore.hp2.jp/pay/
あくまでCMSツールを使用して一から同人サイトを作りたい+サポート、メール、コントロールパネル、アクセス解析は無くていい人向けです。
順次[試用しての感想]追加予定。特に記載が無いものは使える/出来る項目。
■条件(上から下へかけて優先順位が下がる)
- 月額1000円以下
- 同人を公式に許可(同人アダルトの可否/あくまで字書き18禁+局部修正でギリギリ可向)
- MySQLが使え、バージョンが新しい[試用しての感想]
- mod_rewriteがインストールされている
- PHPバージョンが新しい
- .htaccessが使える
- CGIが使える
- sendmailが使える
■以下備考
残念ながらさくらインターネットが総合的に見ていいのかもしれない。
サイト毎にDBを分けたいとかセーフモードやら、同人という壁は大きい。
phpMyadminは自分でインストールする。鯖によってphpとMySQLのバージョンが違うので面倒。
mod_rewrite使えない。
セーフモードなのでWPの自動アップデートが出来ない。DBが十つ付いている。
WP設定が楽。DB鯖は当たり外れ有。[個人的には重いと感じる]
上位にチカッパ等あるがこちらは規約に同人が触れられていない。
バックアップ機能有(大概の鯖は規約で、サーバ側でデータを消失しても責任は負わないと記述)
試用無し。MySQL使用不可
容量100MB
独自ドメイン不可
容量200MB~
海外鯖
永らく募集が止まったりする
DB無制限
試用無し(ただし14日間までならクーリングオフで、手数料15%引きで返金有)
レスポンスが遅い(入金確認等)
試用無し。
女性専用
容量50~100MB、独自ドメイン可
DBが十つ/無制限付いている。
DB鯖は当たり外れ有、だがさくらと違い鯖間移動が簡単に出来る。
miniの方が共有相手に業者が少ない為軽いらしい。
無料でも出来る所は多々あるので触れないが、今まで使ってきた鯖感想
最低限ファイルのアップロードや設置が出来るレベルでないと厳しい。
サポートはほぼ機能していないので自分で調べて自分で全部設定する。
ただし出来る事が多いので、中上級者向けには最適。
コントロールパネルやファイルアップローダ、アクセス解析付き。
見てる限りでは落ちたのを見たことがない。
フォーラムには初心者が溢れて和やかなのでデビューにはいいかもしれない。
鯖管に特徴があるので人を選ぶかも。
MySQLが使えないが、人数が少ないので快適。同人アダルトOK。
審査制。
規約は同人に寛容だが、初心者お断り。審査制だが相当でないと落ちることは無い。
コントロールパネル、アップローダ等は一切無いがxreaのように必要なものは揃っている。
たまに落ちる。個人的にここのDB鯖はさくらより軽快だと思う。
WordPressでブログ(というよりは、データベースに近い感じ)を続けて半年。
WordPressを入れてしばらくは、楽しくてしょうがなかった。
記事が書きやすいのなんの。プラグインも色々あって楽しいし、デザインを入れ替えて四苦八苦するのも楽しい。
一番楽しいのは、コメントの「スパム」ってリンクを選ぶと、しゅわーって消えていくところ。すげー! なんかゾクゾクした。たぶん俺は変態だと思う。
でも、それからしばらくすると、違うところが気になりだした。
遅い。遅すぎる。
だって、ローカルからアクセスしてもページ表示に2秒かかるんだよ? リモートからだと間違いなく3秒は掛かる。デッドライン。死ぬ。いや、死ね! 愛してる! >貧弱サーバ
ダイヤルアップの頃に画像非表示で快適なネットサーフィン(死語)をやっていた俺からすると、いくら便利だからってこれは許容できん。ブロードバンドで「速度がはやい」のに、「時間としては早くない」とは何事。
というわけで、色々やってみた。
そしたら、ローカルから1秒弱、リモートからも2秒以内(たぶん)で表示されるくらいに改善。
一番驚いたのが、AdSenseの収益が1.5倍になったこと。PVは2倍以上。うはうは。
やってみたことをまとめてみる。
最初にやってみたのがmod_cache。phpなんか呼ばずにApacheで処理してくれと。
あれ? 動かない。 ふむふむ、Last-Modifiedを付けろと…
あれ? 動かない。キャッシュファイルは出来上がってるみたいだけどぜんぜん早くならない。
結果: ぐぐってみると、mod_rewrite + mod_cache の組み合わせは不可でした orz パッチ当てればいいらしいけど、めんどい。
プラグインでキャッシュだなんて、WordPressどんだけ自由度高いんだよと思いつつ。
結果: ちょっと早い… かな? イマイチだと思ったので計らなかった。
当たり前にされているらしいけど、今まで全く気にしてなかった。常にキャッシュさせた。
結果: 0.3~0.4秒くらい早くなった。パケットキャプチャして確かめた。
WP-Cacheと相性が悪いとか悪くないとかなので、WP-Cacheを外して実験。
結果: 0.7秒くらい早くなった。これもパケットキャプチャして確かめた。
ページそのものとか、ローカル環境では無関係なんだけど、「体感速度」と「ロード終了」も早くしたかったので。
MySQLクエリキャッシュ + APC。これで1秒ちょっと早くなった。
ローカルからの表示時間は半減。おまけの効果で、体感的にはもうちょっと早く感じる。
HTMLを読むのと比べれば圧倒的に遅いんだけども、以前と比べてかなり早くなったので満足。
しばらく放っていると、AdSenseの収益が増えていることに気付く。しかも1.5倍に。
PVも増えてる。いや、PVが増えたぶん、AdSenseの収益も増えてる、と言うほうが正確か。
…お前らどんだけせっかちなんだよ!
でも色々嬉しかったので許す。
■X-Reproxy-Cache-Clear できる Perlbal プラグインCommentsAdd Star
■[Perl][CPAN][Perlbal] X-REPROXY-CACHE-FORを使いたい人向けショートBK
X-REPROXY-CACHE-FOR ヘッダが Perlbal に(というか Perlbal::Cache に)どのように解釈されるかというと、
1467 sub add_to_reproxy_url_cache {
1468 my Perlbal::Service $self;
1469 my ($reqhd, $reshd);
1470
1471 ($self, $reqhd, $reshd) = @_;
1472
(snip)
1484 my $hostname = $reqhd->header("Host") || '';
1485 my $requri = $reqhd->request_uri || '';
1486 my $key = "$hostname|$requri";
1487
(snip)
1496 $cache->set($key, [$timeout, \@headers, $urls]);
1497 }
こうなってる。ここで、
Perlbal -> mod_perl -> MogileFS
こんな風に、フロントに Perlbal, バックエンドに mod_perl ハンドラでも置いて、その裏の MogileFS とやりとり(をあんまさせたくないので Perlbal に直にキャッシュさせたい)という構成を考える。
この場合、
つまり、
X-REPROXY-CACHE-CLEAR: /artwork/12345
というヘッダを mod_perl から Perlbal に返す必要がある(host は補われる)
この /artwork/12345 というリクエスト URL は、 mod_perl 側から直に参照できない。
mod_perl ハンドラを例えば以下のような conf であてていたとすると、
<Location /example/artwork>
PerlHandler Example::Artwork
</Location>
RewriteEngine On
RewriteRule ^/artwork/(.*) http://127.0.0.1:8080/example/artwork/$1 [P,L]
ここで $r->uri をとると /example/artwork/12345 となり、これをそのまま X-REPROXY-CACHE-CLEAR で返しても Perlbal::Cache がキャッシュした key とは違うものなのでキャッシュを破棄できない。自前で $r->uri を split なりして、 /artwork/12345 を、 Rewrite される前の URL を知る必要がある。当然、どんな RewriteRule かに依存するので一般的な実装はあげられない。 Rewrite しなければもう少し話が簡単になる。
要は、
と、それぞれ意味の違った URL (key になるもの)がいくつか存在して、どれがどれやらわからなくなってしまうので、ハマりどころが多い。ありがちな(というか俺がやった)ミスとしては、 CACHE-FOR でキャッシュした状態で MogileFS からファイル実体を消してしまうと (mogile に突っ込むときの key はまた別に digest とかで作ってあったりすると余計に混乱することうけあい) Mogile にはもう存在せず、したがって mod_perl にはどうしたって知りようがない URL を Perlbal がキャッシュしていて 503 を返しつづける、という状態になってしまう。それから、キャッシュを自発的に消したいときというのはもともとキャッシュしてた URL (Mogile 上でのファイルのありか)が指し示すファイル実体を消したいときなので(実体がないものをいつまでもキャッシュしているのは困る、という理由)当然実体そのものも消すわけだが、
こういう手順でつくらないといけない。この URL は ACL を厳重にしておかないと、全ての artwork に対応するキャッシュ破棄用(つまりファイル削除用) URL を GET されまくってファイルを消されまくってしまうので非常にまずい。
我ながら乱雑で要領を得ない文章だと思うけど、こんなものでもないよりはあったほうがこれから同じことをやろうとする人にとっては多少の助けになると思うので走り書きのままで公開する。こういう、どっかに一言書いてあれば5秒でぐぐって済むことを何時間もかけてやり直すのは人類にとっての時間的損失でばからしいので、適当に間違ってるところとかを修正しつついろんなブログとかに転載しまくって世に広めてください。