格差について（３）

前回「格差を作っているのは実はわれわれかもしれない」という終わり方をしたのですが、どうも気になってしばらく考えてしましました。

確かにわれわれには成功者になりたい、という欲望がある。そして誰かが社会で成功すれば、一方で敗者が生まれます。もちろん共存共栄の場合もあるでしょう。しかしながら、むしろ誰かが多く取れば誰かの取り分が無くなるというゼロサムゲームであるというのが現実でしょう。

つまりわれわれ一人一人が成功しようと努力したり、その成功の結果を享受しようとすれば、必然的に格差が生まれるわけです。人が努力し才能を生かすことは明らかに正しいことだと思います。従って格差自体は悪ではない。

しかし、格差は悪ではないとしても、法外な報酬を取っておきながら社員を大量にレイオフするなんてことは倫理的に許されるはずがない。

ではどうすればいいか。われわれが格差を作り出しているとすれば、たとえ効果は少なくとも格差を生まない行動を選択し続ければよい。例えばビル・ゲイツが気に入らないならLinuxを使うとか。ウォルマートでは買い物をしないとか。

ところがこの考え方には限界があります。日雇いや派遣社員と正社員との格差がそうです。この場合、いくら格差が気に入らないといっても希望すれば派遣社員から正社員になれるわけではありません。派遣を辞めれば収入が途絶える。正社員の口はない。いくら間違っていると思っても、動けないのです。もはや派遣ビジネスというシステムに組み込まれてしまっている。自分の力ではどうしようもない、そんなところまで追い詰められている人も少なくないのではないでしょうか。

恐らく共産主義が理想的に機能すれば経済的な格差はなくなるでしょう。ですがソビエトや中国の例を見れば話はそう簡単ではないことは誰にでも分かると思います。ソビエト連邦や東ドイツが崩壊した時「今こそマルクスを見直そう」と（極めて狭い範囲で）批評家や哲学者が言いましたが、もはやマルクシズにリアリティを感じる人は誰もいないと思います。

どうすればいいのか。今のところ私にも答えはありません。

（以上）
.

RAD7.5（Rational Application Developer v7.5）でJSFを試す

RAD7.5の試用版を半日がかりでダウンロードしました。WebSphere Applicaition Server v7.0一式が含まれているせいでむちゃくちゃサイズ大きいです。インストールは思ったよりも早く出来たかな。2時間はかかってないように思います。

例のJSFのチュートリアルを試しました。最初のところだけですけどね。しかし意外や意外。全く問題なし。少しは引っ掛かってくれないと記事にならないんですが。

さすが標準仕様の威力でしょうか。MyFacesと全く同じコードが動いています。素晴らしい。

以下メモです。

▽ JSFプロジェクトとかにする必要はありません。素の動的Webプロジェクトでも問題ありません。

▽ JSFの実装はWASのj2ee.jarに含まれています。つまり*.jarをlibに入れる必要はありません。

▽ "java.lang.Object を解決できません"というエラー発生。
プロジェクトの「プロパティ」＞「Javaのビルド・パス」－ライブラリー(L)タブ＞「JREシステム・ライブラリー」を選択して「編集(E)」ボタンをクリック＞「代替JRE　WAS v7.0なんとか」ラジオボタンが選択されているので「ワークスペースのデフォルト JRE(D)」を選択で解決しました。

以上。
.

格差について（２）

スポーツ選手を例に取ってみれば、相当なリスクを抱えながら（ケガ、不調、不人気、短い選手生命）、自己を鍛練し、報酬を得るわけですから、まああんたらスゲーよ、としか言いようがないというか、多少高額な報酬を貰っていてもしょうがないかな、という気がしないでもありません。

才能があり、厳しい競争を勝ち抜いてきた人が多額の報酬を受け取る。そのこと自体は当然のことだと思います。

しかし、話をビジネスに持ってくるとまた違うんじゃないか、という気がします。

なぜならいかに優れた人でも一人では何もできないからです。

人が成功するためには多くの要素が必要です。アイデアの質。ビジネスのスキームを作り出す才能。チャンスがあること。人を集め、動かす才能。人脈。そして幸運。純粋にその人の才能だけで成功するのは難しいといっていいでしょう。

そのように大きな成功というのは非常に稀ですから、誰かが一旦成功するとそこに偶像が作られることになる。その偶像はしばしば強いオーラを放っています。あの人なら大丈夫だろう。あの人に投資すれば利潤が上がる。人と金の集まるオーラです。そしてその人の周りに新たなチャンス、資本、協力者が増えて行く。いい循環が作られます。

裏を返せば、どんなカリスマでもその人をカリスマたらしめる大勢の人たちが支えているという訳です。

しかし、経営者が莫大な報酬を取る会社では、結果としてカリスマの周りで循環する金は、あまり広い範囲には落ちてこないように見える。私の想像ですが、金は恐らく狭い世界で動いているに違いない。その世界にいるのは投資した大株主、別のカリスマたちでしょうか。地道に支えるサラリーマンには多くは回って来ないように見える。

