NetBeansのScalaプラグインの出来がよいとの噂があったので、ダウンロードしてみた。
日本語の識別子には対応していないみたい。がっくし。
SimpleModelerのScala DSLは、IDEのサポートが受けられるとかなり使いやすくなるはずなので、期待してみたのだけれど、日本語の識別子が使えないと現時点では使えないなぁ。
2009年3月27日金曜日
XMLリテラル
Google App Engine用ドメイン・オブジェクトCRUD MVCでは、ScalaのXMLリテラルがとても役になった。
生成するHTMLをXMLリテラルでそのまま記述できる。その上で、「{」「}」で囲んだ所にScala関数を評価した結果が挿入される。そのままテンプレートエンジンである。
作成したXMLをテキストとして出力するのはこんな感じ。
ScalaのXMLはこの他にも色々便利な機能がある。
Web系のプログラムだと何かとXMLやHTMLを使うことが多いので、言語ネイティブのXMLサポートは重要ですね。
生成するHTMLをXMLリテラルでそのまま記述できる。その上で、「{」「}」で囲んだ所にScala関数を評価した結果が挿入される。そのままテンプレートエンジンである。
val html =
<html>
<head>
<title>Show {capitalizedTerm}</title>
</head>
<body>
<h1>Show {capitalizedTerm}</h1>
<table class="datasheet">
<tbody>
{
for (attr <- entity.attributes.toList) yield {
<tr>
<td>{attr.name}</td><td>{{{{doc.{attr.name} }}}}</td>
</tr>
}
}
</tbody>
</table>
<table class="action">
<tr>
<td><form action={getActionPath("edit")} method="get"><input type="hidden" name="key" value={getIdCode} /><input type="submit" value="Edit" /></form></td>
<td><form action={getActionPath("destroy")} method="post"><input type="hidden" name="key" value={getIdCode} /><input type="submit" value="Delete" /></form></td>
</tr>
</table>
<table class="menu">
<tr><td><a href={getActionPath("index")}>Index</a></td><td><a href={getActionPath("new")}>New</a></td></tr>
</table>
</body>
</html>
作成したXMLをテキストとして出力するのはこんな感じ。
XML.write(out, html, entityContext.textEncoding, false, null)
ScalaのXMLはこの他にも色々便利な機能がある。
Web系のプログラムだと何かとXMLやHTMLを使うことが多いので、言語ネイティブのXMLサポートは重要ですね。
2009年3月26日木曜日
Google App Engine CRUD MVC動いた
SimpleModelerドメイン・オブジェクトに対するGoogle App EngineのCRUD MVC&Serviceが動いた。ふぅー。
Model, Serviceに加えて、ViewとControllerも自動生成できるようになった。
Web MVCの自動生成器を作ってみて、Webアプリケーション開発が大変なことを実感。
ここが自動作成できたら、かなり便利なはずである。
今はCURDの範囲だけれど、もう少し自動生成の範囲を広げることができると考えている。
この実現のメカニズムとしてdocumentとstateMachineを作りこんできた。また、昨日書いたように画面遷移モデルをサポートすればさらに自動生成の範囲が広がる。
ここからは先が長そうなので、様子を見ながらぼちぼち取り掛かることにしたい。
Model, Serviceに加えて、ViewとControllerも自動生成できるようになった。
Web MVCの自動生成器を作ってみて、Webアプリケーション開発が大変なことを実感。
ここが自動作成できたら、かなり便利なはずである。
今はCURDの範囲だけれど、もう少し自動生成の範囲を広げることができると考えている。
この実現のメカニズムとしてdocumentとstateMachineを作りこんできた。また、昨日書いたように画面遷移モデルをサポートすればさらに自動生成の範囲が広がる。
ここからは先が長そうなので、様子を見ながらぼちぼち取り掛かることにしたい。
2009年3月25日水曜日
Google App Engine MVC
次の組合せでGoogle App EngineのMVC&Serviceが動いた。ふぅー。
Model: 自動生成
Service: 自動生成
View: 金型
Controller: 金型
すっかりPythonプログラマである。
次は、金型をSimpleModelerに取り込んで自動生成する処理の開発。
4月21日のJJUG CCCでデモできそう。
Model: 自動生成
Service: 自動生成
View: 金型
Controller: 金型
すっかりPythonプログラマである。
次は、金型をSimpleModelerに取り込んで自動生成する処理の開発。
4月21日のJJUG CCCでデモできそう。
Webフレームワーク
Google App EngineのWebフレームワークとGoogle App Engine Oil（GAEO)を調査している。
GAEOでURLとMVCの実装を:controller/:actionのコンベンションに結び付けている部分が面白い。一種のリンカですね。
本家のRuby on Railsは:controller/:action/:id.:formatというコンベンションのようだけれど、こういったURLと実装の動的リンク機能(何か名前がついているんだろうなー、以下ではURLルーティングと呼ぶことにする)がRuby on Railsの柱の一つであり、これをGoogle App Engine(GAE)で実現しようとしているのがGAEOということである。
GAEOのCRUD VC自動生成はまだまだ発展途上だと思われるけれど、このURLルーティング機能は現時点でもかなり使える。
と、ここでSimpleModelerのGAE生成器だけれど、GAEOに全面依存するのもリスクがあるので、gaeサービスではGAEのみを使うようにしようと思う。URLルーティングも簡単なものを自前で実装することにする。
これとは別にgaeoサービスでは、GAEOのURLルーティングを活用したプログラムを自動生成することにしたい。
調べてみるとWebのこのあたりの技術はなかなか面白い。こういった処理を実装する場合、メタ・プログラミングを使ってコンベンションによる動的リンクが非常に有効なのでPythonやRubyのような動的言語が大人気なのもよく分かる。
ただ、こういったWeb MVCの実装は、自動生成の格好の対象であることも感じた。
単純な繰り返しのプログラミングは、コンベンションと動的リンクで解決することも可能であるけれど、プログラムの自動生成で解決することも可能である。
プログラムの自動生成をするのであれば、ターゲットのプログラミング言語は静的型付のものでよい。つまり、自動生成を前提にするとテーゲット言語はJavaのみでも、Ruby on RailsやPython Djangoと同等のWebアプリケーションの開発効率が得られると思われる。
開発言語がJava指定の案件でも、Ruby on RailsやPython Djangoと同等の開発効率が得られれば魅了的である。
そうはいっても、RubyやPythonを主力言語として開発している人がわざわざJavaをやるというのも考えにくいので、結局の所、色々な言語の色々なWebフレームワークが並存することになるだろう。顧客が指定するWebアプリケーションの言語やフレームワークも多極化することになるだろうから、どのような組合せであっても対応できるのが開発者側のスタンスとしては望ましい。
こういったニーズに対してSimpleModelerのようなモデル・コンパイラは有力なソリューションである。
今回、Webフレームワークを調べてみて、SimpleModelerでかなりの部分を自動生成できるように感じた。ただし、ユースケースやドメイン・モデルから自動生成できるという意味ではなくて、システム・モデルとして画面遷移モデルなどの専用PIMモデルを定義すればである。
Webのフロントは開発工数も大きい上にバグの出やすいところでもあるし、要件定義から実装までの各段階で試行錯誤が必須の部分なので、PIMモデルからの自動生成ができれば、その効果は計り知れないだろう。
SimpleModeler的には、Scala DSLで定義した専用画面遷移モデルから、画面遷移図と各種Webフレームワーク向け実装の自動生成の機能ということになる。画面遷移モデルとドメイン・モデル、ユースケース・モデルとの連携は確保すれば、上流モデルからWebフレームワーク向け実装まで一気通貫で開発することができる。
GAEが一段落したら、SimpleModelerをそちらの方向に延ばしてみようかな。
GAEOでURLとMVCの実装を:controller/:actionのコンベンションに結び付けている部分が面白い。一種のリンカですね。
本家のRuby on Railsは:controller/:action/:id.:formatというコンベンションのようだけれど、こういったURLと実装の動的リンク機能(何か名前がついているんだろうなー、以下ではURLルーティングと呼ぶことにする)がRuby on Railsの柱の一つであり、これをGoogle App Engine(GAE)で実現しようとしているのがGAEOということである。
GAEOのCRUD VC自動生成はまだまだ発展途上だと思われるけれど、このURLルーティング機能は現時点でもかなり使える。
と、ここでSimpleModelerのGAE生成器だけれど、GAEOに全面依存するのもリスクがあるので、gaeサービスではGAEのみを使うようにしようと思う。URLルーティングも簡単なものを自前で実装することにする。
これとは別にgaeoサービスでは、GAEOのURLルーティングを活用したプログラムを自動生成することにしたい。
調べてみるとWebのこのあたりの技術はなかなか面白い。こういった処理を実装する場合、メタ・プログラミングを使ってコンベンションによる動的リンクが非常に有効なのでPythonやRubyのような動的言語が大人気なのもよく分かる。
ただ、こういったWeb MVCの実装は、自動生成の格好の対象であることも感じた。
単純な繰り返しのプログラミングは、コンベンションと動的リンクで解決することも可能であるけれど、プログラムの自動生成で解決することも可能である。
プログラムの自動生成をするのであれば、ターゲットのプログラミング言語は静的型付のものでよい。つまり、自動生成を前提にするとテーゲット言語はJavaのみでも、Ruby on RailsやPython Djangoと同等のWebアプリケーションの開発効率が得られると思われる。
開発言語がJava指定の案件でも、Ruby on RailsやPython Djangoと同等の開発効率が得られれば魅了的である。
そうはいっても、RubyやPythonを主力言語として開発している人がわざわざJavaをやるというのも考えにくいので、結局の所、色々な言語の色々なWebフレームワークが並存することになるだろう。顧客が指定するWebアプリケーションの言語やフレームワークも多極化することになるだろうから、どのような組合せであっても対応できるのが開発者側のスタンスとしては望ましい。
こういったニーズに対してSimpleModelerのようなモデル・コンパイラは有力なソリューションである。
今回、Webフレームワークを調べてみて、SimpleModelerでかなりの部分を自動生成できるように感じた。ただし、ユースケースやドメイン・モデルから自動生成できるという意味ではなくて、システム・モデルとして画面遷移モデルなどの専用PIMモデルを定義すればである。
Webのフロントは開発工数も大きい上にバグの出やすいところでもあるし、要件定義から実装までの各段階で試行錯誤が必須の部分なので、PIMモデルからの自動生成ができれば、その効果は計り知れないだろう。
SimpleModeler的には、Scala DSLで定義した専用画面遷移モデルから、画面遷移図と各種Webフレームワーク向け実装の自動生成の機能ということになる。画面遷移モデルとドメイン・モデル、ユースケース・モデルとの連携は確保すれば、上流モデルからWebフレームワーク向け実装まで一気通貫で開発することができる。
GAEが一段落したら、SimpleModelerをそちらの方向に延ばしてみようかな。
2009年3月24日火曜日
GAEOのMVC遷移
メモ。
GuestbookController
==create
====r.put()
====/guestbook
==destroy
====Guestbook.get()
====r.delete()
====/guestbook
==edit
====Guestbook.get()
====template/guestbook/edit.hml
======/guestbook/update
==index
====Guestbook.all()
====template/guestbook/index.hml
======/guestbook/new
======/guestbook/show?key
==new
====template/guestbook/new.hml
======/guestbook/create
==search
====?
==show
====Guestbook.get()
====template/guestbook/show.hml
======/guestbook/edit?key
======/guestbook/destroy?key
==update
====Guestbook.get()
====r.put()
====/guestbook
GuestbookController
==create
====r.put()
====/guestbook
==destroy
====Guestbook.get()
====r.delete()
====/guestbook
==edit
====Guestbook.get()
====template/guestbook/edit.hml
======/guestbook/update
==index
====Guestbook.all()
====template/guestbook/index.hml
======/guestbook/new
======/guestbook/show?key
==new
====template/guestbook/new.hml
======/guestbook/create
==search
====?
==show
====Guestbook.get()
====template/guestbook/show.hml
======/guestbook/edit?key
======/guestbook/destroy?key
==update
====Guestbook.get()
====r.put()
====/guestbook
コントロール、サービス、ドキュメント
週末にPythonと格闘してGoogle App Engineの金型をつくったので、これをベースにSimpleModelerのGoogle App Engine生成器のリファインを開始。
Ruby on Rails、Grails、Google App Engine、Google App Engine Oilを一通り調べて、これらのWebフレームワークが共通して持っている問題だと思うのは、MVCのコントローラからPSM(Physical Data Model)をダイレクトにマップしたモデルを直接触る構造になっているということである。もちろん、アプリケーションが意識すればそういう構造にしないことも可能だけれど、自動生成されるCRUDのコントローラはPSMモデルを直接操作する構造になっているし、色々なクックガイドのサンプルもそういう形になっている。
この方式が問題なのは、UIのコードがデータベースのデータ構造を直接意識してしまうことと、アプリケーション・ロジックがUIコードに断片としてばら撒かれてしまう点にある。また、UIデザイナとアプリケーション・プログラマの仕事が分離しづらいという問題もある。
この問題はかつてのCS(Client/Server)で既知のものであり、CSシステムの保守や拡張を大変にしている。
作っているプログラマは楽だけれど、その後、高コストになるアーキテクチャなのである。
もちろん、作り捨てで拙速を重要視するタイプのシステムはこの戦略が合っているわけだけれど、"持続性"が大事な企業アプリケーションではそういうわけにはいかない。
この問題を解決するためには、アプリケーション・ロジックをコントローラから分離し、サービスとして独立したジュールとして作成。コントローラからはサービスを呼び出すという構造にするのがよい。
この時、コントローラからサービスを呼び出す際には"構造を持った値"によってパラメータの受け渡しをすることになる。この目的でSimpleModelingが用意しているモデル要素がdocumentである。
以上のような理由によって、SimpleModelerでは、MVCのコントローラとアプリケーション・ロジックを分離して、アプリケーション・ロジックをサービスとして部品化する構造のアプリケーションを自動生成を指向している。このアプリケーション・アーキテクチャでは、ドメイン・モデルの操作もできるだけサービスとしてカプセル化する。
昨日の作業で、この方針に沿ったそれなりのコードが出てくるようになった。
今朝から、Google App Engine SDK上で生成されたコードのデバッグとチューニング。かすかに動き始めたようである。
Ruby on Rails、Grails、Google App Engine、Google App Engine Oilを一通り調べて、これらのWebフレームワークが共通して持っている問題だと思うのは、MVCのコントローラからPSM(Physical Data Model)をダイレクトにマップしたモデルを直接触る構造になっているということである。もちろん、アプリケーションが意識すればそういう構造にしないことも可能だけれど、自動生成されるCRUDのコントローラはPSMモデルを直接操作する構造になっているし、色々なクックガイドのサンプルもそういう形になっている。
この方式が問題なのは、UIのコードがデータベースのデータ構造を直接意識してしまうことと、アプリケーション・ロジックがUIコードに断片としてばら撒かれてしまう点にある。また、UIデザイナとアプリケーション・プログラマの仕事が分離しづらいという問題もある。
この問題はかつてのCS(Client/Server)で既知のものであり、CSシステムの保守や拡張を大変にしている。
作っているプログラマは楽だけれど、その後、高コストになるアーキテクチャなのである。
もちろん、作り捨てで拙速を重要視するタイプのシステムはこの戦略が合っているわけだけれど、"持続性"が大事な企業アプリケーションではそういうわけにはいかない。
この問題を解決するためには、アプリケーション・ロジックをコントローラから分離し、サービスとして独立したジュールとして作成。コントローラからはサービスを呼び出すという構造にするのがよい。
この時、コントローラからサービスを呼び出す際には"構造を持った値"によってパラメータの受け渡しをすることになる。この目的でSimpleModelingが用意しているモデル要素がdocumentである。
以上のような理由によって、SimpleModelerでは、MVCのコントローラとアプリケーション・ロジックを分離して、アプリケーション・ロジックをサービスとして部品化する構造のアプリケーションを自動生成を指向している。このアプリケーション・アーキテクチャでは、ドメイン・モデルの操作もできるだけサービスとしてカプセル化する。
昨日の作業で、この方針に沿ったそれなりのコードが出てくるようになった。
今朝から、Google App Engine SDK上で生成されたコードのデバッグとチューニング。かすかに動き始めたようである。
2009年3月20日金曜日
python
entityとdocumentのマッピング、状態機械モデルからステートマシーン図と状態遷移表の生成ができるようになって、動的モデルを含むドメイン・モデルを扱うプログラムの生成の土台ができた。
エンティティ・オブジェクトの実装はgaeオプションやgaeoオプションですでに実現済みだけれど、状態機械による振舞いの記述やドメイン・オブジェクトを束ねるドメイン・コンポーネントといったものも生成できるようにすることを考えている。
Google App Engine用のプログラム生成器を本格的に取り掛かるわけだけれど、その前にPythonをちゃんとマスターしないといけませんねー。
ということでPythonに取り掛かる。チョー久々にEclipse Ganymedeを動かしてPyDevを入れてみた。
Eclipse使うの久しぶり。
試しにScalaのプラグインも更新してみたけど、あんまり進展はないみたい。
Pythonは、インデントを文法の論理要素に取り込んだ文法が特色だけれど、それを除いてみるとLispの上に外付けにオブジェクト機能をつけた言語という印象。オブジェクト指向言語としては美しくないような気もするけれど、メタなプログラミングをしたいフレームワーク系の人には逆に分かりやすくてよいかもしれない。
フレームワークが充実すれば、結果としてアプリケーション・プログラマにも恩恵があるので、文法が多少不思議系でもトータルとしてはメリットの方が大きい、ということかな。
その文法もとても簡潔で使いやすいので、不思議系の部分はおまじないと考えれば気にならない。
Djangoとの組合せはとてもバランスがよくて、Webアプリケーションのプレゼンテーションはこういった軽量言語が合っているということを実感。これは、ちょっと前に調べたGrailsでも感じたこと。
プレゼンテーション=>軽量言語、アプリケーション・ロジック=>Java、フレームワーク・DSLコンパイラ=>Scalaで3極化というのをこの間のセミナーのスライドで書いたけれど、そういうことなんだろうと思う。
エンティティ・オブジェクトの実装はgaeオプションやgaeoオプションですでに実現済みだけれど、状態機械による振舞いの記述やドメイン・オブジェクトを束ねるドメイン・コンポーネントといったものも生成できるようにすることを考えている。
Google App Engine用のプログラム生成器を本格的に取り掛かるわけだけれど、その前にPythonをちゃんとマスターしないといけませんねー。
ということでPythonに取り掛かる。チョー久々にEclipse Ganymedeを動かしてPyDevを入れてみた。
Eclipse使うの久しぶり。
試しにScalaのプラグインも更新してみたけど、あんまり進展はないみたい。
Pythonは、インデントを文法の論理要素に取り込んだ文法が特色だけれど、それを除いてみるとLispの上に外付けにオブジェクト機能をつけた言語という印象。オブジェクト指向言語としては美しくないような気もするけれど、メタなプログラミングをしたいフレームワーク系の人には逆に分かりやすくてよいかもしれない。
フレームワークが充実すれば、結果としてアプリケーション・プログラマにも恩恵があるので、文法が多少不思議系でもトータルとしてはメリットの方が大きい、ということかな。
その文法もとても簡潔で使いやすいので、不思議系の部分はおまじないと考えれば気にならない。
Djangoとの組合せはとてもバランスがよくて、Webアプリケーションのプレゼンテーションはこういった軽量言語が合っているということを実感。これは、ちょっと前に調べたGrailsでも感じたこと。
プレゼンテーション=>軽量言語、アプリケーション・ロジック=>Java、フレームワーク・DSLコンパイラ=>Scalaで3極化というのをこの間のセミナーのスライドで書いたけれど、そういうことなんだろうと思う。
2009年3月19日木曜日
合成状態の状態遷移表
合成状態(composite state)の入った状態遷移表が無事生成できるようになった。
横軸はイベントとガードの組、縦軸は状態の表である。合成状態は合成状態を構成するサブ状態と合成状態の擬似状態2つ(初期状態、終了状態)、そして合成状態全体を示す状態のそれぞれを軸として使用する。
この2つの軸のマトリクスによってエンティティの状態遷移を記述することができる。
また、プログラムの自動生成もこの状態遷移表の振舞いをプログラムコード化したものになる。
ネットワーク系のアプリケーションでは、仕様の概要を見るには状態遷移図がよいけれど、プログラムとして実装するためには、状態遷移表の形でより具体的、網羅的な情報が必要である。この状態遷移表で「N/A」となっている部分が仕様としてありえない組合せだけれど、実システムでは往々にしてこのような状態に陥ることがあり、そうなった時の予防的なロジックを仕込んでおく必要がある。このような抜けを網羅的につぶしていくためには状態遷移表を用いるのが有効である。
そんなこんなで、合成状態をサポートした状態機械のステートマシーン図と状態遷移表ができるようになった。
次はアクションのサポートである。
合成状態
ステートマシーン図の合成状態(composite state)完成。
合成状態そのものに対する遷移を、開始/終了擬似ステートではなくて合成状態のシンボルそのものにするようにした。このあたりはGraphvizと格闘した所。
UMLの合成状態のフルスペックというわけではないけれど、実用的には十分でしょう。後はニーズ駆動で作り足ししていく。
Graphvizのdotコマンド呼び出しでハングアップする件は、標準エラー出力のバッファあふれみたい。dotコマンド起動時にWarning出力を抑止して解決。
外部コマンドを起動して標準入出力で連携する処理を汎用的に書く場合には、標準入出力および標準エラー出力の3つの入出力に対してそれぞれ別スレッドで対応しなければならない。単一スレッドで対応する場合にはselectシステムコールを使ったポーリングのメカニズムとなる。いずれにしても単純ではない。
起動するコマンドの振舞いによっては、標準入力に一括書き込み(コマンド側は読み込み)、標準出力から一括読み込み(コマンド側は書き込み)という逐次処理で連携できることがある、という特殊な連携パターンであるということを念頭においておかなければならない。
今回の場合は、dotコマンドが一括入力、一括出力のバッチ処理であることと、コマンド引数で標準エラー出力を抑止、という工夫を併用することで、特殊な連携パターンが可能になったということである。
2009年3月18日水曜日
composite state
ステートマシーン図のcomposite stateを作成して、何とか図が出力されるようになった。ただ、謎のハングアップをするのでデバッグ継続中。
関連して2つ目の図は昨日作成したentityとdocumentの関係を記述したクラス図。
JavaDSL
SimpleModelerはScalaをDSLのホスト言語として採用しているのだけれど、以前はJavaをDSLのホスト言語として使用するモデルコンパイラを作っていた。
Javaだと記述能力上の問題もあり、Scalaがよさそうということで去年JavaからScalaに乗り換えたという経緯がある。
この間のedge2.ccでJavaのDSLを評価する声があった。理由はEclipse。Eclipseを使うとJavaのコード補完がものすごいからである。
以前JavaDSLを作っていた時も、この理由でJavaを採用したのであった。
Scalaは、DSLのホスト言語としてとても優れているので、Scalaをメインにすえるのは問題ないのだけれど、あまり複雑でないオブジェクトの定義についてはJavaをホスト言語にしても十分に記述可能なので、SimpleModelerでJavaをDSLとしてサポートする価値は高いかもしれないと思い始めている。すべてをJavaで記述しようとしなければ十分に実現可能である。
状態遷移表をExcelで書きたいというニーズもあるようなので、どこかのタイミングでこういったScala以外のDSLもサポートしていくこともしたいところである。
Javaだと記述能力上の問題もあり、Scalaがよさそうということで去年JavaからScalaに乗り換えたという経緯がある。
この間のedge2.ccでJavaのDSLを評価する声があった。理由はEclipse。Eclipseを使うとJavaのコード補完がものすごいからである。
以前JavaDSLを作っていた時も、この理由でJavaを採用したのであった。
Scalaは、DSLのホスト言語としてとても優れているので、Scalaをメインにすえるのは問題ないのだけれど、あまり複雑でないオブジェクトの定義についてはJavaをホスト言語にしても十分に記述可能なので、SimpleModelerでJavaをDSLとしてサポートする価値は高いかもしれないと思い始めている。すべてをJavaで記述しようとしなければ十分に実現可能である。
状態遷移表をExcelで書きたいというニーズもあるようなので、どこかのタイミングでこういったScala以外のDSLもサポートしていくこともしたいところである。
document、subgraph、gae、grailsなど
昨日は、entityとdocumentのrelationshipの定義機能の追加と、entityとdocumentのマッピング機能のリファイン。これらの関係を表現するクラス図の生成ができるようになった。
今日から状態機械のネストに取り掛かる。
Graphvizのsubgraphに格闘。subgraph名は先頭が"cluster"となっていないといけないらしい。バグじゃないかなぁ。ドキュメントにはそんなこと書いてないぞ。
ふと、思いついたこと。
クラウド・アプリケーションは、ACIDのRDBMS、BASEのクラウドDBを併用するアプリケーション・アーキテクチャを取る。
さて、そこで、Google App Engine。Google App Engineは当然ながらBigTableをラップしたと思われるクラウドDBしか使用することができない。このため、RDBMSを使用するためには外部のサーバーを利用する必要がある。
このようなアーキテクチャを取る場合、Google App EngineとGrails on EC2という組合せはどうだろう。
Google App Engineの範囲でできること、Googlen App EngineでなければできないことはGoogle App Engineで行い、RDBMS、SpringやJava EEといった所を使いたい場合にはGrails on EC2を併用するわけである。
Google App EngineからGrailsの呼び出しはRESTやSOAPを使えばよい。
もちろん、Messagingも使えればよいのだけれど、現時点ではGoogle App Engineでサポートしていない。そういう意味では、Java EEのJMSを利用するためにGoogle App EngineからGrails on EC2を使いにいくのもありえる。
SimpleModelerではGoogle App EngineとGrailsの両方をサポートしているので、この併用アーキテクチャもサポートできたら面白そうである。
今日から状態機械のネストに取り掛かる。
Graphvizのsubgraphに格闘。subgraph名は先頭が"cluster"となっていないといけないらしい。バグじゃないかなぁ。ドキュメントにはそんなこと書いてないぞ。
ふと、思いついたこと。
クラウド・アプリケーションは、ACIDのRDBMS、BASEのクラウドDBを併用するアプリケーション・アーキテクチャを取る。
さて、そこで、Google App Engine。Google App Engineは当然ながらBigTableをラップしたと思われるクラウドDBしか使用することができない。このため、RDBMSを使用するためには外部のサーバーを利用する必要がある。
このようなアーキテクチャを取る場合、Google App EngineとGrails on EC2という組合せはどうだろう。
Google App Engineの範囲でできること、Googlen App EngineでなければできないことはGoogle App Engineで行い、RDBMS、SpringやJava EEといった所を使いたい場合にはGrails on EC2を併用するわけである。
Google App EngineからGrailsの呼び出しはRESTやSOAPを使えばよい。
もちろん、Messagingも使えればよいのだけれど、現時点ではGoogle App Engineでサポートしていない。そういう意味では、Java EEのJMSを利用するためにGoogle App EngineからGrails on EC2を使いにいくのもありえる。
SimpleModelerではGoogle App EngineとGrailsの両方をサポートしているので、この併用アーキテクチャもサポートできたら面白そうである。
2009年3月17日火曜日
grailsとgaeoのcontroller
GrailsとGoogle App Engine Oilのcontrollerを比較。
Grails:
Google App Engine Oil:
さて、どうするか…
Grails:
- index
- list
- show
- delete
- edit
- update
- create
- save
Google App Engine Oil:
- create
- destroy
- edit
- index
- new
- search
- show
- update
さて、どうするか…
状態機械と文書
3/7のSapporo Java Days 2009 Winter、3/13のatWorksも無事終了し、これらのセミナーをターゲットに開発してきたGrails、Google App Engineも一応動作するようになった。
また、状態機械もかなりよいところまで実現できた。
これらの成果はSimpleModeler 0.1.4として公開している。
3/13のatWareに続いて、3/14のedge2.cc、3/15のMindmapModeling勉強会(SimpleModeling勉強会)での反応をみると、Google App Engineは当然として、状態機械の評判がよい。
状態機械は必要な技術であることは認識しているものの、うまく使いこなせない、ツールが整備されていないといった微妙な立場の技術といえる。
そういった意味で、状態機械はモデル駆動開発を成功させる鍵となる技術であると考えていたのだけれど、その点を確認できてよかった。
ということで粛々と状態機械の実装を続けている。
また、状態機械をプログラムとして実装する上で、SimpleModelingでdocumentとしてモデル化する文書オブジェクトの存在が重要であると考えている。
ということで、今日からdocumentを整備して状態機械に接続する処理の開発に入った。
また、状態機械もかなりよいところまで実現できた。
これらの成果はSimpleModeler 0.1.4として公開している。
3/13のatWareに続いて、3/14のedge2.cc、3/15のMindmapModeling勉強会(SimpleModeling勉強会)での反応をみると、Google App Engineは当然として、状態機械の評判がよい。
状態機械は必要な技術であることは認識しているものの、うまく使いこなせない、ツールが整備されていないといった微妙な立場の技術といえる。
そういった意味で、状態機械はモデル駆動開発を成功させる鍵となる技術であると考えていたのだけれど、その点を確認できてよかった。
ということで粛々と状態機械の実装を続けている。
また、状態機械をプログラムとして実装する上で、SimpleModelingでdocumentとしてモデル化する文書オブジェクトの存在が重要であると考えている。
ということで、今日からdocumentを整備して状態機械に接続する処理の開発に入った。
2009年3月5日木曜日
mavenではまる
あさってのSapporo Java Daysで行う予定のデモの確認をしようとしたら、突如動かなくなっていた。
調査の結果、mavenのscala pluginのバージョンが3月2日に2.10に上がったことの影響のようである。
2.10でpomのエラーチェックを強化したようなのだけれど、SimpleModelが取っているマルチ・プロジェクト方式のプロジェクトのpom.xmlをうまく認識できずエラーとしてはじくことが原因のように見える。正確に調査したわけではないので絶対にそうかどうかは不明だけど。
とりあえずはprojectサービスで生成するpomでscala pluginのバージョンを2.9に指定して回避することができた。
美しい本格的な対処方法はちょっと大変なので、当面はこの方法で回避しておくかなぁ。
あさってのデモでちゃんと動くことを願うばかりである。
調査の結果、mavenのscala pluginのバージョンが3月2日に2.10に上がったことの影響のようである。
2.10でpomのエラーチェックを強化したようなのだけれど、SimpleModelが取っているマルチ・プロジェクト方式のプロジェクトのpom.xmlをうまく認識できずエラーとしてはじくことが原因のように見える。正確に調査したわけではないので絶対にそうかどうかは不明だけど。
とりあえずはprojectサービスで生成するpomでscala pluginのバージョンを2.9に指定して回避することができた。
美しい本格的な対処方法はちょっと大変なので、当面はこの方法で回避しておくかなぁ。
あさってのデモでちゃんと動くことを願うばかりである。
2009年3月3日火曜日
2009年3月1日日曜日
SimpleModeler 0.1.3b (20090301)
SimpleModeler 0.1.3b (20090301)を公開しました。
0.1.3の内部リリース版です。バグ修正が主ですが、CSVやXMindからの移入機能を強化しています。
登録:
投稿 (Atom)
