あーありがち

過去の日記 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ CentOS 5.0 インストールできず

DVD に対応できない環境ばかりなので CD を作成して実験開始。

最初のメニューは表示できるんだけど、その後は GUI でも text mode でも resolution を指定してもまったく何も表示されない。困ったな。目的は Cent そのものじゃなくて Xen with Cent なので、この状況では何にもできない。うーん。

Xen そのものは Debian だけでも実験を進められるんだけど…。うーん。

_ Xen が少しわかってきた

実験環境を用意したっていうか自分が実験できる環境に出向いた。

Domain 0

• 基本的に Xen 向けにカスタマイズされたカーネルを利用した普通の Linux
  • みたいな感覚で扱えるもの
  • ディストリビューションが対応している場合、そのインストールはびっくりするくらい簡単。基本的に普通にカーネルをインストールするのと同じ。
  • 自分でソースから build とかするとカーネルのアップデートが面倒になるので個人的には対応ディストリを使うべきだと思う

Domain U

• 構築は、フロッピーも DVD も何もない状況で起動可能なディスクを作ってそこからブートさせるプロセスに似ている
  • VMware と違ってとりあえず空っぽの仮想マシンを立ち上げてインストーラからインストール、という手順を踏めない
  • だから debootstrap がどうこうという話が wakatono さんの記事によく出てくる。debootstrap に inspire された rpmstrap というものもあるので、rpm ベースのシステムはこっちを使えばいいんじゃないかと思う。xen-tools.org - Xen Software: xen-tools の xen-create-image はどっちも対応しているらしい。
  • Debian 4.0, CentOS 5.0 など対応ディストリビューションではこのプロセスも結構簡単
• 仮想ディスクに相当するデバイス（ファイル、論理パーティション、物理パーティション、物理ディスク）と設定ファイルをコピーすればどの Domain 0 環境でも使えるはず
  • 仮想ディスクイメージとして設定まで中に持っている VMware や VirtualPC とはちょっと違う。逆にそのおかげで特別な設定ツールを必要とせずに Domain 0 上で設定ファイルを直接編集できる
  • Live migration なら動作中でもコピーできるらしいが具体的な方法はまだ知らない

Hypervisor & Monitering Tool

• 仮想環境を操作するために xm コマンドを利用する。最近流行のサブコマンド形式ですげーいろんなことができる。基本的に xend に依存している。
• が、仮想環境の操作を行わないなら必要ないし削除してよい。というか wakatono 推奨環境では Domain 0 からは xend 削除しちゃえば？って感じ。

今のところのまとめ

• VMware と違って従来は基本的に GUI がなく*1、非常にとっつきにくい感じのしていた Xen だが、ちゃんと段取りを押さえていけば一部を除いて非常にオーソドックスに考えることができる。むしろ完全に GUI なしで環境構築できるのでサーバ向けにとてもよい。
• Domain U の「環境」構築は Domain 0 でなければできないわけではないので、構築環境は別に用意しておけば Domain 0 に余計なもの入れなくていいよね。
• Domain 0 に IP アドレスを割り当てない方法も可能なので、完全リモートでないならそれがいいような気がする。

※ 別に Debian 好きではないが、Debian 4.0 と CentOS 5.0 ならやっぱ Debian の方が好きだな。余計なことを何もしないので目的に向かって最短距離で突っ走るにはよい。まぁ 4.0 が出たばっかだから思うのかもしれないけど。

cf. Open Tech Press ｜ CLIマジック：debootstrapによるDebian GNU/Linuxのインストール

_ 生活リズムが変わると

どうでしょう Classic の録画を忘れる。

どちくしょう。でもまぁ昼間充実してたからどうでもいいや。

_ OSX のパスワード周りをやっと理解し始める

まだ続く休日なのにお仕事シリーズ。

自分では使っているけれども、これまでクライアント管理の対象に OSX は入れていなかった。これではいかんということでとりあえず OSX のアカウントについてお勉強。

• root ユーザー（Windows では Administrator に相当するか？）はデフォルトで無効
  • ただし sudo を利用できる管理者アカウントというものがある。管理者アカウントでの作業も通常はそのユーザーの権限で行われる。
• Netinfo マネージャから root アカウントを有効にすることもできるが、ログインウィンドウに root というユーザーが並ぶことはない
  • ここら辺も Windows の Administrator っぽいかな
  • root アカウントを有効にするとログインウィンドウに「その他」が現れると説明されているページが多いが、ディレクトリ環境でない場合は出ない。その場合は Mac OS X 10.3: ログイン時に「その他」オプションが表示されない の手順を踏めばよい。
• マスターパスワードは管理者アカウントのパスワードを忘れても FileVault に対しては有効だが、ログインパスワードとしては機能しない。

管理者アカウントのパスワードを忘れてしまったコンピュータで管理者権限を必要とする作業を行わなければいけない事態*1が想定される場合、

