あるいは StuffIt Expander はやっぱ腐っていたのか、の巻。

Widget の話で、あーやっぱクロスプラットフォームな GUI ツールが作れたら便利だよなーと思い出し、夜中に夢の中の何かにえらくむかついて目が覚めたこともあって昨日はふらふらと XUL とか調べていたんだけど、Firefox とか Thunderbird が入っていても XULRunner は別途必要なのかー、面倒くせぇなぁとか、つか XULRunner の Firefox 2.0 に対応するバージョンて contrib しかねーよぉとか、釈然としないものを感じておったわけです。

今回は Y! Widgets のときに思い知らされた、「GUI アプリは IDE の支援がねーとやってらんない」という考えをベースに eclipse との関連を調べていたので、そこでハタと SWT を思い出す。SWT って Java 以外で使えねーの？とか調べ始めたわけですけど、

そういえば最近 JRuby 1.0 出たじゃん

ということを思い出し、JRuby + SWT の組み合わせで遊んでいる人がいないか探してみる。

いるいる。

でも JRuby って Java のいくつを要求してるのか分からん。どこを調べても Java のバージョンに言及している記述が見つからない。おいおいおいおい。基本じゃないんですか、そういう情報って。もしやと思って ports の Makefile を覗くと 1.3 以降と書いてあった。おぉ、こんなところに情報が。つか表に書けよ。本家もニュース記事書く人もこういうとこサボっちゃダメ。

よーし安心したのでやってみようということで JRuby - Home から tar玉を落としてきて、展開、環境変数を設定して、、、

あれ？ 動かないよ？

散々試したけどうまく動かない。しょうがないので jruby という shell script を読むと、lib/ の中の *.jar ファイルを必要としている様子。見てみる。ねえ。おっやー？ 同じところから jruby-complete-1.0.jar を落としてきて置いてみる。

動きゃしねえ。

ということで昨日はここで挫折。今朝はなんか、昨日の昼間蚊に刺されたっぽいおなかが妙にかゆくて目が覚めた¹のでやり直してみる。やっぱ lib/ の中身がおかしいよなぁ、というところでもしかして StuffIt で展開してるのがまずい？と思いついてコマンドラインから tar zxf してみる。

キター。

$ jruby -v
ruby 1.8.5 (2007-06-07 rev 3841) [ppc-jruby1.0]

ばーかばーか StuffIt Expander のばーか。

Swing のサンプルを起動してみる。やっぱ起動おっそいなぁ…。まだ SWT は試してないけど、とりあえず選択肢は増えた。つか SWT 知らんけど。

Trac の ticket システムは結構ステキな仕組みで、milestone 管理の際に出てくるあの進捗度合いを示すバーが伸びていくのを見たいがために、積極的に ticket を発行してタスクをやっつけてやるぞという気にさせてくれる。

あれだ。テストドリブンでオールグリーンを目指すのとおんなじ。

でだ。これって実は割と応用範囲が広くて、いろんな仕事をこの ticket システムで運用できそうな気がする。近頃流行りの lifehack だの GTD だのという単語そのものにはそれほど興味はないが、いちいち Excel や Wiki でうんうんと表を書いて管理するより ticket をほいっと発行してしまえば一覧は [ View Tickets ] の report 機能や custom query（このインターフェイスも親切でイカす）であれこれ眺めることができるので、圧倒的にこっちのやり方の方が冴えてると思う。¹

ただ問題は ticket のカスタマイズをどうしようってところで。デフォルトの ticket と Web から設定できない現在²の Trac の標準状態では面倒くさくなってしまいやすいので、これを放置して単なる ViewCVS 代わり + Wiki みたいに使ってしまうケースって、実は多いんじゃないかという気がしている。というかうちはまさにそうでした。

最近やっと時間がとれたので WebAdmin plugin を入れて ticket のカスタマイズをしてみているんだけど、component と milestone の設定次第で結構やれそうという感触を得つつある。逆に言うと難しいのもここなんだけど。

今ほしいのはシステム管理向けの Ticket の雛形。開発であればプロダクトによって milestone も component もマチマチになってくるとは思うんだけど、システム管理であれば利用しているクライアント OS や提供しているサービスが component に該当して、あとは細かいハードウェアとか、そういう感じで整理できるような気がしないでもない。

例えばネットワークサービスであれば

• smtp
• pop
• http
• dbms
• dns

とか。あーでも分けない方がいいかもなぁ。とか悩んじゃってる。まぁこれも管理するシステムによって違うか。

小規模で個々のサーバが別々のサービスを担当している場合はサーバ単位に component を切り出すのがいいだろうけど、大量のサーバが同じサービスを受け持っている場合はサービス単位で component を作っておいた方が見通しよさそう。

業務支援系のツールを作り込んでいる場合も悩ましくて、これは本来システム管理のプロジェクトに入れるべきだと思うんだけど、数が多くなってくると component がゴチャゴチャし過ぎちゃうかなという気もしないでもない。ただ、Trac 0.10 から InterTrac という仕組みが用意されているので、とりあえず丸ごと突っ込んでごちゃごちゃしてきたら分割も視野に入れましょう、というアプローチでもよいような気がしている。

そこまで分かってんならダラダラ日記書かずに仕事しろよというご指摘はごもっとも。でもこういうノウハウってどこかで共有できないかしらん。とか思ったりもしてます。

ひとつ分かった。

ticket の component を考え始めたら svn の repository の分け方を変えた方がよいと思った。今の分け方は細か過ぎる。もっと一緒にしておくべきだ。

なるほどな。こういう風に別な視点で全体を眺めると、今まで見えてなかったことが見えてくるんだな。