6 月 11 日 午前の部

二日目も天気のぐずつく中で、熱気にあふれるカンファレンスとなりました。

二日目午前中の演題は、話題のスペクトルが広く、Ruby 用途の果てしない広がりを伺わせる一幕となりました。 また、話題の幅がただ広いだけでなく、とりあげる話題や題材に、昨日から午後の講演へと収斂する流れを感じさせる、配列の妙がありました。

……昨日よりちょっとお客さんが少ない？ いやべつに、たださんの『集客力がない』というわけではないんですけど…

ただただし「Ruby anywhere 〜 Ruby 普及のためにアプリケーションができること」

スピーカー
ただただし氏 (tDiary.org) tDiary のメイン開発者です。
時間
10:00〜10:30
セッション概要
Ruby 普及へのアプリケーションの貢献について、tDiary の開発を通じて学んだことを語る。
講演資料
http://sho.tdiary.net/images/RubyKaigi2006.tadatadashi.pdf s06110002.jpg
  • BR(Before Rails) 度 ★★★
  • 実装自覚度 ★★
  • 一貫ポリシー度 ★★★★
  • プレゼン技度 ★★★
  • 格好悪くなんてないですよ〜 DHH とか見れば度 ★★★

おはようございます。

  • けっこう元気ですな。
  • いろいろ挙手で調査。

注意

  • 昔話です。
  • マーケティングに近い。
  • 成功体験なので眉につばを (一般論ではない)。

普及ということ

  • 「Ruby の人は Perl に喧嘩を売ったりしない。平和主義的なんでしょうか？」
  • 「普及はカッコ悪いことじゃない」

場所への普及 (使える「場所」が増える)

  • 今やあらゆるレンタルサーバに、あたりまえのように最新の Ruby が入っている
  • Linux ディストリビューションに最新の Ruby のパッケージがある
  • と、_おれが_嬉しい

人への普及 (使う「人」が増える)

  • ライブラリやアプリケーションが増える
  • Ruby のお仕事が増える
  • と、_おれが_嬉しい

おれがうれしいから普及は善である

  • 「おれが嬉しい」というと聞こえが悪くとも、「おれ」というのを「ユーザー」と置き換えればよいはずです。
  • 「普及は悪いことでも恥ずかしがることでもない」。
  • 普及のためには、場所・人、両面から攻める。そのためにアプリケーションを作った。

tDiary (2001〜; BR 3 年)

  • tDiary は 2001 年 (BR 3 年) 開発開始。
  • BR というのは “Before Rails Era”。「Rails が無い時代があったんです」
  • 当時の日本の Web シーンでは Web 日記というものが結構重要な位置を占めていた。今で言う Blog に近いが、当時は Blog という言葉も無かった。そこで、Ruby で Web 日記システムを作った。

キャッチフレーズ

  • アプリケーションにはキャッチフレーズをつけることにしている。
  • tDiary のキャッチフレーズはずばり「日記コミュニケーションを加速する」
  • コミュニケーションのことなら貪欲にやる、と決めた。
    • ツッコミ (今でいうコメント機能)
    • リンク元表示 (今でいうトラックバック機能)
    • 携帯電話対応。書きたいときに書け，読みたいときに読める。今では日本の Web ブラウザの半数以上は携帯端末であり、「日本で Web アプリケーション作る以上、意識しないなんてありえない」。これを作ったとき、たださんは携帯を持っていなかったそう。
    • テーマ。デザインを CSS に分離した。テーマは現在は 300 個以上提供されており、Blog、Wiki、はてな、ゆびとま、MyWiki… などと共通に使ってもらっている。
  • これらは今の Blog ツールからすると当り前だが、当時は画期的な機能だった。コメントをメールでもらってはページを編集してアップロードして、アクセスログを解析してはリンク元を見付けて、そういうことを全部手動でやっていた。
  • こうして普通の人にアピールしていった。「普通の人重要」。
  • 「おたくにアピールしたって普及には結びつかない」。

開発を始めた当時の時代背景

  • 256 本出はじめ
  • www.ruby-lang.org のドメインが軌道に乗った頃
  • レンタルサーバーには Ruby など入っていない
  • 世間では「CGI ≒ Perl」という認識

知名度も環境もまだまだで、なにか Ruby で書いても使ってもらえない状況でした……なにも考えなかったら。

