# braindump いつかどこかにちゃんとした形でまとめるかもしれない、今はただの脳内のダンプにすぎない情報群。 死蔵しておくよりマシなのでとりあえず仮の場所と割り切って吐き出していく場所。 ごみの分別にご協力いただき、ありがとうございます。 —— braindump の壁の張り紙 # 人生管理用 Redmine のノウハウと課題 ### チケットのステータス #### 「フィードバック」はおそらく Needs Feedback の意 デフォルトで用意されているチケットのステータスに「フィードバック (Feedback)」というものがある。これだけだと何のことだか曖昧だが、 [Feature #12827: New Ticket status "Needs Feedback" - Redmine (<https://www.redmine.org/issues/12827>)](https://www.redmine.org/issues/12827) ("Status added." としてクローズされている) を参照するに、もともとは「フィードバック待ち」を示すステータスとして用意されている。 つまり、個人的なものであって他人のフィードバックを必要としないような用法においては、「フィードバック」ステータスは利用しないのが標準的である。 また、私の環境では「フィードバック待ち」にリネームした。 #### チケットの終了の分類は？ デフォルトで用意されているステータスにおいて、チケットを Closed にするものは「終了 (Closed)」と「却下 (Rejected)」の2種類がある。しかし実のところ、 “終了” したタスクの種類や状態というのは見かけよりも複雑なものである。生活や趣味の自由なタスクの文脈においては特にそうだ。 「直近でこれ以上進む予定がない」状態を考えてみても、以下のように多くある。 - チケットが (起票時点ではなく作業開始判断の時点において) 不適につき、作業なしで終了。 - いわゆる「却下 (Rejected)」に相当する。 - 作業を開始するかどうかの検討という、ある意味でメタな事前作業は実施されている (こともある)。 - 作業の結果、当初の目的を達成して終了。期待したとおりかそれ以上の成果が得られた。 - 狭義の「終了 (Closed)」に相当する。 - 「目標達成」と表現しても良い。 - 作業の結果、当初の目的を部分的に達成して終了。成果は部分的。 - できるところまでやったが、途中で諦めることにした場合。 - 「部分的達成」とか「途中離脱」などと呼べる。 - 作業の結果、目的を達成できず諦めることにした。成果はほぼない。 - 「ギブアップ」と表現しても良い。 - 「部分的達成」との違いは、残せる成果があるかどうか。 - 作業中に状況が変化して、チケットが不適になったため中止。 - 「状況が変わったので放棄」などと表現するのが良いだろうか。 たとえばアニメシリーズを追跡する場合、以下のようになる。 - \[a\] 却下: 気になっていたが、結局観ないことにした。 - \[b\] 目標達成: 全話観た。 - \[c\] 途中離脱 (1): 放送休止や途中での制作中止で全話制作されないことになったが、公開されているエピソードは全て観た。 - \[d\] 途中離脱 (2): 途中までしか観ていないが、プラットフォーム制限等の状況の変化で未視聴のエピソードを観ることが困難になった。 - \[e\] 状況が変わった (1: 中止): つまらなかったので、途中で観るのをやめた。 - \[f\] 状況が変わった (2: 不発): 観ようとしていたが、視聴開始前に配信停止や公開取り下げ、プラットフォーム制限等で視聴不可能あるいは困難になった。 (プラットフォーム制限とは、たとえば転居によって転居先の国からの配信サービスへのアクセスができなくなったり、アカウントがロックされたり、あるいはアカウントを作るつもりのないサービスでの限定配信になったりなどである。)
項目 当初の目標は達成？ 遂行可能な作業が残っている？ 当初の目標の達成は原理的に可能？ 成果あり？ 着手済？ 自発的な中断？ 再開できるならする？
a (観るのやめ) no yes yes no no yes no
b (全部観た) yes no N/A yes yes N/A N/A
c (制作中止) no no no yes yes no yes
d (自己都合で視聴困難) no no yes yes yes no yes
e (つまらないのでやめ) no yes yes yes yes yes no
f (観ようとしたが遅かった) no no no no no noyes
この表のようにいろいろな性質で属性を考えることができるが、当然これら属性には従属関係のあるものもある。たとえば目標を達成したら残りの作業について考える必要はないとか、未着手であれば自明に成果はないとか、成功したら自明に成果はあるとかである。つまり、これら全ての組み合わせについて名前を与えて分類を試みるのはあまり賢い手ではなく、必要なものだけ選び取るか、あるいはいくつかの少数のグループに分類してしまうべきである。 また、アニメシリーズを例に考えると「成果あり？」と「着手済？」は同値に見えるが、一般的にはそうではない。たとえばプログラムの実装を試みて作業をしたが実用的な成果物やサンプルが出てこなかったなどの場合には、「着手したが成果はない」という分類になるだろう。 また「遂行可能な作業があるか」というのも曖昧な属性である。たとえば「今月は50冊の本を読む」という目標でチケットを立てて48冊読んだところでクローズするとして、このクローズはどう分類されるだろうか。「今月」これ以上できることはないという点では遂行可能な作業は残っていないが、あと2冊読めば50冊という目標を達成できるという点では「あと2冊読む」という遂行可能な作業が残っている。ハードデッドラインとソフトデッドラインの区別をつければ良いかもしれないが、そもそも「今月50冊」などというふんわりした目標でハードデッドラインを使う意味がわからないし、かといってソフトデッドラインにすると「今月」とわざわざ締切を設定した意味を自分から弱めてしまうことになり、「急いで50冊読む」で良いではないかということにもなりかねない。 ### その他 #### 翻訳 ##### ブロック チケットの関係に、日本語だと「ブロック元」と「ブロック先」という選択肢がある。日本語ではどちらがどちらなのかわからないが、英語だと "blocks" と "blocked by" である。こうなるとわかりやすく、 "(This ticket) blocks A" と "(This ticket) (is) blocked by A" で迷うことはまずないだろう。一方日本語では「ブロック元 A」は「A は (このチケットの) ブロック元」、「ブロック先 A」は「A は (このチケットの) ブロック先」となっており、英語と主語・目的語が逆転しているうえ「(このチケットの) ブロック先」はブロック動作の主体が「このチケット」になっており、翻訳との比較で見ても日本語訳の中で見ても、文の構造が安定していない。 [redmine\_message\_customize (<https://github.com/farend/redmine\_message\_customize>)](https://github.com/farend/redmine_message_customize "farend/redmine_message_customize: This is a plugin for Redmine.") プラグインを使うと、メッセージカタログを独自設定でオーバーライドできる。私の環境では、以下のようにして「blocks」を「次のチケットをブロック」に、「blocked by」を「次のチケットがブロック」に置き換えた。テキストは長くなってしまうが、曖昧で操作に迷うよりはずっとマシである。 ```yaml --- ja: label_blocks: 次のチケットをブロック label_blocked_by: 次のチケットがブロック ``` # Portal のメモ ### 設定ファイル ##### autoexec.cfg ``` bind "MWHEELUP" "+jump" bind "MWHEELDOWN" "+jump" bind "MOUSE3" "+jump" ``` ホイールを回すことでジャンプできるようにする。 ABH (Accelerated Back Hopping) で重宝する。 ##### config.cfg ``` bind "t" "save sla ; load sla" bind "q" "save quick" bind "r" "load quick" ``` クイックセーブは言うまでもなく便利。 即時セーブ&ロードは SLA (Save Load Abuse) で使う。レギュレーション次第では使えないので、そのときは誤爆しないよう無効化した方が良い。 ### コマンド - `cl\_showpos 1`: Shows current name, position, angle and velocity - `ent\_bbox <objectname>`: Shows an axis aligned bounding box around the target - `cl\_ent\_bbox`: Shows the bounding box around !picker