6 月 10 日 午後の部 - 2

ここからの第三部は、司会のかずひこさんの紹介通り、「ヤケド必至のマニアな時間」がはじまりました。

arton 「Rubyize による言語境界の越え方」

スピーカー

arton 氏; Microsoft の Windows OS 上で Ruby を動作させる ActiveScript エンジンである、ActiveScriptRuby (ASR) の開発者であり、Ruby と Java とをブリッジする rjb の開発者でもあります (ActiveScriptRuby も実体はブリッジであり、実際のスクリプトの処理は同梱する Ruby の Windows バイナリが行う)。

時間

14:28〜15:03

セッション概要

VBScript、JScript、VB6 などから Ruby を呼ぶ方法

講演資料: http://arton.no-ip.info/data/rubyconj2006/rubyKaigi2006.zip

• ソースコード全開度 ★★★
• 特定環境動物キャラ虐待度 ★
• そこまでするほど VB 嫌ですか度 ★★
• 邪道の蓄積度 ★★★★
• .NET 以降の最新 VM との協調度 -

イルカのデモ

冒頭、Windows 連携を誇示するかのようにオフィスアシスタントのイルカちゃんが PowerPoint を起動して、「TBD」と書かれた部分をプレゼンテーションのアジェンダに書き替えたりしていました。もちろん、背後ではこれを Ruby プログラムが操っています。

Win32OLE, COM, WSC, ASR

Win32OLE¹ が主役です。 COM (Component Object Model) ²は、Windows のカーネルでない部分で、サービス、といっても半分は定義でできています。 そのなかで、今回紹介するのは WSC (Windows Script Component)³、その中で実際サービスを提供している ScrObj.dll との連携を考えます。 VBScript、JScript、VB6 などから Ruby を呼び出す Rubyize も、これでつくられています。

Rubyize

ASR⁴ 附属。使用するには、regsvr32 rbobj.wsc で一回レジストリに登録しないといけません。 これがどういうものかを、JScript 版と VBScript 版の二種類で説明されました。

C レベル (水面下) では何をやってるか？ を明示するためにデモの C 実装が示されました。Visual Basic のオブジェクトの引数の順番に Rubyize の Object(bstr) 引数を合わせている点がはまりやすい、と指摘されました。

速度

「最初は呼べば呼ぶほどオブジェクトを作りまくる実装だったので、結果を返すときだけ生成するようにした」という裏話も披露されました。

Q&A

Q (前田さん)

GC (の方式) は？

A

参照カウンタ。正しく解放しないプログラムがあり、ずっと使っていると重くなってくる。夕方になると電源を切る時代を引きずっているのではないかと推測。mark & sweep とは合わない点はある。また循環参照をはじめとして参照カウンタの実装そのものにも難しい点があり、そこにスレッドの扱いがからむと手が打てない。たとえばイルカはイベントによって次の処理を実行する。この中で DOM をいじろうとすると、プロセスが異様な死に方をする。イルカが LRPC の呼び出しを受けたスレッドからイベントを呼び出しているのではないかと思う。

このころからマイクに若干の異常がみられましたが、その日のうちに運用上の解決を見たようです。

田中哲「使いやすいライブラリ API デザイン」

スピーカー

田中哲氏 (産業技術総合研究所 情報技術研究部門); open-uri をはじめとする多くの標準添付ライブラリの作者です。

時間

15:03〜15:34

セッション概要

使いやすいライブラリをデザインする方法 (RubyConf 2005 の話をコンパクトにしたもの)

講演資料

http://cvs.m17n.org/~akr/pub/rubykaigi2006-06-10.pdf

• Ruby らしい設計指針度 ★★★★
• ライブラリ作者面前で度 ★★
• ベタに深謀無遠慮度 ★★
• 時間不足度 ★★★

目的

• 「ユーザの望みをなんとなくかなえてしまう API を設計する」
• 「怠惰志向設計をしよう」

着目点

• 「Larry Wall の三大美徳」でいう怠惰とは違って、人間はベタに怠惰である。がんばればいいじゃん、で設計された API は使いにくい。

手段

1. ユーザーの典型的な望みをなんとかして推測する
2. 実装 (発表では触れない)
3. 実装した「ユーザーの典型的な望み」にどうにかしてたどりつかせる――誘導する。
   • ユーザが怠惰なので、逆説的にそんな誘導が可能である

成功例: open-uri

Net::HTTP よりシェアがあります (ここで控室から Net::HTTP 作者の青木さん 連行 登場です)。

