拳功房主宰の山田先生(ウチでは勝手に「山田編集長」と呼んでますが)とは、縁あって、池袋道場→高円寺道場時代に一年弱ほど(実質は半年くらいかな〜)通っていたのですが、当時私が腰を痛めていたこともあり、北葛西に移ってからはとんとご無沙汰していました。

現在は均整のおかげで腰も治り、無極会に通っているのですが、陳氏の(というか拳功房の)バチバチしばき合う感触も懐しく、いろいろついでもあって久々にお邪魔した次第です。

山田編集長にはときどき本をいただいたりと、日頃お世話になっていることもあり、一度は顔出さないと、という気持ちもあったのですが、無極会で、きわめて「おとなしい」修行を一年間やってみて、果たしてその効果は? 他でも通用するのか? という好奇心が一番大きな動機でした。

なお本来、私のような初心者／初術者がホイホイと道場をわたり歩くのはあんまり行儀が良いこととは思えないのですが、ここはやはり、後述の「開かれた検証可能性」というところを自分で実践できていないと本当の武術愛好者とは言えないのではないか、と思います、ということで自己弁護自己弁護。

道場に行ったのは午後も大分回ってからだったので、基本功等は終了しており、三才剣を使った稽古から参加。はじめて触る「剣」に少々とまどいましたが、まあどうはいっても中拳ですから、基本の動きは一緒、ということでなんとか動きを真似て動いてみました(「中華剣はペラっとしている」という知識はあったものの、剣道を何年かやっていた身としては、「峰」側でも切りつけられる、というのが一番混乱しますね。。)。長いものを持っていても、身体の重心の動かし方は一緒なので、軸がしっかりしていれば、案外剣先はそれについて来るものです。

次はサンドバッグ。突きはともかく蹴りは無極会では全くやっていなかった(というかまだそこまで私が到達していない)ので、分脚とか後ろ回し蹴りとかでヨロヨロ、と。ただ、最後にやった靠は、日頃やってる「歩き」の延長にある動きなので、実に自然に身体が動きました。まっすぐ載せた体重がサンドバッグに伝わる感触はなかなか気持ちの良いものです。「ああ、拳功房時代はこういう時の骨盤の立て方がわかってなかったなあ」と(ただでさえ悪い腰をさらに痛めまくっていた日々を)懐しく思い出しました。

さらに対面してのコンビネーション。最後の方の突き蹴り8コンボくらいを攻防するのはサッパリ覚えられず、いちいち教えながらの攻防となってしまったIさんはじめ、道場のみなさまには多大な迷惑をかけてしまいましたが、最初の方の突きを受け流しから押し返す動きなどは、その昔(陳氏老架の)抱虎帰山教わって、「腹が動いてない。全然ダメ」「???」となったことなどを思い出しつつ、むしろ当時よりもよく動けるようになっているなあ、と実感。

とまあここらでお暇(それでも2時間半くらいやってた)したんですが、聞けば彼らは10時から17時くらいまでずっとやっている(途中で帰る人もいますけどね)、とのこと。そりゃサンドバッグ吊ってる帯も切れますわな(実話)。

# ちなみにサンドバッグが(たぶん八極の)突きで上下に揺れまくるのは初めて見ました。どういう発勁してるんスかねホント。。

というわけで、結論としては、無極会でやっている動きは拳功房でも通じる(表面的な内容は相当違いますが、基本原理には相通じるものがある)、と感じました。見せかけの表演でもなく、力まかせの打撃でもなく、人体の構造、武術の理論を真摯に極めようとするその姿勢はいずれも同じ、ということですかね。拳功房、無極会、どっちも素晴しいですよ、ということで、ひとつ。

とはいえ、拳功房で急に動くと、さすがに体幹だけではなく、その先の骨格筋も大分痛めつけることになるので、翌日は派手な筋肉痛になりました。(上腕三頭筋いたい。。)

ちなみに、拳功房のリクツをてっとりばやく知るにはこの本、ですかね。ネット上ではいろいろ批判も多い(ただ、そのほとんどが厨二レベルか、理屈に理屈を重ねた類のもので、前者は論外として、後者も「検証可能性の開示」という意味ではマトモに取りあげるレベルにない)ですが、徹底して「実証できることしかやらない」という気骨がある、なかなか真面目な本だと思います。

というわけで、シェルで繋いだ先でファイルを取得したい時のTIPSをいくつか。