20対80の法則からすれば、会社には8割の利潤を上げる2割の人と2割の利潤しか上げない8割の人がいる。莫大な報酬を得る経営者にとっては、そしてその8割の人はリストラ対象としてしか見られないでしょうし、ひょっとしたら上位2割のうちの8割すらもリストラ対象かもしれません。実際アメリカのレイオフってすさまじい印象があります。数字のためには労働者の人生を狂わせることもいとわない、という訳です。また、恐ろしいことにそれが市場から評価されさえもする。（市場＝大株主／投機家）

確かに使えない奴はいるし、使える奴もいる。でも使える／使えないだけで人を判断すべきではないのです。

イタタ。何を青臭いことを言っているんだ。使えない奴は要らない。そんな奴はこの社会で生き延びることはできない。当たり前じゃないか。

でも、仕事で使えないかもしれないけど、何かの役に立つかもしれないじゃないですか。その人がダメでも、その子供が何とかするかもしれない。人の価値・無価値は一概には言い切れないはずです。残念ながら今の社会は使えない人を生かす余裕が完全に失われてしまっています。

「夜と霧」のフランクルが嘆いたように、今の社会／会社では人は単なる利潤を上げる手段となってしまった。しかもそのことが疑われることもない。

人には格差がある。それは事実です。でも、だからといって法外なほど賃金に格差があったり、チャンスに格差があるのは間違っています。

放っておけば確実に格差は拡大します。古い付き合いの友人にはどうしたって手を差し伸べる。成功者たちは成功者たちと付き会うことを望むでしょう。それに誰だって自分の子供はかわいい。そして成功者とその一族のコミュニティで金が循環するのです。

残念ながらわれわれ一般人には、格差を縮小させることは難しいように思います。でも少なくともカリスマとされている人をよく見ることはできる。その人が言ったとされる言葉について考えることができる。二世だから、マスコミから褒められているから、という理由で無批判にあがめる必要もありません。ある程度は地位が人を作る。しかしその人自身の徳や才能があるはず。本当に素晴らしい人かもしれないし、実は中身空っぽかもしれない。あるいは強欲で冷徹な人間かも知れません。

高額な報酬を貰っているからといって、その人をあがめる必要はない。当たり前のことですが、そう考えると少しは余裕が出てきます。所詮は強欲なにいちゃんじゃないか。二世だけが看板で、大した人間じゃないな。見極めることが出来たらその人から離れて行けばいい。支持しなければいい。そうすればカリスマはカリスマでなくなる。

格差を作り、助長しているのは実はわれわれ一般人なのかもしれませんね。

（続く）
.

格差について（１）

asahi.comの「物価高を実感？　首相がスーパー視察、夕食は帝国ホテル」（http://www.asahi.com/politics/update/1019/TKY200810190137.html）という記事はよくできてますね。麻生が物価高を実感するためにスーパーに行ってトンチンカンなやり取り（記事からはそう受けとれる）をした後、帝国ホテルで夕食を取った、という内容。記事のヘッダーが実に的確です。そして政界のサラブレッド、お金持ち麻生のキャラクターが見事に揶揄されています。

さて、それはさておいて、もはや政治的に落ち着いてきたと思われる「格差」というキーワードについて今更ながら考えてみたいと思います。

「格差」という事象の扱いについては、世間・マスコミではほぼ一定のコンセンサスが出来てきたように思います。
日雇い／派遣／契約社員の問題。下流（中下流）と上流階級という図式（asahi.com）。格差先進国のアメリカを元に警告するもの。そして教育の格差から不安を煽るもの（ダイヤモンド社）。

私の見解も大したものではありません。格差はよくない。法外な給与（日本の一部の経営者、アメリカの経営者、マネーゲームの勝者）もいかがなものか。そんなところでしょうか。

しかし考えてみれば、格差やむなし、と思う自分のどこかにある。といっても給与の格差を是認しているわけではありません。ドラッカーもどこかで「経営者の給料は社員の20倍（だったかな？）を超えたらいけない。倫理的に許されない。今のアメリカの社会はおかしい」と言っていたと思います。常識的に考えてもやっぱり法外な報酬はいかんと思う。そうではなくて才能や能力の格差です。他には残念ながら家柄の格差もある。

スポーツ界では残酷なほどその格差が出ます。イチローや松井と一般人との違いは驚異的です。150kの硬球を打てる一般人はそうはいません。もちろん彼らは相当な努力をしている訳ですけど。

ビジネス界ではコネの格差が効いてきます。そこそこの会社の社長の息子であればいろいろと便宜が図られるのは間違いないでしょう。数億、数十億のビジネスを動かせる人を知っているかどうか。その人から目を掛けられているか。いるといないとでは大きな違いです。
伝統芸能は言うまでもありませんし、芸能人としてデビューする際にもコネの格差は効いてきます（二世というだけで生き延びられるほど甘い社会じゃないとは思いますが）。
戦後の教育（人は平等・差別はだめよ）によって覆い隠されてはいますが、日本社会では二世とか家柄というのが実に好まれるようです。また残念ながら負のベクトルにもそれは向かってます。

