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

日本語ではgtd-phpの情報はあまりなかった（とりあげられてはいるんですけどね）ので、最初はなんじゃーと思っていたのですが、しつこく触っているうちに、このアプリが、「すべてをいったんプロジェクトに入れて、そこからactions/waiting on/references/someday maybeに振り分ける」という思想で作られていることを理解し、「なんて型にハマっているんだ！！（注：プラス評価）」とカンドーして、しばらく使っておりました。

ただ、使っていくうちに不満も出てきて、とりわけ致命的だったのは、「すべてはプロジェクトに属すべし」という、この縛りに対する自由度があまりにもなかったこと。それと、ちょっとだけ、インターフェースが分かりにくかった。もしかしたら、ワタシが書いていることはデタラメで、ちゃんとプロジェクトに属さないタスクも作れるのかもしれないけど、半年くらい触っていても分からないのは、やはりUIデザインに多少難がある、と言わざるを得ないでしょう。週次Review機能もちゃんとメインメニューにあるんだけど、あまり使い勝手はよくなかったし。

あと、これを言うと泣けてきてしまうのですが、やはりWebアプリの使い勝手の悪さは、GTDに求められる「手になじむ感」とは相容れないんですな。隣のI氏はRemember the milkを華麗に使いこなしているので、かならずしもwebアプリに本質的に限界がある、というわけではないんですけどね。。

まあ、要するにあんまり触らなくなったんですよ。その頃は「GTDはいいんだけど、結局コラボるときに困るんぢゃねーの？」とかやたら大上段に構えていて、activeCollabとかも触っていたんで、結構頭がごちゃごちゃしていたというのもあるんですが。

で、次に見つけたのがEasyTask。フリーではないので一度はスルーしていたのですが、gtd-phpのもったり感に懲りたので、「やはりネイティヴアプリでしょ」ということでコレをセレクト。mac/win版両方ある、というのも大きかった（USBメモリに本体を入れて、ネットワークでシンクロすればどこでもシゴトができる！みたいなところが萌えポイントですな）。

コレはなかなか良かったです。とにかく、シンプルで。たぶん、コレで十分な人は多いはず。動きもサクサクだし（まあwebアプリと比べたらなんだってそうなんですが）。

だがしかし。謳っているSync機能の実装がしょぼかった。いや、自前でサーバ提供したりとか、なかなかすごい頑張りようなわけですが、いかんせん日本語の同期がぜんぜんできない。これは致命的。あと、iCalとのシンクロもできるんだけど、正直、iCalユーザじゃないから、操作するたんびにiCalがいっしょに開くのはあんまりいい気分はしない、ですな（設定で切れるのかもしれないけど）。

ワタシがツールを選定する縛りの一つは、「自宅でも、職場でも同じものを見られる」というのがあるので（逆に言うと、モバイル環境とかでもカンペキに見られないとダメ、ということでは必ずしも、ない、ということが最近分かってきた）、同期がしょぼい、というのはもう完全圏外なんですね。win版は触ってもいないので評価できませんが、ま、同期問題についてはたぶん一緒でしょう（超適当）。

超有名サイト（たぶん）のlifehacking.jpでも取り上げられていた、Chandlerも触りました。……ま、コレはOutlookの代替品、という側面が強すぎてダメ。メーラーは別に乗り換えたくないので、メールまで統合されたモノはちょっとツラいです。あとは、Webからログインしても同じような画面にアクセスできる、みたいな部分は激しく萌えたんだけど、いかんせん手元のクライアントとwebのアカウントの同期が全然理解できず。断念。

……で、ようやくiGTDのハナシなんですが、すいません、存在は随分前から知っていたんですが、最初は、「名前がチャラい」というただそれだけの理由でシカトしておりました。でも、今回、冷静に考えて、

・mac/win両方で使える、という縛りはそれほど優先順位は高くない
・webでも使える、というのも、スマートフォンに絶望した（笑）今、それほど必要ではない
・とにかく、手帳なみと言わなくても、レスポンス命

という条件で絞った結果、iGTDはスバラしい（んじゃマイカ？）、という結論に到達。共有については、「ファイルサーバに置いた一式を職場／自宅で開く」という超原始的な方法であっさりクリア。二カ所で同時にファイルをオープンするので、ちょっと挙動が怪しいのですが、iGTD自体がこういう状態を想定して、ファイルの保存場所を指定できるんですね。で、たとえば職場で作業して、立ち上げっぱなしで自宅に戻ったら、いったんiGTDを再起動すれば作業再開。まっとうなデータベースシステムのように、行単位でのロック的なナニとはほど遠いハナシで、正確には同期、というのとは少し違うけれども、やりたいことはできているので問題なしです。サーバがちょっと遅いので、レスポンスは実はあまり良くないのですが、まあ、許容範囲です。

実際に触った感触としては、やはりネイティヴアプリならではの「チェックすると線が入る」「Drag&Drop」的なeye candyが素晴らしい（Ajaxでも実現は可能だと思うけど）。また、「とりあえず置いとく」的なInboxが存在していて、あとからプロジェクトやコンテクストを追加できる、というスタイルで、「人というものの弱さ」を知っているなオヌシ、というUI思想が随所に感じられ、好感度大です。さらに、ファンクションキーで呼び出してタスク書く、とか、QuickSilverで一発書き込みとか、メールからも書き込みイケルよ、とか、その手の道筋が何本も引かれているのも、「よく分かっていらっしゃる☆」という感じ。まあ、大体の機能はぢつはEasyTaskとかぶっているんですけどね……。

あー、でも、プロジェクトを階層化できるかどうか、っていうのは大きいな。結局、「あとで階層化できるかどうか」という担保があってはじめて、プロジェクトを切るときに「この粒度は適切なのかハテ」という疑念で立ち止まらずに、「よーしパパこんな大きな概念でプロジェクト切っちゃうぞ〜」と、躊躇無く大風呂敷を広げられるワケで、これは一見事態を複雑化させるようでいて、かならずしもそうではない、なかなか重要な機能なのです（私にとっては、ですけどね）。

# 今はまだつかってないけど、contextsも階層化できるしね。

なにより、このアプリを触っていて、ようやく

・「タスク」の5分類に加え、場所文脈＋時間文脈の属性づけ
・上記三つの次元から分解済みのタスクを絶えず見返すことによって、物事の優先順位が時々刻々、TPOで変化する、ということを脳にフィードバックさせる

ということが多少なりともできるようになり、GTD3級くらいにはなれたのではないか、と（ちなみにGTD4級では、「さまざまな物事を脳から追い出す」ことの重要性が理解出来ればOKです）。効率云々よりも、このことが最大の収穫、ですね。

ちなみに、gtd-phpでは”spacial contexts”と、”temporal contexts”とゆうのがあって、それぞれマトリクスで見られる、的な機能があったんだけど、まあ、ソレは正しいんだけどちょっと教条的すぎるかな、と。”temporal”には”short”とか”medium”とか入れられるんですが、そんなの、何十、何百とできるであろうタスクのひとつひとつに入れて、ひとつひとつを週次レビューでメンテできるわけがない、と思うワケです。そうすると、締切がかなり重要なタスクだけ日付を入れて、みたいな方が現実的かな、と。

というわけで、ここ二週間ばかりはほどよく使っております。さて、今度こそ続くかな？（この項、続くカモ）