• root ユーザーを有効にしておく
• パスワードリセットで乗り切る

のどちらかになるのかな？ FileVault を使う場合はマスターパスワード必須なんだろな*2。これを使うべきかどうか。うむ。

cf. アップル - サポート - Mac OS X v10.4 Tiger - アカウント、パスワード、セキュリティ

ふー。これで宿題はとりあえず終了だろう。

_ irc とか im とか

※ 相変わらず完全には休まない日々。

OSX の irc 環境を調査。以前 Classic 用のものを調べてファイル転送が死ぬほど遅くて実運用を諦めた経緯があるので、もう一度その辺を知っときたかったから。

結果。面白いことが分かった。

※ サーバは irc-hybrid 7.2.1 で、無線 LAN 経由なのでそれほど速くない。

予想通りアプリによって違うんだけど、LimeChat - Conversation 間では瞬間最大で IP messenger 同士の通信より速くなった。おやおやおや。これはいいかもしれんぞ。

ついでに使い勝手的な部分でいくと、

X-Chat Aqua

日本語インターフェイスがないし、文字エンコーディングを GUI から選択できない。

Colloguy

エンコーディングの選択はその場でできるけど日本語インターフェイスがない。

Conversation

エンコーディングは環境設定からの変更になるけど日本語インターフェイスがある。全体に質素で、分かりやすいと言えば分かりやすい。サーバやチャンネル情報を明示的に設定、保存するインターフェイスがなく、手で入れた情報が自動的に XML で保存される。削除はこれを手でいじるしかなさそうに見える。

てな感じ。自分がいじるならどれでもいいけど他人に使わせるとなると日本語インターフェイスの有無はでかい。Conversation はファイル転送も速いのでかなりよさげに見える。あ、日本語ファイル名については試してないな。テストしなきゃ。

Jabber

サーバのある Messenger ということで名前だけ知ってた Jabber も興味出てきた。が、これはさすがに今回は時間切れだろな。（と言いつつとりあえず FreeBSD にサーバをインストールし始める。）

Jabber についてよく分からないのは

• irc の channel のように一部のユーザーだけに注視できるか
• 逆に IP messenger のように他のグループとやりとりしやすいか
  • irc では通常、メッセージをやりとりする channel にはすべて入っておく形になる
• IP messenger のように必要なときだけメッセージのやりとりをしやすいか
  • チャットだとどうしてもウィンドウを出しっぱなしにしたくなる
• IP messenger や irc クライアントのように動作は軽いのか
  • 特にプロプラな囲い込み系 IM のように重いのは勘弁してほしい

矛盾しているんだけど、要するにこっちの希望というか注文としては以下のような辺り。

• irc は 1対1 の瞬間的なやりとりが中心の場合にあまり嬉しくない
• IP messenger は 1ウィンドウ : 1メッセージなので（つまり履歴を活かせないので）込み入った話に不向き*1
• IP messenger はログを各自で保存するしかなく、サーバに保存して誰でも検索できるようにするなどの工夫はできない。またログはデフォルトで保存されない。*2
  • これと 1ウィンドウ : 1メッセージな点と絡んで、必要なウィンドウをうっかり閉じて「黒やぎさん状態」になることもある。
• 必要なユーザーだけに素早く送信したい
  • IP messenger はユーザーが多くなると非常に使いにくい。フィルタリングや優先度などの工夫は認めるけど、どうしてユーザー名検索にみんな注目しないんだろうか。
• クロスプラットフォームで動くこと
• 日本語インターフェイスがあり、多くの人に薦めやすいこと
  • とりあえず OSX なら問題ないけど、あとはどうなんだろ
• 動作が軽いこと

相変わらず注文が多いけど、満たす注文の数が多ければ多いほど嬉しいわけ。Classic Mac が入っている場合は Jabber は自動的に排除されるわけだけど、とりあえず今回それは抜きにして考える。個人的には irc も IP messenger も一長一短だと感じているところ。

Jabber はサーバがあるので リアルタイム性と記録性、閲覧性、検索性の間 で書いたような工夫のしがいがあるのもいいな。何をどう仕込んでいくかはなんにも考えてないけど。

_ めがね買った

今のめがねは5年になる。長いか短いかは人によって判断が変わると思うんだけど、正直コレ自分の顔に合ってないのね。舶来だもんで。やっぱねぇ、日本人の顔には合ってないの*3。デザインは気に入ってるんだけどさ。部品がないからメンテにもえらい時間掛かるしね*4。

つーことで実は数年前から変えたくてしょうがなかったんだけど、それなりに値段するものだから（自分の場合はレンズがどうしても高めなので）我慢してたの。

今回は、生まれて初めてセルフレームにしてみた。と言っても普通のセルフレームとはかなり違います。今回は見た目だけでなく機能性にもこだわったのですよ。えーとどこのだっけ。Eye'DC ってとこ。

