clmemo@aka

何度言っても忘れてしまうチケット起票者に対して、確認画面を出すことになった。使っているチケット管理システムは Redmine。Redmine はデフォールトで JQuery をロードしているので、いきなりソースコードに JQuery のコードを書くことができる。

編集するのは /var/redmine/app/views/issues/new.html.erb。ページの末尾に次のコードを突っ込む。

<script>
$(function(){
  $('#issue-form').submit(function(e) {
    if (!confirm('確認用文言')) {
      e.preventDefault();
      $('#issue-form').removeAttr('data-submitted');
      return false;
    }
  });
});
</script>

これで、「作成」ボタンを押すと「確認用文言」がポップアップして OK を押すとチケットが作成され、キャンセルを押すともう一度説明文を編集することができるようになる。

「確認用文言」は状況に応じて変わると思うけど、「再現手順は書きましたか?」とか「不具合画面のスクリーンショットは貼りましたか?」等々、入力されなくて困ってることを書いておけば良いと思う。if 文以下をコピペすれば、複数個の確認画面を表示できる。

一日に数本チケットを作るかどうかという環境において有効。あんまりやりすぎると、自分がチケットを作る時ストレスになるのでご注意を。

• ref. clmemo@aka: JQuery を初めて触ってみた

Redmine はローカル・マシンにあるリポジトリーしか参照できない。なので、Redmine 用のサーバーとリポジトリー用のサーバーを分けて運用している場合、チケットとコミット・ログを紐付けることができない。

これは不便なので、公開リポジトリーに commit したら Redmine サーバーにデータを転送するようにした。

なお、掲題の通り今回は git リポジトリーを扱う。

設定

Redmine を動かしているサーバーを server_redmine と呼ぶ。

Git の公開リポジトリーを置いているサーバーを server_git と呼ぶ。リポジトリーは /var/git/sample.git にあるとする。

ssh ログインの準備

server_git から server_redmine へ ssh ログインできる様に設定をしておく。

• clmemo@aka: SSH の公開鍵暗号方式によるログイン認証

server_git で上 ssh 鍵を作り、server_redmine へ公開鍵をコピーする。

server_git ~$ ssk-keygen -t rsa
server_git ~$ ls .ssh/
id_rsa id_rsa.pub
server_git ~$ scp .ssh/id_rsa.pub server_redmine:~/
server_git ~$ ssh server_redmine
server_redmine ~$ mkdir .ssh
server_redmine ~$ chmod 700 .ssh
server_redmine ~$ touch .ssh/authorized_keys
server_redmine ~$ chmod 600 .ssh/authorized_keys
server_redmine ~$ cat id_rsa.pub >> .ssh/authorized_keys
server_redmine ~$ rm id_rsa.pub
server_redmine ~$ exit

以上で設定は終了。ssh ログインできれば成功。

server_git ~$ ssh server_redmine
server_redmine ~$ hostname
server_redmine

git repository のコピー

まずは、server_redmine に server_git の git リポジトリーを clone する。

server_redmine ~$ cd /var/git/
server_redmine /var/git$ git clone --mirror ssh:server_git:/var/git/example.git

• ref. gitのbareリポジトリのバックアップをとる - 馬鹿と天才は紙一重

--bare と --mirror の違いがいま一つ分かっていないけれども、--mirror の方が今回の用途に合っていそう。

なお、この作業には server_redmine から server_git へ ssh ログインできることが前提になっている。もし出来ない場合は、上の server_git から server_redmine へ ssh ログインする設定をもう一度、逆方向にして欲しい。

ここまでで、server_git にある最新の git リポジトリーを server_redmine に持って来れた。けれど、今のままでは server_git のリポジトリーにコミットされた内容が server_redmine 側に反映されない。

hooks/update の利用

たいていのバージョン・コントロールには hook という機能がある。コミット直前に何かするとか、コミット直後に何かするとか、そういう機能。

git にも hook 機能があるので、それを使う。今回使うのは post-update フック。

• see also. clmemo@aka: Git で集中リポジトリーに push したら、自動でワーク・ディレクトリーにも反映させる

post-update は、全てのコミットが公開リポジトリーに push された後に実行されるフック。server_git 内の /var/git/example.git/hooks/post-update を編集する。中身は次の通り:

#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".

# exec git update-server-info
ssh -t -t server_redmine <<EOF
 cd /var/git/example.git
 git fetch --all
 exit
EOF

server_redmine に ssh ログインして、git fetch している。git の公開リポジトリーから redmine 側のリポジトリーに push できれば話は簡単なのだけど、「公開リポジトリー (--bare 付きで作ったリポジトリー)」からは git push できない制約がある。仕方がないので、server_redmine 側に移って git fetch している。

ファイルを作ったら、実行権限を付けるのを忘れずに。

server_git ~$ chmod +x /var/git/example.git/hooks/post-update

あとがき

他サーバーにある git repository を同期する手段には、cron を使って定期的に git fetch (or git pull) する方法もある。この方法の欠点は、git push 後、Redmine にデータが同期するまでにタイムラグが出来ること。また、git repository が更新されていなくても、git fetch が実行されてしまうこと。

hook を使えば、誰かが git push したら、自動的に Redmine 側の git repository に反映される。タイムラグもないし無駄な git fetch も発生しない。ぼくは、こちらの方法を好む。

Redmine を使うに当たって、「説明」部分のテンプレートを用意したい。これをブックマークレットで実現した。

Redmine のパワーユーザーならご存じの通り、Redmine で「新しいチケット」を登録する時、「題名」と併せて重要なのが「説明」。

「バグ」に絞って話を進めると、どのような操作をしたのか? エラー・メッセージは何と出たのか? ということは最低限書いて欲しい。

けれど、新人のテスターやプログラミングをやったことのない人が Redmine にバグ登録するのは敷居が高い。そこで、「説明」部分にテンプレートを置き、入力の補助を行なう。

ブックマークレット

「説明」部分にテンプレートを挿入するブックマークレットを作った。

JavaScript のソースコードはこんな感じ。

document.getElementById("issue_description").value="
h1. バグについて

h2. バグが出た場所

* 

h2. バグを出す操作

#

h1. エラー・メッセージ

<pre>
</pre>"

これをブックマークレットに直したのがこちら。

• テンプレート挿入

簡単に説明を加えると、Redmine の「説明」の textarea の ID は issue_description。textarea の中身を書き換えるには InnerHTML ではなく value を使う。

ちなみに Redmine のバージョンは 2.3.0。

他の方法もあるけれど

Redmine のソースコードをいじるのは、バージョン・アップに対してリスクが大きい。特に細めにバージョン・アップを繰り返す場合はやりたくない。

Redmine Plugin では Issue Template というのが良さそうだった。今回、このプラグインが程提するほどの高性能を求めないことと、プラグインは開発が止まる (もしくは最新版に追従しない) リスクがあるので使用を控えた。

あとがき

皆にブックマークレットを登録してもらうのが手間と言えば手間だけど、基本、Redmine 初心者用と割り切っている。

パワーユーザーになれば、定型にこだわることなくテキストを入力する。ほんの数行で理解させるバグ報告の場合もあるし、とても詳しいバグ報告を書かないといけない場合もある。こういった判断は経験を積まないと出来ない。

