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変換が不要となります）

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

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

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

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

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

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

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

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

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

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

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

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

以上です。

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

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

Struts2を試す（２）

引き続き Ready. Set. Go! 通りに試しました。

まずは以下のエラー。

/HelloWorld.jsp TLDによると、タグ url の属性 var は無効です

以下のタグで出ています。

<s:url var="XXX" action="XXXXXXX"> 

リファレンスを見ると、id はdeprecated なので var を使えと書いてありました。deprecated ったって var が使えないんだったらしょうがないわけで、逆にvar ではなく id を使ったら動きました。struts-2.0.11.2(GA版)の標準機能をdeprecatedとして、存在しない機能を推奨しているとは、Tutorial と ドキュメントがずいぶん先走っているようです。
しかし、JavaScriptやCSSで多用する id 属性は確かに使いたくないですね。

途中で com.opensymphony.xwork2.ActionSupport のソースが読みたくなって探して見たのですが、、xwork-2.0.5.jar のソースが見当たりません。
http://www.opensymphony.com/xwork/download.action
Internet Archive で過去を辿っても 2.0.5 が公式にリリースされた形式がありません。（正直結構嫌気がさしました）

ということで2.0.11.2の検証を中止し、ベータの2.1.2で検証を続けることに。

これまで作ったWebプロジェクトのjarのみを入れ替えてすんなり行くかと思ったら、Tomcat起動時に以下のエラーが出てダメでした

Unable to load configuration. - bean - jar:file:/C:.../workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/webapps/Struts2Tutorial/WEB-INF/lib/struts2-core-2.1.2.jar!/struts-default.xml:46:178

Tomcat（あるいはEclipse）にゴミが残っているのではないかと思ってプロジェクトを削除／新規作成してもダメ。
調べてみるとException in struts2 server startupのページがヒット。ガイド通りにcommons-fileupload-1.2.1.jarをWEB-INF/lib追加したら解決しました。

次は <s:include> で日本語を含むファイルのincludeに失敗。チュートリアルでは当然英語なんですが、ためしに日本語入れてみたら見事に文字化けです。pageEncoding とかContentType とか設定してもダメ。日本語が消えたり、化けたりする事態は変わりません。
<jsp:include>では化けないので <s:include> に問題ないかいろいろ調べてみました。しかしWebには有用な情報はありません。（過去に8Kを超えるDBCSテキストで文字化けが発生するというバグはあったそうですが、今回の事象とは関係ありません）
ステップ実行などでソースを追ってみると、 org.apache.struts2.components.Include#getEncoding() でUTF-8でエンコードしているのが化けた原因であると判明。JavaDocによるとstruts.propertiesに指定する'struts.i18n.encoding'を見ているとのこと（基本ですかね。私としてはTutorialに一言欲しいところです）。ここで'Windows-31J'を指定すればよさそうなことが分かりました。どうやらstruts.xmlで指定できそうです。（参考）[Struts2] struts.propertiesが不要に

以下をstruts.xmlに追加すると、

<constant name="struts.locale" value="ja_JP" /><!-- ← 恐らく不要だがついでに -->
<constant name="struts.i18n.encoding" value="Windows-31J" />

<s:include>タグの文字化けは無事解消しました。

今日はここまで。

IT業界で効率を押し下げているもの（３）

▽　技術への無理解

技術が複雑になるにつれ、顧客／マネジメントにはますます理解不可能なものとなって行きます。

上手く行っていればまだいい。でも一度障害が起きるとその事象を説明するだけでも大変です。結果、現場の説明体力が非常に重くなる。エンジニアはますます勉強する時間を失い、くだらない資料の作成に追われることになるわけです。

技術を実際に触ったことがなくても、技術について語ることができれば（それも長ければ長いほど）エンジニアが評価される。出世ができる。そういう事態が続いています。

「エンジニアに必要なのは技術力ではなくコミュニケーション能力だ」という言葉を聞いたことがないでしょうか。これは明らかに間違いです。しかしそのスローガンがまかり通った時代が確かにありました（ひょっとしたら今でもそうかもしれません）。しかしエンジニアには両方の力が必要なのです。

技術がむづかしいが故に技術を使いこなせる人間よりも、まことしやかに技術を語れる人間の方が重視される。その風潮がIT業界の効率を押し下げている要因の一つだと思います。

IT業界で効率を押し下げているもの（２）

▽　技術のオープン化

これは逆説的な要因です。

