実践的オブジェクト指向分析・設計と実装 (続き)

セミナー

今日は、昨日学んだことをベースに新しい演習に取り組みました。演習のお題は電話の通話管理システムです。

簡単なユースケースを出発点にして、

  • 1. オブジェクトレベルで関連/多重度を考え、
  • 2. ユースケース実現の詳細度を高めていきます


オブジェクトをしっかり意識せずにクラス図を描いていくと、いざ実装に移るときにうまくいきません。今回は見事に (先生の用意していた) 落とし穴にはまってしまいました。 (^^;


下のようなクラス図 (その1) を書くと、オブジェクトレベルではその下のオブジェクト図 (その1) のような構成が考えられます。C クラスの個々のオブジェクト (c1 .. c4 ) に A、B のオブジェクト (a、b) 両方からの参照をもつわけです。ただし、今回考えていたユースケースでは、b から C のオブジェクトを新たに追加するというものがありました。



ここで、実際に追加する実装のイメージを膨らませていくと、追加自体は C を new して b でもっている配列なりリストなりに追加すればよさそうだなと思うわけですが、困るのは a からの参照をどうもたせるかです。B から A には関連をもたせていないので、どうにも手がありません。クラス図 (その1) は、何となく雰囲気は出ているものの、実際にはコードに落ちない代物だったわけです。


ちなみに、クラス図 (その1) において、左側の多重度を 1 ではなく 0..1 で考えた場合、オブジェクト図 (その2) のような状況も考えられます。a、b いずれかからのみ参照をもつようなデータ構造ですね。このように、クラス図のだけでは情報はけっこう少なく、オブジェクトレベルで考えるといろいろなパターンを含む可能性があります。オブジェクト図 (その2) のように、a と b 両方からの参照をもつ c が存在しなくてよいのであれば、b から C のオブジェクトの追加をするのもとくに問題なくできるはずです。(要は、ユースケースによってはクラス図 (その1) でもいいわけです。)



というわけで、「b から C のオブジェクトを新たに追加する」というユースケースを実現するために、以下のようにしました。



オブジェクトレベルで考えると、オブジェクト図 (その3) のようになり、c' 経由で (c' のもつ配列ないしリストに) C のオブジェクトを追加することになります。これなら、a からも新たに追加されたオブジェクトが参照可能になります。
クラス図としてはクラス図 (その2) になるわけですが、オブジェクトレベルで考えていないとやはり辿り着きにくいと思います。



落とし穴、2つ目。
クラス図の関連や多重度をちゃんと描けるかです。



上のオブジェクト図 (その4) では、d が e の配列ないしリストをもつとともに、それとは別に e への参照を 1つもっています。いくつかの候補のなかから 1つを選択し、それに対して以後の処理を実行するようなユースケースです。処理のたびに候補から選択をするのはコストが高いので、選択されたものへの参照を別に保持しておくわけです。
クラス図だけを考えてると、D から E への関連を引っ張って終わりにしてしまいそうですが、オブジェクトレベルで考えると、オブジェクト図 (その4) となり、クラス図としてはクラス図 (その3) となります。多重度もちゃんと描きます。



クラス図ってどうも実装との間にギャップがあるように感じていましたが、オブジェクトレベルを意識して、ユースケースがそれで実現できるかという視点でしっかり考えていくと、ちゃんとコードに落ちるものなることが実際に体験できたと思います。


全体を俯瞰しながら大枠の設計を検討する際に、あまりに細部にはいってしまうのはまずいと思いますが、クラスの構成やそれらの関連あたりは細部とは言えないでしょう。そこをよい設計にするのには、やはり可視化されたほうが頭にも入りやすいですし、コミュニケーションにも都合がよいと思います。

今回の講義は、実装とのギャップを小さくした分析/設計の重要性とその有用性を体感できるものでした。



余談ですが、JUDE でオブジェクト図がかけました。
演習のときには、メモ用紙にぱぱっとオブジェクトを描き殴りながら考えていましたが、こんな風に清書する必要があるときにはよいです。オブジェクト図を描けるツールは少ないみたいなので... (リンクは矢印だとなおいい)

Ｑ.「JUDEでオブジェクト図を描けますか？」というご質問。

答えは、「はい」です。JUDE/Community、Professional共に、オブジェクト図の描画が可能です。
クラス図を開いて、「クラス図」でサポートしているオブジェクト、リンク等の図要素を使用して描画してください。

