kumofsに画像をしまって失敗

  • スケールアウトされたサーバー郡からKVSにしまいこんだ画像を引張だすソリューションソリューションをやってみようという試みをやってました
  • 簡単にスケールアウトさせたいのでkumofsを選択
  • 全てのサーバー群に kumo-gateway と kumo-serverを立てる
  • そいつら全部つなげる

これでレプリケーション & ディストリビューションもできた。
なおかつ全部のサーバーから画像を引っ張りだせるなりキテレツぅ！

で、テストを行う

  • Jmeter で 10万回程度setを行う
  • 画像サイズは 500kb あたりを想定

で、ぶん回したら

  • 6万件あたりでkumofsに対してGET/SETができなくなる

という問題が起きた。
ぶっちゃけ、kumofs が大きめなデータに対して弱いのは知っていたが、ぶっ壊れるのは想定範囲外だった・・・。

また、壊れてる箇所がtokyo-cabinetのDBなのかkumo-fsの管理系なのかもわからず。

積んでもうた。

現状ではこれらを何とかする手立てがないので、別手法を考えないといけない。

kumofsは非常に素晴らしいけど

  • もうメンテされてない (息してない感？)
  • kumofs-ng ってgithubにあるけどどうなの？

追記：
調べてみると、Tokyo Cabinetの扱えるDBファイルの最大容量が64Gまでと決まっていたことを知る。
DBを作成する際に

tchmgr create -tl /mnt/data/kumofs/kumofs.tch 100000000

とすればOK。kumofs-serverの起動オプションにも#opts=l をいれておく(これ正しいのかわかんないけどね！)

UItableViewControllerが面倒くさいのでJSONファイルで定義＆テーブル構築できるようにした件

やだ・・私のiOSプログラミング面倒すぎ・・・っ！

特にUITableViewでの "numberOfRowsInSection" やら "numberOfRowsInSection" をif文で作っていくとか
2013年にもなって正気の沙汰とは思えないし、コードが汚れてSAN値がピンチになる。

さすがにもういやでゴザル！！ということで、2011年に plist からUITableView を構築するものを作った。

でもそのコードどっかいっちゃったので、「じゃJSONで定義＋ある程度のユーティリティをもたせよう」ということで、
JSONファイルだけで

  • cellを押した際のアクション指定
  • 次のViewControllerへの遷移
  • セル中にテキストフィールドを埋めたもの

が簡単につくれるようにしたものを作った

https://github.com/salexkidd/UITableViewControllerFromJson

超絶楽にはなったものの、すでに誰かこういうの作ってそうなんだが・・・誰かもっといいのあったら教えて下さい。

>>> 表示しておくんなまし(ハローワールド)

２年前、衝撃的なものをみた。それは、全てが日本語で書かれているコード。
C#だったかなでしこだったか忘れたが、僕と友人は“それ”を見た瞬間に汚物を踏んづけてしまったような顔をした。
コンピューターにとって、日本語は汚物だ。

僕はコンピューター上で日本語を使ったシステムが好きじゃない。ファイル名すら日本語にするのが嫌いだった。
昔あった問題では、日本語名を持つファイルを読み込むと固まってしまったり、システム間でのファイル共有に問題があったからだ。
それにEUCやらSJISの問題で、Perlのコードを実行すると、バケバケになってしまったりとロクな目にあったことがなかったのだ。


そんな僕の“柿が熟しすぎてグチャグチャになってるような半腐れ顔”を見て、ある人はこういった
「このコード、実は君たちが絶対に必要とするものが書かれていないんだ」と。


僕と友人はアメリカ横断ウルトラクイズの帽子よろしく頭に“？”を浮かばせた。
一見、そのコードは日本語が利用してある以外、別段どこも特別なところがなかった。
そうこうしているうちに、タイムアップ（そして「ブー」という音）


その人は言った。「このコード、コメントが一切ないんだ」


言われてはじめて気がついた。まったくコード上にコメントがなかったのだ。
日本語で記述されているだけに、関数名を見れば一目瞭然。初見なのに、そのコードが何をするべきなのかを的確に把握することができた。
そして、日本語で書けるコードの素晴らしさを「言葉」でなく「心」で理解した。


英語は日本人平均プログラマー（男子）にとって、ネイティブコードではなく、ExciteさんやGoogleさんに頼んで翻訳してもらうものだ。
そうじゃない奴は知らない。


その時から時代は日本語になった。


