skip to main |
skip to sidebar
GAEがとうとう1.4.0になった。
Prerelease SDK 1.4.0 is out!!
メジャーバージョンアップということだが、どこが目玉なのか、個人的に思うところを
挙げてみる。
１）インスタンス維持＆Warmup Request
これで、GAE最大の不満、SpinUp問題を解決できるようになる！！ところで、Warmup Requestは、これとセットと考えていいのだろうか。でも、常時実行というのは、技術的な解決策を期待していただけにちょっと残念。
２）Channel API機能
Push技術はリアルタイムWeb時代になくてはならないものだ。Cometなのがちょっと残念。
３）TaskQueue/Cronの実行時間が最大10分に
おおおお！やっときたか。リトライ条件を指定できるのも嬉しい。でも、Datastoreと通常のリクエストが30秒のままなのがちょっと残念。
４）Metadata Queries
これが何なのかどうやって使うかわからないのがちょっと残念。
５）URLFetchのレスポンスが最大32MB
10秒で返さないといけないのがちょっと残念。
全文検索がないのが残念。ああ、残念。
Java
---------
- The Always On feature allows applications to pay and keep 3 instances of
their application always running, which can significantly reduce application
latency.
- Developers can now enable Warmup Requests. By specifying a handler in an
app's appengine-web.xml, App Engine will attempt to to send a Warmup
Request to initialize new instances before a user interacts with it. This can
reduce the latency an end-user sees for initializing your application.
- The Channel API is now available for all users.
- Task Queue has been officially released, and is no longer an experimental
feature. The API import paths that use 'labs' have been deprecated. Task
queue storage will count towards an application's overall storage quota, and
will thus be charged for.
- The deadline for Task Queue and Cron requests has been raised to 10 minutes.
Datastore and API deadlines within those requests remain unchanged.
- For the Task Queue, developers can specify task retry-parameters in their
queue.xml.
- Metadata Queries on the datastore for datastore kinds, namespaces, and
entity
properties are available.
- URL Fetch allowed response size has been increased, up to 32 MB. Request
size is still limited to 1 MB.
- The Admin Console Blacklist page lists the top blacklist rejected
visitors.
- The automatic image thumbnailing service supports arbitrary crop sizes up
to
1600px.
- Overall average instance latency in the Admin Console is now a weighted
average over QPS per instance.
- Added a low-level AysncDatastoreService for making calls to the datastore
asynchronously.
- Added a getBodyAsBytes() method to QueueStateInfo.TaskStateInfo, this
returns
the body of the task state as a pure byte-string.
- The whitelist has been updated to include all classes from javax.xml.soap.
- Fixed an issue sending email to multiple recipients.
http://code.google.com/p/googleappengine/issues/detail?id=1623
Reflex Tagging Serviceでは、GETはJSONPで、POSTやPUTはXMLで実行することを基本としている。そうしているのは、HTMLやJavaScriptといったコンテンツを扱う場合に、POSTやPUTまでJSONを使うのは結構面倒だということに気づいたから。（JSONの中にエスケープされたJSONを入れるのは大変だし読み解くのもつらい。）
しかし、一度GETしたものを編集した後にPUTするような処理では、JSON->XMLへの変換が必要になる。そこで、jquery.entry2dom.jsという、jQueryプラグインを使って、JSONのオブジェクトをDOMに変換してからxmlに変換するようにしている。
DOMからxmlに変換するには、jquery.dom2xml.jsを使えばよい。これは、DOMをXMLに変換をjQueryPluginにしたものである。
ちょっと面倒に思えるかもしれないが、e4xがすべてのブラウザに対応していない現状ではしかたないかなと思っている。ちなみにサーバサイドにおける変換は、Rhinoが標準でサポートしているのでe4xを使っている。
にわかに盛り上がっているプログラミング言語選択の議論。私も一言いわせてくれ。
言語選択は目的と生産性で判断すべき
以前、あるPython使いがGAEでJavaをやるなんてありえない！なんて主張しているのを聞いたことがある。
たしかに、スクリプト言語特有の開発生産性の高さ、心地よさを覚えてしまったら後にはもう戻れない気がしてくる。それはよくわかる。
私自身、プログラミング言語はアセンブラだけありゃ十分と真剣に思っていた頃もあったが、もう戻れない。（今そんな人いないよね。）
でも、PythonかJava、どちらの言語を選択するかは、目的によって異なるんじゃないかと思う。
私は今なら、人にすすめるならJavaScript、自分で書くならJavaが最高と思っている。（あれ？Pythonがない）
Tagging Serviceでは、javaを選択しているが、その理由は、クラウドサービスのミドルウェアを作る必要があったからである。
まず、サーバサイドスクリプト機能のようなJavaScript実行環境を作ることはPythonだと難しいと思った。（もしかしたらできるのかもしれないけど）
これがJavaであれば、RhinoというJarを一つ追加するだけで作れてしまうのである。
また、Reflex Tagging Serviceは、GAEだけではなく、RDBやCassandraのようなKVSでも動かすことを想定しており、その場合、エンタープライズ向けになることもあり、Javaの方が都合が良かった。
もちろん、すべてJavaでいいといっているわけでなく、生産性向上のためには、JavaScriptを活用する方が有効だとも考えている。
Tagging Serviceにおいて、ビジネスロジックはすべてATOMとjavaScriptで書けるようにしているのは、「人にすすめるならJavaScript」と、そう思うからだ。
また、サーバとクライアントの言語を統一することは意外と重要だったりする。異なる言語で書いてしまうと、以下のように酷い目にあってしまうからだ。
pythonのコードに間違ってセミコロンを付けてしまったり、PythonとJavaScriptのどっちがTrueでどっちがtrueだか混乱したりする。(言語対決：JavaScript 対 Objective-C)
どうせクライアントではjavaScriptが必須なわけだから、生産性という観点からいえば、サーバにおいても同じJavaScriptで書けるのが望ましいといえるだろう。
まあ、趣味でやる場合は、プログラミングのためのプログラミングをすることもあるわけで、それはそれでいいんじゃないかとも思う。（でも、その話とエンジニアの素質は別の話だと思っているが・・）
宣言型プログラミングのすすめ
あと一つ強調したいのは、jQueryが宣言型プログラミングモデルに近いということ。
HTMLやCSSをマスターできた人がプログラミングに挑戦しようと思ってもなかなかできないのは、手続型の論理思考が難しいからということではないかと私は考えている。
jQueryであれば、すんなりマスターできたという人が多いのは、HTMLやCSSと同じようなイメージで書ける、宣言型プログラミングモデルであるから。
宣言型プログラミングモデルは、Javaなどの手続型（異論もあるとは思うが少なくとも宣言型ではない）に比べ、はるかに学習コストが低いと思われる。
Tagging Serviceでは、ATOMとJavaScriptでRESTfulに開発できる環境を用意して、jQueryのような宣言型プログラミングモデルの仲間入りを果たすことで、プログラミング初心者でも、GAEのことを何も知らなくても、誰でも簡単にWebアプリケーションを作れる環境を提供している。
以上、生産性の観点からいえば、多くの異なる言語を覚えて書くよりは、どれか強力な言語を覚えて書けるようにした方がいいという話でした。
ちなみに、iPhone/iPadのNativeアプリの開発も、Titanium Mobile を使えば、JavaScriptだけで開発できるそうな。
皆様、盛り上げてくれて、本当にありがとうございました。めちゃ楽しかったです。
私の発表資料を置いておきます。詳細はこちら
atsさんのAHAの話は、Tagging Serviceと同じCMSということもあって大変参考になりました。
佐藤さんの話は大変刺激しげき的でした。Matcherとか、概念が新しすぎて質問がまともにできなかった。
teradaも、話をフルたびに（＞＜；になってましたが、今回はかなり勉強になったと思います。やってよかった。
shin1ogawaへ。飾りじゃないのよ、私は、Ｈａｈａ～
Thx! urekat san
発表の様子
Thx! kazunori san
弊社はかねてより、Reflexというリソース志向のフレームワークを提供しているが、このたび、さらにサービスに発展させたReflex Tagging Serviceというものを作ったので発表したいと思う。（明日のajn12のBTで話す予定なので、興味のある方はぜひ聴きにきてください。）
Reflex Tagging Serviceとは
Tagging Serviceは、リソースから様々なReflex（反射像）を取り出すというReflexの基本設計に則って作成されたサービスであり、URLで示された階層のリソースに対して、ATOM Feedを使ってCRUD(GET/POST/PUT/DELETE)操作を可能にする。
ATOMのAPIといえばGDataが有名だが、Tagging Serviceは、GDataプロトコルとほぼ同等の機能（REST API、JSON表現、Versioningなど）を持つほか、URLによるリソースの階層表現、ACL、WebHook、JavaScript実行機能などを備えている。
詳細については、こちらを参照していただきたい。⇒リンク
サービス志向、もとい、リソース志向
Reflex Tagging Serviceは、リソース志向の階層型CMS＆ワークフローエンジンである。リソース志向とは、簡単にいえば、URIで表されるリソースに対してRESTfulにアクセスする世界のこと。REST APIを提供することで、Key/ValueであるDatastoreの扱いにくさを解消させる目的がある。でもそれ以上に、ドメイン層をサービス化して疎結合とすることで、スケーラビリティが向上し、可搬性が高まることの意味の方が大きい。
また、ドメイン層のサービス化については、以前、この記事の「ドメインサービスとしてのReflex BDB」で以下のように説明した。
Key/ValueStorageではなく、ドメインサービスを提供する
・ 単なるPKによるGET/PUTだけでなく、様々なKeyによるRESTfulなCRUD APIを提供
・ <>比較、Range、前方一致検索、全文検索、Pagingなど
Reflex Tagging Serviceは、要は、このとき作ろうとしたドメインサービスなのである。当のReflex BDBの開発は中断しているが、いずれ、Tagging Serviceと同じAPIを導入しようと考えている。DBMSはRDBかもしれないし、KVSのCassandraになるかもしれないが、Tagging Serviceをラッパーにすることで、Private CloudでもPublic Cloudでも同じように動かすことができる。
例えば、以下のような商品検索サービス（リンク）は、Tagging Serviceを基に作成されているが、REST APIだけで動作しているので、Private Cloudの上でも問題なく動作するはずである。
そして、JavaScriptだけが残った
Reflex Tagging Serviceの目玉機能にServer Side Scriptがある。これを使えば、サーバでJavaScriptを実行できるようになる。ドメインサービスとしての機能以上に、ワークフローエンジンとして使用できるように作られているのがポイントである。
サーバでスクリプトを実行できれば、JSPはいらなくなるし、Javaをデプロイする必要もなくなる。
Reflex Tagging Serviceの目的は、GAEやDatastoreの難しさ、煩わしさをなくすことであった。特殊なスキルがなくても、REST APIだけ知っていれば、アプリを作ることができるようになる。
実際に、先ほどの商品検索アプリは、GAEなんて全く知らない、JavaScript暦3ヶ月のKeigo君が作成したものだ。ちなみに、Tagging Serviceは、Teradaさんが作成したもので、私は1行もコードを書いていない。