Java、SQLなどオープンな技術が主流になることは基本的にはよいことだと思います。いろんな技術が生まれ、淘汰され、結果的によいものが残って行く。開発効率もよくなる筈です。
実際 Apacheを筆頭に、枚挙にいとまがないほど見事なソフトウェアが公開されています。かくいう私も今では Tomcat と Eclipse がなければ仕事になりません。

しかし、少し冷静に考えてみましょう。

例を上げてみます。
Struts は Webアプリケーションフレームワークという概念を一般に広めた、優れたアプリケーションです。Servlet, JSP, Bean というシンプルなMVCモデルを拡張し、大規模な開発と運用に耐える構造にしました。XMLによってMVCそれぞれを疎結合するという非常にエレガントなデザインとなっています。
その後、優れたWebアプリケーションフレームワークが他にもいろいろと出てきました。そしてStrutsもバージョンアップが重ねられています。つまり一口にWebアプリケーションフレームワークといっても、相当な数の選択肢があるのです。
これは裏返して言えば学習体力の増大とスキルの蓄積が困難であることを示しています。（Strutsのプロでも入ったプロジェクトでSpringを使っていたら一から勉強しなければならない、など）
しかし私は思います。今 Struts 0.9 で何が悪いのか。別に悪いことなどありはしません。多分、ほとんどのアプリケーションがStruts 0.9で開発できるはずです。しかし、今敢えてStruts 0.9を選択するプロジェクトなど存在しないでしょう。

次々に新しい技術が生まれ、そして消えて行きます。そしてエンジニアは新しい技術を追い続けなければならない。

その結果今どうなっているか。エンジニアによって持っている知識がずいぶん偏っている状況が生まれています。今流行りの「格差」という言葉を使ってもよいでしょう。好きでいじる人はどんどん詳しくなるし、そうでもない人はついて行けない、という事態です。

今、一口に「Webアプリケーションフレームワーク」と言っても実にさまざまなコンポーネントがあり選択肢がある。代表的な技術を使いこなすだけでも結構大変になっています。

技術のオープン化は確かに必要だと思います。しかし、その結果副作用が生まれていることに、エンジニアは注意が必要でしょう。すなわち、我々は新しい技術を追いつづけなければならない、ということです。逆に言えば能力のあるエンジニアにとってはチャンスでもあります。新しい技術を追いかける限り、先頭の一握りになれる可能性があるのですから。

IT業界で効率を押し下げているもの（１）

さまざまな潮流が業界全体の効率／品質を押し下げているように思います。

▽　セキュリティの重視

モバイルＰＣやインターネット接続が禁止されるプロジェクトが増えてきました。
外部から断絶された環境でコーディングを行うのは極めて非効率的な作業です。
Ｗｅｂ上にはコーディングサンプルや障害情報、技術解説、サンプルライブラリ（継承を要求するライセンスには気を付けなければなりませんが）など大量の有用な情報があります。それらの情報にアクセスできない環境でのコーディングは、かなりやりづらいものです。結果的に成果物の品質を押し下げるのは間違いありません。

そのリスクを考慮せず「セキュリティ」という大義名分だけで外部とのネットワークを遮断するのは単なる無思考といえます。セキュリティを重視して運用を定めるのであれば、納期／品質にリスクがあることを理解しなければなりません。（偉い人たちは決して理解しようとしないでしょうね・・・）

いたずらにエンジニアを縛っても何もいいことはありません。重要なシステムのコーディングを任せるほどエンジニアを信頼するのであれば、インターネットにアクセスするのだって任せればよいのです。めちゃくちゃにプレッシャーを掛けたりいじめない限り、悪いことなんかしやしません。開発用のネットワークと外部を接続するのが嫌ならば、ＡＤＳＬでも何でも引いて別のネットワークを準備すればいい話です。「セキュリティ」を絶対視して杓子定規に運用を定めるのは成果物の品質を押し下げるだけです。

エンジニアが設計／コーディングに集中できる環境を準備すること。その視点が必要だと思います。

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

追加しました。
http://sites.google.com/site/itzattamemo/Home/projectningengaku/shinzenbi

Struts2を試す

久しぶりの検証系投稿です。
Strutsの0.9や1.X系は昔触ったことがあるので、2.X系にチャレンジしてみます。

Springがじわじわと企業向けサービス重視に向かったということで、もう一方の勇Strutsのシェアが結果的に広がるんじゃないか、と思ったのが動機の一つです。↓

※ SpringSource Enterprise Maintenance Policy によると、企業で有償で利用している顧客は最新バージョンとバグ・セキュリティフィックスが即座に提供されますが、コミュニティ版は基本的に３ヶ月遅れになるようです。コミュニティが非活性化するのは明らか？？

