読者です 読者をやめる 読者になる 読者になる

第3回RIAアーキテクチャ研究会に参加してきました

RIA

RIAアーキテクチャ研究会 第3回セミナーに参加してきましたので、参加レポートを軽くまとめたいと思います。
Microsoft系の勉強会だったのですが、実は自分は余りMS系の開発に縁が無かったりします。前回Visual Studioを開いたのは8年くらい前かな...。
でも以前のエントリにも書いたように、ここ最近GUIアーキテクチャにはすごく関心があり、しかもこの手の技術はいつもMSの世界が先行していた印象を持っていたので、きっと色々学ぶことがあるだろうと思い、参加することにしました。
周りを見渡したらみんなWindowsノートPCで (Win8タブレットを持っている人もいました。うらやましー。) 、MBA持ち込んで参加した自分はちょっとアウェー感を感じました。(^^;)

以下にメモったことのサマリをまとめます。なにぶんMSの世界のGUI技術 (WPF/SL/WP/WinRT) には余り詳しくないので、不正確なところがあるかもしれません。

C#次世代非同期処理概説 by 河合さん (@neuecc)

.NETで用意されている非同期処理のパターンの解説と、C#5.0で言語レベルでサポートされる非同期処理についての解説でした。

非同期処理とは何か?なぜ重要か?
  • 並列は1つの処理をばらして処理すること。並行は個別の処理を並行して実行すること。
  • 非同期処理はブロックしない処理のこと。
  • クラウドと並んでバズワード
  • UIスレッドのブロックを防ぐことはとても大切。
    • WinRTとかは非同期のメソッドしかない。
    • JSはデフォルトそうだし。
  • Webサーバー側では同時接続への対応として使われてますね。
非同期処理を書いてみると...

ASP.NET MVCで作ったサーバーとSilverlightで作ったクライアントでライブコーディング、デモを行っていました。

  • 次期ASP.NETはnodeっぽい書き方ができる!
  • SilverLightアプリからそのWebサービスに接続。
    • 最初のサービスにアクセスして、その結果を受けて次のサービスにサクセスする処理をするとコールバックがネスト。見にくい!
    • 例外処理を書き込むとますますごちゃごちゃに
  • ネストや例外処理がしんどいので、.NETではそれらを解決するためのパターンがある。
非同期処理のパターン
  • APM (Asynchronous Programming Model)
    • 一番プリミティブな方法。
    • Begin**-End**のペアでの処理。
    • コールバックをネストするスタイル。
    • コールバックはUIスレッドじゃないので注意。
    • try-catchのネストはやはり必要。
  • EAP (Event Based Asynchronous Pattern)*1
    • **Async + **Completedのパターン。(デモで書いていたパターンはこれ)
    • 先にハンドラを書くので分かりにくい。
    • UIスレッドへのディスパッチはしてくれる。
  • TAP (Task Based Asynchronous Pattern)
    • いわゆるFuture、Deferredパターン。*2
    • TPLと呼ばれるライブラリを使う。
    • メソッドチェインでどんどんつなげていくスタイル。
    • やはりUIスレッドではないが、ContinueWith メソッドに引数でタスクスケジューラのコンテキストを渡すと、UIスレッドで実行してくれる!
    • 例外処理もContinueWithで。
    • ネストが平らになる!
  • Rx (Reactive Extensions)
    • LINQベース。LINQベースなので合成処理が強力。
    • @ITで連載してるので見てね。
    • すごくLINQっぽい書き方。
    • 例外処理はSubscribeの第2引数で。
    • メソッドチェインでスレッドコントロールも。
    • 拡張メソッドでさらにすっきりと書ける。
C#5.0
  • 言語レベルでサポートが加わる。
  • イベントハンドラに async を宣言しておき、メソッド内の非同期呼び出しに await キーワードを付けると、そこでブロック -> 継続をしてくれる!
  • 同期処理と同じように try-catch で囲める!
  • こっちだとTaskの方が使い易い。
    • Rxもawaitableなので、将来的は対応されるはず。
どれを選択すればいいか?
  • SL4ではRx。
  • SL5では将来を見据えてTaskを。
  • WinRTはTaskを使っていこう。
  • ストリーム処理ではRxがよい。
  • タッチイベントではイベント合成が複雑なのでRxが威力を発揮するのでは?
感想

