C9 Tech Notes: 2010

2010年12月7日火曜日

GAE SDK1.4.0

GAE SDK 1.4.0がリリースされた。

詳細な変更内容は記事にゆずるとして、全体でいえば「GAEの規制緩和」がメインであろう。タスクキュー（今回、ようやくExperimentalから正式採用へ移行）関連のほか、URLFetchやMemcache、Image, Mail等の各APIのサイズ制限が引き上げられた。

また、特筆すべきは「Always On」サービスだ。月額９＄と有料ながら、インスタンスを３つまで常時稼働させるというオプショナルサービスで、初回稼働に時間がかかってしまういわゆる「スピンオフ」問題への措置だ。これはPythonな人よりもJavaな人に待望の機能だろう。もちろん、初期処理を短くする技術的なアプローチによる解決も引き続き必要だが、オプションでこういうサービスがあると安心だ。

また、GoogleTALKで使用されている環境と同等のものを提供する「Channel API」が新たに実装。クライアント、サーバー間に双方向なセッションを作るもので、チャットやマルチプレイのゲーム等に利用されそうなAPIだ。

全体としてはGoogleApssの現行仕様が規制緩和とともに「安定期」へ向かいはじめたと感じられる。Googleもリリース当初は様子を見るためにも厳しい規制を設けていたものを、実証とともに徐々に外して「通常利用」のレベルまでもってきたという感じだ。ロードマップをみても、機能的に大きな追加というよりは「改善」「利便性、機能性の向上」がメインである。（相変わらず独自ドメインのSSLはトップリストだが）

今後のさらなる発展に期待したい。

ちなみに、このリリースは日本語記事で出ていますが、文頭で松尾さん(kay-framework)が翻訳したと書かれています。GAEの日本語情報がこのように流れてくるのもReal Googlerになられた松尾さんの「効果」でしょうね。応援しております。

2010年11月23日火曜日

Google Appsのサービスが大幅拡大

メール、カレンダーをはじめビジネス向けのサービスを提供しているGoogle Appsのアカウントで利用できるサービスが大幅に拡大された。

AdSenseやiGoogle、AnalyticsやBlogger等々、日頃よく使っているサービスがGoogleAppsのアカウントで利用できる（現在５９サービス）こととなり、より統合されたサービスとして生まれ変わった。

現在、GoogleAppsが利用中であれば管理パネルから「移行」ボタンを押すだけでサービスを拡大できる。ただし、アカウントによっては（他のサービスと衝突がある場合等）は移行がGoogle側で行われるため、数日待たされる場合がある。また、全アカウントではなく、特定のアカウントだけ移管することもできる。（試しに移管して場合によってはやめることもできる。）

GoogleAppsと様々なサービスが統合された事で、GoogleAppsEngineのほうも魅力が増した。各サービスのデータ通信関連もこれにあわせて充実していくものと思われる。

2010年7月2日金曜日

GAE SDK 1.3.5

GAE SDK 1.3.5がリリースされた。

主な変更点は以下のとおり。

・タスクキューの制約をアプリあたり50リクエスト/秒からタスクあたり50リクエスト/秒へ緩和。これはタスクキューを多様していたアプリには非常にありがたい変更だ。

・PythonでPreCompileをサポート。これによりスピンアップの時間を大幅に短縮することができる。方法はapp.yamlに数行追加するだけ。詳細はこちら。

・Blob型のデータを読み出せるストリームクラスが追加。

Python: BlobReader

Java:BlobstoreInputStream

マイナーチェンジなので迷わずアップデートを。

あと、こんな機能もいつの間にか追加されていた。

Admin Console Custom Page

管理者コンソールに独自のページを組み込むというもの。英語版のドキュメントにしか乗っていない。やっぱりGAE関連は英語でチェックしておかないと変更に気づかないですね。

また、9月28日にGoogle Developers Day 2010 Japan開催されますね。登録には前回のGoogle IOでもあったクイズがあるそうで。

PayPalX for GAE

日本ではいまいちだが、海外では絶大な支持を得ている決済サービス「PayPal」。

そのPayPalの決済モジュールはオープンソース化されており、PayPal Xというサイトで、SDKやドキュメント、APIなどが公開されている。PC用のサイトからモバイル、Webサービス等、様々なプラットフォームに対応可能だ。

