凪瀬 Blog

わんくま同盟富山勉強会レポート

凪瀬 — Wed, 12 Nov 2008 01:10:00 GMT

11/8(土)にわんくま同盟富山勉強会が開催されました。

参加いただいた皆様、スピーカーを引き受けてくださった皆様、ネットから視聴していただいた皆様、どうもありがとうございました。

Wicketで変わるウェブ・アプリケーション開発

矢野勉氏のWicketのセッション。私が忘れ物をしたせいで、セッション時間を入れ替えてもらったという経緯あり。そんなわけで、自分はほとんど見ることができなかったのが悔やまれます。

RIAことはじめ

3月まで自分一緒にプロジェクトをやっていたhikaru氏に頼んでFlexの紹介セッションをやってもらいました。初スピーカーで緊張気味でしたが、セッション狙い（「Flexで作ったアプリは簡単なのにリッチだ!!」といった部分を伝える）は達成できたんじゃないかな。

おひるごはん

私を含む8人で県民会館から少々歩いたところにあるうどん屋（本当は蕎麦屋なんだけど、最近蕎麦を出していない）「鶴喜」にて。富山の名店。平日と土曜の昼しか開いていないのでなかなか食べに行けない。

Javaのこれまでとこれから

本当は最初にやるはずだったセッション。この日の勉強会の各種セッションの土台となる部分を統括的に。Javaの歴史のおさらいと、最近の方向性を提示して、各セッションで具体的なところを見てもらうというつもりだったのですが。

最近は、システム開発の環境改善には経済的側面をちゃんと考えないとうまくいかないよというのを痛感しているので、そちらの比重が高めにしてみました。

部屋移動

会場の都合で連続して部屋を確保できなかったので部屋移動が入ってしまいました。後半の部屋の方が椅子とか座り心地が良かった。富山県民会館を使うなら7Fの部屋の方がグレードが高いよ！

ライトニングトーク

katzchang氏によるプログラミング言語Ioの話。言語としてなかなか面白そう。

daisuke氏によるメールサーバの管理の話。スパムのリレーが多くて挙句スパムのブラックリストに載せられてしまった！スパム対策どうしよう！といった話題。スパム対策は本当に頭の痛い問題です。

矢野勉氏が飛び入りで１つやってくれました。業務で使うちょっとしたツールもJavaで書いちゃうぜってときに短く楽に書くためのコツみたいな話。潔い割り切りが重要。時間が余って晒し者タイムになったのでjava-jaでのLTの雰囲気とかそんな話も少々。

JavaからScalaへ

keisuken氏のScalaセッション。と見せかけて本題は氏の開発するWeb Flavorだったりしたセッション。手続き型のプログラム言語しかやったことない人にはかなりのデカルチャーだったのではないでしょうか。自分もチャンスがあったらScalaを採用したいなぁ。

やっぱAppletやちゃ

米林正明氏によるセッション。Java SE6 update10のドラッガブルアプレットとかそのあたりの話題。(参考：Java SE6 update10 を使って Applet で遊ぶ！)

これはデモのインパクトが大。会場が沸きました。JavaScript - Applet間での呼出しは実務でも応用が効きそうですね。注目すべき技術の一つでしょう。

なお、タイトルの語尾「～やちゃ」は「～だよ」の富山弁表現。氏は富山の出身だそうで、今回の勉強会もスケジュールの厳しい中駆けつけてくれました。感謝！

懇親会

近くのお店に移動して懇親会。掘りごたつ型の座敷だったんだけど、席移動がしにくいのが難点かな。各所で話が盛り上がっていたのはいいのだけど、話す人が偏ってしまいましたね。

1.5次会

数名はラーメンの富山ブラックの大喜（富山駅前店）に吸い込まれていきました。県外の人は一度食べておくと話のネタになるかもしれない。個人的には、一度だけでいいんじゃないのとも思う。

2次会

白馬館という老舗バー。富山駅前の近くなので、電車やバスなどの人がいる場合には最適。自分は思い切り面が割れているので悪いことはできません。えぇ。

3次会

代行運転を捕まえて凪瀬邸へ。矢野氏は前日からの疲れからか付いた早々に爆睡。もうひとりのメンバーkeisuken氏としばらく話をして就寝。