場所

そこでプロモーション戦略を練った。

  1. 魅力的なものを作る
  2. 使いたい人が増える
  3. レンタルサーバー業者に対する「Ruby をインストールしろ」という圧力が強くなる
  4. 場所が増える
  5. おれが嬉しい

そのためには、

  • Easy to Install (え゛ とかいわない！)
    • 変なライブラリ要求しない「Ruby 以外は何もいらない」作戦を取る。
    • どうしても ERb (ERbLight) だけが問題になったので「同梱させてください」と作者に頼んで同梱リリースする、という掟破りのこともやった。
  • 露出を増やす。
    • はやっているかのように見せる作戦。
    • tDiary.Net ドメインを立ち上げて無料ユーザを募った (2002 年)。
    • tDiary.Net には一気に数百人が加入した。当時は数百人という時点で一大事件であり、急速に目立つことになった。
    • また tDiary.Net の制約を嫌ってよそへ流出する人も出てきて、他サーバーへ移転し、これによりますますレンタルサーバー業者への Ruby 標準インストール圧力が強まった。

人

  • tDiary では、人を増やすためにプラグインを簡単に書けるような仕組みを取り入れた。
  • メソッドを増やすだけ
  • Plugin インスタンスに instance_eval するだけ

結果として名前空間の分離はなく、実行順序がファイル名依存というように、欠点も多い「うわ ださっ」な仕組みになったが、これは戦略。こうしてプラグイン開発のハードルを思い切り下げ、人々を Ruby プログラミングへと誘導した。

まとめ

  • 普及は善
  • 場所を増やす
  • 人を増やす

ちなみに Rails は

  • 人を増やす戦略がうまい。
  • 使える場所はまだまだ少ない。
  • 依存ライブラリが多いし、gem は敷居が高い。
  • Rails 普及を促すアプリケーションの登場を期待したい。

Q&A

Q1 (前田さん)
プラグインが eRuby なんですが、$SAFE=4 でうごかせば安全という建前ですけど……
A1
建前どおりに捉えています。自分だけで使うだけでなく、他人に貸せるようにしたかった。開発を始めたのが 5 年前だったので、eRuby で $SAFE=4 とするしか選択肢はなかったのです。
C1 (前田さん)
たださんのせいではないです。まつもとさんのせい？
Q2 (後藤 (ごとけん) さん)
会社で使っていて、使っていた人が退社したときなど、アカウント管理したいのですがベストプラクティスは？パスワードをうまく扱えるやり方があったらいいな。
A2
フォーム内にそういうフィールドを設ける？
Q2 (後藤 (ごとけん) さん)
パスワード忘れたときに、email アドレス打てばメールで返すようなものは、なぜないの？
A2
できるだけ自前で実装するポリシーなので、手間はかけたくなかった。認証は Web サーバまかせ。Basic 認証を書き換えるだとか、やろうと思えばできる世界だろう。
C2 (後藤 (ごとけん) さん)
Basic 認証に対応できない人が多い。あのダイアログをみるとひくらしい。
A2
それを裏付ける調査結果もあります。時代は変わった、ということなのでしょう。
Q3 (松岡さん)
2001 〜 2006 年で野望の達成度は？
A
今時点というのであれば、普及はほぼ 100% 達成できた。その 100% が tDiary のおかげというつもりはないが、自分の希望するレベルには達した、と考えている。

関将俊「dRuby をもう一度」

スピーカー
関将俊氏 (druby.org) drb, erb などの標準添付ライブラリの作者さんです。
時間
10:31〜11:02
セッション概要
dRuby を使った分散オブジェクトプログラミング
講演資料
http://www.druby.org/dRubyAgain.pdf s06110010.jpg
  • BR 度 ★★
  • 時代を呼び戻す度 ★★★★
  • 未来も語り度 ★★★
  • 自著・他著公平に宣伝度 ★★
  • 高齢化社会になるわけです度 ★

dRuby をもう一度思い出してみよう

今日も古い話ばっかり。

重要なことを先に

本

私

  • 今日は Agile の人じゃない
  • 内向的なプログラマ
    • コードにつぶやく
  • たださんみたいにアプリケーション調停することが苦手
  • 作るものは部品ばっか
    • 作ったものの、ユーザ数 1 とか。