プロジェクトに入っていれば人によって生産性の格差があることがすぐに分かります。5倍、10倍の差だって珍しくありません。努力でカバーできることもありますが、努力もまた才能でしょう。やはりデキる人はデキるし、ダメな人はダメなのです。考えてみれば残酷で夢のない話です。でもありていに言ってしまえばそれが人生なのでしょう。

（続く）
.

JSFが気になっていた（４）一旦終了

一旦まとめます。

【評価】

JSFやっぱりイケてます。リリースポリシーが改悪されたSpring MVCに取って代わるんじゃないかと思います。
今後普及するであろうと考えられる理由は主に二つ。

１）イベントドリブンという発想
「イベントドリブン」のフレームワークというのは別に新しい発想ではありません。というかむしろ古いと言ってもいい。また、Ajaxを用いなければVBよりも貧弱な機能しかありません。にもかかわらずイベントドリブンを目指すことがなぜ評価できるか。

ServletといえばMVC。MVCはよいデザインである。そう言われてきました。しかし以前にも書いた通りMVCの発想で画面を作りこむとそこかしこにムリが出てくるのです（ま、当然ですよね）。
チェックボックスやラジオボタンをクリックした時にちょっと表示を変えたいという（Ajax未満の）要件は必ずある。JSFはそれに答えてくれます。一般的なイントラのWebアプリケーションであれば、JSFを使うことで画面表示周りの実装で相当楽ができるはずです。

２）SUNの公式の仕様であること
以下のメリットがあります

○WebコンテナベンダーとしてはJSFのサポート／非サポートを公式に謳わなければならない
StrutsやHibernateなどのいわば勝手フレームワークについて「公式にはサポートしない、自己責任で使って欲しい」と言うことができます。しかし公式の仕様であれば「対応していない」「対応している」を明確に言わざるを得ません。これはつまりJSFの仕様に則ったコードがJSFをサポートしたと主張するWebコンテナで動かなければ、Webコンテナのバグとして修正されることを意味します。

つまりベンダーとしてはある程度JSFにコミットせざるを得なくなるということです。ベンダーが提供するコンテナ－と密着した開発ツールや、サポートが期待できるでしょう。

○自由度が低い
Strutsのように、どんどん技術が発展して広がって行くことはないと思われます。また仕様の改善のスピードも遅いでしょう。それってデメリットじゃないかって？いえいえ。そうとも言えません。自由度が低く、改善スピードが遅いということは、ベンダーにとってはその技術をサポートし続けることが容易であることを意味します。また開発者にとっては学習体力が少なくて済む、というメリットがあります。

○「お墨付き」ネームバリュー
EJBなどは公式の仕様でなければ生き残れなかったと思いませんか？

以上
.

JSFが気になっていた（３）

チュートリアル＋αの実装をしてみたので報告です。微々たるものですが、ラジオボタンにイベントを設定してみました。

JSFがほとんど思った通りに動いてくれるので、公開する意味は薄いと思ってます（つまり、この実装を参考にするまでもなく出来てしまう）まあ、一応ってことで。
あ、一つだけ注意があります。私はEclipse3.4を使っているのですが、JSPをリフレッシュするためにはTomcatの一時作業ディレクトリを毎回クリアする必要がありました（サーバviewで対象サーバを右クリック、"Clean Tomcat Work Directory..."を選択、再起動）。

■JSP

<%@ page language="java" contentType="text/html; charset=windows-31j"
 pageEncoding="windows-31j"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<f:view>
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
  "http://www.w3.org/TR/html4/loose.dtd">
 <html>
 <head>
 <meta http-equiv="Content-Type"
  content="text/html; charset=windows-31j">
 <title>Radioボタンテスト</title>
 </head>
 <body bgcolor="<h:outputText value="#{evTest.bgColor}"/>">
 <h:form>
  <h:selectOneRadio value="#{evTest.bgColor}"
   valueChangeListener="#{evTest.changeBgColor}"
   onclick="submit()"
   immediate="true">
   <f:selectItems value="#{evTest.availableColors}" />
  </h:selectOneRadio>
 </h:form>
 </body>
 </html>
</f:view>

■Java Bean。

package at;

import javax.faces.event.ValueChangeEvent;
import javax.faces.model.SelectItem;

public class EvTest {
 private String bgColor = "WHITE";
 private SelectItem[] availableColors = { new SelectItem("BLACK"),
   new SelectItem("WHITE"), new SelectItem("SILVER"),
   new SelectItem("RED"), new SelectItem("GREEN"),
   new SelectItem("BLUE") };
 
 public String getBgColor() {
  return bgColor;
 }
 public void setBgColor(String bgColor) {
  this.bgColor = bgColor;
 }
 public SelectItem[] getAvailableColors() {
  return availableColors;
 }
 public void changeBgColor(ValueChangeEvent event) {
  String color = event.getNewValue().toString();
  setBgColor(color);
 }
 
}

