val it: α → α = fun

Lingr では shiro さんに伝えたのだけど、あそこは流れてしまうので(アーカイヴァルだからぐぐれば出てくるけど)ここにも書いておく。あっ、ここも流れてしまうか。まあいいや。

えーと、たとえば次のようなコードがあって、

import Control.Arrow x = map (+1) y = filter (< 5) z = sum w = x >>> y >>> z

それで、「おっと x の定義を少し変えよう」というとき、

x = map (\(x,y) -> (x+1,y))

これはこれでいいんだけど w における型の不一致をどうするか、という問題。

もちろんこうしたら y も書き換えないといけなかったりするわけだし、全体から定義を変更する必要がある。でも x の書き換えが少し手間だと全部を書き換えるより前に対話環境で単体のテストしながら詰めたい。でも y や w の型検査がジャマになるというわけ。どうするか。

わたしは shiro さんが書いたように w をコメントアウトしちゃうことが多いんだけど、 where で x を局所定義することでも回避できる。

import Control.Arrow x = map (\(x, y) -> (x+1,y)) y = filter (< 5) z = sum w = x >>> y >>> z where x = undefined

すると w から見える x は undefined (未定義値)となってグローバルな x を参照しない。だから型エラーにもならない。もちろん w を利用しようとするとエラーになるのだが、テスト中は型検査さえ騙せればそれでいいってわけ。で x を改変し終わったら次は y になって、ぜんぶ終わったら w で結合してみればいい。

というわけでした。

あ、ちなみに

x >>> y >>> z

は、

z . y . x

と同じです。 left to right もいいかなあと思ってちょっとそうしてみただけ。

小林めぐみのバカSFシリーズ、これにて完、らしい。なんでも掲載誌の都合で終了っていうことで、まったくなんてことのないところで終わっていていつでもシリーズ再開できそうな雰囲気。いや、いつでもいいんで再開をお待ちしておりまする。

簡単に紹介すると、「わたし」こと主人公は女子高生で、26になるSEと結婚していて、職業作家もやってるのだけど、ご近所で宇宙人とか異次元とかからいろんなものが来てヘンなことが起きたりする、というフォーマットのバカSF短編集。ときどき中編もあり。ともかく、突拍子もないアイディアと展開を馬鹿馬鹿しいユーモアで包み込むという素晴しい短編集であり、ある意味で火浦功で育った私の大好物だけが入ってるといっても過言ではない。

いやほんと面白いんですよ。

今回の巻で面白かったのは、罰ゲームつき双六をやっているうちに友達が罰ゲームで異世界の勇者になって魔王を退治しちゃう双六篇、自宅がとてつもない基地に改造されちゃう秘密基地篇、服についた染みからココロからブラックホールから星までありとあらゆるものを重曹と酢水でキレイにしちゃうクリーニング篇、あたりかな。いやーいいですよクリーニング篇。クリーニング店のオバちゃんがカブに乗ってある星間戦争で邪魔になる星を漂白しに行きますから。

ま、そんなこんなでバカSFが好きな向きにはマストバイ。

食卓にビールを 1 | 食卓にビールを2 | 食卓にビールを3 | 食卓にビールを4 | 食卓にビールを5 | 食卓にビールを6

北岡明佳といえば、蛇の回転などとにかく有名な錯視のページの人だから知っている人も多いと思うのだね。

この本はその北岡明佳による錯視デザインの指南書。よくある錯視の本と違うのは、錯視の例だけじゃなくて基本パターンや錯視が起こりやすくなる(起こりにくくなる)条件なんかの説明が豊富なこと。この本を読めば自分でも錯視デザインを作れる……ところまでは行かないかもしれないが、ひとまず簡単なドローソフトでいろんなものを作ってみることができるようになる。

というわけで、作ってみたのさ。よくあるカフェウォール錯視を、 InkScape でね。そしたらもうぐねぐね曲がる曲がる。面白い。本とかに書いてあることと違って、それはいまわたしがツールで描いてることは明らかなんだけど、四角形を置いていくとどんどん線が歪んでいく。ホワイト効果も試してみたけど、灰色のブロックを動かすだけで色が変化していくのは面白い。

錯視は見るのも楽しいが、つくるのはなお楽しい。そんな本でした。でなくても本書に挙げられた多数の錯視図を見るだけでも充分に楽しいです。クラクラします(いろんな意味で)。

