wtnabe's shlauncher at master - GitHub

こんなものを作ってみました。基本的には単純なもので

1. rake を使って
2. script/ 以下のスクリプトをリストアップして
3. 目的のスクリプトを実行
4. script/ 以下を含めたセットに名前を付けて gem 化できる

ものです。

もし似たようなコンセプトの似たツールが既にあったらニヤニヤしてください。

[2009-10-04 追記]gem化以外には rake を使わなくなりました。rake を使っていたバージョンはややこしい事情により OSX + zsh という非常に狭い環境でしか動きませんでしたが、ruby スクリプト化したことで Ruby の入っている Un*x 系プラットフォームならまずどこでも動くようになったと思います。

sh script が散乱してなんだか分からない

そもそも sh script を呼び出して実行するだけのことをなぜわざわざ rake にやらせようと思ったかと言いますと、

どんなスクリプトをそのシステム用に用意したか覚えていない

ということが発端だったりします。

最近は rake が好きなので割と何でもかんでも rake を使って作ることが多いのですが、以前作ったものは sh script やフツーの ruby script が圧倒的に多いです。でもこの形で作業用のスクリプトを増やすと、どういう作業にどういう名前のスクリプトを用意したのか忘れちゃって、「はて、このシステムでこれこれの作業をやるには何をどうすればいいんだっけ？」となってしまうことが増えてきました。¹

まぁドキュメントを整理してあればある程度はなんとかなるんですけど、ドキュメントは書くのも探すのもコストだし、いろいろ面倒くさくなって似たようなものをもう一度作った方がはえー、なんてこともあるわけです。

これはいけない。

そこでできるだけドキュメントを書かなくても何ができるのか分かるようにする方法を考えました。思いついたのが「rake に task として登録してあれば、たった一つのアプリの起動だけ覚えておけば、何ができるか一覧にできるじゃないか」ということです。

本来は rake は -T を付けないとタスク一覧は出してくれませんが、一覧を出す task を default で定義しておけばいいだけです。

システム固有のスクリプトの置き場所とバージョン管理問題

もう一つ、これも以前から悩んでいたのが、

そのシステム固有のスクリプトの置き場所とバージョン管理システムの相性

です。

伝統的にはこれらは

/usr/local/bin
/usr/local/sbin

などに収まるものだと思います。置くのはいいんです。でもそのまま直置きしてしまうと「バージョン管理しにくい」です。さすがにこれらのディレクトリを丸ごと working copy にしてしまうのはなんか変だなと思いますし、じゃあどっか別な場所に置いて make install とか毎回やるの？ ²

そこでいま採用しているのは「スクリプト実行用のユーザーを一人用意して、そこにスクリプトを展開してしまう」方法です³。この方法は複数あるスクリプトを一気に deploy するのが楽になります。しかし同時にこれらのスクリプトは system wide な PATH 上には置かれていないので、実行するユーザーが増減すると面倒なことになります。要するに覚えていないと呼び出せないスクリプトの、さらに置き場所まで分かっていないといけない、という高コストな方法なのです。

そこで rake task を gem 化できればインストールしやすく、かつスクリプトの修正はどのユーザーでも行うことができる状態になるんじゃないかと思ったわけです。

プラットフォーム固有のパッケージシステムの問題

パッケージングだけの問題であれば rubygems を採用する必要はありません。プラットフォーム固有のパッケージシステムを使えば済むからです。rpm, deb, ports, … 様々なパッケージシステムが各プラットフォームにあります。

逆に問題は各プラットフォームにパッケージシステムがあることです。プラットフォームが複数にまたがった瞬間、煩雑さがどんどん増していきます。実際いま運用しているシステムは複数のプラットフォームにまたがっていますので、プラットフォーム固有のパッケージシステムの採用は避けたいところです。

全部解決できそうな rake + rubygems 方式

そこで出た結論が rake + rubygems 方式です。

• rake で散乱する script をまとめ
• gem でインストールしやすくする

で、これらを適当なバージョン管理システムに突っ込んでしまえばよいわけです。

しかも gem 化するにはバージョン番号を決める必要がありますので⁴、ちゃんと最新の状態になっているかどうかの確認もしやすくなるはずです。