時は流れて今。「いじってねーなPython3.2…」と思った瞬間、

思い出した。
上の話を。
即興で書いた。

表示しておくんなまし=print
名前="コング"
殴れる物="大統領"
勘弁な物="飛行機"

def お前誰よ():
   表示しておくんなまし("俺の名前は{0}".format(名前))
   表示しておくんなまし("{0}だって殴ってみせらぁ".format(殴れる物))
   表示しておくんなまし("でも{0}だけは勘弁な".format(勘弁な物))

お前誰よ()


分かりやすいね！
こういうときどういう顔をすればいいの？
Dan salexkidd the Japanese Programmerとかいうのかな。

OpenKinect(libfreenect) + Python Wrapper　について書いておくか。(id:mactkgが)

概略：読めばlibfreenectのPythonWrapperのインストールが確実にできるはず

KinectつかったHackがすごく楽しそうだね。
あれ？いつの間にか手元にKinectがあるよ？そして残高が減ってるんですが…

さて、PythonでHackしますか。その前に一緒にHackする人が欲しいね。
というわけで、Kinectについて熱く語ったその３０分後、id:mactkgがソッコー

「秋葉なう」

さて、PythonでHackしますか・・・あれ、PythonWrapperのインスコにコケる。

日本中の"OpenKinectのlibfreenectインスコしましたよ" 系のみなさんがPythonのWrapper
インストールにこける中、なんとかインストールを果たした。

でも俺は文章化能力が皆無なのでSkypeでインスコ方法を伝えたらid:mactkgがまとめてくれた。ありがたい！

Djangoで、永続したpickleオブジェクトをDBに保存する方法

入り用で、pythonのpickleモジュールで永続したオブジェクトをDBに投げ込まなくちゃならなかった。
が、Djangoのモデルフィールドにはそれに特化したものは存在しない。ほげー。

というわけで、考えが結果こうなる。
まずは適当なObjをpickle.dumps(tmp_obj)で文字列化。
これをbase64モジュールのb64encode()でb64化。
それを10000文字位を指定したCharFieldに入れてsaveする。

これでおｋ

PythonでPKI関係をいじる(1)

Pythonを使い、PKI関係の処理を自動化したいと思った。で、Pypiで調べるとドストレートなpkiというモジュールを発見。
即 "easy-install pki install"と決め込んでみたものの、インストールでぶっこける。
エラーを見ると、OpenSSLライブラリとPythonの橋渡しをSWIGでモゲモゲするM2Cryptoというモジュールのインストールでこけている。
エラーの内容は"opensslconf-i386.h"がないですよとのこと。
しかし、openssl-develもインストール済みなのになぜ…

調べてみると、どうやらsetup.py中の以下の行を変更しなくてはならないらしい

self.swig_opts.append('-includeall')
#self.swig_opts.append('-D__i386__') # Uncomment for early OpenSSL 0.9.7 versions, or on Fedora Core if build fails
#self.swig_opts.append('-DOPENSSL_NO_EC') # Try uncommenting if you can't build with EC disabled

もういかにもって感じ。
上記を以下に変更する

#self.swig_opts.append('-includeall')
self.swig_opts.append('-D__i386__') # Uncomment for early OpenSSL 0.9.7 versions, or on Fedora Core if build fails
self.swig_opts.append('-DOPENSSL_NO_EC') # Try uncommenting if you can't build with EC disabled

これでいけた。
もちろん、SWIGもインストールしてないとエラーになるから注意

Snow LeopardでSSHFSを利用している人に対するメモとファイル


アブストラクト：

とりあえず、Snow Leopardで、問題なく利用可能(SSHdelay.so削除 & follow symbolic link問題解消)なMacfusionのバイナリを配布しとります。
このエントリの下からどうぞ。とにかく「今すぐ使える」ことがメイン。自己責任で！
信頼できないファイルじゃ！とお考えならば、macfusionのソースを落として、
エントリに記載してある問題を修正してコンパイルしてくださいな。

前に Snow Leopard をインストールし、逃げるように Leopard に戻った。
問題点はいくつかあったが、大きな問題が2つあった。

1つめが「ことえりの馬鹿さ加減」。2つめが「SSHFSが正しく動作しない」

1つめについては答えが出た。それは カワセミというIM。
egbridgeの後継と考えても差し支えはない。
まだ使い始めたばかりなんだけど、以下の2つをサポートしている点で選択した。

  • Snow Leopardに対応している
  • ことえりよりも有能
  • 文章記述中、Shiftキーを押すことによって半角英数をインラインで入力できる
  • 1995円(!)

