2003-04-11
_ OutLook 搾り出し
http://www.zdnet.co.jp/news/0304/11/nebt_06.html
IBM がサーバ製品の廉価版を Express というブランドで展開するらしい。
これを見て思ったのは「IBM よ、おまえもか」だった。
この express という言葉をうしろにつけて無料版や簡易版を表す、というのは個人的には OutLook Express が初めてだったんだけど、最近じゃ Final Cut Express も出て、さらにはサーバ関係も出てきてしまった、という感じだ。まさに「出てきてしまった。」
Express というとやっぱり真っ先に浮かぶのは特急、急行の意味かな。次にくるのは「表現する」。で、あとは出てこない。だから「〜 Express」と言われると、高速化バージョン＝料金高め、というイメージが沸いてしまうので、この命名法はかなり違和感がある。だいたい、言いにくい。Photoshop LE とかの方がなんぼかよかった。（余談だが Elements もかなりどうかと思う。本家のバージョン番号と一致しないので混乱する。Elements は 6 ベース。Elements 2 は 7 ベースかな。）
そこでアレコレ調べたり考えたりしてるうちにいい言葉を思いついた。「搾り出し」。「OutLook 搾り出し」「Final Cut 搾り出し」「IBM Integrated Platform 搾り出し」。どうだろう。
しばらくコレでいってみよう。
p.s. そんなことより WebSphere Express とか DB2 Express って具体的にどんな仕様でどんなお値段なのか気になる？ :-)
2004-04-11
_ tDiary の位置付け変更
tDiary を使った実験を始めて早10ヶ月が経つ。当初思っていたよりこのシステムが扱いやすいということだけは間違いなさそうなので、とりあえず時系列に分類を気にせずどかどか書ける雑記帳ということにして利用を継続することにした。
サイトの更新情報を楽に書くという当初の目的にも、どうにか説教講座の方で採用できそうな気配。しかし Windows との相性は悪く、その辺で作業効率が悪くなっている。なかなか難しいもんだ。
しかし、このまま書き溜めるなら検索の機能がほしいところだな、これ。一応プラグインで検索ってのは存在するらしいけど、基本は Namazu っぽい。どうすっかなぁ。
気が変わった
日記コミュニティデビューをしてみることにする。xrea での Namazu の利用方法を真面目に調べて squeeze.rb を活用してレッツラゴー。という方針にする。こっちは説教講座の方の下書きも兼ねることにする。
_ Windows であれこれアップデート
- OOo 1.1
Office ファイルに関連付けてみた。
- Apache 1.3.29
別に何も変わらず。
- PHP 4.3.4
multibyte 拡張（sjis でスクリプトが書けるとか）を施したバージョンでは Apache が起動にこけてしまうので拡張なしのバージョンに。まぁこれがなくても mbstring, mbereg は有効にできるのでいいんだけど。もう PHP で mb がどうとか気にするのはやめにするかな。
2005-04-11
_ 高橋メソッドを批判するのは中二病らしい
ネット上での立ち振る舞いを「小二病・中二病・高二病・大二病」に分類してみる遊び
あれはネタだからと達観した気になるのが高二病らしい。
もったいない。もったいないぞ。
あれは決して間違った手法ではない。ただ詰めが甘いだけだ。
とマジで返すのが中ニ病なのか？ うーん。とにかく高橋メソッドはこのままではもったいないと思う。ネタかどうか、誰かがネタと思うかどうかなんて知ったことか。もったいないったらもったいない。
例えばこのままネタ認定されると、半年とか経ったときに「古い」と言われかねない。違うんだ。ネタじゃない。あれはあるところまではとても正しい手法なんだ。だからそんなに簡単に古くならない。いや古くしちゃだめ。
2007-04-11
_ screen + emacs c/s 生活始まる
以前 mule-ucs を使いたくなくてしょうがないという話を書いたけれども、どうしても mule-ucs を使わなくてはいけないシーンが出てきた。泣ける。
このクソ重たい起動を待つことはできない。終了しないで使えばいいと言ったって、こちとらすべての作業を Emacs の中で行えるほどの強者ではない。しかしそこでピンときた。
「Emacs ってサーバにならなかったか？」
そうです。なるんです。
M-x server-start
するだけで Emacs はサーバとして待機するようになります*1。クライアント側は
emacsclient FILENAME
するだけ。サーバ動作している Emacs で
C-x #
すると emacsclient に編集終了を教えることができるので、例えば w3m + emacsclient なんて使い方も可能。（ただしこれではファイルを閉じないので、閉じるのであれば普通に C-x k の方がよい。閉じる際にクライアントが居るけどいいか？と聞かれるので、そのまま閉じてしまえばよい。）
しかし再び問題が。
Emacs のセッションを emacsclient を叩いた画面で拝めるわけではない。
のであった。要するにサーバとして動いている Emacs の画面は出しっぱなしにしておかなきゃいけないってこと。emacsclient を起動した画面は 「Waiting for Emacs...」と言ったきり黙りこくってしまうのだ。これは嬉しくない。まぁ幸いなことにこの mule-ucs を使わなきゃいけない Emacs は手元の localhost で動かすわけじゃないので、Emacs 用の screen window も一緒に動かし続ければいいんだな。
ただ、単純に screen を起こすだけでは screen -ls したときにどれが Emacs の動いている screen か分からない。そこで今度は screen 上で
:sessionname emacs-server
って打ってやる。そうすると
There is a screen on:
24693.emacs-server (Attached)
みたいに人間が識別できるようになる。この session を dettach/attach してやればよい。現在の screen の session name を確認したい場合は引数を与えずに
:sessionname
と打つ。
面倒でも、mule-ucs の起動を待つよりマシなのだ！
[追記] ついでに、エディタとしてしか使っていなかったことを反省してちょこちょこ試してみた。期待通り M-x calc と M-x calendar は存在していた。なるほどな。便利便利。というか bc があるんだからわざわざ OSX の電卓起こすことなかったんだよな。よしよし。トシを取ってもたまには環境を見直さないとね :-)
あ。ちなみに、vc-svn は使えている。vc-svn のために 22 にしたいと思っている人はよく調べてみた方がいい。
*1 UNIX ソケットを使える場合の話。Windows で Meadow な場合は UNIX ソケットは使えないので gnuserv が必要です。XEmacs とか GNU Emacs じゃないやつもそうなのかも。そこまでは試していないので分かりません。
2008-04-11
_ Rsync 3 を試す
ネットワーク越しのファイルコピーにおなじみの rsync.
今回、クライアントもサーバも 3 に移行できた組み合わせがあったので試してみた。使ったのはクライアントもサーバも rpmforge の rsync 3.0
単純に軽い
ベンチとかないんですけど、
| バージョン | CPU使用率(目測) |
| rsync 2 同士 | 20 〜 40 % |
| rsync 3 同士 | 1%未満 〜 3% |
残念ながらCPU性能も変わっているのでこの数字を出しても比較にならないんだけど、さすがに10倍も性能向上はしていないので、それを差し引いてもやはり CPU 負荷は数分の一以下になっていると見て間違いないと思う。
今までは結構簡単に跳ね上がっていた CPU 使用率が、ほんとに rsync は動いているのか？と疑いたくなるくらいに大人しいまま。これはすごい。
--iconv での文字コード変換
※ 文字コードなのかエンコーディングなのかというのはここでは問わないでください。
rsync --iconv=SOURCE,DEST
という形で文字コードを指定する*1。例えばこんな感じ。
rsync --iconv=utf8,iso88591
と、マニュアルには書いてある。でもこのハイフン抜きの表記って iconv --list には出てこないんだけど大丈夫かなぁと気になったらどうもハイフンはあってもなくてもいいみたい*2。
rsync --iconv=.
でシステムのデフォルトの文字コードを locale から推測する。
変換を無効にするには
rsync --iconv=-
や
rsync --no-iconv
とする。もちろん iconv 関連のオプションを付けないという方法でもいいんだけど、動的にオプションを生成することを考えると --iconv=- がいちばん楽かな。
daemon として動かす場合は module に charset 指定が必要
[MODULE] path = /path/to/rsyncd_root charset = REMOTE_CHARSET
って感じ。これを指定していない MODULE に対して
rsync --iconv=eucjp,utf8 rsync://HOST/MODULE
みたいに指定するとそんなオプションは許可されてねぇ、と怒られ、転送そのものに失敗する。
charset が指定したものに対して invalid である場合
[sender] cannot convert filename: FILENAME (Invalid or incomplete multibyte or wide character)
このようなエラーが出て該当ファイルの転送に失敗する。
分かりやすく言い換えると、charset の指定に失敗していると
日本語ファイル名のものだけ転送されなくなる
ということ。この動作は恐らく誰も期待していないと思う。
結論として
ファイル名の文字コードが「確実にこれになる」と言い切れない path を rsyncd の対象としている場合、iconv のオプションは利用しない方が無難。
例えば WinSCP で日本語ファイル名を転送する可能性のある領域には Shift JIS(たぶんCP932?) の名前のファイルができる。同じ場所を Netatalk 2 や Samba 3 でマウントしている場合、これらのサービス経由では普通 UTF-8 のファイル名で保存される。つまり、「Shift JIS の名前と UTF-8 の名前が混ざっている」状態になる。
この領域に対して rsyncd.conf で
[MODULES] path = /path/to/rsyncd_root charset = UTF8
と指定しても、
[MODULES] path = /path/to/rsyncd_root charset = CP932
と指定しても転送漏れが起きる可能性がある。
余談 - rsync の制限は rsyncd.conf で
いつも自動化している rsync を使ったファイルの転送は remote shell 上で rsync コマンドを叩く
rsync REMOTE LOCAL -e ssh rsync LOCAL REMOTE -e ssh
という形ではなく、daemon として待機している rsync プロセスに接続する方法
rsync rsync://REMOTE LOCAL rsync LOCAL rsync://REMOTE
を利用している。これならアクセスできるパスや read only にするなどの制限を簡単に掛けられるし、制限 shell の方の扱いも単純化できるし、rsync を叩く機械と ssh や Zebedee でトンネルを作る機械の分離も簡単にできる。個人的にはバッチ処理で rsync をトンネル越しに動かす場合は rsync --daemon + rsyncd.conf を使った方がいいんじゃないかと思っている。
_ すずき [iconvオプションの無効化のトコで「--iconv==-」と=が2個なのはtypoですよね？]
_ wtnabe [ですです。ありがとうございます。]