あーありがち

過去の日記 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

_ 正直、多いな。

いや、自分で作っておいてなんなのだけど。

ページタイトルもオブジェクト化してみた。メインタイトルとサブタイトルをプロパティに持って、テキトーなメソッドでそれを吐き出す。 しかし、いやほんと。くじけそうな気がしてきた。まだレイアウトの調整とか全然始めてないのに。

_ RDoc 勘違いしてた

Ruby 1.8 に取り込まれたのは知っていたけど、これは HTML のドキュメント生成に使わなくても便利なんだ。

require RDoc::usage

なんかを使って、簡単にスクリプトにヘルプ表示の機能を入れることができる。しかもスクリプト内のコメントをそのまま使えるので二度手間にならない。これいいな。

参考 RDocUsage

_ アクセスさらに増えた

今度は カトゆー家断絶 から。

人気サイトこえー。コメントには「メモメモ」しか書いてないのに。1日5000なんて行ったの初めてじゃなかろうか。デイリーポータル効果と言えばデイリーポータル効果だな。いったい誰がどういう紹介してくれたんだろう。分からないのがもどかしい。

_ PukiWiki fork 向け試案

※ まずはじめに、この日記はおれが fork したる！という意思表示ではありません。お間違えのないよう。

pukiwiki.org ドメインが for sale になりましたな。

確認できるのは

• 増井氏が pukiwiki.jp を取得し、死んでた users-ML に報告
• heno氏は dev の開発日記に書き込み

やりとりする気なさそうに見えるなぁ。というか pukiwiki.org のサイトは通常の状態では閲覧不可能なのに、なんでいつまでもここにどんどん書いていくのかな、heno 氏は。hosts 書き換えれば見ることができるっていうのと、そのまま使い続けていくのとは別な話だと思うんだけど。

というか、開発以外の話なんだし、自分で blog 用意してそこに書いてくれるのがいちばんありがたい。

• fork しようかという動きもあるが、愚痴を言う場所になりつつある感じ？ つまり 2ch の PukiWiki スレがもう一つできたようなもんか？

ただ、個人的には fork は悪いアイディアじゃないと思う。サーバ管理やサイトの運営ポリシーの問題を除いてもおおざっぱに

1. PukiWiki 内部に非常に手を入れにくい作り
2. アップデートしにくい作り
3. 設定ファイルやコード中のコメントが日本語じゃなくて敷居が高いなどの問題

があるわけで、これをどうにかしようと思ったら、

• Wiki 記法のパーサ以外全とっかえ

でいいんじゃないかと思う。*1というわけで以降は fork する人向けメモ。（あくまで自分で fork するぞ宣言でないことに注意。）

まず、PukiWiki 全体で global 宣言しまくりで、名前空間がフラットで、それを避けるために関数名とかやたら長くなったりして、超やな感じなので、これはもう全部クラスに分けちゃう*2。あとアップデートしにくいのと設定ファイルの問題は

• 設定ファイルの役割を最小限に絞って、あとは全部 Web インターフェイスで設定するように変更する

で、その設定情報がデータ領域に入るようにすれば、設定ファイルの中のコメントが英語だとかアップデートしにくいだとかの問題を一挙に解決できる、はず。特にコメントの問題は単に設定ファイルがでかすぎるのが問題なんだと思っている。あんだけでかけりゃそらコメント要るし、コメントがすぐ読めなきゃそら面倒くさくてやっとれんて話ですよ。

• そのためには認証周りをもっと扱いやすくしないとダメ

なんだけど、これは前からそうなんだから、この際だからガンバレと。

もひとつ、コード中のコメントが英語でカスタマイズしにくいって問題も、そもそもコメント見ないと何やってるのか分からないような長大なブロックなどが問題なのであって、もっと読みやすいコードにすることが前提にくるべき。あと phpdoc をフル活用する方向にして、それと簡単な図*3をサイト上に載せておけば、ずいぶん楽に全体の構造が把握でき、かつそれぞれのパーツの役割も確認しやすくなると思う。

果たしてそれは PukiWiki をベースにする意味あるのか？という疑問は残るけど、自分にとって PukiWiki が PukiWiki であるいちばんの理由は Wiki 記法なので、自分にとっては意味がある。ま、極端な例だと思うけど、しっかりした何かがベースにないと fork できないままで終わると思うし、fork しない方がいいんじゃないかと思う。

_ Ruby で YAML はすごい楽じゃん

プログラマーのための YAML 入門 (初級編) とか Yaml.rb -- Yaml for Ruby とか参考に、適当に YAML で書いたファイルを用意して

require 'yaml'
require 'pp'

fh = File.open( FUGAHOGE )
yaml = YAML.load( fh )
pp yaml
puts yaml.to_yaml

こんなんでテスト。すっげ。Hash の配列とか配列の Hash とか Hash の Hash とか、正直 Ruby で書くのはだるいんだけど、YAML だとばかみたいに簡単。なんだこれわ。もっと早く試すんだった。Ruby では標準添付っつーのがサイコーに楽。

