JavaじゃないあたりのGAE事情

JAVAじゃないあたりのGAE事情

in AppEngine ja Night Sapporoat 2010/8/6(fri)

大路　裕介(まいむぞう)

2010年8月7日土曜日

あばうと・みー札幌のWeb/スマートフォン系フリーランサーです。

元々Web系プログラマーです。サーバのセットアップからWebシステム開発まで一人で出来ます。

最近はAmazon EC2やGoogle App Engineなどのクラウド系技術やってます。

日本Androidの会の北海道支部長をしています。でも、Androidオンリーと言うよりは、スマートフォン全体の未来が好きです。いつもはiPhone使ってます。


お話すること

Google App EngineではJavaとPythonが動くのに、日本ではJavaばかり取り上げられている。

Slim3を使うとかなり便利にGAEを使えることはわかった。じゃあPythonはどうなの?　PHPとかRubyはどうなの?

ってあたりを、失敗談を交えながらまとめてみます。


まずはRuby

実はまいむぞうは去年の夏ぐらいからGAEをいじっていまして、何度かGAEネタで発表しています。

元々Ruby on Railsが好きだったので，jRuby上でRailsを動かしてみるところから初めてみました。


AttenderバックエンドはGoogle App Engine for

Javaで動いているin 第3回Android勉強会in札幌

at 2009/10/31(sat)

まいむぞう

以前の内容


GAEってRuby動くの?

Googleが正式にサービスを提供しているのは、PythonとJavaのみ

でも、jRubyはJava環境で動くので、Rubyのコードも動くよ

jRubyをGAEjで動かすためのGemも揃ってきたよ→appengine-jruby

以前の内容


Railsのいいとこたくさんあるけど、取り上げるべきは…

ActiveRecordを使えばデータベースがかんたん

プラグインを使えばユーザ認証がかんたん

ロギングが簡単

キャッシュメカニズムがついてる

以前の内容


でもGAEjでは…ActiveRecordを使えばデータベースがかんたん→BigtableというクラウドDBはActiveRecordでは扱えない。

プラグインを使えばユーザ認証がかんたん→プラグインは動くけど、GAEjではGoogleアカウントを使ってログイン管理できる。

ロギングが簡単→GAEj用のログクラスを使う必要があるので、標準ロガーは使えない

キャッシュメカニズムがついてる→標準のキャッシュメカニズムは使えない(動的にファイルを扱えない)

以前の内容


GAEj×Railsの問題点

GAEjでは、配置できるファイル(ソース・HTML・画像などなど)が1000個までに制限されていて、Railsにプラグインを追加すると簡単に1000個を超えてしまう。

そもそも、Railsのメリットをあまり活かせない

以前の内容


と、まぁ

ここまでが去年の状況。結局Railsは捨ててSinatraってフレームワークで作りなおしてみました。

1年経って、現状はどうか調べてみると。。。


なんか動いてるっぽい


普通にRailsできる?

Railsのscaffoldが動くということは、まぁ普通に使う分には、何も考えずに使えるのかも。

BigTableをActiveRecordを使うためのアダプターも出てるみたい。簡単な処理ならいけるかも。でも、たぶんロックや各種便利機能が動くとは考えてはいけない。

やっぱり、スピンアップ問題は辛いみたい。29秒でぎりぎり起動とか。


こんな問題も

Railsを諦めてSinatraを使って組んだとき、dev_serverではうまく動くのに、GAEにアップロードすると動かないという問題が多発。原因は不明だが、ライブラリ実装上の問題なのかも?

GAEの管理コンソールからエラー内容を確認してみると、Rubyのコードに対するエラーではなく，Javaのコードに対するエラーが表示されてしまうので，エラー内容がよくわかんなくて困った。


はい次、PHP

GAE上でPHPを動かすために、QuercusというJava上で動くPHPプロセッサを使います。

Quercusそのものはmod_phpより速いらしい。

