199.html

+-----------------------+           +----------------------+
| Initial Requirements  |           | Initial Architectual |
|   Modeling            |   <--->   | Modeling             |
|  (days)               |           |         (days)       |
+-----------------------+           +----------------------+
                             |
                             ↓
                +----------------------+
                |  ・Model stoming     |
                |        (minutes)     | <---+
                |                      |     | itrative
                |  ・Test driven       | <---+
                |        (hours)       |
                +----------------------+

↑

[edit]

初期モデリング †

初期要求モデリング
- 利用モデル
  - ユースケース
  - ストーリーカード
- 初期ドメインモデル
  - ひつようになるまでいらない。
- 初期ユーザーインターフェースモデル
  - 紙、ホワイトボード

初期アーキテクチャモデリング
- フリーフォームの図
- Change Cases(おまけ)
  - システムがこんな風にかわったらどんなに影響があるか、をまとめておくもの
  - 例) 会員コードが変わったらシステムへの影響度
  - Changes Casesを意識しすぎると、YAGNIなものも付け加えがちな気がするけど、のちのちのデータベースリファクタりんを見据えて、あらかじめ影響を知っとく、ということかな。

↑

[edit]

開発 †

モデルストーミング
- 5～10分
  スタンドアップミーティングみたいなものか。
看板方式
- 必要なものだけ
紙とかホワイトボードに
実装、数時間、テストドリブン

↑

[edit]

ポイント †

無駄なものをは省く。
- リーン生産方式の流れか。
モデルは必要なものを、必要なときに、必要な形式でつくる。
初期のドメインモデルに詳細はいらない。テーブルの中にidしかない、みたいな。

↑

[edit]

データベースリファクタリング †

データベースリファクタリング
アジャイルモデリング
回帰テスト
データベース成果物(設定ファイルとか、インストール手順とか)の設定管理
デベロッパーsandbox

データベースリファクタリングとは振る舞いや情報の意味を保ちながらデザインを改善するデータベーススキーマに対する単純な変更のこと。

概念モデル <--> 論理モデル <--> 物理モデル

↑

[edit]

アジャイルデータベースリファクタリングの手順 †

データベースリファクタリングを今やるのが時期的に適切かを見極める
最適なデータベースリファクタリングを選ぶ
元のデータベーススキーマを非推奨にする
テストを変更前、変更中、変更後に行う
データベーススキーマを変更する
元データの移行
リファクタリング
回帰テストの実施
バージョン管理
アナウンス
本番環境へのデプロイ

↑

[edit]

適切さの確認 †

リファクタリングに意味があるのか?
今必要か?
変更するだけの効果があるか?

↑

[edit]

最適な手法を選択する †

Structural Refactorings
- Drop Column
- marge table
- split table
- ...
Data Quality Refactorings
- データベースの情報の質を高めるもの
- add lookup(マスタ) table
- standard code
- standard type
Referential Integrity Refactorings
- 参照整合制約を導入する、削る
Architectural Refactorings
- Read Only テーブルを導入する
Method Refactorings
- ストアドをちょっとかえてみるとか
Transformations
- カラムを追加
- テーブルを追加

ここが肝か。詳細は本で。本かお。

↑

[edit]

元のスキーマを非推奨 †

移行期間を設けて、両方とも動くようにするのが重要
- 大きいチームなら必要だが、小さなチームだとイランのでは?
トリガーとかで、かたっぽにつっこんだら、もう一方にも突っ込む、などの工夫が必要
- トリガーの例も本にのってます。
移行期間を過ぎたら消しちゃうよ
逆に、移行期間内なら、ダウングレードできる、という保険のため?

↑

[edit]

テスト †

ユニットテスト
データ移行のテスト

↑

[edit]

スキーマの変更 †

簡潔さ
正確さ
バージョニング
- railsのマイグレーション
railsのマイグレーションは番号だけだが、日付とかもあった方がいいかも。な話。
- たしかに、今のプロジェクト(3チーム)でやってて、マイグレーションの番号がバッティングしちゃうのは何度か経験あり。でも、今はマイグレーションcommitするまえにupdateして、その後commitって運用ルールで問題は特になくなると思ってるんだけど、どうなんだろ。リリース担当としては、日付とかだと、どのバージョンでリリースするか、って部分で、ややこしさがあり。

↑

[edit]

元データの移行 †

????(終えず)

※ lookupテーブルは都道府県のマスタとか。

↑

[edit]

リファクタリング †

3さつ
- マーチンファイラーの本。
- working efectively with legacy code
  - テストコードを書いてないコードはみんなレガシーコードだ。
  - テストコードがないコードをどうやってリファクタリングするか、って話かな? だったら是非知りたい。
