Google App Engine 2アプ目

Google App Engine 2� ..

870:nobodyさん
10/02/12 12:17:10
なるほど、スケールアウトのメリットを活かせるんでなければ
別に従来のやりかたでもいいもんなぁ。

871:nobodyさん
10/02/12 17:33:34
ｽﾚﾘﾝｸ(tech板:216番)

872:nobodyさん
10/02/12 18:28:36
ec2は機械的に壊れないのもいいな
物理サーバだと結構壊れるもんなぁ

873:nobodyさん
10/02/12 18:42:13
>>872
gaeは壊れるとでも？

874:nobodyさん
10/02/12 19:17:02
仕様ならぶっ壊れてるかもしれん

875:nobodyさん
10/02/12 19:26:43
>>873
え・・そんなつもりで言ったんじゃないけど・・
誤解させたならごめん・・

876:nobodyさん
10/02/12 19:31:56
受託開発にGAEは使えないだろうな
まぁ受託開発なんてカス企業同士が少ない利益を奪い合う
みっともない事業だからどうでもいいけど

877:nobodyさん
10/02/12 19:34:59
>>876
Webベンチャー（笑）の方ですか？
海外で流行したサービスをパクって
上場詐欺ばかりやってるお前らが
歴史も伝統もある大企業に楯突こうなんて
100年早いんだよ

878:nobodyさん
10/02/12 19:40:43
>>877
そんなつもりで言ったんじゃないけど・・誤解させたならごめん・・

879:nobodyさん
10/02/12 19:47:52
>>877
歴史も伝統もあるが技術力がない大企業ｗ

880:nobodyさん
10/02/12 19:50:24
>>862
ComparatorとExtentで頑張ってる俺のことか？

881:nobodyさん
10/02/12 19:50:41 Zvvvy7KE
>>876
受託開発に未来がないのは皆気づいてるよ
そりゃフロー型よりストック型のビジネスモデルのほうが
安定してるし、営業利益率も高いだろうさ

でも老害経営者達は、ITゼネコン構造からの脱却なんて絶対にしないよ
下請け孫請けからいくら自殺者が出ようと知ったこっちゃない
犠牲になるのは若者で自分たちじゃないから

今の日本と同じだね　JALのOB連中みたいな人間が五万といる

882:nobodyさん
10/02/12 20:02:26 Zvvvy7KE
>>877
お役所から天下りを受け入れて
公共事業を発注してもらい
それを下請けに丸投げする
上流SIerさん、コンニチハ

Wikipedia項目ﾘﾝｸ

883:nobodyさん
10/02/12 20:04:06 Zvvvy7KE
URLﾘﾝｸ(ascii.jp)
これも置いときますね

884:nobodyさん
10/02/12 21:50:43
ただ自分でサービス作って儲けたい、なんてのやろうと思ったら
気楽なサラリーマン出来なくなるんだよな。

Googleからおこぼれ貰いつつニートしてたい・・・

885:nobodyさん
10/02/13 01:35:59
>>873
しょっちゅう壊れてるだろってはなし

886:nobodyさん
10/02/13 02:19:31
安いサーバーの寄せ集めだから毎日壊れまくってるだろうよ

887:nobodyさん
10/02/13 14:44:26
gaeも物理サーバが壊れても吸収するようになってるんでしょ？

888:nobodyさん
10/02/13 15:09:45
半日メンテでログイン出来ないとか
何やってんだろうとは思う

889:nobodyさん
10/02/13 15:32:03
その間サイトは普通に動いてるの？

890:nobodyさん
10/02/13 22:11:31
いいえ

自分のサイトも開けない

login: required
なページのログインも出来ない

そういえば管理画面は見れる

891:nobodyさん
10/02/13 22:14:59
DataStore(BigTable)へのアクセスが完全に出来なくなる時間帯はあるみたいだね
Google的には「メインテナンスだからダウンタイムは0です」だそうで

892:nobodyさん
10/02/13 22:54:14
>>890
cookie全部消してみれば良いことあるかも