ERB

  • テンプレートだけで動かすなんて思ってもみなかった
  • たださん + arton さんの本『網道編』、「こう感動してほしい」がある！
  • Rails 様様で ERB 利用者急増中

今日は dRuby の話をしましょう

再入門の前に、忘れていた歴史の話

  • HTTP サーバ shttpsrv (原さん、1998) を拡張して遊ぶ。
  • やっぱり bookmark 機能が好き。(タグ付けする)
  • RDB を shttpsrv で隠す
  • UI の shttpsrv と http でつなぐ

遊んでいるうちに、発見

  • Ruby としてしか使ってなかった。クライアント対サーバではなくて、Ruby の分散環境が欲しいのでは？
  • shttpsrv の実装をマネる。
  • 要求ごとにスレッドつくるのかっこいい。
  • 書いてみようかな、と思ったら書けた。200 行くらい。Ruby すごい。

再入門

dRuby では、オブジェクトにメッセージを送ると、そのメッセージが他のプロセスに転送され、その転送先でメソッドが起動される。

実験

調査: drb つかってる人

手を挙げてください……(20 〜 30 人くらい)。いる！

  • irb ふたつで対話しよう (y<=>b)
y: {} を front
b: front を参照
  • {} をいじると Hash を公開できる
  • オブジェクトを交換するときに、自動的に値でか参照でかを仕分けして渡す
  • Thread は参照渡し。
  • ブロック付メソッドもふつうに動く。ブロックは Proc で出来てる。Proc は参照渡し。yield は Proc への操作である。
  • ブロック付メソッドが動いている。(例: リモート each)
  • Ruby なので IDL が不要。
  • Thread 同期の仕組みもそのまま。

で？ 何に使うの？

  • いろんな分散
  • 配置 - プロセス - マシン

配置と寿命

オブジェクトって、結局そのプロセスにしかない。

寿命: プロセス < オブジェクト

「相対的」永続化がほとんどだろう (たとえば CGI より長生きさせたい、というのが要求の肝)。 それはもしかして OODB じゃないの？

実装: RWiki == オンメモリ OODB

再起動のときの手がかりとして中身を RD に落とす。変更のログ。 実行中は一切 RD を読まない。書き込むだけ。起動時の再構築に使う。

  • RD data という構想があったけどパス。
  • StoryCard 拡張。gotoken さんのいうチケットシステムのようなもの。
  • ストーリーをオブジェクトに。たぶんスケールしないけど、要るときに考える。

長生きなオブジェクト

Web の UI とか、長生きが自然。コンテキストは細切れ (ユーザーはそう思ってない)

遺言作戦

どこに書くの？ 相続問題が発生する。 「遺言に苦労するなら、死ななきゃいいじゃん！」

Web UI 2.0; dRuby の Web UI への応用

  • Div/Tofu

もっとかっこいいやつ

並列処理糊言語 Linda, Rinda

処理の協調が出来る。参加者がマスターしか知らなくてもちゃんと動くのがミソ。超かっこいい！

  • Linda: in out
  • Rinda: write take, 待ち合わせが出来る。→安全なカウンター

動的な構成言語 Ring (front と URI, Again)

dRuby では結局だれかのことを知らないと動かない。ので Ring。これは TupleSpace を探す仕組 (RingFinger)。

参加者は lookup で自サービスを登録、取得する。参加者がこけたら、賞味期限切れで削除。完全ではないがまあまあ動く。 個人サイト druby.org の維持・運用に使っている。

やっと未来を語れる

少しだけ。proxy ネタで

  • Koya
  • ARb

ARb

$SAFE=4 だとログも残せない。ログを残すサービスなどを、$SAFE=4 のスレッドに公開したかったので書いてみた。でも $SAFE=4 がいまいちだめっぽいので ARb の出番は……。

Q&A

Q1 (森脇さん)
サーバ側がマシンがトラブるとエラーになります。マスターを複数に出来るといいなと思うんですが。
A1
今聞いたんで、これから考えます。
Q2 (Yuguiさん)
Rinda、TupleSpace 管理側に HeartBeat を送るとか (……) 出来ないのか？
A2
今の Rinda だと、Tuple エントリの参照を返せる。キャンセルもできる。もうすぐ期限というときに「まだ生きてる？」と質問も返せる。