.NETの世界では言語、フレームワークレベルで非同期処理の実装に対するサポートが充実しているのに驚きました。JavaScriptなど他の世界ではサードパーティのライブラリが乱立している状況です。うらやましい限りです。
C#5.0みたいに言語レベルでもためらうことなくサポートをどんどん入れていくのもらしいです。
MSにとって主軸はあくまでWindowsであり、Windowsの方向性に合わせて言語やフレームワークを進化させていくからこうなるのかなと思いました。土台部分を握っているMSならではの強みですね。*3

UIパターンの捉え方 by 尾上さん (@ugaya40)

日々色々な考え方が登場するUIパターンについて、どのように捉え、自分達の開発に適用していけばいいのか、といったことについてのお話しでした。

設計パターンを学ぶ意義
  • コミュニケーションの手段。
  • パターンには想定された状況がある。
    • プラットフォームに精通していなくても罠にはまりにくくなる。
UIパターンとは?
  • GUIの責任分割のパターン。
  • プレゼンテーションとドメインの分離。
    • テストの容易性。
    • プレゼンにドメインが引きずられない。
    • プレゼンはプラットフォームへの知識が必要。
  • プレゼン層のプラットフォームには意図した用途と設計がある。
  • UIパターンのコンテキスト。
    • プラットフォームを最大限に引き出す。
    • プラットフォームによって決まる。
  • UIパターンはいっぱいある!
    • 原初的なMVCAndroid MVC、原初的なMVP、Passive MVP、原初的なMVVM、MVVM2011...
  • 実装中立?
    • 基本はプラットフォームがあってできる。
    • でも他で用意されたら実装中立に。
UIパターンとプラットフォーム
  • UIパターンとプラットフォームは相互に影響を与えている。
  • プラットフォームはある程度用途や設計 (UIパターン) を想定して作っている。
  • プラットフォームへのフィードバックが発生し、それを受けて新しいプラットフォームが。
  • プラットフォームが変わるとそれに合わせてパターンも変化する。
  • MVCをとってもプラットフォーム別に派生するので乱立するように見える。
サンプルコードのとらえ方
  • サンプルには小規模、大規模、マーケティング向けがある。
  • そもそも設計パターンは実装で苦しまないですむようにするためのもの。設計のインプットの1つにすぎないことに注意する。
  • 小規模なサンプルだと冗長さが目立つだけ。
    • 分かりやすいが、責務を分けられなかったり、ユースケースが限られるので大規模な開発には使えない。
  • 大規模なサンプルは多くのユースケースに対応しているので、きちんと責務分割されている。が、読むの大変。
  • マーケティング重視サンプルは新機能紹介を重視している。実装例としてはとらえない方がいい。
    • DnDで作れるよ、系のサンプルとかこれ。
  • つまりサンプルから学習するのは良くない。
  • 先に概念を学んでからサンプルを見ること。
    • 成り立ちを知る。
  • サンプルコードの意図を意識すること。裏に必ず目標がある。
UIパターンの適用
  • まず概念の調査、理解。
    • まずは公式のドキュメントを当たる。概念が説明されているはず。
    • 責務の把握が重要。
  • サンプルの理解、解釈。
    • 実装要素を把握する。実装要素が何の責務を果たしているのかを把握する。
    • プラットフォームの何の機能を使っているのか?
    • 「この実装要素を使うから○○パターン」という解釈をしないこと!
  • 実装要素の取捨選択。
    • 責務が役割を果たすための実装要素を特定する。
    • なぜ冗長なのかを見る。
  • 重要な観点。
    • プレゼンとドメインが分離できている?
    • 特定の実装要素にこだわっていないか?
  • 責務分けに悩んだら?
    • Mから考えると悩む。MはViewと中間層以外と考える。
    • それがプレゼンテーションなのか?を意識する。
感想

UIパターンに限らず、何らかの技術を学ぶ際の心構えとして大事なことを説明されているなと感じました。
どんなデザインパターンフレームワークも産まれた背景には解決したい問題があったはずで、その背景を最初に知ることが一番大切だと思います。
しかしまあUIパターンは細かく分けると色々ありますね...。

集中と分散 〜 スマートフォンクラウド連携のアプリ開発と分業の実際​ by カブドットコム証券 谷口さん&セカンドファクトリー 東海さん、高尾さん

カブドットコムにて開発中のWindowsPhone + Azure (!) なアプリケーションの開発事例を主軸に、スマートデバイス開発、クラウド開発を取り巻く状況について色んなことを語って頂きました。すさまじいマシンガントークでした。なので以下のメモは色々取りこぼしがあると思います。(^^;)
実開発に基づいた話であるため、とても説得力がありました。