Pear:DBとSQL4Gを使えば、GQL(SQLみたいなもの)を発行できる。高機能ではない分、RDBの呪縛から抜け出やすいかも。


GAE上で動くPHPフレ

GAE上でも素に近いPHPは普通に動くことがわかった。でも今更フレームワークからフルスクラッチで作るのは辛いので、何か既存のフレームワークを使いたい。

CakePHP / Zend Framework / Ethna / Symfonyのどれをググッても、GAE上で動いたという記事は出てこない。全滅状態。

GAE向けのPHPフレームワークも無いみたい。


ちょっとPHPは辛いかも

GAE向けフレームワークや便利ライブラリが無いので、作業効率が上がらない。

またJavaの慣習に従って手作業でデプロイする必要がある。(たぶん、途中で心が折れる)

当然、ググッてもGAE×PHPな記事はほとんど出てこないので、つまずいたら泣かずに自分でソースを読み解く必要がある。( = イバラの道)


中間まとめ

RubyやPHP周辺は常に工事中なので、精神は休まらないかもしれない。特にRubyは良くも悪くも日進月歩の世界。昨日動いたものが、今日動くとは限らない。

GAE/jに新機能が追加されても，それをRubyやPHPから(便利ライブラリを介して)使えるようになるまでは、数カ月はかかる。

あえて延々と続くイバラの道を進むよりは，JavaやPythonを覚えてみた方が健康的だと思う。


本命のPythonなんといっても、標準サポートの言語。たしかPython 2.5ベース。

Djangoを初めとして、CherryPy / Pylons / web.py / tipfy / web2pyと、GAE上で動くフレームワークもたくさん!

GAE上でのPythonといえばDjangoが有名ですが，こちらもGAEの制約により素のDjangoは動かないので、都合が悪い部分を違うものに差し替えて使うのが一般的のようです。

自分はKayというフレームワークを使っています。


http://web.py

http://web.py

Kayフレームワーク


Kayフレームワーク作者は日本人。ドキュメントは日本語だし、日本語の処理や国際化に関する機能も揃ってるし、分からないことがあればIRCで直接質問できる!(これ大きい)

遅延ローディング機能があるので、スピンアップ対策が簡単。

開発サーバ上でのデバッグが楽。いや、楽というより、楽しい。


開発サーバ上でのデバッグ

エラーが起きた時のオブジェクトの内容をシェルから確認できる


Python vs Java (on GAE)

そもそもJava with Slim3が一番便利なら、他の環境なんていらないじゃん。つーことで、Python有利となる部分をまとめてみた。

まとめてみたけど、結局は一つに集約された。

つまりは、Pythonはインタプリタだから。


つまりは、学習段階にて、コンソール上でオブジェクトと会話することで理解を深めることが出来たり、

開発段階にて、(机上ではなく)生きたオブジェクトを叩いて挙動を確認したり、

メンテナンス段階にて、ローカルのコンソールからBigTableに直接繋いで、即席コードのバッチ処理をかけたり、

こういったことができるのは、Javaには無い(もちろん他の言語環境にもない)Pythonだけのメリット。


本日のまとめGAE上ではRubyやPHPも動くけど，やはり標準対応されているJavaやPythonには及ばない。

既存の言語やフレームワークが動かないことに労力を費やすより，動くことが確約されているGAE用フレームワークを覚えることに意識を集中すべき。

オブジェクトと会話する感覚が好きなホビープログラマならPythonを選択すべき。アジャイル好きとかね。

ただ、業務で使うならJavaも検討すべき。堅牢性も大切。ロック処理などはやはりSlim3が便利。


Kayのコードを見てみたい?

サーバサイドはKay

フレームワークを使っています。

コードも短いのでちょっと眺めるにはいいかも。


おしまい

ご静聴ありがとうございます。

もっと突っ込んだ話は、ビール飲みながらしましょう!


Technology

JavaじゃないあたりのGAE事情