アークウェブWebマーケティングSandBox

• バックアップ一覧
• ソース を表示
• Ruby on Rails/Rails勉強会＠東京第15回 は削除されています。
  • 1 (2007-02-19 (月) 11:33:50)
  • 2 (2007-02-19 (月) 14:37:13)

Ruby on Rails/Rails勉強会＠東京第15回?

Rails 勉強会@東京第15回にはじめて参加してきました。

http://wiki.fdiary.net/rails/?RailsMeetingTokyo-0015

スタッフの皆様、また、参加された皆様、大変勉強になりました。ありがとうございます。m(_ _)m
以下は、その時の議事録。
青字は僕が思ったこと:)

目次 †

AMDD †

発表者: takaiさん

脳内妹 †

• 脳内の妹になんと呼ばれたいか。
• 考えたこともなかったが、よばれ方により、どう見られたいかなど、いろいろな考察があり。KPTでもKEEPに。^^;

参考文献 †

• Agile Database Techniques
• Refactoring Database

ゴール †

• アジャイルモデリング
• データベースリファクタリング
• DHHのセンスをあばく

BDUF †

• データ中心
• データは設計から変わる。変化対応しづらくなる。

アジャイルモデリング †

• 利害関係者の積極的な参加
• モデリング標準を利用しよう
• パターンは控え目にしよう
• 正しい成果物を利用しよう
• 共同所有
• テストしやすさを考えよう
• 平行していくつかのモデルをつくろう
• シンプルな中身をつくろう
• モデルをシンプルに作ろう
• つくったモデルをシェアしよう

• コントラクトモデル(外部インターフェース仕様)はきっちりさせよう
• 他の成果物にとりかかろう
  • 一個に固執していくのではなく、別のを作ろう、

• 詳細は終えなかったが一般的にいわれているアジャイルマインドと同じような感じ?

ポイント †

• 終えず.

アジャイルモデル駆動開発 †

• 「ちょうどなんとかまにあうくらいの」(just barely good enough)
• クリスタルの作者の「ちょっと間に合わないぐらいの」みたいな感じか。コードの場合ちょっと間に合わなかったら欠陥だけど:)

アジャイルモデル駆動開発のライフサイクル †

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

初期モデリング †

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

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

開発 †

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

ポイント †

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

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

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

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

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

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

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

適切さの確認 †

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

最適な手法を選択する †

• 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
  • カラムを追加
  • テーブルを追加

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

元のスキーマを非推奨 †

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

テスト †

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

スキーマの変更 †

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

元データの移行 †

• ????(終えず)

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

リファクタリング †

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

回帰テストの実施 †

バージョン管理 †

• ここでcommitするってことか

アナウンス †

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

本番環境へのデプロイ †

• 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、確認環境は欲しいなぁ。なので、この提案は同意。

デプロイの手順 †

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

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

結論 - RailsとAMDD †

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

DHHのセンス †

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

変化を抱擁せよ †

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

AMDDってどうよ? †

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

フィードとキャッシュ †

沢田さん

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

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本を持っていこう。

懇親会 †

• Java6は場合によってはCより早い。それほどバイトコードが最適化。
• 再起動せずに走ってくシステム...? よく聞こえなかった..
• プログラミング言語C(カーニハン&リッチー)を聖書のように..

投稿者志田 | パーマリンク?

|