これならば、ATOK2009を買わなくても問題はない。むしろ、ATOK2009はあるバグを放置してリリースしているという大きな問題がある。
(バグについては内容から外れるので書かないが、「対応しないよーぷっぷー。ATO2010で直してやるよ」と言うようなことを言われた))

変換効率については、それぞれの打ち方というのが存在するので何とも言えないが、ことえりよりも少々賢い、ATOKよりはアホっぽい感じはする。
これについては使っていくうちに慣れればよい話だし、こまけぇこたぁいいんだよ的発想で利用を継続しようと思う

IMの話はこれくらいにして、次の問題に移る。そう、SSHFSだ。

Snow Leopardが発売されて約3ヶ月。MacFusionは初期のころから対応していたが、SSHFSはちゃんと対応していなかった。
「でもまぁすぐ対応するだろう」とか思っていたら、これが全然対応しない。一体全体これはどうしたことなんだろうか。
どこかの国のエージェントが動いてSSHFS系の開発者を全員アウシュビッツ送りにでもしたのかという妄想が広がる。

といっても、MacFusion.app(GUI)や、sshfs.app(GUI)は、sshfsコマンド自体のフロントエンドでしかないみたい。
なので、Snow Leopard 対応といってもコマンド自体がSnow Leopardに対応しないとどうしようもないんだろうね。

一応、昔のエントリにも記述した通り、MacFusionについては sshnodelay.so を削除すれば動作する。
これで逃げようと思ったら、MacFusion にはこの問題とは別に大きなバグがあった。

個人的に、SSHFSのオプションであるfollow_symlinksがonになっていると困る事象が発生した。なので、こいつをなんとかせねばならない。
MacFusion には follow_symlink というオプションをチェックボックスで on/off できるようになっているのだが、これが動いていない。

follow_symlink オプションを off にしてもマウント先に接続すると、必ずfollow_symlinkオプションが有効になってしまう。
実際に、このオプションを off にしている状態のものと、on にしている状態のものでどのような差があるかを調べてみた。
以下がその結果。

#On時
Macfusion.app/Contents/PlugIns/sshfs.mfplugin/Contents/Resources/sshfs-static test@dev.local:dev /Volumes/dev.local -p22 -oCheckHostIP=no -oStrictHostKeyChecking=no -oNumberOfPasswordPrompts=1 -ofollow_symlinks -ovolname=dev -ologlevel=debug1

#Off時
Macfusion.app/Contents/PlugIns/sshfs.mfplugin/Contents/Resources/sshfs-static test@dev.local:dev /Volumes/dev.local -p22 -oCheckHostIP=no -oStrictHostKeyChecking=no -oNumberOfPasswordPrompts=1 -ofollow_symlinks -ovolname=dev -ologlevel=debug1

差がないのだ。これは、チェックボックスがどう考えても正しく動作していない。
調べてみると、"Cannot disable -o follow_symlinks in 2.0.3"*1にて報告されているバグだった。
ただ、報告 & パッチは投げられているものの、リリースされているバージョンにはこの問題を残しっぱなしという状態だ。怠惰だ・・・。

じゃあなんとかこの問題を修正しようじゃないかということで、とにかく最新版のTrunkにあるソースを拾ってきてコンパイル・・・エラー。
こういう場合、アメリカではこういう表現をすればいいのかな? "Fuck"と。
調べてみると、凡ミスでエラー作り込んでやがりました。

#MFfileSystemControllerの修正ポイント
if (super = [super init]){ -> if (self = [super init]){

そして、一応Tracのチケットを確認したら、やはり同じレポートが…やっぱりバグ修正中に某国のエージェントに連れ去られたんじゃ・・
とにかく、今の問題は「今すぐ動いて」というわけで、修正してコンパイルしたものをUpします。

同じ問題にはまっている人がいたら是非ご活用ください。
とにもかくにも、これでやっとSnow Leopardを安心して利用できそう。あーよかった。
もちろんのことながら、利用は自己責任、なんかあったらソースをmacfusionのところから落として自分で修正してね。

あ、あともし僕がこの修正で某国のエージェントに連れ去られたらうわなにをするやめろうわあああああぁ

Macfusion.zip

*1:http://macfusionapp.org/trac/ticket/79