Windows8 CP

Windows8 ConsumerPreviewが出たので、自宅MacのVirtualBoxに入れてみたんだが・・・。何しろ重い・・・。
重いというか、良く固まる（落ちるわけではない）。これはVirtualBoxのせいなんだろうか。とてもじゃないが実用に堪えない感じ。

とりあえずいろんなIT系ニュースサイトに使ってみたよレポートは出てるので、今更自分が書くようなこともないが、印象としては、

企業（仕事）で使うWindowsじゃあない。

ってとこだろうか。

・Metroが中心に据えられてて主としてMS Officeを使うようなオフィスワーカーには迷惑なだけ。
・クラウドを使っての共有が簡単にできるようになって個人利用には便利だが、会社にとっては「何が流出するかわからない恐怖」を煽るだけ。

とにかく、良くできてるWindows7にタブレットのお洋服を着せた結果、タブレットOSをPCで使わされている印象。ひどい。タブレット専用として売って下さい、これ・・・。

Windows8がリリースされて何年かたてば慣れるのかなあ・・・。

Node.js on Herokuのベンチマーク

Node.js on Herokuの開発環境がとりあえずできてみたので、ちょっとベンチマークをとってみた。といっても、相手はHello Worldを返すだけの最小Webアプリなので、その辺は割り引いて考えてください。

サーバ環境：Herokuの公開用サーバのWeb Dynos（無料枠なので1Dynos）

アプリ環境：Web DynosのCedarスタック上のNode.jsアプリ（Hello Worldを返すだけ）

クライアント環境：MacOSX(Lion)上の標準Java上のJmeter

最初、MacOSXに標準で同梱されているApache Bench（abコマンド:こんなのも同梱されてるって、どんだけ開発者寄りなんだOSX！）で、さくっと感覚だけ掴んでみるべ、と思ったんだけど、並列リクエスト数4（-c 4）あたりからなんだか挙動がおかしなことになってきて、Socketエラーが出てしまう。

これは明らかにHerokuの問題じゃなさそうだな、、、と思ってググってみると、標準のabはイケてないので、ソースからビルドし直した、なんて記事があったりしてガックリ。

ソースから入れ直すのもいいけど、標準abと入れ直したabが混在するのも構成管理上気持ち悪いし、いっその事Jmeterで真剣にやるか、ってな感じに決着がついた（自分内で）。

で、結論的には、

350req/sec（Keep-Alive無効時）

500req/sec（Keep-Alive有効時）

あたりのスループットまで到達した。

ここまでくるとそれ以上に行くためのネックがサーバなのかクライアントなのかネットワークなのかは置いておいても、十分すぎるほどの性能。

前述の通り、アプリは何も処理してないに等しいのは確かだけど、1Dynos(＝1プロセス＜1物理CPUcore、でいいのかな)だけで、350ものコネクション(/sec)の切った張ったをできるだけでも超優秀と言ってもいいんじゃないだろうか。

いじりがいがあるな〜。

（尚、レスポンスタイムはおおむね400ms前後で、こっちはちょっと残念な感じ。サーバが米国だから仕方ない面もあるけど、400msあると人は引っかかりを感じるだろうから、アプリっぽいWebアプリを、サクサク動かすにはちょっとつらいか）

HerokuでNode.jsを始めてみる

Heroku公式サイトのここを見る。おしまい。

・・・いや、ほんとにそうだから。
簡単すぎて半笑いでやりました。

Windowsだとちと大変かも知れない。
Mac(Lion)だと得体の知れないラクさ加減。
Node.jsをローカルにインストールするところで若干戸惑うが、Node.jsとnvmを初めてインストールするときのハマりポイントと対策を参考にさせてもらいました。
（尚、ここに書いてあるのはNode.js v0.4.0時点のもので、自分はv0.4.7で試したところ、wgetは不要でいけました。nvmコマンドの出力形式も多少違う）

あとは、Xcodeさえ入ってれば、Lionにはgitも入ってるし何にも悩むことがない。

学んだこと・・・

• nvmコマンドって、Node.jsのパッケージマネージャなんですけど、Node.jsそのものまでインストールできるのにビビる。Node.jsが存在しない状態で実行できる。まじか。。。
• MacOSXの開発者フレンドリーな環境にビビる。gitまで入ってんのか〜。。。
• Herokuって、多言語に対応してるんだけど、どこで「僕はNode.jsを使うの！」って指定するのかな、っと疑問だった（何しろHerokuといえばRoR、の記事ばっかで・・・）が、Procfileというファイルで指定すれば良いらしい。悩まないでプログラミング界の格言（？）「考えるな、真似ろ」に従っておけば良かったわ。
• gitでデプロイするのは分かってしまえば（GAEのappcfgとの比較で言うと）バージョン管理も直感的だし（つうか、そもそもgitはバージョン管理するためのプロダクトなのだが・・・）好きかも。ただ、いかんせんgitはちゃんと触ったことがないので、慣れるまでは我慢か。
• Windowsで環境を作るのは正直おっくう。