●とりあえずリンクはわかっている場合

だいたいの場合、該当のファイルが置かれているサイトをWebブラウザで開いていることが多いと思うので、まずリンクを右クリックでコピー

シェルに切り替えて、ダウンロードしたい場所に切り替えて、wget “コピーしたリンク”

●リンクはわかっているけど、なんか遷移しそうな予感がする場合

これは経験則によるところが多いのですが、リンクのお尻が.zipとかで終わっていない場合、あとはurlをよく見るとダウンロードファイル自体が置いてあるサイトのurlが内包されている(/down.php?http〜/file.zipみたいな)場合、多いです。こういう場合は、wget/curl -Oはうまくいきません。では、どうするか。

w3m “コピーしたリンク”

TABキーをしばくとリンク文字列をおっかけてくれるので、該当ファイルのところまで進む→Enter

ファイルのダウンロードの確認をしてくるので、Enter

Qキーで終了。確認(y/N)してくるので、y

こんな感じで、まんまと入手できます。

●ファイルの展開時の注意

だいたいの場合、フォルダに入れて配布してくれているのですが、まれにそうでないタイプのアーカイヴをしている人がいます。これをコマンドラインでunzipすると、そのディレクトリに直接ファイルがぶちまかれることになり、大物かつ第一階層にたくさんファイルがあるモノの場合、たいへん悲惨なコトになります。さらに、index.phpだのREADME.txtだのが上書きされることもあり、なかなかの惨状を呈することがあります。しかし、毎回mkdirするのもめんどうだし、大体の場合はちゃんとフォルダを作ってくれるので、フォルダがムダに二階層になり、さらにその構造の修正でコマンドをびしばし打つ、という非生産的な作業が発生しがちです。

では、どうするか。

vi “落として来たファイル”

これで、内容のファイル構造がブラウズできるので、該当のブツがフォルダに入っているのか、その階層にぶちまけられてしまうのか、があらかじめわかります。超便利☆

多くのサーバでは、wgetでなくcurlが、w3mでなくlynxが入っていると思いますが、私はどちらも前者を愛好しているので、みんなもインスコするといいよ! (と、説明をはしょる漏れ)

nmlをシャッフルシャッフル! -2などで書いたように、ナクソス・ミュージック・ライブラリー(以下nml)の全データベースから一曲、選んでは聴く、ということをやっているんですが、クエリ投げると、「全186720件の検索結果(2009-04-03現在)」なんて数字が返ってくる。ほほう18万とはスゴいねえ、しかも日々ガンガン増えてるし、と感心しきりだったのですが、ふと、サイトをよく見ると

今日現在でのNML登録アルバムは、CD ：30,218枚、431,185曲！

(「Urtext」が新規参加 – NML新着情報より)

などと書いてあります。アレ? 43万? なんか多くね? つーか誤差と言うには無理でね?

というわけで、真っ先に自分のコードを疑った(笑)わけですが、どうも問題なさげ。
数日もんもんもんもんとしたあげくnmlのサポートにメールしたところ、「いやーウチでは曲数=トラック数なんですよはっはっはっ(※注：誇張された表現)」と返事が来て、まあ文面も丁寧だったし、表示については検討中とあったし、何よりその時点での最大の問題点は「自分の書いたコードは正しいのか、どうか」だったので、そうですか、では一件落着、だった……のですが。

こちら、本日のnml@本国の表示。

な ん ぞ こ れ

「429,000 tracks」って書いてあんですが。。。曲数じゃないじゃん。いやしくもクラシックを中心とする音楽配信サービスが、本国の表記をねじ曲げてまで、クラシック音楽的には全く馴染みのない、楽章(など)ごとに区切られた要素を「曲」と表現するのはおかしいでしょう。

これって不当表示スレスレだと思うのですが、というかわざわざいらない誤解を誘発する地雷を自ら設置してるような気がするんですが、藻前はミンスか、と。どーなんでしょうねナクソス@日本さま。

新機能追加も大いに結構ですが、賢明な対処を切に願います。

みなさん、あれこれあれこれと対策を挙げてらしたのですが、残念なことにワタシの環境ではうまいこと解決しませんでした。

…が、ついに解決！ 解決方法はこちら。

「同一サイト内の、すべての.htaccessにおいてmbstring.func_overloadの設定をしない（より正確に言えば、php.iniを含むすべての個所でmbstringがらみの設定をしない）」