■faces-config.xml。Nothing specialです。

 <managed-bean>
  <managed-bean-name>evTest</managed-bean-name>
  <managed-bean-class>at.EvTest</managed-bean-class>
  <managed-bean-scope>request</managed-bean-scope>
 </managed-bean>

以上
.

ちゃちなバッシング

悪いことは悪いというスタンスにケチをつもりはありませんが、ちゃちなバッシングが最近目に付いてあまり気分のいいものではありません。例えば前田議員へのマルチ業界からの献金。一昔前の自民党のトップに集まったのと比べると金額小さいねー。あっちで数十万、こっちで数十万。トータルで「少なくとも１１５６万円」とのこと（ソースはasahi.com）。ま、われわれサラリーマンにとっては安い金額ではないけれど、一人一年雇ったら一千万というレベルで考えれば何もできない金額と言ってもよいでしょう。政治家さんに集まるカネってこんなものなのか。じゃ他の人は一体どこからカネが入ってるんだろう。金額も数千万ってレベルじゃないと思うな。

政治にはカネがかかるってのは間違いなく政治家のホンネでしょう。いろんな団体が政治家に献金したり意見言ったりしてますが、これも要するにホンネはカネでしょう。私腹を肥やすか世のために使うか、程度の違いはあるかもしれませんが。カネがなきゃ人は集まらないでしょうし、カネがなくなれば人は去って行くでしょう。

話を変えて公務員バッシング。もう公務員ってのが気楽な家業じゃないってことは分かって来たんじゃないですかね。エリート官僚も勤め先によっては相当ブラックだって聞きますし。そりゃ楽している人は民間、公務員に関わらずどこかにいるでしょう（私の親戚・友人に公務員がいるわけではない）。だって１７：３０になったら帰宅ラッシュ始まってるよ。あまり信じられないけれどちゃんと定時に帰ってる人はいるんだね。それが楽なのかどうかは別問題でしょうけど。

それから、これはちょっと乱暴なロジックかもしれませんが、大麻栽培して新聞に名前書かれた人。誰かに迷惑掛けたんですかね。自分で勝手に吸ってるならいいんじゃないの。一般人の人生狂わすほど報道する必要があるのかね（まあ芸能人なら騒がれるのもしょうがない気がするけど）。タバコより健康に良いし、ニコチンほどの習慣性もないんでしょう。オランダだったら合法なわけだし。暴力団の資金源とか言うならいっそのことJTで扱っちゃえ。（一部中島らもの受け売り）

タテマエと世論の雰囲気だけで「善悪」という図式を作り上げてしまう。瑣末事大主義と杓子定規な無思考がその裏にあると思います。

瑣末事大主義が成果を上げるエリアもあるとは思いますが（ここで私はなぜか高木浩光という名を思い浮かべる）、そこはアカデミックな領域ではないでしょうか。細かい議論が本質的な問題を覆い隠してしまう可能性は常に念頭に置くべきでしょう。

以上。
.

JSFが気になっていた（２）

チュートリアルの１／３くらいまで来ました。

このチュートリアルの出来がまた素晴らしいですよ。ポイントは押さえられているし間違いもない。この通りやればできる。テキストを読めば理解も深まる。つまり、チュートリアルを補足する必要などないわけで、実は私のこのお勉強ページの存在意義も薄いことになる。

それはともかくやっぱりJSF相当イケてると思いますよ？今の所欠点が見当たりませんが？何でブレークしないんだろう？

あまり不思議に思ったので軽くググって調べてみました。十分な調査はしてません（するつもりもありません）が、まだ商用アプリケーションサーバ／開発ツールのサポートが薄いのが理由かもしれませんね。
他に苦戦する理由があるとすれば、斬新さがあまりない（イベントドリブンって特徴も地味ですし、ELのサポートも今となっては・・・）のと、StrutsやSpringから見ると後発になってしまっているってことでしょうか。

しかし、無責任に予測しますがJSFはこれからも生き延びるテクノロジーだと思います。だってシンプルでよく出来ている。

お勉強は続きます。
.

JSFが気になっていた（１）

実は前からJSFが気になっていました。
いまいちブレークはしていませんが、どうやらJSP単体よりもマシらしい。イベントドリブン的な発想も入っているらしい。

ちょっと腰を据えて検証してみました。

対象はapache myFaces。ApacheのJSF実装プロジェクトです。

チュートリアルはJSF Tutorial。

いわゆるWebのチュートリアルとは違って、Sectionごとにテキスト（PDF）と解答（ソース.zip）が付いている形です。最初は「なんじゃこりゃ」と思うかもしれませんが、テキストを読みながら解答通りに進めて行けばよいです。やり方さえ分かってしまえば非常によく出来たのチュートリアルです。テキストの出来もよい。JSFの何が嬉しいのか、ちゃんとポイントを押さえています。

まだ半分ほどしか進んでいないのですが、本日の感想。結構JSFイケてるのでは？しかしコアな発想はStrutsとかSpringに既に取り込まれている可能性もあるので、もう少し検証する必要がありそう。「イベント」をどう扱っているのか楽しみです。

以上。
.

ピクルス