さあ、バリバリ遊ぶぞ〜。

WebSocketとかChannelとか

GAEのChannelは、無料枠では1日100オープンまでだし、HerokuのWebSocket(Pusher)は無料枠で20コネクションまでだし、リアルタイム性の高いPush通信は、コストが高くついて困るなあなんて話を過去のエントリでしたわけですが、

考えてみると、Push It!は、通信対戦アクションゲームのようなギチギチのリアルタイム性を求めているわけでなく、数秒程度の遅延で付箋が更新されれば良くって、だったらChannelやWebSocketである必要なくね？と思い返した。

ただ、短周期のポーリングは避けたいね、クライアントにもサーバにもネットワークにも負荷だし、というのがそもそもChannelやWebSocketを使おうとしたそもそもの理由。

ってことは、Long Pollingでいいんじゃね？という気がした。

GAE/Python2.5だと、CPUすかすかでも１リクエストが１インスタンスを占有するから現実的ではないのだが、GAE/Python2.7（か、Java）だったらマルチスレッド対応なので、CPUすかすかなら対応できるかもしれない。

ただ、GAE/P（多分Jもだが）、リクエスト処理中に外部からのイベントを受け付けられる仕組みにはなってないので、更新があったかどうか、内部では短周期でポーリング（Datastoreなりmemcacheなりに対して）してあげないといけない。これがネック。

HerokuだとNode.jsが使えるので、外部からのイベントが来るまでリクエスト処理は放置しておけるんじゃないか？だとしたら、Long Pollingがかなりラクかつ低負荷で実施できそうな気もする。
どうなんだろ。試してみたい。

（続）モバイルアプリ開発、何使う？

前回のエントリでモバイルアプリ開発に何を使うか書いたばかりだが、非常に参考になるブログがあったので、紹介。

どうしてTitanium Mobileなの？

て、３日前に書かれた記事ですね。

みんな同じような悩みを抱えつつ、自分なりの答えを探しているんですね～。

ぼかぁ、どれもこれもまだ触ってないので、オモテから見える部分でしか評価できないんで非常に参考になりました。

モバイルアプリ開発、何使う？

PCクライアント版PushIt!も完成してないのになんだが、モバイルアプリ（正確にはスマホ向けというべきか）にも手を出したい今日この頃。

さて、モバイルアプリと言えば、昨今はいろいろと作り方があるので、最初を間違えると後で不良債権を抱えてしまうことになり、選び方に慎重になってしまう。

ちょっと比較をしてみた。ターゲットはiOSとAndroidだ。

• 1. ネイティブアプリ
  言わずと知れたObjective-C（iOS）とJava（Android）である。実行速度と「オワコン」にならなさ加減では間違いない選択。しかし、なるべく手間をかけずに両方対応したいならまず外すべき選択肢。Push It!のようなツール系アプリなら実行速度をあまり気にしないので忘れても結構。
  
  
• 2. Unity
  Mono（Windowsの.NETフレームワークのオープンソース版）を使った開発・実行環境。事前にネイティブコンパイルするので、実行速度はネイティブ並み（Javascriptでも開発できるらしいが、それもコンパイルするのかは不明）を確保しつつ、サポートプラットフォームが半端無い。ネイティブ形式にパッケージングされるのでアプリストアで売れる。
  基本、ゲーム向けのフレームワークなので、ライトな用途には重量級すぎるかも？使ってみないとなんとも言えないが。移植性はわからん。
  
  
• 3. HTML+CSS+Javascript
  言わずと知れた。アプリっぽくするにはjQuery Mobileなんかを使いつつ、キャッシュやローカルストレージを駆使してローカルでも動くようにしないとね。
  実行速度的にはまあそれなり。ツール用途で、かつデバイスの機能をフル活用しなくていいならありな選択肢。デバイス特化な機能を使わないなら移植性も高い。
  iOS向けにAppStoreで売って小遣い稼ぎしたいならなし。
  
  
• 4. PhoneGap
  基本的に3と同じだが、ネイティブ形式にパッケージングされるのでアプリストアで売れる。
  デバイス機能へのブリッジもある程度用意されているので、そこそこ凝ったアプリもイケる。
  
  