中島拓「Amrita2 の紹介」

スピーカー
中島拓氏 ((株) ブレーン) いまや blog の世界の有名人です。hack のセカイへお帰りなさい essa さん。
時間
11:03〜11:32
セッション概要
HTML テンプレートライブラリ Amrita2 の設計思想と実装の紹介
講演資料
http://amrita.s14.xrea.com/files/rubyconf2006/rubyconf2006.tar.gz , http://amrita.s14.xrea.com/files/rubyconf2006/rubyconf2006.xul (Firefox が必要) s06110019.jpg
  • AR(After Rails) 度 ★★
  • 一貫思想度 ★★★
  • 控室から拍手度 (by DRY な男) ★★★
  • もんた度 ★★

今日話す Amrita2 の構想は「だいぶ前にはだいたい固まりつつあったのだが、blog にはまってしまって開発が中断していた」とのこと。

テンプレートとは何か？

文字列なのか構造化されたドキュメント (HTML や XML) なのか？

  • HTML/XML は構造化されているので、テンプレートも構造化ドキュメントとして扱った方がいい。
  • 大半のテンプレートエンジンはテンプレートを文字列として扱っている

テンプレートエンジンとは何か？

実行環境か演算か？

  • 「実行環境派」はテンプレートがプログラムで、エンジンが環境（変数やロジックをテンプレートに与える）と考える。
  • Amrita はテンプレートに対してエンジンがデータを適用する。テンプレートを単にオペレータとして、受身の存在と考える。テンプレートにデータを‘演算’すると結果が返る形。

違いがどこに効くか？

セキュリティ。

  • エンジンが環境だと、個々のテンプレートを検証する必要がある。ERB で <%=h %> にするだけ？ でも検証は「個々に」だから面倒。
  • Amrita でセキュリティの責任はエンジン側。エンジンが演算なら、エンジンだけを検証すればよい。

Amrita とはなにか？

  • 上記の選択、いずれも後者を採る。
    • エンジンはアクティブで演算をする
    • データは構造化されている
  • データの構造を利用することで、セキュリティの自然な解を得られる。
    • データが文字列なら置換する
    • 配列なら繰り返しになる
    • 真偽値なら表示条件になる

コード

API は、ほとんど expand 一個だけ。 結果、テンプレートと組み合わせて、スカラーでも配列でも true/false/nil でも扱える。Ruby の素のオブジェクトも扱えるので、たとえば現在時刻が表示できる。

Amrita2 とは何か？

多少妥協した部分がある

  • 綺麗に決まるところはビシッと決まる。しかしすべての現実に対応はできない。その結果、よく分からないはまり方を招きやすかった。
  • Partial ERb template (ところどころ埋め込むことが出来るように)。

Amrita on Rails

  • Amrita2 は Rails の View として使うことができる
  • 豊富なヘルパーメソッドを使えるように部分的に ERb を埋め込める: tmpl.use_erb(binding)
  • <![CDATA[ ]]> を書かないと ERb が埋め込めないので、だったら、これを目印として使う。

amrita:type

HTML to Ruby コンパイラ。amrita:type 属性はコンパイラオプション。API として公開はしていないが一応拡張可能な形。

  • 例: amrita:type=’link’, amrita:type=’use_args’

使い方

  • ループはコントローラ側に移した。コントローラがふくらむ。
  • テストが手で書いてもカンタン。
  • ビューの logic を presentation から分離した。あまり速くはないが。

Schedule

なんとも…… どんどんせかしてください。 はてなにある開発ブログのタイトル変更: 「Amrita2 強化月間」→「gem 戦記」

おわり

控室から拍手が聞こえます。めずらしい。

Q&A

ここで控室から長身痩躯碧眼の男性が登場、登壇者に英語で質問を浴びせ始めます。 DHH でした (二日目のみの参加者のみなさんの中には、ここで初めて Ruby on Rails 作者をごらんになった方もおありでしょう)。

  • essa、DHH に連れられて別室に拉致される

(質問は 2 つあったとのこと、登壇者のブログに詳しく紹介されています。)

secondlife (舘野祐一) 「Perl の会社で使われる Ruby の利用法とは！？」

