• HTTP圧縮を使用するだけで帯域幅もコストも削減できる〜米調査結果 - http://internet.watch.impress.co.jp/www/article/2003/0724/port80.htm

単にmod_gzipを入れるとか、PHPでob_start('ob_gzhandler')するだけならば、簡単なんだけど、プロキシとかキャッシングとかいろいろ絡んできたときに、どのくらい問題がありうるのかよく分からないんだよなー。自分では問題に出会ったことがない（というか、報告を受けたことがない）から、基本的に圧縮有効にしているけど。

Webアプリケーションフレームワークとだけ考えるならば、Webアプリケーションでさえ使えれば済むわけだけれども、ライブラリと考えるならば、バッチ用のスクリプトでも使えるようにしておいた方が幸せだよな。最近のPHPにはCLI版が用意されていることだし、PHPでWeb側を作ったならば裏タスクもPHPで作るのがまっとうだよな。

で、実際にblogmapの裏タスクをPHPで書き直してみた。Web XP側には手をつけずに強引に使った（includeした）だけでも、一応は使えているみたいだったけど、エラーメッセージとかがHTML出力しか想定していなかったり、結構問題はあるな。あと、出力バッファリングが標準だったりとかも。

というわけで、裏タスク用のライブラリとしてもきちんと使えるようにするために、結構全面的に手を入れる必要がありそう。書き直す量は大したことないんだけど、ロジカルに問題がないかを依存関係がある全部を見直さなければならないからなー。納得して公開できるバージョンに達するのはいつのことだろう。

---

ひとまずざっと対応してみたけれども、せっかくだから本格的に対応させておいた方がいいかなー。でも、そうするとまた設計からやり直したくなるんだよなー。公開していないうちにやり直せるだけやり直しておいた方がいい気もするけど、そうするといつまで経っても終わらないような気もしてくる。ひとまず派生バージョンとして、直せるだけなおしてみるかな。

• [言語]PHP - http://www.rubyist.net/~matz/?date=20030727#p02

>>PHPってのは大層人気がある言語だ。（中略）しかし、言語屋あるいは言語設計者の目から見ると、なぜこの言語が人気があるのかがわからない。

私がPHP（4以降）を好きな理由は、

• Apacheモジュールとしての動作が標準である
  • 普通に書いたスクリプトがそのままモジュール版で動作する、というのがmod_perlとの違い。mod_rubyはどうなんだっけ？　Apache restart時のメモリの解放に問題があるとか書いてあった気がするけど。
  • Webアプリケーションの場合、本格的なプログラム（処理時間がかかるもの）というよりは、静的なHTMLにほんのちょっとだけ機能を追加したもの、を作りたい場合が多く、そういう場合にApacheモジュール版の利点が大きい
• HTMLに埋め込んでも使える
  • 私の場合は、出来るだけコードはHTMLには埋め込まずに書くけれども、Webアプリケーションで必須のHTML出力コードを書く場合には、print文およびヒアドキュメントを使うよりも、HTML埋め込みコードをうまく使った方が可読性が高いと思う。
• DBアクセスライブラリがほぼ標準である
  • PHPでDBにアクセスする場合は、MySQLもしくはPostgreSQLを使う場合が多いだろうし、その二つがほぼ標準でサポートされている。
• ほぼC言語ライクな構文だけで書ける
  • Perlみたいに独自の省略表現がないので、他人が書いたコードでも比較的読みやすい。省略表現を多用しすぎると（ほかの言語と行ったり来たりする人間には）扱いにくい
• classが普通に使える
  • Perlと比べると、classの言語仕様がとてもまともだ
• Webアプリケーション用の初期化が自動的に行われる
  • PerlでいうところのCGI.pm相当の機能が、ほぼ自動的に初期化済みの段階からコードの解釈が始まる
• 標準組み込み関数がとにかくリッチ
  • でもまあ、Perlみたいにモジュールがやまほどあってきちんと管理されているのならば、別にすべて標準関数にしなくてもいいんだけどね。でもまあ外部モジュールではなく標準関数としてあった方がいいものも多い
• 中庸的（ポリシーがない？）ポリシー
  • がちがちになんらかのポリシーに準じて作られているという感じではなく、使う人が自分が使いたいように使っても、それなりに何とかできるって気がする