893:nobodyさん
10/02/13 23:15:28
>>890
駄目すぎじゃん
まだそんなレベルなのかよ・・

894:nobodyさん
10/02/14 00:15:17 eZzi4axx
レンサバ業者のネガキャンが酷いな

895:nobodyさん
10/02/14 03:03:35
dashboard のログ表示が体裁がめちゃくちゃで見難過ぎる

896:nobodyさん
10/02/14 15:57:35
ダウンタイムを検証してるサイトとかないの？

897:nobodyさん
10/02/14 17:32:25 +CS+iG30
Eclipseでweb application projectを新規作成した時点で、すでに
java.lang.UnsupportedClassVersionError
がでてしまいます。
Eclipseは3.4.2です。何がまずいんでしょうか？

898:nobodyさん
10/02/14 23:01:11 eZzi4axx
>>897
Java VMのバージョンが古い
常に最新しておけ

899:nobodyさん
10/02/16 20:28:21
どんまい

900:nobodyさん
10/02/17 11:31:06
CPU時間の負荷の上限超えたときのhttpステータスって何番で返ってくるか誰か教えて下さい！
上限上げちゃってテストしようとする課金されるｗ

901:nobodyさん
10/02/17 14:06:08
Bigtableでjoinが使えないので、別の方法を探しています。
同じ書式の二つのテーブルを比較して、数値の増減や新規項目などと分類したいです。
MySQLではjoinを使った検索で簡単に分類できました。
BigTableではどのように検索するのがいいのでしょうか。

1)主キー以外のフィールドを二つずつもった書式のテーブルに代入して、BigTable内で検索する。
2)二つのテーブルをローカルにDLして、二重のforループで検索。
3）実はそれようの関数が用意されている。

項目は500個。できれば3を期待しています…
よろしくお願いします。

902:nobodyさん
10/02/17 17:39:27
>>901
4. KVSについて勉強しなおし、データのモデルを考え直す

903:nobodyさん
10/02/17 17:52:07
>>901
5) GAEはやめる

904:nobodyさん
10/02/17 18:38:22
GAEに向いてない場合も確かにあるよな。

905:nobodyさん
10/02/17 19:38:11
KVSについてよく理解していないだけ。
Googleのサービスでは内部でKVSであるBigTableを使っているんだから、向いていないということはありえない。

906:nobodyさん
10/02/17 19:49:28
>>900
304

907:nobodyさん
10/02/17 20:21:11
>>906
ありがとうございます！

908:nobodyさん
10/02/18 07:52:49
>>902-905
入門サイト探してもうちょっと勉強しようと思います。
ありがとうございました

909:nobodyさん
10/02/18 12:31:55
新刊
RDB利用者のためのGAE講座

910:nobodyさん
10/02/18 15:13:53
cronが止まってたらしい
まだまだ不安定ですな

911:nobodyさん
10/02/18 16:53:14
GAEは箱庭とかモブストみたいなゲームを載せてもBANされない？

912:nobodyさん
10/02/18 17:19:30
You BAN

913:nobodyさん
10/02/18 17:31:08
金さえ払えばおk

914:nobodyさん
10/02/18 17:44:36
遊ばれれば遊ばれるほど金が入るので、きっと喜ばれるよ

915:nobodyさん
10/02/18 18:06:31
定期メンテでも1時間てのは
業務アプリだと厳しいなー
日本時間深夜にやってくれればいいけどそんなわけないし

916:nobodyさん
10/02/18 22:16:27
っつーかメンテで止まるってのがそもそも変

917:nobodyさん
10/02/18 22:18:39
更新できないだけで止まってない！！
それがGAEクオリティ

918:nobodyさん
10/02/18 22:53:19
止まってるよ
require: login
とかのページ開けないし

919:nobodyさん
10/02/19 11:26:17
キャリアはドコモなんですが、アカウント登録に使うメアドは、
登録後すぐに変更しても大丈夫ですか？
また、どんどんメアド変更していけば無尽蔵に取得できますか？

