桜、抹茶、白、日記

名古屋市在住のC++使いのcoderの日記だったもの。

わんくま同盟 大阪勉強会 #50 に参加

Event Programming

d:id:youandi:20110402:p1
何かMVVMネタのきっかけを作ってしまったので責任取って参加してきました。

わんくま同盟 大阪勉強会 #50
http://www.wankuma.com/seminar/20120804osaka50/

開会

40名弱の方が参加。

なぜか[twitter:@daruyanagi]さんも参加していてビックリした。基本プライベートだったけどまあ取材の一環な感じ。

窓の杜 - 【特集】“IT 勉強会スタンプラリー”で行く、全国コミュニティ探訪
http://www.forest.impress.co.jp/docs/special/20120712_546157.html

GUIアーキテクチャパターンの基礎からMVVMパターンへ by 尾上雅則さん([twitter:@ugaya40])

    • MV**系のパターンの整理
        • GUIアプリケーションの例
          • PresentationDomainSeparation
            • PとDの部分を分離する事によりそれぞれの独立性が高まり、共有性やテスト容易性、理解のし易さが生まれる。
      • XAMLの解説
        • WPFで採用されたXAMLの特徴について
        • XAMLの特徴はデータバインディングとCLRプロパティとは異なる独自のプロパティ機構
          • これにより、従来的なC#/VBコードからの制御ですべてを制御することは難しい。
      • XAMLとMVVMパターン
      • 他のMVC系パターン
        • XAMLからMVVMパターンが生まれたように、他のMVC系パターンもそのベースとなった技術を理解する事でMVCの役割が見てくる。
        • MV○系ではModelの部分の設計にはタッチしない
    • MVVMパターンの学習
      • MSが提供するMVVMのサンプルは様々なパターンがあり、それらから共通概念を得るのは難しい。
      • PDSを踏まえて、ボトムアップ的に責務分割の目的を理解する事が大事。
      • PDSを踏まえておけばどのようにするかの取捨選択により、大規模にも対応できるし、シンプルに軽量化する事も可能である。
    • 適用TIPS
      • Modelという名前に囚われないで、PDS視点で関心事の分離を行う。

塹壕よりLivetとMVVM by Posauneさん([twitter:@Posaune])


業務でのMVVM開発経験からのお話。

    • 一度目
      • MFC的なアプリをWPFに移行
      • Model:View:ViewModelの組み合わせの問題に直面
        • すべてが1対1では意味が無い
      • ViewModel:Modeの組み合わせがn:mになって破綻
        • 通知処理の実装において、ViewModelがその責務を行うようにしてしまった。
      • ViewModelの肥大化が問題となった
    • 二度目
      • ViewModelの肥大化の問題解決策としてLivetとDDD本に出会う
      • DDD的にシステム構造をMVVMに分解
        • Model：更新通知等の役割を持つので大きくなる
        • ViewModel：描画データのアクセッサ/ストア。ユニットテストし易くする。
        • View：描画
      • UI上処理が複雑になる部分はカスタムコントロールとして、コードビハインドベースで実装。
        • 外側から見るとコードビハインドのみで成り立っているように見える。
    • Livetの特徴
      • Model-to-ViewModelのコレクションの生成機能が便利
    • MVVMに触れたことにより
      • PDSの分離が理解出来る
      • テスト容易性を意識出来る

Modelの中身 - ドメインロジックパターン by 尾上雅則さん([twitter:@ugaya40])

    • 目的
      • MVC, DDD, PoEEAのModel
      • MVVM, MVCのViewModelやModel
      • WPF, JavaScriptのModel
      • これらは同じラベルは付いているが別物
    • PDSのドメイン
      • PresentaionPlatformとそれ以外に分離
      • PresentaionPlatformがどんなものになるかで、分離される内容も変わる。コードの共有性もない。
      • 分析
        • Webアプリケーションの場合、ステートレス。
        • リッチクライアントアプリケーションの場合、ステートフル。
      • XAML系の場合、メソッドは非同期となる
        • Modelは2つの役割を持つ
          • PresentaionPlatformからの入力や通知の受け取り
          • 自身の変化をViewModelに通知
    • ドメインロジックパターン
      • Web系のMVCは、PoEEAのTransactionScriptとなる
        • これは変更に対する追跡性が低い
        • Webアプリケーションの為の手法
        • ステートレスなアプリケーション向け
      • DDDのDomainModel
        • 業務をモデリングしたものがDomainModel
        • 変更に対する追跡性はTransactionScriptよりも高い
        • ステートフルなアプリケーション向け

時間が余ったのでLivetの解説

    • http://ugaya40.net/livet
    • 特徴
      • bind出来ないプロパティもbind可能とする
    • Modelはこう実装するとかこうあるべきというのはない。Modelは責務分割した結果の残りかすになる。

フィールドからみたプログラム開発」 by 中博俊さん([twitter:@nakawankuma])

前回の名古屋で聞いた話(d:id:youandi:20120707:p1)なので割愛。

SQL Serverにおける データベース設計手法 〜注目すべきポイントを簡単に〜 by 多田典史さん


DB設計手法と言う事でテーブルレイアウトがどうのこうのという話かと思ったら、SQL ServerのH/W構成をどうするといった話や、インデックステーブルやトランザクションログのディスクをどう分けておくかといった事について、参照メインなのか更新がメインなのかによって分けた方がパフォーマンスが出たりといったかなりマニアックな？内容だった。当然ついて行けなかった。あとで懇親会で皆さんの話を聞いたら後半の話は理解出来たという方が多かった。

セッション資料の1ページあたりの情報量がとても多いセッションだった。1ページの説明で10分位じっくりというのもあった。

閉会

特になし。

懇親会 (於：とらの穴(福島・新福島/中華) | ホットペッパーグルメ)

先週のBoost.勉強会の懇親会も中華食べ放題だったけど今週もだったw


京都アジャイル勉強会の主催者の１人の[twitter:@Posaune]さんと主にアジャイルの話をしていました。京アジャも参加者のコンテキストや参加目的が多様化してきたので分科会として対応していくといった話が出てました。あとはScrumBootCamp in 名古屋の参加者の方もいらっしゃって、アジャイルを導入するにはどうしたら良いかという話で、婦プロジェクトファシリテーションだとかTDDだとかアジャイルサムライだといった話をしていました。

参加しての感想等

スタッフとして参加していたのですが、タイムキーパーを担当していてPosauneさんのセッションはセッション時間を勘違いしていたのは大変失礼な事をしてしまった。

あと今回の大阪勉強会に参加して思ったのが、濃い面子が集まっていたなという事。
最近の名古屋勉強会ではそういった層の参加者はいない感じなので、参加者数が増えないのはそういった層を引きつける内容になっていないからではないかと思うなど。