Silverlight vs AIR あなたはどっち？

Flex


id:szk-takanoriさんのところでSilverlightとAIRの比較やっていますが、

私は断然AIRですね。


はっきりいって、Silverlight1.0はまず評価の対象にならないです。

Tech-EDで聞いたところによると、日本語の入力に問題がある点やコアコンポーネントなども無い点などが

まだまだ未成熟といったところが難点。1.1になってようやく評価の対象にあがるんじゃないでしょうか。


翻ってAIRですが、AIRもhtmlコンポーネントだと日本語対応はまだのようですが（たしか1.1から）、

Flexベースの開発スタイルをとれば問題ないです。

で、どっちかといえば従来のFlexベースの開発をする人が多いと思うので、それであれば特に問題はないと思っています。

といってもAIRもまだまだセキュリティまわりなど難点も多いようですが、比較論でいえばSilverlightよりは先行しているでしょう。

この辺はid:sato-shiさんとかid:arkwさんとかのご意見が聞けると嬉しいなあ。



というわけでこれからも実案件でRIAならば、Flex/AIRしか今のところ選択肢が無いです。

これがリッチクライアント開発での私の答え。

選択できる自由

OSS

ソフトウェアの世界でも同じ。特に Java 関係の OSS では、似たようなプロダクトが乱立している。
OSS を選択するということは一つの投資なのではないだろうか。

ソフトウェアの世界に身を置く自分は、製造者であり消費者でもある複雑な立場なわけだが、
ここでは敢えて消費者の立場に割り切って考える。

選択した OSS が絶対に生き残り、普及するという保証は誰にもできないのだ(たとえ開発者でさえも)。
でも、そのプロダクトを選択した(投資した)人が多ければ多いほど、そのプロダクトは成長し利用者もリターンを得る。
投資したプロダクトからリターンを得たければ、さまざまな形でそのプロダクトに関わっていく(経営参画する)ことで、
自分の思う方向に変えることも可能だ。

共通していえるのは、製品やサービスの選択肢が広がったぶん、コンシューマもサプライヤを盲目的に信じるのではなく、
自分の目で見て、考えて選択しなければならない時代になった、ということなのだ。

これが果たして良いことなのか、悪いことなのかはわからない。それでも僕は選択できることの自由を歓迎したいと思う。

http://d.hatena.ne.jp/y-komori/20080228/1204214825


id:y-komoriさんがGoodなエントリを書いていたので便乗。

私もほぼ同じ意見を持っています。


盲目的で自分の眼を持っていないことが一番危ない、そう思いますよ、ホント。

誰かが言ったから、誰かが使っているから、ではなく自分で使えそうなのか？自分のチームで使えるのか？

長期的に安定していきそうなのか？がとても大事。

いくら良いOSSでも自分のチームの人が難しくて使えないんじゃあ話しにもなりません。

あとは小ささ・組み込みやすさ、ですかね。OSSはそれ単品で使うことは基本的に避けたほうが良いと思っています。

その上に自分達のアプリケーションフレームワークをのっけて使うのがリスク回避のためには重要です。

部品として小ささ・組み込みやすさがあるOSSはやっぱり使いやすいし、カスタマイズもしやすいです。

またそれだけでは情報の受け手なだけなので、んじゃあ自分のチームが使いやすいこれは皆にとって使いやすいのか？を検証して、

世の中に公開していくことも大事なんじゃないかなと。この部分は小森さんの意見に足したいところです。

（小森さんはもう既にUrumaで実践されているので、当たり前だと思っているのであえて書かなかったとおもいますが＾＾；）


OSSだけでなく商用ソフトウェアでもそういう眼を養って先行投資すること、そして情報発信することが重要です。

ウィキノミクスの中で、こういう人のことをProsumer(Producer + Consumer)と呼んでいます。

上のエントリでAIR、Silverlightだったら自分はAIRを選ぶよ、というのも投資なのです。AIRマンセイ！というつもりはさらさらありませんけど。

良いProsumerになれるよう精進精進。



ウィキノミクス

ウィキノミクス

Teedaチュートリアル4-3

Teeda


前回はTeedaの画面遷移の仕方について学びました。

本チャプターではTeedaのPage間の値の引継ぎの基本について学びます。

TeedaはアーキテクチャとしてPRGパターン(XXX参照)を採用しており、

あるPageから別のPageへの値の引継ぎを自動で行います。

引継ぎをする際のルールとしては下記のようなものがあります。

  1. 引継ぎ元Pageクラスと引継ぎ先Pageクラスで同一のプロパティ名がある場合、Teedaは値を自動で引き継ぐ
  2. 引き継ぐプロパティは同一のサブアプリケーション内だけに限定する（サブアプリケーションについて後述します）
  3. スコープのアノテーションがついている場合、指定されたスコープ範囲内での引き継ぎとなる


前のチャプターで作った足し算の例でみてみましょう。

package examples.teeda.web.add;

public class AddInputPage {

	public Integer arg1;
	public Integer arg2;

	public Class doCalculate() {
		return AddResultPage.class;
	}

	public Class initialize() {
		return null;
	}

	public Class prerender() {
		return null;
	}

}

package examples.teeda.web.add;

public class AddResultPage {

	public Integer arg1;
	public Integer arg2;
	public Integer result;

	public Class initialize() {
		result = new Integer(arg1.intValue() + arg2.intValue());
		return null;
	}

	public Class prerender() {
		return null;
	}

}


上記のAddInputPageからAddResultPageでは、同一のプロパティarg1とarg2があるので

これらはTeedaによって自動で引き継がれます。

AddInputPageからAddResultPageのpackage文に注目してみてください。

Teedaは同一のパッケージの場合、同一サブアプリケーションだとみなして、値を自動で引き継ぐようになっています。

サブアプリケーションとは、ユースケースごとに設定されるグループの事です。

１ユースケース、１サブアプリケーションがTeedaの基本だととってもらえれば良いです。



では、あるサブアプリケーションから別のサブアプリケーションに遷移してしまう場合はどうでしょうか？

この場合、Teedaは値を引き継ぎません。正確にはアノテーションを指定することで引き継ぐことは可能ですが、

原則何も指定しない場合（これをTeedaではデフォルトスコープと呼んでいます）は引き継がない仕様になっています。




今日はここまで。続く。。。。