920:nobodyさん
10/02/19 16:26:28
・認証済ませれば後はメールは来ないので変更は直ぐ出来る
・グーグルにはメアド変更を判別する手段が無いので無尽蔵に取れる
メアド変更はともかく大量取得が大丈夫かは判らんよ

そもそもそんなに取得してどうするよ
アプリID確保するにも、もうよさげなのは殆ど取得されてるぜ
BAN覚悟のアプリ使うくらいしか用途無いぜ

921:nobodyさん
10/02/19 18:28:10 8xYfT/D8
URLﾘﾝｸ(satoshi.blogs.com)
ここで
「移植性を高めるために標準APIをゴリゴリ使ったアプリを作るのはあんまり意味ない」
的なことが書かれているんですが、実際GAE使ってそれなりのアプリ作ったことのある人の意見が聞いてみたいなーなんて。
（自分はまだ導入段階なもので）

確かに「GAEを使う意味」を考えたら低レベルAPIを直接叩いてGAEのパフォーマンスを
存分に発揮できるようなアプリを作るべきなのかもしれないですけど、
ほぼ無料で使えるというだけで大きなアドバンテージでGAEを選ぶ理由としては十分だし、
仮にその性能をフルに発揮できばくなったとしても、保険の意味もこめて
移植性を高めた書き方をしておくことは間違ってるってほどではないのでは？
と個人的に思ったりするんですが・・。

低レベルAPIより標準APIの方が扱いが難しかったりするんですかね？？

922:nobodyさん
10/02/19 18:41:03
JDO/JPAは使えない機能があったりバグがあったりで落とし穴満載！
悩むのが趣味ならそれもよし

923:nobodyさん
10/02/19 19:11:22
># データの正規化は基本的にはしない → エンド・ユーザーから見て一つの「もの」（たとえば商品、ブログエントリー）があった場合、
>それに付随する情報（たとえば、タイトル、値段、更新日時、作者）をEntityそのもののプロパティとしてもたせておき、Queryなしに
>一回のgetですべて取得できるようにしておく。これは、RDBにおける「ベスト・プラクティス」とは正反対の方向を向いたものなので、
>RDB/SQLに慣れた人こそ気をつけて設計すべきである。
># JOINがない → SQLにおけるJOINをApp Engine上で実現しようとすると、queryの結果をもとに複数のqueryをするというnested query
>をせざるを得ないが、そもそもJOINが必要となるような状況になったことが、データ・モデルの設計がすでにApp Engine向けのものになって
>いない証拠なので、「ああ、JOINが使えたら楽なのに」と嘆く前に、今一度データ・モデルの設計から見直すべき。

GAEについて書かれていることは間違っていないが考え方は間違ってると思う

924:nobodyさん
10/02/19 19:16:50
>>921
漏れはむしろGAEから脱出するときのことを考えて
GAEじゃなくても動くように考えて作っておくのを薦める

925:nobodyさん
10/02/19 19:18:14
>確かに「GAEを使う意味」を考えたら低レベルAPIを直接叩いてGAEのパフォーマンスを
>存分に発揮できるようなアプリを作るべきなのかもしれないですけど、

これこそ Google の囲い込み戦略そのもの

926:nobodyさん
10/02/19 19:24:16
>>924-925
RDBのときもそんなこと言ってたけどさ、結局移行しないか作り直すかだったじゃん？
移植性なんて考えても無駄だよ

927:nobodyさん
10/02/19 20:26:18
素早く移行先の実装を思い付く頭でも養った方がよさそうではあるよな。
今時一つのフレームワークと心中する人も居ないだろうし。

928:nobodyさん
10/02/19 20:42:36
>>924はYAGNIも知らないのか・・・

929:nobodyさん
10/02/19 22:40:30
GAEで簡単にできるものだけ作ればいいじゃん。
単純なサービス作るのはすごい楽よ。

930:nobodyさん
10/02/19 22:58:04 UAHcwqqw
低レベルAPIで移植性考えないで作っても、
ちゃんとGAEでスケールするようになっていれば
乗換先で再構築したシステムもしっかりスケールさせられる
アーキテクチャに自然となっているよね。

