kawatch

CoffeeScript を2日間触ってみた雑感

2011-12-12T00:06:00.001+09:00

この週末は Node.JS, Express で書いたプログラム (JavaScript) を CoffeeScript に書き換えてみました。コード量が 1/3 になることもあるということで、当初の狙いはコードの簡略化でした。

CoffeeScript は JavaScript に素直にマッピングされるので、JavaScript を知っていれば素直に学習できます。説明ページを数時間眺めれば書けるようになります。

コード量
学習後に、JavaScript のコードを CoffeeScript に書き換えたのですが、思ったよりは短くなりません。短くなったのは主に次の2点。

閉じ bracket (}) だけの行。Python と同じ indent による block なので、if, for, function などにおける閉じ bracket は省略できます。
後置 if, for 。if (x) {\n y;\n } が y if x となるので(閉じ bracket 行に加えて) 1 行節約できます。ただし y 部が長い場合は x が視線の右端に寄って読みづらくなるので使わないほうが読みやすいと思います。

どちらも 1行ずつ短くなりますが、たいした量ではありません。

Loop
これまでは map(), each(), filter() などが使いたくて underscore.js を利用したり、いろんなブラウザで forEach() を使うために augment.js を利用したりしていました。
CoffeeScript の loop, comprehension の構文は強力で、なおかつ素直に for 文を使った JavaScript に変換されます。ほぼ全てのの実行環境で動作するんじゃないでしょうか。
実行環境のことを気にしなくて良いのは大きな利点です。

意外に良かった点
生成された JavaScript は (function() { コード } ).call(this); となっているため、グルーバルな名前空間を間違って汚す心配をしなくて良い。Node.JS や Titanium などの CommonJS に従う処理系では各ファイルが独自の名前空間を持つが、Browser で動作する JavaScript ではついつい global を汚してしまいがちなので、とても助かります(私が未熟なだけという話)。
global に露出したいときはこの記事にあるように root = exports ? this とすれば CommonJS と browser の両方に対応できます。(browser の場合は root が window になる)

node-dev は CoffeeScript に対応しています。コードを書き換える毎の再起動を省力化してくれます。素晴らしい。

Browser 用のコードは express-coffee で動的に CoffeeScript から JavaScript に変換できます。0.0.4 には、 Content-Type が application/octet-stream になる問題と、マルチバイト文字を CoffeeScript 内にふくむ際に Content-Length がおかしくなる問題があったので、patch を送りました。すぐに merge され 0.0.5 になりました。著者曰く"That's how open source should be. :)"だそうで。

今一歩な点
エラーが起きた際や nlogger によるソースコードの行数表示は、生成された JavaScript の行数表示になります。coffee -c で JavaScript に変換してどの行か確認する必要があります。Github の issue にて活発に議論されているので、そのうち解決されると期待するとしましょう。

その他
Coco という CoffeeScript の派生言語があります。文法を詳しく見ていませんが、コンパイル速度では Coco に分があるらしいです。
CoffeeScript と Coco が両方流行するとは思えないので、今のところメジャーな CoffeeScript に乗っても問題ないかなと思っています。

Ti.App を global 変数格納場所として使おうとしたら

2011-12-06T08:32:00.001+09:00

どうもおかしい。
以下のコードで

eq1 は false で、eq2 は true になる。Ti.App に関しては property の setter or getter で何かしらトリックが存在するっぽいな。。。

Titanium で複数行のテキストの vertical align

2011-12-05T23:35:00.001+09:00

今 Titanium を利用して iPhone アプリケーションを作成しています。

ここの下の方にあるサンプルのようなことをするべく、複数行のテキストを table view のセル内に表示したいと思い Ti.UI.Label を試しました。height に設定した高さが満たされるだけ文字列が長い場合は私の目的通り動作するのですが、そうでない場合は vertical center align されてしまいます。(top align したい)

UILabel も vertical align をサポートしていなかった記憶があるので、同じ理由だと思います。

さて困ったな。