今回のブックマークレットは、とりあえずバグ報告をする時に「初心者」の敷居を低くすることに主眼を置いている。複数のテンプレートがあるなら、複数のブックマークレットを作ればいいし、ユーザーの力量によってテンプレート挿入を自己判断に任せられることが気に入っている。

Redmine のバージョンを大幅に上げた。

• clmemo@aka: Redmine 2 系へのアップグレード方法

ここで一つ困ったことが発生。Redmine のバージョンが上がって、URL が変わった。変わったのはチケットを番号で指定する URL。

• (旧) http://myserver.com/issues/show/番号
• (新) http://myserver.com/issues/番号

ご覧の通り赤字で書いた「show」という文字列が抜けた。URL がスッキリして良くなったと思う。

問題は、過去の文書資産 — 過去メールや他のドキュメント — に旧 URL が使われていること。全ての文書の URL を直すのは大変なので、旧 URL でアクセスしたら 新 URL に自動的に移るようにした。これを URL のリダイレクトという。

Apache の rewrite 設定

まず、Apache に rewrite 用のモジュール mod_rewrte が入っているかどうかを確認。

$ sudo apache2ctl -M | grep rewrite
Syntax OK
 rewrite_module (shared)

うん、rewirte 用のモジュールが入っている (入ってない人は、頑張って入れて下さい)。

Apache の設定ファイルを変更 (追記部分を青字で書いた)。

<VirtualHost *:80>
  ServerName myserver.com
  DocumentRoot /var/redmine/public
  RewriteEngine On
  RewriteRule ^/issues/show/(.+)$ /issues/$1 [R]
</VirtualHost>

RewriteRule の末尾にある [R] はリダイレクトするための設定。このコードがないと、新しい Redmine の URL に旧 URL でアクセスできる様になる。見る分には問題ないけれど、URL をコピーする時に旧 URL をわざわざコピーさせるのはスマートじゃない。リダイレクトすると、旧 URL でアクセスすると URL は新 URL に変わる。

Apache を再起動すれば、リダイレクトが効くようになる。

あとがき

Redmine を久々にアップグレードして、その変化の大きさに驚いている。地味ながら、結構不満になったのが、今回の URL 問題。正規表現が使えると知るまでは、どうしようかと悩んだ。

• ref. mod_rewrite - Apache HTTP Server (詳しすぎて分からない!)
• ref. mod_rewriteのインストール・設定 - RewriteRuleのサンプル [Fedora, RedHat, CentOS] - Linux (丁度いい分量)

先のエントリーで旧い Redmine を開発版の Redmine に置き換えようとしたのだけど、実は Apache 回りで上手くいっていなかった。何が悪かったかと言うと、新 Redmine はローカルに入れた gems で動き、旧 Redmine はシステムの gems で動いていたこと。

Apache はシステム側の Passenger で動かしていたので、旧 Redmine は動くけど新 Redmine は動かない。何故なら、新 Redmine はシステムの Passenger を使わないから。エイヤッとシステム全体の gems を統一しちゃえば問題ないんだけど、安全策が事態をややこしくした。

というわけで、clmemo@aka: Redmine 2 系へのアップグレード方法 の続きから。

Nginx for Passenger のインストール

Apache で共存させるのは大変なので、Nginx を使うことにした (see also clmemo@aka: Nginx をソースからコンパイルしてインストールしてみた)。これからの作業で Nginx のインストールを行なうので、過去記事の Nginx のインストール部分は飛ばして良し!!

/var/redmine-dev に移動して、nginx 用の module を組む。Apache はモジュールを後から追加できるけど、nginx はコンパイル時に module を組み込む。なので、module 用コマンドがそのまま nginx のコンパイル・コマンドになっている。

$ cd /var/redmine-dev
$ echo 'gem "passenger"' >> Gemfile.local
$ bundle install
$ sudo bundle exec passenger-install-nginx-module
(中略)
Nginx doesn't support loadable modules such as some other web servers do,
so in order to install Nginx with Passenger support, it must be recompiled.

Do you want this installer to download, compile and install Nginx for you?

 1. Yes: download, compile and install Nginx for me. (recommended)
    The easiest way to get started. A stock Nginx 1.2.6 with Passenger
    support, but with no other additional third party modules, will be
    installed for you to a directory of your choice.

 2. No: I want to customize my Nginx installation. (for advanced users)
    Choose this if you want to compile Nginx with more third party modules
    besides Passenger, or if you need to pass additional options to Nginx's
    'configure' script. This installer will  1) ask you for the location of
    the Nginx source code,  2) run the 'configure' script according to your
    instructions, and  3) run 'make install'.

Whichever you choose, if you already have an existing Nginx configuration file,
then it will be preserved.

Enter your choice (1 or 2) or press Ctrl-C to abort:

(1) 自動インストールか、(2) カスタム・インストールか聞かれる。ここはあえてカスタムの 2 を選ぶ。

• Where is your Nginx source code located?
  Please specify the directory: ~/src/nginx-1.3.14/
• Where do you want to install Nginx to?
  Please specify a prefix directory [/opt/nginx]: /etc/nginx
• Extra Nginx configure options
  (中略)
  Extra arguments to pass to configure script: --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --with-mail --with-mail_ssl_module --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl

最後に ENTER を押してコンパイル & インストール開始。

設定ファイルへの追記

2 つのファイルを編集。まず、/etc/nginx/nginx.conf の http セクションに次の 2 行を追記:

  passenger_root /var/redmine-dev/vendor/bundle/ruby/1.8/gems/passenger-3.0.19;
  passenger_ruby /usr/bin/ruby1.8;

Ruby や Passenger のバージョンは環境によって違う。詳しくは、passenger-install-nginx-module のヘルプ・テキストを参照のこと。

次に Redmine を動かす site-availables/yourserver.com を編集。

server { ...
  listen 8080
  root /var/redmine-dev/public;
  passenger_enabled on;
  ...
}

これで nginx を再起動 (/etc/init.d/nginx については過去記事参照)。

上手く http://yourserver.com/ で Redmine が見えたかな?

あとがき

Redmine をアップグレードしようとしたら、二日がかりになってしまった。アップグレードは細めに行ないたいもの。ちょっと泣きそうになったよ。

最後に参考にしたサイトを一つ紹介して終わる。このページはまとまってるとは言いがたいけど、エラーに遭遇して対処して、またエラーに遭遇する様が物語の様で (特に同じ道を歩く者には) 笑いを誘う。もちろん、役にも立つよ。

• Ruby/Rails: Redmine/Passenger/nginxの設定

古い Redmine (< 2.0) を最新の Redmine にアップグレードするので、メモ。今回、ぼくは開発版をインストールした。2013-03-07 現在、Redmine の最新版は 2.2.3 (2013-02-12 リリース)。開発版をインストールする場合でも、問題はないはず。

参考ドキュメント

開発版は公式の git mirror から頂く。

• clmemo@aka: Redmine の公式ミラー・リポジトリー in git/hg

アップグレード手順は以下のページを参照した。

• アップグレード | Redmine.JP
• RedmineUpgrade - Redmine (オリジナル)

必須条件