翌日

朝に二人を送って富山駅へ。お土産を購入。富山の黒作り（イカスミ入りのイカの塩辛）を勧める。関西方面のkeisuken氏を見送った後、東京方面の電車の発射まで時間があったので矢野氏と朝食。話し込んでいたら時間ぎりぎりになってしまった。無事に乗れたようでなにより。

月曜日

気が緩んだのか風邪をひいたらしく、寒気がしてヤバい。夕方に早退して実家で養生。レポートが遅れてすいません。

今週末は富山勉強会#1

凪瀬 — Thu, 06 Nov 2008 01:29:00 GMT

いよいよ今週末土曜日がわんくま同盟富山勉強会 #01です。

場所は富山県民会館です。当日参加も可能ですが、出来るだけ事前登録をお願いします。

10:40 ～ 10:50 わんくまについて
10:50 ～ 11:40 「Javaのこれまでとこれから」凪瀬悠輝Lv2くまー
11:50 ～ 12:20 「RIAことはじめ - Flex-Javaで簡単なアプリを作成してみる -」hikaru
12:20 ～ 13:20 おひるごはん♪
13:20 ～ 14:20 Wicket関連矢野勉
14:20 ～ 14:50 部屋移動
14:50 ～ 15:20 ライトニングトーク

katzchang
daisuke
スピーカー募集中！

15:20 ～ 16:10 「JavaからScalaへ、ScalaからJavaへ(仮)」keisuken
16:20 ～ 17:10 Teeda、Applet関連米林正明
17:40 ～懇親会

わんくま勉強会全般がそうですが、懇親会がメインです！

いろんな人といろんな話ができるのはこうした勉強会の大きなメリットですね。懇親会に参加される方はお店の予約の関係もあるので、できるだけ早く登録をお願いします。

Eclipseのリファクタリング機能を極めるその１

凪瀬 — Mon, 03 Nov 2008 23:49:00 GMT

Eclipseにはリファクタリングという便利な機能があります。このシリーズではその使い方をお送りしたいと思います。

まずは手始めにrename機能からです。

Eclipeのリファクタリングリネーム機能

リファクタリングの初歩としてリネーム（名称変更）が挙げられます。

Eclipse3.4では以下の要素に対してリネームを行うことができます。

型（クラス・インターフェース・列挙型）
メソッド
メソッドの引数
フィールド
ローカル変数
ジェネリクス型パラメータ
列挙
コンパイル単位(.javaファイルのこと)
パッケージ
ソースフォルダ
プロジェクト

Eclipse3.4ではリネームの際にテキストフィールド上で操作を完結することができますが、オプションを指定したい場合は▼をクリックすることでダイアログを開くことができます。

"Open Rename Dialog"を選択します。すると、選択中の要素に合わせたダイアログが表示されます。以下は特殊なオプションの存在する要素についての補足です。

型の場合

型のリネーム機能では、近い名前のフィールド名やメソッド名をリネームさせることができます。 Rename Typeダイアログで"Update similarly named variables and methods"「同名の変数・メソッドも更新する」を選択してください。 "Configure ..."を選択することで、型名のマッチング方法を設定することができます。

"Find exact names only"「完全に一致する名前だけを対象とします」
"Also find embedded names"「語中に埋め込まれた名前も対象とします」
"Also find name suffixes"「語尾が同じものを対象とします」

"Update textual occurrences in comments and strings"
「コメント・文字列中にある型名を更新する」
ではコメントやStringリテラル中にある型名を変更してくれます。ただし、英文を前提にしているのか型名はスペースで区切られていないとうまく識別できません。語と語の間に空白が入らない日本語のような環境下ではうまく機能しないことがあります。

"Update fully qualified names in non-Java text files"
「非Javaのテキストファイル中の完全名を更新する」
では.javaファイル以外のテキストファイル中に現れる、完全名（パッケージ名の記述を省略しないクラス名表記）を更新します。 "File name patterns"で対象となるファイル名を絞り込むことができます。

メソッドの場合

"Keep original method ad delegate to renamed method"
「オリジナルのメソッドを残して名称を変更したメソッドに処理を委譲します」
Adapterパターンなどの実装時に便利です。