今日は料理の話です。かなりマイナーな上に脈絡もなくてすみません。

夏の終わりからピクルスを仕込んでは食べています。
ベースのレシピは きゅうりのピクルス by 韓流マイブーム です。

このレシピをテキトーにアレンジしています。砂糖の量を減らしたり、ハーブを入れたり。ハーブはオレガノ、ディル、バジルあたりが無難なようです。ただし白ワインは外せない。日本酒では香りが出ません。リンゴ酢も試しましたが、米酢とそんなには違わない感じでした。
カレー粉を入れると恐らくはご想像の通り完全に間違いなくカレーピクルスになります。いつもだとしんどいけどたまにはＯＫ？
私だけかもしれませんが、野菜の詰め方が甘いのかこのレシピだと液が足りません。2倍の液を作ってちょうどという感じです。

野菜はきゅうり、にんじん、たまねぎが基本です。最近はきゅうりが高いので大根が多め。ショリショリと美味いです。パプリカも美味いけど高いのでいつも漬ける訳には行きません。若干芋っぽい食感になりますがレンコンも気分が変ってＯＫです。ひょっとして生ジャガイモ（手順で一瞬火を通しますが）もイケるのかな？

要するに洋風甘酢漬けです。夢中でバリバリ食べるほど美味いわけじゃないですが、普段冷蔵庫に漬かってると何気に嬉しい保存食です。肉料理の付け合せとしてはベスト。妻は喜んでます。やはり他人が作る料理は嬉しいらしい。

実は市販のピクルスと比べても割安感はありません。でも自分で買ってきた野菜で漬けるピクルスはやはり美味い。「野菜！」という感じがします。

それからピクルス液はポテトサラダの隠し味に有効。ちょっとオサレな味になりますよ。

まあ、気が向いたら奥さんに作って上げたらいかがでしょう。体験上1週間は軽く保存できます。

（2008/11/12追記）
最近わが家では3週間以上漬けたほうがおいしいという結論になってます。

以上。
.

Struts2（７）まとめ

結論としてStruts2は言うことなしですね。素晴らしく美しいと思います。
PojoでActionクラスが書けるとことか、XMLの使い方とか。疎結合デザインのお手本です。見事。最高のフレームワークの一つでしょう（他をそんなに知らないけど）。

強いて言えば自由度が高すぎることでしょうか。少数精鋭の開発チームなら最適な選択でしょうが、多人数で開発するとなると自由度が高い故にコードの統一感という意味では見劣りするかもしれません。敢えてケチをつけるとすれば。

例えるならSpringが中途半端なアーミーナイフだとすれば、Struts2は切れ味のよい丈夫な万能ナイフといったところでしょうか。Springはいろいろと便利なんだけど機能としてはややシシバリがきつくて息苦しい。Struts2は何にでも応用が効いて切れ味爽快。でも使い方間違えるとケガするぞ、という意味で。苦しいか。

まあSpringにしたってControllerインターフェースをインプリせざるを得ない局面があって、そうなるとほとんど生のServletに近いから、何でもできてしまう＝雑なコードになってしまうという穴もあるんですけどね。

しかしStruts2お見事、というのが総評です。
.

Struts2を試す（６）

日本製のチュートリアルを試しました。（１０ページまでですが・・・）
実践サンプルで学ぶStruts 2 - 生まれ変わった定番フレームワークを徹底解説

よく出来てます。分かり易いし。

2.0ベースなので、2.1では上手く行かないところもありましたが、大した障害ではありません。

■①大量にwarningが出る
jarが足りないのが原因だと思われます。
以下が揃っていれば（私の場合は）止まりました。
commons-collections-3.2.jar
commons-fileupload-1.2.1.jar
commons-logging-1.0.4.jar
freemarker-2.3.12.jar
log4j-1.2.15.jar
ognl-2.6.11.jar
struts2-core-2.1.2.jar
xwork-2.1.1.jar

■②label="ユーザー名" が必要。

×　<s:textfield key="username" />
○　<s:textfield label="ユーザー名" key="username" />

さもなければ
致命的: サーブレット jsp のServlet.service()が例外を投げました
java.lang.NullPointerException
at java.text.MessageFormat.applyPattern(Unknown Source)
at java.text.MessageFormat.(Unknown Source)
at com.opensymphony.xwork2.DefaultTextProvider.getText(DefaultTextProvider.java:70)
が出ます。

■③HelloUserが存在しないと起動時に怒られる。（これは正確にはチュートリアルの不備ではありません）

以下のメソッドのみを持つexample.HelloUserクラスを作成する。

public String execute() {
 return "success";
}

HelloUser.jspもテキトーでいいので何かHTMLファイルを作る

以上の変更で10ページまでは上手く行くことを確認しました。

以上。
.

Struts2を試す（５）

CRUD Demo Iを動かしてみました。
tutorialの節に入ってはいますが、実際にはほとんど読み物です。

