ただのにっき

■ 日本版iTunes Music Store

リリース文。

150〜200円という価格について、レンタルCDより高いだの変わらないだのと文句を言ってる人たちがいて、たいへんアホらしい。レンタルの方が安いなら、レンタルすればいいじゃん。引きこもってばかりいないで、外に出て遊びなさい。CD借りてくれば(その行為の良し悪しは別にして)DRMのかかっていないデジタルデータが手に入るんだ、仮に同じ値段でもはるかにお得だぞ?

オンラインストアの魅力は、なんといってもそのロングテール部分にある。リアル店舗に置けないような、マイナー曲や古い曲が、在庫を気にしなくていいオンラインストアには置けるのである。Amazonだって、ロングテールの売り上げが30%もあるそうじゃないか。iTMSだってそういう方向になるはずだ。

というわけで、スチールドラムが好きなおれとしては、まずその辺を検索。「steel」で150曲、「steel band」で30曲ひっかかる。これからさらに増える可能性があると考えれば、期待していい数字である(たいていのリアル店舗にはアルバムが1、2枚あればいい方)。なんといっても試聴できるのがいい。こういうジャンルはマイナーなせいか、「海賊版かよ」とツッコみたくなるほどひどい録音が多いからのぅ。

一方、古めの曲は……と、カラオケのレパートリーを検索してみたが、「憧れのハワイ航路」も「東京ラプソディ」も「高原列車は行く」も「銀座カンカン娘」もなくてがっくり。って古すぎ!

追記

あ、なんか興味深い調査が。

ソニーやビクターが入ってないと、けっこう買えない曲が多そうだ。特にソニーは、自前のサービスがあるからiTMSに加わることはなさげ? つまんねー話になりそうだなぁ。

■ Subversion(5)

よく考えてみたら、うちにはすでにApacheが立ち上がっていて、しかもmobileimapをport 80で使うためにmod_proxyを使ってreverse proxyを設定しているのだ。これを、通常のproxyも使えるように設定を変えれば、それだけで自宅proxyサーバじゃん。考えるまでもなかった。

というわけで、/etc/apache2/mods-available/proxy.confにあるProxyRequestsをOffからOnへ変更。キャッシュはいらないので、CacheRootはコメントにした。ポート番号はどこで指定するんじゃ……と思ったが、何も指定しなければ80番で受けて、proxyのリクエストかどうかは勝手に判断するようだ。ということで、これでOK。

あとは、サーバ側のzebedee.confに「target localhost:http」を追加。これでサーバサイドの設定は終わり。

続いてクライアント側のzebedeeに、「tunnel 10080:localhost:http」を追加。これで、port 10080にproxyアクセスすれば、トンネル経由で自宅サーバのproxyを使える。

最後に、~/.subversion/serversに以下の設定をする:

[global]
http-proxy-host = localhost
http-proxy-port = 10080

さて(各サービスをreloadしてから)、いってみよう。

% svn co http://projects.netlab.jp/svn/ximapd/trunk ximapd
A  ximapd2/plugins
A  ximapd2/plugins/expirer.rb
(以下ずらずら〜)
リビジョン 204 をチェックアウトしました。

よっしゃっ! というわけで、前田さんから面白い情報をもらってはいたけれど、今回は必要なくなりました。ども。

念のため(←自分で忘れそうなので)、各サービスの関連図を描いておこう。長い旅路だなぁ、おい。

■ Subversion(4)

「CVSupのSubversion版みたいのが欲しいんだよね」と思ってイロイロ探してみたんだけど見つからなくて困っていたら、サクっと「それはsvkである」的なツッコミをもらったのであった。やっぱ人力検索(違)はすごい。まさか「分散」がキーワードになってるとは思わなかった。

で、これを自宅サーバに入れて、リポジトリのコピーを作り、トンネル越しに職場マシンからアクセスすればいい……と思っていろいろいじってみたが、svkは本当にローカルにだけコピーを持つという思想らしく、リモートアクセスをサポートしてない。リポジトリの位置がそもそも「~/.svk」で決め打ちなのであった。