不満点があるとすれば紙がちと薄いことかな。場合によっては裏(次ページ)のデザインが透けて見えてしまって興が削がれるところがいくつかあった(効果には支障なかったけどね)。

だまされる視覚 錯視の楽しみ方

送信元が Andrew Hunt の個人名だった。 Pragmatic Programmer 名義じゃないのか。

さて、そういうわけで本として刊行されちゃいましたねえ。それまでにさくっと訳が出来るんじゃないかと思ってたんですが見通しが甘かった。ここ2ヶ月ほど、ちょっと忙しくて何もできていません。現在はまだ13章の途中かな。8月が過ぎるくらいまでは特に進まないと思います。

さてそんな『Programming Erlang』ですが、邦訳が出るという話があるようです。わたしも詳しい状況はよく知りませんし、すくなくともわたしが訳しているのとは関係ありません。というか誰が訳しているのかも知らない。なのでいつ出るかもわかりませんし詳しい話はできませんが、まあ、そう遠くないうちに翻訳は出るんじゃないでしょーか、とだけ言っておきます。

そんな事情は斟酌せずわたしの方の訳は訳でのんびり進めようかなあと思っていますが。もともと精読するために訳すといっていたのでね。

さて、わたしのこの本に対する評価というのを書いていなかったように思いますが、これはかなり良い本だと思いました。非常に細かく、しょーもないところまで行き届いて書かれているのがポイント。もうひとつのポイントは例題が割と実用的だということ。ごく簡単な例題でも MP3 の ID3 タグを読むとかいったルーチンを例題にしていて楽しい。最終的には MapReduce らしいですし(ただまぁ Erlang で各ノードに分散 Map して後で適当なノードが Reduce する、なんてのはべつに難しいことは何もないのですが……スケールできてるのかな？)。そんなわけで Erlang に興味がなくても読んでみると得るものがあるのではと思いたくなるくらい。

訳は出るといいつついちおうアフィリエイトリンク Programming Erlang: Software for a Concurrent World

ちょっと前に http://googlejapan.blogspot.com/2007/07/google-1.html を読みまして、「へー」と思ったんですが、これってコンフリクトに弱いんじゃないかなあ、という気がしたんですよね。それはどうなんでしょうか。

というけでちょっとテストコードで実行してみましたが、同じ名前で同じ型のフラグを二箇所で宣言すると、リンクするときにエラーになるようですね。ところがフラグの型が違うとリンク時にはエラーにならない。

gflags ではフラグは FLAG_Names_string とか FLAG_Names_bool とかいった型名つきの名前空間に所属するようになっている。したがって違う型では名前空間が違うから、名前衝突のエラーとならない。とはいえ実行時には同じ名前のフラグがあることがわかるので、 ParseCommandLineFlags の実行時にエラーになる。うーん……。

本当に大規模な場合、よく使われるようなフラグ名でこういったコンフリクトが起きたりはしないんでしょうか。

ほかにも、たとえばあるライブラリ L1 が f1 というフラグ名を使っていて、別なライブラリ L2 を開発するときに同じ f1 というフラグを使おうとした。ところが L1 で使われている f1 を L2 で DEFINE すると L2 は L1 とリンクできない。そこで L2 の方を DECLARE で済ませたとする。すると今度は L2 は f1 を DEFINE する外部モジュールがなければ実行ファイルにリンクできないということになるのだが……。

ま、フラグ名のポリシーとかを定めればその辺は回避できそうですが、そうやっているのかな。

ところでParseCommandLineFlags がデフォルトで提供するフラグは help 以外にもいろいろあってなかなか楽しそうです。 -flagfile とか -fromenv なんてのがあるし。 -helpxml とか。

その理由は、

一昨日のネタは、まだ1日くらいのログながらほとんど結果が出たといっていい状況だけどその前に。

User-Agent についてはそれほど詳しくないんですが、 "Mozilla/4.0 (compatible;)" という謎のブラウザがいらっしゃるんですが、何者かご存知の人はいますか。 compatible のあとが空なんですよ。

アクセスのパターンからするとどうも何かのツールくさい定期的なアクセスが多いようだけど、そうでないものもある。 HTTP/1.0 がたまに混じっていたり。 Accept-Encoding もあったりなかったり。ホスト名もバラバラ。

ゲートウェイとかっぽいホストもあって、どうも UA を書き換えるタイプのプロキシの基本設定なのかなあとか思うんですが、まだよくわかってない。 compatible とか言ってるくせに素性が明らかでないのは UA 偽装じゃないかなと思うんだけど。

