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 を放り込むと解決。

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

携帯小説

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

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

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

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

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

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

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

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

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

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