データストアの置き換えが無いのが悩みだな。
トランザクションなしでいいならKVSなんでもＯＫだ。
最近話題のクモＦＳとかつかってみるかね。

> ほぼ無料で使えるというだけで大きなアドバンテージ
だったらべつにいいんじゃない？
スケールしないの覚悟でRDB/SQLで使えるソフトもあるし。
それつかってトラブる方が大変そうだけど。

931:nobodyさん
10/02/20 10:13:24
GAEで簡単にできるものだけ作ればいいじゃん。
単純なサービスしか作れないGAE www

932:nobodyさん
10/02/20 11:41:38
単純なアプリ≠単純なサービス
凄いアプリ≠凄いサービス
結局は自分の技量次第

933:nobodyさん
10/02/20 12:10:23
それ言うと技量ってよりアイデアだな
ぶっちゃけGAEはPHP+レンタル鯖マーケットの置き換え需要がメインだと思ってる

934:nobodyさん
10/02/20 12:58:54
実際個人でやるウェブサービスはアイデアと上手い宣伝が殆どだと思うぜ

935:nobodyさん
10/02/21 02:00:41
自分や少数の関係者の為のサービス作るのにも最適。
そんなのの為に自分でサバ用意するなんてバカらしいからね。

936:nobodyさん
10/02/21 11:33:14
URLフェッチのHTTPヘッダ、
AcceptもAccept-CharsetもAccept-Languageもそのままなのに何故Accept-Encodingは削除するんだorz

937:nobodyさん
10/02/21 12:04:54
>>934
加えて実装の速さだろな。

938:nobodyさん
10/02/21 17:42:36
実際、どんなAPI使っててもサービスやデータアクセス層を
綺麗に分割したらそれなりに移植しやすく実装できるもんだ。

課金を最小に抑えて将来の移転も容易にするためには丁寧な設計と実装が大切。
なんでもこれに尽きる。

939:nobodyさん
10/02/21 19:53:26
こまけーことはいーんだよ！っておもいっきりのよさも必要だ。
1時間ぐらいで実装できるようなのだったら移植なんかもフルスクラッチで良いだろうし。

940:nobodyさん
10/02/21 20:34:36
ってか普通コントローラーからはモデルを直接操作する事って無いんじゃね
大体モデルを操作するロジッククラス作るっしょ

941:nobodyさん
10/02/21 23:32:09
余計なレイヤを増やすと課金が増えますｗ

942:nobodyさん
10/02/22 00:01:45
>>940
モデルの移植が一番大変

943:nobodyさん
10/02/23 22:02:05
BigTableに入っているデータをローカルPCにコピーするにはどうすればいいんですか？
・バックアップを取りたい。
・他のサイトにコピーして使いたい。

GAE for Pythonを使い始めましたが、ツールとかAPIとか、これから勉強するので、分かりません＞＜

944:nobodyさん
10/02/23 22:04:13
あと、GAEで作ったWebアプリを自社サーバでも動かしたい場合、どうやって移植すればいいでしょうか？
BigTableの代わりにHadoopを使えば、自社サーバでもGAEと同じプログラムを動かして、公開できますか？
GAEに入れたプログラムとデータは全てGoogleに人質に取られている形になってしまうんでしょうか？

945:nobodyさん
10/02/23 22:28:19
馬鹿は何をしても無理
諦めろ

946:nobodyさん
10/02/24 00:10:26
移植したいなら移植出来るような設計にしなきゃ。(そんな人がなんでGAE?って思うけど)
よくわからんのならEC2使えば？

947:nobodyさん
10/02/24 00:46:34
>>943
BigTableの中身コピーはフォーラムかどっかでSQLite形式にして落としてくれるスクリプト書いてた人がいたから、それ使うのが手っ取り早いかも。

948:nobodyさん
10/02/24 01:24:27
自社サーバーでの運用も視野に入れるなら946の言うようにAmazonEC2のWindows上で稼動するか
Windowsの資産が使えるとの触れ込みのWindows Azureの方が向いているんじゃね
少なくとも943がGAEを使うメリットが微塵も感じられん

