ditzのreadmeを読む(後半)
後半部分です。力尽きた。
DITZのデータモデル
デフォルトの設定で、Ditzはオープンソース開発のために必要な最低限の機能セットを含んでいます。
経過時間、優先度、開発者へのタスクの割当、期日等の機能は意図的にプラグインシステムに任せるようにしています。
Ditzのプロジェクトは、issues, releases, componentsの３つで構成されています。
- Issues:
issuesはBTSの基本的な要素です。Ditzのissueは機能(feature), バグ(bug), タスク(task)のいずれかです。 しかし、現在の所、このissueの種類は、表示以外には影響しません。
それぞれのissuesは、1つのコンポーネントに属しており、0個か1個のリリースの一部になっています。
それぞれのissuesは、データエクスポートに使えるランダムな40桁の16進数のIDを持っています。
IDは、一意である事が保証されています。IDは通常ユーザーは目にする事はありません。
issueは人が読める形式の名前を持っています。でもその名前は一意でないしデータエクスポートにも使えません。 全てのditzコマンドはissue IDの他にも、issueの名前を使えます。
issue名は特定の状況で変更される事が有ります。例えば、”ditz drop”コマンドの後に変更されます。
issue名は、コメント、タイトル、内容等の中に書く事が出来ます。ditzはissue名が変更された時に自動的にそれらを書き換えます。
- Components:
プロジェクトには常に総称的なcomponentが一つあります。そのcomponentの名前はプロジェクト名と同じになってます。
最も単純な場合は、componentはこの総称的なcomponentが唯一の物になります。そして、ユーザーがcomponentにissueを割り当てる問題に煩わされることはありません。
componentは単純にissuesを整理する為の方法です。実際には何の機能も有りません。
issues名は、割当てられるcomponent名から派生して名付けられます。
- Releases:
releaseはissueの為の主要なグルーピング機構です。
“ditz status”や”ditz todo”のような状態確認コマンドは常に、releaseによってグルーピングされたissuesに作用します。
releaseが100%完了した時に、そのreleaseはリリースされたとマークを付ける事が出来ます。 そして、そのreleaseに属していたissueは停止したと”ditz status”や”ditz todo”のメッセージに表示されます。
もっと知りたい時は
- helpを見るか
$ ditz help
- ソースコードを見てください
$ find $DITZ_INSTALL_DIR -type f | xargs cat
必要条件
- trollop >= 1.8.2, if running via RubyGems.
ライセンス
Copyright (c) 2008 William Morgan.
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
ditzのreadmeを読む(前半)
正直言って、helpだけではよくわからないので、google先生にお願いしてREADME.txtを翻訳してもらう。 おかしな所はほんのり修正。
まずは前半部分だけ。
説明
Ditzはシンプルで軽量な分散型バグトラッカーです。 git, darcs, Mercurial, Bazaarのような分散型バージョン管理システムで動作するように設計されています。
また、SVNのような集中型システムで使用することができます。
DitzはYAML形式のファイルを使用して、ディスク上に問題データベースディレクトリを維持/作成します。 このディレクトリは、プロジェクトのソースコードと一緒にバージョン管理下におく事が出来ます。
Ditzは問題データベースファイルを作成/更新するためのシンプルなコマンドラインベースのインターフェイスを持っています。 また、ブラウザで現状を確認出来るように、静的HTMLの生成機能を持っています。(デモはDitzページを参照してください）
Ditzにはモデルフィールドにコマンドを追加し、出力を変更する堅牢なプラグインシステムが含まれています。 バンドルされているプラグインのマニュアルについてはPLUGINS.txtを参照してください。
現状ではDitzは、集中型システム用のバグ申請を行う方法を持っていません。
使い方
Ditzを使用するには、いくつかの異なる方法があります。
- ソースコードと同じ場所に問題データベースを設置する。issueはコミットの一部として含まれています。他の開発者からの変更による競合は、通常の方法で解決しマージします。
- ソースコードとは別のブランチに問題データベースを設置する。issueの更新をVCSによって管理することができますが、コードに直接結びつけられてはいません。
- VCSで問題データベースを管理しない。
これらのオプションはすべてサポートされています。どの方法を選択するかは、あなたのワークフローに依存します。
- オプション＃1
- おそらく非同期分散開発に最も適しています。個々の開発者が面倒を最小限に抑えて問題の状態を変更することができます。
- オプション＃2
- issueの追加/更新とコードの変更は、それぞれ独立してVCSにコミット出来ます。同期開発に最も適しています。(git同期プラグインを参照してください)
- オプション＃3
- 集中型Webインターフェイスと同様に、いくつかの他の配布方式でのみ有用です。
コマンドライン要約
プロジェクトをセットアップして、bugs.yamlファイルを作る
- ditz init
- ditz add-release
issueの追加
- ditz add
現状確認
- ditz status
- ditz todo (or simply “ditz”)
お仕事をする
- コードを書く
- ditz close <issue-id>
- コミットする
- 3に戻る
ひと仕事終ったら
- ditz release <release-name>
ditzコマンド補完
ditzのMLを読んでいると、ditzコマンド補完のbashスクリプトが有るらしい事が判った。
しかしインストール場所が判らなかったので、findすると以下の場所にインストールされていた。
$ find / -name "ditz*"
.
.
.
/Library/Ruby/Gems/1.8/cache/ditz-0.5.gem
/Library/Ruby/Gems/1.8/doc/ditz-0.5
/Library/Ruby/Gems/1.8/doc/ditz-0.5/rdoc/files/lib/ditz_rb.html
/Library/Ruby/Gems/1.8/gems/ditz-0.5
/Library/Ruby/Gems/1.8/gems/ditz-0.5/bin/ditz
/Library/Ruby/Gems/1.8/gems/ditz-0.5/contrib/completion/ditz.bash
/Library/Ruby/Gems/1.8/gems/ditz-0.5/lib/ditz.rb
/Library/Ruby/Gems/1.8/gems/ditz-0.5/man/ditz.1
/Library/Ruby/Gems/1.8/specifications/ditz-0.5.gemspec
.
.
.
この中の”ditz.bash”が補完スクリプトなので、”~/.bash_profile”に
source /Library/Ruby/Gems/1.8/gems/ditz-0.5/contrib/completion/ditz.bash
を追加すると補完が効くようになる。正直ditzは補完が無いと使いにくい。
特定のドットファイルがあるフォルダーを選択するには
はじめに
コマンドラインツールには、ファイル名の先頭に”.”がついたファイルを作成する物がある。所謂ドットファイルだ。
このドットファイルは、Finder上では不可視ファイルになっていて通常は見る事は出来ない。
Cocoaでこのファイルを選択するには、通常
- [NSOpenPanel setShowsHiddenFiles:(BOOL)flag];
にYESを渡して使用する。
しかしこの方法では、全ての不可視ファイルが Open Panel に表示されてしまう。不可視ファイルは想像以上に多いので、ユーザーは混乱するだろう。
こんな画面は誰も見たくないでしょう？
解決策として、
- 混乱を避ける為に不可視ファイルは表示させない
- 特定のドットファイルが存在するフォルダーだけを読込み可能にする
以上の２点を満たす方法を考えてみた。
開発環境
開発環境は以下の通りです
| MacOSX: | 10.8.2 |
|---|---|
| XCode: | 4.5.2 |
基本方針
NSOpnePanelのdelegateを使う。
- [NSOpenSavePanelDelegate panel:(id)sender didChangeToDirectoryURL:(NSURL *)url];
このdelegatメソッドは、OpenPaneで注目中のディレクトリが変更される毎に呼出される。 呼出された時に、ディレクトリを走査し、目的のドットファイルが有るか確認する。
目的のドットファイルが存在した場合だけ
- [NSOpenPanel setCanChooseDirectories:(BOOL)flag];
にYESに設定してフォルダーを読込み可能にする。
実装
OpenPanelを表示してドットファイル”.ditz-config”が存在するフォルダーを読込み可能にするコードを示す。 ここで、”.ditz-config”はditzの設定ファイル名なので、各自の目的に合わせて変更してください。
- (IBAction)openPanel:(id)sender;
{
NSOpenPanel* theOpenPanel = [NSOpenPanel openPanel];
[theOpenPanel setAllowsMultipleSelection:NO];
[theOpenPanel setCanChooseFiles:NO];
[theOpenPanel setDelegate:self];
[theOpenPanel beginWithCompletionHandler:^(NSInteger result)
{
if (result == NSFileHandlingPanelOKButton)
{
NSURL* thePath = [[theOpenPanel URLs] objectAtIndex:0];
NSLog(@" thePath: %@\n", thePath);
}
}
];
}
- (void)panel:(id)inSender didChangeToDirectoryURL:(NSURL *)inURL
{
NSOpenPanel* theOpenPanel = inSender;
NSFileManager* theFileManager = [NSFileManager defaultManager];
NSString* theFilePath = [inURL path];
NSArray* theFileLists;
BOOL theFlag;
theFileLists = [theFileManager contentsOfDirectoryAtPath:theFilePath
error:nil];
theFlag = [theFileLists containsObject:@".ditz-config"];
[theOpenPanel setCanChooseDirectories:theFlag];
}
実装はコレだけです。