- refactoring to pa(よく見えず...)

↑

[edit]

回帰テストの実施 †

↑

[edit]

バージョン管理 †

ここでcommitするってことか

↑

[edit]

アナウンス †

変更をチームでシェア
- コミットログだけではよくないのでは?
- 意図が伝わらない?
- コミットログだけでなく、アナウンスしたほうがよいと思う。

↑

[edit]

本番環境へのデプロイ †

logical sandboxes to provide developers with safety
1. development sandbox
  デベロッパ単位でDBを持っていおり、がんがん開発する
  テストドリブンで開発していく場所。
2. プロジェクト統合sandbox
  チーム一つ一つごとの環境をもつ。
  development sandboxとは点線程度の垣根っぷり。
3. DEMO環境 or preproduction Test/QA Sandbox
  顧客による受け入れテスト実施
4. 本番

今のプロジェクトだと、プロジェクト統合sandbox=DEMO環境。だけど、リリース前の本番サーバー上での別ディレクトリとかでの、最終DEMO、確認環境は欲しいなぁ。なので、この提案は同意。

↑

[edit]

デプロイの手順 †

移行スクリプトで、以下を自動で?
- データベースのバックアップ
- 前回の回帰テストの実行
- 変更したアプリのデプロイ
- 今回の回帰テストの実行
- 必要ならば元にもどす

rails本には、元に戻すってあたりのやり方も提案があったよな。シンボリックリンク使う方法。P463。
SVNでreleaseってディレクトリを作って、そこにsvn copyで環境を用意しとくとか。今のリリースの仕方は、その通りやってなかったな。反省　 [sad]

↑

[edit]

結論 - RailsとAMDD †

テストドリブン
マイグレーション
ActiveRecordの割り切りの話。
railsは楽にいけるだろう。AMDDをやれ。

↑

[edit]

DHHのセンス †

マイグレーションとか、ActiveRecordの割り切りとか見ると、RailsってもともとAMDDのあんちょこだったんじゃないの?
AMDDやデータベースリファクタリングのエッセンスは、すでにフレームワークにはいってるんじゃ。

↑

[edit]

変化を抱擁せよ †

変化は自分で勇気をもってさせるもの
変化させないといいものはできないよ
(根本的なものを変化させちゃいけないけど?)

↑

[edit]

AMDDってどうよ? †

必要でないものは無駄なもの
必要ないなら、AMDDという考え方だっていらない。

↑

[edit]

フィードとキャッシュ †

沢田さん

FeedToolsの話。 http://rubyforge.org/projects/feedtools/

↑

[edit]

cacheの話。 †

瀧内さん、yamazさん

+--------+
| client |
+--------+
   ↓
+-------+
| proxy |--------+----------+
+-------+        |          |
   ↓　          ↓         ↓
+--------+  +--------+ +--------+
| apache |  | apache | | apache |
+--------+  +--------+ +--------+

railsのcacheはサーバーが複数台構成の時はレールが敷かれてない。
Railsのmemcachedはみんな好んで使っている。
RubyはPHPの6倍遅い
Cacheを使わないとお話にならないほど遅い。
mephistoはDBへのキャッシュを独自に実装。
mongrel clusterは試す価値あり。
Sweeperはobserverじゃない
LVS(Linux Virtual Server)。LinuxがLevel4のロードバランサのように振舞ってくれるもの、らしい。
MySQLはPostgreSQLよりレプリケーションが優れている
WriteやUPDATEの負荷分散のよい解は見つかっていない。
Rails本によれば、NFSを使って、キャッシュ用のディレクトリを共有して、ファイルキャッシュを使うのがよい、とのこと。P468
- 広帯域の内部ネットワークがないと、NFSがボトルネックになるらしい。でも、上記のproxyがボトルネックになるのと同じと思うが... わからず、わからず。
- 次回からはRails本を持っていこう。

↑ こんにちは.proxyサーバは並べることが出来るので,ボトルネックにはならないです.
実際はproxyサーバのさらに手前にロードバランサを置くことになると思います.
またDSR方式を使えばロードバランサがネックになることも通常ならないかと思います(yamaz).

Ref. http://d.hatena.ne.jp/yamaz/20060817
↓下記のようなイメージです.

+--------+
| client |
+--------+
   ↓
+--------------+
|Load balancer |--+----------+
+--------------+  |          |
     |            |          |
+--------+  +--------+  +--------+
|  proxy |  |  proxy |  | proxy  |
+--------+  +--------+  +--------+
    |             |          |
----+-------------+----------+
   ↓            ↓         ↓
+--------+  +--------+  +--------+
| apache |  | apache |  | apache |
+--------+  +--------+  +--------+

↑

[edit]