Appcelerator の Q&A によると、一つの解決策は text property をセットした直後に custom event を発生させ、受信側で size.height が目的の height より小さかった場合には height property を 'auto' に設定するというもの。
もうひとつの解決策は Ti.UI.TextArea を使うもの。

過去 UILabel で同じ問題にあたった時も前者の方法で解決したような覚えがあるので、とりあえず前者の方法をためしてみます。

Cloud Foundry

2011-08-28T19:09:00.001+09:00

Cloud Foundry は open source の PaaS。http://www.cloudfoundry.org/ でコミュニティが運営され、 http://www.cloudfoundry.com/ でサービスが運営されている。
Open source なので自分のマシン上にサービスを構築することも可能。
VMware の仮想マシンが提供されており、開発者はローカルに環境を構築することができる。
Spring, Rails, Node.js, Groovy, Grails, Scala などがサポートされている。

http://www.cloudfoundry.com/ は beta trial 中は無償で利用出来るようなので Node.js を試すついでに試してみよう。

新価格体系 FAQ 日本語版

2011-06-28T00:18:00.000+09:00

Google の松尾さんから mailing list 宛に新価格体系 FAQ を日本語に翻訳したものがポストされています。
値上げだと騒がれている今回の変更ですが、まだ読んでいない方は一度チェックしたほうが良いでしょう。

Google App Engine の新価格 (2)

2011-06-25T00:11:00.002+09:00

Google App Engine の新価格 (1) では月々の費用 $9 に関する部分を見ていきました。
mailing list で FAQ が更新されたようです。

新価格でもっとも影響が大きいのは、これまで CPU 時間で課金されていた部分がInstance 起動時間での課金に変更されたことでしょう。更新されたFAQでもこれについての追加説明がされています。

インスタンスの価格は $0.08/hour
新たなインスタンスを起動するか否かはスケジューラが決定します
スケジューラには4つのパラメータを与えることができます

Min Idle Instances: アイドル状態のインスタンスを最低いくつ確保するか。これまでの Always On を実現したい場合にはこの値を 1 以上にする必要があります。このパラメータは有償プランでのみ利用可能です。
Max Idle Instances: アイドル状態のインスタンスを最高いくつ確保するか。アクセス数が短時間に集中する場合に影響します。
Min Pending Latency: リクエストの予想待ち時間がこの値を下回る場合は新規インスタンスは起動されません。
Max Pending Latency: リクエストの予想待ち時間がこの値を上回る場合は即座に新規インスタンスが起動されます。

新規にインスタンスを開始した場合には 15 min 分が startup 手数料として取られます。5 min だけインスタンスを起動した場合には 0.08 * (15 + 5) / 60 = 2.6 cents になります。

短時間(数分の間)に多くのアクセスが集中するようなケースでは startup 手数料が多く取られることになります。費用を安くするために、これまでは純粋に CPU 時間だけを短くすることを考えれば良かったのですが、これからはインスタンス数と startup 回数を減らす方法を考える必要が出てきました。

インスタンス数を減らすには

応答時間を縮める
並列処理を行う

ことで実現できます。並列処理に関しては現状 Java SDK でのみサポートされており、Python SDK では Python 2.7 をサポートする際にサポートすると宣言されています。
startup 回数に関しては、アクセス規模が小さいサイトでは問題に成り得ますが、比較的大規模のアクセスがあるサイトでは問題にならないかもしれません。

App Engine 1.5.1

2011-06-21T22:13:00.001+09:00

アメリカ時間で6月20日に App Engine の 1.5.1 がリリースされました (公式blog) 。
まだ試せていませんが、大きな変更点はこのようになっています。

Geolocation header: ユーザのアクセス元の国をベストエフォートで判断して X-AppEngine-Country header が付与されるようになりました。国や言語のデフォルト値を設定するときに便利そうです。
Channel API (Presence support, Java & Python): Channel API でユーザの切断・接続を検知できるようになりました。
Image API (WebP support, Java & Python): WebP image format のサポートが追加されました。
ProtoRPC (Python のみ): Web ベースのサービスを定義するための ProtoRPC のサポートが追加されました。
High Replication in the SDK (Java & Python): SDK が high replication の consistency (eventually consistency) をエミュレート出来るようになりました。書き込んだものがすぐには見えない、そんな consistency が手元で試せるようになります。