谷口さんのお話
  • いろんな技術が産まれてきました。
    • 必ず背景に課題がある。
    • 早く創って早く辞めるが重要。
  • 5年続かないとブレイクしない。
  • 日本は技術動向3〜5年後の後追い。
    • でも結果としてより深掘りできていると言える。
    • サービス、課題が先行しているのは強み。
  • 金融業界は?
    • ウォーターフォール大好き。顧客第1主義だからIE6捨てられない。
    • 銀行の仕組みは元々クラウドに近い。勘定系を共有したりしている。
    • オープン勘定系出てきた。Windows系結構ある。
  • 足りないもの。
  • Azure。
    • 企業のPaaS。
    • Windows DNAの直系の子孫。
  • WP7。
    • アプリベースじゃなくてステートベース。
  • 金融の世界の変化。
    • ArrowHeadの登場で知覚では追えない。
    • UXの進化。
  • 金融をシンプルをしたい!マーケットに新機軸を!
  • 金融の仕組みはすごく複雑。
    • 情報源様々。更新頻度、タイミングがばらばら。
      • なのでデータ優先。
      • モデル設計、UI/UX設計がすごく難しい。
        • 対応するためにプロジェクト立ち上げた。
  • AzureとWPを活用。
    • Metroは金融との相性がいいのでは。
      • ザッピングに合う。
    • クラウド経由のMVVMの確立。
    • RESTful Webサービスで層を分離。
      • 会社も分ける。RIA部分を2fcさんに。
2fcさんの話
  • UIが人の体験を変える。トイレのエアタオルとかはジェスチャーUI。
    • 「コンピューターが人々の言語を覚える」
  • NUI (Natural User Interface)
    • 人間の行動をそのままインプットに。
  • RIAのハイプカーブ。
    • 2012年は安定期の入り口。
      • マーケットが市場を引っ張っている状況。
  • ゲームニクスの考え。
    • DSが実現。
    • 本来の目的に意識を集中させる。動詞で説明する
    • ゲームの世界ではNUIが基本。
    • デザインからのアプローチではなく、行動から考える。
  • 実開発のお話し。
    • 7つのロール。
    • ワークフロー。
      • 割と基本的なウォーターフォール
      • 設計フェーズで人間中心設計を行い、繰り返し評価。
      • プロト作成までを短期で
    • 1つのUIで複数のプラットフォームは無理。
    • ミッション
      • 情報主体との体験を。アクティビティやステートにユーザーは興味がある。
      • Win8へつなげる。
  • WPの特性を活かした特徴。
    • People Hubから人をピン留めしてアクションにつなげるのが基本。
    • ザッピング感を。トランプの束に見立てる。
    • 複数見せ方。タイルとリスト。
  • クラウドサービス特有のUX。
    • クラウドサービスの特徴。
      • コネクティビティが重要。オンライン、オフラインがある。
        • 分離ストレージを使った。
      • 権限管理。
        • サーバー側での認証と認証トークンを分離。
      • マルチチャンネルへの配信。
    • アプローチ
      • データコネクティビティの管理。
        • ローカル、サービスの同期タイミングの制御。クライアントサイドのストレージを利用。
          • クライアント側のモデル作成。
        • メモリ上のモデルとストレージのモデルは構造を同じ。
        • クライアントにビジネスロジックを持たせない。
          • クライアントに落ちてくるモデルはVM
        • クライアント側コードでのアクセス性を考え、クライアント側のモデルを先に作った。
        • クラサバ間の通信。
          • サーバー側でクライアント向けモデルに変換するサービスをかます感じ。VM側でプレゼンテーション固有のステートが追加されることはある。
          • エラーもモデルに囲む。
      • UIの実装。
        • 基本的に操作からアプローチする。
        • PGが楽なのはプログラムからのアプローチだけど、それだとWhyが置き去りになる。
      • 専門家が分業して作るのがいいと考える。
Azureの話
  • チャートはみんなこだわる!Azure側でF#使ってチャートを作った!
  • オンプレ側では遅延に対する設計は徹底的にやった。
    • Azureでの遅延は結構大きい。
  • オンプレからAzureのキューに対してJSONをどんどん投げ、Worker roleで拾う。
  • とにかく非同期で連携!
    • いつ接続が切れるのか分からない。切れるものなのでHTTPで!
    • 起動したら初期化コマンドなしで動くこと
  • パフォーマンスとしてはとにかくまとめる。データをまとめてやり取りする。
  • AppFabricのキャッシュを使って認証情報をキャッシュ。
  • オンプレからのアップロード。
    • バッファにためて一括アップデート。
    • CPU負荷は上がったが性能目標を達成。
  • とにかく並列化を意識すること!
