「クラウド」とはいったい何か ITベンダーは本質を語れ
http://itpro.nikkeibp.co.jp/article/COLUMN/20090701/332996/
面白いところを突いています。
というか、このブログに書きたかったことを先に書かれたというか。
最近、「クラウドコンピューティング、はじめました」的なベンダーが多いですよね。
でも、この分野で先行し、成功しているのはGoogle、Amazon.com、Salesforce.comであり、これらのベンダーは「クラウドコンピューティング、はじめました」ではありません。
あくまで各社が独自に提供するサービスが先に存在し、そのために整備してきたインフラの解放という形態です。
Googleは言わずとしれた検索エンジンやGmailその他。
Amazon.comはECサイト。
Salesforce.comはCRM/SFA。
そういう観点では、Yahoo、mixi、楽天などにはその素養がありますね。
果たして、何を提供するのかが不明なままに「クラウドコンピューティング、はじめました」のベンダー(FとかHとかIとかUとかSとか)がうまくいくのでしょうか?
ここに先鞭を付けるのはMicrosoftでしょうか?
「クラウドコンピューティング、はじめました」がうまくいったら、クラウドコンピューティングの時代は新しいフェーズに入るのかもしれません。
July 6, 2009
クラウドコンピューティング、はじめました
post:
liebejudith
at:
00:44
0
コメント
labels: Amazon.com, Cloud Computing, Force.com, Google, Google App Engine, IBM, Microsoft, mixi, PaaS, SaaS, Salesforce, Sun, Web2.0, Yahoo
July 1, 2009
Force.com Free Edition
先月から、US限定で提供が始まっています。
Force.com Platformのの無料版です。
なんと、Force.com Platformの(ほぼ)全機能が、100ユーザ・ディスク容量1GBまで無料で使えます!
Apex/Visualforceも、Web Services APIも、Force.com Sitesも無料で使えます!!
開発サンドボックス(テスト環境)もついています!!!
Developer Editionは開発・学習・検証用で商用利用はNGでしたが、Free Editionは商用利用もOKです!!!!
サインアップ時は英語ですが、Salesforceはもともと多言語対応なので
設定を変えればで全く問題なく日本語化できます。
少し前まではApexコードを作成できなかったのですが、久しぶりにログインしたら作成できるようになっていました。不具合だったのか、サービス内容が変更になったのかは不明ですが・・・
ともかく、これでかなりのことができるようになりました。
注意点は、日本では公式提供されていないということです。
つまり・・・
- どんな簡単な問い合わせでも機能・利用方法・不具合などのサポートを日本法人からは受けられない
- 規定のユーザ数や規定のディスク容量を超えて利用したい場合に有償版へアップグレードしたくても、日本法人とアップグレード契約できない(日本国内ユーザーがUS法人と契約できるかどうかもワカラナイ)
それでも、自己責任で自分でなんとかできる人には朗報ですね。
Google App Engineなどよりもはるかに高機能・パワフル・高開発効率なPaaSを体験してみてはいかがでしょうか?
サインアップはこちら
https://www.salesforce.com/form/signup/freeforce-platform.jsp?d=70130000000EoAM
post:
liebejudith
at:
21:11
0
コメント
labels: Force.com, Google App Engine, PaaS, Salesforce
June 10, 2009
Google Developer Day 2009へ行ってきました。
Google Developer Day 2009へ行ってきました。
午前中はミーティングが入っていたため、午後からの参加でした。
残念ながら基調講演は聴けず。
HTML5やGoogle Waveの話があったようです。
聴いたセッションは・・・
Google App Engine
- Life of Google App Engine Request -
スピーカーはGoogleのフレッド・ソオー氏。
主にGAEのDatasotre周りの実装テクニックの話でした。
Entityに関連Entityのキーとなる値であるStringのList Propertyを持たせる話とか
Merge Joinのテクニックとか。
私はハッキリ知らないのですが、恐らくLazy Loadingができないため
このようなテクニックが存在するのでは?と思いました。
Joinの話は、Salesforce.comのForce.comも同様なのでよく理解できます。
既にGAEをバリバリ触っているような上級者向けのセッションでした。
Java で動かす Google App Engine
スピーカーはGoogleの夷藤 勇人氏、鵜飼 文敏氏。
こちらはGAE/Jの紹介セッションといった内容。
GAEが何を提供するのか?
認証・Datasotre・キャッシュ・Email・URLフェッチ等でどんなAPIを提供し、どんな実装をしているのか?
Sandbox制限(Force.comのガバナ制限のようなもの)、
今後実装予定の機能、
スケールを考えたデータ構造の設計・実装テクニック(これは直前に聞いたセッションと多少被る内容も。)
などのお話しがありました。
表面上のAPI仕様と実装とが分かれているため、API Proxyというアーキテクチャが実現でき、これによりAOP/インターセプターっぽいことができるという話があり、ちょっとうらやましかったです。
Force.comにもAOP的な機能が欲しいです。
RDBではないので、データの非正規化を恐れずに!という話はよくわかります。あまり細々と正規化してクエリが複雑になるよりは、クラウドにおいてはシンプルなクエリ一発で必要なデータを取れるようにデータ設計するべきですね。
GAEのDatastoreは、「ソフトスキーマ」というアーキテクチャを採用しているそうです。これは、スキーマを固定せずにJPAやJDOのアノテーションのみでスキーマを定義するというものだそうで。
推測するに、Force.comのメタデータに近い概念なのではないでしょうか?
わかりやすく言えば、Force.comではDB物理層に直接テーブル定義を生成しているわけではなく、"メタデータ"と呼ばれる「データ構造の定義」をDBに格納し、実データは多数のカラムを持つ単一テーブルに格納するというアーキテクチャです。
GAEのDatastoreは実装にBigtableが使われているので、やはり物理層にテーブルを作成しているわけではありません。アノテーション定義によってアプリケーション側からはテーブルがあるように見えていながら、その裏側で動いている実装では個々のテーブルを作成せずにデータはすべてBigtableという多数のカラムを持つ単一のテーブルに格納している・・・というアーキテクチャなのでしょう。たぶん。
GAEには非同期処理・テキスト全文検索・インバウンドメール・データのインポート/エクスポート等の機能はまだ実装されておらず、今後実装予定とのことです。
まだエンタープライズ用途では使えないかな。
クラウドコンピューティングがもたらす5つのメリットとは
スピーカーはGoogleの泉 篤彦氏。
エンタープライズ分野のプリセールスエンジニアをされている方だそうです。
このセッションでハッキリ聞くことができました。
Googleがエンタープライズ向けに扱っているサービスには、GAEは含まれていません。
このセッションは、Google AppsのPremier/Education Editionの紹介セッションという色が濃いモノでした。
クラウドコンピューティングがもたらすメリット、というお題ですが、内容はクラウドのメリット、SaaSのメリット、Googleであることのメリット、Google Apps固有のメリットが混在していました。
まあ、キレイに切り分けるのは難しいのですが、気をつけないと「クラウドコンピューティングってよくワカラナイ」という人がますます増えそうです。
他のクラウドサービスとの連携が容易である、というくだりではSalesforceが紹介されていました。
Google エンタープライズ エコシステムとは –Google Enterprise Partner–
こちらも引き続き泉氏のセッション。
エンタープライズ向けサービスのパートナー制度の紹介でした。
Google テクノロジー ライトニングトーク
サイオステクノロジー松尾さんによる、自作のGAE向けフレームワーク"Kay"の紹介。
デバッガを使えるのがいいですね。Force.comもブレークポイントを置いて、ステップ実行して、変数の値を確認して・・・とできたらいいのに。
Seessaaの安藤さんによる、Rails on GAE/Jの話。
当初はエライ大変な手順を踏まないとGAE/J上でRailsを動作させることはできなかったのを、とてもとてもカンタンにした、というお話し。
日本Androidの会の近藤さんによる、Androidが組み込み業界へ与えるインパクトのお話し。将来はPCと携帯の垣根が無くなるという展望をお話しされていました。
スパイスボックスラボラトリの神部さんによる、Open Social Hackathonのお話し。Hackathonに参加しよう!というメッセージを熱く語っていました。
E-flowの久野氏による、Dalvik VM実装のお話し。Google謹製のDalvik VMがケータイJavaの2~5倍も遅かったので、自分で実装してケータイJavaと同等まで持って行ったお話し。非常に素晴らしい成果だと思います。一方で、Dalvik VMとは何か?に一切触れなかったので、会場には「そもそもDalvik VMってなに?」な人が多かったのでは?と心配になりました。
最後に、松尾氏がTokyo GTUG(Tokyo Google Technology Users Group)を立ち上げました、と紹介されていました。
Tokyo GTUG
http://groups.google.com/group/tokyo-gtug
個人的に(職業柄?)Googleのエンタープライズ向けサービス戦略の情報を得たかったのですが、今のところGoogleのエンタープライズ向けサービスはGoogle Appsと検索アプライアンス、企業向けGoogle Map APIという内容のようです。
GAEはデータ管理やユーザの権限コントロールが不十分だったり、ワークフローなどが実装されてなかったりと、エンタープライズ用途にはまだまだですね。
なんと、事前登録者全員に携帯電話がプレゼントされました。
Google製OS「Android」搭載のHTC製端末です。
先日、サンフランシスコで行われたGoogle I/Oでも入場者に配られたそうですが
まさか、日本でもやるとは!
Googleさん、太っ腹です。
これはdocomoから発売されるHT-03Aとほぼ同等のものです。
http://www.nttdocomo.co.jp/product/foma/pro/ht03a/index.html
docomo発売前なので、この日この端末を手にした人は
恐らく日本で最も早く日本語入力可能なAndroid端末を入手したことに
なるのではないでしょうか。
あともらったのは、タオルとかステッカーとか。
事前登録の時にTシャツのサイズを聞かれたので
てっきりTシャツをもらえるのかと思っていましたが・・・
急遽タオルに変更になったのでしょうか。
post:
liebejudith
at:
01:17
0
コメント
labels: Android, Cloud Computing, DoCoMo, Google, Google App Engine, Java, Mobile, PaaS, SaaS, Salesforce
January 4, 2009
Google App EngineのJava版「Stax」を触ってみました
Amazon EC2上で提供されるJava版PaaSサービス「Stax」をちょっと触ってみました。今のところはβサービスで、まだ実装されていない機能もあったりしますが無料で試すことができます。
「Google App EngineのJava版」としてニュース記事等でも紹介されています。
Java対応のGoogle App Engineとも言うべき「Stax Networks」ローンチ
http://jp.techcrunch.com/archives/20081216stax-networks-launches-google-app-engine-for-java/
用意されている環境
- Apache Tomcat/6.0.16
- MySQL/5.0.51
要するにServlet2.5/JSP2.1環境を使えるってことですね。JVMはJavaSE5相当のようです。
GoogleもSalesforce.comも、Servletコンテナにはより軽いResineを採用していますが、ここはTomcatですね。
サポートするフレームワーク
- Apache Struts(ただし、1.xではなく2.0.11)
- Apache Wicket
- Adobe Flex/BlazeDS
- Google Web Tool Kit
- Adobe ColdFusion 8
- JRuby on Rails
逆に、WEB-INF/libにライブラリをつっこんで、web.xmlを編集して、WEB-INFに必要な設定ファイルを追加すれば他のフレームワークも使えます。DI/AOPコンテナもORマッピングフレームワークも使えます。
Struts1.3.8/Spring2.5.6/iBATIS2.3.4とか、JSF1.2RI/Spring2.5.6/Hibernate3.3.1とか、試してみたら動きました。この分ならSeasar2を使ったアプリも問題なく動作するでしょう。
アカウントの作成
StaxのWebサイト http://www.stax.net/ へ行きます。