アップグレード必須条件を書いておく (PostgreSQL や SQLite3 を使ってる人は、「Redmineのインストール | Redmine.JP」を参照のこと)。

• Ruby 1.8.7, 1.9.2, 1.9.3
• RubyGems <= 1.8
• Rails 3.2.12
• MySQL 5.0 以上

Ruby 2.0 には対応していない。各アプリケーションのバージョン・チェック方法は以下の通り:

$ ruby --version
$ gem --version
$ gem list | grep rails
$ mysql --version

必要に応じてアップデートを行なわれたし。

データのバックアップ

以降、旧 Redmine は /var/redmine/ 以下にインストールしたとして話を進める。バックアップ先は ~/redmine-bakups。

$ mkdir ~/redmine-backups

files ディレクトリーのバックアップ

Redmine にアップロードしたファイルは、全て files ディレクトリー以下に保存されている。

$ rsync -a /var/redmine/files/ ~/redmine-backups/files

MySQL DB のバックアップ

mysqldump コマンドを使う。

$ mkdir -p ~/redmine-backups/db
$ /usr/bin/mysqldump -u USER -pPASSWORD REDMINE_DB | gzip > ~/redmine-backups/db/redmine_`date +%y_%m_%d`.gz

REDMINE_DB の名前は /var/redmine/config/database.yml の中を見れば確認できる。

アップグレード作業

Redmine の入手

安定版を使う人はDownloadページから最新版を入手して解凍されたし。ぼくは開発版を git から取って来る。

$ cd /var
$ git clone git://github.com/redmine/redmine.git redmine-dev

redmine-dev というディレクトリーに clone。既存の redmine ディレクトリー (今、動いているバージョン) を上書きしちゃわないように。

Redmine の設定

1. 旧い config/dababase.yml をコピー
2. 旧い config/configuration.yml をコピー (ver. 1.2.0 より前からアップグレードする時は config/configuration.yml.example を config/configuration.yml にコピーした上で旧 config/email.yml の内容をコピーする)
3. files ディレクトリー以下をバックアップから復帰
4. プラグインのコピー (これは後回しの方が安全かな?)
5. rake generate_secret_token で config/initializers/secret_token.rb を作る
6. テーマのコピー (これも後回しで良いかな?)

実作業は次の通り:

