日々の破片

_ 時代的な制約

Strutsって、まさに時代的な制約による（アクションが単一インスタンスなんて完全にそうだと思う……と書いた先から不安になってきたが、本当にそうだっけかな？）アーキテクチャを採用して、逆に時代的制約によって好まれて、で、時代的制約によってけなされる（そりゃ、2008年現在から見れば古臭いのは当然）存在であるなぁと。

にもかかわらず、嫌いではない。

フルスタックのよさというのは、Instant RailsとかLocomotiveに端的にあらわれているけど、確かに良いものだ。だって、楽だもの。でもこれは、Microsoft的アプローチと言ってよいと思うけど？ SQL*Server＋IIS＋ASP.NET（ASP）＋System.Enterprise（MTS）＋Visual Studioというアプローチみたいだ。

別に対抗させる意味はないけど、これに対してバザールアプローチというのを対置させてみる。カーネルはLinux、libcはGNU、コマンドもGNUというようなやつ。別々に開発して誰かが取りまとめて（でも取りまとめる誰かがまた複数いるわけで）、みんなで好き勝手に使う。WebサーバーはApacheかも知れないけど、CGIエンジンはPHP、いやおれはPerlが好きだとか、で、RDBMSにはPostgres、いやMySQLとか、ちょっとひねりをきかせてFirebirdというのもあるよとか、そんな風に別々に作られたものを自由に組み合わせて自分のためのシステムを作る。

Strutsはバザールアプローチに向いたフレームワークだったと思う。何をしてくれるかというと、何もしない。ただ、URIからのルーティングをするだけだ（と、おまけのようにTagLibが付いていて）。でもJ2EEが想定したWebアプリケーションの構造を強制するだけの能力は持っている。

奴隷生活は楽だ。自由な生活は不便だし効率もそれほどは良くない。というような考えもないわけでもない。目覚めよと叩き起こした人間が起こされた連中に袋叩きにされるというのは、魯迅の好きな寓話だ。

レールという言葉が、歯車とほぼ同義語だったころを知っているわけだけど（親が敷いたとか、教師が敷いたレールを進む人生みたいな使い方をするんじゃなかったけな）、どうどうと名乗られると別にネガティブな意味ではなく、まあそう悪いものではないとも思う。というか楽だし。

J2EEはある頃までは、そういうバザールアプローチで、いろいろあってさてどれを選ぶとかやっていたのだが、いつのまにか内部で淘汰が始まって、気づくと外側の世界のほうが楽しそうになっていた、という印象も受ける。いや、結局はIBMあたりが巧妙に敷いたレールだったのだよ、という印象もあるわけではあるが。

そこで、もう統一的アプローチの時代なのだ、と考えてみても良いかも。つまりは、Instant Strutsというのは今さらだけど、展開するとApache＋AJP＋Tomcat＋……な環境が勝手にそろって（いつでも削除できるように単一ルートディレクトリの下に配置されて）、いつでもレディみたいなやつ。あるいは、RubyGemsみたく、必要なjarを集めまくってくる仕組みとか。ふむ、ちょっと興味はある（プライオリティを考える必要はあるな）。

_ コードよりも仕様

public foo(String s) {
}

なメソッドのJavadocに、*param s なんちゃら名。名称未決定ならnull。 と書いてあれば

if ("foo".equals(s)) {

と書く。あとになって、s.equals("bar")とか書いてあったらそりゃメソッドの実装がバグだというだけのことだ。
逆に*param s なんちゃら名。null不可。と書いてあれば

if (s.equals("foo")) {

と書く。仕様を決めずにコードの詳細をうんぬんするのって、ばからしい。
というか、入出力の仕様も決めずに適当にその場の勢いで、どっちのオブジェクトを主（メッセージの送り先）に決めるのか？