Struts2の単純なアプリを読み解いて勉強するにはよいサンプルだと思います。Struts2の特徴やパワーも分かりやすい。ただサンプルアプリが既に出来上がっていて動かすだけになっているのと、読む量が多いのとで結構ダレます。Struts2自画自賛なところも好みが分かれそう。（面白いけど疲れる・・・）
ソースコードを未完成にしておいて読者に埋めさせる作りの方が断然良かったと思います。

しかし悪口ばっかしたり顔で言ってると、自分が薄っぺらい批評家になってきた気分。
そろそろ自分で０から作ってみなきゃな・・・
.

Struts2を試す（４）

引き続きStruts 2 + Spring 2 + JPA + AJAXを試しました。

まずは感想から。「詰め込みぎ」チュートリアルの一例です。せめてHibernateとの連携だけにして欲しかった。HibernateとSpringを触ったことがない人には何をやってるか分からないと思います。
Strutsのパワーを知るより、他のコンポーネントとどうやって連携させるかという点に主眼を置いたチュートリアルです。とりあえず上手く連携させることができるよ、と。

以下、作業メモです。

このチュートリアルはStruts 2.0をターゲットに書かれており、Struts 2.1で動かすためには修正が必要です。以下で出てくるエラーと併せて記載します。

いきなり"Dependencies"にあるjarで過不足ありそうな感じですが気にせず進めましょう。Spring、Hibernateのライブラリをダウンロード、名前が一致しているライブラリを適当に/WEB-INF/libに突っ込みます（後でjarライブラリのリストを載せておきます）。

ガイド通りコーディングしてTomcatで実行したところ早速以下のエラーが出ました。

アプリ起動エラー（ClassNotFound系）

Spring周りで以下のjarファイルが足りなかったようです。ClassNotFoundとなったクラスから地道にjarを探しました（そんなに大変でもなかったですが）。
log4j-1.2.15.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
以上をWEB-INF/libに入れ込めばとりあえずwarは起動します。

index.jspにアクセスすると以下のエラー群がでます。

致命的: サーブレット jsp のServlet.service()が例外を投げました
org.apache.jasper.JasperException: /index.jsp(7,0) TLDによると、タグ head の属性 debug は無効です

debug属性をはずして対応しました。

致命的: error when rendering
java.io.FileNotFoundException: Template /template/ajax/head.ftl not found.

FreeMarkerのtemplateを使うためstruts2-dojo-plugin-2.1.2.jarが必要です（地道にjarを展開して探しました）。WEB-INF/libに上記ライブラリを突っ込んで対応。

FreeMarker template error!
Expression parameters.parseContent is undefined on line 45, column 28 in template/ajax/head.ftl.
The problematic instruction:
----------
==> ${parameters.parseContent?string} [on line 45, column 26 in template/ajax/head.ftl]
----------

Troubleshooting guide migrating from Struts 2.0.x to 2.1.x にあるとおり theme="ajax" はobsoleteとのこと。移行ルールは以下の通りです。
（以下の情報は上記ページからそのまま持って来てます）

追加：<%@ taglib prefix="sx" uri="/struts-dojo-tags" %>

旧：<s:head theme="ajax"/>
新：<sx:head parseContent="true"/>

旧：<s:div id="jobStatus" theme="ajax" href="%{jobStatus}" updateFreq="5000" indicator="indicator">
</s:div>
新：<sx:div id="jobStatus" href="%{#jobStatus}" updateFreq="5000" autoStart="true" indicator="indicator">
</sx:div>
（"s"を"sx"に変更してtheme="ajax"を削除する）

これでindex.jsp画面からのPersonalデータCRUDが出来る筈です。

以下が最終的にWEB-INF/libに格納されていたライブラリ群です。

antlr-2.7.6.jar
asm-attrs.jar
asm.jar
cglib.jar
commons-collections-3.1.jar
commons-fileupload-1.2.1.jar
commons-logging-api-1.1.jar
dom4j-1.6.1.jar
ejb3-persistence.jar
freemarker-2.3.12.jar
hibernate-annotations.jar
hibernate-commons-annotations.jar
hibernate-entitymanager.jar
hibernate3.jar
javassist.jar
jta.jar
log4j-1.2.15.jar
mysql-connector-java-5.1.6-bin.jar
ognl-2.6.11.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
spring.jar
struts2-core-2.1.2.jar
struts2-dojo-plugin-2.1.2.jar
struts2-spring-plugin-2.1.2.jar
xwork-2.1.1.jar

以上。
.

MVCは作っているうちに破綻する（２／２）

次に View という位置付けについて考えてみます。実はこのViewが曲者なのです。

前回の投稿で、ModelやControllerという場所にも表示系ロジックを配置しました。私だって本当はこんなことやりたくない。表示はJSPに任せて、ModelとControllerはロジックに専念させたい。でもそうは行かないのです。

単純な例を上げてみましょう。例えば「10月4日（土曜日）」というデータがあります。このデータを画面に表示したい。JSPには例えば<c:out value="model.date"/>などと書いてある。とすれば、modelビーンのdateフィールドに"10月4日（土曜日）"をセットしてやればよい。JSPは入れ物を準備し、モデルに値をセットしているわけで、これはMVCモデルが美しく機能したと言えるでしょう。

