SSLの説明文をNRIサイバーパテントデスクからコピペしたため、どこに繋いでも、「確かにNRIサイバーパテントデスクのWWWサーバであることを保証します。」状態になってるという話。「NRIサイバーパテントデスクの」を自分ちに書き換えなければ、書いてある事が嘘だし、書いてある事が本当なら、じゃ、お前んちはどこに繋げばいいんだ？ になる。
最初にコピペした人は「NRIサイバーパテント」のページから拾ってるんだからわかりそうなものですが、コピペ先から更にコピペしたひとは「NRIサイバーパテントデスク」がSSL関連の技術用語の一部だと思って、まるごとコピペ。同じ勘違いをしたひとたちによってさらに広まって行く。ググるなの典型ですね（w。
何かの昔話に、似たようなものがあったと思ってぐるぐる考えてみたら、思い出しました。
おいもころころだ（笑。
もちろん、元ネタは、「本物のプログラマーgotoを恐れずに使う」なわけですが（w。
つい最近まで、フチ恐怖症だったのです。いや、切実に。
フチ付きの文字が嫌いだったのではなく、フチが恐かったのですよ。フチを付けるのが文字通り恐い。フチと聞いただけで微妙に震えるくらいでした。
フチの恐怖を味わったのは、忘れもしない、25歳の夏の事。
アダルトビデオのジャケットを作った時、裏面のキャッチコピーの指定に、何のためらいもなく「フチ M100+Y100」と書いたのでした。
翌日、製版屋さんに呼び出されました。
小さい製版屋さんで、社長直々に説教です。
「お前らは、簡単にフチとか書きすぎる。お前らは二文字【フチ】と書けばすむかもしれないが、こっちは大変なんだ。今からフチを付ける作業を見せてやるから思い知れ」
と言って、フチを作る作業を始めました。
原稿台に版下を乗せ、トレスコで僅かにピントをズラして、太らせ版を作ります。
製版用の感材は連続階調が出せない仕様のものなので、ボケ部分は、グラデーションではなく、太ったベタになります。
こいつを、フチ部分にして、中の文字を抜くわけです。
そこまでに、アレを反転して、コレを合わせてとか、めんどくさい作業があるのです。
そういう作業を半日くらい見せられてから、
「うちは、フチを付けるほどの代金はもらっていない。フチを付けるとか軽々しく書くな。フチなどいらない配色を考えるのがお前の仕事だ」
などと、延々と説教されたのでした。右手にはカッターを持ったまま（w。
若気の至りで「それをやるのがこちらの仕事では？」などと反論したものだから、更に説教でした……。
グラデーションをあんまし使わないのもここの社長に怒られたから。
グラデーションを作る機械が当時、既にあったと思うのですが（他の印刷所でいわれた事はなかった）、そこの製版屋さんにはなくて、グラデーションっていうならスクリーントーンを付けて来い。って怒られたのでした。
今でも色校に「版ズレ」とは絶対に書きません。まぁ、DTPで版ズレは出力系のバグとか、送りのスリップでもなければありえませんが……。
それもやっぱりここの社長。
色校に「版ズレ」と書いたら、呼び出されたのでした……。
「版ズレっていうのは、貼り込みがずれている時に使う言葉で、この色校の状態は見当ズレっていうんだ。版ズレはうちの責任だけど、見当ズレは印刷屋のせいだ。見当ズレなのに版ズレと書くとは失礼にも程がある」
手作業の時代は、たしかに「版ズレ」はあったので、「見当ズレ」に対して「版ズレ」と書いたのは失礼だったとは思いますが、その辺のズレ全般を指して「版ズレ」と呼ぶのは、当時でも割と普通になっていたと思います。なのに、このときは社長マジ切れしてました。
この社長に呼び出されたのは、フチ＆グラデーションのときと、版ズレのときの二回。
それだけで、フチ、グラデーション、版ズレに対して恐怖心を抱くのに充分でした。
それ以来、21世紀になっても、フチもグラデーションも極力使わず、色校の校正用語には細心の注意をはらってきました。もちろん、社長に呼び出されないために（w。
ようやく、去年くらいから、フチが恐くなくなりました。
というのも、こちらの会社で、私の前にいた常勤のフリーの女の人が激しくフチを多用する人で、その路線で売れていたので、引き継いだものはその路線を継承するわけです。いやでもフチだらけ（w。
エロ本を見かける機会がある人は見た事があると思いますが、200Qくらいの大きさで「中出し」とか、400Qくらいの大きさで「DVD8時間」みたいなキャッチ。あの路線を始めたのがその女の人で、いわゆる天才です。それ以前にあの大きさの文字はほとんど見た事がありません。いまでは普通ですが、先駆者とは偉大なものです。
お陰でようやくフチの恐怖から解放されました。
付けた方が良さそうなときは、恐れずに付けます。どうせ付けるのは機械だし（w。
しかし、あの社長みたいな職人。いなくなったなぁ……。
PHP Acceleratorを、APCに変えました。
前は、ioncube PHP Acceleratorを入れていたのですが、アシアルさんのサイトを見たら、開発終了ということだったので、別のを。っていうことで、APCにしました。
INSTALLに書いてある通りに./configureしてmakeしてinstallして、やはり、INSTALLに書いてある通り、php.iniを変更して、httpdをリスタートして出来上がり。
こういうときは、やっぱりCUIは楽。説明文が英語でも、作業するところはコピペすれば済むのがいいです。
速いらしいとは聞いていたのですが、実際、速いようです。ここの環境（VineLinux 3.2,apache 1.3.33,PHP4.4.2）だと、ioncube PHP Acceleratorの、倍程度以上速いようです。デフォルトのままでも、かなり速いのですが、php.iniで、apc.stat = 0にすると一度キャッシュしたら、httpdをリスタートするまで再読込しなくなるので、爆速だそうです（PHP公式マニュアル参照）。でも、これは、PHPの学習をしているときには使えません。
MySQLへのクエリーが実行時間の大半を占めるここのblogだと、PHPだけ速くなってもさほど変わりませんが、PHPだけで動くものは、時間がだいたい半分以下になるようです。
10分もあれば入れられるので、試してみるのもいいかと思います。
ここのページも同じですが、はやりググッてはいけませんね……。
PHPの学習にと、宅ファイル便もどきを作っているのですが、ダウンロード制限がどうにもうまく作れない。ずっと、公式マニュアルだけで闘っていたのですが、readfile()で読み出すと、でかいファイルでひっかかる。ここで、更に公式マニュアルを読めば良かったんですが、つい出来心でググってしまいました（w。
php.iniで、output_bufferingはoffになっているので、readfile()の仕様だとばかり思い込んでいました。どうやら、同じような思い込みをしている人が結構いるらしく、ググったら、readfile()で出力するときは、どうしてもその辺で引っ掛かるっていう内容のものが結構ありますた。
でかいものが落とせないなら、作っても楽しくないなぁ……。などとグルグルしておりました（w。
それで、もう一度、php.iniと公式マニュアルを禿げしく読んでみたら、引っ掛かっていた原因は、output_bufferingじゃなくて、output_handle = mb_output_handlerでした……。
公式マニュアルを始めから、通読すればよかったのですよorz。
output_handler string
スクリプトの全ての出力を関数にリダイレクトすることができます。 例えば、output_handler に mb_output_handler() を指定した場合、文字エンコーディングは透過的に指定したエンコーディングに 変換されます。出力ハンドラを指定することにより自動的に出力 バッファリングを on にします。
「自動的に出力バッファリングをonにします。」って、思いっきり日本語で書いてありますたorz。
4.1.0 以降のバージョンでは、以下の条件が満たされた場合にこのハンドラは charset HTTP ヘッダを設定します。
*
header() で Content-Type が 設定されていない場合
*
デフォルトの MIME 型が text/ で始まる
*
http_output の設定が pass 以外
ここだけ読んで、Content-Typeを設定してやればオケ。と思っていたのですが、Content-Typeが設定されていれば（text以外）、何もしないけどバッファはする。ってことのようです。
ここの設定をそのままにして、バッファリングさせないには、headerを出力した後で、ob_end_flush()（output bufferをflushして、バッファリングを止める）してからreadfile()すれば、読んじゃ出し、読んじゃ出し状態になるようです。
一歩前進（笑。
ググる前に公式ドキュメント。もう一度念仏（w。