そのPayPalXからGoogleApssEngine用のAPIがされた。

paypalx-gae-toolkit

もちろん、自前でプロトコルを実装すれば実現できるだろうが、ライブラリがあればさっさと使ったほうが早いし、安全だろう。

現在はJavaバージョンのみのリリースで、PythonはComming Soonと言うことになっている。（最近、Pythonまわりのサポートが遅れ気味なのがきになる）

なかなか日本では浸透しないPayPalだが、最近ではユーザー向けのUI（方式）がかなり改良されている。メールで決済という部分とPayPalに会員登録をしなければ行けないという点でかなり抵抗があったかと思われるが、最近ではユーザーがPayPal会員でなくても、クレジットカード＝＞PayPalという方式が確立できるため、通常の決済によるカード払いのような方式が取れる。

海外向けのサービスでは必須であろうが、国内向けのサービスでもクレジット決済であれば十分導入する価値があると思われる。

今回のAPIのように、足回りを強化するライブラリがGAE専用としてリリースされてきている。GAEが普及してきた証なのだろう。

2010年6月23日水曜日

次世代フレームワーク Sencha Touch

ExtJSというJavascriptフレームワークをご存知だろうか？

非常に優れたUIを提供するJavascriptのクロスプラットフォームフレームワークで、私もよくお世話になっている。（DEMO)

ExtJSは彼らの商品名でもありブランド名でもあったが、次世代フレームワークの投入とともに「Sencha」という名前に変更された。もちろん、語源は日本語の「煎茶」である。名前の良し悪しは個人の意見に任せるとして、彼らが今回投入した「Sencha Touch」は注目に値するフレームワークだ。

一言で言えば「iPadやiPhoneそっくりのUIをもつWebアプリが作れるフレームワーク」である。もちろんAndroidもサポートされている。このSencha TouchはExtJSにjQueryのプラグインである「jQtouch」、ベクターグラフィックライブラリである「Raphael」を融合し、HTML5及びCSS3ベースで再構築を行った「スマートフォン専用フレームワーク」である。

UIの素晴らしさは説明するよりデモを見るほうが早いだろう。UIだけでなく特筆すべき機能が「タッチパネルへのタッチイベントが利用できる」という点だ。これはHTML５ならではの拡張イベントで、あのiPadやiPhoneの拡大操作（両指で広げるやつ）なんかもUIとして取り入れられる。これはWeb用フレームワークとしてはかつてないもので、非常に画期的だ。その他の機能としては「ローカルストレージ」へも対応しているようだ。APIを眺めてみたがExtJSを使っていた方ならすんなり行けるはずだ。

問題はライセンスだ。ExtJSは途中でライセンスを「LGPL」から「GPL V3」へ変更したためエンジニアからブーイングが続出、エンジニアチームが分断したり、プロジェクトが枝分かれしたりと何かと物議をかもしだした。GPLとはいえデュアルライセンス形式で、無料のパブリックライセンス（GPL）と有料のコマーシャルライセンスで、要は数万円のライセンスを払えばGPLは免責されますよというものだった。

「Sencha Touch」は現在ベータ版なのでコマーシャルライセンスが準備中となっているが、原則これまでと同じ方式を採用するようだ。しかしながら数多くの批判に対応するためか、パブリックライセンスの場合でも例外事項が新たに設置された。パッケージへSenchaTouchを包括しないこと、SenchaTouchの組み込み方を提示するなどの条件と、配布するパッケージが彼らが提示するオープンソースライセンス（有名なものはほとんど含まれている）で提供する場合に限りGPLの処理（ソースコードにライセンスを書く等）を免責するというものだ。より詳細な説明は彼らのライセンスページ」を参照されたい。

iPadやスマートフォンが大ヒット中のなか、「スマートフォン対応アプリ」のニーズは確実に高まっている。これからの技術的な幅を広げるためにも、ぜひチェックしておきたいフレームワークである。

Ext JS - kurz & gut

作者: Aron Homberg

出版社/メーカー: O'Reilly Vlg. Gmbh & Co.

発売日: 2011/06

メディア: Perfect

クリック: 50回

この商品を含むブログ (1件) を見る

Ext JS入門―リッチUIなWebサイトをつくるAjaxフレームワーク

作者: 古籏一浩,石丸健太郎

