最近、Webシステムの設計やプログラムをやるようになって、
しょっちゅう思うことがあります。
それは、「一体、どの言語やフレームワークが良いんだ？」
ということ。
同じWebアプリを作るにしても、
それを「何で（どのアーキティクチャで）作るか」というとき、
言語やフレームワーク、そしてDBなども考慮に入れると、
これが選び切れないくらいうんとこさあるわけです。
言語なら、Java、C#、PHP、Ruby、perlなど。
フレームワークは、Struts、ASP.NETなど。
DBは、Oracle、PstgreSQL、MySQLなど。
あと、最近はO/Rマッピングのフレームワークや、
デバッグ、ロギング、AOPのフレームワーク、
その他いろいろな支援フレームワークが登場しています。
クライアントサイドのスクリプトなども考え出すと、
その組み合わせパターンは10や20じゃすみません。
まさに、フレーム問題。
私自身、ずっと制御系（非Web）のプログラマだったんだけど、
その時代は、こんなことあまり真面目に考えてませんでした。
とにかく、要求された機能が実現できれば良い。
そして、私が既に習熟している言語でそれが実現できるなら、
選択肢は1択か2択でした。
私は、C++とDelphi（Pascalもどき）を得意としていたので、
物理層に近い制御はC++（若しくはインラインのアセンブラ）で、
画面制御はDelphi（もしくはVB）で、というようなパターンで、
ずっと不自由はなかった。
DBMSも、商用ということになれば、
大抵はOracle、たまにSQLServerかSybaseという感じでしたかね。
Webも、基本的には「機能が実現できれば良い」と考えてましたが、
どうやらそういうわけでもないらしい。
制御系システムというのは、
大体5～10年程度の耐用年数を考えて設計されるので、
最初からガッチリした仕様を決める必要があります。
（これがまたなかなか決まらんのですが。。）
ところがですね、Webシステムというのは、
「仕様というのはしょっちゅう変わるものである！」
という前提で作られるようなのです。
ここがまずカルチャーショックでした。
まぁ、仕様がしょっちゅう変わるというのは、
制御系でもお客さん次第で多々あることではあったんですが、
それはあくまでイレギュラーケースとしての位置づけでした。
（散々泣かされましたが。）
Webアプリの場合、そのライフサイクルは長くて3年程度、
まぁ大体1年くらい周期でリニューアルというケースが多い。
しかも、細かい動作に関しては日々カスタマイズしたい、
というケースも少なくない。
そんなんどう対応するんだ？
というときに、
Webシステムのフレームワークが登場してくるわけですな。
もともとフレームワークというのは、
使用頻度の高い一連の処理を部品として用意しておいて、
それを使うことで高効率、高品質な開発、保守ができまっせ、
というものなんですが、
昨今、フレームワークというのは、動作設定の集まり、
というかお化けみたいなものになりつつあるある気がします。
つまり、条件や設定などはプログラムの外に出して、
プログラムの改変なしに動作を柔軟に（簡単に）変えられる、
というものにする方向なのでしょう。
Webの場合は、WebのHTMLデザインや細かい動作と、
そのバックで動作するプログラムをなるべく切り離す意図で、
いろいろ試行錯誤されたフレームワークが作られてるっぽい。
しかしね。
制御系でも、設定ファイルというものは存在します。
それはCSVだったり(Win)INI形式だったりするんですが、
これがまたいろいろ柔軟に変えたいという意向を汲み過ぎて、
やたら設定ファイルだらけになって、
さらにその設定ファイルの解釈や意味づけを設定するための
メタ的な設定ファイルまで出てきたりと、
非常に複雑怪奇なシステムを何度か扱ったことがあるんですわ。
今のJavaフレームワークなんかみてると、
フォーマットこそXML形式という今風な姿にはなっているけど、
流れ自体は、設定ファイルのモンスターになりつつある、
あの日の苦い思い出がありありと甦ってくるわけですよ。
Servletひとつ使うにも、
コンテキストの設定ファイルと、web.xmlを書かなければならない。
さらにStrutsを使うならstruts-config.xml、
log用にlog4j.xml、Hibernate用にhibernate.cfg.xml、
他にもAOPにSpring、独自のJSTLを使うならtaglibも、などなど、
こんなにあれこれと設定しなきゃならないなら、
さくっとプログラム1行変えた方がはやいよ？と思うことも。
実際、これは「もうJavaは終わってるよ」
といわれる大きな理由の1つのようで、
それらフレームワークを支える設定XMLの仕様もかなり複雑で、
素人がそれを把握するのはかなり時間がかかるはずです。
そこで、新たな候補生としてあげられるのが、
最近流行り（？）のRubyだったりするんですね。
結局、設定ファイルもプログラマが設定することになるなら、
最初から全部プログラムでもいいじゃん、
（よくいじる変数や定数はdefineやstaticで切っとけば良いし）
というのは、極端だけど正論ではあるのかも。
どうせWebアプリは、長くて3年、大体1年の使い捨てなんだから、
その程度のコストしかかけなくても良いものであるべきじゃないか。
となれば、RubyやPHPでいこうじゃないかと。
Javaなんかで重量級のシステムを組むより、
RubyやPHP、或いはperl（JSPやASPのみでも良い）あたりで、
ささっと書いて1人月程度のモノで十分。
まぁこうなってくると、昔のCGIに戻るイメージなんですがね。
でもまぁ、Java（ASP.NETもだけど）を使ったシステムは、
信頼性という意味では、
サーバスクリプティングのようなものよりも高いことは高い。
スクリプトだとセッションがプロセスとして動作するけど、
Javaや.NETなら基本的にWebサーバのスレッドで動作するので、
その分リソース消費も少ないし、速度もそれなりに速い。
Apache、Tomcatなんかは分散やクラスタリングにも対応してるし。
なので、1度に500とか1000とかアクセスがあるような場合は、
やっぱりJavaや.NETになるんでしょう。
要は、結局ケースバイケースってことか。
多分、1度に100アクセスもないようなシステムなら、
RubyやPHP、或いはperlなどで組むのが向くのかな。
動作をちょっと変えたければ、
設定ファイルをいじるよりもスクリプトを一部変えた方がはやい、
開発やメンテも少人数（1人とか2人とか）、
そういうのは、Javaは大仰過ぎでしょう。
例えば、言語はPHPで、フレームワークもなし、
DBもMySQLとかPostgreSQLあたりのフリーなやつでやる、
というのが安上がりで良い。
そして、同時アクセスが100を超えるとか、
処理能力やシステムとしての信頼性が求められる場合は、
やっぱりJavaや.NET C#などになるんだろうか。
DBは、コネクションプールやバッチ処理、XMLDBなど、
いろいろ強力なツールを使いたいなら、
やっぱりOracle、SQLServerあたりになるんでしょう。
余計なものはいらなくて普通にRDBで良いなら、
MySQLやPstgreSQLでも良いか。
ちなみに、mixiはperlとMySQLらしいですね。
mixiって、結構大規模なシステムの部類に入ると思うんだけど、
よくそれでやれてるなぁ、というのが正直な感想。
何かで聞いた話では、
ハードウェアを増やして分散させて対応しているということだったけど、
それにしても、あれだけのシステムが、
Javaはおろか、PHPでもRubyでもないというのが驚きです。
やっぱり、スクリプトは、プログラムを簡単に変えられる、
というのが最大のメリットだとは思うんですが。
処理能力的には、perlではちょっと不安が。。。
とにかく、当面私が関わっている今のシステム。
一度に500アクセス以上想定の大規模システムの予定なんだけど、
これ、まだつくる前なので、
JavaにするかPHPにするかなんてあたりも考える余地があるんです。
さて、どうしたもんかと。。
これもやっぱり、仕様は途中で簡単に変わるものだ、
という前提で設計せにゃならんのでしょうね。
（しかしなぁ、Web開発の経験1年にも満たない私に設計やらせるか？）
コーヒーか紅玉石か
IT・プログラミング