$ cd /var/redmine-dev/config
$ cp -p ../../redmine/config/database.yml ./
$ cp -p configuration.yml.example configuration.yml
$ cat ../../redmine/config/email.yml >> configuration.yml
$ cd ..
$ rsync -a ~/redmine-backups/files/* files
$ rake generate_secrete_token
$ ls config/initializers/secret_token.rb
config/initializers/secret_token.rb

トラブル・トラブル・トラブル

実は rake generate_secrete_toke する所でエラーになった。

 rake aborted!
no such file to load -- bundler/setup

bundler が必要らしいけれど、インストールされていない。インストールしようとしたら、gem のバージョンが古い (bundler は gem 1.3.6 以上) という。そんなわけで gem をアップデートして bundler をインストール。

$ sudo gem1.8 install rubygems-update -v 1.3.6
$ sudo update-rubygems
$ sudo gem1.8 install bundler

旧い Redmine が稼動中なので、gem をシステム・インストールするのは怖い。もしかすると、動かなくなるかも。bundler は --path オプションでローカルにファイルをインストールできる。推奨とされる ./vendor/bundle 以下にインストールすることにした:

• ref. Bundler: The best way to manage a Ruby application's gems

$ cd /var/redmine-dev
$ bundle install --path vendor/bundle

しかし、ImageMagick 系でエラー。

checking for Magick-config... no
Can't install RMagick 2.13.2. Can't find Magick-config in (後略)

Magick-config がないという。ImageMagick 系のパッケージをインストール:

$ sudo apt-get install graphicsmagick-libmagick-dev-compat 

再度、bundle コマンド実行。

checking for wand/MagickWand.h... no

お次は wand/MagickWand.h がないという。libmagickwand-dev をインストール。

$ sudo apt-get install libmagickwand-dev

さあ、どうだ!!

$ bundle install --path vendor/bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies...
Using rake (10.0.3)
Using i18n (0.6.4)
Using multi_json (1.6.1)
Using activesupport (3.2.12)
Using builder (3.0.0)
Using activemodel (3.2.12)
Using erubis (2.7.0)
Using journey (1.0.4)
Using rack (1.4.5)
Using rack-cache (1.2)
Using rack-test (0.6.2)
Using hike (1.2.1)
Using tilt (1.3.4)
Using sprockets (2.2.2)
Using actionpack (3.2.12)
Using mime-types (1.21)
Using polyglot (0.3.3)
Using treetop (1.4.12)
Using mail (2.4.4)
Using actionmailer (3.2.12)
Using arel (3.0.2)
Using tzinfo (0.3.36)
Using activerecord (3.2.12)
Using activeresource (3.2.12)
Using metaclass (0.0.1)
Using mocha (0.10.5)
Using bourne (1.1.2)
Using bundler (1.3.1)
Using nokogiri (1.5.6)
Using ffi (1.4.0)
Using childprocess (0.3.9)
Using rubyzip (0.9.9)
Using websocket (1.0.7)
Using selenium-webdriver (2.31.0)
Using xpath (1.0.0)
Using capybara (2.0.2)
Using coderay (1.0.9)
Using fastercsv (1.5.5)
Using rack-ssl (1.3.3)
Using json (1.7.7)
Using rdoc (3.12.2)
Using thor (0.17.0)
Using railties (3.2.12)
Using jquery-rails (2.0.3)
Using mysql (2.8.1)
Using net-ldap (0.3.1)
Using ruby-openid (2.1.8)
Using rack-openid (1.3.1)
Using rails (3.2.12)
Installing rmagick (2.13.2)
Installing shoulda-context (1.0.2)
Installing shoulda-matchers (1.4.2)
Installing shoulda (3.3.2)
Installing yard (0.8.5.2)
Your bundle is complete! It was installed into ./vendor/bundle

成功!!

rake をこのまま実行すると、システムの gems を使ってしまう。bundle exec を使うと、--path で指定・インストールした gems を使ってくれる。なのでこれからの作業は bundle exec 付きで実行。

$ bundle exec rake generate_secret_token
$ ls config/initializers/secret_token.rb
config/initializers/secret_token.rb

secret_token.rb が出来ていることを確認して一安心。

MySQL の設定

MySQL の初期設定を行なう。

ここからは、ローカルの gems を使うので bundle exec を付ける。システム・インストールした gems を使う人は、適宜 bundle exec を消して作業されたい。

$ bundle exec rake db:migrate RAILS_ENV=production

クリーンアップ

キャッシュとセッション・ファイルをクリアする。

$ bundle exec rake tmp:cache:clear
$ bundle exec rake tmp:sessions:clear

パーミッションの変更

Apache などのウェブ・サーバーがディレクトリーにアクセスできるようにパーミッションを変更。

$ sudo chown -R redmine:redmine files log tmp
$ sudo chmod -R 755 files log tmp

確認

以上で Redmine 側の設定はおしまい。心配症な方は WEBrick サーバーを起動してチェック。

$ ruby script/rails server webrick -e production

ぼくはやらなかったけどね。

おしまい

最後にアプリケーション・サーバー (Apache とか) を再起動して実行。

DB を壊しちゃった人は、バックアップから復帰して再挑戦?

$ mysql -u USER -pPASSWORD REDMINE_DB < ~/redmine-backups/db/redmine_YYYY_MM_DD.gz

古い Redmine からアップグレードしようとすると、rake db:migrate RAILS_ENV=production でエラーが出るかもしれない。その場合は Redmine 2.2.2 をダウンロードして上の記事を参考に rake db:migrate ... を実行。データベースを新しくしてから、もう一度最新の Redmine で rake db:migrate ... をかける。

2010 年 3 月、Redmine の git による公式ミラー・リポジトリーについて書いた (Redmine の開発は Subversion で行なわれている)。

• clmemo@aka: Redmine の公式 git mirror repository

今日、サイトを見てみたら公式 git リポジトリーと hg (Mercurial) リポジトリーが載っていた。昔、紹介した git のミラー・リポジトリーも生きている様だけど、今後はこちらの方を使っておくのが良いかな。

• Download - Redmine

ミラー・リポジトリーのプロジェクト・ページは以下の場所にある:

• https://github.com/redmine/redmine (git)
• https://bitbucket.org/redmine (hg)

git における開発版の入手方法:

$ git clone git://github.com/redmine/redmine.git

Mercurial (hg) における開発版の入手方法:

$ hg clone https://bitbucket.org/redmine/redmine-trunk redmine

開発版に手を出したい方はどうぞ。

背景

「コーディング作業に入ったお仕事」のリーダーになった時の経験。正確には「リーダー」という役職ではなかったけれども、役割的には指導的な立場だった。メンターというのかな? 新人部下と書いたけれども、正しくはプログラミングの基本を一応勉強した同期と一年下の後輩だった。その開発プロジェクトは、その後一か月位いでキャンセルされてしまったので、メンターを務めた期間もほんの僅かだった。

とはいえ、メンターとして指導をする機会に恵まれたことは確かで、その中で頭を悩ませた。自分なりに教育方法にも工夫した。その話を、記事にしてみる。

基本は PDCA とコミュニケーション

PDCAサイクルは、Plan (計画)・Do (実行)・Check (評価)・Act (改善) の頭文字を取ったもの。会社の研修では、報連相 (ほうれんそう) (報告・連絡・相談) と共に教えられることが多い。

PDCA は仕事をする上で基本的な概念なのだけれども、職場で PDCA を実践している人を見たことがほとんどなかった。なので、まず PDCA を徹底させることを第一にした。

また、各段階においてコミュニケーションを多く取ることを心がけた。

TiDD

まず、プログラムの大まかな目的と設計を説明した。具体的には (ぼくが作ってた) UML 図のユースケース図とクラス図・アクティビティ図を見せた。で、全体像を掴んでもらったところで、任せる仕事の話に移った。

ここの機能をやって欲しい、と伝える。

そしたら、その機能を作るために必要な作業を挙げてゆく。これは一人任せにせず、一緒にやった。最初なので大まかな作業分割しか出来ないけれども、「プラン」を作る流れを掴んでもらうのが目的。

更に、チケット駆動開発 (TiDD) を覚えてもらった。ぼくは当時 Redmine を使っていたので、Redmine の操作方法を教えて、チケットを発行する方法を教えた。

分割した作業項目を、まずぼくがチケットに落としこんでゆく。彼にはその作業工程を見てもらう。次に彼にチケットを作ってもらい、その様子をぼくが見る。気を付けたのは、チケットの目的を教えることだった。つまり、一つ一つのチケットが「PDCA」の Plan に当たると伝えた。このプランに沿って作業 (Do) するのだと。

そのためにチケットの題名をどう書くべきかを教えた。後から読み返して、「作業のプラン」が分かるように書くよう気を付けた。例えば、「○○部の設計を行なう」といったコーディング以外のチケットも書かせたし、「コーディングを行なう」というチケット名は止めさせて、具体的に「DB と接続するコードを書く」とか「取り出したデータを確認するテスト・コードを書く」とかそういった具合。

一般に TiDD ではチケットの粒度を 1〜2 日で終わる程度としているが、ぼくの場合は一つのコミットに対して一つのチケットを作らせた。コミットも一機能につき一回として、その一機能も最小限の機能にした。従って、チケットの粒度は 1 日に 3〜10 ほどだったと思う。

何故、こんなに粒度を小さくしたかというと、新人はプラグラマーのプロではなかったから。プログラムする部署に配置されたからって、プログラムが必ずしも好きではなかった (一人目の場合)。プログラムは好きでも、努力が空回りしてスパゲッティーな長いコードを書いた (二人目の場合)。例外な人はいるけれども、ぼくの許についた人達は「例外な人」じゃあなかった。

一人目には沢山のチケットをこなしてもらい、その一つ一つをちゃんと褒めた。短いコーディングなので、ミスも少ない。必然、褒める回数が増える。「Good」でも「OK」でも、「いい感じに進んでるね」でも何でも良いので、褒めることを前提にチケットも作った。「出来て当然」という態度は絶対に取らない様にした。そういう態度は、プログラミングが好きになって、コーディング技術が上がってから取れば良いと思った。プログラミングを楽しいと思う様に願った。好きになれば、スキルは自然と伸びるから。

二人目は、チケットを守らせることに気を使った。せっかくチケットを細かく区切っても、彼は「それ以上」をやろうとしてしまう。その頑張りというか、前向きな姿勢は素晴らしいのだけど、コーディング技術が追いついていない。結果、手戻り作業が増える。コーディングのダメ出しが増える。これじゃあ、彼のやる気を削ぐばかりになってしまう。やる気はあるので、もったいない。だから、チケット 1 つの粒度を小さくして、チケットに書いてあること以外をやらせない様にした。時々、チケット以外のコードも書いていたけれども、戻す様に言ったこともある。最初は大変だったけど、最後の方は一機能一コミットでバグの少ないコーディングになっていたので良かったと安堵した。

最初のチケット作成は、ほぼ付きっきり。以降、新しい機能追加のたびに簡単なミーティングで「やるべきこと」を洗い出して、チケット作成は任せる様に少しずつシフトさせた。

なお、毎朝のミーティングで「今日、どのチケットをやるか」の確認だけは日課にした。一日の作業見積りが分かり易くなったし、(緊急会議などで時間が取れないトラブルでもない限り) チケットが終わらない場合は、そこにトラブルの元が潜んでいることが自然と分かったので、悪くない日課だった。時間は二、三分で切り上げる程度。

UML 図

プログラム・ロジックが難しくなったら、UML のアクティビティ図を描いてもらった。描いた図を見て二人で協議。ああでもない、こうでもない。ここの変数は要らない。このチェックどうしよう。こんなアイデアどうだろう。ロジックが難しくなればなるほど、アクティビティ図を複数回描き直してもらった。

アクティビティ図における「一つのアクティビティ」が「一つのチケット」にほぼ対応した。

コードの流れ、チケットの作成 (粒度・取りかかる順番) などが明解になるので、時間をかける価値はあった。

ペア・プログラミング

最初はプログラミングの流れも分かっていないので、ペア・プログラミングをやってみた。

初日にやったこと: チケットのステータスを「担当」にして、コーディングを行ない、コミット・ログを日本語で書いて、実際にコミットする。TiDD の流れと SCM の使い方、そしてコミット・ログの書き方に重点を置いた。

Redmine では、コミットが行なわれると自動的にそのチケットのステータスを「解決」にしてくれる。そして、チケットのコメント欄にコミット・ログが表示される。ぼくは、このコミット・ログの書き方が一番大変だと思う。何故、このコミットを行なったのか? どういう変更を行なったのか? 簡素に、しかし必要な情報は省かずに書く例を見せた。

最初の何日かは大変だった。ログを修正してもらう。自分でログを書く。ログを書いてもらう。ペア・プログラミングで、その繰り返し。完璧ばかりを求めても時間とやる気がなくなるので、最初は好ましくないログでも、そのままコミットさせた。次第に文章は良くなって行く。

ペア・プログラミングは初日以外にも行なった。タイミングは、コーディングが大変そうな時。チケットを見て、先にこのチケットは大変そうだと分かる時もある。その時は、朝のうちにこのチケットはペア・プログラミングでやろう、と声をかけた。あと、ブラリとこちらから声をかけて無駄話をする。その時、コーディングで躓いてないかさり気なく聞く。苦戦している様なら、ペア・プログラミングをやろうともちかけた。相手側からペア・プログラミングを持ちかけられた記憶はほとんどない。自分から言ってみないとダメみたい。

ペア・プログラミングすると、コーディング・スタイルの悪い所も指摘できるし、バグの温床も取り除きやすい。こういうのって、コミットされた後のコードに対して指摘・バグ取りすると、お互い気まずいので、ペア・プログラミングの機会は重宝する。あと、自分のやり方も学んでもらえるのも良い。特に変数の命名方法なんかは、自分でコードを書きながら説明すると、相手の頭に入りやすかった様に思う。

ただ一言。ペア・プログラミングはすごく疲れる。相手が成長しているのを感じられるから面白いけれども、一日に何時間もやれるもんじゃないね。

まとめ

新人プログラマーを教える立場に立ってやったことをまとめると、「PDCA サイクルを回すこと」に尽きる。その手段に TiDD (Redmine) を使った。TiDD の補助に UML 図とペア・プログラミングを活用した。潤滑油はコミュニケーション。

批判

ぼくのやり方に対して批判もあった。ぼく自身のプログラミング時間が大幅に削れている。教育に時間を割き過ぎている。せっぱつまった状況で、悠長に教育しているのはナンセンス。実際、ぼくのプロジェクトは「せっぱつまった状況」で消えてしまう。

自分の時間が削られた分は残業で何とかするとして、ぼくは、教育は重要だと思った。世の中には、指示する前に仕事を見つけて動く人もいる。指示を受けて、十全にこなす人もいる。課題を与えられて、成長する人もいる。叱られて、伸びる人もいる。でも、そうじゃない人もいる。批判した人達は、大量の課題や叱責を与えて伸ばそうとしていたけれども、それがダメで彼らはぼくの許に来た。彼らは、ちゃんと時間をかけなければ育たないと思ったし、せっぱつまった状況だから戦力が増えるように育ってもらわないといけないと思った。

ほんの一か月ちょっとだったけれども、彼らが、ぼくと一緒に仕事をして良かったと思ってくれてることを願う。

関連エントリー

• see also. clmemo@aka: 我流ながら Doing List を二年間試して得た Tips 集

Redmineによるタスクマネジメント実践技法
小川 明彦 阪井 誠


翔泳社 2010-10-13
Amazonで詳しく見る by G-Tools

「Redmine によるタスクマネジメント実践技法」はチケット駆動型開発の実践書。チケット駆動型開発 (Ticket Driven Development) は略記として TiDD とも書かれる。これはテスト駆動型開発 (TDD) と区別するための表記的な問題。

TiDD には BTS システムが欠かせない。現在、代表的な BTS には Trac と Redmine がある。本書では、Redmine を使って TiDD を行なうための実践技法を紹介している。読者対象は TiDD を導入するチームリーダー。TiDD/BTS を導入してみたものの、運用方法に自信がない、チーム・メンバーへの普及が上手くいかない、そもそも自分は TiDD を理解していないのでは? そんな人を対象にしている。

今まで Redmine の本は何冊か出ていた。けれど、それらは Redmine のインストール方法、設定方法、機能説明に終始していた。TiDD について踏み込んだ本はなかった。せいぜい Redmine を使った時のメリットを物語風に紹介する程度だった。

• ref. clmemo@aka: Redmine の解説本を二冊買ったので比べてみた

Redmine の本ではツールの使い方は分かっても、TiDD という技法が分からなかった。

本書はその解答の一つを教えてくれる。その代わり、Redmine のインストール等の説明は削ってある。あくまで Redmine インストール後、チームリーダーが TiDD を実践するための本。

アジャイル etc.

本書では何度もアジャイル開発という言葉が出てくる。実は TiDD とアジャイル開発は相性が良い。本書では、そういった事象についても解説が加えられる。特に考えさせられたのは p.163 の次の一節。

大規模開発におけるアジャイル開発についても、「アジャイルリリーストレイン」と「スクラムオブスクラム」を取り上げて説明をしている。

SCM

本書では主に Subversion によるバージョン管理をベースに説明が展開される。ぼくは最近 Git を使っているので、Subversion に使い勝手の悪さを感じる。開発ペースも集中管理型の Subversion と分散管理型の Git では大きく違う。

現在、バージョン管理の主流は分散管理型に移り変わっているので、Subversion 中心の説明に不足を感じた。もし第二版が出ることがあれば、分散管理型 SCM での TiDD (特にブランチの作成云々) を書いて欲しいと思った。

TestLink

TestLink というテスト管理ツールがある。

自動化できないテストに関して、開発者やテスターはテスト計画書を書く。一つリリースを出したら、テスト計画書に従ってテストを行なう。バグが見つかったら、BTS に登録する。

以上が一般的なテストの流れ。テストを管理して BTS と連携させるツールが TestLink。本書には TeskLink と Redmine との連携方法に一章が丸々割かれている。TestLink の解説書自体見かけたことがないので、貴重な一章と思う。

ぼくはテスト計画書を今まで Excel で書いていたけれど、TestLink の存在を知って、TestLink を使いたくなった。

あとがき

今までになかった、チケット駆動開発に主眼を置いた解説書。同じ言い回しが何度か出てきて、疎ましく感じることもある。それを差し引いても、一読の価値はあると思う。

最後にチケット粒度について。本書とぼくはチケット粒度について立場を異にする。これはその道の人でもちゃんとした答えが出ていない問題のようなので、自分のプロジェクトに合わせて試行錯誤する必要がありそう。

関連記事

• チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)
• Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ
• チケットファーストでアジャイル開発！～チケットに分割して統治せよ

Redmine の最新バージョン 1.1 が、2011-01-09 にリリースされていた。

• Redmine 1.1.0 リリース | Redmine.JP Blog

新機能については、Redmine.JP Blog にエントリーがある。

• Redmine 1.1のCHANGELOG (新機能のみ・日本語訳付き) | Redmine.JP Blog
• see also 1.1 | Redmine.JP Blog

主なところでは、ガントチャートのソースコードが新しく書き直されたこと、コミット・メッセージから「作業時間」の入力が可能になったことが挙げられる。また、インストールに際して Ruby の国際化ライブラリー i18n (version 0.4.2+) が必須になった。

バグ修正で目につくところは、{{toc}} が {{include}} の中で使えるようになったこと。この不具合のおかげで {{include}} マクロが使いにくくてしょうがなかったので助かる。

現在、1.1.0 のバグ・フィクス版 1.1.1 の開発と、新バージョン 1.2.0 の開発が進められている。新バージョン 1.2.0 では待望の「プライベート・チケット」がサポートされるらしい。期待大! 一応リリース予定は 2011-04-30。

入門Redmine 第2版 Linux/Windows対応 (version 1.0 対応)
前田 剛


秀和システム 2010-08-11
Amazonで詳しく見る by G-Tools

github にプロジェクトを登録したら、README ファイルを用意しておくと良い。すると、github はそのプロジェクトのトップページに、その「README」ファイルの中身を表示する。初めてそのプロジェクト・ページにアクセスした人は、README ファイルを開かずに概要を知ることができる。プロジェクトを公開する側も、使おうと考えている側にとってもメリットは大きい。

一般に README ファイルはテキスト・ファイルで用意してやれば良い。

しかし、中には README ファイルも HTML の様に「綺麗」に表示されることを望む人も居ることと思う。URL があれば、それがリンクになることを望むことと思う。ヘッダーは大きな文字で表示される方が嬉しかろう。

そんな人のために、github は wiki の書式を README に入れる仕組みを用意している。

README に wiki 書式を持ち込む

wiki の書式は一つだけではない。Markdown や Textile などが外部ライブラリー化された wiki 書式としては有名。Perl のドキュメント・フォーマット pod も一種の wiki 書式と考えて良いかもしれない。

例えば Textile 書式で README ファイルを書きたいとしよう。その場合、次のやうにする:

1. README を Textile 書式で書く
2. README ファイルを README.textile にリネームする
3. github に push する

README ファイルに「書式の拡張子」を付けてやるだけ。

現在、github がサポートしている書式は以下の通り。README に付けるべき拡張子を示す:

• .markdown
• .textile
• .rdoc
• .org (Org-mode)
• .creole
• .rst (reStructuredText)
• .asciidoc
• .pod (Perl POD)
• .1 (groff)

あとがき

先日 GitHub に公開した html-fold に Textile 書式の README.textile を追加してみた。

• ataka's html-fold at master - GitHub

よければ参考にして欲しい。

ちなみに、Textile を選んだのは、ぼくが愛用している Redmine の Wiki 書式が Textile を採用しているから。

ref

• github's markup at master - GitHub

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

• ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト | Lifehacking.jp
• 今、そこにある未来：脳内バイパスを作る Doing リストの実践例 | Lifehacking.jp

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

Original Doing List

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

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

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

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

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

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

我流 Doing List

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

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

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

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

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

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

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

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

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

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

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

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

我流 Doing List Tips

• 日付を入れる
• 方眼紙を使う
• 4 色ボールペンを活用する
• 略記号を作る
• 英語を使う
• サブタスクはインデントする
• 最初の数行は空けておく
• 時計を描く
• 1 日 1 ページ
• 関連タスクをつなげる方法
• 緊急な割り込みがあった場合は?

日付を入れる

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

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

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

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


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

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

方眼紙を使う

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

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

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

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

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

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

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 円。

• clmemo@aka: Lamy 2000 -- 手離せない 4 色ボールペン
• clmemo@aka: 多色ペン Reporter 4 を買った

略記号を作る

毎日同じやうなタスクを書いていると、時間が惜しい。自作の略記号を作っておくと便利。作った略記号はノートの 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 の例。会議ではないけれど、どこに隙間時間があるのか把握できる。

ノートを方眼紙にしているメリットがここにも現れている。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 やチケットから「自分の手元」に降りてきたタスクを「自分でマネージメント」する道具だと思う。

Redmine の Wiki にはファイルを添付する機能がある。ところが、Wiki の名前を変更すると、添付したファイルは消えてしまう。正確には、古い Wiki 名にファイルが紐付けされていて、新しい Wiki 名へと追随しない。

現状、スマートな解決策はない。泥臭いけれど、Wiki を管理している DB を直接いじるしかない。本エントリーでは、MySQL を使っているとして Wiki に添付したファイルを移動させる手順を説明する。

database.yml

使っている database.yml を示す。

/var/lib/redmine$ cat config/database.yml
# MySQL (default setup).  Versions 4.1 and 5.0 are recommended.
#
# Get the fast C bindings:
#   gem install mysql
#   (on OS X: gem install mysql -- --include=/usr/local/lib)
# And be sure to use new-style password hashing:
#   http://dev.mysql.com/doc/refman/5.0/en/old-client.html

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: foo
  encoding: utf8

adapter は mysql。database や username、password は自分の環境に合った値に設定されたし。

Backup DB

DB を下手にいじって壊してしまってもいけないので、作業前にはバックアップを取っておこう。

/var/lib/redmine$ /usr/bin/mysqldump -u -p | gzip < redmine_`date +%y_%m_%d`.gz 

MySQL をいじる

ここでは実際に「GitWindows」という Wiki ページを「MsysGitInstall」という名前に変更した場合の作業手順を示す。ちなみに、「GitWindows」という Wiki を「MsysGitInstall」にリネームした後、改めて「GitWindows」という Wiki ページを作成してある。やりたかったのは、「GitWindows」という Wiki が大きくなりすぎたので、一部を「MsysGitInstall」という Wiki に切り出す作業。

次のコマンドを実行して、MySQL が管理している Redmine の DB をいじる。オプションとして与える user, password, host は database.yml の値を使う。

/var/lib/redmine$ mysql --user=redmine --password=foo -h localhost redmine

以降、mysql のプロンプトでの操作になる。

まずはどんな DB があるか確認してみやう。

mysql< show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| redmine            | 
+--------------------+
2 rows in set (0.00 sec)

redmine という DB があるのが確認できる。これから、この DB をいじっていく。

mysql< use redmine;
Database changed

作業 DB を「redmine」に切り替えたら、どんなテーブルがあるか確認しやう。

mysql< show tables;
+-------------------------------------+
| Tables_in_redmine                   |
+-------------------------------------+
| attachments                         | 
| auth_sources                        | 
| boards                              | 
| changes                             | 
| changesets                          | 
| changesets_issues                   | 
| comments                            | 
| custom_fields                       | 
| custom_fields_projects              | 
| custom_fields_trackers              | 
| custom_values                       | 
| documents                           | 
| enabled_modules                     | 
| enumerations                        | 
| groups_users                        | 
| issue_categories                    | 
| issue_relations                     | 
| issue_statuses                      | 
| issues                              | 
| journal_details                     | 
| journals                            | 
| member_roles                        | 
| members                             | 
| messages                            | 
| news                                | 
| open_id_authentication_associations | 
| open_id_authentication_nonces       | 
| plugin_schema_info                  | 
| projects                            | 
| projects_trackers                   | 
| queries                             | 
| repositories                        | 
| roles                               | 
| schema_migrations                   | 
| settings                            | 
| time_entries                        | 
| tokens                              | 
| trackers                            | 
| user_preferences                    | 
| users                               | 
| versions                            | 
| watchers                            | 
| wiki_content_versions               | 
| wiki_contents                       | 
| wiki_pages                          | 
| wiki_redirects                      | 
| wikis                               | 
| workflows                           | 
+-------------------------------------+
48 rows in set (0.01 sec)

この通り、48 のテーブルが見つかった。wiki の一覧を見るには、wiki_pages テーブルを参照する。全てを select すると量が多くて大変になるだらうから、like 演算子等を使って絞り込みをしやう。ここではタイトルに「GIT」が含まれている Wiki を抽出してみる。

mysql< select * from wiki_pages where title like '%GIT%';
+----+---------+----------------+---------------------+-----------+-----------+
| id | wiki_id | title          | created_on          | protected | parent_id |
+----+---------+----------------+---------------------+-----------+-----------+
| 26 |       2 | GitAdmin       | 2009-08-20 11:19:13 |         0 |         3 | 
| 27 |       2 | GitProxy       | 2009-08-20 11:29:46 |         0 |         3 | 
| 28 |       2 | GitCommitLog   | 2009-08-20 11:38:24 |         0 |         3 | 
| 29 |       2 | GitRepo        | 2009-08-20 11:59:23 |         0 |         3 | 
| 30 |       2 | GitIntro       | 2009-08-20 12:03:18 |         0 |         3 | 
| 39 |       2 | GitWindows     | 2009-10-08 11:14:10 |         0 |         3 | 
| 41 |       2 | GitConfig      | 2009-10-21 11:09:13 |         0 |        30 | 
| 45 |       2 | EclipseGit     | 2009-11-05 14:32:43 |         0 |         3 | 
| 46 |       2 | MsysGitInstall | 2009-11-05 17:31:37 |         0 |        39 | 
+----+---------+----------------+---------------------+-----------+-----------+
9 rows in set (0.00 sec)

この通り、9 つの Wiki が見つかった。ここで、移動元の Wiki「GitWindows」の id が 39 であること、移動先の Wiki「MsysGitInstall」の id が 46 であることをメモしておこう。

次は attachments テーブルを見てみたい。ただこのテーブルの構成が分からない。未知のテーブルに出会ったら desc コマンドでテーブルの詳細を確認する。

mysql< desc attachments;
+----------------+--------------+------+-----+---------+----------------+
| Field          | Type         | Null | Key | Default | Extra          |
+----------------+--------------+------+-----+---------+----------------+
| id             | int(11)      | NO   | PRI | NULL    | auto_increment | 
| container_id   | int(11)      | NO   | MUL | 0       |                | 
| container_type | varchar(30)  | NO   |     |         |                | 
| filename       | varchar(255) | NO   |     |         |                | 
| disk_filename  | varchar(255) | NO   |     |         |                | 
| filesize       | int(11)      | NO   |     | 0       |                | 
| content_type   | varchar(255) | YES  |     |         |                | 
| digest         | varchar(40)  | NO   |     |         |                | 
| downloads      | int(11)      | NO   |     | 0       |                | 
| author_id      | int(11)      | NO   | MUL | 0       |                | 
| created_on     | datetime     | YES  | MUL | NULL    |                | 
| description    | varchar(255) | YES  |     | NULL    |                | 
+----------------+--------------+------+-----+---------+----------------+
12 rows in set (0.01 sec)

12 のカラムがあることが分かった。

各々のカラムの役割を見てみたい。そこで適当なファイルを選んで、カラムと値の対応関係を見てみる。

mysql< select * from attachments where filename like 'msysgit%-01.png';
+----+--------------+----------------+------------------------+-------------------------------------+----------+--------------+----------------------------------+-----------+-----------+---------------------+------------------------------------+
| id | container_id | container_type | filename               | disk_filename                       | filesize | content_type | digest                           | downloads | author_id | created_on          | description                        |
+----+--------------+----------------+------------------------+-------------------------------------+----------+--------------+----------------------------------+-----------+-----------+---------------------+------------------------------------+
| 42 |           39 | WikiPage       | msysgit-install-01.png | 091008113037_msysgit-install-01.png |    22520 | image/png    | af7ca8345cb3477b3ee7c59327918779 |         0 |         3 | 2009-10-08 11:30:37 | MsysGit インストール画面 1         | 
+----+--------------+----------------+------------------------+-------------------------------------+----------+--------------+----------------------------------+-----------+-----------+---------------------+------------------------------------+
1 row in set (0.00 sec)

どうやら、添付ファイルの ID が「id」、そのファイルが添付されている Wiki の ID が「container_id」、そして添付ファイル名が「filename」というカラム名で現されているらしい。

移動させたい添付ファイルは「msysgit-install-*.png」なので、こんな SQL 文を書いてみる。

mysql< select id,container_id,filename from attachments where filename like 'msysgit%';
+----+--------------+------------------------+
| id | container_id | filename               |
+----+--------------+------------------------+
| 42 |           39 | msysgit-install-01.png | 
| 43 |           39 | msysgit-install-02.png | 
| 44 |           39 | msysgit-install-03.png | 
| 45 |           39 | msysgit-install-09.png | 
| 46 |           39 | msysgit-install-04.png | 
| 47 |           39 | msysgit-install-05.png | 
| 48 |           39 | msysgit-install-06.png | 
| 49 |           39 | msysgit-install-07.png | 
| 50 |           39 | msysgit-install-08.png | 
| 55 |           39 | msysgit-install-11.png | 
+----+--------------+------------------------+
10 rows in set (0.00 sec)

この通り、添付ファイルは 39 番の Wiki に貼り付いている。これを 46 番の Wiki へ移動させたい。やるべきことは、SQL で container_id の値を変えるだけ。

mysql< update attachments set container_id = 46 where filename like 'msysgit%';
Query OK, 10 rows affected (0.01 sec)
Rows matched: 10  Changed: 10  Warnings: 0

Query は成功したと言っている。実際に成功したか確かめてみやう。

mysql< select id,container_id,filename from attachments where filename like 'msysgit%';
+----+--------------+------------------------+
| id | container_id | filename               |
+----+--------------+------------------------+
| 42 |           46 | msysgit-install-01.png | 
| 43 |           46 | msysgit-install-02.png | 
| 44 |           46 | msysgit-install-03.png | 
| 45 |           46 | msysgit-install-09.png | 
| 46 |           46 | msysgit-install-04.png | 
| 47 |           46 | msysgit-install-05.png | 
| 48 |           46 | msysgit-install-06.png | 
| 49 |           46 | msysgit-install-07.png | 
| 50 |           46 | msysgit-install-08.png | 
| 55 |           46 | msysgit-install-11.png | 
+----+--------------+------------------------+
10 rows in set (0.00 sec)

見事、添付したファイルが 46 番の Wiki に移った。

後は、ウェブ・ブラウザーを開いて Redmine の中で本当に添付ファイルが移動しているか確認しませう。

おしまい。

バグ管理システム Redmine は、コードのハイライト表示に CodeRay と呼ばれる Ruby Library を使っている。

Redmine 0.7 の時代に CodeRay 0.7.6 を使っていた。そして今、Redmine 0.9.3 が最新になるも、CodeRay のバージョンは上がっていない。CodeRay の最新版は 0.9.2 が出ているにもかかわらず!

ついに 0.9.2 を採用

そして一昨日、ついに変化が起きた。Redmine の開発版に CodeRay のバージョン 0.9.2 が入った。

• Redmine - Feature #3359: Update CodeRay 0.9 - Redmine

CodeRay 0.9.2 版では、C++ や Java といったメインな言語のサポートが行なわれている。コード・ハイライトについては (同じバグ管理システムとして代表的な) Trac に一つ遅れる Redmine だったけど、このバージョン・アップでようやく追いついたかな。

簡単な使い方

Redmine でコード・ハイライトを使う場合は Wiki にこのやうに書く:

<pre><code class="cpp">
  C++ のソースコード
</code></pre>

code 要素のクラス名に「言語」を指定するのがポイント。

• ref. Redmine.JP | textile記法

新しく加わった言語

まずは 0.7.6 でサポートされていた言語一覧をば

• c (C 言語)
• html
• java_script
• rhtml (ERB+HTML)
• ruby
• scheme
• xml (html と同じ)

0.9.2 の採用で次の言語が利用可能になった。

• cpp (C++)
• css
• delphi
• diff
• groovy
• java
• json
• nitro_xhtml
• php
• python
• sql
• yaml

Nitro XHTML というが何なのか良く分からない。他は知ってる言語ばかりかな。

新しいコード・ハイライトを試したかったら、開発版 Redmine は魅力的。公式版を待つならば、2010-07-03 リリース予定の Redmine 1.0 をお楽しみに。

ref

• clmemo@aka: Redmine の解説本を二冊買ったので比べてみた

バグ管理システム Redmine は Subversion で開発が進められている。

• http://redmine.rubyforge.org/svn

ところが、最近、Git によるミラー・レポジトリーが公開されるやうになった。このミラー・レポジトリーは GitHub 上で公開されている。

• See edavis10's redmine at master - GitHub

Git 使いの人 (ぼくを含む) にとっては、自分の好みの環境で Redmine を取得できるのは嬉しいね。

一応、取得方法だけ書いておく。

$ git clone git://github.com/edavis10/redmine.git

Git を使うとネットワークに繋がっていない環境でも Commit Log を読んだり、Branch をローカルで作れたりして便利。他のサービスも、(Git で開発しろとは言わないけれど) Git のミラー・レポジトリーを作るようにしてくれると有難いなぁ。

Ruby on Rails で作られたバグ管理システム Redmine の解説本が最近立て続けに出た。

一冊は「入門 Redmine」で (以下「入門」と呼ぶ)、秀和システムから。225 ページ。作者は前田剛氏。氏は日本の Redmine の総本山的なサイトである Redmine.jp の運営者とのこと。

もう一冊は「Redmine もっと手軽にプロジェクト管理」で (以下「手軽」と呼ぶ)、インプレスから。231 ページ。単著ではなく、TIS の社内ベンチャー SonicGarden の中の人達が書いている。名前を挙げると、倉貫義人・栗栖蔵臣・並河祐貴・前田直樹の 4 人。このうち栗栖氏だけは、TIS 入社後にはてなへ転職している。

比較

発売は、「入門」が 2008 年 12 月、「手軽」が 2009 年 8 月。対象にしている Redmine は、「入門」が 0.7 系の開発版 (一部 0.8 の情報を含む)。対して「手軽」が 0.8.2。現在の最新版は 0.8.4 なので、「手軽」の方がバージョンは合っている。

といっても、「入門」を読んでいて、最新バージョンとの違いに困ったという場面はなかった。

利用者・管理者

Redmine 利用者向けの説明、及び管理者の設定項目の説明では、「入門」の方が良いかもしれない。表やスクリーン・ショットが多く、読みやすい。

他方、「手軽」は文章中心で、「入門」より詳しく説明している部分があるにもかかわらず、あっさりとしている印象を受ける。表より列挙を多様しているのも、初学者に敷居を高くしている。

両者ともに、バグ管理システムそのものの使い方について説明している点が良い。「入門」は陥りがちな点をピンポイントで解説していて分かり易い。「手軽」は物語仕立てでメリットを説明していて、バグ管理を使わない時・使った時の改善点が際立つ構成になっている。

「入門」は本当に入門的で、一冊をプロジェクト・メンバーに回し読みさせるのに良さそう。「手軽」は、回覧させても読まない人が出てきそうな点がイマイチ。どちらかというと、Redmine のマネージャー的立場の人が読んで、啓蒙の手がかりにする本かもしれない。

インストール

両者とも Cent OS に、MySQL を DB として Redmine をインストールしている。Redmine は DB として SQLite もサポートしているけど、それを推めない点がいい (Trac は SQLite で構築してちと困った)。

ウェブ・サーバーについては、両者で少し対応が違う。

「入門」で扱うのは、主に Apache + Passenger でのインストール方法。それ以外には軽く触れる程度。Passenger がベスト・プラクティスだと言って、初めて Redmine をインストールする人を迷わせない。拍手。

「手軽」が紹介するのは、mongrel を使う方法と lighttpd を使う方法の二種。Passenger は言葉が出てくる程度。

さて、どれがいいのかしらん。一応、「入門」の言葉を引いておく

ぼくには、この言葉を裏付ける数値を出せない。もしかしたら、「入門」から「手軽」の約 8 か月の間に状況は変わったのかもしれない。そうじゃないかもしれない。誰か分かる人がいたら、コメント下さい。

Amazon と Plugin

「手軽」にしかない項目が 2 つある。

一つは、Amazon の EC2 を使って Redmine を構築する方法。いわゆるクラウド・サービスに Redmine を置いちゃおう、ってお話。Amazon の S3 を使ってバックアップを取る方法も解説している。手順の流れを追う程度の簡単な解説だけど、今の所、この本でしかない解説なので貴重。

もう一つは、Redmine の Plugin を作るお話。Plugin のインストール方法は「入門」にもあるのだけど、作り方は書いてない。「手軽」の説明は、Ruby on Rails を触った人なら付いていけるんじゃないかな? (Rails でアプリを作ったことがないと厳しいかもしれない)。

総評

入門者にターゲットを絞っているのが「入門」。広く浅く、Redmine の色んな可能性を知りたい少し中級者には「手軽」。

でも、本当に Redmine をプロジェクト内で使おうとするなら、きっと両方買うことになるのかもしれない。

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

Trac_wiki_to_textile

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

• ataka's trac_wiki_to_textile at master - GitHub

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

• hchoroomi's trac_wiki_to_github at master - 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 へ移行するためのツールは既に存在している。

• Redmine.JP | 他システムからの移行

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

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

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

• ataka's trac_wiki_to_textile at master - 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 を作る気にはならなかったと思う。感謝。

• ref. The trac_wiki_to_github Network - GitHub

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

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

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