おまけ

今回のツールは script/ 以下のスクリプトを task としてリストアップして実行する機能を持っていますが、おまけとして script/ 内にディレクトリを掘っている場合、ディレクトリ名を task として指定するとその中のスクリプトを全部順番に実行するという機能を用意してあります。

これは以前

• periodic と run-parts
• run-parts(periodic)で mail の送信先を変更する
• periodic_forwarder を書いた

などで触れた、複数のスクリプトをまとめて実行する機能を独自に実装したものです。中を読めばビックリするほど簡単で実装なんて呼ぶのもおこがましい状態ですが、これが run-parts や periodic を使わずにできるようになったことも個人的には大きな収穫です。

仕様と既知の問題

1. rake task としてリストアップするために、スクリプト内には必ず何らかのコメントが必要
2. 引数を取る sh script は今のところ登録できない

1 は仕様です。最低限のコメントをすぐに閲覧できるように強制することで、運用の際に迷うことがないようにした方がよいという判断です。

2 はちょっと解決の方法を思いつきません。rake task は引数を取ることができるし、sh script に引数を渡すことも可能だと思いますが、任意の数の引数を自由にやり取りする方法が分からないのです。お手紙待ってます。

[2009-10-04 追記]task の実行の際に rake の利用をやめたので引数はほぼ自在に渡せます。

cutagem（と、あといろんなもの）に感謝

最後に、cutagem の作者、cho45 氏、genki 氏に感謝します。cutagem がなければ gem 化しちゃえばいいじゃんなんて、今の自分が軽々しく発言することはなかったと思います。それくらい cutagem は簡単に使え、十分に自分の目的を満たしてくれます。rubygems の作り方を自分が初めて delicious にブックマークしたのはもう2年以上前の話です。そこからたいした理由もないままウダウダと実際にやってみることを避けてきたボンクラな自分でも、「cutagem なら簡単だ！」と思わせてくれました。本当にありがとうございます。

関連つぶやき

twitter落ち穂拾い。基本的には mirroring で再現しにくいサーバを手早く起こすことを目的に語っています。ほとんど同じ仕事をするサーバを増やす（スケールアウト）ためのセットアップの簡略化は Web 上でよく見かけますが、そういう要求ばかりじゃないんだよーということが言いたいようです。

• Twitter / wtnabe: 冗長化によって 24/7 を目指すサーバではないが、 …
• Twitter / wtnabe: ドキュメントをしっかり書けば確実なセットアップは可能 …
• Twitter / wtnabe: 同じサーバのセットアップを手早くやる方法としてはやは …
• Twitter / wtnabe: 最近思いついたのは自作 sh script とか r …
• Twitter / wtnabe: rake を使うのは好きだからっていうのも理由だけど …
• Twitter / wtnabe: そういうのはみんな rake にまとめてコメント書い …
• Twitter / wtnabe: なぜ rubygems かと言うと、例えば pear …
• Twitter / wtnabe: 「なぜ rubygems か」続き。gem にはなん …
• Twitter / wtnabe: pear は package 作るのも pear サ …

PHP をどうしても dis っちゃうのはクセみたいなもんですね。脱線するからよくないんだけど、マルチプラットフォームのパッケージシステムの例として出すのは一応間違ってないと思っています。

PHP は（っていうか Web アプリは、だっけ？ もう忘れちゃった）呼び出されたスクリプトのパスがカレントディレクトリになるので相対パスの計算が楽ちんなんだけど、Perl スクリプトを CLI でテストしてると本番動作時のディレクトリとテストコードのディレクトリが違って、相対パスの計算がずれる。

もちろん中で全部 __FILE__ や $0 のフルパスを基準に計算するようにしておけばいいんだけど、昔はそんな知恵なかったし File::Spec も知らなかったんです、ごめんなさい。

それにしても「昔の自分の書いた」「中途半端にレガシー」なコードもタチが悪いなぁ。上のパスの計算のほかにも、なんとなく OO っぽいけど package が分かれてるだけで class として閉じ切ってないとか、依存性を内部に抱えまくってるとか、まだまだ一つのメソッドブロックが長くて処理を追いにくいとか、おかげで、テストがないからテストを書き始めるんだけどうまく書けないとか、いやーあっはっは。¹

