System.Exit

Web アプリケーションフレームワークを使うべきか否か。

当然使うべきでしょ。
開発効率が全然違ってくる。
ものすごく特殊なアプリケーションとかだったら適用するのは難しいかもしれないけど、ほとんどの Web アプリケーションが何かしらのフレームワークを使って構築できるはず。
フレームワークの選択を誤ると無駄にコストがかかるかもしれないけど、ま、そうそう間違えないでしょ。

メジャーなフレームワークには、たいていわかりやすいドキュメントがある。
ドキュメントがあるとシステムの見通しが良くなるので、メンテナンスがやりやすくなる。
例えば、独自のフレームワークを作ったとしてもドキュメントが無いと他の人がシステムを理解するのに余計な手間がかかる。
ドキュメント書くのって結構面倒くさい。

要は、どこにコストをかけるか、という話ですね。
自社の製品にめちゃくちゃ特化したフレームワークをはじめにコストをかけてドーンと作って、それを活用することで後々の開発のコストを下げるのか、メジャーなフレームワークを活用して開発コストを下げるのか、という。

図にすると以下のような感じ（状況によって違ってくることも多々あると思いますが）。

フレームワーク無しでいく場合

フレームワーク無しでいく場合、各開発において効率が相当悪くなることが予想されます。
似たような機能をそれぞれで実装したりするはめになるので。

独自フレームワークでいく場合

フレームワークを作るのにかなりのコストがかかります。
それに、そこそこ使い物になる良いフレームワークを作るにはかなりの技術力が要求されるので、優秀な技術者がいないと厳しいです。

メジャーなフレームワークを活用する場合

メジャーなフレームワークを使うと全てが上手くいきます！
（嘘）

複数の情報筋からの情報：２年近くの間、高い頻度で発生していたスケーリング関連のトラブルで、TwitterはRuby on Railsのフレームワークを捨て、PHPないしJava（Rubyは使い続け、Railsのフレームワークのみを放棄する案もあるようだ）を使ってゼロから作り直すことにしたようだ。

— TechCrunch Japanese アーカイブ » Twitter、Ruby on Railsを放棄か

実際のところどういう問題があったのか知りたいな。
おそらく、Twitter のような膨大なトラフィックを集めるサイト特有の問題だと思われる。
以下のような話も関連してるんだろうな。

TwitterのスケーリングについてはCookがその任に当たっていたが、彼はこの作業をうまくこなすことに失敗した。
[略]
Twitterは今年になって、少なくとも３つ、キーとなる技術面での雇用を行っている。Lee MighdollはVPエンジニアおよび運用担当として１月から参加している。そして今週になってJohn Kaluckiと（「BloggerおよびBlogspotのスケーリング分野での働きでその名を知られる」）Steve Jensenという、２名のスケーリング分野のエキスパートを採用した。

— TechCrunch Japanese アーカイブ » Twitterにおける素人の前座は終わり？

というか、アレですよ。
Web アプリケーションをいかにスケールさせるか、という話になってくると、どのフレームワークが良いとかそういう話の重要度はきわめて低くなってくるんだろうな。
例えば、Java もしくは PHP に置き換えることによってシステムの負荷がほんのちょっと下がるだけでハードウェアにかかるコストがものすごく減る、なんてこともあるだろうし。
ごくごく一般の Web アプリケーションにおいてはこういう問題はそうそう起こらないと思う。

つまりは、「開発コスト」と「運用コスト」の二種類のコストがあって、サイトの規模や種類によってどちらの負担が大きくなるかが変わってくる、ということですね。
そういったことを考慮した上でシステムに採用する技術（言語やフレームワーク等）を決める必要があると。
なので、 Rails がダメだったから、とか早急に結論づけるのは問題の本質をとらえ損ねてるわけですよ。

いや、でも、Rails もしくは Ruby に致命的な問題があったとかだったらまた話は変わってくるけど。

うーん、アレですね。
Web アプリケーションをちゃんと作るのってくそ面倒くさい大変ですね。
というか、Web という基本ステートレスな環境でいろいろなことを表現しなくちゃいけないというのが、本当に、、、特殊。
慣れるまでは大変。

僕は今までは主に Windows 上で動く GUI アプリとか、RPC によるサーバークライアント型システムのサーバー側の処理とかを Java とか C# なんかで作ってたりしたんだけど、まあこういうシステムってそこそこ直感的ではあるんですね。
プログラミングとしては、特にマルチスレッドで動く部分とかがあるといろいろ大変になってくるけど、そういう部分さえ意識していればその他の部分はわりと作りたいように作れる。
そこそこ思い通りに表現できたり、無理のない実装、綺麗な実装にできたりとか、オブジェクト指向的に作れたりとか。
なんていうか、クラスを中心に物事を考えられるんですね。

