![Sign in - Google Accounts](https://cdn-ak-scissors.b.st-hatena.com/image/square/3698d95cde56fff85faa825c5621a8503d5f00e9/height=288;version=1;width=512/http%3A%2F%2Ftech.topgate.co.jp%2F_%2Frsrc%2F1472875901223%2Fgijutsu-shiryou%2Fslim3-json%2FScreen%2520shot%25202010-05-18%2520at%252017.26.59.png%3Fheight%3D173%26width%3D400)
App Engineで使える言語は基本的にはPythonとJavaです。それでは、どちらを選ぶのが良いのでしょうか。 それ以外の言語の人向けの話は後から出てくるのでしばらくこのままお読みください。 趣味ならば単に好きなものを選ぶだけでいいのですが、仕事で使うためには、長所と短所をきちんと把握した上で選ぶ必要があります。また、ここでの話は言語としての一般的な話ではなくApp Engineで使うとき限定の話としてお読みください。 まず安定度ですが、インフラ部分の安定度は、どちらも基本的に同じです。もしかすると、まったく同じものを使っているのかもしれません。 その上で動くAPIの部分は、インフラと直接結びついている低レベルな部分と低レベルなAPIの上に構築された高レベルな部分とに分けて考える必要があります。 低レベルなAPIはLLAPIと呼ばれたりしますが、安定度は、PythonとJavaも同じ
Google App EngineにはTransactionは1つのEntity Group内でしかできないという制限があります。詳しくは、App EngineのEntityGroupを理解しよう - yvsu pron. yasを参照してください。 そうするとある口座から別の口座にお金を振込むような送金のパターンで、Transactionを利用することができません(すべての口座を1Entity Groupに押し込むと更新がぶつかって現実的ではないから)。送金パターンで整合性を保つためには、理論的には次のようになります。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 実装するとこんな感じ。 http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engi
Slim3の正式リリースは、来年の一月くらいになりそうですが、ドキュメントも最低限のものはそろったので、今の段階のものをPreview版として紹介しておきます。 サイトへは、http://slim3.org でアクセスしてください。 Getting Startedをやり、Slim3 Datastoreのドキュメントを読み、Online demoをみれば、Slim3のことは把握できるようになっています。 Oneline demoからソースも見れるようになっているので、動かしながらソースを確認することができます。Online demoは、IE6で見るとレイアウトが崩れていますが、これはIE6を使うなというメッセージということで。(IE7,8では未確認) Slim3は、Google App Engineに対して最適化されています。 例えば、最近、App Engineで問題になっているのは、spi
Slim3をGAE/Jに対応させました。 デモサイトはこちら。 http://higayasuo.appspot.com/ ソースコードをチェックアウトしたい場合はこちら。 http://code.google.com/p/slim3/source/checkout https://slim3.googlecode.com/svn/を指定してチェックアウトできます。デモ用のプロジェクトは、slim3-demoです。 SAStrutsのチュートリアルをやったことのある人なら、デモサイトが、そっくりだということがわかるでしょう。Slim3 Struts(SAStruts相当)がGAE/Jで動くわけです。 素のStrutsだとGAEではファイルアップロードに失敗しますが、Slim3 Strutsはその辺も対応してます。 やってみて感じたのは、GAE/Jは、制限が結構厳しいので、高度なフレームワー
S2JDBC(やS2Dao)では、2Way SQLにIFやBEGINコメントを埋め込んで動的にWHERE句を組み立てていました。 select ... /*BEGIN*/ where /*IF foo != null*/ foo = /*foo*/1 /*END*/ /*IF bar != null*/ and bar = /*bar*/1 /*END*/ /*END*/このSQLコメントを使った動的なSQL生成は、評判の良かった機能ですが、SQL文にロジックが入るとコンパイラでチェックできないので、何とかしたいと思っていました。 そこで、Slim3 JDBCで考え付いたのが、WHEREコメントを使って、Javaから動的にWHERE句を組み立てる方法です。SQLはこんな感じ。 select ... /*WHERE*/WHERE句は、Conditionオブジェクト(S2JDBCのWhereオ
雨の中、600名の人に来ていただきどうもありがとうございました。 アンケートも一通り目を通しました。よねさんの俳句が好評で、今井さんのギャグが不評だったことが良くわかりました(笑)。 Seasar2とSlim3のすみわけについてよくわからなかったという意見がいくつかあったので、補足しておきます。Seasar Projectで、今最も人気のある組み合わせである「Seasar2.4 + SAStruts + S2JDBC」は、安定していて、機能も充実しているので、既にSeasar2を使われている人は、そのままSeasar2を使い続けて欲しいと思っています。 Slim3のターゲットとしているユーザ層は、現在Struts + Spring + Hibernate/iBatisで開発していて、生産性がいまいちあがらないなぁとおもっている人たちです。 別の言い方だと、コンテナには、Springを使いた
JavaでAnnotationがついたクラスがあったら、それに対して処理したい場合は、Seasar2のコンポーネント自動登録で使っているように、ファイルシステムまたは Jar ファイルを全走査してクラスロードする方法もあります。 ファイルシステムまたは Jar ファイルを全走査してクラスロードしてください。が結論です。 Seasar だったら、 org.seasar.framework.util.ClassTraversal を読むべし。 でも、これは、Seasar2.3時代(3年前)の話で、技術としてはちょっと古い。 HOT deployなどと組み合わせると、リクエストのたびに全コンポーネントをデプロイする必要があるので、コンポーネントの数が増えると実用的には使えないのです。 そこで、考え出したのが、Seasar2のONDEMAND deploy。コンポーネントの定義を見に行って、あれば
Slim3のトランザクション管理の部分を実装しました。 http://svn.slim3.org/browse/trunk/slim3/slim3-transaction/src/main/java/org/slim3/transaction/ 一番のポイントは、どのアプリケーションサーバで動いているかを自動で検知して、適切なセットアップをすることです。これにより、単に設定が楽になるだけではなく、同じ設定ファイルで、テストのときも本番のときも動かすことができます。 設定といってもslim3_configuration.propertiesに次の一行を足すだけ。 slim3.plugins=org.slim3.transaction.plugin.TransactionPluginPluginというのは、アプリケーションの開始時と終了時に呼び出されるクラスで、通常は、Plugin#initi
Slim3 Container、略してS3ContainerのDI部分は出来上がったので、機能を軽く紹介します。 まだ、サイトのデザインが決まってないので、サイト自体がないのですが、興味のある方は、https://www.slim3.org/svnのリポジトリにアクセスすることで最新のソースを見ることができます。 はしもとさん、はやくSlim3のサイトの打ち合わせをしましょう。 S3Containerを動かすには、以下のjarファイルが必要です。 slim3-commons-xxx.jar slim3-container-xxx.jar geronimo-annotation_1.0_spec-1.0.jar geronimo-ejb_3.0_spec-1.0.jar geronimo-interceptor_3.0_spec-1.0.jar javassist-3.4.ga.jar ge
Slim3は、この半年間、ずっと構想を練ってきたわけですが、10月からいよいよ本開発に入ります。なぜ、半年間も構想を練っていたかというと、SAStrutsとS2JDBCの開発が続いていたからというのが主な原因です。 なぜなら、Slim3は、SAStrutsとS2JDBCをポーティングしようとしているので、ポーティング元が安定してないと、二重にメンテナンスをしなければいけなく、負担が大きくなってしまうためです。 半年間待っている間に、状況も大きく変わってきました。一番大きいのは、Springのメンテナンスポリシーの変更ですね。 Springの新しいメンテナンスポリシーでJava界の勢力図が変わる もともと、Slim3は、Springコミュニティに対して、Seasar2で人気のあるHOT deployの機能とSAStrutsを提供しようというつもりで企画しました。 しかし、Springの新しい
仕事で勉強会にはいけなかったのですが、資料を見てのちょっとした感想 Configurerの目的がいまひとつピンときませんでした。環境切り分け用であれば、SpringはJNDIを簡単に使えるのでそちらを利用したいところです。特に、本番環境用設定は設定ファイル上には持ちたくないので、セキュリティ的にはJNDIが最も安心だと思っています。環境面での切り替え用途だけではなく、APサーバ提供機能に対する切り分けという意味でも便利ですし。Seasar2のJndiContext相当の機能が提供されれば、SpringのJNDI機能はもっと便利になるだろうと感じています。 AOPの例でMethodInterceptorが使われているのが気になりました。Spring2でのAOP記述の推奨パターンはAspectJ形式ですし、AspectJ形式で書いておけばいざというときにAOP実行をAspectJに切り替えるこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く