Intel SSD 320シリーズの8MBのアレの進展とか


 Intel SSD 320シリーズについて、容量が8MBとして認識されるようになる不具合がIntelで認識されたとか何とかの話はこのblogでも以前に…、あれ?
 書いてなかったかも。まあ、そういう話なので、利用者としてはだいぶ気になっていたのだが。
 ここんとこ忙しくて続報とか確認してなかったけど、何となく調べたら昨日にも続報があったようで。公式には"Bad Context 13x Error"と呼ぶらしいが、発生条件はやはり特定状況での電源断で確定っぽく、ファーム更新で対策出来そうらしいけど、リリース前の検証中で二週間くらい待たされる模様。夏場だから電源には不安もあるんで、とっととリリースされて欲しいけれども、まあ検証も必要だしなあ。早く来ないかなあ。


BackWPupにそろそろ疲れてきたかも


 このblogはBackWPupでバックアップを取っているが、2.0.0がバグてんこ盛りで結構困っていて、それ以降アップデートも頻繁にされてじわじわマシになってる感じではあるが、今でも細かい不具合が多い。
 で、2.1.4がリリースされたので入れてみたが、また動かなくなった。うむ。そろそろめんどくせえな…。
 んで、wp-cronでDropboxとかにDBからデータを流せるプラグインねーかな、と一瞬探しかけたが、それもめんどくさいので、Warning出しつつも一応動いていた2.1.3に戻した。むーん。変なとこで411とか吐いてるんで、例によってLighttpdとの相性くささを感じるが。417を吐く問題も出てたしなあ。
 まあでも、色々な用事が立て込んできてて地味に忙しいので、応急手当で様子見したいところ。


BackWPupが復活したけど何かおかしい


 激しく気に入ってたのにバージョン上がったらバグだらけになって、でもなるべく乗り換えたくない、というくらいには気に入ってたBackWPupだが、最近のリリースでようやく一応動くようになった。
 ただ、XML(たぶんWXR?)の出力を使おうとすると、

1. try for wordpress export to XML file...
[ERROR] cURL: (417) Invalid response.

などと吐く。こいつは何だ、と調べてみると、HTTPサーバがExpectリクエストヘッダに対応してない時っぽいような。つってもExpectは色々な使い方がありそうなんで、いまいち原因分からん。ただ、Lighttpdは一番基本的なExpectの使い方にも対応してるんだかしてないんだか分からんような話があった。ふーむ。Apacheに戻したくはないし、Nginxにするほどの話でもないし。
 つーことで、WXRを吐くのはとりあえず諦めることに。DBからのバックアップだけだと少し不安だが。リストアはちゃんと動くのかなーとか。リストアは正常に稼働してる間に試すべきだけどさー。


C9の検索アルゴリズムが面白い


 C9の取引所、FFで言うと競売に当たるソレでは、アイテム名を直接検索することが非常に多い。俺の場合。そして、変なもんにヒットすることも多い。が、慣れると便利な仕様に思えてきた。
 この手の検索だと、キーワードを適当にトークン化して部分文字列のANDマッチングを行うことが多いと思う。だがC9では単純に、キーワード中の全部の文字が現れるならマッチ、という仕様のような気がする。’abc’がキーワードだと、’abechan’でも’became’でもヒットするという訳だ。多分。ちゃんと調べてはいないけど。
 よくよく考えると、トークン化が一文字ずつ常に分割する仕様(Pythonだとlist(str)とか、Perlだとsplit(//,str)だったか)な場合は、同じアルゴリズムになるのか。つーか、漢字かな交じりだからたまたま便利な仕様になっているだけのような気もするし、本来はこういう予定じゃないのかもしれないなあ。修正して欲しくはないけど。
 もう一つ気付いたけど、スペース入れててもちゃんとヒットするから、やっぱり狙った仕様じゃないかもなあ。便利だけどなあ。
 まあ、ゲーム中の日本語アイテム名検索という極めて狭い用途限定での便利さではありそうだけど、別の用途でも同じ手が使える可能性はあるかも。

追記:
 順序も影響してたので(’abc’は’abechan’にはヒットするが’became’にはヒットしない)、やっぱり別のアルゴリズムか。順序も見てるならハングルでも問題出ないだろうし、これはこういう仕様の予感。

再追記:
 どうせなら’abechan’と’beckham’にした方が面白かったなあ、とか思った。


AWSのアップロードがタダになっていた


 最重要データのディザスタリカバリ用バックアップにAmazon S3とか使ってる訳だが、アップロードにもお金が掛かるので、バックアップ頻度は低くしていた。
 が、2011/7/1からAWSのData Transfer Inが無料化されていた。ほっほー。思い切ったことを。つっても、上げるだけ上げて全く落とさない、なんて用途は少ないのかな。うちはまさにその用途だから有難いが。バックアップ用途では以前にも増して安価なサービスになりそうだ。
 ただ、AWSは料金の上限設定が見当たらないんだよな…。まあ、上限に達した時の挙動とかが面倒かもしれないが。スクリプトのバグで何万とか支払うことになると嫌だからなあ。どっかで設定出来ないんだろか。