• 5. Titanium Mobile
  1と同じことを言語にJavascriptを使う、といったら良いだろうか。同じくJavascriptを使う3,4との違いはViewの部分（つまり見た目）もJavascriptで構築するところ。
  当然、ネイティブ形式にパッケージングされるのでアプリストアで売れる。
  Javascriptがネイティブコードにコンパイルされるなんて情報もあるが定かではないので、実行速度は不明。
  移植性に関しても良く分からないが、ViewとI/Oをうまく切り出せれば大部分は流用できるだろう。
  どんだけ流行るか不明。
  
  
• 6. Adobe AIR (for Mobile)
  AIRランタイムを使ったアプリをネイティブ形式にパッケージングするもの。
  思想的には2や5に近い。Flash(Flex)開発者にとっては取っ付きやすいが、そのFlashがモバイル向けから手を引いたので、衰退の予感。HTML＋Javascriptでも開発できるけど、その場合は3,4でもいいわけだし。
  PCとのマルチデバイス展開もやりやすいといえばそうだが、PC向けとは（ある程度コードは共有できるけど）別物だと思った方が良い。

個人的には、実行速度的にはどれでも満足できる用途なので良しとして、1はマルチデバイス展開の点でナシ、2は重量級すぎてナシ、6はオワコンの予感でナシ、3やるくらいなら4の方が楽できる（し売れる。実際売れるかどうかは別だが）のでナシということで、残るは4,5になる。

で実際5ってどうなんですかねえ。開発者ついてるんですかねえ。

4は時々ニュースになるし、PhoneGapそのものの魅力ではないけど、UI周りではjQuery Mobileが巨大なコミュニティを持っているおかげで凝ったViewも作りやすそうなので、今後も有望なんじゃないかと思うんだけど、どうかな。

Aptana Studio with Pleiades on MacOSX

Push It!のサーバ側は、俗にいうGAE/Pであり、つまりPythonなのである。
で、Pythonの開発環境として有名なものにはPyDev(Eclipseのプラグイン)というものがある。
PyDevはもちろんただで使えるのだが、基本、Aptanaという会社が作っていて（多分）、AptanaはEclipseベースの開発環境であるAptana Studio（これもただ）を配布しており、当然その中にはPyDevも入っている（だけでなくスクリプト系Web開発環境のほぼすべてが揃っていると言っても過言ではないくらいてんこ盛りである）。

さて、そのAptana Studio、Eclipseベースなので当然Javaであり、当然Macでも動く。
Mac用インストーラも配布されているので楽チンなのだが、残念ながら日本語化されていない。

Eclipseを日本語化するには有志の皆さんが作っているPleiadesというプラグインがあり、（Windows版なら）Eclipse込みのパッケージも配布されている、が、前述の通り自分は
「Macに」
「Aptana Studioを」
入れたのであり、Eclipseは既に存在しているところにPleiadesを入れたいのだ、わたしゃ。

Pleiadesは単なるプラグインではなく、ものすごく乱暴に言うと、
「Eclipseのテキスト表示をインターセプトして、その場で翻訳して日本語で表示しちまうぞ、こら！」
という仕組みであるらしく、plugins & featuresフォルダにファイルを突っ込むだけでは足りず、インターセプトするために起動オプションに仕込みが必要になる。

で、前置きが長くなったが、起動オプションなんである。
Pleiadesの配布パッケージには優しい（易しくはない・・・）READMEがついているんだけど、Eclipseの起動オプション設定として、世界で70億人くらいが使っているであろうeclipse.iniがAptana Studioには、ない！

どーすりゃいいんすか〜、まあ、メニュー等が日本語でなくてもソースに日本語が使えないわけではないのだし、なんとかなるけど・・・と思いながらも諦めきれず探していたら、ありました。別の名前で。

その者の名は、

/Applications/Aptana Studio 3/AptanaStudio3.app/Contents/MacOS/AptanaStudio3.ini

である。

第一のトラップは「AptanaStudio3.app」であり、MacのFinderでは通常「.appなフォルダ」は実行ファイルに見える。が、実体は特殊なフォルダなのであり、それに気がつかなかったというか、知ってたけどその中まで探さなかったこと。

第二のトラップはeclipse.iniではなく、AptanaStudio3.iniであること。まあ、こちらは第一のトラップがわかれば容易くわかる、のだが、それに気がつかない間、「.appフォルダ」を特別扱いしないツールであるコンソールから、一生懸命

find "/Applications/Aptana Studio 3" -name eclipse.ini

しても見つからなかったのでプチトラップである。
恐るべしMac、そしてAptana Studio・・・の巻。