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

勉強会

非同期、UIパターンって何？など現在私が興味を持っている分野の発表が多かったので参加してみました。

発表内容はこんな感じでした。

いやー、とても濃い発表ばかりでついてくだけで精一杯でした。ぜひ資料が公開され次第復習したいですね。
以下は自分メモ。

C#次世代非同期処理概観 Task vs Reactive Extensions

  • UIを固めてしまうような重い処理をUIスレッドに書くのはご法度。
  • 非同期処理でスレッドを占有しないようにしよう。
  • 非同期とは平行・並列処理という意味ではなく「スレッドをブロックしない」という意味。
  • ちなみにSilverlight・WinRTでは最初から非同期なメソッドしかない処理も多い。
  • しかし非同期処理を素で書くとネストしやすい。
  • さらに例外処理も絡むとカオスに。
  • というわけで、Rx(Reactive Extensions）などのフレームワークやawaitなどの言語拡張機能を活用してすっきり書けるようになろう。

@neueccさんのデモがすごかった。3分クッキング方式であらかじめ用意したコードをコピペするわけでもなく、流れるようなライブコーディングでした。あれは惚れる。

UIパターンの捉え方

  • UIパターンに限らずパターンを学ぶと他者とのコミュニケーションがしやすくなる。
  • パターンを学ばなくてもその技術に習熟すればいつかパターンにたどり着ける。
  • でもパターンを通して学ぶと高速道路に乗れる。
  • さらにはまりやすい落とし穴にはまる危険性を減らせる。
  • 開発者が知っておくべき、6つのUIアーキテクチャ・パターン − ＠IT
  • UIパターンにいろいろあれど、UIパターンの共通の目的は「プレゼンテーションとドメインの分離」
  • 後UIパターンに従うとそのプラットフォーム（WPFとかのこと）のパフォーマンスを最大限引き出せるようになる。
  • UIパターンではプレゼンテーション・プレゼンテーションの状態保持・ドメインの3つに分かれる。
  • でも、何となく開発を進めると上記３つの責務分割があいまいになっていくことが多い。
  • サンプルコードの読み方。サンプルコードはそのサンプルの目的によって3つに分けられる。
  • 小規模・大規模・新機能のマーケティング
  • 小規模なサンプルコードは読みやすい。でも、小規模ゆえにUIパターンに従って書くと冗長になりパターンのメリットがわかりにくい。
  • 大規模なサンプルコードは読むのが大変。ただただ大変。
  • マーケティング用サンプルコードは、新機能が便利だと感じやすいように書かれる。UIパターンに従って書かれることはまずない。
  • 要はどのサンプルコード読んでもコードからUIパターンの成り立ちとか考え方とかを抽出するのは大変。
  • UIパターンを知りたいなら、パターンの概念を学習してからコードを読む方式がお勧め。
  • 「実装要素（CommandとかBindingとか）を使っているからUIパターンを使っている！」と誤解しやすいので注意。
  • 実装要素を使わなくてもUIパターンを使うことはできる。
  • 「Modelに何を書くべきか？」から考えるとはまる。
  • Model以外（WPFではViewとViewModel）に書くことを考えて、Modelはそれ以外を担うすると良い。

「UIパターンの捉え方」表題に偽りなしでした。パターンの目的は何か？どう学習するか？パターンを適用するにはどうしたらよいか？といった内容が詰まった発表でした。ちょっと時間をおいて再度見直したいです。

集中と分散　〜 スマートフォンとクラウド連携のアプリ開発と分業の実際

  • 発表者は谷口さん。
  • 早く作って早くやめる。
  • そうそうそくそく
  • 2種類のスマフォにそれぞれアプリを作ったら2倍お金もらますか？ -> もらえません。
  • 一つのことを5年間続けることが重要。GREEもmixiもブレイクに5年かかった
  • バズワードで一気に流行った後下火になり、また見直されて安定期を迎える（黎明期 -> 流行期 -> 反動期 -> 回復期 -> 安定期）
  • 早い変化に対応するための開発運用体制が必要。フレームワークとインフラ重要。
  • iPhoneアプリに使い慣れた人から「株アプリは使いづらい」と指摘を受けるようになった。
  • 客はツールを使いたいわけではなく、株の売り買いや売値の確認などを行いたい。
  • 発表者が東海さんに交代。
  • いきなりNUIの話しに。
  • 「iPhoneみたいななのが欲しい」
  • ゲームニクス
  • ユーザの行動を観察することが重要
  • ワイヤフレーム作成・修正 -> アニメーション定義 -> プロダクト作成のサイクルを回して製品を作る。
  • iconographic vs infographic(ってなんだっけ？何かで聞いたけど忘れた）
  • WP7の開発環境についてくるデフォルトのスタイルは日本語だとフォントサイズやマージンなどのバランスが悪い。
  • メロトUIでは4ピクセル単位が一つのリズムになっている。
  • デバイスをユーザとして使い倒すことが大事。
  • スマートフォンで情報をザッピングする
  • 株銘柄をカードに見立てて管理。カード単位でザッピング。
  • 発表者が高尾さんに交代。
  • オンプレミスサーバーと連携した権限制御
  • クライアントのデータはWPの分離ストレージかAzureから取得。
  • 分離ストレージとAzureから取得するデータ形式を同じにすることでファサードをかませやすくした。
  • エラー時のデータと正常時のデータを同じ型にすることでView側はエラーと正常系を意識しないつくりを可能にした。
  • プログラムで何ができるかから要件を導出するとWhy(なぜそれが必要か？）が置き去りになりやすい。
  • 「ユーザが何をしたいか？」からアプローチすべき。
  • 発表者が再び谷口さんに交代。
  • 株チャートは1ドットずれるとクレームが来る厳しい世界。
  • Azureはレスポンスタイムが遅め。
  • 非同期でAzureのキューにバンバンデータを投げ込み、ある量がたまったらまとめてデータ処理する方式でパフォーマンスを確保。
  • インフラの理解を深めないとパフォーマンスを上げることができない。
  • Azureで画像を生成するロジックをF#で作った。
  • F＃erはM
  • Azureはパッチが当たって勝手に再起動とか普通にある

最初にカブドットコムの谷口さんが怒涛のマシンガントークで金融周りのバズワードの話しなどを展開。一転セカンドファクトリーの東海さんがデザイナの視点からゆったりとした語り口調で発表。次に同じくセカンドファクトリーの高尾さんが技術の話しを展開。最後に再び谷口さんがAzureでハイパフォーマンスを出すため位にはどうしたらよいかを熱弁して締める。発表なのに劇を見ているかのようでとても楽しかったです。でも密度高すぎて何が何やら。これ一日かけても足りなくらいの発表内容な気が…。

MVPVMパターン

  • VとVMを両方していてそれらを管理する何かが必要と思っていた。
  • MVPVMは以前からPrismに入っていた。名前がついていなかったので誰も知らなかっただけ。
  • VMは本来プロパティの公開とコマンドの受付が責務のはず。MVPVMでVMの本来の責務の戻す。
  • MVVMではView間のナビゲーション機能を書くところがなかった。
  • Messenger + Behaviorでダイアログ表示とかのナビゲーション機能をどこに書くか？
  • Applicationクラスに「ViewをnewしてそのViewに対応するViewModelをnewしてViewにVMをセットする」という処理を書いてませんか？
  • Presenterにこれらの処理を移動させる。
  • PresenterはViewとViewModelを知っている。また、ナビゲーション先などのViewを知っているPresenterへの参照も持ってよい。
  • アンドゥ・リドゥ機能をPresenterに持たせるとすっきりする。
  • MVPVMを使うと、VとVMは相互に参照する必要がなくなり、PからVへとPからVMへの一方向な参照にできる。

MVVMで「VMからVへ参照する」話しが出てくるたびにどうすればよいのか悩むことが多かったのでこれは一つの解決策になるかもしれませんね。ただ、Presenterが何でもやっちゃうスーパークラス化しそうで新たな悩みも生まれそうだと思いました。