実践的オブジェクト指向分析・設計と実装

セミナー

ラーニング・ツリー・インターナショナルの講座を受けています。
カンサス州立大学のコンピュータサイエンス学科の教授、水野 匡章先生が講師をされている講座です。
別件ではありますが、先生の講演資料として下記のものが Web で参照できます。米国での仕事経験に基づいたものですが、こちらも興味深い内容でした。

  • ヒューマンキャピタル 2008

ITアーキテクトの重要性とその育成方法 〜アメリカの成功事例から学ぶ〜

先生のお話のなかでもよく登場するのが、「Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている」の記事。あまりに納得のいく内容なので全文引用したいくらいですが、少しだけ... (それでも多いですが)。
先生も同じ想いを持っていて、強くアーキテクトの必要性を説いています。上の資料もその流れですね。

自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。

実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。

世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。


(中略)


「自分でプログラムを書かない上流のエンジニアが詳細設計書を作り、下流のエンジニアがコーディングをする」という工程そのものが、根本的に間違っているとしか思えないのだ。

シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。

さて、講座のタイトルは、実践的オブジェクト指向分析・設計と実装というものですが、一連のプロセスを座学的に学ぶのではなく、かなり実装イメージが膨らむところまで分析/設計し、そして実装まで落とすのが特徴的だと思います。(この手の講座を受けたことはないので、これまでに読んできた書籍からの印象ですが。)


で、そのために講義開始の 1時間後くらいには、メモリ上のスタック、ヒープ領域の話になり、スタックフレームやオブジェクトの参照状況などの「基本」をたたきこまれます。ひさしぶりに Visual Studio の画面を見ましたが、ヒープメモリの中身や、スタックフレームが詰まれている状態がデバッグトレースでかなり見やすく可視化されるのはすごいですね。それにしても、この講座のタイトルでヒープやスタックの話が最初に登場するとは思わなかったです..。


クラス図での関連も、オブジェクトレベルでの参照を強く意識しながら描くように教えられるので、クラス図上での何気ない一本の線が実装上かなり大きな意味をもつことが理解しやすいです。間違った線 (関連) のせいで実装が複雑になり、メンテナンス性にも乏しく、パフォーマンスもよくないものになるのはままあることだと思います。

間違った線はよく設計されていないため (場合によってはいきなり実装から入ってしまったがため) に起きることが多く、UML レベルでは線一本の付け替えで済むものが、実装に入ってしまっているとなかなか付け替えに等価な変更はできません。だからこそ、オブジェクトレベルまで意識しつつ、しっかり分析/設計をし、多重度を含めたクラス間の関連を最初にしっかり決めるのが大事という話です。多重度を意識しないと、オブジェクト同士が m 対 n で関連をもつなんていう悲惨な事態が生まれやすいんでしょうね。


演習が多いのも特徴で、初日は自動販売機を分析/設計し、実装に落としました。バウンダリー (コイン投入口や選択ボタン、購入可能ランプや売り切れランプ、釣り銭切れランプなど) まで含めると 10 以上のクラスが登場してくるのでさすがにいきなりの実装は大変です。ちょっとずつ実装しながらってのもありでしょうが、やはり問題にぶちあたったときの設計の変更コストは大きく、下手をするとデバッグ地獄にはまってきそうな気配もあります。


演習を通じ、オブジェクトレベルを意識してクラス図を描き、クラス間 (オブジェクト間) の関連と、ファンクション名だけしっかり設計すると、たしかに手戻り少なく実装に落とし込めるように感じました。ファンクションの中身の詳細までは分析/設計の対象ではなく、あくまでオブジェクト間がどんなシーケンスでつながっていくかを把握するのに注力します。そして、それができたあとでファンクションの中身を含めて、機械的に実装に落とし込んでいきます。
もちろん、実装に落とし込みながら、再度設計を見直すことはあるでしょうし、一緒に開発するメンバーの経験や知識の度合いによっても、どこまで詳細に分析/設計するかは変わるでしょう。バランスは都度調整する必要がありますが、設計をあらわす共有ドキュメントが必要なのであれば (プロダクトレベルで不要なことはないと思いますが)、それを無駄にせず、手戻りを少なくできる武器にするのがいいというのは納得です。やはり関連構造の見直しはコードだけからだと大変ですし、可視化されていると見直しがしやすい上に、全体構造を踏まえてよい設計になっているのが "分かる" という安心感もあると思いました。