• マニュアルがまとまっている
  • 大元のPHPのマニュアルをダウンロードして読めば、それでたいていのことは書かれている。というのは、たいていの機能は標準関数で提供される＝PHP自体のマニュアルに説明が書いてあるから。Perlとかだと使いたいライブラリごとにドキュメントを探す必要がある

続いて欠点、

• 言語仕様ががんがん変わる
  • 言語仕様自体は基本的に互換性を持って拡張されているけれども、標準設定状態での挙動が派手に変わるというのが、ほぼ言語仕様の互換性なしの改変に匹敵する。でもまあ設定関連はほぼフィックスされたかな
• 関数命名規則がいまいち
  • グローバルな名前空間に標準関数をがんがん追加していくもんだから、わかりにくいプレフィックス付きの関数がとても多くて覚えていられない
• classの機能がいまいち
  • いまどきの言語としてはclassで実現できる機能はとても少ない
• 共用サーバーではあまり使いたくない
  • ソースコードを他のユーザーに見られるくらいならばともかく、パスワード関連の扱いとかに困る
• 過去互換性にひきずられて使いにくい部分が多い
  • global変数をローカルスコープで使うときに毎回宣言し直さなければならない、とか、自動的にaddslashesされる設定が標準だ、とか、過去互換性のために残されている同じ意味を持つ別の表現がいろいろある、とか
• 異常系のコードが書きにくい
  • 自前のフレームワーク（Web XP）では、エラーハンドラーの書き換えとグローバルなTransaction管理クラスとでサポートしてみたりしたけれど、普通にtry catchしたいなー。

ちなみに、

• PEARは好きじゃない（ドキュメントと利用例を眺めただけの食わず嫌い）ので使っていない
• コミュニティには所属していない（PHP-users MLを最近読み始めた程度）

という私は、PHPユーザーとしては全然標準的ではないと思う。って、標準的なPHPユーザーって想定可能なのだろうか？　標準的なRubyユーザーとかJavaユーザーだったらそれなりに想定可能な気もするけど。

反応の反応 → [言語]PHP(その2) - http://www.rubyist.net/~matz/?date=20030728#p02

いろいろ書いたけれども、それらをまとめると、PHPはプログラミング言語としてというのではなく、「Webアプリケーション環境として使いやすい」ことがポイントなのかもしれない。

私自身、PHPの言語仕様には全然萌えないけれども、それでもメインで使っているのは、自分が作りたいWebアプリケーションを一番手っ取り早くプロトタイピングできるのが、今のところPHPだから、なんだろう。

• 斎藤環氏に聞く ゲーム脳の恐怖 - http://www.tv-game.com/column/clbr05/

ゲーム脳みたいなあきらかな“ト”は、まともに相手をする価値もないと思うけれども、それでも放置しておくといつの間にかああいうのが多数派になったりするかもしれないんで、『「斎藤環氏に聞く ゲーム脳の恐怖」のGoogleランクを上げよう』運動（http://sodium.dnsalias.com/sodium/diary/20030726.html#p01）に協力しておこう。

風邪自体は先週の中頃からずっとひいていて、微妙な頭痛と鼻水に悩まされていたんだけど、日曜に草野球をしに行ったところ、太陽が照りつけている間はやたらと暑く、太陽が雲に隠れたらとたんにやたらと風が涼しく、というコンディションに5時間くらい晒されていたら、頭痛と鼻水の症状がバージョンアップした。

といってももともと一桁前半のレベルが一桁後半にあがった程度で、中ボスクラスも倒せない程度のかわいい風邪なんだけど、ここ最近のんびり休んだ記憶がなかった（ムスコと一緒の休日はとてものんびりはできん）んで、休んでみた。

ああそういえば、ここ一ヶ月切迫流産の診断を受けて自宅安静、会社欠勤状態だったオクサンは、先週の土曜日の診断でなぜか「もう普通の生活に戻っていいよ」といわれて、今日からまた会社に復帰している。「一度こうなったら、もう絶対復帰しちゃダメ」みたいな診断だったのが、なんで突然ころっと変わるかなー。まあいい方に変わるぶんにはダメージはないんだけどさ。

• Longhornに「少しビクビクしている」とビル・ゲイツ氏 - http://www.zdnet.co.jp/news/0307/25/ne00_gates.html

