結論

「はじめての導入」に fixdap を選びました。

背景

• 遠隔地とタスクを共有したい
• メールベースでは共有しにくい¹
• 相手方はそういうツールに疎いのでシンプルな方が良い
• 非公開で使いたい
• できれば無料で

もう十分に外部のサービスが揃っているので、小さい仕事まで全部自前でサーバにセットアップとか、できるだけやりたくない。すぐやめるかもしれないんだし :-P

候補

ITS ( Issue Tracking System ) は外す。Issue Tracking とプロジェクト管理はベツモノだと思うので。まぁ最近は ITS とプロジェクト管理を統合する方向で各ツールは進化してるっぽいが、個人的には Wiki が好きということでも分かるように

シンプルなツールが好き

なの。特に管理系のツール自体がヘビーになるのはどうも解せない。ツールは目的じゃないんだから。

で。

• 残念ながら参加する人間の関係上、英語インターフェイスしかないものは却下
• Google Docs は Office 文書の共有しかできない。まさか Excel で管理とか常識的に無理
• Backlog は非公開プロジェクトを無料では作れない

残りは Zoho Projects と fixdap

Zoho Projects

これは本格的なプロジェクト管理ツールで、しかも無料で非公開で使える。（ただし、作れるプロジェクトは一つまで。）

OpenID 対応

Google ID などでログインできる。一見地味だけど、後に挙げる「外部メンバー」のところで効いてきそう。

概念の階層が Trac より一つ多い

• プロジェクト
  • マイルストーン
    • タスクリスト
      • タスク

慣れもあるけどタスクリストはちょっと邪魔かなぁ。

外部メンバー、内部メンバー

これは面白い。社外の顧客と情報共有をしつつ、内部リリース（非公開）用のマイルストーンを設定できる。

またこの際、Google ID などでログインすることができるので、Zoho Projects を普段使っていない人との情報共有の際にいくらかハードルを下げてくれる効果があると思う。

カレンダーですぐ確認できる

カレンダーと連携しているので、締め切りを視覚的に確認できる。

未割り当てタスクを作れない

タスクを起こす際に担当を未定にできない。この辺はちょっと最初の計画の比重の高いツールという印象を受ける。まぁ普通のビジネスではあまり問題にはならないのかもしれないけど、「にわか」アジャイラーとしてはこういうところも気になる。

結論としては見送り

今回に関しては見送り。というのも本格的過ぎる。プロジェクト管理の概念、管理ツールに慣れていない人にとっては逆に多機能、高機能さが「面倒くさそう」という印象になってしまいかねない。

「はじめての導入」にはちょっと向かないと思う。

慣れている人同士ならかなり使えるツールだと思う。

fixdap

fixdap はプロジェクト管理じゃなくてタスク管理ツール。

• livedoor ID は無関係
• milestone 管理はできない
• 締め切り、担当を未定にしてタスクを起こせる
  • 洗い出しだけ先にやって「振ったり」「立候補したり」して進めていくことができる
• 無料
• 内容は非公開にできる
  • プロジェクトの存在を完全に隠蔽することはできない（ユーザーにたどりつけば、非公開のプロジェクトの存在はバレる）

あと地味に

• ガラケー対応

これ実は日本人同士のお仕事で使う際に大きなポイントになるような気がする。

これがあれば

• iCal 出力
• 非公開プロジェクト用の Feed URI
  • RTM のプライベートアドレス程度のもので ok

fixdap はタスクに変化（作成とか変更とか）があったときにメールを飛ばす機能があるんだけど、正直毎回メールが来るのはうっとうしい。逆に iCal や Feed で出力してくれると「チェックする側」としてはとても嬉しい。作業者向けというよりはマネージャ向けの機能として欲しいかなぁ。

あとタスクの description を再編集できないという致命的な問題がある。これは早急に直してほしいけど、たぶん放置なんだろうなぁ。仕方ないので description は短く簡潔に書いておいて、返信で補足していく感じにしないといけない。

fixdap ってちょっと信用ならない感があったり、残念な扱いだけど、面白い企画だと思うんですよねぇ。多少マネタイズを考えてもらってもいいので、もうちょっと完成度を上げると全然他のツールに負けないと思うんだけどなー。

ちなみに