「Apply for the Beta」をクリックしてサインアップ画面へ行き、メールアドレスを入力して送信すると認証メールが送られてくるので、そこに書いてあるURLにアクセスするとサインアップ終了です。簡単です。

改めてStaxのWebサイトからログインするとアプリケーション管理画面に入れます。

管理画面では、TomcatのログやApacheのアクセスログ等の参照、アプリケーションの作成・DBの作成・設定・パフォーマンスやアクセス監視モニタの参照等を利用できます。
アプリケーションの作成
管理画面左側メニューの「Create App」をクリックすると、アプリケーションを作成できます。ユニークな名前を付けましょう。Application Core Runtimeからフレームワークを選べますが、前述の通り、Servlet2.5/JSP2.1環境で動作するものなら好きなモノを使えます。用意されているもの以外のフレームワークを使うのなら「Basic Servlet and JSP」を選択してもかまいません。

Stax SDK http://stax-downloads.s3.amazonaws.com/sdk/stax-sdk-0.2.12-dist.zip をダウンロードして解凍しておきます。
http://www.stax.net/appconsole/createapp から、任意の名前のアプリケーションを作成します。
解凍したディレクトリ中の「Stax Console」ショートカットを起動します。
コマンドラインコンソールが起動するので、そこから
stax getapp -a [ユーザ名]/[アプリ名] -u [ユーザ名] -p [パスワード]
を実行すると、アプリケーションのひな形がダウンロードされます。このひな形はEclipseプロジェクトになっているので、そのままEclipseへインポート可能です。でもこのプロジェクトはWTP互換じゃないのが残念です。
アプリケーションの構造
- webapp: JavaEE Webアプリケーションディレクトリ
- src: Java ソースファイルディレクトリ
- conf/stax-application.xml: Stax デプロイメントディスクリプタ
DBの作成
管理画面左側メニューの「Create DB」をクリックすると、アプリケーションを作成できます。任意のDB名、ユーザー名、パスワードを設定します。