マイクロソフトの支配力に陰りが出てきている状態で、一般ユーザーに媚びないOSを準備に時間をかけて出すってのは、かなりの冒険だよな。俺的にも、SL-C760をしばらく使ってみた感触では、マイクロソフト系の開発をしないのならば、Linuxでも全然無問題な感じなんで、次にPCを買い換える頃にはもしかしたらWindows以外のOSを選んでしまうかもしれない。ただ、Longhornに載るという噂のDBベースの新しいファイルシステムはちょっと気になるな。

• 凸版の Bitway、コンテンツ流通で初のビジネスモデル特許を取得 - http://japan.internet.com/ecnews/20030725/4.html

ユーザーが Bitway の有償コンテンツの購入依頼を送信すると、 ISP にて「ユーザー認証」と「課金」が行われ、Bitway に対して「アクセスキー」の発行が依頼される。Bitway はアクセスキーを発行してユーザーに配信、ユーザーはこのアクセスキーで有償コンテツを楽しむ。

「認証と課金をISPが代行し、アクセスキーの発効まで受け持つ」ってところが独自性なのかな？　それ以外はごくごく当たり前のコンテンツ認証だよな。認証と課金をISPが代行しない限りは、このビジネスモデル特許に抵触することはないよね。

でもどっちにしろ、こんな仕組みにいちいち特許をとって権利を主張して欲しくないなー。最近、特許とか著作権なんて権利は、もはや存在しない方がいいような気がしてきたよ。みんな、思いついたことはどんどんネットに垂れ流して公知の事実にしてしまおう。

• ユビキタス認知は3割弱、セキュリティの不安感じる向きも〜矢野研調査より -

http://internet.watch.impress.co.jp/www/article/2003/0725/yano.htm

「ユビキタス」なんて耳になじまないぱっとしない言葉が、よくまあここまで広まったもんだなー。俺の中では、うさんくさくて（商売っけが強すぎて）使うのがちょっと恥ずかしい言葉だけど、でも妥当な言い換えが思いつかないからしょうがなく使う、って感じかなー。ユビキタスに一番近い表現としては、「SFの浸透と拡散」という文脈における「（ネットワークとコンピュータの）浸透と拡散]」かもしれない。

• どこからでも自分の音楽コレクションにアクセスできる『ミューズ・ネット』 - http://www.hotwired.co.jp/news/news/business/story/20030728104.html

前にStreamsicleを使って似たようなことをやろうと思ったんだけど、俺が家以外でMP3データを聞きたいのって、外を出歩いているとき＝AirH" 32kbpsで接続しているときだから、それだといくら低品質なMP3でも結構きついんでやめてしまった。けれども、よく考えたら家に一個サーバーを立てておけば、会社とかでもそのデータを聞けるようになるんだよな。それは結構いいかもしれない。今度試してみよう。

• 持たざる者のための超ナローバンド用サーチエンジン「TEK」 - http://internet.watch.impress.co.jp/www/article/2003/0728/tek.htm

>>検索語を入力すると、TEKクライアントはその検索内容をメール形式に変換し、PC管理者の待ち行列に入れる。管理者がインターネットに接続すると、メールがインターネット上のTEKサーバーに送信され、管理者はここで一旦インターネット接続を切る。検索を受け取ったTEKサーバーはたっぷりと時間をかけて検索を行ない、重複している検索結果の削除や類似しているページのうち最も重要なページを抽出し、ファイルサイズを減らすために画像や余分なHTMLコードを削除も行なった上で、最終的にすべてのページ内容をZIPファイルに圧縮してメールでクライアントに送り返す。

なんかH"でWebをメール変換して読むサービスみたいだな。あるいは、メタ検索エンジン（複数の検索エンジンにまたがった検索サービス、とか）とかがやっているインターフェースをメールにしたもの、といった方がシステム的には近いだろうか。

別に回線が遅い人向けのサービスと限らず、一次サービスのデータを加工して提供する二次データサービスってのは、いろいろ可能性がありそうだな。ただ、こういう回線が遅い人向けというエクスキューズがあればごまかせるけど、単に二次データ加工サービスというと一次データ提供元との権利関係の話がややこしくなりそうだ。