• open-uri では (くさるほど考えて、ユーザがモノを憶えなくてもいいように)「典型的な望み」に API をチューンしてある。

• 単にデータを HTTP で取ってきて表示するだけならばどちらのライブラリでも大差ないが、ちょっと違ったことをしようとすると、Net::HTTP ではいちいち新しい API を覚えて書き方を変えないといけない。open-uri ではオプション引数を増やす程度で済む。
  • レスポンスヘッダ取得
  • リクエストヘッダ指定
  • プロキシの使用
  • BASIC 認証
  • 極めつけが SSL
• SSL に至っては、Net::HTTP の場合、require するファイルを HTTPS 専用のものに変えた上でポート番号 443 を明示的に指定する必要がある。
  • ユーザーは HTTPS のポートが 443 であることを覚えておかなければならない
  • Net::HTTP ライブラリは HTTP の機能を余す所無く、十分に使いこなせるよう設計されているために、API が比較的低水準であることが原因

誘導

• open-uri ではこれらはすべて、オプションを指定するだけ。これを実現するための設計指針として、機能を以下の2つに分類して、後者は使いにくくする、もしくは使えなくしている。
  • 典型的な望み
  • あまり典型的でない望み／だれも望まないこと
• こうして前者に誘導する。ユーザは最小限のことしか憶えなくても使える、使いやすいライブラリになる。
• open-uri の場合はインクリメント処理・パーシステントな処理は、あまり典型的でないので使えなくなっている。
• その代わりに典型的な処理においては使いかたがぐっと簡単になっている。

使いやすい API を、具体的にはどうデザインするか？

推測 (非常に重要)

対象領域

対象領域を考察することで、その世界に入ろうとする／入り込んでいる人の望みはある程度わかる。例えば SSL なら「サーバを検証する」など。「初心を忘れるべからず」。あとあと実装のために規格や仕様書に下手に入り込んでしまうと、往々にして規格の思想に染まってしまい、ユーザーの典型的な望みを忘れがちになる。必要ならば、規格の調査に入る前に、実現したい「典型的な望み」をメモしておく。

メタファ

メタファがあると想像しやすく憶えやすく思い出しやすい (誘導しやすい) 。例えば open-uri は「URI でアクセスするファイル」というメタファを使用している。メタファを導入した結果、たとえば次のような問答が予想できる。

• 書き込めるか？: すいません、それはまだ作ってません。
• ディレクトリをたどれるか？: すいません、それもまだです (このような質問が出ること自体、ユーザを誘導できている証拠！)。

常識

常識がユーザにあれば、もともと知っていることだしお互い楽できる。ユーザーは新しいことを覚えるのを嫌う。常識というのはわざわざ覚え直す必要がない。例としては、Ruby の組み込みメソッド・Unix・標準 POSIX・RFC など。これらはopen-uri のユーザー層を考えれば、ある程度知られているはず。いくら声が大きくても、変人の言うことは誰も聞きません。(cough cough)

一貫性

一貫性により外部からの類推が効きやすく (透明に) なる。そうなると、逆にライブラリ作者の側としてもユーザの行動を予測しやすくなる。ただし、やりすぎると苦労の割に誰も喜ばないので、対象領域の推測よりも要求としては弱い。

誘導 (難しいところ)

1. 普段遣いのクラスやメソッドの数を減らす: Ruby の大クラス主義はここに通じる。注意: ミニマリズム (可能な限りのチイサナセカイ狙い) に陥るな。
2. 設定なしが良い設定
3. ハフマンコード: よく使うものほど短い名前にする(もともとは Perl の思想。例としては p コマンド。これは名前としては非常識)。
4. DRY⁵: 落とし穴回避

フィードバックで改善 (継続的に)

1. イディオムは悪い兆候: 「便利なイディオム」が生まれるのはそういう「典型的な望み」が存在するのにライブラリが望みをかなえていないことを意味する。よく使われるイディオムを API に取り込んでしまいましょう。これはイディオムを一発で実行するようなもの。
2. 繰り返される驚き: 改善の目印になる。
3. 憶えにくい事項: これも改善の目印になる。

• 誘導には事前の備えが必要。
• もともとメソッド名はある程度の長さを持っていないと、後から短いメソッドに改善できない。したがって特にプリミティブは長めにしておくべき。不幸な例が CGI#[]。

次の例題: digest の問題。

