2008年12月10日水曜日

gemspec.infoのβ2リリース

gemspec.infoに機能追加しました。

バージョンアップ内容β1→β2

  • 各gemの最新バージョンを対象にRDocを生成しておき、gemspec.info上から表示可能とした。これにより、ユーザは事前にRDocを使ってgem内容を確認できる。ただし、gemからRDocを生成する処理は半手動であり、RDocを生成できないgemも多数存在するため、全てのgemでRDocを表示できるわけではない。テンプレートは Allisonを使っているので標準よりキレイかも。
  • RDoc生成機能に合わせ、クラスダイアグラムも生成しておき、gemspec.info上から表示可能とした。ただし、これもうまく生成できないモノが多数。RDocより数は少ない。
  • これらに関連し、現在のシステム上のデータ量統計を表示した。総gem数、総version数、総spec数(なんでversion数より多いんだ?w)、保持している総RDoc数、保持している総クラスダイアグラム数、最終RDoc更新日時を表示した。
  • トップページの新着gemの表示内容を変更。どうせ新しいモノには付加情報は無いのだから、gem名と概要だけ表示する様にし、興味を引くようにした。
  • HostingRails.com を使ってるんですが、同じHostingRails.com内の別データセンターに引っ越ししました。こちらの方が日本からの回線も、サーバ内のピーク時負荷も軽いので結果として良かったかも。

GitHubサポートの問題点

GitHubのgemリポジトリサポートについては、まだ悩んでます。

末端ユーザとしては最新の機能で最も安定しているバージョンのgemを使いたいはずなんですが、分散バージョン管理であるが故に共通の親を持つ同系列のgemが多数存在し、結局どれを使うべきか判断できないのです。

中央集権的なRubyForgeであれば最新バージョンを追うだけなんですが、GitHubの場合、スクレイピング無しには親子関係さえ判断できない。というかそもそも、Rubygemを使わず直接GitHubにログインしてどれを使うか検討するときでさえも、同系列のgemの内、誰のgemを使うべきか悩ましいですよね。

結局、Subversionのような中央サーバ型でも、Gitの様な分散サーバ型でも、一つのプロジェクトを継続していくためには全体の流れを統括して本流を維持していくコミッタが必要と言うことなんでしょうね。

全文検索機能の問題点

もう一つ付けたい機能が全文検索機能で、これが無いとgemspec.infoは実用にならないと思ってるくらい重要な機能なんだけど、これはacts_as_searchable(エンジンはHyperEstraier)を使おうと思ってるんですが、このHyperEstraierがちょっとくせ者です。

というのは、HyperEstraier自体は国産なので日本語に対する検索性能や日本語の資料がしっかりしてて機能的にも性能的にも良いところが一杯なんですが、どうも作者は既に興味を失っているらしく、メンテされている気配がない+コミュニティも盛り上がってない。(MLを見ている限りでは)

gemspec.infoへの全文検索実装だけ考えればあまり問題ではないんだけど、どうせ使い方をマスターするなら次のサービスや仕事でも使いたいし、それなら将来性があるエンジンを採用したいですよね。

Wikipediaで調べる限りは、機能的にはぶっちぎりで優秀(使いやすい)なので、メンテナさえ居ればしばらく安泰って感じなんだけどねぇ。分かち書き+N-gramのハイブリットって他では無いので。

で、次のタスク

話は逸れましたが、個人的にはandroid に興味が移ってきており、プライベートな時間帯にRubyを触る時間は減りつつあるので、gemspec.infoのコードも、さくっとオープンソースとして公開すべきなんでしょうね。GitHubあたりに載っけちゃいましょうか。


0 件のコメント: