[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
ラベル Trac の投稿を表示しています。 すべての投稿を表示
ラベル Trac の投稿を表示しています。 すべての投稿を表示

2010-11-10

我流ながら Doing List を二年間試して得た Tips 集

2008 年 3 月、ブログ Lifehacking.jp にて「Doing List」なるライフハックが紹介された。

この記事を読んでから、約 2 年間我流ながら Doing List をつけ続けた (途中、Doing List をお休みしていた時期あり)。本エントリーでは、2 年かけて蓄積した「我流 Doing List」の Tips をまとめる。

Original Doing List

Doing List。日本語に訳すと「今、何をしているのかリスト」。このライフハックの衝撃は、元の記事が一番良く伝えている。少し長いが引用してみる:

その作業にはまったく無駄がなく、黄色いリーガルパッドに書かれたリストの一番上から一つずつ確実に作業を行っていきます。時折指を止め、考え込んだかと思うと、すぐに作業を再開するのでした。

面白かったのは次の一瞬でした。12年前の記憶を呼び起こしながらファイルを探していると、探していたのとは別のファイルのディレクトリを発見したのです。

彼はちょっと顔を曇らせると「こんなところにあったのか…」とつぶやき、「でも今やっていることから離れるのはいやだな」と言ってリーガルパッドの方に、ディレクトリの情報をささっとリストの最後に付け加え、それまでやっていた作業を続行したのでした。

ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト | Lifehacking.jp より引用

よく「作業は直列化しよう」と聞く。並行作業をやっているやうに見えても、実際の作業は直列で行なえるよう準備しておく、次にやることが分かっているので効率が上がる、と紹介されたりもする。

Doing List は正に作業を直列化するツールと言える。

Doing List の具体的な書き方は、エントリー「今、そこにある未来:脳内バイパスを作る Doing リストの実践例」に詳しい。このエントリーを書いた筆者は 3 つのポイントを挙げているので、引用する:

  1. 「今やっていること」がアンカーされていて、かならずリストから行動が生じている。リストに書かれていない事はしてはならない。
  2. 途中で割り込みが生じた。タスクの前提条件をクリアできていないので別タスクを行なう必要が生じた。単に達成不能だった。この3つの場合は、割り込みタスクか「次になにをするか」をリストに加えて次に進む。止まらない、次に進み続ける。
  3. リストの下までいったら、残っているのは割り込みタスクと、次のアジェンダのみですので、それを元にして次の Doing リストを作って上からこなしてゆく

オリジナルの記事ではリストを作るために「情報カード」を使って、「今やってること」と「いつでもできること」をタスク分けしたりしている。

我流 Doing List

オリジナルの Doing List では、「リストの下まで行ったら、残存タスクから新しい Doing List」を作るようだが、ぼくは一日に一つのリストだけで作業を行なった。

まず、一日の始めに今日やることを書き出す。サンプルとして 11/9 の Doing List をお見せする。ただし本来は仕事の中で使っていたけれど、それを見せるのは会社員的にやばいので、「日常」を例に作った Doing List で我慢して頂きたい。

My Doing List 11/9

(クリックすると、もっと大きな写真が見られます)

これは 11/9 のお昼の時点での Doing List。

  1. タスクを書き出す
  2. 上からタスクを実行
  3. すぐに出来ないタスクは飛ばして次のタスクへ
  4. 途中で「新タスク」が発生したら、リストの一番下に追記する
  5. リストの最後まで到達したら、リストの最初に戻って、同じ作業を繰り返す

タスクが順不同になりがちだけど、一応リストをひとなめすると、全部のタスクが終了するのであまり気にしない。

11/9 終了時点、もしくは 11/10 の朝の時点での Doing List は次のやうになった。

Doing List 11/9 (END)

いくつか未遂タスクが残ってる。これは 10/9 日中に終わらなかったということ。

10/10 日は、まず 10/9 の Doing List を参考にしながら 10/10 の Doing List を作成していく。

Doing List 11/10

この時、タスクの順序入れ替えなども行なう。未遂タスクのうち 10/10 の Doing List に移したものには、10/9 の Doing List にその印を残しておく。ここでは「緑」のチェックを入れている。我流では「緑」のチェックは「延期」を表す。

前日の Doing List と、その日のスケジュール等から 10/10 の Doing List が完成する。

あとは、昨日と同じく上からタスクをこなしていく。新規タスクはリストの末尾に追加。リストの最後まで行ったら、もう一度リストの最初に戻ってやり直し。やることは毎日変わらない。

我流 Doing List Tips

日付を入れる

Doing List の頁端に「日付」を入れる。

後で Doing List を見直すとき、日付けが入っていないと凄く不便。必ず入れるようにしたい。

サンプルでは、手書きで日付を書き入れているけど、会社では日付スタンプを使って日付を入力していた。スタンプを使うと、日付が奇麗に入る。そして、何よりスタンプする瞬間が楽しくてしょうがない。ここは是非、日付スタンプを使って欲しい。下の日付スタンプは一例。

【Shiny/シャイニー】Mini Dater/ミニ・データー S-300

B002Z6VXXU
Shiny
Amazonで詳しく見る
by G-Tools

ちなみに、Doing List のために日付スタンプを使うと、自然と毎日日付スタンプの日付が、その日の日付になる。いざ日付スタンプを捺してみたら、前回使った時の日付だった、という失敗は誰にでもあると思う。Doing List に日付スタンプを常用していると、そのミスがなくなる。ちょっとしたメリット。

方眼紙を使う

方眼紙タイプのノートを使う。目的は、最初の三コマを正確に空けること。

  • ノートの四コマ目からタスクを書き始める
  • ノートの二コマ目に「タスク終了」のチェックを入れる

一コマ目と三コマ目の使い方は関連タスクの節で説明する。それと方眼紙を使う利点はサブタスクの節でも紹介する。

ノートは方眼紙なら何でも良いけれど、ぼくは Moleskine の Squared Notebook を愛用している。

Moleskine Squared Notebook Large モレスキン 「伝説のノート」活用術~記録・発想・個性を刺激する75の使い方

罫線の色が濃すぎず薄すぎず、見えやすく邪魔にならないのが良い。また、裏写りしにくいのもポイント。ちょっとした会議メモを糊で貼り付けても、次のページにあまり影響を与えないのも良い。紙質が良いからかな? あと、ノートにポケットが付いているのも便利。ぼくは名刺を数枚入れている。急な会議で社外の人と名刺交換することになった時用の保険 (何回に一回は名刺入れを忘れてしまうから...)。もちろん、メモ書きや薄手の資料を入れておくのにも使える。

ノートとしては高価だけど価値ある一冊だと思う。頑丈で、使っていてカッコイイのも好き。一冊使い終えるたびに、宝物が一つ増えた気分になる。

4 色ボールペンを活用する

本文は黒色で書く。残りの色はチェック欄 (二コマ目) で活用する:

  • : タスクが終了した
  • : タスクを延期する (もしくは延期した)
  • : タスクを行なわない (もしくは不要になった)・タスクに失敗した

正常終了したタスクには「青」チェックを付けていく。

タスクが延期になった場合は「緑」チェックを付ける。例えば、今日予定されていた会議が明日に延期された場合には「緑」チェックを入れ、「緑字」で「会議は明日に延期」等のコメントを入れておく。また、「前日の Doing List を見て今日の Doing List を作る」という話をしたが、その時に付けるチェックもこの「緑」チェックを使う。後で見返した時、「このタスクはこの日のうちに終わらなかったのだ」と明示する。

タスクを行なう必要がなくなった場合は「赤」チェックを付ける。11/9 の例だと、「昼寝」というタスクは結局行なわないことにしたので「赤」チェックが入っている。また、「GNU Arch のアーカイブを探す」というタスクにおいて、まず「PC 内を探し」、見つからなかったら「CD-R 内を探す」ようリストを組んだ。ところが PC 内にアーカイブが見つかったので、CD-R 内を探すタスクは不要になった。そこで「CD-R 内を探す」というタスクには「赤」チェックを入れ、タスクに赤線で打ち消し線を入れた。打ち消し線を入れるかどうかは、気分次第。大低は「赤」チェックだけで済ませている。

それから失敗したタスクについても「赤」チェックを付けるようにしている。ぼくの場合、「○○を探す」なんてタスクは失敗してしまうことが多い。

この他、タスクに対してコメントを付ける時は「緑」色で文字を書くようにしている。「CD-R 内を探す」タスクを再び例に出すと、このタスクに「赤」チェックを入れた後、「緑字」で「PC 内を探す」のタスクの後ろに「見つけた」と一言コメントを入れて「CD-R 内を探す」タスクに矢印を伸ばした。これで、CD-R 内を探さないで済んだ理由が明確になる。

基本、コメントは「緑」で書くけれど、危険度の高いもの、注意を引きたいもの、失敗したタスクなどには「赤」でコメントすることもある。一例。「コンパイルする」というタスクに対して「エラーが出た」と赤字でコメントした。また「緑」字で書いたコメントが間違っていた場合も、赤字で緑字コメントに打ち消し線を書いて追加コメントした。

ボールペンについてはLamy 2000 (左) を愛用している。定価一万円するが Amazon なら半額ほどで買える。現実的な価格で考えるなら トンボの Reporter 4 (右) がお勧め。税抜き 350 円。

LAMY マルチボールペン ラミー2000 L401 (色:クロ 材質:レジン樹脂 )

略記号を作る

毎日同じやうなタスクを書いていると、時間が惜しい。自作の略記号を作っておくと便利。作った略記号はノートの 1 ページ目に記号と説明を書いておく。

参考に、ぼくが使ってる略記号を紹介する。

S: スケジュールの略。一日は常にこの記号から始まる。

M: メール・チェックの略。あくまで流し読みする程度。じっくり読む必要があるメールには「M: ○○の件」という風に新タスクを作る。また返事が必要なメールも「M: □□さんに返事」とする。誰かにメールを書く場合も「M: 青木さん、○○の件」と書く。メールを書く場合は宛先も書いとくと便利。

例)

M: ○○の連絡事項
M: 青木さん、○○のバグ

Re: メールの返事を書くことを明示的に示したい時に使った。M との使い分けはケース・バイ・ケース。

C: Chat の略。メールを書く場合と同じく、相手と用件を書いておくと便利。チャットは「誰かと短い時間話す」ケースと「IM 等を使ってチャットする」ケースの二種類あるけれど、特に二つを使い分けていない。チャット・タスクに達した時に、相手が話せそうなら相手の席まで行くし、IM で済ませられる程度のことなら IM で終わらせてしまう。

例)

C: 伊藤さん ○○の会議の準備
C: 内田さん 体調

R: Read の略。仕様書や回覧された文書・資料を読む作業。

例)

R: ○○の仕様書
R: wiki for ○○

MTG: Meeting の略。略記号の前に「開始--終了」時間を書いておくと見やすい。時間は 24 時間表記で。時間と分の間のコロンを取っ払ってしまうと更に楽。

例)

1000-1100 MTG 全体会議
1400-1600 MTG コード・レビュー at 小会議室 4

T: Ticket の略。チケット駆動型開発をしている人向け。登録しなきゃいけないチケットを見つけた時に使う。

例)

T: ○○を△△するとエラーになる
T: ○○の機能を実装する

#123: 同じくチケット駆動型開発をしている人向け。# に続けてチケット番号を振る。チケット番号だけだと、後で見返した時に何のタスクなのか分からなくなるので、チケットの概略も続けて書くこと。

例)

#123: ○○を△△するとエラーになる
#256: ○○の機能を実装する

こんなところかな。

英語を使う

ぼくはこの Tips を 1/3 位いの割合でしか使っていない。それでも、英語でタスクを書き上げる利点を説きたい。その一番の理由は、Doing List が見易くなること。

次の二つの例を比べて欲しい。まず、日本語を使う場合

江川さんに電話
小川さんの書類を読む
○○の資料を読む
△△書類を書く
週報を書く

一方、英語を使った場合

Call 江川
Read 小川 paper
Read ○○
Write △△
Write weekly report

英語の方が動詞が揃うので、タスクのカテゴリー分けが見分けやすい。別に全部英語で書く必要はなくて、「江川」さんは「江川」さんのまんまでいい。ここで「Egawa」なんてすると、同音の人がいる場合に混乱のもとになるしね。要は英語の語順にすると見易くなるということ。

よく使う「動詞」は略記号に昇格させてあげるといい。

サブタスクはインデントする

一つのタスクが大きな場合は、タスクを分割しておくといい。つまりサブタスクの作成。サブタスクは、親タスクに対して 1 コマ分インデントすると見易い。サブタスクを全部終了したら、親タスクも終了チェックを入れる。

例)

洗濯
 洗濯機
 干す
 取り込む
 畳む
 片付ける

サブタスクを作るということは、仕事に取りかかる前に自分のやることを予めプランニングすることを意味する。いわゆる PDCA も回しやすくなる。いろんなアイデアを出しておいて、ダメなら「赤」チェックを入れて別のタスクに取りかかればいい。こっちをやって、あっちをやって、あれ頭の中がこんがらがったということがなくなる。つまり、自然と仕事が直列的に行なえるやうになってくる。オススメ。

なお、タスクの下に既に別のタスクが書かれていて、サブタスクを書くスペースがないこともある。こういう時は、そのタスクに「緑」(延期) チェックを入れて、同じタスクを Doing List の一番下に改めて書いた。

最初の数行は空けておく

ぼくは最初の 3〜5 行は空けて、小日記をつけるようにしていた。書くことは体調から、予定、文句等色々。

例)

体調悪くて、20:45 退社
携帯電話を探して 1.5 時間無駄にした
○○さん、明日から夏休み
Apple Fall 2010 Event のため徹夜
△△さんの歓迎会 19:00〜
今週、初めてふとんで寝た

とりとめもないことを書いている。でも、後で読み返すと、その時の調子とか雰囲気とか、Doing List だけじゃ伝わらないことが思い出せるので重宝している。

時計を描く

会議が多い日は、アナログ時計を描いて埋まっている時間を塗り潰す。自分の残り時間が「見える化」できて良い。写真は 11/9 の例。会議ではないけれど、どこに隙間時間があるのか把握できる。

Doing List - Analogue Clock

ノートを方眼紙にしているメリットがここにも現れている。4x4 = 16 コマ使うと比較的綺麗にアナログ時計が描ける。

1 日 1 ページ

Doing List に半ページしか使わなかったとしても、空スペースは捨てて次のページに移ること。そうすると、ページの頭に「日付」が出るので、後で見返す時に目的の日を探し易い。

仕事が良く進むと、1 日 1 ページで足りないことがある。そういう場合は素直に 2 ページ目を使う。仮に 2 ページ目に突入して、2〜3 行しかタスクを書かなかったとしても、翌日の Doing List はその次のページに書くこと。

仕事量が多い人は、毎日 2 ページ使うかもしれない。そして仕事の少ない日に 1 ページ分しか Doing List を書かないことが起きる。そういうケースは、1 ページ真っ白にしても毎日 2 ページのペースを守る方が、後で見易い。

仕事量が変動し易く、1 日 1 ページと 2 ページの日が同じ位いな人は... 毎日 2 ページ使うより、その日のタスク量に合わせれば良いかな。

関連タスクをつなげる方法

Doing List を書いていると、関連するタスクを作ることがある。よくあるのが、大きなタスクをサブタスクに分割したけれど、分割しきれていなかったケース。事前タスクや確認用タスクを後で思いつくことがある。

ここで、方眼紙の 1 コマ目と 3 コマ目を使う。

1 コマ目は関連タスクの親を表す記号 (a. など)。3 コマ目は親タスクに関連するタスク。例えばこんな風になる:

a.  ○○をする
    △△について調べる
    ◇◇のテスト・コードを書く
    コーディングする
   別のタスク その 1
   ‖
   別のタスク その X
  a. パフォーマンス・チェックをする
緊急な割り込みがあった場合は?

オリジナルの Doing List を実践していたのは大学教授ということもあり、自分の時間をかなり自由に使える。でも、仕事によっては「緊急」タスクが割り込む場合もあるでせう。肝を冷やすのが、サーバー管理者にとっての「Samba が動かない」「Apache が落ちてる」「Subversion にアクセスできない」系のクレーム。これは自分の仕事を止めてすぐにでも対処しないといけない。

こういう時は、無理に Doing List を守らない。まず、今までやっていたタスクを中断し、Doing List の一番下に新タスクを追加する。問題が難しそうならサブタスクを作る。そして、タスクに取りかかる。タスクを無事終了したら、元のタスクに戻って作業を再開する。

失敗談

2 年間やっていて失敗もある。2 つ紹介しやう。

タスク終了時に「チェック」マークではなく「終了時間」を書いていた時期があった。前のタスクから引き算をすれば、そのタスクに費した時間が分かるという寸法。このやり方には 3 つ問題があった。1 つ目はタスク終了のたびに、「時間」を調べなきゃいけないこと。スムーズさに欠けた。2 つ目は終了時間が曖昧もしくは不明なタスクの扱いに困ったこと。3 つ目は、Doing List のタスクは「必ず」上から順に「終了」するとは限らないこと。「緊急」タスクが入ることもあるし、重いタスクなので後回しにすることもある。そんな中でタスクの実行時間を計算するのは大変。シンプルにチェック・マークを入れるだけに留めた。

Doing List で仕事の流れをより良くするためにと、「このタスクはあのタスクの前にやる」という風な矢印を引いたことがあった。デジタルなら簡単に出来ることだけど、ノートだとこれが大変。余計に混乱を招いた。そんなことをしなくても、Doing List を上から普通になめるだけで十分だと分かったので、この「矢印」はやめた。同時に、デジタル・ツールで Doing List を作る必要も少ないな、と感じた。

あとがき

Doing List は、「今やっていること」を明確にし、仕事の効率を上げるツール。でも、それだけがメリットじゃない。後で見返せば、素晴らしい作業ログが出来上がっている。

また Doing List がアナログ・ツール (ノートに書くだけ) ということも強調したい。まず、ディスプレーを少しも専有しない。机の上に開いておけばいい (机の上でページが開くというのも Moleskine の良い所)。図が描けるのも良いし、必要ならメモを貼り付けることもできる。会議に持っていっても電源切れになることはない。紙は省電力を上回る 0 電力製品だから!!

といっても、デジタル・ツールを全否定するわけじゃない。長期的な視点においては、デジタル・ツールで GTD したり Gantt Chart を作る方が良い。チケット駆動開発においても、Trac や Redmine を活用することをおすすめする。Doing List は GTD やチケットから「自分の手元」に降りてきたタスクを「自分でマネージメント」する道具だと思う。

2009-09-07

入門 Trac 第二版

「入門 Trac 第二版」を手に入れて、サラッと読んだ。

入門Trac第2版―Linux/Windows対応

ページ数は 20 ページ増えた (327 から 347 ページへ) 。この 20 ページというのがクセモノで、ちゃんとしたレビューにしづらい。初版を持ってる人が第二版も必要かと言われると、フム。

というわけで、第二版で気に入った点を列挙してレビューに代える (これをテヌキといふ)。

  • Trac 0.12 の説明が入った。国際化、trac-admin の強化、複数リポジトリー対応がメインか? 複数リポジトリー対応は嬉しいなぁ。ちょっと説明が少なかったのが痛いぞ。
  • Git 対応。Trac の SCM に Git を対応させる Git Plugin の紹介。昔は、この情報がなくて苦労したんだよねぇ。感謝。
  • CGI で動作高速化。静的ファイルを trac.cgi を経由せずに読び出す方法の解説。ネットでは有名 (?) だけど、ちゃんと本に入ったのは良い。試す人がきっと増えるはず。
  • 「タスクトレイからチケット登録」「Perl から Trac を操る」。2 ページにも満たない小ネタ。マニアック! 大好き。

ref

2009-08-27

「入門 Trac」第二版が出る

Trac の解説書として好評を博した (?) 「入門 Trac」の第二版が出る。

入門Trac 第2版―Linux/Windows対応

出版社は秀和システム。サイズは A5 版で、ページ数は 368 ページ。著者は高山恭介氏。発売日は 2009-08-26。

第二版

初版の発売は去年の 5 月。約一年振りの改訂となる。

ぼくも初版を買って、Trac の勉強をした。少し悩んだけど第二版も予約済み。

第二版の目玉は、リリース間近のバージョン 0.12 の解説 (初版はバージョン 0.11 の解説だった)。それと、個人的な興味だけど「Subversion 以外の SCM」の項目に git があること。高山さんに伺ったところ、「GitPlugin の解説をサラリとしただけ」との話で、Git の commit log を Trac の ticket comment に自動反映させる方法には踏み込んでいないらしい。まあ、それでも Trac を Git で使いたいという人は多いと思うので、楽しみ。

2009-08-20

Trac の Wiki を Redmine の Wiki (Textile) に変換するスクリプト

Trac の Wiki を、Redmine の Wiki に変換するスクリプトを書いてみた。Redmine の Wiki 書式は Textile に Redmine 独自のリンク書式を追加したもの。

Trac_wiki_to_textile

ソースコードは GitHub で公開している。

このコードは、seven1m 氏と hchoroomi 氏の trac_wiki_to_github を参考にして作った。両氏には感謝。

使い方

  1. trac.db を convert.rb スクリプトと同じディレクトリーに置く
  2. convert.rb スクリプトのあるディレクトリーに、「wiki」という名前のサブ・ディレクトリーを作る
  3. convert.rb スクリプトを実行する
    $ ./convert.rb
    
  4. Textile の書式に変換された Wiki が、wiki ディレクトリーに出力されるので、手で Redmine の Wiki にコピペする

trac.db は $trac_project/db/trac.db にある。

convert.rb スクリプトは sqlite3 を内部で呼び出している。libdb-sqlite3-ruby パッケージを入れてなかったら、事前にインストールしませう。

$ sudo apt-get install libdb-sqlite3-ruby

あとがき

ちなみに、Trac から Redmine へ移行するためのツールは既に存在している。

ただ、このツールはチケットからマイルストーンまで全て移行してしまうらしい。今回ぼくは、Trac で作っていた Wiki だけ (それも一部のページだけ) Redmine 側に移行したかった。そこで、他人のスクリプトに手を入れて、trac_wiki_to_textile を作ってみたわけ。

2009-06-27

Wiki の Trac 書式を Redmine (Textile) 書式に変換するスクリプト

Trac の Wiki を Redmine の Wiki に移行するための Ruby スクリプトを書いた。Redmine の Wiki は、Textile に少し手を加えたものなので、Trac Wiki を Textile 書式に変換するスクリプトと言ってもいい。

ソースコードは github で公開している。

ダウンロードには git を使う:

git clone git://github.com/ataka/trac_wiki_to_textile.git 

使い方

  1. Trac の trac.db ファイルを convert.rb の入ってるディレクトリーにコピー
  2. convert.rb の入ってるディレクトリーに wiki という名前のディレクトリーを作る
  3. convert.rb コマンドを実行する

trac.db は Trac のデータの入ってるファイル。Trac プロジェクト直下の db ディレクトリー下にある。

Foo プロジェクトが /var/trac/foo にある場合の作業は次のやうになる。

$ git clone git://github.com/ataka/trac_wiki_to_textile.git 
$ cd trac_wiki_to_textile
$ cp /var/trac/foo/db/trac.db ./
$ mkdir wiki
$ ./convert.rb

convert.rb は中で sqlite3 パッケージを呼び出している。Ubuntu 使いの人は、次のコマンドで sqlite3 パッケージをインストールできる。

$ sudo apt-get install libsqlite3-ruby

謝辞

trac_wiki_to_textile は、hchoroomi 氏の trac_wiki_to_github を fork して作った。 そして彼のスクリプトは、seven1m 氏のスクリプトを元にしている。両氏のスクリプトがなかったら、trac_wiki_to_textile を作る気にはならなかったと思う。感謝。

2009-03-31

Redmine 本を注文した

「入門 Redmine」を Amazon で注文しちゃった。

Redmine は Ruby on Rails で書かれたバグ管理システム (Bug Tracking System / Issue Tracking System)。同種のソフトウェアに Trac がある。

今まで、ぼくは Trac を使っていたのだけど、Trac は複数リポジトリーに対応していない。バージョン管理システムに Subversion を使ってるうちはまだ良かったのだけど、最近 git (というか repo) に手を出すやうになって、どうにも Trac ではプロジェクト管理が出来なくなって来た。Redmine は複数リポジトリーにも対応しているし、Git も OK という話を聞いたので注文した次第。といふわけで、このブログにも Redmine ネタが多くなるかもしれない。

入門Redmine Linux/Windows対応

2009-03-12

Git の commit log を Trac の ticket comment に自動反映させる方法

Trac の SCM に Subversion を使ってる人の多くは、Subversion のコミット・ログを Trac のチケット・コメントに自動反映させる hook を利用していることと思う。

入門Trac with Subversion―Linux/Windows対応

これを、Git でも使えるようにしてみた。

Git Plugin

まず Trac で Git を使うようにするには、GitPlugin for Trac をインストールする必要がある。ここら辺のウェブ・ページを参考にしてインストールされたし。

git-post-receive-hook の入手

Git 用の hook スクリプトを github で公開している。まずは、そちらで最新版を入手されたし。

$ git clone git://github.com/ataka/trac-git-post-receive-hook.git

一応、(2009-03-11 現在の) ソース・コードのコピーも置いておく。

#!/bin/sh

# The original script is available at
#   http://trac-hacks.org/browser/timingandestimationplugin/branches/trac0.11/scripts/git-post-receive
#

#
# An example hook script for the post-receive event
#
# This script is run after receive-pack has accepted a pack and the
# repository has been updated.  It is passed arguments in through stdin
# in the form
#  <oldrev> <newrev> <refname>
# For example:
#  aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
#
# see contrib/hooks/ for an sample, or uncomment the next line (on debian)
#

TRAC_ENV="/var/trac/YOURPROJECT"
POST_COMMIT="/usr/local/src/Trac-0.11.1.ja1/contrib/trac-post-commit-hook"
LOG="/dev/null"
echo "in git post commit: $TRAC_ENV" | cat >>$LOG

while read oval nval ref ; do
    if expr "$oval" : '0*$' >/dev/null
    then
        git-rev-list --reverse "$nval"
    else
        git-rev-list --reverse "$nval" "^$oval"
    fi | while read com ; do
        echo "posting a comment to trac" | cat >>$LOG
        echo "  *** $com"
        AUTHOR="$(git-rev-list -n 1 $com --pretty=format:%an | sed '1d')" \
        MSG="$(git-rev-list -n 1 $com --pretty=medium | sed '1,3d;s:^   ::')"
        echo "author ... $AUTHOR"
        echo "msg ... $MSG"
        sleep 0.1
        sudo -u www-data $POST_COMMIT \
            -p "$TRAC_ENV" \
            -r "$com" \
            -u "$AUTHOR" \
            -m "$MSG" \
        echo "DONE posting a comment to trac" | cat >>$LOG
    done
done

echo "Done with trac commit hook: $TRAC_ENV" | cat >>$LOG
exit 0

設定

git-post-receive-hook を手に入れたら、それをリモートの git リポジトリーの hook ディレクトリーに入れてやる。ここでは、リモート・リポジトリーが /git/foo.git にあるとして話を進めませう。

$ chmod +x git-post-receive-hook
$ cp -p git-post-receive-hook /git/foo.git/hooks

次に、git-post-receive-hook で Trac の設定を行なう。具体的には、TRAC_ENV に trac project への path を、POST_COMMIT に trac-post-commit-hook への path を指定する。例えば、Trac Project を /trac/foo に置いていて、Trac を Ubuntu のパッケージからインストールしている場合は、次のように編集する。

TRAC_ENV="/trac/foo"
POST_COMMIT="/usr/local/src/Trac-0.11.1.ja1/contrib/trac-post-commit-hook"

最後に、/git/foo.git/hooks/post-receive.sample を post-receive に名前を変更して、git-post-receive-hook を呼び出すようにする。

$ cd /git/foo.git/hooks
$ cat post-receive.sample
#!/bin/sh

/git/foo.git/hooks/git-post-receive-hook
$ mv post-receive.sample post-receive

post-commit じゃなくて、post-receive を使うことに注意。

設定は以上で終了。あとは、Subversion と同じやうにログが書くだけ。ローカル・リポジトリーからリモート・リポジトリーに git-push したタイミングで、Trac のチケットにログが反映されるようになる。

2008-05-19

Trac Lightning をインストールした

Windows 用の Trac 一括インストール・ソフト「Trac Lightning (旧称「Trac 月」)」を利用してみた。自分用メモとしてインストール手順を残しとく。

ダウンロード

ここら辺のページを参考に、最新版をダウンロード。

インストール

ダウンロードした TracLight-x.x.exe をダブル・クリック。あとは、ウィザードに従うだけ。でインストール完了。

使ってみる

※もしかしたら、インストール直後に再起動が必要かもしれない。

以下の URL にアクセス。

すると、Trac の解説ページが現れる。Trac のプロジェクトを見るには、次の URL にアクセス。

外のマシンから、上記ページにアクセスする場合は localhost を「ホスト名」に変える。