RSSが取得できませんでした。|一番怒っていたのは、記者の姿勢、とりわけ取材量についてである。「一昔前の記者は現場をよく歩き、色々な人から話を聞いた上で記事を書いていた。現場で聞いたことに基づいていれば、たとえ耳が痛い指摘であっても、こちらは真摯に受け止めた。ところが今の記者は一人か二人の取材先から吹き込まれた情報を基にいきなり記事を書こうとする。『××は失敗のようですね』などど言ってくるが、そういうお前は××の現場に行ったのか、と怒鳴りたくなる」。記者の基本そんな中、毎日欠かさず読んだ記事の一つが、2003年4月から04年9月まで断続的に続いた同紙一面連載「働くということ」だった。それは、採算度外視で取材に法外なコストをかけた、恐ろしく単価の高い記事であることが容易にうかがえたからだ。(略)優れた新聞記者は、時代の意味を切り取って、それを新しい文字や言葉の組み合わせによって表現するものだ。グーグルを駆使する上で難しいのは、検索キーワードの選択である。正しいキーワードを思いつけるかどうかで、得られる情報の質が大きく違ってくる。ある事象とそれにぴったりと合った言葉を連想できるかどうかが、個人の情報戦略における競争優位の源泉となりつつある。そのギャップを埋めることが、新聞の新しい役割となるのかもしれないなと、本書を読んで思った。雑誌や新聞に目を通さなくなったのは、「単価の安い記事」がウェブ上に溢れているからかもしれない。雑誌や新聞の記事もほとんどは単価の安い記事だし。逆に、ウェブ上にあるもののほとんどは単価の安い記事ばかりだ。ブログがもてはやされていても、結局は単価の安い記事でしかないしね。いうわけで、雑誌や新聞が生き残る方法の一つは「単価の高い記事」の充実なんじゃないでしょうかね。|訪問者が多いうちに聞いてみよう*1。Class::DBI::Cacheableは前の会社にいたときに使おうと思ってたんだけれど、Cache::FileCacheを使っているのでサーバが複数あるとupdateしたときに不整合が起こりそうな気がして使うのをやめた記憶があります。このあたりはどうなってるんでしょうかね?updateする可能性のあるカラムだけキャッシュしない設定があるとか、あるいはそういうテーブルには使うなってことなんでしょうか。この辺りが気持ち悪くて自前のCahce::FileCacheラッパを使ってたりするのですけれど。上記みたいなケースでNFSを使うよりは良さげな気がするんですけれど。補足Class::DBIのパフォーマンスを気にしている方がいますが、まずはEssentialの設定を見直すことをオススメします。キャッシュなんかしなくても、数倍パフォーマンスが良くなりますから。|個人的にはどうやってサーバを展開してるかが気になるのですが~。ハードじゃなくてソフトのほうね。プログラムをバージョンアップさせるときに、某所のようにrsyncで散まいてるとは考えたくないのですけれど。伊藤氏ははまぞうで利用したAWSのポイントとして「AWSは正規表現でプログラムすること」を挙げた。はてなのようにページビューが多いサイトでは速度の問題がシビアであり、PerlのXML関連モジュールはどうしても速度の面などで問題があるのだという。「Perlの正規表現はとても優秀で、モジュールと比べても桁違いに早い。(速度という観点から)XMLモジュールよりも現実的なほうを実装している」。XMLモジュールでロジックをテストしてから正規表現による独自モジュールに変更、とかじゃないのか......。そもそもそんなにXMLを頻繁にパースする必要はない気もするんだけれど*4、2億PV/月=5,000PV/分*5だったりすると何かと問題があったりするのかもしれない。いうか、90台のサーバって、どんな振り分けになってるんでしょ。*1:もう少なくなってたりして。*2:特にMySQLクラスタが良さそう。