端的な表現にしてしまうと以下に尽きるのすが、手を動かす & 失敗経験がともなわないといまいちピンとこないですね。

  • 1. オブジェクトレベルで考える
  • 2. ユースケース実現の詳細度をあげる


うーん、なかなか言葉だけで表現するのは難しい..。だから数多あるこの手の書籍も苦しんでいるのでしょうか?
個人的にはかなりヒットな内容なので、そのよさをうまく伝えられるようがんばってはみたのですが... (講座の一部でいいんで youtube とかに流してほしいですね.. 広告費ゼロの宣伝なんだけどなぁ)


まだまだメモしたことはいろいろあるのですが、ひとまず明日もあるのでこのあたりで。 (^^;

RubyKaigi2009 三日目メモ

rubykaigi2009

いよいよ最終日。スタッフのみなさま、本当におつかれさまでした。
そして、今年もありがとうございました。 <(_ _)>


ソケットライブラリの改善

  • TCPServer、UDPServer はプロトコル依存
  • 気にいらなかったこと
    • 分かりにくい引数 (SOCKET、SOCKET、SOCKET..)
    • 戻り値がバイナリ
    • port,host の順番
  • プロトコル非依存な UDP は難しい
    • サーバは待てばいいがクライアントは 3 way hand shake もないので判定できない
    • マルチホーム環境で届いたアドレスから返したい
  • 今の Socket ライブラリは大クラス主義が認識されてない頃の設計かも
    • だから今回は TCPServer ではなく、Socket に集めた
    • でも使う側的には分かりにくくね？っていう質問もあった
  • デザインデシジョン
    • inspect 可能 = 意味がオブジェクト内で決まるということ
    • 何をオブジェクトすべきかにもつながってくる

スクリプト言語 Ruby

  • バッチファイルに Ruby を埋め込む
    • -x オプション
    • バッチと Ruby の共存が可能になる
  • Unix Tools
  • fork はよろしくないので spawn を使ってください

RubyGems の落とし穴

  • Web に転がっている事例として reliable-msg が登場した
    • そして自分のブログ (^^;
    • そして irc には MDD..
  • 処方箋
    • 複数バージョンの gem は混ぜない
    • GEM_HOME で完全に分けるとか？
  • .gemrc に追加するといいかかも
    • --format-executable

Ruby製アプリを配布する n 個の方法

  • 最近は Ruby の仕様を書いているとのこと
    • わからなかったら隣のひと (まつもとさん) に聞くらしいw
  • デスクトップアプリの配布
    • Ruby インタプリタ必要
    • native コードに変換してくれる実用的なライブラリはまだない
    • どこ向けに、どこでパッケージ作成するかも問題
  • RubyScript2Exe (03-07)
    • 開発はとまっている
    • 動くことは動くらしい # Ruby1.8.6 以降で動かないらしい
    • Ruby のインタプリタごとひとまとめにするので、起動が遅い
  • Exerb (02-09)
    • クロスコンパイルできる
    • require を書きかえてる
  • Ocra (09-)
  • Crate (08-)
  • sqlite3 に Ruby のファイルをつっこんで、実行ファイル 1つ
  • Zip
    • Win 用の Ruby を解凍して自分のファイルをつっこんで起動スクリプト書いて、再び固める
    • 最強w
  • Rails でデスクトップアプリ
    • Ramaze や Sinatra でもできる
    • zip it
    • HTML と JavaScript でけっこう柔軟にかける
    • が、port が覚えられなくなる
  • RubyStation
    • Gem の機構をそのまま使っている
    • インタプリタの問題は RubyStation が動いてるならインタプリタあるはずってことで逃げ
    • もう少し開発が進めば、RubyStation のインストールをうまくやりたいとのこと
    • github
  • port の管理は？
    • RubyStation が適当にランダムにあててる
  • アクセス制御
    • 127.0.0.1 以外から蹴る？
    • でも家庭内 LAN で使いたいよね
    • RubyStation で設定可能なインターフェースを提供するのが正解かな

tDiary の Ruby 1.9 対応の過程と今後のロードマップ

  • 1.9 対応
  • compatible.rb
    • for 1.9: String.each_line、String.to_a
    • for 1.8: String.force_encoding、String.byte_size
    • 意外とほかのアプリでも require するだけで 1.9 対応できるかも
  • 1行目に任意の文字列を挿入するワンライナー、すぐに思いつく？
    • sed を使うんだwww
  • File.open(FILE__NAME, 'r:UTF-8')
    • これだと 1.8 で動かないので却下
    • Encoding::default_external='UTF-8' で対応
    • でも、Ruby バージョン で分岐させるのはよくない by yugui
    • begin resucue end で対応
  • 細かいこと
    • cgi:cookies が ASCII-8BIT と認識されるので、encoding を個別に指定する
    • ブロックをつけない map は Enumerator を返すようになったので、to_a する
    • get の第二引数が nil を許容しなくなった
  • その他
    • cache フォルダに cache じゃないデータがある
    • 消すと不幸なことにw

Haml と Sass

  • RHTML、CSS から Haml、Sass へ
    • Haml を使うとコードが 50 %減
    • Haml は行思考なので閉じない、複数行に渡るものはインデントで表現
    • 属性はハッシュで書く
 %div{ :class => "block"}
 %div.block
 .block
  • ふつうに Ruby が評価される
    • eruby でありがちなタグのなかにタグが入るようなことがない
  • ちなみに end をつけると Syntax エラーw
    • メソッドチェーンするときに限って end をつけられる
  • !!! だけで DocType 指定ができる
  • python + yaml ？
  • Sass
    • ロゴが変なのは作者のセンス
    • CSS はすべてのルールがフラット
    • Sass だとインデントで構造化できる
  • ! ではじまるのが変数
    • color = !base_color-#666 みたく、演算もできる
  • 「=」がマクロで「+」で展開される 
 get install haml
 haml --rails path/to/rails_app
  • デザイナとの協業は？
    • 困難
  • html2haml コマンドがある
    • css2sass もある (変換精度はあまり期待しないほうがいい)
    • ページ単位での段階的な移行も可能
  • :ugly オプション
    • 指定するとパフォーマンスはよくなるが、インデントがつかなくなる
    • パフォーマンスの劣化は 20% くらい。

Erubis 徹底解説

  • Erubis は高機能かつ拡張性が高い
  • 設計が美しい
    • Enhancer 機能追加のためのモジュール
    • include / extend するだけ
    • コマンドラインからも指定できる
  • eRuby の (に関連した) 問題点とその解決策
    • binding を使うとローカル変数がローカルでなくなってしまう
    • ERB の解決策: Struct を使う方法@Seki3のブログ
    • Erubis の解決策: Binding のかわりに Hash を使う
  • 余分な改行
    • 式と文で挙動を変えるだけで対応
    • 同じに見えるけど、実はちがうものと認識することが重要
  • テンプレートシステムの将来
    • テンプレートは一種のメソッド、コンテキストデータは引数とみなせる
    • テンプレートにも仮引数宣言が可能になったらいいな..
    • Django のテンプレートには継承がある
  • eruby の仕様的には parse (構文解析) まではしていない
    • ゆえにブロックの認識が難しい (ほかの if の end とかと被る)
    • だから merb では、記号をつけて拡張している
  • ERB も Erubis も時代遅れ
    • しょせんテキストプロセッサなので、テンプレートエンジンとしての機能が貧弱
    • そこで、高速高機能なテンプレートエンジン、Tenjin
    • いいらしい？

RubyKaigi2009 戦利品

rubykaigi2009

ジュンク堂書店出張所で買ったもの。いずれも著者、監訳者のサイン付き。
われながらミーハーだ... (^^;


まつもとゆきひろ コードの世界?スーパー・プログラマになる14の思考法

まつもとゆきひろ コードの世界?スーパー・プログラマになる14の思考法


ふつうのコンパイラをつくろう

ふつうのコンパイラをつくろう


エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術



こっちはすでにだいぶ前に読み終わっていたので、yhara 先生のサインはもらいそこねました。
でもとっても面白い本でしたー。


Rubyで作る奇妙なプログラミング言語 ~Esoteric Language~

Rubyで作る奇妙なプログラミング言語 ~Esoteric Language~

RubyKaigi2009 二日目メモ

rubykaigi2009

初日の晩にはしごして少し飲み過ぎましたが、今日もしっかり朝から会議。
今年は 3日間のゆったり構成ですが、毎日少しずつ開始時間が早くなっていくという罠。


以下、昨日と同じく自分用メモ。
# スポンサーセッションではなく裏番組のほうが笑いが多かったみたい.. orz

1/60 秒で Ruby (Ruby でゲームを作ったら)

  • ゲーム作りに使ったライブラリ
  • 1.9 には GC::Profiler あり
    • オブジェクト数に比例して GC による停止時間も増加
    • 10万オブジェクトに対して 10msec くらい
    • インクリメンタル GC、誰かつくって
  • 配布方法
    • Windows には .exe にするのに Exerb
    • Mac には、適当に app にまとめる

Ruby における生産性を高める開発環境を考察する by ujihisa

静的コード解析統合環境の試作

  • 日立で、PaaS、RoR 開発、学習環境サービスの提供を検討中
    • ORM、Reek、Roodi、Flog、Saikuro、Flay を利用した静的コード解析サービス付き
  • チェック内容
    • ORM: コーディングルールに従っているかを評価
    • Reek: Code Smell の検知
    • Roodi: デザインに関する問題を警告
    • Flog: 代入、分岐、呼出を分析することでコードの複雑度評価
    • Saikuro: McCable
    • Flay: 構造的類似性の評価、コピペ探し
  • 類似ツール
    • Metric_fu
    • 同じく上記 OSS ツールを使用してレポート出力(html)
    • CSS を似せているが、基本的には各結果をそのまま載せているだけ
  • 日立のと何がちがうかと言うと、結果を一度集めて分析しているかどうかくらい
  • Q&A
    • Q: Rubyならではの苦労、知見など
    • A: ちょっといい例が浮かばない。Rubyならではのチェックルールが現状限られている感じなので増やしたいというのはある
    • Q: 日立ソフトさんが作られて、実際に使われてるのでしょうか
    • A: 一部のプロジェクトでは使われていて、評価しているという状況
    • Q: 感触は
    • A: 個人の意見だが: JavaにしろRubyにしろ、プロジェクトによってはこういうツールは有用だし、逆に有用性が低くなる場合もある。大規模プロジェクトに対しては有効性が高いのでは。
    • Q: C++だとメモリ周りが嬉しいんだけど、RubyだとDSL関係をチェックしてくれると嬉しい気がするんだけど
    • A: 検討します？

Keynote

  • Ruby 羅針盤
    • われわれはどこにいてどこに向かっているのか？
    • 現代は The Programming Golden Age
    • 正しい技術を選んで、正しく評価できる時代のさきがけ
  • Twitter@yukihiro_matz
    • はじめたらしい
  • 酸っぱいブドウ
    • 自己正当化、真実から目を背ける
  • 割れ窓 Broken Window
    • バグを放置しておくとスラム化
    • OSS は生きていることが魅力、枯れた / 変化しないソフトウェアは面白くない？
  • 責任
    • 責任を与えて信頼、より多くの成功
    • 下にあわせるよりも、上の生産性の最大化
    • 「Ruby は正論の通じる言語」 by yugui
    • 「バグ連発するとコミット権とりあげるよ」と言われたらしいw
  • StGit (Stacked Git)
  • 未公開スタック (パッチ) が 27 個ある
    • 互換性の問題がある、かつ必要なのか分からないのでフィードバックがほしいそうな
    • 1/2 -> 有理数 1/2
    • 今までの割り算との互換性に問題
    • 明示的な変換 (to_a) と 暗黙的な変換 (to_ary)
    • as と to のどっちがどっちだがわからなくなる罠
    • Math 関数が NaN ではなく、例外を返す
    • ほかの言語では例外が多い
    • 省略
    • 以下みたいに n 重ループが書ける
 nloop(3,3,3) {|i,j,k|
   p [i,j,k]
 }

a = "foo"
a[3] = x # "foox"  1.9 だと
    • シンボルを回収する GC
    • 100万個シンボルをつくると遅くなる..
    • GC 自体も遅くなるという欠点
    • スーパークラスと共有しないインスタンス変数
    • @_foo で private
    • けっこうこの書き方を使っている既存プログラムがある
    • := で代入した変数はブロックローカル
    • ブロックパラメータでの宣言が不要になるが、美的感覚的には微妙
    • module + module で新しいモジュールを生成
    • その時点の機能をコピーなので、あとからオープンクラスで機能を追加しても反映されない
    • メソッド再定義でオーバーライド
    • 古いものを super で呼べちゃう
    • アスペクト指向のベースとなる
    • メソッド定義でキーワード引数
    • ブロックのあとで変数を使うと勝手にスコープを拡張してくれる
    • キモいと言われたw

Lightning Talks

Decimal
  • 標準添付の BigDecimal をつくりかえた
  • Bignum の再利用することでシンプルかつ、パフォーマンスも数倍に
Morumotto
  • Visual Authentication
  • 主要OS、主要キャリアに対応
Enphase Energy
ギャルゲー
  • Romantic Ruby で略して RoR
arduino.rb
  • 手元でボタンを押してスライドのページ送り
rubyrep
初心者のためのグラフィックライブラリ
  • Ruby/SDL はちょーめんどいので、BASIC みたいに簡単に
  • Ruby/SDL をラップ、OpenGL もラップ
  • 近日公開予定
Ruby でネットワーク運用
  • 監視だけなら汎用ツールでよいが、外部の死活監視と連携するなら作り込み
    • 最初に想定しきれない、変化する、受け入れる、ならば Ruby
  • 数千、数万台
    • 処理プロセスのマルチスレッド化
  • テストの自動化重要
    • rspec 日本語ラブ
Ruby によるお手軽 CDN
daemon-kit
ActiveLDAP
  • 今日 1.1 0 リリース
  • LDAP の木構造のデータを Ruby で扱えるようにするもの
  • 直感的な API # AR ライク

スポンサーセッション

The Samurai Ruby
  • 省略..
携帯ポータル
  • 最近の @nifty には 40強の携帯サイト
    • 仕様変更あたりまえ
    • 機種依存あたりまえ
    • ターゲット層と使われ方
    • スピード勝負
  • 垂直統合型
    • サイト単位に機能を追加
  • 水平統合型
    • 機能単位でリソースを用意し、その API をたたく
  • これまでは垂直統合型
    • 言語自体もちがう、ミドルウェアもちがう
    • 運用も大変
  • これから水平分業で柔軟なシステムを目指す
    • 基本 RoR、jmobile
    • firemobilesimulator
    • redmine
    • コーディング規約 (shugo3)
実践投入 Rails
  • 大人の事情で書けなかったこと (プロジェクトの規模感とか) を紹介
    • とある業界の最大手、世界中でかなり知られている
    • そこの人事管理システム (10万人以上)
    • 既存運用中のシステムがある... が、大炎上、そして億単位の赤字
    • 既存システムは untutchable、カラムひとつ追加で1人月!？
  • 既存システムと Rails の共存
    • これまでと基盤が違うし実績の面で最初は相当渋られた -> がんばって説得
    • 既存システムの DB を利用するので、Rail に乗れない
      • 1. sarogate_key ではなく、natural_key
      • 2. composit primary key
      • 3. 既存システムとRails 部分で別ログインになるのは嫌だったのでセッション機構を自作
  • 作ることが目的ではなく、日々使い続けてもらうことが目的
    • 健全に運用できることに Rails の価値あり
Media Technology Lab
  • RoR ベースで 8つの携帯サイト
    • 全体で月間 6000万弱 PV
    • データ転送量 4TB
  • 構成
    • Rails のバージョンいろいろ
    • httpd もいろいろだが、今はPassenger に寄せているところ
    • サーバ運用が楽だし、パフォーマンス (mongrel より 2割くらい速い)
    • Ruby Enterprise Edition も使ってる
  • Xen の上で Rails
    • php は CPU を食う、ruby はメモリを食う
    • 複数 AP サーバでうまく共存できた
  • H/W Spec
    • 16GB
    • 2x Quad Core Xeon
  • VM Spec
    • 1GB メモリ
    • 10GB Disk
    • 8cpuコア available
    • これで 13 VM くらい動く (ぎりぎり)
  • 1つの VM あたりの mongrel process
    • 10 process /1GB mem VM
    • 24 process / 2GB mem VM
  • TIPS
    • my.conf で遅い SQL をロギング
    • Log rotation、copytruncate が重要
    • Xen で使ってるときは mongrel が swap しないように気をつけるべし
    • Monit
C と Ruby とその間
  • Ruby と C
    • 直感的、柔軟 <=> 高速な動作
    • 似てない、だから補完して仲良く
  • groonga API
    • 高速な全文検索エンジン、C で実装
    • ActiveGroonga # AR 風の API
    • Ruby / groonga # Ruby からのアクセス
  • milter manager (迷惑メール対応)
    • 直感的な設定方法、柔軟な動作変更、そして高速であってほしい
    • Ruby インタプリタ埋め込み
オープンソース開発
  • SKIP Wiki
    • 近日 1.0 公開
    • 三菱UFJインフォメーションテクノロジ SonicGarden (TIS 社内ベンチャー) と永和の3社で開発
  • オンライン 4日、オフライン 1日で開発
楽天 (ROMA)
  • 都合によりデモできなくなりました.. orz
  • Rails と CakePHP でベンチ
    • 200 req/sec あたりから応答スピードがさがる
    • CPU 使用率は ruby のほうが低い (ファイルI/O が少ないのが system が低い)
  • 起動プロセス数の最適値
    • キャッシュ等のために 500 MB 程度が空き容量になるようにチューニング
  • DB の応答性能
    • テーブル分割 => model に手を入れて吸収
    • KVS でキャッシュ (ROMA、memcached)
  • Apache + passenger graceful 問題
    • apache のログローテートのため graceful 処理を行うと apache が起動しない
    • ファイルのリネームで passenger の spawn も同じファイルをみていたのでデッドロック
    • ログローテートに rotatelogs を利用して解決

RubyKaigi2009 初日メモ

rubykaigi2009

思い返せば DHH が招待講演していた 2006 年の Ruby会議から今年で 4回目。何気に自分が全部参加していたことにびっくりしました。 (^^;


今年のテーマは「変える/変わる」。そして裏テーマは「COBOL」?。

一際国際色豊かなのも今年の特徴ですね。世界地図に出身を付箋紙で貼ってくのは面白いアイデアでした。


受付済ませて給電所でぼーっとしてたら角谷さんに会って、会場前の通路を RubyConf 風にしてみたと言ってました。たしかに連絡ボードとかドリンクサービス、給電所なんかがあるのは似てたかも。


全体的な内容や雰囲気についてはすでに gihyo.jp さんとかで公開されてる (GJ!) ので、以下は自分用のメモ。

git

  • 発表者の Scott Chacon さんが本を書いたらしい
  • git rebase --onto
    • branchのbranchをmasterに当てたいが、途中のserverブランチの部分がいらない
    • git rebase serverだけやると、だめ
    • --ontoを使うと、serverからみたclientブランチのコミットをとって、masterに当てる
  • squash
    • squashすれば、複数コミットが一つになる
    • pickして、squashしたら、新しいコミットメッセージを付ける
    • 注意：ローカルのコミットでやれ。pushしたものに対してやるな
  • Fork QUeue
    • 他のforkでのコミットをかんたんにみえる
    • 緑は問題なしとりこめるもの、赤の場合は衝突がある
  • rebase と merge の使い分け
    • ローカルだけで管理のとき or 外から取り込むときくらいで使い分け

現場で役立つ RoR パターン

  • 設計 / 実装の一体化で自分も実装できる、という意味でエンタープライズでも RoR を活用
    • マネージメントやオフショアなど、実装できない流れは嫌
  • 課題
    • 書き方がばらばら
    • 品質が揃っていないので、メンテナンスしにくくなる
  • コードをよい状態に保つには？
    • 共通パターン
    • DSL (控え目に利用、やりすぎは新規参入者の障壁)
  • 権限のあるデータの表示
    • find_by_user_id や named scope でがんばるのは条件を書き忘れても気づきにくい
    • 関連を使って、オブジェクトからはじめる検索がいい
 @note = current_user.notes.find(params[:id]
    • データの権利者パターン
  • Filter の利用
    • 重複している処理を Filter に切り出す
    • ある程度強制力が働く..のかな？
  • 複雑なビジネスロジックのモデルへの集め方
    • Model のなかに do_create、do_destroy メソッドを切ったひとがいる (びっくり!)
    • コントローラに書きがちな処理をモデルにもっていく
    • モデルで attr_accessor で DB に関係ない属性を追加
    • パラメータ構造をかえる # form_for を使うとか
    • これでパラメータを受けとったタイミングでモデルにはいるのでコントローラで分岐処理を書く必要がなくなる
  • 付随する他モデルへの処理の移動
    • あるモデルを触るついでに別モデルもさわる場合もコントローラにかかれがち
    • モデルのコールバック (save や destroy などの前後に呼び出される処理) に移しましょう
  • 話せなかったこと
    • 多レベルの検証 (範囲を決めて検証とか) # これ聞きたいな
    • STI の原則
    • 関連オブジェクトに属性情報を伝える
    • routes.rb の整理
  • 実装パターンの見いだし方
    • 誰のすべき仕事なのかにこだわる
    • 原則に従う (DRY、CoC、RESTful)
    • コントローラの設計は、URL 設計から (対象リソース1種類につき 1コントローラ)
    • 複数リソースの CRUD がひとつのコントローラにはいっているのはまずい
  • しつもん
    • Q. 想定している開発者数
    • A. 10人以上、4-5ヶ月の開発期間
    • Q. 気づくとモデルが1000行とか...そういった場合は？ by 食べろぐの京和さん
    • A. 機能別にモジュールに切り出す、1ファイルの内容をしぼる
    • Q. モジュールが増えて、名前空間にこまったりしない？
    • A. モデルにそった名前をつけるとか
  • あとで大場さんに聞いたら、まずいコードの検知はペアプロだそうな

「エンタープライズ Rails」 に学ぶ企業のための Rails アーキテクチャ

  • あなたの会社でいちばん大切な資産って何ですか？
    • 人材？
    • エンタープライズなひとにとっては「要員」、それほど重要じゃないw
    • それはデータです。
  • データ中心アプローチ
    • プロセスよりもデータのほうが安定的
    • 要求をデータに対するものとして体系化できる
    • データモデルによって業務ルールを分析できる
  • Rails と DOA の類似点
  • Rails と DOA の相違点
  • DOA と Rails のギャップを埋めるのが「エンタープライズ Rails」
    • 作者は MySQL が大嫌いらしい
    • 使えない SQL、制約が多いとのこと
  • ここまで前フリ
  • データを保護するためには、アプリ層だけじゃなく、DB層の制約を使う
    • NOT NULL 制約
    • チェック制約 # 4文字以上とか (こんなのあったのね)
    • データベースのユニットテスト
      • save_with_validation(false) とかすると、modell の validation をはずしてDBのチェックを確認できる
    • 外部キー
  • データベースでちゃんとチェックするためには複合主キーのほうが都合がよい
    • Rails での複合主キーへの対応、composit_primary_key
 set_primary_keys
 has_many :foreign_keys => [...]
  • データベースビューの利用
    • View-backed モデル
    • migration では、execute を使う

Rails3

  • 疎結合化
    • ActiveRecord、ActiveController、ActiveView がけっこう密に結合
    • Rails3 ではそのあたりが綺麗に掃除
    • Rails内部も ActiveSupport の必要なところだけを require、ちゃんと依存関係を尊重
    • Rails本体のデフォはたぶんallをrequireするけど(便利だから)、オフにするオプションはある
    • ただし、これからはrequire順が重要になる
    • それを楽にするのに、ActiveSuppor::Concern を追加した
    • includedというメソッドでモジュールがすでにロードされているかを簡単に確認できる
    • depends_on で依存関係を明確にすることもできる？
  • Rails は Ruby Citizen になる

Lightning Talks

懇親会

  • iPhone 人口多し、Bamp いいなー

AP4R が Softpedia に登録されました

Ruby AP4R

ふと、気づくとメールが届いてました。
一瞬、ジャンクメールと見間違えたのは内緒です。 (^^;


Softpedia は海外のソフト紹介サイトで、400,000 以上のソフトウェアが登録されているそうです。Mac だけじゃなく、Windows や Linux 向けの各種ツールも扱っています。(と、さっき知りました。)

Subject: AP4R included in the Softpedia Mac OS software database


Congratulations,


AP4R, one of your products, has been added to Softpedia's database of software programs for Mac OS. It is featured with a description text, screenshots, download links and technical details on this page:
http://mac.softpedia.com/get/Developer-Tools/AP4R.shtml


The description text was created by our editors, using sources such as text from your product's homepage, information from its help system, the PAD file (if available) and the editor's own opinions on the program itself.


If you feel that having your product listed on Softpedia is not a benefit for you or simply need something changed or updated, please contact us via email at webmaster@softpedia.com and we will work with you to fix any problem you may have found with the product's listing.

  • -

Sincerely,
The Softpedia Team


ライセンスが「Free License」になってるのが微妙...。MIT、MIT。