Seasar3がやってくる
Seasar2は、機能を枯れさせることに徹し、機能追加は行わないと宣言してから、二年以上たちます。
で、Seasar2が冒険しないことによって、適切な大きさの問題は生まれなくなり、開発者が離れ、Seasar関連プロダクトが生まれなくなり、Seasarユーザも離れていく。使われないSeasarからさらに開発者が離れていく。
こういうスパイラルが発生するかもしれないことについては、どう考えますか？
このような声もありました。「機能を枯れさせることに徹する」というのは、かなりの冒険でしたが、今のところ、うまく行っていると思っています。
「RubyやSeasar2、OpenPNEが“定番”に、Linux Foundationが活用動向調査」という記事も出てましたね。
http://itpro.nikkeibp.co.jp/article/NEWS/20100527/348514/
しかし、二年の間に世の中は色々と変化しました。その中でも一番大きな変化はクラウドでしょう。スケールアウトが必要になるようなアプリ向けには、Slim3があるので、心配はしていないのですが、最近、大きな動きがあるのが、エンタープライズクラウドです。
VMforce、Google App Engine for Businessがその典型的な例で、これらの中心にいるのは、Springです。エンタープライズクラウドは、Springが牽引することは間違いないでしょう。
これまで同様、守りに入ったままだと、Seasar2は徐々に衰退していってしまうので、ここで、Seasar3の開発に踏み切ることにしました。
Seasar2のユーザーは、安心してSeasar2を使い続けてください。Seasar2は、ユーザーがいる限りメンテし続けます。弊社の商用サポートも続けます。
Seasar3は、Seasar2を維持するために、はじめるのです。Seasar3をはじめないと、Springの存在感が日本でも徐々に大きくなり、Seasar2が衰退してしまうから。Seasar2が衰退してしまうと、開発メンバーが維持できなくなるのです。
Seasar3が運良く成功できれば、Seasar3の開発を続けながら、Seasar2のメンテ体制も維持できます。
Seasar3がどのようなもになるのかは、6/13(日)に開催されるSeasar Conferenceで、最初の案をお話します。会場の皆様とディスカッションしながら仕様を考えていきたいと思います。
セッションのお申し込みはこちらから。
https://event.seasarfoundation.org/jcmt2010/register/
後、2週間弱あるので、Seasar3がどのようなものになるのか、いろいろ想像してみてください。
Slim3はGoogle App Engine向けで、Google App Engine for Business向けではありません。Seasar3とかぶることはないでしょう。
Seasar3は、VMforce、Google App Engine for Businessのリリースに合わせて、年末か、来年初めにリリースする予定です。
プロが仕事で使う場合にApp Engineでどの言語を選べばいいのか
App Engineではどの言語を使えばいいのか - yvsu pron. yas
ただ、仕事で使う場合は、素のSDKで開発することはなく、何らかのフレームワークを使うことが普通です。App Engineに特化したKay frameworkやSlim3のレベルで比べるとそんなに違いはありません。
これは、単純なリクエストの処理だと、Javaの方が10倍速いが、実際に行われている処理で比べるとそんなに違いはないのと似ています。
私は、Javaを使っているので、Javaへの評価が良くなりすぎないように、意識的にJavaのデメリットを強調し、Pythonのメリットを強調していますが、実際の仕事で使うレベルにおいては、差はほとんどないということです。
んんーーーー。
たまには本音を書きましょう。プロが仕事で使う場合には、リファクタリングやテストのしやすさは、非常に重要なポイントですが、これらを考慮すると、正直、Javaのほうがリファクタリングはしやすく、テストもしやすい。
リファクタリングのしやすさは、Javaの言語としての特徴とSlim3のタイプセーフクエリのおかげ。テストのしやすさについては、App Engine/Javaがもともとテストしやすいように作られていることと、Slim3のようにテストのしやすさを追求したライブラリが存在することがその理由。
論より証拠。このustを御覧下さい。
http://www.ustream.tv/recorded/6377235
正直、あんなに高速にコーディング出来る人はあまりいないけどねｗ
App Engine/Pythonはローカルのデータストアのstubの出来が良くないので、ローカルとプロダクションで動きが違うことが結構あり、ローカルでテストできることが限られてしまいます。Javaの方は、Statisticsの機能を除いては、ローカルとプロダクションの動きはほとんど同じです。stubレベルでは、ローカルでプロダクションと違う部分もあったりしますが、Slim3でおなじになるように実装してたりするので、ほとんど違いがないのです。
じゃ、プロならJavaを使った方がいいかというとそんなこともありません。好きで慣れている方を使った方が効率いいからね。
ただ、プロが仕事で使う場合には、リファクタリングやテストのしやすさは、非常に重要なポイントです。その点ではApp Engine/Javaが優れているということは知っておいた方がいい。テストのしやすさは、ソフトウェアの問題なので、改善することが可能です。今回わざわざ指摘したのは、改善されることを期待しているからです。お互いに良いところは学び、悪いところは改善していけばいい。
GAE/PのほうがGAE/Jより良いと無邪気に主張している人は、App Engineに関しては、素人だと思われても仕方がない。最後に大人気なく書いてみましたｗ
DIコンテナの必要性
DI コンテナの起動が遅いなら、起動が速いのを作ればいいじゃない
何度か書いているとおり、DIはテストをしやすくすることが一番のメリットであり、オンプレミスの世界では、今でもある程度有効です。ただ、appengineの世界では、テストする環境が整えられているので、DIを使う必要はないということです。
http://d.hatena.ne.jp/higayasuo/20091115/1258245284
DIを使ったことがある人はわかると思うけど、DIには、ある程度のめんどくささがあります。appengineの世界では、DIがなくてもテストが簡単にかけるので、わざわざめんどくさいことをする必要はないでしょう。
appengineの世界でテストがどれくらい書きやすいのかは、次のustをみればわかります。
http://www.ustream.tv/recorded/6377235
技術的には、JSR330を実装したspin-upの速いDIコンテナを作ることは簡単だし、作ればかなりユーザが付くだろうと思ってますが、いらないと思っているものを作る気には全くなれません。同じように、spin-upの速いJDO/JPAの実装も作れると思うけど作る気になりません。こっちに関しては一瞬作ろうかと思ったこともあるけどｗ
さんざん苦労するなら、pythonでいいじゃんという考えも、短絡的で、slim3は、appengineに向いているようにを最初から設計されているので、spin-upについては全く困った事がありません。JDOに困らされて、JDOを捨ててSlim3 Datastoreを一から設計し直したのは、苦い記憶だけど。
appengineで使う言語は、素のSDKで比べるとpythonの方が断然出来がいいけど、プロが仕事で使う場合には、リファクタリングやテストのしやすさやIDEの効率などを含めると、たぶん、Javaの方が生産性が高い。これは、ajn7の会場にいた人はきっとそう思っただろうし、会場にいなかった人も上記のustを見てもらえればわかるでしょう。
「プロが仕事で使う場合にappengineでどの言語を選ぶべきか」ついては別のエントリを書きます。
よしおりが結婚できた本当の理由
よしおりがドラ娘と婚約したことがtwitterで話題になっていたんだけど、TLで各界の識者が「よしおりが結婚できた本当の理由」について分析している。だけど、このTLを読んで一つ大きく疑問に思うのは、「なぜ各界の識者は、ぼくのところに話を聞きにこないのだろうか？」ということだ。
よしおりが結婚できた本当の理由を、ぼく以上に分析するのにふさわしい人物はいるだろうか？
いやいない。
なにしろ、200?年の?(よく覚えていない)に、飲み会で『Javaをやってる人がかたいなんて、ごちゃごちゃいってないで、自分でなんかはじめたらいいじゃん』といったことばをよしおりが真に受けてJava-jaを作って以来、無類のよしおりウオッチャーとしてその観察・研究に生きている時間のほとんど全てを費やすようになり、Java-jaの集まりは、ゲーム大会と飲み会以外は、出たことがないというのに……
でもいいのです。ぼくはそういうことについては、7月3日(土)18時、目黒雅叙園にてひらかれるkekkon披露パーティで語っていこうと思ってますから。
といっても、そこでは別に、「よしおりの知られざる女関係」といった、下衆なことを語るわけではない。それよりは、それこそ@t_wadaが悩んでいるような、「結婚できたの理由」の概要や法則を分析し、皆さんにお伝えしていきたいのである。
なぜそれをしたいかといえば、ぼくの今の目標の一つに、「結婚の仕方を方法論化し、それを彼女のいないやつらに支えたい」というのがあるからだ。
というわけで、よしおりとドラ娘を祝いたいと思っている方は、7/3をあけておいてほしい。
それと最後になったが、結婚本当におめでとう。
よしおりとドラ娘の結婚に関するハッシュタグは、#doramadamです。
あわせてよみたい
http://d.hatena.ne.jp/aureliano/20100407/1270611575
App Engineではどの言語を使えばいいのか
App Engineで使える言語は基本的にはPythonとJavaです。それでは、どちらを選ぶのが良いのでしょうか。
それ以外の言語の人向けの話は後から出てくるのでしばらくこのままお読みください。
趣味ならば単に好きなものを選ぶだけでいいのですが、仕事で使うためには、長所と短所をきちんと把握した上で選ぶ必要があります。また、ここでの話は言語としての一般的な話ではなくApp Engineで使うとき限定の話としてお読みください。
まず安定度ですが、インフラ部分の安定度は、どちらも基本的に同じです。もしかすると、まったく同じものを使っているのかもしれません。
その上で動くAPIの部分は、インフラと直接結びついている低レベルな部分と低レベルなAPIの上に構築された高レベルな部分とに分けて考える必要があります。
低レベルなAPIはLLAPIと呼ばれたりしますが、安定度は、PythonとJavaも同じです。API自身も非常によく似ています。言語の違いをあまり感じさせないくらいです。
高レベルなAPIはデータベースに接続する部分だとJavaならJDO/JPA、Pythonだとdbモジュールだとかがあります。実は、この部分からJavaとPythonの運命がわかれてきます。Pythonの方は安定していますが、Javaの方は、まだまだバグがあったり仕様が変わったりすることがあるのです。ただ、最初の頃に比べるとかなり改善されていて、今では頻繁にバグに遭遇することはありません。安心して使えるかというとそうでもないけど。
Javaの方がPythonより安定していないようなイメージがあるのは、この辺に原因があるのかもしれません。
Javaを使いたいあなた、心配することはありません。Slim3を使えばいいのです。Slim3は、安定しているLLAPIの上に構築されている薄いラッパーなので、あまりバグが入り込む隙間がありません。1.0.0もリリースされたし、安心して使うことができます。Javaで開発する場合もSlim3を使えば安定した開発が可能なのです。
次はパフォーマンスについてです。パフォーマンスはspin-up(アプリケーションの起動)とリクエストの処理の二つに分けてみていきます。
spin-upの速度はAppEngineにおいて、非常に重要なものです。
これまでのスタイルでは、アプリケーションの起動時に出来る限りの最適化を行っておき、リクエストの処理を短くすることが重要でした。アプリケーションの起動はどうせ一回しかやらないのだから、その速度はあまり重要ではなかったのです。
しかし、AppEngineでは、2,3分アクセスがないと直ぐにインスタンスがspin-down(終了)され、次にリクエストがあったときに、spin-upが起きるので、spin-upはとても頻繁におきます。また、リクエストが集中してscale outが必要なときにもspin-upがおきます。
spin-upの速度はAppEngineにおいて、非常に重要なものなのです。大事なことなのでなんどもいいますよ。
とても単純なアプリケーションで比較するとPythonのspin-upは100ms以下。Javaは1000ms以下。大雑把にいってPythonの方が10倍速いと言えるでしょう。
これは、単純なアプリケーションでの場合ですが、Springのような重量級のフレームワークを使うとspin-upが20000msを超えることもざらです。桁を間違って書いているわけではありません。念のため。DIContainerの中では軽いといわれているGuiceでも7000msから8000msくらいかかったりするのでAppEngineでDIContainerを使うのはあまり現実的ではありません。
もともとDIContainerが普及したのは、テストをしやすくするためとAOPを使った宣言的トランザクションなどが使えるためですが、AppEngineではテストをするためのフレームワークが整備されていてDIContainerなしでもテストが簡単に行えますし、AppEngineでは基本的にGlobalTransactionが使えずごく限定された範囲でしかトランザクションが使えないので、宣言的トランザクションも役に立ちません。
つまり、AppEngineでは、DIContainerを使うメリットがあまりなく、デメリットが非常に大きいので、DIContainerを使うべきではありません。
もっというと、機能の豊富なフレームワークは、spin-upが遅く、AppEngineの制限から豊富な機能が使えなかったりするので、AppEngineには向かないと言えます。
JDO/JPAもspin-upに4000msから5000msくらいかかるので、はっきりいってAppEngineに向いていません。標準で用意されているフレームワークがAppEngineに向いていないというのは、ちょっとどうかなと思いますが。
AppEngineでとりあえず動作するということと、実用的につかえるということはまるで違います。自分たちがこれまで使ってきたフレームワークをAppEngineで試してみて、spin-upの遅さにがっかりしたという開発者は、世界中にいっぱいいます(MLやtwitterでよく見る)。
この辺が、AppEngine for Javaが遅いと思われている原因なのかもしれません。
Javaを使いたいあなた、心配することはありません。Slim3を使えばいいのです。Slim3はAppEngineに最適化されているのでspin-upも1100msくらいです。超単純なServletより若干(200msから400ms)オーバーヘッドがあるくらいなので、安心して使うことができます。
リクエストの処理は、単純なRequest Handlerの場合、Javaの方がPythonより10倍速いという結果があります。ただ、実際は、Bigtableへのアクセスなどを含むので10倍の差は開かないでしょう。
リクエスト時に動く、データアクセスの処理もJDO/JPAはもっさりしていて遅いです。Slim3の方が圧倒的に速いので、ぜひ次のデモを自分で試して実感してください。
http://slim3demo.appspot.com/performance/
これまでの話をまとめると、AppEngineで開発する場合、Pythonと比べてJavaは、安定度に難があり、spin-upの速度やデータアクセスの速度に問題を抱えています。これらの問題を解決するには、Slim3を使うのが良いということです。
もちろん、Java使いでSlim3を使わずに開発している人もいると思いますが、その人達は、上記にあげた問題を抱えているはずです。
さて肝心な、どの言語を選んだ方がいいかですが、Pythonの出来がいいので、LLな人はPythonを使うのがおすすめです。これまでPHPやRubyを使ってきた方も仕事で使うなら、Pythonを使った方が固いです。
JVM(Java)経由でRuby(JRuby)やPHP(Quercus)を使う手もありますが、Javaのオーバーヘッドに加えてさらにScriptEngineのオーバーヘッドが加わるので速度的には期待できません。
ただ、JRubyは頑張ってチューニングしていて、最新版だとSinatraで8000ms位でspin-upするようなので、なんとか使えるかもしれません。Sinatraでも厳しいくらいなので、AppEngineでRailsを仕事で使うのは、今のところ現実的ではないでしょう。
Pythonを使う上での注意点は、Djangoのような高機能なフレームワークを使うとPythonでも重くなってしまうということです。KayのようなAppEnginejに最適化されているフレームワークを使うのがおすすめです。
http://code.google.com/p/kay-framework/
Java使いの方は、Slim3を使うのがオススメ。もちろん、Slim3が好みに合わない人も沢山いると思いますが、使わない場合は、上記で上げたような問題を自前で解決する必要があります。
Slim3 1.0.0 Released
Slim3 1.0.0をリリースしました。
リリースノートはこちら
http://sites.google.com/site/slim3appengine/release-notes
ダウンロードはこちら
http://code.google.com/p/slim3/downloads/list
Slim3の主な特徴は次のとおりです。
- Global Transactions
- Faster than JDO/JPA
- Fast spin-up
- HOT reloading
- Type safe query
詳しくはこちらをどうぞ
http://slim3.org
Seasar2譲りのHOT reloadingやS2JDBC譲りのType safe queryなどもありますが、最大の特徴は、Global Transactionsを実装していること。
http://d.hatena.ne.jp/higayasuo/20100210/1265781747
App Engineの世界で汎用的に実用的な速度でGlobal Transactionを実装したのはSlim3が初めて何じゃないかなと思います。Global Transactionがなぜ速いのかは、明日のAppEngine ja nightで詳しくお話します。
NoSQLの世界では(NoSQLじゃなくてもそうだけど)、consistencyを重要視するとパフォーマンスが劣化します。Slim3では、いくつかのテクニックでこの問題を解決しています。
軽く書いておくと、複数のリソースにまたがるときに、最初のリソースに対しては、通常のローカルトランザクションとして実行していること(これは2PCの世界でlast resource optimizationと呼ばれているものを応用したものです)。30秒経ったら自動的にロックが外れるようにしていること。Journalを圧縮していることの三つです。
GlobalTransaction.java
Lock.java
Journal.java
Slim3はもちろんオープンソースなので、このようなテクニックがNoSQLの世界で少しでも役に立つならうれしく思います。
AppEngineのJDO/JPAはAppEngineを軽く知る分にはいいのですが、パフォーマンスが悪く、はまりどころ満載で、誰得なフレームワークなのでSlim3 Datastoreを使うのをお勧めします。
さらにJDO/JPAはspin-up(アプリケーションの開始)が超遅いんだよね。AppEngineではちょっと使ってないと直ぐ(2,3分くらい)にインスタンスが停止され、次のリクエストでspin-upが起きるのでspin-upが速いことはとても重要です。