しかし、ここで顧客が一言。「土曜日は背景色を青にしたいな。日曜と祝日は赤だ」。ロジック的には容易な変更です。従って断れない。この要件に対して以下の２つの実装パターンが考えられます。

１．JSP（以下はJSTLの例）で表示ロジックを組み立てる（以下がイメージですが多分この通りに書いても動きません）

<c:choose>
<c:when test="${model.date eq 土曜日}">
   <c:out value='<span style="background-color: blue">'/> ... </span>
</c:when>
<c:when test="${model.date eq 日曜日}">
   <c:out value='<span style="background-color: red">'/> ... </span>
</c:when>
...（祝日リストはどうするの？当日の表示は？？？面倒くさ！）
</c:choose>

２．Beanの中に表示ロジック込みでデータを入れ込む

Calendar cal = Calendar.getInstance();
cal.setDate(date);
int tmp = cal.get(Calendar.DAY_OF_WEEK);
StringBuffer sb = new StringBuffer();
if (tmp == SATURDAY) 
  sb.append("<span style="background-color: blue">");
  sb.append(date);
  sb.append("</span>");
... まあありがち。

１の案は恐らく「Viewに表示を任せるという方針に沿っている」というメリットしかありません。このようにずらずら書かれたJSPをメンテする人がかわいそうです。

２はいろんな意味で美しくはありませんが、少なくともメンテナンスはしやすい。UTもできます。

好みはあるでしょうが、私なら２の案を取ります。Viewの役割に固執するのは意味がないと考えるからです。

以上を センセーショナルにまとめると View という考え方自体現実的には破綻しているともいえます。

なぜか。

それはデータの表示方法はデータの意味と密接に関連しており、それはロジックによって制御されるべきだからです。View として独立させてしいまうのはそもそもムリがある。

もちろん単純なロジックであればJSPなりJSTLなり使ってシンプルに表示できるのが望ましい。メンテも容易だし、結果として美しいコードに仕上がります。しかしそんな容易な表示要件は残念ながら少ないでしょう。

最近MVC2という考え方も出てきていて、これはJSP＋Ajaxなどとして表示を制御するロジックをViewに持つ考えのようですが、これも完全な解決策にはなりません。恐らくはView用に最適化されたAjaxフレームワークができるまで・・・

結論として何が言いたいか。あまりMVCだとかMVC2だとかにこだわらず、センスと経験に任せてデザインするのがよい、そういうことです。

（以上）
.

MVCは作っているうちに破綻する（１／２）

MVCとはアプリケーションの内部のコンポーネントを、Model（データ） View（表示） Controller（ロジック）という３つのレイヤーに分けて考える思想です。例えばJava Webアプリケーションでは Model=JavaBean、View=JSP、Controller=Servlet などと言われたりします。

まあWebアプリを作ったことのある人であれば「こんなに簡単に分けられねーよ」ということを身をもって知っていると思います。実際に作ってみると
　▽　Model＝JavaBean + 業務ロジック
　▽　View＝JSP＋表示ロジック
　▽　Controller＝制御＋業務ロジック
と何となく曖昧に、ロジックとデータと表示が渾然一体になってしまうものです。
もちろん、例えば Actionクラスに一切業務ロジックを持ち込まず「これはコントローラだ」と気合いで分けてしまうことは可能です。しかし、それは単にロジックをファイルに分割したに過ぎない。実際のところアプリケーションは各所にロジックやデータを持つものであり、MVCという区分はあくまで便宜的なものなのです。

つまり、MVCは単なる方針として最初にざっくりと区別しておくだけに留め、それよりもロジックやJavaBeanをキレイに分けてデザインすることに注力した方が結果的にはよい設計になる、ということです。ざっくりと言ってもMとVとCの分類だけではいまいちなので、例えば

▽ Model1（データに近い系）
⇒ DB（DAO）
⇒ JavaBean (※1)
⇒ データ処理系汎用的ユーティリティ（型変換、エンコード／デコード処理など）
(※1) DAOとJavaBeanは分けた方がいいです。

▽ Model2（業務に近い系）
⇒ 業務ロジック
⇒ 業務系汎用ユーティリティ
⇒ 表示制御ロジック ※2

▽ Controller1（フレームワーク系）
⇒ 普通はフレームワークが準備してますね。StrutsのActionクラスとかSpringのControllerとか

▽ Controller2（業務に近い系）
⇒ 業務ロジックに近いController（Validationとか、ロジックによる画面の振り分けとか）
⇒ 表示制御ロジック ※2
(※2)は後述

という感じで区別するのが私の好みです。この分類でパッケージを分けてしまってもよいでしょう。
私見ではデザインの美しさは、JunitによるUTの容易さによって評価され得ると思います。つまりメソッド単位あるいはインターフェース単位で完全に独立しているのが望ましい。あまりMVCにこだわってもしょうがない。どうせMVCという枠組みは曖昧かつゴタゴタになるんだから。

（続く）
.

Struts2を試す（３）

一通りReady, Set, Go!を試しました。