御存じの通り、.htaccessはディレクトリごとにapacheの設定を制御できるので、ちょっと入り組んだ構造のwebサイトを構築している場合は欠かせない存在なのですが、なぜかmbstringがらみの設定に限っては、「漏れ」てしまうんですね。で、他のところでエラーを引き起こし、結果的にサイト全体にめちゃめちゃ負荷がかかる、と。

func_overloadはあんまり好きではないので、普段は使っておらず、この指摘に気づいた時もしばらくは、「えーそんな設定してないしー」とサイト全体を確認していなかったのですが、よーく考えたら、egroupwareが.htaccessにこの設定を書いていた、ということを思い出し、コメントアウト。再起動。apacheが……重くならない！　MaxRequestsPerChildを通常値に戻しても大丈夫。やったー！　ここ数か月悩みつづけていた問題がついに決着！

というわけで、もし同様のお悩みを抱えている方はぜひおためしを。いやー長かった。multibyte系の話題のせいもあって、あんまり情報がないんで苦労したんですよねー。（しかし2004年からのバグなのか。。それに、cvs版でフィクス、って言われてもなあ。。）

ところで。

Bug #27421 mbstring.func_overload set in .htaccess becomes global

決め手となったのはこの記事なんですが。。。
アレ？　上述の記事内の引用記事からすでにリンクされていた？（汗）……まあ……いいか！

nmlシャフラー2

まあ、いろいろ問題を抱えたコードのような気がするが、、、まあ、いいか！

[2008-12-04追記] cache-controlがヘッダに入っているのでおんなじ検索結果が二回ずっこ出ることに気づいたので、そこら辺をゴリゴリと。

[2008-12-14追記] セッション寿命の問題なのか、シャフラーが動かなくなってしまった。ヘッダをキャプチャしなおして、__EVENTVALIDATIONの値を最新のものにしてとりあえず解決。うにゅー。

[2009-02-22追記]まれにときどき動かなくなるものの、__EVENTVALIDATIONをいじらなくても復帰するように、いつの間にか、なった。まあ、めでたい。

[2009-02-23追記]nmlのライブラリアンが怒涛の勢いでトラックを突っこんでくるので、シャッフルする数値の母数の更新がだんだんメンドくさくなってきた。というわけで地味に改良。アクセスしたときに検索全件が表示されるので、その値をmb_egrep()で切り出して、テキストファイルに保存。次回のアクセス時はその数値ベースで乱数を発生するようにした。まあ、母数17万もあるんだから、そんなに頻繁に更新せんでも十分な気もするが、自動化マンセーということで。

最近、もろもろの事情からphp5.2.6を導入後、webサーバの挙動が極端に遅くなることがあることに気づいた。ちょっと負荷が、といった程度ではなく、えんえんと高負荷状態が続き、そうなると大抵のサーバはメールサーバも兼ねているので、そっちが遅延しだす。ヘタするとnamedがコッソリ落ちたりする。ワームが喰いついた形跡もないし、サーバを再起動すると何事もなかったように復帰。

で、いろいろと原因を探ったところ、httpd/error_logにこんな記録が。

[Sun Nov 16 11:47:54 2008] [error] [client xxx.xxx.222.55] PHP Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in /xxxxxxxxx/wp-includes/gettext.php on line 91
[Sun Nov 16 11:47:54 2008] [error] [client xxx.xxx.222.55] PHP Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 in /xxxxxxxxx/wp-includes/gettext.php on line 91
[Sun Nov 16 11:48:29 2008] [error] [client xxx.xxx.222.55] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /xxxxxxxxx/wp-includes/streams.php on line 92


うーん、わけわからん。とにかく、gettextまわりがよろしくない、ということで、いろいろ調査。

WordPress › Support » PHP Warning: unpack() [<a href='function.unpack'>function.unpack</a>]: Type V: n

ま、そのものずばりの話ではあるんだけど、結局「WPLANGを空っぽにするとイイよ」という投げ遣りな回答。いや、まあ、それはそうなんだが。。。(ちなみに、コレをやると、一見管理画面の国際化がなされなくなる「だけ」に見えますが、gettextが絡むタイトル表示部分とかの、「外見」部分が若干おかしくなるのでオススメしません)

A PHP mbstring bug? | Jure Merhar