フィールドの場合

"Update textual occurrences in comments and strings"
クラスに同じ

"Rename getter: 'getHoge' to 'getPiyo'"
"Rename setter: 'setHoge' to 'setPiyo'"
getter/setterを併せてリネームします

列挙の場合

"Update textual occurrences in comments and strings"
クラスに同じ

コンパイル単位の場合

"Update similarly named variables and methods"
"Update textual occurrences in comments and strings"
"Update fully qualified names in non-Java text files"
クラスに同じ

パッケージの場合

"Rename subpackages"
「サブパッケージも併せてリネームします」

"Update textual occurrences in comments and strings"
"Update fully qualified names in non-Java text files"
クラスに同じ

機械的なリファクタリングの力

いかがでしょうか。これらの変更は、コンパイルと同じく静的に機械的に行われるもので、現在ではかなりの信頼性を持っています。手作業でこういった作業を行う場合、時間がかかることもありますが、ヒューマンエラーによるミスの混入を防げません。その点からしても、これらの機能を使わない手はないでしょう。

過去にはこうした作業はヒューマンエラーによるバグ混入を恐れて、「極力行わないこと」としていたかもしれませんが、機械的に相当の精度で行われると言う前提のもとでは、そのリスクも再評価せねばなりません。

少なくとも、これらの要素の名称変更に対して昔ほどリスクを負わなくなったと言うことは把握しておいてください。名称変更がそれほどリスキーではなくなった今、名称未確定のまま開発を進めることは難しくなくなったということでもあります。

ジェネリックなクラスの階層を遡って適用された具象型を得る

凪瀬 — Wed, 29 Oct 2008 00:50:00 GMT

イレイジャではジェネリクスの何が消えるのかにて親クラスを継承する際に投入しているジェネリクス型パラメータはclassの情報として残っていることを述べました。

これを利用すると、