はぁ o…rz

まぁ自分が成長したっつーことではあるんだが、自分が成長したからといって過去のコードは自動的に成長しないので、成長したら成長したなりに苦労が増えるというこの不思議。もっと寿命の短いコードを書けばよかったのか！

……。

それを最初から狙うのもなんだかさみしい話だよな。

category_to_tag も tDiary grep¹ も CSS も問題解決。途中 tb.rb ってどこにあんだっけー？と探したり、permission の設定ミスって Internal Server Error 出したり、いつまで経っても CGI の更新は億劫な作業なんだな、これが。

今回 tDiary 2.1系に上げたのはやっぱ category_to_tag が使いたかったから。これは今まで日記のサブタイトルの部分に列挙されていたカテゴリ名をイマドキの blog ツールっぽく tag として表示してしまうというずっこいプラグイン。実は「カテゴリ」に積極的でなかったたださんが「タグ」なら使うよということででっちあげちゃったもんなんだけど、まぁおかげで日記のタイトルがうざくなくなるのでありがたく使わせてもらおうってわけ。さーばんばんカテゴリ増やすぞ。del.icio.us 使っていちばんの収穫はこの「タグは便利だっていう感覚」だったかもしんないな。

輸入車ユーザーはアップルがお好き？–輸入車ユーザーのPC購入実態調査より (CNET Japan)

これは久しぶりに面白い。（1ページめのグラフがおかしいけど。）

自分に当てはめると（外車乗ってないけど）、IBM & Apple & 自作ユーザーで、あえて乗りたい外車を挙げると OPEL, VOLVO なんだけど、OPEL ユーザーの IBM 所持率がドンピシャで笑える。Apple 率もミニ、ローバー、VOLVO が高いのでなんとなく当たりな感じ。なるほどねぇ。

実際のソースとの関係が分かりやすいように sample.pm を書き、ここから pod2XXXX で作成したドキュメントと、Pdoc で作成したドキュメントを作成。これを download に置いた。

で、これを textfile.org にタレコんでみた。少しでも Pdoc についての日本語の情報が増えてくれると嬉しい。

from ケータイWatch

携帯は市場として勢いがあるし、新しいコンテンツが既得権益とぶつかってもちゃんとした喧嘩になるのではないだろうか。PC ヲタ、ハイテクヲタが立派そうな理屈をかざすよりも、ずっと効果が大きいはず。もちろんそれが自分を含めたヲタの望む方向に行くかどうかは分からないが、現状の権利処理の煩雑さと矛盾が今よりクローズアップされるだけでも、何かが変わるのではないかと思いたい。

CSS の @import 規則は、これに対応していないだめブラウザでのだめ CSS 適用を避けるために使えるものなのだけど、意外な落とし穴にハマってしまった。それは

wget も @import には対応してません

ということ。まぁ当たり前なんだけど、実際にやってみるまで気づかなかった。てことはやっぱ media 属性をあれこれした link で読み込むしかないんだなぁ。ちょっと悔しい。

ミ゛ィミ゛ィミ゛ィミ゛ィ〜ンとギターの鳴くオープニングに虜になってしまった未来少年コナン。実はこの作品の設定では超磁力兵器により地球が壊滅的な被害（五大陸が沈むとか地軸がねじ曲がるとか）を受けるのがなんと 2008年の7月なのです。あと4年しかない！

しかし世界を壊滅的な事態に陥れるような兵器の開発に割く予算は現在の地球上には存在しない感じで、紛争の火種をでかくして世界的規模のテロを生んで軍需産業とオイルダラーを育てるくらいしか兵器や戦争という意味合いでの脅威はなかったりします。（ジョークですぜ、念のため。）

むしろ食生活や細胞（というか細菌か）・遺伝子レベル、そして温暖化で自滅への道を地味に歩んでいることの方が怖かったりしますな。アレルギーって、これを災害と捉えると、実際どれくらいの額になるんでしょうか。文明は本当に生活を豊かにしてるんですかねぇ。