さて本題。

この (compatible;) 以外で Mozilla/4 を名乗るのは(MSIEを除くと) NetFront や jig browser であったりして、こういうのは Accept-Encoding が指定されてないことが多い。

ただ、超古いマシンなのかどうか知らないけど本物の Netscape 4.x っぽいアクセスもあるのね。本当に支障があるとしたらどうなるかは気になるところ。てことで、たまたま某所にある超古いマシン(FreeBSD 3.5.1！)を拝借して、Netscape 4.76 でテストしてみたところ、gzip を適用しても(たぶん)コンテンツのHTMLは正しく表示される。どこに問題があるかというとスタイルシートとかがうまく読めていないようだ。 js も読めてないのかもだけど、なんせ古いブラウザでは MochiKit がそもそも動かないのだろう、 js は最初から正しく動いてない。凝ったレイアウトにはしないから css が読めなくてもそんなに支障ないだろうしなあ……。

てことで、つまり問題がありそうで Apache の設定レシピにも載っている「Mozilla/4 compatible を名乗る MSIE でないもの」については、

ふと気付くと FreeBSD の ports の emacs が、これまでの 21.3 から 22.1 になったが、おかげでいくつかの port はけっこうややこしいことになっているようだ。というのは、ほかの elisp の ports は emacs21 を前提に組まれているので emacs22 では正しくインストールしづらいのだ。

たとえば apel では Makefile に EMACS_PORT_NAME?=emacs21 という記述がじかに書いてある。なので /usr/ports/editors/apel-emacs22 を作って(apel-emacs20を参考に) Makefile を作るか、あるいは単に /etc/make.conf に EMACS_PORT_NAME を設定しておくといい。

migemo の場合はもう少し面倒で、けっきょく手作業になってしまった。 /usr/ports/japanese/migemo-emacs22 を作成すれば、 portupgrade -f ja-migemo-emacs22 で行けたかもしれない。

ddskkはややこしかった。 SKK-MK の方で(つまり ddskk の方で) emacs-major-version が 21 と等しくないと skk-e21.el がインストールされないのだが、ロードする方は skk-e21.el を要求するので、いっけん正常にインストールできたように見えてうまく動かなかった。けっきょく手作業で skk-e21.el を /usr/local/share/emacs/22.0/site-lisp/skk にコピーした。ちなみに skk の pkg-plist (パッケージの含むファイルのリスト)も、 emacs21 でない場合は別なファイルが使われるから、あらかじめ /usr/ports/japanese/ddskk/pkg-plist を /usr/ports/japanese/ddskk/pkg-plist.emacs22 にコピーするといい。

サーバの方への対処なので、とりあえずはこんな感じで意外と少なかったのはよかったよかった。

まあ、数日もしないうちにキチンと対応されることになると思うけど先っちょを触る人にはそれなりの覚悟が必要だよねっていうごく当たり前の話でした。

www.jmuk.org は lighttpd でやってるけど、 lighttpd には mod_compress というのがあるのにいまごろ気付いた。というかあるのは知ってたけど単に Apache の mod_deflate と同じようなものだと思っていたのだが違うことに気付いた。

lighty の mod_compress では、最初にアクセスしてきたときにファイルを圧縮し、圧縮されたファイルをどこかローカルなディレクトリに保存する。そして次のリクエストには保存されたディレクトリを使いまわす。ようはhttp://www.onflow.jp/blog/archives/2007/06/javascriptcssdeflatecpu.htmlでやってるような機能を組込みで持ってると言うことができる。楽でいいよね。

しかも設定はわずか2行(＋server.modules に mod_compress を追加する1行)。書くのは次の2行で、これは lighttpd.conf のテンプレートにある。

compress.cache-dir = "/tmp/lighttpd/cache/compress/"; compress.filetype = ("text/plain", "text/html", "text/javascript", "text/css")

なお cache-dir で指定したディレクトリは lighty を動かすプロセスで書き込み可能でなければならない(とーぜん)。

というわけでお手軽でいいですね、ということでおしまいなら良かったんだけど、残念ながら問題がある。

まず、上でリンクした先に書いてあるように、 Apache でこのテの処理をするには一部のブラウザを省くのが常道のようだ。一部のブラウザは Accept-Encoding に表示するくせに正しく処理できないらしい。ところが mod_compress の設定はサーバ全体に効くので、そういう設定が効かないわけだ。