スピーカー
secondlife (舘野祐一氏) (株式会社はてな) 何かと話題の会社の中の人であり、rail2u.com の中の人でもあります。
時間
11:33〜11:59
セッション概要
はてなの裏側で Ruby こっそり
講演資料
http://rails2u.com/misc/rubyka2006/ s06110032.jpg
  • Ad(After dRuby) 度 ★★
  • 他著宣伝度 ★★
  • 「へんな会社」度 ★★
  • 活用の場開拓「それ Ruby でできるじゃん」度 ★★★★
  • プレゼン技度 ★★

自己紹介

好きなアイドルの項を立てたのは、結局 secondlife さんだけでした。

デプロイツール

  • 2006年、社内バージョン管理システム (VCS) を CVS から subversion へ移行
  • いいデプロイツールが無かった
  • SwitchTower (→現 Capistrano) 使ったらどうか？
    • Ruby で書かれている
    • 規約に沿って書かれたものなら OK
    • Rails に向いている
    • さまざまなバージョンコントロールシステムで利用可能
    • 実行はレシピ (Rake のコード) を置くだけ。
  • 実際に使ってみた。
    • けっこう使えた。
    • SwitchTower の deploy の流れは、ほとんどの LL な Web アプリの管理にあてはまる。

しかし使い込むと罠が……

  • Rake のオプションでつまづく。::CLI ラップして使う……
  • コマンドラインユーティリティ自作しちゃったほうがよくね？ サーバの棲み分け
  • 構成（アプリサーバ + DBサーバ + Webサーバ）が定型から外れると、hatena_recipe.rb を作ることになる
  • production 環境だけしか deploy できない？ →本体拡張して

はてなの中での使い方、起きたこと……

  • 全サーバ同時にしかリスタートできない
    1. 全部リスタート
    2. 2, 3 秒サービスが止まってしまう
    3. ロードバランサー混乱
    4. 「時間差リスタート」が欲しい
  • ロールバック
    • 途中で 1 台がリスタート失敗したら、その 1 台だけやり直しができない
    • 全部ロールバック
  • 本気で改善して、いまは、わりと幸せな感じになった。

サービス

いままでは社内システムは全部 Perl で書かれていた。でも Perl は……今後どうなるの？ そろそろ転換期？でも Ruby で Web サービスといっても決定打はないし……

そこで Rails の登場

  • Webアプリが作りやすくなった。FCGI とか mongrel とか。
  • まともな速度で安定して動く。
  • CPAN が無くても gems が使える。

もちろん「これからはみんな Ruby ですよ」「あ、いーよー」とはならないので。

  • さくっと作って社内アピール。
    • はてな SNS。
    • はてなスクリーンショット、5 月下旬リリース。

はてなスクリーンショット

  • Rails アプリ
    • lighttp が静的ページ担当。
    • mongrel が動的ページ担当。いまはそれほどアクセスないので余裕。
  • proxy 他サービスとの共用、一台で。他の一台は app, db 込み込み。
  • DB は MySQL
  • スクリーンショットを実際巡回しに行くサーバはさらに別建て (後記の理由で Windows)。
  • dRuby で URL をクライアントがもらって、スクリーンショットを撮って、dRuby で返す

他の社内 Perl サービスとの連携

  • 疎結合で、REST。といっても GET のみだけど。

ショットは実際にはどう撮るか？

  • Linux→不安定、遅い。じつは Windows (IE コンポーネント)→速い、全然きれい。

さてここで dRuby ですよ。

  • ある程度のスケーラビリティは確保。dRuby 最高！
  • 去年良書が出版された。まだ初版が買えるので。
  • 私事ですが、るびまの読者プレゼントに当選しなかったら、はてなスクリーンショットは今この世になかったかもしれない。

勉強法

オススメは、はてな。

はてなダイアリー

  • キーワードで Ruby のチェック
  • id:ruby* もオススメ
  • 実は rubywo は社内の

はてなグループ

  • rubyist グループというものがある。
  • ソース貼るとすべてのメソッドにリンクが貼られて、Ruby Quiz の答えを貼ったりすると、添削に非常に便利。
  • 最近は割と活発。

Q&A

Q1 (たださん)
dRuby の使い方で、Rinda でやった方が、実装きれいっぽくならない？
A1
TupleSpace つかうときれいだろうなあ。と今なら思います。作った当時は知らなかった……。