社内でtracを使っています。

普段、UIのぱっと見の綺麗さをほとんど評価対象にしないのですが、正直、このUIはいかがなものか、と思うUIです。唯一、tracで評価しているのが、SQLを直接書けるTracReport機能です。もっとも、以下のマニュアルページ(http://trac.edgewall.org/wiki/TracReports)を見ると、次のように書いてあります。

Note: The report module is being phased out in its current form because it seriously limits the ability of the Trac team to make adjustments to the underlying database schema. We believe that the query module is a good replacement that provides more flexibility and better usability.

要は、SQL直書きのTracReport機能は推奨しない、ということです。作り手側の意見として、SQL直書き機能が足かせになるのは理解しますが、query module(GUIでプルダウンメニューを選ぶUI)の方がflexibleという主張は納得できません。

TracReportを除けば、tracはbugzillaの出来損ない、という印象でした(RDBのテーブル設計も似ています)。

しかし、WebAdmin(http://trac.edgewall.org/wiki/WebAdmin)がプラグイン、という事実を知って見方が変わりました。他の人が色々セットアップした後からしか見ていないので、この辺の事情を知りませんでした。一見、基本機能のように見える部分までプラグインとなると、tracは侮れません。知らずに、見た目だけで軽率な評価を下していたことを反省しました。

最近、trac以外に、外部ユーザの作った機能に、大胆に画面を侵蝕させるシステムをいくつか見ました。SalesforceのAPEXとfacebookです。tracを含めて3つに共通するのが、画面が結構しょぼいことです。主観的評価ですが、画面にリッチ感がありません。しかし、それゆえにか、外部ユーザの作った(UIに凝っていない)機能が画面に侵蝕しても、あまり違和感がありません。結果、外部ユーザの参入障壁が下がる、外部アプリが増える、という好循環が起きている気がします。周りのUIがリッチすぎると、こうは行きません。さしずめ、Web UI版、悪い方が良いの法則を見た気がします。

推奨しないと書いてありますが、それでもTracReportは便利です。subversionのコミットログもRDBに入っているので、subversionの統計処理にも使えます。プロジェクトマネージャーみたいなことをしていると、この手の統計情報が欲しくなります。過去、bugzillaやmantisでは、バイト学生にPerlやPHPで統計処理を行うプログラムを書いてもらっていました。tracであれば、SQLを書くだけです。

以下にsqliteがバックエンドの時のTracReportのSQLを書くtipsを書きました。

• http://dev.ariel-networks.com/column/tech/tracreport-tips/