まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000

まるごとPerl! Vol.1 の見本誌が届きました。興味の沸いたところを目を通してみましたが、結構いい仕上がりになってますね。ちょっと濃ゆすぎる気もするけど(笑) まるごとPerl! Vol.1 作者: 小飼弾,宮川達彦,伊藤直也,川合孝典,水野貴明出版社/メーカー: インプレス発売日: 2006/08/24メディア: 大型本購入: 7人 クリック: 123回この商品を含むブログ (115件) を見る 基礎編がいきなり「まるごとEncode」で椅子からずり落ちそうになりましたが、読んでみたら、Encode の中の人が書いただけあって正確かつ分かりやすかった。Unicode 絡みでいまいち理解があいまいな人にはおすすめかもしれない。かく言う僕も、ああ、そういうことだったのかーと読みながら思ったり。 フレームワーク特集の中では、id:charsbar さんが書いた Jifty のチュートリア

見本誌届きました。先月も良かったど今月はさらに良いんじゃなかろうか。自分がいいと思ったのは 弾さん DHH にインタビュー。Ruby Kaigi 来日のときに突撃したらしい。 宮川さんの US オフィスのエンジニアの中で顔をみせる Vox の開発体制の話 第一特集の性能改善大作戦のところには sar, vmstat, iostat とかの Linux の基本ツールの使い方が載ってるとこ vmstat / iostat はともかく、商用Linuxではおなじみ、Linux では比較的新しい(とは言っても何年も前からあるけど) Linux の sar の使い方が詳しく解説されてる記事を見るのはめずらしい。 基本 Java の記事だけど、Linux 基本ツールの使い方とかは UNIX ハカーなひとにもうれしいと思う。 弾さんの Haskell 入門 Web認証API特集(!) サイボウズラボの奥さ

ETech も今日が最終日です。午前中のセッションを終えて、聞きたいものはだいたい全部終わったし、ここらで全体を通してのレポートを書いてみます。一つ一つのセッションについて全部レポートは難しいので、個人的に面白いと思ったトピックやセッションだけ振り返ってみたいと思います。 Attention Economy 今回の ETech のテーマは Attention Economy。ETech は 5 回目ですが、毎年このようにテーマがあるらしく、そういえば去年の ETech は "Remix" がテーマでした。この辺がきっかけて Web 2.0 がどうこうという話が盛り上がりはじめたんだっけ。 Attention Economy というのは 今回のテーマは"Attention Economy"ということで、Attentionをキーワードに色々な話が繰り広げられています。 パソコンはどんどん安くな

RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。 以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB　な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな？ 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもな

ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増