……。

また舶来だorz

いや、掛け心地は今よりずっといいよ。マジで。

_ Jabber はちょっと面倒なのかも

なんだかんだで Jabber の実験を少々。

FreeBSD で立て始めたんだけど、パッケージがあれば Debian の方が簡単だろうと踏んで Debian に。予想通り楽ちん。設定ファイルも小分けになっててどこが足りないか把握しやすい。慣れたアプリだと Debian のポリシーの極端さに腹が立つことが多いんだけど、今回は全面的に甘えておこう。とりあえず動くところまではきた。

……。

そうか、IM って普通はサーバにアカウント作ったりコンタクトリスト作らないといけないのか。使ってないからそういう基本的なことすら分かっていない。えー面倒くさいなぁ。サーバ側で一括登録したりユーザーを検索できたりしないの？

あ、それは別モジュールなのか。jabber user directory ってモジュールを足すのね。はい足した。

……。

動かない。というか user directory に jabberd が動いているマシンそのものを指定すると user directory を見つけられない。調べたらどうも user directory は別な名前が必要なのか。DNS のないイントラで起こそうと思ったら結構面なことになっちゃうんだな、これ。（うちは使えるけど。）

user directory にアクセスするところまではきた。けど、うまく動かないなぁ。思った通り面倒くさそうだ。user directory が ldap で外に出せそうならそれなりに便利かなって気がする。なんか数年前に Software Design で Jabber の記事あったよな。休み明けたら探してみよう。

_ めがねゲット

意外と早くできたな。

うむ。めがねは合っている。

しかし、オヤジがうるさい。

たぶん他の人から見ればオレもこのオヤジみたいにうるさい人間なんだろうと思うとあんまり悪く言えないのだが、それにしたってどうだろうという感じがしなくもない。メガネのセレクトと腕は確かかもしれないだけに、うーん。

まぁいずれにせよ合わないメガネで苦しむ日々とはおさらばできたのだから、よしとしなきゃいかんのだろな。

今回はあえてインチキくさい感じを前面に出してみました。会う機会のある人はビックリしてください。

_ ちょっと環境整備

イントラのフィードは Thunderbird で

常用ブラウザである Camino でフィードを読むのは難しいので、イントラのフィードはどうしようかと先送りにしてきたんだけど、Firefox の Sage で auto-discovery から引っこ抜いて、これを opml export して Tnunderbird で読むことにした。ブラウザでもメーラでもないアプリをわざわざそれ用に立ち上げるのもだるいし、ティッカーってゆうの？あの画面上に居座るやつ。あれも XGA の環境では非常に使い勝手が悪い。メールチェックはどうせするので Thunderbird に一本化という形に。

フィードが増えた場合はまた Sage からスタートし直しってことで。

ただこれ、メッセージの表示スタイルをプレーンテキストにしてあると、プレーンテキストのフィードがない場合に何も表示されないという欠点があるんだな。まぁ description に HTML を放り込んでるような無作法なフィード*1が悪いっちゃ悪いんで、あんまり気にしないことにしよう。

[追記] ダメだった。Trac 0.10.x になっても HTML しか存在しない Feed だったので Thunderbird で plain text しか表示しないようにしてると中身が見えない。まぁ commit message は Subject に出ているのでそれ見りゃほとんど分かるし、リンク辿れば詳細は分かるしなぁ…。なんか微妙。

ヒマがあったら Fresh Reader - Fast RSS feed reader - boost your productivity - とか試してみるべきか。

localhost を utf-8 で Emacs 22 に

Emacs 21.3.50 では、なぜか ruby-mode になっても色分けされたりされなかったりするという謎の現象をずっと引きずっていたんだけど、Emacs 22 にしたらとりあえず問題なさそう。ついでに

