デブサミ2010行ってきました（二日目）

devsumi2010

今シーズンは二日とも行ってきました。

【19-C-2】本当に問題ないですか？〜大規模RIA案件50社をこなしてきたプロが語るエンタープライズにおけるCloud＆RIAアーキテクチャ

失敗事例を聞くことができたのが嬉しかったです。こういう情報こそ知りたかったですから。

  • データを物理的に何処で管理するかを求められる場合がある。
  • 国内かもしくは何処で蓄積されるかの明示化。
  • ロサンゼルス市はGoogleの政府専用のクラウドを提供されているので問題ないが、日本国でクラウドを利用する場合はユーザのポリシーを確認すること。
  • パブリッククラウドはお安いが、プライベートだと高くつくので、安い見積もりを出した後プライベートに変えるのは受け入れられない。
  • データの特性によってパブリック・プライベートの併用も視野に入れると良い
  • パブリッククラウド上のデータセキュリティも日々進化しているの
  • アプリケーションの動きが遅いときがある
  • 処理に問題がなくても、レイテンシが悪い場合がある。
  • サーバの処理が同じ処理でも時間が異なる。
  • 通信はどうしようもないので、クライアントアプリ側の工夫がいる
  • 変更のないデータは再取得しないなど、転送量が小さくなる工夫がいる
  • サーバのパフォーマンスが悪くても何とかなる設計がいる
  • 既存システムのリプレース案件だと、今までやらなかった操作をやるようになり、当初想定のデータ転送より多くなる場合がある

まとめ

  • 小さく始めたい、実験的なことをやりたいなら適していそう
  • 大量データを扱うものは、レスポンス面で厳しいかも（たとえばどこかの会社の業務システム）
  • 情報保護として、データが何処にあるかを明示するのも難しい（そのうち日本国にサーバを置くようになると思う）

【19-B-3】三周遅れのXP -僕とドワンゴのXP-

1週目はケントベック
2週目は@kakutaniさん
3週目が@yoshioriさん

4つの価値

  • コミュニケーション
  • シンプルさ
  • フィードバック
  • 勇気
  • おやつ神社というブースを作ってそこを集まって気軽に話せる場所にしているらしい。タバコルーム以外でもこういう場を作れるのは良さそう。
  • テスト駆動は、品質管理やテストの話ではない。開発手法の話。
  • ペアプロの会があるらしい。今までやったことないのでちょっと体験してみたい。

TDDをやると

  • 自分の解決すべき問題を明白に
  • すぐにテストを実行
  • 開発するためのテストを書く
  • 品質を担保するためのテストでない

　が、TDDという開発手法自体が品質アップにつながる

  • 今日リリースの案件があっても、チームリーダーがイベントでスピーカーをやりにいくこともできる！

Q:UnitTestになってしまい、網羅的にテストを書いてしまう
A:不安をテストする

文化を根付かせるためには

  • 社内でTDD写経会（Web+DB Press Vol.35を参考。1〜36の総集編CDに入っているのかな？）
  • ペアプロ（コードの共有をしていると認識しやすくなる？）
  • 新人にブログを書かせ、返信もブログでする。コードを晒す事に慣れる


ちょっと疑問
僕が今まで関わってきた案件だと、自分で実装したところを自分で修正するという文化がある。これはほかの人が直してしまうと間違った本人が何処がおかしいかを認識しないからという事らしいのです。これにも一理あるなあと思うのですがどうなんですかね？


CI（継続的結合）ツールを使う

  • Hudsonなど。テストを自動実行し、落ちたらメールで教えてくれる。
  • 使い出すとSlowtest問題に直面するらしい。

　テストに時間がかかる→select系はデータを入れ替えないでやるなど


見積もりと計画

　プランニングポーカーでストーリーポイントを割り振って、期間内に何ポイント消化できるかを肌でつかむ
　2週間1イテレーションがちょうど良かったらしい
　ユーザストーリーでなく、機能別にやっている


タスク

  • いつでも誰でも見られるように、ホワイトボード＋付箋でやってる
  • Tracにも登録しているけど


進捗管理

  • バーンダウン
  • 正直に書く（FF13のような大型タイトルが出るとスケジュールに影響が出るのでそれを見越す、など）

