enbug diary

_ なぜ靴下は洗濯後に離れてしまわないのか

洗濯機にいろんな衣服を入れて洗濯します。 靴下は両足の分をペアにして、脱いだらそのまま一緒に入れます。 脱水も終わって開けてみると、あら不思議、ほとんどの靴下がペア同士、ちゃんと近場にいらっしゃいます。 どうしてなんでしょうか。

解釈その一。 気のせいである。そもそも定量的に測っているわけでもなく、 単にペアを干すときに探すせいで、心理的バイアスがかかっていて、 そんな気がするだけである。

解釈その二。 靴下には当然静止摩擦がある。 一緒に入れれば、いくらぐるぐる回され、水が注ぎ込まれても、 摩擦のおかげで離れにくい。

解釈その三。 靴下には科学では解明できない意識がやどっている。 ペアになった靴下はお互いを好む性質がある。 そのため、靴下はペア同士、近くに行きたがっている。

解釈その四。 完全にランダムに撹乱したとしても、入れている衣服の数がある程度少ないときには、統計的に遠くにあるより近くにある（と感じられる）方が多い。 よって、単なる統計のマジックに過ぎない。

解釈その一が当たっていることは否めない。ちゃんと実験したわけではなく、真面目に勘定したこともない。 そもそも近くの定義がいい加減なんで。

解釈その二が当たっているとすれば、洗濯開始前から洗濯終了後まで、靴下のペアは常に近くに存在していなければならないことが自明である。 これは途中で開けて観測すればわかるかもしれない。

解釈その三は当たっていてほしくない。

解釈その四は、幾何学モデルを作って、真面目に計算すれば証明できそうである。 誰かやってみてほしい。

_ Shift_JISなファイル名を含むZipファイルを解凍する

要するにタイトルの通りなんですが、 よく知られているように、 Windowsで日本語を含むファイル名があったとき、 Zipファイルの中にはそのままShift_JISでエンコードされたままの文字列が入ってきます。 そして、Linuxとか、普通UTF-8を使うことになっている環境で展開しちゃうと、unzipが頭悪くて、うまく変換してくれたりはしません。 もっと悪いことに、Shift_JISは2バイト目にASCIIコードで言うとバックスラッシュ相当のコードが入っていたりするんで、 これをunzipがパスの区切りだと勘違いして、変なディレクトリを掘ってくれたりとか、もう勘弁してくださいって状態になります。

Ubuntuとかには、対策済みのunzip-jaとかがあるらしいんですが、 私の使っているMandriva Linuxにはそんなものはないみたいです。 自分でRPMを作ってもいいんですが、面倒くさかったので、 手っ取り早くPythonで作ってしまいました。 即席なので、機能もコードもいい加減ですが、一応自分に必要な程度には動きます。

#! /usr/bin/python

import zipfile
import sys

zips = sys.argv[1:]
if not zips:
    print 'Usage: unzip-sjis ZIPFILE...'
    sys.exit()

for zip in zips:
    print 'Archive:  %s' % (zip,)
    f = zipfile.ZipFile(zip, 'r')
    try:
        for member in f.namelist():
            try:
                name = member.decode('sjis').encode('utf8')
            except:
                # maybe UTF-8 originally
                name = member.decode('utf8').encode('utf8')
            print '  inflating: %s' % (name,)
            out = open(name, 'wb')
            try:
                out.write(f.read(member))
            finally:
                out.close()
    finally:
        f.close()

フォルダーのあるZipファイルには対応していないし、パスワードとかも無視しているし、解凍したファイルを一度にメモリにロードしちゃってるので、無駄にメモリを食うし、ツッコミどころは満載ですが、 私はこれぐらいでとりあえず済んでいるので。 足りてないところを直すのは簡単なので、当分このスクリプトで耐え忍ぶ予定です。

正直に言って、Arkが対応してくれていないのが一番厄介なんですが。

_ Zope/Plone開発勉強会に行ってきた

昨日、(第0回)Zope/Plone開発勉強会 に参加してきました。 みなさんご苦労さまでした。

いやー、やっぱり開発者のイベントって面白くていいですね。 開発者でない人ばかりだと、どうしても表層的な話題ばかりになりがち。 参加者が「今あるものがすべて」ではなく、「これからどうしていこうとしているのか」という話ができますからね。 しかもコードを書くイベントなので、書いている最中にわからないことが出てきた時に、近くの人にいろいろ相談できるので、オンラインだとネタになりにくいことまで見てもらえるので、とっても便利。 学部生時代のクラブ を彷彿とさせました。

私は不良なので、平気で遅れていって、着いたのが11時40分ぐらい。 参加者の大半は、UnicodeSplitterをやるグループ、pasterやbuildoutを使ってPloneで何か作ってみるグループに分かれて、 私自身は Localizer をZope 2.12で使えるようにzope.i18n用にlocal utility化するのがテーマ。 残念ながら、Zope2のようにcontent spaceにオブジェクトを置いてlocal utilityとしてregisterするための流儀がよくわからなくて、 それを調べながら試していくだけで時間オーバー。 成果としては、

• five.localsitemanagerというパッケージに入っているmake_objectmanager_siteを使ってlocal site managerを作るのが現在は正しいらしい。
• Zope2のAppオブジェクトもちゃんとlocal siteになれるらしい。
• content spaceに置くlocal utilityを自動的にregisterする（スマートな）方法は、Zope2標準ではないらしい（ただし、Plone + GenericSetupなら適当なxmlを適当な場所に置けばできる）。

