okkez です。

2009年12月20日21:40 Takao Kouji <kouji@t...>:
> 高尾です。
>
> みなさん、ruby-lang.org でのるりまの提供についてのご意見ありがとうございます。
>
> みなさんの意見の多くはるりまを提供するドメインに関するものですね。
> それと、okkezさんからは提供するコンテンツについて具体的な質問がありました。
>
> 1. ドメインについて

ドメインは doc.ruby-lang.org が良いと考えています。覚え安い方がいろいろなところで紹介しやすいです。
rurema が悪いとは言いませんが、doc.ruby-lang.org の方が圧倒的に覚えやすいし説明しやすいと思います。
パスはシンプルな方が望ましいので特に ja を入れなければならないとは考えていません。

> 2. 提供するコンテンツについて
>
> bitclust で動的なドキュメントを提供するならば静的なものは提供しません。okkez さんは両方のドキュメントを提供されていますが、静的なドキュメントを提供した方が良い理由はありますでしょうか。ユーザが permanent リンクをはるためにどちらか一方にしたほうが良いと考えています。bitclustより優れた検索機能を今月中に提供するのは難しいと判断し、bitclustだけを提供することにしました。
>

サーバーの負荷が問題ないなら良いと思います。
bitclust を thin (rack) で全バージョン動かすと 1 インスタンスあたり 250-300MB のメモリを消費します。
# doc.okkez.net では Ruby1.8.7 でそれを三つ動かしています。
また、キャッシュを使わない場合はちょっと負荷が高くなると思います。

「検索が遅い(と思う)」という話があったので簡単に調べてみたのですが、BitClust の検索自体は
速いと思います。

ローカルで試したところ以下のような結果になりました。
# 経験的に検索結果に現れるエントリが多いときと検索結果がないときに遅い

refe (bitclust)
to_s 初回 0.799sec, 二回め 0.140sec
nosuch 初回 0.342sec, 二回め 0.188sec

bitclust web (webrick debug mode)
to_s 初回　37.465sec 二回め 0.461sec
nosuch 初回 3.753sec 二回め 0.274sec

bitclust web (okkez.net thin) (二回め以降は nginx のキャッシュが効きます)
to_s 初回 34.444sec 二回め xxx
nosuc 初回 3sec 程度 二回め xxx

bitclust web の初回が異常に遅いのはウェブアプリケーションの場合は、検索結果の HTML を生成する
処理も毎回行っているためだと思います。(要確認)

> また、提供する新リファレンスのバージョンは doc.okkez.net と同じ全てのバージョンでよいと考えています。
> 1.8.0や1.8.1といった過去のバージョンを提供しないほうがよい理由は何かありますでしょうか。それによっては、最新のリリースバージョンのみにします。

ruby-lang.org では過去のバージョンを提供しない方が良い理由は、Ruby の過去のバージョンは
開発終了しているからです。
リファレンスのトップにそのことを明示しておけばいいかもしれませんが、ruby-lang.org でリファレンス
が提供されているから(公式に)サポートされていると勘違いする人がそれなりに出そうな気がします。

あとは、サーバマシンの負荷の問題ですね。用意されているマシンのスペックを知らないので杞憂かも
しれませんが、るりまの提供のみで数百MBもメモリを使ってしまっていいのかとかは考えてしまいます。

-- 
okkez
okkez000@g...