タスク管理なら RTM でいんじゃね？と考えるかもしれないけど、RTM は個人のタスク管理をベースにしているので普段 RTM を使っていない人を巻き込むのはかなりハードルが高いと思う。見なくていい情報が多すぎる。

スマートフォン対応がしっかりしてるという意味では今後も考えてとてもいいんだけど。

Ruby のリファレンスマニュアルを見ていると URI#encode のところで $KCODE をいじっている処理を見掛ける。

URI - Rubyリファレンスマニュアル

require 'uri'
$KCODE = 'EUC'
p URI.escape('http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=Rubyリ ..
=> \"http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=Ruby%A5%E ..

これ、要るんだろうか？

Ruby 1.8.7@OSX 10.5.7 + MacPorts で試す。

$ irb
irb(main):001:0> $KCODE=''
=> ""
irb(main):002:0> require 'uri'
=> true
irb(main):003:0> URI.encode( '日本語' )
=> "%E6%97%A5%E6%9C%AC%E8%AA%9E"
irb(main):004:0> $KCODE='u'
=> "u"
irb(main):005:0> URI.encode( '日本語' )
=> "%E6%97%A5%E6%9C%AC%E8%AA%9E"
irb(main):006:0> $KCODE='e'
=> "e"
irb(main):007:0> URI.encode( '日本語' )
=> "%E6%97%A5%E6%9C%AC%E8%AA%9E"

以上、encode については $KCODE の値はなんら影響なし。例によってこれを書いている時点では Ruby 1.8.7 で試して結果をコピペしてるけど、実際には 1.8.5 でも 1.8.6 でも試している。

irb(main):008:0> URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' )
=> "日�\234�語"
irb(main):009:0> $KCODE='u'
=> "u"
irb(main):010:0> URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' )
=> "日本語"
irb(main):011:0> $KCODE='e'
=> "e"
irb(main):012:0> puts URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' )
日本語
=> nil
irb(main):013:0> $KCODE=''
=> ""
irb(main):014:0> puts URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' )
日本語
=> nil

decode についても途中文字化けして見えるのは terminal が UTF-8 で、utf-8 の文字列を euc-jp の設定で無理矢理出力しようとしているのか、確かに化けて見えるが戻ってきた値を puts したものでは化けない。

つまり、戻り値の日本語に対して何かの操作を加えようとするなら $KCODE の値は意味があるかもしれないが、encode, decode 自体には関係ないように見えるんだけど、違うのかな？

Ruby 1.9.0@Debian lenny の場合。

$ irb
irb(main):001:0> $KCODE = 'u'
(irb):1: warning: variable $KCODE is no longer effective; ignored
=> "u"
irb(main):002:0> require 'uri'
=> true
irb(main):003:0> URI.encode( '日本語' )
=> "%E6%97%A5%E6%9C%AC%E8%AA%9E"
irb(main):004:0> $KCODE = 'e'
(irb):4: warning: variable $KCODE is no longer effective; ignored
=> "e"
irb(main):005:0> URI.encode( '日本語' )
=> "%E6%97%A5%E6%9C%AC%E8%AA%9E"

irb(main):006:0> $KCODE = 'u'
(irb):6: warning: variable $KCODE is no longer effective; ignored
=> "u"
irb(main):007:0> URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' )
=> "\xE6\x97\xA5\xE6\x9C\xAC\xE8\xAA\x9E"
irb(main):008:0> puts URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' )
日本語
=> nil
irb(main):009:0> $KCODE = 'e'
(irb):9: warning: variable $KCODE is no longer effective; ignored
=> "e"
irb(main):010:0> puts URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' )
日本語
=> nil
irb(main):011:0> URI.decode( '%E6%97%A5%E6%9C%AC%E8%AA%9E' ).encoding
=> #<Encoding:ASCII-8BIT>

やっといてなんだけど $KCODE の値は ignored って言われてるんだから意味がない。この場合は locale が UTF-8 だから UTF-8 で解釈されるような気がしたんだけど、中身は ASCII-8BIT だった。

まぁ言いたいことはそういうことじゃなくて、戻り値に対して操作を加える必要がないなら URI#encode, decode 自体には $KCODE は関係ないよね？ってことでした。

elisp の byte compile がいちばん時間掛かる…。先に抜いときゃよかった。どうせ snapshot に入れ替えるつもりなのに、21 用の elisp を延々 byte compile してもらっちゃってるのはバカすぎだなぁ。

[追記] なんか一部のパッケージが信頼できないとしてインストールされていなかった。nkf.pm と trac がそれ。こっちゃ trac のアップグレードにいちばん期待していただけにちょっとびっくりした。「あっれー trac 動かないよ？」と思ったら入ってねーんだもの。警告を無視してなんちゃらかんちゃらと脅されたが振り払ってインストール。

trac-admin <PATH> upgrade
trac-admin <PATH> resync
trac-admin <PATH> wiki upgrade

をプロジェクトの数だけリピート。あ、この作業ってすぐスクリプトにできるやんけ。あーまぁいいか。

うむ。 エンコーディングが混ざっていても化けない diff みたいにごちゃごちゃ頑張らなくても chengeset をポチっとするだけでまともに見れるようになった。よしよし。

base_url の設定を足すことで proxy 経由の Trac でも意図した URL への link を持つ Feed を生成できるようになった。よしよし。

Mac OS XにVNCサーバーを入れたいときはARD2.1 Clientをインストールすれば良い

を見て「うぉっ」と思って試してみたんだけど、Ultr@VNC とは相性があまりよろしくないような。Ultr@VNC Viewer の方で AUTO で繋いじゃうと画面の初期化ができない。接続スピードとか設定とかいじれば見れる状態にはなるんだけど、マウスカーソルが出てこない。

いずれも制御はできるんだけど。

まぁあんまり真面目に検証してないし、そもそも組み合わせ的に

Ultr@VNC Viewer → Apple Remotedesktop Client

という接続はほぼあり得ないので、自分とこでは全然困らないんだけど。

Photo は Enjoying Multimedia に統合しよう。

なぜなら Windows は起動したバイナリファイルをロックしてしまうから。terminal からは detach されるが Windows が放してくれないので、タスクマネージャから zebedee のプロセスを殺すか、Windows をログオフあるいはシャットダウンしない限り USB メモリを抜けなくなる。まぁそういうもんだと思っていればいいかもしれないが、すぐに抜きたい場合もあるでしょうし、みんなが「プロセス」なんてものを意識しなきゃいけないってのはちょっとハードル高いんじゃないかと。

PortForwarder みたいな GUI が Zebedee にもあればいいんだけど、そういうものはないので。。。

Windows の GUI プログラミングはできないので誰か作ってくんないかなぁ。

まず基本。

を設定すると server から client へ接続される。以下補足。

• serverport は両方に必要。（もしくは両方指定しないで自由に通信させるか、どっちか。でも自由に通信できるんだったら tunnel の意味ないよね :）これは Zebedee の接続ポートを明示的に制限する場合の基本。
• listenmode の client は設定した serverport 及び tunnel のすべてのポートで listen する。ただし、tunnel の方に書いた port については、localsource true の場合は localhost 以外からの接続は受け付けない。
• firewall の設定は serverport を開けておく。
• client が listenmode でなおかつ serverhost * でない場合は、server の名前をどうにかして client が解決できないといけない。例えば DNS のない LAN 内の場合は Windows <-> Un*x 間は普通名前解決できないので繋がらない。
• serverhost * の listenmode は要するにサイバーノーガード状態なので identity checking を行う。この際、秘密鍵、公開鍵は以下のように

接続 ok

接続 ok

どっちに何を置いても繋がる。秘密鍵があれば公開鍵は生成できるので、より信用できるホストに秘密鍵を置いておいた方がいいかな。

接続手順

server は Zebedee の listen にだけは connect するが、実際の認証は client 側で接続要求が発生してから。

1. client を起動（これはずっと接続待ち）
2. server を起動（timeout するまで、default では 300秒待つ）
3. client に接続するプログラムで通信を試みる
4. server が timeout してなかったら tunnel が作成される

これを使えば ssh の remote forward を使わなくても「ちょっと風変わりな SSH 経由 VNC」と同じことができる。ただし、Zebedee server の timeout という制限は加わる。（ssh の場合は exit しない限り基本的には繋がりっぱなし。）