公式ブログに書いてあるのはここまで。

Google App Engine の SLA

2011-06-01T23:53:00.000+09:00

新価格体系で支払いを行った場合に受けられる SLA の draft が公開されています。draft なので今後変更される可能性があります。
内容から気になったところをピックアップします。

GAEのサービスが停止した時間の割合により、その月以降で利用出来るクレジットが付与されます。稼働率に応じて当月利用料に対して以下の割合が付与されます。

99.95% を下回った(停止時間約22分を超えた)場合 10%
99.00% を下回った(停止時間約7.2時間を超えた)場合 25%
95.00% を下回った(停止時間約36時間を超えた)場合 50%
90.00% を下回った(停止時間約72時間を超えた)場合 100%

問題が起きたときは、顧客が Google に通知する必要があります。

Google Apps support portal で SLA violation issue を新規に起こす
Google Apps support portal から application id とエラーログを送る。

予定されていたメンテナンスによる停止は SLA に含まれません。メンテナンスは月合計80分以内です。
応答時間が極端に遅いアプリ、DeadlineExceededException を出しているアプリは SLA 対象外です。

大体こんなところです。

大抵の場合、GAE上で実行しているサービスが生み出す価値がGAEの利用料を上回っているでしょうし、GAEは使用料自体が安い部類なので、サービスクレジットに関しては大きなインパクトは無いように思います。
自分から申し込まなければならないというのは意外でした。てっきり勝手に稼働率を測定して判断してくれるものと思っていました。他の SLA を読んだことがないのですが普通なのでしょうか。
DeadlineExceededException を出しているアプリは対象外というのも気をつける必要がありますね。処理が遅くならないように気をつけたプログラムを書かなければ SLA の補償が受けられません。

上にも書きましたがこの内容は draft なので、実際に導入される際には変わる可能性があります。

Kay framework で code coverage 測定

2011-05-31T23:18:00.001+09:00

今日は Kay framework を試しました。このフレームワークは Google API Expert である Ian M Lewisさんが中心となって作っている Google App Engine 用の web framework です。
Kay framework は GAE のサービスを利用しているコードを単体テストするための便利な仕組みを備えています。この仕組みを用いて単体テストを書いた後、それをコマンドラインから実行するには

$ python manage.py test

とします。

ここで単体テストのコードカバレッジを知るには coverage package が利用できるようです。

$ sudo easy_install coverage

で coverage package をインストールした後に、

# myapp/ 以下のコードを測定対象に。ただし */test/* は除く。
$ coverage run --include 'myapp/*' --omit '*/test/*' manage.py test
$ coverage report -m

とすることでカバレッジを表示できます。
カバレッジの測定をする場合はテストの実行が遅くなるため、普段は coverage コマンドなしで単体テストを実行し、カバレッジを知りたいときのみ coverage コマンドで実行するのが良いでしょう。

Google App Engine の新価格 (1)

2011-05-30T23:53:00.000+09:00

先日 Google App Engine の今後の価格体系が発表されました。2011年後半に App Engine が preview を抜けると共に新価格体系に変更される予定です。価格表はリンク先を見ていただくことにして、Greg が mailing list に投稿した FAQ の内 Costs の部分を訳そうと思います。

費用
Q：$ 9/app/month は手数料か？最小使用料か？
A： フィードバックに基づき、元々は手数料であったが最小使用料に変更します。 言い換えれば、スケールさせるために $9/month を支払う必要があるが、各月最初の $9 の使用料の為に追加の $9 を支払う必要はありません。 $500/account/month は運用サポートのコストをカバーするために手数料となっています。

Q：ほとんどの客は有料アプリに移行する必要がありますか？
A：いいえ、私たちは、現在アクティブなアプリケーションの大半は依然として無料の割り当てに収まると予想しています。