引っ掛かった点は全てblogに書きました。全体的にかなり順調に行った感じがします。

【Ready, Set, Go! 総評】

ぱっと触っただけなので今後変るかもしれませんが、今の所欠点が見当たりません。Spring MVCよりもイケてんじゃないか、というのが印象です。

SpringではXMLの編集、コントローラの作成、Beanの作成を一通り完了しないと画面遷移が作れないところが面倒でしたが、Struts2ではXMLで汎用的な設定をしておけば（下記設定）JSPのガラだけでとりあえずの画面遷移の確認ができます。これは結構便利です。考えられてるな、という気がします。

<action name="*">
  <result>/{1}.jsp</result>
</action>

とりあえずコーディングして、動かして、UTして、という開発手法であれば SpringMVC よりも効率がよいのではないか、と思います。

それに、SpringMVC もそうでしたが、触っていて楽しい。具体的に楽しさとは何かと言えば「こうすればこうなるんだろうな、という予測がビシビシ当たる」それから「よく考えられた設計であることが肌身で感じられる」ことです。フレームワークには非常に重要な要素だと思います。

ただし、柔軟さ、容易さと成果物の複雑さは表裏一体です。言い換えれば、いろいろと柔軟に出来てしまうフレームワークを使うと出来上がったものが複雑になりがちなのです。その点、SpringMVC は適度な窮屈さがあって良いデザインだったと思います。Struts2の便利さが仇にならないか、もう少し見て行こうと思います。

【おまけ】

Localizing Outputで、package.propertiesの日本語版を下記手順で作成しました。（まあ大した手順じゃありません）
dosプロンプトから

> native2ascii.exe　（当然パスが通っているのが前提です）
パスワード
\u30d1\u30b9\u30ef\u30fc\u30c9
ユーザー名
\u30e6\u30fc\u30b6\u30fc\u540d

などと変換。生成された文字列を"package_ja_JP.properties"に貼り付け（以下のイメージ）

requiredstring = $\{getText(fieldName)} \u304c\u5fc5\u8981\u3067\u3059\u3002
password = \u30d1\u30b9\u30ef\u30fc\u30c9
username = \u30e6\u30fc\u30b6\u30fc\u540d
HelloWorld.message = Struts\u306f\u8d77\u52d5\u3057\u3066\u3044\u307e\u3059 ...
Missing.message = \u5de5\u4e8b\u4e2d\u3067\u3059\u3002

package.propertiesと同じ場所に置く。

以上の手順で問題なく日本語が表示されました。

参考サイト）Javaリソース・プロパティーメモ(Hishidama's Java resource/property Memo)
これは便利）www.Javable.Jp - Tools　（プロパティファイルエディタです。面倒くさいnative2ascii変換が不要となります）

「プロジェクトの人間学」完了のお知らせ

「プロジェクトの人間学」 全ての草稿をアップロードしました。

３０を過ぎてから感じること

今回は本当にどうでもいいような話題です（当人にとっては重要なことですが）。
歳を取るにつれて心身が変ってくることが分かります。３０の半ばとなった今の状況をまとめてみました。

▽ （悪い）秋、冬、春はフケが大量に出るようになりました。
シャンプーしてドライヤーで乾かした直後から一日中、かなりの量が出ます。シャンプーをいいもの（ケミカル合成品ではなく自然石鹸系）に変えても効果なし。恐らく乾燥が原因なのでしょう。頭も痒いです。
乾燥を押さえるため、妻の保湿化粧用品などを試していますが、少しは効果がありそうな感じです。

▽ （悪い）皮膚が痒い
夏と秋に痒さを感じることが増えました。
夏の痒さは格別です。汗かアレルギーかは分かりませんが、そのいずれかだと思っています。
関係があるかどうかは分かりませんが花粉症っぽい症状も出始めました。今の所有効な対策は見えません（というかまだ真剣に対策を考えていません）。
秋は乾燥系の痒さだと思います。体の一部がピリピリして痒い。夏よりはマシです。

▽ （悪い）直近の記憶力の衰え
残念ながら顕著です。何気なく置いたボールペンや書類を忘れて焦って探すことが多くなりました。

△ （良い）
若いときよりもある種の理解力がよくなりました。

－　本質をつかむ力
悪く言えば大雑把に、よく言えばこまごまとしたことに惑わされずに、問題の構造をすばやく把握する力がついたように思います。経験が蓄積されたのでしょう。

－　人の気持ちが分かるようになった
歳を取った人が考えることや、昔の偉人が考えたことが理解できるようになりました。
若い人の気持ちも、若いときは若いなりに理解していたのですが、今は別の角度から見られるようになりました。こいつも大変なんだなあ、とか。

幸いまだ大丈夫そうなこと

△ 体力の衰え
数年前から簡単なワークアウト＋柔軟体操を始めたせいだと思います。軽い運動＋本当に軽い柔軟ですが効き目はあるようです。体は大事ですね。

以上です。

「プロジェクトの人間学」に一件追加しました

標準化が達成すること
そろそろ終わりそうです。