こういう感覚に慣れているから、いや、こういう感覚にしか慣れていないから、Web アプリケーションの開発って非常に、とまどいます。
僕としては、アプリケーションの土台となるような部分に一本ビシーッと筋が通ってて欲しいんですね。
この処理はこれが面倒見て、ここに関してはこれが責任を持つ、とかそんなような。
Web アプリケーションにおいてはそういうのを一から作らないといけない。
ま、フレームワークってのがそういう役割を担うものなわけなんだけど。
で、巷には Rails とかいろいろあるわけですが、導入するにしても学習コストが馬鹿にならない。

ていうか、Web アプリケーションフレームワークって種類多すぎじゃね？
例えば、僕は Swing のような GUI ライブラリが何十種類も存在するなんてのを想像できない。
それだけ Web アプリケーションって特殊なんだな。
とか、簡単に結論づけちゃってるけど、これは結構切実な問題なんですよね。
今まさにそういうところで悩んでいるわけなので。
（GUI ライブラリと簡単に比較するのもどうかと思うけどね）

というわけで、いろんな Web アプリケーションフレームワークをザーッと眺めていこうと思ってます。
上手くまとめて社内勉強会なんかで発表できるといいなぁ。

↑こういうのを表示するコード↓

<div style="background-color: #AFEEF1; height: 1px; width: 1px; margin-left: 26px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 3px; margin-left: 25px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 5px; margin-left: 24px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 7px; margin-left: 23px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 9px; margin-left: 22px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 11px; margin-left: 21px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 13px; margin-left: 20px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 15px; margin-left: 19px;"></div>
<div style="background-color: #AFEEF1; height: 1px; width: 17px; margin-left: 18px;"></div>
<div id="twitter_div" style="background-color: #AFEEF1; padding: 4pt;">
  <div id="twitter_update"></div>
  <div style="text-align: right;"><a href="http://twitter.com/jugyo"><img src="http://twitter.com/favicon.ico" /></a></div>
</div>
<script type="text/javascript">
<!--
function twitterCallback2(twitters) {
  document.getElementById('twitter_update').innerHTML = twitters[0].text;
}
-->
</script>
<script type="text/javascript" src="http://twitter.com/statuses/user_timeline/jugyo.json?callback=twitterCallback2&count=1"></script>

一番下の行の script タグの src の「jugyo」となってるところを変えたりするといいと思います。

Googleを支える技術 ‾巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ) 西田 圭介 技術評論社 2008-03-28 売り上げランキング : 30 Amazonで詳しく見る by G-Tools

これ、わかりやすくていい。
社長から借りて読んでる。

各所で非常に評判がいいですよね、この本。

ていうか、面白くない部分がほとんどない。
データセンターのコストの話も非常に為になった。
ハードウェアとか設備とか電力とかのコストってあんまり意識したことないけど、かなり重要な問題なんだなぁと思った。
いやー、Google すごいなぁ。
「Googleを支える技術」というか、その技術そのものが Google なんだよなぁ。

とか。

たぶん僕しか使ってない Hatebu daily report ですが、トップページをちょっと変えました。

何が変わったかというと、集計途中のデータを表示するようにしました。
一日の集計の区切りが夜の12時で、その時間になるまではその日のランキングって出ないんですけど、途中経過みたいなのをとりあえず出しておくようにしました。

僕は毎日これを見てはてな界隈の話題をなんとなくさらってます。

超〜細々と動かしてる Web アプリ Hatebu daily report ですが、ランキングデータの集計方法をちょこっと変えました。
図にすると以下のような感じです。

えーっと、つまりこういうことです。
はてなブックマーク上に登場して 24 時間経過した Web ページについて、その 24 時間の間のブックマーク数でランキングしてます。

15 分ごとに cron でバッチをを動かして、ランキング用のデータをせっせと集めてます。
例えば、はてなのサーバが止まってたりしても 15 分後とかにまた取りに行くので安心です。
以前のやり方では、夜の12時頃に、その日のブックマーク情報を取ってきて集計を行うバッチを一個ドカーンと動かしてたりしていて、それが止まったらどうしようもなかったりしました。

というか、デザインがダメすぎるのでもうちょっと良くしたい。