DB作成後、テーブルやら何やらを作成するには、なんとTCP:3306が開いているのでMySQL Query Browser や mysql コマンドが使えます(^^;(←いいのか?)
アプリケーションのconfディレクトリにあるstax-application.xmlに、下記の設定を追記します。
<resource name="jdbc/db01" auth="Container" type="javax.sql.DataSource">
<param name="username" value="[ユーザ名]" />
<param name="password" value="[パスワード]" />
<param name="url" value="jdbc:stax://[DB名]" />
</resource>
Javaアプリケーションからは、JNDI参照名「java:comp/env/jdbc/[DB名]」でLookupできます。
アプリケーションのデプロイと動作確認
コマンドラインから
stax deploy -a [ユーザ名]/[アプリ名] -u [ユーザ名] -p [パスワード]
とすると、作成したアプリケーションをアップロードできます。
Antを使ってWARファイルからのデプロイも可能です。WARファイルをそのままアップロードできるUIがあればいいのに。。。
次のURLからアプリケーションの動作を確認できます。
http://[アプリ名].[ユーザ名].staxapps.net/
何度アップロード/デプロイし直しても反映されるので、クラスローダはカスタマイズしていじっているっぽいですね。Tomcatのデフォルトのリロード機能ではヒープメモリがすぐに破綻しますから。
[追記]
サーバのログを見るとTomcatまんま再起動しているっぽいです。
一度デプロイしたアプリケーションは削除できません(^^;削除機能はまだ未実装のようです。
ちょっと触った所感
Tomcat/MySQL/Eclipse環境に慣れた人ならすぐに開発できるのが良いですね。フレームワークもお仕着せのものだけでなく好きなものを選べますし、使い慣れたRDBがそのまま使えます。Python/Django/webappsにどうしてもなじめず、Google App Engineを放り出してしまった私には嬉しいポイントです。
懸念としては、サーバの信頼性・可用性・セキュリティと正式サービス開始後の料金体系です。まあ、これはすべてのクラウドサービスに言われていることですが。Amazon E2Cを利用しているのでこのレベルではある程度の信頼性はありますが、その上で動作しているアプリケーションサーバレベルではStaxの技術力・資金力・信頼性が問われるところでしょう。
Amazon EC2上に構築されたってのが、次世代のビジネスモデルを予感させます。自前のデータセンターを持たずにSaaS/PaaS事業を展開するという例はこれからも増える可能性がありますね。
post:
liebejudith
at:
23:54
2
コメント
labels: Cloud Computing, Eclipse, Google App Engine, iBatis, Java, MySQL, OSS, PaaS, Python, SaaS, Salesforce, SpringFramework, Tomcat
December 8, 2008
Force.com for Google App Engine
Force.com for Google App Engine
http://developer.force.com/appengine
というのがリリースされたみたいです。GAEからForce.comのAPIを呼び出せるPythonライブラリだそうです。
コンシューマ向けのフロントはGAEで、顧客情報管理はセールスフォースで、のような利用が想定されているのでしょうか。
来年からサービス開始すると発表されているForce.com Sitesも外部公開サイト向けの機能ですが、まだ一部ユーザ向けプレビューのみで料金体系や利用上の制約条件が発表されていません。Force.com Sites では完全独自ドメインでの利用は難しいですし。
post:
liebejudith
at:
23:08
0
コメント
labels: Google App Engine, PaaS, Salesforce
November 6, 2008
Salesforce.comが新サービスを発表
Salesforce.comが、米サンフランシスコで開催中のDreamforceで、様々な新サービスを発表しました。
- Force.comアプリを外部公開サイトにできるForce.com Sites
- Force.comアプリでGoogle Visualizationを利用できる
- Force.comアプリのAmazon EC2/S3対応
- Force.comアプリからFaceBook APIを利用できる
各機能の解説は各種ニュースサイトにお任せするとして・・・
この中で私が注目するのは「Force.com Sites」です。
http://developer.force.com/sites
単なる外部公開するWebアプリケーションPaaSプラットフォームとして強力なGoogle App Engine対抗となり得るばかりか、独自ドメインも使えるようですし、SFDCがこれまで提供してきたCRM等と連携して、アンケートやお問い合わせ・サポートなど、マーケティングツールとして幅広く使えそうですね。
Google App Engineで同じことをやろうとしたら自分で作り込まなくてはならない部分があまりにも多すぎます。
SaaSベースのCRMを提供している他ベンダー(OracleやSugarCRMなど)が同じことをやろうとしてもまた、自分で作り込まなくてはならない部分があまりにも多すぎます。
この機能はまだDreamforce参加者限定のプレビュー版ということですが、この機能を使うにはライセンス料がそれほど安くはなさそう・・・と予測しますが・・・。
それから、Amazon EC2/S3対応。
http://wiki.apexdevnet.com/index.php/Amazon_Toolkit
つい先日のエントリーで、オープン性・互換性についての懸念を書いたばかりですが、SFDCはちゃんと対応を考えていました。
まだチュートリアルをちゃんと見ていませんが・・・
Force.comで作成したアプリをAMIにしてAmazon VM上で動作させることができるのかな?
私は、ユーザがクラウドコンピューティングへの抵抗を感じるポイントとして、セキュリティ面の他に互換性の問題があると思います。
クラウドコンピューティングプロバイダのサービス廃止は、フェイルオーバー、サービス障害、プロプライエタリ技術による囲い込み以上に大きな問題です。ユーザは、SFDCのアプリを使えば使うほど、「これが無くなったらどうしよう?」と思いますから。
作成したアプリが、SFDCのクラウド上でも、Amazonのクラウド上でも動作できるならば、ユーザにとって大きなメリットになるでしょう。
ストレージとしてS3が使えるのも大歓迎です。
Facebook連携は・・・
日本国内ユーザはあまり多くないのでまぁいいでしょう(笑)
post:
liebejudith
at:
02:07
0
コメント
labels: Amazon.com, Cloud Computing, Google, Google App Engine, PaaS, SaaS, Salesforce
October 5, 2008
最近のクラウド・SaaS・PaaS
Cloud Computing
最近、データセンターを作っただけで「クラウド参入」とか言ってる企業、多くないですか?
「データセンター」を「クラウド」と言い換えているだけのような。
「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
「過大な情報がIT業界に混乱を招く」とガートナーが警鐘
※「MSとIBMが使い出した時点でバズワード化する」とはS社のO氏の発言。(^^;
SaaS
実態はただのWebアプリやASPなのに「SaaS参入」とか言ってる企業、多くないですか?
SaaSと言いながらクラウド環境・マルチテナント環境ではないため、いったいどれだけスケールするのか不安で仕方ない「SaaSもどき」が増えてきました。
PaaS
これを実用化・収益化できている企業はごくわずか。さすがに猫も杓子も「PaaS」と言い出すまでには至っていませんね。
各社の動向
最近の各社の動きはどうなっているのでしょうか?
大きく分けると、
- クラウドインフラのみ提供
- アプリケーションを提供(SaaS)
- アプリケーション動作環境を提供(PaaS)
Yahoo/HP/Intel連合
まだ研究開発段階。クラウドインフラと、もしかしたらPaaSも?
HP、インテル、ヤフーの3社、クラウド・コンピューティングの共同研究プロジェクトを発表
ユニシス
「SaaSはじめます」と言ったが、その後進んでいるのだろうか?「乗り遅れたくない」感で言ってみただけ?
日本における早急なPaaS、CaaSの確立を目指す~ユニシス
富士通
「SaaSはじめました」と言ったが、その後進んでいるのだろうか?「乗り遅れたくない」感で言ってみただけ?
富士通が SaaS 3 サービスを開始
IBM
データセンターをばんばん作っている。その上で何をやるのだろう・・・。クラウドインフラと、もしかしたらPaaSも?
IBM、「Blue Cloud」コンピューティング計画を発表
IBM、世界4カ所にクラウド・コンピューティング・センターを開設
Sun
Project Carolineは大注目。Salesforce.comが成し得ていない、標準言語(Java)によるPaaSを実現しようとしている。でもまだ研究開発段階。
サン、PaaSモデルの研究プロジェクト「Project Caroline」を披露
Google App Engineはアプリケーション実行環境の提供という形式でPaaSをやっているけど、アプリケーションの開発作業はローカルマシン上で行ってそれをアップロードするしかない。
ここ1年ぐらい、エンタープライズ分野では最近目立った動きがないが、Mobile側(Android)からクラウドの使い道を広げようとしている。うまくいけばこっちの切り口からエンタープライズ分野へ食い込んでいけるのかも。
「独創的な」という言葉がぴったりなこの企業の動きには常に要注目。
Amazon.com
インフラの提供はしっかりやっているけど、その上で何をするのか?は利用者任せ。今のところ、Amazon.com自身はECサイト以上のサービスをしていない。Amazon WSは、実質はレンタルサーバっぽい使われ方がほとんどなのでは?
Microsoft
クラウド上にWindows Serverが乗っかって、何が嬉しいのだろうか・・・
MSのクラウドへの取り組みは、Office Suiteにしろ、OSにしろ、結局クライアントパッケージをインストールしないと使えない「非SaaS」なものになるでしょう。
MSのバルマーCEO、「Windows Cloud」の詳細に言及
Oracle
Siebel on Demandなど一部SaaSを提供しているけど、いったいどのぐらい儲かっているのだろうか。MS同様、パッケージライセンスの売上によって過去最高利益を更新し続けているこの企業が、本気でSaaS/PaaSに取り組むとは考えにくい。
Amazon WS上にOracle Databaseを乗っけるパッケージの提供も始めるらしいけど、自社パッケージをクラウドに乗せますという点ではWindows Cloudと同じ。自分でアップロードして展開して設定してね、という点ではもっとひどいかも。すぐに使えるDaaS(Database as a Service)を用意していたらちょっとは「ほう」と思ったかも。
オラクルのクラウドへの第一歩
RedHat
Amazon WS上でJBossが動くようになるらしい。
Red Hatが見据える次世代のアーキテクチャ
Salesforce.com
結局、「クラウドだけどSaaS/PaaSではない」サービスは、ユーザーにとってはハードウェア準備・運用の手間は省けるけど、サーバソフトウェアの構築・管理、アプリケーション開発をしなければならないことは変わらず。MSのアプローチはまた独特だけど。
また、クラウドはそれだけではその存在に意味は無く、クラウド上で提供されるサービスがビジネスとして確立しないと成り立たない。エンタープライズ分野でインフラ・ミドルウェア・アプリケーション・開発環境まで(クラウドからSaaS/PaaSまで)トータルに提供し、実用化・収益化できているのは、事実上SFDCのみか・・・
今のところ、Salesforce.comが独走態勢で、他企業が技術・サービス両面で追いつくのはもう少し先になると思う。
SFDCを脅かすのは、オープン化の波かもしれない。
Amazon WSがXenベースであるため、JBossやOracleは対応できた。
アメリカではAmazon WS互換の他社サービスも始まっているらしい。Amazon WSのバックアップやフェイルオーバー用途に使えるとのこと。
数年後にはプロプライエタリなテクノロジによる囲い込みをオープンソースが切り崩すという波がクラウドコンピューティングの世界にも来るかもしれない。
post:
liebejudith
at:
13:05
0
コメント
labels: Amazon.com, Cloud Computing, Google, Google App Engine, HP, Intel, Java, JBoss, Microsoft, Oracle, PaaS, RedHat, SaaS, Salesforce, Sun, Yahoo
April 30, 2008
Google App Engine で Web アプリケーション ~ その2
Google App Engine は、Django というフレームワークがデフォルトで利用できます。この Django には強力なテンプレートエンジンが含まれています。
前回までのような方法で画面を出力するのは少々骨が折れますが、Django のテンプレートエンジンを使うと HTML ベースの画面を作りやすくなります。
Javaで言うところの、Velocity や FreeMarker のようなモノですね。
というわけで、今回はこれを利用してみました。
テンプレートとなるファイルを作成する
拡張子は .html で OK です。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ</title>
</head>
<body>
<center>
<br />
<h3>ようこそ!{{username}}さん!</h3>
<br /><br />
<a href="/index.html">戻る</a>
</center>
</body>
</html>
Django テンプレートでは、動的に値を埋め込みたい箇所は、{{...}} で囲み、括弧の中に変数名を記述しておきます。オブジェクトの属性にアクセスするには、user.username のように、. (ドット) で区切ってネストを指定します。
テンプレート出力処理を行うには
こんな風に書きます。
# テンプレートを取得
templatefile = os.path.join(os.path.dirname(__file__), 'テンプレートファイル名')
# パース・コンパイル・出力処理
self.response.out.write(
template.render(templatefile, {'変数名':オブジェクト}))
template.render() メソッドの引数には、出力したいオブジェクトと、そのオブジェクトの変数名を連想配列の形式で記述します。複数指定したい場合は
template.render(templatefile, {'変数名1':オブジェクト1, '変数名2':オブジェクト2, '変数名3':オブジェクト3}))
のように書きます。
というわけで、前回のアプリケーションを、Django テンプレートを使ったものに書き換えてみると、こうなります。
[index.html]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ!</title>
</head>
<body>
<form action="welcome" method="post">
<center>
<br />
<h3>お名前は?</h3>
<input type="text" name="username" size="30" />
<br /><br />
<input type="submit" value="送信" />
</center>
</form>
</body>
</html>
前回と同一です。
[WelcomeRequestHandler.py]
# coding: UTF-8
import os
import wsgiref.handlers
from google.appengine.ext import webapp
from google.appengine.ext.webapp import template
# webappのインポート
from google.appengine.ext import webapp
class WelcomeRequestHandler(webapp.RequestHandler):
# HTTP post リクエスト処理
def post(self):
# リクエストパラメータ "username" の取得
userName = self.request.get("username")
# テンプレートファイルを取得
templatefile = os.path.join(os.path.dirname(__file__), 'welcome.html')
# パース・コンパイル・出力処理
self.response.out.write(
template.render(templatefile, {'username':userName.encode('UTF-8')}))
def main():
# リクエスト URL パターンと、実行するクラスの関連づけ
application = webapp.WSGIApplication([('/welcome', WelcomeRequestHandler)],
debug=True)
wsgiref.handlers.CGIHandler().run(application)
# アプリケーション起動時に main() 関数が実行されるようにする
if __name__ == "__main__":
main()
前回は、HTML タグなどを直接出力していましたが、今回はテンプレートを利用してレスポンス出力を行っています。
[welcome.html]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ</title>
</head>
<body>
<center>
<br />
<h3>ようこそ!{{username}}さん!</h3>
<br /><br />
<a href="/index.html">戻る</a>
</center>
</body>
</html>
「ようこそ!{{username}}さん!」の箇所に注目です。WelcomeRequestHandler.py で、リクエストパラメータから取得した値を "username" という名前でテンプレートオブジェクトとして指定しました。この welcome.html では、その "username" という名前の変数の値を出力しています。
[app.yaml]
application: liebejudith-helloworld
version: 1
runtime: python
api_version: 1
handlers:
- url: /welcome
script: WelcomeRequestHandler.py
- url: /index\.html
static_files: index.html
upload: index.html
- url: /
static_files: index.html
upload: index.html
前回と同一です。
実行結果


実行結果も前回と同一です。
HTML センシティブな文字・記号のエスケープについて
Webアプリケーションでは、正しい表示やクロスサイトスクリプティング対策のために、< や、> など、HTML や JavaScript コードとして認識されてしまう文字をエスケープする必要があります。
現在のバージョンの Django では、デフォルトでエスケープが有効になっています。もし何らかの理由でエスケープ処理を無効にしたい場合は、
こんにちは {{ username|safe }} さん
のように、safeフィルタを利用します。
あるいは、
{% autoescape off %}
こんにちは {{ username }} さん
{% endautoescape %}
のように、autoescape タグを使って、off オプションを指定します。Django テンプレートでは、タグの表記に {% ... %} を使います。
ループ処理を行うには
for タグを使います。Velocity や FreeMarker を使ったことのある方なら直感的におわかりでしょう。
{% for 要素 in リスト %}
・・・・
{% endfor %}
ループの中では、次の変数を利用できます。
| forloop.counter | ループカウンタ(1から開始) |
| forloop.counter0 | ループカウンタ(0から開始) |
| forloop.revcounter | ループの終わりからのインデックス(1から開始) |
| forloop.revcounter0 | ループの終わりからのインデックス(0から開始) |
| forloop.first | ループの最初の繰り返しの場合、True になる |
| forloop.last | ループの最後の繰り返しの場合、True になる |
条件分岐を行うには
if タグあるいは ifequal/ifnotequal タグを使います。
if タグを使った評価
指定した変数が存在するか・空ではないか(リストの場合)・Trueかを評価します。
{% if name_list %}
・・・・
{% else %}
・・・・
{% endif %}
or not and を使って複合的な評価も可能です。
{% if name_list or order_list %}
・・・・
{% endif %}
{% if not name_list %}
・・・・
{% else %}
・・・・
{% endif %}
{% if name_list and order_list %}
・・・・
{% endif %}
{% if name_list and not order_list %}
・・・・
{% endif %}
ifequal/ifnotequal タグを使った評価
2つの値が同一かどうかを比較します。
ifnotequal は同一でないかどうかを比較します。
2つの値はスペース区切りで指定します。
{% ifequal user.id comment.user_id %}
...
{% endifequal %}
{% ifnotequal user.username "liebejudith" %}
...
{% endifequal %}
画面部品をインクルードするには
include タグを使います。
ファイル名は、文字列リテラルで直接指定することもできますし、変数を使っての動的指定も可能です。
{% include "foo/bar.html" %}
{% include template_name %}
コメントを記述するには
{# ... #} で囲みます。
{# comment #}
テンプレートの継承
Django では、テンプレートを継承することができます。この機能は、同一レイアウト、同一部品を使った似たデザインの画面が多数存在する場合に非常に便利です。
子テンプレートでオーバーライドする部分は、{% block ブロック名 %} ~ {% endblock %} で囲んで記述しておきます。ブロック名はユニークな任意の名前です。
<html>
<head>
<title>{% block title %}タイトル{% endblock %}</title>
</head>
<body>
<div id="content">
{% block content %}{% endblock %}
</div>
</body>
</html>
あるテンプレートを継承したテンプレートを作成するには、{% extends "親テンプレート名" %} を記述します。そして、親で定義された {% block ブロック名 %} ~ {% endblock %} を任意にオーバーライドできます。
{% extends "base.html" %}
{% block title %}子ページ{% endblock %}
{% block content %}
content 部分のオーバーライド
{% endblock %}
変数値の出力、条件分岐、ループ処理、インクルード、テンプレートの継承と見てきました。これでたいていの画面は作成できるのではないでしょうか?
Django の翻訳ドキュメントも見つけました。Yasushi Masuda さん、Takanao Endoh さんという方が翻訳されています。
Django
http://ymasuda.jp/python/django/index.html
Django オンラインドキュメント和訳
http://michilu.com/django/doc-ja/index/
Django は、テンプレートエンジンだけでなくアプリケーション全体をカバーするフルスタックのフレームワークです。今回取り上げたテンプレートのリファレンスはこちらです。
テンプレート作者のための Django テンプレート言語ガイド
http://michilu.com/django/doc-ja/templates/
Django のユーザコミュニティも存在するようですが、残念ながら現在はサーバが止まっているようです・・・
http://djangoproject.jp/
私は Python 初心者のため、定石もお作法も知りません。バリバリの Python 使いの方から見たらとんでもないコードを書いているかもしれませんがご容赦下さい。間違いや「こうするもんだ」を指摘していただけるととても嬉しいです。
環境: Python 2.5
April 22, 2008
Google App Engine で Web アプリケーション ~ その1
Google App Engine には webapp という、Webアプリケーションのためのシンプルなフレームワークが用意されています。
前回はとりあえず Hello World まで行ったので、次はこの webapp フレームワークを使ってリクエストパラメータを受け取り、それを表示するアプリケーションを作ってみました。

私は Python 初心者のため、定石もお作法も知りません。バリバリの Python 使いの方から見たらとんでもないコードを書いているかもしれませんがご容赦下さい。間違いや「こうするもんだ」を指摘していただけるととても嬉しいです。
環境: Python 2.5
ソースコードを UTF-8 で書くには
ソースコードの1行目または2行目に
# coding: UTF-8
と書きます。
こうしないと、文字列リテラルの前には u'こんにちは' のように、毎回 u をつけないといけなくなってしまいます。それはあまりに面倒です。
HTTP post リクエストを受けるには
webapp.RequestHandler を継承したクラスを定義し、post() メソッドを定義します。
(例)
class WelcomeRequestHandler(webapp.RequestHandler):
def post(self):
HTTP get リクエストを受けるには、post() ではなく get() メソッドを使えば OK です。使い方は post() と全く同一です。他にも、Restful なアプリケーション構築のために put() delete() head() trace() options() が用意されています。
※ Python って、メソッド?関数?どう呼ぶんでしょう?
リクエストパラメータ値を取得するには
RequestHandler オブジェクトに用意されている属性 request の get() メソッドを利用します。引数にはリクエストパラメータ名を指定します。
(例)
userName = self.request.get('username')
これは、"username" という名前のリクエストパラメータ値を取り出し、変数 "userName" に入れておく、という処理になります。
リクエストパラメータが来なかった場合のデフォルト値を同時に指定することができます。
(例)
userName = self.request.get('username', default_value="anonymous")
上記の場合、リクエストパラメータ"username"が来なかった場合は変数"userName"の値が"anonymous"になります。
同名のリクエストパラメータが複数来る場合は
(例)
userNames = self.request.get('username', default_allow_multiple=True)
この場合、変数 userNames は配列になります。
レスポンスを出力するには
こう書きます(^^;
self.response.out.write('出力したい文字列')
変数の値を出力するには
こう書きます。
self.response.out.write(変数名.encode('文字エンコーディング名'))
これ、ハマりました。self.response.out.write(変数名) とするだけでは、実行時に UnicodeDecodeError とエラーになります。Python を使い慣れている方なら何でもないことなのでしょうけど・・・
リクエスト URL パターンと、実行するクラスを関連づけるには
こう書きます。
def main():
application = webapp.WSGIApplication([('URLパターン', クラス名)],
debug=True)
wsgiref.handlers.CGIHandler().run(application)
アプリケーションが起動したら main() 関数が呼ばれるようにするには
こう書きます。
if __name__ == "__main__":
main()
ある URL にリダイレクトするには
redirect() メソッドを使います。
self.redirect('http://www.google.co.jp/', False)
2番目の引数に True を指定すると、HTTP Status 301 での Redirect になります。False を指定した場合は HTTP Status 302 での Redirect を行います。
※Python の True/False って、大文字からはじめるんですね・・・
例外発生時の処理を記述するには
RequestHandler クラスの handle_exception() メソッドを使うらしいのですが、使い方がよくわかりません・・・
以下、全ソースコード。
[index.html]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>ようこそ!</title>
</head>
<body>
<form action="welcome" method="post">
<center>
<br />
<h3>お名前は?</h3>
<input type="text" name="username" size="30" />
<br /><br />
<input type="submit" value="送信" />
</center>
</form>
</body>
</html>
テキストボックスとsubmitボタンが一つずつあるだけのシンプルなフォームを実装した単純な HTML です。
[WelcomeRequestHandler.py]
# coding: UTF-8
import wsgiref.handlers
# webappのインポート
from google.appengine.ext import webapp
class WelcomeRequestHandler(webapp.RequestHandler):
# HTTP post リクエスト処理
def post(self):
# リクエストパラメータ "username" の取得
userName = self.request.get("username")
# レスポンス出力
self.response.out.write('<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">')
self.response.out.write('<html>')
self.response.out.write('<head>')
self.response.out.write('<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">')
self.response.out.write('<title>ようこそ</title>')
self.response.out.write('</head>')
self.response.out.write('<body>')
self.response.out.write(' <center>')
self.response.out.write(' <br />')
self.response.out.write(' <h3>ようこそ!')
# 変数値を出力する際には encode() 関数で処理する必要がある
self.response.out.write(userName.encode('UTF-8'))
self.response.out.write('さん!</h3>')
self.response.out.write(' <br /><br />')
self.response.out.write(' <a href="index.html">戻る</a>')
self.response.out.write(' </center>')
self.response.out.write('</body>')
self.response.out.write('</html>')
def main():
# リクエスト URL パターンと、実行するクラスの関連づけ
application = webapp.WSGIApplication([('/welcome', WelcomeRequestHandler)],
debug=True)
wsgiref.handlers.CGIHandler().run(application)
# アプリケーション起動時に main() 関数が実行されるようにする
if __name__ == "__main__":
main()
リクエストパラメータを受け取り、その値を使って「ようこそ!○○さん!」と出力するスクリプト。
[app.yaml]
application: liebejudith-helloworld
version: 1
runtime: python
api_version: 1
handlers:
- url: /welcome
script: WelcomeRequestHandler.py
- url: /index\.html
static_files: index.html
upload: index.html
- url: /
static_files: index.html
upload: index.html
/ あるいは /index.html が要求された場合は index.html を返し、/welcome が要求された場合は WelcomeRequestHandler.py が実行されるように設定しています。
app.yaml では、リクエスト URL パターンの関連づけを行いますが、.py スクリプトとの関連づけは、前回の Hello World で出てきました。
URL パターンと静的ファイルを関連づける場合は、static_files: エントリでファイル名を指定し、同時にサーバへアップロードするファイルを相対パスまたは絶対パスで指定します。
前回、「次回は掲示板でも・・・」なんて書きましたが、いきなり掲示板なんてとんでもなかったです。文字エンコーディングごときで大ハマリするぐらいですから。もっと少しずつ進めていきたいと思います。
April 9, 2008
Google App Engine が公開されました
Google App Engine が公開されました。
http://code.google.com/appengine/
Googleが提供するインフラ上に自作のWebアプリを乗せられ、データベースまで利用できるというモノです。
しかも、初期費用無料で。
私自身このニュースを見たとたん「来たっ!」と思いましたが、
マスコミの反響も大きいようです。
Googleのインフラでアプリを動かせる「Google App Engine」(ITmedia)
http://www.itmedia.co.jp/enterprise/articles/0804/08/news056.html
グーグル、「App Engine」を発表--オンラインアプリケーション開発用にインフラ提供 (CNET Japan)
http://japan.cnet.com/news/media/story/0,2000056023,20370974,00.htm
クラウドサービスに参入【詳報】「Google App Engine」ってなんだ (@IT)
http://www.atmarkit.co.jp/news/200804/08/appengine.html
「Google App Engine」発表、Googleのインフラ上でWebアプリ構築 (マイコミジャーナル)
http://journal.mycom.co.jp/news/2008/04/09/002/index.html
技術系ブログでも大盛況ですね。
Google ブログ検索の結果
Google App Engine は、Amazon の EC2/S3/SimpleDB や、Salesforce.com の force.com と競合するサービスになり得ますね。
Amazon や Salesforce.com がこれらのサービスを始めたときよりも反響が大きい印象です。改めて Google の影響や注目の大きさを感じます。
Salesforce.com に転職した後輩が、「Google が始めたとしても、Salesforce.com はもう8年もやっている実績がありますから」と言ってました。
Salesforce.com の force.com は、既存の高機能なCRMシステムを持っていて連携できるのが強みでしょうか。さらにリッチな GUI 開発環境を SaaS 形式で提供しているのが特徴です。アプリケーションのコードは Apex という、Java によく似た独自言語で記述します。
Goole App Engine は、背後に GoogleのBigTable、GFSという基盤を持っているのが強みだと思います。これは非常にスケーラビリティの高いシステムを構築できる可能性を持っていることを意味します。
mixi のような大規模 SNS もホスティングできたら、これはすごいことになりますね。世の中のインターネットサービスやエンタープライズシステムのあり方を一変させる可能性を秘めています。自らインフラを持たずとも初期投資ほぼ0からスタートして、大規模エンタープライズシステムやmixi のような規模を持つコンシューマサービスを運営できることになるのです。
多くのサービスやエンタープライズシステムが、自社サーバではなく Amazon や Google のクラウド上に移行するということがさらに現実味を帯びてきた感があります。Google のことですから、それぐらいの野望は持っているでしょう。
Web 上で Service を提供する SaaS から、プラットフォームを提供する PaaS (Platform as a Service) 時代へシフトする未来が見えてきた感があります。
Goole App Engine の正式サービス開始時の料金体系がまだ発表になっていませんが、Google の大容量ストレージを格安で利用できるメリットを打ち出してきそうな予感がします。
プログラム言語としては、現在は Python のみのサポートですが、将来的には他言語にも対応予定とのこと。Salesforce.com の force.com が独自開発言語と SaaS 形式のリッチな GUI 開発環境を提供するというアプローチに対して、Google App Engine は多言語対応で、開発環境は「自分の好きなものを使ってね」的なアプローチです。
| Salesforce force.com | Google App Engine | |
|---|---|---|
| 開発言語 | Apex | Python 他言語もサポート予定 |
| 開発環境 | 専用GUI環境(SaaSで提供) | SDK提供 統合開発環境は無し。 開発者が好きなものを利用。 |
| インフラ | Salesforce.com (恐らく市販商用サーバ + 商用DB) | GFS + Google BigTable |
| 最低限の 初期投資 | 0円 | 0円 |
| 他サービス との連携 | 強力・高機能なCRMシステム | Googleアカウントを利用した 認証等 |
| 独自ドメイン の利用 | 不可 | 可 |
Yahoo! や MS はこの流れに追従するのでしょうか?MS はやりそうな気がしていますが・・・
まあ、Google と SalesForce.com ではターゲットとするユーザ・アプリが違う気もしますが・・・
平たく言うと Web2.0 的コンシューマサービスをゲリラ的に立ち上げやすい Google と、あくまで企業ユーザをターゲットにした SalesForce.com という感はあります。
ともあれ、Getting Started Guide に従って少しいじってみました。
(Windows XP Professional 環境です。)
トップページ http://code.google.com/appengine/ から、サインアップし、SDK をダウンロードします
msi 形式の Windows インストーラが用意されているので、それをダウンロードしました。
さて、インストール・・・
と思いインストーラを起動したら、Python2.5 が必要なので、まずはそっちをインストールしなさい・・・と怒られました。
Mac OS X 10.5 Leopard ならデフォルトで入っているんですけどね。
というわけで、Python をインストールしてから、GoogleAppEngine SDKのインストール。
インストール作業は、ライセンス同意と、インストールディレクトリの選択のみのシンプルな構成。「I Agree」とか「Next」を押しているだけで特に問題なく終了しました。
インストール時に、インストーディレクトリに PATH を通すかどうかのチェックボックスがありますが、チェックを入れておくとサーバの起動やアプリケーションのアップロードの時にコマンドをフルパス指定しなくて済みます。というだけです。
開発環境(SDK)には、開発用アプリケーションサーバ、ローカル環境専用データベースが含まれています。
Getting Started Guide に従って、最も簡単な Hello World アプリケーションを作ってみました。
まず、適当な場所にhelloworldディレクトリを作成し、その中にテキストベースで helloworld.py という名前のファイルを作成します。
ファイルの中はこんな感じ。
print 'Content-Type: text/plain'
print ''
print 'Hello, world!'
Google App Engine では、app.yaml という名前の設定ファイルが必要なので、同じディレクトリ内に作成します。
application: helloworld
version: 1
runtime: python
api_version: 1
handlers:
- url: /.*
script: helloworld.py
application: App Engine がアプリケーションを識別するためのユニークな名前を付けます。
- version: アプリケーションのバージョン番号。アップロードする前にバージョン番号を編集する必要があるそうです。App Engine はバージョン番号を認識しているので、管理コンソールで前のバージョンに戻したりできるらしいです。
- runtime: と api_version: エントリは、現在は python、1 で固定です。将来別の言語を使えるような計画もあるので、その際に拡張されるみたいです。
- handlers: 上記の設定は、すべてのリクエストに対して helloworld.py スクリプトが動作するということを意味します。スクリプトの他にも、ディレクトリを指定したり、指定したURIは管理者のみがログイン可を指定したりが可能です。
http://code.google.com/appengine/docs/configuringanapp.html
これで準備完了です。
コマンドラインから Google App Engine のサーバを起動します。その際にスペース区切りでアプリケーションの配備ディレクトリを指定します。
dev_appserver.py アプリケーションのディレクトリパス
あとは、ブラウザから http://localhost:8080/ にアクセスすると・・・
これを、Google App Engine のサーバにアップロードすれば公開できます。
アップロードするには、まず http://appengine.google.com/start/createapp からアプリケーションを作成します。
このとき、Application Identifier の項目は app.yaml の application エントリに登録した文字列と合わせておく必要があります。
この文字列はアプリケーションの識別子となるのですが、ユニークであるスコープはユーザ単位ではなく、Google App Engine サーバ全体です。つまり、同一のアプリケーション名を他人に使われていたら使えません。
というわけで、helloworld が(当然のように)使われていたので、ここでは「liebejudith-helloworld」に変更しました。app.yaml の application エントリもこれに合わせて修正しています。
そして、アップロード。Web 管理インタフェースからアップロードするのかと思いきや、Google App Engine ではコマンドラインから appcfg.py コマンドを実行してアプリケーションをアップロードします。
appcfg.py --email=登録メールアドレス update アプリケーション配備ディレクトリ
これで完了。ブラウザから次のURLにアクセスします。
http://アプリケーション名.appspot.com/
Google App Engine は、Pure Python アプリも動作しますし、アプリケーションと一緒にアップロードすれば多くのフレームワークを動作させることができます。
SDKに同梱されているのは、Django v0.96.1 と、オリジナルのWebアプリケーションフレームワーク "webapp" です。
webappフレームワークには、下記のような機能が含まれています。
- Google アカウントと連動したユーザ認証API
- データストアAPI。データ操作には、SQLによく似たクエリ言語"GQL"を利用
- Webページ作成のためのテンプレートエンジン
- Mail API
私は Java しか知らない人間なので Python はほとんど触ったことはないのですが、Google App Engine アプリを作るために Python を覚えてもいいかな?という気にさせてくれます。
次回は、Getting Started Guide で紹介されているゲストブックアプリケーションを参考にして、掲示板アプリでも作成してみたいと思います。
post:
liebejudith
at:
22:59
0
コメント
labels: Google, Google App Engine, Python, SaaS, Salesforce, Web2.0