XPにするのが困難なら、それにもアジャイルで対応する



入力項目の仕様をExcelで提出しなければならない
・プログラムでExcelを読み込んでバリデーション
・DB→Excel、Excel→DBができる環境を作っておく

個人のローカルで動いているプログラムも多数ある

大きなものは把握できるように小さく分ける
小さい単位で1つずつ相手する
知見を

とりあえず個人で導入してみる
そこからチーム→会社→社会に展開


結果だけを求めない



余談：iPhoneをプレゼンのリモコンにしているのが見ていて良い感じに思えた。

【19-E-4】クラウド開発に役立つ OSS あれこれ

オージス総研のオブジェクトの広場を見るといいよ

  • 企業のサービスをクラウドを使って再構築する場合、既存システムと連携がいる場合がある
  • テストには社内にも環境がないと、テスト実行にお金がかかる
  • デプロイを簡単にしたい。たくさんの環境に人の手でやるのは怖い

とりあえず繋げて
エレガントに繋げる


プレゼン資料のアップを待とう・・・・


【19-B-5】パネルディスカッション　出張！ DDD難民救済キャンプ 〜ドメイン駆動設計をあきらめない〜

なぜ今DDDか？
海外ではかなり流行っている（日本ではほとんどない）
ドメインモデル貧血症
ユーザのドメインに関連した問題を解決する能力
TheBook　ドメイン駆動設計
ドメイン＝知識・組織・活動の領域
複雑なドメインは、モデルに基づいて設計すべきだ（実装の手法でなく、建築物のようなもの）
知識の噛み砕き


ユビキタス言語
ユーザの言葉で作られたドメインモデルを作る

モデル駆動設計
設計から実装をトレース可能に作る
実装からモデルにフィードバックもある

深いモデル
ドメイン自体をインクルメンタルで作る
ある時点まで到達するとブレイクスルーが起こる


自分にとってのDDD

  • 佐藤

　ソフトウェア開発が目指すべき最終形
　テクノロジーが変わっても、活動は変わらない

  • 角田

　銀の弾丸などない
　DDDは開発の生産性を上げるものではない。むしろ長くなる。納期に間に合わなくなる
　全てに適用できるわけではない。開発の90%は適用しない

  • 渡邊

　複数のアプローチを持っておくことは、技術者としての嗜み
　90%の案件をRailsでさくっと作っていても、10%の時の方法を持っておくべき

  • 和智

　同じ言葉で同じものを見る
　新しい言葉を見つけると、見えていなかったものが見えてくる


明日から始めるDDD
・敷居が高い
　要アジャイル開発
　洋書
・入門者向け
　http://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html
　（パターンの紹介に偏っているので注意）
　http://www.infoq.com/jp/minibooks/domain-driven-design-quickly
　http://www.amazon.co.jp/exec/obidos/ASIN/4798116173/flare-22/ref=nosim
・実装者向け
　普段使っているDAOをリポジトリに名前を変えてみるｗ（概念から考える）
　DAOで一番良くないのは、結合表を返すもの
　DDDサンプルでググる
・設計者向け
　エクセルで設計書を書いて終わりでなく、実装の視点を持つ
　実装者と近くなる
　レビューで実装者と意識あわせをする
　プロジェクトの用語集をきちんとメンテし、設計書やモジュールに反映させる
　ユビキタス言語を中心に使う
・マネージャ向け
　戦略的設計（本の1/3を占める内容）
　チーム設計
　　アプリケーションエンジニアの復権。共通基盤だけでなくアプリ作りにも優秀な人を入れる


【19-D-6】Programming Amazon Web Services/EC2,SQS,S3,SimpleDB

Amazon Web Service Use Case

  • Backup / Archive
  • Media Sharing
  • Media Distribution
  • Academic Computing
  • Website Hosting
  • Programing Trading（金融）
  • Media Rendering
  • Search Engine Crawler
  • Social Network（mixiなど）
  • Online Gaming


S3=Simple Storage Service
物理ディスクを送って、import/exportをしてもらえる

EC2=Elastic Compute Cloud
OSはLinux, WindowsServer2003, 2008, OpenSolaris

シンガポールにセンターを作るらしい（2010のH1）