C#でiPhoneアプリを作ってみた！

C#や.Net Frameworkを使ってiPhoneアプリを開発出来るというMonoTouchを使ってみた

まずMonoFrameworkとMonoDevelopをダウンロード＆インストールする。（共にMac版）
次にMonoTouchのSDKをダウンロードする
上記２つは無料らしい、MonoTouchは有料だけどTrial出来るので今回はそれで試してみました

あ、もちろんiPhoneSDKは必須です。AppleIDを取得すれば無料でダウンロード可能

全部インストールした所でおもむろにMonoDevelopを起動、、、はい、文字化けしてます
ぐぐると早速答えがあったので設定します



はい、バッチリ日本語でました
とりあえず公式のチュートリアルを進めてみます

ファイル＞新規＞ソリューション　で　テンプレートから C#>iPhone を選択



早速使えるテンプレートが増えているようです、今回はHelloWorldなんで、iPhone Window-based Projectでいってみましょう
とりあえず作成しただけの状態で実行してみます・・・



iPhone Simulatorが立ち上がってまっしろな画面が出ました、ここまでは良好ですね。
生成されたプロジェクトの MainWindow.xib をダブルクリックすると InterfaceBuilder が起動しました。
この辺はXcodeで作る時と同じ容量で良さそうですね。

InterfaceBuilderで生成されたOutletやActionを、MainWindow.xib.designer.cs という自動生成されたファイルで関連付けしてくれます。
で作ってみたHelloWorldがこんな感じ



残念なところは、MonoDevelopが日本語入力出来ません・・・
ファイルを直接別のエディタで編集すれば日本語も使えますが、ちょっと効率悪いですね。
実機テストもしてみようかと思ったのですが、実機テストが出来るのは有料版のみのようです。

C#マカーがどれだけいるのかわかりませんが、actionscript等、別の言語で作れるようになるのは非常に良い事です。
今後に是非期待しましょう！

kumofs その５・スケールアウトしてみた

kumo-serverを２台のマシンへセットアップし、色々試してみました。

スケールアウト時のチェックポイントはserverのIPや名称等は必ず一意となるようにつける事です。
例えばmanagerを起動するサーバで
kumo-manager -v -l localhost
kumo-manager -v -l 127.0.0.1
とかやってしまうと失敗します。必ず自分のIPか一意のサーバ名としましょう。

前回接続が不安定だったのはSpymemcachedが原因でした。
memcached client for javaで接続したらエラーにならずにすみました。
んが、こちらの方が速度が遅いようです。

1台から2台にした結果、速度は遅くなりました。
まぁ２台ではボトルネックの方が大きくなってしまうのでしょうがないですね・・・

memcached client+2台状態での速度は以下のような感じでした。
Set
128,187ms

Get
112,314ms

どちらも大体同じくらいの速度で安定して動きました。
SetはHSQLDBより遅くなりましたね・・・
GetをチューニングしたらHSQLDBが最速になるかな？？と思って試してみました

Indexあり HSQLDB Get
637,811ms
622,084ms

Indexなしより４倍ぐらい早くなりましたが、kumofsと比べるとだいぶ遅いですね。
CouchDBより微妙に遅い程度なので、Grailsの中だけで使うDBという割当にCouchDBは向いていません。

続いて障害時の検証

memcached clientには複数のmemcachedをPoolして使う機能があります。
なのでkumo-gatewayを二つたてて二つをPoolして使ってみました。

マシン構成
server1 - kumo-manager , kumo-server , kumo-gateway
server2 - kumo-server , kumo-gateway

・すべてが稼働している状態からserver1or2のkumo-gatewayを落とす
正しく取得出来たり、Exceptionが出たり。
memcached clientでは接続先が落ちているかどうかまで判断はしてくれないようです。
A,Bどちらを落とした場合でも結果は同じです。

・すべてが稼働している状態からserver1or2のkumo-serverを落とす
何事もなかったかのように動作しました。