出版社/メーカー: 秀和システム

発売日: 2009/07

メディア: 単行本

購入: 5人クリック: 131回

この商品を含むブログ (16件) を見る

2010年6月11日金曜日

Google Apps + Federated Login

Google Apps SDK 1.3.4から、OpenIDによる認証がサポートされるようになった。

最近はKayFrameworkでアプリを作っているのだが、Kayは早くからOpenIDに対応してGoogle Marketplace用のアプリもサポートしていた。今回のSDKのバージョンアップでKayの独自実装は延期となり、新たな統合方法が検討されている。

現在開発しているアプリではGoogle Appsによるアカウント認証を行うためいろいろと調査した。認証方法にさほど変更はなく、create_user_loginメソッドに以下のパラメータが追加されている。

Function

The google.appengine.api.users package provides the following functions:

create_login_url(dest_url=None, _auth_domain=None, federated_identity=None)

_auth_domainとfederated_identityパラメータだ。(Federated Login周りの情報は現在英語版でしか提供されていない）

Google Appsでログインするには_auth_domain=None, federated_identity='Google Appsのドメイン’でOKだ。（このあたりの情報はあまり出揃っていないようだ）

実際稼働させてみるとGoogleApssアカウントへの認証へ飛ばされる。もしAppsのロゴなども変更していればそれらも反映されている。

Kayにどうやって組み込もうかとあれこれ考えたが、やっぱり手っ取り早く@apps_login_requiredデコレータを自作することにした。

もともとのkay.auth.decorators.login_requiredのcreate_login_urlの部分を変更してOK。

さて、この時に認証先のドメインをどうやって取得するかが問題となった。

Google Market PlaceであればManifestのURLにドメインを組み込んでセットアップを行うのでその時に情報はあれこれ取得できるだろう。

今回開発しているアプリはMarketplace用ではなく、Google Appsへドメイン追加でアプリを追加している。また独自ドメインでエイリアスを設定している。

独自ドメインでAppsへ登録したなら、その情報を使えばいいじゃないかということでいろいろと調べた。環境変数のSERVER_NAMEでホスト名は取得できるが、そこからドメインを推測するのは避けたい。AUTH_DOMAINかと思って試したが、gmail.comからかわらず・・。

いろいろ試してようやく見つけることができた。

Google Apps Engineで作ったアプリを、Google Appsへドメイン許可して登録すると以下の環境変数が追加される。

・HTTP_X_ZOO: 'app-id=アプリケーションID,domain=GoogleAppsドメイン'

・HTTP_X_GOOGLE_APPS_METADATA: 'domain=GoogleAppsドメイン’

これらの環境変数は独自ドメインでアプリにエイリアスを登録した時にのみ付与される。（appspot.comの場合は付与されない）

Federated Loginを使用した場合はその他にもFEDERATED_IDENTITYやFEDERATED_PROVIDERなども追加される。（DATACENTERなんていう変数も・・）

また、もうひとつの注意点としてFederated LoginでGooleAppsの管理者アカウントへログインした場合でも、is_current_user_admin()がTrueにはならない。あくまでアプリの管理者リストに登録されている場合にのみTrueが返される。（appspot.comの管理サイトで管理者リストにメールアドレスを登録する必要がある）

これで、AppsEngineで作ったアプリをドメイン追加でApps認証させることができるようになった。

2010年5月22日土曜日

GAE for Business

　Google Apps Engineで新しいサービスがアナウンスされた。

Google Apps Engine for Business

　Google Apss Engineのエンタープライズ向けのサービスである。下記のサイトでロードマップが提示されている。

Google Apps Engine for Business Roadmap

　変更内容はたくさんある。技術的な観点で言えば以下の２点はこれまでビジネス利用ではネックとされていただけに非常に大きなポイントだ。

SQLデータベースのサポート

独自ドメインSSLの実装

　GAEがこれら２つをサポートすることで、ビジネス用サービスとしても非常に強力なプラットフォームとなる。（ロードマップで上記２つは年内プレビューリリース予定となっている）

　その他にも以下のような内容が予定されている。

集中管理サイトの提供

価格帯の変更

　集中管理サイトでは、管理下にあるアプリを一括管理できるインターフェースが提供され、認証などの設定が行えるようになる（こちらはプレビューリリースされた）。また、これまでは各アプリごとにDNSの設定が必須だったが、これらをサブドメインで一括管理するなどの機能が提供されている。

　価格体系は以下のようになる。

Each application costs $8 per user, up to a maximum of $1000, per month.

各アプリごとに、$1,000（約１０万）を上限として各ユーザーあたり月額８＄。

　つまりGAE for Businessでは従量制ではなく、ユーザー単位のコストで決定される。これにより、GAE for Businessでは、GoogleApps Permium Editionと同様SLAで99.9％の動作保証を付けている。価格もユーザー単位で計算しやすく、SLAもつけている点でビジネス的には利用はしやすいだろう。これまでのGAEは利用予測が難しいコンシューマー向け、企業向けサービスはFor Businessというすみわけを狙っていると思われる。

　また、GAEのSDKも1.3.4へバージョンアップしており、OpenID及びOAuthによる認証のサポートがExperimentalながらサポートされるようになった。これにより認証設定が柔軟になり、GAEの適用範囲が広がったと言える。（Google Apps Marketplace対応もかなり楽になると思われる）

　今回のアナウンスで、Googleは本気でGAEをビジネスプラットフォームとして位置づけるという戦略が伺える。独自ドメインSSLやSQLDBのサポートなど、ユーザーの声を拾い上げてウィークポイントを確実に埋めつつある。マネタイズで頭を悩ますコンシューマー向けと違い、ビジネス向けはビッグマーケットだ。Google Marketplaceの動向もあわせてGoogle For Businessの動向は注目だ。

2010年5月21日金曜日

Google Storage

　今週はGoogle IOが開催されていることもあり、Google関連のリリースが目白押しだ。

Google Apps Engine for Business等の他にも気になるサービスがリリースされた。

Google Storage

　現在Labの位置づけではあるが、RESTfulなインターフェースをもつGoogleのストレージサービスである。そう、Google版S3である。

　Google Apps EngineではBlobSotreの取り扱いの制約がきついため、大きなデータを取り扱うアプリには他のサービスとの連携が必要であった。このサービスを利用すればEC2+S3のようなシステムがGAE＋Google Storageで実現できるようになることを戦略的に考えていると思われる。

　Storageとはいっても一般的なファイルシステムでいうネストした構造はサポートしていないようで、Bucket（バケット、バケツのこと）と呼ばれるコンテナ単位でデータを取り扱う。これはApps Engine同様、スケールアウトのしやすさを設計ポリシーとしているためだろう。

GooglePythonベースのコマンドラインツールGSUtilのほか、Webアプリベースの管理ツール「Google Storage Manager」が提供されている。

サービス自体はこれからという感じだが、Google Apps Engineの開発に携わる人にはうれしい機能だ。

2010年5月17日月曜日

クラウドエキスポ

今月12日から14日まで東京ビックサイトで開催されたクラウドEXPOへいってきた。

参加企業も来場者も多く、早々と秋の第2回目が決定したようである。やはり「クラウド」というキーワードは勢いがついており、ようやく日本でもビジネスレベルでのクラウドが始まるなという感じであった。

その反面、クラウドという言葉が非常にあいまいな定義であると同時に、サービス化が進んでいる英語圏とではだいぶ開きがあるという日本の実情も垣間見えた。

何をもってクラウドとするかといえば次々と言葉が出てくる。「仮想化」「伸縮性」「所有から利用へ」等など。しかし、「ASPと何がちがうの？」といわれると、言葉が少なくなる。既存のサービスで、「データの保存先にAmazonが選べるようになりました」といわれても、正直困る。

「所有から利用へ」というフレーズはASPの時代のまんまなのでそのままにしておくが、「仮想化」がクラウドだといわれると、何かひっかかる。本当に仮想化がクラウドの本質なのかと。

確かに、仮想化はクラウドの中核技術である。それによってもたらされるコストカットもユーザーの最大の関心事だ。しかし、コストカットは仮想化によってもたらされたというよりも、技術的な部分も含めて「企業努力」の賜物だ。別に仮想化でなくてもできる。要は仮想化が「サービス提供側の理屈」に聞こえるのだ。

質問を変えよう。「ASPではできなかったことは何か？」

やはり大規模なインフラと仮想化を駆使した「伸縮性」だと考える。特にコンシューマー向けのソリューションはアクセスの予測が難しい。アクセスが増えれば仮想化を使ってスムーズにリソースを伸縮し、莫大な初期投資をかけずとも、従量制の料金でサービスが開始できるという点では利用者側のメリットも大きい。

EXPOでIaaSのサービスを提供している企業をいくつか回ったが、EC2のような自動でリソースを伸縮するようなサービスを提供している企業は皆無だった。コストカットはもちろん、機器の調達が要らない、数分でホストを追加できる等、仮想化のメリットはあるにせよ、その追加自体が手動ということはアクセスの状況に注視し続けなければ対応できない。

よく、クラウドを3つのレイヤーに分ける。英語圏では既にそれぞれのレイヤーに巨人がいる。SaaSでは、Google Apps、Office Live、SalesForce等、PaaSではGoogle Apps Engine、Azure、IaaSではAmazonなど等。「仮想化」だけではとても太刀打ちできそうにない。仮想化とコストカットだけに安易に向かうと、自らの首をしめるような結果にならないか。

クラウドはまだこれからだ。その「成長ののりしろ」もたくさんある。クラウドと称した「安価な専用サーバー」も有効なソリューションのひとつではあるが、「クラウドらしさ」を活用した次のステップが重要だと感じさせられた。

2010年4月22日木曜日

Google Apps Marketplaceのよくある勘違い

Google Apps Marketplaceは、今年3月にGoogleが発表したGoogle Apps向けのアプリケーションやサービスを販売するサイトだ。

アプリケーションをクリックひとつで自社ドメインのGoogle Appsへインストール・統合することができ、今後のサービス販売の場としても注目するべきサイトのひとつであろう。

Google Apps Marketplaceのよくある勘違いとして、「Google Appsに統合されるわけだからGoogle Apps Engineで開発する必要がある。」というのがある。（私もはじめはそう勘違いしていた・・）

結論から言えば「Google Apps Engineである必要は全くない」のである。それどころか、サイトを検索するとGoogle Appsとは一見関係のないようなものから、インストール代行などアプリケーションではないものも売り出されている。（関連サービスということなのだろう）

Googleのドキュメントによれば、Marketplaceに登録するには以下の要件を満たしてくれとある。

OpenIDによるシングルサインオンを実装してください。

アプリケーションマニフェストを書いてください。

ユニバーサルナビゲーション（Google Appsのページ一番上にあるメニュー）をつけてください（どうやらオプションのようだ）

Google Appsのメールやカレンダーと連携する場合はGoogleDataAPIを使ってください。

以上である。

３と４はオプションなので実際は１と２が必須項目である。

言い換えれば「自社のサービスにOpenIDを実装すれば、すぐにMarketplaceに出展できる」のである。

もちろん、OpenIDの実装のほかにもマニフェストで設定するページやそのたGoogle Appsとの連携などに若干の開発は必要であろう。

要は、すでにユーザーに提供しているASPやサービスがあれば、ある程度の開発だけでMarketplaceに出展できるということだ。

わかりやすい例として、ZoHoがある。

SOHO向けの機能（本当にたくさんある）をクラウドで提供する会社だが、彼らのサービスはMarketplaceでも販売されている。彼らは既にあるサービスをOpenID化して、Marketplaceに提供しているのだ。試してみると（無料版もある）、認証や管理はGoogle Appsと連動しているが、実際のサイトでは彼らのもともとのサービスと全く代わりがない。（それはそれでGoogle Appsとの連動が薄いと評価されているが）

整理すると以下のようになる。

Google Apps Marketplace

Googleが決済代行をするGoogle Appsユーザー向けのアプリケーション及び付帯サービスのコマースサービス。

認証の連動など、いくつかの条件がクリアできれば、稼動要件などは問わない。

提供するサービスはアプリケーションである必要もない。

Google Apps Engine

Googleのインフラを使って、伸縮性のあるWebアプリケーションを開発できる。

独自ドメインでサービスを提供

ここまで書くとお分かりだろうが、Google Apps Engineで開発したアプリはMarketplaceですぐ使えるというものではなく、あくまで「自社ドメインで稼動するWebアプリをGoogleのインフラで作った」という位置づけである。

Marketplaceとはあまり関係ないというか、むしろ別のサービスと考えたほうがすっきりする。

Google Apps Engineは独自ドメインのSSLが不可（いろいろと組み合わせれば回避可能だが）だったり、メール送信や外部のURLアクセスに件数制限（有料設定でコントロール）があるなど、サンドボックス的な制約も多い。しかしながら、数百万ユーザーのアクセスでも耐えるであろうGoogleのインフラを考えれば非常に魅力的だ。

専用サーバーなどを自由にカスタマイズして作るWebアプリも魅力だが、ユーザーの増加が読めないコンシューマー向けのサービス等では、拡大に伴うコストは非常に高くなる。そういう場合の選択肢としてGoogle Appsなのだと考える。（過去にサービスを立ち上げる前から「100万ユーザーでも耐えられるようにつくってくれ」と頼まれたことがある。まだサーバー2台で稼動しているが・・）逆に言えばアクセスや用途が限定されているのであれば専用サーバーのほうが有利なケースも多い。

実際の落としどころで言えば、「用途や内容によってGAE、AWS、専用サーバーを組み合わせて実装する」というところであろう。（言語の選定やライブラリ・フレームワーク等は非常に悩ましいところだが）

P.S. AMAZONでもメールの送信数には制限があるようですね。やっぱりそうだよね（笑）

2010年4月18日日曜日

app-engine-patchの終了とDjango-nonrel

Google AppsでDjangoを使うためのパッチ集であるapp-engine-patchが、バージョン1.0.2.3をもって開発終了した。

といっても完全になくなったわけではなく、Google Apps +Djangoの別のプロジェクトであるDjango-nonrelへ引き継がれた。

django-nonrelではapp-engine-patchのように「djangoがGAEで動くようにパッチを当てる」という方向性とは違い、「Djangoで非リレーショナルDBをサポートする」というプロジェクトで、そのDBの中のひとつにGoogle Apps Engineのモデルが含まれているというもの。GAEのモデルのほかにもMongoDBやAmazoneのクラウドサービスのひとつであるSimpleDB等がサポートされる予定である。

実装方法としてはbackendtemplateと呼ばれるデータProxyのような役割を果たす低レベルAPIのレイヤーをモデルに入れるという方法。パッチがでかくなりすぎてしまったapp-engine-patchよりは正しい方向性だと思われる。

まだ実装されたばかりでこれからという感じだが、GAEだけでなくAWSでも使えるとなれば「Django LOVE！」な人は要チェックだ。

2010年4月7日水曜日

April Fool

ネット上のあちこちでApril Foolネタが掲載されているが、KLabのニュースリリースは大笑いしてしまった。

KLabニュースリリース

2010年3月29日月曜日

GAEでの言語選択

リリース当初は様子見という感じでみていたGAEも、そろそろ本気で取り組もうということでこの1ヶ月、改めて最新バージョンの検証やテスト等をおこなってきたが、現時点での結論は以下のとおりだ。

「Apps Engineに最適化されたPythonのフレームワークをつかえ」

おのずとKayフレームワークなのだろう。（腕に覚えのあるひとならフレームワークをつくってもいいのだが）

Java使いであればいろいろとフレームワークを使いたいだろうが、はっきりいって「遅い」のである。得てして重量級のフレームワークが多い中、選択肢としてはSlim3くらいであろう。このあたりに関してはその作者でもあるひがやすを氏もブログで述べている。id:higayasuo:20100319:1268984735

ひが氏が指摘しているようにJavaはその構造上、SpinUp, SinDownでインスタンスを生成するまでの時間がかかることがネックとなっている。

上記の理由からも、現時点でGAEJ＋jRubyやGAEJ＋Quercus(PHP)は論外ということになるだろう。（Amazonへどうぞ）

誤解のないように言うが、Javaが使えないのではなく「GAEでJavaはまだ発展途上だ」と考えている。速度や安定性の問題は今後GAEJがアップグレードしていくなかで解決されていくだろう。フレームワークもひが氏がSlim3を中心にGAEにコミットしている（と勝手に煽る）ので、今後改善されていくだろう。

djangoの記事でも書いたが、SpinUp+SpinDownの時間の問題や、データモデルが根本から変わるなど、クラウド開発ではこれまでとは違う「常識」が必要になるとあらためて感じさせられた。

2010年3月27日土曜日

GAEJ + Struts2

GAEJでStruts2を試してみようと環境構築。

用意した環境は以下のとおり。

・Eclipse3.5

・Google Plugins for Eclipse (3.5)

・Struts 2.1.8

Eclipseはそのままインストールで展開。

起動後に「ヘルプ」「新規ソフトウェアのインストール」、ダイアログの作業対象に以下のURLを入力。

http://dl.google.com/eclipse/plugin/3.5

あとはWizardにしたがって進めるとインストール完了。

Eclipse再起動後、新規プロジェクトでGoogleAppsのプロジェクトを作成。

Strutsで必要なライブラリをwar/WEB-INF/libへコピー

・commons-fileupload-1.2.1.jar

・commons-logging-1.0.4.jar

・freemarker-2.3.13.jar

・ognl-2.6.11.jar

・struts2-core-2.1.6.jar

・xwork-2.1.2.jar

上記6つが最低限必要。コードビハインドを使うならstruts2-codebehind-pluginも追加。

簡単なアクション、JSPを書いて実行してみる。

JSPにエラーが発生している。そうか、JDKが必要なんですね。JDKをインストールして

JAVA環境を設定。

今度はXalanがないというエラーが発生。Apacheプロジェクトからダウンロードしてきて

Xalan、Xercesのライブラリをlibへ追加。

ようやく動作確認。

久しぶりにJavaを触って、頭がすっかりLLになってしまっていることに気がついた。

2010年3月11日木曜日

Google Apps Marketplace

Googleが開発したGAEのソリューションを販売できる仕組み「Google Apps Marketplace」（以下GAM）を開始している。

Google Apps Marketplace

Google Appsを利用しているユーザーはクリックしてドメインを入力するだけでGmailやGoogle Calendar等と高度にインテグレートされた機能を利用できるというもの。

たとえば以下のような機能が販売されている。

myERP.com

CRM, Sales, Projects, Purchasing, Inventory, Accounting

1アカウント29ドル/月、2Userまで無料

eFAX

メールによるFAXサービス

16.95ドル/月

その他ワークフロー関連からビジネスパック、独自ドメインApps環境設置代行まで様々。

利用料金は以下の記事によればアプリの登録に100＄、その後販売価格の20％をGoogleが徴収する仕組みのようだ。

C-NET

Google announces business app store for Google Apps

Developers will have to pay a one-time $100 fee to list their applications in the store, and Google will get a 20 percent cut of all applications sold through the store

iPhone大躍進の理由の1つにAppStoreがあげられると思うが、ソフトウェア開発をワールドマーケットへ直結させた成功パターンがビジネスモデルとして認知され、GAMもその流れできたというところか。App Storeはいわゆるエンタメ系が多いが、GAMはその性格から業務系やグループウェア系等、ビジネス向けのアプリが占める。

日本向けのサービスはまだ探せなかったが、今後増えていくものと思われる。イントラネット系のアプリを開発しているならマーケットとして注目すべきだろう。

2010年3月5日金曜日

GAE+django

pythonのフレームワークであるdjango。非常に評価しているフレームワークのひとつである。DRYやルースカップリング等の設計哲学、非常にスマートな実装で素晴らしい。

しかしである。Google Application Engine（以下GAE)を久しぶりに動かしてみて考えたのだが・・・・。