こういう話も。たぶん、コレが正解に近いと思うし、wordpressのgettextクラス(特に2.6xのやつ)はこれでもか、と修正コードが並んでいるんですが、ソレにしても解決せず。とにかく、なんか起きてしまったhttpdのプロセスがめちゃくちゃリソースを喰うので、それらが切り捨てられる(タイムアウトする)までは問題は解決しない模様。

今のところウチでの解消方法は、httpd.confで、

MaxRequestsPerChild 16
※デフォは4000。プロセスの「再起動までの寿命回数」を決めるので、(メモリリークするプログラムを抱えていない、健全なサーバであれば)大きな値を指定するのが推奨。

と超短命にして、「プロセスごとにこまかくapacheを再起動」というコスい戦術。

Firefox2.xだと、管理画面上にエラーが現れて更新自体うまくできなくなったりと、とにかくスッキリしないこの現象、どなたか情報プリーズ。

[2009-01-17追記]解決しました。

ムシャクシャした……わけではないんですが、こんなものを作ってみました。

nmlシャフラー

なにもかも面倒になり、ナクソス・ミュージック・ライブラリーで選曲するのすらめんどくさくなった、そんなハート様ゲイラ(素で間違えたorz)のような貴方に贈る、「全ライブラリから勝手にピックアップ」をそこそこ支援するすごい300秒で作ったWebアプリ。

全件取得クエリを放ることになるんで、結果がちと遅いとか、まあ、いろいろありますが、意外と楽しいですよ。いやホント。

ま、曲数はどんどん増えるからメンテが面倒だけどな!

[2008-11-20追記]
ぬあーリニューアルしよった。そして全曲目へのアクセスがかなーり困難に。。。IISとかaspとか、さっぱりわからんのう。。とりあえず、11月中は旧サーバを見るようにして、なんとか対処せねば。

[2008-12-08追記]
nmlをシャッフルシャッフル! -2 に続く。

qemuで、何を今更の問題に遭遇。
それは、「qemuホスト(192.168.0.H)→ゲスト（192.168.0.G1）にメールすると、ちゃんと流れない」問題。/etc/postfix/main.cfを何度見直しても、「loops back to myself」となる。

これは困った。

ウチでは、qemuのネットワークはeth0に仮想的にipをバインドして、ルーティングすることによって実現している。

具体的には、ゲストマシンのipアドレスは、ホストマシンのeth0:1、2……に当たっている。で、ゲストマシンは実際には192.168.G1.G1というアドレスが当たっていて（これは外部からはわからないし、到達もできない）、ホストマシン上でルーティングするような設定になっている。

つまり、ホスト→ゲストにメールをしようとする、ということは、とりもなおさず自分自身にメール、ということになる。
そう、「loops back to myself」になってしまうのである。

これを防ぐには、ホストマシン上で、192.168.0.Hからの問い合わせのみに反応するdnsサーバを立てる。

allow-query{
127.0.0.1;
192.168.0.H/32;
};
allow-recursion{
127.0.0.1;
192.168.0.H/32;
};
allow-transfer{
127.0.0.1;
192.168.0.H/32;
};
forwarders{
普段使いのdnsサーバ;
};

とかやって、


@ A 192.168.0.G1
www A 192.168.0.G1
;mail A 192.168.0.G1
mail A 192.168.G1.G1
ftp A 192.168.0.G1

的なゾーンファイルを書いてあげればよい。

（この問題は、メール固有の問題とも言えるので、メールサーバの設定で解決する方がスマートかもしれない。その場合、/etc/postfix/main.cfでtransport_mapの設定をちゃんとやれば、解決するらしい）

……というわけで、4年前におすがりした、qemuの記事を公開してくれている山森さんには今回も大変お世話になりました。この場を借りて御礼申し上げます。

気をとりなおして。

マカーといえばDTPやったりDTMやったり、ということで、計算機を「プロ用の器具」の延長として使う人が多かったので、「テキストを選択したら色を紫にして18ptのHelveticaにx1000回」的なニーズに応えられるQuicKeys的ユーティリティは絶大な支持を得ていたわけですが、その後DTPアプリ自体、スタイル構造の整備とかでオブジェクト指向を強め、また、ヒストリ機能、スクリプト機能といった自動化支援機能を自前で用意するものが増え、OSベースではAppleScript自体が大幅に高速化し（でもすべてのアプリがスクリプタブル、という状況はついに来なかったなあ）、一方web系の人間はスクリプト言語が必修科目になった頃からこの手のツールはめっきり影が薄くなってしまっているわけですが、ま、それでもAppleScriptとAutomaterではイカンともしがたい「ちょっとした一連の動作の繰り返し」というのはあるわけで、まあ昔を懐かしみながら使うのもなかなか良いですよ、と。アプリによっては、Mac OS Xが持っている「キーボードショートカット」機能で動作を指定してもうまくいかないこととか、結構多いし（しかし漏れ自身はこのアプリを単なるProgram Switcherとして使っているだけのような気も）。