・片方のkumo-serverしか動いていない状態で、データを追加or変更し、落ちているkumo-serverを復旧させる
復旧した時点では not attached になっていますので、Aのマシンからattachします

kumoctl server1 attach

attach時にReplicationが行われ、アプリケーションからは常に変更後のデータが取得されます。
もちろんノンストップでいけます。

という事で、memcached clientのPoolは使わずに、公式のオススメどおりwebアプリとkumo-gatewayを1:1にし、kumofs側で障害対策をするのが良いようです。

kumofs その４・速度比較してみた

Grailsから kumofs と couchDB で速度比較してみました。（ついでにRDBMSも）
対象データは全国の郵便番号(12万件)をキーに住所を入力しています。

kumofs+spymemcachedでは、大量のデータをいっぺんに投げると接続が不安定になります。
一応接続方法を DefaultConnectionFactory から、KetamaConnectionFactory （蹴球？）に変えたら多少良くなったような気がしました。（が、たまにエラーでます）

やり方は前回のサービスの一部を変更↓

1. def void afterPropertiesSet() {  
2.   memcachedClient = new MemcachedClient(new KetamaConnectionFactory(60000,60000), AddrUtil.getAddresses("localhost:11211"))  
3. // memcachedClient = new MemcachedClient(AddrUtil.getAddresses("localhost:11211"))  
4. }  

def void afterPropertiesSet() {
  memcachedClient = new MemcachedClient(new KetamaConnectionFactory(60000,60000), AddrUtil.getAddresses("localhost:11211"))
// memcachedClient = new MemcachedClient(AddrUtil.getAddresses("localhost:11211"))
}

コメントアウトしたところが元のソースです。
念のためバッファ等もあげてあります。


CouchDBはRESTですべて行えるので、Grailsからはサクサク使えるのですが、Java用のライブラリがあったので試してみました。
勢いのあるjcouchdbを使っています。

インポートはこんな感じで書きました

1. Database db = new Database("localhost", "postal");  
2. def doc=new BaseDocument()  
3. doc.setId(key)  
4. doc.setProperty("val",val)  
5. db.createDocument(doc);  

Database db = new Database("localhost", "postal");
def doc=new BaseDocument()
doc.setId(key)
doc.setProperty("val",val)
db.createDocument(doc);

・結果はこんな感じ
データインポート

kumofs	CouchDB	HSQLDB
21,917ms	980,457ms	41,883ms
18,785ms	1,008,333ms	33,800ms
18,205ms	955,118ms	35,256ms
17,387ms	3回で心が折れました	31,735ms
18,062ms		32,539ms

取得した結果はこちら

kumofs	CouchDB	HSQLDB
51,357ms	564,257ms	2,803,802ms
45,988ms	590,907ms	2,764,875ms
50,615ms	539,712ms	2回で心が折れました
46,966ms	3回で心が折れました
48,286ms

・ちなみにDBの容量はこんな感じになりました。
元のテキスト 12mb
kumofs 22mb
couchDB 600mb

couchDBは差分もてたりする分情報が多いのは理解出来ますが、ちょっとありえないサイズになってますね・・・


・まとめるとこんな感じ
（そもそも単純なKVSであるkumofsとMapReduce出来るCouchDBを比べるのも変かも知れませんが・・・あえてTokyoTryrantとかとは比べないのがうちっぽいという事で）

速度だけでみたらkumofsが最速（安定性に不安があるけど・・・）
CouchDBは想像以上に遅かったですね、、、特に書き込み。
ってそういう見方もあるけど、CouchDB良い所はKVSやSQL文になじみのない人がチームにいても理解しやすいって所だと思います。

RDBMS(今回はHSQL使ってます)の読み込みの遅さは正直壊れたのかと思うぐらい遅かったです・・・
まあINDEXもチューニングも何もしていない状態だとこんなものでしょうか。
そこらへんはプログラマならやって当然の事なんですが、そういう事考えなくても早いDBってのも良い物ですよね。

次回はkumofsをスケールアウトしてみます、果たして更なる速度向上はあるのか！？