SHA1 アルゴリズムを使うためのライブラリは digest/sha1 なのに、SHA256 アルゴリズムや SHA512 は digest/sha2。類推が効かない上に、2 という名前も良くない。ファイル名 sha2 が短いために、今更 sha256 というファイルを作ってもユーザーは短いほうを使いたがるので誘導できない。

終幕

残念ながら、ここでゴングがなってしまいました。時間切れです。「鳴ってしまった。すいません」

石塚圭樹「Ruby プログラミング + モデリングでより楽しくなろう - その 1」

スピーカー

石塚圭樹氏 (日本IBM ラショナル事業部); 世界初の Ruby 本の著者の一人で、Ruby 界の立役者として最古参の一人といえます。

時間

15:35〜16:03

セッション概要

Ruby プログラミングにモデリングを組み合わせる

講演資料

http://www.rubyist.net/~keiju/doc/ruby-with-modeling-for-pdf.pdf

• 設計手法度 ★★★
• メタ度 ★
• 分析度 ★★★
• ライブラリ化度 ★★
• 時間不足度 ★★
• いつか (2) をききたいな度 ★★★★
• 真実のモテ度 不明

はじめに

• Ruby なのにモデリングって禁句？
• いつか、その 2 があるかもしれません。
• 時間が来たら終わり。メタモデルは省略する。

なぜ Ruby でモデリング？

Ruby は高い記述力を備えているので、メソッドのフローを詳細に、また後から見ても分かりやすく書くことができる。 一方で、基本がテキスト表現なので、クラス間の関連は一目で把握できない。 オブジェクト指向においてはクラス間の関連が本質的に重要なので、 この状態は美しいアーキテクチャを開発する障害になる。 なにも考えないでベタでコーディングするとめちゃくちゃになりがち。 どうせ作るんなら美しいアーキテクチャを実現したい！

• UML 知ってる方は？ 約半数。
• UML で食べてる方は？ 一名。
• UML が Ruby に勝てるところ。UML 界に来れば講習会の半分は女性。

そこで UML

• UML: オブジェクト指向設計における標準的な記述言語で、その名も統一モデリング言語 (Unified Modeling Language)⁶。

標準的なビジュアル化の方法にはユースケース図やクラス図やシーケンス図などたくさんの種類があるが、講演では以下が紹介されました。

• クラス図
• コミュニケーション図 (UML1.* ではコラボレーション図)
• シーケンス図

結論。静的構造、システム全体の振舞、クラスの役割が明確化する。

デザインパターン

デザインパターンは、典型的な問題の文脈に対して (逆に言えばインタフェースとしては問題ごとに安定)、動的な解法を示すものである。 動的なので、ライブラリの対象外 (となることが多い)、と一般にはいわれている。

けれども、もとが動的な Ruby なら MLF⁷ を使えばライブラリ化できるのでは？ 実際にはどうなのか？ 使い物になるのか？

実際に試してみると GoF⁸ の 23 個のパターンのうち 9 個が実装できた。試したものはすべてライブラリ化できた (ここで Composite パターンの事例が紹介されました)。 けっこうパターンって単純な話が多いので、できるのは当たり前だなぁ。

• 課題 (1): インタフェースを「パターン間で」統一したい――メタメタレベル構造。「パターン間で」似た構造がある！
• 課題 (2): ソリューションはひとつではない！ コンテキストに応じたソリューションが提供できるのでは？
• 他: Ruby らしさの追求 (GoF は静的言語前提だし)。Parameterized Collaboration って Ruby で実現できないんだろうか？

いつかあるかもしれない「Ruby プログラミング + モデリングでより楽しくなろう - その 2」に続く……。

Ruby で MDA: 概念編

MDA の立場は Ruby の立場(というかアジャイル系の立場)と正反対にある

MDA = model driven architecture⁹

プラットフォーム独立モデル (PIM)→プラットフォーム特化モデル (PSM)→ソースコード。

これを Ruby でどのように実現するか？ PSM に関しては、Ruby でメカニズムやパターン記述能力によって, プラットフォームやアーキテクチャに依存する部分が表現可能なので PSM をわざわざ用いて表現する必要がない。また、Ruby でコードテンプレートの記述ができるので、わざわざ PSM 上で定義しなくても、PIM からいきなりコードを生成しちゃっていい。さらにアクション言語として Ruby そのものを採用すれば、実行まで可能！

次回の予告

実践編を。

休憩

ここで 10 分間の休憩。 懇親会の最後のアナウンス。

---