(set-default-coding-systems 'utf-8)

にして全面的に utf-8 に移行。

(load "ls-lisp")

して Emacs 立ち上げ時に LANG=C にするとかいう小細工もやめる。ついでに

(setq grep-command "lgrep -n -Au ")
(setq grep-program "lgrep")

してエンコーディングの混ざった状態でも正しく grep の結果を受け取れるように。

physical-line-mode は動かないらしいので以前どこかで見つけた別なコードをコピペ。（というかコメントアウトしてあったのを戻しただけ。）

色の問題は以前解決済みなので無問題。

速いし、OSX 上で日本語ファイル名を認識できるし、とりあえず言うことなし。やっと Terminal が OSX のデフォルトのエンコーディングに戻りました！

他の環境ではとりあえず screen の

encoding eucJP UTF-8

とかでしのぐことにする。

_ SourceForge.net: Spyc 0.3 beta is out

待てしばし。

遅さが気になってた人は今度は性能向上を感じると思うよっつー話なんだけど、フルスクラッチで書き直しているらしいのでテストが欠かせませんな。

つか時代は yaml.com の方なんだよな。Spyc 0.3 は PyYaml 互換になった…わけじゃないんだろな。中身は見てないけど。

_ Thunderbird 2.0 の「すべての新着」からフィードが漏れるような？

Thunderbird でイントラのフィードを読むようにしたんだけど、なんか

すべての新着メッセージを受信

してもフィードを取得してくれない。フィード用のアカウントをアクティブにしてからだと受信できるんだけど。

不便だなぁ。やっぱあんまりこの機能使われてないのかしら？　

_ xinetd 経由の daemon てどうやって再起動すんだっけ

ポイントは xinetd を再起動したいんじゃなくて、そこから起こしてるプロセスを再起動したいってとこ。

軽く調べたけどよく分からず、なんか面倒くさいから kill -HUP したらそれきり帰ってこなくなってしまった。

でもまぁ xinetd が監視してんだからそれで別に困らないわけだけど。

※ 自分で検索してもこのページが見つかるし、referer を見ても情報を探してる人がそれなりにいそうなので書いておくと、たぶん

xinetd を kill -SIGHUP

でいいような気がする。xinetd の設定変更を反映する。そもそも上の記述は xinetd 経由にしてるはずの daemon プロセスが自分一人で起き続けている段階で何かがおかしい。

あるいは多くの Linux では

/etc/init.d xinetd (restart|reload)

でイケるはず。

_ すっかり Perl の書けないカラダに

irb 超便利だよーとか言っているうちに昔書いた Perl スクリプトが直せなくなってきている。まぁ直せないのはそもそもの作りが悪いっつーのも大きいんだけど、CPAN をバリバリ使いこなして…っていう流れがどうにも解せない*1こともあって非常に効率が悪い。だからと言って今さら自作ライブラリを書こうなんて気もさらさらなく、実に中途半端で困った状態になっている。

イマドキのライブラリを同梱した all-in-one perl とか誰か作ってくれんやろか。

[追記] とりあえず Data::Dumper を入れて泥臭く対処。

_ まだまだ UTF-8 は悩ましい、のか？

Fink の screen はまだ 4.0.2 のままで、これにはあれこれバグが潜んでいるらしい。LANG を UTF-8 にしたのだが、screen 上でだけ画面がずれる。えーと、文字がずれると書いた方がいいのかな？ カーソル位置の計算や文字の表示位置の計算がずれているので編集している文字がどれなのか分からないとか、表示が乱れ過ぎて使いものにならないといった現象が起きる。で、このずれはアプリによってマチマチ*1だったりするので screen だけの問題なのかどうかがよく分からなかったりする。

うーん。まだ早かったか？

terminal が euc-jp のままだとせっかく utf-8 の編集ができても表示できない文字がいっぱい出てきてしまうので嬉しくないのだが、utf-8 の出力はまだうまく対応できないツールがいろいろあるみたいだ。Fedora や ports で最新版をガンガン使っていきます、みたいな世界ならそれなりに快適に過ごせそうな気がするんだけど、Fink は Debian 系だし、そういうわけには行かなそう。ドキュメントの充実ぶりはものすごくありがたいんだけどねぇ。

MacPorts に鞍替えか？ どれどれパッケージは増えたのかな？

……。

どこ見りゃいいんだ。MacPorts になってからサイトが分かりにくいんだよなぁ。Trac のカスタマイズがすごいのは分かったからなんとかしてくれ。とりあえず Browse Source する。なんかものすごい増えたような気が。見慣れた本家 ports のような分類なので欲しいものがどこにあるのかはだいたい分かる。ふむふむ。問題の screen は 4.0.3 が入ってるな。しかしいつの間にこんなに増えたの？ もしかして Intel 化の恩恵？ だとすると、

これって PPC でテストされてるかどうか分かんなかったりする？ てか Panther って対象外？

うぉう。こえー。どうすべ。もう少し調べてみっか。

[追記] 結局 screen の設定と w3m の設定を見直したらかなりまともに動くようになったのでこれでいくことにした。w3m の方でエンティティを ASCII に置き換えるようにしていたのがダメだったのかなーという感じがしている。あとは文字幅の変わる置換とかその辺の設定かな。あんまり細かく切り分けてないけど。

MacPorts については、一応 MacPorts 自体は 10.3 用のバイナリがあるので少し安心しているんだけど、まぁおいおいってことで。

_ Emacs で table が書けるのか

今まで知らなかったのかおまえシリーズ第?弾。

table-insert

で新しく表を作ると

+-----+-----+-----+
|     |     |     |
+-----+-----+-----+
|     |     |     |
+-----+-----+-----+
|     |     |     |
+-----+-----+-----+

こんなのができる。この中に文字を書いていくわけだけど、ちゃんと文字列がセルに対して長すぎたら自動でセルが伸びるし tab キーでセル間の移動もできる。うっかり C-d で文字を消してちょっとハマったけど、table として処理させないように切り替えて修正してから改めて table として処理させたらうまくいった。

ちょっと気をつければ結構便利に使えそう。というか今までメールで表を使いたかったときは Wiki 上に書いてそれを w3m で Terminal に文字として表示して、それからそれをコピペとか訳の分からない技を使っていたんだけど、これだけですべて解決するってことに気がついた。なんてこった。

こういうときに、起動時に tips が出るようなアプリならよかったのかなとか思わなくもないけど、あの機能って真っ先に外しちゃうからな。発見があった試しがない。

[追記] もしかして Fink の Emacs 22 じゃなくて CarbonEmacs に移行せよという天啓か？

_ prototype.js の Element.update() が頼りにならない

IE の innerHTML を書き換えてもダメなことありますよエラーにハマったので、prototype.js に丸投げしちゃえーと思って Element.update() にしても同じ挙動をする。中を見ると自分のコードと基本的に同じ処理をしている。

うーん。

replace() の方は真面目にやってるっぽいので、自分と同じ element を create してそいつと replace() すればいいのかなと思ったけれど、同じ element を DOM で真面目に create するのは激しく面倒くさい。attributes の扱いが超メンドイ。いやベタ書きなら楽だけど、これを汎用の update() としてまとめるのは結構大変。

うーん。

attributes.keys().each()

みたいに書けるとすごい楽なんだけどね。

[2007-07-10 追記]Ajaxian » MooTools 1.1 Released からすると、実は MooTools ではこの時点で可能だったっぽい。Prototype.js は 1.5.1.1 以降のどこかの時点で DOM Builder が入るらしい。

_ Debian 4.0 etch へアップグレード

elisp の byte compile がいちばん時間掛かる…。先に抜いときゃよかった。どうせ snapshot に入れ替えるつもりなのに、21 用の elisp を延々 byte compile してもらっちゃってるのはバカすぎだなぁ。

[追記] なんか一部のパッケージが信頼できないとしてインストールされていなかった。nkf.pm と trac がそれ。こっちゃ trac のアップグレードにいちばん期待していただけにちょっとびっくりした。「あっれー trac 動かないよ？」と思ったら入ってねーんだもの。警告を無視してなんちゃらかんちゃらと脅されたが振り払ってインストール。

trac-admin <PATH> upgrade
trac-admin <PATH> resync
trac-admin <PATH> wiki upgrade

をプロジェクトの数だけリピート。あ、この作業ってすぐスクリプトにできるやんけ。あーまぁいいか。

うむ。 エンコーディングが混ざっていても化けない diff みたいにごちゃごちゃ頑張らなくても chengeset をポチっとするだけでまともに見れるようになった。よしよし。

base_url の設定を足すことで proxy 経由の Trac でも意図した URL への link を持つ Feed を生成できるようになった。よしよし。

_ backports って公開鍵のインストールが必要なのか

今日の「お前そんなことも知らなかったのか」

Debian etch に上げた機械で喜び勇んで emacs-snapshot を入れようとしたらそんなものは search に引っかかってこない。うーん。うーん。どうしよう。とりあえず emacs だけ入れられればそれでいいんだけど、そもそもそういう場合の apt line の書き方すら知らない。（ヒドイ。）

AptGet - Debian GNU/Linux スレッドテンプレ

で 99target を /etc/apt.conf.d/ に置いたら testing, unstable を明示することでそこからインストールできることを知るが、なんか全体的に testing も unstable も選択肢に入ってきちゃうのがちょっと不満。というか emacs-snapshot はまだ unstable に居るのにちょっと驚いた。

そこで backports なんてものがあったのをハタと思い出し、きっと backports で etch に持って来れるだろう、と思ったらこれが Bingo.

• start [Debian Backports]
• daemon's horn｜yet another etch-backports

を sources.list に追加し、apt-get update ...

失敗します。公開鍵をインストールしないといけないのでした。

指定された鍵のファイルを取得して、root 権限で

apt-key add FILE

したら使えるようになった。なるほどねぇ。

なんかまだ cron で動いているものと動いていないものがいたり、bind が立ち上がらなかったりしてあちこちおかしい。bind はバックアップ用に動かしているやつなので深刻じゃないんだけど、ここで確実に問題に対処するノウハウをモノにしておかないと本チャンの bind の載ってる Debian を上げるときに困るのよね。原因は当たりついてるんだけど、対処の手順がよく分からねっす。

[追記] 全部問題なく動くようになった。

bind の問題は以前 FreeBSD で経験済みで、

• rndc での認証が加わったのでその設定が正しくないと動かない
  • 正しく設定しても daemon の起動のタイミングの問題で動かない場合があるので、考えるの面倒でかつ許されるならシステムごと再起動すると直ったりする
• hostname のチェックが厳密になり、以前は大丈夫だった名前でも 4.0(etch) で動いているバージョンでは弾かれたりする。要対処。

cron は cron.d/ 以下のファイルがどうもインストールされていなかったらしく、ファイルを修正したらインストールされて動くようになった。なんだか不思議。どうもこの辺の cron.d/ 方式の動きがよく分からないんだよな。

_ Q では PPC 仮想マシンはまだまともに動かないのね

戯れに Q - [kju:] で Mac 上に Linux 環境でも作ってみっかーと思ったけど動かなかった。x86 環境は Pentium II 18MHz とかいう理解できない数字で動いてたけど、修行する気はないので却下。

別に Mac on Mac はできなくてもいいけど PPC 仮想マシンが使えるようになったらそれなりに嬉しいかなーと思わなくもない。どう使うのかはボンヤリしてるけど。（たぶん Linux でしかできない作業、ext3 で mkfs とかをやろうとしているのだろう。でも仮想環境でそんなことできるんかいな。）

_ よーしパパ釣られちゃうぞー < PHP

もう 21 日に長いの書いちゃったから久しぶりに未来日記書いちゃうぞメソッド発動。

404 Blog Not Found:そろそろPHPに関して一言いっとくか

細かく言ってみよう。つかまぁ、自分も PHP マスターではないのでそこら辺のツッコミも希望しつつ。

全部 cofigure でビルド？

No. phpize がある 4.3.0 以降は個別にインストールできる。

ただし、できるだけ。

PHP には pear, pecl という便利なリポジトリ＆管理ツールがあるが、phpize はその範疇になく、どの拡張モジュールを入れたのかの管理はできない。はず。

Perl や Ruby では Pear と違って pure Perl, pure Ruby 以外のライブラリも多く、そこら辺で格安 or 無料レンサバ使いの人には不評だが、逆に言うと拡張モジュールもライブラリも一元的に管理できる便利さがある。PHP では Pear が pure PHP を守ってくれるというメリットはあるが、逆に拡張モジュールの管理はできない。（全部 pecl に入ってればいいのにね。）

php.ini で on/off できるのとはまた別な話ね。言うなれば Apache モジュールのようなものなんだよな、これ。ビルド済みのものでなければ .conf で on/off できない。結局全部まとめてビルドしてないと不便、ということになってしまう。このスクリプトのときだけこのモジュールが欲しい、てな要求にはもう対応不能。

最初に設定しちゃえば似たようなスクリプトを書く際にいちいち気を使わなくていいって意味では php.ini 方式は楽なんだけど、PHP のコードでそれを制御できないのはやっぱ面白くないと感じる場合もあるな。

<?php はウザイ ？

同感。

否定する気まったくなし。というか、いまどきはテンプレートを使って V とそれ以外を分離するので実は <?php なんて記法必要ないし。

すっげー簡単な確認用のスクリプト以外では最近では <?php は不要です。オプションかなんかで、書かなくていいようにできるとすごい嬉しい。

妙な約束事が多いのは Perl も一緒

prefix とか 1文字、2文字の特殊変数とか微妙な構文レベルの呪文になってしまってる分、見た目や理解しやすさは Perl の方がきつい。

ただし、細かい関数の違いという意味では PHP の方がきつい。似たような関数が大量にあり、バッドノウハウの塊と化しているのは間違いない*1。そして充実しているはずのマニュアルにそのノウハウは還元されていない。

例えば Perl や Ruby では obosolete なメソッドなどが必ず出てくるのだが、PHP はなぜか全部平等に扱われたままである。そんなわけないやろ、とツッコミたくなる。

余談だが、PHP はマニュアルが充実してしまっている分、動かして確認している人が少ない感じがする。動かして確認していればあり得ない嘘を再生産しているサイトが多いなぁという印象。

PHP 4 と 5 の違い < Perl 5 と 6 の違い

つかまぁ、Perl 6 は pugs であってもいじったことはないので知らないのが正直なところですが、ちらっと文法を眺めた限りでは Perl 6 を持ち出してまで叩くほどの違いはないと思う。

Perl 4 〜 5 の時代も経験しているのでそれと比較すれば、ドッコイドッコイか、少し PHP 4 から 5 の移行の方がヘビー。ってくらい。ただし Perl 4 から 5 への移行と同じく、メリットがかなり多い。

MVC の V しか書けない？

そんなわけないが、面倒くさい。バックエンドは Ruby で書きたくなる。

結局のところ、関数一発で書けない処理は書きにくいのだ、PHP は。Pear があるって言っても、あまり感嘆するようなライブラリはなかったりする。いやテメーで書けと言われたらシンドイからヤダって言うけど、なんつーかこう、他の言語では「なんて超絶すげーライブラリなんだ！」と思うようなものがあるのに、PHP ではそういう感動を覚えることがほとんどないのね。

自分でライブラリを書き始めると、Perl って自由だなぁ、とうらやまくしくなることもあります。マジな話。

まとめというか

フレームワーク全盛の今、PHP のメリットはけっこう薄れてきていると言える。以前 違いは作業環境的な面だと思うんだな で書いたときに比べると

• フロントコントローラ方式なら実行ビットの必要なファイルは 1つだけなので、そこら辺がルーズでもよいと言う PHP のメリットはなくなる
• ブラウザ上で back trace できるのは素の PHP の何倍も便利

てな感じ。

ただ。

フレームワークを日曜大工スクリプトに応用しちゃうと基本的に重たくなる一方だし、アクセラレータがない環境ではそんなに嬉しくないだろうことを思うと、手軽に使ってサクサクと動的なページを高級 SSI 程度の感覚で作って行く分にはやはり PHP 最強だなと思う*2。

プロが仕事の道具として使うには微妙なところがいくつもあるんだろうけど、そこら辺も Debian のようにバージョンを fix したうえでパッチを提供してくれるディストリビューションを使う、あるいはそういうサービスを使うという選択肢も当然あるわけで、プラスして IDE でコード品質の統一をはかりやすいという部分もやはり大きいかなと。Zend もeclipse も頑張っているわけだから、その成果を使えばよいのではないかと。

ただそういうプロダクト頼みっていうところがなんとなくオープンソース万歳、フリーソフト万歳な他の LL と違うっていう感じはする。なんというか言語そのものというよりは文化の違いと言うか。例えば PHP が好きになれない人はたぶん VB も好きになれない人だと思う（自分はそう）んだけど、それって結局「お仕着せのツールを使ってる分には楽」っていう、制限された堕落さにあるんじゃないかという気がしている。工夫の余地がないというか、ハッカー的においしくないというか。

Perl で Perl を、Ruby で Ruby を、JavaScript で JavaScript を拡張できる、書きやすくできるってのはやはりものすごく「オレってばスゲー感」が前面に出てるわけ。その快感をあまり PHP から得ることはできない、という感じはする。

ただ。

同じ「使わなきゃいけない状況」になるのであれば、絶対に Perl より PHP の方がいいな。自分が書き手の場合は。力量を図るためにあえて求人のメインストリームから外れた言語を使わせる場合は「Perl + CPAN モジュール + コーディングスタイル」よりは Ruby か Python にすると思う。コーディングスタイルまで含めるなら Python がいいのかねぇ。書いたことないけど。

しかし元記事のコメント欄、釣れてるなぁ。

_ PHP を取り巻く人々の思惑の変化とかギャップとか

祭りも収まってきたことだし、その間に読んだり書いたりしたことをもう一度思い返してみる。

自分が書いたものは主に Dan の中の人の発想に同調して「ハッカーが使いたくなる言語か否か」、「『使える』かどうか」だったんだけど、その方向で気になったポイントとしては、

PHP を PHP で拡張できないことに異論を唱える人はほとんどいない

という点。「そこは割り切って使うのが PHP 使い」というのが大勢だったかなと思う。

あとは

1. 関数ばっかいっぱいあって邪魔くさい
2. そんなのリファレンス見ればいいじゃん
3. 名前空間がなくて扱いにくい、一個一個の名前が長くてダサイ

というフラットで巨大な関数群の話。

個人的にはリファレンスとか IDE の補完があればオッケーという話ではないと思うな、これは。予約語もけっこう多いし、そういう意味でも扱いにくいと思う。

たぶん PHP モジュールを作る人が増えてこないのはこの辺も関係してるんじゃないかなぁ。例えば面白いツールがあっても PHP のバインディングだけない、っていうケースは少なくない。PHP 以外を知らない人はこの事実、気づいてないのかな。

それと

1. Web に特化しちゃってて他のバックエンドツールとか書きにくいじゃん
2. Web に特化しているからこそ目的を素早く達成できるんじゃないか
3. Web に特化していることを肯定したうえで、であればもっと素人でもセキュリティを確保しやすい仕組み、あるいはサンプルを提供してくれたらもっといいのに

という特化話。特化していることの善し悪しは要するに目的によって変わってくるのでそこら辺は置いとくとして、自分が気になったのは

本当に特化して楽ちん簡単なのか？

という辺りかしら。

以降はとてもなんとなくな思いつきをダラダラ書くだけなのであまり気にしないでほしいんだけど、ここ数年の PHP 開発の流れって、基本的に大型開発に耐えられるツールを指向していると思うのね。

PHP が Perl で書かれたツールだった頃の話は知らないんだけど、その後の PHP は Perl っぽさというよりは素朴でポインタのない C のような雰囲気を身にまとって C 系のプログラマが移行しやすくなり、その後オブジェクト指向風の機能を追加し、5 ではますます Java 風の機構を取り入れてくる、というのが大まかな流れなわけです。そして今いちばんアツイのは PHP そのものではなく PHP 上に乗っかるライブラリと PHP を利用した Web 開発を支援する環境である、と。つーことは他の言語の流れと基本的にはおんなじところに向かっているように見えるんだな。乱暴に言うとオブジェクト指向を取り入れてライブラリを整理しましょう、という流れ。

もちろん主戦場が Web であるというところは疑う余地はないと思うんだけど、PHP そのものの開発をするうえで Web に特化するということを第一としているのかというと、そうでもないような。というかその辺の機能はすでに実装済みというか*1。で、最近特に問題になることが多いセキュリティ周りは、言語そのもので対応するよりライブラリ、フレームワークで対応する方が効率がいいと判断しているような感じがする。（もちろんクラッシュする類いのものは PHP では対処不能なのでそこは直すけど。）

一方でバージョン 3 の頃のような牧歌的なノリで PHP は導入も簡単で学習コストも低く、初心者にオススメです、という人たちも居て、そういう人たちは残念ながら Web プログラミング特有の難しさにはあまり頓着がなかったりしているように見える。

PHP にいっちょかみする人って、PHP 好き派ときらい派に分かれるのは当然として、PHP は初心者にも簡単でいいよ派と、PHP を大型案件もこなせるツールにしたい派にも分断しちゃってるような、そんな風に見えるんだなぁ。

自分としては「（生の）PHP は Web に特化しているし、簡単でいいんです」、というのは安全なネットワークの中で閉じたツールを作る分には当てはまるけれど、インターネットという危険な大海原では当てはまらないと思うんだな。それでも PHP を薦めるのは

初心者に対してではなくプロの共通語として

なら理解できるかなーと思う。これは PHP くらい使えなきゃダメよと言っているんではなくて、恐らくプロは PHP で書かれたサンプルを読める程度になら半日もあれば到達できるだろう、という感じの意味ね。巨大なライブラリを読みこなせるとか自由に書けるとかいうことではないです。例えば XSS や CSRF 対策の基本はこんな感じです、みたいなサンプルを提示する際に PHP はそれなりに使いやすいんじゃないかな、くらいの意味。もう一つは求人の多さかな。求人の話はニワトリタマゴだけど。

_ 個人的によくあること

• 見知らぬ人にモノを尋ねられる
  • 昔は公園でよく幸せを祈らせてくれと頼まれた
• 外食産業で注文を忘れられる

南禅寺前の交差点で外国の方に道を尋ねられた。えーとワタシも観光客ですが。まぁ看板はすべて読めるけれども。とりあえず「こっちだと思う。たぶん。maybe.」と答えた。ありがとうと言われなかった。珍しい人だな。こっちの答え方がよくなかったかなぁ？

その後、三条河原で MealMUJI とやらに入る。へー、無印はこんなこともやってるのか。いいなぁ。こういうの、田舎には増えないだろうか。MealMUJI のようなスタイルでは注文忘れが発生しようがないので安心だ。いや、増えてほしいのはそういう理由じゃなくて、「たいがいの定食屋は量が多すぎるので減らして安くしてほしいと思っているから」です。

_ PHP の array はマップだってマニュアルにも書いてある

ときどきの雑記帖 リターンズ 2007年5月 - awkってつくづく影が薄い喃

いやぁ。両方使いますけど PHP の方はやっぱ変な感じがしますよ。JavaScript も書くので awk と JavaScript は似ている感じしますけど、PHP の配列だけとても違和感があります。確かに便利に使えるシーンは多いんですけど、PHP から入っちゃった人は気をつけておかないと、他の言語で連想配列やハッシュと言われるものが思った通りに動かない問題にぶち当たると思います。

_ 豪華披露宴…

なぜだろう。

昭和の匂いがするのは。

まぁでもだからいいのかもしれませんが。

イマドキ珍しい、やたらと段取り、手続きのしっかりした人たちだなぁと思いました。

_ 何回でも言おう。僕は rsync が苦手だ。

いやぁ。

またハマった。

どうしても rsync で狙った特定のファイルだけをコピーすることができない。最終的に

1. 丸ごと別な場所にコピー
2. 不必要なファイルを find + rm で削除
3. 残ったファイル群を丸ごと rsync でコピー

という段取りに至るのだが、困ったことにどうしてもこの手順を忘れてしまう。だいたいこういう作業が普段から必要なわけではないというところがまたやっかいだ。

どうしてマニュアルをよく読んでいろんなパターンで include, exclude を書いてみてもダメなのだろう。rsync でこの作業をやるたびにものすごくイライラしてしまう。

あと cp で階層ごとコピーする方法ってなかったっけなぁ。

cp hoge/fuga/bar ./foo

ってやったら

./foo/hoge/fuga/bar

ができるもの。これはもしかすると単体ではなく tar を組み合わせれば可能かな？