public class A<X> {

public class B<Y> extends A<Y> {

public class C extends B<String> {

といった継承階層があった場合に、C.classからA.classの<X>にどのような具象型が適用されているのか(上記例ではString型)をリフレクションで取得することができます。

Aの型パラメータのプレースホルダ<X>を取得
Bでsuper-classの型パラメータに渡されたTypeを取得
2のTypeが具象型ではなく型パラメータ<Y>なのでさらにサブクラスを走査
Cでsuper-classの型パラメータに渡されたTypeを取得
B<Y>のYにString型が渡されていることが分かるのでA<X>のXがStringであることが分かる

といった感じです。型階層がいくらあるのか分からないので再帰で処理するとよいでしょう。

サンプルプログラム

/** * 渡された型から継承階層を登って、 * 指定の親の型の指定の名前のジェネリクス型パラメータが * 継承の過程で何型で具現化されているかを走査して返す。 * @param clazz 走査開始する型 * @param targetClass 走査する対象のジェネリクス型パラメータを持つ型。 * 走査開始型の親である必要がある。 * @param targetTypeName 何型で具現化されたを確認したい型パラメータのプレースホルダ名 * @return 具現化された型 */ public static <T> Class<T> getGenericType( Class<?> clazz, Class<?> targetClass, String targetTypeName) { if (!targetClass.isAssignableFrom(clazz)) { throw new IllegalArgumentException( "型" + clazz.getName() + "は、型" + targetClass.getName() + "を継承していません"); } Stack<Class<?>> stack = new Stack<Class<?>>(); while (!targetClass.equals(clazz.getSuperclass())) { stack.push(clazz); clazz = clazz.getSuperclass(); } return getGenericTypeImpl(clazz, targetTypeName, stack); } /** * 型パラメータの具象型取得の実装。再帰処理される。 * @param clazz 現在の走査対象型 * @param targetTypeName 現在の走査対象のジェネリクス型パラメータ名 * @param stack 現在の走査対象型以下の継承階層が積まれたStack * @return 該当型パラメータの具現化された型 */ @SuppressWarnings("unchecked") private static <T> Class<T> getGenericTypeImpl(Class<?> clazz, String targetTypeName, Stack<Class<?>> stack) { TypeVariable<? extends Class<?>>[] superGenTypeAray = clazz.getSuperclass().getTypeParameters(); // 走査対象の型パラメータの名称(Tなど)から宣言のインデックスを取得 int index = 0; boolean existFlag = false; for (TypeVariable<? extends Class<?>> type : superGenTypeAray) { if (targetTypeName.equals(type.getName())) { existFlag = true; break; } index++; } if (!existFlag) { throw new IllegalArgumentException( targetTypeName + "に合致するジェネリクス型パラメータがみつかりません"); } // 走査対象の型パラメータが何型とされているのかを取得 ParameterizedType type = (ParameterizedType) clazz.getGenericSuperclass(); Type y = type.getActualTypeArguments()[index]; // 具象型で継承されている場合 if (y instanceof Class) { return (Class<T>)y; } // ジェネリックパラメータの場合 if (y instanceof TypeVariable) { TypeVariable<Class<?>> tv = (TypeVariable<Class<?>>)y; // 再帰して同名の型パラメータを継承階層を下りながら解決を試みる Class<?> sub = stack.pop(); return getGenericTypeImpl(sub, tv.getName(), stack); } // ジェネリック型パラメータを持つ型の場合 if (y instanceof ParameterizedType) { ParameterizedType pt = (ParameterizedType) y; return (Class<T>) pt.getRawType(); } throw new IllegalArgumentException("予期せぬ型 : " + y.toString() + " (" + y.getClass() + ")"); }

Seasarなど命名規約ベースのDIではリネームに気をつける

凪瀬 — Wed, 22 Oct 2008 09:45:00 GMT

Seasarでは命名規約に則ったクラス名のクラスのインスタンスを、同名のフィールドにインジェクションしてくれる機能があります。

public class SampleService { /** DIコンテナがインジェクションしてくれるフィールド */ public HogeLogic hogeLogic; public void exec() { // メソッド中はインスタンスフィールドにインジェクションされる前提でコードを書く this.hogeLogic.hoge(); } }

これは命名規約を理解して使っている分には便利なのですが、Eclipseのリファクタリング機能などでクラス名をリネームすると突如動かなくなることがあるので注意が必要です。

上記例で、HogeLogicをPiyoLogicにリネームするとしましょう。HogeLogicのクラス名を選択して、Refactor → rename を選択します。すると以下のようなバルーンが表示される(以下はEclipse3.4のスクリーンショット。確か3.2以前ではリネームは必ずダイアログでの入力だったはず) ので新しい名前―ここではPiyoLogicとしましょう―を入力します。

すると、Eclipseのリファクタリング機能でクラス名をリネームすると、参照している箇所を網羅的に探してリネームしてくれるため、プロジェクトの全ソース中でHogeServiceがPiyoServiceに変わります。

この際、クラス名は変更されますが、同名のフィールド名まではリネームしてはくれません。そのため、SampleServiceでのフィールド宣言は以下のようになります。

/** DIコンテナがインジェクションしてくれるフィールド */ public PiyoLogic hogeLogic;

フィールド名が元のままですね。これにより、命名規約違反が生じてうまくインジェクションされなくなります。コンパイルエラーは起きませんが、実行時にインジェクションを期待したフィールドがnull値となり NullPointerExceptionを発生させることになります。

デフォルトのリネーム操作だとこのような問題が起きるのですが、Eclipseにはフィールド名を含めたリネームがサポートされています。リネームの際に▼をクリックし、"Open Rename Dialog"とします。(キーボードショートカットのAlt+Shift+Rも活用しましょう)

"Update similarly named variables and methods"にチェックを入れます。同名の変数とメソッド(getter,setterなど)を更新する、という意味合いですね。そうすると、以下のように変数名も同時にリネームしてくれます。

public class SampleService { /** DIコンテナがインジェクションしてくれるフィールド */ public PiyoLogic piyoLogic; public void exec() { // メソッド中はインスタンスフィールドにインジェクションされる前提でコードを書く this.piyoLogic.hoge(); } }

Seaserなどを利用している場合は、クラス名のリネームの際にはこの点に気を付けて作業しましょう。

イレイジャではジェネリクスの何が消えるのか

凪瀬 — Mon, 13 Oct 2008 20:21:00 GMT

Javaのジェネリクスはコンパイル時に解決され、classファイルになった時にはジェネリクスの型情報は残されていません。そのためイレイジャ（型消去：type erasure）方式と呼ばれます。

と、ひとくちで言っても意味がよく分からないのでちょっと掘り下げてみましょう。

インスタンスからジェネリクスの型情報は拾えない

リフレクションを用いたとしても、インスタンスからジェネリクス型パラメータが何であるかを取得することはできません。

List<String> stringList = new ArrayList<String>();

のような変数stringListがあったとして、ここから<String>を取得するということができないのです。これが消えてしまった部分。

この変数stringListに対する各種操作において、その型の安全はコンパイル時に精査され、実行時にはあくまでObject型引数のメソッドを通したやりとりで動くのです。

クラス宣言に関わるジェネリクス型情報は拾える

しかし、型の宣言に関する部分はリフレクションで拾うことができます。ここが混乱する部分ですね。

親クラスを継承する際に投入しているジェネリクス型パラメータ
インターフェースを実装する際に投入しているジェネリクス型パラメータ
メソッドの引数・戻り値に用いられているジェネリックな型とそこに渡される型パラメータ
フィールドに用いられているジェネリックな型とそこに渡される型パラメータ

といった情報は拾えるわけです。

public class Piyo extends Hoge<String> implements IHoge<String> { private List<String> value; public List<String> get() { return this.value; } public void set(List<String> value) { this.value = value; } }

といったコードがあった場合、リフレクションで親クラスがHoge<String>型であることを拾えます。インターフェースも同等。また、フィールドやメソッドの戻り値・引数がList<String>型であることも拾うことができます。

11/08は富山勉強会

凪瀬 — Tue, 07 Oct 2008 09:18:00 GMT

中さんのところでも告知がでていましたが、わんくま同盟富山勉強会 #01の募集が始まっています。

2008/11/08(土)で場所は富山県民会館です。富山駅近辺ですので近県の方も是非いらしてくださいね。

LT(ライトニングトーク)の登壇者募集中です。発表時間は5分きっかり。こちらはテーマも自由ですよ。

アーキテクチャ選定を考える

凪瀬 — Sun, 28 Sep 2008 14:15:00 GMT

アーキテクチャ選定ではメリットとデメリットを考えるではフレームワークやアーキテクチャの選定は合目的でなくてはならない、ということを言いましたが、「システムの贅肉」という曖昧な概念を説明できていませんでした。

なんとなくイメージはできるんだけど、論理的な定義をうまくあたえれていない…。

骨格＝要件の大きさ

まず、確認しておくことは、システムの規模そのものの大きさです。要件定義・要件開発において、スマートになるように要件を決めよう、という話題ですね。

お客さんに「ちょっとここはこうなるようにしてほしい」とか言われたときに気にするのがこの点。今の設計に無理なく乗るなら軽く「いいですよ」と返せるところですが、その一見小さく見える事象に対応するために骨格がいびつになるような場合は悩んでしまいますね。

さて、そんな要件開発ですが、絶対値というか、要求される事象の大きさの下限は決まっていて、目的を達成するために必要な最低限の骨格を作るだけでも、とても大きな骨格になってしまうものもあります。

ネズミかゾウかではなくて、肥満か筋肉質かだろうが言っているのはこの骨格の大きさと、プログラミングのまずさからくる贅肉を混同するな、ということですね。

体の大きさ＝実装の大きさ

要件を実装するにあたって、実装手段によってソースコード、つまるところ実装の大きさが異なります。大雑把にいえばステップ数ですね。 (ステップ数という単位は誤差が酷いのであまり使いたくないですが、プログラムの大きさと正の相関を持つのは事実)

成長の早さ＝リリースまでの期間

システムを完成させるまでの期間、というのはゾウなりネズミなりが成人するまでの期間に相当するでしょう。

ゆっくり時間をかけて成長（プログラミング）が進み、完成までに数年の歳月を費やすシステムもあれば、非常に高速で成長しわずかに数か月で稼働にこぎつけるシステムもあることでしょう。

一般には、小さなシステムの方が、リリースまでの期間は早く、大きなシステムほどリリース時期は遅い。

養育費用＝開発コスト

成人までの間にどれだけの費用を投入したのかという数値ですね。

成人後の成長＝アジャイル性

アジャイルなシステムというのは成人が早い。割と未熟なうちにリリースしてしまう。リリース後の成長も大きく、成人してからも代謝が高いのですね。

対してウォーターフォール式のシステム開発などは、成人後にほとんど成長は止まってしまう。下手をすると成長などまるでなくて、「老後の介護」にばかり手間がかかるということもありえるのです。

代謝を高めるための設計手法と言うのもあります。こうした後の変更がある場合にそれは活きてくる。でも、いざそのときが来ない限りはそうした設計の良さというのは日の目を見ない。ソフトウェアの保守性はアップサイドリスクであるで言ったのはそういう事情のことなのですね。

寿命＝システムの寿命

システムは改修をしつつ、使われるわけですが、やがて寿命を迎えます。死因はさまざまですが、

土台となるOSやミドルウェアが死んだ
要求の変更に対応できなくなった

というのが大きいかなと思います。

システムというのは設計時に、いろんな前提条件を加味します。こういう部分は変更が容易なように、この辺は変えなくてもよい、とかいろいろ。「全部対応できるように」だといくらカネがあっても足りません。

それらの前提が覆ってしまったとき、それがシステムが死ぬべき時だと私は考えます。

贅肉・筋肉＝？？？

さて、問題となるのがここですね。「実装の質」と言いたいところですが、ひとことに「質」と言っても質にも種類があるので混乱しやすい。

例えば、高い処理効率（パフォーマンス）をたたき出すようなカリカリにチューニングされたソースコードというのは、変更に対してとても弱い。柔軟性に欠けるわけですね。

逆に抽象化を施し、仕様変更などにも柔軟に対応できるようなコードというのはパフォーマンスで劣る。柔軟だけど速度は遅い。

なので、これらのメリット・デメリットを考えた上で適度なところでバランスする必要があります。赤筋（反応が遅いが持続力がある）と白筋（反応が速いが持続力がない）みたいなもんですね。ハンマー投げの室伏広治氏は白筋が多く、マラソンは苦手だというエピソードもあります。状況を見て合致する「質」を選ばなくてはいけない。

ただ、一見して贅肉と分かるものも中にはあって、

コードクローン。要するにコピー＆ペーストによって冗長なコードになっている状態
構造化がうまくされていない
データ構造が非効率

といったところはかなり目立つ贅肉ですね。データ構造が悪いと、それを処理するプログラムも煩雑になって贅肉が贅肉を呼ぶ状態。

こうした、明らかな贅肉はそぎ落とすことでコードが数分の一になることがありますが、経験則からして1/10を超えない。どんだけ贅肉で太らせようとても骨格が支えられないほどには大きくなる前にシステムが破たんするのではないかと思います。人間の体重も世界記録では700kgぐらいらしく、限界までいっても10倍そこそこのようですね。

体脂肪を落とす効率

システムの贅肉を落とし、体脂肪率を10%にするためのコストと、体脂肪率10%から1%に落とすコスト、1%から0.1%に落とすコストが概ね等しいと思います。(無責任な社会、限定責任な社会から着想)

まぁこれは概念的な話なので数字が正確かというと怪しいのだけども、指数関数的だよね、というのは理解いただきたい。過度なダイエットは費用ばかりが嵩むので、ほどほどの贅肉は許容せざるをえないというわけです。

とはいえ、このほどほどの贅肉はコードが数分の一に縮むほどの贅肉じゃない。人間だって体脂肪率が0%になることはないでしょう？多少の脂肪に病的に神経質になっても仕方がない。

合目的なアーキテクチャ選定

フレームワークやアーキテクチャの選定は合目的でなくてはならない。そこで取り上げられる評価軸は「小規模 - 大規模」なんて単純な1軸ではないわけです。

システムの骨格の大きさ：要求事項の絶対値
システムの実装の大きさ：ソースコードの量
リリースまでの期間：開発速度
リリースまでのコスト：開発生産性
リリース後のコスト：可変性
システムの寿命

「時間、品質、料金」のうちから、2つを選択できる、なんてジョークがあるのですが、示唆深いと思いませんか？

これらのうち、何を活かして何に目をつぶるのか、その比率はどの程度にするのかというのが、アーキテクチャ選定で悩む部分です。小さなシステムは、使い捨てにすることもできる。リリースまでの期間が短くコストも小さいなら、定期的に使い捨てにするという方法論もアリでしょう。過去のリソースを使いたいからCOBOLで開発というのもコスト・リスクが見合うならあるいはアリでしょう。

コンセプトは前提条件の上に繰り広げられるものです。コンセプトだけ聞くと「ないわー」と思うようなことでも、特定のシチュエーション下では「そうせざるを得ないね」という合理的なものであったりするのです。

目的があってその実現手段としてアーキテクチャを選ぶのですから、アーキテクチャ単体だけを取り上げて安易に良しあしと言ってはいけない。

出来ることなら、技能あるチームで今風のアーキテクチャで今風の設計をするようなシステム開発をやりたいものですね。

アーキテクチャ選定ではメリットとデメリットを考える

凪瀬 — Thu, 25 Sep 2008 23:16:00 GMT

アルゴリズムであるとか、アーキテクチャというのは、必ずメリットとデメリットがあります。

プログラマは前提条件に合わせてメリットが活き、デメリットは表に出ないように考えアルゴリズムの選定します。アーキテクトがフレームワークやアーキテクチャを選定する時も同等です。

「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えようというエントリに対し、私はネズミかゾウかではなくて、肥満か筋肉質かだろうと答えたわけですが、さて、では筋肉質なシステムとはどんなシステムか？という話になります。

思うに、筋肉質なシステムというのは、選定したアーキテクチャなり、フレームワークなりのメリットが活き、デメリットが隠れるようになっている、そんなシステムのことではないでしょうか。

だから、それが例えばCOBOLで新規開発という話だったとしても、「過去資産を活用する」というメリットが大きく、その過去資産の活用のための工数がデメリットにならず、過去資産を流用することで未来の保守の工数が嵩むといったデメリットもでない、というなら筋肉質と言えましょう。

通常は、このメリット・デメリットを秤にかけて、相応にメリットが大きいという状況でないといけないわけで、東京海上の例では、本当にデメリットは小さいの？と疑問に思うわけです。

さて、ではJavaのフレームワークの中ではすっかり枯れた技術という評判のStrutsはどうなのでしょうか？Strutsは初出が2001年と古く、近年のAJAXなどの対応を盛り込むにはマッチしないフレームワークだと私は評しています。非同期通信を伴わない、単純なWebシステムで工数を抑えて機能を量産するというなら、それなりにメリットは活きるでしょうし、デメリットは隠れるのではないかと思います。

これはStrutsに限らず、PHPやRubyでの開発でも、状況によってはメリットは活きず、デメリットが表出することになります。そうしたミスマッチな選択をしたプロジェクトは、その無理から脂肪のような無駄なソースが膨らみ、デメリットだらけとなってしまうことでしょう。私が選定するならFlexなどのリッチクライアントとかかなぁ。ユーザ容貌的にそちらの方がマッチして贅肉が少なくなる気がしますね。

9/13は「エンジニアの未来サミット」

凪瀬 — Fri, 12 Sep 2008 14:26:00 GMT

明日は「エンジニアの未来サミット」ですね。私も参加します。会場では名札さげるようにしますので、お気軽に声をおかけください。

そもそも何のイベントなの？

ことの始まりは10年泥で話題になったIPAX2008。情報処理推進機構（IPA）が開催したものだったのですが、いろいろ議論を呼ぶ展開になりました。

これを受けて、Seasarで著名なひがやすを氏が「IT業界の重鎮に期待せず、アルファギークと学生の討論会はいかが」にて

とはいえ、重鎮たちと学生を討論させても、学生がIT(SI)業界に夢を持ってくれるとは思えないので、ここで1つ提案をしたい。
小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。
もちろん、司会は、ダンコーガイ。いいよね、弾さん。

と言いだしたのが始まり。本当に実現させちゃうんだからひがさんは凄いですよね。

自分はアルファギークと言うほどでもありませんが、会場をうろついているので学生の参加者の方は気軽に質問をぶつけてみてくださいね。