Q：既存のアプリケーションには新価格が非適用となり、現在の課金モデルが適用され続けますか？
A：いいえ、App Engine がプレビューを終了すると、既存のアプリケーションは新しい課金モデルが適用されます。

Q：ほとんどの客は請求が増えるのでは？もしそうなら、なぜGoogleはApp Engineを値上げしたのか？
A：はい、ほとんどのお客様の請求は増えるでしょう。 App Engine がプレビューフェーズの間、典型的な使用パターンとともに、製品を稼動させるための費用を観測することができました。 GAE は今 Google の完全な製品になろうとしており、それゆえに今後数年間にわたり持続的な収益モデルを持つ必要があります。そのための価格変更です。

価格は全体的に少し上がるようですね。代わりに SLA が整備されるのは喜ばしいことです。製品開発に利用するための敷居はむしろ下がったのではないでしょうか。

C言語の未定義動作と golang

2011-05-30T00:13:00.003+09:00

LLVM の blog What Every C Programmer Should Know About Undefined Behavior を読みました。C言語の未定義動作と、最適化過程において一見正しそうにみえるバグを生み出す例が載っています。
例としてあげられているのは、符号付き整数のオーバーフロー。負の最小値(INT_MAX + 1 => INT_MIN)になると思いがちですが、C言語では未定義となっています。未定義ということなので、データが飛ぼうがコンピュータが爆発しようが文句は言えません。言い換えるとコンパイラが好きなように扱っても良い(標準準拠)ということになります。以下例を見ていきます。

int i, n; for (i = 0; i <= n; ++i) は n = INT_MAX のときに無限ループしそうな気がしますが、INT_MAX + 1 は undefined なので、コンパイラは n の値に関わらずループは n+1 回実行されると解釈し、コードを最適化することが可能です。
このことがバグを誘発します。void f(int n) { /* check overflow */ if (n > n+1) abort; ... } というコードがあったとき、n < n+1 によりオーバーフローチェックがされているように見えますが、 INT_MAX+1 は未定義なのでコンパイラは n > n+1 は常に偽と解釈することが可能です。その結果、if文は取り除かれてしまい、プログラマの思い通りには動作しません。

さて golang ではどうでしょうか？LLVM blog で挙げられていた以下の項目について mailing list に質問してみました。

Use of an uninitialized variable
Signed integer overflow
Oversized Shift Amounts
Dereferences of Wild Pointers and Out of Bounds Array Accesses
Dereferencing a NULL Pointer
Violating Type Rules

お返事を頂いた結果としては、すべての動作は定義されているということでした。
GoはCよりプログラマが思ったとおりに動く言語であると言えるでしょう。

Goroutine on App Engine

2011-05-29T19:23:00.006+09:00

先日、待望の App Engine 上での Go 言語サポートが発表されました。
Goroutine は single thread 上で実行されるということですが、Multi-threading が利用できない他のプラットフォームと比較すると、並列性サポートが非常に楽になったと言えるのではないでしょうか。

早速 goroutine を試してみます。

以下のコードでは 3 つの goroutine が 1ms ずつ sleep しながら 5 つ数えます。(w を引き回すのは良くないかも?)

実行したときの出力結果は以下のようになりました。

Routine 0: 0
Routine 1: 0
Routine 2: 0
Routine 0: 1
Routine 1: 1
Routine 2: 1
Routine 0: 2
Routine 1: 2
Routine 2: 2
Routine 1: 3
Routine 2: 3
Routine 1: 4
Routine 2: 4
Routine 0: 3
Routine 0: 4
Done.

各 routine が interleave されて実行されている様子がわかります。
App Engine では並列性の弱さが一つの弱点である/あったと思いますが、goroutine が動作することにより楽に並列性を確保することができます。
現在 go runtime は申し込みしないと appspot.com 上で使えません。私も今申し込んでいるところです。上記のサンプルはローカルで動作させていますが、appspot.com 上でも同様に動作すると思います。

はやく experimental を抜けて実用出来るようになってほしいです。