しかしこうなると yaml-mode.el がほしくてたまらない。

_ Emacs22 の font-lock の色使いが terminal で再現できなくて意味不明

頑なに拒んでいた unicode 化の波なんだけど、一応 javascript のネイティブは unicode だしなということで渋々対応を考え始める。*1

なんで渋っていたのかというと、mule-ucs を組み込むと Emacs の起動がやたら遅いから。Debian マシンは当然 CVS 版が入ってるわけないので、これに関しては mule-ucs で我慢することを決め込む。Emacs は終了しないで使う。*2

問題は手元の OSX 版。mule-ucs を組み込む方法が分からん。*3fink で入れることにすると Emacs からビルドし始めるので、それだったら CVS 版でいいじゃないかと思い立ち、Carbon Emacs を落としてくる。立ち上げる。おぉ、OS ネイティブのウィンドウだ。こえぇ。Emacs は terminal でしか使ったことがないので自分のウィンドウを持ってる Emacs を見るとビビる。いそいそと Carbon Emacs 内のディレクトリをたどり、

emacs -nw

すると普通に terminal の中で起動してくれた。よしよし。

……。

あれ。色分けがおかしくね？ font-lock は有効になっているんだけど、色の付き方がずいぶん中途半端になってしまう。うーん。もう一度ウィンドウを持ってる Emacs を立ち上げてみる。あー。何この中途半端な色。こんな微妙な色が terminal で出るわけないじゃん。

うーん。Carbon Emacs だからかなぁ？と思い、意を決して Fink から Emacs 22 のビルドを開始。その間はずっとサーバ上で作業するので手元の処理が重くなっても気にしない。で、起動。

やっぱり色分けの意味が分からんorz

どうやら Emacs 22 の font-lock の色分けは基本的に terminal での利用は考慮していないっぽい。まいったなぁ。Emacs は細かいカスタマイズって面倒でやってないのでこういう事態が起きるとさっぱり分からない。

※ とりあえず Emacs 21.3.5 にして回避した。

[追記] ansi8 + M-x customize で emacs22 への準備 で Terminal でも使えるようになりました！

_ Emacs の M-x grep をマルチエンコーディングに

なんかたまにエンコーディングの混ざっているファイル群に対して検索を掛ける必要があったりするんだけど、そのときだけ mi を起動したりしてものすごい敗北感を味わっていたんだけど、lgrep を使うことにした。

厳密には以前から emacs の grep で lgrep は使っていたんだけど、recursive に検索してくれなくてなんじゃこれめんどくさ、と放置気味だったわけ。

今回一念発起してこうしてみた。

(setq grep-program "find . -type f -a -print0 | xargs -0 lgrep -nk -Ou8 ")

• UTF-8 出力で
• 半角カナを全角カナに変換してから検索する

ようにしてみた。うむ、やっと便利になった。バイナリファイルも大量にあるっつー場合は適当に find の条件を書き換えて使うこと。lgrep を知らない人は勝手にググること。

_ バージョン番号…

なんか今になってものすごく初歩的なことなんだけど、Perl で

print $];

はちゃんとバージョン番号を返すのに

use English;
print $PERL_VERSION;

は何も出ないな…。まぁ困らないっちゃ困らないんだけど、どうなってんだろ、これ。

_ 『Googleを支える技術』読了

実はこの本はスルーするつもりだったんだけど、最近、やっぱこの本は読んどいた方がいいんだろうなと思い直して手にしてみた。

よかった。

何がよかったか。書き手と編集の仕事が素晴らしい。

正直、内容的にはあちこちのサイト、ブログなどで散見できていて、新しい情報は多くない。だけど断片が離散している状態よりも一冊の本になっている方が当然見やすい。それが優れた作り手の手によるものならなおさらだ。

まず図が豊富で、それほど技術に強くない人間でもある程度までは理解した気になれる。もちろん、技術の分かる人間にとってもこの図は非常に有用である。

次に文章が読みやすい。正直、技術系の本に読みやすさは求めない気持ちで挑むことが多いのだが、この本は久しぶりによくできた縦書きの本を読んだような錯覚に陥った。それくらいに書く行為の基本がよくできていると思う。節、章のまとめもいい具合。いいタイミングでくり返し説明されるのでしっかり内容が頭に残る。

しかし見ると著者はライター歴が長いわけでもなさげ。なおかつ「スーパークリエイター」。天は二物を与えるんだねぇと、少し恨めしい気持ちになった。

良書です。

もちろん編集もグッジョブ。というかここ数年の WEB+DB PRESS の仕事ってほんと感心する。以前は「あー Java の雑誌ね」と見向きもしなかったんだけど、LL 全般を扱い出した辺りから急に幅も奥行きも広がって来ていて、構造化プログラミングを特集されたときには正直「やられた」と思ったものだ。ここにきてこれか、と。

次は「サーバ/インフラ」か？ いやー「集合知」勉強したいんだよな。