形式は前半・後半に時間を区切って オープンスペース 形式。要 ポジション・ペーパー というのも変わらず。
この形式はいいんじゃないかなと思ってる。最初、秋葉原でやっていた頃、参加者全員が集まって座れる場所を確保できなかった故に 角谷さん の発案でオープンスペースになったそうだけれど( 第0回 )、これによって、最多で10人程度に分かれるから参加者のコミュニケーションが促進されてる。Listen Only Memberを発生しにくい仕組みになってるんじゃないかと思う。
反面、少数であるが故に全員が受け身だとひたすら沈黙になってしまうのは確か。一時期、そういう感じでいつまで経ってもセッション案が出なかったりしたけれど。でも、 もろはし さんの提言で事前にセッション案を十分に出しておくというのが復活して、そういう難点は解消されつつある。
ポジション・ペーパーについてはこれはよい作用をしているのは言うまでもない。どういう人なのか、Ralsについてどういう立場なのか、どう考えているのか、どのくらいの知識があるのかがはっきり分かるから、参加者の一体感を高める役に立つし、そこからセッションが膨らむことも多々ある。
唯一ポジション・ペーパーの難点を言うならば、私が初参加のときに感じたのだけれど、一般的な手法ではないが故の敷居の高さがある。こういう集まりに参加したことがないと、何かを書いていいのか分からなくて不安だ。一応、勉強会の公式ページから参照されてる解説にも作例はあるけれど、ね。これは勉強会に参加した人が積極的に自分のベーパーを公開することで敷居を低くするしかないんじゃないかと思う。で、私も過去のレポートで何回か、公開している。
今回は出かける間際に慌てて書いたので私のポジション・ペーバーは手書きだったのだけれど、内容はこんな感じだ。
Yugui (園田 裕貴)
- ratio - rational - irrational (http://idm.s9.xrea.com/ratio/)
- 株式会社プライムスタイル テクニカル雑用係
舞波乙
- Rails + ABD 研究中
- has_one :through 作成中
- はぶさんを囲むRails使いの団(Hakr団)発足
- C++はLLです
- Apple教、入信しました。
えっと、ポジション・ペーパーを見せながらの自己紹介のとき喋った内容を補足すると、
舞波さんの『 Ruby on Rails入門 』はいいね。
何気なく持ってきたら、なんと今回は舞波さん本人が出席していた。
はぶあきひろさん 提唱のABD(Activity Based Datamodel)は、DHHが言っているCRUDな世界と相性がいいし、アジャイルプロセスとも相性がいいし、スーパーDBエンジニアならざる一般のWeb屋でも使えるDB設計技法なので、いろんな意味てRailsと相性が良いんではないだろうかと思って、組み合わせのノウハウを研究中。
昨日のLL Ringで会ったとき、もろはしさんと話して、はぶさんを飲み会にご招待してABDを語ってもらう場を設けようと決定。はぶさんご自身も「 呼んでくれれば話す 」と仰ってるし。実施は10月以降の予定。そのうち、それ以降ではぶさんの都合の良い時期を聞いてみよう。
追記: む、はぶさんご自身が 飲み会やる感じ だけど、これはこっちの動きとは関係あるの? ないの? とにかく参加希望。
昨日のLL Ringで「(C++は)LLじゃないけどね」と言われたのがちょっと悔しかった。
id:ogijun さんの営業力にかなり影響されてる
要素指定をどう書くか
一応、一通りの話が終わってあとはだんだん雑談へシフトした。Seleniumに限らず、標準のassert_tagであれ、Hpricot test extensionであれ、出力されたHTMLを検証するにはある種の困難がある。要素を特定するためにXPathを使ったりしてなんとか要素を表す訳だけれども、viewをいじるとXPath式がすぐに無効になってしまうからだ。
私は「でも、そういうところで悩まないようにアサーションを掛けたいような対象にはきっちりidを振っておくのは良い習慣かもしれない」と言ったけれど、「でもデザイナーさんが絡むとその理屈が通じなかったりするからなー」と言われたり。
HTML parser
Viewに対してのテストで、出力されたHTMLを解析してアサーションを掛けたいのだけれど、parserが遅い問屋なので何が良い? という話。
お薦めは Hpricot 。一部Cで実装されているので 速い し、テストケースで自動的にHTMLを解析してくれてアサーションに使えるようにする Hpricot Test Extension もある。
ちなみに、Hpricot Test Extensionは一度解析したデータをずっとキャッシュしてるので、テストメソッド内で複数のリクエストが発生するIntegration Testに使うと変なことになる。私はそこを修正して動かしてるけど、あぁ、パッチ送らなきゃ。
というか、Viewが生成するHTMLに対するアサーションはFunctional TestとIntegration Testとどちらに置くのが正しいんだろう。
本当に雑談
- よしみさん曰く、『 Perlベストプラクティス 』はRubyにも活かせる知識が盛りだくさん
舞波さんに、本にサインしてもらった。
後半セッション
後半も3つのセッションに分かれた。
- Rioを読む
- ソーシャルブックマークを作る
- has_one :throughを作る
私は一応has_one :throughセッションのオーナーを務めた(努めたというほうが正しい気がするが)。
先日作った has_one :through には予想以上に反響があった。それでセッションのネタ出しにあたってhas_one :throughのセッションを求められたのだが、何しろあれからあまり進展してない。
まず、has_one :throughをActiveRecord本体に対するパッチとして書き直すことだけは決めてある。でも、 Railsパッチの書き方 に書いてある「テスト駆動だテスト駆動」「ちゃんとテストしろよ」というのに激しく頷いてテストを書こうとはしたものの、 ActiveRecordのテスト用モデル の複雑さにちょっと困惑していたのであった。とりあえず整理しようと思って クラス図もどきを書いてみた ものの、さて、どうしたもんか、と。
それで、「私と一緒にhas_one :throughを作らないか」セッションならやれますよー、と言ってセッション主催となった。そして、舞波さんや瀧内さんや、実際にパッチを書いているひとたちの参加もあってとても実りあるセッションとなった。
- has_one :throughの実装方針
- acts_as_tabの予告
- habtm 2.0構想
- タブ表示ライブラリの予告
- ABD の真の姿
has_one :throughの実装方針
みんなでクラス図もどきを眺めた末、Post - Categorization - Categoryモデルにおいて、Postが
has_one :main_categorization, :conditions => .... has_one :main_category, :through => :main_categorization
とかするのが一番適切かな、ということになった。
これ、別にhas_manyしてるモデルを:throughしてもいいのだけれど。
has_many :categorizations has_one :main_category, :through => :categorizations, :conditions => ...
こんな風に。でも、この場合Categorizationは:conditionsで絞られて、結局唯一の行だけを:throughしてhas_oneしてるわけだから、表記としては単数系の
has_many :categorizations has_one :main_category, :through => :categorization, :conditions => ...
のほうが自然だね、ということになった。ここは実装にちょっと工夫が要るかな。
acts_as_tab, habtm 2.0
これらの詳細は舞波さんからの告知を待て。期待して良いはず。私が書くより舞波さんにAA付きで書いてもらった方がきっと読者は感動できるだろう。
どちらも、結局はレコードのアイデンティティをどう捉えるのが自然か、というところに通じるのね。舞波さんが考えていたacts_as_tabと、後述するABDの読み込みとを通じて、habtmにあってhas_many :throughが失ったものは本質的に何かというのをみんなで検討した結果、その失われたものを取り戻すhabtm 2.0の構想が生まれた、とだけ言っておこう。
タブ表示ライブラリ
acts_as_tabと関連して舞波さんがスマートにタブ表示を実現するCSSを欲しがっていたのだけれど、これはshachiさんが近いうちに実装してまとめてくださるとのこと。
ABDの真の姿
さてさて。このセッションで得た大きな収穫としてABD理解の深化もあった。
Searsar Conference 2006 Springで はぶさんのABDの話を聞いて 、それでえらく感動してABDかわいいよABDと言い続けてきたけれど、実はABDについて私は大きな勘違いをしていることが判明。
はぶさんが「 アクティビティ系を忘れるな 」と指摘なさってるけれど、私はまさにアクティビティ系を見落としてた。で、「 アクティビティ系って何だっけ? 」と慌てたのであった。
Seasar Conferenceのときのはぶさんの資料 を見てほしい。32ページ目の図を見ると、売上の日付は独立した「売上」テーブルになっている。「売上_関連」テーブルとは別物だ。
私の考えていたやり方だと、この2つのテーブルは結合してるのね。売上があったというイベントに対応する「売上」テーブルがJoin Tableとして 「顧客」「商品」「売上明細」を結びつけていて、日付は「売上」の属性になる。これはDHHがPerson - Membership - Memberのモデルで説明してるのと同じところに落ち着いて、だからRailsがActiveResourceで目指そうとしてるのと大体同じだ。
でも、はぶさんの説明は違う。売上があったという事実(Fact)の記録は「売上」表に記録されて、これはForeign Keyを持たない。そして、「顧客」「商品」「売上」「売上明細」を結びつけるActivityの記録が「売上関連」テーブルだ。はぶさんが言ってるイベント系が「売上」でアクティビティ系が「売上関連」であるらしい。
そういえばSearsar Conferenceでもそう言っていた気がするし、この資料自体にそう書いてある。この資料は今まで何度も読み返したのだけれど、でも私は何か違った思い込みで資料を読んでいて、目が曇っていた。私の目は節穴か。セッションの中でみんなで徹底してこの資料を読み込んで、ようやく、どうも違うらしいということが分かってきた。
そうすると、はぶさんのやり方はDHHのやり方より更にeXtremeだ。そして、今のところの私の思想は、DHHよりはeXtremeではぶさんよりは保守的だ。私がここしばらくRailsに「アクティビティ系を見落としたABD」を適用してきた限りでは、「結合してしまったイベント系+アクティビティ系」にアクティビティにまつわるロジックを持たせるとコントローラーにMVCのオーケストレイト以外のロジックが混ざり込まなくて割り合い綺麗に実装できるらしい。それで、私にはまだ、どうして日付をアクティビティ系の属性にしてはいけないのか理解できていない。ABDは「スーパーDBエンジニアならざるWeb屋にもできる楽な設計法」であると理解しているけれど、日付を分離して「売上」にするとそうでないときに比べてどのように楽になるのか理解できていない。
ともかく、私が前に書いた記事は非常に不完全。私の理解は今も不完全。ABDの方向性には賛同するけれども、結局は異なる考えを持つかもしれない。でも、今回のセッションでちょっとだけアクティビティ系が何なのかという理解に近づいた。
そして、私がABDの方向性の中に見いだす一番の価値はやっぱりアジャイルであることである。週単位でビジネスの視野自体が変化するような現場での、RDBに可能な限りの柔軟性である。たぶん、これははぶさんとは力点が違う。だから、私が今考えている力点の置きかた、そこから導きだされるABDに似てABDならざるモデリング、多分DHHの考え方にかなり似ているやりかた。そこには別の名前をつけるべきなのかもしれない。たとえそれが、試行錯誤を重ねた末に結局は本物のABDに収束していく可能性が高いとしても。
折角はぶさんが「 強大な敵求む 」と仰ってるので、敵になる気満々でこのABDもどきのことを「"Agile Building Datamodel"とでも名付けるか」、と言ったら舞波さんに「ややこしいから同じabbrはやめてほしい」と言われた。「べっ、別にActivity Based Datamodelなんか気にしてないんだからね(赤面)」感が漂って良いかと思ったのだが。
他のセッション
Rioを読む
今回の勉強会直前に話題になった統合IOライブラリである Rio を読んだそうだ。もうこれはRubyではない別の言語語彙を為していて、実装も複雑怪奇であったという。
ソーシャルブックマークを作る
前回の勉強会から引き続いてSBSを作ったという。
それにしても、みんなにガンガン意見を出してもらったおかげで悩んでいたhas_one :throughの実装方針もすんなり決まったし、habtm 2.0なんて素敵なものまで出てきた。「こういうブレーンストーミング系のセッションは効果的」とのshachiさんの評。