本当は復習も兼ねて1.3からいじってみたかったのですが、ざっとみる限り1.X台は本質的に変ってない様子（当たり前か）。Struts2.0からコアが書き変ったということで若干の違和感はありつつも、試してみたいと思います。

とりあえずReady. Set. Go!は以下のトラップに引っかかったものの、ほぼ問題なくOK。

▽トラップ
アクセスするといきなり"There is no Action mapped for namespace / and action name HelloWorld"と怒られる

▽対応
struts.xmlはsource folderになければならないとのこと。eclipse かに座 ではソースフォルダにstruts.xmlを移動できなかったので、WEB-INF/classes フォルダを作成し、そこに struts.xml を放り込むと解決。

やはり質の良いドキュメントがあると早いです。
本日は以上。

携帯小説

「あたし彼女」という携帯小説が評判になっています。

私もちょっと読んでみました、こりゃ凄いですね。ちょっとしんどくて読みとおすことはできなかったのですが、それにしても「すげえなあ。ここまで来たか」という感じです。

といってもさかしらにこの手の表現をあざ笑おうというつもりはありません。

ちょっと乱暴な連想ですが、俳句という表現形式もまたシンプルで奥深いものがあります。短い単語を連ねる文学表現は、日本語に案外マッチするのかもしれません。

それにしても考えさせられるのはケータイというインプット／アウトプットツールが生み出す形式です。何を言いたいかというと、メディアによって人の表現形式も異なってくることを、ケータイ小説は如実に示しているということです。

ケータイ小説は恐らく手書きでは生まれなかった表現形式でしょう。「いや*ケータイ*小説なんだから当たり前だろ」というツッコミは勘弁して下さい。そうではなく、ここまで短い文章を、感覚的な口語体で連ねる、という表現形式です。

つまり、極端を言えばツールやメディアが表現形式の制約となるのではなく、むしろ積極的に表現形式を生んでいるとも言える訳です。
あらかじめ型が決まっていて、その型をどう自分のものにするか、そこで表現の質が決まってくるように思います。

振り返ってみれば、昔から毛筆から鉛筆、万年筆、ボールペン、ワープロと表現ツールは変って来ています。特に手書きからワープロへの進化は、文学という表現形式に大きな影響を与えているに違いありません。（この雑文だってＰＣがなければ生まれなかったことでしょう。）

また連想が飛びますが、村上春樹の「風の歌を聴け」という短編小説があります。これもまた短い文章を連ねて表現された文学です。この小説が発表されたときも「こんなの文学じゃない」「あれならオレだって書ける」などと言った人もいたそうです。新しいものが出たからと言って、安易に批判してはいけない、ということでしょう。

しかし、ケータイ小説をチラっと読んで、やはり重厚で体系的なスゴイ小説を読んで見たいなと思う人も多いのではないでしょうか。ひょっとして「カラマーゾフの兄弟」の新訳が売れているのも、ケータイ文化への反動だったりして。

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

「～でなければならない」思い込み
を追加しました。

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

良いミーティング／悪いミーティングを追加しました

村社会としての会社

日本の会社の特徴を表すのに、終身雇用制とか家族主義といったキーワードが用いられます。

その良し悪しはさて置き、プロジェクトに入って仕事をしているとやはり同じ会社のメンバーが強い連帯感によって結ばれていることがよく分かります。

例えばトラブル対応やミスの対応。例え直接的な関係はなくても、同じ会社のメンバーが起こしたトラブルには、他のメンバーも自分は役に立たないと分かっていても一緒に対応するとか、同じ会社のメンバーのミスはかばってあげるとか。

いや、当たり前と言えば当たり前なのですが、異なる会社のプロジェクトメンバー同士でかばい合うよりも濃い絆がそこにあることがはっきり分かります。

中には「同じ会社とはいえ、とばっちりだよな」と思っている人もいるようですが、祭りのように楽しんでいる人もいます。

そういうのを見ていると、やはり日本の企業というのは村社会的な結束があるなあ、という印象を持ちます。

村社会という観点から言えば、「ちょっとおかしいな」と思っても「村八分＝リストラ」が怖いから断れないとか、そういう束縛もあるのではないか、「オレは違う」とはなかなか言えない。単独行動が取りにくい。そういう特徴もあるように思います。

そういう会社＝村社会の中では、何とか楽しくやって行ける人と、ちょっと息苦しいなと思う人とに分かれるはずです。

さて、あなたはどちらのタイプに属するでしょうか？