「GAEではdjango以外の選択肢も考えたほうがいい」

と思った。

確かに以前と比べてdjangoのインストールは非常に簡単になっている。SDKをインストールした後、app-engine-patch-1.0.2.3.zipをダウンロードし、展開するだけである。

（django本体はzip形式でパッチに含まれており、zipimportされるので別途インストールする必要はない。ネット上には0.9時代の情報が多く混乱した。ドキュメント読めばわかるのだが）

GAE SDK 1.3.1

http://code.google.com/intl/ja/appengine/downloads.html

app-engine-patch 1.0.2.3

http://code.google.com/p/app-engine-patch/

SDKもGUIがついて、コマンドラインからmanege.pyを触らずともボタンひとつで開発サーバーが立ち上がる。いろいろと設定せずともEclipse+PyDevとSDKだけでさっとクラウド開発環境が作れるところまで出来ており、非常に手軽だ。

問題はここからである。

現在の時点ではこのGAE＋djangoではdjangoのモデルが使えないのである。GAE＋djangoではGAEで提供されるGoogleAPPのモデルを使用するしかない。そこで世界中の有志がGAEモデルで「djangoらしく」使えるようにと、様々なレベルの修正を行ったおかげで、リリース当初は使えなかったadminインターフェースも現在のバージョンではGAEモデルで使えるまでになっている。