ということがわかったぐらいです。 次回はもっと実のある成果を出したいです。

終了後は懇親会で焼き鳥屋。 久々に会った人や初めて会った人（オンラインでは知っていた人を含む）と、技術の話、コミュニティのこと、お仕事にまつわるあれやこれや等をダベることができて楽しかったです。

なお、この勉強会（開発会？）は来月以降も毎月開催されることになりました。 これをきっかけにコードで世界に語りかけることのできる人がもっともっと増えていくことを願ってます。 Zope以外でも、こういう開発イベントが増えるといいですね。

参考：

• 寺田さんの報告
• たかのりさんの語る、今回のきっかけ
• 清水川さんの報告
• ytakeuchさんの言い訳（笑）

_ Nexedi Japan一周年記念

昨日は、うちの会社 がようやくというか、早くもというか、設立一周年を迎えましたので、 社員全員でパーティを開こうということなり、 駒形どぜう でみんなでどじょうなべを食べてきました。 どじょう自体は、まあこんなもんかなあという程度のおいしさでしたが、 こういう機会でもないと食べようともしないので、 悪くなかったと思います。

ここまで頑張ってこられたのも、世界中に散らばるNexediのスタッフ、出来たばかりの会社にもかかわらず、お付き合いくださったお客様たち、まだまだ勉強不足の私を励ましてくださるジャーナリストやオタク仲間のみなさんのおかげです。 ここまでの1年間は会社という組織を形作ることで精一杯でしたが、 次の1年間はNexediという会社が日本でも少しは役に立っているというところをもっとお見せしていきたいと思っています。 今後ともよろしくお願いいたします。

_ ThinkPad X40 + PhotoFast G-MONSTER SSD

もう長い間使い続けているThinkPad X40ですが、 少々延命措置を下すことにしました。 いろいろと問題があって、

• 元から挿さっていたHDDは40GBで、いつも残りを気にしながら（掃除しながら）使うのが鬱陶しい上に、時間の無駄。容量にもっと余裕がほしい。
• しかもこのタイプのHDDはすでに生産中止になっており、もっと大きいサイズのHDDに乗り換えることも難しい。
• そしてとにかく遅い。だから作業効率が悪い。

それでSSDのことは前から気にはしてましたが、性能といい信頼性といい、出回りはじめたばかりのSSDに手を出すのはまだ早すぎると判断して、ずっと様子見を続けてきました。

しかし先日 PhotoFast G-MONSTER 1.8インチ SSD が発売され、MLCながらSLC並の性能を持ち、なおかつ、 変換アダプター無しでX40に挿せてしまう、なおかつ、 64GBで今より大きい、というモデルが出現したので、 ようやく乗り気になりました。

自分でファームウェアをアップデートするのは、DOSが必要で面倒くさかったので、最新にしてくれていると明記されていた SSD Laboratory で購入しました。 かなり速攻で届けてくれましたが、クロネコヤマトのおかげで実際に手にするのはちょっと時間がかかってしまいました...

それで、換装ですが、私はLUKSで暗号化したUSBディスクにバックアップを取っているので、LUKSの使える環境じゃないと、書き戻すことができません。 USBメモリを買ってきて、LUKSが使えて、USBメモリに簡単にインストールできそうなディストリビューションを探したところ、 grml がちょうどよさげだったので、これを使うことにしました。

後は、grmlを起動して、rsyncでUSBディスクに書き出して、 抜き差しして、再びrsyncでSSDに書き戻しました。 この際、フラグメンテーションがあるなら、それも解消しておきたかったので、パーティション生コピーはせず、ファイルシステム・レベルでコピー。 rsyncはversion 3になってから、ファイル・リストを生成せずにコピーできるようになったので、かなり快適でした。

この後は、chrootして、GRUBを手動再インストールして、MBRを設定して、いざリブート。でもroot filesystemがマウントできず、失敗。 何でかというと、最近のMandriva LinuxはUUIDでマウントするデバイスを探していて、ファイルシステムは作り直してしまったから、UUIDが変化してしまっていて、駄目になったというわけでした。 他にもUUIDを書いているところがあったら面倒だと思ったので、手っ取り早く、前のUUIDに替えてしまいました。

これでちゃんと起動するようになりました。 おおすげー速い！とか感動していたのも束の間、 時々フリーズすることが判明しました。

でもこれは巷で言われているプチフリーズではなくて、 ataドライバがtimeoutを起こしているから、のようで、 しかしそもそものtimeout以前に妙なことが起きているようでもあり、 どうもよくわからない問題でした。

試行錯誤を繰り返して、どうにか解決できました。 単にSMARTをoffにしてしまえば済むようです。 SMARTがonになっているとなぜ駄目なのかはわかりませんが、 どうせSSDでSMARTがあっても役に立たないだろと思ったので、 あまり気にしないことにします。 smartdが起動時に勝手にonにしてくれるので、 smartd.confを弄っても良かったのですが、 特に用はなさそうなので、smartdを立ち上げること自体をやめてしまうことにしました。

SSDは寿命の点では、MLCでもあることだし、若干不安ではありますが、 いずれにせよ、このマシンの寿命はもうそんなに長くはない気がするので、壊れたら潔く諦めるという方針です。 日頃のバックアップを怠らなければ、それほど困ることはないでしょう。

速度の点では、素晴らしいです。今まで遅すぎたと言えなくもないのですが、体感ではっきりわかる速度向上です。 価格も手頃になってきましたし、1.8インチの遅いHDDを持っている人はそろそろ試してみてもいいんじゃないかと思います。