サーバ移転作業はどこか反省会に似ている

サーバを新しくしようと思って1年も前に新しいVPSを借りていたのに、何だかんだと後回しになってしまい、そうこうするうちに若干抜き差しならぬ状況になった。近いうちにハードウェアメンテが入り、日中に30分くらい停止するというのである。それで急遽、一気に移転を済ませてしまわなければならなくなった。

サーバの移転というのは、要するに新しいサーバに前と同様の環境を構築し、データを移植してやる作業である。しかしなかなかこの1行余りで済むような話でもない。そもそもまったく同じ環境を構築することからしてできない。サーバのOSやアプリケーションにもサポート期間というものがあり、まあ使っているソフトが消え失せることはほとんど無いが、バージョンを上げずに済むこともほとんど無い。従って、データを移植したら検証作業が必要になる。検証をすると、まあ大抵は何らかの不具合が出る。ので、細々とした修正をちまちまと施さなければならぬ。これまで何度かサーバを新しくしているが、この辺のプロセスをすっ飛ばせたことは一度とて無い。

検証と修復をしていると、否応なく昔の自分のコードをメンテナンスすることになる。昔書いたコードで今も動いているもののうち、最も古い部類のものには2003年の署名がある。実に14年前である。過去の自分は他人だとか何とかいうが、14年も前だと他人どころか先史時代を生きていた遠い祖先のようなもので、そのあまりのあんまりさ加減にクラクラする。こんなものが幾星霜を経ていまだに動作しているのは実際驚くべき事である。もっとも、これは主にperl開発陣の素晴らしい努力の賜物であって、ぼくの功績ではひとつもない。

時間さえあれば全面的に書き直してしまいたいけれども、今だって新たに書かなければならないコードはいくらでもある。まあ過去の自分も未熟なりにいろいろと考えて書いており、何かと不満はありつつも手を入れねばならない箇所は毎回それほど多くはなく、よほどセキュリティ的にアレだとかそもそも動かないとかいう場合は別だが、ほぼそのままにしている。どうせまた1年くらいしたら、今書いているコードにだって不満が出てくるのだ。

Mac mini (Late2014)のWindowsを7から10にアップグレードした