この手のツールはシステムの結構深い所を触るので、それなりにアップトゥデエトでないとよろしくないなあ、ということでようやく2.x系から3.2にアップ。Web系のオートログインとか、それなりに便利そうだけど、ことweb系に関しては「自分だけ便利になる」tipsってあんまり萌えないんだよねえ。。あーでも自分でWeb鯖上げると、外部からマクロ叩けるようになる……のか？　そうすっと管理人としてはマシンを遠隔操作できるのはラク……かなあ？　……ぶつぶつ。

……ということで、忘れた頃に気付いたジャブの打ち方。伝統武術系をかじった人ならだいたい気付いていると思いますが、ビリー隊長の動きは伝統系のカラテの動きを多くつかっています。で、フツーに「ジャブ」とか「ワンツー」とか言ってますが、身体の使い方がボクシングと真逆です（多分）。

●漏れが考えるボクシングのジャブ（オーソドックス）

・左手前、左足やや前
・腰を左に切る
・肩が引ける反動で、左手が最初にあった位置から振り出される
・腰を右に切る（腰つーか、腹筋〜胸筋かな）
・左手が引き戻される

もちろん、スピード命だから、腰をグルングルン回すわけではないのですが、こういうイメージで打たないと、もろ手打ちになってしまうはず。
で、この打ち方だと、足は動かないんですね。むしろ、歩いている→止まる←ここで打つ、みたいな感じ。

しかし、ビリー隊長の動きでは、打ち終わりで右足のかかとが上がっている。従前の打ち方だと、打ち終わりは筋肉で「壁」を作って拳を急停止（引き戻し）させなければいけないので、カカトが浮くなんてことはあり得ないわけです。だから、「ジャブ（前進）→ジャブ（前進）→ジャブ（前進）」とか言われると「やりにくいなあ」とか思っていたわけです。なんか、「弾んで！」とかいってるし、力入れづらいし。

「ビリー隊長のジャブにはリアリティがない」
そう思っていた時期が漏れにもありました。（AA略）

しかしある日、ふと「ビリー隊長の蹴りはあれだけ伝統風なのに、パンチだけはボクシング風、などということがあるのだろうか」という疑念が湧き、あらためてジャブ（と称しているもの）の動きをしかと見てみると、全然上述の動きではないことに気付きました。

●ビリー隊長風「ジャブ」の打ち方（同じくオーソドックス）
・左手左足前。つま先と踵のそれぞれ四点を意識
・右足を、爪先を軸に外旋。踵をスライドさせて身体を前に送る（左足は爪先を軸にやや内旋するか、半歩弱くらい踏み出す）
・左腰、というかむしろ尻を前に突き出すイメージで
・同時に左拳を振り出す
・右踵が着地すると同時に打ち終わり
・重心の移動で拳を出すだけなので、上半身はほとんど力まない。肘も伸ばし切らない（「伸ばすと首に来る」って隊長も言ってるし）

……というわけで、うむ、これなら「弾んで」打てますな。なるほど、井桁を崩すような動きなのですね。納得。
スピードは出せないかもしれないけど、距離は稼げるし、身体を使う上で効率もよさそう（ボクシングのリングで使ったら一発も当たらなそうだけど。。）。なかなか奥が深いですなー。

[2008-02-22追記]
「カカトが上がるのはあり得ない」のは言い過ぎ。フットワークしているときはカカトが常に上がっていることの方が多いですね。ただ、ベタ足で打ち始めたとしたら、打ち終わりにカカトが上がる、というのはやっぱりあり得ない。やってやれないことはないけど、すごいやりにくい。上がっていたら上がりっ放し、ベタ足ならそのまんま、というのが正確な表現、かな。
で、ビリー隊長の場合は、カカトは外旋した結果として、上がっている。明らかに動きの系統が違う、というわけです。