デブサミ2010

event

ただただ、自分向けのメモ。

三周遅れのXP

  • つたわりにくいこと（TDDとUnitTestは違う）
    • 網羅的にテストを書いてしまう
    • ×テストが肥大化する。コストが高い
    • ○不安をテスト
  • カバレッジが...品質が...テスト計画が
    • 違う
  • 導入
    • ペアプロでいきなりテストを書いた
    • TDD写経会をやった
    • 個人で導入してみる。
  • ペアプロで重要なこと
    • コードの共有
    • 人の書いたコードを直しても問題ない
    • コードはチームのもの
    • ★コードの指摘は人格批判では無い。教育みたいなもの
    • 新人は学んだことはブログに書く（コードをさらすことに慣れる）
  • CI
    • テストを自動化してくれる(Hudson)
    • １日に１回は少ない。５分に１回に変更
  • ★SLOW TEST問題
    • テストが遅いのでテストをしなくなる
    • ローカルでテストを走らす時はH2DBでテストをしている
    • UPDATE/INSERTしないものはDBの入れ替えをしていない
    • 本来はモックを使うべきかも。カイエンを使ってたのでH2DBを使った
    • CIサーバではOracleを使っている。テストに３時間くらいかかる。
  • 計画と見積もり
    • ★アジャイルな見積もりと計画づくり（書籍）
    • ユーザーストーリに分割
    • プランニング効果
    • 5SP(ストーリーポイント)。ポーカー。みんなで見積もり
    • 2週間で１イテが調子がいい
    • 自分のチームが1週間で何ポイント使えるかわかる
    • 理想時間
    • 誰が何をやっているかを付箋で管理
    • 見えるか
    • Tracと付箋の２重化を使っている
    • バーンダウンを使っている（タスクの消化率を）突発で発生する作業を追加している
    • 正直に書く
    • ユーザーストリーではなく、機能ベースになっている
    • ★「プラクティスを採用するのが困難なら、その障害にアジャイルに対応する！」
    • DRY(Dont repeat yourself)
    • ★「大きなものは把握できるよう小さく分ける（五輪書）」
  • 感想
    • やはりXPは楽しいから好き
    • 来て良かったと思えるセッションだった
    • 自社サービスゆえに飛び込み作業は少ない気がする。SIの保守では差し込み作業が多くスプリントのタスク量を維持するのが困難な場合がある。

クラウド開発に役立つOSS

  • 企業内システムをクラウドサービスで再構築する
  • SIer的な話
  • 世の中のシステム全てがクラウドになるわけではない
  • 簡単に接続したい
  • クラウドインテグレーション
    • 問題：プロトコルギャップ,接続数が多い,１対1とは限らない
  • 開発時の盲点
    • AWSの契約をした時に個人契約情報の共有
    • ローカルに自分のテストを持つ/クラウドでテストに課金された
    • ★CIが困った
    • 共同開発
  • デプロイ先が多い
    • デプロイが多い
  • エレガントにつなげる
    • 目的用途別
    • Atomosphere
      • Comet(Ajaxサーバプッシュ)関連APIを抽象化するライブラリ(GAE/J上で動く)
    • mule ESB
      • SOAのインフラ[ESB(Enterprise Service Bus)]。Springで設定
    • Eucalyptsu
  • 感想
    • クラウドインテグレーターになれないSIerは時代に取り残されるだろう。
    • Azureについてはまったく触れられず


出張 DDD難民救済キャンプ 〜ドメイン駆動設計をあきらめない〜

  • 会場アンケート。読んだ人３割。読み切った人１人
  • 海外ではDDDが人気。2009年飛躍的にMLの投稿数が増えている
  • The Bookエッセンス
    • Evansはドメインランゲージという会社を作ってる
    • ドメイン = 「知識、組織、活動の領域」=アプリケーションの中核
    • 「複雑なドメインは、モデルに基づいて設計すべきだ」
    • 有能なドメインモデラーは知識の噛み砕き、をしている
    • ユビキタス言語 = DDDの真髄 = １つ覚えるならコレ。
    • モデル駆動設計 = ジェネレートだけではなく、実装からモデルに戻す = ビルディングブロック
    • 深いモデル = モデルを深化 = ドメインリファクタリング
    • ブレイクスルー = 深いモデルの先
  • 推進派
    • ソフトウェア開発が目指すべき最終系
    • テクノロジは進化するが、ドメインは変わらない。ドメインの追及は続く
    • 長期的に見ると変更に強くなる。
    • ★同じ言葉で同じものを見る
    • ★新しい言葉（深いモデル等）を見つけることで、見えていなかったもが見えてくる
  • 冷静派
    • 銀の弾丸などない
    • ブレイクスルーを待っていると納期が長くなる。
    • 全てに適用できない。Evansも90%は適用しないと言っている
    • ただ、複数の設計アプローチを持っておくことは技術者としての嗜み
  • 明日から始めるDDD
    • 敷居は高い
    • アジャイルが必要
    • 1.オブジェクトの広場の記事を読む
      • パターンの説明が中心
    • 2.InfoQ Domain-Driven Design Quickly日本語版
    • 3.ドメイン駆動。実装(C#,NHibernate)。
    • The Bookの翻訳してほしいなぁ
  • DAOからRepositoryにリネームする（冗談）
  • 実装者向け
    • 冗談だけど名前が表す。
    • Daoはデータアクセス
    • Repositoryはエンティティの集合をとる
  • ハンズオンモデラー
  • 設計者向け
    • 実装を踏まえた上で設計をする
    • 実装者と設計者が近い
    • ユビキタス言語を使っているかのレビューをする
    • ユビキタス言語レビュー。プロジェクトの用語集が打ち捨てられがち。実装に用語が引き継がれる
  • マネージャ向け
    • チームを編成するか、アサインするか
    • 業務のまとまりでチームを作る。
    • ストラジティックデザイン。The Bookの3分の1
    • 大規模なプロジェクトでは優秀な人をFW基盤チームに入れるが、DDDはアプリケーションエンジニアに注視している。基盤が充実してきたのなら、アプリケーションに注目する
  • 終わりに
  • 感想
    • 複雑なシステム開発ではDDDは必要になってくるだろう
    • ブレイクスルーとなるべき100%完璧なシステムを目指すという思想は好きだ
    • 基盤チームは花形なことが多いけどアプリチームを最重要するべきかも

★はなるほどと思ったこと。


庭園美術館を散歩して、揚州商人で酸辣湯面を食べて帰りました。楽しかったです。