Mac mini (Late 2014）にBoot CampでWindows 7 Proを入れて使っていたのだが、流石に潮時のように感じられたので、Windows 10にアップグレードすることにした。ところがうまくいかない。マイクロソフトのサイトからアップグレードツールを拾ってきて起動し、Windows 10をダウンロードしてPCをチェックして……までは良いのだが、その後で止まってしまう。「このデバイスはWindows10で互換性がありません」とあり、Iris 5100の名が書いてある。検索してみると同じところで引っかかっている人が結構いるようだ。

アップグレードするのは正直面倒だが、アップグレードできないとなると意地になるのが人間というものである。どら焼き片手にあちこちを見て回っていたところ、アップルのフォーラムの英語版にヒントらしきものがあり、それを参考にしたら何とか無事Windows 10にアップグレードすることができた。冗長なので全ては書かないが、要点としては次のようなものだ：

1. デバイスマネージャからディスプレイアダプタを見付け、Iris 5100のドライバの削除を選ぶ。
2. 本当に削除するかを聞かれるので、ファイルも削除するようにチェックを入れて実行。
3. 再起動するかどうかを聞かれるが、この段階では再起動せずに作業を続ける。
4. 画面が低解像度に切り替わるが、慌てずにWindows 10アップグレードツールを実行する。

この手順を踏むことにより、互換性云々で躓くことなく、インストールを開始することができた。後は画面の指示に従って適宜進めるだけである。アップグレード直後も画面表示が何となく変だったりするが、ぼくの手元ではディスプレイドライバをきちんと見付けて自動でインストールしてくれた。手順3のところで再起動すると失敗するのかどうかは試していないのでよくわからない。が、フォーラムには「絶対再起動すんな」と全部大文字で書いてあったので、おそらくうまくいかないのだろう。

なお、この手順はマイクロソフトやアップルが公式に認めたものではない。環境によってはうまくいかないかもしれないし、うまくいかなかったからといってサポートが助けてくれるとも限らない。要するにくれぐれも自己責任でどうぞというアレである。ま、うまくいかなかったとしても、ディスプレイドライバを入れなおせば少なくとも原状復帰はできるはずだから、その辺の理屈がわかっていて同様の症状にお悩みなら、試す価値はあるだろう。

第70期将棋名人戦がもうすぐ始まる

名人戦がこの10日から始まる。今期は森内名人に羽生二冠が挑戦という構図。去年のまったく逆である。ニコニコ動画のプロモーションによると、この10年間、名人位はこの二人だけで争っているのだそうだ。将棋の名人戦というのは、名人は迎え撃つ側なので特に何をせずとも名人戦を迎えることになるが、挑戦する側は順位戦というリーグ戦で優勝する必要がある。将棋の順位戦にはA〜C2まで実績ごとに五つのリーグがあるのだが、プロ棋士はまずフリークラスからキャリアが始まり、やがてC2、C1……というように昇級していく。そして上り詰めたA級順位戦で優勝して初めて名人に挑戦することができるのだ。要するにA級というところは猛者の集う場所であって、そんな場所で森内名人と羽生二冠は交替々々に優勝しつづけているということでもある。

ところで、最近の小学生には将棋が結構な人気を誇っているそうである。カードゲームといい将棋といい、これだけデジタルコンテンツが身近になると、逆に手で触れられるものに新鮮さを感じるということなのかもしれない。そんなことはともかく、そんな世相を反映してなのか、近頃ニコニコ動画は将棋連盟とやたらと仲が良い。今年のはじめに米長会長がボンクラーズと対戦して苦杯をなめたのは記憶に新しいが、あの棋戦の主催者のひとつであり、また生中継をしたのもニコニコ動画だった。この他にもタイトル戦や将棋祭りの中継なども盛んに行っている。

で、今年はなんと名人戦を全局中継するのだそうだ。去年の名人戦では宝塚でも対局があり、これ幸いとばかりに見物に行ったのだが、今年は最も近くて京都である。これはちと無理だなと思っていたところだったので、白林檎としても大変に喜んでいるところである。

考えてみれば将棋とネット生中継というのはなかなか相性が良い。ときには十時間にも及ぶ映像をだらだらと流しつづけることのできるテレビ局など、この世に存在しないであろう。放映に多大なコストがかかる割に、視聴する層が限られてしまうからだ。名人戦などの二日制タイトルともなればなおさらで、二日間合計二十時間近くもチャンネルを占有することなど、普通の放送局には不可能である。しかし、チャンネルという概念のないネット中継ならそれが可能になるのだ。もともと棋戦はFlashを使った棋譜中継などもあって、ネットとの相性は悪くなかった。ニコ動によってそれがさらに向上したと言える。

これは何も将棋に限ったことではなく、長時間に及ぶ試合の生中継、例えばプロ野球なんかにも格好の形態である。実際、すでに楽天の試合はニコ動で中継されている。ニコ動での中継ならば放送時間の延長によって予約録画に失敗するという悲しい現象もなくなるし、また途中で打ち切られることもほぼ無い。サッカーだって同じで、プレミアリーグか何かの中継も確か開始されていたはずだ。そういったメジャーなスポーツだけでなく、あまり世間で知られていない競技でも、ニコ動などのネット中継なら、従来よりずっと簡単にお茶の間に届けられるようになるかもしれない。これはなかなか楽しい事態だ。

最後の方はちょっと将棋から話が外れてしまったが、とにかく楽しい時代になったものだと思う。

携帯電話の機種変更をした

来年から携帯電話用の電波の帯域割当が変更になり、一部のキャリア、つまりauの古い機種は利用できなくなる。これはどういうことかというと、白林檎の使っている機種が割当変更以後は不通になるということである。というので、今年の春頃から、auから機種変更の優待割引を案内するダイレクトメールが度々届いていた。この機種なら無料で交換しますよ、こっちの機種もこんなにお安くなりますよ、そもそもあなたの機種は来年から使えなくなるんですよ、さあ変えろ今すぐ変えろと、まさに矢の催促である。しかしぼくは生来メンドウなことが嫌いであるのと、長く使っていた日立の機種に愛着があったので、なかなかauショップに足を運ばなかった。

そうこうする内に夏モデルが発表されて、ちょっと気になる機種が出た。京セラのK009である。スタイリッシュな上に使いやすそうで、これが優待の対象になったら機種変更をしても良いと思えた。で、さらに時間が流れて11月の末頃、またauからダイレクトメールが届いた。そしてこれに件のK009が優待割引、それも無償交換対象と書かれていたので、ようやく変更してきたという訳である。

ところでぼくの使っているのはauであるから、当然iPhoneやAndroid搭載スマートフォンにも変更が可能である。それでもK009を、というよりいわゆるガラケーを中心に検討したのは、スマホが電話としては使い物にならないからだ。耳に付けて通話をしたら液晶画面に脂がべったり付きそうだし、何より電池の保ちが悪いのはいただけないと思ったからである。

こういうことを書くと「スマホを電話として捉えるのが間違っている」と言い出す人もいるだろうが、これは反論にはならない。スマホが電話としては使いにくいことを暗に認めているからだ。もっと言えばぼくと同意見な訳である。というより、これは機械マニアにとっては共通認識とでもいうべきもので、ガラケーが携帯電話に様々な機能を追加する方向で進化してきた機械であるのに対し、スマートフォンはごく小さなパソコンに携帯電話をくっつけたようなもので、はっきり言えば通話機能はオマケみたいなものなのである。スマホの携帯電話機能を通話に使わないなら何に使うのかといえば、Webやメールなどのデータ通信回線として使うのである。要するに、スマホは従来のケータイから機種変更する物というより、普段からノートパソコンを持ち歩いていた層が荷物を軽くするために買い足す物なのだ。

猫も杓子もスマートフォンというご時世に、少なくとも周辺からは機械マニアだと思われている白林檎が従来型のケータイにわざわざ機種変更したのは意外に思われそうだが、それは大体上記のような理由からである。確かにぼくはどちらかといえばスマートフォンが欲しい側の人間だが、どちらかひとつを選べと言われたら、今のところ必要なのは携帯電話の方だったのだ。また、一定の範囲内では常識と言えそうなことをこれまたわざわざ書いたのは、万が一キャリアのエライ人か何かの目にとまって、スマートフォン一辺倒な現状が改善されればと思ってのことである。

スマートフォンは素晴らしい機械だから持つ人には満足してもらいたいし、ユーザを満足させるだけのポテンシャルをスマホは確かに秘めている。実際、満足している人たちもたくさんいることをぼくは知っている。一方で、電池や料金のことなどで、不満の声が絶えないのも事実だ。おそらく携帯電話と勘違いして入手したそういう人々の怨嗟の声で、スマートフォンのブームに水が差されてしまってはもったいない。いっそのこと「次世代型携帯電話」という類の呼び方や煽り方は止めた方がいいのではないかと思う今日この頃である。

HTML5

Flashの代替だのスマートフォン向けコンテンツ制作だの、そういう面ばかりが強調されるHTML5。そういう話ばかり耳にしていると何だかHTML3の時代に逆戻りするような気がして食わず嫌い的に敬遠していた白林檎だが、実際に触ってみたらまったくそんなことがなく、むしろHTML4よりも構造化文書を作りやすいので驚いてしまった。変な勘違いをして本当に申し訳ない。

アプリケーションがどうこうというのは無論JavaScriptやサーバサイドスクリプトと組み合わせた場合の話で、当たり前だがその点はHTML4の頃から何も変わっていない。それなのにこれだけ取り沙汰されているのは、HTML5から仕様に加わったcanvasが非常に柔軟だからだ。テストページを組んだついでにJavaScriptでcanvasと戯れてみたが、図形描画からピクセル画像の操作までかなりのことができるので、確かにちょっとしたアニメーションくらいならすぐにでもFlashの代わりが務まりそうである。

ただ、ブラウザだけで動くものというのは、いつの時代も互換性の問題が付き物だ。プラグイン動作でそれに考慮しなくて良いFlashはそれだけでやはり作り手にはありがたいし、それがOSベンダーの都合で徐々に潰されていくのはちょっと釈然としないものがある。HTML5そのものは素晴らしいものではあるが、選択肢がそれだけになってしまうのでは、Webに関わる者のハシクレとして、どうしても手放しでは喜べない。

まあ、そういったモヤモヤ感が残るにしても、HTML5は面白い。上記とは矛盾するようだが、ブラウザだけで動くものをエディタでちまちま作っていくこの感じは、それこそ90年代の、ブラウザもFlashも未成熟であった頃が思い出されて懐かしい。冒頭に書いたようにsectionやnavなど合理的な要素も増えているし、これが標準化される日が待ち遠しいというのも正直な気持ちである。我ながら複雑だ。

MacCVS ProでOpenOffice.orgのCVSを使うメモ

ちょっとした手伝い程度の作業だが、何年かぶりにOpenOffice.orgのサイトに関わることになった。ソフト自体は使い続けているものの、プロジェクトの方に関わるのは随分と久しぶりなものだから、CVSへのコミット方法を綺麗サッパリ忘れていて、我ながら驚いた。それで色々とググったりしていたのだが、当てにしていた記事が影も形も無かったりして、少なからず戸惑ってしまった。また忘れたら嫌なので、ここにメモしておくことにする。

なお、言うまでもなくMac OS Xからコミットする方法である。バージョンはMac OS Xが10.4、MacCVS Proが3.0。誰か別の人の参考になるかどうかは知らない。

ちなみに、もしOOoに貢献したい人で、万が一この記事を参考にする人のために書いておくが、事前準備として、まずはOpenOffice.orgのサイトにユーザー登録し、コミットするプロジェクトに参加した上で自分のSSH公開鍵をサーバに登録してもらい、コミット権を設定してもらう必要がある。著作権関連の手続きがあったような気がするが、この辺は今回の主題ではないので、詳しくは述べない。ちょっと長いので以下追記の中に格納する。

続きを読む

NSIを騙るスパムメールが鬱陶しい

昨日あたりから急にドメイン管理関係のメールが増えて、差出人を見てみるとNetwork Solutionsナントカdivisionとある。うちにNSIで管理しているドメインは無いのにおかしいなと思っていたら、今日も次から次へと届く。中を見てもさっぱり要領を得ない。ちょっとググってみたら同じようなメールを受け取っている人が何人もいて、やはりどうやらスパムのようだ。

仕事柄、ドメイン関連のメールは一応目を通しておかないと気持ちが悪いので見ていたが、スパムなら迷うことはない。今後はすべて即刻削除しよう。

それにしても、仕事関連で紛らわしいスパムは何と鬱陶しいものだろう。大抵のスパムは件名だけでポイポイ捨てているのだが、NSIを名乗られるとつい見てしまう。流石に記載してあるURLにアクセスしたりはしなかったが、これと似たような手口で、銀行を騙ったフィッシングに引っ掛かってしまう人が多いのも仕方がないような気がする。

ウルトラチャンネル@YouTube

スラッシュドット経由。ウルトラマンでおなじみの円谷プロダクションが、この度YouTubeに公式チャンネルを開設した。開設と同時に無料配信されるのは、ウルトラＱ、ウルトラマン、ウルトラセブンなどの第一話とのことで、今後も第二段、第三段と公開していくそうだから、目が離せない。

ぼくは子供の頃、夕方のテレビで確か『ウルトラマンＡ』を見ていたが、ウィキペディアによればこれは1972年の作品らしいから、明らかに再放送であろう。リアルタイムなのは『ウルトラマン80』のはずで、弟と共に母に連れられて映画も見に行った記憶があるが、どういう訳かテレビでは見た事がない。一方で『ウルトラマン』や『ウルトラセブン』『帰ってきたウルトラマン』はほとんど見た事があるし、『ウルトラＱ』も数話見て怖い思いをしたような気がする。もちろんいずれも再放送だが、名作はいつまで経っても名作ということなのだろう。

円谷プロに限らず、大手コンテンツホルダーが自ら作品をYouTubeなどに公開しはじめたのはとても良い傾向だ。惜しむらくは、このような動きが「やっぱり」海外のサービスを中心に動いていること。ニコニコ動画をはじめ、国内の動画共有サービスが軒並みアングラ扱いされている現実はどうにかならないものだろうか。

国内の動画配信サービスといえばGyaoなんかもあるが、あれはWindowsでしか観賞出来ないから、Mac使いの白林檎としては論外もいいところである。何の意味もないDRMを付けなければ国内ではコンテンツを配信させてもらえないのだろうから仕方がないのかもしれないけれど、このままでは日本発のコンテンツが海外サービスでしか自由に楽しめない未来が待っている。それは心底悲しむべき事態だ。どうせ今のままでは地デジはこけるしかないんだから、テレビ局はじめコンテンツホルダーは色々と考えを改めてはどうだろう。

SPFとかDomainKeysとか

ドコモが迷惑メール対策にSPFを採用したり、Yahoo!メールやGMailがDomainKeysを導入していたりして、ここのところメールが不達になることが多く難儀しているというかいい加減頭に来たので、渋々ながらメールサーバに対策を施すことにした。

とりあえず手軽なSPFから。これは本当にお手軽で、DNSに次のようなTXTレコードを入れてやるだけだ：

example.com. 7200 IN TXT "v=spf1 +ip4:192.168.0.1 -all"

これを、example.comのDBファイルに記述してやる。要するに「このドメインのメールはこのIPアドレスからしか飛んでこないはずであります」と宣言してやる、ということのようだ。

SPFが案外すんなり終わったので拍子抜けしたが、気を取り直して次にDomainKeysの導入である。実はDomainKeysにはDKIMという親戚筋に当たる後発規格があって、IETF標準になっているのだが、肝心のYahoo!メールとGMailがこれに対応していない。後々のことを考えればDKIMにすべきなのはわかりきっているのだが、この両者が対応していないのでは白林檎的に現状お話にならないので、ここは敢えてDomainKeysを導入することにした。

まあ、元々が似たような仕組みだから、将来的にDKIMに乗り換えたくなっても、それほど苦労はしないはずだ。あらかじめDNSにDKIM用のレコードも書いておけば、Postfixのmaster.cfをhogehogeするだけで何とかなるはず（もちろんDKIMフィルタをインストールしてからだけど）。

さて、DomainKeysを利用するには、SSLの鍵を用意しなければならない。面倒だなぁと思っていたのだが、調べてみたらそれほど手のかかる作業でもなかった。とりあえずdkfilterをportsからmake install。その後、このページを参考にしながら作業を進める。途中、鍵の置き場所を/usr/local/etc/dkfilterにしたこと以外は、ほぼこのままの手順で導入が完了した。

あまりにもすんなり事が運んだので呆気にとられたが、[e-mail]に送ってテストしてみたところ問題ないようなので、これにて一応作業完了。

引き続き事の発端であるYahoo!メールの自分のアカウントにも送ってみる。一応DomainKeysのテストはパスしているのだが、何故か迷惑メールフォルダに入ってしまう。「迷惑メールでない」ボタンを押している内にスパム判定はされなくなったようだが、どういうロジックになってるんだか。ひょっとして、DomainKeysを入れるのって、Yahoo!メールのスパムフィルタに対してはあまり意味がないのか？　そんならDKIMにするけど。GMailはどうなんだろうか。

無理々々

SennaのFreeBSD 4.11へのインストールだが、どうにもうまくいかない。断腸の思いで--without-mecabしてみても駄目だ。ちなみに--without-mecabすると、pthread関連の書き換えを行わなくてもconfigureは通った。

どう進めても、必ず同じところで止まる。lib/com.cの317行目で、storage size of 'msg_iov' isn't knownとかエラーを吐く。getpagesize()への書き換えくらいならやるが、ここまで来るとソース等を理解していないとどうにもならなさそうだ。

という訳で、あまりこれにばかり時間を食っても仕方がないし、ここは一旦撤退。そのうち、手元のPCにFreeBSD 6.2あたりを入れて、そっちで試してみることにしよう。

FreeBSD 4.11にSennaを入れ……たい

という訳で、引き続き全文検索エンジンSennaのインストールである。portsにも入っているが、雰囲気的に無理だったので、例によってソースを拾ってきてビルドすることにする。

Sennaは主にLinux上で動いているらしく、ググってもFreeBSDで動かしている例があまり見付からなかった。だからなのかどうなのか、こちらもpthread関連で引っ掛かった。今度はconfigureが通らない。pthreadならと思って、試しにMeCabのときと同じようにsedしてみる──お、通った。

引き続きmakeしてみると、いきなり止まる。io.cで_SC_PAGESIZEが宣言されてないとか何とか。ソースを見てみると、sysconf(_SC_PAGESIZE)がそれのようだ。面倒なのでgetpagesize()に書き換えてしまう。すると、どうやらそのエラーは乗り越えられるようになったようだ。

──が、まだ止まってしまう。これも長期戦になりそうだ。とりあえずカレーを食べて、温泉に浸かってくることに決定。やれやれ。

続・MeCabを入れてみ……たいんだけど……

gcc 3.4のmakeが終わったので、満を持してMeCabのコンパイルを開始。ところが、またエラーで止まってしまった。やはりスレッドがどうのこうのと言っている。とすると、gccのバージョンの問題ではないのだろうか。

試しに手元のMac OS X 10.4でコンパイルしてみる。念のためgccのバージョンを確認してみると、4.0のようだ。結果だけ述べると、configureもmakeも何の苦労もなく通った。どうやらgcc 4でも難なくコンパイルできるらしい。

じゃあ何だろうな、と考えていて、ハタと思い出した。そういえばFreeBSDのpthreadって何かあるんじゃなかったか。それが何だったかは詳しく思い出せないが、とにかく何かが潜んでいたような気がする。

もう一度portsからmakeしてみる。もし本当にFreeBSDに特有の現象なら、portsではそれをうまく回避しているはずだからだ。しばらく眺めていると、エラーで止まってしまったが、configureの前に興味深い一文を見付けた。sedで、configureの、おそらくpthreadに関連する部分を書き換えている。

その文をconfigureのパスだけ書き換えてソースの方に直接適用して、作業してみた。

% /usr/bin/sed -i.bak -e 's/-lpthread/-pthread/g' -e 's/-O3/-O -pipe /' ./configure

% ./configure CC=/usr/local/bin/gcc34 CXX=/usr/local/bin/g++34 F77=/usr/local/bin/g77-34

% make

さあ、これでどうだ。素数を数えながら待っていると、やがて音もなくコンパイラが終了。おお、おお、どうやら通ったようだぞ。万歳。

IPA辞書の方はこれといった苦労もなくインストールできた。さあ、次はSennaだ。でもその前にちょっと休みたい……。

MeCabを入れてみ……たいんだけど……

Webコンテンツの整理をしてサーバが一台空いたので、ぼくはこの機に以前から考えていたことを試してみようと企てた。Sennaを入れてみようと思うのである。そのためには、まずMeCabを入れなければならない。

MeCabというのは近年話題沸騰中の形態素解析エンジンである。和布蕪が名前の由来なのだそうだ。日本発のオープンソースプロジェクトには、こういう茶目っ気のある名前が多くて楽しい。

名前だけでなく、これは機能的にも面白いソフトなのだ。受験勉強の際、誰もが文法とか品詞なるものに悩まされた経験をお持ちだと思うが、MeCabは何とそれを自動で解析してしまうのである。つまり「すもももももももものうち」という文を、「すもも|も|もも|も|もも|の|うち」と品詞レベルに分解し、さらには各句が名詞であるとか助詞であるとか、そういったことまで教えてくれるのだ。

国語が苦手だった方には、これがどれほどすごいことかおわかりいただけると思う。ただ、それが何の役に立つのかというと、いまいちピンと来ないという方も多いのではなかろうか。だが、MeCabのような形態素解析技術がなければ、全文検索は不可能に近い。

例えば、「京都府」でググったとする。すると、検索結果として、京都に関するページが多数ひっかかる。そして驚くべきことに東京都府中市に関するページは、少なくとも50件以内には決して出現しない。形態素解析技術がなければ、こんな芸当はとてもではないが無理なのである。

まあ、それはさておき。

MeCabはFreeBSDのportsにも収録されている。ぼくは万事にテキトーな人間なので、まずは何でもportsに頼ることにしている。というわけで、例によってmake install。ところが、エラーで止まってしまう。まあ、FreeBSD 4だしな、メジャーバージョンで二つも古いんだもんな、仕方ないかな、と思いつつ、ソースからインストールすることにした。

といっても、portsとそれほど作業が変わるわけではない。configureしてmakeするだけだからだ。ところが、こちらでもコンパイルが途中で止まってしまう。

流石におかしいと思って、Google様に聞いてみると、どうやらgccが古いとエラーで停止してしまうようだった。stringのclear()がないからということで、そのページではソースを修正してコンパイルを通す方法が紹介されていたが、grepしてみたらこれがやたらと多い。ぼくにはとてもそんな気力がない。

そこで、gccの新しいのを入れることにした。これもportsに入っている。どうせなら最新版が良かろうということで4.2を入れた。さあ、これで準備は整った……と思ったら、またエラーが出る。今度はスレッドがどうとかこうとか。困ったな。

落ち着いてMeCabの公式ページを見てみると、コンパイルはg++ 3.4.xで確認済みと書いてある。最初からこれを確認しておけば良かったのだ。そそっかしいにも程がある。眠い目を擦りながら入れたgcc 4.2を泣く泣くアンインストールし、目下gcc 3.4を絶賛make中である。これでちゃんと入るといいなぁ。

SPAMフィルタリング

メールサーバをPostfixに移行しようと思って、かれこれ二ヶ月余りダラダラ作業をしている。あまり急ぎでないのもあるのだが、ひとつだけどうしても解決できない問題があって、仮運用の域を出られないというのが大きい。

すなわち、SPAMメールのフィルタリングがもう一歩のところでうまくいかないのである。

正確にいうと、SPAMの判定自体はうまくいっているのだが、配送先を変えられないのである。現在の構成は、Postfixを軸に、入ってきたメールをまずClamSMTPに渡してウイルスメールを検疫し（これはうまく動いている）、次にSpamPDに渡してSPAMメールを判定してからPostfixに戻し、最後にdeliverquota経由で各ユーザーのmaildirに配送するという流れである。SpamPDはSPAMと判定したメールに印を付けてはくれるのだが、印が付いたメールは結局各ユーザーの元に届いてしまい、何かと面倒を強いることになってしまう。

色々と試行錯誤を重ねた結果、header_checksで印の付いたメールをHOLDするなり何なりすれば良さそうだということに気付いた。しかし、ルールは正しいのに、いまいちうまく動かない。おそらく、戻したあとのsmtpdのオプションに何か間違いがあるのだろう。あと一歩だと思うんだがなぁ。困った。

どうやらドキュメントを扱うモジュールらしい

コメントで指摘されて気になったのでちょっと調べてみたところ、OpenOffice::OODocは、少なくとも従来のバージョンはOOoに接続するのではなく、ドキュメントを扱うためのモジュールのようだ。ちょっと先走ってしまったようである。

とはいえ、OOoとの連携をサイトで取りやすくなるのは間違いなさそうなモジュールである。商品を扱っているようなサイトで、代金をスプレッドシートで管理しているようなところがあったら、結構面白いんじゃないかと思うんだけどな。現状でもCSVで連携出来るけど、「CSVで書き出してくださいね」ってのは、ある程度以上のスキルを持っている相手でないと言いにくいから、「この表計算ソフトで表を作って、保存して、出来たものをこのページからアップロードしてください」というフローを提示できたら、お互いに手間が軽減出来そうだ。

これは大変な本ですよ

まずは何も言わず次のリンクをとっくりと眺めていただきたい：

まるごとPerL! Vol.1
http://home.impress.co.jp/reference/2289.htm

Perlが好きな方もそうでない方も、という内容だ。少なくともPerlに多少なりとも関わりがあるなら、一読しておくべきである。Googleのおかげで手軽に情報を拾えるようになったとはいえ、これだけの情報を体系的に手元に置いておける機会はそうあるものではない。

ちなみに、我らがOpenOffice.org日本ユーザー会からも可知さんと秋山さんが記事を寄せている模様。目次によると「OpenOffice::OODocで作ろう！ Webアプリケーション」とある。OOoをサーバー的に使うことが出来ることは知っていたけれど、Perlモジュールがあったとは知らなかった。これはWeb屋にとって朗報以外の何者でもない。WebサーバにOOoを走らせておいて、クライアント（人間の）が使うPCにはOOoで作業環境を整えれば、面白いことを色々と出来そうではないか。

ところで、Vol.1と銘打っているからにはVol.2も予定されていると心得ておいて良いのだろうか。PC系の雑誌が次々に廃刊に追い込まれる昨今だが、是非とも健闘してほしいものである。

Webの分業体制

スラドにWeb制作者の常識、開発エンジニアの常識というトピックが立っていて、なかなか興味深い。要するに「デザイン方面の人」と「サーバサイド等、技術方面の人」との間で、Web制作に関する知識の乖離がある、という話である。

知識を常に最新のものに保つというのは、ジャンルの多寡に関わらず並々ならぬ努力が必要である。従って、何かに強い人間がそれ以外の何かについて疎くなるのは仕方がない。すべてをカバーしようと思ったら、とても仕事などしている時間はなくなる。問題は、どこで必要・不必要の線引きをするかということになろう。

Webの場合でいえば、HTML+CSSの知識は、デザイナー、デベロッパーの別を問わず必須であると思う。なぜならば、これが両者の接点になるからだ。デザイナーは、HTML+CSSよりも技術向けのことは──もちろん彼がPerlやPHPを書かないのならば、という条件付きだが──知らなくても構わない。逆にデベロッパーは、HTML+CSSよりもデザイン向けの知識、例えば配色だとかタイポグラフィだとか、そういったスキルを持っていなくても、とりたてて問題にするようなことではない。

HTML+CSSの知識を両者が共有していれば、ほぼ理想的な分業体制を築くことができる。すなわち、テンプレートを利用した素早いサイト構築が可能となる。

ここでいうテンプレートというのは、動的なページにおけるレイアウトを定義したファイルをいう。つまり、「ここにはブログのタイトル」「ここには本文」というようなことが、その他のデザイン要素と一緒に記述されているHTMLファイルのことである。WebページをMVCで考える場合には必須の要素だ。

PerlにはHTML::Templateというモジュールがあって、これを使うと思わず床を転げ回りたくなるくらい幸せになれる。まあ、ほとんどのラクダ乗りは知ってるだろうけど。知らない人はテキトーに検索すればすぐに出てくる。詳細は面倒だから省く。

まあそのような訳で、Webに関わる以上、やはりHTMLとCSSは最低限知っておくべきことだと思う。他はその人の嗜好と能力次第であって、自分には無理だとわかったら、共通言語を話せる別の能力を持った人と共同作業をした方がずっと効率が良い。

故に、冒頭のトピックに付いている某コメント文中の「SQLインジェクションとかそういうのは開発の方が考えること」という意見は、それほど不思議な感覚ではないと思うのであるが、どうだろうか。

postfixとcourier-imapでmaildirquotaを使う

メールサーバをリプレース中である。今回は訳あってOSでquotaを設定できないため、maildirquotaを使うことにした。同じ境遇の人（いるのか？）のために、ちょっとしたメモを書いてみる。用意する物はpostfixとcourier-imap。例によって両方ともportsから放り込む。FreeBSD万歳。

まず、各ユーザーのホームディレクトリにmaildirを作り、maildirquotaを設定する。手順としては：

> cd /home/hogehoge
> sudo -u hogehoge maildirmake maildir
> sudo -u hogehoge maildirmake -q 10000000S maildir

な感じ。この例では約10MB程度の設定になる。maildirquotaの実体というか記録ファイルというか、そういったものは、maildirの中にmaildirsizeというファイルで作成される。これのオーナーはコマンド実行時のユーザーになるのだが、うっかりrootで作ったりするとquotaが有効にならないっぽいので要注意である。

とはいえ、ユーザー権限で勝手に変更出来るのはイマイチな気がするのだが、どんなもんだろう。まあ一般ユーザーはシェルにログインさせないので、とりあえず問題ないんじゃないかな。と思う。ダメかな、やっぱり。まあいいや。

さて、次にpostfixのlocalからdeliverquotaに渡すように設定する。これはmain.cfに：

home_mailbox = maildir/
mailbox_command = /path/to/deliverquota /home/${USER}/maildir

のようなエントリーを追加すればOK。

とりあえず以上でpostfixからもmaildirquotaが有効になるはずである。quotaを1KBにして試してみたら、ちゃんとquota exceededでバウンスされている。

POPについては、当たり前だが、courier-imapのpop3dを起動しておくだけで特に問題なく動くようだ。もちろんIMAPも同様だろうが、うちの場合は需要がないので、試していない。

将来的に解決すべき課題は、maildirsizeの肥大化対策だろうか。Perlで適当なスクリプトを書いてcronで回してやれば済むような気もするけど。

ライブドアブログが落ちている

ライブドアブログが落ちているので大変迷惑している（使っている訳ではないが読んでいるブログがある）。おそらく某所からのF5アタックが原因ではないかと思っている。

F5アタックは一種のDoSアタックだが、こんな単純なことでサービスが落ちてしまうあたり、Webはまだまだ未成熟な技術なんだなぁと思う。Web 2.0などといって比較的表層の技術革新（？）にうつつを抜かしていると、こういうところで足下をすくわれそうだ。

WinnyやBitTorrentのようなP2Pファイル共有技術を基礎にしたサーバ不可分散機構の実用化こそ急務であると思う今日この頃。って、もうあるのかな？

OpenPNEが動かん

ApacheをmakeしなおしてもPHPをmakeしなおしてもMySQLをmakeしなおしても設定ファイルを目が痛くなるまで凝視してあちこち書き直してみてもソースを手当たり次第hackしても、どうしてもOpenPNEがちゃんと動作しない。

手元のMac OS Xではちゃんと動くのにFreeBSDのサーバに設置したら不具合が出るのも妙な話で、端から端まで読んだわけじゃないから（読めばいいんだろうが時間がない）、問題の切り分けもうまくいかない。いろいろmakeしなおしてみたりしたのも、処置に窮してというのが本当のところで、入れ直せば何とかなるなどとは欠片ほども思っていないのである。何とかなったら儲け物くらいにしか考えていない。

ずっといじっているうちに、自分で作った方が早いような気がしてきた。とはいえ、ひとりで全部書くのは大変そうだ。もうちょっと頑張ってみよう。いざとなったら自作してくれる。