しかし、そのおかげでパッチがパッチと呼べないほど肥大化してしまった。（本体が入っているパッチって・・）ここまでくるとパフォーマンスへの影響も大きくなってくる。

djangoはモデルの生成からform/validation、tempalte、そしてほぼ自動化された管理画面と、モデルを中心とした設計から最低限のコストで高品位なアプリを生成できるところが最大の魅力だ。モデル中心のフレームワークでモデルの構造が変わるわけだから、それは上記のような結果になるのも当然である。

GAEのモデルが悪いわけではない。それどころかdjango+patchでは「GAEモデルの強力な部分が生かされない」ところが問題なのだろう。触ったことがあるひとならわかると思うが、GAEのモデルはRDBにはない拡張が行われている。動的プロパティ（カラム）やテーブルの継承（Postgres等でサポートされているものに近い）が行える。RDBというよりオブジェクトデータベースのほうに近い実装となっている。これら2つの機能を独自に実装したRDBは既にあるが、GAEのようなオープンなクラウド環境で提供されているという点では大きな違いといえる。

上記2つの機能はモデル設計を劇的に変える。例えば継承を使えば以下のようなモデルを作れる。


from google.appengine.ext import db
from google.appengine.ext.db import polymodel
from google.appengine.api import users
from datetime import datetime