感想

分量多くてすみません。でもそれくらい情報量があったということです。実開発に基づいたお話しだけに、説得力もありました。ものすごく聞き応えのあるセッションでした。
一番強く印象に残ったのが、iPhoneをはじめとするスマートデバイスの登場によるUXへの変化やクラウド技術の広まりに伴い、我々ソフトウェア開発者の意識の変化が重要であるという点です。後者については今自分が携わっている仕事の関係上、普段からすごく実感していることではありますが。
この変化について行けるか否かで、今後開発者として生き残れるかどうかが決まってきそうな気がします。

MVPVMパターン by 児玉さん (@ mnow)

MSDNマガジンの12月号の記事で紹介された、MVPVMパターンについてのお話しでした。

MVPVMパターンとは?
  • Prismで導入。あとから名前が付いた。
  • MVVMとMVPの組み合わせ。
    • VMは本来あるべきプロパティ公開とコマンドの受付に専念。
    • Pがプレゼンロジックの複雑さに対応。
  • VMはユーザー入力やコマンドをPに渡す。
  • Pがナビゲーション (VやVMの切り替え) をして、Modelに入力を伝える。
  • VMの役割をPに切り出すことになる。
ナビゲーションの問題
  • MVVMではどこがナビゲーション?
  • メッセージ+ビヘイビア。
    • Behaviorを継承して作る。
      • VMからのデータを受け取り、メッセージボックスを出す。
      • 結果をコールバックに返す。
      • ダイアログの場合はWindowを作り、ContextにVMを渡す。
    • VとVMが密結合になる。
  • VM + DataTemplate。
    • XAML側でフラグメントを作り、切り替える。
    • この場合XAMLがナビゲーション。
  • 結局Vにコードを書いていることになる。
    • コードビハインド書いてなくても。
  • ナビゲーションはVとVMの両方を知らないといけない。
  • あとはアプリケーションクラスに持たせちゃうとか。
Presenterの役割 *4
Presenterの校正
  • VやVMも階層構造になるから、Pも階層構造に。
  • パネル等のコンテナだと複数のPを管理。ダイアログ単位に対応するPも。
Presenterの利点
  • ApplicationやVMからプレゼンテーションロジックの解放。
  • VとVMの分離をより容易に。
  • Undo、Redoの実装場所に最適!
  • VMからVをクローズするメッセージは不要。
Presenterの親子管理
  • 親Pが子Pのインスタンスの生成、解放をする。メモリ管理が容易になる!
  • コンテナのスライドの例。
    • 普通はコンテナパネルにストーリーボードを仕掛ける。
    • 両方のVとVMを知っている存在が必要!
      • その役割をPresenterに。
        • 親P、子の2つのPを作ることになる。
感想

MVVMとMVPの長所をうまく組み合わせたパターンと言ったところでしょうか。Controllerを復活させたMVVMと言っても良いかもしれません。とても興味深かったです。
実は話を聞いていて、このパターンはJavaFX2.0にぴったりなのでは?と考えました。
JavaFXには強力なバインディング機構があり、MVVM的なアプローチが向いていると思っています。しかし、ビヘイビアなどに相当する仕組みはないので、ナビゲーション部分はこのようにPresenter (Controller) を用意して担当させると良さそうです。暇なときに何かサンプルでも書いてみよう。

全体を通しての感想

このエントリの分量が多くなったように、情報量がとても多かったです。上にも書いたように普段MS系の開発をしていないのですが、違う世界だからこそ学べることは多いなあと思いました。
体調が良くなかったので懇親会に参加できなかったのがちょっと残念でした。次の機会があればぜひ。

*1:Flash/Flexのイベントハンドリングはこのスタイルですね

*2:自分のブログでも取り上げたjQueryのDeferredオブジェクトもこのパターンですね。

*3:もちろん同じことはAppleにも言えますね。

*4:個人的にはこの責務にとどまるのなら普通にControllerと呼んでも良いように思いました。Presenterのもう1つの役割である、複雑なプレゼンテーションロジックを伴うViewの操作は行っていないようなので。