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 アプリケーションフレームワークをザーッと眺めていこうと思ってます。
上手くまとめて社内勉強会なんかで発表できるといいなぁ。

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

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

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

HTML Form の内容を見るための Greasemonkey スクリプトを書きました。
きっと役立つと思います。

ソース

form_debug_view.user.js

スクリーンショット

例えば Twitter のログインフォームを見てみると、

こんな感じになります。

↓読みました。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 Venkat Subramaniam Andy Hunt 木下 史彦 オーム社 2007-12-22 売り上げランキング : 453 Amazonで詳しく見る by G-Tools

非常に良い内容。
翻訳も読みやすくでいいですね。
この本は、ソフトウェア開発に携わる全ての人が読むべきなんじゃないでしょうか。
当然、読むだけじゃなく実践もしていかないとだめですけどね。

こういう本を読むとつくずくソフトウェア開発っておもしろいなぁって思う。
いや、でもソフトウェア開発に限らずだよな。

例えば、本書には天使と悪魔が出てくるんだけど、天使がこんなこと言ってる。

誰かの後ろ指をさすのではなく、自分のできる解決策に注力しなさい。大事なことは、意味のある成果をあげることです。

そうなんですよねー。
でも人って、せっぱ詰まってたり焦ってたり疲れてたりすると、すぐに人のせいにしたりしてしまうんですよねー。
まあ、難しい。
人間が社会的な生き物であるからこその難しさというか。
機械だとこういうこと起こらないからね。

機械ではない人間がいかにうまく協調作業できるか、ということをよくよく考えていかないといけないんですね。
そこで重要になってくるのってやっぱり人間の心理的な部分だったりするんですよ。
そういう意味で、本書に天使と悪魔が出てくるのは非常にわかすくて、的を得てると思う。
仕事中は常に、楽をしたい気持ちと、きちんと仕事を成し遂げたいという気持ちのあいだで心が揺れ動いてるんですよね。
本書は、そういった際に正しい行動をとるための指針になると思います。

というかまあ、実践あるのみですね。
本読むだけじゃ何の意味もないし。

いくつか引用。

伝説のジャズギタリスト、パット・メセニー曰く、「どんなバンドで演るときも、一番下手なプレイヤーでいろ。もし自分が一番上手いんだとしたら、それは別のバンドに移る時期だ。同じことは世の中のほとんどのことに当てはまると思う」

うん。
パット・メセニーが言ってるんだから間違いない。

「自分でもよくわかっていないことを、厳密にしても意味がない」
―― ジョン・フォン・ノイマン

ノイマンが言ってるんだから間違いない。

まず何よりも、巧妙であるよりも明瞭であれ。「意図を明確に表現するコードを書く」こと。

これはホントそう思う。

よく考えて選んだ意味のある名前を使って、コードを読みやすくしましょう。コメントはコードの意図や制約を示すのに使います。ひどいコードを取り繕うために使ってはいけません。

はい。

シンプルであることは、安直だとか未熟だとか、不足しているといったことを意味しない。むしろ全く反対だ。シンプルさは、やたらと複雑で後先を考えない解放よりも、はるかに実現が難しい。

いいこと書いてありますね。
そうなんです。
シンプルっていうのは無駄がないということで、無駄を極限までなくすっていうのは結構難しいことだったりするんですよね。

本物の洞察は、実際にコードを書くことからもたらされます。コーディングしないアーキテクトと一緒に仕事をしないように。システムの実態を知らずにまともに設計なんてできません。

だそうです。

環境:
Rails 1.2.3

1. FastCGI を有効にする



2. シンボリックリンクをはる

ln -s ~/[railsプロジェクトディレクトリ]/public ~/[公開用ディレクトリ]

3. .htaccess に以下を記述

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

4. パーミッションの設定

chmod 755 dispatch.fcgi