Gaeutilities Description: gaeutilities is a collection of classes developed by people working in the Google App Engine environment to handle needs they had for their own projects. They've been released to the general public in order to help others who find they have similar needs. Sessions for preserving data across multiple page views.An event management system to provide callbacks for plugging
Python æ¦è¦ CGI ç°å¢ ãã¼ã¿ã®æ ¼ç´ æ¦è¦ ã¨ã³ãã£ãã£ã¨ã¢ãã« ãã¼ã¿ã®ä½æãåå¾ãåé¤ ãã¼ã¨ã¨ã³ãã£ã㣠ã°ã«ã¼ã ã¯ã¨ãªã¨ã¤ã³ããã¯ã¹ ãã©ã³ã¶ã¯ã·ã§ã³ åã¨ãããã㣠ã¯ã©ã¹ GQL ãªãã¡ã¬ã³ã¹ ãªãã¡ã¬ã³ã¹ Model Expando PolyModel Property Query GqlQuery ãã¼ é¢æ° ä¾å¤ ãµã¼ãã¹ Memcache æ¦è¦ Memcache ã®
EclipseのGoogleプラグインを使ってローカル環境でサーバを起動するとき、通常サーバは127.0.0.1:8080で待ち受け状態になる。しかし、これだと他のPCからアクセスできないので、サーバを起動するときに以下のオプションをつけることで、他のPCからもアクセス出来るようになる。 --address=0.0.0.0以下はポートまで指定した例。 この場合、以下のようにリスンされる C:\WINDOWS\system32>netstat -an|find "3001" TCP 0.0.0.0:3001 0.0.0.0:0 LISTENINGなので、このPCがたとえば「192.168.0.50」で動いていたとすれば、他のPCから「http://192.168.0.50:3001/」でアクセスできることになる。(ファイアウォールとかあるならそれは解除してね) 設定するには、Eclipseの
昨日、low-level APIを試してみたんだけど。めちゃシンプルで分かりやすいってことがやってみて分かった。 low-level APIを使ったデータアクセス - ありの日記 そこで、low-level APIを使ったお得意のTODOリストサービスを作ってみた。あんまりむつかしいことはしてないんだけど、基本的な操作は一通りやってるはず。前回のTODOリストにはなかったページング機能を実装。と言っても、ユーザ管理とか何もないから。いや、みんなで共有して使えるというソーシャルなんとか的なアレがあるかも。 例によってSlim3で作って見ました。最初low-level APIを試すだけなら生のServletにそのまま書いてもいいかなと思ってたんだけど、やっぱりSlim3でやった方が色々はやそうなので、こっちにしました。やっぱりHOT reloadingが使えるのってメリット大きい。他にもCon
2009年09月09日20:38 カテゴリGoogle App Engine GAE/Jアプリ開発のTIPSまとめ Google App Engine for Java関連の記事が随分と溜まってきましたので、まとめ記事を作ってみました。今後も記事追加時にはこの記事を更新していきたいと思います。 GAE関連ブログをお書きの他の方のように、バックエンドの技術に対する深い考察などはありませんが、実際にアプリケーションを作成してみた上で遭遇したトラブルや小技を書いています。また、なるべくGoogleのドキュメントには記述されていないことを書いたつもりです。 GAEでアプリを開発される方の参考になれば幸いです。 ■対象のアプリケーション 次のアプリケーションを作成した上でのTIPSです。 Cycle Base NANASHI -サイクルベース名無し- 自転車用品・パーツのレビューまとめサイト。2ch
(随時更新中です。間違いなどありましたらコメントをお願いします!) このページのtinyurl: http://tinyurl.com/gaetips Datastoreのtips Bigtableの内部構造 BigtableによるDatastoreの実装 Datastoreによるクエリの実装 トランザクションとエンティティグループ Datastoreのtips List Proprtyとmerge joinの使い方 GAE一般のtips GAEのサーバー構成とリクエストの流れ Task Queue APIの使い方 開発環境とプロダクション環境の違い Flex/AIR+GAEのtips GAE/JにBlazeDSを組み込む BlazeDSの本番環境へのデプロイでハマる Datastore APIの取り扱いでハマる App Engine開発の便利な参考ページ TOPGATEさんのGoogle
Google App Engineで作ったアプリからGoogle Calendarのデータを使いたかったりしたので、調べてみた。 最初AutuSub認証でやろうと思ってたんだけどなんか、違うと思って、OAuthでやることにした。AuthSubとOAuthの役割って同じなんだろうか。OAuthはオープンな仕様で、AuthSubはそうじゃないってだけ? ちなみに、OAuthはコンシューマとサービスプロバイダとユーザという3つのアクターが登場する。今回、自分の立場はコンシューマになる。サービスプロバイダがGoogleで、ユーザはコンシューマが作ったサービスとサービスプロバイダの利用者だ。 以下のサイトがOAuthについてわかりやすく説明されてる。 第1回 OAuthとは?―OAuthの概念とOAuthでできること:ゼロから学ぶOAuth|gihyo.jp … 技術評論社 また、OAuthではサー
Under the covers of the App Engine Datastore Ryan Barrett Google May 28, 2008 Contents Best practices Bigtable in one slide The Entities table Queries and indexes Kind index Single-property index Composite index Merge join Entity groups and transactions Bigtable in one slide (...ok maybe ten) What is Bigtable? Scalable, structured storage (vs unstructured)
もう1つの、DBのかたち、分散Key-Valueストアとは:分散Key-Valueストアの本命「Bigtable」(1)(1/3 ページ) RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog
素朴なBigtable、できること できないこと:分散Key-Valueストアの本命「Bigtable」(2)(1/2 ページ) RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 あまりにもRDBとは異質な「Bigtable」 前回の「もう1つの、DBのかたち、分散Key-Valueストアとは」では、連載第1回目として、クラウドコンピューティングにおける新しい潮流である「リレーショナルデータベース(RDB)から分散Key-Valueストア(分散KVS)への移行」が、どのようなパラダイムシフトをもたらすのかを解説しました。今回からは、グーグルが運用する代表的な分散KVS「Bigtable」の内部構造を紹介し、クラウドの本質をより深く掘り下げます。 前
ここが大変だよBigtableとGoogle App Engine:分散Key-Valueストアの本命「Bigtable」(3)(1/2 ページ) RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 月間3000万PVの大規模サイトの運用費が月額4万円!? 月間3000万PV相当の膨大なトラフィックを楽々とさばく大規模サイトが、月額4万円弱で運用されている。 Google App Engine(以下、App Engine)が普及するにつれて、そんな驚愕の国内事例も登場しつつあります。GClueがApp Engine上で実装したmixiアプリモバイルモバイルには、1日100万PV以上のアクセスが集中している状態でもサービスのレスポンス低下やダウンは皆無
前回のエントリが結構好評だったのと、前回のエントリだけだと、JDOから入った人は「Relationshipどーすんの?」となりそぅな気がしたので、調子に乗ってlow-level APIとJDOでのRelationshipの比較等について書きます。 JDOの方はLLParentクラスがOneToOneでLLChildAを、OneToManyでLLChildBを保持するような構成です。一方low-level APIではJDOと同じ事をキーのみでEntityGroupを構成します。LLParentkindは子エンティティのためのpropertyを一切保持しないと言う事です。JDOの方でもキーのみでEntityGroupを構成する事ができますが、ListPropertyで保持する方が一般的というかORMっぽいかなぁと思いまして。 一見、データの保持の仕方が全く違うよね?と見えますが、実はどちらの方
shin1ogawaさんのエントリ:「#appengine JavaのLow-Level API入門 Relationship編」 ここまで読んでしまうような変態な皆さんは、フックする為に使用しているMyDelegate#makeSyncCall()メソッドが気になって仕方無いですよね。特に第四引数であるbyte[] requestとかいうヤツ。「…何が入っているんだろう…というか全部が入っているんだよね?何でも取得できるよね」という予測ですよね!ズバリその通りです、ここに全部入っています。ただ、この中身は実行されるサービスによって変わる、ProtocolBufferによるシリアライズの結果です。例えば今回使った DatastoreサービスのPUTメソッドであればcom.google.apphosting.api.DatastorePb.PutRequestオブジェクトに組み立てられます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く