class BusinessObject(polymodel.PolyModel):
creation_date = db.DateTimeProperty()
creation_user = db.UserProperty(auto_current_user_add=True)
modification_date = db.DateTimeProperty()
modification_user = db.UserProperty(auto_current_user=True)
def __unicode__(self):
return self.key()
def save(self):
if self.is_saved() == False:
self.creation_date = datetime.now()
self.modification_date = datetime.now()
super(BusinessObject, self).save()

class Contact(BusinessObject):
title = db.StringProperty(required=True)
caption = db.StringProperty()
phone = db.PhoneNumberProperty()
fax = db.PhoneNumberProperty()
postal_code = db.StringProperty()
address = db.PostalAddressProperty()
def __unicode__(self):
return self.title

class Company(Contact):
url = db.StringProperty()

class Person(Contact):
last_name = db.StringProperty(required=True)
first_name = db.StringProperty(required=True)
last_name_caption = db.StringProperty()
first_name_caption = db.StringProperty()
mail = db.EmailProperty()
mobile_phone = db.PhoneNumberProperty()
url = db.StringProperty()
def save(self):
self.title = '%s %s' % (self.last_name, self.first_name)
self.caption = '%s %s' % (self.last_name_caption, self.first_name_caption)
super(Person, self).save()

上記のモデルはPerson及びCompanyはContactとしても扱われる。PersonやCompanyにクエリを実行すればそれぞれが返されるのは当然だが、Contactにクエリを実行するとCompany、Person及びContactを全てを含めて返される。もちろんこれらのオブジェクトは全てBusinessObjectの内容も継承している。（GAEで提供される管理画面からデータベースをのぞくと、これら全てのデータはBusinessObjectのテーブルに含まれている。ちなみに現時点では継承と動的プロパティを同時に使うことはできない。）

app-engine-patchのサイトでもトップページで以下のように述べている。

We might also recommend that you check out the Kay Framework if you're looking for a very django-like framework that is built specifically for App Engine (no Object To Relational To Object data mapping issues or other monkey-patch warts).

「とてもdjangoライクでGAEに特化して作ったKayフレームワークもあるよ。チェックしてね（モデルリレーションの問題やぐちゃぐちゃなパッチもないよ）」

Kay Framework

http://code.google.com/p/kay-framework/

もちろん、djangoの優れた設計哲学のおかげで、パーツとしての活用（特にテンプレート）は有用だろう。しかしながら上記のようなデータ構造の違いやパフォーマンスの問題も大きい。（処理負荷で課金するクラウドではなおさらだ）

djangoは「djangoらしく」、GAEでは「GAEらしく」というアプローチのほうが正しいのだろう。