  |
はてなキーワード: Google App Engineとは
もうすぐ年末年始休暇も折り返しに差し掛かるので軽く振り返ってみる。
作っていたウェブアプリをJavascriptからTypeScriptに移行した。
自分はこのウェブアプリに関して『自分の死んだ後も変わらず動作し続け、後世の奇特な人が気が向いたらメンテ出来る』ことを目指しているので、できるだけフレームワークなどは利用せずpureなJavascriptで実装していた。最初はjqueryを使っていたが廃止し、bootstrapも使っていたが廃止し、Vue.jsで作り直したものも本番投入せず廃棄した。他のウェブアプリで新しい技術を試すことはあっても、このウェブアプリだけは徹底的に保守的なスタンスを貫いてきた。でもここ数年の流れから言って、TypeScriptなら将来的にも大丈夫かな、と思えて来たので、満を持してのTypeScript化。
イベントの実行順序などで多少苦戦したものの、それ以外は大きな問題もなくTypescriptで再構築することができた。
あーやっぱり型があると良いね。画面制御と描画処理が今まで１つのモジュールでやっててそれを何とか解消したかったんだけど、型が入ることでそのリファクタリングを安全に行うことができた。描画周りが分離できたんで、そこだけvueなりreactなりに再挑戦するのもアリかもしれない。どっぷりフレームワークに浸かるのは避けたいけど、部分導入だけなら後で捨てるのも容易になる。捨てるのが簡単ならちょっとくらい試しても良いかもしれない。
Google App Engineで動作している自分のサイトをPythonからGoに移行した。
サーバーサイドではほとんど何もやっていないので別にPythonで不便はなかったんだけど、インスタンスの起動がGoの方が早いらしいので、Goに移行することにした。起動が早ければ待機させるインスタンスの数を抑えられるので、費用の低減を図れる。Goで作り直すと言ってもほとんどが静的なhtml。手作りbootstrapからhugoに移行して、サーバーじゃないとできない最低限の処理をGoで書き直し。素人感丸出しのサイトが、hugoのテーマのお陰でそれなりに見栄えのするものになった。
■07.Google App Engineのデータストアを自動バックアップする方法
http://b.hatena.ne.jp/entry?mode=more&url=http%3A%2F%2Fameblo.jp%2Fcabeat-e%2Fentry-11409296253.html
http://uploda.cc/img/img50ac4df841c95.png
■デザインの配色に悩んだ時に見るアプリ【Saturation】
http://b.hatena.ne.jp/entry?mode=more&url=http%3A%2F%2Fameblo.jp%2Fcabeat-d%2Fentry-11406461389.html
無事1周年を迎えました。本当にありがとうございます！
投げ売り堂の増田への2012年1月の結果と雑感を書き込みます。
| 項目名 | 2月 | 1月 | 増減 |
|---|---|---|---|
| ユニークユーザー | 4854 | 5105 | 251 |
| ページビュー | 34212 | 33168 | -1044 |
| 平均ページビュー | 1.66 | 1.57 | -0.09 |
| 平均滞在時間 | 1:54 | 2:15 | +0:21 |
| 新規訪問数 | 15.87% | 13.94% | -1.93％ |
詳細はいつものように以下の Analytics の PDF に書いてあります。
そして、2011/03/01～2012/02/28 の1年間のデータを置いています。
投げ売り堂の 2011/03/01～2012/02/28 の Analytics PDF
2011/03/01から投げ売り堂を公開し、1年が経ちました。
途中、Amazon API の仕様変更だったり Google App Engine の課金開始だったり
いろいろな事がありましたが、無事乗り切ることが出来ました。
運用状況ですが、Google App Engine の課金は月1500円前後で落ち着いています。
このアクセス数だと恐らく980円のさくら VPS 等を使っても全く問題ない感じだとは思うのですが
長期間ストップするような障害も無かったですし、運用ｺｽﾄもほぼ無い感じなのでこれからも使っていきます。
後は、1年間月初めにこちらに増田に投下してた月次報告をブログとかに纏めないとなぁ・・・と思ってます。
同時にいつも Twitter で昼に流している商品情報を纏めて、日々更新していくような形をとればアクセス数は増えるのかなぁとか、ぼんやりとその辺は考えています。
毎日ブログは性格的には無理そうな気がしているので、一先ず自動で纏める形を取らないと・・・。
今年始まってふがいない事になっていますが、地味に昨日更新をしていたり徐々に更新をしています。
これから先の大きな更新としてはログイン機能とそれに付随しての該当商品が一定値を超えた場合にメール通知機能をするなど考えています。
投げ売り堂で行っているGoogle App Engine の新料金体系 の対応についてのその2です。
Cron 処理を Backends の無料枠で対応できそうだったので、無料分で収まるように Cron で行っている処理を Backends でやるようにしました。
その結果、日額0.1～0.2ドルで月間で3～6ドル程度になりました。
なんとか、1000円以内に抑える事が出来、このままだとなんとか大きな課金になる事無く対応は出来そうです。
これに加え、新課金体系への移行についてに書いてあるとおり
新料金体系の適応が11/1 になったので、落ち着いて作業を行えるようになったのですが
現時点においてギリギリでやってる為、 Google App Engine のままだとなかなか拡張もやりにくい事もあります。
ですので、やはり通常のサーバーでも動かせるように移植のほうも進めます。
Java 以外で使い慣れている PHP を使って同じシステムを作成しようと思います。
全ての商品を1時間に1回商品情報の更新や、フィギュア・DVD・BD・ゲーム以外の商品情報も集めるようにし
Cookie で表示商品の種類のカスタマイズ等などを組み込もうかなと思います。
投げ売り堂も Google App Engine をしようしてますが、9月から慌しくなっている Google App Engine の新料金体系 に対しての対応について。
ほぼApp Engine アプリケーションのリソースを管理する方法を参考に作業を進めています。
一先ず、まだ Background の無料枠で対応できそう？なので回せる分はそちらに回したり
先ほどのリンクでも対応できていない部分があるので、まだ対応の余地はあります。
しかし、やはりこのアプリ一つのために 2000～3000円くらいとられるのは、うーん・・・という感じはします。
自分くらいのアクセスだと、スケーラビリティは全く考慮しなくてもまだまだ大丈夫なので
さくらVPS を借りて、そちらの方で動かせるように移植を行っていこうと思います。
小学生の時は家庭環境最悪で自宅に固定電話でさえなかった。中学生～高校生の時は生活で手一杯、高卒で地元でて生活で手一杯、ずっと携帯持つ余裕なし。
今は定職にもついて生活には困らない程度になってるけど、物心ついてから携帯のある生活を一度もしていないので、必要性を感じず、持たないまま今に至ってしまった。
PC でのネットはかなり使っている。けど最近 Google のサービスを登録するのに携帯の番号がいるので、使えなくて困ってる。Twitter などで知り合う人はなぜかプログラマやギーク系が多くて携帯どころかスマートフォン当然のように持っててすげー使いこなしてそうで、｢実は携帯もったことないんです (当然スマートフォンも)｣なんて言ったら｢え？あなた人間なの？｣と思われそうで面倒で言ってない。
Google App Engine 使うためだけに携帯手に入れるってのもバカバカしいし、はぁー
http://anond.hatelabo.jp/20110731225757
爽やかで頼れる職場の先輩のWebサイトを、同僚たちと訪問する事になった。
そうしたらその先輩が、ちょっと照れたように、でも爽やかに
「ちょっとサーバーサイド・スクリプトとかがいっぱいあるけど許してね」と笑う。
同僚たちとワイワイ問い詰めてみたら、『CakePHP』のフレームワークだそうだ。
先輩曰く「奥さんと二人で、一昨年くらいからハマっちゃって」らしい。
うっかり「Google App Engine ですか」とか言わなくて良かった。
何よりも、スクリプトを普通に実装して普通にその事を話せる点が、大違いです。
もちろん、同僚たちの誰も引いたりしない。
一口にスクリプト言語が好きって言っても、何かもう色々根本的に違う。
適わねーなー、と思いました。
そんだけ。
この記事をみて、非常に耳が痛くなった。
あまり前例がない Google App Engine + Amazon API で Web サービスを作ってみたり
その Web サービスのツイッターのアカウントで商品情報を呟く Botを作ってみたり、色々それ以外にもやってても
ちゃんとそれを表に出す宣伝を行う努力をしないとどうしようもないんですよね。
別に誰々に勝つとかそういうのを持って無くても、そういう努力をしないと地に這い蹲るんだろうなーと実感しました。
ということで細々と宣伝を。
投げ売り堂 http://www.nageuridou.com
Amazon で売っている割引率が高いフィギュアの販売情報を、自動ページ読み込みで流し見る事ができる Web サービスです。
Amazon 商品を紹介するサイトによくある要らないコンテンツは何も付けてないです。商品見るだけのサイトです。
ツイッターアカウントの @nageuridou (http://twitter.com/nageuridou) で30分に1回商品情報を呟きます。
http://anond.hatelabo.jp/20100725025127
"どうすればいいか"を教わって、プログラミングが身につく人は多くありません。"なにをやりたいのか"を自分で生み出せないと、詰まってしまうし、なにより楽しくありません。
やりたいことがあれば手段は後からついてきます。これは物作り全般に言えることです。特に学び始めにおいてモチベーションを維持し勢いをつけるのに大事なのは"やりたいことがあるか"、もっと具体的に言うなら"作りたいものは何か"です。これがないと始まりません。それがどうしてもないなら、そういう状況に自分を追い込むのも有効です。仕事でどうしてもやり遂げなければならない状況に追い込まれれば人間 0 からでも身につきます。実際自分がそうでした。
とかく、プログラミングというのは手段さえ知れば、あとはだれがやっても同じ結果が出る生産業だと誤解されがちです。そういう認識で学ぼうとしても楽しくありませんし、本質を掴みにくいので応用が利かなく上達しにくいです。
本質は絵や音楽と同じです。言語を覚えるということは道具の使い方を覚えることでしかありません。音楽の理論や絵筆の使い方を知っているだけで、すぐに素晴らしい音楽や絵ができるでしょうか。殆どの人がそうは思わないはずです。プログラミングもそれと同じです。作りたいものがある人が圧倒的に強いのです。
んー、ここまで読んでも｢やりたいことはないけどとりあえず勉強したい｣というなら、すぐに動くものをつくりやすい言語がお勧めかなあ。
Google App Engine で Python をやるとか。 Python のいいところは、明快で作法にあまり迷わなくていいところです。自分がまったく言語やったことない知り合いにすすめるとしたらこれ。
レガシーではないちゃんとした JavaScript (http://www.crockford.com/javascript/ この辺にあるような) もいいです。ブラウザですぐ動きますし、 Firefox 環境なら本格的なデバッガまであります。 JavaScript は非常に誤解の多い言語ですが、悪いものではありません。 お手軽にグラフィカルなものを扱える、結果がわかりやすいので初心者向けです。それでいて、拡張性が高く、プログラミングに必要な概念、ロジックの殆ど再現できる底力も秘めています。
Perl はレガシーな作法がいまだに見受けられる (Perl って CGI のことでしょ的な解説が未だにある) のですが、初めから strict に慣れて、 CPAN にあるようなスタイルを参考にして、初めから OOP に突っ走るなら今からやってもいい言語です。 CPAN 等のリソースの豊富さとコミュニティの広さが強いです。ただ、懐の広さ、できることの多さゆえに初心者向きではないところもあります。
PHP はお勧めしません。理由は適当に検索してください。 PHP5 でかなり良くなりましたが、逆に言えば 4 と 5 では別言語と言っても良いほどです。古い考え方と新しいスタイルがごったになりすぎていて、かつて同じような状況にあった Perl に比べても、洗練されたスタイルを学びにくいと思います。また、ロジックの面白さに感動するような部分が PHP にはちょっと足りないです。
MMORPG やそのエミュレーターの中には、 Lua を使って AI やマクロやイベントスクリプトなどを組めるものがあります。すぐに結果が出て自分の役に立つものが作れるので、既にその手のゲームが趣味ならお勧めです。こうした用途では、自分の望む世界を構築するために嫌でも物事をモデル化して考えるので、自然と OOP 的な考え方やデザインパターンが身につきます。
VB は簡単に GUI アプリケーションが作れるのでやる人が多いですが、癖が強いし応用がききにくいのでお勧めしません。また、公開されているソースコードが少ないことも学ぶには不便です。
Ruby はそれほどやりこんでないのでコメントはしないでおきますが、悪くはないと思います。
C++ は何をすればいいのか？を聞いてる人にはすすめにくいです。作りたいものが明確にあり、ロジックを見つけることで応用が利く人ならほっといても覚えるでしょう。自分は、必要に迫られて身につきましたが・・・
個人的には、作りたいものがあってそれにマッチしてるなら、関数型言語を最初にやったっていいと思います。一度ロジックを掴み取る能力がついてしまえば、第二第三の言語は猛スピードで身につくので。
作ったものを公開して、人に見せたり使わせたりして、レスポンスを得るというのはモチベーションの維持や上達に非常に有効です。むしろ、早く上達したいなら必須と言ってもよいです。プログラミングの場合はこれがおざなりにされがちです。
絵を上達したいなら、 pixiv を薦められますよね。今下手かどうかは関係ない。上手くなりたい人が沢山投稿してる。歌が上手くなりたいなら、人前で歌う事は避けられない。ニコニコ動画などで公開してる人がいるよね。人の作品をみると刺激をうける。これはすごいパワーだってのはわかると思う。
プログラミングだって全く同じです。なのに、プログラミングは引きこもって一人で勉強する人が多すぎる。絵や歌は公開しても人に害を与えないけど、プログラミングはバグやセキュリティホールがあったら人に害をあたえるかもしれない、といった印象が強いのかもしれません。
それでも、もっとコミュニティに参加したり、作ったものを公開することが学び始めのうちから重視されていいのは事実。そういった面から考えると、バグやセキュリティホールが出来にくく、安全で、危険な動作がしようもない実行環境があり、加えて Web に公開しやすい言語が学びはじめに向いています。
こちらも参考にしてみて下さい
http://d.hatena.ne.jp/Hamachiya2/20090721
http://d.hatena.ne.jp/Hamachiya2/20080131
学校に行けば一人で学ぶよりは後押しや出会いがあるかもしれませんが、”やりたいこと””必用なこと””作りたいもの”が無い限り、殆どの人は身につきません。
また、残念なことに講師にも大変当たり外れが多いです。自分は専門学校にいったことはありませんが、講師の知り合いがいるのでよく学生さんの話を聞きます。結局の所、しっかり身につく人は、家に帰っても色々作りたいものを作って公開したり、著名なプログラマ達のブログを読みまくったり、フォーラムに出入りしたり、ML に入ってたり、 twitter で刺激的な知り合いをつくるとかしていて、そういうところでめっちゃ差がつきます。
学校に行くなとまでは言いませんが、学校いかないで身に付ける人は本当に多いし、学校いって身につかない人も本当に多いということは考えて下さい。
元増田さんがどの言語をやれば・・という方だったので仕方なくこのような書き方になってしまいましたが、作りたいものが既にある人はあまり”どの言語をやるか”には拘らなくてよいと思います。
そんなことよりも、今必用で/気軽に/すぐ結果がわかることをやるのが、始めてのプログラミングには大事。だから本当は、どの言語をやるかよりも何を作りたいのかを先に見つけてほしい。
目の前の意外なところにプログラミングは生かせます。できるだけ身近な、すぐ効果がわかるところからとりかかった方がプログラミングの楽しさにはやく気付けるはず。
みたいな導入口でもいいんだ。
例えば C++ でのプログラミングを初心者が 0 からやるのは難しいだろうけど、既存のアプリケーションのプラグインなら開発のためのテンプレートや目的に近い作例があってコードも短いからそれを改造するところから始められる。需要があるから楽しいよ。
google app engineって、落ちないって保証していたっけ？使った分だけ払えという契約だけど、時間売りとは違うし？ジョブ売りでしょ？落ちていても何かを請求する権利が無いのでは？
それに、googleだし・・・googleは最新・高速だけど、良く落ちてるってのは、一般常識ちがうんかね？ というか本気でgoogleは不安定ではあるよ？
google app engineに繋がらない。
signinすら出来ない。
googleにメールを送っても返事が無い。金曜の夜から24時間ぶっとおしで、もう30通は送ったはずだ。仕事してんのか？
ハードが目の前にありさえすれば、なんとかやりくりできるのによ。最期の時には、全部俺様の過ちだと納得もできようよ。しかしクラウドはどうだ。何だこのざまは！何もかもが雲の中だ！誰が何を間違ったのかさっぱり分からない！俺様の目の前でバックアップをとっていないHitachiのHDDがガチャンと音を立ててクラッシュしてくれる方がまだマシだ！！！！！
くそくそくそくそくそくそくそｊそうｋすおｌ￥くｄさくｌｄｆｇgoogleappengineの た め だ け に 携帯を買ったんだぞ畜生！！！！！金返せ！！！！！１もうだめだ！！！！！クラウドはクソだ！！！クソの山だ！！！！！こんなものを良い方向に評価できなくたって、俺様は天才プログラマなんだよ！！！！！！！！ああああああああおｈんｗｚそえｆどい：＠－２ｓ；
今後！！！！！俺え様の目の前でクラウドとうう言葉を使った奴はぶん殴る！！！いいな！！！！！！！！えろいｓｄｆｇｚｊｌｋ；あｄ
まあpythonはgoogle公認だから本質的にウンコ程度の価値しかないから俺様はこいつとおさらばできてせいせいする。javaはまともだから、本腰を入れて何か作ってみるか。しかしやはり俺様に合っているのはネイティブコードを吐くコンパイラの揃っている言語、C++やDだ。何でもできる。OSをぶっ壊すことすらできる。OSは一度壊してからが美味い。googleappengineとは全く対照的だ。googleappをいくらグズグズとファックしようとしても、所詮はpyだ。せいぜい砂場の上でウンコするだけだ。他には何もできやしない。gccは無いのかとまさぐろうとしたが、さっぱりまさぐれない。ISPのCGI鯖ならこっそりgcc使える所もあったのに。そういう点でもgoogleはウンコだ。ユーザーの要望をまったく理解していない。googleappengiんで動いてる有名なサービスってあったっけ？ｗｗどれもこれもただのチンポコだろtukau使う価値もないｗしかし携帯もかってみたけどクソだなemacsもうごかないマシンもちあるいてみんな楽しいか？こんなちいいさい画面でこーど書きたいのか？こんなのただのうんこじゃんｗｗｗほりえもんもiphonにむちゅうらしいけどていどがしれるなｗｗうんこしながらめーるかけるからべんりｗｗｗうんこうんこｗｗ
！という、コンパイルできなくても
！あん
昨年来、日本のＩＴ業界ではクラウド・コンピューティングがブームになっている。最近は短縮して単に「クラウド」と呼ばれることも多いようだ。そして、この業界ではよくあることだが、クラウド・コンピューティングについて、コンセンサスのとれた定義はない。
しかしそれでは議論が進まないので、まずはマッキンゼーが発表した"Clearing the air on cloud computing"という資料におけるクラウドの定義を引用するところから始めよう。大企業でのクラウド利用に懐疑的な見方を示したことで、話題になったリポートだ。
これによれば、クラウドとは「以下の条件を満たす、情報処理（コンピューティング）、ネットワーク、記憶装置（ストレージ）を提供するハードウエアベースのサービス」である。
1. 利用者にとって、ハードウエアの取り扱い（管理）が、高度に抽象化されている
3. インフラに、非常に柔軟性がある（スケーラビリティーがある）
クラウドと聞いて誰もが思い浮かべるのは、アマゾンが行っている、ネット経由でコンピューティング機能を提供する「ＥＣ２」や、同じくストレージを提供する「Ｓ３」といったサービス、あるいはウェブアプリケーション開発キットを提供する「Google App Engine」などだ。これらは上記の定義を満たしている。ユーザーは簡単に仮想サーバーや仮想ストレージをインターネット上に持つことができ、そのコストは使用量に応じて課金されるのが普通で、企業会計の中では経費として処理される。また、スケーラビリティーがあるので必要に応じてリソースを増やすことも減らすことも簡単かつスピーディーにできる。
クラウドがこれだけ話題になるのは、やはり多様な効用があるからだ。
まず、使いたい時にすぐに利用できる。ハードウエアやソフトウエアの調達は必要ない。ネットワークへの接続や各種環境設定などの作業も不要である。試験的なシステム構築も容易で、使えないと分かればすぐに止めることも可能。費用は、コンピューティング機能やストレージなどのリソースを使った量に応じて課金され、会計上は経費として処理でき、バランスシート上の資産が増えることがない。スケーラビリティーも高い。そもそもインターネットの“あちら側”にあるため、関係者でデータなどを共有することも容易である。
さらに、運用業務から解放される。内部統制やコンプライアンス（法令順守）強化の流れを考えると、利用するサービスが十分信頼できるものであれば、これはメリットが大きい。
特に中小、中堅企業にとっては、クラウドの持つ機能や信頼性、情報セキュリティーレベルは自社システムより優れていることが多い。信頼性や情報セキュリティーに対するユーザーの懸念は、クラウド普及の障害になると考える人が多いようだが、実際には追い風になるだろう。
こうしてクラウドの効用を並べてみると、企業規模が小さい企業ほどメリットが大きいことがわかる。そこで登場するのが、「プライベート・クラウド」である。
プライベート・クラウドとは、ＥＣ２やGoogle App Engineのような「パブリック・クラウド」とは異なり、一つの企業や組織の中に閉じたクラウドである。従って、そのコストはすべてその企業や組織が支払うことになる。
たとえば、米国防総省の国防情報システム局（DISA）が保有する「RACE (Rapid Access Computing Environment)」は、国防総省内部向けのクラウドであり、関係者以外は利用できない。実際に構築したのはヒューレット・パッカードであるが、その構築費用も国防総省が負担している。
したがってプライベート・クラウドは、最初に挙げたクラウドの定義のすべてを満たさない。つまり、条件の１と３（バーチャルなサーバーを簡単に構築でき、その規模を自由に変更できること）は満たすのだが、２の条件（コストを経費として支払うこと）を満たさない。
最初に挙げたクラウドの定義を正しいとするならば、プライベート・クラウドはクラウドではないことになる。
当然、クラウドのメリットであるはずの「使えないと分かればすぐに止めることも可能」「費用はリソースを使った量に応じて課金」「会計上は経費として処理でき、バランスシート上の資産が増えることがない」「リソースを増強することも縮小することも簡単にできる」というわけにはいかない。
もちろん、その組織内の個人や一部局は、クラウドの持ついくつかのメリットは享受できる。使いたいときにすぐに使うことができるだろうし、スケーラビリティーも高い。しかし、組織全体で見た場合にはクラウドのメリットの多くの部分は消滅する。
そう考えると、プライベート・クラウドは、仮想化技術を利用したサーバー統合だと考えた方がよいのではないだろうか。
さて、2009年度の補正予算には、電子行政クラウドの推進という項目がある。この中に、霞が関クラウドと自治体クラウドの構築が含まれている。これはそれぞれ、政府のプライベート・クラウド、地方自治体のプライベート・クラウドである。
当然のことながら、パブリック・クラウドのように「使えないと分かればすぐ止めること」はできないし、「費用は使った分だけ支払う」わけにもいかない（自治体クラウドについては、各自治体に利用量に応じて課金する方法も考えられるが、利用率が低い場合には、徴収できる利用料が運用コストを下回ることになってしまう）。
ただ電子行政クラウドにもメリットがないわけではない。分散されたサーバーを統合すれば、コンピューターリソースの利用効率を高めることが可能になるし、運用コストを削減できるだろう。また、自治体クラウドを利用して市町村や都道府県の業務システムをSaaS（ネット経由でソフトウエアを提供）化できれば、大幅なコスト削減も可能になる。
「うちの自治体は隣の自治体と業務のやり方が違うので同じシステムでは処理できない」という話を地方自治体の関係者から聞くことが多いが、優れたSaaSはそれぞれの組織や業務プロセスに合わせてデータの構成はもちろん、ワークフロー、業務プロセスをカスタマイズできる。そうした仕組みを取り入れた自治体向けSaaSを開発すれば、間違いなく自治体の情報処理コストは大幅に削減できる。
問題は、それを実現できるかにある。中央官庁のサーバー統合にしても、自治体向けSaaSにしても、机上の計算では、投資に見合う十分なコスト削減効果をはじき出すことはできるだろう。しかし、一歩誤れば稼働率が上がらず、税金の無駄遣いだと非難されることにもなりかねない。
そこで提案なのだが、電子行政クラウド構築のリスクを民間企業に委ねてはどうだろう。政府が構築するのではなく、民間企業が霞が関クラウドや自治体クラウドを構築し、各府省、自治体にサービスを提供する。もちろん、利用者である各府省や自治体からは利用量に応じた料金を徴収する。当初の構築費用については補正予算を使ってもよいが、数年間で国庫に返納してもらう仕組みにする。
利用料金は、ある一定の利用率で採算が取れるように設定する。つまり、利用率が予定以上になればその民間企業は大きな利益を得ることになるが、そうでないと損失を被ってしまう。
つまり、政府や自治体のプライベート・クラウドにするのではなく、政府や自治体をユーザーとするパブリック・クラウドにするという発想である。こういう仕組みにすれば、構築を担当する企業は知恵を絞り、多くのユーザーを獲得しようと使い勝手のよい電子行政クラウドを構築するのではないだろうか。
このコラムは日経デジタルコアによって企画・編集されています。
ご意見・問い合わせは同事務局あてにお願いします。
相手が勝ち誇ったとき、そいつはすでに敗北している
何が違うのか解った気がする（菊池 Blog）
今どき言語論争なんて愉快なことをやってるのがアンテナに引っかかったのでヲチしてたんだけども、勝利宣言キタコレ。
さて。
ネットバトル(藁)の勝敗は傍観者の評価によって定まるとしても、「傍観者の評価」は俺一人の評価と同値ではなく、むしろ多数が形成する「空気」だから、俺が「このバトルは◯◯の勝ちだ」と宣言したところで月桂冠には成り得ないわけだけども、「空気」の一要素として、高らかに宣言しておく。
このバトルは菊池氏の負けだ。
菊池氏の主張というのは結局、「日頃から良い設計でコードを書いていればコードの再利用も容易なはずだ」という「Javaプログラマかくあるべし」論だ。
だから菊池氏は自分の勝利を確信しているだろう。「低能プログラマを叩きのめしたぜ万歳！」
ところが、このネットバトルの勝利条件は「どちらが優れたプログラマか」では無い。もともと他言語との比較でJavaのメリットが問われているから、Javaプログラマを叩きのめしても意味がない。
そこで「優れた設計に基づく既存のコードを簡単に再利用できるのがJavaのメリットだ」と答えても、「その優れた設計に基づく既存のコードというのはどこにあるんですか？」と訊かれる。（ここでの「優れた設計」は、RDBMSがbigtableになりGAEのSandBoxの縛りがあっても容易に移植できる設計でなければならない。）
さて、この問いに胸を張って「いくらでもある」と答えられるJavaプログラマがどれほどいるのだろうか？百歩譲って自身が優れた設計に基づくコードしか書いてこなかったとして、Java界全体を代表して発言してもなお結論が変わらないと言えるだろうか？
つまり、他言語使いに問われた時に「俺の書いたものに限らず、Javaの既存コードはたいてい再利用できる」と言えるだろうか？
答えは否だ。嘆かわしかろうが何だろうが、否だ。
さて、このネットバトルの勝利条件は何であろうか。
それは、「GAEでJavaを使うメリットをより的確に表現する事」だ。
id:higayasuo氏の答えは大要「慣れた言語で書ける事」だ。格好良くはないが、現実的な答えだ。
菊池氏の答えが全く説得力がない以上、id:higayasuo氏の答えの説得力が弱く反論が容易であったとしても、1ピコグラムでも説得力を有する以上は、天秤はid:higayasuo氏に傾くのだ。
これは、JavaとPythonの勝敗とは関係のない世界の話。
あまちゃんのをスルーしてたけど
Google App Engineの方がいろいろ面白いことが出来ると思うけど。
これ、GAE関係ないやん。OpenSocialやん。って、OpenSocialよくしらんけど。
あれって、何処まで出来るの？増田の記事を扱えたりする？
ま、JSONPとかYQLとか使ってがんばれば増田リーダーも不可能ではない気がするけど。
とりあえずmixi使ってない身としては、なーんにも思いつきません。
つい最近Google App Engine Oilに処女を捧げたばかりの増田ですが。
ドキュメントの量？
そんなもんネーよ。App Engine自体、pythonのドキュメントに比べたらヘみたいな物だよ。ドキュメントよりコードだよコード。
HTMLがピロ？
それで十分じゃネーか。パラメータだ？クッキーだ？セッションだ？そんな物に構ってられるか。
対応してる奴使え。対応してなきゃ捨ててしまえ。
知るか。SQLなんか捨てちまえ。そんな高尚な物なんて必要ねー。
業務？
そんなもん使えるかボケ。
ってのはおいといて。
結局、定型処理の標準化なんで、設計もフレームワークに合わせて標準化するなら有用でしょう。
Cでやってたのをjavaで標準化したような物。
Google App Engineに数千エントリ食わせたら重くなってしまった。
絞込みとかが出来ないでいる。つか、どんなデータ構造にしたら良いかわからない。
その辺がさっぱりだ。
ま、そんなことは置いて置いて。
とかが、過去にはあった。といっておく。
芸術性って・・・。
だったら言語から作れよ。
芸術性は見る人に訴求するものがあり、人によって解釈が違う。そういう定義の言葉だろ。
素敵すぎるだろそんなソース。
芸術をも感じさせるソースを見て、どうやったらこんな独自進化を遂げられるんだよと何度ヒザをついたことか…。
人を満足させるために作るのか、自分が満足するためにつくるのか。
自分を満足させるために作り出したものが結果的に人を満足させるということは殆どない。
だって最初のスタート方向が違うんだもの。
コーディングにポリシーはもっていてもいいとおもうけど、そのポリシーがアクションの枷になっているのだったら本末転倒だとおもうな。
どんな立派な機能があるクラスだろうが最初で弾かれて落ちてこないだったら意味ないじゃーん。
というかApp Engineってなに？
つかって何かやりたいとまだ思えてこない以前にApp Engineがまだ未チェック。
PythonはGMOの証券会社が外部APIを公開したのがPythonだった。うんこだった。
勉強するには至らなかったが、そんな特殊だったという印象はもってないな。
plのcgiがあって、そっからasp,jsp,cfmという時代をえて、
php5,RonR,Pythonとかになってきているわけだが、時代は違えどひとつ覚えておけば学習コストっていう意味は殆どかわらないと思うよ。Oracleを覚えてからSQL-serverにいこうがpostgresqlにいこうがmysqlにいこうが一緒みたいなもの。
後継に位置するものであれば必ず似た機能はある。
むしろiis-ocxとかtomcat-Servletとか、ns-ldapとかそういう周辺が違うのであって、
基本的な部分に収まっているあいだは殆ど一緒じゃない？
今の時代みたいに殆どがApacheごにょごにょしただけで動く時代ならphpもRonRも殆ど変わらないと思うな。
所詮LL。
いまだってデータ処理はDBに任せたり、画面だってjavaなりFlashにまかせるじゃん。
LLがクラスに対応したときはおお！！と思ったし、どんどん進化しているのは感じる。
そんな感じで、どんどん面白いのがでてくればいいとおもう。
言語なんてこだわりもって選らんだところで変遷は激しいよ。
コールドフュージョンがどれだけすばらしいかについてプレゼンしてた坊を思い出すたびに涙を禁じえない。
いい音楽が売れるんじゃない。
話題になる音楽が売れるんだ。
