チケットとカスタムクエリの日付表示フォーマットを変える
TracLightningの0.12対応も進みつつありますが0.11系の話題です。
先日のOSC2010/Tokyoで尋ねられたことなのですが、Trac のチケットやカスタムクエリで表示される登録日や更新日は今ひとつ優しくありません。
チケットの登録/更新日 | |
チケットのコメント | |
カスタムクエリ |
何ヶ月前とか何分前とか表示されても、ちっとも嬉しくありません。
マウスカーソルをリンクに当てると年月日の表示も見られますが、極めて直感的ではないと言えます。
そこでTracのテンプレートを修正して、直感的な日時の表示にしちゃいましょう。
手を入れる対象のテンプレートは2つで、TracLightning2.5.xの場合は、
%TRAC_LIGHT_HOME%python\Lib\site-packages\Trac-0.11.7.ja1-py2.5.egg\trac\ticket\templates以下に
ticket.html
query_results.html
がありますので、コピーしてから修正します。*1
改修箇所も内容も多くないので、diff使うよりも手で直したほうが早いかもしれませんが、面倒だからといって直接手を入れるとバージョンアップなどで私のように苦労することになるので注意しましょう(笑)
--- ticket/templates/ticket.html +++ mod/ticket.html @@ -146,8 +146,8 @@ <div id="ticket" py:if="ticket.exists or preview_mode" class="${preview_mode and 'ticketdraft' or None}"> <div class="date"> - <p py:if="ticket.exists">登録: ${dateinfo(ticket.time_created)} 前</p> <!--! FIXME: message_contains_tag --> - <p py:if="ticket.time_changed != ticket.time_created">最終更新: ${dateinfo(ticket.time_changed)} 前</p> <!--! FIXME: message_contains_tag --> + <p py:if="ticket.exists">登録: ${format_datetime(ticket.time_created)}(${dateinfo(ticket.time_created)}前)</p> <!--! FIXME: message_contains_tag --> + <p py:if="ticket.time_changed != ticket.time_created">最終更新: ${format_datetime(ticket.time_changed)} (${dateinfo(ticket.time_changed)}前)</p> <!--! FIXME: message_contains_tag --> <p py:if="not ticket.exists"><i>${_('(ticket not yet created)')}</i></p> </div> <!--! use a placeholder if it's a new ticket --> @@ -240,7 +240,7 @@ </span> <!--! FIXME: message_contains_tag --> - 更新者: ${authorinfo(change.author)} (${dateinfo(change.date)} 前) + 更新者: ${authorinfo(change.author)} ${format_datetime(change.date)} (${dateinfo(change.date)} 前) </h3> <div py:if="'cnum' in change and can_append" class="inlinebuttons"> <input type="hidden" name="replyto" value="${change.cnum}" />
--- ticket/templates/query_results.html +++ mod/query_results.html @@ -62,7 +62,7 @@ <td py:when="name == 'id'" class="id"><a href="$result.href" title="${_('View ticket')}" class="${classes(closed=result.status == 'closed')}">#$result.id</a></td> <td py:otherwise="" class="$name" py:choose=""> <a py:when="name == 'summary'" href="$result.href" title="${_('View ticket')}">$value</a> - <py:when test="isinstance(value, datetime)">${dateinfo(value)}</py:when> + <py:when test="isinstance(value, datetime)">${format_date(value)} (${dateinfo(value)})</py:when> <py:when test="name == 'reporter'">${authorinfo(value)}</py:when> <py:when test="name == 'cc'">${format_emails(ticket_context, value)}</py:when> <py:when test="name == 'owner' and value">${authorinfo(value)}</py:when> @@ -79,7 +79,7 @@ <td colspan="${len(headers)}"> <!--! FIXME: message_contains_tag --> <p class="meta">${_('Reported by')} <strong>${authorinfo(result.reporter)}</strong>, - ${dateinfo(result.time)}前.</p> + ${format_date(result.time)} (${dateinfo(result.time)}前.)</p> </td> </tr> <py:choose>
修正したテンプレートは、
- プロジェクトのテンプレートフォルダに入れる。
- 利用しているTracの全体のテンプレートフォルダを作って、そこへ入れる。
の、どちらかで対処しましょう。
プロジェクト個別で対応したければ前者、Trac全体に適用したいなら後者になると思います。
修正したテンプレートの移動が終わったらTracを再起動しましょう。
するとほら、日付が人に優しい形で表示されます。
チケットの登録/更新日 | |
チケットのコメント | |
カスタムクエリ |
以上、ちょっとしたことですが気にする人は気にするので普及のために手を入れてみるのも悪くないと思います。
*1:違うバージョン等の場合は適宜読み替えるか、探し出してください。
Shibuya.trac#7 開催終了
Tanabata.TarcTracことShibuya.trac#7が無事終了しました。
参加者の皆さん、登壇者の皆さん、スタッフの皆さん、Ust経由の視聴者の皆さん、お疲れ様でした。
平日開催の3回目、前回に引き続きビアバッシュ形式で開催でしたが、申込み延べ人数が69人、最終参加者が57名というShibuya.trac始まって以来の参加者数で、しかもドタキャンが2名しか居ないという驚くべき結果でした。
2007年8月31日のいがぴょんTracOff(通称 第0回)から3年、Shibuya.trac第1回から数えても2年半が経過しましたが、開発者の「プロジェクトを良くしたい」「幸せに開発がしたい」という想いの表れなのかもしれませんね。
当時は完全に裏方業に徹してたので、ピザの手配やらお金の確認*1、追加のビールの買い出しなどをしていたので*2、殆どの発表は通して見れてません(笑)
でも今回もUst担当 [twitter:@Nekotank] が頑張ってくれたので、週末にでもゆっくり録画されたモノを見たいと思います。*3
今回は発表はせずに、おわりの挨拶担当でした。
ど〜でも良い資料なので公開しない予定だったのですが
と褒められた(?)ので公開します。
最近は写真多めのプレゼンテーションZen風味な資料が多かったりしてたのですが、今回は本来の芸風である「高橋メソッド」に戻しました。
ちなみにTypoは狙っている分けでは無く、30分程度で見返さず作った結果生まれたものです orz
それと毎回*4「ふんどし」が出てくるので不思議に思っている人が多いとは思います。
きっかけとなったLT資料はShibuya.tracのwikiにあったのですがxul形式で気軽に見られないので、ppt→pdfにしてスライドシェアへアップしました。
ネタ系LTなのに164枚というふざけた枚数なので、時間に余裕があるときにでも見てやって下さい。
たとえ話
三角ベースを近所の空き地や公園で毎日のようにやっている人達がいました。
彼らは野球(三角ベース)が今ひとつ面白くないと感じていました。
どうしようかと考えた末に、野球をより面白くするために他のスポーツの要素を
採り入れることを思いつきました。
やったことは無いけど似ているスポーツにクリケットがあるのは知っていたので、
クリケットを参考に野球を改善することにしたのです。
ウィキペディアやblogでクリケットについて調べてクリケットの特徴である
- 打者は全方位どこに向かって打ってもよい。
- 後ろにある棒(ウィケット)に投球が当たると打者アウト。
- 三振はなしで、ウィケットに球が当たれば打者アウト。
- アウトにならなければ、三振が無いので何球でも打者は打てる。
を採り入れれば面白くなるに違いないと確信し、
もしかすると野球に革命が起きるかもしれないとまで思った人が出るぐらいでした。
・・・
さて彼らの野球(三角ベース)は、その後どうなったでしょう?
野球を超えるスポーツを作ることは出来たのでしょうか?
MS Agile Day 3でLTしてきました
マイクロソフトのTech Fielders セミナー Agile Day 3でLTしてきました。
Shibuya.tracでは何度か話してますが、比較的堅い(?)場所で話すのは初めてで、しかもアジャイルについて話すのも初めてでした。
結果から言うと・・・聴衆受けは良くなかったなぁというのが正直な感想。
一般の人が話すLTで聴衆が期待するのは経験談なのですが、そこをあえて『再考』なんてやったので当然の結果なんですけどね。*1
なんでそんなLTをというと・・・
社内でアジャイルな一歩を踏み出すときに簡潔に纏まった資料が意外と少ないので、社内勉強会に向けに作った資料*2を基に5分のLTに再構成し、これからアジャイルを理解して貰おうとしている人達に再利用して貰えればという想いからでした。
誰の役に立つかは不明ですが使えそうだなぁと思った人は、ppt形式置いておきますのでご活用いただければと思います。
ライセンスはクリエティブコモンズの"表示−非営利ー継承"でお願い致します。
TracLightningに追加している10+2のプラグイン
今、ウチの環境で使っているTracは、独自環境から一年半前にTracLightning 2.1をベースにして構築後、プラグインをちょこちょこ追加しながら使ってますが、随分長い間更新してません。
そんななか気が付けばベースにしているTracLightningは2.5.1が6月1日にリリースされ、随分と環境が進んでいます。(こちら)
停滞しているとdisられ気味のTracも0.12が登場目前でなので、Trac 0.11系列であるTracLightningの2系も2.5が恐らく最後のリリースになるのではないでしょうか。
というわけで、現在利用しているウチで利用している2.1+αなTracの環境を2.5.1へ移行するべく、独自で入れているプラグインを洗い出してみました。*1
結果は追加が10個、変更(修正)が2個。
以下はその結果と各プラグインの解説です。(だいたいアルファベット順)
TracLightningに追加しているプラグイン
名称 | 備考 |
---|---|
ChangDeateRecordPlugin | QueryChartで使う日付のリセットするプラグイン。 全体ではなく特定のチケットのみに対してだけ実行できるので、日付調整等で更新したくないチケットがある場合などに非常に重宝します。*2 |
DoxygenPlugin | Doxygenで生成したドキュメントをTracに統合するプラグイン。 一部のプロジェクトでDoxyGenを使っているのですが、保守フェーズに入りTracをポータルと利用する際にシームレスな参照が出来るので若干癖のあるプラグインですが便利です。 |
EnquetePlugin | アンケートが実施できるプラグイン。 半お遊び的なプラグインではありますが、Tracしか自由になるサーバが無い場合には重宝します。 プロジェクトでの呑み会アンケートなんかに使ったりしてます。 |
FineGainedPageAuthzEditorPlugin | FineGrainedPermissionsで使うAuthzの情報をTracの管理画面から編集する為のプラグイン。 そのままだと改行コード等に不具合が出るので、Trac Hacksのチケットにあったパッチを当てて利用しています。 まぁFineGrainedPermissions自体をあまり使っているという話を聞きませんが・・・・*3 |
FlashEmbedMacro | FlashをWikiに貼り付けるwikiマクロ。 パワーポイントの資料は添付でも良いのですが、見せる(魅せる)ということを考えるとSlideShareのような形が便利。そんな願いを実現させるプラグインです。 TracのWikiにパワーポイントをFlashに変換して、このマクロで表示させてますが意外と好評。あとあまり使いませんが同じwikiマクロでYouTubeの動画なんかもWiki上に表示できます。 |
FootNoteMacro | 脚注のマクロ。 0.10の日本語環境では使えなかったので諦めていたのですが、0.11では問題が無く動作しているようなので最近使い始めました。 |
FormAutoSavePlugin | 書きかけのフォームを保存してくれるプラグイン。 うっかりブラウザを閉じたり、戻るボタンを押して書きかけのチケットが全消失といった事態を防いでくれます。 対応しているフォームはwiki/ticket/reportの各編集画面。 |
httpauthplugin | xmlrpcでの認証周りの不具合を解消するプラグイン。*4 |
ReportIncludeplugin | TracReportを元にグラフ表示してくれるプラグイン。 QueryChartの方が手軽にチャート表示できますが、複雑なレポートを元にチャートを表示したいときに便利です。*5 |
WikiLinkMakerPlugin | Wikiやリポジトリのリンクをツリーから選択して挿入できるプラグイン。 wiki/Ticketの編集画面で簡単に既存wikiやリポジトリへのリンクが書くのが容易になります。 |
TracLightningに入ってるけどバージョン違い、もしくは手を入れているもの
名称 | 備考 |
---|---|
TicketClone | チケットを複製するマクロ。 TracLightningにも2.5から同梱になってますが、マクロに手を入れて使ってます。 というのもTimingAndEstimationを使っている場合に単純にチケットを複製してしまうと、実績時間まで複製されてしまい困った状態になるので実績時間は複製しないようにしてます。 またTrac_Adminが無いと複製出来ないのは意外と不便なので、Ticket_Create権限を持つユーザにも複製を可能にしています。 |
TimingAndEstimationPlugin-Permissions | TimingAndEstimationの権限管理を強化版。 TimingAndEstimationがTracLightningに入っているのは私がリクエストしたからなのですが、実は同梱のものを現在では使ってなくて、チケットに関する権限が拡張されたこちらのバージョンを使ってます。 権限を厳しくしたいというのが理由ではなく、TimingAndEstimationを有効にした際に邪魔だと言われているTracReportに表示されるTimingAndEstimationで利用するレポートがPermissionsの場合には表示されないからというのが理由。 |
コミットコメントを意地でも書かせたい
コミットコメントを意地でも書かせたいと思うことがあります。
でも意外と書いてもらえなかったりします。
酷い場合だと
バグ修正
とか
対応した
だけ書いてあったりします。
注意するのも疲れるし、大抵の場合は注意しても直りません。
そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。
単にエラーだと障碍だと騒ぐ人達が居るので、コメントの重要性をエラーメッセージで語りかけるようにもしてたりします(笑)
以下はTracLightning環境下で動作する(はず)のScriptです。*1
キーワードの定期的な見直しは必要ですが、コメントを書かないとコミットできなくなるので意識付けを行うのには有用だと思います。コミットコメントが書いてもらえないと悩んでいる方は試してみては如何でしょうか。
#結構やっつけなScriptなので、突っ込みや質問は大歓迎です(笑)
用意するもの
- コミット前に実行するhooks Script(pre-commit.bat)
- Subversionのリポジトリのhooksに置いてください。
- 環境変数 %LENGTH% を設定することで、入力を強制するバイト数を指定します。
- 文字数としてカウントしないキーワード一覧(pre-commit-filter.sed)
- NGワード一覧(pre-commit-filter_sp.sed)
- %TRAC_BAT_ROOT%以下に置く
- 規定バイト数には足りてるが、半定型化していて逃げ道的なコメントを登録しておく
pre-commit.bat
:: PRE-COMMIT HOOK :: [1] REPOS-PATH (the path to this repository) :: [2] TXN-NAME (the name of the txn about to be committed) SET REPOS=%1 SET TXN=%2 SET SVNLOOK=D:\TracLight\CollabNetSVN\svnlook.exe SET TRAC_BAT_ROOT=C:\TracLight\bin Set LENGTH=10 %SVNLOOK% log -t "%TXN%" "%REPOS%"|python.exe -c "import sys,string;print(string.replace(sys.stdin.read(),'\n',''));"|CALL %TRAC_BAT_ROOT%\sed -f %TRAC_BAT_ROOT%\pre-commit-filter.sed>%REPOS%\hooks\%TXN%.TXT for %%F in ("%REPOS%\hooks\%TXN%.TXT") do if %%~zF LEQ %LENGTH% goto _NOCOMMIT %SVNLOOK% log -t "%TXN%" "%REPOS%"|%TRAC_BAT_ROOT%\sed -f %TRAC_BAT_ROOT%\pre-commit-filter_sp.sed>%REPOS%\hooks\%TXN%.TXT for %%F in ("%REPOS%\hooks\%TXN%.TXT") do if %%~zF GTR 0 goto _NOCOMMIT :OK del "%REPOS%\hooks\%TXN%.TXT" exit 0 :_NOCOMMIT del "%REPOS%\hooks\%TXN%.TXT" echo ---------------------------------------------------------------->&2 echo 最低でも何故変更したのかのを、>&2 echo 未来の自分と保守担当者に向かって書きましょう。>&2 echo.>&2 echo コミットログは未来の自分へのメッセージです。>&2 echo 今は不要に思っても、未来にはきっと役に立ちます。>&2 echo.>&2 echo (有効なメッセージを %LENGTH%byte 以上)>&2 EXIT/B 1
pre-commit-filter.sed
y/[0123456789/]/[0123456789\/]/ y/[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz]/[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz]/ y/[ABCDEFGHIJKLMNOPQRSTUVWXYZ]/[abcdefghijklmnopqrstuvwxyz]/ s/[0-9]{2,4}\/[0-9]{1,2}\/[0-9]{1,2}//g s/[0-9]{2,4}年[0-9]{1,2}月[0-9]{1,2}日//g s/^[0-9]{1,2}\/[0-9]{1,2}//g s/ //g s/ //g s/\-\-*/\-/g s/\.\.*/\./g s/\(.\)\1\1*/\1/g s/^新規//g s/新規作成//g s/\(\#[0-9]{1,4}\) \(([0-9]{1,2}\.[0-9])\)/\1/g s/\(\#[0-9]{1,4}\) \(([0-9]{1,2})\)/\1/g s/ソースの修正を行いました//g s/単体テスト実施 //g s/ソースあげます//g s/メッセージ変更//g s/対応しました//g s/ソース手直ししました//g s/内容を修正しました//g s/とりあえず現状をコミット//g s/バグ対応バージョン//g s/バグ対応//g s/バグ//g s/バージョン変更//g s/ブランチ切り//g s/やりなおし//g s/とりあえず//g s/ソース手直し//g s/手直し//g s/共通ソース//g s/履歴シート//g s/あいうえお//g s/不具合の// s/不具合を// s/不具合//g s/一部訂正//g s/コミットします//g s/コミット//g s/コメント//g s/仕様変更につき//g s/仕様変更//g s/公開//g s/訂正しました//g s/訂正します//g s/訂正した//g s/訂正のため//g s/修正しました//g s/修正します//g s/修正した//g s/修正のため//g s/修正の//g s/修正//g s/変更した//g s/変更します//g s/変更しました//g s/変更//g s/追加しました//g s/追加します//g s/追加した//g s/追加//g s/更新しました//g s/更新します//g s/更新した//g s/更新//g s/削除しました//g s/削除します//g s/削除した//g s/削除//g s/作成しました//g s/作成します//g s/作成した//g s/作成//g s/移動しました//g s/移動した//g s/移動//g s/依頼//g s/改修しました//g s/改修した//g s/の改修分//g s/改修分//g s/の改修//g s/改修//g s/緊急//g s/管理//g s/割愛//g s/完了しました//g s/完了した//g s/完了//g s/反映しました//g s/反映します//g s/反映した//g s/反映//g s/訂正しました//g s/訂正します//g s/訂正した//g s/訂正//g s/実装中です//g s/実装中//g s/実装//g s/直しました//g s/直した//g s/実装中です//g s/実装中//g s/処理//g s/恐縮です//g s/いろいろ//g s/をついき//g s/をついか//g s/色々//g s/リクエストを//g s/リクエスト//g s/^仕様書//g s/^仕様//g s/^概要//g s/の為//g s/update//g s/transition//g s/todo//g s/^refs//g s/^ref//g s/^fixed//g s/^fix//g s/⇒//g s/→//g s/←//g s/↑//g s/↓//g s/。//g s/・//g s/.//g s/?//g s/!//g s/☆//g s/★//g s/◆//g s/○//g s/●//g s/△//g s/▲//g s/▽//g s/▼//g s/◎//g s/『//g s/』//g s/【//g s/】//g s/\n//g
pre-commit-filter_sp.sed
/コメント書くの面倒/p d
マイルストーンのプログレスバーをカスタマイズする
前回からずいぶんと時間が経ちましたつづきです。(激しく申し訳ない)
前回は永遠とQueryChartの説明をしましたが皆さん試してみましたか?
チケットに手を入れる必要があるので躊躇ってやっていない人も多いと思います。
さて今回はチケットに手を入れなくても出来る、マイルストーンのプログレスバーをカスタマイズについてです。
プログレスバーをカスタマイズ
Tracのマイルストーンビューは結構悲しくて、デフォルトでは「解決済み」と「未解決」を二色で塗り分けて表示しているだけです。
0.11からワークフローのカスタマイズも可能になり、色々な状況を設定可能になりましたがTracのwiki(TracIni#milestone-groups-section)に書かれている内容はイマイチ良く分かりません。
ワークフローも0.10とは違い、acceptとassignが明確に分けて管理されるようにもなりました。
ならばマイルストーンのプログレスバーも、acceptとassignを色分けして出ると少し幸せになれるはず。
本来ならば、まずはcssの修正を行うのですが、Trac Lightningの2.4.2にはThemeプラグインが入っているので、管理コンソールのTheme Customize: Advanacedの部分に
table.progress td.red { background: #ffcccc } table.progress td.blue { background: #99ccff } table.progress td.orange { background: #ffcc99 } table.progress td.violet { background: #cc99ff }
を追加します。
そしてtrac.iniをメモ帳以外で開いて以下のセクションを追加します。
[milestone-groups] accepted = accepted accepted.css_class = red accepted.label = 作業中 accepted.order = 2 closed = closed closed.label = 完了 closed.order = 1 closed.overall_completion = true closed.query_args = group=resolution new = new new.css_class = open new.label = 未着手 new.order = 4 assigned = assigned,reopened assigned.css_class = blue assigned.label = 割当済 assigned.order = 3
これでプログレスバーはこんな感じに表示されるようになったはずです。
完成形
前回のQueryChartの表示をマイルストーンビューで設定すると・・・
おぉ〜!進捗が何となく可視化された気がします。
同様に右側に表示されるxx別チケットのステータスのプログレスバーも同じ色づけをされるので非常に状況を把握しやすくなるはずです。
地味で何に使うか難しかったマイルストーン画面もこれで進捗確認用として使えそうです。
次回予告
さて次回は前回のQueryChartと今回のプログレスバーを使って、更に作業の進捗を確認しやすいようにワークフローの修正サンプルについて書きたいと思います。
補足
一部訂正・訂正有り
Themeプラグインが入っていないTracLightningや素のTrac場合には直接Trac本体のcssに手を入れます。ると全てのプロジェクトに反映するので楽です。
Trac Lightningの2.4系の場合 %TracLightning%\\python\Lib\site-packages\Trac-0.11.5.ja1-py2.5.egg\trac\htdocs\cssにある roadmap.css を修正ます。*1
21行目付近からプログレスバー関連の設定があるので以下を追記します。
table.progress td.red { background: #ffcccc } table.progress td.blue { background: #99ccff } table.progress td.orange { background: #ffcc99 } table.progress td.violet { background: #cc99ff } <|| これでThemeプラグインで指定したのと同じ状態になります。 <span style="color:#FF0000;"><追加></span> プロジェクト毎にcssをカスタマイズしたい場合には、site.htmlを用意して対処しましょう。