いまどき Netscape の4系なんて使っている人がいるだろうかという気もするけど、けっこういる。PCももちろんあるけど PSP とか PDA とかで閲覧している方々だな。こういうアクセスを捨てるのは偲びない。ちなみにどれくらいいるかというと、

% cat /var/log/lighttpd.access.log | ruby -ne 'puts $_.split[0]' | uniq | sort | uniq | wc -l 4618 % cat /var/log/lighttpd.access.log | grep 'Mozilla/4' | grep -v '\bMSIE' | ruby -ne 'puts $_.split[0]' | uniq | sort | uniq | wc -l 37

ホスト名だと 0.8% くらい。下位8ビットを無視すると、

% cat /var/log/lighttpd.access.log | ruby -ne 'puts $_.split[0].split(/\./)[0,3].join(".")' | uniq | sort | uniq | wc -l 1852 % cat /var/log/lighttpd.access.log | grep 'Mozilla/4' | grep -v '\bMSIE' | ruby -ne 'puts $_.split[0].split(/\./)[0,3].join(".")' | uniq | sort | uniq | wc -l 27

1.5%くらいだ。この割合をどう考えるかによるけど、やっぱ気にはなる。

あとそれから、 mod_compress には不要なファイルを削除する機能がなく、ファイルごとに圧縮するしないを判断することもできない(上の設定のように mime-type で圧縮するしないの設定はできる)。とにかく問答無用に圧縮ファイルを作成するから容量は増大し続けると考えられるので、何らかのスクリプトでたまに削除するといった手間がかかる。 Apache の mod_deflate と違って、その場で(メモリ内で)圧縮してファイルに残さない動的圧縮もできない。

てことで、こういったのを解消するために mod_deflate というのが新しく用意されていて、こっちだとそういった処理は可能なようだ(ユーザエージェントは $HTTP["useragent"] で取得できるから、マッチさせて deflate.enabled をスイッチすればいいのだろう)。ただ現在の stable である lighttpd 1.4.x にはなく、先端の 1.5.x にしか存在していない。 1.4.x の lighttpd で使う場合はパッチを充てる必要があり、いささか面倒くさい。

そういうわけで今いきなりこれを使っていいものかちょっと悩んでるところ。とりあえず問題がありそうなのがどれくらいあるかというのが気になるので、アクセスログに Accept-Encoding を書き出すようにしてみた。問題ありそうなクライアントが Accept-Encoding を使ってないようなら、楽でいいんだけどね。

校長先生になろう!

カワバタさんが褒めてたので興味をもって買ってみた本。かなり面白かった。いや、そもそも校長になるのに教員免許が必要ないなんて知りませんでしたよ。

リクルートから校長に転身したという変わり種の校長先生の書いた「校長という仕事」の本。

この本が面白いのは、著者の視点が定まっていること、ビジョンを明確に語っていることだろうか。学校は、学校教育はどうあるべきかっていうのを物凄くはっきりと書いている。書いているなかには、いささか一方的にも見え、しかも生徒にはあまり好かれないような施策を選択しているようにも見えるんだけど(たとえばテレビの試聴時間は制限するべきだという話とかね)、ちゃんとそうである理由を明快に語っているので説得的。「学校を地域に開放するのではなく、学校を核に地域社会を再興する」というビジョンも面白い。

ただまあオレみたいに今さら中学校の教育にはそれほど興味のない身としては面白かったのは、校長の仕事をマネジメントと認識していることかな。「校長には事務屋さんや生活指導屋さんは多いけれども、マネジメント屋さんともいうべき経営者が少ない」。そういう状況をふまえて、校長に与えられたリソースが何で、著者はそれをどう活用してきたか、それはどういう意図があり、どういう効果を生んだか、ということがきちんと書いてある。

あーともちろん、ここで述べられてるマネジメントは校長という特殊な職業のマネジメントなので、仮にあなたが何かのマネージャだとしてもあなたの仕事の役には全く立たないことだけは請け合うが、本としては面白い。

難点。書籍の構成で気になったのは主張に繰り返し/重複が非常に多いこと。強調するために意図的に繰り返していたのかと思っていたら、奥付によればぜんぶで7つある章のうち5つは、ほかのところに掲載された記事とかの再録で、それが理由だろう。とはいえ、全体の半分弱を占めるのが書き下ろしのパートで、ここは108個の項目で著者がやってきた取り組みを説明し、分析するというところだから既読の人がいてもそれほど損した感覚はないんじゃないかな。