GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Alex Blewitt , 翻訳者 金森 諭 投稿日 2008年4月7日
先日開催されたEclispeCon(source)には1400人を超える聴衆が集まり300以上のプレゼンテーションやチュートリアル(source)が行われた。EclipseConは一昨年と昨年に引き続きOSGi DevCon(source)と共同で開催された。
開幕での大きなニュースはEclipse Runtime、略してEclipse RT(サイト・英語)と呼ばれるトップレベルプロジェクトの発表だった。ApacheのようにEclipseではプロジェクトがトップレベルプロジェクト(top level projects)とコンポーネント(components)に分けられている。トッププロジェクトではレポジトリや時にはメーリングリストなどが共有され、コンポーネントではSWT(source)やECF Jabber(source)のサポート機能のような特定の機能を開発している。
新しいランタイムプロジェクトはEclipseのOSGi(SOAによりネットワーク上のサービス/コンポーネントを容易に利用するための仕様)ランタイムであるEquinox(サイト・英語)プロジェクトやEclipse Communication Framework(サイト・英語)のようなキーとなるコンポーネントプロジェクトを行うことを目的にしている。さらに、潜在するランタイムの分野でより広範囲でコミュニティ活動を盛り上げるため、新しくEquinox Portal(サイト・英語)も作られた。これはしばしば(Javaの)IDEとして認知されるEclipseあるいはEclipse Platformとの違いを明確にするため、それらとは異なるものとして作られている。
Eclipse Foudationはオープンソースのランタイム技術を開発し促進させるための新しい第一歩を今日発表しました(source)。この技術はOSGiに準拠した軽量ランタイムであるEquinoxをベースにしています。Eclipseは開発ツールとして広く知られていますが、今回の第一歩はランタイム技術にフォーカスしたEclipseオープンソースプロジェクトについてのコミュニティを作ります。そのランタイム技術はモバイル、デスクトップ、サーバ環境においてソフトウェアの開発・デプロイをより柔軟にする方法を提供します。
Eclipse FoundationのエグゼクティブディレクターであるMike Milinkovich氏は「ランタイムにフォーカスしたEquinoxコミュニティの開始は自然な流れである」と語っています。「我々のコミュニティは既にRCPやRAP、Swordfish、EclipseLink、ECFといったランタイムプロジェクトを開発しています。この新しいコミュニティはソフトウェアの開発やデプロイを容易緒することに焦点を当てた付加的なプロジェクトをまとめたり、促進させる手助けとなるでしょう。」
EclipseConでのもう一つの大きなニュースはEclipseLink(source)がJPA2.0(別称JSR317)(source)のリファレンス実装に選ばれたことだった。このJava Persistence APIはJavaEEおよびJavaSE環境での永続化およびORマッピングの管理を行うJava APIだ。
Eclipse Foundationは、Java(TM) Persistence API(JPA)2.0についてのJSR317標準を主導するSunが、そのリファレンス実装としてEclipseLinkを選んだことをお伝えします(source)。このEclipse Persistence Services Project(EclipseLink)は、Oracleが主導していて、キーとなる永続化の標準仕様をサポートするオープンソースのランタイムフレームワークを開発しています。EclipseLinkプロジェクトは、複雑なマッピング、パフォーマンス、スケーラビリティを実行するためのリッチサービス、そしてエンタープライズJavaアプリケーションに必要とされるより進んだ機能を提供します。
JSR 317のJava Persistence APIは、Java Platform Enterprise Edition(Java EE)およびJava Platform Standard Edision(Java SE)環境で永続化とORマッピングを管理するためのJava APIです。リファレンス実装として、EclipseLinkはJavaSE・JavaEE両方において実績ある商用品質の永続化手段を提供することになるでしょう。
Eclipse FoundationのエグゼクティブディレクタMike Milinkovich氏はこう言いました。「JSR 317のリファレンス実装としてEclipseLinkが採用されたことは、Javaソフトウェアアプリケーションの開発を効率化するためにJCPと Eclipseのコミュニティが一緒になって取り組んだ素晴らしい実例です。」「このようにオープンなコラボレーションが行われることで、技術を広く採用されるよう促進がされます。」
EclipseLink(source)プロジェクトが昨年Oracle(サイト・英語)から寄贈されたTopLink(サイト・英語)によって始まったことを考えると、今回のリリースは特に注目すべきことだ。そして今後Glassfish 3(source)にも採用されようとしている。SunがEclipseプロジェクトに今すぐ参加することは考えにくいが、このような協力はみなにとって間違いなく役立つことだ。
最後に、MicrosoftのSam Ramji氏(source)からSWTを利用できるようなWPF(.NETのGUI基盤)上で動くリソースを投じる(source)という展望を示した。ただしこれはまだ合意がされていない。さらに、Windows CardSpace(ID管理技術)(source)のチームがID管理プロジェクトHiggins(サイト・英語)に取り組みを始めた(最近そのプロジェクトからHiggins 1.0)(source)がリリースされた)。
Eclipseにはこれまでも健全なエコシステムがあった。最近の唯一の大きな変化はOSGiランタイムの採用だったが、Eclipseの将来にについての健全な議論がされている。今年のEclipseConでは、カンファレンス後のセッション(source)(メモ)(source)でE4(Eclipse 4.0)(source)をターゲットにしたプレゼンテーションが行われていた。あるEclipseセッションでのトピックは、ユーザインターフェースとしてブラウザを使うこととサーバ上にコードを置くことだった。これによってどこでもログインしてコーディングが可能になる。この取り組みの結果の一部として、より非同期なAPI (ウェブベースの非同期環境で動作する)が作られていて、これは将来Eclipse3.xで取り入れられる可能性がある。今の時点ではE4は時間とともに進展するであろうアイディアの集まりで、いずれ目にすることになるアイディアの集まりだ。それが実現するまでにはいくつかのデモ(source)が見れるはずだ。
Rich AJAX Platform(source)では既存の実装をウェブブラウザ内で変換するコード(デモもある(source))が作られていて、ごくわずかなコード変更をする(source)だけで既存のGUIを実行することができる。ただしデータの永続化には注意が必要でServlet風のやり方でハンドリングしないといけない。
ここ3年間、OSGi DevConがEclipseConと共に開催されている。Eclipseは3.0からOSGiランタイムを使用してて、今ではBEAのmicroServicesArchitecture(サイト・英語)やIBMのWebSphere(source)(将来はJBossJ(source)も)のような多くのエンタープライズアプリケーションがOSGiランタイムの上に構築されている。 OSGi実装としてFelix(サイト・英語)(旧Oscar(サイト・英語))、ProSystのmBedded Server(サイト・英語)、Knopflerfish(サイト・英語)、そしてEquinox(サイト・英語)などがあることを考えると、特定の性能を満たすランタイムやその技術供与に対する需要があるようだ。
昨年までの2,3年は、OSGiは何か、OSGiはどのように使うか、といったビギナートピックが多かったが、今年は特定のことに特化したトピックが数多くあった。例をあげると、Spring Dynamic Modules(旧称Spring OSGi)の使用(PDF・英語)についてや、OSGiをAndroidで使う(PDF・英語)ことやOSGiを備えたカスタムハードウェアを使う(PDF・英語)BugLabs(サイト・英語)といったハードウェア関連の話があった。さらに、J2MEプラットフォームでユーザインターフェイスを構築する(Nokiaも使用するeRCP(サイト・英語)もサポートされる)ためのOSGiプラットフォームとしてSprint Titan(サイト・英語)(Windows Mobileデバイス向けのJavaプラットフォーム)が発表された。Sprint Titan開発プラットフォームについて近くウェブセミナ(source)が開かれることになっている。
JSR 277(source)とJSR 294(source)で定められたゴールがOSGiへの準拠(JSR 291(source))であること、top 25 REF(source)(機能拡張要求)に押し上げられるほど優先度が高くなっていっているSun bug 6650394(source)(モジュールシステムの相互運用性を求めて報告)、そしてマルチベンダによるOSGiの浸透およびマルチベンダ以外のベンダでのOSGiの採用を考えると、数多くのモジュラシステムが将来もOSGiをベースにし続けることだろう。
まとめ
他のカンファレンスと同様、EclipseCon(とOSGi DevCon)はアイディアと実装について人と会い話をする場であり、今年も例外ではなかった。そして特定のプロジェクトウェブサイトについて議論する場というよりは、より広いコミュニティの場でもある。ここで行われたプレゼンテーションはそのうちEclipseConで利用可能になるものもある(source)。
Eclipse Runtimeプロジェクト(source)が創設されたことはEclipseが単にIDEのためのものではないことを明らかに示している。(RAP(サイト・英語)や来たるE4(source)を使った)ウェブ、Rich Client Platform(サイト・英語)を使ったクライアントサイド、eRCP(サイト・英語)を使ったモバイルクライアント、そしてEquinoxサーバ(サイト・英語)を使ったサーバサイドのすべてにおいて、Equinoxベースのシステムは十分に実績のあるモジュラアーキテクチャとして成長しそうな予感がある。
原文はこちらです:http://www.infoq.com/news/2008/03/eclipsecon2008
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
他の記事(例えばwww.infoq.com/jp/news/2008/04/jsr277-silence)を確認していただきたいのですが、OSGi(JSR 291)とJSR277&JSR294は代替できる技術で、いわばライバル関係にある技術ではないでしょうか。原文もそういう書き方がされていたと思いますが…。私自身はOSGiに準拠していってくれた方がみんな幸せになれると思います。ただ、原文から違った解釈になってしまっているのはよろしくないと思い、敢えて書かせていただきます。
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
1 comment
スレッド表示 返信