で、実装はsvnのラッパーなので、職場マシン上リポジトリを構築しようにも、やはりproxyの問題でそれはできない、と。がっくし。いいアイデアだと思ったんだが。

で、自宅にproxyを作ったらという案を応用して、(とりあえずximapdだけ欲しいので)ダイレクトにprojects.netlab.jp:80につながるトンネルを掘ってしまえ、とzebedeeをいじる。そしたら、うっかりして自宅サーバ上のzebedeeを落としてしまった。トンネルの出口を爆破して埋めてしまったようなものである。これでもう自宅サーバにアクセスできないので、今日はここまで。あぁ、もう。

■ Subversion

やまだあきらさんがximapdのMLにもりもりパッチを投げまくっているので、「こりゃTrunk HEADに追従しないと乗り遅れるかも!」と焦り(←客観的には焦る必要なし)、重い腰を上げることに。ってつまり、Subversionを入れたってことなんだけど(おせー!)。

といっても、こんだけ:

% sudo apt-get install subversion

で、ximapdは職場で使っているので、proxyを通さないと社外のリポジトリは使えない。調べたところ、~/.subversion/serversを書き換えるらしい。設定はこんな感じ?:

[global]
http-proxy-host = proxy.example.com
http-proxy-port = 8080

で、coしてみたら、ダメなのだった:

% svn co http://projects.netlab.jp/svn/ximapd/trunk ximapd
svn: REPORT リクエスト (相手: '/svn/ximapd/!svn/vcc/default') が失敗しました
svn: REPORT (URL: '/svn/ximapd/!svn/vcc/default'): 400 Bad Request
(http://projects.netlab.jp)

Status 400って……。proxyのいらない自宅サーバ上でやると問題ないから、svnの使い方は間違ってないんだよな(たぶん)。これは会社のproxyの設定に問題があるってことか?(→コレかな?) 上流のproxyにイチャモンつけるのは難しいなぁ……。自宅でsvn upして、それをscpかrsyncで取ってくることにするか。

……というわけで、ただいま先っぽに追従中。

■ Subversion(2)

せっかくなので真面目に使うテスト。自宅サーバのCVSリポジトリを変換してみよう。ブランチも切ってないから、素直にコンバートできるだろう。もっとも、CVSでも何も困ってないんだけど。

ツールはcvs2svnを使うらしい。保存形式には悪評高き(?)Berkeley DBじゃなくて、そろそろ安定してきたと言われているfsfsを使うことにする。

% sudo apt-get install cvs2svn
% cvs2svn --fs-type=fsfs -s ~/svn /var/lib/cvs

うんうん考え込んだあと(マシンが遅いので)、コンバート完了。これを、ssh経由で職場のマシンからアクセスする。真面目に(といっても関係のありそうなところだけつまみ食いのように)マニュアルを読んでから:

% cd ~/tmp
% svn co svn+ssh://tsukuba/home/sho/svn/trunk/www/komainu

ずらずらずら〜とcheckoutされてきた。成功だ。スムーズすぎて怖い(←珍しくちゃんとマニュアルを読んだからだと思われ)。

■ Subversion(3)

よそのレポジトリを職場からGETできるようにするには、自宅サーバに本家のコピーを持たせちゃえばいいんだよな。そうすればsvn+sshで取れるわけで。でもcvsの-dオプションみたいに、commit先のレポジトリを無理やり変更することはできないみたい……? svn switchが使えるかと思ったけど、違うようだし。

結局、ximapdについては、

• svn exportした本家の内容を自宅サーバのレポジトリにsvn add、svn ci
• 本家の内容を反映するときは上のディレクトリにsvn export --forceで強制上書きしてからsvn ci

って感じにしてみたが、スマートではないよなぁ。まぁこれだと、少なくとも自分で書いて追加したpluginなんかは問題ない。ファイルの追加や削除があったときには少し困る(が自動化は可能か?)。ローカルパッチがどうなるかは……そのときになってから考えよう(汗)。