949:nobodyさん
10/02/24 03:36:40
>>943
取り出すのは少しずつ取ってくるプログラム書けばいいよ
ReferenceProperty がめちゃくちゃにならないように気を付けようねw

950:nobodyさん
10/02/24 03:41:47
>>943

>>461
>>479
>>775
>>781
>>783
>>792
>>793
>>795

951:nobodyさん
10/02/24 04:41:19 X/o33lUL
↓作者乙

952:nobodyさん
10/02/24 05:33:37
│　 ↑
└─┘
おらっしゃあぁぁ！！！
　∩∧ ∧
　ヽ（ﾟДﾟ）
　　　＼⊂＼
　　　Ｏ-､　）～
　　　　　　∪

953:nobodyさん
10/02/24 13:24:25
>>947 >>949 なるほど。BigTableからデータを外部にエクスポートするには、自分で仕組みを用意しなくちゃいけないんですね。
URLﾘﾝｸ(www.usinezumi.com)
↑BigTableのデータをインポートしたり、エクスポートする機能の用意は、公式対応してないみたいですね？

954:nobodyさん
10/02/24 13:38:09
>>946 >>948
EC2の方が自由度が高いけど、ユーザーを詰め込み過ぎらしいので様子見。
URLﾘﾝｸ(news.livedoor.com)

オンプレミスとクラウドのシステムを同じ構造にしておきたい。

＝自社サーバでさばききれないアクセスを、GAEに受け持たせるかんじ。
＝最初からGAEと同じアーキテクチャーでシステム開発しておけば、スケールアップさせるときに容易にGAEに移せる。
＝必要なくなったら、GAEから自社サーバに戻せるようにする。

イメージとしては、GAEとローカルで常に同期が取れてるかんじのシステムです。
URLﾘﾝｸ(d.hatena.ne.jp)
↑この人みたいな使い方

あとは、NoSQLなデータストアの使い方を練習したいため、あえてGAEでｗ

955:nobodyさん
10/02/24 13:50:39
>>950
素晴らしい書籍のご紹介、どうもありがとうございます。
URLﾘﾝｸ(www.amazon.co.jp)

この前、本屋に行ったときGAE関係の本を立ち読みしまして、この本も読みました。
GAEでKay Frameworkを使う機会があれば、図書館で借りてみようと思います。

まずはオーソドックスに、素のPythonで作ってみて、
URLﾘﾝｸ(satoshi.blogs.com)
フレームワークを使うならGAE標準装備のDjangoを利用してみようかなと思います。
URLﾘﾝｸ(www.metareal.org)

956:nobodyさん
10/02/24 15:22:45
>>953
>↑BigTableのデータをインポートしたり、エクスポートする機能の用意は、公式対応してないみたいですね？

ReferenceProperty がめちゃくちゃになるからね

957:nobodyさん
10/02/24 15:31:50
>>955
GAEのdjango実装には期待しない方がいいよ

958:nobodyさん
10/02/24 18:52:31
Django使うならURLﾘﾝｸ(code.google.com)

959:nobodyさん
10/02/24 18:56:15
Google で EC2 みたいなサービスしてくれんかなぁ。

960:nobodyさん
10/02/24 21:27:35
Kayって誰か使ってるの？

961:nobodyさん
10/02/24 22:14:32
>>956
今は大丈夫ですよ

962:nobodyさん
10/02/24 22:15:32
>>958
今からだとこっちの方が良さそうですね
URLﾘﾝｸ(www.allbuttonspressed.com)

963:nobodyさん
10/02/24 22:16:14
>>960
多く見積もって数十人くらいですかね

964:nobodyさん
10/02/24 23:15:41
webapp + Genshi で満足。

965:nobodyさん
10/02/25 00:26:25
>>955
URLﾘﾝｸ(www.amazon.co.jp)

レビューが当たりすぎてる。

966:nobodyさん
10/02/25 00:31:59
>>963
少なく見積もると一人くらいですか？

967:nobodyさん
10/02/25 00:38:29
俺と作者の二人だけかな